| Stateflow® | |
| On this page… |
|---|
Lifecycle of a Stateflow® Chart |
Stateflow® charts go through several stages of execution:
| Stage | Description |
|---|---|
| Inactive | Chart has no active states |
| Active | Chart has active states |
| Sleeping | Chart has active states, but no events to process |
When a Simulink® model first triggers a Stateflow chart, the chart is inactive and has no active states. After the chart executes and completely processes its initial trigger event from the Simulink model, it transfers control back to the model and goes to sleep. At the next Simulink trigger event, the chart changes from the sleeping to active stage.
See Executing an Event.
When a chart is inactive and first triggered by an event from a Simulink model, it first executes its set of default flow graphs (see Executing a Set of Flow Graphs). If this action does not cause an entry into a state and the chart has parallel decomposition, then each parallel state is entered (see Entering a State).
If executing the default flow paths does not cause state entry, a state inconsistency error occurs.
After a chart has been triggered the first time by the Simulink model, it is an active chart. When it receives another event from the model, it executes again as an active chart. If the chart has no states, each execution is equivalent to initializing a chart. Otherwise, the active children are executed. Parallel states are executed in the same order that they are entered.
By default, Stateflow charts execute once for each active input event. If there are no input events, then the charts execute once every time step. If you are modeling a system that must react quickly to inputs, you can enable super step semantics, a Stateflow chart property (see Enabling Super Step Semantics).
When you enable super step semantics, a Stateflow chart executes multiple times for every active input event or for every time step in which there are no input events. This means that the chart takes valid transition until either of these conditions occurs:
There are no more valid transitions, that is, the chart reached a stable active state configuration
The number of transitions taken exceeds a user-specified maximum number of iterations
In a super step, your chart responds faster to inputs but performs more computations in each time step. Therefore, when generating code for an embedded target, make sure that the chart can finish the computation in a single time step. To achieve this behavior, fine-tune super step parameters by setting an upper limit on the number of transitions that the chart takes per time step. For simulation targets, specify whether the chart goes to the next time step or generates an error if it reaches the maximum number of transitions prematurely. However, in generated code for embedded targets, the chart always goes to the next time step after taking the maximum number of transitions.
To enable super step semantics, follow these steps:
Right-click inside a chart and select Properties from the context menu.
The chart properties dialog box opens on your desktop.
In the chart properties dialog box, select the Enable Super Step Semantics check box.
Two additional fields appear, as shown:
Enter a value in the field Maximum Iterations in Each Super Step.
The value you enter is the maximum number of transitions a Stateflow chart can take in one super step. Try to choose a number that allows the chart to reach a stable state within the time step, based on the mode logic of your chart.
Select an action from the drop-down menu in the field Behavior after too many iterations.
Your selection determines how the chart behaves during simulation if it exceeds the maximum number of iterations in the super step before reaching a stable state. Here are the options:
| Behavior | Description | |
|---|---|---|
| Proceed | The chart goes back to sleep with the last active state configuration, that is, after updating local data at the last valid transition in the super step. | |
| Throw Error | Simulation stops and the chart generates an error, indicating
that too many iterations occurred while trying to reach a stable state.
|
Here is a model that illustrates how super step semantics differs from Classic Stateflow chart semantics:
In this model, a Constant block outputs a constant value of 20 to input u in a Stateflow chart. Because the value of u is always 20, each transition is valid. In Classic Stateflow chart semantics, the chart takes only one transition in each simulation step, incrementing y each time.
When you enable super step semantics, the chart takes all valid transitions in each time step, stopping at state C with y = 3.
When you enable super step semantics for a Stateflow chart with multiple active input events, the chart takes all valid transitions for the first active event before it begins processing the next active event. For example, consider the following model:
In this model, the Step block produces a 2-by-1 vector signal that goes from [0,0] to [1,1] at time t = 1. As a result, when the Simulink model wakes up the Stateflow chart, events E1 and E2 are both active. If you enable super step semantics, the chart takes all valid transitions for event E1, as shown in the highlighted path:
As you can see, the chart takes transitions from state A to B and then from state B to C in a single super step. The scope shows that y = 3 at the end of the super step:
In a super step, this chart never transitions to state D because there is no path from state C to state D.
If your chart contains transition cycles, taking multiple transitions in a single time step can cause infinite loops. Consider the following example:
In this example, the transitions between states A and B cycle produce an infinite loop because the value of x remains constant at 1. One way to detect infinite loops is to configure your chart to generate an error if it reaches a maximum number of iterations in a super step. See Enabling Super Step Semantics.
By default, the first time a chart wakes up it executes the default transition paths. At this time it can access inputs, write to outputs, and broadcast events. If you want your chart to begin executing from a known configuration, you can enable the option to execute at initialization. When you turn on this option, a chart's state configuration initializes at time 0 instead of at the first occurrence of an input event. The default transition paths of the chart are executed during the model initialization phase at time 0, corresponding to the mdlInitializeConditions() phase for S-functions.
You enable the option Execute (enter) Chart At Initialization in chart properties, as described in Setting Properties for Individual Charts.
Due to the transient nature of the initialization phase, do not perform certain actions in the default transition paths of the chart — and associated state entry actions — which execute at initialization. Follow these guidelines:
Do not access chart input data because the blocks connected to Stateflow chart input ports may not have initialized their outputs yet.
Do not call exported graphical functions from other charts because those charts may not have been initialized yet.
Do not broadcast function-call output events because the triggered subsystems may have not been initialized yet.
Execute at initialization is ignored in Stateflow charts that do not contain states.
| Executing an Event | Executing a Transition | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |