An event is a construct that represents an action, transition, or condition. You can
broadcast events from within a model hierarchy. Events can connect blocks that detect
important conditions with a partition to schedule the execution of the partition when the
conditions occur. The Schedule Editor allows you to create and manage partitions and schedule
the execution of your model. You can bind an event to an aperiodic partition that is
scheduled, based on priority, for execution when the event is broadcast. Starting in R2020b,
Schedule Editor events can be sent from Stateflow® charts by using the
send keyword. Events simplify system
creation and provides more flexibility during scheduling.
Each model in a model hierarchy has its own Events panel in the Schedule Editor, that contains all the events present in the model and the model's children. When you open the Schedule Editor and update the diagram, all partitions and events present in the model appear in the Schedule Editor. Through the Events panel, you can:
Create an event.
Delete an event.
Rename an event.
Get an event.
Bind an event to a partition.
Unbind an event from a partition.
You can schedule the execution of an aperiodic partition based on broadcasting of a particular event in the Stateflow Chart as shown below:
The Events panel in the Schedule Editor shows you the event tree. Under every event, you can see the broadcasters and listeners of that event.
When an event is bound to a partition, the event name appears on the left side of the partition and in, the Trigger column of the Order table.
Unique names are enforced for events within a model and within a model hierarchy.
Within a model hierarchy, the model name prepends the event name. For example, if the
model reference named
ModelName contains an event,
E1, then that event appears as
ModelName.E1 in the
Bind Events. An event and a partition can be bound together to indicate that the partition executes when the event is broadcast. A partition may only be bound to a single event.
Priority Based Execution. If the event-bound partition is scheduled to run before the partition driving the event, then the event-bound partition execution preempts the execution of the partition driving the event. If the triggered partition is scheduled to run after the partition driving the event, then the triggered partition executes when the scheduler reaches its position in the execution order.
listenerPartition is an aperiodic partition and a listener to the
Event1. Suppose that
Event1 comes from a
Stateflow Chart present in the model and is a part of the partition called,
Event1 occurs, which then triggers the execution of
Hit Times. You can trigger an aperiodic partition at specified hit times. If a partition has hit times and gets bound to an event, the hit times are replaced with the specified event. Likewise, if a partition is bound to an event and hit times are added, then the bound event is removed from the partition. Variables can also specify hit times for the aperiodic partitions. In case of ambiguous variable and events names, events are given precedence.
This example shows how you can use events to schedule the execution of aperiodic partitions via a Stateflow chart. You can send events from Stateflow and use those events to control the execution of the partitions in the model by using events in Schedule Editor.
Open the Model
In this example, we simulate the digital speed control of an internal combustion engine. In this model, the angular velocity of the engine is measured using two redundant Hall sensors, and we simulate the failure of the Hall sensors.
The model primarily contains the following main components:
System Inputs: Inputs and signals to exercise the system.
Engine: Simplified representation of internal combustion engine.
Composition: Digital controller intended to deploy on an Engine Control Unit (ECU), with a Run-time Environment (RTE).
Crank Dual Hall Sensor: Emulation of two redundant sensors,
sensor A and
RTE Services: Emulation of the services provided by Engine Control Unit.
The system inputs for this model are designed using the Signal Editor block. The
ex_engine_speed_control_external_inputs.mat file contains the following scenario:
The desired angular velocity is set to
2000 rpm for the entire simulation.
t = 01 sec, the speed controller is enabled. As a result,
Hall sensor A is being used to compute the angular velocity and the engine speed increases to
t = 06 sec, a failure of the first Hall sensor is injected. As a result,
Hall sensor B is now being used to compute the angular velocity, the engine speed remains at
t = 11 sec, a failure of the second sensor is injected. As a result, the speed controller is disabled, the engine speed falls toward zero.
t = 15 sec, the failure of
sensors A and
B gets resolved.
t = 21 sec, the command to enable speed control is cycled back to zero for one second and back to one. As a result, the engine speed increases to
The engine dynamics are represented by a Transfer Function that receives a throttle command and converts it into torque, and a Second Order Integrator to integrate the motion.
ex_engine_speed_controller_composition implements the digital control algorithm. It contains the following components:
ComputeRPM_B: Aperiodic partitions registered as hardware interrupts.
Hall sensors A and
B trigger these partitions when the engine shaft rotates by every increment of 10 degrees.
computeThrottle and actuatorProcessing:
computeThrottle interrogates the RTE at every time step.
monitorMalfunction: Periodic partition executing at 0.01 sec. Monitors output signals of
ComputeRPM_B to identify potential hardware failures. If a failure is detected, it calls a function provided by the RTE to register the failure.
checkForRecovery: Aperiodic partition that is triggered by RTE once a failure has been detected. Upon detection,
checkForRecovery is called by the RTE at a rate of 1 sec. It calls a function provided by the RTE if a recovery is detected.
Using the Schedule Editor, the events
trigCrankB are created and bound to aperiodic partitions
ComputeRPM_B respectively. These events are broadcast from the top level model.
Crank Dual Hall Sensor
The Hall sensors are modeled using Hit Crossing blocks that generate a function-call every time the engine shaft rotates by increments of 10 degrees. When the Stateflow chart gets triggered, it sends events
trigCrankB, which have been bound to execute aperiodic partitions,
RTE Services subsystem emulates functionalities available on the Run-time Environment onto which the code generated form the digital controller is deployed. For simulation purposes, those services are emulated using Simulink Functions.
recoverFailureStatus are called respectively by the
checkForRecovery partitions when a failure or a recovery is detected. The global failure statuses are stored using Data Store Memory blocks for simulation purposes.
getFailureMode is called by the
computeThrottle to verify if a failure has been detected in one of the sensors.
getTimeB simulate the RTE clock.
Check for Recovery simulates the logic to determine when the
checkForRecovery aperiodic partition of the digital controller should be triggered. Triggering is done by broadcasting the event
Open the Schedule Editor
To open the Schedule Editor, on the Modeling tab in the Design Section, click Schedule Editor. Doing an Update Diagram compiles the models and shows you the existing partitions in the Schedule Editor.
Events Panel in the Schedule Editor
The events broadcast by the
send keyword in Stateflow are shown in the Events panel of the Schedule Editor, these events are bound to aperiodic paritions, so that these partitions can be triggered from the top model. In the Events panel, you can expand each event to see the listeners and the broadcasters of that event. The icon, indicates broadcaster of the event and the icon, indicates the listner. In this example, the sender of the event
checkForRecovery is the Stateflow Chart in
RTE Services subsystem, the sender of the events
trigCrankB is the Stateflow chart in the Crank Dual Hall -> Sensor A and Sensor B.
In the Order panel, the partitions are arranged in the order of priorty of execution. Since
ComputeRPM_B are time sensitive, their priority is the highest. Therefore, when the events
trigCrankB are broadcast, the corresponding partitions
ComputeRPM_B are executed immediately. In contrast, the aperiodic partition
checkForRecovery is less time sensitive, and is lower in the priority order. Therefore, when the event
checkForRecovery is broadcast, the execution of the corresponding partition
checkForRecovery is deferred until all the partitions with higher priority complete execution.
Click on View Results in Simulation Data Inspector in the model to view the results of the simulation.
You can use the Schedule Editor to generate a test harness for a model with events. Using events with test harnesses helps you avoid complex wiring between the test sequence block and the entire system.
The generated test harness gets its own Schedule Editor, which enables you to easily send events through the test harness. Through the test harness scheduler, you can test the model under different scenarios by triggering events at specific times.
The Events panel also allows you to bind existing events to other aperiodic partitions. You can do this by dragging and dropping the event over a valid aperiodic partition, or by adding the partition directly using the dropdown. You can order the partitions that have events as their Trigger in the Order table relative to the other partitions.You can also create events in Schedule Editor. Click the plus icon. Double click Add Row to create a new event. You can use this event to send from Stateflow to schedule execution of an aperiodic partition.
Events in the Schedule Editor cannot be used in models with export-functions.
Events do not support code generation and do not impact the generated code.
Events in the Schedule Editor use the following guidelines:
An event cannot be raised before that event has processed.
Duplicate event names in the parent model caused by giving two model references the same name are not allowed.
Infinite looping is not allowed.
A partition cannot raise an event that triggers itself.