A Modern Protocol: OPC UA vs MQTT

September 08, 2020

Story

A Modern Protocol: OPC UA vs MQTT

Consider the following challenges before implementing an OPC or OPC UA architecture. The most common complaint about OPC UA is how complicated it is to implement

I’ve been sharing my thoughts on IIoT protocols for years, but more recently I’ve gotten a little bolder about comparing OPC UA with the benefits of MQTT.  Full disclosure, I co-invented MQTT, an open standard, publish-subscribe network protocol, in 1999.  So sure, I’ve always been an MQTT evangelist, but there is a reason MQTT has become the dominant messaging standard in IoT.  Let’s take a quick look at these two protocols and where they fit in the IIoT landscape.

OPC UA was released in 2008 as an update to the original OPC interoperability standard for secure and reliable exchange of data in industrial automation. OPC is built on a client/server architecture. The OPC server converts the hardware communication protocol, then any program that needs to connect to the hardware becomes the OPC client software. 

Consider the following challenges before implementing an OPC or OPC UA architecture. The most common complaint about OPC UA is how complicated it is to implement.  The OPC UA spec is 1,240 pages. It is expensive when fully implemented and also heavy on CPU utilization, development costs and ongoing support costs. OPC is also inflexible, and has a hard time handling the varied data structures and heterogeneous devices found on the shop floor today.  It struggles with multiple data consumers and does not do the real data decoupling needed for a one-to-many approach.

A Deeper Look at MQTT

MQTT is a transport protocol I invented with IBM’s Andy Sanford Clark in 1999 as a lightweight, publish-subscribe network protocol that allows for multiple data consumers and is designed for constrained devices and low-bandwidth, high-latency or unreliable networks (Figure 1).  MQTT is based on a message-oriented middleware approach.

 

(Figure 1: The basic MQTT architecture allows for unlimited clients over a publish/subscribe protocol.)

The MQTT spec is simple and easy to implement.  The spec is 80 pages, and Sparkplug adds another 60.  It is lightweight and flexible because it reports by exception, or pub/sub model, minimizing the data footprint. MQTT is cost-effective, open-standard, and secure, with TCP/IP layer security. The number of vendors natively implementing MQTT-Sparkplug, both on the hardware and software side, is growing rapidly.  All of the leading cloud vendors, IoT platforms, edge computing platforms, big data and third-party applications support MQTT. 

Sparkplug is a new specification within the Eclipse Tahu project that defines how to use MQTT in a mission-critical, real-time environment.  Sparkplug defines a standard MQTT topic namespace, payload, and session state management for industrial applications while meeting the requirements of real-time SCADA implementations. The Sparkplug B specification provides the context data needs to define a tag value for use with OT, also providing data to IT, making it 100% self-discoverable and easy to consume. 

Utilizing MQTT with the open-standard Sparkplug allows OT data to be consumed with simple configurations on proven software tools that securely bridge the OT/IT gap and provide contextual information for the data scientists to use Big Data Analytics, ML, and AI to gain insight and increase productivity and profit. MQTT opens up these use cases in industries ranging from oil and gas to telemetry to process manufacturing.

OPC UA and MQTT Can Work Together

OPC UA and MQTT can actually work together harmoniously.  They may be polar opposites in the way they move data around, but there are still old devices that need an OPC server to share data and there is a way to use MQTT to overcome the challenges presented.  With a sensor connected to a legacy PLC, IoT platforms can connect and translate that data into MQTT, move it across any type of network in a pub/sub model, and then either send it to the cloud and enterprise apps, or some IoT platforms will translate it back into OPC for legacy OPC clients.

Many manufacturers have made a choice based on the existing architecture in their environment.  If they have a SCADA system, they tend to use OPC or OPC UA.  However, new manufacturers or those looking to digitally transform should consider MQTT/Sparkplug to solve modern challenges and adopt an IIoT solution that can handle any number of data producers and consumers across the enterprise with ease.

About the Author

Arlen Nipper brings over 42 years of experience in the SCADA industry to Cirrus Link as President and CTO.