There are two general approaches to programming a Stateflow® chart in a Simulink® model:
Identify the operating modes of your system.
Identify the system interface, such as events to which your system reacts.
This tutorial uses the first approach— that is, start by identifying the operating modes of the system to program the chart.
This example shows how to build a Stateflow chart using MATLAB® as the action language. The model represents a machine on an assembly line that feeds raw material to other parts of the line. This feeder behaves as follows:
At system initialization, check that the three sensor values are normal.
A positive value means the sensor is working correctly. A zero means that the sensor is not working.
If all sensor values are normal, transition from "system initialization" to "on".
If the feeder does not leave initialization mode after 5 seconds, force the feeder into the failure state.
After the system turns on, it starts counting the number of parts fed.
At each time step, if any sensor reading is 2 or greater, the part has moved to the next station.
If the alarm signal sounds, force the system into the failure state.
An alarm signal can occur when an operator opens one of the safety doors on the feeder or a downstream problem occurs on the assembly line, which causes all upstream feeders to stop.
If the all-clear signal sounds, resume normal operation and reset the number of parts fed to zero.
The feeder LED changes color to match the system operating mode— orange for "system initialization", green for "on", and red for "failure state".
Based on the description of feeder behavior, you can identify the key system attributes.
|Parallel Modes||No operating modes run in parallel. Only one mode can be active at any time.|
|Default Mode||System initialization|
In this exercise, you add a Stateflow chart to a Simulink model that contains sensor and alarm input signals to the feeder.
To implement the model yourself, follow these exercises. Otherwise, you can open the completed model.
SensorSignals block to see the three
sensor signals represented by pulse generator blocks.
sensors signal indicates when the assembly part is
ready to move to the next station.
AlarmSignal block to see the step blocks
that represent the alarm signal.
ALARM signal is active, the machine turns off.
Run the model to see the output of the sensor and alarm signals in the Scope block.
The upper axis shows the sensor signals. Only two sensor signals appear because two of the sensors have the same signal. The lower axis shows the alarm signal which turns the feeder off between the simulation time of 45 to 80 seconds.
Open the Stateflow Library by executing
sflib at the MATLAB
Chart and drag it into your model.
To create a new model with an empty Stateflow chart which uses MATLAB as the action language, use the
Delete the connections from the SensorSignals subsystem to the scope and from the AlarmSignal subsystem to the scope.
Rename the label
Chart located under the Stateflow chart to
Feeder. The model should now look like
Based on the system attributes previously described, there are three operating modes:
To add states for modeling the behavior of these operating modes:
Double-click the Feeder Chart to begin adding states.
The MATLAB icon in the lower left corner of the chart indicates that you are using a Stateflow chart with MATLAB syntax.
Click the State Tool icon to bring a state into the chart.
Click the upper left corner of the state and type the name,
Repeat steps 2 and 3 to add two more states named
States perform actions at different phases of their execution cycle from the time they become active to the time they become inactive. Three basic state actions are:
|Type of Action||When Executed||How Often Executed While State Is Active|
|Entry||When the state is entered (becomes active)||Once|
|During||While the state is active and no valid transition to another state is available||At every time step|
|Exit||Before a transition is taken to another state||Once|
For example, you can use
entry actions to initialize data,
during actions to update data, and
actions to configure data for the next transition. For more information about other
types of state actions, see Syntax for States and Transitions.)
Press return after the
InitializeSystem state name
and add this text to define the state entry action:
entry: Light = ORANGE;
Add the following code after the
name to define the entry action:
entry: Light = RED;
A red LED indicates entry in the
Add the following code after the
On state name to
define the entry action:
entry: Light = GREEN; partsFed = 0;
Onstate. The number of parts fed is initialized to 0 each time we enter the
Add the following code to the
On state after the
entry action to check if there is a strong sensor signal and increment
the parts fed to the next station:
during: if(any(sensors >= 2)) partsFed = partsFed + 1; end
On state checks the sensor signal to determine
if a part is ready to be fed to the next assembly station. If the sensor
signal is strong (the number of sensors that are on is greater than or
equal to 2), then the chart counts the part as having moved on to the
The chart should now look like this figure.
Transition conditions specify when to move from one operating mode to another. When the condition is true, the chart takes the transition to the next state, otherwise, the current state remains active. For more information, see Transitions.
Based on the description of feeder behavior, specify the rules for transitions between states:
Connect a default transition to the
to indicate the chart entry point.
Default Transitions specify where to begin the simulation.
Draw a transition from the
InitializeSystem state to the
Move the mouse over the lower edge of the
InitializeSystem state until the pointer shape
changes to crosshairs.
Click and drag the mouse to the upper edge of the
On state. You then see a transition from the
InitializeSystem state to the
Double-click the transition to add this condition:
This transition condition verifies if all of the sensors have values greater than zero.
Repeat these steps to create these remaining transition conditions.
Draw another transition from
FailState. On this transition, type the following to
create the transition event:
The syntax on this transition is an event rather than a transition condition. For details, refer toControl Chart Execution by Using Temporal Logic.
The chart now looks like this figure.
The outgoing transitions from
InitializeSystem have a small
label 1 and 2 to indicate the order in which transition segments are evaluated. If
the numbers from the figure do not match your model, right click the transition and
then change it by clicking on
Execution Order. See Transition Evaluation Order for details.
Start the simulation of your model. Errors about unresolved symbols appear, along with the Symbol Wizard.
The Symbol Wizard does not automatically add any data to your chart. It identifies the unresolved data and infers the class and scope of that data using the inference rules of MATLAB expressions in Stateflow actions. In the chart:
Data that is read from but not written to is inferred as input data. However, if the name of the data is in all uppercase letters, the Symbol Wizard infers the data as a parameter
Data that is written to but not read from is inferred as output data.
Data that is read from and written to is inferred as local data.
The Symbol Wizard infers the scope of the input data in your chart. However, you
must fix the data scope for the
partsFed Output. Follow these
For the partsFed data: in the Data Scope column, select Output from the list
The Symbol Wizard now looks like this figure.
To add the data that the Symbol Wizard suggests, click OK.
Add initial values for the parameters. At the MATLAB command prompt, enter:
RED = 0;
Similarly, at the MATLAB command prompt, add the following initial values for the remaining parameters:
Return to the model and connect the inputs and outputs to their respective ports.
Start the simulation.
Double-click the Scope block to verify that the model captures the expected feeder behavior.
The upper axis shows the LED signal which varies between orange (1), green (2), and red (0) to indicate the current operating mode. The lower axis shows the number of parts fed to the next assembly station, which increases incrementally until the alarm signal turns the machine off and then resets.
Another approach to programming the chart is to start by identifying parts of the system interface, such as events to which your system reacts.
In the previous example, when you use input data to represent an event, the chart wakes up periodically and verifies whether the conditions on transitions are valid. In this case, if ALARM == 1, then the transition to the failure state happens at the next time step. However, creating a Stateflow chart which reacts to input events allows you to react to the alarm signal when the event is triggered.
For details on when to use an event-based chart, see Synchronize Model Components by Broadcasting Events.
In the event-based approach, the system attributes to consider first are the events, inputs, and outputs.
In the following table, consider the characteristics of the event-driven Feeder Model that are different from the system based on transition conditions.
|Events||Two asynchronous events: an alarm signal and an all-clear signal|
|Inputs||Three sensor readings to detect if a part has moved to a downstream assembly station|
In this example, the feeder model reacts to input events using a triggered chart.
The chart now has only one input port on the left and an event triggered input on the top. For more information on how to create a Stateflow chart activated by events, see Activate a Stateflow Chart by Sending Input Events
ALARM signal triggers the chart, the chart responds to the
trigger in that time step. If the current state is
On when the alarm
is triggered, then the current state transitions to
The scope output for the Event-triggered chart is in the following figure.
The upper axis shows the LED signal which varies between red (0), orange (1), and green (2) to indicate the current operating mode. The lower axis shows the number of parts fed to the next assembly station, which increases incrementally until the alarm signal turns the machine off and then resets. However, the event-based simulation feeds more parts to the next assembly station due to clock and solver differences.