Real-time simulation of an engineering system becomes possible when you replace physical devices with virtual devices. This replacement reduces costs and improves the quality of physical and control systems, including their software, by enabling more complete testing of the entire system. It also enables continuous testing, without interruption and under possibly dangerous conditions. Real-time simulation allows you to test even when you have no prototypes.

Real-time simulation becomes a necessity if you want to simulate a system realistically responding to its environment. Such realistic simulation means that the inputs and outputs in the virtual world of simulation must be read or updated synchronously with the real world. When the simulation clock reaches a certain time in real-time simulation, the same amount of time must have passed in the real world.

In desktop simulation, you use models to develop and test control
and signal processing algorithms. Once the designs are complete and
you have converted these algorithms to embedded code, you must test
that code as well as the actual controller. If the model is capable
of running in real time, you can use the model created in the design
phase to test the embedded code and processor, instead of connecting
it directly to a hardware prototype. Such real-to-virtual substitution,
simulating in real time, is referred to as *hardware-in-the-loop* (HIL)
testing.

Systems with a human in the simulation loop require real-time simulation. For example, flight simulators that train pilots require real-time simulation of the plane, its control system, the weather, and other environmental conditions.

Configuring a model and a numerical integrator to simulate in real time is often more challenging than ordinary simulation. You simulate with a more restrictive version of the universal computational tradeoff of accuracy versus speed.

The simulation execution time per time step must be consistently short enough to permit any other tasks that the simulation environment must perform, such as reading sensor input or generating output actuator signals. This requirement must be satisfied even if the simulation changes its qualitative character: the system stiffness might change, and discrete components can switch states. Such changes occasionally require more computations to achieve an accurate result.

When real-time simulation is the goal, the execution time per simulation time step must be bounded. Variable-step solvers, which are often used in desktop simulation, take smaller steps to accurately capture events that occur during the simulation. But you cannot vary the step size in a real-time simulation. Instead, you must

Choose a fixed-step solver that can capture the system dynamics accurately and minimize the amount of computation required per time step, without changing the step size. If the system states are all discrete, the fixed-step solver can be discrete as well.

If you choose a small enough step size, most fixed-step solvers produce the same simulation results as a variable-step solver. However, different fixed-step solvers (implicit/explicit, lower/higher order, and so on) require different step sizes to produce accurate results. They also require different amounts of computation per time step.

Choose a fixed step size large enough to permit stable real-time simulation. The step size must not be so large that the simulation results are inaccurate, but not so small that real-time simulation is impossible.

You often need trial and error to find the right combination of settings that satisfy both criteria.

Real-time simulation requires not only bounding the execution time, but fixing it to a stable value. This requires a fixed-cost simulation method. For more information, see Customizing Solvers for Physical Models.

Achieving real-time simulation with any Simscape™ model includes:

Enabling simulation with fixed-step, fixed-cost solvers

Converting the model with Simulink Coder to code for a particular computer hardware target

Testing real-time simulation on PC-compatible hardware with Simulink Real-Time, if desired

For more information, see Code Generation.

Preparation for real-time simulation requires particular choices
and adjustment of Simulink^{®} variable-step solvers. Actual real-time
simulation requires Simulink fixed-step solvers. Certain Simscape features
enable and enhance real-time simulation of physical systems with Simulink fixed-step
solvers, both explicit and implicit. These features include fixed-cost
algorithms and local solvers, with the trapezoidal rule or backward
Euler method. See Customizing Solvers for Physical Models.

This figure plots the normalized computational cost of all fixed-step solvers available for Simscape models, obtained for a nonlinear model example with one physical network. For comparison, the step size was kept the same, with similar settings for the total number of solver iterations.

To move from desktop to real-time simulation on your real-time hardware target, adjust the following simulation properties until the simulation can execute in real time and deliver results close to the results from desktop simulation:

Solver choice

Number of solver iterations

Simulation time step size

Model size and fidelity

Follow these high-level tasks to prepare a model for real-time simulation. Each task is also a link to specific instructions for that part of the procedure.

Simulate with Fixed-Cost Solver and Compare to Variable-Step Simulation

Adjust Step Size and Iterations to Approximate Variable-Step Simulation Results

The first task is to obtain a converged set of results with a variable-step solver.

To ensure that the results obtained with the fixed-step solver are accurate, you need a set of reference results. You can obtain these by simulating the system with a variable-step solver. Ensure that the results converge by tightening the error tolerances until the simulation results do not change significantly.

The second task is to examine the time step sizes during the desktop simulation and determine if the model is likely to run with a large enough step size to permit real-time simulation.

A variable-step solver varies the step size to keep the solution
within error tolerances and to react to zero
crossing events. If the solver abruptly reduces the step
size to a small value (for example, `1e-15 s`

), the
solver is trying to accurately identify a zero crossing event. A
fixed-step solver might have trouble capturing these events at a step
size large enough to permit real-time simulation.

Analysis of these particular variable time steps provides an estimate of a step size that can be used to run the simulation. Modifying or eliminating the effects are causing these events makes it easier to simulate the system with a fixed-step solver at a reasonably large step size and produce results comparable to the variable-step simulation. See Troubleshooting Real-Time Simulation Problems.

The third task is to simulate the system with a fixed-step, fixed-cost solver and compare these results to the reference results from the variable-step simulation.

**Limiting Per-Step Solver Iterations. **Simulating physical systems often requires multiple iterations
per time step to converge on a solution. To perform a fixed-cost simulation,
you must limit these iterations. In each physical network Solver Configuration block, select the **Use
fixed-cost runtime consistency iterations** check box
and enter the number of allowed iterations.

**Switching to Local Solvers. **You can further minimize the computations done per time step
by choosing a local solver on each physical network in the model.
To switch to a local solver in a physical network, open the Solver
Configuration block of that network and select **Use local
solver**. By using this option, you can use an implicit
fixed-step solver only on the stiff portions of the model and an explicit
fixed-step solver on the remainder of the model. This minimizes the
computations done per time step, making it more likely that the model
can run in real time.

The fourth task is to reduce the step size and adjust the number of nonlinear iterations, in order to produce results that are sufficiently close to the reference results from variable-step simulation. The step size must still be large enough for a safety margin to prevent an execution overrun.

During each time step, the real-time simulation must calculate the result for the next time step (simulation execution), and read inputs and write outputs (I/O processing and other tasks). If these actions take less time than the specified time step, the processor remains idle during the remainder of the step. Choosing a computationally more intensive solver, increasing the number of nonlinear iterations, or reducing the step size both increases the simulation accuracy and reduces the amount of idle time, raising the risk that the simulation cannot run in real time. Adjusting these settings in the opposite way increases the amount of idle time but reduce accuracy.

Estimating the budget for the execution time helps ensure that you choose a feasible combination of settings. If you know the amount of time spent processing inputs and outputs and performing other actions, as well as the percentage of idle time that you want, the amount of time available for simulation execution can be calculated as follows:

Simulation Execution Time Budget =

Step Size – [I/O Processing Time + (Desired Percentage of Idle Time)·(Step Size)]

**Estimating Real-Time Execution Time. **You can use the desktop simulation speed to estimate the execution
time on a real-time hardware target. Many factors affect the real-time
target execution time, so that comparing processor speeds might not
be sufficient.

A better method is to measure the execution time of desktop simulation and then to determine the average execution time per time step on the real-time target for a particular model. Knowing how these execution times compare for one model means that you can estimate execution time on the real-time target from the desktop simulation execution time when you test other models.

The fifth task is to use the selected solver, the number of nonlinear iterations, and the step size to simulate on the real-time target and to verify if the simulation can run in real time.

If the simulation does not run in real time on the target hardware, the model might not be real-time capable.

If the simulation does not run in real time on the selected real-time target, perform a sixth, contingent task, described in Troubleshooting Real-Time Simulation Problems.

If the simulation does not run in real time on the real-time platform, or if the simulation performance is unacceptable, you should determine the causes and find an appropriate solution. The combination of effects captured in the model and the speed of the real-time platform might make it impossible to find solver settings that permit it to run in real time. Consider the following options to make it real-time capable.

Once you modify your model, return to the third, fourth, and fifth tasks of Preparing a Model for Real-Time Simulation to identify and implement the appropriate settings to enable real-time simulation.

You can speed up the real-time simulation by using a faster real-time target computer.

Alternatively, you can achieve the same goal by determining new model settings that permit a larger step size or reduce the execution time (for example, by reducing the number of nonlinear iterations).

If possible, configure the model to evaluate multiple physical networks in parallel. You can do this if the networks are not dependent upon one another. You need experience and experimentation with your model, the generated code, and the real-time target to make effective use of this option.

Certain effects in your model can prevent real-time simulation. Such effects include instantaneous events and rapid changes in parts of the system with very small time constants. Identify and modify or remove these elements before searching again for a combination of solver settings and step size that permits real-time simulation.

**Identifying Elements Causing Rapid or Instantaneous Changes. **Watch for certain system elements becoming excited to high frequencies.
Examine the system eigenmodes to isolate which system states have
the highest frequency. Mapping those states to individual components
often points to the source of the problem. Because you can only do
this at a particular operating point, choose an operating point corresponding
to simulation times in the variable-step simulation that had small
step sizes. At such simulation times, the variable-step solver is
struggling to simulate a rapid change.

With scripts written in MATLAB^{®}, you can interrogate the
model, identify these components quickly, and narrow the search for
the effects that you need to modify. You can automate and extend these
searches to other models with tools like the Simulink Model
Advisor. The troublesome components that you need to locate
include:

Elements that create events and change the solution nearly instantaneously. A fixed-step solver might not be able to step over such rapid changes and find the right solution on the other side of the event. If it fails to find the solution, the solver may become unstable. Examples of elements that create these kinds of events include:

Hard stops or backlash

Stick-slip friction

Switches or clutches

Elements with very small time constants. The dynamics of these elements require a small step size so that a fixed-step solver can accurately simulate them, perhaps too small for real-time simulation. Examples of systems with a small time constant include:

Small masses attached to stiff springs with minimal damping

Electrical circuits with small capacitance and inductance and low resistance

Hydraulic circuits with small compressible volumes

**Modifying or Removing Elements Causing Rapid or Instantaneous
Changes. **Once you have identified these elements, change or eliminate
them by:

Replacing nonlinear components with linearized versions

Replacing complex equations with lookup tables for their solution

Replacing complicated components with simplified models by using system identification theory on their input and output data

Smoothing discontinuous functions (step changes) by using filters, delays, and other techniques.

Was this topic helpful?