谁是OPC UA与MQTT之争的最大输家？

那些头发花白、步伐缓慢的人（指阅历广泛的人）已经见过很多这种情况了：控制器之争，PC与PLC之争，DeviceNet与PROFIBUS之争等等。现在是OPC UA与MQTT之争。

我不知道谁会成为赢家，但我确定制造商将付出更多时间和金钱。事情总是这样。我所知道的是，制造业需要一致的、标准的机制来访问设备、描述数据及其元数据特征，并安全、可靠地传输数据。但我们现在没有这样的机制！

制造商面临着一个复杂的拼图游戏，使用的设备和应用程序的软件应用程序接口标准在很大程度上是不兼容且难以协同组装的。虽然所有东西大多都在以太网上，但没有什么能轻松地结合在一起。需要数据的人创建了次要的、平行的应用程序和系统——通常没有记录和支持——以解决现有问题。更多的时间浪费，更多无法使用和无法获得的信息，当然还有不断上升的成本。

OPC UA提供可扩展的平台、多种安全模型、多种传输层以及复杂的信息模型，使最小的专用控制器可以自由地与复杂的高端服务器应用程序交互。它与许多行业贸易团体的标准、行业特定数据模型集成。UA可以通信任何从简单状态到大量高度复杂的整个工厂信息的内容。

所有这些灵活性的代价是实现复杂性和复杂、冗长的规范。此外，它的开源支持并不好。

MQTT发布/订阅架构与我们在工厂生产线上使用的基础架构根本不同。数据和事件的生产者和消费者之间完全分离。MQTT易于理解和快速实现。新的Sparkplug增强标准标准化了内容、主题名称，并添加了状态管理。

但它也存在一些问题。MQTT数据缺乏上下文，并且使用Sparkplug时，你被迫使用不总是满足应用程序需求的API。其三个版本会导致一些混淆。而且没有发现支持，接收方无法查询 broker 以了解它保存的数据。

如果我们假设最终会进入一个所有东西都具有可下载数据模型的世界，那么OPC UA和MQTT都是可能的解决方案。OPC UA提供更先进的数据模型支持，但MQTT可以调整以提供类似的功能。

与我们多年来进行的所有其他自动化竞争一样，不会有明显的胜者。开发人员、集成商和系统架构师最终将学会在哪些方面使用OPC UA获得最佳成功，而在哪些方面使用MQTT获得最佳成功。两者都不会在所有应用程序中都优越，这对于制造商来说是一种损失，因为他们必须理解、支持并使用两种技术。