Is safety-critical software a subset of real-time software?

Question

I would like to refute my hypothesis that all safety-critical software (that is, software where errors can have catastrophical consequences, either in terms of human lives or high material costs) is a real-time software (where tasks have timing constraints) by finding interesting counterexamples: systems without timing constraints which are safety-critical.

I tried thinking of several examples, but they always seem somehow related to some physical system (e.g. flight control, radiation therapy, nuclear power) and therefore have some implicit timing constraints/deadlines. Even somewhat contrived "safety-critical" systems such as high-frequency trading are still real-time.

Note: I am not interested in a very specific subset of the code which is timing independent, but on something more complete, consisting of a substantial part of a complete application.

Answer 1

The important thing is to understand that real-time software is a strict subset of "software with timing constraints".

If you want to be nitpicky about it, all software has timing constraints: if the algorithm is correct, but it's not gonna give you the correct answer until one billion years from now, then it's not very useful. So one can make a quite reasonable argument that all software has some sort of timing constraint. Even, say, a sorting routine has some timing requirements.

Does that mean we should say that all software is real-time software? No. That stretches the definition of real-time software to a point where it becomes useless. I would never call mergesort a real-time application (even though there is an upper bound on the running time of mergesort).

Instead, we should realize that not all timing requirements are created equal. Empirically, some timing requirements are very strict and are non-trivial to achieve, while others are straightforward to achieve. For instance, "the brakes must be applied within 30 ms of pressing the brake pedals" is non-trivial to achieve: if we've got some generic software running on a multiprocessor polling the brake pedal sensors, if we are not careful, we could easily end up failing to notice the brake pedal has been pressed for over 30 ms. For instance, maybe a garbage collector kicks in and runs for 50ms, preventing the application code from running for the duration; maybe several other processes are running and the sensor polling process doesn't get a chance to run for a stretch of 50ms; or any number of other possibilities. So that would be an example a situation where we need to apply special techniques to ensure that the timing requirement is met. Software like that is called real-time software.

In contrast, when we have software that technically has some timing requirements but where the timing requirements are relatively easy to achieve, we do not call it real-time software (in general). For instance, consider a web browser/web site: "when I click on a link to CNN, the CNN web page should start to show up within a few seconds, or a minute at most"; or, "when I open a web page in the browser, it should either load within a minute or so, or else the browser should show a visible indication that it was unable to load the page". Those are timing requirements that do not require special real-time techniques to meet. In particular, no one would call your web browser an example of real-time software. There might be some timing requirements, but no one would call your web browser a real-time system, and your web browser was not built using real-time implementation techniques.

With that understanding, it is straightforward to see that there is plenty of safety-critical software that is not real-time software. There are safety-critical systems that are not built using real-time techniques because, while they might have some sort of timing requirement, the timing requirement is easy enough to meet that there is no need for special real-time techniques or systems.

For instance, think of a medical X-ray machine. One requirement might be "when the doctor programs it to irradiate at X units of beam strength for Y minutes, the machine does it, and it does not generate more than X units or run for more than Y minutes". Another requirement might be "the machine beeps whenever it is emitting radiation". Both of these requirements can be achieved without real-time systems. Consequently, I would call this a safety-critical system but not a real-time system.

Answer 2

I would like to refute my hypothesis that all safety-critical software (that is, software where errors can have catastrophical consequences, either in terms of human lives or high material costs) is a real-time software (where tasks have timing constraints) by finding interesting counterexamples: systems without timing constraints which are safety-critical.

A good example of a safety critical program which does not itself have to meet real time constraints is a compiler.

If a compiler has code generation bugs, then even if the programmer wrote a safe program, the emitted machine code may still fail to meet some necessary guarantees. As a result, the standard practice at many development teams developing safety-critical software is to generate code with compiler optimizations turned off, and then to manually review the generated machine code.

The Compcert C compiler has a machine-checked formal proof showing that it never generates incorrect assembly programs for any input program. As a result, it is possible to (a) limit code review to the C source code, and (b) permit the compiler to do optimization passes, without compromising the safety of the overall system. (See for example Towards Formally Verified Optimizing Compilation in Flight Control Software...)

Obviously, if you are trusting the compiler to generate code for flight control software, it is safety-critical. Equally obviously, a compiler is not real time software.

Answer 3

No, not all safety-critical software is real-time. Suppose you have an industrial batch process that generates acidic waste, which must be neutralized by being mixed with an appropriate amount of alkali before being poured down the drain. It's important to use the right amount of alkali: if you use too little, your waste is still acidic; if you use too much, your waste is alkaline. Therefore, the computer program that tells you how much alkali to use is safety-critical.

However, it is not real-time. If, for some reason, the program takes unusually long to tell you how much alkali to use, you just have to wait unusually long before neutralizing your waste and disposing of it. As long as you don't run your process again before you've disposed of the last batch's waste, you will never have more waste than you can deal with.