Why Is the Digital Twin of an Oil Refinery the Most Complex AI System You Will Ever Build?

Ask most engineering teams what makes a digital twin of an oil refinery technically difficult, and the conversation usually lands on platform selection. AVEVA or Honeywell? Which historian database? On-premise or cloud-native? Those are real decisions. They are not, however, where most projects fail.

The difficulty lives in the refinery itself. A crude oil facility runs thermodynamics, reaction kinetics, fluid dynamics, and real-time safety constraints simultaneously across several hundred unit operations, with no commercial tolerance for a model that drifts from physical reality. That combination puts a working digital replica in a different technical category from almost anything else you will build in industrial AI.

More engineering teams should understand this before they start.

What a refinery digital twin actually is

Walk into the control room of a modern refinery, and you will find simulation tools, historian databases, and SCADA dashboards that have been running for years. A digital twin for oil and gas is not an upgrade to any of them. It sits on top of all three at once.

What that looks like in practice: live sensor readings from your DCS and SCADA network feed continuously into a physics-based process simulation, while an AI inference layer reconciles the simulation state with what the instruments are actually measuring. Most engineers have worked with tools like AspenTech HYSYS or AVEVA DYNSIM to model steady-state behaviour or run operator training scenarios. That is a simulation — useful, but static. The digital twin keeps pace with current operating conditions rather than representing a fixed design-case scenario.

Process simulation versus digital twin

Think of process simulation as a map drawn before you travel. The energy digital twin is the live navigation feed: it shows where everything is right now, anticipates what comes next, and flags deviations as they develop. A map stays fixed. The live feed adjusts every few seconds.

That difference in behaviour is what drives most of the technical complexity. Operators can only rely on a twin if it is current — not last week's current, not this morning's current, but current as of the last instrument reading. Maintaining that fidelity across a facility that never stops running is the design challenge everything else builds on.

Learn more about how Go Wombat approaches the Oil and Gas industry, and see our deeper look at AI in oil and gas operations for context on where the technology currently stands.

The seven layers that make this system extraordinary

Ask any process engineer who has worked on one of these projects, and you get a consistent answer: the complexity does not live in any single layer. It accumulates.

Here are the seven layers that most organisations underestimate when they begin a refinery simulation AI project.

1. Physics-based simulation

A crude oil refinery runs thermodynamics, reaction kinetics, fluid dynamics, and mass and energy balances simultaneously across several hundred unit operations. Getting that right means solving systems of partial differential equations continuously, with state variables in the thousands updating on every clock cycle. There is no version of this that machine learning handles alone, because the governing physics cannot be approximated away.

2. Sensor data ingestion

A mid-scale refinery typically generates somewhere between 10,000 and 80,000 instrument tags, and those tags do not all behave the same way. Some carry latency that makes time-alignment tricky. Some drift gradually in ways that look, at first pass, like a genuine process shift rather than measurement degradation. A small fraction fail silently and keep reporting the last valid reading until someone notices. Getting clean, consistently time-stamped data into the simulation is a full engineering discipline on its own, separate from anything the AI layer does.

3. Data fusion and state estimation

The simulation and the sensor feed will always disagree, at least slightly. Reconciling them, a problem known formally as data reconciliation and state estimation, requires algorithms that can determine which discrepancies reflect genuine process changes and which are measurement artefacts. This is a class of problem most machine learning engineers have never encountered outside a refinery context.

4. AI inference on top of simulation

The ML components (predictive maintenance, yield optimisation, anomaly detection) must sit on top of the simulation layer, not replace it. A model trained purely on historical sensor data can generate outputs that look perfectly plausible under normal operating conditions and are physically impossible at the same time. The AI oil and gas operations sector has accumulated a substantial catalogue of failed deployments that collapsed at this exact junction, often because the problem did not surface until the twin was already in production use.

5. Control system integration

The twin becomes genuinely valuable when it can write recommendations back to the DCS without creating instability. That is safety-critical software territory, governed by IEC 61511, and it demands a level of formal validation far stricter than anything required in general software development.

6. Multi-unit dependency modelling

In a refinery, nothing operates in isolation. The output from the crude distillation unit (CDU) feeds the vacuum distillation unit (VDU), which feeds the fluid catalytic cracker, which feeds downstream treating units. Each unit's twin must propagate state changes across the entire train. A local disturbance in one unit produces cascading effects the model must track accurately.

7. Change management and digital continuity

A refinery is not a fixed installation. Over any 18-month window, a typical facility will have added capacity to at least one unit, replaced catalyst loads on others, retired ageing equipment, and run one or two capital projects that rerouted pipework or modified feedstock handling. Each of those changes needs to propagate into the digital twin within a defined tolerance window. Leave them unaccounted for, and the model starts drifting from the plant it is supposed to represent. Most organisations discover they have no formal process for this only after the drift becomes visible. By that point, re-establishing model accuracy costs significantly more than building the update workflow would have at the start.

This is not a list of edge cases. These are the core requirements of any serious deployment, and every layer depends on the ones beneath it.

If you are working with SCADA infrastructure specifically, our technical guide on how to secure a SCADA system covers the integration and cybersecurity challenges that sit alongside the digital twin work.

What the data tells us: real deployments

Theory is useful, but production evidence is better.

In Japan, Cosmo Oil deployed an AVEVA Process Digital Twin, running real-time optimisation across four crude units at two of its three refineries. Cosmo Oil is Japan's third-largest petroleum refiner, with a combined CDU capacity of 363,000 barrels per day across all three sites. Each optimised crude unit delivered upward of $2 million per year in savings, with payback in under 12 months. The project was scoped around a defined set of units, not the company's entire refinery network. That was intentional, and it is the correct starting point for an initiative of this complexity.

In April 2026, Honeywell announced a partnership with Dangote Petroleum Refinery in Lekki, Nigeria. Dangote is the world's largest single-train petroleum refinery, currently processing 650,000 barrels per day. The deployment covers digital-twin operator training simulators built on Honeywell Forge, connected performance monitoring across core processing units, and UOP engineering support. The collaboration supports a planned capacity increase to 1.4 million barrels per day within three years.

Both deployments share a pattern worth holding onto: they started with a specific, bounded use case before expanding scope. That sequencing is not a compromise. It is the only approach that reliably produces a system operators will actually trust.

Go Wombat has direct experience building and integrating connected industrial systems. Our SCADA system case study illustrates the integration complexity that underlies any serious industrial AI deployment. For a broader view of how the sector is shifting, our article on digital transformation in the oil and gas industry maps the wider technology trends driving these investments.

Physics-informed neural networks: the architecture that changes the picture

What changes when you embed physical governing equations directly into the model architecture itself, rather than training purely on data?

Take a standard neural network trained on historical sensor data. It will produce plausible-looking predictions under normal operating conditions, and when the process shifts outside its training range, the model tends to break without any obvious warning signal. In a refinery, where a miscalculated prediction about process behaviour can escalate quickly, that failure mode is not one you can accept and manage around.

PINNs work differently. Rather than learning from data alone, they have energy balances, conservation laws, and reaction kinetics embedded directly into the network architecture. A PINN is constrained by those governing equations even in conditions it was never trained on, which makes it far less likely than a purely data-driven model to output something physically impossible. That constraint is what makes real-time AI inference inside a refinery simulation workable at industrial scale, where edge cases are not edge cases at all; they are a routine part of operations.

Data scientists arriving from general ML backgrounds typically need significant re-orientation on projects of this type. The physics is not background context to be aware of. It shapes the model architecture from the ground up.

PINNs still require validated simulation baselines, clean physical parameters, and careful per-unit tuning before they can be trusted. The data engineering work upstream determines whether the AI layer can function reliably in practice. Architecture is a prerequisite, not a shortcut.

What it actually takes to build one

To build a working digital twin of an oil refinery, even at single-unit scope, you need a specific combination of expertise that rarely sits within one team by default.

The minimum viable combination looks like this:

• A process engineer with deep operational knowledge and hands-on experience with HYSYS or DYNSIM
• A data engineer who understands historian databases such as OSIsoft PI, time-series alignment, and sensor data quality
• A machine learning engineer familiar with physics-constrained models, not just general deep learning frameworks
• An integration specialist with direct experience connecting AI systems to DCS and SCADA environments in regulated settings

Beyond the team, there are data prerequisites. You need a minimum of two to three years of clean historian data, P&IDs in a digital format that can be linked to the simulation model, and a validated steady-state simulation baseline before any dynamic twin work begins.

On timeline, a single-unit twin typically takes six to nine months from baseline to operational. A full-train twin covering an entire refinery is an 18 to 24-month programme. These are not pessimistic estimates. They reflect what organisations with dedicated teams and good data actually achieve.

The integration with the control system is where most projects stall. Writing recommendations back to a DCS is categorically different from building a monitoring dashboard. It requires formal change management, safety analysis, and vendor coordination that the initial project scope often does not account for.

We build the AI and integration layers for industrial environments. Our machine learning services are designed for clients where physics constraints determine the model architecture, not just data volume. If you are not yet sure where to begin, our discovery phase service is structured to map out data readiness, team requirements, and integration architecture before any development starts.

Why most refinery digital twin projects fail

Most of the projects in this space that never make it to production share a pattern, and it is not a technology problem.

Data quality

An oil and gas operator in Northern Europe began a digital twin pilot with reasonable confidence in their historian data. Six months into the build, the project team found calibration gaps spanning three years, instrument tags pointing to decommissioned equipment, and no documented record of two capacity modifications made earlier (illustrative scenario, not a real client). The simulation baseline built on that data was unusable. Fixing it retrospectively cost as much time as building the original model.

Simulation and ML built by separate teams

Engineering teams produce a physics-based simulation. A data science team, working in parallel, trains ML models on the same sensor data. When the two outputs are brought together, they disagree, often enough to erode operational trust. On paper, each component works. In production, the disagreements between them are the problem nobody planned for.

Change-tracking neglect

A twin that was accurate on day one but receives no systematic updates becomes a liability within 12 to 18 months. Process modifications, catalyst changes, equipment replacements — the physical system shifts continuously. Without a formal process for pushing those changes into the model, the twin drifts, and operators stop relying on it.

The common thread is programme design, not technology choice. Teams that build data governance, integration architecture, and model maintenance into the project from the start have a substantially higher success rate than those that treat these as downstream concerns.

Our AI services and solutions practice is structured around helping clients design these programmes before a line of code is written.

What this means in practice

A digital twin of an oil refinery is a stack of interdependent layers: physics simulation, data engineering, AI inference, control system integration, and change management. Each layer depends on the quality of the ones beneath it. When teams treat any of those layers as a secondary concern, they tend to find out in production.

The organisations achieving real results worked the same way. They scoped narrowly at first and built the programme around what their data and their team could sustain. Cosmo Oil proved out unit-level ROI before expanding. Dangote started with operator training simulators before connecting them to live performance monitoring. Neither attempted a full-refinery twin in year one.

If you are evaluating a project like this, the most useful first question is not which platform to select. It is whether your data, your team, and your integration architecture are ready to support a system that must be accurate, maintained, and operationally trusted on an ongoing basis.

To map out what that readiness looks like for your facility, speak with our engineering team.