MQTT is the messenger of the industrial internet of things. It moves data from sensors, gateways and PLCs to applications with very little overhead, over unreliable networks and at large scale. What MQTT does not do is describe what the data means. That is why the question “OPC UA vs MQTT” comes up in almost every IIoT architecture, and why the best answer is often: OPC UA and MQTT together.
- What it is: a lightweight, open publish-subscribe messaging protocol for IoT and IIoT
- Created: 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper
- Standards: OASIS standard (versions 3.1.1 and 5.0) and ISO/IEC 20922
- Core concepts: broker, topics, three Quality of Service levels, retained messages and last will
- In industry: often combined with OPC UA or Sparkplug B, which add structure and semantics
What is MQTT?
The MQTT protocol is an open, event-driven communication protocol based on publish-subscribe. A sensor, a gateway or a PLC (the publisher) sends messages to topics on a broker. Applications (subscribers) subscribe to the topics they care about, and the broker forwards matching messages. Publishers and subscribers do not need to know each other, which decouples the architecture: a new application can consume data without changing the device.
MQTT was created in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper to monitor oil pipelines over satellite links. It is now an OASIS standard, with versions 3.1.1 and 5.0, and an ISO/IEC standard (ISO/IEC 20922). The name originally came from MQ Telemetry Transport (sometimes wrongly expanded as Message Queuing Telemetry Transport), but today it is used as a name, not an acronym.
How MQTT works
- Broker: the central middleware that receives and distributes all messages. Clients connect via TCP, usually on port 1883, or on port 8883 with TLS encryption.
- Topics: hierarchical strings such as plant1/line2/press4/temperature that organize the data.
- Quality of Service: three levels, from “at most once” (QoS 0) to “exactly once” (QoS 2).
- Retained messages and last will: new subscribers get the last value immediately, and a client can define a message that the broker sends if the client disconnects unexpectedly.
The protocol is payload-agnostic: the message can be JSON, binary or anything else. This flexibility is a strength and a weakness. Without agreements on the payload, every application has to interpret every device’s data individually.
Sparkplug B: adding structure to MQTT
Sparkplug B, an Eclipse Foundation specification, addresses this gap for industrial use and is the basis of many unified namespace architectures, in which all sensor data and machine data of a company is organized in one topic structure. It defines a topic namespace, a binary payload format and state management through birth and death certificates, so that a SCADA system knows which devices are online and which metrics they provide. Sparkplug makes MQTT more interoperable, but it describes far less semantics than an OPC UA information model or an Asset Administration Shell.
OPC UA vs MQTT: the key differences
OPC UA vs MQTT is not a comparison of two equal tools. One is a full industrial automation standard with a data model, the other a lean transport. The table shows the ua vs mqtt differences at a glance:
| MQTT | OPC UA | |
|---|---|---|
| Communication model | Publish-subscribe via a broker | Client-server, plus PubSub |
| Data model | None, payload is free (Sparkplug adds basics) | Rich information model with types and semantics |
| Footprint | Very lightweight | Heavier, scalable from embedded to cloud |
| Security | TLS and broker authentication | Built-in certificates, signing and encryption |
| Typical use | Device-to-cloud, telemetry, event distribution | Machine and controller integration, shop floor to MES |
| Standard | OASIS, ISO/IEC 20922 | IEC 62541, OPC Foundation |
When should you use MQTT or OPC UA?
Use MQTT when many IoT devices and gateways send data to many consumers, when bandwidth is limited, or when data flows from the factory floor to cloud platforms, analytics and big data tools. Use OPC Unified Architecture (often written OPC-UA) when applications need to browse a machine, read historical data, understand its data model, call methods or communicate securely with PLCs and controllers. In most manufacturing facilities, both are present: the OPC UA protocol connects machines and SCADA systems on the shop floor, while MQTT distributes data to MES, ERP and the cloud, for use cases from predictive maintenance to energy reporting.
Can MQTT and OPC UA be used together?
Yes, and that is the common architecture today, because it lets companies unify shop floor and cloud data without giving up semantics. OPC UA PubSub can use MQTT as its transport: messages keep the OPC UA information model, while the MQTT broker handles distribution. Gateways also translate OPC UA servers into MQTT topics. The Open Industry 4.0 Alliance builds on this combination. OEC compliance requires a security-enabled data bus based on MQTT, with data exchange between applications based on MQTT and OPC UA PubSub. In the Product Change Notification demonstrator, an MQTT broker notifies subscribers when a supplier updates a submodel in an Asset Administration Shell, and the AAS-based onboarding project connects MQTT devices automatically.
Frequently asked questions
What does MQTT stand for?
MQTT originally stood for MQ Telemetry Transport, named after IBM’s MQ product line. Today the standard simply uses MQTT as its name.
OPC UA vs MQTT: which is better?
Neither is better in general. MQTT is lighter and ideal for distributing data at scale, OPC UA brings semantics, security and a full information model. Many architectures use OPC UA on the shop floor and MQTT for the transport to the cloud.
Is MQTT secure?
MQTT supports TLS encryption and authentication at the broker. Security depends on configuration, and brokers in industrial networks should never run without authentication.