| Products & Services | Solutions | Academia | Support | User Community | Company |
| Download Product Updates | | | Get Pricing | | | Trial Software |
| Documentation → SimEvents |
| Contents | Index |
| Learn more about SimEvents |
| On this page… |
|---|
Opening a Time-Based Simulink Demo Running the Hybrid F-14 Simulation Confirming Event-Based Behavior Using the SimEvents Debugger Visualizing the Sampling and Latency |
This section describes how to modify a time-based model by adding some discrete-event behavior. The original demo is a model of a flight controller in an aircraft. The modifications are a first step toward simulating a remote flight controller for the same aircraft. The aircraft dynamics are unchanged, but the controller and the aircraft (plant) are separated. A simple way to model a separation is a time delay, which is what this example does. A variation on the example also complicates the interaction between controller and aircraft by modeling occasional transmission failures.
Using the example model, this section shows you how to:
Attach data from time-based dynamics to entities whose timing is independent of the time-based dynamics
Use an entity's departure event to cause the update of a signal that influences time-based dynamics
Create a simple model of a hybrid system and then vary it to explore other behaviors
Note More realistic ways to model a remote-control system might involve communication over a shared network, where the time delays and transmission failures might depend on other network traffic. The f14_control_over_network demo shows a more complicated model of a remote flight controller. |
To open the time-based F-14 demo, enter
sldemo_f14
in the MATLAB Command Window. The model simulates the pilot's stick input with a square wave. The system outputs are the aircraft angle of attack and the G forces experienced by the pilot. A model scope displays the input and output signals. The Controller block connects to other components in the model, namely, the stick input, the q and σ signals from the aircraft dynamics model, and the actuator model.

Run the simulation by choosing Simulation > Start from the model window's menu. You can view the results graphically in the model scope.
This section describes modifying the sldemo_f14 model by inserting several SimEvents blocks between the Controller and Actuator Model blocks. The result looks like the following figures, where the SimEvents blocks are contained in a subsystem for visual neatness.
Part of Top Level of Modified Model

Subsystem Contents

The following topics describe the subsystem and then provide instructions for building it yourself:
To skip the model-building steps and open a completed version of the example model, enter simeventsdocex('doc_sldemo_f14_des') in the MATLAB Command Window.
The SimEvents blocks are an abstract representation of a simple communication link that samples the information from the remote controller and conveys that information to the aircraft:
Data from the controller is related to the subsystem via the subsystem's In1 block.
Periodically, the Event-Based Entity Generator block creates an entity, which serves as a vehicle for the data in this communication system between the controller and the aircraft.
The Set Attribute block attaches the data to the entity.
The Infinite Server block models the latency in the communication system by delaying each data-containing entity.
The Get Attribute block models the reconstruction of data at the receiver. This block connects to the subsystem's Out1 block so that the actuator block at the top level of the model can access the data.
The Entity Sink block absorbs entities after they are no longer needed.
Note This subsystem models communication from the controller to the actuator, but does not address the feedback path from the aircraft back to the controller. This model is only a first step toward modeling a remote controller. Next steps might involve modeling the communication in the feedback path and replacing the Infinite Server block with a more realistic representation of the communication link. |
To modify the sldemo_f14 model to create this example, follow these steps:
Open the Simulink and SimEvents libraries, referring to instructions in Opening a Model and Libraries if you are new. Also, open the sldemo_f14 model by entering its name in the MATLAB Command Window if you have not already done so.
Use File > Save As in the model window to save the model to your working folder as sldemo_f14_des.mdl.
Enter simeventsconfig('sldemo_f14_des','hybrid') in the MATLAB Command Window to make some model settings more appropriate for a simulation that includes discrete-event behavior.
From the Simulink Ports & Subsystems library, drag the Subsystem block into the model window and insert it between the Controller and Actuator Model blocks. The model window should look like Part of Top Level of Modified Model.
Double-click the newly inserted Subsystem block to open a subsystem window. The rest of this procedure builds the subsystem in this window.
From the Sources library in the Simulink library set, drag the Digital Clock block into the subsystem window.
Double-click the Digital Clock block to open its dialog box, set Sample time to 0.1, and click OK.
From the Entity Generators sublibrary of the Generators library of the SimEvents library set, drag the Event-Based Entity Generator block into the subsystem window.
Double-click the Event-Based Entity Generator block to open its dialog box, set Generate entities upon to Sample time hit from port ts, and click OK.
From the Signal Generators sublibrary of the Generators library, drag the Event-Based Random Number block into the subsystem window.
Double-click the Event-Based Random Number block to open its dialog box. Set Distribution to Uniform, set Minimum to 0.01, set Maximum to 0.06, and click OK.
From the Attributes library, drag the Set Attribute and Get Attribute blocks into the subsystem window.
Double-click the Set Attribute block to open its dialog box. The Set Attribute tab contains a grid. On the first row, set Name to Data, set Value From to Signal port, and click OK. The block acquires a signal input port labeled A1.
Double-click the Get Attribute block to open its dialog box. The Get Attribute tab contains a grid. On the first row, set Name to Data and click OK. The block has a signal output port labeled A1.
From the Servers library, drag the Infinite Server block into the subsystem window.
Double-click the Infinite Server block to open its dialog box. Set Service time from to Signal port t and click OK. The block acquires a signal input port labeled t.
From the SimEvents Sinks library, drag the Entity Sink block into the subsystem window.
Connect the blocks as shown in Subsystem Contents.
Save the model to preserve your modifications.
Run the sldemo_f14_des simulation by choosing Simulation > Start from the model window's menu. By comparing the plots in the model scope with the plots in the original time-based sldemo_f14 model, you can see how the discrete-event behavior affects the simulation. The latency in the control loop (that is, the delay between the controller and the actuator) degrades the behavior somewhat.
One way to experiment with the simulation is to change the latency in the control loop (that is, the delay between the controller and the actuator) and run the simulation again. Here are some suggestions:
In the Event-Based Random Number block, set Maximum to 0.1.
In the Event-Based Random Number block, set Distribution to Beta, set Minimum to 0.01, and set Maximum to 0.06.
Replace the Event-Based Random Number block with a Step block from the Simulink Sources library. In the latter block's dialog box, set Step time to 30, Initial value to 0.03, Final value to 0.07, and Sample time to 1.
You can use the SimEvents debugger to confirm the behavior in the subsystem of the sldemo_f14_des model. This section expands upon the debugger introduction in Exploring the Simulation Using the Debugger. The topics are as follows:
To open a completed version of the example model for this tutorial, enter simeventsdocex('doc_sldemo_f14_des') in the MATLAB Command Window. Save the model in your working folder as sldemo_f14_des.mdl.
To start running the sldemo_f14_des simulation in debugging mode, enter this command at the MATLAB command prompt:
sedebug('sldemo_f14_des')The simulation has initialized but does not proceed. The purpose of this example is to confirm that the event-based behavior matches what Behavior of the Subsystem describes. Specifically, the example demonstrates how to confirm this by proceeding step by step using the step function repeatedly and studying what happens.
In the SimEvents debugger, proceeding step by step means suspending the simulation before or after each occurrence that is part of the event-based behavior of the simulation. A step might or might not be later in time than the previous step because many occurrences relevant to debugging might occur simultaneously in the simulation. A step does not reflect time-based behavior, except where time-based behavior directly affects event-based behavior. Steps might not be in the same sequence that you see in the topology of the block diagram, even if the topology of the block diagram is linear, because the topology does not solely determine the event-based behavior of the simulation. For more information on the granularity of steps in the SimEvents debugger, see The Debugger Environment.
To proceed with this simulation, enter the following command several times in succession at the sedebug>> prompt:
step
Several step commands illustrate the occurrences that make up the event-based behavior of the simulation.
| Step | Description and Command Window Output |
|---|---|
| 1 | An event-based block, the Event-Based Entity Generator block in the subsystem, has sensed a relevant update in the signal that connects to the block's input port. %==============================================================================% Detected Sample-Time Hit Time = 0.000000000000000 : Block = Subsystem/Event-Based Entity Generator |
| 2 | The Event-Based Entity Generator block is about to react to the update it has detected. The indentation of the output with respect to the first output indicates that this operation is dependent on the first one. This particular response is to schedule an event that generates an entity. %..........................................................................%
Scheduling EntityGeneration Event (ev1)
: EventTime = 0.000000000000000 (Now)
: Priority = SYS1
: Block = Subsystem/Event-Based Entity Generator |
| 3 | The event calendar is about to start executing the entity generation event. %==============================================================================% Executing EntityGeneration Event (ev1) Time = 0.000000000000000 : Entity = <none> Priority = SYS1 : Block = Subsystem/Event-Based Entity Generator |
| 4 | The Event-Based Entity Generator block is about to generate an entity. %..........................................................................%
Generating Entity (en1)
: Block = Subsystem/Event-Based Entity GeneratorTo this point, the steps illustrate the part of Behavior of the Subsystem stating that the Event-Based Entity Generator block periodically creates an entity. While the periodicity is not evident from the behavior at T=0, you can infer periodicity from the discrete sample time of the Digital Clock block that connects to the Event-Based Entity Generator block. |
| 5 | The generated entity is about to advance from the entity generator to the next block, a Set Attribute block. %..........................................................................%
Entity Advancing (en1)
: From = Subsystem/Event-Based Entity Generator
: To = Subsystem/Set Attribute |
| 6 | The Set Attribute block is about to attach data to the entity, as Behavior of the Subsystem describes. The value of Data, which is 0, comes from the controller. %..........................................................................%
Setting Attribute on Entity (en1)
: Data = 0
: Block = Subsystem/Set Attribute |
| 7 | The entity, with attached data, is about to advance to the next block, an Infinite Server block. %..........................................................................%
Entity Advancing (en1)
: From = Subsystem/Set Attribute
: To = Subsystem/Infinite Server |
| 8 | The Infinite Server block is about to schedule an event representing the completion of service on the arriving entity. The scheduled time of the event is random. %..........................................................................%
Scheduling ServiceCompletion Event (ev2)
: EventTime = 0.055383948677907
: Priority = 500
: Entity = en1
: Block = Subsystem/Infinite Server |
| 9 | The event calendar is about to start executing the service completion event. %==============================================================================% Executing ServiceCompletion Event (ev2) Time = 0.055383948677907 : Entity = en1 Priority = 500 : Block = Subsystem/Infinite Server Together, the previous step and this step illustrate the part of Behavior of the Subsystem stating that the Infinite Server block models the latency in the communication system by delaying each data-containing entity. To see the delay, notice that the Time = part of the Command Window output indicates T=0 in step 3 and T>0.055 in this step. |
| 10 | The entity is about to advance from the server to the next block, a Get Attribute block. %..........................................................................%
Entity Advancing (en1)
: From = Subsystem/Infinite Server
: To = Subsystem/Get AttributeAlthough it is not apparent from the message, the Get Attribute block models the reconstruction of data at the receiver. |
| 11 | The entity is about to advance to the Entity Sink block. %..........................................................................%
Entity Advancing (en1)
: From = Subsystem/Get Attribute
: To = Subsystem/Entity Sink |
| 12 | The Entity Sink block is about to destroy the entity because it is no longer needed. %..........................................................................%
Destroying Entity (en1)
: Block = Subsystem/Entity Sink |
| 13 | The behavior cycle repeats, upon the next update of the time-based signal from the Digital Clock block to the Event-Based Entity Generator block. The next update occurs at T=0.1. %==============================================================================% Detected Sample-Time Hit Time = 0.100000000000000 : Block = Subsystem/Event-Based Entity Generator |
Exit the debugging session by entering this command at the sedebug>> prompt:
sedb.quit
The simulation ends prematurely, the debugging session ends, and the MATLAB command prompt returns.
For additional information about the SimEvents debugger, see these resources.
| Topic | Description |
|---|---|
| Video tutorial | A video example that introduces a variety of debugger features |
| Debugger function list | List of functions related to debugging |
| Overview of the SimEvents Debugger | Overview of debugging and links to other debugging topics |
By sending relevant data from sldemo_f14_des to the MATLAB workspace and examining it after the simulation, you can determine when the application updates signals during the simulation. In particular, you can confirm that the data sent from the controller to the actuator is, in fact, delayed.
To send the controller's output and actuator's input to the workspace and compare the signals after the simulation, follow these steps:
Note If you skipped the earlier model-building steps, you can open a completed version of the model for this section by entering simeventsdocex('doc_sldemo_f14_des') in the MATLAB Command Window. |
From the Simulink Sinks library, drag two copies of the To Workspace block into the top-level model window.
Double-click one To Workspace block to open its dialog box, set Variable name to tx, set Limit data points to last to Inf, set Save format to Structure With Time, and click OK.
Double-click the other To Workspace block to open its dialog box, set Variable name to rx, set Limit data points to last to Inf, set Save format to Structure With Time, and click OK.
Connect the To Workspace blocks to the input and output signals to the discrete event subsystem using branch lines, as shown.

Run the simulation.
Enter the following in the MATLAB Command Window:
n = 100; % Plot first 100 values
plot(tx.time(1:n), tx.signals.values(1:n),'b.-',...
rx.time(1:n), rx.signals.values(1:n),'rx-');
legend('Transmitted','Received')The resulting plot exhibits the data sampling and the delay in the discrete event subsystem. The data transmitted by the controller appears with blue dots, while the data received at the actuator appears with red x's. Notice that the data transmitted at T=0.1 is received slightly later and then held constant until the data transmitted at T=0.2 is received. The time points 0, 0.1, 0.2, 0.3, and so on, are significant because the subsystem generates an entity at these times and it is the entities that carry data from the controller to the actuator.
Transmitted and Received Data

In the sldemo_f14_des model, the time-based dynamics of the aircraft coexist with the event-based dynamics of the communication link. When you run this simulation, the ODE solver and an event calendar both play a role. The ODE solver simulates the time-based dynamics of the aircraft. Solving the event-based dynamics entails scheduling and processing events, such as service completion and entity generation, on the event calendar. The events representing service completion and entity generation are asynchronous and unrelated to the time-based simulation steps used in solving the ordinary differential equations of the aircraft.
In this model, time-based blocks interact with event-based blocks at the input and output of the Subsystem block. At each of its sample times, the Controller block updates the value at the input port of the Subsystem block. The Set Attribute block, which is event-based, uses the value upon the next entity arrival at the block. Such entity arrivals occur at times 0, 0.1, 0.2, and so on, and explain why the value of each received data point in the plot, Transmitted and Received Data, is the value of the transmitted signal at one of the times 0, 0.1, 0.2, and so on. The received data does not reflect values transmitted at other times.
When an entity completes its service, the entity arrives at the Get Attribute block, which is event-based. This block updates the value at the output port of the subsystem. The Actuator Model block, which is time-based, uses the value upon the next time step determined by the ODE solver.
To learn more about the event calendar and the ODE solver, see Working with Events, and Simulating Dynamic Systems in the Simulink documentation.
You can vary the implementation of the sldemo_f14_des model's remote communication from the controller to the actuator by having the communication link drop messages with small probability. When a message is dropped, the actuator continues to use the last received message, until the next time it gets an updated message.
The modified portion of the subsystem looks like the following figure.
Subsystem Modified to Drop Some Messages

The following topics describe the subsystem modifications and then provide instructions for building them yourself:
To skip the model-building steps and open a completed version of the example model, enter simeventsdocex('doc_sldemo_f14_des_drop') in the MATLAB Command Window.
In the original subsystem, every entity (with data attached to it) reaches the Get Attribute block, which sends the data out of the subsystem and to the actuator. In the modified subsystem,
The Set Attribute block assigns not only the Data attribute but also a new DropMessage attribute. The value of the DropMessage attribute is 1 with probability 0.95 and 2 with probability 0.05. The values 1 and 2 refer to the entity output ports on the Output Switch block.
Entities advance to either the Get Attribute block or a new Entity Sink block. The Output Switch block uses the DropMessage attribute of each entity to determine which path that entity takes. Because of the probability distribution, 95% of entities advance to the Get Attribute block and the remaining 5% of entities are absorbed by the Entity Sink block.
When an entity reaches the Get Attribute block, the attached data successfully reaches the actuator. When an entity uses the other path, the attached data is discarded and the actuator continues to see the data that it received from the last entity that reached the Get Attribute block.
The actuator continues to see previous data because the signal holds a value until a block updates it. When an entity is absorbed without reaching the Get Attribute block, the block does not update the signal that goes to the subsystem's Out1 block. Therefore, the value of that signal is whatever value was attached to the last entity that reached the Get Attribute block during the simulation.
This is also why the actuator sees a constant signal between successive entities, that is, between successive samples by the communication link. Although the controller issues a continuous-time signal, the communication link between the controller and actuator creates a new data-carrying entity according to a discrete-time schedule. In other words, the subsystem samples the data from the controller before transmitting it to the actuator.
To modify the subsystem in the sldemo_f14_des model to create this variation, follow these steps:
Note If you skipped the earlier model-building steps, you can open a completed version of the model for this section by entering simeventsdocex('doc_sldemo_f14_des') in the MATLAB Command Window. |
From the Routing library, drag the Output Switch block into the subsystem window.
Double-click the Output Switch block to open its dialog box. Set Number of entity output ports to 2, set Switching criterion to From attribute, set Attribute name to DropMessage, and click OK. The block retains two entity output ports, labeled OUT1 and OUT2.
Create copies of the Event-Based Random Number and Entity Sink blocks, which are already in the subsystem. You can create a copy by dragging the block with the right mouse button, or by using Edit > Copy followed by Edit > Paste.
Double-click the newly copied Event-Based Random Number block (labeled Event-Based Random Number1) to open its dialog box. Set Distribution to Arbitrary discrete, set Value vector to [1 2], set Probability vector to [0.95 0.05], set Initial seed to an odd five-digit number different from the one used in the other instance of this block, and click OK.
Double-click the Set Attribute block to open its dialog box. On the Set Attribute tab, click the Add button to create a new row in the table. In the new row, set Name to DropMessage, set Value From to Signal port, and click OK. The block acquires a signal input port labeled A2.
Delete the connection between the Infinite Server and Get Attribute blocks.
Connect the blocks as shown in Subsystem Modified to Drop Some Messages.
Use File > Save As in the model window to save the model to your working folder as sldemo_f14_des_drop.mdl.
![]() | Building a Simple Discrete-Event Model | Reviewing Key Concepts in SimEvents Software | ![]() |

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |