Consystence
Start free
Back to blog
Updated 10 September 2026Featured

The plant without the plant: a simulation that runs the real control logic

Test control behavior before commissioning with a native simulator and a PLCnext execution option. How the model works, what has been demonstrated and what still needs field validation.

Garry Thomas
ArchitectureSimulationEngineering

Update — 20 July 2026. The gap below has closed further: the dam-pump-station program running the virtual PLCnext on our workshop rig is now a generated one, produced by the same pipeline. Details in C#, not Structured Text.

Update — 15 July 2026. On PLCnext the deterministic pipeline now emits the controller program as eCLR C# rather than Structured Text — the same class of artifact the dam-pump-station proving run executed — which closes most of the gap this post is honest about below. Details in C#, not Structured Text.

Original engineering account

The implementation and status descriptions below record the work at publication. For current controller support, demonstration scope and beta availability, see the Platform page.

Control logic cannot be iterated against a running plant. A bad test does not throw an exception and roll back — it drives a VFD past a trip or swings a duty/standby changeover the wrong way, and the cost lands on the steel and on whoever is standing next to it. The one window for trying things — the commissioning window — is short, shared with production and booked weeks out, so the logic that most needs iterating gets the fewest chances. The usual answer is to write a second plant: a hand-built simulator that drifts from the real logic until the rehearsal stops predicting it.

There is no second plant. The simulation runs the same control logic as the PLC — built from the same device model, held equivalent by tests, and addressed exactly like a real controller — so the only place anyone breaks the plant is the one place a break costs nothing.

The same logic, not a mock of it

The simulation is not written by hand alongside the controller; it is generated from the same device model that produces the controller’s code — the deterministic pipeline covered earlier in this series. Where that pipeline emits IEC 61131-3 Structured Text for the PLC, it also wires an in-process scan program for the simulator, its blocks translated from the hand-authored CSY_* library and held to it by a behavioural-equivalence test suite, including a full dam-pump-station scenario. It runs a real scan cycle on a default 10 ms tick — copy inputs, execute each block, copy outputs — and keeps scanning through a logic fault the way a controller does, not an approximation of what will run but the model itself, wired the same way.

A PLC you address like a PLC

A simulated instance answers at a sim:// address; everything else routes to a containerised runtime, behind one client factory speaking one client interface. Nothing above that seam learns the difference. The pollers, the faceplate and the operator’s screen read and write a simulated pump exactly as they do a real one — same address, same calls, no second code path; the historian records it the same way. It is the same seam as one device model, many vendors: the variation lives at a thin edge, and everything above is written once.

The part a sceptic pushes on

If it is not the real runtime, how do I trust what it tells me? Honestly: the native runtime is equivalent behaviour, not equivalent execution. For what-if, operator training and commissioning rehearsal, that is exactly what you need. The real PLCnext runtime is commercially licensed per running instance — fine for one bench, fatal for a model where hundreds of people each spin up a trial. Licence-free is what makes those uses possible.

When a customer’s validation genuinely needs identical execution — a regulatory requirement for identical compiled code, or logic that leans on vendor-only blocks — the path opts up to the actual PLCnext runtime, the same one that runs on Phoenix Contact field hardware, byte-for-byte. By design it is an explicit, justified upgrade surfaced as a deliberate choice, not a default checkbox. Two implementations of the one control logic behind one seam: licence-free and native by default, the real runtime when fidelity is the requirement.

What ships, and what is next

To be precise about the line:

  • Shipped: the native, licence-free simulation runtime — the same control logic as the PLC, held by the behavioural-equivalence suite; addressed like a real controller over sim://; and every sample it produces stamped simulated.
  • Roadmap: the byte-for-byte opt-up, still gated on vendor licences and not yet exercised with our generated logic; higher-fidelity native shapes, such as a Structured Text interpreter, built when a customer requirement justifies them; the hosted self-serve sandbox at scale, still behind a bounded-sandbox wall, a concurrency ceiling and a load-test gate, and not yet live; and field-hardware sign-off. All of it is future work, and we label it as such.

Now the honest gaps. The native simulation is held equivalent by tests, not signed off against a real plant’s field IO, and its process model is deliberately simple — affinity-law pressure, an integrating level, first-order lag and noise on the sensors — sufficient for demos and training, not Simulink-grade physics. The byte-for-byte path is a runtime capability, not yet a validated run of our own logic: the dam-pump-station proving run executed a hand-authored, pure-managed C# program on a virtual PLCnext’s eCLR runtime — not the generated Structured Text, which has not yet run on a virtual or physical PLC. And the historian stamps every sample measured, inferred, imported, simulated, replayed, or workspace, so a rehearsal is never quietly mistaken for a field run. The proof against a real plant is still to come.

A simulation is only useful if it breaks the way the plant would. Same logic, same address — the only thing that is not real is the part that could hurt someone.