---
title: "Digital twins in oil and gas: what the data actually looks like"
date: "2023-03-01T06:00:00.000Z"
categories: "Digital twins"
canonical: "https://xraph.com/writing/twins-in-oil-and-gas"
---

# Abstract

Decades of tag naming conventions, four systems of record that disagree, and connectivity that is genuinely intermittent. The problems are not the ones the vendor slides show.

## Where the difficulty is

Presentations about upstream digital twins tend to show a rendered platform with live values floating over it. The rendering is not the hard part. The hard part is that the values come from four systems that do not agree about what anything is called.

A survey of the field lists integration and data quality among the dominant challenges, which matches what I have seen closely [1].

## The four systems

**The maintenance system** holds the asset register: equipment, hierarchy, work orders, criticality. Its identifiers were assigned by whoever commissioned the facility.

**The historian** holds time series against tag names. Those follow a plant convention that encodes area, unit, type and sequence, and the convention changed at least once in the facility's life.

**The engineering drawings** hold the topology: what is connected to what, in what order, through which valves. Often as PDFs. Sometimes as paper that was scanned.

**The spreadsheet** holds whatever the site actually relies on, maintained by one person, more accurate than the other three, and mentioned in no architecture diagram.

The same pump is in all four with a different identifier in each, and at least one identifier contains a typo that has been there for a decade and is now load bearing, because downstream reports match on it.

## Why identity is the first problem

Nothing downstream works until the four sources agree on what a thing is. If identity is assigned when a record is first imported, importing a second source creates a duplicate, and you need matching, merging, un-merging, and a policy for relationships attached to a merged record.

Deriving identity from a normalised natural key instead makes ingestion converge by construction. The difficulty moves entirely into the normalisation rule, which is site specific and needs to be strict. Over-merging is silent and under-merging is visible, so the default should be strict.

## The connectivity reality

An offshore facility has a satellite link that is expensive, limited and genuinely unavailable during weather. An onshore wellsite may have cellular coverage that varies by hour.

The consequences are concrete. Buffer at the edge, because the link will drop and the data must survive. Expect a flush of several hours at once when it returns. Never make a control decision that depends on the link. Size any reordering window per site rather than globally, because a satellite site and a wired unit differ by orders of magnitude in how late their data arrives.

## Standards that matter here

OPC UA is the interoperability layer worth building against, since it carries an information model rather than only values [2]. ISA-95 gives the vocabulary for equipment hierarchy and the boundary between operations and enterprise systems [3].

The NAMUR Open Architecture concept is directly relevant to the security question, because it describes how to take monitoring data out of a control system without creating a path back in [4]. That one-way property is what makes a twin acceptable to the people responsible for the control system, and IEC 62443 is the framework they will hold you to [5].

## The advice I would give

Spend the first phase on identity and topology, with no visualisation at all. It is unsatisfying, nobody can see it, and every later phase depends on it. Projects that start with the rendering spend their second year discovering that half the tags point at equipment that was replaced in 2015.

# References

1. Thumeera R. Wanasinghe et al., "Digital Twin for the Oil and Gas Industry: Overview, Research Trends, Opportunities, and Challenges", IEEE Access, vol. 8, pp. 104175-104197, 2020 <https://doi.org/10.1109/ACCESS.2020.2998723>

2. International Electrotechnical Commission, "OPC Unified Architecture", IEC 62541

3. International Electrotechnical Commission, "Enterprise-Control System Integration", IEC 62264 (ISA-95)

4. NAMUR, "NAMUR Open Architecture: NOA Concept", NAMUR Recommendation NE 175, 2020

5. International Electrotechnical Commission, "Security for Industrial Automation and Control Systems", IEC 62443

---

*Unpublished draft. Not peer reviewed and not submitted to a venue.*
