A notion which applies to those computing systems where near-simultaneous response to input data is a necessary requirement; examples include air-traffic control, point-of-sale terminals, military applications, and vehicle control. Interactive computing on larger computers is generally time-shared, and does not place the user in a real-time computing environment.
In computer science, real-time computing (RTC) is the study of hardware and software systems which are subject to a "real-time constraint" —ie. 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. A real time deadline must be met, regardless of system load.
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 implemention of a real-time operating system, giving the user interface and the disk drives lower priority than the real time thread. Modern Desktop PCs will usually fail at such tasks, if no specialised real-time operating system is installed.
Hard and Soft real time systems
A system is said to be real-time if the correctness of an operation depends not only upon the logical correctness of the operation but also upon the time at 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.
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, such as physically damaging the surroundings or threatening human lives; 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.
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. Live audio-video systems are also usually soft real-time;
It is important to note that hard versus soft real-time does not necessarily relate to the length of time available.
Real time and high performance
Real-time computing is sometimes misunderstood to be high performance computing, but this is not always the case. 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. Hence, such a network server would not be considered an RTC system: Temporal failures (delays, time-outs, etc.) are typically small and compartmentalized but are not catastrophic failures. 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.
User Comments Add a comment…