Handbook of Reliability, Availability, Maintainability and Safety in Engineering Design - Part 66 doc

5.2.4.2 Cause-Consequence Analysis for Safety Systems Design Cause-consequence analysis for safety systems design is fundamentally a combina-torial symbolic logic technique, utilising th

{N (t)+C(t)} is obtained by multiplying the p.g.f.s of the random variables together

Ez N (t) · Ez C (t) = Ez N (t)+C(t) (5.79) where N (t) and C(t) are independent.

5.2.4.2 Cause-Consequence Analysis for Safety Systems Design

Cause-consequence analysis for safety systems design is fundamentally a combina-torial symbolic logic technique, utilising the symbolic logic of fault-tree analysis (FTA), reliability block diagramming (RBD) and event tree analysis (ETA) Each of

these techniques has unique advantages and disadvantages In most complex safety systems designs, it is beneficial to construct a model using one technique, then trans-form that model into the domain of another technique to exploit the advantages of both Fault trees are generated in the failure domain, reliability diagrams are gen-erated in the success domain, and event trees are gengen-erated in both the success and failure domains

Methodology to transform any one of the above models into the other two, by translating equivalent logic from the success to failure or failure to success domains,

is considered later Probabilities are propagated throughout the logic models to de-termine the probability that a system will fail, i.e its risk, or the probability that

a system will operate successfully, i.e its reliability Probability data may be de-rived from available empirical data or, if quantitative data are not available, then subjective probability estimates may be used

Cause-consequence analysis for safety systems design explores the system’s re-sponses to an initiating deviation from predetermined norms (such as the limits

of safe operating parameters), and enables evaluation of the probabilities of un-favourable outcomes at each of a number of mutually exclusive loss levels, depend-ing upon the extent of deviation from these norms The deviation beyond a set limit

is designated an event

The analysis then begins with an initiating event and performs a forward (bottom-up) analysis using ETA This technique provides data similar to those available with conventional event tree analysis; however, it affords two advantages over the con-ventional event tree—time sequencing of events is better portrayed, and discrete, staged levels of outcome are analysed The cause portion of this technique is the safety system response to an undesired process state or condition This process state

is represented as a fault-tree TOP event and is normally, but not always, quantified

by its probability of occurrence The consequence portion of this technique yields

a display of potential outcomes representing incremental levels of success or failure

of the safety system Each increment has an associated level of assumed or calcu-lated probability, based on variations of responses of the safety system to the various process states or conditions The cause has an associated probability, and each con-sequence has an associated severity and probability (NASA 1359 1994)

Cause-consequence analysis for safety systems design is particularly useful in analysing command-start and command-stop protective devices, emergency re-sponse systems, and engineered safety features Cause-consequence analysis is fundamentally useful in evaluating design decision options concerning the effects and/or benefits of sub-tiered redundant or diverse countermeasures for safety sys-tems design This technique may be used to compliment a failure modes and effects analysis (FMEA) or, more specifically, a failure modes and safety effects (FMSE) analysis, otherwise known as probabilistic risk analysis (PRA)

a) Fault Tree, Reliability Block Diagram, and Event Tree Transformations

Fault trees, reliability block diagrams (RBDs) and event trees are all symbolic logic models Fault trees are generated in the failure domain, reliability diagrams are gen-erated in the success domain, and event trees are gengen-erated in the success and failure domains These techniques transform any one of the above models into the other two by translating equivalent logic from the success to failure or failure to success domain Fault trees offer comprehensive qualitative or quantitative analysis RBDs offer a simplistic method to represent system logic, and event trees enable systems evaluation in both the success and failure domains Prior to considering the methods for transforming a fault tree, RBD or event tree into either of the other two logic models, it is essential to first review reliability block diagrams (RBDs):

A reliability block diagram (RBD) is a deductive, top-down analysis, symbolic

logic model, used to define the path from effect to cause, and generated in the suc-cess domain Each RBD has an input and an output and flows left to right from the input to the output Blocks may depict failure events or element functions within

a system, though most RBDs typically depict system element functions only A sys-tem element can be a sub-syssys-tem, assembly, sub-assembly, component or part Sim-ple RBDs are constructed of series, parallel, or combinations of series and parallel elements, as indicated in Fig 5.26 (NASA 1359 1994)

An RBD may contain a combination of series and parallel branches where each block represents an event or system element function These blocks are connected in series if all elements must operate for the system to operate successfully, or they are connected in parallel if only one element needs to operate for the system to operate successfully

Reliability is the probability of successful operation during a defined time inter-val and, conversely, unreliability is the probability of failure during a defined time interval In a safety analysis context, RBDs indicate system reliability or unreliabil-ity, where each block may represent a system element function (operates success-fully) or a failure event Each element of a block diagram is assumed to function or

to fail independently of the other elements The overall system reliability can thus be determined from the relationships between element reliability and system reliability for series and parallel systems

Fig 5.26 Simple RBD construction

The relationships between element reliability and system reliability for series and parallel systems can be mathematically expressed as

Series RS=∏n

i

Parallel RS= 1 −∏n

i (1 − R i)

Parallel RS= [1 − (1 − R1)(1 − R2)(1 − R3) (1 − R n)]

where:

RS= system reliability

R i = system element reliability

n = number of system elements that function independently

Not all systems can be modelled with simple RBDs Some complex systems cannot

be modelled with true series and parallel branches These systems must be modelled with a complex RBD Such an RBD is presented in Fig 5.27 In this example, if

Fig 5.27 Layout of a complex RBD (NASA 1359 1994)

element E fails, then paths B, E, G and B, E, H are not success paths; thus, this is not a true series or parallel arrangement

An RBD enables evaluation of various potential design configurations The re-quired element reliability levels can be determined to achieve the desired system reliability An RBD can also be used to identify design configuration elements in symbolic logic as a precursor to performing an FTA The procedures to generate

a simple RBD are as follows:

(1) Define the system into its SBS from the available functional diagram of the system

(2) Construct a block diagram using the convention illustrated in Fig 5.26

(3) Calculate system reliability bands, RSL(low) to RSH(high), from each element’s

reliability band, R iL (low) to R iH(high), in the following manner:

a For series systems with n elements that are to function independently

RSL =∏n

i

R iL = R1L· R2L · R3L · · R nL (5.81)

RSH =∏n

i

R iH = R1H· R2H · R3H · · R nH

b For parallel systems with n elements that are to function independently

RSL= 1 −∏n

i

RSL= [1 − (1 − R1L)(1 − R2L)(1 − R3L) (1 − R nL)]

RSH= 1 −∏n

i (1 − R iH)

RSH= [1 − (1 − R1H)(1 − R2H)(1 − R3H) (1 − R nH)]

c For series-parallel systems, first determine the reliability for each parallel branch using the equations in step 3b Then treat each parallel branch as an element in a series branch and determine the system reliability by using the equations in step 3a

d For parallel-series systems, first determine the reliability for each series branch using the equations in step 3a Then treat each series branch as an

element in a parallel branch and determine the system reliability by using the equations in step 3b

For systems that are composed of the four arrangements given above, the relia-bilities for the simplest branches are first determined, which then become branches within the remaining block diagram The reliability for the new branches are then determined This process is continued until one of the above four basic arrangements remains, from which system reliability is calculated

As an example, consider a high-pressure process with a high-integrity protection

system (HIPS) containing two sub-systems designated S1and S2 Sub-system S1has three sensor components and at least one of the three must function successfully for

the sub-system to operate Sub-system S2is an essential instrumentation path for

the protection system Sub-system S2has three components that all need to function successfully for the sub-system to operate The estimated reliability band for each component is given in Table 5.14

The components for sub-system S1 are in a parallel branch with the

compo-nents of sub-system S2 In addition, the components for sub-system S1form a series

branch, and the components for sub-system S2form a parallel branch An RBD for the system is illustrated in Fig 5.28

Sub-system S1reliability

Low band value: RS1L= 1 − (1 − 0.80)(1 − 0.80)(1 − 0.80) = 0.992

High band value: RS1H= 1 − (1 − 0.85)(1 − 0.85)(1 − 0.85) = 0.997

Table 5.14 Sub-system component reliability bands

Fig 5.28 Example RBD

Sub-system S2reliability

Low band value: RS2L= (0.90)(0.90)(0.90) = 0.729

High band value: RS2H= (0.95)(0.95)(0.95) = 0.857

System reliability

Low band value: RSL= 1 − (1 − 0.992)(1 − 0.729) = 0.998

High band value: RSH= 1 − (1 − 0.997)(1 − 0.857) = 0.999

The reliability band for the combined system is 0.998 to 0.999 This example

is of particular interest in that the configuration for the HIPS produces an overall reliability range that is higher than any of the sub-system reliabilities The reliability

values for the parallel sub-system S1are higher than the reliability values for the

series sub-system S2, implying that the sensors configuration of the HIPS has higher priority than does the instrumentation path

The application of an RBD in safety systems design provides several advantages

in that it allows evaluation of design concepts when design changes can still be incorporated Furthermore, it tends to be easier to visualise than other logic models, such as fault trees, because blocks representing elements in an RBD can be arranged

in a manner representing how these elements function in the system Since RBDs are easy to visualise, they can be generated prior to conducting FTA, and transformed into a fault tree

The methods for transforming a fault tree, RBD or event tree into either of the other two logic models are as follows (NASA 1359 1994), starting with the RBD to fault tree transformation shown in Fig 5.29

Fig 5.29 RBD to fault tree transformation

b) RBD to Fault Tree Transformation

A fault tree represents system functions that, if they fail, produce a TOP event fault

in place of a success event, which the reliability block path indicates The series nodes of an RBD denote an OR gate beneath the TOP event of a fault tree The parallel paths in an RBD denote the AND gate for redundant component functions

in a fault tree The reliability diagram can thus be relatively easily transformed into

a fault tree, as shown in Fig 5.29

c) Fault Tree to RBD Transformation

An RBD represents system component functions that produce success in place of

a TOP fault event, if these functions prevail A fault tree can be transformed into

a reliability diagram, as illustrated in Fig 5.30

d) RBD and Fault Tree to Event Tree Transformation

An event tree represents path sets in the success branches of the tree and all the cut sets in the failure branches of the tree Therefore, if the path sets and cut sets

of a system are known for the TOP event of a fault tree, then an event tree can be

Fig 5.30 Fault tree to RBD transformation

Fig 5.31 Cut sets and path sets from a complex RBD

Fig 5.32 Transform of an event tree into an RBD

constructed Cut sets and path sets may be obtained from a reliability diagram as shown in Fig 5.31 (cf Fig 5.32)

e) Event Tree to RBD and Fault Tree Transformation

An event tree represents path sets in the success branches of the tree and all the cut sets in the failure branches of the tree To transform an event tree into an RBD, the process is reversed as illustrated in Fig 5.32 Once the RBD is formed, a fault tree can be developed as illustrated in Fig 5.33

These techniques allow for weaknesses of any one of the analysis techniques

to be overcome by transforming a system model into an equivalent logic model as another analysis technique For example, a complex system that may be hard to model as a fault tree might be easily modelled with an RBD Then, the RBD can

Rs = 1 − (1 − RA) ∗ (1 − RB) ∗ (1 − (RC)(RD)(RE ))

Fig 5.33 Transform of an RBD to a fault tree

be transformed into a fault tree, and extensive quantitative or pseudo-quantitative (partially qualitative and quantitative) analysis can be performed

However, these techniques do possess some limitations, such as the following:

• No new information concerning the system is obtained and the models are only

as good as the models being transformed

• The cut sets and path sets required to perform these transformations for large

complex systems may require extensive computer resources to determine

f) Structuring the Cause-Consequence Diagram

Previously in Sect 5.2.1.4, a four-stage procedure to construct and analyse a cause-consequence diagram was given as:

• Step 1) Component failure event ordering.

• Step 2) Cause-consequence diagram construction.

• Step 3) Reduction.

• Step 4) System failure quantification.

If this procedure is to be considered as a generally applicable approach, it must be capable of dealing with the events that occur in more than one fault-tree structure attached to the decision boxes in any sequence path It can be shown that the cause-consequence diagram method can deal with repeated events in a more efficient way

than that used for fault-tree analysis (FTA) Using the cause-consequence diagram method, there is no need to obtain the Boolean expression of the top event and then manipulate it to produce a minimal form prior to analysis

The cause-consequence method deals with sequences of events that either occur (fail) or do not occur (work) The probability of a particular outcome is obtained by summation of the probability of all paths that lead to the outcome Summation of the probabilities of the mutually exclusive paths results in the development of the reduced form that would be obtained from the fault tree following Boolean reduc-tion An algorithm has been developed that can trace through a cause-consequence diagram, and identify and extract any repeated basic events in more than one fault-tree structure on the same sequence path Certain procedural steps are used in this extraction algorithm (Ridley et al 1996)

Procedural steps used in an extraction algorithm to identify and extract any re-peated basic events in more than one fault-tree structure on the same sequence path:

• Step 1) Identify the fault-tree structures in the path under inspection.

• Step 2) Each fault tree in a path is modularised and the independent sub-trees

identified

• Step 3) Each independent sub-tree for each fault-tree diagram is compared to

the others and, following identification of common sub-trees or individual basic events, the cause-consequence diagram is modified

• Step 4) The cause-consequence diagram is modified using the following rules:

a Following the identification of a common sub-tree or basic event, the com-mon element is extracted and set as a new decision box at the highest point

in the cause-consequence diagram that has all dependencies below it

b The cause-consequence diagram is then duplicated on each branch

c Having developed a decision box for the common sub-tree or basic event, the decision boxes that contained the common event prior to extraction require modification The common event(s) are set to 1 (TRUE) in the fault trees following the NO outlet branch from the new decision box, as this indicates failure, and to 0 (FALSE) in the fault trees following the YES branch to signify that the common event(s) works

d After extraction of the common sub-tree or basic event, each fault tree that has been modified requires reorganisation Each fault tree containing the ex-tracted Boolean variable is inspected and the fault trees modified by setting the Boolean variable to represent the path taken in the cause-consequence diagram

e The cause-consequence diagram is then reduced to a minimal form by re-moving any redundant decision boxes that have been identified This proce-dure is repeated until all sequence paths have been inspected and no repeated sub-trees or basic events discovered

As an example, the technique is applied to the simple high-pressure protection sys-tem depicted in Fig 5.34 The basic functions of the components of the syssys-tem are shown in Table 5.15 The overall function of the protection system is to prevent