OPC UA and MQTT in factories: where each fits

Two protocol names come up in almost every factory data conversation, and they are often presented as rivals. They are better understood as two tools with different shapes. OPC UA is a way to ask a machine a structured question and get a structured answer. MQTT is a way to shout a small message to everyone who has asked to hear it. Most plants that get their data flowing well end up using both, in the places each is good at.

Two protocols, two jobs

OPC UA is a client-server protocol with an information model. A server, typically running on a controller or a gateway, exposes an address space: a tree of nodes with names, types, values and relationships. A client browses that tree, reads and writes values, calls methods, and can subscribe to be told when a value changes. The protocol carries security, sessions and rich typing. It was designed by and for the automation industry to replace an older, Windows-bound generation of the same idea.

MQTT is a publish-subscribe messaging protocol standardized by OASIS. Clients connect to a broker. A publisher sends a message to a topic; the broker delivers it to every client subscribed to that topic. Messages are small and their payload is whatever the publisher decides: a number, a string, a JSON document, a binary blob. MQTT knows nothing about what the data means. It was designed for unreliable networks and constrained devices, and it is light enough to run on a sensor node.

The shape difference is the whole story. OPC UA is about a client talking to a specific server about a specific structure of data. MQTT is about many-to-many delivery of messages with no built-in structure.

How OPC UA works

An OPC UA server organizes everything it knows as nodes. A node has a browse name, a node id, a data type, and references to other nodes, so a motor object might contain a temperature variable, a speed variable and a start method. Because the structure is discoverable, a client can connect to a server it has never seen and find out what is there by browsing, in the same way a file browser explores a disk.

Reading is on demand: the client asks for a value and gets the value with a timestamp and a status code that says whether the reading is good. Subscriptions let the client register interest in a set of nodes and receive updates when they change or at a fixed interval, which is how a SCADA display keeps its numbers current without polling.

Security is built in. Clients and servers authenticate with certificates, sessions are encrypted, and access can be restricted per user. This is one of the reasons OPC UA is trusted for connecting to control systems: the machine can decide who is allowed to read what.

The information model is where OPC UA does its most valuable and least visible work. Companion specifications define standard object types for classes of equipment, so a machine from one vendor can describe itself in the same vocabulary as a machine from another. When that is used well, a client written for one machine works with the next.

The cost is weight. An OPC UA server is a substantial piece of software, sessions are stateful, and each client holds its own connection to each server. That is fine for a control room talking to controllers. It is awkward for a thousand small sensors talking to a cloud.

OPC UA also defines a publish-subscribe extension, which can carry its structured data over MQTT as a transport. That is how the two protocols meet in practice, and it is covered below.

How MQTT works

An MQTT client opens a single long-lived TCP connection to a broker, authenticates, and from then on either publishes messages or subscribes to topics or both. Topics are strings with a slash-separated hierarchy, chosen by the people who design the system: something like a site, an area, a line, a machine and a measurement. Subscribers can use wildcards to receive whole branches of that tree.

Each message carries a quality of service level that decides how hard the broker and client work to deliver it: fire and forget, at least once, or exactly once. A message can be retained, so a new subscriber immediately receives the last value published on that topic. A client can register a last-will message that the broker publishes on its behalf if the connection drops unexpectedly, which is how the rest of the system learns that a gateway went offline. The MQTT explainer on this site goes through each of those features, and the MQTT against CoAP comparison covers the alternative for very small devices.

The payload is opaque to the protocol. A plant has to decide its own conventions: units, timestamps, and a format for the value. Without a convention, every subscriber has to know every publisher’s habits. Several open specifications exist that define a topic structure and a payload format for industrial use (Eclipse Sparkplug is the best known), and adopting one early is the single best thing a team can do for the years that follow.

MQTT’s strengths are its lightness, its fan-out, and its tolerance of poor networks. A sensor node with a small microcontroller can run a client. A broker can serve a great many clients. A gateway that loses its connection reconnects, and its last-will and retained messages keep the rest of the system informed in the meantime.

Where OPC UA fits

OPC UA fits wherever the data lives in a controller and someone needs structured, secured, on-demand access to it. Reading process values from a PLC into a SCADA system. Letting a quality system query a machine’s current recipe. Giving a maintenance tool a browsable view of every drive on a line. Anywhere a client needs to ask a specific question, get a typed answer with a status, and be certain who it is talking to.

It fits at the boundary between the plant and the outside too, because its security model lets a site expose a carefully limited address space to an outside client without opening the controller itself.

It fits less well when the number of producers is large, when the network is unreliable, or when many consumers need the same data. Each of those is where the client-server shape starts to strain.

Where MQTT fits

MQTT fits wherever data needs to be collected from many sources and delivered to many consumers. Sensor nodes and gateways publishing readings. Machine data being fanned out to a historian, a dashboard, an alert engine and a cloud analytics service at once, without any of them being configured on the machine side. Assets on cellular or low-power links, where a lightweight protocol that survives dropouts is essential.

It fits the “add a consumer later” pattern that every data project eventually needs. A new tool subscribes to the topics it wants; nothing upstream changes.

It fits poorly where a consumer needs to browse what is available, needs strong typing, or needs to write to a controller with the assurance that only authorized clients can. MQTT can be secured with certificates and access control at the broker, but the protocol has no idea what a value means or which client is entitled to change it.

Using OPC UA and MQTT together

The pattern that most plants converge on uses OPC UA close to the machines and MQTT above them, which is the same split the edge computing article describes for processing. A gateway, or the controller itself, acts as an OPC UA client that reads the structured data from the control layer, then publishes it as MQTT messages to a broker. Everything upstream subscribes. The controllers see one well-behaved OPC UA client; the rest of the enterprise sees a stream of topics.

The OPC UA publish-subscribe extension formalizes this by letting OPC UA’s own structured messages travel over MQTT as the transport. Where it is supported, it keeps the information model intact all the way to the subscribers. Where it is not, a gateway that maps OPC UA nodes to MQTT topics with a documented payload format does the same job with more manual setup.

Whichever variant you use, the division of labor holds. OPC UA answers “what is this machine, what does it know, and may I read it?” MQTT answers “how do I get that reading to everyone who needs it, cheaply and reliably?” A plant that assigns each protocol its job, and writes down its topic and payload conventions before the second machine is connected, will find both easy to live with.