PLCnext Border Gateway

In the border-gateway topology, a PLCnext controller is the border gateway between an isolated field network and everything above it. This is an accepted target topology, demonstrated in our workshop on a virtual PLCnext. It is one of the ways Consystence reaches controllers: a ControlLogix can also be read directly over EtherNet/IP by an edge (see deployment topologies). In this topology the PLCnext owns all communication with the field devices behind it and runs deterministic ISA-95 Level 1/2 control. The edge runtime does not touch that field network; it reads and writes a curated set of variables on the PLCnext.

This page covers the four things the gateway is responsible for: the CSY function-block library, dual-port network segmentation, exposing GDS / PORT variables to the edge, and speaking CIP / EtherNet/IP to field devices.

Demonstrated in our workshop

The border-gateway topology is demonstrated in our workshop on Virtual PLCnext Control (vPLCnext); validation on VL3 hardware is pending. Treat scan rates and tag-count limits as workshop figures, not production guarantees.

Why a border gateway

Field devices (controllers running as IO racks, VFDs, protection relays) live on an isolated OT subnet. Exposing that network to the broader site/OT network is unacceptable in a mining or CHPP environment. The PLCnext solves this two ways at once:

• Segmentation — the field network sits behind the PLCnext and is invisible to anything above it. The gateway is the single point of control for every field device.
• Independence — the PLCnext runs a self-contained control program. In the target design, equipment state machines, interlocks, sequences, PID loops, and alarm processing keep running on the local scan even if the edge runtime, cell, or wider platform is offline. Consystence configures and observes control; it does not host it.

This independence is also why licensing is degrade-not-kill: a lapsed or offline licence may reduce platform features, but it never gates a control write — control authority lives in the PLCnext, not in the platform.

flowchart TB
  Edge["Edge runtime<br/>.NET 10 Orleans silo<br/>driver: plcnext-grpc"]
  subgraph GW["PLCnext border gateway"]
    GDS["Global Data Space<br/>PORT variables"]
    CSY["CSY function-block library<br/>Common / IO<br/>Device / Sequence: roadmap"]
    CIP["CIP client"]
  end
  Field["Isolated field network<br/>controller IO rack, VFDs, relays"]
  Edge -- "gRPC-over-UDS<br/>/run/plcnext/grpc.sock" --> GDS
  GDS --- CSY
  CSY --- CIP
  CIP -- "CIP explicit messaging<br/>EtherNet/IP, TCP 44818" --> Field

Dual-port segmentation

The PLCnext is a dual-Ethernet controller, and the two ports play different roles:

Port role	Faces	Carries
Field-side	The isolated field subnet (for example 192.0.2.x)	CIP explicit messaging over EtherNet/IP (TCP 44818) to the controller IO rack, VFDs, and relays. The PLCnext is the CIP client and initiates every connection.
OT / edge-side	The site OT network where the edge runtime runs	The Global Data Space (GDS), consumed by the Consystence edge over local gRPC. OPC UA on this port is reserved for third-party SCADA consumers (Ignition, AVEVA), not the edge fast path.

Nothing on the field subnet is routable from the OT side. The only data that crosses the boundary is the explicitly declared set of GDS PORT variables.

Note

The PLCnext’s own dual-port roles are distinct from the edge appliance’s eth0 (IT) / eth1 (OT) split. Deploy the edge on segmented IT and OT networks — see network security. When the edge and the PLCnext share a single VL3, the boundary between them is a local socket, not a wire.

The CSY function-block library

The control program is the CSY function-block library, a layered set of blocks mapping onto the Consystence device model. On controllers, the device and sequence layers are ControlLogix today: that is where conformance testing runs. On PLCnext there is a generated runtime program, a managed eCLR C# library built from the same source (the C# behavioural master), run on a virtual PLCnext only, with no conformance replay; per-block vector replay on PLCnext is planned. The gateway’s Device and Sequence layers below are roadmap. A separate, hand-maintained Structured Text block library is used only for the Structured Text (PLCopen XML) export to PLCnext Engineer; that export covers less than the runtime program.

Layer	Blocks	Responsibility
Layer 0 — Common	EdgeDetect (R_TRIG/F_TRIG), Debounce, Filter, RateLimiter, Scaling, Alarm (ISA-18.2)	Reusable primitives: debouncing, filtering, ramping, raw-to-engineering-unit scaling, alarm state machines
Layer 1 — IO	AI, AO, DI, DO, RemoteIO, CipClient	Analogue/digital input and output processing (scaling, filtering, HiHi/Hi/Lo/LoLo alarms, IO quality), remote-IO connection monitoring, and the EtherNet/IP CIP client
Layer 2 — Device (roadmap on the gateway)	Pump, Valve, Sensor, PID, Motor	Equipment blocks with state machines (e.g. Stopped, Starting, Running, Stopping, Faulted), interlock checks, condition monitoring
Layer 3 — Sequence (roadmap on the gateway)	Sequence (ISA-88 step sequencer), Interlock (condition matrix), Timer	Procedural sequences, the hard interlock matrix — enable/bypass per condition, blocked-by tracking, aggregate OK — and the sequence timer

In the target design, each Layer 2 device block corresponds 1:1 to a Consystence device instance, wired through the GDS. This is the field-side realisation of the engineering model — a controller exposes modules, channels, and tags, and a device type such as consystence.pump.centrifugal resolves to a CSY block at commissioning time. The mapping from device type to CSY block (config, tuning and command shapes) is declared in the platform’s type mapping, and the deterministic code generator uses it to emit the program that instantiates and wires the blocks; see instances and commissioning.

GDS / PORT variables exposed to the edge

Every status value, command, and configuration parameter the platform needs is declared as a PORT variable in the PLCnext Global Data Space. GDS direction is relative to the PLC program, and lines up with the tag’s read/write access in the engineering model — not with its physicalRole, which classifies which side produces the raw value. A measured flow is physicalRole: Input — a sensor produces it — yet it reaches the platform as a GDS Output, because the PLC program publishes it:

GDS direction	PLCnext attribute	Tag access	Meaning
Output	Output	Read	FB status read by the edge (e.g. PP01_Running BOOL, PP01_Speed REAL, SEQ_CurrentStep INT, CIP_Connected BOOL)
Input	Input	Write	Commands and configuration written by the edge (e.g. PP01_Cmd_Start BOOL, PP01_Cmd_SetSpeed REAL)

Boolean commands are pulse-style: the controller raises a paired acknowledge output (for example PP01_Cmd_Start_Ack), and the edge then resets the command port. Config and tuning are online changes — written at runtime with no restart. Structural changes (adding a device block) require a recompile and redeploy.

Edge transport: gRPC-over-UDS

The edge reads and writes these GDS PORT variables through the PLCnext gRPC data-access service. When the edge runtime and the PLCnext are co-located on one VL3, this is a Unix Domain Socket — /run/plcnext/grpc.sock — giving the lowest possible latency with no network stack. Across the network (for example an edge on a separate host from the PLCnext, or a containerised virtual PLCnext as in our workshop) the same gRPC services are reached over TCP (default port 41100).

On the edge side this is the plcnext-grpc driver in the edge’s driver layer. The driver layer also has an ethernet-ip driver for direct CIP connections and a stub driver for development; a Modbus TCP runtime driver is on the roadmap. Protocol details and driver selection are covered in PLC communication.

Direct connections

In the border-gateway topology the edge speaks only gRPC to the PLCnext, and the PLCnext speaks CIP to the field. Outside this topology, an edge reads a Rockwell ControlLogix directly over EtherNet/IP CIP (the ethernet-ip driver); see deployment topologies. The edge and the site server share the same pure-.NET driver layer; no third-party PLC client library is used on either tier.

Speaking to the field: CIP / EtherNet/IP

On the field-side port the PLCnext runs the CipClient block as a CIP explicit-messaging client over EtherNet/IP (TCP 44818). On the workshop rig, the far end is a ControlLogix running a generated interface/echo layer rather than plant IO: it holds no control logic, accepts the PLCnext’s command tags and returns simulated feedback after a configured travel time. In the dam pump station demo, the PLCnext read that feedback over CIP as discrete inputs; every other input, including every analogue value, came from a field simulator. Where Consystence connects to an existing controller today, that controller’s own program keeps control authority (see deployment topologies).

The client manages its own TCP session with auto-reconnect, surfacing health as GDS outputs (CIP_Connected, CIP_ErrorCount) so the platform can observe link state without seeing the field network itself. EtherNet/IP is the implemented field protocol on the gateway, demonstrated in our workshop; as gateway field-side protocols, Modbus TCP is reserved for future implementation and PROFINET support is planned via the PLCnext runtime’s native capability. Separately, Modbus TCP as a platform acquisition driver (edge or site server) is on the roadmap; see PLC communication.

Control authority and AI

AI is advisory-only

Consystence AI reads, explains and recommends — it never commands equipment. The authority for any field action is the PLCnext control program. Operator and platform commands arrive as GDS Input ports; in the target design, the CSY device blocks and the Interlock matrix validate them against hard interlocks before acting. Final safety — hard interlocks, trip logic — lives in the PLCnext, the IO modules, and dedicated safety relays, never in the AI layer or the network above it.

This is why the gateway is the right place to enforce safety: it runs deterministically on a fixed scan, independently of the platform, and it is the single chokepoint through which every command to the field must pass.

Where to go next

• PLC communication — the driver layer, gRPC and CIP details, and driver selection
• Deployment topologies — the edge topologies, and when the gRPC transport is a local socket versus TCP
• VL3 edge setup — the target installation on VL3 hardware, where the edge and the PLCnext share one device
• Network security — the reference IT/OT firewall policy for the edge host, which complements field-network segmentation