CS 5032 L8 dependability engineering 2 2013
Download as PPTX, PDF1 like1,188 views
This document discusses dependable systems architectures, including protection systems, self-monitoring architectures, and N-version programming. It notes that dependable architectures use redundancy and diversity to ensure fault tolerance. Key challenges include achieving true software and design diversity, as teams may interpret specifications similarly and diverse versions could still contain common errors.
CS 5032 L8 dependability engineering 2 2013
- 1. Dependable systems architectures Lecture 2 Dependable systems architectures, 2013 Slide 1
- 2. System fault tolerance • Fault tolerance means that the system can continue in operation in spite of software fault i.e. the fault does not lead to a failure • Fault tolerance is required where there are high availability requirements, no ‘fail safe’ state or where system failure costs are very high. • 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. Dependable systems architectures, 2013 Slide 2
- 3. Dependable system architectures • Dependable 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. Dependable systems architectures, 2013 Slide 3
- 4. 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. Dependable systems architectures, 2013 Slide 4
- 5. Sizewell B reactor • Software controlled protection system in Sizewell B reactor • Go-live in 1993 • Software protection system has been claimed to have a 1/10000 PFD Dependable systems architectures, 2013 Slide 5
- 6. Protection system architecture Dependable systems architectures, 2013 Slide 6
- 7. 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. Dependable systems architectures, 2013 Slide 7
- 8. 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. Dependable systems architectures, 2013 Slide 8
- 9. Self-monitoring architecture Dependable systems architectures, 2013 Slide 9
- 10. 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. Dependable systems architectures, 2013 Slide 10
- 11. Airbus 340 • Airbus were the first commercial aircraft manufacturer to use ‘fly by wire’ flight control systems • Fly by wire systems are lighter (saving fuel), can be more fuel efficient and can detect and prevent pilot actions that are potentially dangerous. Dependable systems architectures, 2013 Slide 11
- 12. Airbus flight control system architecture Dependable systems architectures, 2013 Slide 12
- 13. 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 and secondary systems use different processors. – 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. Dependable systems architectures, 2013 Slide 13
- 14. Hardware fault tolerance • Depends on triple-modular redundancy (TMR). • Three 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 Dependable systems architectures, 2013 probability of simultaneous Slide 14
- 15. Triple modular redundancy Dependable systems architectures, 2013 Slide 15
- 16. 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. Dependable systems architectures, 2013 Slide 16
- 17. N-version programming Dependable systems architectures, 2013 Slide 17
- 18. 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. Dependable systems architectures, 2013 Slide 18
- 19. Software diversity • Approaches to software fault tolerance embedded in the system architecture 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 Dependable systems architectures, 2013 Slide 19
- 20. 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. Dependable systems architectures, 2013 Slide 20
- 21. 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. Dependable systems architectures, 2013 Slide 21
- 22. 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. • Are such improvements are worth the considerable extra development costs for multi-version programming? • Is it cheaper to increase the reliability of a single version using fault avoidance and fault detection Dependabletechniques? systems architectures, 2013 Slide 22
- 23. Key points • Dependable system architectures are system architectures that are designed for fault tolerance. • Architectural styles that support fault tolerance include protection systems, self-monitoring architectures and N-version programming. • Software diversity is difficult to achieve because it is practically impossible to ensure that each version of the software is truly independent. Dependable systems architectures, 2013 Slide 23