Fault trees, Software Hazard Analysis

Fault trees are commonly used in safety critical industries such as aerospace. Their power is in being able to communicate complex failures in a simple graphical format which is relatively easy to learn. They can be applied to either potential failures or retrospectively in investigating actual failures. FTA has subtle limitations however especially when one needs to systematically identify aU possible causes of a particular hazard - for this, an alternative technique needs to supplement the analysis. Fault trees are also notoriously difficult to apply to complex software. 

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. 

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 ... 

A more careful comparison has also been made. JAXA (the Japanese Space Agency) and MIT engineers compared the use of STPA on a JAXA unmanned spacecraft (HTV) to transfer cargo to the International Space Station (ISS). Because human life is potentially involved (one hazard is collision with the International Space Station), rigorous NASA hazard analysis standards using fault trees and other analyses had been employed and reviewed by NASA. In an STPA analysis of the HTV used in an evaluation of the new technique for potential use at JAXA, all of the hazard causal factors identified by the fault tree analysis were identified also by STPA [88]. As with the BMDS comparison, additional causal factors were identified by STPA alone. These additional causal factors again involved those related to more sophisticated types of errors beyond simple component failures and those related to software and human errors. 

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... 

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. 

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. 

Now, efforts have been made to develop suitable software for various methods of plant (process) hazard analysis (PHA). There are a number of papers available where through suitable software it is possible not only to automate one PHA method but to integrate several automated PHA methods such as event tree/fault tree (Chapter V) with HAZOP or HAZOP with FMEA, which will be discussed in the next clause in this chapter. 

It has become quite popular to integrate timed Petri-Nets with software fault tree analysis. You can use the Petri-Net to describe the system architecture and then switch to software fault trees to describe the hazards in the system and the events that lead to that top event and keep switching back and forth to analyze the software safety of the system. 

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. 

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. 

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. 

---