PLCnext Border Gateway

The PLCnext controller is the border gateway between the field network and everything above it. In the Consystence four-tier path (Browser to Server cell to Edge runtime to PLCnext Border Gateway to Field), the PLCnext owns all communication with field devices and runs deterministic ISA-95 Level 1/2 control. The edge runtime never touches the field network directly; 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.

Workshop-proven, hardware validation pending

The border-gateway pattern is validated on Virtual PLCnext Control (vPLCnext) against the dam pump station demo. Physical validation on production VL3 hardware is pending hardware availability. Treat scan rates, tag-count limits, and any safety rating as workshop figures, not committed 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. 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/>IPlcDriver = plcnext-grpc"]
  subgraph GW["PLCnext border gateway"]
    GDS["Global Data Space<br/>PORT variables"]
    CSY["CSY function-block library<br/>Common / IO / Device / Sequence"]
    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. The edge enforces its own IT/OT firewall with nftables — 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, implemented as a managed eCLR C# firmware library running on the PLCnext runtime. That is the single deployed implementation (it is what runs on the workshop’s Virtual PLCnext Control); earlier Structured Text and C++ ports are frozen as reference material only.

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	Pump, Valve, Sensor, PID, Motor	Equipment blocks with state machines (e.g. Stopped, Starting, Running, Stopping, Faulted), interlock checks, condition monitoring
Layer 3 — Sequence	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

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, command shapes) is what the IO AI code generator produces; 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)

Commands are pulse-style and auto-reset after one scan via edge detection inside the FB. 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 Orin edge beside a separate AXC F controller) the same gRPC services are reached over TCP (gRPC port 41100).

On the edge side this is the plcnext-grpc implementation of the IPlcDriver abstraction. The abstraction also has ethernet-ip, modbus-tcp, and stub drivers; the protocol details and driver selection are covered in PLC communication.

Prefer the gateway for Consystence-managed devices

In the border-gateway model the edge speaks only gRPC to the PLCnext, and the PLCnext speaks CIP to the field. An edge opening CIP or Modbus TCP sessions to a controller directly (the ethernet-ip / modbus-tcp drivers) is the supported interop path for third-party and legacy controllers — prefer the gateway for Consystence-managed equipment. 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). In the reference deployment the field controller is stripped to a passive IO rack — it runs no application logic — and the PLCnext reads inputs and writes outputs against its IO module tags. Analogue values that are not on that rack arrive from separate field instruments on the same isolated subnet.

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 and validated field protocol on the gateway; as gateway field-side protocols, Modbus TCP is reserved for future implementation and PROFINET support is planned via the PLCnext runtime’s native capability. This is distinct from the platform’s native Modbus TCP acquisition driver, which ships — see PLC communication.

Control authority and AI

AI is advisory-only

Consystence AI configures, queries, classifies, and explains — it never commands equipment. The authority for any field action is the PLCnext control program. Operator and platform commands arrive as GDS Input ports; 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 IPlcDriver abstraction, gRPC and CIP details, and driver selection
• Deployment topologies — co-located VL3 versus separate Orin + AXC F, and when the gRPC transport is a socket versus a wire
• VL3 edge setup — provisioning the controller hardware that hosts the gateway
• Network security — the edge IT/OT firewall that complements field-network segmentation