Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| Documentation → Stateflow |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| Documentation → Stateflow |
| Contents | Index |
| Learn more about Stateflow |
| On this page… |
|---|
Lifecycle of a Stateflow Chart Execution of an Inactive 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 How Events Drive Chart Execution.
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 Order of Execution for 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 becomes active (see Steps for 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 the chart 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 execute. Parallel states execute in the same order that they become active.
By default, Stateflow charts execute once for each active input event. If no input events exist, 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 when the chart has no input events. The chart takes valid transitions until either of these conditions occurs:
No more valid transitions exist, that is, the chart is in 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:
Right-click inside a chart and select Properties from the context menu.
The Chart properties dialog box appears.
In the Chart properties dialog box, select the Enable Super Step Semantics check box.
Two additional fields appear.
Enter a value in the field Maximum Iterations in each Super Step.
This value 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.
| 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.
|
The following model shows 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 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 model wakes up the 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:
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 and 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, the chart 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, the state configuration of a chart initializes at time 0 instead of the first occurrence of an input event. The default transition paths of the chart execute 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 the Chart properties dialog box, as described in Setting Properties for a Single Chart.
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 blocks connected to chart input ports might not have initialized their outputs yet.
Do not call exported graphical functions from other charts, because those charts might not have initialized yet.
Do not broadcast function-call output events, because the triggered subsystems might not have initialized yet.
Execute at initialization is ignored in Stateflow charts that do not contain states.
 | How Events Drive Chart Execution | Process for Grouping and Executing Transitions |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
