Conversations about OPC Unified Architecture (OPC UA) and Message Queuing Telemetry Transport (MQTT) seem to be increasing more and more amongst engineers getting involved with Industrial Internet of Things (IIoT). The most common questions are: Which one is better, and are they mutually exclusive?
Frankly, this is like deciding whether text or email is better. Both can be used to send a message to one or more people, but we use them differently depending on the context; it is unlikely someone would send a marriage proposal via text! However, there are many cases when a text message is the better medium and more appropriate.
The same can be said for OPC UA and MQTT: It is not OPC UA versus MQTT, but rather OPC UA and MQTT.
OPC is great for process automation and control. It was developed in the 1990s to facilitate connectivity between programmable logic controllers (PLCs) and process control hardware and software using the Microsoft Windows operating system. The original OPC Data Access (OPC DA) standard was replaced with the OPC UA standard, which eliminated the reliance on Microsoft Object Linking and Embedding (OLE) and Distributed Component Object Model (DCOM) technology. This makes it possible to implement OPC on many platforms, including Linux.
The OPC UA standard is quite popular due to its many capabilities. It allows users to create data models such as industry, meta, and information models. These provide more than just process values, since they include a certification process to ensure connectivity with OPC applications. There is a security model which verifies the authenticity of servers and clients, as well as the integrity of the communication. Finally, alarm and event management are configurable for providing notifications to clients.
While the standard is great for process control—after all, this is what it was designed to do—it is not necessarily suitable for IIoT applications. The server/client architecture uses a poll/response method to get updates. This means that the server must contact every device to get an update, and the scan time across many devices may not be fast enough to capture critical updates.
Furthermore, these models may lead to a significant amount of information, creating a heavy payload, which may consume significant network resources. While security is an attractive feature, the OPC standard requires an inbound port which exposes the network; an open port is often a cybersecurity concern.
As presented in a previous blog article, MQTT was developed to provide a communication protocol that would be able to transmit data with a lightweight payload. This is due in part to leveraging the capabilities of the TCP transport layer. It also uses a publish/subscribe method, along with a report by exception trigger, which means that the device provides an update when there is a change.
There is a flexible namespace so that data can be published in several ways. Subscribers can use wildcards—like the pound sign (#) and plus sign (+)—to limit what data is received. Finally, MQTT is an outbound-only protocol, eliminating the need to open an inbound port, which is a common risk mitigation strategy.
While MQTT is great for what are now known as IIoT applications, it has had limited adoption in manufacturing automation. In the mid-2010s, an effort was made to evolve the MQTT standard for automation. This resulted in the Sparkplug standard which created a common payload, defined set of topics, and data compression. Like the OPC standard, it enables interoperability with any device or manufacturing automation application.
The difference between OPC and MQTT/SpB is how quickly data is available to use with MQTT. Once a device or application is configured and connected to a broker, all other systems are aware of its existence. The ability to, say, historize thousands of data points is done by simply connecting the devices and historian application to the same broker. The historian will then start logging the configured data structure. The same system can contextualize this data and publish it back to the broker.
As the MQTT/SpB standard becomes more prevalent, it is now being considered for simple control applications, like changing a state setpoint from an HMI. Having its roots in SCADA applications, it is certainly appropriate. That said, it does not have some of the feature-rich capabilities of OPC UA.
The role of the solution architect or control engineer is to determine the best way to solve a problem. There is no one-size-fits-all or “silver bullet” when it comes to any technology solution. In the end, the right way will be a combination of many technologies, including the likely use of both OPC UA and MQTT.