Real-time computing

As real-time systems (english real-time systems) " systems for the direct control and management of processes " are referred to, have to meet the demands placed upon it for quantitative real-time requirements. These come in various technology areas for the application, such as in process control, motor control circuits, in the satellite system technology, signal and switch open systems, robotics and other areas.

Often there is a requirement that a result is calculated guaranteed within a pre- defined time interval, that is present before a certain time limit. The size of the time interval is not important: While in some tasks (such as in the motor control ) is a second may be too long already, enough for other problems hours or even days. Thus, a real-time system must not only a measurement or calculation result with the correct value, but the same also deliver in time. Otherwise, the system has failed.

In practice, an arbitrarily small time bounds for lack of sufficiently fast hardware does not always represent. Therefore it is also called " real-time " when programs work without any noticeable delay. This definition is very dirty. Basically it wrong, "real time system " to be regarded as a synonym for " very fast " is. On the contrary, real-time systems need appropriate idle time schedule to be in particularly demanding situations their real-time requirements.

• 2.1 Fixed periodic triggering
• 2.2 Synchronous approaches
• 2.3 Process -Based Approaches

Hard and soft real-time

Definition

Depending on the consequences is sometimes between hard real-time (English hard real-time), soft real time (English soft real-time) and distinguished fixed real time. For this purpose, each have different real time requirements apply.

• Hard real -time requirements: Exceeding the response time is counted as a failure. After a precise time measurement of the application be provided computations are necessary according to the theory of real-time systems. Real-time systems deliver the correct result is always within the specified time limits. This property can be trusted when using a hard real -time system.

• Soft real-time requirements: Such systems typically operate all incoming inputs from fast enough. The response time achieved for example an acceptable average or other statistical criterion. The time requirements are to be seen here as guidelines. Exceeding the time requirement shall not be considered a failure. Firstly, the time can often be exceeded, as long as it is still within a tolerance range. Second, it can rarely be greatly exceeded.

• Firm real-time requirements: For hard real -time requirements threaten no direct harm. After expiry of the time requirements, however, the result of the calculation is useless and can be discarded.

Depending on the problem and point of view also the following definition is used:

• Soft real-time requirements: The system must respond in the specified time period, but do not provide the complete result. If there is no reaction, the process is considered failed and will be canceled. Alternatively, soft real-time systems can also occasionally provide the result is correct, but too late.
• Hard real -time requirements: The system must be fully present in the defined time window the result.

Within the soft real-time systems sometimes find other classifications that differentiate exceedances of the response times finer. Common criteria are:

• The result has no value; the calculation is canceled and discarded.
• The usefulness of the result decreases the end of the response time.
• An excess of the response time is acceptable and the result is assumed if it is present.

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

DIN 44300 standard defined in real-time mode (where real-time operation ) and has the operation of a computer system, wherein the programs for processing applicable data are constantly ready for operation, such that the processing results are available within a predetermined time period. This term standard has been in practice as a sole accepted definition can not prevail, however, as the criteria in the English-speaking world.

Examples

• Systems for video conferences must include picture and sound within milliseconds, preprocess, send and display. If this fails for some images, " jerky " the presentation a bit, but after that it can be continued without any negative consequences. Thus, the system must meet only soft real-time requirements.
• The electronic engine control in a car has to meet hard real-time, otherwise the engine stutters or the car stops. The failure or an incorrect -compliance with hard real-time can cause mechanical damage, or worse, an accident.

Implementation

Real time describes the time input and output behavior of a system, but says nothing about its realization. A real-time system may be a computer with appropriate software, but can also be a pure hardware solution. For requirements with so-called soft limits standard computer systems are often used. For requirements with hard limits specific architectures (hardware and software ) can be used, eg, microcontroller, FPGA or DSP -based solutions.

Fixed periodic triggering

One approach to perform a required response time for specific applications, is the use of a separate functional unit that meets only perform this task with a fixed frequency, obtained from the reaction time. An example of a hardware implementation is a digitization with an ADC as a functional unit and a quartz clock, such as the digitization of sound for an audio CD with a necessary frequency of 44.1 kHz (corresponding to a response time ≤ 22.7 microseconds). Such a solution satisfies the reliable hard real-time criterion, since it was specifically designed to perform a single task. However, a complex real-time task decomposed according to this principle (such as a system with many input parameters with great dynamics in the required response times ), can be expensive and complex to be solved by the asynchrony and redundant system components.

Synchronous approaches

A generalized approach for multiple tasks is to use a single, equally clocked ( synchronous ) solution platform, typically implemented with microcontrollers, DSPs, FPGAs or CPUs. The information required for real- time condition reaction times to try to meet in this solution concept in that all tasks are executed sequentially as soon as possible. The real- time condition is certainly satisfied if the minimum required response time twice as great among the tasks, like the Maximum duration for a total throughput of all tasks.

An example would be a real-time control system having a microcontroller which accepts a plurality of input parameters, calculates a response, and it returns. Assume you want to be s and responds to the crossing of a temperature with a response time of ≤ 1 to a speed below ≤ 1 ms with putting a turn-off. A technically simple solution on a microprocessor with a 2 MHz clock frequency would be a simple endless program loop (example in Intel syntax assembler pseudo code, a semicolon is a comment character ):

Mov a, 10000; Spindle speed limit    mov b, 30; Limit of the temperature    mov O, 1; shutdown signal  : loop; Mark in the program flow ( no instruction is used by the assembler for jump targets)    in t, PORT 1; Read the current speed values    in d, PORT 2; read the current temp values  : rotation check    cmp t, a; check the speed    jg TempCheck; if limit is not reached, jump to: TempCheck    out PORT3, O; Limit is reached! set switch-off signal  : TempCheck    cmp d, b; check the temperature    jg loop; if limit is not reached, jump to: loop    out PORT3, O; Limit is reached! set switch-off signal      jmp loop; unconditional jump to label: loop ( infinite loop ) Assuming that each command ( each line of code ) costs on this processor clock cycle of time, a test cycle is performed in six clock cycles, with a worst case response time of 12 clock cycles for the temperature () and 11 for the rotation speed ( ). The hard real-time requirements are met with this scheme but is orders of magnitude faster than is actually necessary ( inefficient ). An extension of the real-time control, for example, to the test of a pressure is possible through this over-dimensioning of the system. However, the achieved response time for each of the sub-tasks grows with the total elapsed time. The border of this design is thus achieved when the worst-case event, the total elapsed time exceeds the response time for a subtask.

This concept is the usual paradigm on the computer for multimedia applications such as video, demos and games. Typically, so only the soft real- time condition criterion is met because a Worst-case-Abarbeitungszeit/Reaktionszeit due to the complexity of the system can not be determined ( or, as in the example above, not countable ) and / or non- deterministic. For multimedia applications, this nondeterminism is expressed eg by varying FPS or response times for inputs. Reasons for this non-determinism are the presence of multiple code paths with different execution times, the waiting execution on inputs or outputs, or simply tasks with variable complexity (eg varying scene complexity in computer games ).

Process-based approaches

In complex real-time systems (such as a PLC or a computer acting as a real-time system ) usually run several processes simultaneously and with different priorities from, governed by a real- time operating system. The minimum response time is defined by the length of time for a complete change from one process of low priority to a process of higher priority. This change is initiated when a defined event occurs, such as generated by an external trigger ( in computer technology interrupt) or internal timer. The actual execution of the called process begins only after the running process change. This performance of the hard real- time criterion to a higher priority task is forced by the execution of a lower priority task is interrupted ( Preemptive multitasking ).

In principle, a PC real-time capable, but not or only very limited, if it is operated with classical multi-tasking operating systems, because then run many asynchronous processes non- deterministically. Real-time operating systems are often also capable of multitasking, but have a different scheduler than conventional systems. There are also solutions where an existing standard operating system is real-time capability by adding special software. This has the advantage that only the truly time-critical processes must take place in real-time system and for the rest of the normal APIs (including compiler or GUI ) can be used in the underlying operating system.

Also in programmable logic controllers ( PLCs) and distributed control systems (DCS ) real-time operating systems are used, which are not directly accessible to the user though.

In a software to meet real-time constraints, the maximum running time must be determined, and may not or only conditionally modifiable factors subject, so it must be deterministic. This is influenced, inter alia, by the following system or software features:

• One problem is complex I / O, such as hard drives with cache and automatic sleep mode or network communication with non- deterministic time behavior (such as IP).
• The term of the operating system and library calls must be taken into account.
• The need for resources, in particular the need for the memory needs to be known. The runtime environment and the hardware must be able to meet the resource requirements.
• In recursion, the maximum recursion depth has the maximum number of iterations it must be established in loops.
• Memory management: it must therefore be ensured that the real-time modules of the virtual memory management of the operating system are not affected and are never swapped out (typically use real-time systems therefore no virtual memory management ).
• A particular problem is also, for example, the use of automatic garbage collection ( garbage collector ), the duration of which must be estimated very pessimistic.
• The behavior in case of imminent timeout must be defined and predictable.

Examples of real-time systems

Computers for the control of technical installations or processes such as machinery, process equipment or transport are almost always real-time systems. Thus, a real-time system to react in time to all events and processes the data " keeping pace " with the technical process. As it were not suspended from the technical process - not normally even in critical situations.

• The temperature of a device in a process plant usually only changes within minutes. A controller that responds within several seconds to deviations, therefore, can not be considered as real-time capability. The reaction time is in the range of seconds.
• Graphical applications on the computer such as games or demos require in updating the screen display response times of ≤ 63 ms ( ≥ 14-16 fps ) to be perceived as a liquid flow.
• Computer programs, their reaction times are on user input with input devices (keyboard, mouse, etc. ) under ≤ 10 ms are perceived subjectively as immediately (see usability).

• The airbag control unit in the car must be permanently and process and decide whether and how much the air bag inflates, the measured values ​​of the sensors in the shortest possible time; the reaction time is in the range of 1 ms.
• An anti -lock braking system in a car typically has a frequency of typically ≥ 100 Hz, i.e. the reaction time is below 10 ms.
• In machine tools, the mutual position of the workpiece and tool changes. Today's CNC controls have temporal resolutions of the motion control of 125 microseconds.
• In a car the electronic engine management needs at certain times his results ( injected amount of fuel, ignition timing ) provide. Received later results are worthless. The reaction time is directly dependent on the rotational speed and goes down for typical engines at high rotational speeds of many cylinders up to 1 ms.
• For the accurate deflection of electron beams, for example, in electron beam welding, magnetic fields having frequencies of 100 kHz to 1 MHz to be controlled. The reaction time is from 1 microseconds and 10 microseconds.

Design paradigms

In the implementation, there are two design paradigms: event-driven and time-controlled.

In the event control (mostly using an interrupt ) responds to an incoming event from the outside as soon as possible, that is, started processing. If necessary, a currently running process is interrupted. The event control has the advantage that it reacts with very little loss of time to the event. Because it is intuitive, it is also widely used. The main disadvantage is that it is not preventable, that several events may occur within a short time and there ( with the loss of events and / or violation of the time limits) can thus cause an overload of real-time system come. To work around this problem must be clearly defined which events can occur at which maximum frequency. Typically, priorities determined by the order in which concurrent events to be processed. In a hard real-time environment must be ensured that even in the worst case ( maximum number and frequency of all possible events ) itself, the process with the lowest priority his result is still able to deliver within the time limits, that is, still gets allocated enough computing time, to perform his assigned duties.

In the time control processes are started due to a pre-determined schedule. Each process a precisely defined time slice is therefore assigned to the scheduler (eg every 100 ms exactly 10 ms). The advantage is that congestion can be ruled out (if the process never exceeds the allotted time). The behavior of the application is predictable for all time, making it suitable timing for safety-critical applications. The disadvantage of the timing is the higher planning effort (the time allocation must be precisely known during the implementation of the processes ) and the necessary tools associated use. Another advantage is that at the timing the available resources (CPU time, memory ) can be utilized to 100 per cent, while this is not possible in the event of its control due to asynchrony. In the event control is always some reserve must be planned for the resources so that the system can "catch up " with a heavy load time.