Sponsored by PTC
Accelerating Manufacturing Digital Transformation

Data Standards and Modern Protocols: MQTT and OPC UA

PinIt

Data movement and sharing is critical for industrial digital transformation. Modern protocols like MQTT and OPC UA play a key role. How do they work, how they differ, and when do you use them?

As industrial operations become increasingly digitally transformed, sharing and moving data requires increased attention. The industry typically uses MQTT and OPC UA. The question is, when do you use one versus the other, and for which use cases?

RTInsights recently sat down with Sam Elsner, Director of Solutions Consulting for the Kepware business segment within PTC, to talk about how these modern protocols work, how they differ, and when do you use them.

This is a lightly edited version of our conversation.

RTInsights: What trends do you see – globally – that are driving the adoption of modern protocols like OPC UA and MQTT

Elsner: Over the past few years, analytics solutions, analytics engineering practices, and generative AI have made remarkable progress. These advancements have driven a substantial increase in demand for OT data, surpassing the demand seen during the big data movement of the past 15 years, which greatly influenced the need for industrial data, particularly using OPC and MQTT. These trends have been developing for quite some time.

There has been a focus on messaging interfaces, whether UA, MQTT, HTTP, Kafka, DDS, CoApp, and the list could go on and on and on. It stems from a clear understanding that a company’s latent and untapped sources of data yield potentially critical discoveries that could increase efficiencies, reduce costs, increase revenues, increase safety, reduce environmental impacts, and altogether transform an organization and yield a significant competitive advantage. In fact, it is a competitive threat not to have a digital transformation strategy to collect and then make sense of that latent or lesser utilized or cross-functional data created by an organization.

That has driven all sorts of interest in enabling technologies. A recent big one has been generative AI, but there is also interest in just more nuts and bolts technologies like data plumbing and data presentation technologies that allow the information to move between systems and be understood by both humans and machines. So, we find ourselves with both the need to collect a vast amount of process data as quickly as it’s created and to have a mechanism to help people and machines make sense of the data.

Said differently, to drive insights that lead to transformation, you have to solve the plumbing and presentation problem. And that problem is solved with the holistic, flexible messaging interface that can move data quickly and reliably and permits flexible data presentation.

See also: Accelerating Digital Transformation in Manufacturing with Enterprise Industrial Connectivity

RTInsights: What are the differences between OPC UA & MQTT?

Elsner: The differences are often misunderstood, and both the politics and the technology are very interesting for data plumbers like me.

Let’s start with OPC UA. It’s a complete protocol specification that defines a presentation of information that includes how individual details should be presented and related together, what data types should be assigned, how to create custom types, how that information is turned into a message, and how that message is moved across a network between systems. It’s an information modeling language and a wire protocol in one.

MQTT, on the other hand, is only a wire protocol; it only defines how information should be converted into a message and how that message moves across the network. The data or information itself is often plaintext JSON object notation, but it can literally be anything; there is no definition. It could be a video of a cat with a text extension, or it could be a set of bytes representing critical process data constructed and encoded using a portion of the UA specification. So, MQTT can move UA data, and there’s actually a UA specification that outlines how to move UA data over MQTT and what the UA data should look like when it’s placed within an MQTT message. It’s called OPC PubSub, and the MQTT implementation, in particular, is called out individually as “UA over MQTT.”

However, most of the time, when we talk to customers and the industry about this, we’re comparing plaintext JSON formatted messages over MQTT with binary OPC UA formatted messages over OPC UA Data Access services like Reads, Writes, and Data Publishing. We often call attention to the differences between publish-subscribe protocols and client-server protocols and how they work. The difference between publish and subscribe and client-server is often used to describe the differences between MQTT and UA simply because most of the UA implementations out there still today use client-server features like Data Access versus UA Pub/Sub features.

So, with that context, in publish-subscribe protocols, publishers are pre-configured with information sets that move to an external entity; oftentimes an intermediate message broker responsible for receiving and providing messages. And the folks who want the data, the subscribers, either receive the published information directly or talk to this message broker. In the case of message brokers, one benefit is that brokers allow publishers and subscribers to come and go; direct, active connections do not need to be maintained between systems that generate data and systems that consume it because there is an intermediary managing message exchange. This architecture can, therefore, help to facilitate more secure message exchange between critical and non-critical systems by preventing the need to directly connect with each other in order to pass messages.

UA and its client-server implementation, on the other hand, are peer-to-peer connections. So, a client, very often a manufacturing execution system or a SCADA supervisory control platform, forms a relationship directly with the server or data provider for the duration that the client needs the information or that they need to conduct that specific activity. Maybe it’s a control command or a process cycle command. The fact that the client forms the relationship with the server, that the client asks the server to begin talking with it, has implications on network topologies that can be supported, and then various security restrictions that must be allowed, like inbound ports in a firewall instead of just outbound. Within UA client/server implementations, there are options to initiate report-by-exception data publishing, but the client is still required to submit a request to initiate this and then continually query the server with a small message to maintain publishing.

Client-server protocols like UA are often used for control operations, though they’re very commonly used for data collection as well. You’ll see MQTT used for control operations to a much lesser degree, primarily due to a lack of out-of-the-box deterministic feedback between publisher and consumer. Basic MQTT is not interested in the context of the payload and its interpretation – not in “Was my message understood correctly?” but rather only “Did my message arrive successfully?”

RTInsights: When should someone use OPC UA vs. MQTT?

Elsner: MQTT and OPC UA overlap and have differences. This does drive differences in use cases, but in some, they are interchangeable. Note that this assumes you are not using UA over MQTT or OPC PubSub standard I mentioned earlier.

MQTT is often used for data collection, especially where it’s better to push a message out of a network or a system than allow another system to come in and pull the message out of that system or that server. MQTT is great for movement to cloud systems. When information needs to travel over the internet to a public or private entity, and it has to exit the company’s secure network, generally pushing a message out of that secure network is more secure than allowing a request originating from across the internet to come into your network and pull the information out.

We’re now seeing MQTT used to move data between on-premises systems as well, as well as lots of time series databases and message brokers. The on-premises MQTT brokers are often set up with specific data presentation and organization requirements in order to create an understandable information hierarchy for broad use across the organization. Folks often call these on-premises MQTT brokers Unified Namespaces, or “UNS.” And the MQTT protocol itself facilitates this idea of a clearinghouse for your company’s information really well because of its flexible, anything-goes payload formatting and its support for brokered, event-driven message exchange between producers and consumers. Message flexibility is especially desirable for analytics, AI, and digital twin use cases. UA’s modeling specification is extremely flexible, but there is a more significant learning curve than basic JSON object notation, and with the current maturity of model-based and model-aware systems, custom JSON is sometimes all that’s needed to meet requirements.

OPC UA, on the other hand, has typically been used to interlock process systems with SCADA or manufacturing execution or for data collection to on-premises, dedicated plant, or process historian applications. In SCADA and MES use cases, the software applications may need to be able to confidently, continually assume the health of the running state of the overall process and its equipment or make spontaneous requests to report the status of values directly from the automation equipment to have immediate, best-available knowledge of the process state. Or, they may need to write new values to the automation layer that control a process. Utilizing a protocol like OPC UA with statefulness and determinism avoids accommodating potentially long wait period where you must let a value change message that results from a control command propagate a purely event-driven collection path, or code around scenarios where a control command may not trigger a value change even if it is successful. The OPC specifications provide options for end-to-end state awareness of the health of the process and each command and response transacted, whereas MQTT only builds in message confirmation between broker and publisher and broker and subscriber, but not directly between publisher and subscriber; they are unaware of each other’s state without customization beyond base specification.

For data collection use cases, while it’s possible to overwhelm a small embedded UA server on an automation device or to create a lot of bandwidth requirements if you’re not careful, Subscription services use UA’s binary message format over TCP pretty quickly consumes less bandwidth than JSON over MQTT as message size is increased, say as the result of additional data points reported. UA binary bandwidth consumption is often less than MQTT JSON depending on factors like topic length, message format & size, etc.

My professional guidance on MQTT versus OPC UA is as follows: OPC UA is highly suitable for in-network factory management systems, SCADA, HMIs, Process Historians, and time series databases. These scenarios often involve large, high-throughput, high-volume historians, deterministic control, substantial data volumes, numerous tags, and high-frequency information being transmitted upwards. In such cases, client-server UA within the network has proven to be a sophisticated, effective, and relatively lightweight messaging standard.

MQTT, on the other hand, is great for pure data collection use cases, especially those where statefulness isn’t important. Data collection is where we see the most overlap with OPC UA. MQTT really shines in remote edge data reporting where configuration – the individual points collected – doesn’t need to change often, or in pure data collection use-cases where destinations are out of network like cloud, or for in-network use-cases where bandwidth is no issue and where it is beneficial to have flexible message formats. I’m also seeing MQTT used to publish small, compact binary payloads directly from automation devices like PLCs at fast frequencies; stuff typically reserved for proprietary device protocols or common low-level OT standards like Modbus. This could be generic MQTT and custom payloads or UADP binary payloads following the UA over MQTT spec. I think as the hardware resources available to automation devices grow and as folks become more intentional in their organization of data within the automation devices that produce it, I think the use of event-driven messaging with web-oriented standards like MQTT will become more and more common.

RTInsights: How does Kepware support the use of modern protocols?

Elsner: Kepware is committed to interoperability, providing our customers with seamless, secure industrial connectivity for many use cases, including analytics and AI. Our communications platform provides an OPC UA client, a UA server, an MQTT subscriber, and an MQTT publisher for data exchange across disparate systems. Our support for these protocols is well-established and proven across a broad swath of industries. We introduced OPC UA into Kepware products in 2009 and MQTT in 2015.

For more information about how Kepware industrial connectivity supports MQTT and OPC UA, I encourage you to visit www.ptc.com/kepware and contact us directly.

Salvatore Salamone

About Salvatore Salamone

Salvatore Salamone is a physicist by training who has been writing about science and information technology for more than 30 years. During that time, he has been a senior or executive editor at many industry-leading publications including High Technology, Network World, Byte Magazine, Data Communications, LAN Times, InternetWeek, Bio-IT World, and Lightwave, The Journal of Fiber Optics. He also is the author of three business technology books.

Leave a Reply

Your email address will not be published. Required fields are marked *