Using one platform for bowties, LOPA and quantitative risk assessment

Peter Lacey Risk Management News Leave a Comment

Many industries are embracing the use of bowties and layers of protection analysis to get to grips with the way their risk works.  Some professionals, such as process safety engineers, have been working with layers of protection analysis (LOPA) for many years.  A more recent (and exciting) application is the use of bowties to analyse fatality risk scenarios in mining and construction.

One of the key obstacles to embracing this type of analysis is the lack of easy tools with which to build these types of risk models.  Risk professionals in aviation, mining, oil and gas, process safety, and other fields know their risk well.  What is missing is the ability to translate that knowledge into useable models for analysis.

This is where having a single platform for bowties, LOPA, and quantitative risk assessment is a real advantage.  A key benefit here is the ability to pick the right style of model for the job, without needing to start over.  Better still is if we can have a common library of causes, risk controls, consequences and other factors being drawn from all of our models in one place.

Here we’re going to look at how we can use the different models, and how we can bring them together in one place.

Want to see what the models look like? Read on.

Want to skip ahead to how we bring them together in one platform? Scroll down to working with different models in one platform.

Bowties – an example from a mining and fatality risk context

Bowtie analysis is a flexible model of analysing risk through a combination of event tree and fault tree analysis.  On one side of the diagram, we model the faults and sequence of intervening factors leading up to an undesirable event.  On the other side, we model the way that our calamity unfolds and what steps are taken.

Mining and construction businesses have picked up the bowtie method in recent years as a great way of modelling how fatalities can be prevented in complex work environments (often where humans are a key driving factor of risk).

The bowtie kicks in at the point that a risk is identified as having a credible potential to cause a fatality. The method is to take these types of events (e.g. all the different ways that a worker can fall from height) and bring them together into one model.  The goal is to make the sequence of events within the risk more accessible, and to make decision-making more robust.

In the example below, we’re looking at the risk of a vehicle colliding with another vehicle.  This particular bowtie is imagining a mine site or a construction site rather than open roads.

The left hand side is looking at the causal pathways that can trigger our unwanted event (the accident).  Because we’re using a qualitative risk method, all our descriptions are in words: for example, excess speed is assessed as being “likely” to lead to a traffic collision.  Having a site speed limit is assessed as being a “weak” control, whereas an automatic speed limiter on vehicles is assessed as an “adequate” control for reducing the likelihood of speeding.

After our event has already begun (i.e. the vehicles are already colliding), we have an opportunity for interventions before fatalities occur.  In the model below, our seat belts are rollover protection system (roll cage) reduce the likelihood of a traffic collision causing our workers to be killed.

The advantage of the qualitative bowtie is that it makes the bowtie method accessible to a broad audience.  The frontline people who have the best risk knowledge (from the ground level) can understand how each pathway represents a way that the risk event can unfold.

For greater precision, we need a model that isolates and quantifies the risk.  This is where the LOPA model used in process safety can add more value.

LOPA – an example from process safety

Our LOPA model typically involves one cause and one consequence, or one cause with several alternate consequence outcomes.  This is because we’re isolating each of the causes to analyse it in detail. 

We’re also quantifying our assessment: so in the example below, rather than assess our procedures as an “adequate” control, we’re quantifying that the control will only work 9 out of 10 times (giving a probability of failure on demand of 0.1).

The overall approach is similar, but the process safety professional is working with a stricter set of rules around how the risk assessment is done.  The operator of the chemical plant needs to be able to demonstrate that their risks events would actually occur only after thousands of years.  The key difference here to our earlier mining example is that we’re potentially talking about multiple fatalities in nearby communities (e.g. from toxic gas releases), rather than being concerned with one or more workers being killed on an isolated mine site.  Hence, there are more rules about what criteria a control has to meet in order to qualify as an independent control, and there are industry-wide definitions of the effectiveness of certain types of controls.

Falling somewhere between bowtie analysis and LOPA is the idea of semi-quantitative risk analysis.  This is a broad descriptor, so let’s go with a tangible example.

SQRA – an example from aviation

The worlds of aviation, oil and gas, and energy are good exemplars of how semi-quantitative risk analysis (SQRA) can be applied to bowtie analysis.  We end up with a hybrid model with elements of LOPA and elements of the bowtie method. 

In aviation, for example, an accident can have an impact on local communities much like a chemical plant.  Accidents are also high profile in nature, and can have ramifications for the operation of other aircraft.

In the example above, we’re examining how a collision accident could occur on the ground (e.g. during take-off, landing or taxiing).  We have multiple potential causes of the scenario.  We have sequences of controls for each cause, and for each consequence.  Our likelihood (frequency) and control effectiveness ratings are quantified.  If nothing else, that enables us to think about how many years (or how many flights, how many hours of operation, etc.) we’re talking about when we look at causes and how well our controls work.

We can then take our overall risk rating in two ways.  The first way is to take our total consequence risk score, which is our treated likelihood (frequency) for each of our consequences multiplied by the severity score for each consequence.  We also have the option of using the semi-quantitative part of SQRA, by mapping our quantitative frequency value back to a risk matrix to give us a risk rating in qualitative terms (e.g. Rare x Severe = Medium).

It is easy to see how many businesses would potentially need to use more than one type of risk model to handle all of their risk.  For example, a mineral mining business might need to use bowtie risk assessments for the safety of workers at the mine, but then use LOPA to analyse risks at the refining plant that uses toxic chemicals.

Working with different models in one platform

Having gone through the examples above, you will notice that model has similar formatting (although the level of detail displayed varies).  This is because all three examples were generated using the same software platform.

The main benefit of this is that we have the flexibility to use different modelling methods, without ending up with a set of different diagrams that can’t be reconciled with each other.

The key to bringing bowties, LOPA and SQRA into one platform is to have a common set of rules and calculations running in the back-end.  We define how “Likely” corresponds to a frequency value, so that our platform can compare the results of a bowtie with a LOPA study.

All of these fields and intersections are user-definable in RiskView.  The platform provides the structure for bringing different analytical methods together.  It is then up to the business to determine or validate how they want to accomplish that.

At the most simplistic level, we have a carefully-worded risk matrix with colours.  We have a set of standard likelihood values, which we match back to quantitative frequency values.  The bowtie user will never see the numbers unless they switch over to SQRA, which keeps things simple.  The LOPA user will never see the worded likelihood descriptions, because they input frequency values directly into the LOPA study.

We do the same with severity values: we define a list of worded descriptions for different types of impact, and link these to quantitative values.

Having this framework in the background is what creates a seamless platform for the end-user.  The bowtie user, LOPA user, and SQRA user are only ever faced with the level of analysis which accords to their skill level.  The more expert users will be able to swap back and forth between analysis models without needing to manually edit anything.

Making it useful – detailed analysis

At the simplest level, this method of using a single platform for multiple risk analysis models allows reports like the one below.  Here we’re comparing LOPA and qualitative bowties side-by-side.  The software platform can easily report in this fashion because we’ve mapped our qualitative (worded) risk ratings against quantitative values.

Of course, there’s a lot more detailed analysis we can do with all of our risk model data in one platform.  It becomes possible to compare the controls being used in qualitative bowties to the same controls as they are used in LOPA.  This is even a good opportunity for starting the risk discussion around common controls, such as permits to work: for example, a process safety engineer will have a good concept of a control’s function and standard criteria, but the health and safety advisors may have first-hand experience of that control’s performance that would be useful.

The advanced analysis menu in RiskView supports this type of analytical work.  RiskView can provide a tabular list that shows the common controls across an entire library of bowties and LOPA studies.  Searches and filters can then be applied to identify useful cross-sections of the data.  This is the method we use for clients that ask for assistance in identifying and defining the common critical controls in their risk data.

This also makes the validation and review process easier.  Review can be done at the bowtie level, or applied using the grid view shown above.

Making it more useful – auditing

From the bowtie model view, we can pick out the critical controls needed to mitigate our risks.  That sets the auditing agenda.

Where organisations often struggle is managing the auditing of those controls after that point, given how many critical controls might be contained across all the bowties or LOPA studies.  Using the advanced analysis grid view described above makes a big difference to this process.

The grid view allows us to identify points of commonality, and can allows us to group together the same (or very similar) controls.  This makes auditing easier (by applying the same audit across multiple contexts) and makes reporting easier (reporting different areas of performance against the same abbreviated list of common critical controls).

In a larger business using a variety of different risk models, the audit reporting can look like the above.  This approach moves the business away from risk silos (gradually) and towards a common risk framework.  There will be areas that remain unique to particular risk domains, but there are many elements that can be brought together.

This “bringing together” of risk only works where there is a common platform or framework for risk.  In this particular case, there’s a common platform for producing bowties, LOPA studies, and SQRA models.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.