What’s the Difference Between OPC UA and MQTT?

5 min read

Nowhere are the challenges of systems networking in an increasingly connected world more evident than the shop floor. Manufacturers and industrialists are facing more market pressure to adopt digital technologies than ever before. Not only do these solutions—which range from data analytics to robotics to the Industrial Internet of Things (IIoT)—require a new approach to IT networking, but we also need to find creative ways to integrate them with existing machinery and workflows.

That’s why industrial communication protocols have become such a key part of the conversation. Whether it’s for machine-to-machine (M2M) communication for real-time control (RTC), pushing data up from an IoT gateway to the cloud, or just displaying data on a human-machine interface (HMI) for an operator to monitor it, we all need to transfer data in ways that are scalable, reliable, and secure.

While there’s plenty of options to choose from, two of the most dominant ones are OPC UA (Open Platform Communications Unified Architecture) and MQTT (Message Queuing Telemetry Transport). Both of these protocols share certain similarities, such as built-in cybersecurity and their reliance on other networking technologies like TCP. Each bring their own advantages, and each is better suited for different use cases.

The question, then, is which one is better for your application. In this article, we’re going to give you a high-level overview of both OPC UA and MQTT, lay out the advantages of each, and provide some example use cases so that you can make a more informed decision when planning your next project.

OPC UA vs MQTT

As a descendant from OPC DA, OPC UA has a long history of industrial application. The main difference between the old version and the newer Unified Architecture is that it’s now compatible with any platform, not just the Windows OS.

The central concept that underpins OPC UA is the client/server architecture, a one-to-one topology where clients request data and servers respond with that data. Each client can interact with any number of servers, and likewise servers can serve however many clients. A single device can simultaneously function as both as client and a server. For instance, a programmable logic controller (PLC) can request data (client) from a sensor (server), process it, and then feed commands (server) to a robot (client).

OPC UA also recently added a Publish/Subscribe (PubSub) model to the OPC UA Specification Part 14 in February of 2018 , where publishers publish data on a topic and then subscribers can subscribe to that topic to receive the data. An example is a thermometer that publishes to a “temperature” topic and then various components of a boiler system that subscribe to that topic.

One of the main draws of OPC UA is that it’s much more feature-rich than MQTT. For instance, OPC UA's object orientation lets servers “model data, information, processes, and systems as objects and presents those objects to clients in ways that are useful to vastly different types of client applications.” Another unique feature is the ability to perform remote procedure calls (RPCs), which allow one machine to call a procedure, function, or method on another machine. This is useful for distributed systems; for instance, a PLC can send an RPC to a different, downstream PLC so that it can begin configuring equipment for the next type of product coming down the line without several handshakes between controllers. Basically, OPC UA enables us to run more sophisticated services over the network.

The final notch in OPC UA’s belt that we want to highlight is that it's capable of real-time control. We don’t need to linger too long about why that’s so important for industrial automation.

Now let’s move on to the competition: MQTT. This protocol uses a PubSub model that uses an MQTT broker as a middleman. Essentially, a publisher sends data to the broker, who then distributes it back out to subscribers who want the data from that topic.

The real advantage of MQTT is that it’s incredibly lightweight. Packets sent over MQTT are significantly smaller and require less overhead, making this protocol better for constrained networks with limited bandwidth. MQTT is also ideal for devices with less resources because it requires a smaller code footprint. These factors are the primary reasons why MQTT has seen such widespread adoption as the default for IoT devices.

Another reason is that it’s better for less reliable networks. MQTT includes useful features like quality of service (QoS) and last will and testament (LWT), which respectively define how much confirmation a device needs to receive that its message was received and what message a device sends if it “ungracefully disconnects” from the network for whatever reason. Combined with its lightweight form-factor, MQTT shines for tasks like remote asset management.

Example Use Cases

Major industrial vendors heavily use both of these protocols to expand their communication features. For instance, Siemens preconfigures their hardware for OPC UA for easier integration, and they maintain an MQTT library for IIoT development. Inductive Automation likewise utilizes OPC UA as the backbone of their Ignition platform, while simultaneously banking on MQTT for IIoT and remote communication.

The main use case of OPC UA is for closed loop process control on a local area network (LAN). If we need to get our machinery on the plant floor to talk to each other in real-time, OPC UA is the first place to look. A corollary is that this protocol is better suited for integrating with a supervisory control and data acquisition (SCADA) system. Not only does OPC UA have a proven track record for SCADA use cases, but it’s features and architecture are strong reasons to prefer it for SCADA.

Another good reason to use OPC UA is if we need to integrate legacy equipment. Industrial equipment tends to have a longer lifespan than most IT devices, and, as a industrial-first communication protocol, OPC UA is designed with this fact in mind.

Our final use case for OPC UA comes from research by Profanter et al. They found that, at least compared to MQTT, OPC UA functions much better for quick response time, which makes it very well suited for high speed motion and sensing applications. If your application requires serious compute power or you don’t have many cycles to spare, OPC UA is the way to go.

On the other hand, the primary use case for MQTT is IIoT applications. If you’re collecting data from remote locations and sending that data over an unreliable network like cellular, we recommend MQTT. Along these same lines, because of MQTT’s built in QOS feature a message can be guaranteed to be received by the end source because MQTT can keep attempting to post a message whereas in a base implementation of OPC UA, the message would be lost. A great example for using MQTT is for IoT gateways that collect sensor data and push it up to the cloud for data analysis and an overall view of a manufacturing line’s performance.

The Profanter research also found that MQTT functions better on heavily trafficked networks than OPC UA does. So, if you’re sending tons of data over the wire and pushing your network capacity to the maximum, MQTT will offer better performance.

Conclusion

At the end of the day, choosing between OPC UA and MQTT isn’t actually an either/or decision. Each protocol plays its role and excels at certain use cases. An optimal industrial network uses both; when combined, we can leverage the strengths of each and mitigate their downsides.

That’s why it’s so crucial to carefully architecture your systems and network from the beginning. By designing with these protocols in mind, you’ll experience greater productivity, more reliability, and less downtime. All it takes is the know-how to get the job done.

Outlier automation has that know-how. Get in touch with us today to learn more about how we can take your business to the next level of industrial automation.