The success of Digital Transformation strategies for manufacturing companies largely depends on their ability to connect to industrial data sources of all kinds and mobilise the data they create over the internet for purposes of integrating OT centric data with Enterprise/IT applications.

In that regard, there are two leading communication protocols that provide standardised message exchanges to provide the necessary interoperable connectivity between these two aforementioned domains that have traditionally remained isolated from each other. These are MQTT Sparkplug and OPC UA.

In this article, I’m going to describe the key differences between MQTT Sparkplug and OPC UA. But before we dive into the defining characteristics of these protocols, let us set the stage by briefly defining each communication technology.

What is MQTT Sparkplug?

MQTT Sparkplug is an open-source software specification that provides MQTT clients the framework to seamlessly integrate data from industrial sources within the MQTT infrastructure in a bi-directional and interoperable way. It achieves this by defining a consistent MQTT Topic Namespace, Payload Representation and Session State Management.

What is OPC UA?

OPC UA is a cross-platform, open-source data exchange standard for machine-to-machine industrial communication. It achieves interoperability by using a service-oriented architecture and defining generic device and information models that are independent of the manufacturer or system supplier.

Below are the key differences between MQTT Sparkplug and OPC UA

Scalability

MQTT Sparkplug’ s centrally brokered publish-subscribe communication model enables you to build a highly scalable IIoT solution, because even if thousands of components subscribe to consume an event it wouldn’t affect how that event is produced. Depending on the MQTT broker, a MQTT Sparkplug based IIoT system can scale up to tens of millions of connected devices and systems.

On the other hand, due to its request-response communication model, OPC UA only works well in small internal networks where the server has the capacity to respond to all clients’ demands. Because of that, your capacity to significantly scale an OPC UA based IIoT solution to include other business functions is severely limited.

Data Bandwidth Efficiency

MQTT Sparkplug’s report-by-exception rule ensures that data producers publish data only when they detect a change in the value of the monitored data point, meaning that MQTT Sparkplug clients only transmit changed data and a small keep alive packet to let the MQTT broker know that the client is still there. This saves bandwidth, memory, cpu time, power, and when combined with small payload size, results in a highly efficient protocol.

OPC UA’s request-response model requires that the client continuously poll the server even when there has been no change in process data. This consumes a lot of bandwidth, memory, cpu time, power, and when combined with the need to maintain a stateful connection, it results in an inefficient protocol.

Data Integrity

MQTT Sparkplug’s data modelling capabilities enables the creation of a single source of truth at the plant-floor for contextual model, asset, and tag data that can be consumed by hundreds or even thousands of both OT and IT applications through a single non-altering messaging medium, an MQTT broker. Allowing you to define and organise business processes around the data model.

OPC UA too has an OT centric modeling engine with many different data model definitions. Firstly, the variety of data models creates fragmentation within the standard itself, and also, because consumption of its data depends on direct connections of a limited number of client applications that in turn expose the data for consumption by other OT and IT applications, there is no guarantee that the integrity of the data will be maintained along the pipeline, hence business processes cannot be organised around it.

Ease of Integration

MQTT Sparkplug publish-subscribe architectural model enables the connection of devices and applications through a Unified Namespace such that they never have to contact each other directly, which results in loosely coupled IIoT systems that make integrating (new) components easier.

OPC UA’s request-response architectural model requires that devices be directly connected to applications which means that applications become dependent on a particular device they control, resulting in a tightly coupled IIoT system that makes it difficult to integrate new components.

Auto Discovery

MQTT Sparkplug components can automatically discover what data will get sent by all the network participants that are connected.

OPC UA clients need to be pre-configured with information such as node address or OPC Ua device type.

Session State Awareness

MQTT Sparkplug has inbuilt Session State Management capabilities through Birth and Death certificates in conjunction with the MQTT connection “Keep Alive” timer that enables it to provide real-time visibility of all system components.

Meanwhile OPC UA relies on the expensive, and sometimes not feasible, continuous polling to maintain a notion of the State of the connection between IIoT components.

Responsiveness

Because MQTT Sparkplug uses an Event Based Architecture and report-by-exception, it allows for the quickest and most real-time adjustments of anomalies or events such as alarms whenever they arise, which results in a highly responsive IIoT system. Meanwhile, with OPC UA you’d have to tune the polling frequency to get close to real-time reporting of events

Communication Directionality

MQTT Sparkplug allows bi-directional communication that can be initiated by any component in an IIoT system, while in OPC UA the server only responds to requests made by the client.

Security and Privacy

MQTT Sparkplug defines no security protocol, it lets you handle security at the TCP/IP level. Meaning that your IT department can pick a security model such as TLS/SSL, Certificates e.t.c and MQTT will run on top of it. Because MQTT Sparkplug clients initiate communication with the server using outbound communication ports, it means that there is no need to open any inbound communication ports that may increase the attack surface on your IT infrastructure.

On the other hand, OPC UA does define a security protocol. But due to the fact that communication with an OPC UA server is initiated from an external platform such as the cloud, it means that your IT infrastructure needs to open ports for inbound traffic, which will expose it to actors with malicious intentions. However, they both have application layer security mechanisms such as username and password and security tokens.

Cloud Connectivity

MQTT Sparkplug makes it easy to integrate cloud based functionalities with your plant-floor systems by simply plugging the cloud-applications to an MQTT Broker that is hosted in the cloud. Moreover, in mission-critical applications that may only need cloud connectivity occasionally, an MQTT broker can be hosted on-prem for low latency data exchange while timeously connected to the cloud-based MQTT Broker through a bridge.

On the other hand, to integrate OPC UA systems which cloud-based applications requires multiple components to perform discovery and data aggregation both at the edge and in the cloud. And while OPC UA recently introduced PubSub specification for cloud connectivity over protocols such as MQTT, its implementations are rare due to its immaturity, and it does not yet define how to map OPC UA’s rich information model to MQTT.

Complexity of Specification

MQTT Sparkplug specification consists of 68 pages with straightforward information which makes it simple to implement on devices and applications.

OPC UA specification consists of multiple parts (Over 14) with hundreds of pages each (>1200 pages in total), which makes it a complex standard to implement on devices and applications.

Summary: OPC UA Vs. MQTT Sparkplug

Conclusion

In conclusion, while this article covers a wide spectrum of characteristics to highlight the key differences between MQTT Sparkplug and OPC UA, the importance of each characteristic to a manufacturing enterprise varies from use-case to use-case. So, to ascertain their importance, it would make sense to group these characteristics into the main manufacturing business KPIs Cost, Risk and Revenue.

Scalability, Data Bandwidth Efficiency, Ease of Integration and Complexity of specification lead to Reduced Costs. Data Integrity, Security and Privacy lead to Reduced Business Risks. And lastly, Responsiveness, Auto Discovery, Session State Awareness, Cloud Connectivity, and Communication Directionality leads to Revenue Loss Avoidance through increased operational efficiency.

Learn more about OPC UA and MQTT Sparkplug:

IIoT-Protocols - A Comparison of OPC UA & MQTT Sparkplug

Read

About Kudzai Manditereza

Kudzai is an experienced Technology Communicator and Electronic Engineer based in Germany. As a Developer Advocate at HiveMQ, his goals include creating compelling content to help developers and architects adopt MQTT and HiveMQ for their IIoT projects. In addition to his primary job functions, Kudzai runs a popular YouTube channel and Podcast where he teaches and talks about IIoT and Smart Manufacturing technologies. He has since been recognized as one of the Top 100 global influential personas talking about Industry 4.0 online.

Follow Kudzai on LinkedIn

Contact Kudzai