Complex systems rarely operate at a single natural timescale. A control loop may require frequent updates, while thermal behavior, navigation calculations, status monitoring, and supervisory logic can often run at slower rates.

A real-time simulation must coordinate these different rates without losing the timing relationships between subsystems. It must execute fast tasks often enough to represent their dynamics while preventing slower tasks from consuming processing capacity unnecessarily.

Multirate real-time simulation provides a structured way to schedule models and subsystems with different sample times within the same test environment. When implemented correctly, it improves computational efficiency while preserving predictable data flow and execution timing.

The objective is not automation for its own sake. It is to create tests that can be repeated, reviewed, and understood.

What Is Multirate Real-Time Simulation?

Multirate real-time simulation is the execution of models or model components at different scheduled frequencies within a shared simulation.

For example, a test could contain:

• A current-control model executing every 250 microseconds
• A mechanical model executing every millisecond
• A thermal model executing every 10 milliseconds
• Supervisory logic executing every 100 milliseconds

The fastest required interval is often treated as the fundamental or base simulation period. Slower rate groups execute at scheduled multiples of that period.

If the base period is 250 microseconds, a model with a one-millisecond period executes once every four base cycles. A model with a 10-millisecond period executes once every 40 base cycles.

These values are illustrative. The appropriate sample rate for each subsystem depends on its dynamics, numerical solver, interfaces, and test objectives.

Why Use More Than One Simulation Rate?

Running every subsystem at the fastest rate may appear simpler, but it can waste significant processing capacity.

A slowly changing thermal model, for example, may not produce more useful information by executing at the same rate as a fast electrical control loop. The additional calculations consume time that could otherwise support more detailed models, additional I/O, data recording, or processing headroom.

Multirate execution allows engineers to match computational effort to the behavior being represented.

Potential benefits include:

• Reducing unnecessary model calculations
• Supporting larger combined simulations
• Preserving capacity for high-frequency subsystems
• Integrating models created with different sample times
• Distributing workloads more effectively across processor cores
• Maintaining clearer relationships between subsystem requirements and execution rates

Multirate execution does not automatically make a simulation more accurate or efficient. The rate assignments and data exchanges must be designed intentionally.

Sample Time and Execution Time Are Different

Two measurements are important when discussing a real-time model:

• Sample time defines how frequently a model is expected to execute.
• Execution time measures how long the model takes to complete one calculation.

A model with a one-millisecond sample time does not have one millisecond available solely for its own calculations. That same simulation period may also include input processing, other scheduled models, output processing, synchronization, and platform overhead.

Figure . Sample time is the whole scheduled period, not just the model’s own calculation, average execution time can hide a worst-case overrun.

For real-time operation, all work assigned to the period must finish within the available timing budget.

This is why average model execution time is not sufficient. Engineers must consider maximum observed execution time, scheduling overhead, interference from other tasks, and the behavior of the complete test configuration.

As discussed in Why Deterministic Timing Matters in Real-Time Simulation, a model that usually finishes on time can still create invalid timing behavior if its worst-case execution exceeds the available period.

Consider a simplified simulation with a base period of one millisecond and three rate groups:

Rate group	Period	Execution frequency
Fast control model	1 ms	Every base cycle
Mechanical model	5 ms	Every fifth cycle
Supervisory model	20 ms	Every twentieth cycle

During most base cycles, only the fast control model executes. Every fifth cycle, the mechanical model also runs. Every twentieth cycle, all three rate groups are scheduled.

A multirate schedule in practice, most cycles are light, but the busiest combination of rate groups is what has to fit the base period.

That twentieth cycle may require considerably more processing than the cycles between it. The simulation must have enough capacity to handle this combined workload without exceeding the one-millisecond base period.

This creates an important design consideration: multirate loading is not uniform.

A system may appear lightly loaded during typical cycles while approaching its limit whenever several rate groups coincide. Performance testing must therefore include the most computationally demanding schedule combinations not just average utilization.

Coordinating Data Between Rate Groups

Models operating at different rates still need to exchange data. The timing of those exchanges must be defined clearly.

Suppose a fast control model produces a value every millisecond, while a slower supervisory model reads that value every 20 milliseconds. The supervisory model needs to know which value it receives and when it becomes available.

In the opposite direction, the fast model may use a supervisory command that updates only once every 20 milliseconds. Between updates, the previous command will typically remain in effect unless another transition behavior has been designed.

Important questions include:

• Does the receiving model use the newest completed value?
• Is the value held constant between slower updates?
• Is interpolation required?
• When during the frame does the data become visible?
• What happens when a producing model is late?
• Does a rate transition introduce an intentional one-cycle delay?
• How are initial values established before every rate group has executed?

These choices affect both numerical behavior and test repeatability. Rate transitions should be treated as part of the model architecture rather than left as an accidental result of thread timing.

Execution Order Matters

Rate alone does not determine the behavior of a multirate simulation. The order in which related models execute can also affect the results.

Consider two models scheduled during the same simulation cycle:

1. Model A calculates a value.
2. Model B consumes that value.

If Model B executes before Model A, it may receive the value from the previous cycle. That may be correct if the design includes an intentional delay. If the design assumes same-cycle data transfer, the order is incorrect.

A real-time scheduler must therefore coordinate more than frequency. Depending on the architecture, it may also need to manage:

• Dependencies between models
• Input and output phases
• Same-rate execution order
• Data availability across rate groups
• Synchronization between processor cores
• Start-of-frame and end-of-frame operations

These relationships become increasingly important when models originate from different engineering teams or modeling environments.

Multirate Is Not the Same as Multicore

Multirate and multicore simulation address related but different problems.

Multirate simulation determines when and how frequently tasks execute. Multicore simulation determines where those tasks execute.

Multirate and multicore answer different questions when a task runs versus where it runs and complex systems typically need both.

A multirate simulation can run on a single processor core if every scheduled workload fits within its deadline. A single-rate simulation can use multiple cores if the workload can be divided appropriately.

Complex systems often use both techniques:

• Rate groups prevent slow subsystems from executing unnecessarily.
• Multiple processor cores provide additional computing capacity.
• CPU assignment limits contention between important tasks.
• Processor isolation reduces interference from unrelated system activity.

Moving a model to another core does not remove its data dependencies. Models running in parallel may still require synchronization before their outputs can be used. Poorly planned core assignments can add coordination overhead without producing a meaningful performance improvement.

A later article in this series will examine how to scale real-time simulation workloads across multiple CPU cores.

Integrating Models with Existing Sample Rates

Simulation environments frequently combine models produced by different groups or generated from different tools. Those models may already contain defined sample rates.

Changing the rate to simplify integration can affect model behavior. A controller designed and tested at a specific interval may not produce equivalent results if its step size is changed without further analysis.

Before integrating a model into a multirate environment, engineers should identify:

• The model’s fundamental sample time
• Additional discrete rates within the model
• Solver and fixed-step requirements
• Assumptions about data arrival
• Dependencies on other models
• Maximum execution time for each rate group
• Initialization and reset behavior
• Whether generated code separates rate groups into different threads

This information should be part of the interface definition between the model developer and the test-system engineer.

Detecting Timing Problems in Multirate Tests

Multirate timing problems can be difficult to diagnose because they may occur only when particular tasks align.

An overrun might appear every twentieth or hundredth cycle rather than continuously. It may also occur only when a specific test condition activates additional logic.

Useful diagnostic information includes:

• Execution time by model or thread
• Processor utilization by core
• The rate groups active during an overrun
• Start and completion times for scheduled tasks
• Missed or delayed model activations
• I/O processing time
• Data-logging activity
• Interrupts or background activity occurring on simulation cores

Engineers should examine timing over a sufficiently long test period to capture infrequent combinations of scheduled tasks. Tests should also include demanding operating conditions rather than only steady-state model behavior.

Multirate Simulation in SIMulation Workbench

SIMulation Workbench supports simulations containing multiple models and multiple execution rates.

For Simulink-based workflows, SimWB’s MLToolkit can generate real-time model code while preserving discrete sample rates from the source model. The resulting rate groups can be represented as separate model threads scheduled as part of the SimWB test.

SimWB also allows engineers to assign model threads and other simulation processes to processor cores. This makes it possible to coordinate execution rate with processor allocation rather than treating the simulation as a single sequential workload.

Data exchanged among models, I/O processes, and other simulation components is maintained through SimWB’s memory-resident real-time database. This shared data layer helps integrate separately scheduled processes without embedding physical I/O configuration directly into each model. Concurrent’s hybrid electric vehicle demonstration provides an example of a Simulink model containing multiple discrete sample rates. Each rate becomes a corresponding thread in the SimWB test configuration, where its execution and processor assignment can be managed.

Questions to Ask When Configuring a Multirate Simulation

Before deploying a multirate test, engineering teams should ask:

• What is the fastest required sample time?
• Why does each subsystem need its assigned rate?
• Are the slower rates compatible with the base period?
• When do models exchange data across rate boundaries?
• Are any delays intentional or simply caused by execution order?
• Which rate combinations create the highest processing load?
• What is the maximum execution time of each task?
• How much timing headroom remains during the busiest cycle?
• Should particular rate groups execute on separate processor cores?
• How are overruns detected and recorded?
• Does the test remain deterministic with logging and visualization enabled?

Answering these questions before full HIL integration can prevent timing problems from being mistaken for controller, model, or hardware defects.

Conclusion

Multirate real-time simulation allows engineers to represent subsystems at appropriate timescales without forcing every calculation to execute at the fastest rate.

The approach can improve computational efficiency and support larger simulations, but it also introduces scheduling, data-transfer, and workload-management requirements. Sample rates must be compatible, execution order must be understood, and the busiest combination of scheduled tasks must still complete within the base simulation period.

The goal is not simply to run different models at different speeds. It is to preserve the intended timing relationships among those models, their data, and the hardware interacting with the simulation.

For a broader look at multirate scheduling, model and I/O separation, multicore scaling, and test automation, download Designing Scalable, Deterministic X-in-the-Loop Simulation Environments.

Frequently Asked Questions