This is a brief article in the sense of popular science to introduce one of my fields of interest.
Concerning Model Time and Real Time
In most cases the artificial time in a simulated model is in no way related to the real time outside the computer model. For example in a simulated population model years are simulated in seconds. In a comlex CFD simulation, however, it may take hours to simulate seconds. Thus we can define model time as the artificial time and its elapse in a computer model. "Real time" is the (real-life) duration in which a user is waiting for the model/simulation to deliver its results. A real-time simulation is a simulation in which model time and real time are expected to be. Due to the fact that computer simulations challenge our concept of time as a continuous process by including elements of discretization, model time and real time can only be equal at a set of given synchronized points. For example thinking of HIL (Hardware-In-The-Loop) simulation, real time and model time have to be equal every millisecond.
Soft Real Time Simulation
So in fact in a real-time simulator time itself is the critical resource. In this context it is not enough to achieve a high-performance. Beyond this one has to be in time. Let's take a flight simulator as example: A flight simulator is meant to represent the real world for a pilot trainee or maybe a gamer by creating behavioural patterns that might as well be observed in time-based real-world situations. Any action performed by a trainee in a flight simulator must lead to consequences identical to those made by pilots in real aircrafts. Realistic time spans are essential here. "In the same time" means. "between a lower and an upper bound of duration after the event". An event is in this context everything that occurred outside the simulated model and influence it. If it the simulator reacts too quickly this is as bad for the quality of the simulation as reacting too slowly.
If the trainee is merely "in-the-loop" with the simulator one may call this a soft real-time scenario because it is fairly acceptable to find the response occurring within a given time interval. Maybe it would be most suitable to ind the response to occur in the middle of the interval We can conclude that in a soft real time scenario model time needs to stay close to real-time situations but a hard synchronization is not required.
Hard Real Time Simulation: ECU tests using Hardware-In-The-Loop Realtime Simulators
One aspect that makes real time simulation so extremely interesting is its application in the development of electronic control units (ECU). Today there is a huge number of ECUs built in a modern car, and one method to test them during the development process of a new ECU software is a Hardware in the Loop (HIL) test . Such a test is performed by attaching one or more ECUs to a simulator. Here the simulator represents driver, car and environment In such a test not a human but a piece of hardware, the ECU, is in the loop. For this reason the requirements are in a way harder. In such a case one has to be sure that a response is given, e.g. after one millisecond, neither earlier nor later. This is called hard real- time requirement.
Nowadays both hard and soft real-time Hardware-in-the-Loop scenarios are used as standard tests in the development and testing of mechatronic control systems by the automotive industry.
Part of such a Hardware-in-the-Loop scenario is, of course, the simulator itself, containing a real time operation system (RTOS) and proper I/O-Hardware, e.g. to attach FlexRay, CAN or LIN bus systems. Obviously another important part is the real-time model itself and the way in which it is transferred into simulation code. Compared to a non-real-time simulation, this simulation code requires ifferent approaches concerning numerical algorithms or parallelization.
The level of the RTOS open solutions like RTLinux or even the standard Linux Kernel using the Realtime-Preempt-Patch (s. e.g. an Article in "Electronik Praxis" (German)) allow an easy access because of the open API and source code for teaching and research activities.