A state describes an operating mode of a reactive system. In a Stateflow® chart, states are used for sequential design to create state transition diagrams.
States can be active or inactive. The activity or inactivity of a state can change depending on events and conditions. The occurrence of an event drives the execution of the state transition diagram by making states become active or inactive. At any point during execution, active and inactive states exist.
To manage multilevel state complexity, use hierarchy in your Stateflow chart. With hierarchy, you can represent multiple levels of subcomponents in a system.
In the following example, three levels of hierarchy appear in the chart. Drawing one state within the boundaries of another state indicates that the inner state is a substate (or child) of the outer state (or superstate). The outer state is the parent of the inner state.
In this example, the chart is the parent of the state Car_done
. The
state Car_done
is the parent state of the Car_made
and Car_shipped
states. The state Car_made
is also
the parent of the Parts_assembled
and Painted
states. You can also say that the states Parts_assembled
and
Painted
are children of the Car_made
state.
To represent the Stateflow hierarchy textually, use a slash character (/)
to
represent the chart and use a period (.)
to separate each level in the
hierarchy of states. The following list is a textual representation of the hierarchy of
objects in the preceding example:
/Car_done
/Car_done
.Car_made
/Car_done
.Car_shipped
/Car_done
.Car_made
.Parts_assembled
/Car_done
.Car_made
.Painted
States can contain all other Stateflow objects. Stateflow chart notation supports the representation of graphical object hierarchy in Stateflow charts with containment. A state is a superstate if it contains other states. A state is a substate if it is contained by another state. A state that is neither a superstate nor a substate of another state is a state whose parent is the Stateflow chart itself.
States can also contain nongraphical data, event, and message objects. The hierarchy of this containment appears in the Model Explorer. You define data, event, and message containment by specifying the parent object.
Every state (or chart) has a decomposition that dictates what type of substates the state (or chart) can contain. All substates of a superstate must be of the same type as the superstate decomposition. State decomposition can be exclusive (OR) or parallel (AND).
Substates with solid borders indicate exclusive (OR) state decomposition. Use this decomposition to describe operating modes that are mutually exclusive. When a state has exclusive (OR) decomposition, only one substate can be active at a time.
In the following example, either state A
or state
B
can be active. If state A
is active, either
state A1
or state A2
can be active at a given
time.
Substates with dashed borders indicate parallel (AND) decomposition. Use this decomposition to describe concurrent operating modes. When a state has parallel (AND) decomposition, all substates are active at the same time.
In the following example, when state A
is active,
A1
and A2
are both active at the same time.
The activity within parallel states is essentially independent, as demonstrated in the following example.
In the following example, when state A
becomes active, both states
B
and C
become active at the same time. When state
C
becomes active, either state C1
or state
C2
can be active.
The label for a state appears on the top left corner of the state rectangle with the following general format:
name/ entry:entry actions during:during actions exit:exit actions on event_name:on event_name actions on message_name:on message_name actions bind:events
The following example demonstrates the components of a state label.
Each action in the state label appears in the subtopics that follow. For more information on state actions, see:
Execution of a Stateflow Chart — Describes how and when chart execution occurs.
State Action Types — Gives more detailed
descriptions of each type of state action, entry
,
during
, exit
.
A state label starts with the name of the state followed by an optional
/
character. In the preceding example, the state names are
On
and Off
. Valid state names consist of
alphanumeric characters and can include the underscore (_
) character.
For more information, see Rules for Naming Stateflow Objects.
Hierarchy provides some flexibility in naming states. The name that you enter on the state label must be unique when preceded by ancestor states. The name in the Stateflow hierarchy is the text you enter as the label on the state, preceded by the names of parent states separated by periods. Each state can have the same name appear in the label, as long as their full names within the hierarchy are unique. Otherwise, the parser indicates an error.
The following example shows how unique naming of states works.
Each of these states has a unique name because of its location in the chart. The full
names for the states in FAN1
and FAN2
are:
PowerOn.FAN1.On
PowerOn.FAN1.Off
PowerOn.FAN2.On
PowerOn.FAN2.Off
After the name, you enter optional action statements for the state with a keyword label that identifies the type of action. You can specify none, some, or all of them. The colon after each keyword is required. The slash following the state name is optional as long as it is followed by a carriage return.
For each type of action, you can enter more than one action by separating each action
with a carriage return, semicolon, or a comma. You can specify actions for more than one
event or message by adding additional on
event_name
or on
message_name
lines.
If you enter the name and slash followed directly by actions, the actions are
interpreted as entry
action(s). This shorthand is useful if you are
specifying only entry
actions.
Entry Action. Preceded by the prefix entry
or en
for short.
In the preceding example, state On
has entry
action on_count=0
. This means that the value of
on_count
is reset to 0 whenever state On
becomes
active (entered).
During Action. Preceded by the prefix during
or du
for short.
In the preceding label example, state On
has two
during
actions, light_on()
and
on_count++
. These actions are executed whenever state
On
is already active and any event occurs.
Exit Action. Preceded by the prefix exit
or ex
for short.
In the preceding label example, state Off
has the
exit
action light_off()
. If the state
Off
is active, but becomes inactive (exited), this action is
executed.
On Action. Preceded by the prefix on
event_name
,
or on
message_name
. In the preceding label
example, state On
has an on power_outage
action.
If state On
is active and the event power_outage
occurs, the action handle_outage()
is executed.
Bind Action. Preceded by the prefix bind
. Events bound to a state can only be
broadcast by that state or its children.