MQTT vs. OPC UA: Protocols From an OEM Perspective

In modern factories, machines produce data that reflects production counts, product test values, and machine efficiency. This data needs to be transferred from the machines to servers or even cloud systems to be used for KPI assessment and metrics.

The method we chose to use for transmitting data is often based on customer influence or application. Before we build our futuristic factory, we need to decide which protocol to use or whether to use a mix of both. Below, I’ll outline the pros and cons of each protocol from the perspective of a Controls Software Designer.

Figure 1. MQTT vs. OPC UA. Images used courtesy of MQTT and the OPC Foundation

First, A Little History

Message queuing telemetry transport, or MQTT, is a popular IoT messaging protocol that got its start sending data to satellites. The protocol was developed by Andy Stanford-Clark and Arlen Nipper to send sensor data from oil pipelines to control facilities through a network of satellites. The protocol had to be lightweight, use minimal power to transmit, and deal with intermittent connections.

Open Platform Communications or OPC is based on Microsoft’s Object Linking and Embedding, which allows devices to exchange information. The OPC Foundation used this model and applied it to industrial communications particular for automation. They created a communication protocol that is vendor-neutral. OPC UA is one of the latest additions to the OPC Foundation offerings and is platform-independent, includes security upgrades, and is scalable.

How Do They Work?

Both protocols transmit data from one system to another over a secure network. How this transfer occurs is very different between MQTT and OPC UA.

How Does MQTT Work?

MQTT works on a publish/subscribe (often shortened to pub/sub) model that uses relatively small amounts of data. Devices publish a payload of data to a topic, and clients can then subscribe to each topic. Data can be published to the topic as frequently as you like, and the data can be queued or overwritten. Subscribers can pull from the topic at regular intervals, or they can be notified when there is new data to retrieve. The topic resides in a broker, so both end devices must connect to the broker to have access to relevant topics.

This system works very well in situations where the connection between the machine and the broker is unreliable, or if a webpage is the client and a temperature sensor is the machine. The sensor will publish to the topic, and when someone loads the web page, their browser will be the client.

How Does OPC UA Work?

OPC UA is an open-source protocol that allows for direct connection to the internal variables of the machine. This direct connection allows the OPC UA system to browse variables and read values in real-time. The OPC UA architecture was developed specifically for automation, and many automation manufacturers are a part of the OPC Foundation. For this reason, most PLCs come equipped with OPC UA; however, a licence may be required for activation.

OPC UA is technically referred to as an architecture, being more complex than dedicated protocols like Ethernet or PROFINET. OPC UA can be configured for a client/server or a pub/sub network model. It also provides the ability to store data sets in files and folder structures, and it provides a host of security controls, since it’s designed for access outside of a local network.

Figure 2. A remote facility where communication is unreliable. Image used courtesy of Unsplash

Benefits of MQTT

When you are dealing with small payloads, MQTT is fast and reliable. It doesn’t take much programming to connect to a broker and start publishing or subscribing. Many frameworks and packages support the protocol, so the help is there when you need it. The downside is that popular control systems do not support the protocol natively. You will need to purchase a gateway or additional communication cards.

Figure 3. An AMR that uses OPC UA to communicate with a fleet manager. Image used courtesy of Unsplash

Benefits of OPC UA

Live data is sometimes required when collecting data on test results, batch parameters, or high-speed equipment. Live data can be rather large and should be moved from the control system to the database as quickly as possible. OPC UA provides that pathway. OPC UA is also natively supported with most out-of-the- box control systems. A license will likely need to be purchased before you can start transmitting data. You will also need a solid connection between the server and the control system.

Figure 4. A technician uses OPC UA sensor data to cloud systems. Image used courtesy of Wikipedia

Designing the Proper Communication System

When building automated equipment, the customer often drives decisions. Some factories already have communication technology stacks in place, and they will want you to use what has already been developed. If you get the chance to decide, you should evaluate your application. Ask yourself, how much data am I transmitting in a payload? Do I need real-time data? Do I need to push data to the cloud?

Personally, I prefer OPC UA. I get real-time access to the data I need, I can browse tags that are exposed to the server, and I can push data back to the control system without additional logic. If I have to push data to a cloud repository such as AWS, I would opt for MQTT. The MQTT protocol is already embedded into AWS services to make integration easier.

Whichever route you choose, lay out your data as best you can, and keep your data organized and as compact as possible. If you are pushing data to the cloud, remember that each transaction has a cost associated with it, so be mindful of what you are pushing. Both protocols move data around in slightly different methods.

Featured image used courtesy of Adobe Stock