Modbus, OPC UA and MQTT Are Three Theories, Not Three Transports

The three protocols that move most industrial data were born decades apart, to different parents, for different reasons.

Modbus, from 1979, is a child of the serial age: a master asks a slave for the contents of numbered registers, and the registers say nothing about what they mean.

OPC UA, from 2008, is a child of the interoperability wars: a server offers a browsable, typed address space where a value arrives with its units, status and timestamp attached — because the point was to stop re-keying meaning at every boundary.

MQTT, from 1999 and industrialised through the 2010s, is a child of the thin pipe: publishers push small messages to topics on a broker, subscribers hear only what they asked for, and the network carries traffic proportional to change.

None of the three is obsolete. None is universal. And an architecture that treats them as interchangeable transports — rather than as three different theories of what communication is — will keep paying the difference in integration labour, forever, without ever locating the invoice.

Theory one: shared memory, read remotely

Modbus’s theory is that communication is one device reading another’s registers.

Its virtues are why it survives. It is implemented in nearly everything, simple enough to debug with a laptop and a serial tap, and cheap to bridge onto TCP.

Its silences are structural, and they are the whole story for a data architecture. Registers carry no units. No scaling. No quality. No timestamp — values are “now”, meaning whenever the poll happened to occur. No server-side change notification, so you poll or you hear nothing. And classic Modbus carries no security, which downstream architecture has to compensate for rather than assume away.

Every one of those silences becomes work somewhere else: scaling tables, register maps, timestamp assignment at the poller, and a compensating security design. The map from register to meaning lives somewhere — in the gateway, in a spreadsheet, in one engineer’s memory — and where that somewhere is, is an architecture decision whether or not anyone made it deliberately.

Theory two: a typed model, served

OPC UA’s theory is that communication is browsing and subscribing to a structured address space.

Values are typed nodes carrying units, status codes and source timestamps. An information-model layer lets whole industries standardise what a particular kind of device looks like. Subscriptions with deadbands replace polling. Security — authentication, signing, encryption — is part of the specification rather than an afterthought bolted on by the integrator.

The price is heft. More configuration. More compute at both ends. Certificate lifecycles that somebody has to own for the life of the installation.

And one procurement trap worth naming plainly: there is enough profile flexibility that “supports OPC UA” underdetermines what two products can actually do together. Interoperability is a per-profile, per-model question. It is worth testing before purchase, in a lab, with the actual firmware versions — rather than after, on site, with a deadline.

Theory three: events, brokered

MQTT’s theory is that communication is publishing state changes to topics on a broker that decouples every producer from every consumer.

With report-by-exception, retained messages and last-will announcements, a thin link carries a live plant image. Adding the Sparkplug B specification supplies what bare MQTT deliberately omits — a topic namespace convention, a compact payload encoding, and birth and death certificates carrying full state, which is the answer to report-by-exception’s silence problem.

The structural trade is that the broker is now infrastructure. Its availability, capacity and security posture belong to the chain. And bare MQTT’s flexibility means that without a payload discipline like Sparkplug or a governed namespace, every publisher invents its own dialect, and the integration debt returns wearing a modern badge.

Three consequences for the chain

Conversion is where meaning dies. Every gateway that turns Modbus into OPC UA into MQTT is reassigning names, units, timestamps and quality. Each hop either carries the value’s original properties forward or forges new ones. The rule that follows is short: convert as few times as possible, as close to the source as possible, under a governed mapping.

The theories compose. A common modern pattern reads devices by Modbus at the edge, models and serves them as OPC UA where semantics and interoperation matter, and ships change events north over MQTT where bandwidth and fan-out matter. That is not a compromise. It is each theory used where its assumptions actually hold.

Timestamps differ by theory. A Modbus poll timestamps at the poller. OPC UA carries source timestamps. MQTT carries whatever the publisher chose. That difference is invisible on every dashboard demo, and it decides whether events across systems can ever be honestly ordered afterwards.

An exercise that costs an afternoon

Draw the actual protocol path for one value that somebody uses to make a decision. Not the architecture diagram — the real path, hop by hop, from the device that first named the value to the screen where it is read.

Most paths turn out to have more hops than the diagram claims.

• ✓ Count the conversions. Every box where the protocol changes is a point where names, units, timestamps and quality were preserved or invented. Three conversions is common; three governed conversions is not.
• ✓ At each hop, ask what the value carried in and what it carried out. A quality code that exists at the transmitter and not at the dashboard was dropped somewhere specific, and the somewhere is findable.
• ✓ Find where the register-to-meaning map lives for any Modbus segment. If the answer is a spreadsheet on someone's drive, or a memory, that is the architecture — write it down as such.
• ✓ Test for re-stamping. Compare the source timestamp at the device with the timestamp on the same value after the last hop. Gateways that replace source time with 'now' are common and silent, and one hour of testing settles it.
• ✓ Ask what happens to each hop when the one upstream stops. If the answer everywhere is 'the last value keeps being served', you have found how a stuck chain looks normal.

The finding that changes a roadmap is usually the conversion count. Reducing three hops to one is rarely a product purchase — it is a decision to read closer to the source and fan out afterwards, and it removes an entire class of argument about which system is right.

For a broader view of how these protocol paths sit inside a full five-layer architecture, the machine data flow reference walks the same ground from PLC to decision owner in one pass.

How many times does your most important number change protocol before somebody reads it?

The three theories, the comparison of what a value carries under each, and the three consequences — conversion, composition, timestamps — are from Industrial IoT and Data Architecture: From Sensor to Historian to Dashboard (Part 2: Edge and Acquisition, section 2.3).