“Most systems people use the term real-time rather loosely,” the young manager said. We were seated over dinner with three members of her staff and some other managers who took part in the day’s seminar. “They say they’ve got a real-time constraint when they’re worried about impatient insurance brokers or bankers sitting in front of their terminals. A real-time system, in their minds, is just one that needs to be ‘quick as a bunny.’ If they fail to meet that constraint, their users might be inconvenienced or even annoyed. When we use the term, it means something rather different.”
Her co-workers began to smile, knowing what was coming. “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 channel. 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.”
Foreword by Tom DeMarco in “Strategies for Real-Time System Specification” by Derek J. Hatley and Imtiaz A. Pirbhai