Real-time systems
Users of most software systems like to have their applications respond quickly: the difference is that in most information systems and general desktop applications, a rapid response is a useful feature, while in many real-time systems it is an essential feature.
Consider, for example, the greatly simplified aircraft autopilot application illustrated schematically in Figure 1.4.
Here, we assume that the pilot has entered the required course heading and that the system must make regular and frequent changes to the rudder, elevator, aileron and engine settings (for example) in order to keep the aircraft following this path.
An important characteristic of this system is the need to process inputs and generate outputs very rapidly, on a time scale measured in milliseconds. In this case, even a slight delay in making changes to the rudder setting (for example) may cause the plane to oscillate very unpleasantly or, in extreme circumstances, even to crash. As a consequence of the need for rapid processing, few software engineers would argue with a claim that the autopilot system is representative of a broad class of real-time systems.
In order to be able to justify the use of the aircraft system in practice, it is not
enough simply to ensure that the processing is ‘as fast as we can make it’: in this situ- ation, as in many other real-time applications, the key characteristic is deterministic processing. What this means is that in many real-time systems we need to be able to guarantee that a particular activity will always be completed within (say) 2 ms, or at precisely 6 ms intervals: if the processing does not match this specification, then the application is not simply slower than we would like, it is useless.
Tom De Marco has provided a graphic description of this form of hard real-time requirement in practice, quoting the words of a manager on a software project:
‘We build systems that reside in a small telemetry computer, equipped with all kinds of sensors to measure electromagnetic fields and changes in temperature, sound and physical disturbance. We analyze these signals and transmit the results back to a remote computer over a wide-band chan- nel. Our computer is at one end of a one-meter long bar and at the other end is a nuclear device. We drop them together down a big hole in the ground and when the device detonates, our computer collects data on the leading edge of the blast. The first two-and-a-quarter milliseconds after detonation are the most interesting. Of course, long before millisecond three, things have gone down hill badly for our little computer. We think of that as a real-time constraint.
(De Marco, writing in the foreword to Hatley and Pirbhai, 1987) In this case, it is clear that this real-time system must complete its recording on time: it has no opportunity for a ‘second try’. This is an extreme example of what is sometimes referred to as a ‘hard’ real-time system.
Note that, unlike this military example, many applications (like the aircraft system outlined earlier), involve repeated sampling of data from the real world (via a trans- ducer and analog-to-digital converter) and, after some (digital) processing, creating an appropriate analog output signal (via a digital-to-analog converter and an actuator). Assuming that we sample the inputs at 1000 Hz then, to qualify as a real-time system, we must be able to process this input and generate the corresponding output, before we are due to take the next sample (0.001 seconds later).
To summarize, consider the following ‘dictionary’ definition of a real-time system:
‘[A] program that responds to events in the world as they happen. For example, an automatic-pilot program in an aircraft must respond instantly in order to correct deviations from its course. Process control, robotics, games, and many military applications are examples of real-time systems.’
(Hutchinson New Century Encyclopedia (CD ROM edition, 1996))
It is important to emphasize that a desire for rapid processing, either on the part of the designer or on the part of the client for whom the system is being developed, is not enough, on its own, to justify the description ‘real time’. This is often misunder- stood, even by developers within the software industry. For example, Waites and Knott have stated:
‘Some business information systems also require real-time control … Typical examples include airline booking and some stock control systems where rapid turnover is the norm.’(Waites and Knott, 1996, p.194)
In fact, neither of these systems can sensibly be described as a real-time application.