How OPC UA and MQTT Prevent Interoperability

Note from the Author: The content below was originally published in an article titled "How protocols fail at data access interoperability," found in the Industrial Ethernet Book November 2022 Issue. The article has been abridged and republished here as the industrial data access market continues to struggle with interoperability.

One of the many goals of Industry 4.0 is to eliminate the integration cost when incorporating new data producers or consumers within the enterprise. Simplifying integration is achieved primarily through products implementing a handful of well-known standards. For example, OEMs solving the interoperability problem may advertise products supporting “OPC UA” or MQTT.” Similarly, end users attempting to improve their efficiencies may specify industrial equipment to comply with “MQTT” or “OPC UA.” Are these two terms, however, enough to achieve interoperability?

Much of the confusion of interoperability for these two technologies stems from the popularity of the TCP Model. While powering worldwide connectivity, the TCP Model does not detail communication protocols or information encodings required for data consumers and producers. Industrial Internet of Things (IIoT) initiatives are not concerned with the physical network connections, how the LANs are segmented, which routes must be taken, or how to maintain reliable connectivity; all these capabilities are assumed to exist already. The discussions regarding IIoT architectures primarily target the only layer not standardized by the TCP Model: its Application Layer.

The Data Access Model, in contrast to the TCP Model, compresses network infrastructure into a single Transport Layer and expands the application layer into six layers. Communication layers sit above the Transport Layer and handle how data from TCP/UDP moves between producers and consumers. Information layers specify the information formats of the data flowing. Finally, the Application layer is on top, which is the business justification for embarking on the IIoT journey in the first place. Interoperability between two systems is determined by the number of compatible layers within the Data Access Model.

MQTT has become a popular protocol for systems implementing “provide data once; distribute everywhere” architectures. Defined in 1999 towards the tail-end of the protocol wars, MQTT defined a lightweight alternative to traditional client-server connectivity for distributed oil wells constrained by expensive satellite bandwidth. MQTT reduces bandwidth by moving from a conventional poll-response behavior to an event-based behavior where a consumer waits for changed data. In addition, defining devices and equipment with MQTT has reduced the cost of integration since the consumer application can have a single connection regardless of the number of producers and, through wildcard subscriptions, can automatically discover new data as it appears. While invented as an Industrial Protocol, it remained largely unknown until around 2011, when IT-based companies began learning its inherent scalability and deployed the technology within popular, consumer-facing applications. Ironically, the protocol’s popularity within the IT space is what convinced OT organizations to begin deploying its own protocol within the plant floor.

The OPC Foundation released its first OPC UA specification in 2006, which featured Data Access among many other connectivity functions. Products began implementing OPC UA to transform existing connections with benefits such as enabling non-Windows devices, browsable address spaces with standard datatype definitions, and long-polling mechanisms with dead-band filter criteria. OPC UA became popular among manufacturers because it upgraded existing client-server paradigms established from the original 1996 OPC specification. As publish-subscribe protocols increased in popularity, PubSub connectivity was added to the specification in 2018, including broker-less protocols (Ethernet and UDP) and brokered protocols (AMQP and MQTT). Continuing its goal of interoperability, the OPC Foundation defined standard object types through companion specifications, each of which utilizes the core data definitions to construct standard object definitions.

Regarding interoperability, the terms “OPC UA” and “MQTT” are undefined and originate from opposite sides of the same coin.

As seen in the figure above, specifying MQTT for equipment defines the base communication protocol, but leaves all the remaining data access stack undefined. Lack of definition levies a heavy burden for engineers tasked to integrate consumer applications. Integration hurdles include learning topic paths implemented by the producer and determining whether an application can monitor the producer’s health through the Last Will Testament function. Also, engineers must determine which QoS level is being used, and whether producers are publishing on fixed time intervals or only on changed data. Even more daunting to engineers is that MQTT has no definition of the transmitted data, so engineers are forced to accept whatever decisions the software developers of the data producer selected, such as the encoding scheme, data types, and object definitions. If the goal is interoperability, specifying “MQTT” is not enough.

Whereas “MQTT” is undefined above the Communication Protocol layer in the Data Access Model, OPC UA has achieved standardization at every level of the Data Access Model. While definitions at each layer are an achievement matched by no other technology, the portfolio of specifications includes many customizations at each level of the model. Given the plethora of communication protocols, encoding schemes, data types, and object definitions, simply connecting an OPC UA consumer to an OPC UA producer does not guarantee interoperability. Even going so far as to specify "OPC UA PubSub MQTT" between systems still does not guarantee interoperability. With OPC UA, an engineer must closely evaluate all the standardized layers for all the customizations implemented at each layer by the producer device and ensure it matches the capabilities of the consumer application. Or conversely, the integrator knows the consumer application capabilities and is forced to limit what OPC UA products he can utilize. If the goal is interoperability, specifying “OPC UA” is not enough.

Those striving for interoperability should ignore statements made by Standards Bodies, OEMs, System Integrators, and End Users when only using the terms "OPC UA" or "MQTT".

Unfortunately, the current state of the data access market is reminiscent of the days of the protocol wars from forty years ago. The TCP Model coalesced the market around a streamlined definition, enabling an ecosystem of switches, routers, and firewalls from different vendors to build the worldwide internet. The industrial data access market desperately needs a similar streamlined definition within the Data Access Model. Until a simple data access stack is defined for the market, OEMs will continue to produce customized solutions, and end users will continue to expend energy learning various competing technologies and comparing the benefits of each.