Real-time computing


Real-time computing is the computer science term for hardware and software systems subject to a "real-time constraint", for example from event to system response. Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".
The term "real-time" is also used in simulation to mean that the simulation's clock runs at the same speed as a real clock.
Real-time responses are often understood to be in the order of milliseconds, and sometimes microseconds. A system not specified as operating in real time cannot usually guarantee a response within any timeframe, although typical or expected response times may be given. Real-time processing fails if not completed within a specified deadline relative to an event; deadlines must always be met, regardless of system load.
A real-time system has been described as one which "controls an environment by receiving data, processing them, and returning the results sufficiently quickly to affect the environment at that time". The term "real-time" is used in process control and enterprise systems to mean "without significant delay".
Real-time software may use one or more of the following: synchronous programming languages, real-time operating systems, and real-time networks. Each of these provides essential frameworks on which to build a real-time software application.
Systems used for many safety-critical applications must be real-time, such as for control of fly-by-wire aircraft, or anti-lock brakes, both of which demand immediate and accurate mechanical response.

History

The term real-time derives from its use in early simulation, where a real-world process is simulated at a rate which matched that of the real process. Analog computers, most often, were capable of simulating at a much faster pace than real-time, a situation that could be just as dangerous as a slow simulation if it were not also recognized and accounted for.
Minicomputers, particularly from the 1970s onwards, when built into dedicated embedded systems such as DOG scanners, increased the need for low-latency priority-driven responses to important interactions with incoming data. Operating systems such as Data General's RDOS and RTOS with background and foreground scheduling as well as Digital Equipment Corporation's RT-11 date from this era. Background-foreground scheduling allowed low-priority tasks CPU time when no foreground task needed to execute, and gave absolute priority within the foreground to threads/tasks with the highest priority. Real-time operating systems would also be used for time-sharing multiuser duties. For example, Data General Business Basic could run in the foreground or background of RDOS and would introduce additional elements to the scheduling algorithm to make it more appropriate for people interacting via dumb terminals.
Early personal computers were sometimes used for real-time computing. The possibility of deactivating other interrupts allowed for hard-coded loops with defined timing, and the low interrupt latency allowed the implementation of a real-time operating system, giving the user interface and the disk drives lower priority than the real-time thread. Compared to these, the programmable interrupt controller of the Intel x86 family of CPUs generates a very large latency and the Windows operating system is neither a real-time operating system nor does it allow a program to take over the CPU completely and use its own scheduler, without using native machine language and thus bypassing all interrupting Windows code. However, several coding libraries exist that offer real-time capabilities in a high-level language on a variety of operating systems, for example, Real-time Java. Later microprocessors such as the Motorola 68000 and subsequent family members also became popular with manufacturers of industrial control systems. This application area is one where real-time control offers genuine advantages in terms of process performance and safety.

Criteria for real-time computing

A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline:
  • Hard missing a deadline is a total system failure.
  • Firm infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
  • Soft the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.
Thus, the goal of a hard real-time system is to ensure that all deadlines are met, but for soft real-time systems the goal becomes meeting a certain subset of deadlines in order to optimize some application-specific criteria. The particular criteria optimized depend on the application, but some typical examples include maximizing the number of deadlines met, minimizing the lateness of tasks and maximizing the number of high-priority tasks meeting their deadlines.
Hard real-time systems are used when it is imperative that an event be reacted to within a strict deadline. Such strong guarantees are required of systems for which not reacting in a certain interval of time would cause great loss in some manner, especially damaging the surroundings physically or threatening human lives. Some examples of hard real-time systems:
  • A car engine control system is a hard real-time system because a delayed signal may cause engine failure or damage.
  • Medical systems such as heart pacemakers. Even though a pacemaker's task is simple, because of the potential risk to human life, medical systems like these are typically required to undergo thorough testing and certification, which in turn requires hard real-time computing in order to offer provable guarantees that a failure is unlikely or impossible.
  • Industrial process controllers, such as a machine on an assembly line. If the machine is delayed, the item on the assembly line could pass beyond the reach of the machine, or the machine or the product could be damaged by activating the robot at the wrong time. If the failure is detected, both cases would lead to the assembly line stopping, which slows production. If the failure is not detected, a product with a defect could make it through production, or could cause damage in later steps of production.
  • Hard real-time systems are typically found interacting at a low level with physical hardware, in embedded systems. Early video game systems, such as the Atari 2600 and Cinematronics vector graphics, had hard real-time requirements because of the nature of the graphics and timing hardware.
  • Softmodems replace a hardware modem with software running on a computer's CPU. The software must run every few milliseconds to generate the next audio data to be output. If that data is late, the receiving modem will lose synchronization, causing a long interruption as synchronization is reestablished or causing the connection to be lost entirely.
  • Many types of printers have hard real-time requirements, such as inkjets, laser printers, and dot matrix and various types of line printers. A failure in any of these would cause either missing output or misaligned output.
In the context of multitasking systems the scheduling policy is normally priority driven. In some situations, these can guarantee hard real-time performance. There are other hard real-time schedulers such as rate-monotonic, which is not common in general-purpose systems, as it requires additional information in order to schedule a task: namely, a bound or worst-case estimate for how long the task must execute. Specific algorithms for scheduling such hard real-time tasks exist, like earliest deadline first, which, ignoring the overhead of context switching, is sufficient for system loads of less than 100%. New overlay scheduling systems, such as an adaptive partition scheduler assist in managing large systems with a mixture of hard real-time and non real-time applications.
Firm real-time systems are more nebulously defined, and some classifications do not include them, distinguishing only hard and soft real-time systems. Some examples of firm real-time systems:
  • The assembly line machine described earlier as hard real-time could instead be considered firm real-time. A missed deadline still causes an error that needs to be dealt with: there might be machinery to mark a part as bad or eject it from the assembly line, or the assembly line could be stopped so an operator can correct the problem. However, as long as these errors are infrequent, they may be tolerated.
Soft real-time systems are typically used to solve issues of concurrent access and the need to keep a number of connected systems up-to-date through changing situations. Some examples of soft real-time systems:
  • Software that maintains and updates the flight plans for commercial airliners. The flight plans must be kept reasonably current, but they can operate with the latency of a few seconds.
  • Live audio-video systems are also usually soft real-time. A frame of audio that is played late may cause a brief audio glitch, but this may be better than the alternatives of continuing to play silence, static, a previous audio frame, or estimated data. A frame of video that is delayed typically causes even less disruption for viewers. The system can continue to operate and also recover in the future using workload prediction and reconfiguration methodologies.
  • Similarly, video games are often soft real-time, particularly as they try to meet a target frame rate. As the next image cannot be computed in advance, since it depends on inputs from the player, only a short time is available to perform all the computing needed to generate a frame of video before that frame must be displayed. If the deadline is missed, the game can continue at a lower frame rate; depending on the game, this may only affect its graphics, or the gameplay itself may be slowed down.