An adaptive digital twin is only as good as its data

A digital twin that forecasts biomass, flags an off-spec batch, or recommends a feed adjustment is doing one thing underneath: running a model against the real state of a running process. The model gets the attention. The data layer decides whether any of it works.

Data exists. Usable data does not.

Walk into most bioprocess facilities and you will not find a shortage of data — you will find the opposite. Historians hold years of it. The problem is that “we have the data” and “a model can use the data” are very different statements. A twin needs signals that are live, complete, correctly labelled, and in context. Getting there is where most digital-twin efforts quietly stall — long before anyone argues about which algorithm to use.

Three ways plant data resists a model

It speaks incompatible languages. OPC UA on newer equipment, Modbus TCP and Siemens S7 on installed skids, MQTT from edge devices, MTP on modular units. Each source exposes its own interface, and connecting a new instrument becomes a bespoke integration task rather than a configuration.

It has no shared meaning. Underneath the protocol, most sources hand you a flat list of tags with local names — AI_0473, TIC_112.PV — and no statement of what they are. A dissolved-oxygen probe on one skid and the same probe on the next can be named nothing alike. Feed that raw into a model and you have modelled a spreadsheet, not a bioreactor.

It has no context. A number without its unit, its timestamp, its sampling rate, and the batch and phase it belongs to is not an observation a model can trust. Aligning signals in time, resolving units, and attaching each value to the run it came from is unglamorous work — and it is the difference between a twin that reasons about a batch and one that hallucinates about a stream of floats.

Historians were built to record, not to reason

SCADA and historians did their job: they run the plant and keep a faithful log. They were never designed to hand a model a clean, typed, contextualized picture of the process in real time. Expecting them to is where a lot of twin projects meet reality.

What we build instead

Modica’s connectivity layer is the quiet foundation under the twin. It exists to turn the mess above into a model the twin can reason about:

One hub, many protocols. A driver per protocol, so a new source is a configuration — not a project — with redundant connections and a watchdog on stale data.
Standardized types. Raw tags are mapped onto reusable, typed modules following the Module Type Package standard (VDI/VDE/NAMUR 2658, published as IEC 63280) — the same plug-and-produce approach the process industry uses to integrate modular skids independently of the controller vendor. A pump, a valve, an analyzer becomes a known type with defined signals.
Automatic device detection. Define a standard once and matching equipment populates the inventory on its own — so scaling from one reactor to a fleet is not a manual re-mapping exercise each time.
A monitoring channel, alongside control. In the spirit of NAMUR Open Architecture (NOA), the layer reads plant data through a second, monitoring-oriented path — so the twin gets what it needs without reaching into the control system that keeps the process safe.

Why this decides whether a twin is trustworthy

The value of a digital twin is the simulation and prediction it enables. But a prediction inherits the quality of the picture it was made from. Clean, standardized, contextualized data is what lets the twin model a real bioreactor — with real critical parameters, updated live — instead of a snapshot pasted from a report. The connectivity layer is one feature, not the product; it is simply the feature the product cannot be trusted without.

We go deeper on the simulation side — golden envelopes, uncertainty bands, and prescriptive recommendations — in the companion pieces.