OPC-UA vs MQTT: Choosing a Protocol for Manufacturing IIoT
Introduction
A controls engineer walks into a plant meeting with two options on the table. One vendor wants to run everything over OPC-UA. Another insists MQTT is the future. The plant manager wants to know which one lets her see machine status on a phone without calling an integrator every time something changes.
Nobody in the room is wrong. They're just talking about different problems.
OPC-UA and MQTT are the two protocols that dominate industrial iot conversations right now. They solve overlapping problems in very different ways. Pick wrong and you're looking at six months of rework, a SCADA system that can't see your newer cells, or a cloud dashboard that floods your network every time an operator opens it.
This article walks through what each protocol actually does, where it shines, where it struggles, and how most serious iiot manufacturing deployments end up running both.
What OPC-UA Actually Is
OPC-UA stands for Open Platform Communications Unified Architecture. The name is a mouthful. The idea is straightforward: a standard way for industrial equipment from different vendors to describe itself and exchange data.
A Siemens PLC, an Allen-Bradley ControlLogix, a Fanuc CNC, and a Beckhoff motion controller all speak their own internal languages. OPC-UA gives them a common way to expose tags, method calls, alarms, and historical data to anything that asks. It was designed by automation people for automation problems, and it shows.
The protocol carries a full information model. When you connect to an OPC-UA server on a CNC, you don't just get a flat list of tag names. You get a tree of objects. The machine describes its axes, its spindle, its current program, its active alarms, with data types and units attached. A client that understands the model can walk it without needing a hand-written tag dictionary.
OPC-UA also carries security in the protocol itself. Certificate-based authentication, signed and encrypted sessions, user roles. This matters in a plant where the alternative has historically been "the PLC is on a flat network and whoever gets there first can write to it."
The downside is weight. OPC-UA over TCP is a session-based protocol. Every client opens a connection, authenticates, subscribes to tags, and maintains that session. On a small cell with a handful of clients, this is fine. On a connected factory with hundreds of machines and dozens of consumers (MES, historian, dashboard, quality system, a data lake, two different analytics tools), session counts explode. Server CPUs get hot. Subscriptions drop under load.
What MQTT Actually Is
MQTT started life as a pipeline telemetry protocol in 1999. It was built to move data over satellite links that were slow, expensive, and unreliable. That pedigree is why it fits iiot manufacturing so well today. The design assumption was never that the network would be good.
The model is publish-subscribe through a broker. A machine publishes data to a topic like plant1/line3/cnc4/spindle/load. Any number of clients subscribe to that topic. The broker handles fan-out. The machine publishing the data has no idea who is listening. The dashboard doesn't need to know where the machine is. They both just talk to the broker.
That decoupling is the whole point. You can add a new consumer (a predictive maintenance model, a new OEE dashboard, a data lake) without touching a single machine. You can swap out a PLC without reconfiguring every downstream system. In a reactive-maintenance shop where adding a sensor used to mean a week of integration work, this is a genuinely different world.
MQTT payloads are small. The protocol overhead is minimal. A broker on modest hardware can handle tens of thousands of messages per second. Quality-of-service levels let you decide whether a message needs to be delivered exactly once (important for a shift-start counter) or is fine to drop if the network hiccups (normal for a 1Hz temperature reading).
The catch is that MQTT is transport, not meaning. The broker moves messages. It does not know what the payload represents. Two integrators can publish spindle load to two different topics in two different JSON structures and neither one is wrong by the protocol. This is why Sparkplug B exists, which we'll get to.
Where OPC-UA Wins
OPC-UA is the right answer when the consumer needs to understand the machine's structure, not just scrape values.
A real example. A plant has a fleet of 14 CNCs from four different vendors. The maintenance team wants a single dashboard showing spindle hours, alarms with their full descriptions, active tool numbers, and the currently executing program. They also want the MES to be able to push a new program to any machine and confirm it loaded.
This is OPC-UA territory. Every modern CNC ships with an OPC-UA server. The information model for machine tools (the Umati companion spec) standardizes where the axes, the spindle, the program, and the alarms live in the tree. A client written against the companion spec can walk any compliant machine and find what it needs. No custom tag mapping per vendor. No translator layer.
OPC-UA also wins when you need strong session semantics. The MES tells the machine "start job 4471." It needs to know the machine received the command, accepted it, and is now executing it. That's a method call with a return value, and OPC-UA handles it natively. MQTT would need request-reply built on top, which people do, but it's bolted on.
Finally, OPC-UA is the right answer for regulated environments where auditors care about how every bit moves. FDA, aerospace, defense. The protocol's security model is documented, certified, and understood by the people who sign off on validation packages.
Where MQTT Wins
MQTT is the right answer when you have a lot of things publishing data, a lot of things consuming data, and you want the two sides to evolve independently.
Another real example. A mid-size manufacturer wants to get OEE on 60 machines, some new, some thirty years old. The old Fanuc controls don't have OPC-UA and never will. The team installs a small edge gateway on each cell that reads whatever signals it can get (relay contacts, M-codes, vibration, current draw) and publishes them to an MQTT broker using Sparkplug B.
Within a month, three different consumers are reading that data: a live dashboard, a shop floor analytics module, and a maintenance team's mobile alert system. None of them talked to each other during setup. None of them needed to know which gateway was on which machine. They all just subscribed to topics and got data.
That is MQTT's superpower. It is the protocol that makes a smart factory software stack actually possible to build incrementally. You don't have to know on day one which systems will consume the data. You don't have to rewrite a client when a new data source shows up. The broker is the contract.
MQTT also wins hard on unreliable networks. If the connection to the broker drops, the client buffers messages locally and ships them when the link comes back. For remote sites, mobile assets, or plants with flaky wireless, this isn't a nice-to-have.
Sparkplug B: The Missing Structure
Plain MQTT with arbitrary JSON on arbitrary topics works for a small project and becomes a nightmare at scale. Sparkplug B, maintained by the Eclipse Foundation, adds the structure that plain MQTT leaves out.
Sparkplug defines a topic namespace. It defines a payload format (compact binary, not JSON). It defines birth and death certificates so consumers know when a device comes online or goes away. It defines a metric model so a consumer can discover what a device is publishing without out-of-band documentation.
For iiot manufacturing at any real scale, if you're choosing MQTT, you're almost certainly choosing Sparkplug B on top of it. The raw protocol is too loose. The companion spec makes it enterprise-ready.
The Hybrid Architecture Most Plants End Up With
Here's the honest answer almost nobody leads with. Most serious connected factory deployments run both protocols. OPC-UA at the machine edge, MQTT across the plant and up to the cloud.
The pattern looks like this. A machine exposes its data through its native OPC-UA server. An edge gateway or translator reads from OPC-UA, transforms the data into Sparkplug B topics, and publishes to an MQTT broker. Consumers read from the broker. The MES, the historian, the dashboard, the analytics engine, none of them ever talk to a machine directly.
This decouples everything. If a vendor ships a firmware update that changes its OPC-UA model, you fix the gateway, not every consumer. If you add a new dashboard, it subscribes to the broker and works immediately. If a machine goes offline, Sparkplug sends a death certificate and every subscriber knows.
This is the architecture Deloitte and the World Economic Forum describe in their Lighthouse Network case studies. The WEF Global Lighthouse Network documents plants that took this approach and cut unplanned downtime sharply while adding new data consumers in weeks instead of quarters. It is not theoretical. It is the working pattern.
See WorkCell's IIoT platform for how this looks in practice with pre-built OPC-UA connectors and a managed Sparkplug broker.
Connecting Legacy PLCs
The hardest problem in any iiot manufacturing rollout is rarely the new equipment. New CNCs ship OPC-UA ready. The problem is the 1998 PLC running a press brake that still makes money every shift and is never getting replaced.
You have three realistic options.
Drop an OPC-UA wrapper in front of it. Products like Kepware, Ignition, and Matrikon sit between legacy PLCs (Modbus, Ethernet/IP, DF1, even serial) and expose an OPC-UA server to the rest of the plant. The legacy device stays exactly as it was. Everything upstream sees a modern protocol.
Publish directly to MQTT from an edge device. A small Linux box with the right drivers reads from the PLC over whatever native protocol it speaks and publishes to MQTT. This is cheaper per point than a full OPC-UA wrapper and fits well when you don't need bidirectional control, just telemetry.
Add external sensors. When the PLC is truly closed and nobody wants to touch it, strap a vibration sensor, a current clamp, or a cycle counter to the outside and publish from there. You lose access to the internal logic but you gain data that can drive OEE and shop floor visibility without modifying the original control system.
None of these are wrong. They're tradeoffs against cost, risk, and how much you actually need from the old machine.
A Practical Decision Framework
If you're standing at the whiteboard trying to pick, here's the short version.
Pick OPC-UA first when you need a rich, typed information model. Machine tools with companion specs. Systems that need bidirectional command and control. Environments where security certification matters. Small to mid-size deployments where session counts stay manageable.
Pick MQTT (with Sparkplug B) first when you have many publishers and many consumers that need to evolve independently. When network conditions are unreliable. When you're building a smart factory software stack on top of data you'll collect from heterogeneous sources. When you want to add new analytics consumers without touching the edge.
Plan for both when you're running a real plant. Use OPC-UA at the machine, MQTT across the facility, and let a gateway bridge them.
Conclusion
OPC-UA and MQTT are not competing religions. They solve different parts of the same problem. OPC-UA describes what a machine is. MQTT moves data between systems that don't need to know about each other. A serious industrial iot architecture uses both, each where it fits.
Pick based on the problem in front of you, not the vendor pitch. If you're connecting one new CNC to one new dashboard, OPC-UA end-to-end is fine. If you're trying to instrument an entire plant across three generations of equipment and feed ten downstream systems, you're running MQTT on the backbone whether you planned to or not.
The protocols are mature. The patterns are well understood. The part that still takes judgment is matching the right tool to the specific problem your plant is trying to solve.
Want to see this working on real equipment?
WorkCell ships with OPC-UA connectors for major CNC and PLC brands and a managed Sparkplug B broker out of the box. No middleware project. No six-month integration. Book a demo and we'll connect one of your machines live.