Fault Tree Analysis

FAULT TREE ANALYSIS 1. Introduction FTA is a deductive, failure-based approach. As a deductive approach, FTA starts with an undesired event, such as failure of a main engine, and then determines (deduces) its causes using a systematic, backward-stepping process. In determining the causes, a fault tree (FT) is constructed as a logical illustration of the events and their relationships that are necessary and sufficient to result in the undesired event, or top event. The symbols used in a FT indicate the type of events and type of relationships that are involved.

The FT is a qualitative model that provides extremely useful information on the causes of the undesired event. The FT can also be quantified to provide useful information on the probability of the top event occurring and the importance of all the causes and events modelled in the FT. This handbook leads the reader through FTA. Particular details can be skipped if the reader desires only an overview of FTA and instead wants to focus on its uses to assist decision-making. In addition to FTA, inductive approaches are also used in safety analysis and in risk and reliability analysis.

In contrast to the deductive approach used in FTA, inductive approaches are forward-stepping approaches that begin with a basic cause or initiating event and then investigate (induce) the end effects. Both FTA and inductive approaches are failure-based. The advantages of failure-based approaches are also discussed. A FT can be transformed into its logical complement; a success tree (ST) that shows the specific ways the undesired event can be prevented from occurring. The ST provides conditions that, if assured, guarantee that the undesired event will not occur.

The ST is a valuable tool that provides equivalent information to the fault tree, but from a success viewpoint. Techniques for transforming the FT to its ST are described along with uses of the ST. The uses of FTA to assist decision-making are described in this AFTH. FTA provides critical information that can be used to prioritize the importance of the contributors to the undesired event. The contributor importance provided by FTA vividly shows the causes that are dominant and that should be the focus of any safety or reliability activity.

Mo re formal riskbenefit approaches can also be used to optimally allocate resources to minimize both resources expenditures and the occurrence probability of the undesired event. These risk approaches are useful for allocating resource expenditures, such as safety upgrades to complex systems like the Space Shuttle. FTA can be applied to both an existing system and to a system that is being designed. When it is applied to a system being designed for which specific data do not exist, FTA can provide an estimate of the failure probability and the important contributors using generic data to bracket the design components or concepts.

FTA can also be used as an important element in the development of a performance-based design. When applied to an existing system, FTA can be used to identify weaknesses and to evaluate possible upgrades. It can also be used to monitor and predict behaviour. Furthermore, FTA can be used to diagnose causes and potential corrective measures for an observed system failure. The approaches and tools to obtain this information and the applications of this information in decision-making are important topics of the AFTH.

The second part of the AFTH contains examples of the application of FTA in studies that have been previously performed. The focus is on aerospace applications. The examples include the rupture of a pressure tank (a classic FTA example), failure to initiate and terminate thrust in a monopropellant propulsion system, failure of a redundant container seal (design analysis), and a dynamic FT analysis of a mission avionics system. GRAPH BASED METHODS 2 FAULT TREE ANALYSIS 1. The Fault Tree Approach FTA can be simply described as an analytical technique, whereby an undesired state of the system is specified (usually a stat e that is critical from a safety or reliability standpoint), and the system is then analyzed in the context of its environment and operation to find all realistic ways in which the undesired event (top event) can occur. The fault tree itself is a graphic model of the various parallel and sequential combinations of faults that will result in the occurrence of the predefined undesired event.

The faults can be events that are associated with component hardware failures, human errors, software errors, or any other pertinent events which can lead to the undesired event. A fault tree thus depicts the logical interrelationships of basic events that lead to the undesired event, the top event of the fault tree. It is important to understand that a fault tree is not a model of all possible system failures or all possible causes for system failure. A fault tree is tailored to its top event that corresponds to some particular system failure mode, and the fault tree thus includes only those faults that contribute to this top event.

Moreover, these faults are no t exhaustive—they cover only the faults that are assessed to be realistic by the analyst. It is also important to point out that a fault tree is not in itself a quantitative model. It is a qualitative model that can be evaluated quantitatively and often is. This qualitative aspect, of course, is true of virtually all varieties of system models. The fact that a fault tree is a particularly convenient model to quantify does not change the qualitative nature of the model itself. Intrinsic to a fault tree is the concept that an outcome is a binary event i. e. , to either success or failure.

A fault tree is composed of a complex of entities known as “gates” that serve to permit or inhibit the passage of fault logic up the tree. The gates show the relationships of events needed for the occurrence of a “higher” event. The “higher” event is the output of the gate; Chapter “Lower” events are the “inputs” to the gate. The gate symbol denotes the type of relationship of the input events required for the output event. Figure 1- 1 shows a simple fault tree. FTA Logic Symbols GRAPH BASED METHODS 3 FAULT TREE ANALYSIS • • • • • • • • • • • • OR Gate (a): used when output event occurs when one or more input events occur.

AND Gate (b): used when output event occurs when all input events occur. Priority AND Gate (c): like AND gate but input events occur in a specified order. Exclusive OR Gate (d): used when output occurs when one and only one of the input events occur. Delay Gate (e): used when output event occurs after a specified time delay. Inhibit Gate (f): used when output event occurs based on a conditional event occurring. M-out-of-N Gate (g): used when output event occurs based on a m out of n input events occurring. Resultant Event (h): used to represent an event resulting from some combination of preceding fault events.

Basic Fault Event (i): used to represent failure of component or subsystem. Incomplete Event (j): used to represent a fault event whose cause has not yet been determined. Conditional Event (k): used to represent the condition associated with an Inhibit gate. Trigger or Switch Event (l): used to examine special cases by forcing events to occur, or by forcing them not to occur. GRAPH BASED METHODS 4 FAULT TREE ANALYSIS 2 Fault Tree Analysis-Basic Concepts 2. 1 What is FTA Fault tree diagrams represent the logical relationship between sub-system and component failures and how they combine to cause system failures.

The TOP event of a fault tree represents a system event of interest and is connected by logical gates to component failures known as basic events. After creating the diagram, failure and repair data is assigned to the system components. The analysis is then performed, to calculate reliability and availability parameters for the system and identify critical components. 2. 2 When to use FTA • • • • Use it when the effect of a failure is known, to find how this might be caused by combinations of other failures.

Use it when designing a solution, to identify ways it may fail and consequently find ways of making the solution more robust. Use to identify risks in a system, and consequently identify risk reduction measures. Use it to find failures which can cause the failure of all parts of a ‘fault-tolerant’ system. Fig. 1. Fault Tree Analysis in problem solving 2. 3 How to understand FTA The failure of an item in a system is often caused by the failure of other items, for example where a vehicle’s braking failure is caused by water in the brake cylinders, which may in turn be caused by failure of the cylinder seals.

Fault Tree Analysis, or FTA, provides a method of breaking down these chains of failures, with a key addition for identifying combinations of faults that cause other faults. Combinations of faults come in two main types: (a) where several items must fail together to GRAPH BASED METHODS 5 FAULT TREE ANALYSIS cause another item to fail (an ‘and’ combination), and (b) where only one of a number of possible faults need happen to cause another item to fail (an ‘or” combination). The FTA diagram shows faults as a hierarchy, with two other symbols to show the ‘and’ and ‘or’ combinations, as in Fig. . These are called gates, as they prevent the failure event above them occurring unless their specific conditions are met. Fig. 1. Logical And and Or in Fault Tree Analysis A third type of gate is called an inhibit gate, as it prevents a failure from happening unless a specific condition is met (it is effectively an ‘and’ of the failure and some other conditions). In an FTA diagram, there are two main types of failure event box: combination events, which are the result of other events, and basic events, which are the start points for the chains of events above them.

Basic events may be real root events or may simply not be developed further on this diagram. These and other symbols that may be used in FTA diagrams are shown in the table below. GRAPH BASED METHODS 6 FAULT TREE ANALYSIS Table 1. FTA symbols Symbol Name Meaning And gate Event above happens only if all events below happen. Or gate Event above happens if one or more of events below are met. Inhibit gate Event above happens if event below happens and conditions described in oval happen. Combination gate Event that results from combination of events passing through gate below it. Basic event Event that does not have any contributory events.

Undeveloped basic event Event that does have contributory events, but which are not shown. Remote basic event Event that does have contributory events, but which are shown in another diagram. Transferred event A link to another diagram or to another part of the same diagram. Switch Used to include or exclude other parts of the diagram which may or may not apply in specific situations. GRAPH BASED METHODS 7 FAULT TREE ANALYSIS A common way of reducing the chance of failure of a system is to build redundancy into it, for example by having two sets of critical components running in parallel.

It is possible, however, for failures to occur, which results in the fault tolerance of such systems to be negated as one failure causes all redundant parts to effectively not work. This is called common mode failure. For example, a motor system driven by two separate engines may fail when a common fuel line ruptures. FTA is a useful tool for discovering such failures, as it looks back down the chain of events to find possible failures in all areas. Fig. 2. Selector system 2. 4 Rules of FTA 1. Identify the failure effect to be analyzed. Typically this will be a critical effect that must be eliminated or reduced.

It should be a complex failure, which may be caused by combinations of other failures, rather than a low-level failure with simple causes. This may be found using other tools, such as Failure Mode and Effects Analysis. 2. Write the failure effect in a box at the top-center of the diagram area. Make this a clear phrase that describes the effect as precisely as possible, describing not only what the failure is, but how it occurs. For example, ‘carburetor fails when engine reaches full temperature. 3. List failures that may directly contribute to the failure described in step 2.

For example, ‘fuel delivery failure’, ‘air intake blockage’, etc. When identifying ways in which an item may fail, try looking at the problem from different angles. For example: • • • • • • Excessive stresses and strains. Potential misuse and abuse. Environmental extremes. Natural variation in the system. Failure of dependent systems. Failure of related processes. GRAPH BASED METHODS 8 FAULT TREE ANALYSIS 4. Divide the list of failures in the list derived in step 3 into separate groups, where all members of each group must occur together for the failure in step 2 to occur.

For example, ‘dirt in fuel’ and ‘partially blocked jet’. There are three possible outcomes from this: • There is one group, as all failures identified in step 3 must occur together for the failure from step 2 to happen. This is an ‘and’ group, so draw an ‘and’ gate under the failure from step 2 and connect this to boxes underneath containing the failures from step 3, as in (a) in the illustration below. No such groups can be found as any one failure from step 3 can result in the failure effect from step 2.

This is an ‘or’ group, so draw an ‘or’ gate under the failure from step 2 and connect this to boxes underneath containing the failures from step 3, as shown in (b) in the illustration below. There are several groups. This is a complex grouping, so draw each group with more than one member under an ‘and’ gate and connect these gates to an ‘or’ gate under the failure effect from step 2, as shown in (c) in the illustration below. • • Fig. 1. Grouping failures under gates It may also be worth checking whether any ‘and’ group actually constitutes an independent failure effect.

This can be shown with an additional failure box above the ‘and’ gate. There may also be additional conditions for a failure or group of failures to occur. For example, environmental or procedural conditions such as ‘ambient temperature >50° C’ or ‘engine idling’. These may be shown with an inhibit gate, as in Fig. 2. GRAPH BASED METHODS 9 FAULT TREE ANALYSIS Fig. 2. Adding inhibit gate 5. For each failure which has no connections below it, decide whether or not to develop this further by finding other failures which may contribute to it. If the failure is not to be developed on this diagram, draw it in an appropriate box.

Thus, if the failure cannot reasonably be developed further, put it in a circle; if it could be developed, but is not appropriate to do this here, then use a diamond-shaped box. If the failure is to be developed, repeat step 3 to find contributory failures and appropriate gates. 6. When the diagram is complete, examine it to draw conclusions and plan for appropriate actions. For example, acting to reduce risks such as critical failures and safety hazards GRAPH BASED METHODS 10 FAULT TREE ANALYSIS 3 A case study As an example for the application of formal FTA, we present an analysis of a radio-based railroad crossing.

The case study was done using the interactive theorem KIV [2] and the proof effort was about 1. 5 person months. This case study is the reference case study of the German research councils (DFG) priority program 1064. This program aims at bringing together field-tested engineering techniques with modern methods of the domain of software engineering. The German railway organization, Deutsche Bahn, prepares a novel technique to control railroad crossings: decentralized, radio-based railroad crossing control. This technique aims at medium speed routes, i. e. routes with maximum speed of 160 km/h. Fig. Radio Based Rail road crossing The main difference between this technology and the traditional control of rail-road crossings is that signals and sensors on the route are replaced by radio communication and software computations in the train and railroad crossing (see Fig. 4). This offers cheaper and more flexible solutions, but also shifts safety critical functionality from hardware to software. Instead of detecting an approaching train by a sensor, sending this information to a central office which closes the railroad crossing, the train continuously computes the position where it has to send a signal to secure the level crossing.

This effectively saves money (not so much equipment on the track is needed) and removes the central control office (this is a single point of failure for all trains in the region). To calculate the activation point the train uses data about its position, maximum deceleration and the position of the crossing. Therefore the train has to know the position of the railroad crossing, the time needed to secure the railroad crossing, and its current speed and position. The first two items are memorized in a data store and the last two items are measured by an odometer. For safety reasons a safety margin is added to the activation distance.

This allows compensating some deviations in the odometer. The system works as follows: The train continuously computes its position. When it approaches a crossing, it broadcasts a ‘secure’-request to the crossing. When the railroad crossing receives the command ‘secure’, it switches on the traffic lights, first the ‘yellow’ light, then the ‘red’ light, and finally closes the barriers. When they are closed, the railroad is ‘secured’ for a certain period of time. The ‘stop’ signal on the train route, indicating an insecure crossing, is removed and substituted by computation and communication.

Shortly before the train reaches the ‘latest braking point’ (latest point, where it is possible for the train to stop in front of the crossing), it requests the status of the railroad crossing. When the crossing is secured, it responds with a ‘release’ signal which indicates, that the train may pass the crossing. Otherwise this has to brake and stop before the crossing. The railroad crossing periodically performs self-diagnosis and automatically informs the central office about defects and problems. The central office is also GRAPH BASED METHODS 11 FAULT TREE ANALYSIS responsible for repair and provides route descriptions for trains.

These descriptions indicate the positions of railroad crossings and maximum speed on the route. The safety goal of the system is clear: it must never happen that the train passes a crossing which is not secured. A well designed control system must assure this property at least as long as no component failures occur. The corresponding hazard is “a train passes the crossing and the crossing is not secured”. This is the only hazard which we will consider in this case study. 3. 1 The formal model In the following part a brief description of the state chart model of this system is given.

Note, that the model not only includes intended behaviour but failure modes as well. This is necessary for all types of formal safety analysis. Details on how such models may be derived from functional models of the intended behaviour maybe found in [12] and [11]. The model of the radio-based railroad crossing is split in three parallel charts. One chart models the crossing another one models the communication and a third models the train. These three charts are explained below. 3. 1. 1 Model of the crossing The state chart in figure 5shows the model of the crossing which is reacting to the signals sent by the train.

Initially the crossing is in state Opened, which means the bars are open. When the crossing receives the signal Close_Request_Rcv from the train, it goes into state Closing. This activates a timer called Closing Count which simulates the time needed for turning on the light signals at the crossing and the closing of the bars. This takes the time (T_Max_Closing). After the expiration of this time the crossing is closed (state Closed). Another timer Closed Count is started to assure that the bars are not closed too long. This is a standard procedure in railroad organization.

The crossing reopens if either the train passes the danger spot (Pos > DS) or the timer reached T_Max_Closed. The crossing also opens its bars if a fault in the sensor, which detects the passing of the train, occurs (Unwanted_Open). The response of the crossing on the train’s status request is modelled by a static reaction (SR_CROSSING). If it receives a status request (Status_Request_Rcv), a release message (Release_Snd) will be sent if the bars are closed (intended behavior) or if there is a faulty detection at the sensor for the bars ‘position (ErrorClosed). Fig. Model of the crossing Chart. GRAPH BASED METHODS 12 FAULT TREE ANALYSIS 3. 1. 2 Model of the train The model of the train is divided into two parts: one for modelling the physics of the train and one for modelling the controller logic. From a theoretical point of view, it is advisable to model the control and the physics of the train separately. But in this example, the physical model consists only of some static reactions (seefig. 3). These static reactions basically state, that the position of the train updates according to the speed and that the speed updates according to the acceleration.

So for an easier representation these two parts have been combined. The train control supervises the position of the train, issues closing requests to the crossing and ultimately decides, if an emergency stop is necessary or not. The train control is implemented in software on-board the train. The formal model is given in figure3. Starting from its initial state Idle the chart goes into state Wfc (’wait for close’), when the train approaches the crossing and the control sends a close request (CloseRequestSnd) to the crossing.

The point when this signal assent is continuously calculated depending on the actual speed, estimated closing and communication time, and the maximum deceleration of the train. This is modelled in the predicate Close (Pos,V,AccMAX,DS). Sometime later, the train reaches another virtual control point which is also calculated continuously and modelled in predicate Request (Pos,V,AccMAX,DS). This is the position when the train sends a status request (StatusRequestSnd) to the crossing. The control is then in stateWfs (’wait for status answer’).

If the train receives a release signal within the next Wfs_Counttime units the controller will go into state Go and the train may pass the crossing. Otherwise an emergency stop must be issued. In this case the brakes are activated (A=AccMAX) and the controller goes into state Brake. A failure of the brakes is also modelled. If the brakes fail, the controller will still go into state Brake, but there will be no real deceleration. The two states Brake and Go are final states of the chart, so they won’t be left anymore. Fig. 3 Model of Train Control Chart GRAPH BASED METHODS 13 FAULT TREE ANALYSIS . 1. 3 Model of the communication The communication is modelled by three static reactions, seefigure4. These static reactions represent the function and dysfunction of the communication. The functional communication relays all incoming messages, e. g. (SR_COMM1) the close request of the train (Close_Request_Snd) is forwarded to the crossing as Close_Request_Rcv. If the communication fails (Failure_Comm) then no messages will reach their re-ceiver. The other two static reactions represent the status request (SR_COMM2) and the release message (SRCOMM3). Fig. 4 Model of the Communication Chart 3. Fault Tree Analysis This model is now analyzed with formal FTA (see Sect. 2). The interesting hazard is a situation, where a train passes the crossing, while the bars are not closed. We will call this hazard ”collision”. The fault tree for this hazard is shown in figure5. The top event of the fault tree (collision) may have two different causes. One is that the train passes the crossing, while the bars are not closed, although no release signal has been sent. The other is a situation where the train passes the crossing, while the bars are not closed, but a release signal has been sent.

The first cause corresponds to misbehaviour of the train and the second to one of the crossing. The “or” relationship is modelled by a decomposition gate. These two different situations must be further analyzed. The left node — train passes the crossing (while the crossings not closed) although no release signal has been received, is caused by a failure in the train’s behaviour, so no information about the crossing is needed. This is phrased by a D-INHIBIT-gate. The right node, train passing the not closed crossing and a release signal has been sent, can be caused by two different situations.

One is given by the train approaching the not closed crossing and the release signal is being sent (while the crossing is not closed). The reason for this can be a faulting the position sensors of the bars2. The other possible reason is, that the bars open after a release signal has been sent but before the train has passed the crossing. The reason for this can be either a timeout or a faulty request to open the bars. The other cause is given by the train passing the opening/opened crossing and the signal has been sent sometime before. As an example, the formalization of the first three nodes is shown in table1.

The resulting proof obligation is then constructed by inserting these formal descriptions of the nodes into the D-OR-gate formula of Fig. 1. The other fault tree gates are handled analogously. The fault tree above has been proven complete. This means that for every gate the corresponding proof obligation has been shown. The conclusion is, that – for this example – all minimal cut sets are single-point-of-failures. So there is no redundancy in the system. On the other hand the fault tree also shows that if these failures are prevented then the hazard will not occur. In GRAPH BASED METHODS 4 FAULT TREE ANALYSIS other words if nothing fails, the system will work as intended or even shorter: the system is functionally correct. Fig. 5 Fault tree for Hazard Collusion Table. 1 Formalisation of Fault Tree nodes GRAPH BASED METHODS 15 FAULT TREE ANALYSIS Advantages • • • • • • • • • • • • • • • • Easy to read and understand Can handle multiple failures or combinations of failures Exposes the needs for control or protective actions to diminish the risk Quickly exposes critical paths. The results can provide either qualitative or quantitative data for the risk assessment process.

FTA is a root cause analysis tool Models fault combinations and relationships Can model more undesired states than just “Failed” state Can approximate event dependencies Can account for repair Can handle very, very large models FTA has a structured process making it difficult to leave root causes out Easy to modify as design changes Easy to validate Excellent for documentation Produces Importance measures which identify critical items Disadvantages • • • • • Though fault trees may reveal human error, they do little to determine the underlying cause.

Fault trees require detailed knowledge of the design, construction and operation of the system. Not suitable for assessing normal operations Fault trees may become very large and complex. Significant training and experience is necessary to use this technique properly. Once the technique has been mastered, application stays time-consuming however commercial software is available. Is not practical on systems with large numbers of safety critical failures. • GRAPH BASED METHODS 16 FAULT TREE ANALYSIS 5 Conclusions -Formalizing FTA nodes is difficult.

Even for simple systems it can be very hard to correctly formalize the nodes of the fault tree. This is because the informal understanding of a fault tree (decomposition of causes into components)is not enough for a formal description. This problem can be attenuated if all proof obligations are at the beginning validated with depthfirst-search. It is our experience that this additional effort is really worth the time, because formalizing nodes of a fault tree is very error-prone. -We showed the first verification of an infinite state system with FTA.

Our Experiences show, that formal FTA with interactive verification is a promising, but not an easy topic. Many problems arise from specification errors. These problems may be countered with good methodology. Compared to other formal safety analysis methods, formal FTA is the only one which has a human readable and understandable logic background structure and will thus be more easily accepted in industry than push-the-button techniques (like pure model checking). Conclusions Summary i. ii. iii. iv. v. vi. vii. viii. ix. x. xi. xii. xiii. xiv. xv.

Consideration Models Undesired Events Models Probability Parallel System Series System Parallel System Sequence Parallel System Full Monitor System Partial Monitor System Repair Latency Dependency Approx Large models Coverage Easy to follow model Easy to document process X X X X Approx Approx Approx Approx X X Approx X X X X Summary As you see, FTA is very simple. Don’t let its simplicity fool you, however. If you want to get fancy, you can play with probability statistics to try to get even more precise – determining the “chance” that a fault or cause could occur. Very precise calculations are possible.

But even if you do not get fancy, you will have taken a powerful step toward preventing problems in the first place, or resolving tough problems. Often the act of creating a fault tree generates excellent ideas and possible solutions where before there were none. FTA can be used by Technical Observation Post (TOP) teams, Problem Managers, Availability Managers, and even IT Service Continuity Management teams with a minimum GRAPH BASED METHODS 17 FAULT TREE ANALYSIS of training. The graphical nature of FTA makes it easy to understand and easy to maintain in the face of Changes.

All in all, FTA is a powerful tool. 5 Research Work and Programs Fault Tree Analysis Programs • • BRAVO (JBF Associates): The program supports creation and analysis of fault trees. Estimates reliability characteristics and importance’s for fault trees. CAFTA for Windows (SAIC): A comprehensive PC-based fault tree workstation with support for all phases of systems analysis. It includes full screen editor, multilevel reliability database, plotting, cut set generator and cut set results editor. Extensive syntax and logic checking, logical editing, supports macros, calculates unavailability rom failure rate and exposure times, user definable fields, truncates on cut set probability or size, allows user selectable gate transfers & page breaks. Program also supports sensitivity studies. CARA-Fault Tree (Sydvest Software): Software tool for construction and analysis of fault trees. With its intuitive graphical user interface, CARA-Fault Tree lets you create fault trees in a flash. A total of six system performance measures and six measures of component importance is available, along with enhanced report utilities. All in all, CARA-Fault Tree is the product of choice for supporting fault tree analysis.

CARE® FTA – Fault/Event Tree Analysis (http://www. bqr. com):The software handles Hardware/Software Fault and Event trees (no limit of functional levels, number of assemblies, faults or events. The FTA tree can be built-up from the project tree assemblies or components and/or from the functional FMECA tree andor from the RBD model tree. Different Gates options such as OR, AND, NOT, XOR, K-outof-N. FTA analyses common mode failures. There is a really simple on screen presentation of the tree using + and – to expand and collapse trees.

Only up and down scroll – no need to scroll right and left for large trees. It has Quick and accurate calculation of probability and rates for all events. Conditional effects probability may be given under OR gates. ETA-II (SAIC): It is an event fault tree analysis program. It allows for multiple branches at event tree nodes and multiple attributes to be assigned to each node. Expanded event names, branch labels, expected value calculations, probabilistic truncation, supports most plotters. EventTree (Item Software): Draws event tree diagrams and carries out cut set calculations and probabilistic analysis.

FaultTree+ (Isograph Inc): FaultTree+ provides CCF analysis, importance analysis, and uncertainty and sensitivity analysis facilities. The program allows users to construct a single project database containing generic data and event tables, fault trees with multiple TOP events, event trees originating from different initiating events, • • • • • GRAPH BASED METHODS 18 FAULT TREE ANALYSIS CCF tables and consequence tables. Fault and event tree pagination is automatically controlled by the program. Fault tree TOP events may be used to represent specific nodes in the event tree. Multiple branches are also handled to allow for partial failures.

FaultTree+ uses efficient minimal cut set generation algorithms to analyse large and complex fault and event trees. NOT logic may be included in the fault and event trees at any level and event success states retained in the analysis results as an option. • FaultTree+ for Windows (Item Software): Dramatic time savings over manual methods. Draws the tree automatically from simple gate inputs using the keyboard, graphics display and a mouse. Cut set analysis using Kinetic Tree method, sorted by order or probability. Quantitative analysis and a confidence evaluation. Fault tree gates or events can be linked to the event tree.

Fault Tree (Mitchell & Gothier): Construction and analysis of fault tree, automatic fault tree generation, library of standard symbols provided, modular tree construction, error traps, qualitative and quantitative analysis. Easy to use mouse and menus, handles large trees with hundreds of gates, cut set analysis, user controlled plot scaling and placement, automatic positioning of symbols, hard copy on demand, logical consistency checks and automatic checks for crossing interconnecting lines. FaultrEASE: FaultrEASE is an interactive graphics editor for fault trees. It allows you to create, edit, and draw fault trees with a minimum of effort.

It performs elementary fault tree mathematics, including mixed probability and frequency calculations, and cut sets. Formal-FTA (Formal Software): Formal-FTA is new product, initially for Sun Workstations. Being based on advanced software techniques, it has no real restrictions, i. e. it supports an unlimited number of gates and events, events may appear in any number of subtrees, subtrees may be nested to any level etc. The X/Motif graphical user interface is highly intuitive, and supports advanced capabilities such as moving branches from one location to another (with just a few mouse clicks).

An events database is provided, which enables the description of events to be independent of the tree. The events database may be shared between fault trees. Minimal cut set generation is fast, and is based on an advanced algebraic method. Both deterministic quantitative analysis and Monte Carlo simulation are well supported. Hosted on UNIX systems, Formal-FTA is intended to meet the needs of the most demanding studies, particularly where fault tree analysis is performed as a group activity. The product may be run from UNIX workstations or PCs (by use of X Terminal emulation software).

FTRAN (Rex Thompson & Partners): Graphical package to define and analyze fault trees. Package capable of multi-state prime events. Performs Monte Carlo analyses of gate and top event probabilities. MFAULT (Fault Tree Analysis Cut Set Production) (National Energy Software Center) This tool identifies the cut sets of a fault tree and computes the probability of occurrence. The input is the fault tree of an on-line or standby component FOM with • • • • • • GRAPH BASED METHODS 19 FAULT TREE ANALYSIS AND, OR, and INHIBIT gates and ON and OFF switches. The cut sets may contain repairable items only, non-repairable items only, or a mixture of both. Relex Fault Tree (Relex Software Corporation): Relax Fault Tree is a powerful and user-friendly tool for performing fault tree and event tree analyses. Included is support for gate types such as AND, OR, Exclusive OR, NAND, NOR, Priority AND, Voting, and Inhibit gates. The fast MCS calculations support common cause failures, as well as importance and time-dependent analyses. Capabilities include a user friendly interface, powerful CAD Import/ExportWizard, complete integration with the Relex Reliability Prediction and Relex FMECA Software, visual report designer, spelling checker, VBA macros, and much more.

Relex is the industry leading software package of its kind and incorporates MIL-HDBK-217, Bellcore, and Mechanical Reliability Predictions, graphical Reliability Block Diagrams, FMEAs, FMECAs, Maintainability Predictions, RCM and Life Cycle Cost analyses, and Fault Tree analyses in one completely integrated tool. Results II (Fault Tree Analysis) (Management Sciences): Fault Tree Analysis package models from the top unwanted event downwards, as a logic tree. The top gate represents the unwanted event and the roots represent contributory events.

Analysis of the tree is performed to identify those events that must fail or operate to cause system failure or operation (cut sets and minimal path sets). RESULTS III (Management Sciences): Complex risk analysis using logic trees (success or failure), Fault Tree Analysis, Success Tree Analysis, Event Tree, Risk Quantification, Cut-sets, Path-sets. Risk Spectrum Fault Tree (Innovative Software Designs): Fault tree analysis with interactive graphical fault tree editor, minimal cut set analysis, calculation of top event unavailability, importance/sensitivity analysis, time dependent analysis.

RKP606: Fault Tree Analysis (Innovative Timely Solutions): The program provides the capability to create and analyze fault trees. The program supports both qualitative and quantitative evaluation of fault trees. Program features include minimum cutset path definition, graphic representation of the tree, and probability of occurrence. GUI technology is used to facilitate user inputs. SAICUT (SAIC): A fault tree evaluation program used to obtain minimal cut sets and for estimating event probabilities. Features include: allows truncation on cut set probability or size, fault tree size limited by memory, estimate event probabilities.

Finds cut sets for any event in a fault tree. Calculates importance measures. Provides choice of top-down or bottom-up algorithms. Identifies independent sub-trees, finds prime applicants for fault trees containing negated events. SAIPLOT (SAIC): Used to plot fault trees generated by SAIC’s (CAFTA). Features include: handles up to 1000 gates & 1000 events, plots up to 250 pages, complete editing to tailor fault trees to specific needs before printing. Handles AND, OR, NOT, EQU, XOR, COM, NAND, NOR, AANB(ANOT), ANAB, OANB(ONOT), ONAB, and INH type gates.

Supports plotting large single-sheet fault trees. Plots basic event, external event, undeveloped event, transfer, conditioning event, and special transfer. • • • • • • GRAPH BASED METHODS 20 FAULT TREE ANALYSIS • TRACE (Tree Analysis Code) (COSMIC): This package analyzes fault trees to identify the most probable causes. The primary and secondary component failures are the basic inputs while the time to failure is a random variable exponentially distributed. The minimal cut-sets and critical paths of fault trees are determined using Monte Carlo simulation techniques.

The probabilities of fault tree failures are also determined in this fashion. The usual logic gates are permitted. Tree Master (Management Sciences): Success and Fault tree analysis. Risk Decision Analysis with 16 gate types. Graphic input optional. Quantification by Monte Carlo techniques. Full cutset/pathset and plotting options. Common cause, etc. Tree-Master Software Family (Antonin Wild): Family of programs for editing, evaluating, and plotting fault trees and success trees. Simulation program evaluates failure rates and downtimes. • • 6 References Ericson, Clifton (1999). “Fault Tree Analysis – A History”. Proceedings of the 17th International Systems Safety Conference. Retrieved 2010-01-17. Rechard, Robert P. (1999). “Historical Relationship Between Performance Assessment for Radioactive Waste Disposal and Other Types of Risk Assessment in the United States”. Risk Analysis (Springer Netherlands) 19 (5): 763– 807. doi:10. 1023/A:1007058325258. SAND99-1147J. Retrieved 2010-01-22. Winter, Mathias (1995). “Software Fault Tree Analysis of an Automated Control System Device Written in ADA”.

Master’s Thesis (Monterey, CA: Naval Postgraduate School). ADA303377. Retrieved 2010-01-17. Benner, Ludwig (1975). “Accident Theory and Accident Investigation”. Proceedings of the Society of Air Safety Investigators Annual Seminar. Retrieved 2010-01-17. Martensen, Anna L. ; Butler, Ricky W.. “The Fault-Tree Compiler”. Langely Research Center. NTRS. Retrieved June 17, 2011. DeLong, Thomas (1970). “A Fault Tree Manual” (pdf). Master’s Thesis (Texas A&M University). AD739001. Retrieved 2010-03-09. Eckberg, C. R. (1964). Fault Tree Analysis Program Plan.

Seattle, WA: The Boeing Company. D2-30207-1. Retrieved 2010-01-17. Begley, T. F. ; Cummings (1968). Fault Tree for Safety. RAC. ADD874448. Retrieved 2010-01-17. • • • • • • • GRAPH BASED METHODS 21 FAULT TREE ANALYSIS • Hixenbaugh, A. F. (1968). Fault Tree for Safety. Seattle, WA: The Boeing Company. D6-53604. Retrieved 2010-01-17. Acharya, Sarbes; et. al. (1990) (pdf). Severe Accident Risks: An Assessment for Five U. S. Nuclear Power Plants. Wasthington, DC: U. S. Nuclear Regulatory Commission. NUREG–1150. Retrieved 2010-01-17. • GRAPH BASED METHODS