MQTT Sparkplug B：探索工业协议的将来
背景在学习有关Unified Namespace(同肯定名空间）的知识以及其在工业4.0情况下的须要性期间，我遇到了很多问题。其中就是有关工业4.0中的首选协议，有资料说是OPC UA，但Walker Reynolds不断推崇MQTT。基于我对工业协议只有入门程度的了解的程度，很难做出判断。
于是我做了一些调查，在这里分享我对这个问题的初步明白以及一些感想。我习惯用First Principle Thinking（第一性原理）的方式来明白问题，有些部分对于很熟练的人来说会有点啰嗦。
工业协议的需求
本日有很多企业要数字化转型
数字化的基础是数据，数据须要被收罗，转换，使用。
https://i-blog.csdnimg.cn/direct/da6e193cbc5f43cea6b463e016d66833.png
在制造业中，存在大量设备，包罗传感器、MES、SCADA，以及来自差异供应商的各种设备和软件，这些设备和软件往往被用于完成差异的任务，同时也在为企业的数字化和高层决策提供数据支持。
如果仅有少量部件须要集成，问题还不算严重；但当涉及到上百个设备时，集成和维护的难度就会大大增加。
各种设备和系统之间的集成形成了spaghetti integration（意大利面条集成）的问题出现
而造成这一问题的根本原因在于：除非全部设备供应商都同意遵循同一的工业通信和集成规范，否则设备之间的互联互通始终无法完全实现。
https://i-blog.csdnimg.cn/direct/32349221736c44c9b4c497b647c6b59d.png
为了要办理意大利面条集成的问题，开发了一些常见规范如OPC UA, MTConnect等。
问题是OPC UA是复杂的协议规范，对很多用户和开发者都不是很友好。并且不是全部设备都能与OPC UA集成。
传统工业协议最重要的问题
[*]OPC UA集成和实施难度高。依靠点对点通信。
[*]MTConnect是一种只读协议
[*]这些协议集成尺度有肯定的精密耦合，使得维护和扩展变得更加困难。
那到底什么样的工业协议才气办理这问题？在回复这个问题前，我们先了解IIoT中工业协议的焦点需求：
为什么须要工业协议？
工业情况中有大量设备（传感器、执行器、控制器等）须要协同工作。要实现这一点，必须让设备之间共享状态、指令和数据。
[*]焦点问题：如何让差异设备明白彼此传递的信息？
[*]设备之间必须有一种共同语言（即协议）。
[*]这种语言须要明确约定数据的格式、传输方式和行为逻辑。
[*]抱负方案：
[*]轻量化、安全、解耦、跨平台、及时性、易于实施。
按照以上的需求分析，OPC UA是没有做到的。OPC UA是重量级的，集成和实现难度高，安全性依靠于厂商的实现质量，而非协议本身的逼迫尺度化。生态系统过于复杂，实际上并差异一。
办理方案：MQTT + SparkplugB
mqtt是发布/订阅消息库协议，轻量级，基于TCP并且与数据无关的安全协议。重点是，使用MQTT架构，可以实现解耦架构，同时易于学习和集成。
MQTT的由来：
mqtt最初被提出是为了办理石油和天然气行业的一些停滞。在石油和天然气行业中，通讯基础设施有个问题，就是要从中提取数据的仪器仪表和传感器一样平常都在很偏僻的地点，所以要没有很好的通讯基础设施，导致两个问题出现：
[*]不能常常收罗监视数据，由于宽带不敷。
[*]即使检查了，也不肯定有反馈，由于信号不可靠
mqtt是为了办理这个问题而被开发，目标是开发一个可以快速和可靠提取据的协议。
MQTT的架构：
https://i-blog.csdnimg.cn/direct/35f36ec2ab5b4e4ea575ef0112a00ce0.png
MQTT 使用的是 发布/订阅（Publish/Subscribe）架构，为 IT 和 OT 的集成提供了更大的机动性息争耦性，同时也更易于集成。
在 MQTT 中，发布者（Publisher） 将消息发送到一个特定的主题（Topic），而 订阅者（Subscriber） 通过订阅该主题来接收消息。发布者和订阅者之间完全解耦，彼此无需直接通信。恰当须要多对多通信的场景，如多个传感器和监控设备之间的数据共享。
比如：有一个温度传感器，它收罗到的温度数据为 23°C。
温度传感器作为 发布者（Publisher），会将该温度数据通过 MQTT Broker 发布到一个名为 temperature的主题（Topic）。
任何须要这个温度数据的系统或设备（例如一个监控仪表或分析系统）只需作为 订阅者（Subscriber） 订阅 temperature 主题，即可从 MQTT Broker 处及时接收到温度为 23°C 的消息。
https://i-blog.csdnimg.cn/direct/0e85630f53e14dfd95a0045cedbc41b2.png
MQTT Broker提高系统扩展性
通过 MQTT Broker 实现消息中转，发布者和订阅者之间无需彼此了解彼此的存在。
这样，新设备加入时，只需订阅相关主题即可，扩展性极强。同时制止了点对点协议中新增连接导致的复杂性。
但是，MQTT也有些问题：
[*] 语义建模不足。MQTT 缺乏对数据的语义、结构和上下文的形貌能力。比如，它只管发送消息（"温度传感器=25°C"），但不能表明“这是什么设备、这个数据属于哪个工厂设备的哪个部分”。没有尺度和结构化界说
[*] MQTT 没有内置的主题发现机制，也就是说，应用步伐和设备不知道当前有哪些可用主题可以订阅或发布。
于是，出现了Sparkplug B，作为MQTT的扩展协议。两者联合，就弥补了MQTT原有的一些局限。
什么是MQTT Sparkplug B?
MQTT 本身只界说了数据传输的方式，但没有规定数据的具体格式，和如何在工业情况中同一设备状态、事件和下令的语义。Sparkplug B是一个为 MQTT 提供语义化和工业尺度化的协议。是一个扩展协议。Sparkplug B 界说了一种通用的数据模型和结构，资助工业设备用 MQTT 举行通信时实现数据的互操作性。
https://i-blog.csdnimg.cn/direct/e68967dbe01c436081363c4c803b2eb3.png
Sparkplug B 办理了什么问题:
Sparkplug 允许 IIoT 部署在硬件和软件源之间解耦数据。使用 Sparkplug，其他系统组件可以立即发现新数据源。它，说明白topic（主题）和 payload（有效负载）必须如何形成和结构化，并发送到支持 Mqtt Sparkplug 的代理。
Sparkplug B 界说了工业设备的状态（如属性、丈量值、事件）的同一结构，使差异设备和系统可以明白和操作相同的数据。例如：每个设备都用唯一的设备标识符（Device ID）体现。数据按组（Group）、设备（Device）、边沿节点（Edge Node）组织。
此外Sparkplug B还引入了设备生命周期管理，
状态消息功能，报告设备的在线/离线状态，确保系统中的设备状态始终最新。
主动发现与交互，Sparkplug B 允许订阅者主动发现发布者的主题和数据内容，而不须要手动配置。
以下是MQTT Sparkplug B的架构：
https://i-blog.csdnimg.cn/direct/804551eaab144bb7995a72668c775554.pngSparkplug B topic and payload（主题和有效负载）结构：
namespace/group_id/message_type/edge_node_id/device_id
分别是定名空间，组标识符，消息类型，边沿节点标识符，设备标识符
https://i-blog.csdnimg.cn/direct/2efafd090c384dc885841d2afdecef54.png以下是对主题和有效负载结构的表明：
1. Namespace (定名空间)
[*]界说：体现协议的版本和上下文信息，表明使用的是 Sparkplug B 协议。
[*]格式：spBv1.0
[*]用途：
[*]确定协议版本（如 spBv1.0 体现 Sparkplug B 的版本 1.0）。
[*]确保发布者和订阅者都明白相同的通信语义。
示例：
spBv1.0 体现使用 Sparkplug B 协议的第 1.0 版。
2. Group ID (组标识符)
[*]界说：逻辑分组的标识符，用于区分差异的设备网络或逻辑分组。
[*]用途：
[*]在大型工业情况中，每个组通常体现一个工厂、车间、生产线或逻辑区域。
[*]允许系统将差异的设备数据分类管理，制止肴杂。
示例：
factory1 体现某个工厂的数据组。
lineA 体现生产线 A 的数据组。
3. Message Type (消息类型)
[*]界说：消息的类别或功能，用于形貌当前消息的目标和内容类型。
[*]常见类型：
[*]NBIRTH：节点上线（Node Birth）。
[*]DBIRTH：设备上线（Device Birth）。
[*]NDEATH：节点下线（Node Death）。
[*]DDEATH：设备下线（Device Death）。
[*]DATA：数据更新（Data Metrics）。
[*]CMD：下令消息（Commands）。
用途：
[*]资助订阅者快速判断消息内容的性子（例如设备状态还是数据更新）。
示例：
NBIRTH 体现该消息用于转达边沿节点的上线事件。
DATA 体现该消息携带设备的及时数据。
4. Edge Node ID (边沿节点标识符)
[*]界说：边沿节点的唯一标识符，用于体现一个数据收罗网关或设备聚集的代表。
[*]用途：
[*]边沿节点通常是物理设备（如边沿计算网关、PLC 或其他控制器），负责与具体设备交互并将数据传递到 MQTT Broker。
[*]通过唯一 ID 区分差异的边沿节点。
示例：
edge1 体现边沿网关设备 1。
5. Device ID (设备标识符)
[*]界说：具体设备的唯一标识符，用于形貌边沿节点下的单个设备。
[*]用途：
[*]一个边沿节点通常管理多个设备，Device ID 允许对这些设备举行准确区分。
[*]确保每个设备的数据和状态消息可追踪到具体来源。
示例：
temperature_sensor1 体现一个温度传感器设备。
感想：
当然，固然MQTT Sparkplug B弥补了MQTT的一些局限，但现在也不能完全代替OPC UA。在网上看了一些资料是这样表明的，在未深入学习之前就不多涉及这方面了，只能说传统工业情况，如PLC和SCADA之间沟通还是使用OPC更合适，由于一些历史数据管理和传统工业设备兼容性的原因，但一旦涉及到云端的话，就要用MQTT了。后续肯定会把这部分的知识学好。
以下是我在社区里问的问题，和社区的老手给我的一些建议。他的回复我没有完全明白，还须要本身去研究一下。添加到此处可以作为参考。也可以作为给本身的提示。
https://i-blog.csdnimg.cn/direct/233823a2083a4974bb9c9894531d4a98.pnghttps://i-blog.csdnimg.cn/direct/f5df85616f9c4f23a87c0d9f1dafdefc.pnghttps://i-blog.csdnimg.cn/direct/15a5cfc36358476688cdec5ab91f4ba2.png
我信赖在数字化转型的情况下，MQTT Sparkplug B将会是首选协议，而且也应和一些其他工业协议融合，达到最好的效果。
这是我入门智能制造领域以来写的第一篇博客，记录我感兴趣的部分，后续会不断提升本身的技术知识库。如果写得不好，大概有什么写错的，希望可以在评论区给我一些指导，谢谢。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]