Bowties 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, here’s an extract from a bowtie 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.
Bowties not available in electronic format
Where bowties are not available in electronic format, or are just images in documents, a data capture process needs to be run first to digitise the source data using OCR and image recognition tools.
Bowties are at a generic level and have not been created for each area
In some cases, the bowties 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 bowties.
Making a comprehensive Digital Twin – adding other dimensions
The bowtie 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.
The extract below from Eigen’s Data Model in Neo4j shows an example of how a physical item is connected to both the Bowtie model directly via the Bowtie 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 Bowties.
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 the next part of this blog we’ll look at dealing with protective functions that are not related to physical equipment.
