The infeasibility of quantifying the reliability of life-critical real-time software

Abstract

This paper affirms that the quantification of lifecritical software reliability is infeasible using statistical methods, whether these methods are applied to standard software or faulttolerant software. The classical methods of estimating reliability are shown to lead to exorbitant amounts of testing when applied to life-critical software. Reliability growth models are examined and also shown to be incapable of overcoming the need for excessive amounts of testing. The key assumption of software fault tolerance-separately programmed versions fail independently-is shown to be problematic. This assumption cannot be justified by experimentation in the ultrareliability region, and subjective arguments in its favor are not sufficiently strong to justify it as an axiom. Also, the implications of the recent multiversion software experiments support this affirmation.

High integrity software for nuclear power plants: Candidate guidelines, technical basis and research needs. Main report, Volume 2

“…Even though these requirements exist, it is beyond the current state of the art to demonstrate these failure rates [Littlewood and Strigini, 1993;Butler and Finelli, 1993;Shimeall and Leveson, 19911. [Littlewood, 19911 and [Musa et al, 19871 have shown that current techniques are capable of demonstrating failure rates of 10-4 per hour (to high confidence levels) by testing.…”

“…'There is no meaningful metric in which small changes and small effects go hand in hand, and there never will be" [Dijkstra, 19891. Furthermore, many problems with developing software arise from its inherent complexity and the nonlinear increase in complexity with size. "From the complexity comes the difficulty of enumerating, much less understanding, all the possible states of the program, and from that comes the unreliability" [Brooks, 19871. Based on a great deal of research completed on software-based systems in normal environments, it appears that deterministic evaluation of such complex systems is currently an intractable problem [Littlewood and Stringini, 1992;Butler and Finelli, 1993;Bennett, 1991;Zucconi, 1991;Lavine, 1990; ; s m 9 3 -2 2 101.…”

Modeling Time-Triggered Protocols and Verifying Their Real-Time Schedules

“…A design error causing a system to have a higher rate of failure-say a failure rate of 10 −8 per hour-is unacceptable, yet it is infeasible to determine whether a system has this reliability through testing alone [6]. The inability to demonstrate correctness through testing motivates us to prove these systems are correct.…”

Software Fault-Freeness and Reliability Predictions

“…For instance, if we had 90% confidence that an item of avionic software has no faults such as to cause catastrophic failure, this by itself satisfies the regulatory requirement that catastrophic failures due to this equipment be "not anticipated to occur during the entire operational life of all airplanes of one type", "usually expressed" as "probability on the order of 10 −9 or less" per flight-hour [6] (the often-quoted "10 −9 " requirement which has been forcefully argued to be infeasible to demonstrate statistically [1,7]). Yet, the possibility that, in the unlikely (10% probability) case of faults being present, such faults cause a high probability (say 1%) of failure per flight, would probably seem unacceptable: some evidence would be required that even if faults are present the pfd would still be low.…”