Platform · Digital twin
Bring your simulation. We'll bring the plant.
A digital twin stands on a data substrate: the governed model of the plant, the live state bound to it, and an honest record of everything that has happened. OrdinateDB is that substrate — it is not a simulator, and this page is precise about which parts are whose.
What a twin needs
Five requirements. Three are ours, one is deliberately not, and one is split.
The split, stated plainly: (a)–(c) are what OrdinateDB provides natively. (d) is deliberately out of scope — the section below says so in full. (e) is partially reachable today through the calc engine, and fully addressed by Foresight, a future service, labelled as such wherever it appears on this page.
What OrdinateDB provides natively
SPEC 01 §2–§3 · §11The model layer, the live state and the history — governed, and already there.
The composition tree with templates is the twin’s model layer SPEC 01 §3 — asset classes declared once, with series, units and limits, inherited by every instance. Typed topology links (feeds, drains-to, powers) give the structural graph a simulation binds to, traversable upstream and downstream rather than inferred from naming conventions SPEC 01 §11.
Live state and the full raw history come bound to the same model — no export pipeline, no “integration layer” to build first. And the property twins rarely get: the model itself is versioned. The twin can ask what the plant looked like in 2024 and receive the 2024 answer — hierarchy, bindings and topology as-of any moment SPEC 01 §2.
On requirement (e): expected bands and residuals against system-generated forecasts are the domain of Foresight SPEC F1 · future — a future, optional service that will publish its own rolling accuracy. It does not ship today, and nothing on this page pretends otherwise.
asset hx_e202 · shell_and_tube_v4 as_of 2024-06-01T00:00:00Z ├─ template v7 in force (v9 today) ├─ series 12 bound · raw retained ├─ links feeds ×2 · powers ×1 └─ upstream(hx_e202, via: feeds) └─ p_101 → t_204 → hx_e202 topology and bindings as configured on that date — not as they are now
the twin asks what the plant looked like in 2024 and gets the 2024 answer. paths, links and bindings resolve historically.
What we deliberately don’t do
SPEC 00 §4No CFD. No first-principles process simulation. No FEA. No 3D geometry engine.
Requirement (d) is not on the roadmap, and that is a decision, not a gap. Simulation is a different discipline and a different product category, built by teams who do nothing else. The project’s public non-goals list SPEC 00 §4 exists precisely to keep this class of feature-parity trap out of the codebase — absence you can cite, not absence you discover.
So, said with respect: if you arrived here shopping for a simulator, this section has just saved you a discovery call. Pick the one you trust — and when you have, the rest of this page is about feeding it properly.
absence as decision, not omission. changing a non-goal requires more ceremony than adding a feature — deliberately.
The pitch
Twin projects rarely fail at simulation. They drown in plumbing.
A behavioural model needs clean, contextualised, historised inputs with honest quality. What a site can usually hand over is a flat list of tag names — so the integration starts with months of reconstructing what the tags mean, which units they carry, and which readings to believe. That is a market fact about data plumbing, not a criticism of anyone’s simulation.
OrdinateDB hands the twin a governed model instead: typed, unit-checked, quality-marked, over an open and versioned API, on an open storage format. The simulation gets better inputs. Your twin project stops being 70% data engineering.
the integration starts at the model, not at a spreadsheet of tag names.
The middle ground
SPEC 05 §2Lightweight behavioural models live inside the historian. Heavy physics stays where it belongs.
A heat balance, a degradation curve, a mass balance — models like these do not need a simulator. They run inside OrdinateDB as WASM modules in the calc engine’s programmable tier SPEC 05 §2, producing ordinary derived series: deterministic by construction, versioned, with lineage back to rule version and input windows. Predicted-vs-actual residuals are just more derived series — trended, alarmed and audited like everything else.
The heavy physics — CFD, first-principles dynamics — stays in the simulator you bring, reading and writing through the same public API as everything else.
predicted-vs-actual as ordinary derived series. no wall clock, no network, no unseeded randomness — the module cannot be non-deterministic.
Whichever twin you buy or build, it stands on the plant’s data. That part is ready, open, and versioned.