Fault tree analysis description

Fault tree analysis is based on a graphical, logical description of the failure mechanisms of a system. Before construction of a fault tree can begin, a specific definition of the top event is required for example the release of propylene from a refrigeration system. A detailed understanding of the operation of the system, its component parts, and the role of operators and possible human errors is required. Refer to Guidelines for Hazard Evaluation (CCPS, 1992) and Guidelines for Chemical Process Quantitative Risk Assessment (CCPS, 2000). 

Module 3 (Description) a dozen employees already have been trained in qualitative fault tree analysis by an external training institute. 

Analytical trees can be used in a variety of ways in the system safety effort. The most common application of analytical trees in current system safety programs is probably the use of fault trees for fault tree analysis (FTA). However, analytical trees can also be used as planning tools, project description documents, status charts, and feeder documents for several hazard analysis techniques (including fault tree analysis). Analytical trees can be multipurpose, life cycle documents and represent one of the most useful tools available to managers, engineers, and safety professionals. 

The first step in performing a fault tree analysis is to collect the appropriate project description documents, existing hazard analyses, and guidance documents and carefully review them to determine the limits, scope, and ground rules for the FTA.This review includes defining the system to be analyzed, the depth or indenture levels to be included in the effort, and, of course, the nature of the undesired event or failure to be studied. 

Shaeiwitz, J. A., Lapp, S. A., Powers, G. J. (1977). Fault tree analysis of sequential systems. Industrial Engineering and Chemical Process Description Development 16 (4), 529. 

Reliability block diagrams are, similar as the fault tree analysis, are considered in ISO 26262 as example for deductive analysis. The blocks can be logically put into relations through Boolean algebra. If the blocks are quantified, the relations can also be described mathematically, whereas such descriptions are used as a foundation for formal description models. The simplest quantitative method is a simple summing up of the failure rates of the individual components of a function. The method is also called Part Count Method , which simply based on an addition of failure rates of electric parts. 

In this section we give a brief description of three commonly used methods of safety analysis Fault Tree Analysis, Event Tree Analysis and Failure Mode and Effect Analysis. Those are the methods which, in our opinion, can mostly benefit fix)m being extended with more formal semantics. We do not cover here Hazard and Operability Study (HAZOP) which is a "structured brainstorm" - type method with the main stress on managerial aspects. However, as HAZOP may make use of FTA, ETA and/or FMEA, it can also benefit firom the proposed approach. 

Fault Tree Analysis (FTA) is widely used in the context of safety applications [3,4]. The assumption behind the feult tree approach is that the feilure space is easier to identify and describe than the success space (it is easier to agree on what is a failure than on what is a success). Also, the ure space is less structured - less failure classes or types are worth to be considered than it is a case fix>m the success standpoint. It is also easier to sacrifice a part of the success space and to include it to the feilure space e.g. in order to make the description of the failure space simpler. Because the failure space is less structured, there are usually few system failure modes which determine the number of fimlt trees to be developed (as opposed to many success modes which would have to be considered). 

The bulk of the information in the report is included in a 317-page appendix that contains systems descriptions, station blackout fault trees, diesel generator historical data, and diesel generator common cause failure analysis results for 18 different nuclear power plants. Tables and graphs are well organized and present data correlated to each plant studied. The study also contains conclusions and recommendations for improving reliability. 

As can be noted in Figure 21.7.2, steam and ethane are mixed before entering tlie reactor tubes where pyrolysis reactions take place. All feed and product lines must be equipped wiUi appropriate control devices to ensure safe operation. The FTA flow cliart breaks down a TOP event (see description of fault tree in Unit 11) into all possible basic causes. Altliougli, tliis metliod is more structured tlian a PHA, it addresses only one individual event at a time. To use an FTA for a complete liazard analysis, all possible TOP events must be identified and investigated this would be extremely time consuming and perhaps unnecessaiy in a preliminary design. 

Such a task description invites task analysis, which would lead naturally to human reliability analysis (HRA). Indeed, perhaps the earliest work in this field applied HRA techniques to construct fault trees for aircraft structural inspection (Lock and Strutt 1985). The HRA tradition lists task steps, such as expanded versions of the generic functions above, lists possible errors for each step, then compiles performance shaping factors for each error. Such an approach was tried early in the FAA s human factors initiative (Drury et al. 1990) but was ultimately seen as difficult to use because of the sheer number of possible errors and PSFs. It is occasionally revised, such as in the current FRANCIE project (Haney 1999), using a much expanded framework that incorporates inspection as one of a number of possible maintenance tasks. Other attempts have been made to apply some of the richer human error models (e.g.. Reason 1990 Hollnagel 1997 Rouse 1985) to inspection activities (La-toreUa and Drury 1992 Prabhu and Drury 1992 Latorella and Prabhu 2000) to inspection tasks. These have given a broader understanding of the possible errors but have not helped better define the PoD curve needed to ensure continuing airworthiness of the civil air fleet. 

The events and gates each have a Description and a Label associated with them. The Description is intended for use by persons reading the results of the analysis. It provides detail as to the purpose and function of that event or gate. The label is a unique identifier used by the fault tree software. Generally, the label will be composed of a letter and a number. The letter G indicates a gate the letter E an event (any type). 

Suitable mathematical expressions representing the fault tree entries may be developed using Boolean algebra. When more than one event on a chart can contribute to the same effect, the chart and the Boolean expression indicate whether the input events must all act in combination (and relationship) to produce the effect, or whether they may act singly or relationship). The probability of failure of each component or of the occurrence of each condition or listed event is then determined. These probabilities may be from actual failure rates vendors test data comparison with similar equipment, events, or conditions or experimental data obtained specifically for the system. Hie probabilities are then entered into the simplified Boolean expressions. The probability of occurrence of the undesirable event being investigated may then be determined by calculation. When an FTA is used for qualitative analysis, care is required in the description of each event to be sure it can be fitted with a suitable probability. 

General Fault tree description and structure, objectives, applications, and combinations with other reliability analysis techniques, for example, FTA-FMEA, FTA-ETA, etc. 

The work described in this paper is preliminary. The most relevant related work seems to be the attack tree approach [5]. This approach proposes to use the classical fault tree notation in order to study security. As in our work, the attack tree contains basic events representing elementary threats. In some variants of the notation, the tree also include a description of the effect security barriers. In [7] the authors propose to use an extension of the fault-tree notation in order to deal with dynamic aspects of the threat propagation. Both of the previous works tend to focus on a quantitative assessment of security requirements whereas we have been working on qualitative requirements because this would be more consistent with the Airworthiness Safety process. Another relevant approach was proposed by the CORAS project [6], this notation aims at assisting the security risk analysis. A difference between this approach and our work is that the CORAS can be applied before the security architecture is designed whereas our approach is applied once the security architecture is established. 

---