Use Events to Execute Charts

Events control when Stateflow charts execute. Event-triggered charts remain inactive until an event wakes them up. The chart then processes the required actions and returns to an inactive state. Using events to control Stateflow^® charts reduce computational load and ensures charts only run when needed. In automotive, aerospace, and other control applications, events can coordinate multiple charts and subsystems by triggering execution at specific moments.

When an event-triggered chart receives an event, it follows a standard execution sequence: wake up, execute transitions and actions from top to bottom through the chart hierarchy, then become inactive. Events can interrupt ongoing actions, and charts handle these interruptions using early return logic to maintain consistent behavior. Events queue when a chart is busy, ensuring no events are lost during execution.

For more information, see Synchronize Model Components by Using Events.

How Stateflow Charts Respond to Events

Stateflow charts respond to events in a cyclical manner.

1. An event wakes up an inactive chart.

2. The chart responds to the event by executing transitions and state actions from the top down through the chart hierarchy. Starting at the chart level:

   1. The chart checks for valid transitions between states.

   2. The chart executes during and on actions for the active state.

   3. The chart proceeds to the next level down the hierarchy.

3. The chart becomes inactive until it receives the next event.

For more information, see Execution of a Stateflow Chart.

Events in Simulink Models

In Simulink^® models, Stateflow charts receive input events from other blocks in the model.

While processing an event, a state or transition action can generate explicit or implicit events that trigger additional steps. For example:

• The operator send can broadcast local or output events.

• The operators enter and exit can generate implicit local events when the chart execution enters or exits a state.

• The operator change can generate an implicit local event when the chart sets the value of a variable.

In each case, the chart interrupts its current activity to process the new event. When the activity caused by the new event finishes executing, the chart returns to the activity that was taking place before the interruption.

Note

In a Simulink model, the execution of output edge-trigger events is equivalent to toggling the value of an output data value between 0 and 1. This type of event does not interrupt the current activity of a chart. Instead, the receiving block processes the event the next time that the model executes the block. For more information, see Activate a Simulink Block by Sending Output Events.

Early Return Logic

When Stateflow charts process events, they might encounter timing conflicts. For example, a local event can interrupt and invalidate the action that generated it. Early return logic checks that when a local event changes the state configuration, any ongoing actions are evaluated for validity. If the action that initiated the event is no longer valid, the chart terminates that action early rather than completing potentially contradictory operations.

Early return logic affects action types based on their relationship to the state activity. Actions that depend on specific states being active terminate if those states become inactive during local event processing.

Action Type	Early Return Logic
State entry action	If the state is no longer active after the local event is processed, the chart stops the process of entering the state. The chart does not perform the remaining statements in the entry action. If an event inside an entry action causes the chart to exit and reenter the same state that sent the event, the chart does not perform the remaining statements in the entry action. (since R2024a)
State during action	If the state is no longer active after the local event is processed, the chart stops executing the state. The chart does not perform the remaining statements in the during action.
State exit action	If the state is no longer active after the local event is processed, the chart stops the process of exiting the state. The chart does not perform the remaining statements in the exit action nor any transition actions and state entry actions that result from exiting the state.
Condition action	If the source state of the inner or outer transition path, or the parent state of the default transition path, is no longer active after the local event is processed, the chart stops the transition process. The chart does not perform the remaining actions on the transition path or any state exit and entry actions that result from taking the transition.
Transition action	If the parent of the transition path is not active, or if the parent has an active substate, the chart stops the transition process. The chart does not perform the remaining actions on the transition path or any state entry actions that result from taking the transition.

For example, in this chart, the input event E and the local event F trigger the transitions between states.

Suppose that state A is active when the chart receives event E. The chart responds to the event with these steps:

1. The chart determines that the transition from the active state A to state B is valid as a result of event E.

2. The chart executes the condition action of the valid transition and broadcasts event F.

3. The chart interrupts the transition from state A to state B and begins to process event F.

4. The chart determines that the transition from the active state A to state C is valid as a result of event F.

5. State A executes its exit action.

6. State A becomes inactive.

7. State C becomes active.

8. State C executes its entry action.

After the chart processes event F, state C is the active state of the chart. Because state A is no longer active, the chart uses early return logic and stops the transition from state A to state B.

Tip

Avoid using undirected local event broadcasts and directed local events that create early return logic. These events can cause unwanted recursive behavior in your chart. If your chart contains these events, it generates a warning when you simulate the model. To remove events that cause recursion, see Resolve Unintended Recursive Behavior.

Events in Standalone Charts

Standalone Stateflow charts receive an input event when you call the step function or an input event function in MATLAB^®.

Standalone charts also receive implicit events from MATLAB timer objects associated with the absolute-time temporal logic operators after, at, and every. These operators define temporal logic in terms of wall-clock time. If the state associated with the temporal logic operator becomes inactive before the chart processes the implicit event, the event does not wake up the chart.

Queuing of Events

If a chart is processing another operation when it receives an event, the chart queues the event for execution when the current step is completed. You can specify the size of the event queue by setting the configuration option -eventQueueSize when you create the chart object. For more information, see Chart Object Configuration Options.

For example, in this chart, the input events E and F trigger the transitions between states. Assume that SendF is a function in the MATLAB path that calls the input event function F.

Suppose that state A is active when the chart receives event E. The chart responds to the event with these steps:

1. The chart determines that the transition from the active state A to state B is valid as a result of event E.

2. The chart executes the condition action of the valid transition and calls the function SendF.

3. SendF calls the input event function F. Because the chart is busy processing a condition action, it queues event F.

4. The chart completes executing the condition action.

5. State A executes its exit action.

6. State A becomes inactive.

7. State B becomes active.

8. State B executes its entry action.

9. The chart begins to process the queued event F.

10. The chart determines that the transition from the active state B to state D is valid as a result of event F.

11. State B executes its exit action.

12. State B becomes inactive.

13. State D becomes active.

14. State D executes its entry action.

After the chart processes event F, state D is the active state of the chart.

Control Chart Execution by Using Event Actions in a Superstate

The following example shows the use of event actions in a superstate.

In this example, the Stateflow chart is an event-triggered chart above with three input events: IE1, IE2, and IE3. When event IE3 occurs, and the Heat state is active, the chart processes the event through the chart hierarchy.

1. The chart checks to see if there is a valid transition for IE3. No valid transition exists.

2. State On executes during actions to flash the LED and check the water temperature.

3. State On executes and completes the on event IE3 action to set water temperature.

4. State On checks its child states for valid transitions.

5. If the water temperature is warm, the chart transitions from state Heat to Idle and state Idle executes its entry actions.

6. If the water temperature is not warm, the chart stays in state Heat.

7. The chart goes back to sleep.

This sequence completes the execution of the Stateflow chart associated with event IE3.