A bow tie is developed during the design phase of a facility and, when it goes into operation, there is a regulatory requirement on the operator to have a “Barrier Management Strategy” for monitoring and maintaining the effectiveness of these safety barriers.
How can we make these bow ties “live” during the operating phase of an asset so that the real-time health of all aspects is easily visible and understandable? How can we automate data capture, processing and aggregation of barrier health score in a reliable and auditable way?
In practice there are many layers to this challenge and, as can be seen from the diagram on the following page, the information on the health and status of all the various barrier elements comes from many different systems (and some elements cannot be made live).
At Eigen we have solved this challenge and our software is already live and in operation doing just this.
An example of a bow tie in practice showing the different sources of health and status information.
Ingenuity builds a digital twin of your bow tie
Our Eigen Ingenuity platform architecture allows us to solve this challenge at all levels by breaking the problem down into the following three steps:
1. Create a data model or digital twin of all the aspects – ideally integrated as an extension to a full data model of a facility.
2. Link this model to the systems that store relevant information on the status of objects in the model.
3. Define the rules aggregating the health status throughout the model, from barrier safety elements and functions all the way up to Areas, Performance Standards, Systems and Major Accident Hazards (MAH).
Zooming in on the detail
Bow ties are a 37,000 feet view – they do not contain enough detail to make a digital twin on their own, but it is possible by using other information sources.
By way of example, below is an extract from a bow tie about preventing overpressure. Note that the descriptions of the preventative measures are very high level – “Platform ICSS” or “Operator Response”. If we use these as the basis for the model, we are going to hit problems very quickly because any problem with the status of the “Platform ICSS” object will affect (almost) every bowtie.
Instinctively one knows this is not right. An override on a smoke detector in say the flash gas compression area should not result in an impairment on the water injection overpressure protection system.
We need to zoom in on the details and narrow the scope of the object to be just those functions within the “Platform ICSS” relevant to this protective function.
Something like:
“Platform ICSS functions for the prevention of overpressure in the water injection system”
Now we can use things like the Safety Instrumented Functions (SIFs) to identify the specific control logic and instruments that are related to this particular hazard, and then add these to the model.
Challenges with data quality
On facilities where the bowties are well maintained and stored digitally, creating the data model can be scripted and is a well understood problem. However, issues such as those listed below can make the things more complicated.
Bow ties not available in electronic format
Where bow ties are not available in electronic format, or are just images in documents, a data capture process needs to be run firstto digitise the source data using OCR and image recognition tools.
Bow ties are at a generic level and have not been created for each area
In some cases, the bow ties for a facility are at a very generic level (such as above) and knowledge of their actual implementation is in the heads of staff and a few documents. This is essentially a data gap that needs to be closed as part of the initial model build through a combination of interviews with key staff, going through documents and scripting the generation of an “as is” digital version
of the bow ties.
Making a comprehensive digital twin – adding other dimensions
The bow tie is just one way of looking at the risk picture – it is a specific arrangement of the information for the purpose of identifying the causes and consequences of an event. And there are other ways that are useful to consider on an operating asset as
well:
– Area – protected area or physical location
– System
– Performance standard
This information comes from sources such as the master tag database and is usually in a well-structured format meaning it can be added to the model relatively easily using scripts.
Underpinned by a domainspecific knowledge graph.
The extract below from Eigen’s Data Model in Neo4j shows an example of how a physical item is connected to both the bow tie model directly via the bow tie Element and also links to the Performance Standard. Existing relationships to documents, areas, systems etc. were already in place before the Data Model was expanded with the bow ties.
By using a graph database as the basis for our digital twin, an existing model can be easily extended to include more information. Or a barrier model can be added to an existing data model.
In our example extract from a bow tie 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 “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 programme) will inform the calculation of the ongoing health of this protective aspect.
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.
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.
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.
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.
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-theless, 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 Competency Management System (CMAS) system, Operational Risk Assessments and Direct Manual Input of impairments can be incorporated in an online calculation of barrier health.
If a CMAS 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.
