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 IPlcDriver abstraction. This page describes the three deployment topologies in which that runtime connects to control, and which IPlcDriver each one selects.

The edge hardware is the same across every topology: a PLCnext VL3 (primary) or an Nvidia Orin (GPU-capable variant). Both run the identical .NET edge runtime — 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 third-party or legacy controller directly from the edge — over EtherNet/IP CIP or Modbus TCP, with no gateway in between — is the supported interop path for equipment that is not behind a border gateway, and it is actively expanding (OPC UA and S7 are future additions). Prefer the gateway for Consystence-managed equipment. See PLCnext border gateway and PLC communication for the protocol detail.

Note

The edge tier itself is optional per controller: a controller that is not mapped to an edge can be acquired directly by the site server over the same shared driver layer, and an edge can report directly to the cloud where no site server is deployed.

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.

The IPlcDriver implementations

IPlcDriver has four implementations:

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-to-controller interop with third-party / legacy controllers
modbus-tcp	Modbus TCP (TCP 502) directly from the edge	Direct-to-controller interop with Modbus devices
stub	none (in-process, no hardware)	Simulation, development, CI

The ethernet-ip and modbus-tcp drivers are pure-.NET implementations 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/>IPlcDriver"]

    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 / modbus-tcp<br/>direct (interop)"| L3

Topology	Runs control	Edge → control	Control → field	IPlcDriver
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 (preferred) / ethernet-ip (direct interop)

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 (the PLCnext runtime and consystence-edge run as separate containers) and reads and writes GDS variables over the local socket. The edge selects plcnext-grpc.

This is the primary, recommended topology: lowest latency (no network stack), strongly typed against the published PLCnext gRPC contracts, and 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 using a Phoenix Contact vPLC, selected per device instance at commissioning when a documented trigger applies (regulatory byte-for-byte equivalence, or PLCnext-only function blocks). It is a tenant-paid entitlement — see Licensing.

Caution

Gateway-vPLCnext is workshop-proven but not yet production-deployed. A licensed Virtual PLCnext Control (Phoenix Contact CodeMeter network licence) is the live workshop controller, with the full PLC → edge → site → cloud chain verified end-to-end. Physical, co-located Native PLCnext remains the target primary topology, but it has not yet been exercised on VL3 hardware.

Gateway-legacy-PLC

An existing controller (a ControlLogix, CompactLogix, S7, etc.) keeps its rack, power supply, IO modules and field wiring. It is stripped to IO passthrough and 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 identical to the other two topologies.

The direct variant — the edge talking straight to the controller with no gateway in between, using the ethernet-ip driver (or modbus-tcp for a Modbus device) — is the supported interop path for third-party and legacy equipment. Route Consystence-managed devices through the gateway.

Caution

First-class control over legacy controllers (Consystence-generated control code, override-accepting IO modules, 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 unless a device is explicitly commissioned for control.

Selecting a topology

Topology is chosen per device instance at commissioning, not globally for a site — a single edge can drive devices across all three topologies concurrently. 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 satisfies IPlcDriver in-process with no hardware, so the full edge silo can run without a PLC present.

Network and runtime placement

The edge enforces an IT/OT split at the network layer: eth0 faces IT (upstream to the site server), eth1 faces OT (the field / gateway), with nftables policy between them. 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 firewall model.

Each edge runs a single Orleans silo; control reads and 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 configures, queries, classifies, and explains. 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 — per-instance topology selection