Chapter 14 Annex D - Bow Tie Methodology

Introduction to Bow Tie Risk Methodology

The bow-tie methodology is a useful tool that is similar in process to a Threat Block Diagram, consolidating a ‘fault tree’ and ‘event tree’ either side of a Loss of Control point. Thus, the bow-tie methodology is a convenient way to visualise the various complex elements of risk into a single, simple diagram. This allows effective and efficient communication of the risk management process, and an immediate view of the benefits offered by the various risk treatment options. An explanatory diagram is shown at Figure D-1.

Figure D-1: Bow Tie Diagram

Hazards

The first step in the bow-tie process is to clearly describe and understand the Hazard, which sets the context and scope of the RM process. The Hazard defines the desired activity within the normal operating environment, where control has not yet been lost, but which has the potential to cause harm if control is lost. A Hazard can be focused on a condition, object or activity. To effectively define a Hazard, the following points should be considered:

Describe the Hazard in its controlled state. Hazards describe a condition where there is a potential for harm, so avoid terms that describe the situation where control has been lost over the Hazard.

Include appropriate detail. It is important to be specific throughout the Hazard identification process, as vague Hazard descriptions can lead to large and complex risk assessment and management procedures. This will allow application of effective and deliberate control measures to manage specific Hazards. It can often be helpful to include the situational context (such as location and phase of operation) as well as providing some indication of scale (such as timeframe or people involved).

Top Events

Top Event is the point in time describing a deviation from the desired state or activity, at which there is a loss of control over a Hazard. A Top Event is considered an unsafe state – although the Top Event has occurred it is not yet an accident or incident, as there is still time for the Recovery Controls to intervene and prevent or mitigate the consequence. To effectively define a Top Event, the following points should be considered:

The Top Event should not be the consequence or outcome. Top Events are not incidents, but have the potential to become incidents if nothing is done to effectively control them. For example, a Top Event could be described as an engine failure; the engine failure is an unsafe and uncontrolled state, however is not yet an accident, instead having the potential to become an accident should no controls prove effective.

Hazards can lead to multiple Top Events. During Hazard identification and analysis, it could be possible to identify multiple Top Events for the same Hazard as a loss of control could occur in different ways. Therefore, a single Hazard can generate several bow tie models. Trying to combine multiple Top Events into one RM procedure, often by utilising an overly vague Top Event definition, can lead to a confusing bow tie, which may not effectively manage the specific risk. Therefore, careful selection of an appropriately detailed Top Event will enable a more effective RM process.

Causes

Causes describe credible circumstances that could directly result in the Top Event (loss of control) being realised. They are the ‘why’ or ‘how’ a Top Event could occur. Typically, there will be multiple causes that lead to the realisation of the Top Event. To effectively define causes, the following points should be considered:

The Cause should lead directly to the Top Event. The causal link between Causes and the Top Event must be clear, without further clarification necessary.

The Cause should independently lead to the Top Event, without requiring input or interaction with other Causes. If two Causes are required to occur in sequence for the Top Event to occur, it is often appropriate to reformulate the Causes into one description that capture the specific threat.

Causes are not control failures. As controls are designed to prevent a Cause triggering the Top Event, they are not conditions that will independently cause a Top Event.

There is no requirement for Causes and Top Events to align in time. It is entirely possible for a Cause to occur well before a specific Top Event, and not act until aspecific circumstance arises. For example, a latent Cause, such as a programming fault, could lay in a system for a significant period prior to affecting the operation.

The UK CAA and CASA use the nomenclature of ‘threat’ for this component of the bow-tie. The terminology of ‘cause’ has been used to align with the bow-tie module in Sentinel.

Consequences

Consequences describe the potential impact or hazardous outcomes that may result from the Top Event and loss of control. Typically, there will be multiple consequences resulting from the realisation of the Top Event. To effectively define a consequence, consider describing the anticipated loss or damage, and the direct reason for loss or damage. To do this it is best to use the descriptive formula ““<damage/impact> due to <event>”.

Controls

Controls, sometimes also referred to as barriers, describe the measures taken to either:

prevent, or reduce the likelihood of, a Cause initiating the Top Event (Preventative Control); or

eliminate, or mitigate the severity of, the consequence once the Top Event has been realised (Recovery Control).

Controls can be based on personnel (behaviours, actions) or materiel (hardware, software). Controls should have the following characteristics:

Effectiveness. Must be able to prevent the Top Event or mitigate a Consequence by acting as and when expected. Effective controls should have the capacity to detect the threat, provide a preventative or recovery action, and describe the action taken to affect the desired outcome (ie “Fire detection system” is not effective as it alone is not capable of mitigating the expected consequence, merely detecting danger. “Automatic operation of fire detection and suppression system” is effective as it has detected, decided, and acted in order to affect the Top Event).

Independence. Control should be functionally independent of the Cause, Top Event or Consequence. Controls that rely on the operation of other functions could lose effectiveness if that function is compromised by the Cause, Top Event or Consequence (ie a system that relies on engine power will not be an effective control against an engine failure).

Auditable. Control must be capable of being evaluated for efficiency and effectiveness to very expected performance.

Defeating Factors

Defeating Factors are factors that can defeat, or reduce the effectiveness of, a control. They can affect both Preventative and Recovery Controls. Defeating Factors should be used sparingly to highlight real issues, and are not mandatory. Effectively defining a Defeating Factor, includes:

using the same principles as a Cause, however the threat pathway is focused toward a barrier, not the Top Event. This mean Defeating Factors are not capable of causing the Top Event themselves

avoiding repetition and duplication. While a Defeating Factor may be relevant for multiple controls, focusing only on their effect on critical controls will allow the RM process to concentrate on the most pertinent factors.

Like Cause Controls, Degradation Controls can be developed to prevent or mitigate the impact of Defeating Factors. However, further defeating factors should not be developed for those controls (ie do not nest Defeating Factors).

The nomenclature of ‘escalating factor’ for this component of the bow-tie. The terminology of ‘defeating factor’ has been used to align with the bow-tie module in Sentinel.

Bow Tie Application in Sentinel

Sentinel has the ability to develop Bow Tie models for any risk in the Risk Module. There is also the functionality to perform:

Cause Contribution Assessments. Each Cause can be assessed to rate its relative contribution to the risk.

Control Effectiveness Assessments. Each control can be assessed to rate its effectiveness, displayed as a numerical value (0 being non-effective, 100 being fully effective).

Status Assessment. Each element of the Bow Tie, expect the Top Event, can be evaluated and its status displayed (eg proposed vs implements controls).

Identify Control Breaches. These are controls that have failed, contributing to the occurrence of the Top Event.

Identify Safety Critical Controls. These are controls that have a safety critical effect.

Critical Control Mode. This reduces the controls displayed on the Bow Tie to show only those controls which have been flagged as Safety Critical.

Score Card. This shows the overall risk score, calculated from the Cause and Control assessment scores.