How to make a Digital Twin of a Bowtie – Part 2

In this blog series we’re looking at how you turn a bowtie diagram into an online Digital Twin showing live barrier health information. The previous part looked at the level of detail required to make a working data model in practice. In this instalment we’re looking at the challenge of assessing the health of protective functions not directly related to the physical SECEs (Safety and Environmentally Critical Equipment).

In our example extract from a BowTie about preventing loss of containment due to overpressure, we have a couple of elements that are not related to individual SECEs; “Design Factor for Overpressure” and “Operator Response”.

The left hand Threat (Cause or Scenario) side of a Bowtie for a Loss of Containment event

The “Design Factor for Overpressure” is a discrete thing that happened in the past. It was either done or not done and there’s nothing you can do about it now (or at least not without a major refit!). There will be no live updates to the health of this element*. One can either include it in the model or not and it will have no bearing on the current health of the overall system. We like to include it for completeness as it means the model is accurate and can be a useful teaching aid as well.

*There are cases where the health of this element might change over time – for example, if the Design Factor results in a corrosion allowance being added to the wall thickness of pipework and hence the monitoring of the thickness of this corrosion allowance over time (as part of an Inspection program) will inform the calculation of the ongoing health of this protective aspect.

Then we have “Operator Response”. The health of this element can be digitised and is based on the information from at least three other systems (four if one also includes Operational Risk Assessments as part of this element).

If we expand the Bow Tie to show the protective elements preventing Degradation of Operator Response we can see we have Alarm Management, Process Surveillance and Operator Procedures/Competence.

Information on the health of the Operator Response can come from existing systems such as the Alarm Management System, the Realtime Historian and the Competency Management System

Alarm Management
Alarm Management here refers to the design and continuous improvement of the Alarms from the control system such that the operator is not overloaded and is able to take the correct action within the required timeframe – usually 10 mins otherwise the action should be automated. (See EEMUA 1911 , ISA 18.22 and API RP 11673 for the full details).

This in itself is a detailed subject but it is mature and specialist systems are available for Alarm Management such as Honeywell’s Dynamo or PAS which, when properly configured, generate live KPIs of performance against the guidelines. For example, the maximum number of alarms in a 10 minute period – target = 10 or less.

By connecting to an existing Alarm Mangement System, live Alarm Management KPI data can be used to inform the health of the Alarm Managent protective functions

Most oil and gas facilities have such systems already in place and, by connecting to these existing systems and leveraging their capability, Alarm KPI data can be used to inform the health of the Alarm Management protective functions.

Process Surveillance
Process Surveillance is again a broad subject so I will demonstrate the principle with an example, with the intention of sparking the readers imagination as to how this could be expanded to other situations.

Deviations between the Process Control and Process Safety Transmitters are “weak signal” informing of impaired barrier health (Image Source: a live Eigen Ingenuity installation)

Let’s take the example of transmitter pairs – most transmitters performing a safety function are separate from an equivalent transmitter performing a process control function. One useful surveillance operations is to compare the readings from these two equivalent transmitters and check that they are within x% of each other – say 5%. If they begin to disagree significantly then a check is required to find which transmitter needs to be recalibrated. Otherwise the likelihood of either an unintended trip, or operation beyond safe limits, is increased.

These checks are easily configured in the realtime historian and the results can be used to inform the health calculation of the protective functions.

Information from virtual tags in a realtime historian can be used to inform the health calculation of barrier elements

Operator Procedures and Competence
Tracking the completeness of Operating Procedures and the training of operators is necessary to assess the health of the barrier elements here. Active Operational Risk Assessments may also be relevant.

Assessing Operating Procedures, and also possibly Operator Competence, is likely to include more qualitative elements and is hence harder than the qualitative nature of the two examples above. But it is possible none-the-less, and even if it does involve an element of human judgement, by including it in the overall model a complete picture is gained. And this visibility can also improve the accuracy of the human judgement as an awareness of the impact of such judgements becomes more widely understood.

Information from a CMAS system, Operational Risk Assessments and Direct Manual Input of impairments can be incorporated in an online calculation of barrier health

If a Competency Management System is available then direct, qualitative, information can be taken from these for the specific Operators and also workers that will be performing other tasks. This can be extended to a more advance level later that takes account of the competencies required for different maintenance activities and assesses these against the competencies of those people offshore available to perform these activities.

Active Operational Risk Assessments may be available from a system such as DNV’s Synergi. If so then they can also be used directly in the calculation of barrier health.

In the next part of this blog we’ll consider the elements of a BowTie that are hard to model such as the Organisation elements and elements that appear on both sides of the BowTie.

  1. EEMUA Publication 191 “ALARM SYSTEMS – A guide to Design, Management, and Procurement”
  2. ANSI/ISA-18.2-2009 “Management of Alarm Systems for the Process Industries”.
  3. API Recommended Practice 1167 First Edition, December 2010

Read Previous Post (How to make a Digital Twin of a Bowtie – Part 1)

written by

Murray Callander

posted on

May 30, 2021

you may also like...

Agile Software Development Business Internet Techology Concept

What is Agile?

You have probably heard software developers talk about being Agile, and maybe wondered what they…