One device model, many PLC vendors

Update — 15 July 2026. A third driver now sits behind the seam: native Modbus TCP, read and write, with the register spec explicit in the tag path — type and word order stated, never guessed — bench-verified against an independent open-source reference implementation. The production configuration surface that lets a site declare a Modbus controller is still landing, so Modbus stays on the roadmap for customers today. OPC-UA remains the honest “no driver behind that string yet”.

Every brownfield site is a different sediment of controllers. A ControlLogix rack on the pump skid the integrator commissioned last year; an older Allen-Bradley unit on the clarifier that nobody dares re-flash; a Phoenix Contact box bolted to the conveyor drive because that is what was on the truck; and somewhere a serial drive older than the integrator. No two sites are the same mix, and it changes under you as the plant is rebuilt. The usual answer is a vendor stack per plant — one vendor’s driver, tag database and HMI for the Rockwell gear, another for the rest — so the same pump gets described two or three times, in two or three places, and the descriptions drift apart.

We refused that. The platform speaks to a tag, not a vendor. A pump faceplate is identical whether a ControlLogix or a PLCnext is behind it, because the device model reads and writes a tag — a path, a typed value, a quality and a timestamp — and never a vendor’s wire frame.

One model, one seam

A pump is modelled once, as a device type, the same way whether its tags live in a ControlLogix or a PLCnext. That is the catalogue you can browse on this site: 22 device types across pumps and drives, I/O and controllers, and materials handling, distilled from 112 UDTs and 57 AOIs of Deftec control code delivered to Tier-1 Australian miners over 20+ years. A ControlLogix Controller and a PLCnext Controller sit side by side there, and the pump device type above them does not care which it is talking to.

Underneath the model is a deliberately thin seam. The whole boundary the rest of the edge runtime talks to is one interface: connect, read a tag, read a batch of tags, write a tag, write a batch. Every value that crosses it is the same neutral type — a tag path, a typed value (BOOL, DINT, REAL, all carried the same way), a quality, a timestamp. Nothing above the seam — the pollers, the streaming link to the site server — ever learns the brand. A config string picks the driver. Ask for one that does not exist and the factory refuses — Unknown PLC driver type — rather than quietly pretending.

Why we wrote the wire by hand

Here is the obvious objection. Libraries already exist that speak EtherNet/IP; why write the wire ourselves? We did, for the Rockwell path. The driver builds the EtherNet/IP CIP frames by hand — the encapsulation header, the service codes, reads and writes batched into a Multiple Service Packet and routed through Unconnected Send. It pulls in no Rockwell SDK and no native PLC library at all — pure managed code.

That was deliberate. A Consystence edge ships as a self-contained linux-arm64 build onto a small ARM controller with a tight memory budget, and a pure managed stack — no native .so to cross-compile and pin per platform — fits that where a native-library wrapper would not. We own the bytes on the one protocol where the protocol is the contract.

The rule is not hand-roll everything. Where a vendor publishes a clean local API, we use it: the PLCnext driver speaks gRPC over a Unix domain socket to the runtime already on the box — its Global Data Space — against Phoenix Contact’s own service definitions, generated stubs rather than bytes we wrote. Hand-rolled EtherNet/IP CIP on one side, the vendor’s own gRPC contract on the other, behind the identical seam. One model, many drivers is the same bet we made with one tree, many renderers — the variation lives at a thin, well-named edge, and the core is written once.

What ships, and what is next

To be precise about where the line is:

• Shipped (bench-validated): two field drivers behind one device model — the hand-rolled EtherNet/IP CIP driver for ControlLogix, and the PLCnext gRPC/GDS driver — chosen by config and swapped without touching the model, the faceplates or the alarms above them.
• Roadmap: the further drivers the seam was built to accept but that we have not written yet, such as an OPC-UA client. The abstraction would route one, but there is no driver behind that string today; ask the factory for it and it refuses. We name it as direction, not capability.

We will not oversell the field side. We have run the full PLC → edge → site → cloud chain end to end — but on the bench, against a containerised virtual PLCnext on our dam-pump-station proving ground. The EtherNet/IP CIP driver is implemented and registered, not yet signed off against a physical controller in the field; the field chain has not yet moved onto the physical ARM edge controller. Our historian stamps the origin of every sample — measured, inferred, imported, simulated, replayed, or workspace — so a driver exercised in simulation is never quietly recorded as a field run.

A new vendor, then, is a new driver — not a new platform. The model speaks to a tag, and a tag has no brand.