IIoT protocols: comparing OPC UA to MQTT

OPC UA and MQTT are like polar opposites in the way they move data around, and have different roles when it comes to digital transformation.

The internet expanded rapidly thanks to two technologies. First HTTP, a data exchange protocol, and then HTML, which was used to define the data sent by HTTP. Both technologies were needed, and the explosion of the internet was made possible, and interoperable, by the uniform adoption of these common standards.

Industrial IoT has not yet enjoyed this type of uniform adoption that leads to rapid growth at scale. There are several different architectures and protocols that can be used to gather data on the factory floor and deliver it to data consumers across the enterprise. Some common options are CoAP, DDS, HTTP, MQTT and OPC UA. For the purpose of this discussion we’ll compare two options on opposite ends of the spectrum — OPC UA and MQTT/Sparkplug.

OPC UA is the next-generation standard from the OPC Foundation, released in 2008 as an update to the original OPC interoperability standard for secure and reliable exchange of data in industrial automation. OPC classic was released in 1996 and was designed to abstract PLC-specific protocols into a standardised interface to allow SCADA systems to access the data. It is built on a client/server architecture, in which the OPC server converts the hardware communication protocol, then any program that needs to connect to the hardware utilises the OPC client software.

MQTT is a transport protocol invented 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. MQTT is based on a message-oriented middleware approach. Sparkplug is an open source software specification that provides MQTT clients with a framework to integrate data — defining a Topic Namespace, State Management and Payload to make the data interoperable for IIoT applications.

Today, many manufacturers or users of process control monitoring 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 organisation.

A deeper look at OPC UA

Back in the mid-90s, hardware vendors were developing PLCs and had to solve the challenge of sharing operational data with other software systems, but every vendor had their own proprietary communication protocols.

As a result, a number of companies worked with Microsoft to try to improve the situation in industrial automation. They became the original authors of OPC.

OPC was developed for Windows, and traditionally requires a dedicated Windows PC, and does a good job of exchanging OT data with legacy systems on a local area network. OPC uses a client/server architecture, ideal for connecting PLCs to SCADA and MES systems where OPC and OPC UA are already available. However, there was a call for scalability and a platform-independent architecture, which led to the development of OPC UA.

According to the OPC Foundation, “With the introduction of service-oriented architectures in manufacturing systems came new challenges in security and data modelling. The OPC Foundation developed the OPC UA specifications to address these needs and at the same time provided a feature-rich technology open-platform architecture that was futureproof, scalable and extensible.”

OPC UA aims to expand interoperability to the device and enterprise applications and recently added publish/subscribe to the original client/server communications infrastructure. The specification also attempts to remove the requirement for a dedicated Windows PC by permitting a server to be embedded into an edge product. The OPC Foundation open-sourced the OPC UA standard to increase adoption.

OPC has several limitations, and OPC UA tries to solve some of these problems but is extremely complicated to implement. The following issues should be considered before implementing an OPC or OPC UA architecture.

Complicated

The most common complaint about OPC UA, or OPC for that matter, is how complicated it is to implement. The original specification is over 1000 pages and OPC UA is 1250 pages. Many companies do not implement the full OPC Server, and even if they do it also requires routers, firewalls and VPNs. New devices must be configured and connected rather than auto-discovered. Because OPC UA is so complex, it does not often get completely or accurately implemented.

Heavy

When an OPC server talks to a client, since the subscriptions are not reported by exception but traditionally use a poll/response protocol (other than a very few modern OPC UA implementations), they are very heavyweight. A lot of devices that support OPC cannot handle a lot of subscriptions because they do not have enough storage. This limits the number of data consumers on the system. In addition, even though it is heavy, OPC data only comes with basic tags and values — no metadata or objects.

Inflexible

The shop floor is becoming increasingly varied — with both modern and legacy devices, different operating systems, network architectures and more. OPC has a hard time handling these varied data structures and heterogeneous devices. Classic OPC and OPC UA implementations usually include an OPC server that talks native protocols to the devices and then clients come and get the data. The focus is on OT data and the solution falls short for big data analytics applications, since it only collects OT data and not IT data.

Expensive

When OPC UA is fully implemented it is very expensive. The architecture requires embedding an OPC UA server into products, which increases the cost and time-to-market, the footprint size, CPU utilisation, development costs and ongoing support costs.

Lack of vendor support

OPC has been around for many years, but many IIoT technologies do not come with native support for OPC connectivity. Microsoft is the only cloud vendor that uses both OPC UA client-server connections as well as the new OPC UA publish/subscribe connections. Hardware vendor participation has been lacklustre and there are only a few OPC UA software clients available. Typically a shop floor does not have a lot of assets that natively support OPC UA, so they use an OPC UA server to serve the data up to OPC UA clients.

Struggles with multiple data consumers

OPC architectures struggle to supply all of the data to multiple data consumers. An OPC UA server does provide ‘one-to-some’ capabilities but does not do the real decoupling needed for ‘one-to-many’. In addition, most implementations don’t include meta-tag data, which once again means it falls short on getting data to IT functions in a usable format.

A traditional OPC system is shown in Figure 1, where SCADA owns the data path that was built for operations, or OT data. When new consumers request OT data, new application or custom code is written to get the data out of SCADA. As new data consumers are added, a brittle enterprise of applications is built that is costly to manage and becomes too complex to change. The organisation is trapped from moving to new technology without tremendous costs and operational disruption.

Figure 1: Traditional SCADA systems isolate OT data and can’t handle multiple data consumers. For a larger image click here.

A deeper look at MQTT

MQTT was invented to serve multiple data consumers and multiple data producers. In order for digital transformation to be successful, data must be decoupled and provided over an enterprise-wide solution architecture. MQTT allows for multiple data consumers (Figure 2). Companies can publish the data from a manufacturing asset and multiple applications can consume it, all at the same time.

Sparkplug defines a standard MQTT topic namespace, payload and session state management for industrial applications while meeting the requirements of real-time SCADA implementations. Sparkplug is an open standard that is licence-free to use and builds on 20 years of experience of how to use MQTT. 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.

Utilising MQTT with the open-standard Sparkplug data representation provides the tools for organisations to build a cost-effective solution for digital transformation across their enterprise. With minimal risk and cost, MQTT 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.

Figure 2: The basic MQTT architecture allows for unlimited clients over a publish/subscribe protocol. For a larger image click here.

The following points explain how MQTT solves the pain points not addressed by OPC UA.

Simple

The MQTT specification is 80 pages and Sparkplug adds another 60. Developers can follow the specification and implement it on their own, within a few days or weeks. MQTT is very easy to implement since devices can be added and auto-discovered.

Lightweight

MQTT reports by exception, minimising the data footprint and leading to more efficient communications. The protocol overhead is extremely small, the smallest packet has only 2 bytes of overhead. With Sparkplug, MQTT also includes the essential meta-data with no additional work required, and still keeps it lightweight.

Flexible

MQTT is based on a publish/subscribe model that decouples data publishers from consumers, which means subscribers do not need to know who provides the information to which they are subscribed. The message can be in any data format for the payload, such as JSON, XML, encrypted binary or Base64, which gives a lot of flexibility to the protocol.

Cost-effective

IIoT powered by MQTT provides a cost-effective solution for access to data on brownfield devices. MQTT can transport the data from a sensor, to a device (such as a PLC), to an edge gateway, and then up to the SCADA/MES system on the factory floor.

Secure

MQTT provides security in several ways starting with client usernames and passwords required to log in. MQTT uses the most current TCP/IP layer security available, which today is TLS. Next the connections are remote originated, so no ports are open in the field and only one port at the main firewall is connected to the broker. Access control lists (ACLs) only allow known remote devices to connect.

Vendor support

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 other third-party applications support MQTT. Progressive cloud providers are implementing Sparkplug to give auto-discovery data modelling.

Supports unlimited data consumers

Moving to a publish/subscribe model with MQTT enables the transition from a one-to-one to a one-to-many approach, encouraging innovations while making it easy to adopt new technologies. Data producers publish the data in Sparkplug B format to an MQTT server. The MQTT server enables those who have secure access to subscribe to the data. The OT application will subscribe to the data instead of polling for it.

OPC UA and MQTT can work together

It is important to note that 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 via the publish/subscribe 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.

OPC still has a place on a constrained, private network and for a point-to-point connection where multiple data consumers are not necessary. OPC still has a place for a user who is not interested in adding new technologies and new capabilities.

However, if a manufacturer has a choice of purchasing devices that support publish/subscribe with an MQTT-based IIoT platform or native support for MQTT/Sparkplug, an MQTT implementation requires less effort, less money and less time than OPC. Using MQTT allows users to embrace newer IoT technologies and software like big data, machine learning and more. Just as HTTP and HTML worked together to enable the rapid expansion of the internet, so do MQTT and Sparkplug, providing users with a modern option for interoperability of data on the shop floor.

Top image: iStock.com/simonkr