Play by the rules – applying CCPS/EI Guidelines to an Existing Bowtie

Describe credible threats and consequences

After the hazard and top event are defined, the next step is to determine the threats and consequences. Since consequences normally are more direct than threats in events chains, many bowtie experts prefer to create consequences ahead of threats. According to CCPS/EI guidelines, the consequence should be described as ‘[Damage] due to [Event]’; the threat should be direct, specific, credible, sufficient, and not a barrier failure. The more precise the description is, the easier the identification of barriers will be.

In Figure 2a, some common mistakes are shown. Except for a general description of fire, the consequences only describe damages (e.g. human, property, organization, and environment damages). A well-worded consequence should include how the impact happens, for example in Figure 2b ‘Large pool fire in the tank bund area leading to fire related injuries to personnel’ elaborates on a consequence event and impact as in a credible scenario. This description not only explains the scale and context of fire but also refers to the impact on people, which is indispensable for further risk assessment.

‘Overfill’ is a common threat for creating a LOC bowtie. However, since this is a specific bowtie in the process field, we need to know how the ‘overfill’ causes the top event ‘loss of primary containment’. Therefore, in figure 2b, the ‘overfill’ is described as ‘Parcel (volume) too large for the space in tank’. This shows the specific and credible causal event or state.
Summarized changes:

• Change the top consequence to move away from ‘damage’ to an event and incorporate the middle (second) consequence into it.
• Change the last consequence from ‘damage’ to an event.
• Delete the consequence ‘injure/death’.
• Change the top threat to being more meaningful about how the tank is overfilled.

Ensure the quality of both preventive and recovery barriers

Preventive barriers and recovery barriers share some common characters. According to the guidelines, they should be effective (functional), independent, and auditable. To check the barriers on the prevention side against the guidelines, the first question is 1) does the barrier on its own stop the threat from causing the top event? If the answer is no, then the second question is 2) does this barrier relate to other barriers in this threat line? If the answer is no as well, it is not a proper barrier and we delete it. A preventive barrier is effective if it is capable on its own of preventing a threat developing into the top event. The way to validate preventive barriers applies similarly to check the recovery (mitigation) barriers. In this example, here we only elaborate on the preventive side.

In the original bowtie, the barriers ‘Ensure an appropriate overfill design with containment’ and ‘Periodic inspection of the overflow system’ cannot independently prevent the threat from becoming the top event. We haven’t found any related barriers in the threat line of the ‘Overfill of storage tank’ as well. Thus, we leave them out.

Summarized changes:

• Delete the improper or ineffective barriers according to guidelines.

If the answer to the second question (does this barrier relate to other barriers in this threat line?) is yes, we need to group the barriers with a common barrier name in a family field. When we define a barrier family, we consider the functional phases of a barrier (Detect – Decide – Act), the integrity of safety-critical equipment, the implementation of a barrier including a whole PDCA cycle, etc. (for further understanding of barrier families, please click here).

In figure 4a, we distinguish two barrier families among the six barriers. These two families are independently functional. For example, the three barriers, ‘High level trip system’ ‘Periodic inspection of the inlet trip valve’ and ‘Overhaul the inlet trip valve’, are grouped together as ‘Independent high level trip’. The ‘Periodic inspection’ and ‘Overhaul of the trip valve’ are not barriers on their own capable of stopping the threat from becoming the Top Event, but they are associated with the high- level trip system.

Summarized changes:

• Group barriers to achieve the (prevention, control or mitigation) function independently.

When considering barrier types and function phases according to the CCPS/EI guidelines, the ‘High level alarm’ is missing an element and the ‘Operator response’ as the alarm on its own does not truly meet the CCPS guidance on barrier rules. Here, a recap of the barrier rules is required (i.e. barrier is effective, independent and auditable). A barrier is auditable if there is a means to check that it works and delivers its functionality on demand.

Summarized changes:

• Complete partial barriers in order to accomplish the barrier function.

• Ultimately, remove the grouped elements and create standalone barriers named as the families if a concise bowtie is needed. Switching on the family grouping display feature (BowTieXP Advanced software only) can be enough.
• Consider if there are any missing barriers and add them.

Check, check, double check

In summary, this blog illustrates how to improve an existing bowtie following the CCPS/EI guidelines. After fully understanding the definitions of the basic elements, one needs to check every element carefully with the guidelines. If the bowtie has any flaws, one should edit them and record the editing actions. Creating a good bowtie requires thorough checks of all elements and sometimes repeat this to update a bowtie.

^{© CGE Risk. 2020 – The copyright of the content of this blog belongs to CGE Risk Management Solutions B.V.}