Original supplied source slides 33–52. The source retains historical examples and wording. Use the classroom explanation for contextual qualifications. Source review is part of the chapter.

Download the original source pack for full slide layout and vector diagrams.

Slide 33 · Fault-tolerant architectures

Fault-tolerant architectures

Slide 34 · Fault tolerance

Fault tolerance In critical situations, software systems must be fault tolerant. Fault tolerance is required where there are high availability requirements or where system failure costs are very high. Fault tolerance means that the system can continue in operation in spite of software failure. Even if the system has been proved to conform to its specification, it must also be fault tolerant as there may be specification errors or the validation may be incorrect.

Slide 35 · Fault-tolerant system architectures

Fault-tolerant system architectures Fault-tolerant systems architectures are used in situations where fault tolerance is essential. These architectures are generally all based on redundancy and diversity. Examples of situations where dependable architectures are used: Flight control systems, where system failure could threaten the safety of passengers Reactor systems where failure of a control system could lead to a chemical or nuclear emergency Telecommunication systems, where there is a need for 24/7 availability.

Slide 36 · Protection systems

Protection systems A specialized system that is associated with some other control system, which can take emergency action if a failure occurs. System to stop a train if it passes a red light System to shut down a reactor if temperature/pressure are too high Protection systems independently monitor the controlled system and the environment. If a problem is detected, it issues commands to take emergency action to shut down the system and avoid a catastrophe.

Slide 37 · Protection system architecture

Protection system architecture

Slide 38 · Protection system functionality

Protection system functionality Protection systems are redundant because they include monitoring and control capabilities that replicate those in the control software. Protection systems should be diverse and use different technology from the control software. They are simpler than the control system so more effort can be expended in validation and dependability assurance. Aim is to ensure that there is a low probability of failure on demand for the protection system.

Slide 39 · Self-monitoring architectures

Self-monitoring architectures Multi-channel architectures where the system monitors its own operations and takes action if inconsistencies are detected. The same computation is carried out on each channel and the results are compared. If the results are identical and are produced at the same time, then it is assumed that the system is operating correctly. If the results are different, then a failure is assumed and a failure exception is raised.

Slide 40 · Self-monitoring architecture

Self-monitoring architecture

Slide 41 · Self-monitoring systems

Self-monitoring systems Hardware in each channel has to be diverse so that common mode hardware failure will not lead to each channel producing the same results. Software in each channel must also be diverse, otherwise the same software error would affect each channel. If high-availability is required, you may use several self-checking systems in parallel. This is the approach used in the Airbus family of aircraft for their flight control systems.

Slide 42 · Airbus flight control system architecture

Airbus flight control system architecture

Slide 43 · Airbus architecture discussion

Airbus architecture discussion The Airbus FCS has 5 separate computers, any one of which can run the control software. Extensive use has been made of diversity Primary systems use a different processor from the secondary systems. Primary and secondary systems use chipsets from different manufacturers. Software in secondary systems is less complex than in primary system – provides only critical functionality. Software in each channel is developed in different programming languages by different teams. Different programming languages used in primary and secondary systems.

Slide 44 · N-version programming

N-version programming Multiple versions of a software system carry out computations at the same time. There should be an odd number of computers involved, typically 3. The results are compared using a voting system and the majority result is taken to be the correct result. Approach derived from the notion of triple-modular redundancy, as used in hardware systems.

Slide 45 · Hardware fault tolerance

Hardware fault tolerance Depends on triple-modular redundancy (TMR). There are three replicated identical components that receive the same input and whose outputs are compared. If one output is different, it is ignored and component failure is assumed. Based on most faults resulting from component failures rather than design faults and a low probability of simultaneous component failure.

Slide 46 · Triple modular redundancy

Triple modular redundancy

Slide 47 · N-version programming

N-version programming

Slide 48 · N-version programming

N-version programming The different system versions are designed and implemented by different teams. It is assumed that there is a low probability that they will make the same mistakes. The algorithms used should but may not be different. There is some empirical evidence that teams commonly misinterpret specifications in the same way and chose the same algorithms in their systems.

Slide 49 · Software diversity

Software diversity Approaches to software fault tolerance depend on software diversity where it is assumed that different implementations of the same software specification will fail in different ways. It is assumed that implementations are (a) independent and (b) do not include common errors. Strategies to achieve diversity Different programming languages Different design methods and tools Explicit specification of different algorithms

Slide 50 · Problems with design diversity

Problems with design diversity Teams are not culturally diverse so they tend to tackle problems in the same way. Characteristic errors Different teams make the same mistakes. Some parts of an implementation are more difficult than others so all teams tend to make mistakes in the same place; Specification errors; If there is an error in the specification then this is reflected in all implementations; This can be addressed to some extent by using multiple specification representations.

Slide 51 · Specification dependency

Specification dependency Both approaches to software redundancy are susceptible to specification errors. If the specification is incorrect, the system could fail This is also a problem with hardware but software specifications are usually more complex than hardware specifications and harder to validate. This has been addressed in some cases by developing separate software specifications from the same user specification.

Slide 52 · Improvements in practice

Improvements in practice In principle, if diversity and independence can be achieved, multi-version programming leads to very significant improvements in reliability and availability. In practice, observed improvements are much less significant but the approach seems leads to reliability improvements of between 5 and 9 times. The key question is whether or not such improvements are worth the considerable extra development costs for multi-version programming.