Industrial Architecture
MQTT vs OPC-UA for Shopfloor Monitoring: Which Protocol Should You Use?
Both MQTT and OPC-UA are widely used in industrial IoT, but they solve different problems. Choosing the wrong one for your machine connectivity layer creates latency gaps, data quality issues, and integration debt that grows with every new device.
What the question is really asking
MQTT and OPC-UA are not competing standards — they are complementary layers in an industrial communication stack. MQTT is a transport protocol: it moves data from point A to point B efficiently with low overhead. OPC-UA is a data model and information model standard: it defines what the data means, how it is structured, and how to query it semantically. The question is not 'which one' — it is 'at which layer of your architecture does each one belong'.
MQTT: what it is and when to use it
MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe protocol designed for constrained environments. A device publishes machine state, counters, or sensor readings to a topic on an MQTT broker. Subscribers — edge processors, cloud platforms, dashboards — receive that data in real time. MQTT is ideal for: high-frequency telemetry from many devices, unreliable or low-bandwidth networks (cellular, WiFi), and simple point-to-point streaming without complex handshake overhead. The main limitation: MQTT topics carry raw values without semantic context. '42' published to 'factory/line1/cnc01/temperature' is meaningless without external documentation. For machine fleets with consistent data structures, this is manageable. For heterogeneous environments, it creates integration complexity.
OPC-UA: what it is and when to use it
OPC-UA (OPC Unified Architecture) is an industrial communication standard from the OPC Foundation that defines both transport and information model. Unlike MQTT, OPC-UA carries semantic metadata: a temperature reading includes units, engineering range, timestamp, and data type as part of the standard schema. OPC-UA is ideal for: PLCs and CNCs with native OPC-UA servers (Siemens S7-1500, Fanuc CNC, etc.), environments requiring rich semantic interoperability with SCADA or MES systems, and regulated industries where data provenance and structured audit trails are required. The tradeoff: OPC-UA has higher protocol overhead and requires more capable devices — not suitable for simple sensors or microcontrollers.
SparkplugB: the practical bridge
SparkplugB is an MQTT extension specification from Cirrus Link that adds a standard payload schema on top of MQTT topics. It defines how device metadata, data types, and engineering units are encoded into MQTT messages — giving MQTT the semantic structure it otherwise lacks. SparkplugB is becoming the de facto standard for IIoT platforms that need MQTT efficiency with OPC-UA-style data consistency. Most modern industrial IIoT platforms — including Factobrain — support SparkplugB natively alongside raw MQTT and OPC-UA, letting you choose based on what each device natively supports.
Decision framework for your machine fleet
Use OPC-UA when: your PLCs or CNC controllers have a native OPC-UA server (most Siemens, Fanuc, and Mitsubishi machines manufactured after 2015 do), you need structured semantic data for SCADA or MES integration, or you are in a regulated environment requiring data provenance. Use MQTT or SparkplugB when: your devices are constrained (sensors, older PLCs without OPC-UA), your network is unreliable, you need lightweight high-frequency streaming, or you are building a new IIoT stack without legacy system constraints. In most industrial deployments, you will use both: OPC-UA from PLC to edge node, then MQTT or SparkplugB from edge node to cloud. The edge device translates between them, normalizing data into a consistent format regardless of the source protocol.
What this means for your IIoT platform selection
Evaluate any IIoT platform on protocol flexibility, not just claimed support. A platform that only handles MQTT will require you to add an OPC-UA broker for your CNC fleet. A platform that only handles OPC-UA will struggle with your sensor network. A platform with native support for MQTT, SparkplugB, Modbus, and OPC-UA — with edge normalization — means you connect any machine without custom middleware, regardless of vendor or vintage.
Turn this blueprint into action
Book a demo to convert this strategy into a practical pilot and scale plan.