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 Controller communication.

How the edge reaches controllers

The edge reads controllers directly. It speaks EtherNet/IP CIP to a Rockwell ControlLogix and gRPC (GDS) to a Phoenix Contact PLCnext, on one shared driver layer, and one edge can connect to both. A site server can also read a ControlLogix directly, read-only, without an edge. This is in early access: our engineers enable it per controller, and it has run at a site trial since 28 October 2026. Off by default. Production control stays on your existing control system.

flowchart LR
  Site["Consystence site server"] -->|"gRPC"| Edge["Edge runtime"]
  Edge -->|"EtherNet/IP CIP"| CLX["ControlLogix"]
  Edge -->|"gRPC (GDS)"| PLCnext["PLCnext controller"]
  PLCnext -.->|"CIP / EtherNet/IP (border-gateway topology)"| Field["Field devices"]

Note

Use the vendor-neutral term controller rather than “PLC”. An existing controller that runs its own program keeps that program and its authority over outputs, and Consystence reads it alongside your current system. In the border-gateway design below, the PLCnext runs the control logic and can use a rack such as a ControlLogix as remote I/O.

The PLCnext border-gateway topology

Where Consystence manages the control equipment, the accepted target topology puts a PLCnext border gateway between the isolated field network and everything above it, and the edge talks to that gateway. It has been demonstrated in our workshop on a virtual PLCnext.

In the target design, the gateway (a Phoenix Contact PLCnext controller, such as an AXC F 3152, or a virtual PLCnext) runs the deterministic ISA-95 process-control logic using the CSY function-block library (pump, valve, sensor, PID, sequence, interlock); the gateway’s device and sequence layers are roadmap. 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 speaks CIP / EtherNet/IP to the field devices on an internal, isolated network, and the edge reads and writes the gateway’s abstracted process variables, never the raw field I/O.

The design 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, and the gateway’s own port separation is the field-network boundary.

The edge runtime

The edge runtime is a .NET 10, single-silo Orleans application. Inside it, a coordinator for the edge manages one connection per controller (each wrapping its driver with reconnect logic), the poll groups that read on a timer, and the upstream client that streams to the site server.

The edge runtime is the same on every host:

Host	Status	Notes
PLCnext VL3 UPC 2440 EDGE	Target platform	The target installation runs the edge runtime as its own service beside the PLCnext control runtime on one DIN-rail device, reading the PLCnext over a local socket. We are proving the edge runtime for it on a Linux container in our workshop. See VL3 edge setup.
Nvidia Jetson Orin	Workshop host	A workshop edge has run on a Jetson Orin since 10 September 2026, connected to a physical ControlLogix and a virtual PLCnext. Its GPU is reserved for future advisory edge ML (roadmap). See Nvidia Orin edge.

Three responsibilities

1. Controller I/O

For a Phoenix Contact PLCnext, the edge reads global data space (GDS) port variables through the controller’s gRPC data-access service, and writes them for authorised operator commands. This is strongly typed (protobuf contracts) and symmetric with how the edge talks upstream. On a co-located PLCnext, as in the VL3 target installation, the channel is a Unix domain socket with no network stack; a remote or containerised PLCnext, such as the workshop’s virtual PLCnext, is reached over TCP.

For a Rockwell ControlLogix, the edge speaks EtherNet/IP CIP directly to the controller’s symbolic tag space. Modbus TCP and OPC UA runtime drivers are roadmap. Both drivers sit behind one driver layer, so everything above it handles them the same way.

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 over HTTP/2 (TCP).

3. IT/OT network policy

The edge is designed to sit on two networks: an IT (upstream) interface towards the site server and an OT (field) interface towards the controllers. Network security gives a reference nftables policy for the edge host: default-deny on every chain, no forwarding between the two interfaces, and only the flows the edge needs on each side. A host installer that applies it is planned. On request, the edge’s local diagnostics API reports traffic statistics for its interfaces and any unexpected peers or ports on the OT interface. Where a PLCnext border gateway is used, the gateway’s own port separation is the field-network boundary.

Edge ML and the advisory boundary

AI is advisory-only

All AI on the platform — the advisory assistant and any future edge ML — is advisory and diagnostic only. Today it answers questions and explains alarms and trends; anomaly detection, failure prediction and classification are roadmap. It never commands equipment. Every control action goes through the deterministic controller path; hard interlocks are enforced in controller logic and hardwired safety relays, never in a 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. On the Orin, the GPU is reserved for it. Do not assume on-device inference is live.

Where the edge fits

In the layered model the edge, where one is used, sits between the site server and the controllers, with the browser and CLI clients 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 a counted Edge SKU pool under an organisation’s licence. An edge receives its signed licence through its site server, or from a licence bundle file placed on the edge host, and verifies it offline. Licences degrade rather than kill on grace or expiry, and never gate operator control writes — see licensing.

Public beta

The hosted service is in public beta. During the beta, free individual sandboxes and paid organisations are both arranged with our team: request access.

Next steps

• Controller communication — the EtherNet/IP CIP and GDS/gRPC wire detail.
• Deployment topologies — where the edge sits in each topology.
• Architecture overview — the layered model end to end.
• API reference — the cell-direct /api/* surface.