Modbus and OPC-UA for Edge AI Agents

Connecting AI Agents to Industrial Machines

To put an AI agent on the factory floor, you have to read the machines — and on the floor that means Modbus and OPC-UA. A Linux edge gateway speaks both: it polls Modbus registers, subscribes to OPC-UA nodes, maps the resulting machine data into an agent graph for reasoning, and writes conclusions back over the same protocols. The PLC stays authoritative for control; the agent advises. Choosing between the two protocols comes down to how much structure and security you need.

Modbus: Simple, Ubiquitous, Register-Based

Modbus is the lowest common denominator of industrial communication. It exposes a device’s data as four primitive areas:

• Coils — single read/write bits (e.g. a relay state).
• Discrete inputs — read-only bits (e.g. a limit switch).
• Input registers — read-only 16-bit values (e.g. a sensor reading).
• Holding registers — read/write 16-bit values (e.g. a setpoint).

It comes in two transports. Modbus RTU runs over serial (RS-485), often multi-drop with one master and many slaves. Modbus TCP wraps the same protocol over Ethernet. The model is request/response and polling-based: the master asks for registers, the slave answers. There is no push.

The limits matter for an agent:

• No native semantics. Register 40001 has no inherent meaning — the mapping lives in a vendor manual or your config.
• No subscriptions. Data freshness equals your poll interval, and over-polling a serial bus causes contention.
• 16-bit values. Floats and 32-bit integers span two registers with vendor-specific byte/word order.
• Thin security. Plain Modbus has no authentication or encryption; isolate it on a trusted segment.

For a single, fully-controlled machine, Modbus is fast to integrate and entirely sufficient.

OPC-UA: Typed, Browseable, Secure

OPC-UA was built to fix exactly those gaps. Its centerpiece is the information model: a self-describing address space of typed nodes, each with a name, data type, engineering unit, and relationships to other nodes. A client can browse the server at runtime and discover that a node is a temperature in degrees Celsius with a defined range — no hard-coded register map required.

Two more features make it ideal for agents:

• Subscriptions and monitored items. Instead of polling, the client subscribes to nodes and the server pushes updates only when a value changes beyond a configured deadband. This cuts traffic and improves freshness simultaneously.
• Security as a first-class concern. OPC-UA defines authentication, signing, and encryption of sessions out of the box, plus role-based access to nodes.

OPC-UA also offers a pub/sub profile for one-to-many distribution, complementing the classic client/server sessions. The cost is complexity: a heavier stack and more setup than Modbus. Open implementations like Eclipse Milo make it tractable on a gateway.

When to Use Each

Dimension	Modbus	OPC-UA
Data model	Raw numbered registers	Typed, browseable information model
Transport	Serial (RTU) / TCP	TCP client/server + pub/sub
Data delivery	Polling only	Subscriptions (change-driven) + reads
Security	None natively	Authentication, signing, encryption
Footprint	Tiny	Heavier stack
Best for	Legacy field devices, simple values	Modern controllers, multi-vendor, semantics

In practice a gateway bridges both: Modbus toward legacy sensors and drives, OPC-UA toward modern PLCs and the SCADA layer. Protocol gateways and the edge gateway itself perform this translation, normalizing everything into one internal representation.

Mapping Machine Data Into an Agent Graph

Whatever the wire protocol, the gateway normalizes each signal into a typed input — temperature, vibration RMS, motor current, machine state — and feeds it as an event into the agent graph. Nodes in that graph apply thresholds, statistical checks, correlation across signals, and where appropriate LLM reasoning over the assembled context. The same gateway can fuse a Modbus current reading with an OPC-UA spindle-state node and an MQTT-published anomaly score from an on-device model.

That last point is worth underscoring: the heavy, high-rate inference often belongs on the device. An STM32F7 running CMSIS-NN or an ESP32 with TFLite Micro can detect anomalies locally and expose a compact result the gateway reads over Modbus or OPC-UA — keeping the agent’s reasoning focused on cross-machine decisions rather than raw signal crunching.

Read vs Write: Keep the PLC Authoritative

The most important design rule: reading is safe, writing is dangerous. Monitoring and advisory output require no control authority and carry no risk. Direct actuation does.

The safe write pattern is advisory, not control. The agent writes a suggested setpoint or a flag to a dedicated holding register or OPC-UA node. The PLC program reads that advisory value and decides — gated through its own interlocks, limits, and safety logic — whether to act on it. The PLC stays the authority. A reasoning mistake or an LLM hallucination can at worst write a number the PLC rejects; it can never directly drive an actuator. Hard safety functions stay in the PLC and in hardwired interlocks, exactly where standards and good practice put them.

How ForestHub Fits

ForestHub is the edge AI agents orchestration platform. It runs as a Go binary in Docker on your Linux edge gateway and connects to your machines as a Modbus master and an OPC-UA client. It ingests registers and nodes, normalizes them, and feeds them into an agent graph that orchestrates the sense-reason-act loop as a deterministic, inspectable, replayable, and auditable structure — with the LLM as one node among many, alongside rules, thresholds, and protocol I/O.

When the agent reaches a conclusion, ForestHub writes back over the same Modbus or OPC-UA link advisingly, into registers or nodes the PLC reads and validates. ForestHub does not run on the PLCs, MCUs, or sensors and does not control machinery directly; the device and control layer handle sensing, on-device inference, and real-time control, and ForestHub sits on the gateway above them. This is the foundation of ForestHub’s edge agents approach and the broader ForestHub solutions for OEMs and system integrators who want reasoning at the edge without disturbing a single line of validated control code.