| Frame jitter is a measure
of real-time determinism. Real-time simulations with high, real-time determinism
result in stable, predictable, and repeatable real-time simulation.
Real-time simulations use the concept of a “frame.”
The frame is a series of activities that must occur within a specific period of
time. The frame is repeated throughout the simulation run. The frame time corresponds
with the integration step used over a set time period.
Typical “frame times” range from 50 µs to 5 ms.
The table below shows a few examples of activities that occur during a frame.
Activities known as hard activities are those that require
completion within the allotted frame time. Soft activities may be completed over
many frames, require a lower priority, and do not compromise real-time determinism.
|
| Activity |
Hard or Soft |
Read hardware input signals
|
Hard |
Execute simulation model dynamics equations
|
Hard |
| Execute hardware interrupt triggered subsystems |
Hard |
Write hardware output signals
|
Hard |
Perform user perturbation “puts” on writable model
variables
|
Soft |
| Execute real-time scripting |
Hard |
| Return user inquired “gets” on readable model
variables |
Soft |
| Send data samples to the data acquisition system |
Hard |
| Calculate real-time performance statistics |
Hard |
| Synchronize with multi-rate models |
Hard |
| Synchronize with distributed simulation targets |
Hard |
If hard activities are not completed in the allotted frame
then the simulation is said to have a “frame overrun." If this occurs,
then you need to take a corrective action. Your options are to reduce the complexity
of the project, use fewer I/O signals, reduce the complexity of the dynamic models,
or, alternatively, increase the frame time.
Simulation jitter is a measure of the error between expected
frame time and measured frame time. For example, when a frame time is set to 1.00 ms
with a measured frame of 0.98 ms, the jitter is 0.02 ms. In a typical simulation,
the frame executes millions of times. Therefore, frame is normally quantified
using a statistical measure. Real-time jitter is caused by one of the following
real-time system components:
- Operating System
- Simulation Framework
Operating System
Operating systems such as Microsoft Windows, Solaris, and Linux are not designed
to operate in real-time. They typically exhibit very high real-time jitter --greater
than 1 ms. High performance real-time operating systems typically exhibit frame
jitter of less than 10 µs.
Of even greater importance than the magnitude of frame
jitter is accumulated frame jitter. It accumulates random error and greatly reduces
real-time determinism.
Both the RTS and the rtX targets feature real-time operating
systems that guarantee no error accumulation and maintain a minimal frame jitter.
Simulation Framework
The fundamental design of the real-time simulation framework
can greatly affect the magnitude of frame jitter and reduce error accumulation,
as described in the following examples
- Most real-time operating systems use layers of functionality
designed to ease real-time development. These layers add computational overhead
and can defeat the inherent determinism. ADvantage tools bypass these layers and
work directly with the real-time kernel whenever possible.
|
- Multi-rate, real-time simulations implement one or more integration step time.
Another benefit of the ADvantage is that the run-time framework handles the execution
of multiple models, including multi-rate models.
|
| For more on hard and soft real-time applications, see
What are Soft and
Hard Real-Time Applications? |
