Documentation

Real-Time Execution in Normal Mode

Simulink® Desktop Real-Time™ extends Simulink normal mode to run in real time.

The simulation algorithm for a non-real-time Simulink normal mode model runs entirely within Simulink. The model can use either a fixed-step or a variable-step solver and runs as fast as it can, given the presence of competing operating system processes. However, it is not synchronized with a real-time clock and cannot easily be used to operate real-time hardware.

You can synchronize a Simulink model with a real-time clock using Simulink Desktop Real-Time I/O blocks. In real-time normal mode, Simulink executes the simulation algorithm, while a separate operating system kernel mode process runs I/O drivers for the I/O blocks. Both the Simulink process and the kernel mode process run on the host machine, using a shared memory interface to transfer parameter data.

  • Signal acquisition — You can capture and display signals from your real-time application while it is running. Simulink retrieves signal data from the I/O driver and displays it in the same Scope blocks you used for simulating your model in nonreal time.

  • Parameter tuning — You can change parameters in your Simulink block diagram and have the new parameters take effect in your Simulink model in real time. The effects then propagate through the I/O driver to the hardware.

Because only the I/O drivers are synchronized with the real-time clock, Simulink can use either a fixed-step or a variable-step solver. The Sample Time setting in the Simulink Desktop Real-Time block does not change the step size of the simulation. For a fixed-step simulation, you set the step size in the Fixed step size box from the Configuration Parameters dialog box. For a variable-step simulation, you set the step size by using the Min Step Size attribute, or Simulink determines the step size automatically.

In real-time normal mode, at each sample interval Simulink evaluates each real-time block. Simulink writes the input data into a buffer that it passes to the kernel mode process. The kernel mode process propagates the data to the hardware, which writes response data into another buffer. At the next time tick, Simulink reads the response data and propagates it to the rest of the model.

A consequence of this kind of limited synchronization is that your simulation can be configured to miss real-time clock ticks and their associated data points. Ticks can be missed under the following circumstances:

  • Complexity of Model — The model can be so complex that Simulink cannot keep up with the real-time kernel. In this case, the number of missed ticks increases steadily with time. Once the number of missed ticks exceeds Maximum Missed Ticks, an error occurs, even if Maximum Missed Ticks is set to a large value. You can identify this situation by a rising straight line on a Scope connected to the optional Missed Ticks port.

  • Process Contention — The model generally executes faster than required to keep up with the kernel. However, process contention or some random operating system condition prevents Simulink from executing the model over some time period. In this case, the number of missed ticks jumps to some number, then decreases to zero as Simulink catches up with the kernel. You can identify this situation by a sawtooth-like shape on a Scope connected to the Missed Ticks port.

  • Variable-Step Solver — If you are using a variable-step solver, the number of ticks per algorithm step can vary during simulation. If Simulink execution does not reach the Simulink Desktop Real-Time blocks in time to synchronize with the tick, the number of missed ticks jumps to some number. As Simulink catches up with the kernel, the number of missed ticks decreases to zero. As with process contention, you can identify this situation by a sawtooth-like shape on a Scope connected to the Missed Ticks port.

Related Topics

Was this topic helpful?