In earlier times, OPC learned a hard lesson that tying a specification to a specific wire protocol leads to obsolescence as technology evolves. This is why OPC UA has a layered architecture, which makes it possible to create mappings for any number of transports like JSON HTTP or UA TCP for Client/Server and MQTT or UA UDP for Pub/Sub. When OPC releases a specification, they try to provide mappings for what the market has initially indicated they want, only to find that sometimes the uptake may be diminished (e.g., AMQP). The power of OPC UA is that these mappings can be quickly modified to implement new mappings that better match market needs (e.g., MQTT). When a future technology emerges, a such as QUIC/HTTP3, OPC UA is ready.
The reason protocols can be added as needed is because the value of OPC UA comes from information interoperability, which exists no matter what protocol is used to communicate. OPC UA provides a standard framework for describing information that can be accessed by Client/Server or Pub/Sub. This enables a level of plug-and-play between applications from different vendors that cannot be achieved by simply standardizing the message format and topic tree. This is particularly true for cloud-based applications that need to integrate data from many sources.
This is why Erich Barnstedt, Chief Architect, Standards & Consortia, Azure IoT at Microsoft, shared that, “One of the questions I get quite a lot is ‘should I use OPC UA or MQTT to send industrial data to the cloud?’ My answer is always the same: ‘Use both! OPC UA for the payload and MQTT for the transport’.” Let me explain: “First of all, comparing the two technologies is an apples-to oranges comparison, as OPC UA is an application while MQTT is a protocol. It is like asking: ‘Should I use web pages or the Internet Protocol for my website?’ I think you get my point…” The emphasis on the need for information interoperability was also why the OPC Foundation and CESMII joined forces to create the OPC UA Cloud Library, which enables the publishing and discovery of standardized OPC UA Information Models as a component of the Smart Manufacturing Innovation Platform and Profiles. In their July 2021 press release, CESMII stated, “The key to new levels of innovation and performance will only be achieved when information, and associated context, can flow freely in the enterprise, to users and applications that need that information.” Delivering reusable information models is a strategic component of the Cloud Library.
The protocol independent architecture of OPC UA also allows for synergies between applications that would not necessarily have anything in common. For example, all of the major automation vendors are investing heavily in OPC Foundation’s Field Level Communication (FLC) initiative, which is based entirely on UA Pub/Sub using UDP. For these applications, MQTT simply cannot provide the capabilities that the controller-to-controller FLC applications require. On the other hand, the UA Pub/Sub infrastructure developed for FLC will enable connectivity to the cloud via UA Pub/Sub over MQTT because the overall architecture and configuration model is the same. This, in turn, will mean a lot of OPC UA commercial off-the-shelf (COTS) products will be available that can push data to the cloud via UA Pub/Sub over MQTT. In the long term this means a much greater selection of products will be available to factory owners that need to connect their factories to the cloud.
This emphasis on information interoperability and protocol adaptability makes OPC UA the best long-term solution for any factory owner looking to leverage MQTT and a means to connect their factories to the cloud.
Randy Armstrong