Nothing reaches the plantuntil it has been proven.
DjiniousCC is a complete SCADA system — acquisition, historian, HMI, alarms and commands — with a physics twin of your plant built into it. Which means a change can be proven on the twin before it touches the field. One licence per site. Everything unlimited.
- Observe
- Author
- Prove
- Act


A complete SCADA system, not a component of one
Everything a supervisory system has to do, in one product with one data model — so there is no integration seam between the tag you acquire, the alarm it raises and the command you send back.
Acquisition
OPC-UA · MODBUS TCP · SPARKPLUG BGenuine protocol stacks polling at 1 Hz. A tag in LIVE mode takes its value from a device read or reports not-connected — there is no silent fall-back to a model.
Historian and trends
TIMESCALEDBEvery tag historised and queried back through the same API that serves the live value. If the historian is down, a trend says so rather than drawing an empty chart.
HMI, built and run
ISA-101Draw a mimic in the Builder and the Runner renders the same components from the same screen record. 2D synoptics and orbitable 3D scenes, with no second drawing set to drift.
Alarms
ISA-18.2Priority, shelving, suppression, out-of-service and second-person acknowledgement — the management lifecycle, not just a red list.
Commands and interlocks
READ-BACK VERIFIEDEvery write passes the asset's interlocks and a policy gate, then confirms against an independent applied-setpoint echo rather than the register it just wrote.
Procedures
BPMN 2.0Operating procedures as versioned, statically validated artefacts executed by a token runtime — with a validation report and a record of who or what authored them.
One licence. One site. Nothing metered.
DjiniousCC is licensed per site — one physical plant — not per tag, per client or per screen. Add operators, grow the tag count, build more screens, connect more devices: the licence does not change. Nobody should be deciding which signals are worth historising because of a licence.
- TagsUnlimited
- Clients and usersUnlimited
- ScreensUnlimited
- Device connectionsUnlimited
- Concurrent designersUnlimited
- Digital ReplicaIncluded
What a conventional SCADA leaves you to solve
We do not name vendors, and we do not claim every system has every one of these problems. These are the properties of the category as most plants run it today.
| Axis of comparison | Conventional SCADA | DjiniousCC |
|---|---|---|
| Licensing | Per tag, per client, per screen — the estate is metered as it grows | Per site, everything unlimited, the Digital Replica included |
| Digital twin | A separate product with its own data model, or nothing at all | The same assets, the same tags, the same historian — one model |
| Testing a change | On the running plant, or on a spare PLC on a bench, or not at all | On an isolated twin, with assertions, and the baseline must fail first |
| AI | Bolted on through an external API the control room cannot depend on | In the loop, with a deterministic core that needs no external model |
| Who may act | A role and a password | An authority class and an autonomy level, granted with a justification and an expiry |
| When a driver drops | The last value, held — or a lamp that stays green | The tag reports not-connected and the lamp goes grey |
The last row is the one worth arguing about. A system that holds the last value when a driver drops is telling the operator something it does not know.
A Digital Replica, not a diagram
A conventional SCADA shows you what the plant is doing. DjiniousCC also runs a physics model of that plant, bound to the same tags — so a change can be posed as a question and answered before it becomes a command. This is what a standard SCADA does not give you, and it is why the rest of the loop is possible at all.
- Behavioural physics per equipment family, bound to the tags the live plant already writes
- Runs beside a live plant, not instead of one — per-asset SIM or LIVE, switchable, and badged on the asset register, the twin and the asset detail
- Structurally isolated: every command a dry-run issues is intercepted before a connector sees it
- Reproducible by construction — virtual clock, seeded RNG, bit-exact on replay


Four stages, and a gate between intent and the field
This is the whole product. Everything else — the historian, the alarm engine, the drivers, the twin — exists to make one of these four stages true.
- 01
The plant, and its twin, in one place
Real-time supervision on ISA-101 high-performance screens, backed by a continuously synced digital twin. Neutral grey is the resting state; colour means something is wrong.
- 1 Hz acquisition over OPC-UA, Modbus TCP and MQTT Sparkplug B — real drivers, not adapters-in-name
- Every tag historised to TimescaleDB and queryable back through the same API
- ISA-18.2 alarm management: priority, shelving, out-of-service, second-person acknowledgement
- Mimics you draw in the Builder are the same graphics the Runner shows — no parallel drawing set
- 03
Run it against a twin that cannot touch the field
The procedure is dry-run on an isolated simulation twin with a virtual clock and a seeded RNG. Field commands are intercepted. Assertions are evaluated against what the twin actually measured.
- Structurally isolated: every command the procedure issues is caught before a connector sees it
- Reproducible: same seed, same trajectory, bit-exact on replay
- Run the scenario without the procedure first — the baseline must fail for the proof to mean anything
- Both the scenario's assertions and the procedure's own acceptance criteria are checked
- 04
Execution a regulator could follow
Approval issues real commands through interlocks, policy and read-back. Authority classes bound what an agent may ever request; autonomy levels bound whether it may execute at all.
- Authority C0–C6 and autonomy L0–L4, granted per agent, per scope, with an expiry
- Interlocks evaluated before every write; a failed check is an incident, not a retry
- Read-back from an independent applied-setpoint echo — never the register just written
- Kill switch, second-person approval, and a timestamped, attributed audit trail
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 |
Read off the isolated simulation twin. Baseline and mitigated runs use the same scenario, the same seed and the same virtual clock.
The loop does not care what the plant makes
The same acquisition, twin, alarm and policy machinery runs a wind farm, a drinking-water works, a gas processing skid, a bottling line and a city district-heating network. Each is a real configuration in the platform — assets, tags, mimics, alarms and a proven procedure.

MEDIDistrict energyEuroméditerranée District Energy Network
A seawater-source district-heating network: two intake pumps and two seawater exchangers feeding three heat pumps, two backup boilers and a stratified thermal store, distributing through two network pumps and a differential-pressure valve to thirty consumer substations. The network is simulated; the city under it is not — every substation sits on its real IGN BD TOPO® building footprint in the Euroméditerranée quarter. It is a demonstration network on open data, not any operator's plant.
44 assets · 301 tagsRead the case →
AQUAWater & wastewaterVaucluse Water Treatment Works
A 42 Ml/d municipal drinking-water works: raw-water intake, coagulation, three ultrafiltration skids, UV and chlorine disinfection, clearwell storage and pressure-managed distribution.
16 assets · 116 tagsRead the case →
CAMGOil & gas midstreamCamargue Gas Processing Skid
A midstream conditioning and export skid: emergency shutdown valve, two three-phase production separators, pressure control, two export compressors, interstage and export cooling, condensate export and a flare/relief system.
12 assets · 82 tagsRead the case →
BLN3Food & beverage manufacturingBellini Foods — Aseptic Bottling Line 3
A 24 000 bottles/hour aseptic PET line: blow moulding, aseptic filling, capping, labelling, case packing and palletising, with live OEE on every machine and its own utilities and CIP block.
12 assets · 95 tagsRead the case →
PROVRenewable generationProvence Hybrid Plant
A 120 MW hybrid plant: six wind turbines, four PV inverter blocks, two battery racks, the main 33/225 kV transformer, the grid connection point and a meteorological mast.
15 assets · 99 tagsRead the case →
An agent with a budget of authority
The copilot reads the plant, authors a procedure and asks for it to be run. What it cannot do is decide how far it is allowed to go: authority bounds what it may ever request, autonomy bounds whether it may act alone, and both are checked server-side on every command. The closed loop is deterministic — attach a language model to widen what the copilot understands, but nothing load-bearing sits behind it.
- Authority C0–C6 and autonomy L0–L4, granted per agent and scope, with a justification and an expiry
- Interlocks before every write; a failed check raises an incident rather than a retry
- Second-person approval on safety-classified actions — the requester cannot self-approve
- One kill switch halts agent-originated execution without taking supervision down with it
This is control software. It does not pretend.
DjiniousCC runs against real plant. So the product refuses to fake: a tag in LIVE mode takes its value from a device read or reports no data; simulation is labelled SIM on every asset that carries it; an unimplemented capability is shown as unimplemented rather than mocked; and a lost connection turns a lamp grey, never green.
- A LIVE tag with no fresh device read reports not-connected — it never falls back to the model
- Command read-back reads an independent echo, so an acknowledgement cannot be tautological
- The simulation twin is labelled, isolated, and its intercepted commands are listed
- Where a protocol adapter is a stand-in, the connectivity page says so on the card
Bring us your plant.
We will stand DjiniousCC up against your tags, your alarm philosophy and one procedure you actually run — and dry-run it in front of you.