Concurrent Execution with Simulink Real-

Time and Multicore Target Hardware

Running a high-fidelity plant model in real time for hardware-in-the-loop (HIL) simulation
helps reduce the need for hardware prototypes, which, in turn, reduces development time and
cost. The higher the fidelity of the model, however, the greater the risk of a CPU overrun—
overloading the CPU of the target computer.

You can reduce this risk by using concurrent execution. In concurrent execution the model is
partitioned, and each part is executed in parallel on a multicore machine. By balancing out
the computational load across the multiple cores of the target computer, concurrent execution
improves real-time system performance because it increases the amount of code that can run
within a specified sample time.

Using a model of an electric vehicle as an example, this article describes a workflow for
concurrent execution using Simulink Real-Time™ and a Speedgoat dual-core target
computer.

We will begin by running the model on a single core to obtain a baseline measure of real-time
performance. We’ll then configure the model to utilize multiple cores and run a concurrent
execution. A comparison of the single-core and multicore simulation results will show us
whether there is any risk of a CPU overrun.

The High-Fidelity Plant Model

In this example we will be using an electric vehicle model built with Simulink®,
SimDriveline™, SimElectronics®, and Simscape™ (Figure 1).

Figure 1. Baseline electric vehicle model.

The model includes the following parts:

 Test input – the drive cycle (for this test, the US06 drive cycle)
 Operator and power management subsystem
 Battery, electric drive, and vehicle model
The goal is to be able to run this high-fidelity plant model on the HIL simulator so that we
can connect a real ECU to the simulator and test its performance.

Running a Baseline Simulation

We begin by running the electric vehicle model on a single-core real-time machine to obtain
the total execution time (the computation time required to execute the model in real time).
We will use the execution time as a baseline for comparing the results of single-core and
multicore execution.

To configure the model for Simulink Real-Time we do the following:

1. Select the solver and the sample step time—in this case, the discrete solver and Ts =
0.001.
2. Set the system target file in the Configuration Parameters>Code Generation options to
“slrt.tlc.”
3. In the Configuration Parameters>Code Generation>Verification> Code Profiling
option, enable “Measure task execution time” and select the save option “All
measurement and analysis data.”

After this we build and download the model to the real-time machine and run it for 10
seconds. We then generate a code execution profiling report using the following command:

% Matlab Code-
profileInfo.modelname = 'EVdemo_4_RT'; % your model name
profData = profile_xpc(profileInfo);

The profiling report displays a summary of model execution time (Figure 2).

Figure 2. Code execution report and execution profile for baseline model.

For the baseline model, all the blocks are grouped as a single task during code generation. As
a result, the profiling report shows only two tasks: timer interrupt and base rate.

The right-hand side of the report shows that the average execution time for the model task is
0.948 ms while the time needed to service the timer interrupt that triggers the model
execution is ~ 0.003 ms.

The Execution profile shows that the tasks are being executed sequentially (Figure 3).
Figure 3. Execution profile for baseline model.

The total execution time is the sum of the time required to service the timer interrupt and the
time required to execute the model—in this example, 0.948+0.003 =~0.951 millisecond.
This means that we have already used more than 95% of the core capacity. Any changes in
the execution time caused by the model dynamics will lead to a CPU overrun and stop the
simulation. To prevent this from happening we will use concurrent execution.

Partitioning the Model for Concurrent Execution

If the model has multiple rates, you can utilize the multiple cores of the target hardware by
enabling the “Allow tasks to execute concurrently on target” option in the configuration
parameters without restructuring the model. Depending on how much computational work is
being done within each rate, this may or may not lead to execution time benefits. Since this
step requires minimal configuration, it is an easy experiment to try. In our example, the whole
model runs at a single rate, and so we will have to explicitly partition the model in order to
derive the benefit of multiple cores.

There are many ways to partition a model. At a high level, the model partitioning can be
based on any of the following:

 Rate – partitioning based on the multiple execution rates within the model (such as
Slow rate, Fast rate)
 Physics – partitioning based on the physical characteristics of the subsystems (such as
engine model, transmission model, and electrical systems)
 Functionality – separating I/O channels and plant model components

Since the test model is single-rate and we aren’t using any I/O channels, we have partitioned
the model based on physical characteristics, as follows:

 Mechanical components – the vehicle model

 Electrical components – the battery model and the DC/DC converter
 Controls – the operator model

In the explicitly partitioned model, each top-level block must use the model reference block
from the Simulink Ports and subsystems library (Figure 4). Using model references allows us
to separate tasks at the model level.
Figure 4. Partitioned model for concurrent execution.

Configuring the Model for Concurrent Execution

To configure the model for concurrent execution, we do the following:

1. Under the solver settings in the Configuration Parameters dialog box, enable “Allow
tasks to execute concurrently on target” and select “Configure Tasks” (Figure 5).

Figure 5. Configuration parameters for partitioned model.

2. Create three separate tasks so that we can assign each referenced model to an
individual task by clicking the Add task button on the left-hand corner of the panel
(Figure 6).

Figure 6. Configuring all the model tasks.

3. Assign the respective referenced models by using the Task and Mapping tab (Figure
7).
Figure 7. Task mapping.

The model is now configured to utilize multiple cores. When the model is updated, the
assigned tasks show up as colored icons on the top left-hand side. This means that we can
always see the task assignment by looking at the top-level model.

Note that assigning tasks in this fashion changes the behavior of the simulation model by
adding unit delays at the boundaries between tasks. Concurrent execution lets you see these
changes via annotations on the task transition lines. It also allows you to simulate the changed
behavior. During model partitioning it’s a good idea to simulate the system frequently, since
unit delays can lead to changes in the functionality of the plant model.

Using the ‘Build and Download’ button we download the model to the Speedgoat real-time
target computer.

Concurrent Execution Results

After executing the model for 10 seconds, we generate a new profiling report (Figure 8).

Figure 8. Code execution report and execution profile for concurrent model.

The report confirms that the model execution has been split into three tasks rather than the
single task of the baseline model, and that the tasks are being executed in parallel. There is
also an entry for the additional timer interrupt task.

We see that the average execution time for the Battery_DCDC task is the highest. This means
that, from a computational perspective, this subsystem is taking up most of the execution
time: 0.789 ms out of the 0.948 ms as seen in the baseline model.

Since the model tasks are now being scheduled in parallel, the total time required for the
model execution is only 0.789+ 0.002 =~ 0.791— 16.82 % lower than the original 0.951 ms.

It should be noted that utilizing two cores doesn’t automatically improve performance by
50%. The actual performance improvement depends on the type of model and the way the
tasks are partitioned. In addition, data transfer between multiple cores takes time, and so there
is a penalty associated with creating additional tasks. More tasks allow us to split the model
across multiple cores, which is good, but utilizing multiple cores also increases the overhead
required for inter-core communication. For further improvements, we could use a high-
performance quad-core target computer from Speedgoat instead of a dual-core machine.

In summary, concurrent execution lets you execute high-fidelity plant models in real time by
utilizing the multiple cores of the target computer. We saw a significant reduction in total
execution time, and that gave us sufficient assurance that the real-time execution will not stop
because of CPU overruns. Reducing model execution time is beneficial in the case of HIL
testing because it means we can test the controller against a higher fidelity plant model,
which is a closer representation of the actual physical system.