This chapter describes how to use RT-LAB to monitor the performance of your running simulation.

Monitoring Overview

The Monitoring is a profiler that is tightly integrated with RT-LAB and runs within your simulation on the target computers. It enables you to profile your simulations for performance, CPU usage, overruns, and synchronization problems. Monitoring provides a comprehensive set of features and provides an intuitive user interface to analyze the simulation behavior.

The monitoring feature provides:

CPU Profiling

• Account for your CPU time including I/Os calculations and RT-LAB overhead.
• Identify performance bottlenecks.
• Get detailed information on CPU usage when overruns occur.
• Evaluate how much time is left in your computation step for adding calculations, I/O access, etc.

Tasks Profiling

• Check the time spent on your user-written code or your block execution in the model.
• Determine the tasks’ execution order and concurrent execution.
• Scale your application by evaluating the effect of distribution.
• Identify and resolve deadlocks.

Distributed Monitoring

• Monitoring gives you the ability to concurrently monitor many processes running on many CPUs, thereby profiling a distributed simulation.

Monitoring Architecture & Concepts

The Monitoring service is a service running on the target that records the exact time of events occurring during the target simulation. All measurements are relative to the beginning of the simulation and are measured using an external hardware IO clock (in hardware synchronized mode) or using a processor clock (in software synchronized mode).

The monitoring service also calculates the time elapsed between these events.

These measurements are called probes. Generally, the probes are the time elapsed between two events that occur in the same time step, i.e. the beginning and the end of a task.

Tasks are any calculations performed on the target during real-time simulation. Also, note that most common tasks are completely executed during one single step and are executed at every step of the simulation.

The monitoring service measures all time spent by all RT-LAB services including acquisition, communication and IOs. It could also measure time spent by other tasks, such as user C Code function called during simulation, or time spent by one or more subsystems in the model’s diagram.

The most common and useful probes are:

The monitoring service also performs statistical analysis and summarizes this information to determine where the CPU time is going.

The monitoring service is based on the RT-LAB acquisition system and performs data acquisition similarly to normal acquisition. It means that the monitoring service performs data acquisition for N consecutive steps. Data acquisition can be triggered and acquired data can be saved to a file.

See Acquiring and Viewing Data for more information on the acquisition concepts and features. Acquired probes are sent to the host computer and can be displayed in the Monitoring View.

Enabling Monitoring

In order to be able to monitor a model, the monitoring service must be enabled before loading the model on target. Since the monitoring will add a small overhead to your model’s calculation time (a few microseconds depending on the target CPU speed), it is not enabled by default.

To enable monitoring:

• Select the model in the Project Explorer view.
• Double click the model to open its editor.
• Select the diagnostic tab. (Refer to Diagnostics Page for more information.)
• Check the Enable monitoring property.

Using the Monitoring View

The Monitoring View displays CPU usage of each task/probe executed during real-time simulation. It displays the start and stop time of each probe and its duration. It detects overruns and highlights steps where overruns are detected. 

The Monitoring View can be used with any model that has the monitoring setting enabled. You do not have to rebuild your model once you have enabled monitoring. Once the model has been selected in the Project Explorer and loaded on a target, simply open the Monitoring View to get the monitoring information:

• Click Window > Show View > Other ... menu,

and then select the RT-LAB > Monitoring view.

Click the Get Probes button in the view’s toolbar to retrieve monitoring information.

Refer to Monitoring View for more information.

Using the OpMonitor Block

The OpMonitor block provides monitoring and probe information inside the Simulink model as outputs of the block. Most common probes could be outputed from the blocks.

The model can use these values to adjust itself by enabling or disabling subsystems or to log the information to a data logging file, etc. When the block is inserted into the model, the monitoring will be enabled the next time the model is compiled and then loaded. In this case, you do not need to enable the monitoring feature using the Diagnostic Page of the model editor. Refer to the Block Library Reference Guide for more information about the OpMonitor block.

Measuring a Model’s Subsystem Calculation Time

RT-LAB monitoring provides information about RT-LAB overhead and calculation time of the whole model. Sometimes, only a part of the Simulink model needs to be monitored. In this case, user probes could be added to the model’s diagram using the OpMonitoringStart and OpMonitoringStop blocks. These blocks allow you to measure the time spent by one subsystem on the model that is connected to these blocks. Refer to the Block Library Reference Guide for more information on how to insert these blocks into the model.

Measuring User Code Source Calculation Time

User C code could be added to the Simulink model using S-functions or UCBs. This user code is part of the major and minor calculation time event. At times, parts of the user code need to be monitor. This can be achieved using the monitoring API functions provided by RT-LAB.

See the Monitoring1 template to learn how to insert monitoring probes within user code.

• Create a new RT-LAB Project.
• Type its name and then click Next.
• Select the Features/Monitoring1 template from the list of available project templates.
• Click Finish.

Events and Probes List

Here is the list of all available probes and events that can occur when a simulation is running:

The following figure shows an example of the basic probes acquired by the monitoring over time. It illustrates the data acquired for one-time step of simulation for a model with one subsystem. Here is a short description of the probes shown on this graph.

• The total step size shows the time to simulate one time step in real time; it includes all other probes.
• The execution cycle tasks are the time spent by the model to perform all model/blocks calculations and the RT-LAB services.
• The major and minor computations tasks is the time spent by the model to perform only all blocks calculations.
• The idle task is the time available that can be used to compute more calculation.

Pay attention: The major and minor calculation tasks are concurrent to the execution cycle. Also, note that small holes are visible between tasks. These holes represent the time spent by other tasks not shown on this figure.

The following figure shows a similar example but now it also includes most advanced probes. It illustrates the data acquired for one time step of simulation for a model with one subsystem. Pay attention to the order the tasks are executed. You can also see that most of the CPU time is now represented by one of the tasks (there is no hole between tasks).

Continuous Sample Time and Major/Minor Time Step

Unlike the discrete sample time, continuous sample times are divided into major time steps and minor time steps, where the minor steps represent subdivisions of the major steps. The discrete ODE solver you choose integrates all continuous states from the simulation start time to a given major or minor time step. The solver determines the times of the minor steps and uses the results at the minor time steps to improve the accuracy of the results at the major time steps. However, you see the block output only at the major time steps.

The number of subdivisions performed by the discrete solver depends on the ODE solver. For example, the ODE3 and the ODE5 solver perform 3 and 5 iterations, respectively.