Fault trees demand tree

Layer of protection analysis (LOPA) is a simplified form of event tree analysis. Instead of analyzing all accident scenarios, LOPA selects a few specific scenarios as representative, or boundary, cases. LOPA uses order-of-magnitLide estimates, rather than specific data, for the frequency of initiating events and for the probability the various layers of protection will fail on demand. In many cases, the simplified results of a LOPA provide sufficient input for deciding whether additional protection is necessary to reduce the likelihood of a given accident type. LOPAs typically require only a small fraction of the effort required for detailed event tree or fault tree analysis. 

A logic model that graphically portrays the combinations of failures that can lead to a particular main failure (TOP event) or accident of interest. Given appropriate data, fault tree models can be quantitatively solved for an array of system performance characteristics (mean time between failures, probability of failure on demand, etc.)... 

Notice that one event has units of per-demand and the others have a per-unit-time dimension. From elementary considerations, the top event can only have dimensions of per-demand (pure probability) or per-unit-time dimensions. Which dimensions they have depends on the application. If the fault tree provides a nodal probability in an event tree, it must have per-demand dimensions, if the fault tree stands alone, to give a system reliability, it must have per-unit-time dimensions. Per-unit-time dimensions can be converted to probability using the exponential model (Section 2.5.2.6). This is done by multiplying the failure rate and the "mission time" to give the argument of the exponential which if small may be... 

The component failure rate data used as input to the fault tree model came from four basic sources plant records from Peach Bottom (a plant of similar design to Limerick), actual nuclear plant operating experience data as reported in LERs (to produce demand failure rates evaluated for pumps, diesels, and valves), General Electric BWR operating experience data on a wide variety of components (e.g., safety relief SRV valves, level sensors containment pressure sensors), and WASH-1400 assessed median values. 

All team members should be familiar with PrHA objectives, the PrHA method to be used, and their roles in performing the PrHA. A 1- or 2-hour overview at the beginning of the first team review session is generally sufficient for this purpose. However, the more demanding PrHA methods, such as fault tree analysis (FTA), require more training and/or a greater depth of experience than less-rigorous methods, such as what-if and checklist analyses. 

Figure 15.23 shows a fault tree and Gate based on the first standard example. The gate has two inputs failure of P-IOIA, which is steam driven, and failure of P-IOIB, which is electrically driven. (Pump A is normally operating, with B being on standby.) It is assumed that the two pumps have failure modes that are totally independent of one another, i.e., the failure of one is completely independent of the failure of the other. Pump 101-A has a predicted failure rate of once in 2 years, or 0.5 yr Pump 101-B has a predicted probability of failure on demand (PFD) of 1 in 10 or 0.1. 

The fault tree method requires that one define an undesirable event (often called the "top event"). Consider the equipment set used for the safety instrumented function in Figure 5-6. A fault tree drawing shown in Figure 5-7 shows a top event defined as probability of failure on demand for the safety instrumented function shown in Figure 5-6. 

The calculations may be done with simplified equations, fault trees, Markov models or other techniques depending on the complexity of the model and the demand mode of operation. 

Low Demand Mode Verification Calculation Using Fault Trees... 

Using rough, first order approximation techniques, a simple formula can be generated from the fault tree for the probability of dangerous failure (probability of failure on demand), PFD (assuming perfect periodic test and repair)... 

In order to determine the required safety integrity level, the expected number of demands on the overfilling protection is calculated in the first place. These demands stem from the operational level, which is modelled by the fault tree of Fig. 11.8. This fault tree is quantified with the data from Table 11.7. 

Fig. 11.8 Fault tree for modelling the expected frequency of demands of the protection against overfilling...

A fault tree for a process plant can be built up by starting with the fault tree for the unprotected system (the demand tree), to which is added branches representing protection by the process operator and/or instrument systems. ... 

The fault tree analyses are performed using equivalent fault trees (see Figure 2), and SimTree, the fault tree module of the Aralia Workshop software tool, distributed by Dassault Syslemes. 249 minimal cut sets (MCS) have been obtained and are arranged by orders in Table 6. Probability of failure on demand of the... 

Wu (2007) has constructed a fault tree for the top event SBLC failure on demand , see Figure 1. 

Let. 4 denote the top event SBLC failure on demand in the fault tree of Section 2.2, and q the probability (chance) of occurrence of A over a fixed mission time, Tm- The probability (chance) q depends on the logical structure of the fault tree and the probabih-ties (chances) of occurrence of component failures, or basic events S, / = 1,2,..., 22. The probabilities (chances) Pi(Xi) of occurrence of the basic events Bi in the fixed mission time are assumed to be unknown. Here X, is a parameter, possibly vector-valued, of the underlying failure time distribution of component i. In this work, an exponential failure time distribution is assumed for all components in the system, i.e., p(Xi) = -exp — XiTm), and we use = 31 days. 

The unavailability of a required component may be constant, if it only depends on the failure probability to start on demand (see Sec. 3.2.2). But, principally, the unavailability is time-dependent. It depends, for instance, on the failure behaviour of the component over time in stand-by mode, on the time between periodical function tests, on the timing of maintenance and repair work, and/or on the failure behaviour over lime in operating mode. Moreover, it may also depend on process conditions (e.g. high stress for some time) under which the component has to operate. However, the concept of fault-tree models is not suited for modeling time- and/or process-dependent failure behaviour. 

FTA, fault tree analysis LOPA, layer of protection analysis NR, not recommended PFDavgt probability of failure on demand SIL, safety integrity level X, acceptable. ... 

Having identified a number of initiating events, the demand tree can be used as an input to other analysis techniques to carry out a more detailed risk assessment. This further stage would typically use either a fault-tree analysis or a layer of protection analysis (so long as the LOPA methodology used has sufficient flexibility to treat each cause separately and then combine them when assessing the frequency of the hazardous event). 

As a simple example of selecting an appropriate SIL, assume that the maximum tolerable frequency for an involuntary risk scenario (e.g., customer killed by explosion) is 10 pa (A) (see Table 2.1). Assume that 10 (B) of the hazardous events in question lead to fatality. Thus the maximum tolerable failure rate for the hazardous event will be C = A/B = 10 pa. Assume that a fault tree analysis predicts that the unprotected process is only likely to achieve a failure rate of 2 x 10 pa (D) (i.e., 1/5 years). The FAILURE ON DEMAND of the safety system would need to be E = C/D =10 column of Table 1.1, SIL 2 is applicable. 

Figure 5.10 shows a fault tree for the example assuming that the human response is independent of the shutdown system. The fault tree models the failure of the two levels of protection (2) and (3). Typical (credible) probabilities of failure on demand are used for... 

The table below the fault tree in Figure 14.2 shows part of the fault tree output from the Technis TTREE package (see end of book). The cut sets have been ranked in order of frequency since this is a high-demand scenario which deals with a failure rate. Note that 80% of the contribution to the top event is from the PEI event. 

In analyzing process systems by means of fault trees, a point Is reached at which erroneous operation of a field device due to faulty control signal Is postulated. For example, a pump may fall to continue running due to Its circuit breaker being demanded open erroneously by the control system. The topmost event In the fault tree of Figure 4, taken from a process system fault tree, shows such a failure mode. In this example, such an event can occur If two... 

Previous failure mode and effect analysis and fault tree analysis work by the authors has shown that the inherently complex system of a PEMFC assembly can harbor dependencies between multiple failure modes. Therefore in this presented work, Petri-Net simulation has been adopted to develop a more accurate degradation model. Operational parameters such as water content, temperature and current density s effects on the occurrence of failure modes can be modelled through this technique. This work will improve previous fuel cell reliability studies by taking into consideration operating parameters (water content, temperature), ambient weather and fuel cell voltage demand (drive cycles). 

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

Specification of key protective systems, mechanical, electrical and instrument. This will include estimates for hazard demand rates and required risk reduction factors supported by hazard analyses or fault tree logic diagrams... 

---