TABLE OF CONTENTS The static and dynamic redundancy architectures described in Chapter 6 can also be applied to software. One important distinction is that fault tolerance in software implies diversity because exact copies of a program are likely to fail at exactly the same instruction. Thus, a problem common to both forms of software fault tolerance is how to ensure independence of failure modes while maintaining uniformity of performance.
At some point all versions of a program will have to start at a common specification that contains the functional and timing requirements dictated by the application. And all versions will have to terminate with data structures that can be evaluated by a common evaluation mechanism. The specification or evaluation mechanism must be carefully generated and reviewed because their faults will not be covered by the fault tolerance provisions. The following have been employed to obtain independence of the software versions:
Independent design teams and design rules;
Independent programming teams;
Different computer languages and compilers;
Different processors.
Despite these precautions, there have been problems achieving fault tolerance in some applications due to common misinterpretation of the specification, particularly as it relates to exception handling [9], and actions of the operating system that recognizes a software problem and causes it to abort before fault tolerance provisions can take over [25].
Static software fault tolerance depends on a voter that can be implemented in either hardware or software. The latter approach is more flexible in allowing small or temporary differences to be...
