Fault-tolerant real-time objects
Communications of the ACM
Dynamic Configuration Management in Reliable Distributed Real-Time Information Systems
IEEE Transactions on Knowledge and Data Engineering
IEEE Transactions on Knowledge and Data Engineering
Primary-shadow consistency issues in the DRB scheme and the recovery time bound
ISSRE '96 Proceedings of the The Seventh International Symposium on Software Reliability Engineering
Systematic Reliability Analysis of a Class of Application-Specific Embedded Software Frameworks
IEEE Transactions on Software Engineering
Structural analysis of explicit fault-tolerant programs
HASE'04 Proceedings of the Eighth IEEE international conference on High assurance systems engineering
| Hi-index | 0.02 |
The failure of safety-critical systems can result in catastrophic loss of life and property. Hence, it is necessary to assure the reliability of these systems to a high degree of confidence before they are put into operational use. However, at these extreme levels of ultra-high reliability requirements, typically failures rates of less than $10^{-7}$ failures per hour, errors in the specification and in estimates of the operational profile become significant factors. An approach that has been suggested in practice is to use secondary and tertiary software that meet ultra-high reliability requirements but at a reduced functionality as compared with the primary software. Two major problems are (a) how to select appropriate functionality for the non-primary versions and (b) how to determine when to invoke these backup versions.In this paper, we present a unified approach for handling these two problems. It starts with a rigorous method for assessing ultra-high reliability requirements and then develops mechanisms for incorporating one or more backup versions. The reliability assessment procedure uses formal methods to amplify the effect of each test case and results in the construction of a reliability MAP (Measured Assurance Prediction system) for the software. This provides a confidence estimate for the correctness of the software for a given operational situation and serves as a trigger for switching to a backup version. The main requirement is that the MAP for the backup version must be known to a higher degree of confidence than that for the original version. The approach is illustrated using a simple process-control example.