OPC-UA

What is OPC-UA?

OPC-UA (Open Platform Communications Unified Architecture), formally IEC 62541, is a communication standard that lets software read data from industrial equipment — PLCs, SCADA systems, HMIs, robots, CNC machines — regardless of who manufactured them. Published by the OPC Foundation, first released in 2008, and now embedded directly in controllers from Siemens, Rockwell, Schneider, ABB, Beckhoff, and most other major PLC vendors.

Think of it as USB for factory equipment. Before OPC-UA, reading data from a Siemens PLC required Siemens software. Reading from a Rockwell PLC required Rockwell software. OPC-UA gives them a common interface.

Why it matters for manufacturing

Most factories run equipment from multiple vendors. Line 1 has Siemens PLCs. Line 2 has Allen-Bradley. The packaging machine speaks Modbus. The robot speaks its own proprietary protocol. Getting all of them to report data to one dashboard or historian used to require a different driver for each vendor — or an expensive middleware platform.

OPC-UA solves this at the protocol level. If your PLC has an OPC-UA server built in (most modern PLCs do), any OPC-UA client can read its data. No vendor-specific driver. No middleware license. One standard protocol.

That said, OPC-UA carries a convention tax worth understanding. See "when you do and don't need it" below.

How it works

Client/server architecture:

OPC-UA Client (your software) → connects to → OPC-UA Server (runs on the PLC or gateway)

• Address space — the server exposes data as a tree of nodes. Each node represents a variable (temperature, speed, status), an object (a machine, a production line), or a method (start, stop, reset). Clients browse the tree to discover what's available.
• Read/Write — clients can read current values or write setpoints. Read is the common case. Writing requires explicit permissions (for good reason — you're sending commands to physical equipment).
• Subscriptions — instead of polling, clients subscribe to nodes and get notified when values change. More efficient than repeated reads.
• Security — built-in TLS encryption and X.509 certificates. Unlike MQTT (which relies on the broker for security), OPC-UA encrypts end-to-end between client and server. This matters in OT environments where data passes through untrusted network segments.

Key difference from MQTT: OPC-UA is request/response (client asks server for data). MQTT is publish/subscribe (devices push data to a broker). OPC-UA gives you a rich data model with types and structure. MQTT gives you lightweight, fire-and-forget messaging. They solve different problems and are often used together.

When you do and don't need it

You need OPC-UA when:

• Reading data from modern PLCs (Siemens S7-1500, Rockwell CompactLogix, Beckhoff TwinCAT) — the OPC-UA server is already built in. Just enable it and connect.
• Integrating with SCADA or MES software that speaks OPC-UA natively
• You need rich data modeling — typed variables, hierarchical structure, method calls
• Security is critical — built-in encryption beats bolting TLS onto Modbus

You probably don't need OPC-UA when:

• Reading simple sensor data (temperature, vibration, flow) — MQTT is lighter and easier
• Your equipment only speaks Modbus or other legacy protocols — you'd need a gateway anyway, and at that point the gateway can speak MQTT just as easily
• You have fewer than 10 data sources — point-to-point integration with a Python script may be faster than learning OPC-UA's 14,000-page specification
• You just want a dashboard — a MING stack (Mosquitto + InfluxDB + Node-RED + Grafana) gets you there without touching OPC-UA

The convention tax: OPC-UA is sometimes prescribed as "the standard you must adopt before your systems can interoperate." That's the vendor story. In reality, a factory with 5-50 machines often does better with simple point-to-point integration (Modbus reads, REST APIs, even CSV exports) than with a full OPC-UA implementation. OPC-UA pays off at scale (100+ machines, multi-vendor environments, enterprise integration requirements). For a first IoT project, it's often premature optimization.

OPC-UA + MQTT: the modern pattern

The OPC Foundation recognized that OPC-UA's client/server model doesn't scale well for cloud and IoT scenarios (it requires inbound firewall ports on the server side). OPC-UA PubSub mode was introduced to solve this — it can transport OPC-UA messages over MQTT or AMQP, combining OPC-UA's rich data model with MQTT's lightweight pub/sub transport.

Sparkplug B is the alternative approach: it adds a standardized payload format (with device/metric semantics) to plain MQTT, solving the "no data model" problem without requiring OPC-UA at all. Both approaches work. Sparkplug B is simpler; OPC-UA PubSub is richer.

Common pairings

• Apache PLC4X — open-source library that reads from PLCs via OPC-UA, S7, Modbus, and other protocols. Used by StreamPipes for its connectivity layer.
• Node-RED — has OPC-UA nodes for reading/writing PLC data in flow-based pipelines
• United Manufacturing Hub — uses OPC-UA as one of its primary data ingestion protocols for the Unified Namespace
• Eclipse Milo — open-source OPC-UA stack for Java, the foundation for many open-source implementations
• Prosys OPC UA Simulation Server — free tool for testing OPC-UA clients without a real PLC

Getting started

1. Check if your PLC already has OPC-UA — most Siemens S7-1200/1500, Rockwell CompactLogix 5380+, and Beckhoff TwinCAT controllers have OPC-UA servers built in. Enable it in the PLC configuration (Siemens: TIA Portal, Rockwell: Studio 5000).
2. Browse the address space — use a free OPC-UA client like UaExpert or Prosys OPC UA Browser to connect to your PLC and see what data is available.
3. Read your first variable — in Node-RED, drop an OPC-UA client node, configure the endpoint (e.g., opc.tcp://192.168.1.10:4840), and read a tag. Or use Python with the opcua or asyncua library.
4. Decide your architecture — if you need real-time dashboards, route OPC-UA data through Node-RED to MQTT, then to InfluxDB + Grafana. If you need enterprise integration, look at a Unified Namespace approach with MQTT + Sparkplug B or OPC-UA PubSub.