Consystence
Start free
Back to blog
Updated 20 July 2026

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

A bad control test does not roll back — it surges a duty/standby changeover or trips a VFD on equipment people are standing next to, and the commissioning window is short and shared with production. So the platform ships a native, licence-free simulation that runs the same control logic as the PLC, addressed exactly like one. Here is how we drew that line.

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.

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.