MQTT is a publish/subscribe messaging protocol that carries data over TCP/IP through a central broker, with a fixed header of two bytes in the simplest case and three delivery guarantee levels. Designed in 1999 for telemetry over scarce bandwidth, it is standardised by OASIS in versions 3.1.1 and 5.0; version 3.1.1 was also published as ISO/IEC 20922.
Where it comes from
The protocol was created in 1999 for pipeline telemetry over expensive, slow and unreliable satellite links. IBM named it MQ Telemetry Transport, but since the handover to OASIS in 2013 the name is no longer treated as an acronym: MQTT is simply the name of the protocol. That original constraint, count every byte and survive a dropped link, explains almost every design decision, and is also why it fits a plant so well, where the network is rarely the problem but intermittency and the number of consumers certainly are.
Broker, topics and retained messages
The central piece is the broker: a server every participant connects to and which distributes the messages. Nobody connects to anybody else directly. A publisher sends a message to a topic without knowing, or caring, who will receive it; a subscriber asks for a topic without knowing who publishes it. That decoupling turns an integration of N systems against M systems into N+M connections against a single point.
A topic is a UTF-8 string with levels separated by slashes, such as plant/line1/press3/barrel_temperature. Nothing has to be declared anywhere: the topic exists as soon as someone publishes to it. Subscriptions accept two wildcards, + for a single level (“every machine on line 1”) and # for the rest of the tree, which may only appear at the end. Published messages, by contrast, never carry wildcards. That freedom cuts both ways: the protocol imposes no hierarchy, so the topic structure is a design decision that must be taken deliberately and is expensive to change later, because renaming a topic breaks every subscriber at once.
By default the broker stores nothing: a system that connects three minutes after a machine published its temperature never sees that value and has to wait for the next one. Retained messages solve this: publishing with the retain flag set makes the broker keep that message (one per topic, always the latest) and deliver it immediately to anyone who subscribes afterwards. Publishing a retained message with an empty payload clears the previous one. Without retention there is no current state in the broker, only a stream of events, and that distinction decides whether a dashboard starts with data or blank.
Quality of service and session lifecycle
The three QoS levels grade delivery guarantees. QoS 0 delivers at most once: the message is sent unacknowledged, so a link that drops mid-way loses it. QoS 1 delivers at least once, with explicit acknowledgement and retransmission, which means the receiver may see duplicates and must tolerate them. QoS 2 delivers exactly once through a four-message exchange, at the cost of more latency and more state at both ends.
The nuance most often missed is that QoS is negotiated per hop, not end to end: a publisher sending at QoS 2 and a subscriber that subscribed at QoS 0 produce a QoS 0 final delivery, because each leg applies the lower of the two. In industrial telemetry the practical choice is usually QoS 1 with local buffering on the publishing device, plus idempotent consumers that do not break when a value arrives twice.
The connection lifecycle provides the other half of the robustness. On connecting, a client declares an identifier and may register a last will and testament up front: a topic and a payload the broker will publish on its behalf if the connection drops abnormally, without a proper goodbye. A device failure therefore becomes an explicit event arriving on the same channel as the data, instead of being inferred from silence. The mechanism relies on the keep alive interval, which sets how often the client must show signs of life before the broker declares the connection dead. Sessions can also be persistent: the broker remembers subscriptions and queues QoS 1 and 2 messages while the client is offline, delivering them on reconnection. MQTT 5.0 adds user properties, reason codes on responses, message and session expiry, topic aliases that avoid repeating long strings, and shared subscriptions that spread one stream across several instances of a consumer.
Where it fits on the plant floor
In a typical factory, machine data has always moved by polling: the SCADA asks at fixed intervals over Modbus, over a vendor protocol or over OPC DA, and the device answers. That model carries three costs, all of which surface as soon as a second party wants the data. Latency is set by the interrogation cycle rather than by the event, so anything shorter than the cycle may never be seen. Every new consumer adds its own load, because each one queries the same machine independently. And the device cannot raise a hand: it only answers when asked.
Publish/subscribe inverts that. Data is published once, on change or on schedule, and the broker fans it out to as many consumers as exist: machine load stops depending on how many systems are watching. Adding a historian, a dashboard or a predictive model requires no change on the machine and no extra polling loop; subscribing is enough. What MQTT is not deserves equal clarity: it is not deterministic, it does not replace a fieldbus and it does not live inside the control loop. It occupies the layer running from the machine towards information systems, not the one governing motion.
The reality of the installed base is that almost no controller publishes MQTT by itself. Typically an industrial gateway or an edge computing device reads the PLCs and instrumentation over their native protocols and publishes on their behalf. Some recent controller ranges and some IO-Link masters with Ethernet uplinks already include it, but they will remain a minority for years.
MQTT versus OPC-UA
Treating them as same-level alternatives is the usual mistake. MQTT is transport: it moves a payload the protocol treats as an opaque sequence of bytes. What that content means, which units it carries, what type it is or how it relates to the rest of the plant are questions MQTT deliberately leaves open. OPC-UA does the opposite: its main contribution is a semantic information model, a browsable address space where each variable carries name, type, units, relationships and metadata, plus a session model with authentication, encryption and signing built into the specification itself.
In practice they compete little and combine often. The most widespread pattern is to read the equipment over OPC-UA, where semantics are already solved, and distribute the result over MQTT, where fan-out to many consumers and tolerance to poor networks are already solved. The OPC-UA specification acknowledges this: its publish/subscribe model (part 14) supports MQTT as a transport, with payloads encoded in JSON or in binary form. In that setup nothing is chosen over anything else; the OPC information model rides on the MQTT transport. The full comparison is in the OPC UA vs MQTT guide.
MQTT versus HTTP/REST
With HTTP the initiative always belongs to the client: someone asks and the server answers. To learn whether a value changed you have to ask again: polling once more, now over a protocol whose text headers weigh hundreds of bytes per request and which opens and closes connections frequently. With MQTT the TCP connection is established once and kept open, and the broker pushes the message to the subscriber the moment it arrives; per-message overhead is counted in single bytes rather than hundreds.
HTTP has real advantages worth acknowledging: it crosses corporate firewalls and proxies without argument, fits naturally into management APIs, is trivial to debug and requires no session state. The sensible rule is to use each where it performs: MQTT for continuous telemetry from many sources to many consumers, HTTP for point queries, transactions and integration with business systems such as the ERP. When network policy will not let port 1883 out, the usual answer is not to abandon MQTT but to wrap it in WebSocket and send it over port 443.
Sparkplug B and the unified namespace
The gap MQTT leaves, saying nothing about content or structure, is what Sparkplug B fills, the Eclipse Foundation specification that fixes a closed-form topic namespace, a typed Protocol Buffers payload and, above all, an explicit session lifecycle. Sparkplug uses the MQTT last will as a death certificate and, on connecting, publishes a birth certificate listing every metric of the node with its type and initial value. The result is a self-describing system: a new consumer learns which signals exist without prior mapping tables.
On that base sits the Unified Namespace pattern: a single namespace where the current state of the whole operation is available and any new system plugs in without bespoke integrations. MQTT is the usual transport for that pattern but does not constitute it. A broker with no naming convention, no typing and no retention policy is not a unified namespace; it is a dumping ground for numbers. The hard part of the project is never standing up the broker, it is agreeing the model.
Security
The base protocol encrypts nothing by itself: port 1883 carries everything in the clear, including the username and password travelling inside the connect message. The correct configuration is TLS, normally on port 8883, with authentication by credentials or by X.509 client certificate. On top of that, nearly every broker supports per-topic authorisation, which is the piece usually missing: defining what each system may publish and read, so a dashboard cannot write to a command topic and a line device cannot read another site’s data.
The broker is in fact the natural place where the OT/IT boundary materialises: a common pattern deploys a broker at the edge, inside the plant network, and bridges it to a corporate broker so traffic leaves in one direction over a single outbound connection, with no inbound ports opened towards the industrial network.
What it takes to get plant data to a broker
Publishing over MQTT is not the same as reading the machine: these are two separate legs and the first one rules. The real latency of the chain is set by the cycle at which the gateway interrogates the controller or the instrument, not by the transport protocol; MQTT adds milliseconds, the underlying poll adds tenths of a second or whole seconds. For the same reason, the timestamp belongs at the gateway, next to the machine, and not at the consumer at the end of the path: stamping at the destination turns any queueing or network delay into a dating error that cannot be corrected afterwards.
The engineering work concentrates in four decisions. The topic hierarchy should mirror the physical plant, usually along ISA-95 lines (enterprise, site, area, line, cell), with stable names that survive tomorrow’s extra machine, since renaming a topic breaks every subscriber at once. The payload format has to be fixed, either with a house JSON convention carrying value, units, quality and timestamp, or by adopting Sparkplug B; without that convention every integration starts from zero again. The retention and QoS policy decides whether a starting consumer sees current state or waits for the next change, and whether it tolerates duplicates. And the publication rate is sized from the dynamics of each variable: report by exception, with a deadband that filters measurement noise and a periodic heartbeat that separates “no change” from “no communication”, keeps the historian from filling with identical values.
As for interference with control, publishing is an outbound operation that touches neither the controller logic nor its interlocks, and the extra load falls on the gateway and the broker, not on the machine: the device is read once no matter how many consumers subscribe, which is precisely the advantage over multiple pollers. The point demanding attention is the opposite direction. MQTT is bidirectional and nothing prevents publishing towards the plant; the moment a topic is used to write setpoints it stops being a data layer and becomes a control function, with the design, validation and authorisation requirements that implies. Separating read topics from command topics is an architectural decision, not a convenience.
Finally, network outages. A publishing gateway must buffer locally while the link is down and drain the queue on recovery, using QoS 1 and a persistent session; without that, a brief corporate network glitch becomes a permanent hole in the historian. And the broker has to be sized: concurrent client count, queue depth and message rate are the three parameters that decide whether it holds, and a # subscription from a slow client is the fastest way to degrade the whole system.
Related terms
MQTT is the usual transport of the Unified Namespace pattern and a central piece of the OT/IT bridge, complementary to OPC-UA, which excels at reading equipment with semantics, and to Sparkplug B, which adds the convention it lacks. Downstream it feeds on whatever the gateway can extract from PLCs and instrumentation over Modbus and other field protocols; upstream it feeds the historian and the analytics layer. Broker deployment, topic hierarchies and plant data publishing are the scope of MQTT integration.