MQTT vs OPC UA myths and delusions
You can see a repetition of the same myths and delusions that have been circulating on the internet for quite a while now. Here are some of them:
1. “When you use OPC UA, it is always point-to-point connections.”
In fact, very often you will see OPC UA clients connecting to a gateway or aggregator like Kepware KEPServerEX or Prosys OPC Forge. Even in the “Decoupled Architecture” diagram presented by Kudzai, you can see an aggregator—Node-RED—being used.
2. “OPC UA is request-response based and synchronous, while MQTT is publish-subscribe and event-driven/asynchronous.”
In fact, OPC UA clients very rarely use the Read service call to get real-time data. Instead, they use the Subscriptions and Monitored Items mechanism, which in many cases delivers data once it changes—and often within a much shorter time than MQTT brokers would. Note that this is a separate mechanism from OPC UA Pub/Sub (e.g., over MQTT/UDP), which can be considered equivalent to standard MQTT.
3. “When you use MQTT as a transport, data is published only when it changes (Report by Exception / RbE).”
In fact, MQTT itself has nothing to do with RbE; it does nothing to prevent publishers from repeatedly sending identical messages. In contrast, RbE is a core, built-in requirement for OPC UA. Furthermore, OPC UA allows you to explicitly define what a “value change” means using the deadbands feature. In other words, you can configure the server to trigger a change event only when the value fluctuates beyond a specific absolute value or percentage.
4. “MQTT overhead is minimal, while the OPC UA binary protocol is heavier.”
In fact, the opposite is true. The OPC UA binary protocol is roughly three times lighter on the wire than vanilla MQTT.
5. “OPC UA might be good to use at the OT level, but when you move data to the cloud, MQTT is the only suitable option because OPC UA requires opening incoming ports into the OT network.”
In fact, OPC UA features a “reverse connection” capability. This allows clients located in the cloud to access data from OPC UA servers located inside the OT network using only outgoing connections from the OT network—exactly how it is done with MQTT. If your specific OPC UA server or client doesn’t natively support this feature, you can easily implement it using aggregating proxies like Prosys OPC Forge.
