工业物联网解决方案 | 6 工业物联网通信解决方案

要说选择工业物联网的任务(工业物联网 ) 通信基础设施是一项非常复杂的工作，这是轻描淡写的。对无数商用解决方案进行评估既费时又费钱。尝试下载和评估每种基础架构的多个解决方案，您会很快发现自己处于一个项目中，该项目需要几个工程师六个月才能完成。我们都去过那里，我想帮助您节省一些宝贵的时间！

这篇博文的目的是向您介绍市面上流行的 IIoT 基础设施解决方案——AMQP、CoAP、DDS、RTI Connext DDS、MQTT 和 ZeroMQ——以及突出每个解决方案的功能。将应用以下六个评估领域：架构、通信模式、传输、数据类型和过滤、服务质量和安全性。

单击此处下载可打印的 PDF 版本。

1.架构

根据给定通信基础设施的架构模式，应用程序将用于跨基础设施与其他应用程序通信的逻辑连接（如下图 1 所示）各不相同。当今中间件解决方案中使用的两种最基本的架构是 (1) 点对点和 (2) 基于代理的星型架构。

1. 点对点架构 使应用程序可以直接相互通信，而无需向中间元素发送数据。由于只有发送和接收应用程序消耗 CPU 资源来完成传输，因此这些架构在数据传输方面本质上更高效。因此只有拥有数据的应用程序和需要数据的应用程序才会消耗 CPU 周期；从而导致基于应用程序需求的有效处理分配。点对点架构的另一个好处是数据的确定性交付更容易实现，因为在生产者和消费者应用程序之间没有处理数据的“中间人”。

图 1. 各种物联网协议的架构图。

2. 基于代理的解决方案 要求所有正在发送数据的应用程序将数据直接传输到代理服务器，然后它会转而将这些数据重新发送到接收应用程序。这种架构的好处是代理管理与发送/接收数据相关的所有复杂性。通常，这些解决方案具有内置工具，用于准确查看哪些数据路径处于活动状态、谁正在发送数据以及谁正在接收数据。基于代理的解决方案确实会导致数据传输延迟，并且还会出现单点故障，如果代理失败，所有通信也会失败。为了解决单点故障问题，这些实现中的大多数都提供了冗余且高度可用的代理服务器。

2.沟通模式

通信模式支持对于您可以在项目或产品线的整个生命周期中使用的基础架构至关重要。最初的项目可能只需要发布/订阅，但后续的项目或产品可能需要额外的模式，如请求/回复或排队。在这方面，并非当今可用的所有现有 IoT 解决方案都可以支持您的项目所需的所有必要模式。对于比较表，我们确定了当今最常用的模式以及每个基础架构解决方案是否提供该模式。这些是当今最常用的模式：

• 发布/订阅 ：应用程序（订阅者）请求数据 1 次，然后对数据的所有后续更新都“推送”给订阅者。无需不断要求数据更新。
• 请求/回复/RPC (远程过程调用 )：请求者应用发送请求，回复者应用回复请求。
• 排队 （或点对点 )：数据被推送到一个将信息保存在队列中的服务器。然后可以从队列中提取数据或将数据推送给消费者。与发布/订阅不同，每条数据仅分发给一个接收应用程序。
• 一对多 ：能够让多个接收应用程序从单一来源获取相同的数据。
• 多对一 ：能够将来自多个来源的数据接收到单个消费应用程序中。

3.传输和路由/桥接

大多数通信中间件解决方案都支持 TCP 作为其主要通信协议。使用 TCP，您可以使用 TCP 固有的内置可靠性机制可靠地传输数据。这对于需要可靠性但过度杀伤的特定数据流来说是理想的，并且为不需要可靠交付的简单传感器数据增加了不必要的开销。一些物联网解决方案（如 ZeroMQ 和 DDS）也支持其他传输，如共享内存。一种值得注意的传输是将 UDP 传输用于 DDS。因为可靠性的实现是内置在 DDS 中的，所以它不需要底层的可靠传输。这使应用程序能够挑选和选择哪些数据流是可靠交付的，哪些流是最好的。

所有这些解决方案都以某种方式在传输之间和跨 WAN 路由数据。在当今世界，利用 ESB 和 Web 技术的企业系统还必须访问一些实时数据，因此通信中间件也必须支持连接到这些技术。因此，您将看到路由和桥接是分布式系统中间件的核心组件。

4.数据类型和过滤

数据在线路上的封装和表示方式对于给定的基础架构也是独一无二的。一些解决方案只发送原始数据字节，由应用程序来序列化和反序列化数据。其他人只发送文本/字符串数据，以便信息可以用 XML 或 JSON 格式表示。这种情况在当今的 Web 技术中非常常见，但效率可能非常低，因为每次发送数据时，数据包还包含数据的描述，有时会使数据包大小超过其原始大小的 3 倍。较大的数据包大小会增加带宽使用率，并增加传输发送端和接收端的 CPU 使用率。在中间放置一个代理，您现在还可以使线路上的数据包数量增加一倍。

其他解决方案，例如 DDS，支持使用由中间件唯一序列化和反序列化的强类型数据。模式是单独发送的，XML 或 JSON 不是这种情况，因此您无需为每条消息（或样本）支付罚款。这对于过滤方面也变得非常重要。假设您正在设置一个拥有许多订阅者的发布者。一些订阅者可能想要所有数据，但一些订阅者只想要一部分数据。如果没有强类型数据解决方案，您的应用程序将不得不管理所有这些过滤功能，而您必须编写更多代码。使用诸如 DDS 之类的强定义类型信息的解决方案，中间件可以为您管理所有过滤。更少的代码 =更快乐的开发人员 :)。事实上，RTI Connext DDS 具有额外的功能，可以在数据传输的写入端提供这种过滤，从而减少线路上的带宽使用量，并减少不需要过滤掉数据的应用程序的 CPU 处理。

5.服务质量

并非所有数据都是平等的。这是什么意思？好吧，实时分布式应用程序中的一些数据是流式传感器数据。大多数时候这种数据不需要保证交付的数据。对于给定的传感器，您可能只关心是否满足了给定的数据交付期限，或者更重要的是，没有满足。其他数据可能是警报/事件数据。此数据的可用性频率没有周期性。但是，保证其交付非常重要。对于警报/事件数据来说，了解该数据源是否处于活动状态也很重要。如果警报生成器不存在，这可能会在您的实时系统中导致灾难性事件。这些只是管理应用程序各种数据流的服务质量 (QoS) 方面的一小部分。与当今所有其他 IIoT 解决方案相比，服务质量是 DDS 独一无二的一个领域。 DDS 标准是从第一天开始构建的，旨在解决 QoS 适用于每个主题的概念。

以下是可以基于生产者、消费者或两者定义的所有 QoS（DDS 和 MQTT）：

DDS QoS 策略

• 可靠性/尽力而为
• 历史
• 截止日期
• 活力
• 使用寿命
• 基于时间的过滤器
• 耐用性
• 读者/作者生命周期
• 延迟预算
• 运输优先
• 所有权
• 资源限制
• 分区
• 目的地顺序
• 用户数据、群组数据、主题数据

有关 DDS 提供的这些 QoS 的描述，请参阅此资源。虽然 DDS 在其提供的 QoS 策略方面是独一无二的，但其他基础设施解决方案也提供了一些有限的 QoS 功能。这些 QoS 功能的结构围绕使代理成为支持冗余和高可用性的解决方案的基础。使用 MQTT 时，有 3 个基本的 QoS 设置：

MQTT QoS 策略

• QoS 0：最多交付一次
• QoS 1：至少交付一次
• QoS 2：一次交付

有关 MQTT QoS 的说明，请参阅此资源。

6.安全

您是否担心系统中的数据被泄露？如果没有，您要么需要有一个非常严格的物理安全解决方案，要么如果您的数据被外部威胁访问和/或操纵，那么您的数据就不是那么重要。为了解决这个问题，大多数物联网通信解决方案采用 SSL/TLS 传输来保护生产者和消费者之间的数据传输。 ZeroMQ 还提供了使用 SASL 的身份验证解决方案。 DDS 是唯一能够在每个数据流（主题）的基础上指定身份验证、访问控制、加密/解密、数据标记和日志记录的解决方案。这种由 OMG DDS 安全规范定义的安全实现基本上将身份验证和访问控制与发现的概念联系在一起。有关 DDS 安全的更多信息，请参阅此资源。

现在您已经掌握了所有信息，您可以将评估阶段缩小到与您尝试交付的应用程序类型相关的几个解决方案。祝你好运！

单击此处下载可打印的 PDF 版本。