Every layer,in one product.
Acquisition, historian, HMI, twin, process automation and policy are not six integrations here — they are one system with one data model. Which is why a procedure can be grounded in the twin, proven against it, and executed through the same tag it was written for.
Real drivers, and an honest badge when they are not
Southbound acquisition runs on genuine protocol stacks — a node-opcua client, a Modbus TCP master and an MQTT Sparkplug B subscriber. Flip an asset to LIVE and its value comes from a device read or it reports no data. There is no silent fall-back to the model.
- OPC-UA client with subscriptions, auto-reconnect and per-tag NodeId mapping
- Modbus TCP (32-bit float) and MQTT Sparkplug B with a real broker
- Northbound OPC-UA server: 392 AnalogItems with engineering units and EU range, historical access served from TimescaleDB, and Alarms & Conditions with acknowledgement round-trip
- Governed writes: an external OPC-UA write is issued as a command and passes the same interlocks and read-back as an operator's
A twin with bindings, not a diagram
Site, areas and assets carry an ontology type, aspects, a criticality and a safety classification. Twin nodes bind to the specific tags that express their state, which is what lets a procedure be grounded rather than guessed.
- Ontology-typed assets with explicit tag bindings and binding confidence
- Per-asset data-source mode: simulated model or real device, switchable per asset or plant-wide
- Behavioural (F1) physics per equipment family, shared by the live simulator and the proving twin
- Every tag carries a quantity kind, unit and limits, so an alarm limit is dimension-checked at authoring time
Draw it once. The Runner shows exactly that.
The Builder is a palette and a canvas with a tag-binding inspector. The Runner renders the same elements with the same symbol components, so what an engineer draws is what an operator sees — there is no second drawing set to drift.
- Equipment symbols per family — turbine, inverter, battery, transformer, pump, tank, valve, machine — bound to live tags
- Process pipes and power feeders animate from the tag they carry; ISA-101 keeps them neutral until something is wrong
- 2D synoptics and orbitable 3D scenes from the same screen record
- Imported CAD: OBJ, STL, glTF and STEP/IGES tessellated in a worker, normalised to glTF-binary
Procedures are artefacts, not scripts
A process is authored as intent, compiled to BPMN, statically validated, published, and executed by a token runtime. It has a version, a validation report, an authority class and a generation record naming who or what wrote it.
- PIR → BPMN with a validation report listing required capabilities and blast radius
- Capability steps, decisions, human tasks and notifications — readable by the people who sign it off
- Token runtime with activity history, task assignments and incidents
- A step does not complete until its command's read-back settles; a mismatch is a step failure
The plant as it was actually built
Import a LiDAR or photogrammetry survey and drop equipment tags onto the point cloud. Useful when the as-built and the drawing disagree — which, on a plant of any age, they do.
- PLY, PCD, XYZ and PTS point clouds rendered in the browser
- Colour by scan or by height; click to place an equipment annotation
- Point data stored out-of-line so the list view stays fast
Configuration you can sign, export and roll back
Everything that makes this deployment what it is — assets, tags, screens, alarm definitions, connections, processes — snapshots into a signed project with a deployment mode. Export it, import it elsewhere, activate it to restore.
- Signed snapshots of every configuration table, versioned
- Deployment mode: production, simulation or mixed
- Export to JSON, import into another instance, activate to restore and reload the runtime
Every asset, every plant, one list
Four plants in one deployment means one asset register, one tag namespace and one alarm list — not four consoles that happen to share a login.
What it actually is
Acquisition & storage
- Southbound protocols
- OPC-UA · Modbus TCP · MQTT Sparkplug B
- Acquisition rate
- 1 Hz tick, per-connection scan rate
- Historian
- TimescaleDB (PostgreSQL 16), continuous aggregates
- Northbound
- OPC-UA server — AnalogItems, HA, Alarms & Conditions, methods, audit events
Operations
- HMI
- ISA-101 high-performance, 2D and 3D, authored in-product
- Alarms
- ISA-18.2 — priority, shelve, suppress, out-of-service, second-person ack
- Commands
- Interlocks, policy gate, independent read-back echo
- Languages
- English, French, German, Italian, Romanian
Automation & governance
- Process model
- PIR → BPMN 2.0, statically validated, token runtime
- Simulation
- Isolated twin, virtual clock, seeded RNG, intercepted commands
- Authority
- C0–C6 classes, granted per agent and scope with an expiry
- Autonomy
- L0 advisory → L4 autonomous with review
Platform
- Runtime
- Bun · React 19 · TypeScript
- Data
- SurrealDB 2.x (graph, vectors, full-text) + TimescaleDB
- Auth
- JWT (HMAC-SHA256) + Argon2id, server-side role gates
- Agent access
- MCP server + REST, API-key scoped
Not built yet
So you can plan around it rather than discover it in a workshop:
- OPC-UA server redundancy (hot-standby pairs) and reverse connect
- Per-tag register mapping for Modbus and per-metric mapping for Sparkplug — OPC-UA per-tag mapping is done
- Hot-standby session transfer for a redundant OPC-UA client connection
- Unified Namespace publishing to a live broker — the current view is a projection, and is labelled as one
See it against your tags.
Bring a tag list and one procedure you run today. We will wire it up and dry-run it with you on the call.