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 — Describes how and when chart execution occurs.

• State Action Types — Gives more detailed descriptions of each type of state action, entry, during, exit.

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

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.

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.