Edge Overview

The Consystence edge runtime is the component that lives on the plant floor. It bridges a Consystence site server to the controllers and field devices it monitors, and it does so without ever putting probabilistic software in a safety-critical control path. This page introduces the edge model; for the wire-level detail of how tags are read and written, see PLC communication.

The border-gateway model

Consystence does not talk to field devices directly. Instead, a PLCnext border gateway sits between the isolated field network and everything above it, and the edge runtime talks to that gateway.

The gateway (a Phoenix Contact PLCnext — typically an AXC F 3152, or a virtual PLCnext running on the same VL3 hardware as the edge) runs the deterministic ISA-95 process-control logic using the CSY function-block library (pump, valve, sensor, PID, sequence, interlock), authored as a managed eCLR (C#) library on the PLCnext runtime. It speaks CIP / EtherNet/IP to the field devices on an internal, isolated network. The edge runtime then reads and writes the gateway’s abstracted process variables — never the raw field I/O.

This gives three properties that matter on a mining or CHPP site:

• The internal field network (controllers, VFDs, protection relays) is invisible to anything above the gateway.
• The gateway is the single deterministic point of control, and it keeps running its logic if the edge — or the link to the site server — disconnects.
• The edge sees abstracted device and process blocks, not raw registers, so the security and control boundary is enforced in hardware at the gateway’s dual-port Ethernet level.

flowchart LR
  Cell["Consystence site server"] -->|"gRPC"| Edge["Edge runtime"]
  Edge -->|"gRPC over UDS (GDS)"| GW["PLCnext border gateway"]
  GW -->|"CIP / EtherNet/IP"| Field["Field devices"]

Note

Use the vendor-neutral term controller rather than “PLC”. The PLCnext is the border gateway and primary controller; legacy ControlLogix racks downstream of it are reduced to dumb I/O.

The edge runtime

The edge runtime is a .NET 10, single-silo Orleans application. Orleans virtual-actor grains orchestrate its lifecycle: a controller grain coordinates one or more connection grains (each wrapping a PLC driver with reconnect logic), the tag pollers that read on a timer, and the upstream client that streams to the server.

It runs on two hardware profiles, both executing the same runtime:

Profile	Role	Notes
PLCnext VL3 UPC 2440 EDGE	Primary	Runs the edge runtime and the PLCnext control runtime as separate containers on one DIN-rail device. The default for most deployments.
Nvidia Orin	GPU-capable variant	For sites that need GPU-accelerated inference (vision, complex models). Sits alongside or upstream of the controller.

Three responsibilities

1. Controller I/O

The primary path is gRPC over a Unix domain socket to the co-located PLCnext runtime: the edge reads and writes the PLCnext global data space (GDS) port variables through the published RSC data-access services. This is strongly typed (protobuf contracts), the lowest-latency option (no network stack), and symmetric with how the edge talks upstream.

For third-party and legacy controllers that sit outside a border gateway, the edge speaks to them directly via native drivers — EtherNet/IP CIP to a ControlLogix, or Modbus TCP to a Modbus device. This direct path is a supported and expanding interop surface (OPC UA and S7 are future additions); prefer the gateway for Consystence-managed equipment. A shared IPlcDriver abstraction means both paths look identical to the grains above them.

2. Store-and-forward

The edge is designed to operate autonomously. Tags keep polling and buffering locally when the upstream link drops or the device power-cycles. The buffer is an SQLite-backed message store, disk-capped via Upstream:BufferMaxBytes (default 512 MiB) — on overflow the oldest data is dropped first, drops are counted and reported on the heartbeat, and edge health degrades while overflowing. On reconnect it flushes automatically in sequence order. Upstream transport to the site server is gRPC — designed for HTTP/3 (QUIC), which the edge client requests by default, but server-side HTTP/3 is not yet enabled, so deployments today run gRPC over HTTP/2 (TCP).

3. IT/OT firewall and monitoring

The edge enforces network segmentation between its IT (upstream) and OT (field) interfaces. A firewall (built on nftables) keeps the upstream interface to server traffic only and the field interface to the OT network only, while a passive monitor watches the OT interface for traffic anomalies using kernel network statistics. This is the software complement to the hardware boundary the PLCnext gateway already provides.

Edge ML and the advisory boundary

AI is advisory-only

All AI on the platform — site LLM and any future edge ML — is advisory and diagnostic only. It can detect anomalies, predict failures, classify, and explain. It never commands equipment. Every control action goes through the deterministic controller path; hard interlocks live in the I/O modules and safety relays, not in any model. Operators acknowledge and execute.

Roadmap, not GA

On-edge machine learning (for example TensorRT or ONNX inference) is not shipped today — “Edge ML” is roadmap, and remains advisory when it lands. The GPU-capable Orin profile exists to host it in future. Do not assume on-device inference is live.

Where the edge fits

The edge is the second of the four compute tiers (server/cell → edge → border gateway → field devices), with the browser/CLI client surface above them. For the bigger picture see the architecture overview and cell topology; for the core vocabulary (device types, instances, tags) see platform concepts.

Edge capacity is sold as a counted Edge seat pool under an organisation’s licence. Licences degrade rather than kill on grace or expiry, and never gate operator control writes — see licensing.

Not yet GA

The account control plane, cells, and self-serve provisioning that mediate edge licences are workshop-proven but not yet generally available. Treat the cell-mediated licensing flow as forthcoming.

Next steps

• PLC communication — the GDS/gRPC and EtherNet/IP CIP wire detail.
• Architecture overview — the four-tier model end to end.
• API reference — the cell-direct /api/* surface.