Real-time computing: Difference between revisions

Content deleted Content added

Inline

Revision as of 16:38, 6 November 2005

Real-time computing is the study of hardware and software systems which are subject to constraints in time. In particular, they are systems that are subject to deadlines from event to system response; that is, the computation can be said to fail if it does not complete in the time-period after the event before the deadline relative to the event. These deadlines are independent of system load. Real-time computing can be illustrated by contrasting it with non-real-time computing. A classic example of a real-time computing system is the anti-lock brakes on a car. The real-time constraint, or deadline, in this system is the time in which the brakes must be released to prevent the wheel from locking. A network server is a system in which fast response is desired but for which there is no deadline. If the network server is highly loaded, its response time may slow with no failure in service. This is contrasted with the anti-lock system where a slow down in response would likely cause system failure, possibly even catastrophic failure. Real-time computing is sometimes misunderstood to be high performance computing, but these examples illustrate that this is not the case. Network servers, depending on demand, can soak up all the performance enhancement available and yet are not real-time computations, whereas once the hardware and software for the anti-lock brake system has been designed to meet the required deadline no further performance is necessary or desired. Some kinds of software, such as many chess-playing programs, can fall into either category. If the chess program must for instance play in a tournament with a clock it would by definition have a deadline and therefore would become a real-time computation, whereas if we let the program stop when it came to its own decision on a move it would not be a real-time computation. One can see fairly easily in this chess program example the essential difference between real-time computations and other computations, in one case it takes whatever time it needs, and in the other case if the 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.

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.

The needs of real-time software are often addressed via use of real-time operating systems, and synchronous programming languages, which provide frameworks on which to build real-time application software.

Key people

External links

@@ Line 1: / Line 1: @@
 {{mergeto|Real-time}}
-'''Real-time computing''' is the study of [[Computer hardware|hardware]] and [[software]] systems which are subject to constraints in time.  In particular, they are systems that are subject to deadlines from event to system response; that is, the computation can be said to fail if it does not complete in the time-period after the event before the deadline relative to the event.  These deadlines are independent of system load.  Real-time computing can be illustrated by contrasting it with non-real-time computing.  A classic example of a real-time computing system is the [[anti-lock brakes]] on a car.  The real-time constraint, or deadline, in this system is the time in which the brakes must be released to prevent the wheel from locking.  A [[network server]] is a system in which fast response is desired but for which there is no deadline.  If the network server is highly loaded, its response time may slow with no failure in service.  This is contrasted with the anti-lock system where a slow down in response would likely cause system failure, possibly even catastrophic failure.  Real-time computing is sometimes misunderstood to be [[high performance computing]], but these examples illustrate that this is not the case.  Network servers, depending on demand, can soak up all the performance enhancement available and yet are not real-time computations, whereas once the hardware and software for the anti-lock brake system has been designed to meet the required deadline no further performance is necessary or desired.  Some kinds of software, such as many [[chess]]-playing [[Computer program|program]]s, can fall into either category.  If the chess program must for instance play in a tournament with a clock it would by definition have a deadline and therefore would become a real-time computation, whereas if we let the program stop when it came to its own decision on a move it would not be a real-time computation.  One can see fairly easily in this chess program example the essential difference between real-time computations and other computations, in one case it takes whatever time it needs, and in the other case if the 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.
+'''Real-time computing''' is the study of [[Computer hardware|hardware]] and [[software]] systems which are subject to constraints in time.  In particular, they are systems that are subject to deadlines from event to system response; that is, the computation can be said to fail if it does not complete in the time-period after the event before the deadline relative to the event.  These deadlines are independent of system load.  Real-time computing can be illustrated by contrasting it with non-real-time computing.  A classic example of a real-time computing system is the [[anti-lock brakes]] on a car.  The real-time constraint, or deadline, in this system is the time in which the brakes must be released to prevent the wheel from locking.  A [[network server]] is a system in which fast response is desired but for which there is no deadline.  If the network server is highly loaded, its response time may slow with no failure in service.  This is contrasted with the anti-lock system where a slow down in response would likely cause system failure, possibly even catastrophic failure.  Real-time computing is sometimes misunderstood to be [[high performance computing]], but these examples illustrate that this is not the case.  Network [[servers]], depending on demand, can soak up all the performance enhancement available and yet are not real-time computations, whereas once the hardware and software for the anti-lock brake system has been designed to meet the required deadline no further performance is necessary or desired.  Some kinds of software, such as many [[chess]]-playing [[Computer program|program]]s, can fall into either category.  If the chess program must for instance play in a tournament with a clock it would by definition have a deadline and therefore would become a real-time computation, whereas if we let the program stop when it came to its own decision on a move it would not be a real-time computation.  One can see fairly easily in this chess program example the essential difference between real-time computations and other computations, in one case it takes whatever time it needs, and in the other case if the 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.
 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''').

Revision as of 16:38, 6 November 2005

Key people

See also

External links