Edge Deployment Topologies

The Consystence edge runtime (consystence-edge) is a single-silo .NET 10 Orleans process. It buffers and forwards telemetry to the site server (store-and-forward over SQLite, shipped upstream over gRPC) and reads and writes control values through a pluggable driver layer. This page describes the three deployment topologies in which that runtime connects to control, and which driver each one selects.

The edge runtime is the same on every host. The PLCnext VL3 is a target platform for it, which we are proving in our workshop on a Linux container. In our workshop the edge also runs on an Nvidia Jetson Orin today; the Orin is not a standalone ML appliance. See VL3 edge setup and Orin setup.

The wire constraints

Two wire rules hold across every supported topology:

• Edge ↔ PLCnext is gRPC. The edge reads and writes PLCnext GDS / PORT variables over the PLCnext gRPC API — via a local Unix domain socket (/run/plcnext/grpc.sock) when co-located, or over TCP (PlcNext:GrpcHost / PlcNext:GrpcPort, default 41100) when the PLCnext is containerised or remote. gRPC is the only edge-to-PLCnext protocol; OPC UA is not used as the edge-to-PLCnext transport.
• PLCnext ↔ field is CIP / EtherNet-IP. The PLCnext border gateway speaks EtherNet/IP CIP (TCP 44818) to field equipment and existing controllers.

Reaching a Rockwell ControlLogix directly from the edge over EtherNet/IP CIP, with no gateway in between, is a supported path for a controller that is not behind a border gateway; the workshop edge reads a physical ControlLogix this way. Modbus TCP and OPC UA runtime drivers are roadmap. See PLCnext border gateway and PLC communication for the protocol detail.

Note

The edge and the site server share one driver layer. A site server can also read a ControlLogix that no edge serves directly, read-only: early access, enabled per controller by our engineers, off by default. An edge reporting directly to the cloud, where no site server is deployed, is roadmap; today an edge reports to a site server.

Note

Consystence also defines control-instance deployment topologies (Native / Gateway-vPLCnext / Gateway-legacy-PLC) — these describe where control logic executes. The “Native” control topology is Consystence-native, in-process .NET control (the Consystence vPLC) with no protocol bridge and therefore no PLC driver at all. The topologies on this page describe how the edge runtime reaches a PLCnext or controller over the wire; they share names with the Gateway-vPLCnext and Gateway-legacy-PLC control topologies but are concerned with the edge driver, not the control implementation. Native PLCnext on this page is not the Native control topology: it is a physical PLCnext with the edge co-located on it. See deployment topologies in the type system.

The drivers

The driver layer has four drivers:

Driver	Wire	Used by
plcnext-grpc	gRPC (UDS or TCP) to PLCnext GDS / PORT variables	Native PLCnext, Gateway-vPLCnext, gateway-mediated Gateway-legacy-PLC
ethernet-ip	EtherNet/IP CIP directly from the edge	Direct connection to Rockwell ControlLogix controllers
modbus-tcp	Modbus TCP (TCP 502)	Roadmap: merged in the shared driver layer, not yet used by any acquisition path
stub	none (in-process, no hardware)	Simulation, development, CI

The ethernet-ip and modbus-tcp drivers are pure-.NET implementations in the driver layer shared by the edge and the site server — no third-party PLC client library is used on either tier.

Topology overview

flowchart LR
    EDGE["consystence-edge<br/>.NET 10 single-silo Orleans<br/>driver layer"]

    subgraph T1["Native PLCnext"]
      direction TB
      P1["PLCnext border gateway<br/>VL3"]
      F1["Field IO"]
    end
    subgraph T2["Gateway-vPLCnext"]
      direction TB
      P2["Virtual PLCnext Control<br/>container"]
      F2["Field IO"]
    end
    subgraph T3["Gateway-legacy-PLC"]
      direction TB
      P3["PLCnext border gateway"]
      L3["Existing controller<br/>e.g. ControlLogix"]
    end

    EDGE -->|"plcnext-grpc<br/>gRPC-over-UDS"| P1
    EDGE -->|"plcnext-grpc<br/>gRPC (typically TCP)"| P2
    EDGE -->|"plcnext-grpc<br/>gRPC-over-UDS"| P3
    P1 -->|"CIP / EtherNet-IP"| F1
    P2 -->|"CIP / EtherNet-IP"| F2
    P3 -->|"CIP / EtherNet-IP"| L3
    EDGE -.->|"ethernet-ip<br/>direct"| L3

Topology	Runs control	Edge → control	Control → field	Driver
Native PLCnext	Physical PLCnext border gateway (VL3)	gRPC-over-UDS to GDS	CIP (TCP 44818)	plcnext-grpc
Gateway-vPLCnext	Provisioned Virtual PLCnext Control container	gRPC to GDS / PORT (typically TCP)	CIP via the gateway	plcnext-grpc
Gateway-legacy-PLC	Existing controller via the gateway	gRPC-over-UDS to the gateway	gateway scans controller over CIP	plcnext-grpc via the gateway; ethernet-ip direct

Native PLCnext

A physical PLCnext border gateway executes the control logic and owns the field side — driving its own IO modules and/or acting as an EtherNet/IP scanner over CIP. The edge runtime is co-located on the same device (consystence-edge runs as its own service beside the PLCnext runtime) and reads and writes GDS variables over the local socket. The edge selects plcnext-grpc.

This is the target topology for VL3 hardware, not yet validated on it. It gives the lowest latency (no network stack), is strongly typed against the published PLCnext gRPC contracts, and uses the same gRPC transport the edge already uses upstream to the site server.

Gateway-vPLCnext

Where there is no physical PLCnext silicon, control logic runs inside a provisioned Virtual PLCnext Control container — the same PLCnext runtime, virtualised. The edge reaches it with the same driver (plcnext-grpc, gRPC to the container’s GDS / PORT variables), so the edge driver is unchanged from Native — though the gRPC channel typically runs over TCP (PlcNext:GrpcHost / PlcNext:GrpcPort) rather than the co-located Unix socket, since a containerised vPLCnext does not share the edge’s socket namespace. This is the Gateway-vPLCnext control topology: Phoenix Contact vPLCnext runs the PLCnext control program in a container when that execution environment is required, for example where a regulatory requirement means the compiled controller code itself must be validated, or where the logic uses PLCnext-only function blocks. Offering it as an explicit, per-device-instance upgrade at commissioning is roadmap.

Caution

Gateway-vPLCnext is demonstrated in our workshop, not deployed in production. A licensed Virtual PLCnext Control (Phoenix Contact CodeMeter network licence) is the workshop’s PLCnext controller, and the full PLC → edge → site → cloud chain runs end to end against it. Native PLCnext is a target topology for VL3 hardware and is not yet validated on it.

Gateway-legacy-PLC

An existing Rockwell controller (a ControlLogix) keeps its rack, power supply, IO modules, field wiring and its own program, and is reached via the PLCnext border gateway, which acts as the EtherNet/IP scanner: the gateway speaks CIP (TCP 44818) to the controller, and the edge speaks plcnext-grpc to the gateway. From the edge’s point of view this is the same as the other two topologies.

The direct variant — the edge talking straight to a ControlLogix with no gateway in between, using the ethernet-ip driver — is also supported, and it is how the workshop edge reads its physical ControlLogix. A site server can also read a ControlLogix that no edge serves directly, read-only (early access: our engineers enable it per controller; it has run at a site trial since 28 October 2026; off by default).

Caution

Consystence generates ControlLogix control code (AOIs, UDTs and programs) today: on 8 September 2026 the generated set of 11 materials-handling blocks matched all 112 of its test vectors on a physical ControlLogix in the workshop, and blocks revised since have been checked off the controller so far. First-class control over legacy controllers (running generated code as an existing plant’s production control, override-accepting IO module blocks that let a simulator inject values into an existing controller’s logic, and full simulation parity) is roadmap. Today a legacy controller that has not adopted the Consystence Standard Library IO patterns gets observation-mode simulation: simulated values are historised with source_class=simulated but never drive the controller. Control authority for a legacy controller stays with the controller’s own program; the edge observes and historises.

Selecting a topology

In the design, control topology is chosen per device instance at commissioning rather than for a whole site; per-instance topology selection is roadmap. The edge’s wire is set per controller by its driver, so one edge can already connect to a PLCnext over gRPC and a ControlLogix over EtherNet/IP at the same time. See Instances and commissioning. The behavioural contract (states, alarms, commands, tag surface) is declared once in the device-type manifest and is canonical across topologies; only the control implementation and the wire differ.

For development, simulation, and CI, select the stub driver — it runs in-process with no hardware, so the full edge silo can run without a PLC present.

Network and runtime placement

Deploy the edge on segmented plant networks: eth0 faces IT (upstream to the site server) and eth1 faces OT (the field / gateway). When the edge and PLCnext are co-located, the edge ↔ PLCnext gRPC connection is a local Unix domain socket, not a network hop; a containerised or remote vPLCnext is instead reached over gRPC/TCP on the OT side. See Edge network security for the reference firewall policy.

Each edge runs a single Orleans silo; supervisory tag reads and command writes, store-and-forward buffering, and (on the roadmap) edge ML all run inside it.

Advisory only

AI on the platform — including roadmap edge ML (cloud-trained ONNX, CPU inference, advisory) — never commands equipment. It reads, explains and recommends. Control writes that reach the field originate from the control logic running on the PLCnext or controller, and hard interlocks live in the IO modules and safety relays, never in the AI or the edge ML layer. No TensorRT/ONNX inference ships on the edge today. See AI architecture.

Related pages

• PLCnext border gateway — the gateway role and gRPC/GDS surface
• PLC communication — driver protocols and tag mapping
• VL3 edge setup · Orin setup — hardware provisioning
• Edge network security — IT/OT firewall
• Instances and commissioning — device instances and commissioning (per-instance topology selection is roadmap)