Events in Schedule Editor
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 occurs. 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 provide more flexibility during scheduling.
Event Management in the Schedule Editor
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
A scoped event iindicates that the event is used within the context of the parent
model. A scoped event is visible in the Events panel for
the parent model. A scoped event with the name E1, that's present in the model named
ModelName, is displayed as
ModelName.E1 in the
You can set the scope of the event in the Events panel. To set the scope of the event, right click the event in the Events panel.
There are two options:
Global, – A global event indicates that an event is available for
use anywhere in the model hierarchy. You can use and connect the global event anywhere
within the model hierarchy. A global event is visible in the Events
panel for the parent model. A global event with the name
referred to as
EventName in all parent models. All global events must
have a unique ,name. These multiple instances of the events can then be triggered by the
same Stateflow chart to unify scheduling.
Scoped (default), – When the event is scoped, it indicates that the event
is used within the context of the parent model. A scoped event is visible in the
Events panel for the parent model. A scoped event with the name
E1, that's present in the model named
is displayed as
ModelName.E1 in the Events
|Event available for use only in the context of the model where it is present.||Event available for use anywhere in the model hierarchy|
|Visible in the Events panel for the model where the event is.||Visible in the Events panel for the parent model|
|Displayed as ||Displayed as |
Execution of Aperiodic Partitions with Events
Bind Events. An event and a partition can be bound together to indicate that the partition executes in response to the broadcasting of the event. 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 sending 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.
In the flochart below, for example,
listenerPartition is an
aperiodic partition and a listener to the event,
Event1. Suppose that
Event1 comes from a Stateflow Chart present in the model and is a
part of the partition called,
broadcastPartition starts executing,
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.
Schedule Partitions with Events
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,
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 rpmfor the entire simulation.
t = 01 sec, the speed controller is enabled. As a result,
Hall sensor Ais 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 Bis 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
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 Aand
Btrigger these partitions when the engine shaft rotates by every increment of 10 degrees.
actuatorProcessing: Periodic partitions executing at 0.001 sec.
computeThrottleinterrogates the RTE at every time step.
monitorMalfunction: Periodic partition executing at 0.01 sec. Monitors output signals of
ComputeRPM_Bto 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,
checkForRecoveryis 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 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.
recoverFailureStatusare called respectively by the
checkForRecoverypartitions when a failure or a recovery is detected. The global failure statuses are stored using Data Store Memory blocks for simulation purposes.
getFailureModeis called by the
computeThrottleto verify if a failure has been detected in one of the sensors.
getTimeBsimulate the RTE clock.
Check for Recoverysimulates the logic to determine when the
checkForRecoveryaperiodic 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 partitions, 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 listener. 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 priority 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.
You can view this event connection in the Simulink model, this connection conveys the flow of execution between a block broadcasting an event and another block listening to that event. To view this connection, on the Simulink Toolstrip, on the Debug tab, select Information Overlays in the Diagnostic section. From the drop-down menu, select Schedule Connectors in the Blocks section.
Click on View Results in Simulation Data Inspector in the model to view the results of the simulation.
Test Harness Generation
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.
Limitations and Error Conditions
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.