MQTT is a lightweight publish-and-subscribe messaging protocol. Devices publish data to a central broker under named topics, and any system that cares subscribes to those topics, so a machine sends its data once and every dashboard, historian, MES, and AI model receives it without being wired to the machine directly. It is the backbone of modern IIoT and the unified namespace.
MQTT solves a problem that polling protocols like Modbus cannot: getting floor data to many consumers without building a spiderweb of point-to-point connections. This is a practical primer on how MQTT works, what Sparkplug B adds, why the unified namespace pattern is catching on in manufacturing, and how to roll it out on a real plant floor.
What is MQTT?
MQTT (Message Queuing Telemetry Transport) is a protocol built for sending small messages efficiently over networks that may be slow or unreliable. It was designed for machine-to-machine communication, is an open OASIS standard, and has become the default way industrial devices talk to software. Its defining choice is decoupling: the thing producing data and the things consuming it never talk to each other directly. They only talk to a broker.
That decoupling is the whole trick. A polling protocol makes every consumer ask every device for every value, over and over. MQTT flips it: a device publishes a value once, when it has one, and the broker fans it out to everyone subscribed. This "report by exception" style means far less network chatter than polling, which is exactly what you want when a plant has thousands of tags and a dozen systems that all need them.
The scaling math is what wins people over. With point-to-point polling, connecting five systems to five data sources can mean building and maintaining dozens of separate links, and every new system multiplies the work. With a broker in the middle, each system connects once, to the broker, and the number of connections grows in a straight line instead of exploding. That is the same lesson plants learn when they try to escape data silos: the fix is not more wires, it is a shared hub everyone talks through.
How does publish and subscribe work with a broker?
The broker is the hub, and everything else is a client. A publishing client, a PLC a sensor gateway, an edge device, sends a message to the broker tagged with a topic, like site1/filling/line3/speed. Subscribing clients tell the broker which topics they care about, and the broker delivers every matching message to them. Publishers do not know or care who is listening; subscribers do not know or care who is publishing. The broker is the only thing that has to know about both.
MQTT also lets you choose how hard the broker tries to deliver each message, through three Quality of Service levels: QoS 0 (at most once, fire and forget), QoS 1 (at least once, delivered, possibly twice), and QoS 2 (exactly once, guaranteed single delivery). A speed reading that updates constantly can live at QoS 0; a batch-complete signal that must not be lost or doubled belongs at QoS 2. Picking the right level per topic is part of designing an MQTT system well.
What is Sparkplug B, and why does manufacturing need it?
Plain MQTT is deliberately unopinionated: it moves messages but says nothing about how topics should be named or what the payloads should contain. That freedom is a problem at plant scale, because two integrators will invent two incompatible topic schemes and the data becomes a new kind of silo. Sparkplug B is the specification that fixes this. It is an open standard that defines a strict topic structure and a standard payload format specifically for industrial MQTT.
Sparkplug B adds three things plain MQTT lacks: a defined topic namespace (so every publisher organizes data the same way), typed and efficient payloads, and, critically, state awareness. It tracks whether a device is online or offline through birth and death messages, so a subscriber can tell the difference between "the value is still zero" and "the device fell off the network." For a plant, that state awareness is the difference between trusting the data and guessing at it, which is why Sparkplug B has become the common language for serious industrial MQTT deployments.
What is a unified namespace?
A unified namespace (UNS) is a single, structured, always-current picture of everything happening in the plant, published through one broker, that any system can subscribe to. Instead of each application asking each device for data, every device publishes its current state into the namespace, and every application reads from it. The namespace becomes the single source of truth for the operation's live state.
The payoff is that adding a new consumer becomes a subscription instead of an integration project. A new analytics tool, a dashboard, or an AI assistant just subscribes to the namespace and immediately has the live plant. This is the pattern replacing point-to-point integration spaghetti, and it maps naturally onto the ISA-95 hierarchy you would use for a manufacturing data model. Done well, the namespace and the data model become two views of the same thing: one describes the plant's live state, the other its structure.
Why does MQTT fit IIoT better than polling protocols?
MQTT fits because it scales the way plants actually grow: by adding consumers. With polling, every new system that wants data adds load to every device it polls, and the integration count grows toward chaos. With MQTT, the device publishes once and any number of subscribers can listen at no extra cost to the device. The broker absorbs the fan-out.
It also suits the physical reality of factories, intermittent networks, remote sites, constrained edge hardware, because MQTT was built to be lightweight and to survive dropped connections. Combined with Sparkplug B's state awareness, that resilience is why MQTT has become the transport of choice for moving machine data up off the floor and into the systems that act on it.
None of this makes polling protocols obsolete, and it is worth being honest about that. Modbus and its kin still do the deterministic, real-time control work MQTT was never meant for; MQTT sits above them, moving the data they produce to everyone who needs a copy. The common and effective pattern is a layered one: legacy protocols talk to the machines, an edge device translates and publishes into MQTT, and the whole plant reads from the broker. MQTT does not replace the floor's plumbing, it gives that plumbing a single, scalable way to reach the rest of the business.
How do you roll out MQTT on a plant floor?
You do not rip out your controls to adopt MQTT; you add a broker and publish into it from the edge. A sensible rollout looks like this.
- Stand up a broker. Start with one broker, on a controlled network segment, as the hub everything will publish to and subscribe from.
- Adopt Sparkplug B from day one. Agree on the topic namespace and payload standard before the first device connects, so you never have to untangle competing schemes later.
- Publish from the edge, not the PLC. Use edge gateways to read existing protocols like Modbus and publish them as MQTT, leaving control logic untouched.
- Design the namespace to match the plant. Mirror the ISA-95 hierarchy, enterprise, site, area, line, tag, so topics are self-describing.
- Set QoS and retained messages per topic. Choose delivery guarantees to match each signal's importance, and use retained messages so a new subscriber gets the last known value immediately.
- Secure it. Use TLS on port 8883 rather than plaintext on 1883, authenticate every client, and keep the broker off the open internet.
By the numbers
MQTT is an open standard maintained by OASIS; version 5.0 is the current specification, it defines three Quality of Service levels (0, 1, and 2), and it uses IANA-registered TCP port 1883 for plaintext and 8883 for TLS (OASIS MQTT v5.0 standard). Because plaintext MQTT exposes data to anyone on the network, industrial guidance stresses TLS, authentication, and network segmentation around brokers and legacy protocols (CISA: Industrial Control Systems). Where Harmony fits: Harmony is an AI-native operating system for manufacturing that connects machines, edge data, and business systems into one real-time operational layer, consuming plant data however it arrives, MQTT included, so a unified live picture becomes something you can act on, not just publish. See the broader stack in IIoT the control layer in SCADA or how CLS unified its floor.