Ask the plantbefore you tell it.
Every DjiniousCC deployment runs a physics model of the plant it supervises, bound to the same tags, driven by the same configuration. A conventional SCADA can tell you what happened. A Digital Replica lets you pose the change first, and measure the answer, without touching the field.
A model that computes, not a picture that rotates
Each equipment family — turbine, inverter, battery, pump, exchanger, compressor, filler — carries a behavioural model that computes its state from its inputs. Those models are bound to the same tags the live plant reads and writes, so the replica is not a parallel drawing of the plant: it is the plant's own asset register and tag namespace, computed instead of measured.
- Behavioural (F1) physics per equipment family, shared by the live simulator and the proving twin
- Bound to the real asset register — the same assets, the same tags, the same units and limits
- Every tag carries a quantity kind, a unit and its limits, so a model value and a plant value are always in the same terms
- The same historian, so a value the replica computes is trended and queried back exactly like a measured one
It runs beside the plant, not instead of it
The replica is not a sandbox you go to when the plant is down. It runs on the deployment that is supervising your plant right now. Each asset independently carries a data-source mode — a real device read, or the model — and whichever it is, it says so on the screen. A plant can be fully live with a replica running alongside it.
- Per-asset data-source mode: real device or model, switchable per asset or plant-wide
- A SIM or LIVE badge on the asset register, the twin and the asset detail, so no one mistakes a computed value for a measured one
- A LIVE asset whose device is down reports not-connected — it never silently falls back to the model
- Configuration snapshots carry a deployment mode of production, simulation or mixed, and it is recorded
Isolated structurally, not by policy
A dry-run cannot reach the field because there is no path from it to a connector — not because a flag says it should not. The run maintains its own setpoint and state maps, and every command a procedure under test issues is caught and recorded before any driver sees it.
- Every field command the procedure issues is intercepted and listed on the run
- A virtual clock, so a ten-minute excursion is evaluated in seconds
- A seeded RNG — the same seed gives the same trajectory, bit-exact on replay
- Both the scenario's assertions and the procedure's own acceptance criteria are checked, and the run passes only if every one of them holds
Three things a conventional SCADA cannot do
Prove a procedure before it runs
An operating procedure is dry-run against the replica before anyone approves it. The commands it would issue are intercepted and listed, its assertions are evaluated against what the replica actually measured, and the verdict is recorded against that version of the procedure.
Pose a scenario and measure the answer
Declare a condition — a gust front, a cold snap, a fouling excursion, a suction restriction — and run it. The replica reports what the plant would do, as measured aggregates against the limits you set, not as an opinion.
Rehearse without touching the field
Train an operator, walk a new engineer through an upset, or rehearse a seasonal changeover on the replica of the plant they actually run, with its real tag names and its real screens.
A dry-run only counts if the baseline fails
Every procedure below ships with the scenario that proves it. The same scenario is run twice — once without the procedure, once with it. If the baseline passes, the procedure has proven nothing, and DjiniousCC shows you that.
| Plant | Scenario | Measured | Baseline | With procedure |
|---|---|---|---|---|
| AQUA | UF-03 fouling excursion | Transmembrane pressurelimit 1.35 bar | 1.62 bar — fail | 0.56 bar — pass |
| CAMG | CMP-01 suction restriction | Anti-surge marginlimit 12 % | −32.3 % — fail | +16.6 % — pass |
| BLN3 | Filler overspeed push | Reject ratelimit 3.5 % | 9.40 % — fail | 1.90 % — pass |
| PROV | High-wind gust front | Wind-field powerlimit 1.3 MW | 3.60 MW — fail | 1.08 MW — pass |
| MEDI | Cold snap capacity shortfall | Supply headerlimit 67 °C | 61.63 °C — fail | 72.50 °C — pass |
The same replica, wherever the plant is easiest to read
2D synoptics
ISA-101 mimics authored in the Builder and rendered by the Runner from one screen record.
Orbitable 3D
The same screen record as a 3D scene, with primitive models or imported CAD — OBJ, STL, glTF, STEP and IGES.
Geo-twin
When the plant is a district, the replica is the district — real building footprints over open orthophoto imagery, bound to their substation assets.
Reality capture
A LiDAR or photogrammetry survey of the plant as it was actually built, with equipment tags dropped onto the point cloud.
Two things it is worth knowing it will not tell you
This is control software, so the page ends with the limits rather than hiding them. If either of these is what you need, say so on a call and we will tell you plainly where we are.
It does not predict or forecast
There is no forecasting, no trend extrapolation and no predictive model in the product. The replica answers a scenario you pose — it does not tell you unprompted what next week looks like.
It models behaviour, not first principles
The physics is behavioural, at the fidelity level the platform records as F1: good enough to prove that a curtailment holds a limit, not a CFD or a detailed thermodynamic model.
Bring a change you are afraid to make.
One procedure you run today, and the condition that makes it risky. We will model the equipment, author the procedure and dry-run it in front of you — baseline first, so you watch the assertions fail before they pass.