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.

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.

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.

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.

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.

• State Decomposition

• Specifying Substate Decomposition

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.

• Default Transitions

• State Inconsistencies in a Chart

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.

• Using Input Events to Activate a Stateflow Chart

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.

• State Action Types

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

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 Backtracking Behavior in Flow Graphs Example and Best Practices for Creating Flow Graphs.

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.

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.

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.

Modeling Logic Patterns and Iterative Loops Using Flow Graphs

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

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

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

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.

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.

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.

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

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.

Use descriptive names in function signatures.

Descriptive function names enhance readability of chart objects.

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.

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.

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.

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.

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.

• State Decomposition

• Specifying Substate Decomposition

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.

• History Junctions

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?

   To specify the order:

   1. Verify that the chart uses explicit ordering.

      In the Chart properties dialog box, select the User specified state/transition execution order check box.

   2. Right-click in a parallel state and select a number from the Execution Order menu.

For reference, see Steps for Entering a State.

You can occupy both rooms at the same time.

Master_bedroom and Second_bedroom remain active at the same time.

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.

• State Decomposition

• Specifying Substate Decomposition

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.

• History Junctions

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.

• Execution Order for Parallel States

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?

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?

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.