D-Six Timing
The topic of timing and simulation can be a confusing and controversial subject. The following discussion is provided to explain the timing of the D-Six simulation loop and present evidence that it meets the timing needs of the simulation and hardware in the loop tasks for which it is applied. For the purpose of this discussion, a distinction is made between the terms "true time", "real-time" and "real-time system". "True time" refers to a reference time used to track simulation timing. The use of the term "real time" in the context of this discussion refers to timing of sufficient accuracy to solve the problem at hand. For the closed loop hardware in the loop application efforts, 10-millisecond accuracy with true time was required. The term "real-time system" refers to a common definition found in Referencei , provided below.
"A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred."
Based on these definitions, with the exception of Windows CE, the systems running any of the Windows family of operating systems cannot be considered "real-time systems." However, this does not imply that software running under Windows operating systems cannot meet "real time" for a particular task.
With this in mind, since Windows is not a real-time system, there are no guarantees that a simulation time frame can be executed within a fixed period of time. While there are no guarantees Windows will not preempt an application process and unnecessarily delay it's time frame execution, there is nothing inherent in the operating system that would cause this to happen. Timing errors are caused solely by software installed on the system. Therefore, it is possible to determine the total timing error for each time step using the Windows performance counter and use the information to detect errors greater than maximum values for a predefined task, thus providing a degree of determinism.
Figure 1. Simulation loop state diagram.
 |
In cases where these maximums are not met, it is generally possible to identify and correct the source of the error.
The D-Six simulation loop uses an error correction model to maintain relative real-time operation as shown in the simplified state diagram (Figure 1).
During the begin state, the initial true time is determined, and the simulation time is set to zero prior to calling the initialization routines for the simulation model. The wait state normally performs background operations as well as effective delay prediction to reduce system load, but for simplicity these operations are left out of the above state diagram. The simulation holds in a wait state until it is time to execute simulation frame. The execution state increments the current simulation time by a single frame length, then executes a single simulation step, upon completion it returns to the wait state.
In this loop, the Windows performance counter determines timer resolution and is dependent on the processor and clock speed. For example, an Intel Pentium III-500MHz system has a performance counter frequency (PCF) of approximately 3MHz, where an Intel Pentium II 233MHz system has a PCF of approximately 1.2MHz.
The simulation frame execution time error can be computed at the start of the execution state using equation (1).
 |
(1) |
This value is a measure of the difference between a scheduled time for a simulation frame execution and the actual time it is executed.
A series of tests were performed to evaluate D-Six timing. A D-Six simulation was run under Windows 2000 in conjunction with a CPU stress tool included with the Windows Platform Software Development Kit (SDK). The test configuration is provided in Table I.
Table I. Timing test parameters.
| Computer |
Intel Pentium II 500 MHz |
| Operating System |
Windows 2000 Professional |
| D-Six Configuration |
- Six-Degree of Freedom Flight model. Including multiple nonlinear 1,2, and 3-D table look ups.
- 600 x 600 Pixel DirectX Graphics Window
- A Single DirectX driven "real-time" strip chart.
- A Single Microsoft Side Winder USB game stick.
|
| Simulation Frame |
80 Hz |
| Simulation Duration |
10 Seconds |
The accuracy of these tests is based on the assumption that the processor clock is accurate. This assumption is valid based on publicly available data (Reference ii).
Table II. Timing test results.
Load |
[ms] |
Low:
D-Six + no other apps |
2.78 |
Medium:
D-Six + 1 Normal Priority Thread |
19.71 |
High:
D-Six + 3 Normal Priority Threads |
252.06 |
High:
D-Six + 4 Threads Above Normal Priority |
617.34 |
Simulations were executed at four different levels of system load defined by the Window System load tool, low, medium, high, and critical. Table II contains a summary of test loads and maximum errors attained.
The test results show that under low system load, the D-Six environment is capable of reasonable frame scheduling within 3 ms of true time and meets timing requirements specified for this effort. Depending on task requirements, the environment may achieve sufficient timing under medium system loading, but would not be recommended for use real time requirements under high or critical loads.
back to FAQs
