Platform
Everything between the PLC and the cloud.
One semantic model spanning five capability areas. Author equipment from a typed standard library, prove it in closed-loop simulation, operate it through control screens your team assembles in real time, and trust it with hard tenant isolation — with AI that explains the plant and never controls it.
Proven end to end on a dam pump station — PLC to cloud.
Operate
Control screens, assembled in real time
No single-page app to build or ship. The server resolves every control screen from one renderer-agnostic semantic UI tree and streams it live — driven by the operator's question and the live state of the plant. The browser and the csy CLI both render that same tree today; new surfaces follow it.
Server-driven UI
AI advisory chat
csy — command-line client
Simulate
The same control logic — in a container
Run a native simulation engine or a full containerised Phoenix Contact vPLCnext. The logic that executes on the panel executes here, so training, what-if, and commissioning all behave like the real plant. And simulation is per-device, not a plant-wide switch — run live and simulated equipment side by side, with provenance keeping them separate.
Native Sim runtime
Phoenix Contact vPLCnext
Training · what-if · commissioning
All IO modelled in software — the control logic runs against a simulated plant and nothing touches the field.
Live IO bridged to real PLC tags over EtherNet/IP CIP or PLCnext GDS. The logic drives, or shadows, hardware.
Recorded history streamed back through the same logic, sample-for-sample, to reconstruct an incident — on the roadmap.
Build
Author once, from a typed standard library
Device types carry their tags, alarms, commands, UI faceplates, and simulation profiles in one definition — lifted from production PLC code, not drawn on a whiteboard.
Device type system
IO AI code generation
Living electrical model
type: consystence.pump.centrifugal version: 1.4.0 tags: - { name: Running, type: bool } - { name: Speed, type: real, unit: "%" } - { name: FlowRate, type: real, unit: m³/h } alarms: - { name: LowFlow, priority: high } commands: [ Start, Stop, Reset ] faceplate: pump.detail simProfile: centrifugal.v1
One definition, the whole stack
A device type is the contract the rest of the platform reads from — the UI, the alarm engine, the simulator, the historian, and the AI context all resolve against the same source, so an instance behaves the same everywhere it's deployed.
- Tags, alarms, and commands typed together
- UI faceplates rendered server-side
- Simulation profile for closed-loop test
- Deterministic PLC code generated from the mapping
Roadmap A device-type marketplace to publish and install vetted templates across organisations.
Data & edge
Every sample knows where it came from
A historian where provenance is a first-class column, trend import that keeps imported data honest, and an edge that keeps working when the link to site drops.
Provenance historian
CSV trend import
Offline-tolerant edge
Fleet-learning engineRoadmap
Trust & platform
Isolation you can prove, in your jurisdiction
Multi-tenancy that's tested adversarially, one source tree for cloud and site, identity through Microsoft Entra External ID, and platform data hosted in Australia.
Hard multi-tenant isolation
One codebase, cloud & site
Entra External ID OIDC
Australian data residency
Clustered site server, no load balancer
Comes online with one code
Safety first
AI explains the plant.
It never takes control.
Every control action goes through the PLC on the established deterministic path. The advisory AI is diagnostic: it reads live tags, alarms, and history to explain what the PLC is doing and recommend where to look — it never commands equipment. Today that's the cloud advisory model tier, hosted in-region; asite-local advisory model and on-devicetimeseries ML for anomaly detection and health scoring are on the roadmap. Operators acknowledge and execute.
Hard interlocks stay in IO modules and safety relays, consistent with IEC 61511 and ISO 13849. That line is non-negotiable for mining safety culture — and it's built into the architecture.
Every operator command is written to a persisted, append-only audit trail — actor, target, and outcome — and a command with no authenticated actor fails closed instead of executing.
Where it sits
What it is — and what it isn't
Consystence runs the control screens and keeps the history — over the PLCs you already have. It isn't a fixed vendor HMI, it isn't an MES, and it isn't autonomous control. Here's the line in each case, drawn against the mechanism rather than the marketing.
Replaces the page, not the PLC
A fixed-page HMI — Citect, FactoryTalk View, Ignition — is built around screens you draw once and bind to tags by hand. The screen project becomes the deliverable, and it starts ageing the day the plant changes. Consystence doesn’t draw pages: the server resolves one semantic UI tree from the typed device type and the operator’s question, then streams it live to the browser over SignalR. The same equipment renders the same faceplate, alarms and commands everywhere — no per-site screen build. It runs alongside your control system; it never replaces the PLC. And where Ignition is staying, Consystence can generate its tags and Perspective faceplates from the same model — proven on a live gateway on our workshop rig, with UDT export in development — programming your SCADA rather than replacing it, and never sitting in its runtime data path.
Sits in the SCADA/HMI role · server-assembled, not hand-drawn
Below the MES, not across it
An MES answers what to make, when, at what cost, and against which order. Consystence answers what the equipment is doing right now, why, and whether it’s healthy. There’s no scheduling, inventory, costing or finance in it — it models typed equipment, tags, alarms, commands and history. What it hands up is a clean operational feed where every sample carries its source — measured, inferred, imported, simulated, replayed or workspace. If you run an MES, this sits beneath it, not on top of it.
Complements your MES · feeds it sourced data
Outside the control loop, on purpose
Closed-loop AI products put a model inside the control loop — it decides and it actuates. Consystence deliberately doesn’t: the advisory AI explains anomalies and helps diagnose faults, but every control action still executes on the PLC’s deterministic scan. The boundary is structural, not a setting you toggle.
Advisory only · the model never sits in the path
Straight answers
The questions engineers ask first
Do we have to rip out our existing SCADA?
No. Consystence speaks to the controllers you already run — EtherNet/IP CIP (bench-verified on Rockwell ControlLogix) and PLCnext over gRPC/GDS, with Modbus TCP and OPC-UA on the roadmap. It reads their tags and issues operator commands through them; it doesn’t replace the controller or the field IO. You can stand it up alongside an existing SCADA on the same plant, both reading the same PLCs, and start by modelling one process.
Screens are assembled at runtime — doesn’t that make them unpredictable?
The assembly is deterministic: a screen resolves from the typed device-type definition, so the same device type always renders the same faceplate, alarms and commands — there’s no client-side control logic to drift out of sync, and no per-site screen build to maintain.
Is the simulation a second model we have to keep in sync?
No. The closed-loop simulation runs the same control logic that executes on the panel — a native engine, or a containerised Phoenix Contact vPLCnext running the same control program a physical controller runs. A device type carries its own simulation profile, so the model and the plant resolve against one definition.
How do we know the device types reflect real plant behaviour?
Because they were lifted from production control code, not modelled from a datasheet. The standard library was distilled from 112 UDTs and 57 AOIs of Deftec control code delivered to Tier-1 Australian miners over 20+ years. The set shipping today is 22 typed device types across 3 standard libraries — browsable in full, and growing. It was first proven end to end on a dam pump station, PLC to cloud.
We run a water utility / gas plant / data centre — is the library for us?
The device model is vertical-agnostic — a clarifier, a compressor, and a CRAC unit are all tags, states, alarms, commands, a faceplate, and a simulation profile — and you can author your own types in any vertical today. The shipped libraries cover pumps & drives, IO & controllers, and materials handling; full control device libraries for water utilities, gas, and data centres are planned next, sequenced by what beta users ask for first. See the library for what ships today and what’s planned.
Can we put the beta into production today?
No — and we’d rather tell you that plainly. The beta is for evaluation, authoring and simulation, and supervised commissioning trials alongside your existing SCADA; it is not intended for production control of live plant while the beta label is on. Deterministic controller logic holds final authority over physical outputs regardless — hard interlocks live in IO modules and safety relays, never in software.
See the platform run on your process.
A 30-minute walkthrough on a live plant model — pumps, conveyors, MCC sections — running in our simulation engine.