|
|
|
| R2011b Documentation → Stateflow | |
Learn more about Stateflow |
|
| Contents | Index |
| On this page… |
|---|
To ensure that output is a function of input and state, Mealy state machines enforce the following semantics:
Outputs never depend on previous outputs.
Outputs never depend on the next state.
Chart wakes up periodically based on a system clock.
Note A chart provides one time base for input and clock (see Calculate Output and State Using One Time Base). |
Chart must compute outputs whenever there is a change on the input port.
Chart must compute outputs only in transitions, not in states.
To conform to the Mealy definition of a state machine, you must ensure that a Mealy chart computes outputs every time there is a change on the input port. As a result, you must follow a set of design rules for Mealy charts.
You can compute outputs only in the condition actions of outer and inner transitions. A common modeling style for Mealy machines is to test inputs in conditions and compute outputs in the associated action.
You cannot use state actions or transition actions in Mealy charts. This restriction enforces Mealy semantics by:
Preventing you from computing output without considering changes on the input port
Ensuring that output depends on current state and not next state
You can define inputs, outputs, local data, parameters, and constants in Mealy charts, but other data restrictions apply:
Restrict Machine-Parented Data to Constants and Parameters. Machine-parented data is data that you define for a Stateflow machine, which is the collection of all Stateflow blocks in a Simulink model. The Stateflow machine is the highest level of the Stateflow hierarchy. When you define data at this level, every chart in the machine can read and modify the data. To ensure that Mealy charts do not access data that can be modified unpredictably outside the chart, you can define only constants and parameters at the machine level.
Do Not Define Data Store Memory. You cannot define data store memory (DSM) in Mealy charts because DSM objects can be modified by objects external to the chart. A Stateflow chart uses data store memory to share data with a Simulink model. Data store memory acts as global data that can be modified by other blocks and models in the Simulink hierarchy that contains the chart. Mealy charts should not access data that can change unpredictably.
Limit the use of events in Mealy charts as follows:
| Do: | Do Not: | |
|---|---|---|
Use input events to trigger the chart | Broadcast any type of event | |
Use event-based temporal logic to guard transitions You can use event-based temporal logic in Mealy charts because it behaves synchronously (see Operators for Event-Based Temporal Logic). Think of the change in value of a temporal logic condition as an event that the chart schedules internally. Therefore, at each time step, the chart retains its notion of state because it knows how many ticks remain before the temporal event executes.
| Use local events to guard transitions You cannot use local events in Mealy charts because they are not deterministic. These events can occur while the chart computes outputs and, therefore, violate Mealy semantics that require charts to compute outputs whenever input changes. |
You can use one time base for clock and input, as determined by the Simulink solver (see Solvers). The Simulink solver sets the clock rate to be fast enough to capture input changes. As a result, a Mealy chart commonly computes outputs and changes states in the same time step.
The following chart uses Mealy semantics to model a vending machine.
To open the model of a Mealy vending machine, click sf_mealy_vending_machine or type sf_mealy_vending_machine at the MATLAB command prompt.
In this example, the vending machine requires 15 cents to release a can of soda. The purchaser can insert a nickel or a dime, one at a time, to purchase the soda. The chart behaves like a Mealy machine because its output soda depends on both the input coin and current state, as follows:
When initial state got_0 is active. No coin has been received or no coins are left.
If a nickel is received (coin == 1), output soda remains 0, but state got_nickel becomes active.
If a dime is received (coin == 2), output soda remains 0, but state got_dime becomes active.
If input coin is not a dime or a nickel, state got_0 stays active and no soda is released (output soda = 0).
In active state got_nickel. A nickel was received.
If another nickel is received (coin == 1), state got_dime becomes active, but no can is released (soda remains at 0).
If a dime is received (coin == 2), a can is released (soda = 1), the coins are banked, and the active state becomes got_0 because no coins are left.
If input coin is not a dime or a nickel, state got_nickel stays active and no can is released (output soda = 0).
In active state got_dime. A dime was received.
If a nickel is received (coin == 1), a can is released (soda = 1), the coins are banked, and the active state becomes got_0 because no coins are left.
If a dime is received (coin == 2), a can is released (soda = 1), 15 cents is banked, and the active state becomes got_nickel because a nickel (change) is left.
If input coin is not a dime or a nickel, state got_dime stays active and no can is released (output soda = 0).
This example of a Mealy vending machine illustrates the following Mealy design rules:
The chart computes outputs in condition actions.
There are no state actions or transition actions.
The chart defines chart inputs (coin) and outputs (soda).
The value of the input coin determines the output — whether or not soda is released.
 | Creating Mealy and Moore Charts | Design Considerations for Moore Charts |  |
Learn how engineers use Stateflow to model state machines in their Simulink models.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |