Hardware and software faults

The view is therefore growing that we should try to design plants so that they are safe even if there is a fault in the software. This can be done by adding on independent safety systems, such as relief valves and hardwired trips and interlocks, or by designing inherently safer plants that remove the hazards instead of controlling them (see Chapter 21). 

Errors in written instructions are also systemic, but it is easy for the author to check them, and readers can understand what is meant even though they contain errors in spelling or grammar or are ambiguous. We know what is meant if we are told to save soap and waste paper. 

---

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. 

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. 

The computer system s hardware and software architecture should be such that the system operates in a predefined safe marmer after the occurrence of a limited number of hardware and software faults. Techniques such as the use of alternate data sources and redundant architectures should be considered. The limitations of these techniques and the associated procedures should be fully described in the computer system design and should be reflected in the manuals of plant operating procedures. 

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. 

A complete lEC 61508 assessment includes a FMEDA, a study of Prior Use and adds an assessment of all fault avoidance and fault control measures during hardware and software development as well as detail study of the testing, modification, user documentation and manufacturing processes. The objective of all this effort is to provide a high level of assurance that an instrument has sufficient quality and integrity for a safety instrumented system application. This is clearly more important for products containing software as many end users have the strong opinion that software is "bad... 

Virtual machines also serve as the unit of fault contaimnent. Hardware or software faults only affect the virtual machines that actually used the faulty resource. Disco also handles memory management issues that arise from non-uniform memory access by transparently doing page replication and migration. Again, changing commodity operating systems to do this would be more diffi-... 

Since software faults have a big Common Cause Failure (CCF) potential, it is sometimes imderstand to be a part of the hardware CCF of Central Processing Unit (CPU) or other programmable device. This approach makes a sense but it expects correlation between hardware and software which is probably very weak and hardly can dominate to the probability of software... 

To prevent the introduction of faults during the design and development of the SIS hardware and software, requirements for the avoidance and control of systematic faults (i.e. related in a deterministic way to a certain cause) are introduced. Techniques and measures are given in Part 2 Atmexes A and B. 

Software Fault Hazard Analysis Similar in concept and structure to the system hazard analysis (SHA), which is conducted on system hardware, the software fault hazard analysis will analyze and evaluate a computer software program to identify critical areas in the programming that may contribute to or directly cause a hazard risk. Such risks may be due to an undetected hardware failure or incorrect inputs into the operation of the system software. The software FHA will also attempt to uncover any probable errors that can possible develop in the software after system activation. 

Software System Hazard Analysis This type of analysis is conducted similar to a hardware system hazard analysis (SHA), analyzing software functional processing steps to determine whether they may have any particular hazardous effect on the system. The analysis utilizes a hazard-risk index to illustrate the severity of each potential failure. The main advantage to this method is in its ability to positively identify safety-critical hardware and software functions as well as consider the effect of the human element in system software operations. The results of the software SHA, which identifies single-point failures or errors within a system, can often be used to assist in the development of a software fault tree analysis or, to some degree, a system FMEA. However, as with the other various SWHA techniques briefly described above, this method is also time-consuming and costly to perform. 

A pragmatic method of addressing this issue is to undertake a HRA focused specifically on the basic human events identified by the system safety analyses and in particular from the system Fault Tree Analyses. For systems, which typically have a high degree of operator interaction, many basic FTA events will be identified as human interactions. Once each fault tree is modelled, predictive, quantitative failure data can be input at the bottom from Availability and Reliability data for all hardware and software base events. By subtracting these... 

Redundancy is applicable to both hardware and software. It can be implemented using identical or diverse devices. When assessing the integrity of an SIF, the potential for common-cause faults should be considered. Elimination or reduction of the common fault source is a very effective means to reduce the potential for failure. In addition, diverse redundancy can be employed to reduce the potential for common-cause faults. Some examples of common-cause faults were given in Annex G.7, such as ... 

The definition of software reliability is willingly similar to that of hardware reliability in order to compare and assess the reliability of systems composed of hardware and software components. One should note, however, that in some environments and for some applications such as scientific applications, time (and more precisely time between failures) is an irrelevant concept and should be replaced with a specified number of runs. The concept of software reliability is, for some, difficult to understand. For software engineers and developers, software has deterministic behavior, whereas hardware behavior is partly stochastic. Indeed, once a set of inputs to the software has been selected, once the computer and operating system with which the software will run is known, the software will either fail or execute correctly. However, our knowledge of the inputs selected, of the computer, of the operating system, and of the nature and position of the fault is uncertain. We can translate this uncertainty into probabUities, hence the notion of software reliability as a probability. 

Refer to lEC 61508-1, table 2 (for low demand mode operation) or table 3 (for continuous or high demand mode operation) to determine the safety integrity level (SIL). The SIL then guides the selection of the techniques used for the avoidance of systematic faults in both hardware and software, so that as the risk reduction increases, or the hazard rate decreases, there is a reduction in the likelihood that systematic failures (including those resulting from incorrect specification) will result in a hazard. 

Software life cycle Fig. IV/2.5.1-1B (both hardware and software life cycles are compared). In the hardware case it is basically a bathtub curve (comprising random fault, early life manufacturing, or design defect and wearout during the end of usual life— see Chapter VII). Software does not really wear out (like a hardware system) but it deteriorates, though not as a function of time but as a... 

Defects or faults in any component of the loop can develop into malfunctions. Faults are not always visible to the operator immediately, but may appear in such a way that they give rise to complete loop failure. In safety-critical applications, no failure can be tolerated [3]. Redundancies in hardware and software facilitate fault recovery. So, for increased dependability fault tolerant control (PTC) is an ideal solution. In critical controls it may be disastrous to tolerate any failure of control systems. In PTC the system continues to operate with single failure in components and/or subsystems. Also in cases of critical controls, FTC will make a controlled shutdown to a safe state in a critical situation. FTC systems use the help of redundancies in hardware and software, discussed earlier, and fault diagnostics and intelligent software to monitor health and behavior of components and function blocks and take remedial action. With these tools the faults are isolated and suitable... 

Traditional design based on multiple redundant instrumentation chaimels with a voting arrangement, as commonly used in analog applications, has benefits for the hardware of computer systems. However, this type of redundancy does not prevent a failure of the system due to common cause faults in hardware and software design that could lead to impairment of all redundant chaimels. 

Safety standards like the ISO 26262[8] or the D0178c[17] require a safety case to argue the absence of unreasonable risk for humans caused by the item to be developed. The safety concepts that describe the architectural decisions regarding the detection and the mitigation of faults are important elements of the safety case. Starting from a functional safety concept at very early stages of the system development, this fault propagation specification is further refined at lower abstraction levels, e.g. the hardware and software implementation level. If this safety specification and the functional requirements are refined to an acceptable level, the specification can be implemented in terms of hardware and... 

In a top-down approach the faults are t q)ically expected defects in functions selected by experts. If they are refined to a particular level it needs to be shown that the selected hardware and software component match the expectations. In a bottom-up approach, the potential malfunctions of a component can be found in the safety manual or identified by techniques like FMEA. 

---