Real-time computing

From Free net encyclopedia

Template:Mergeto In computer science real-time computing (RTC) is the study of hardware and software systems which are subject to a "real-time constraint" —ie. 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 is a simple example of a real-time computing system where the real-time constrain in this system is the short time in which the brakes must be released to prevent the wheel from locking. RT computations can be said to have failed if they are not completed in the time-period after the event before the deadline relative to the event (where deadlines are independent of system load).

1 Hard and Soft real time systems
2 Real time and high performance
3 Design methods
4 Key people
5 History
6 See also
7 External links

[edit]

Hard and Soft real time systems

A distinction can be made between those systems which will suffer a critical failure if time constraints are violated (hard or immediate real-time), and those which will not (soft real-time).

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.

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. It would not be possible to offer modern commercial air travel if these computations could not reliably be performed in real time. 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 if needed, without affecting a critical operation, perhaps without a delay noticeable to the user.

[edit]

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 an RTC system: Temporal failures (delays, time-outs, etc.) are typically small and compartmentalized but are not catastrophic failures. In an RTC system, a slow-down beyond limits would often be considered catastrophic for 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.

[edit]

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 and Real-Time Java.

[edit]

Key people

[edit]

History

The Saturn rocket had a 50 Hz hard coded loop.

Once when the C64 and later Motorola 68000 were popular, anybody could use his/her home computer as a real-time system. The possibilty to deactivate other interrupts allowed for hard coded loops with defined timing, the low interupt 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.

[edit]