The accuracy of a real-time simulation depends on more than the mathematical model being executed. The model must also run at the correct intervals, process inputs at the expected time, and produce outputs before the next simulation cycle begins.

A model that produces accurate results when run offline may behave differently when placed in a real-time test environment. If its calculations occasionally finish late, its outputs may no longer represent the intended point in simulated time. That timing variation can affect the behavior of a controller, hardware component, or operator interacting with the simulation.

This is why deterministic timing is a foundational requirement for many hardware-in-the-loop and X-in-the-loop simulation environments. The objective is not simply to execute a model quickly. It is to execute every required operation within a defined and repeatable timing window.

What Does Deterministic Timing Mean?

In a real-time simulation, deterministic timing means that critical tasks complete within their assigned deadlines with a known and controlled level of variation.

This should not be confused with a deterministic mathematical model. A deterministic model produces the same output when given the same inputs and initial conditions. Deterministic real-time execution concerns when those calculations and data exchanges occur.

A simulation can therefore use a deterministic model while still experiencing nondeterministic execution timing.

Consider a model configured to execute once every millisecond. Each simulation frame may need to:

1. Acquire input values from connected hardware.
2. Update the simulation’s data values.
3. Execute one or more model calculations.
4. Write the resulting outputs to the hardware.
5. Record selected data for later analysis.

Figure 1. One simulation frame, five required steps, all must finish before the next fixed-period frame begins.

All required synchronous work must finish before the next one-millisecond frame begins. Completing most frames on time is not enough when an occasional late frame can change how the device under test experiences the simulated system.

Fast Execution Is Not the Same as Deterministic Execution

Average execution speed can be misleading when evaluating a real-time simulation system.

Suppose a model normally completes in 400 microseconds but occasionally takes 1.2 milliseconds. Its average execution time may still appear acceptable. However, if the simulation period is one millisecond, the longer execution creates a deadline overrun.

For offline simulation, a slow calculation generally means waiting longer for the result. For real-time simulation, time cannot simply pause while the model catches up. The physical controller, sensor interface, data bus, or operator continues to operate according to real-world time.

A useful performance assessment must therefore examine more than average execution time. Engineers should also consider:

• Maximum observed execution time
• Variation between individual execution cycles
• Available processing headroom
• Frequency and duration of overruns
• Interference from operating-system activity
• Effects of logging, visualization, and network traffic
• Execution behavior under worst-case test conditions

This distinction is especially important as simulation models become larger or as multiple models and I/O processes share the same system.

How Timing Errors Affect Simulation Results

A timing error does not necessarily cause the simulation to stop. In some cases, the test continues while producing results that no longer reflect the intended timing relationships.

Several types of problems can result.

Stale input data

If input processing is delayed, a model may calculate its next state using values from an earlier cycle. The data may be numerically valid but temporally incorrect.

Delayed outputs

A controller may receive the expected output later than it would in the real system. For closed-loop control, this changes the apparent response of the simulated plant.

Phase errors between subsystems

When models execute at different rates, inconsistent scheduling can shift the timing relationship between them. A slower subsystem may consume data from a different cycle than expected.

Distorted fault-injection tests

Faults often need to be introduced at a precise point in a test sequence. Timing variability can change when the device under test detects or responds to the simulated condition.

Reduced repeatability

If operating-system activity, I/O processing, or background workloads affect each run differently, engineers may find it difficult to reproduce a failure. This makes the source of the problem harder to isolate.

These effects can be subtle. The resulting data may look plausible even when the timing relationship between inputs, model calculations, and outputs has changed.

Latency, Jitter, and Overruns

Three timing concepts are particularly important in deterministic real-time simulation.

Latency

Latency is the elapsed time between an event and the corresponding response. In a HIL environment, this could include the time between receiving a hardware input and producing the calculated output.

Some latency is unavoidable. The engineering question is whether it is bounded, understood, and appropriate for the system being simulated.

Jitter

Jitter is the variation in timing from one execution cycle to another. Even when every cycle technically meets its deadline, large variation can make system behavior less predictable.

A low average latency does not compensate for excessive jitter when the test depends on consistent signal timing.

Overruns

An overrun occurs when the required work does not finish within the available simulation period. Possible causes include:

• A model requiring more computation than expected
• Multiple tasks competing for the same processor
• An I/O operation blocking execution
• Interrupt activity on a simulation processor
• Data logging or visualization consuming excessive resources
• A test condition activating a more computationally demanding model path

An overrun should be detectable and recorded. Without adequate monitoring, engineers may analyze the resulting signal values without knowing that the intended schedule was missed.

Figure 2. Latency, jitter, and overrun are related but distinct timing failures, each affects a test differently.

Coordinating Models and I/O

Most real-time simulations do more than execute a single model. They may include several models, physical I/O devices, communication buses, test scripts, logging processes, and visualization tools.

These components do not necessarily have the same timing requirements.

Analog or digital I/O used in a closed-loop control test may need to operate synchronously with the model. Other interfaces, such as certain serial or network-based devices, may generate data according to their own schedules and therefore require asynchronous handling.

Placing every operation directly inside the time-critical simulation loop can make the loop unnecessarily difficult to complete. Allowing asynchronous activity to interrupt critical work without control can create a different set of timing problems.

A scalable architecture needs to distinguish between:

• Work that must occur at a specific point in every simulation cycle
• Work that must execute periodically but at a different rate
• Work that can operate asynchronously outside the critical loop
• Work that should be assigned to separate processor cores
• Work that can be deferred until the test has finished

This separation helps protect the simulation loop while still allowing the test system to communicate with a wide range of devices and supporting applications.

Multirate Models Add Another Timing Dimension

Complex simulations frequently contain subsystems that naturally operate at different rates. A fast control loop may need to execute more often than a thermal, navigation, or supervisory model.

Forcing every subsystem to run at the fastest required rate can waste processing capacity. Running slower subsystems without a coordinated schedule, however, can introduce unintended data dependencies.

A multirate real-time simulation must define:

• The base simulation period
• The execution rate of each model or subsystem
• When data passes between rates
• Which values are retained between updates
• How workload is distributed across processor cores
• What happens if one task misses its deadline

The scheduler must maintain these relationships throughout the test. This is one reason real-time simulation requires more than simply compiling a model and running it on a fast computer.

Why Processor Isolation Matters

Modern multicore processors provide substantial computing capacity, but their cores also handle operating-system services, interrupts, network traffic, and background applications.

If a time-critical model shares processing resources with unrelated activity, its execution time may vary even when the model itself has not changed.

Real-time systems address this problem through techniques such as:

• Assigning simulation workloads to specific processor cores
• Shielding selected cores from noncritical operating-system activity
• Routing interrupts away from critical cores
• Separating models, I/O tasks, and support processes
• Monitoring execution time and processor utilization

Figure 3. Isolating the critical core keeps unrelated operating-system activity from perturbing simulation timing.

These measures do not make an oversized model meet an impossible deadline. They create a more controlled execution environment in which engineers can measure workload behavior and allocate resources intentionally.

Logging and Visualization Must Not Disrupt the Test

Engineers need visibility into a running simulation, but measurement can affect the system being measured.

Recording too many signals, transferring large volumes of data, or refreshing a visualization interface too frequently can consume processor, memory, storage, or network resources. If these activities compete with the simulation loop, they can introduce timing variation.

A well-designed platform separates time-critical execution from supporting activities wherever possible. Engineers should still test the complete configuration—including logging, scripting, visualization, and connected hardware—rather than benchmarking only the model in isolation.

The relevant question is not whether the model meets its deadline under ideal conditions. It is whether the complete test configuration meets its timing requirements under the conditions in which it will actually be used.

Evaluating Timing Behavior in a Real-Time Simulation Platform

When evaluating a platform, engineering teams should ask:

• How are models, I/O tasks, and scripts scheduled?
• Can workloads be assigned to specific processor cores?
• Can critical cores be isolated from unrelated activity?
• How does the platform handle multirate models?
• How are synchronous and asynchronous I/O separated?
• How are execution-time variations measured?
• What information is recorded when an overrun occurs?
• Can logging and visualization operate without blocking the simulation loop?
• How much processing headroom remains in the full test configuration?
• Can the same test be repeated with consistent timing behavior?

These questions reveal more than a general processor-speed specification. They show how the system behaves when multiple parts of a realistic test environment operate together.

Deterministic Execution in SIMulation Workbench

SIMulation Workbench provides a framework for coordinating models, I/O processes, scripts, and data recording within a real-time simulation environment.

Its scheduler initiates and monitors processes in the simulation loop, while a memory-resident real-time database provides a shared data layer between models and I/O. Models and I/O tasks can remain separate processes, allowing their execution and processor assignments to be managed according to the test configuration.

SimWB runs on Concurrent Real-Time’s RedHawk Linux platform for deterministic real-time execution. A Windows-based environment is also available for model preparation and functional development before deployment to the real-time Linux target.

The important architectural principle is broader than any individual product: trustworthy real-time testing requires control over both the calculations being performed and the timing with which the complete test system performs them.

Conclusion

A high-fidelity model is necessary for many simulation applications, but model fidelity alone does not guarantee a valid real-time test.

The simulation must acquire inputs, execute models, produce outputs, and coordinate connected processes within defined timing boundaries. Engineers must understand not only average performance but also jitter, maximum execution time, overruns, processor interference, and the behavior of the complete test configuration.

Treating timing as part of simulation correctness produces test results that are easier to reproduce, analyze, and trust.

To explore the larger architecture, including scheduling, model and I/O separation, multicore scaling, model integration, and test automation download Designing Scalable, Deterministic X-in-the-Loop Simulation Environments.

Frequently Asked Questions