Fault tree analysis software faults

Dugan, X, Sullivan, K., Coppit, D. (2000). Developing a low-cost high-quality software tool for dynamic fault-tree analysis. IEEE Trans, on Rel. 49-59( ), 49ff. 

Instrumentation and Control (I C) systems are very often subject of probabilistic examination either within separate structural reliability analysis or Probabilistic Safety Assessment of a whole technological complex (e.g. Nuclear Power Plant). Use of programmable components in the design of these systems represents a challenge and utilizes the methods, which have been developed for components with a different behaviour. The typical method used for above mentioned examination is Fault Tree Analysis (FTA) (Vesely et al., 1981). The way of software faults modelling within Fault Trees vary a lot between particular models and there is no generally accepted modelling technique. 

The fault tree analysis describes a hazardous top event and the basic event which maybe leads to such a top event in a top-down method. The methods are dev-ided in static fault tree analysis and dynamic fault tree analysis. The static fault tree analysis describes the system top event in static way. In further steps it is not possible to describe functional system redundancy with this static Fault Tree Analysis (FTA). Especially if cold and hot spares are integrated or if triggers are used, the static fault tree analysis is unsatisfying these requirements. Therefore it is more suitable to use the extended Dynamic Fault Tree Analysis. The DIFTree (Dynamic Innovative Fault Tree) software package could be a helpful tool for the system development... 

The recommended techniques for preliminary hazard analysis are energy trace and barrier analysis (ETBA) and failure modes and effects analysis (FMEA). Recommended techniques for system and subsystem hazard analyses are FMEA, fault tree analysis (FTA), common cause analysis, sneak circuit analysis (for electrical, electronic, and some hydraulic or pneumatic circuits) and, of course, software hazard analysis for software. 

Based on the results of the PHA, recommendations made by 30% review boards, and guidance provided in the system safety program plan, detailed hazard analyses are made of specified (critical) subsystems. The techniques for these SSHAs are as outlined in the system safety program plan or as selected by the SSWG. Failure modes and effects analysis (FMEA) and/or fault tree analysis (FTA) are generally the techniques of choice. Software hazard analysis, common cause analysis, and/or sneak circuit analysis may also be appropriate. 

Unfortunately, the state of the art in software hazard analysis appears to be woefully lagging. Even though traditional hazard analysis techniques like fault tree analysis and tailored versions of operating hazard analysis may be applied to the evaluation of software, validated, specific methods of software hazard analysis appear lacking. 

Much of the functional safety practitioner s work involves random hardware failure modes and failure rates as a way of providing quantitative information to support claims that a SIL specification has been met. This is accompanied by rehabihty engineering calculations, as described in detail in lEC 61508. Standard software packages have eased the calculation burden, particularly with fault tree analysis and probabihty of failure estimates. 

Fault Tree Analysis (FTA) is a well known and widely used safety tool, implementing a deductive, top down approach. It starts with a top level hazard, which has to be known in advance and "works the way down" through all causal factors of this hazard, combined with Boolean Logic (mainly AND and OR gates). It can consider hardware, software and human errors and identifies both single and multiple points of failure. Both a quantitative and qualitative analysis is possible. 

Fault Tree Analysis Module of ITEM Tool Kit (Item Software [USA] Inc.) SAPHIRE (formerly IRRAS, U.S. Nuclear Regulatory Conunission) Probabilistic Risk Assessment Workstation (Electric Power Research... 

There are numerous software safety tools on the market, some quite good. And you can even take some of our current tools and use them for analyzing software systems. The most common ones are software hazard analysis, software fault tree analysis, and software FMECA. These are good starts, but insufficient to do the job completely. However, before you can attack the problem of software safety, a few facts should be stated first ... 

Chapters 5 through 9 describe the different safety analysis tools available. Hazard Analysis, H AZOF, What-If, Fault Tree Analysis, Failure Modes, and Effects Analysis, Human Factors, Software Safety, and other safety tools are described with realistic worked examples. The chapters detail how to use them, give examples, describe common mistakes in using them, and also provide best practices and tips of how to apply them judiciously. 

HAZOP and wAat-iJ/safety checklists, two of the most common safety methods in the chemical industry, are explained. Sample process problems, which engineers face every day at work, are shown. Other safety tools, such as fault tree analysis, failure modes and effects analysis, human factors safety analysis, and software safety, are explained. Examples of the use of these tools are also presented. 

Fault Tree Analysis (FTA) is a well known and effective method for analyzing hardware systems 1-3. This paper describes a possible use of FTA in a software embedded system for temperature control. The analysis is first applied to the hardware and software systems but concentrates on the software section afterwards, two critical events were detected by FTA and steps were taken to overcome them. Although this work describes a specific situation it can be applied to many control systems. 

Fault tree analysis has not to consider all possible failures, only these which lead to the top event (Modarres, 2006). The output is finally depicted in a directed tree diagram. The factors in the tree diagram can be hardware failures, software failures, human errors or pertinent events (lEC/ISO 31010,2009). 

EPRI (2005). Fault Tree Analysis System. CAFTA 5.2 software. Data Systems Solutions/Electric Power Research Institute, Palo Alto, CA, USA. 

For this reason, more and more standards and guidelines for the development of safety-relevant systems demand safety analyses for the system and the software as part of a rigorous development process. Examples of this are lEC 61508 [1], lEC/TR 80002 [2], MISRA safety analysis guidelines [3], and ISO 26262 [4]. ISO 26262 is a committee draft for the development of road vehicles. It defines requirements on the development of electrical and electronic systems and particularly requirements on the development of software, which include qualitative safety analysis for software architecture as well as for software unit design. However performing a qualitative safety analysis technique such as failure mode and effect analysis (FMEA) or fault tree analysis (FTA) on software architectmal design is a complex task. One reason for this is that safety analyses do not fit well with software architectural design and do not... 

We can then state that a general tactic for mitigating hazards is to use fault tree analysis to show that their maximum probability of occurrence does not exceed that established for their severity level, and that the integrity level of the system software is at least that required for the given severity level. We can state this as a generalized axiom (with variables) as follows. 

Here, H2 fta doc is documentation that describes the fault tree analysis performed and justifies the claim that this estabUshes the given probability similarly, H2 integrity doc is documentation that justifies the claim that the software satisfies the requirements for integrity level 5 (in some scale). 

A number of analysis techniques such as fault tree analysis, real-time logic and timed petri-nets are being used in limited contexts. However, system wide techniques that allow consideration of the control system rather than just of the software in isolation require further development. 

A wide number of commercial and academic tools for static fault tree analysis are available. Some are merely drawing tools, while others provide probabilistic analysis, like the popular FaultTree-f package from Isograph [14]. Dynamic FTA is supported by tools like Windchill [18], NASA s Galileo/ASSAP software [11], and the simulation tool DFTSim [10]. A first implementation of DFT analysis using I/0-IMCs was realized in Coral [7], the predecessor of DFTCalc. 

Numerical probabilities should not be indicated for software errors in fault trees. Any software analysis in an FTA should be expressed in terms of DALs to protect against software errors. The analysis should be evaluated for compliance on a purely qualitative basis. When the probability of an undesired event needs to be calculated, SAE ARP4761 (para 4.1.2) advises as follows ... 

Used in conjunction with ISA-TR84.00.04-2005 Part 1, the example set forth in this technical report is provided to illustrate howto apply ANSI/ISA-84.00.01-2004 Parts 1-3 (lEC 61511 Mod). It is intended to demonstrate one method to meet the requirements of the standards. The reader should be aware that ANSI/ISA-84.00.01-2004 Parts 1-3 (lEC 61511 Mod) is performance based, and that many approaches can be used to achieve compliance. Some of the methods applied in this example include what-if and HAZOP techniques for hazard and risk analysis, LOPA for allocation of safety functions to protection layers, fault tree analysis for SIL verification, and ladder logic to document the application software requirements. Other techniques and tools could be utilized at each of these steps in the safety lifecycle to meet the requirements of the standards. 

The SIS logic solver has a claim limit of SIL 3, which addresses failures of hardware, architectural requirements (fault tolerance) and the embedded software. Note that systematic failures of application software were not addressed in the certification of the logic solver. Systematic logic solver application software failure issues were addressed by shadowing the logic in the BPCS (see bubble diagrams Figures 4, 6, and 8). The BPCS was used to reduce the systematic failures of SIS application software however, the contribution of the BPCS hardware to the PFD has not been included in the fault tree analysis for each SIF. 

---