Choosing Between Modbus, OPC UA and MQTT

Modbus, OPC UA and MQTT get compared as though a plant had to choose one, which is the source of a great deal of confused architecture. They answer different questions. Modbus is a register-level device protocol, OPC UA is an information model with a protocol attached, and MQTT is a transport pattern with no data model at all. A well-built system frequently uses all three, each on the link where it fits.

Modbus is the incumbent because it is trivial. A device exposes numbered registers, a master reads and writes them, and that is the whole specification. Implementing it takes an afternoon, every device supports it, and it has been running plants for four decades. Its weaknesses are equally structural. There is no self-description: register 40012 means whatever the manual says it means, and if the manual is wrong or missing, the value is unrecoverable. There are no data types beyond sixteen-bit words, so a temperature is an integer scaled by ten by convention and a float is two registers in a byte order that varies by vendor — the source of an entire genre of commissioning bug. There is no discovery, no timestamp, no quality flag, and no security whatsoever. Modbus is right when the device only speaks Modbus, when the value set is small and stable, and when something else in the architecture provides the meaning and the protection.

OPC UA exists to fix the meaning problem. A server exposes an address space of typed, browsable nodes, so a client can discover what exists and what it means rather than being told out of band. Values carry timestamps and quality alongside the number, which matters more than it sounds: a stale value and a live value look identical in Modbus. Companion specifications standardise the model for particular equipment classes, so two compliant machines describe themselves the same way. Security is part of the specification rather than an afterthought — certificate-based authentication, encryption and user authorisation. The costs are real: a heavier stack than a small device may have room for, certificate management that must be planned because certificates expire, and configuration effort that is only repaid when something later consumes the semantics.

MQTT solves a different problem, which is getting data from many places to many consumers over a network you do not control. Clients publish to topics on a broker and other clients subscribe; publisher and subscriber never know about each other, so adding a consumer requires no change at the source. The features that matter industrially are the unglamorous ones: quality-of-service levels, retained messages so a new subscriber gets the current value immediately, and last-will messages so the broker announces a device that dropped off. What MQTT does not provide is any convention for what the payload contains — which is why Sparkplug B exists, adding birth and death certificates, defined metrics and state management on top. MQTT without a payload convention is a well-organised way to ship JSON that nobody can interpret in two years.

The decision is per link, not per company. Talking to a device on a panel: whatever the device speaks, usually Modbus, sometimes OPC UA. Integrating heterogeneous equipment into a plant-level system where the meaning has to survive: OPC UA. Moving data from many sites to a central platform over cellular or shared WAN: MQTT with Sparkplug, usually bridged from OPC UA at the edge. That last pattern — OPC UA inside the plant for semantics, MQTT northbound for transport — is the architecture most greenfield projects converge on, and it is not a compromise. It is each protocol doing the thing it was designed for.

Two failure modes are worth naming explicitly. The first is polling everything. A Modbus master configured to read five thousand registers every second because storage is cheap will saturate a serial segment, add latency to the values that actually matter and generate data nobody reads. Poll fast what changes fast, poll slowly what does not, and use report-by-exception where the protocol supports it. The second is assuming a tunnel is security. Modbus inside a VPN is still unauthenticated once anything reaches the other end, and the UK's NCSC guidance last week named the migration path directly — Modbus to Modbus Security, DNP3 to DNP3-SAv5, OPC DA to OPC UA — while noting that anything without a secure variant belongs in an isolated segment.

The honest summary is that protocol arguments are usually proxies for an architecture question nobody has written down: where does meaning live, who is allowed to talk to what, and what has to keep working when the link does not. Answer those three and the protocol choice for each link mostly makes itself.