In this post, I want to briefly discuss a broadly-misused term, and attempt to define it. When I say broadly misused, I mean exactly that. Whether on the job or elsewhere — such as today, at a webinar run by a prestigious analytics firm — the truth is most people who routinely use IT services do not have a proper understanding of the terms ‘real time’ or ‘real-time system.’
It is not uncommon to hear ‘real time’ and ‘very fast’ used together, and naive end users cannot be blamed for thinking along those lines. Indeed, when discussing the purchase of an expensive system, a vendor will say it is ‘real time’ or will boast about its ‘real-time performance’ crunching gobs of ‘real-time data’, and the customer in the hospital’s IT department or on the clinical staff will generally assume that it is fast, even ‘Ferrari fast’, and thus able to do millions of calculations or transactions in a matter of milliseconds. The inference is that the system will therefore perform in a manner satisfactory to their needs. This, of course, is not necessarily true, or I would not be writing this post.
A transaction-oriented system (think a DBMS) is considered to perform as expected when its outputs are correct, by which I mean that numerically or otherwise accurate data are retrieved and displayed to end users. A real-time system, on the other hand, needs for its outputs to be both accurate and timely to be considered to be working correctly. So, we see that the definitions of operational correctness are actually quite different. Real-time systems often have their inputs tied to real world events, or sit on top of complex physical systems, and the ‘corrective action’ calculated by the computer system to try to influence those events in the physical system (or ‘physical plant,’ in engineering terms) may not lag the inputs indefinitely or catastrophic failure will likely ensue.
The astute reader will have noticed that I have not been specific, since ‘timely’ could really mean anything. This is true, because a real-time system does not carry with it a connotation of producing results within X seconds, say, where X is a hard number. Whereas a specification for the design of a real-time system could well require that it perform its function within X milliseconds, no such specificity is inherent to the term ‘real-time system.’
So, what then, does ‘timely’ mean?
A simple definition is that a system that produces a correct output within a certain time-frame or before a certain deadline is considered to work in timely fashion, whereas if it does so at any time afterwards it is considered to have failed and to not have met its real-time requirements. The system has failed to produce a timely response, although the response may have been numerically accurate, and therefore it has failed the two-pronged real-time correctness test defined earlier. Examples of real-time systems include ABS on motorcycles, ECG/arythmia monitors in hospital ICUs, floor trading systems for stocks, bonds, or commodities, over-temperature controllers in nuclear power plants, and even automated mail order systems, the latter with a perfectly acceptable response of days or weeks. Clearly, if any of these systems is late to react and is therefore not timely, it cannot not be said to be operating correctly and great damage may be the result. Hard real-time systems — distinguished from the more common soft real-time systems — are so called not because of the extremely short time-frame allowed for system response to occur, but rather due to the impact of a potential failure.
I hope this post has helped to clarify the all too common misconception associating the definition of real-time system with sub-second performance.