How Chart Constructs Interact During Execution

Overview of the Example Model

The example model shows how common graphical and nongraphical constructs in a chart interact during execution. These constructs include:

  • Conditions and condition actions

  • Exclusive (OR) states

  • Flow charts

  • Function calls

  • History junctions

  • Parallel (AND) states

  • State actions

  • Transitions guarded by input events

For details of the chart semantics, see Phases of Chart Execution.

Model of the Check-In Process for a Hotel

This example uses the hotel check-in process to explain Stateflow® chart semantics. To open the model, click sf_semantics_hotel_checkinsf_semantics_hotel_checkin or type sf_semantics_hotel_checkin at the MATLAB® command prompt.

The model consists of four Manual Switch blocks, one Mux block, one Multiport Switch block, a Hotel chart, and a Display block.

The model uses this block...To...Because...

Manual Switch

Enable toggling between two settings during simulation without having to pause or restart.

During simulation, you can interactively trigger the chart by sending one of these input events:

  • Checking in to a hotel

  • Calling room service

  • Triggering a fire alarm

  • Sending an all-clear signal after a fire alarm

Mux

Combine multiple input signals into a vector.

A chart can support multiple input events only if they connect to the trigger port of a chart as a vector of inputs.

Multiport Switch

Enable selection among more than two inputs.

This block provides a value for the chart input data room_type, where each room type corresponds to a number (1, 2, or 3).

A Manual Switch block cannot support more than two inputs, but a Multiport Switch block can.

Display

Show up-to-date numerical value for input signal.

During simulation, any change to the chart output data fee appears in the display.

The Hotel chart contains graphical constructs, such as states and history junctions, and nongraphical constructs, such as conditions and condition actions.

For a mapping of constructs to their locations in the chart, see Common Graphical and Nongraphical Constructs.

How the Chart Interacts with Simulink Blocks

Chart Initialization

When simulation starts, the chart wakes up and executes its default transitions because the Execute (enter) Chart At Initialization option is on (see Execution of a Chart at Initialization). Then the chart goes to sleep.

    Note:   If this option is off, the chart does not wake up until you toggle one of the Manual Switch blocks. You can verify the setting for this option in the Chart properties dialog box. Right-click inside the top level of the chart and select Properties from the context menu.

Chart Interaction with Other Blocks

The chart wakes up again only when an edge-triggered input event occurs: check_in, room_service, fire_alarm, or all_clear. When you toggle a Manual Switch block for an input event during simulation, the chart detects a rising or falling edge and wakes up. While the chart is awake:

  • The Multiport Switch block provides a value for the chart input data room_type.

  • The Display block shows any change in value for the chart output data fee.

Chart Inactivity

After completing all possible phases of execution, the chart goes back to sleep.

Phases of Chart Execution

The following sections explain chart execution for each shaded region of the Hotel chart.

    Tip   Click a shaded region to jump directly to information about that phase of chart execution.

Phase: Chart Initialization

This section describes what happens in the Front_desk state just after the chart wakes up.

StageHotel ScenarioChart Behavior
1

Your first stop is at the front desk of the hotel.

At the chart level, the default transition to Check_in occurs, making that state active. Then, the default transition to Front_desk occurs, making that state active.

For reference, see Steps for Entering a State.

2

You leave the front desk after checking in to the hotel.

The check_in event guards the outgoing transition from Front_desk. When the chart receives an event broadcast for check_in, the transition becomes valid.

For reference, see How Charts Process Events.

3

Just before you leave the front desk, you pick up your bags to move to your room.

Just before the transition occurs, the exit action of Front_desk sets the move_bags local data to 1. Then, Front_desk becomes inactive.

For reference, see Steps for Exiting an Active State.

Modeling Guidelines for Chart Initialization.  The following guidelines apply to chart initialization.

Modeling GuidelineWhy This Guideline AppliesReference

Use exclusive (OR) decomposition when no two states at a level of the hierarchy can be active at the same time.

This guideline ensures proper chart execution. For example, Check_in and Waiting_area are exclusive (OR) states, because you cannot be inside and outside the hotel at the same time.

Use a default transition to mark the first state to become active among exclusive (OR) states.

This guideline prevents state inconsistency errors during chart execution.

Use events, instead of conditions, to guard transitions that depend on occurrences without inherent numerical value.

Since you cannot easily quantify the numerical value of checking into a hotel, model such an occurrence as an event.

Use an exit action to execute a statement once, just before a state becomes inactive.

Other types of state actions execute differently and do not apply:

  • Entry actions execute once, just after a state becomes active.

  • During actions execute at every time step (except the first time step after a state becomes active). Execution continues as long as the chart remains in that state and no valid outgoing transitions exist.

  • On event_name actions execute only after receiving an event broadcast.

Phase: Evaluation of Outgoing Transitions from a Single Junction

This section describes what happens after exiting the Front_desk state: the evaluation of a group of outgoing transitions from a single junction.

StageHotel ScenarioChart Behavior
1

You can move to one of three types of rooms.

After the check_in event triggers a transition out of Front_desk, three transition paths are available based on the type of room you select with the Multiport Switch block. Transition testing occurs based on the priority you assign to each path.

For reference, see Order of Execution for a Set of Flow Charts.

2

If you choose an executive suite, the base fee is 1500.

If the room_type input data equals 1, the top transition is valid. If this condition is true, the condition action executes by setting the fee output data to 1500.

    Note:   If the top transition is not valid, control flow backtracks to the central junction so that testing of the next transition can occur. This type of backtracking is intentional.

    To learn about unintentional backtracking and how to avoid it, see Backtrack in Flow Charts and Best Practices for Creating Flow Charts.

3

If you choose a family suite, the base fee is 1000.

If room_type equals 2, the middle transition is valid. If this condition is true, the condition action executes by setting fee to 1000.

4

If you choose a single room, the base fee is 500.

If room_type equals 3, the bottom transition is valid. If this condition is true, the condition action executes by setting fee to 500.

 What happens if room_type has a value other than 1, 2, or 3?

Modeling Guidelines for Evaluation of Outgoing Transitions.  The following guidelines apply to transition syntax.

Modeling GuidelineWhy This Guideline AppliesReference

Use conditions, instead of events, to guard transitions that depend on occurrences with numerical value.

Because you can quantify a type of hotel room numerically, express the choice of room type as a condition.

What Is a Flow Chart?

Use condition actions instead of transition actions whenever possible.

Condition actions execute as soon as the condition evaluates to true. Transition actions do not execute until after the transition path is complete, to a terminating junction or a state.

Unless an execution delay is necessary, use condition actions instead of transition actions.

Supported Action Types for States and Transitions

Use explicit ordering to control the testing order of a group of outgoing transitions.

You can specify explicit or implicit ordering of transitions. By default, a chart uses explicit ordering. If you switch to implicit ordering, the transition testing order can change when graphical objects move.

Evaluation Order for Outgoing Transitions

Phase: Execution of State Actions for a Superstate

This section describes what happens after you enter the Checked_in state, regardless of which substate becomes active.

StageHotel ScenarioChart Behavior
1

After reaching your desired room, you finish moving your bags.

The entry action executes by setting the move_bags local data to 0.

2

If you order room service, your hotel bill increases by a constant amount.

If the chart receives an event broadcast for room_service, these actions occur:

  1. The counter for the service local data increments by 1.

  2. A function call to expenses occurs, which returns the value of the hotel bill stored by the fee output data.

For reference, see How Charts Process Events.

Modeling Guidelines for Execution of State Actions.  The following guidelines apply to state actions.

Modeling GuidelineWhy This Guideline AppliesReference

Use an entry action to execute a statement once, right after a state becomes active.

Other types of state actions execute differently and do not apply:

  • During actions execute at every time step until there is a valid transition out of the state.

  • Exit actions execute once, just before a state becomes inactive.

State Action Types

Use an On event_name action to execute a statement only after receiving an event broadcast.

Use a superstate to enclose multiple substates that share the same state actions.

This guideline enables reuse of state actions that apply to multiple substates. You write the state actions only once, instead of writing them separately in each substate.

Create Substates and Superstates

Phase: Function Call from a State Action

This part of the chart describes how you can perform function calls while a state is active.

StageHotel ScenarioChart Behavior
1

Based on your room type and the total number of room service requests, you can track your hotel bill.

expenses is a MATLAB function that takes the total number of room service requests as an input and returns the current hotel bill as an output.

If you double-click the function box, you see this script in the function editor:

function y = expenses(x)

if (room_type == 1)
   y = 1500 + (x*50);
else
   if (room_type == 2)
      y = 1000 + (x*25);
   else
      y = 500 + (x*5);
   end
end

Modeling Guidelines for Function Calls.  The following guidelines apply to function calls.

Modeling GuidelineWhy This Guideline AppliesReference

Use MATLAB functions for performing numerical computations in a chart.

MATLAB functions are better at handling numerical computations than graphical functions, truth tables, or Simulink® functions.

MATLAB Functions in a Chart

Use descriptive names in function signatures.

Descriptive function names enhance readability of chart objects.

Phase: Execution of State with Exclusive Substates

This part of the chart shows how a state with exclusive (OR) decomposition executes.

StageHotel ScenarioChart Behavior
1

When you reach the executive suite, you enter the bedroom first.

    Note:   The executive suite has separate bedroom and dining areas. Therefore, you can be in only one area of the suite at any time.

When the condition room_type == 1 is true, the condition action fee = 1500 executes. Completion of that transition path triggers these state initialization actions:

  1. Checked_in becomes active and executes its entry action.

  2. Executive_suite becomes active.

  3. The default transition to Bedroom occurs, making that state active.

For reference, see Steps for Entering a State.

2

When you order room service, you enter the dining area to eat.

When the room_service event occurs, the transition from Bedroom to Dining_area occurs.

3

When you want the food removed from the dining area, you order room service again and then return to the bedroom.

When the room_service event occurs, the transition from Dining_area to Bedroom occurs.

4

If you leave the executive suite because of a fire alarm, you return to your previous room after the all-clear signal.

If a transition out of Executive_suite occurs, the history junction records the last active substate, Bedroom or Dining_area. For details on how this transition can occur, see Phase: Events Guard Transitions Between States.

Modeling Guidelines for Execution of Exclusive (OR) States.  The following guidelines apply to exclusive (OR) states.

Modeling GuidelineWhy This Guideline AppliesReference

Use exclusive (OR) decomposition when no two states at that level of the hierarchy can be active at the same time.

This guideline ensures proper chart execution. For example, Bedroom and Dining_area are exclusive (OR) states, because you cannot be in both places at the same time.

If reentry to a state with exclusive (OR) decomposition depends on the previously active substate, use a history junction. This type of junction records the active substate when the chart exits the state.

If you do not record the previously active substate, the default transition occurs and the wrong substate can become active upon state reentry.

For example, if you were eating when a fire alarm sounded, you would return to the bedroom instead of the dining room.

Phase: Execution of State with Parallel Substates

This part of the chart shows how a state with parallel (AND) decomposition executes.

StageHotel ScenarioChart Behavior
1

When your family reaches the suite, family members can be in both bedrooms (for example, parents in the master bedroom and children in the second bedroom). A default room choice does not apply.

When the condition room_type == 2 is true, the condition action fee = 1000 executes. Completion of that transition path triggers these state initialization actions:

  1. Checked_in becomes active and executes its entry action.

  2. Family_suite becomes active.

  3. The parallel states wake up in the order given by the number in the upper right corner of each state: Master_bedroom, then Second_bedroom.

     How do I specify the order?

For reference, see Steps for Entering a State.

2

You can occupy both rooms at the same time.

Master_bedroom and Second_bedroom remain active at the same time.

Modeling Guidelines for Execution of Parallel (AND) States.  The following guidelines apply to parallel (AND) states.

Modeling GuidelineWhy This Guideline AppliesReference

Use parallel (AND) decomposition when all states at that level of the hierarchy can be active at the same time.

This guideline ensures proper chart execution. For example, Master_bedroom and Second_bedroom are parallel states, because you can occupy both rooms at the same time.

Use no history junctions in states with parallel (AND) decomposition.

This guideline prevents parsing errors. Since all parallel states at a level of hierarchy are active at the same time, history junctions have no meaning.

Use explicit ordering to control the execution order of parallel (AND) states.

You can specify explicit or implicit ordering of parallel states. By default, a chart uses explicit ordering. If you switch to implicit ordering, the execution order can change when parallel states move.

Phase: Events Guard Transitions Between States

This part of the chart describes how events can guard transitions between exclusive (OR) states.

StageHotel ScenarioChart Behavior
1

If a fire alarm sounds, you leave the hotel and move to a waiting area outside.

When the chart receives an event broadcast for fire_alarm, a transition occurs from a substate of Check_in to Waiting_area.

 How does this transition occur?

2

If an all-clear signal occurs, you can leave the waiting area and return to your previous location inside the hotel.

When the chart receives an event broadcast for all_clear, a transition from Waiting_area to the previously active substate of Check_in occurs.

The history junction at each level of hierarchy in Check_in enables the chart to remember which substate was previously active before the transition to Waiting_area occurred.

 How does this transition occur?

Modeling Guidelines for Guarding Transitions.  The following guideline discusses the use of events versus conditions.

Modeling GuidelineWhy This Guideline AppliesReference

Use events, instead of conditions, to guard transitions that depend on occurrences without numerical value.

Because you cannot easily quantify the numerical value of a fire alarm or an all-clear signal, model such an occurrence as an event.

Activate a Stateflow Chart Using Input Events

Was this topic helpful?