In the OPC UA vs. MQTT Battle, Manufacturers Lose

Those of us with more gray in our hair and a more leisurely gait have seen this before: controller wars, PCs vs. PLCs, DeviceNet vs. PROFIBUS to name a few. Now it’s OPC UA vs. MQTT.

I don’t know who the winner will be, but I’m sure manufacturers will bleed more time and money. They always do. What I do know is that the manufacturing floor needs consistent, standard mechanisms for accessing devices, describing data and its metadata characteristics, and moving that data securely and reliably. BUT THAT’S NOT WHAT WE HAVE!

Manufacturers face a complex jigsaw puzzle of software application interface standards used by devices and applications that are largely incompatible and difficult to cohesively assemble. Though everything is largely on Ethernet, nothing meshes together easily. People who need data create secondary, parallel applications and systems – often undocumented and unsupported – to work around what’s in place. More time lost, more unusable and unavailable information and, of course, rising costs.

OPC UA offers scalable platforms, multiple security models, multiple transport layers, and a sophisticated information model to allow the smallest dedicated controller to freely interact with complex, high-end server applications. It integrates with standard, industry-specific data models from many industry trade groups. UA can communicate anything from a simple status to massive amounts of highly complex plant-wide information.

The price for all its flexibility is implementation complexity and a complicated, long specification. In addition, its open source isn’t supported well.

The MQTT publish/subscribe architecture is fundamentally different than what we’ve ever used on the factory floor. There is complete decoupling between the producer and consumer of data and events. MQTT is easy to understand and fast to implement. The new Sparkplug enhancement standardizes the content, topic names, and adds state management.

But it’s also not without its warts. MQTT data is without context, and with Sparkplug, you’re forced to use an API that doesn’t always serve the needs of your application. Its three versions lead to some confusion. And without discovery support, receivers can’t interrogate the broker to know what data it’s holding.

If we assume that we are going to end up in a world where everything has a downloadable data model, then both OPC UA and MQTT are possible solutions. OPC UA offers more advanced data model support, though MQTT can be massaged to provide similar functionality.

Like all the other automation battles we’ve fought over the years, there isn’t going to be a clear winner. Developers, integrators and system architects will eventually come to learn where they have the best success with OPC UA and the best success with MQTT. Neither will be superior for all applications, and that is a loss for manufacturers who are going to have to understand, support and work with both technologies.

As always, RTA has the products to make that support simpler and faster.