Software fault tolerance

Randell 1975] B. Randell, System Structure for Software Fault Tolerance, IEEE Trans, on Software Engineering, vol. SE-1, no. 2, pp.220-232, 1975. 

There are irmumerous means to reduce the risk of losing an AUV One could increase the vehicle reliability through redimdancy of critical components, use of safety barriers, at the hardware level. At the software level, software fault tolerance techniques, software diversity and formal checking are also techniques that can reduce the risk of system failure. At the operational level, a guided maintenance program is an effective way to reduce the risk. 

The applied software fault tolerance techniques will be verified. Let us assume, for example, the implementation of the rule 20.3 by MisraC 2004 standard for critical systems. This rule indicates that the validity of values passed to library functions shall be checked to avoid errors. The fault injector can introduce a negative value before a sqrt function call to test the introduced value checking process and the consequences on the system if this check fails. 

The fault tolerant design discussed here mainly pertains to computing systems and intelligent systems for real-time computer systems such as DCS/PLC and/or associated intelligent devices. Here, the discussion is on the basics of hardware and software fault tolerant principles in computing systems, whereas that applicable to control systems is covered in Clause 1.2. Two ways in which fault tolerant designs can be developed are hardware technique and software technique. 

Software fault tolerance For software, fault tolerant design redundancies are required to mask residual design faults. Some of the issues related to this shall include but are not limited to ... 

Because software fault tolerance is based on hardware fault tolerance, it is a bigger challenge. Additional software is used in computing systems for fault handling and for fault-free computation. A few major software fault tolerance techniques somewhat similar to their hardware counter parts have been... 

Software fault tolerance methods. FT, fault tolerance. (A) Software fault n version programming, (B) software fault - recovery block, and (C) software fault - recovery block schematic. 

Design diversity This approach is rather costly. It combines hardware and software fault tolerance in different sets of computing channels. Each channel is developed in different hardware and software in redundant mode to provide the same function. This method is deployed to identify deviation of a channel from the others. The goal is to tolerate both hardware and software design faults [7]. After developing a fault tolerant design it is necessary to validate it from a reliability point of view, discussed later. 

Architecture-level fault injection (FI) has been the standard analysis technique in the software fault-tolerance community for at least two decades [8,9]. In an FI campaign... 

Shimeall, T., Leveson, N. An empirical comparison of software fault tolerance and fault elimination. IEEE TSE 17, 173-182 (1991)... 

Kanoun, K., Laprie, J.-C. Dependability modeling and evaluation of software fault-tolerant systems. IEEE Transactions on Computers 39(4), 504—513 (1990)... 

Lyu, M.T. Software Fault Tolerance. John WUey Sons, Inc., New York (1995) ISBN 0471950688... 

The hardware and software used to implement LIMS systems must be vahdated. Computers and networks need to be examined for potential impact of component failure on LIMS data. Security concerns regarding control of access to LIMS information must be addressed. Software, operating systems, and database management systems used in the implementation of LIMS systems must be vahdated to protect against data cormption and loss. Mechanisms for fault-tolerant operation and LIMS data backup and restoration should be documented and tested. One approach to vahdation of LIMS hardware and software is to choose vendors whose products are precertified however, the ultimate responsibihty for vahdation remains with the user. Vahdating the LIMS system s operation involves a substantial amount of work, and an adequate vahdation infrastmcture is a prerequisite for the constmction of a dependable and flexible LIMS system. 

Reliability and availability Does the running system reliably continue to perform correctly over extended periods of time What proportion of time is the system up and running In the presence of failure, does it degrade gracefully rather than shut down completely Reliability is measured as the mean time to system failure availability is the proportion of time the system is functioning. Both qualities are typically dealt with by making the architecture fault-tolerant using duplicated hardware and software resources. 

Xu et al. 1995] J. Xu, B. Randell, A. Romanovsky, RJ. Stroud and Z. Wu. Fault Tolerance in Concurrent Object-Oriented Software through Coordinated Error Recovery, in Proceedings 25th Int. Symp. Fault-Tolerant Computing (FTCS-25), Los Angeles, IEEE Computer Society Press, 1995. 

Despite the optimistic overtones, robust control is not a solved problem. Some difficult theoretical questions remain in the synthesis area. The available software is, at best, experimental the controller is complex and its structure is not obvious. It generally uses all the measurements and all the manipulated variables in a centralized fashion. On-line tuning is difficult except when the IMC structure is employed [8], Fault tolerance, that is, continued satisfactory or at least stable performance in the event of an actuator or sensor failure, cannot be guaranteed. 

Several of FM s Loss Prevention Data Publications (1, 17B, 17C) discuss the concept of triply-redundant, fault-tolerant, high-reliability hardware/software systems for manufacturing operations. Risk analysis and systems reliability research is currently underway to develop better guidelines for the design and application of reliable process control systems. 

Note that in discussing availability and performance one needs to make reference to the stakeholders responsible for hosting the system. In practice this could be the healthcare organisation, software manufacturer or a third party. The principles of fault tolerance and resilience remain the same irrespective of which party takes commercial responsibility. However the stakeholder responsible for implementing controls will vary as will the information available to safety case developers. In this... 

The accident report does not explore whether the PCS software could have included sanity checks on the roll rate or vehicle behavior to detect that incorrect roll rates were being provided by the IMS. Even if the PCS did detect it was getting anomalous roll rates, there may not have been any recovery or fail-safe behavior that could have been designed into the system. Without more information about the Centaur control requirements and design, it is not possible to speculate about whether the Inertial Navigation Unit software (the IMS and PCS) might have been designed to be fault tolerant with respect to filter constant errors. 

The 3051S SIS has a 61508 assessment certificate states that the product can be used in SIL 2 applications as a single transmitter and SIL 3 applications if more than one transmitter is used in an identical redundant (hardware fault tolerance > 0) architecture. This helps point out the differences between random and systematic failures. The design process used to create the transmitter and its software met the more rigorous criteria of SIL 3. The chance of a systematic fault is lower. 

SIHFT Software Irrrplemerrted Hardware Fault Tolerance... 

Following the state-of-the-art review, the next step is to implement fault tolerance techniques. We will start by explaining in detail and implementing two known software-based techniques, called Variables and Inverted Branches (AZAMBUJA 2010b), which will later be used as a complement to hybrid fault tolerance techniques. These techniques have been proposed in the past years and achieved high fault detection rates at low performance degradation levels and therefore are useful not only as an introduction to software-based fault tolerance techniques, but also to be combined with hardware-based and hybrid techniques. Then, three novel hybrid techniques will be proposed and implemented, based on both software and hardware replication characteristics. The three hybrid techniques will be divided into their software and hardware sides and described in detail, concerning both operation description and implementation. 

The book is organized as follows Chap. 2 presents the terminology and general concepts used in this work. Chapter 3 describes existing fault tolerant techniques for processors presented in the literature. Chapter 4 describes the fault tolerant techniques implemented in this work to detect transierrt fairlts in processors, from which two are known software-based and three are new lybrid techniques. Chapter 5 presents experimental fault injection campaigns for the implemented fairlt tolerarrt techniques. Chapter 6 presents the configuration bitstream fairlt injection campaign and results. Chapter 7 presents radiation experiments on some of the proposed techniques. Chapter 8 describes future work and concludes the book. 

Although the effect of faults is increasing, the rate is not yet sufficient to test fault tolerant techniques at ground level. In order to do so, fault emulation and testing is necessary. In this Section, we will go over a few options to do so, such a software fault injection by simulation, fault injection in the FPGA s memory configuration bitstream and irradiation experiments. 

Fault tolerance techniques aiming to detect transient effects can be mainly divided in three broad categories (1) software-based techniques, (2) hardware-based techniques and (3) l brid techniques. Fault tolerance techniques can be applied at different levels of implementation, starting from the software level down to the architecture description level, the logical and transistor level, until the layout level. In this book, we will focus on hybrid techniques applied at software level. 

---