Nvidia Orin Edge (Variant)

Nvidia Orin is a supported edge hardware variant. It runs the exact same Consystence edge runtime as the primary PLCnext VL3 — a single-silo Orleans application on .NET 10 — and talks to controllers through the same IPlcDriver layer. The differences are the box it runs on and the field link it uses.

Workshop-proven, hardware validation pending

Orin support carries the same maturity caveat as the VL3 setup: the edge runtime is portable to Orin, and the direct-CIP topology this page describes is deployed in the workshop against a ControlLogix controller today — but this is not a shipped GA install path. Treat this page as the target setup, not a GA procedure.

If you have read the VL3 setup guide, there is very little here that is new. This page exists to answer one question precisely: what changes when the edge runs on Orin instead of VL3? The short answer is very little — a different field link and a couple of chassis-specific config values — and specifically, Orin is not a standalone GPU inference appliance.

Same runtime, different hardware

There is one edge runtime, built once, deployed to either hardware target. Both run the same .NET 10 single-silo Orleans runtime, the same store-and-forward buffer, and the same IPlcDriver abstraction.

flowchart TD
  RT["Consystence edge runtime<br/>.NET 10 · single-silo Orleans"]
  RT --> VL3["PLCnext VL3<br/>(primary)"]
  RT --> ORIN["Nvidia Orin<br/>(GPU-capable variant)"]
  VL3 -->|"gRPC over UDS"| BG["Co-located PLCnext<br/>border gateway"]
  BG -->|"EtherNet/IP CIP"| FIELD["Field controllers"]
  ORIN -->|"EtherNet/IP CIP<br/>(direct)"| FIELD
  ORIN -.->|"gRPC TCP :41100<br/>(remote PLCnext gateway)"| BG

Because the runtime is hardware-agnostic, most of what is documented for the VL3 applies unchanged on Orin — the one structural difference is the PLC link:

• PLC communication — the VL3’s gRPC-over-UDS path (/run/plcnext/grpc.sock) does not apply on Orin: a Unix domain socket is machine-local, and an Orin has no co-located PLCnext runtime. An Orin either speaks EtherNet/IP CIP directly to the controller (the ethernet-ip driver — the topology deployed in the workshop today) or reaches a separate PLCnext gateway over gRPC TCP (PlcNext:GrpcHost, default port 41100). See PLC communication.
• Driver selection — the same IPlcDriver implementations (plcnext-grpc, ethernet-ip, modbus-tcp, stub); no Orin-specific driver exists.
• Store-and-forward — SQLite buffer over gRPC (HTTP/2), surviving upstream disconnects and power cycles.
• IT/OT segmentation — nftables firewall splitting the IT interface (upstream) from the OT interface (field). See network security.
• Identity and licensing — the identity sent at registration is the configured Edge:Id, required in the edge’s local configuration on any chassis (bootstrap fails without it; the target design is an activation flow that enrols the device by its write-once install identity, with Edge:Id remaining a display label — not yet shipped). That write-once install ID, minted on the device at first boot, is also the licensing identity to which the account-signed offline licence artifact is bound. Under the per-seat model an edge consumes an Edge seat from the org’s licence pool, enforced on-device via that artifact — purchase/billing is not yet live pre-GA.

Tip

Follow the VL3 edge setup procedure for Orin as well — there is no separate Orin install path, and the install steps, systemd unit, and registration handshake are the same. Two config values are chassis-specific: the PLC driver (see above) and the firewall interface names — the nftables policy defaults to eth0 (IT) / eth1 (OT), so on an Orin set Firewall:ItInterface / Firewall:OtInterface to its actual NIC names (e.g. a WiFi upstream and a dedicated Ethernet link to the controller).

Why choose Orin: the GPU

The distinguishing property of Orin is its GPU. Today the edge runtime does not use it for anything: there is no on-edge TensorRT or ONNX inference shipping on either VL3 or Orin. The GPU matters only as forward provisioning for Edge ML.

Edge ML is on the roadmap

On-edge machine learning is not yet generally available. The planned model is cloud-trained ONNX, executed on the edge in an advisory capacity. CPU inference is the baseline — it has to work on the GPU-less VL3 — and GPU-compiled inference (TensorRT) on Orin is the design option for GPU-dependent workloads such as vision models and complex autoencoders. None of this ships yet: Orin’s GPU does not enable any inference feature today. Treat it as future capacity, not a current feature.

AI is advisory only

Consystence AI — at the edge, the site server, or the cloud — only configures, queries, classifies, and explains. It never commands equipment. Control actions remain with the controller logic and hard interlocks in the IO modules and safety relays. An Orin GPU does not change this boundary. See AI architecture.

What Orin is not

Orin in Consystence is a general-purpose edge node that happens to have a GPU. It is not:

• a standalone TensorRT inference appliance — it runs the full edge runtime (tag polling, store-and-forward, firewall), not just a model server;
• a PLCnext host — an Orin does not run the PLCnext control runtime. It either connects directly to existing field controllers over EtherNet/IP CIP (the topology deployed today) or reaches a separate PLCnext border gateway over gRPC TCP; control logic stays in the controller either way;
• a different software product — there is no “Orin edition”, only the one edge runtime on different silicon.

Setup

Use the VL3 edge setup guide as the canonical procedure. The systemd unit, registration handshake, and OT-network hardening approach are the same on Orin. Set the required Edge:Id in local configuration exactly as you would on any chassis, choose the Orin-appropriate PLC driver, and point Firewall:ItInterface / Firewall:OtInterface at the Orin’s NIC names (see the tip above).

For where Orin and VL3 fit alongside site servers and the border gateway, see deployment topologies and the edge overview.