Handbook of Reliability, Availability, Maintainability and Safety in Engineering Design - Part 58 potx

554 5 Safety and Risk i n Engineering Design Feed water system problem ID Feed water pump Feed water pump shaft Bending of pump shaft Thermal stress Lack of lubrication Manufacture and installation Systems and equipment design Operations and maintenance ComponentAssembly Failure mode Failure cause Root cause Fig. 5.6 Outage cause investigation logic tree expanded to potential root cause areas Origin of design criteria Utility inputs prior to design Equipment specifications Constraints on the design Actual design solution and tests Systems and equipment design Fig. 5.7 Root cause factors for the systems and equipment d esign area Each of these factors is developed into a factor tree chart indicating functional areas to be explored with the equipment’s design. A thorough examination of preliminary information should eliminate the need for going through all the factor trees and all the associated questions concerning the potential root causes of design integrity problems. In the following Figs. 5 .6 and 5.7, a graphic example is given of a potential outage in a power generation unit due to root cause failure in the boiler feed water pump, expanded to the potential root cause areas of equipment design, manufacture and maintenance. Figure 5 .8 gives a layout of the factor tree for the origin of design criteria. 5.2.1.3 Event Tree Analysis for Safety in Engineering Design As indicated before, event tree analysis (ETA) is an inductive logic method for identifying the various accident and/or incident sequences that can generate from a single initiating event. The approach is based on the derivation of a sequence of hazardous events (accidents and incidents) that are then quantified in terms of their probability of occurr e nce. The events delineating these sequences are usually char- acterised in terms of: 5.2 Theoretical Overview of Safety and Risk in Engineering Design 555 Fig. 5.8 Factor tree for origin of design criteria 556 5 Safety and Risk in Engineering Design • The intervention of protection systems that are supposed to take action for the mitigation of hazardous events (system event tree); • The fulfilment (or not) of safety functions (functional event tree); • The occurrence of physical phenomena (phenomena event tree). Functional event trees are an intermediate step to the construction of system event trees. Following the initiating event, the safety f unctions that need to b e fulfilled are identified; these will later be substituted by the corresponding safety and protection systems in the schematic design phase. The system event trees are used to identify the hazardous event sequences that may develop within the process engineering de- sign that would require protection and safety systems. The phenomena event trees describe the evolution of hazardous event phenomena outside the process (i.e. fire, contaminant dispersion, etc.). Event tree analysis may be qualitative, quantitative, or both, depending on the objectives of the analysis. In the application of hazards analysis, event trees may be developed independently or follow o n from fault-tree analysis. An ETA is usually carried out in six steps (AIChE 1985): 1. Identification of a relevant initiating event that may g ive r ise to unwanted con- sequences. 2. Identification of the safety functions that are designed to deal with the initiating event. 3. Construction of the event tree. 4. Description o f the resulting hazardous event sequences. 5. Calculation of probabilities/f requencies fo r the identified safety consequences. 6. Compilation and presentation of the results from the analysis. Step 1. Identification of a Relevant Initiating Event An event tree begins with a defined hazardous event (accident and/or incident), termed the initiating event, the preciseness of the definition being essential for fur- ther an alysis. The in itiating event may b e a n internal or external failure, or even human error, and may have been identified by other risk analysis techniques like preliminary hazard analysis (PHA) or HAZID. To be of interest for further analysis, the initiating event must give rise to a number of safety consequence sequences. If the initiating event gives rise to only one consequence sequence, then fault-tr ee analysis is a more suitab le technique to analyse the problem. The initiating event is often identified and anticipated as a possible critical event already in the early schematic design phase. In such cases, barriers and safety functions have usually been introduced to deal with the event. Initiating events may be defined slightly different. For example, in the safety analysis of the cooling water system of an oxidation reactor, ‘loss of cooling water to the reactor’ may be chosen as a relevant initiating event. Altern atively, ‘rupture of cooling water pipeline’ may be c hosen as the initiating event. Both of these are equally correct. It therefore fo llows that there is one event tree for each in itiating 5.2 Theoretical Overview of Safety and Risk in Engineering Design 557 event considered. This aspect obviously poses a limitation o n the number of initiat- ing events that can be analysed in detail. Thus, one of the initial activities of event tree analysis is to group similar initiating events. Initiating events that are grouped in the same class usually have similar characteristics that lead to similar consequences and warrant the same safety fun c tions. Only one typical initiating event for each class is investigated in detail. Step 2 . Identification of the Safety Functions Once an initiating event is defined, all the safety functions that are required to miti- gate the hazardous event must be defined and organised according to their time of intervention. The safety functions (safety systems, procedures, operator actions, etc.) that respond to the initiating event may be thought of as the system’s defence against the occurrence of the initiatin g event. All safety functions that have an im- pact on the safety consequences of an initiating event must be identified in the se- quence in which they are assumed to be activated. For each safety function, the set of possible success and failure states must be defined and enumerated, each state giving rise to a branching of the event tree. The safety functions are classified in the following groups (AIChE 1985): • Safety systems that automatically respond to the initiating event (e.g. automatic shutdown systems). • Alarms that alert the operator(s) when the initiating event occurs (e.g. fire alarm systems). • Operator procedures following an alarm. • Barriers or containment methods intended to limit the effects of the initiating event. The possible event chains, and sometimes also the safety functions, will be affected by various hazard-contributing factors (events or states) such as: • Ignition o r no ignition of a gas release. • Explosion or no explosion. • Time of the day. • Wind direction. • Meteorological conditions. • Liquid/gas release containment. Step 3. Constructio n of the Event Tree The event tree displays the chronological development of event chains, starting with the initiating event and proceeding through successes and/or failures of the safety functions that respond to the initiating event. The safety consequences are clearly defined events that result from the initiating event. The diagram is usually drawn 558 5 Safety and Risk in Engineering Design from left to r ight, starting from the initiating event. Each safety fun ction or hazard- contributing factor is called a node in the event tree, and is formulated either as an event description or as a question, usually with two possible outcomes (‘true’ or ‘false’—‘yes’ or ‘no’). At each node, the tree splits into two branches, an upper branch signifying that the event description in the box above that node is ‘true’, and a lower branch signifying that it is ‘false’. The outputs from one event lead to other events. The development is continued to the resulting safety consequences. For example, if the initiating event is the explosion of a process environment impregnated with flammable dust, coupled with the possible sparking of fire, the first function required would be that of quenching the fire with the appropriately installed sprinkler system and, finally, the setting off of a fire alarm. Following the initiating event ‘explosion’, fire may or may not break out. A sprink ler system and an alarm system have been installed that may or ma y not function. The quantitative analysis of the event tree is consid ered later. The functions are structured in the form of headings in the functional event tree, as shown in Fig. 5.9. In Fig. 5.9, the calculation of the frequencies for the identified safety conse- quences are: Fire control, with alarm = 10 −2 /year×0.80×0.99×0.999 = 7.9 ×10 −3 Fire control, no alarm = 10 −2 /year×0.80×0.99×0.001 = 7.9 ×10 −6 No control, with alarm = 10 −2 /year×0.80×0.01×0.999 = 8.0 ×10 −5 No control, no alarm = 10 −2 /year×0.80×0.01×0.001 = 8.0 ×10 −8 No fire = 10 −2 /year×0.20 = 2.0 ×10 −3 Fig. 5.9 Event tree for a dust explosion (IEC 60300-3-9) 5.2 Theoretical Overview of Safety and Risk in Engineering Design 559 Step 4. Description of R esulting Hazardous Event Sequences The next step in the qualitative part of the analysis is to describe the different event sequences arising from the initiating event. One or more of the sequences may repre - sent a safe recovery and a return to normaloperation or an orderly shutdown. The se- quences of importance, from a safety point of view, are those that result in accidents. The structure of the event tree diagram, clearly showing the progression of events relating to the accident, helps in specifying where additional procedures or safety systems will be most effective in protecting again st these accidents. The resulting safety consequences must be described in a clear and unambiguous way. Once the safety consequences have been described, a criticality analysis is conducted, and the safety consequences ranked according to their criticality. Such a criticality ranking isbasedontherisk of the safety consequence, in terms of its severity and probability of occurrence. This is considered later in Sect. 5 .2.1.6. Sometimes, it is beneficial to split the end safety consequences (outcomes) of the event tree, such as the as- sessment of ‘estimated disabling injury frequency’ and ‘estimated reportable hazard frequency’, into different categories of safety consequences, namely: • Life risk—when the occurrence of critical functional failures can be expected to result in a risk of loss of life every time. • Loss risk—when the occurrence of critical functional failures can be expected to result in a risk of loss of limb every time. • Health risk—when the occurrence of critical functional failures can be expected to result in the risk of a health hazard every time. • People risk—when the occurrence of critical functional failures can be expected to result in the risk of an accident affecting people working in the area every time. • Environment risk—when the occurrence of critical functional failures can be ex- pected to result in the risk of an accident affecting the environment every time. • Process risk—when the occurrence of critical functional failures can be expected to result in the risk of an accident affecting the production process every time. • Product risk—when the occurrenceof critical functional failures can be expected to result in the risk of an accident affecting the related product every time. In the example event tree for a dust explosion shown in Fig. 5.9, the following simplified categories are used: • loss of lives • environmental damage • material damage. The safety consequences may b e ranked within each of these simplified categories. For the categories ‘environmental damage’ and ‘material damage’, typical sub- categories are used such as N (negligible), L (low), M (medium), and H (high). What is meant by these categories has to be defined in each particular case. If the safety consequences cannot be placed into a single group, a probability distribution may be given for various sub-categories, such as for the category ‘loss of lives’. Thus, for this category, the sub-categories 0, 1–2, 3–5, 6–20, etc. are proposed. The 560 5 Safety and Risk in Engineering Design outcome of an event ch a in may be, for example, that 0 pe rsons would be killed with probability 50%, 1–2 persons may be killed with probability 40%, 3–5 persons may be killed with probability 10%, and 6–20 persons may b e killed with probability 2%. If, in addition, the frequency of the outcome can be estimated, then the fatal accident rate (FAR) associated to the specified initiating event can be calculated (Rausand 1999). Quantitative Assessment of the Event Tree If sufficient information is available for the initiating event and all the relevant safety functions and hazard-contributing factors, a qu antitative analysis of the event tree may be carried out to give frequencies or probabilities of the resulting consequen ces. The pro bability of occurrence of the initiating event is usually modelled according to a homogeneous Poisson distribution, and a frequency that is measured as the ex- pected number of occurrences per year (or a time unit). For each safety function, the conditional probability that it will function properly when the previous events in the event chain have occurred must be estimated. Some safety functions, like emer- gency shutdown (ESD) systems on offshore oil/gas platform s, may be very complex and will require a detailed analysis for the integrity of their design. The conditional reliability of a safety function will depend on a wide range of environmental and operational factors, such as stress-strength loads from previous events in the event chain, time since the last function test, etc. In many cases, it will also be difficult to distinguish between ‘functioning’ and ‘non-functioning’. For example, a fire pump may promptly start but stop prema- turely before the fire is extinguished. The reliability assessment of a safety function may in most cases be performed by a fault-tree analysis or by an analysis based on a reliability block diagram. If the analysis is computer ised, a link may be es- tablished between the reliability assessment and the appropriate node in the event tree, to facilitate automatic updating of the outcome frequencies and for sensitivity analysis. It may be relevant to study the effect on the outcome frequencies by chang- ing the testing interval of a safety valve, for example. Graphically, th e link may be visualised by a transfer symbol on one of the output branches from the node. The probabilities of the various hazard-contributing factors (events/states) that enter into the event tree must also be estimated for the relevant contexts. Some of these factors will be independent of the previous events in the event chain, while others are not. However, most of the probabilities in the event tree are conditional probabilities. The probability that the sprinkler system in Fig. 5.9 will function after the initiating event is not equivalent to the probability that it will function on the basis of pilot tests under normal conditions. The possibility that the sprinkler system may have been damaged during the dust explosion and the first phase of the fire (i.e. before it is activated) must also be taken into account. Considering the event tree in Fig. 5.9, let f A denote the frequency of the initiating event A, ‘explosion’. In this example, f A isassumedtobeequalto10 −2 per y ear, which means that an explosion will occur on average once every 100 years. Let B 5.2 Theoretical Overview of Safety and Risk in Engineering Design 561 denote the event ‘start of a fire’, and let P (B|A) = 0.8 be the conditional probability of this event when a dust explosion has already occurred. In the same way, let C denote the event ‘sprinkler system on’, following the dust explosion and outbreak of a fire. The conditional probability of C that the sprinkler system will function is P (C|BA) = 0.99. The event ‘fire alarm activated’ is denoted by D with probability P (D|BA) = 0.999. In this example, the probability that the alarm will b e activated by the event ‘start of a fire’ is assumed to be the same whether the sprinkler system is functioning or not. In most cases, however, the probability of th is event would depend on the out- come of theprevious event.Thus, let b, c and d denote the negation(non-occurrence) of the events B, C and D respectively, where P (b|xy) is equal to 1−P (B|xy), etc. The frequencies (per year) of the end consequences may now be calculated as follows: 1. ‘Fire control, with alarm’ f A ×P(B|A) ×P(C|BA) ×P(D|BA) = 10 −2 /year×0.80×0.99×0.999= 7.9×10 −3 2. ‘Fire control, no alarm’ f A ×P(B|A) ×P(C|BA) ×P(d|BA) = 10 −2 /year×0.80×0.99×0.001= 7.9×10 −6 3. ‘No control, with alarm’ f A ×P(B|A) ×P(c|BA) ×P(D|BA) = 10 −2 /year×0.80×0.01×0.999= 8.0×10 −5 4. ‘No control, no alarm’ f A ×P(B|A) ×P(c|BA) ×P(d|BA) = 10 −2 /year×0.80×0.01×0.001= 8.0×10 −8 5. ‘No fire’ f A ×P(B|a)=10 −2 /year×0.20 = 2.0×10 −3 It is evident that the frequency of a specific outcome (consequence) is simply obtained by multiplying the frequency of the initiating event by the probabilities along the event sequence leading to the outcome in question. If it is assumed that occurrences of the initiating event may be described by a homogen eous Poisson process, and that all the probabilities of the safety functions and hazard-contributing factors are constant and independent of time, then the occurrences of each outcome will also follow a homogeneous Poisson distribution. 562 5 Safety and Risk in Engineering Design Evaluation of the Event Tree Once the final event tree has been constructed, the remaining task is to compute the probabilities of system failure. Each event (branch) in the tree can be interpreted as the top event o f a fault tree that allows the evaluation of the prob ability of the occur- rence of such event. The value thus computed represents the conditional probability of the occurrence of the event, given that the events preceding that sequence have occurred. In the case of independent events, multip lication of the conditional probabilities for each branch in a sequence gives the probability of that sequence. This was illus- trated in the example functionalevent tree for a dust explosiongiven in Fig. 5.9 (IEC 60300-3-9). Similarly, an illustration of independent event tree branching for a re- actor safety study by the US Nuclear Regulatory Commission is given in Fig. 5.10 (NUREG 75/014 1975). Once the system failure and success states have been properly defined, the states are then combined through the tree branching logic to obtain the various accident sequences that are associated with the given initiating event. Figure 5.10 shows a graphical example of a system event tree where the initiating event (I) is first depicted, and the system states are then connected in a stepwise, branching fashion. System success or failure states are denoted by S i and F i respectively, where i = the number of systems in the configuration. The accident sequences that result from the tree structure are shown in the last column. Each branch yields one particular accident sequence; for example, (I)(S 1 )(F 2 ) denotesthe accident sequence in which the initiating event (I) occurs and system 1 is called upon and succeeds, (S 1 ), and system 2 is called upon but fails to perform its defined function, (F 2 ). For larger event trees, this stepwise branching would simply be continued. The success and failure of a system must be defined under the condition that the Initiating event Initiating event (I) Success state (S1) Success state (S2) (I) (S1) (S2) (I) (S1) (F2) (I) (F1) (S2) (I) (F1) (F2) Success state (S2) Failed state (F1) Failed state (F2) Failed state (F2) System 1 System 2 Sequences Fig. 5.10 Event tree b ranching for reactor safety study 5.2 Theoretical Overview of Safety and Risk in Engineering Design 563 initiating event has occurred. Likewise, the system states on a given branch of the event tree are conditional on the previous system states having occurred. In the case of dependent events, two approaches to accident seque nce modelling are available. The first approach is called boundary condition event trees, and consists of de- composing the system so as to identify the supporting parts or functions upon which some components and systems are simultaneously dependent. The functions appear explicitly as system event tree headings, preceding the dependent protection sys- tems and components. Since d ependent parts are extracted and explicitly treated as boundary conditions in the event tree, this approach leads to relatively small event trees. For example, consider an initiating event that requires two systems, S 1 and S 2 ,to intervene and suppose that, to operate, S 1 needs the pumps of S 2 . Then, one could extract the ‘ common part’ and consider three systems: S 1 , S ∗ 2 , which is the S 2 system without the pumps common to S 1 ,andS 3 , which includes the pumps used by both S 1 and S 2 . It is obvious that S 3 is logically placed before S 1 and S 2 in the event tree, as schematically shown in Fig. 5.11, because it is the function that first responds to the initiating event because, to operate, S 1 needs the pumps of S 2 . The dependencies are then explicitly represented in the tree, and the branching associated with S 1 and S ∗ 2 may be eliminated when S 3 is not functioning.Thus, all the conditiona l proba bilities a re made independent, and the prob a bility o f the accident sequences can be computed by simple multiplication. This approach considerably simplifies the computations but it requires a great deal of expertise by the analyst. In fact, since sy stem interactions and dependencies are treated primarily within the inductive logic of the event tree, those dependencies not recognised by the analyst may not be incorporated into the analysis. The second approachis called fault-tree linking. In this method, the dependencies from support systems or common parts are modelled in fault trees and thus, at the level of the event trees, the systems are inserted without the need to consider their E1 E1 S3 F3 S3 S1 S1 F1 S2 * S2 * F2 * S2 * F2 * Freq (Sequence) Freq (Seql) = f (E1).Pr (S3).Pr (S1).Pr (S2*) etc. Fig. 5.11 Event tree with boundary conditions . char- acterised in terms of: 5.2 Theoretical Overview of Safety and Risk in Engineering Design 555 Fig. 5.8 Factor tree for origin of design criteria 556 5 Safety and Risk in Engineering Design • The intervention. initiating event. The diagram is usually drawn 558 5 Safety and Risk in Engineering Design from left to r ight, starting from the initiating event. Each safety fun ction or hazard- contributing. (IEC 6030 0-3 -9 ) 5.2 Theoretical Overview of Safety and Risk in Engineering Design 559 Step 4. Description of R esulting Hazardous Event Sequences The next step in the qualitative part of the analysis