States

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.

State Hierarchy

To manage multilevel state complexity, use hierarchy in your Stateflow chart. With hierarchy, you can represent multiple levels of subcomponents in a system.

State Hierarchy Example

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

Objects That a State Can Contain

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.

State Decomposition

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).

Exclusive (OR) State Decomposition

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.

Parallel (AND) State Decomposition

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.

State Labels

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.

State Name

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 Guidelines 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.

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

State Actions

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.

This table summarizes the different state action types.

State Action	Abbreviation	Description
`entry`	`en`	Executes when the state becomes active.
`exit`	`ex`	Executes when the state is active and a transition out of the state occurs.
`during`	`du`	Executes when the state is active and a specific event occurs.
`bind`	none	Binds an event or data object so that only that state and its children can broadcast the event or change the data value.
`on` `event_name`	none	Executes when the state is active and it receives a broadcast of `event_name`.
`on` `message_name`	none	Executes when a message `message_name` is available.
`on after`(`n`,`event_name`) `on after`(`n`,sec) `on after`(`n`,msec) `on after`(`n`,usec)	none	Executes when: the event `event_name` has occurred at least `n` times since the associated state became active. at least `n` units of time have elapsed since the associated state became active. For more information, see `after`.
`on at`(`n`,`event_name`) `on at`(`n`,sec)	none	Executes when: the event `event_name` has occurred exactly `n` times since the associated state became active. exactly `n` seconds have elapsed since the associated state became active. For more information, see `at`.
`on before`(`n`,`event_name`) `on before`(`n`,sec) `on before`(`n`,msec) `on before`(`n`,usec)	none	Executes when: the event `event_name` has occurred fewer than `n` times since the associated state became active. fewer than `n` units of time have elapsed since the associated state became active. For more information, see `before`.
`on every`(`n`,`event_name`) `on every`(`n`,sec)	none	Executes: every `n`^th occurrence of the event `event_name` since the associated state became active. every `n` seconds since the associated state became active. For more information, see `every`.

`entry` Actions

Entry actions are executed when a state becomes active. Entry actions consist of the prefix entry (or the abbreviation en) followed by a colon (:) and one or more actions. To separate multiple entry actions, use semicolons or commas. You can also enter the actions on separate lines.

In the preceding example, the entry action id = x+y executes when the chart takes the default transition and state A becomes active. See Enter a Chart or State.

`exit` Actions

Exit actions are executed when a state is active and a transition out of the state occurs. Exit actions consist of the prefix exit (or the abbreviation ex) followed by a colon (:) and one or more actions. To separate multiple exit actions, use semicolons or commas. You can also enter the actions on separate lines.

In the preceding example, the exit action time_out executes when the chart takes one of the transitions from state A to state B or C. See Exit a State.

`during` Actions

During actions are executed when a state is active, an event occurs, and no valid transition to another state or the current state is available. During actions consist of the prefix during (or the abbreviation du) followed by a colon (:) and one or more actions. To separate multiple during actions, use semicolons or commas. You can also enter the actions on separate lines.

In the preceding example, the during action switch_on() executes whenever the state C is active because there are no valid transitions to another state. See Execution of a Stateflow Chart.

`bind` Actions

You can bind the data and events to a state by using a bind action. A bind action consists of the prefix bind followed by a colon (:) and one or more events or data. To separate multiple events and data, use semicolons or commas. You can also enter the events and data on separate lines.

Only a state and its children can change data or broadcast events bound to that state. Other states can read the bound data or listen for the bound event, but they cannot change the bound data or send the bound events.

Bind actions apply to a chart whether the binding state is active or not. In the preceding example, the bind action bind: id, time_out for state A binds the data id and the event time_out to state A. This binding prevents any other state (or its children) in the chart from changing id or broadcasting event time_out.

If a state includes actions that change data or broadcast events that bind to another state, a compile-time error occurs. For example, this chart contains two state actions that produce errors.

State Action	Reason for Error
`bind: id` in state `B`	Only one state can change the data `id`, which is bound to state A
`entry: time_out` in state `C`	Only one state can broadcast the event `time_out`, which is bound to state A

Binding a function-call event to a state also binds the function-call subsystem that it calls. The function-call subsystem is enabled when the binding state is entered and disabled when the binding state is exited. For more information about this behavior, see Control Function-Call Subsystems by Using bind Actions.

Bind actions are supported only in Stateflow charts in Simulink^® models.

`on` Actions

On actions are executed when the state is active and it receives an event or message. On actions consist of the prefix on followed by a unique event event_name or message message_name, a colon (:), and one or more actions. To separate multiple on actions, use semicolons or commas. You can also enter the actions on separate lines.

You can specify actions for more than one event or message. For example, if you want different events to trigger different actions, enter multiple on action statements in the state action label:

on ev1: action1();
on ev2: action2();

If multiple events occur at the same time, the corresponding on actions execute in the order that they appear in the state action label. For instance, in the previous example, if events ev1 and ev2 occur at the same time, then action1() executes first and action2() executes second. See Execution of a Stateflow Chart.