Sparkplug 使用发布/订阅（Pub/Sub）架构模式，为可扩展且高效的通信提供了解决方案，这与过去40多年来工业自动化、离散制造业及石油和天然气行业中使用的传统轮询/响应协议截然不同。这意味着过去几十年的通信协议需要数据生产者（通常是 PLC）和数据消费者之间非常紧密的耦合。这种耦合使得改变工作流程和流程变得困难，使得建立新的系统和设施变得困难，并且使得在整个系统中使用和分析数据变得困难甚至不可能。
图1：轮询/响应方式
图 1 显示了从 PLC、网关和应用程序获取数据的传统轮询/响应方式。轮询系统向生成数据的设备请求数据，或者是特定数据的单一来源。为了尽快获取数据，轮询系统会以非常高的频率请求数据，否则新数据将无法及时提供给需要该数据的系统。这种方法效率非常低，因为它非常浪费带宽和处理能力。
在本次演示中，比较了 MQTT、OPC-UA 和 Modbus，并表明即使对于基本场景，使用 MQTT Sparkplug 与 OPC-UA 相比，效率也有数个数量级的提升。可以在此处找到演示文稿。如果您想通过加密通信来增加安全性（如果您通过互联网连接设备，则必须这样做），那么与 Sparkplug 相比，旧协议产生的开销甚至更大。
图 2 描述了系统需要对每个新的数据生产者进行轮询。这意味着在最坏的情况下，每个标签都需要单独轮询。
图2：众多制造者的轮询/响应
这种轮询方法在行业中广泛使用，特别是在Modbus和OPC-UA等协议中。数据产生的指数级增长以及工厂本地和全球范围内的超连接性显示了轮询/响应方法的局限性。如今，公司需要即时获取全球数百家工厂和数千台机器生成的数据，并希望所有利益相关者都能轻松访问重要数据，无论他们身在何处。行业现在终于迈向了一个必须打破数据孤岛的世界。
从技术角度来看，与现代发布/订阅方法相比，轮询/响应有一些严重的缺点：
- 无状态意识，大多数 IIoT 协议都无法感知状态，这意味着需要始终轮询状态，有时每个设备每秒轮询多次，以确保不会丢失重要数据或状态更改。
- 大量不必要的数据流量，即使没有发生状态更改或数据更改，数据生产者也会每秒被轮询多次。
- 仅定期检查新数据，没有基于即时推送的机制来获取发生的数据和事件。
- 轮询设备上的计算密集型，大量不必要的计算周期被浪费，因为即使数据没有改变，数据也会一直被请求。
- 轮询组件和轮询组件之间的紧密耦合。如果需要更改/更换数据生产者，则需要重新配置多个系统，可能会导致停机。
- 无法扩展到大量数据生产者。
显然有更好的方法。这就是为什么 MQTT Sparkplug 从一张白纸开始，并提出了这样的问题：“如果我们可以使用最轻量级的通信协议（MQTT），并结合过去 40 多年的经验教训，弥合 OT/IT 差距，实现即插即用的互操作性，那会怎样？”
为了克服传统协议的缺点，Sparkplug 使用基于现代发布-订阅的架构，如图 3 所示。
图3：发布/订阅架构
这种基于 MQTT 的架构具有以下优点：
- 异常报告：仅当发生变化时才发布数据和状态。
- 最小化计算密集度：设备和应用程序自行决定何时发送数据，并且不会不必要地浪费计算周期。
- 通过单个代理（集群）可扩展到数十万甚至数百万台设备，每天处理数十亿个标签数据和状态变化。
- 基于推送的通信。
- 完全解耦。要更改、添加或删除数据消费者或生产者，无需更改其他组件。
MQTT Sparkplug 在大多数行业中越来越受欢迎，可以用其相对于传统协议的明显优势来解释，甚至能够将这些传统协议集成到 Sparkplug 架构中。
回复