Many programming texts (written by folks who ought to know better) confuse the concepts of real-time software with mission-critical.
- I see hard and soft realtime confused all the time, but haven't seen them confused with mission-critical. Where do you see this confusion? I've never seen them confused either, but perhaps I just thought the author was talking nonsense, which substituting one term for the other would have transformed into sense...?
They are
not in any sense the same.
RealTime software is software which fails if a timing deadline is not met.
MissionCritical software is software whose failure might cause catastrophic consequences (such as someone dying, damage to property, severe financial losses, etc.)
While the two frequently go hand-in-hand (much real-time software is also mission-critical); the two concepts are orthogonal.
- The control software for a medical radiation device is likely both real-time and mission critical. As a control system, it undoubtedly has a real-time component. As a medical device, it is mission critical. Several people were killed when the control software for the TheracTwentyFive malfunctioned (though this wasn't a failure due to not meeting a RealTime constraint).
- The control software which runs the printhead on a cheap HP inkjet printer is real-time, but not mission-critical. Were the software to not calculate the appropriate amount of ink to deposit before the printhead reaches the point, one would end up with a spoiled page. One would not end up with someone dead, however. (Assuming that the failure of this software will not cause the printer to catch fire, or something like that)
- The software which handles banking transactions (in the millions of dollars) is mission-critical but not real-time. Were it to fail, severe financial losses would result. However, there isn't any time interval which in which a transaction must complete, else the system is considered to have failed.
- The vast majority of software is neither mission-critical nor real-time.
Hard real-time systems must not miss a deadline. "A late answer is a wrong answer". In certain cases, an early answer is also a wrong answer. Generally, the deadlines are not negotiable - they are often determined by the physics of the other objects involved. An example of hard real-time is an air bag for a car.
Soft real-time systems can handle missing some deadlines (or their deadlines are soft), although their functionality does depend on speedy processing. An example of soft real-time is echoing input from a keyboard. Slow echoing is annoying, but the result is still correct.
Non-real-time systems have no absolute deadlines, although issues like performance and throughput may still be important.
If performance or throughput are important, the system is at least soft real-time. There are really very few systems that are non-real-time -- the user expects an answer within a "reasonable" amount of time. Usually, that "reasonable" amount of time is so much longer than the computer really needs that you can implement the software without resorting to real-time techniques.
Really? Many "overnight batch" programs are (or were) designed with performance and throughput in mind, and the user expects an answer within a "reasonable" amount of time (8 to 16 hours), but I've never heard them described as real-time! This discussion seems to have already taken place on RealTime. RefactorMe
- Don't confuse fast/high throughput with real-time. With RealTime (hard or soft), there is a line in the sand; with consequences if the line is crossed (with soft real-time, the line can occasionally be crossed). With high-throughput; speed is a figure of merit; but in general there isn't a hard and fast separation between "acceptable" and "unacceptable"; and a late answer is still a useful one. Generally, the term "soft real time" is used for things with tighter constraints than merely a "responsive UI". A streaming video codec is a good example of a soft real-time system; the codec ought to be able to decode the video at a rate of 30 frames per second (or whatever the video format is); if it doesn't a noticeable degradation in performance occurs. However, dropping the occasional frame doesn't cause system failure, just poorer performance. A codec that dropped every other frame, OTOH, might be considered unacceptable. A codec that can render frames faster than 30 frames per second, OTOH, won't improve the user's experience; there's no point in rendering video faster than it streams. (It might leave more CPU cycles for something else).
It should be noted that many design techniques designed for high throughput are inappropriate for real-time, and vice versa. For high-throughput applications, it is not uncommon to see (non-deterministic) caching strategies employed, for example -- strategies which improve average performance (but make worst-case worse). Such strategies are a no-no in a hard realtime system; where one tries to make things deterministic as possible, and is generally interested in worst-case performance. The importance of average-case analysis vs worst-case analysis is a key differentiator between real-time and non-real-time. The worst-case query time for
OracleDatabase, for instance, is something that most folks don't care about (and Oracle doesn't specify). The average-case query time (and the number of queries per second possible on a given system), OTOH, is a BannerSpec
? for any RDBMS.
- Sadly, many so-called real-time programmers don't realize this. They do realize that their computation must be time-bounded, but they also write code to make the average performance better at the cost of the worst-case.
Actually, real time design
starts with the worst case and moves to the average from there. If there is a hard real time limitation (this rotary encoder must be read before the count exceeds 127 at this speed) then it won't matter if the system is faster overall but fails to meet the worst case. The system is a failure. Real time design starts with these considerations foremost.
Does the term "mission-critical" really have to imply catastrophic consequences when it fails? I thought it just meant that correct operation was necessary for the users to be able to perform their mission, whatever that is. A printer component could be mission critical if that was the only printer available to an organization that makes its money by printing things. An X-Box could be mission-critical if you are seeking to entertain some kids.
- Usually, the term mission-critical implies catastrophic consequences (and thereby implying a different set of design/test methodologies being brought to bear to solve the problem). If we use your definition, then any software might be considered mission-critical -- and criticalness becomes more a property of the application then of the software itself. (Criticality should be designed into the software when appropriate; non mission critical software shouldn't be used for mission critical tasks - and it is often too expensive to develop and maintain mission-critical software quality for non mission critical tasks).
- You might consider mission-critical a case where software failure will cost you more than correct and robust software will cost you. Costs on both sides might be measured in money, time and skilled labor, reputation, lawsuits, human lives, and so on. Exactly how human lives weigh into that equation really depends on your conscience and on your government. Software for a gaming console might not be 'mission-critical' in the sense of failing a mission to entertain children, but might be 'mission-critical' to the effect that a failure has a great financial cost or damage to reputation. (Not that Microsoft's reputation would be much hurt by yet another product that crashes regularly...)
Any software can be considered mission-critical. It's up to the "mission" to determine what is "critical" and to manage its risk accordingly. Whether the "mission" should use software designed with a radically different perception of criticality in mind is an entirely separate question.
- Agreed; though it is occasionally suggested that even the most trivial software (a text editor, say), ought to be subject to ProofOfCorrectness and/or other formal methods -- on the grounds that it might get one day used in a mission-critical system (even if not explicitly designed for such). And it should be emphasized that mission-criticality (and RealTimeness) are system properties; not properties of software packages in isolation. (OTOH, many software packages are, by their nature, inappropriate for inclusion in any RealTime or mission-critical system).
See: RealTime
CategoryTime, CategoryEmbeddedSystems?
Real Time Vs Mission Critical