Events common cause

WAMCOM Fault tree with susceptibilities 1 Uses modularizatton and SETS to more effectively identify cutsets that contain critical events, critical nindcmt events, and significant common cause events or to describe common cause sets for each failure Can identify etymon total or partial links between fault-tree components con handle very large fault trees CDC 7600, Available froni i I l Rl i V 1.-Cenler... 

A common cause event causes two separate, supposedly independent systems to fail simultaneously. For example, solid materials in a liquid system may cause both a pressure controller instrument and the high-pressure shutdown system to be blocked at the same time. The normal control and the interlock are not independent of one another. 

Common cause events negate the value of an and gate in a fault tree (Chapter 15). 

The following are examples of common cause events that frequently crop up. 

If instmments are placed on manual, particularly emergency instruments, then a common cause event has been created. For example, one of the contributing factors in the Piper Alpha disaster was that both firewater pumps were on manual. They had been placed in that state to ensure that any divers in the water were not sucked into the firewater intake in the event of an automatic start of the pumps. Unfortunately, the fire on the platform prevented operators firom getting to the pumps to turn them on. The lack of firewater capability materially contributed to the magnitude of the disaster. 

Airlines use a second pilot to serve as a backup in the event that the first pilot is incapacitated during the flight for any reason. Management aims to eliminate common cause events where possible. For example, the pilots may be required to eat different types of meals so that, if one type of meal is contaminated, only one of the pilots is affected. 

Even at this early stage in the report writing process, the leader and scribe should be cross-referencing information and findings in order to identify common cause events. For example, if the cause of high pressure in two or more vessels is the same, the leader can note this as being a generic issue. 

Imprecision in defining terms Multiple contingencies Complexities and subtle interactions Dynamic conditions Common cause events Knowledge of safe operating limits Lack of quantification Team quality Personal experience Boredom... 

In conventional fault tree analysis, one of the biggest benefits of the technique is that it highlights common cause events, i.e., those events that occur in two or more places on the tree and thus bypass safeguards. A common example would be electrical power failure. Loss of power could cause equipment to fail and could also lead to failure of some of the backup systems. 

Some events occur in more than one place on the tree. In the worked example, the event Instrument Plugs — E-004—occurs three times. This is a common cause effect. Common Cause events need to be identified properly before the Tree is quantified. How this can be done is discussed later in this chapter. 

The failure rate of this simple system is (0.5 X 0.1), i.e., 0.05 yr. In other words, the pumping system is expected to fail once in 20 years. However, those operating the above system find that it is, in fact, considerably less reliable than it ought to be, so an investigation into common cause events is carried out. The following factors contribute toward the failure of the steam-driven P-IOIA. 

The development of common cause events does not stop here. Another issue that could cause both pumps to fail is the inadvertent introduction of corrosive chemicals into the RM-12 stream. When corrosion is considered, the fault tree looks as shown in Figure 15.27. 

In Chapter 1, it was noted that the Fukushima-Daiichi catastrophe provides a good example of Common Cause events the earthquake knocked out the primary cooling pumps, and the tsunami then knocked out the backup pumps. Copies of the Fukushima-Daiichi P IDs (Piping and Instrument Diagrams) are not available. Therefore, for the sake of discussion it is assumed that there are two sets of pumps three operating pumps (Ol, 02, and 03) driven by electricity and two backup pumps (B1 and B2) that are diesel-powered and that do not require electrical power. The Fault Tree for this assumed set up is shown in Figure 15.28. It consists entirely of and Gates. 

Throughout this book emphasis is placed on the problems associated with common cause effects. In the case of safety instruments it is important to identify any problems that could simultaneously disable all the instruments. For example, solid material in a liquid stream could plug both instruments thus cancehng out perceived redundancy. In order to minimize the problem of common cause events, good practice calls for different types of instmment and transmitter to be used when redundancy is called for. 

One of the best known parametric models is the Binomial Failure Rate (BFR) model (Vesely 1977). The model postulates a shock causal mechanism for the failures. In particular, the model assumes that common cause events occur to the system as a result of shocks that may lead to common cause events of various multiplicities. These shocks hit the system according to a Poisson distribution with rate /x. A fundamental assumption of the BFR model is that, at the occurrence of a shock, all components fail independently with the same probability p. Therefore, the probability 4>k/m that exactly k components fail, whereas m — k... 

Assiunptions 1 and 2 mean, for instance, that common-cause events cannot generally be handled by a Poisson process. Some common cause events may violate assumption 1, because two or more components may fail at the same time. If assumption 1 is approximately satisfied, because the common-cause mechanism makes the events to occur with a slight delay, it is assumption 2 which might be violated. That s because the occurrence of one or more events of the component group increases the probability of another event of the same component group to occur soon after. 

Guidelines for PSA of operator action, common cause events, cross-Unk effects, redundancy and diversity. 

In addition to the explicit dependencies noted above, other dependencies are included by accounting for common cause events. 

Common cause failures are described in Section 2.2.3.4 as simultaneous failures of multiple components due to some underlying common cause, such as design errors or environmental factors. Common cause events can be placed directly on fault trees for analysis. Engineering judgment is used to determine which common cause events are important enough to include. It is not possible to include all conceivable combinations of common cause events due to the number of components involved. For example, the number of combinations of motor-operated valves in a plant that could fail from a common cause is almost endless. Standard practice is to consider common cause combinations across multiple trains of single systems, but with a few exceptions not across multiple systems. 

Finally, PHWR practice requires consideration of common cause events. These are identified either by a systematic plant review or by a PSA. The analysis thereof is usually reported as part of the PSA. 

Analysis of Dependence Such as Common Cause Events... 

---