Real-time system

When Real-Time Systems ( english real-time systems ) are "systems for immediate designated control and management of processes" that it asked them quantitative real-time requirements must be fulfilled. These are used in various fields of technology, for example in process control technology , in motor controls , in satellite system technology, in signaling and switch control systems , in robotics and in other areas.

Often the requirement is that a result is guaranteed to be calculated within a predefined time interval, i.e. that it is available before a certain time limit. The size of the time interval is irrelevant: While for some tasks (e.g. in engine control) a second can be too long, hours or even days are enough for other problems. A real-time system must therefore not only deliver a measurement or calculation result with the correct value, but also deliver the same in good time . Otherwise the system has failed.

In practice, an arbitrarily small time limit cannot always be implemented due to a lack of sufficiently fast hardware. This is why one speaks of "in real time " when programs work without a noticeable delay. However, this definition is very imprecise. It is fundamentally wrong to see “real-time system” as a synonym for “particularly fast”. On the contrary, real-time systems have to plan appropriate idle times in order to meet their real-time requirements even in particularly demanding situations.

Hard, soft and firm real time

definition

Depending on the consequences, a distinction is sometimes made between hard real-time , soft real-time and firm real-time . Different real-time requirements apply for this.

hard real-time requirements: Exceeding the response time is considered a failure. After an exact time recording of the application to be provided, calculations according to the theory of real-time systems are necessary. Real-time systems always deliver the correct result within the specified time limits. You can rely on this property when using a hard real-time system.

Soft real-time requirements: Such systems typically process all incoming inputs quickly enough . The response time reaches, for example, an acceptable mean value or another statistical criterion. The time requirements are to be seen here as guidelines. Exceeding the time requirement does not have to be rated as a failure. On the one hand, the time can often be exceeded as long as it is still within a tolerance range. On the other hand, it can rarely be exceeded significantly.

Fixed real-time requirements: With fixed real-time requirements, there is no risk of immediate damage. However, after the time requirements have expired, the result of the calculation is useless and can be discarded.

Depending on the problem and perspective, the following definition is also used:

Soft real-time requirements: The system must react in the specified time span, but not deliver the full result. If there is no response, the process is considered to have failed and is canceled. Alternatively, soft real-time systems can sometimes deliver the result correctly, but too late.
Hard real-time requirements: The system must present the result in full in the defined time window.

Within the soft real-time systems, there are sometimes further classifications that differentiate more finely the exceeding of the response times. Common criteria are:

The result no longer has any value; the calculation is canceled and discarded.
The usefulness of the result decreases from the end of the response time.
Exceeding the response time is accepted and the result is accepted if it is available.

Even the definition of soft real-time systems is of a rather colloquial nature, so that a finer subdivision is even more difficult to give.

The DIN standard 44300 defines under real-time operation (called real-time operation there) the operation of a computer system in which programs for processing accumulating data are always ready for operation, in such a way that the processing results are available within a specified period of time. This standard of terms has not been able to establish itself in practice as the only accepted definition; the terms from the English-speaking world dominate.

Examples

Systems for video conferencing have to record, preprocess, send and display picture and sound within milliseconds. If this does not work for some images, the display will "jerk" a bit, but you can continue working without any negative consequences. The system only has to meet soft real-time requirements.
A program that is to record (longer) video sequences, on the other hand, has to meet tough real-time requirements. If it is not possible to save the video data to the data carrier quickly enough, pictures will be lost and the video will be unusable for many applications.
The electronic engine control in a car must meet tough real-time requirements, otherwise the engine will stutter or the car will stall. The failure or a hard real time that is not maintained correctly can cause mechanical damage or, in the worst case, an accident.

implementation

Real time describes the temporal input and output behavior of a system, but says nothing about its implementation. A real-time system can be a computer with suitable software or a pure hardware solution. Standard EDP systems are often used for requirements with so-called soft limits . Special architectures (hardware and software) are used for requirements with hard limits, e.g. B. Microcontroller , FPGA or DSP -based solutions.

Fixed periodic triggering

One approach to meet the required response time for specific applications is to use a separate functional unit that only fulfills this task with a fixed frequency , derived from the response time. One example of a hardware implementation is digitization with an ADC as a functional unit and a clock crystal , e.g. B. to digitize sounds for an audio CD with a required frequency of 44.1 kHz (corresponds to a response time ≤ 22.7 microseconds). Such a solution reliably fulfills the hard real-time criterion, since it was specifically designed to fulfill a single task. However, a complex real-time task broken down according to this principle (such as a control with many input parameters with high dynamics in the required response times) can become expensive and complex due to the asynchrony and redundant system parts to be solved . ${\ displaystyle f = {\ frac {1} {\ text {Response time}}}}$

Synchronous approaches

A generalized approach for several tasks is the use of a single, equally clocked (synchronous) solution platform, typically implemented with microcontrollers , DSPs , CPUs or FPGAs . The reaction times required for the real-time condition are attempted in this solution concept by processing all tasks sequentially as quickly as possible. The real-time condition is definitely met if the smallest required reaction time among the tasks is twice as large as the maximum runtime for a total run of all tasks.

An example would be a real-time control with a microcontroller that receives several input parameters, calculates a reaction and returns it. Assume that a response to exceeding a temperature with a reaction time of ≤ 1 s and a speed of less than ≤ 1 ms is to set a switch-off signal. A technically simple solution on a microprocessor with a 2 MHz clock frequency would be a simple endless program loop (example in Intel syntax pseudoassembler code , semicolon is comment character): ${\ displaystyle t}$ ${\ displaystyle d}$ ${\ displaystyle O = 1}$

  mov a, 10000 ; Grenzwert der Drehzahl
  mov b, 30    ; Grenzwert der Temperatur
  mov O,1      ; Abschaltsignal

:loop          ; Markierung im Programmfluss (keine Instruktion, wird vom Assembler für Sprungadressen verwendet)
  in d,PORT1   ; einlesen der aktuellen drehzahl-Werte
  in t,PORT2   ; einlesen der aktuellen temp-Werte

:drehcheck
  cmp d,a      ; prüfe die Drehzahl
  jg  tempcheck; wenn Grenzwert nicht erreicht, springe zu :tempcheck
  out PORT3,O  ; Grenzwert erreicht! setze Abschaltsignal

:tempcheck
  cmp t,b      ; prüfe die Temperatur
  jg  loop     ; wenn Grenzwert nicht erreicht, springe zu :loop
  out PORT3,O  ; Grenzwert erreicht! setze Abschaltsignal

  jmp loop     ;unbedingter Sprung zur Marke :loop (Endlosschleife)

Assuming that each instruction on this processor (each line of code) costs one clock cycle in time, a test run is carried out in 6 clock cycles, with a worst-case reaction time of 12 clock cycles for the temperature ( ) and 11 for the speed ( ) . The tough real-time requirements are met with this control, but orders of magnitude faster than would actually be necessary ( inefficient ). An extension of the real-time control z. B. to test a print is possible through this oversizing of the system. However, the response time achieved for each of the subtasks grows with the total expiry time . The limit of this design has been reached when, in the worst-case scenario, twice the total expiry time exceeds the response time for a partial task. ${\ displaystyle t _ {\ text {loop}}}$ ${\ displaystyle {\ frac {12} {2000000}} = 0 {,} 006 \, {\ text {ms}}}$ ${\ displaystyle {\ frac {11} {2000000}} = 0 {,} 0055 \, {\ text {ms}}}$ ${\ displaystyle p}$ ${\ displaystyle t_ {loop}}$ ${\ displaystyle t_ {loop}}$

This concept is the common paradigm on the computer in multimedia applications such as video , demos, and games . Typically, only the soft real-time condition criterion is met, since a worst-case processing time / response time cannot be determined (or, as in the example above, cannot be counted) and / or is not deterministic due to the complexity of the system . In multimedia applications, this nondeterminism is expressed e.g. B. about varying FPS or response times for inputs. Reasons for this nondeterminism are the existence of several code paths with different execution times, the waiting for execution for inputs or outputs or simply tasks with variable complexity (e.g. varying complexity of the scenery in computer games ).

Process-based approaches

In complex real-time systems (such as a PLC or a computer acting as a real-time system), various processes usually run simultaneously and with different priorities, controlled by a real- time operating system . The minimum response time is defined by the time required for a complete change from a process of lower priority to a process of higher priority. This change is initiated when a defined event occurs, e.g. B. generated by an external trigger ( interrupt in computer technology ) or internal timer. The actual processing of the called process only begins after the process change has been carried out. This enforces the hard real-time criterion of a higher-priority task by interrupting the execution of a lower-priority task ( preemptive multitasking ).

In principle, a PC is also real-time capable, but not, or only to a limited extent, if it is operated with classic multitasking operating systems, since many asynchronous processes then run non-deterministically. Real-time operating systems are often also capable of multitasking, but have a different scheduler than conventional systems. There are also solutions in which an existing standard operating system is made real-time capable by adding special software. This has the advantage that only the really time-critical processes have to run in the real-time system and the normal APIs (including compilers or GUIs ) of the underlying operating system can be used for the rest .

Real-time operating systems are also used in programmable logic controllers (PLC) and process control systems (PCS), but these are not directly accessible to the user.

In the case of software that is supposed to meet real-time conditions, the maximum runtime must be determinable and must not be subject to any factors that cannot be influenced or that can only be influenced to a limited extent, i.e. it must be deterministic . This will u. a. influenced by the following system or software properties:

One problem is complex I / O, e.g. B. Hard disks with cache and automatic sleep mode or network communication with non-deterministic timing (e.g. IP ).

The runtime of the operating system and library calls must also be taken into account.

The need for resources, especially the need for storage , must be known. The runtime environment and the hardware must be able to meet the resource requirements.

With recursion the maximum recursion depth, with loops the maximum number of iterations must be fixed.

Memory management: It must therefore be ensured that the real-time modules remain unaffected by the virtual memory management of the operating system and are never swapped out (this is why real-time systems typically do not use any virtual memory management at all).

The use of automatic garbage collector, for example, is particularly problematic , the runtime of which has to be estimated very pessimistically.

The behavior in the event of an impending timeout must be defined and predictable.

Examples of real-time systems

Computers for controlling technical equipment or processes such as machines, process engineering systems or means of transport are practically always real-time systems. A real-time system reacts to all events in good time and processes the data “keeping pace” with the technical process. It is, so to speak, not dependent on the technical process - neither in normal cases nor in critical situations.

The temperature of an apparatus in a process plant usually only changes within minutes. A controller that reacts to deviations within several seconds can therefore still be considered real-time capable. The reaction time is in the range of seconds.

Graphic applications on the computer such as games or demos require reaction times of ≤ 63 ms (≥ 14–16 images per second ) when updating the screen display in order to be perceived as a smooth process.

Computer programs whose response times to user input with input devices ( keyboard , mouse etc.) are less than 10 ms are subjectively perceived as being immediate (see usability ).

The airbag control in the car has to process the measured values of the sensors continuously and within a very short time and decide whether and how strongly the airbag is triggered; the response time is in the range of 1 ms.
An anti-lock braking system in a car typically has a control frequency of ≥100 Hz, i.e. H. the response time is less than 10 ms.
In machine tools , the mutual position of workpiece and tool changes. Today's CNC controls have a time resolution of the motion control of 125 µs.
In a car, the electronic engine management system has to deliver its results (amount of fuel to be injected, ignition point) at certain times. Results arriving later are worthless. The response time depends directly on the speed and goes down to 1 ms for typical engines at high speeds with many cylinders.
For the precise deflection of electron beams, e.g. B. in electron beam welding , magnetic fields with frequencies of 100 kHz to 1 MHz must be regulated. The response time is between 1 µs and 10 µs.

Design paradigms

There are two design paradigms for implementation: event-driven and time-driven .

With event control, an external event (usually by means of an interrupt ) is reacted to as quickly as possible, i.e. H. processing started. If necessary, processing that is currently running is interrupted. The event control has the advantage that it reacts to the event with very little loss of time. Because it is intuitive, it is also widely used. The main disadvantage is that it cannot be prevented that several events can occur within a short period of time, which can lead to an overload of the real-time system (with loss of events and / or exceeding of time limits). To avoid this problem, it is necessary to clearly define which events can occur with what maximum frequency. Typically, priorities are used to determine the order in which simultaneously occurring events are to be processed. In a hard real-time environment, it must be ensured that even in the worst case (maximum number and frequency of all possible events) even the process with the lowest priority can still deliver its result within the time limits, i.e. H. is still allocated enough computing time to complete its task.

In the time control, processings are started based on a predetermined schedule. A precisely defined time slice in the scheduler is assigned to each process (e.g. exactly 10 ms every 100 ms). The advantage is that overloads can generally be ruled out (provided that the process never exceeds the allotted time). The behavior of the application is predictable for all time, which makes the time control suitable for safety-critical applications. The disadvantage of time control is the higher planning effort (the time allocation must be precisely known during the implementation of the processes) and the associated use of tools. Another advantage is that with time control the available resources (CPU time, memory) can be used to 100 percent, while with event control this is not possible due to its asynchrony . With event control, a reserve must always be planned for the resources so that the system can "catch up" with time when the load is high.

literature

Dieter Zöbel: Real-time systems - basics of planning . Springer Vieweg, 2020, ISBN 978-3-662-60421-2 .
Sascha Roeck: Real-time simulation of production plants with real control systems . Jost-Jetter Verlag, 2007, ISBN 3-939890-24-3 .
Hermann Kopetz : Real Time Systems. Design Principles for Distributed Embedded Applications (= The Kluwer International Series in Engineering and Computer Science. Vol. 395). Kluwer Academic Publishers, Boston MA a. a. 1997, ISBN 0-7923-9894-7 .
H. Zedan (Ed.): Real-time Systems. Theory and Applications. Proceedings of the conference, organized by the British Computer Society, York, September 28-29, 1989. North-Holland et al. a., Amsterdam a. a. 1990, ISBN 0-444-88625-7 .

Web links

Comp.realtime: Frequently Asked Questions (FAQ) :
regularly on the newsgroup comp.realtime posted
- in HTML format
- via anonymous FTP
faqs.org
dedicated-systems.com
dedicated-systems.com
Linux Realtime FAQ

Individual evidence

↑ Computer science - a specialist lexicon for study and practice . Dudenverlag, Mannheim 2003, ISBN 3-411-10023-0 , p. 537
^ ^A ^b Heinz Wörn, Uwe Brinkschulte: Real-time systems. Basics, functions, applications . Springer, Berlin a. a. 2005, ISBN 3-540-20588-8 , pp. 321 , doi : 10.1007 / b139050 .
↑ Boris Burger, Ondrej Paulovic, Milos Hasan: Realtime Visualization Methods in the Demoscene ( en ) In: CESCG-2002 . Technical University of Vienna . March 21, 2002. Retrieved March 21, 2011.

[1] Computer science - a specialist lexicon for study and practice . Dudenverlag, Mannheim 2003, ISBN 3-411-10023-0 , p. 537

[Echtzeitsysteme-S321-2] A ^b Heinz Wörn, Uwe Brinkschulte: Real-time systems. Basics, functions, applications . Springer, Berlin a. a. 2005, ISBN 3-540-20588-8 , pp. 321 , doi : 10.1007 / b139050 .

[CESCG-2002-3] Boris Burger, Ondrej Paulovic, Milos Hasan: Realtime Visualization Methods in the Demoscene ( en ) In: CESCG-2002 . Technical University of Vienna . March 21, 2002. Retrieved March 21, 2011.