| Stateflow® | |
| On this page… |
|---|
A state describes a mode of a reactive Stateflow® chart. States in a Stateflow chart represent these modes. The following table shows the button icon for a drawing a state in the Stateflow Editor and a short description.
Name | Button Icon | Description |
|---|---|---|
State |
| Use a state to depict a mode of the system. |
States can be active or inactive. When a state is active, the chart takes on that mode. When a state is inactive, the chart is not in that mode. The activity or inactivity of a chart's states dynamically changes based on events and conditions. The occurrence of events drives the execution of the Stateflow chart by making states become active or inactive. At any point in the execution of a Stateflow chart, there is a combination of active and inactive states.
States can contain all other Stateflow objects except targets. 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 and event objects. The hierarchy of this containment appears in the Model Explorer. Data and event containment is defined by specifying the parent object when you create it. See Defining Data, Defining Events, and Defining Interfaces to Simulink® Models and the MATLAB® Workspace for information and examples on representing data and event objects in the Model Explorer.
In the following example, 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 Stateflow 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.
Stateflow hierarchy can also be represented textually, in which the Stateflow chart is represented by the slash (/) character and each level in the hierarchy of states is separated by the period (.) character. This 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
Every state (and chart) has a decomposition that dictates what kind of substates it can contain. All substates of a superstate must be of the same type as the superstate's decomposition. Decomposition for a state can be exclusive (OR) or parallel (AND). These types of decomposition are described in the following topics:
Exclusive (OR) state decomposition for a superstate (or chart) is indicated when its substates have solid borders. Exclusive (OR) decomposition is used to describe system modes that are mutually exclusive. When a state has exclusive (OR) decomposition, only one substate can be active at a time. The children of exclusive (OR) decomposition parents are OR states.
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 any one time.
The children of parallel (AND) decomposition parents are parallel (AND) states. Parallel (AND) state decomposition for a superstate (or chart) is indicated when its substates have dashed borders. This representation is appropriate if all states at that same level in the hierarchy are always 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 bind:events, data on event_name:on event_name actions
The following example demonstrates the components of a state label.
Each of the above actions is described in the subtopics that follow. For more information on state actions, see the following topics:
Entering, Executing, and Exiting a State — Describes how and when entry, during, exit, and on event_name actions are taken.
State Action Types— Gives more detailed descriptions of each type of state action.
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 example, Transmission or Green_on.
The use of hierarchy provides some flexibility in the naming of states. The name that you enter as part of the label must be unique when preceded by its ancestor states. The name stored in the Stateflow hierarchy is the text you enter as the label on the state, preceded by the names of its parent states separated by periods. Each state can have the same name appear in the label of the state, as long as their full names within the Stateflow 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 Stateflow chart. Although the name portion of the label on these states is not unique, when the parent state is prefixed to the name in the hierarchy, the result is unique. The full names for these states are as follows:
Ride1.On
Ride1.Off
Ride2.On
Ride2.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 by adding additional on event_name lines for different events.
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 Event_Name Action. Preceded by the prefix on event_name, where event_name is a unique event. 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. In the preceding label example, the data on_count is bound to the state On. This means that only the state On or a child of On can change the value of on_count. Other states, such as the state Off, can use on_count in its actions, but it cannot change its value in doing so.
| Overview of Stateflow® Objects | Transitions | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
