(Redirected from Real time)
In
computer science, 'real-time computing' (
RToC) is the study of
hardware and
software systems which are subject to a "real-time constraint"—i.e., operational deadlines from event to system response. By contrast, a ''non-real-time system'' is one for which there is no deadline, even if fast response or high performance is desired or even preferred.
The needs of real-time software are often addressed in the context of
real-time operating systems, and
synchronous programming languages, which provide frameworks on which to build real-time application software.
A real time system may be one where its application can be considered (within context) to be
mission critical. The
anti-lock brakes on a car are a simple example of a real-time computing system — the real-time constraint in this system is the short time in which the brakes must be released to prevent the wheel from locking. Real-time computations can be said to have ''failed'' if they are not completed before their deadline, where their deadline is relative to an event. A real-time deadline must be met, regardless of
system load.
History
The term 'real time' derives from its use in early
simulation. While current usage implies that a computation that is 'fast enough' is real time, originally it referred to a simulation that proceeded at a rate that matched that of the real process it was simulating.
Analog computers, especially, were often capable of simulating much ''faster'' than real time, a situation that could be just as dangerous as a slow simulation if it were not also recognized and accounted for.
Once when the
MOS Technology 6502 (used in the
Commodore 64 and
Apple II), and later when the
Motorola 68000 (used in the
Macintosh,
Atari ST, and
Commodore Amiga) were popular, anybody could use their home computer as a real-time system. The possibility to deactivate other interrupts allowed for hard-coded loops with defined timing, 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 CPUs (8086..80586) 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 surpassing all interrupting windows code. However, several coding libraries exist which offer real time capabilities in a high level language on a variety of operating systems, for example
Java Real Time. The
Motorola 68000 and subsequent family members (68010, 68020 etc) also became popular with manufacturers of industrial control systems thanks to this facility. This application area is one in which real-time control offers genuine advantages in terms of process performance and safety.
Hard and Soft real time systems
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. The classical conception is that in a 'hard' or 'immediate real-time system', the completion of an operation after its deadline is considered useless - ultimately, this may lead to a critical failure of the complete system. A 'soft real-time system' on the other hand will tolerate such lateness, and may respond with decreased service quality (e.g., dropping frames while displaying a video).
Hard real-time systems are typically found interacting at a low level with physical hardware, in
embedded systems. For example, a
car engine control system is a hard real-time system because a delayed signal may cause engine failure or damage. Other examples of hard real-time embedded systems include medical systems such as heart
pacemakers and industrial process controllers.
Hard real-time systems are used when it is imperative that an event is reacted to within a strict deadline. Usually such strong guarantees are required of systems for which not reacting in a certain window of time would cause great loss in some manner, especially physically damaging the surroundings or threatening human lives (although the strict definition is simply that missing the deadline constitutes failure of the system). Systems that always have hard real-time constraints (due to the potentially severe outcome of missing a deadline) include nuclear power stations and car airbags. In the context of
multitasking systems the scheduling policy is normally
priority driven pre-emptive schedulers. Other scheduling algorithms include
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.
Soft real-time systems are typically those used where there is some issue of concurrent access and the need to keep a number of connected systems up to date with changing situations. Example: the software that maintains and updates the flight plans for commercial
airliners. These can operate to a latency of seconds. Live audio-video systems are also usually soft real-time; violation of constraints results in degraded quality, but the system can continue to operate.
It is important to note that hard versus soft real-time does not necessarily relate to the length of time available. A machine may overheat if a processor does not turn on cooling within 15 minutes (hard real-time). On the other hand, a
network interface card may lose buffered data if it is not read within a fraction of a second, but the data can be resent over the network (soft real-time), without major adverse consequences.
Real time and high performance
Real-time computing is sometimes misunderstood to be
high performance computing, but this is not always the case. For example, a massive
supercomputer running a scientific simulation may offer impressive performance, yet it is not executing a real-time computation. Conversely, once the hardware and software for an anti-lock braking system has been designed to meet its required deadlines, no further performance gains are necessary. Furthermore, if a network server is highly loaded with
network traffic, its response time may be slower but will (in most cases) still succeed. Hence, such a network server would not be considered a real time system: temporal failures (delays, time-outs, etc.) are typically small and
compartmentalized but are not catastrophic failures. In a real time system, a slow-down beyond limits would often be considered catastrophic in its application context.
Some kinds of software, such as many
chess-playing programs, can fall into either category. For instance, a chess program designed to play in a tournament with a clock will need to decide on a move before a certain deadline or lose the game, and is therefore a real-time computation, but a chess program that is allowed to run indefinitely before moving is not. In both of these cases, however, high performance is desirable: the more work a tournament chess program can do in the allotted time, the better its moves will be, and the faster an unconstrained chess program runs, the sooner it will be able to move. This example also illustrates the essential difference between real-time computations and other computations: if the tournament chess program does not make a decision about its next move in its allotted time it loses the game—i.e., it fails as a real-time computation—while in the other scenario, meeting the deadline is assumed not to be necessary.
Design methods
Several methods exist to aid the design of real-time systems, an example of which is
MASCOT, an old but very successful method which represents the
concurrent structure of the system. Other examples are
HOOD,
Real-Time UML, the
Ravenscar profile and
Real-Time Java.
Key people
★
David Dill
★
Rajeev Alur
★
Costas Courcourbetis
★
Alan Burns
See also
★
Real-time operating system
★
Synchronous programming language
★
Ptolemy Project
★
High frequency computing
★
DSOS
★
Worst-case execution time
External links
Technical Committees
★
IEEE Technical Committee on Real-Time Systems
★
Euromicro Technical Committee on Real-time Systems
Scientific Conferences
★
ECRTS - Euromicro Conference on Real-time Systems
★
IEEE Real-time Systems Symposium
★
IEEE Real-time Technology and Applications Symposium
★
International Symposium on Object-oriented Real-time distributed Computing
★
IEEE International Conference on Embedded and Real-Time Computing Systems and Applications
Research Groups
★
Real-Time & Embedded Computing Laboratory (USMAN SHARIF BCS-SP03-37)
★
Mälardalen Real-Time research Centre
★
Real-time, Embedded, and Specialized Systems Platform Task Force
★
Real-Time Computing Laboratory
★
Real-Time Systems Laboratory
★
RTSE Laboratory
★
Institute for Systems Engineering - Real Time systems Group
★
Real-Time & Embedded Computing Conference
★
Vienna University of Technology - Institute for Computer Engineering - Real-Time Systems Group
★
Real-Time Systems Research Group at the University of York, UK