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.

What a refinery digital twin actually is

A modern refinery control room already has simulation tools, historian databases and SCADA dashboards. A digital twin for oil and gas does not replace any of them; it sits on top of all three.

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 used tools like Aspen HYSYS or AVEVA Dynamic Simulation (formerly DYNSIM) to model steady-state or dynamic behaviour and to run operator training scenarios. Those models run on design cases and scenarios; a digital twin stays in step with current operating conditions.

Process simulation versus digital twin

Process simulation is like a map drawn before you travel; a digital twin is the live navigation feed. It shows where everything is now, anticipates what comes next and flags deviations as they develop.

That difference drives most of the technical complexity. Operators can only rely on a twin that is current as of the last instrument reading, and keeping that fidelity in a facility that never stops running is the design challenge everything else builds on.

See how Go Wombat works with the oil and gas industry and our article on AI in oil and gas operations for where the technology stands today.

The seven layers of a refinery digital twin

The complexity does not sit in any single layer; it accumulates across them.

These are the seven layers that teams often underestimate when they start 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

Even a mid-sized refinery streams data from tens of thousands of instrument tags into its historian, 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 produce outputs that look plausible under normal operating conditions and are physically impossible at the same time. Deployments that fail at this point often do so only after the twin is 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 territory: it falls under the site's process safety management and management-of-change regime, must never compromise the independence of the safety instrumented system required by IEC 61511, and 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.

These are core requirements of any serious deployment, not edge cases, 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.

Real projects: Cosmo Oil and Dangote

In Japan, Cosmo Oil deployed an AVEVA Process Digital Twin that runs closed-loop real-time optimisation of its CDU operations. Cosmo Oil is Japan's third-largest petroleum refiner, with a combined CDU capacity of 363,000 barrels per day across its Chiba, Yokkaichi and Sakai sites. According to AVEVA, the CDU optimisation delivers $2.3 million a year in benefits, with payback in less than a year. The project was scoped around a defined set of units, not the company's entire refinery network, which is the right starting point for an initiative of this complexity.

In April 2026, Honeywell announced a collaboration with Dangote Petroleum Refinery in Lekki, Nigeria. Dangote is the world's largest single-train petroleum refinery, with a capacity of 650,000 barrels per day. The planned deployment covers Operator Training Simulators built on digital twins of Dangote's facilities, plus Honeywell Performance+ Services delivered through the Honeywell Forge platform across several core processing units, backed by Honeywell UOP engineers. The collaboration supports a planned capacity increase to 1.4 million barrels per day within three years.

Both projects are scoped around a specific, bounded use case rather than the whole refinery. We recommend scoping a first twin the same way.

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 (PINNs)

A standard neural network trained on historical sensor data produces plausible predictions under normal operating conditions, but when the process moves outside its training range, it tends to break without warning. In a refinery, where a wrong prediction about process behaviour can escalate quickly, that failure mode is unacceptable.

PINNs work differently. They build energy balances, conservation laws and reaction kinetics into training itself, typically as penalty terms in the loss function. That pushes the model to respect the governing equations even in conditions it was never trained on, so it is far less likely than a purely data-driven model to output something physically impossible. This is what makes real-time AI inference inside a refinery simulation workable in a setting where unusual operating conditions are routine.

Data scientists from general ML backgrounds usually need time to adjust on these projects, because the physics shapes the model architecture from the start.

PINNs still need validated simulation baselines, clean physical parameters and careful per-unit tuning before they can be trusted, and the upstream data engineering decides whether the AI layer works reliably in practice.

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.

At minimum, you need:

• A process engineer with deep operational knowledge and hands-on experience with HYSYS or DYNSIM
• A data engineer who understands historian databases such as the AVEVA PI System (formerly 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: 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.

Timelines depend mainly on data readiness and integration complexity. A full-train twin covering an entire refinery is a much longer programme than a single-unit twin.

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

Projects that never reach production tend to share one of three problems, and none of them is about technology.

Data quality

Illustrative scenario, not a real client: an oil and gas operator in Northern Europe began a digital twin pilot with reasonable confidence in its historian data. Six months into the build, the team found calibration gaps spanning three years, instrument tags pointing to decommissioned equipment, and no documented record of two earlier capacity modifications. The simulation baseline built on that data was unusable, and fixing it retrospectively took as long 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 gradually becomes a liability. Process modifications, catalyst changes and equipment replacements keep changing the physical system, and 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: data governance, integration architecture and model maintenance need to be part of the project from the start.

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

Both projects described above are scoped narrowly: Cosmo Oil's around CDU optimisation, Dangote's around operator training and a defined set of core processing units.

If you are evaluating a project like this, start by asking whether your data, your team and your integration architecture can support a system that must stay accurate, maintained and trusted by operators. Platform selection comes after that.

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