Aspects of Fault Tolerance in Software Design

Abstract

A frequent misconception is that the elimination of errors during design is the sole factor in achieving quality software. This is too simplistic an assumption. In practice all software is likely to contain residual faults, albeit at very low levels, after extensive debug and quality activities. Compare, therefore, two safety systems, one of which has some low level of unknown residual faults and another which has double the number. Assume that the code having the greater number of faults has been carefully structured and limited in its ability to access variables and code in such a way as to restrict the propagation of errors. Assume, also, that there are a number of error check routines in the code which enable the program to reinitialise at known acceptable values when an error is detected. If, in addition to these features, the safety system and its software are designed in such a way that individual failures do not cause total loss of function, then it will at least continue to offer a degraded level of protection. An example of the latter would be a fire protection system which measures more than one parameter (i.e. UV light, smoke, rate of temperature rise). The interpretation of each type of input, and the generation of the executive output action, could be dealt with by separate parts of the hardware and software. This fault-tolerant type of design offers a far higher level of integrity than the system which, despite containing fewer faults, implies worse consequences in the event of failure.