In the field of industrial automation, two technologies stand out due to their widespread use and specific capabilities: OPC Unified Architecture (OPC UA) and Message Queuing Telemetry Transport (MQTT). Both protocols play a crucial role in the networking of OT devices and IT applications. However, OPC UA and MQTT serve different requirements and use-cases based on their specific properties. The following article therefore highlights the main differences between OPC UA and MQTT with regard to these properties.
OPC UA Fundamentals
OPC UA (Open Platform Communications Unified Architecture) is a communication standard developed by the OPC Foundation. This standard was designed for secure, reliable and platform-independent data exchange in industrial automation systems. OPC UA supports complex data types and object models. This capability makes it possible to support complex industrial processes. Detailed information on OPC UA can be found here.
The OPC UA key functions are:
- Information modeling: Supports extensive information modeling including structured data types, object-oriented models and complex data structures.
- Integrated security mechanisms: Provides built-in security features, including authentication, authorization, encryption and data integrity.
- Platform-independent communication: OPC UA supports both client-server and publish-subscribe communication models and can be used on embedded devices as well as in large server infrastructures.
MQTT Fundamentals
MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol that was originally developed for networks with low bandwidth and high latency. This is particularly relevant in IoT scenarios (e.g. integration of external sensors). Developed by IBM, MQTT is based on a publish/subscribe model. This makes the standard very scalable and efficient in the distribution of information to a large number of subscribers. You can find more information here.
The MQTT key functions are:
- Efficiency: Lightweight protocol with minimal data transmission, ideal for use-cases with restrictions in the network or on the IoT devices.
- Decoupling: The publisher and subscriber model enables decoupling between devices and applications.
- Scalability: Easily scales to support thousands to millions of devices and subscribers.
OPC UA vs. MQTT
OPC UA and MQTT are designed for different industrial application areas and are therefore not directly comparable. These differences are reflected in the following important properties of the two standards.
1. Integration Effort: OPC UA vs. MQTT
With over 1200 pages, OPC UA has a very extensive specification that covers a wide range of functions in industrial automation. MQTT, on the other hand, focuses on a small number of core specifications (approx. 80 pages) that are geared towards efficiency and simplicity in IoT scenarios. The differences in the number and type of specifications reflect the different design goals and fields of application. The difference in scope is also reflected in the integration effort of the two standards.
OPC UA: The OPC UA specifications are divided into several parts that cover different aspects of the OPC architecture. This division shows that OPC UA is not just a simple data transfer protocol, but a comprehensive framework for communication in industrial systems. This includes security, data modeling, state management and historical data access. A large part of this is optional. This means that it is up to the user to decide which part of the specification is implemented and which is not. Due to the breadth of the standard, which has evolved over decades, implementation is complex and time-consuming in practice. This is one of the reasons why most systems only use a small part of the standard.
MQTT: In contrast to OPC UA, MQTT is a simple and lightweight protocol. It essentially consists of two documents with approx. 80 pages (MQTT 3 and the newer version of the standard MQTT 5), which mainly focus on the core elements of the protocol. Due to this fact, the integration is much simpler and usually requires significantly fewer resources.
2. Communication Model: OPC UA vs. MQTT
In terms of communication models, OPC UA and MQTT differ fundamentally in their architecture, which has a significant impact on their application and performance in industrial environments.
OPC UA Client/Server uses a client-server model at its core. In this “one-to-one” topology, a client requests data from a server and the server responds with the requested data (poll response). While clients can interact with many servers simultaneously, servers can serve many clients. The client/server architecture is particularly suitable in automation scenarios in which direct synchronous communication (e.g. for closed loop, command & control) between a small number of systems is required.
MQTT minimizes bandwidth usage by moving from a conventional “poll-response” behavior (such as the OPC UA client-server architecture) to an event-based “publish-subscribe” behavior. In this model, communication is decoupled by a broker that mediates messages asynchronously between the participants. Event-based means that a data consumer waits for data changes (instead of requesting them cyclically), which enables event-driven communication between devices and applications. Due to these characteristics, the pub/sub architecture is particularly suitable in scaling scenarios with dozens to millions of data producers and subscribers.
OPC UA Publisher/Subscriber (Pub/Sub), part 14 of the specification, was first published in 2017 as an addition to the original client/server-based communication model. Pub/Sub specifically addresses the limitation in the scalability of client/server models and was developed to address the growing need for efficient and lightweight communication mechanisms for IoT applications. However, it is important to note that OPC UA Pub/Sub is based on standard Pub/Sub protocols such as MQTT or AMQP.
3. Security: OPC UA vs. MQTT
While MQTT offers users flexibility in security implementation, OPC UA has integrated security mechanisms that cover a wide range of security aspects. Both approaches offer advantages, but require the user to have the relevant expertise.
MQTT does not define its own security protocols. Instead, MQTT leaves the implementation of security to the TCP/IP level. This means that the user can choose between suitable security models such as TLS/SSL or certificates. In addition, the MQTT standard does not offer any specific measures for user and application security, which is often compensated for by additional security implementations at application level. While the possibility of using recognized standards such as TLS/SSL makes the implementation of a secure MQTT architecture easier in principle, additional effort is still required at application level.
OPC UA, on the other hand, offers an integrated security solution that includes user, application and transport security. This OPC UA security architecture supports authentication, authorization, encryption and data integrity. This can make the protocol a robust choice for industrial automation systems. However, only if implemented and configured correctly. And this is where the problem often lies in practice. Due to the scope and complexity of OPC UA, weak security implementations are often found in practice.
4. Interoperability: OPC UA vs. MQTT
Interoperability is a popular buzzword. And unfortunately, the term is often not understood by those who promote interoperability. In fact, neither OPC UA nor MQTT in themselves guarantee true interoperability in practice. To illustrate this challenge, we draw on Matthew Parris’ “Data Access Model” (source), which defines the key levels of interaction between data sources and consumers in an industrial environment. 
The following applies:
- Undefined levels favor flexibility at the expense of higher integration effort, as each implementation must be interpreted and integrated individually.
- Multiple options on one level favor flexibility at the expense of higher integration effort, as different implementations have to be integrated individually.
Level 0 – Transport
This level defines the basic transport mechanisms required for data transfer between systems. While MQTT uses TCP/IP or websockets for easy and efficient data transfer, OPC UA enables additional transport options. The choice of transport mechanism is left to the user depending on their needs and technical requirements.
Level 1 – Protocol
This level concerns the specific implementation and application of the communication protocol itself. MQTT relies on a simple publish/subscribe model that offers high flexibility and scalability, but specifies little in terms of security features and error handling. OPC UA, on the other hand, defines a more complex protocol that includes not only publish/subscribe, but also session management, authentication and encrypted communication.
Level 2 – Mappings
This level defines the specific protocol mappings. These determine how data is structured and transmitted within the selected communication protocol. While MQTT leaves this up to the user (e.g. conventions for topic namespaces), the OPC UA specification contains detailed information models that precisely define the structure of the data.
Level 3 – Encoding
This level defines the encoding of the data required for transmission over the network. This includes the choice of data format, which defines both the efficiency of the transmission and the compatibility between different systems. While MQTT leaves the encoding of the data to the user, OPC UA specifies encodings such as binary, XML and JSON. The choice of suitable encoding is left to the user depending on their needs and technical requirements.
Level 4 – Values
This level defines the data types for data transfer. A clear specification of data types is essential for the correct interpretation and use of the data by different systems. While MQTT leaves this to the user, OPC UA specifies 60 so-called “base types” and allows the user to add individual complex types.
Level 5 – Objects
This level defines data models and schemas, i.e. how data is organized as objects, including their attributes and methods. This is particularly relevant for the application logic. While MQTT leaves this to the user, OPC UA specifies these models for the user via so-called companion specifications.
To summarize: MQTT is not equal to MQTT , OPC UA is not equal to OPC UA
MQTT: As the standard does not specify essential levels, the implementation is left to the user. This may seem much more flexible and simpler at first, but it leads to individual implementations. Two MQTT-capable systems must therefore be integrated individually at these levels. The new “Sparkplug B” standard provides a remedy here. You can find more information here.
OPC UA: The standard was originally developed for cross-platform compatibility in order to facilitate communication across different hardware systems. However, due to the high number of optional and alternative specifications and the increased complexity, different parts and versions of the standard are typically implemented. Two OPC UA-capable systems are therefore only truly interoperable with a great deal of luck.
5. Scalability: OPC UA vs. MQTT
Scalability is a crucial aspect when choosing the right communication protocol. This is particularly true in environments in which the number of networked devices is constantly increasing.
OPC UA: The scalability of OPC UA can be challenging in large industrial environments. This is especially true when a large number of devices and systems are connected for data exchange. In addition to the traditional client/server structure of OPC UA, the complexity of the standard and its implementation significantly limits scaling. To improve scalability, OPC UA also supports a publish/subscribe model (pub/sub). This was introduced in the more recent Part 14 specification. Brokers such as AMQP or MQTT are used here, which guarantee the efficient distribution of messages to many subscribers.
MQTT: MQTT, on the other hand, was designed with ease and efficiency in mind. It is ideal for scenarios where thousands to millions of devices need to be supported efficiently. MQTT’s publish/subscribe model minimizes network traffic and significantly reduces the resource load. In addition, its simplicity and efficiency make MQTT particularly suitable in scaling scenarios. However, due to the lack of depth of the standard (see interoperability layer), users must fill the existing gaps themselves during scaling. This includes the use of other standards (e.g. Sparkplug B) or the definition of their own standards.
Conclusion
Both OPC UA and MQTT play a crucial role in the ecosystem of industrial automation and OT/IT convergence. However, neither OPC UA nor MQTT lead to interoperable system architectures in practice today. While the deliberate lack of depth of the MQTT specification is not designed for this, the complexity and scope of the specification leads to interoperability problems with OPC UA in practice.
The choice between OPC UA and MQTT largely depends on the specific requirements of the application in question. For complex industrial applications that require detailed data modeling and robust security, OPC UA is the preferred protocol. In contrast, MQTT offers an optimal solution for lightweight, efficient data transfer in environments with tens to millions of data producers and subscribers. Due to these specific strengths, the two technologies are increasingly being used in combination as part of the Industrial Unified Namespace Architecture (UNS) to ensure efficient and reliable data communication between OT and IT.
