What is OPC UA and how does it work?
How OPC UA models machine data, how client/server and PubSub work, how security and companion specs fit in, and how it compares with MQTT and Sparkplug.
Photo: Raymond Sime / Unsplash
After reading this article you will be able to:
- Explain how an OPC UA address space describes a machine with typed objects, variables and methods
- Tell apart client/server sessions from PubSub over UDP or MQTT, and choose between them
- Decide where OPC UA, OPC UA FX, plain MQTT and Sparkplug each fit in a plant
On this page
OPC UA (Open Platform Communications Unified Architecture) is the standard industrial machines use to expose their data together with its meaning. A machine runs an OPC UA server that publishes a structured, typed model of itself: this is a pump, it has a speed in revolutions per minute, a bearing temperature, a running state and a Start method. A client such as a SCADA system, an MES or an edge gateway can browse that model, read and write values, subscribe to changes and call methods, all over an encrypted, authenticated connection.
The OPC Foundation released OPC UA in 2008 as a platform-independent successor to OPC Classic, which was tied to Windows through Microsoft’s COM/DCOM. The specification is maintained by the Foundation as the OPC 10000 series, published free on its online reference, and standardized internationally as the IEC 62541 series. This guide covers the information model, the two communication patterns, security, companion specifications, the newer field-level extension called OPC UA FX, and how OPC UA relates to MQTT and Sparkplug.
What problem does OPC UA solve?
A PLC speaking Modbus offers numbered registers: register 40001 holds a value, and only the documentation says it is the motor speed in tenths of a percent. Every integration starts with a spreadsheet that maps addresses to meanings, and every new machine repeats the work.
OPC UA moves that meaning into the protocol. The server tells the client what each value is, what type and engineering unit it has, how it relates to other values, and what type of equipment it belongs to. A client written once against a standard model of a pump or a robot can connect to any vendor’s implementation of that model. That is the interoperability promise, and it is why OPC UA appears in most Industry 4.0 reference architectures.
How does the information model work?
Everything a server exposes lives in its address space, a graph of nodes connected by typed references. The address space model defines a small set of node classes: Objects (a pump, a sensor, a folder), Variables (a temperature value with its timestamp and status), Methods (Start, Reset), the matching ObjectTypes and VariableTypes, ReferenceTypes that name relationships such as HasComponent or Organizes, DataTypes, and Views.
Types are what make the model useful. A vendor defines a PumpType with its expected components, every pump on the line is an instance of it, and a client that understands PumpType can handle all of them without knowing the plant. Types can inherit from other types, so a centrifugal pump type can extend a generic pump type. Each variable carries a value, a source timestamp and a status code, so a client can tell a fresh good reading from a stale or uncertain one.
How do client/server and PubSub differ?
The original pattern is client/server. The client opens a SecureChannel, then a Session, and calls services: Browse to explore the address space, Read and Write for values, Call for methods, and CreateSubscription with monitored items so the server pushes changes instead of being polled. The usual transport is the binary OPC UA TCP protocol, on port 4840 registered with IANA; HTTPS and WebSockets mappings exist for web clients. Client/server suits configuration, diagnostics and supervisory reads where each client needs its own view.
PubSub (Part 14) adds a one-to-many pattern. A publisher sends DataSets, named groups of values, without knowing who receives them. The specification supports two forms: broker-less, where messages travel as UDP datagrams (often multicast) or raw Ethernet frames in a compact binary encoding called UADP, and broker-based, where messages go through an MQTT or AMQP broker in UADP or JSON. Broker-less PubSub suits fast, frequent exchanges inside a cell; the broker form carries the same data model to the cloud. Publishers and subscribers do not need to be servers or clients at all.
How is OPC UA secured?
Security is part of the core security model, not an add-on. Every application, client or server, has an application instance certificate, an X.509 certificate that identifies the software installation. When a SecureChannel opens, both sides check the other’s certificate against a trust list, then agree on a security policy (the algorithm suite) and a security mode: None, Sign, or SignAndEncrypt. The specification requires None to be disabled by default. On top of the channel, users authenticate with a username and password, an X.509 certificate or a JSON Web Token, and roles can restrict what each user may browse, write or call. PubSub uses a Security Key Service that hands out the symmetric keys a group of publishers and subscribers share.
The weak point in practice is certificate management. Plants with many servers either click “trust” on each new certificate or, worse, leave endpoints in None mode. A Global Discovery Server can act as a certificate manager and push certificates and trust lists to applications, which is the scalable answer. The same PKI discipline described in the device identity guide applies, and OPC UA products are often assessed against IEC 62443.
What are companion specifications?
A companion specification is a standard information model for one kind of equipment, usually written by the OPC Foundation together with an industry association. The reference site lists many: OPC 10000-100 for devices in general, OPC 40001-1 for machinery building blocks, OPC 40010-1 for robotics, OPC 40501-1 for machine tools, OPC 40223 for pumps and vacuum pumps, OPC 30050 for PackML packaging machines, and dozens more. Each defines the ObjectTypes a conforming machine exposes, published as machine-readable NodeSet files that servers and clients can load.
Companion specifications are where the interoperability promise is kept or broken. A server that exposes only a flat folder of vendor-named tags is technically OPC UA but saves the integrator little. When you buy equipment, ask which companion specifications it implements.
What is OPC UA FX?
OPC UA FX (Field eXchange) extends OPC UA down to the field level, where controllers and devices exchange process data in real time, the territory of PROFINET, EtherCAT and other fieldbuses. It is published as Parts 80 to 84. The current release covers controller-to-controller communication: connections are set up through the information model and carry data over PubSub, optionally on Time-Sensitive Networking for bounded latency, with OPC UA Safety for functional safety. Controller-to-device and device-to-device exchanges, and connections over client/server, are planned for later releases. FX is early; for now, plan cell-level networks around the fieldbus your controller vendor supports, and treat FX as a direction to watch.
How does OPC UA compare with MQTT and Sparkplug?
MQTT moves bytes on topics and says nothing about their meaning. Sparkplug, an Eclipse specification published as ISO/IEC 20237, adds a topic namespace, a payload format for process variables and rules for session state on top of MQTT. OPC UA brings the richest model and the strongest built-in security, at the cost of more complex stacks.
| Aspect | OPC UA client/server | OPC UA PubSub | MQTT with Sparkplug |
|---|---|---|---|
| Pattern | Request and subscription per session | One to many, broker-less or via a broker | One to many via a broker |
| Data model | Typed address space, companion specs | Same model, sent as DataSets | Metrics with names, types and metadata |
| Security | Certificates, signed and encrypted channel | Shared group keys from a key service | TLS to the broker, broker access rules |
| Typical place | Machine and cell, SCADA, MES | Cell to cell, cell to cloud | Plant to enterprise and cloud |
The common architecture uses both. Machines expose OPC UA servers; an edge gateway reads them and republishes over MQTT, often with Sparkplug, into a broker that the rest of the business subscribes to. Choose OPC UA when you need to browse, write, call methods or rely on a companion specification; choose MQTT and Sparkplug for fan-out to many consumers across sites. The MQTT guide covers the broker side.
Where to go next
- Industrial IoT: a practical guide places OPC UA in the plant architecture.
- MQTT explained covers the broker that carries PubSub and Sparkplug traffic.
- Device identity, certificates and PKI for IoT explains the certificate work behind OPC UA security.
- Digital twins explained shows where a typed machine model gets used next.
Topics: OPC UA, industrial protocols, IIoT, PubSub, Sparkplug