框架和传输：选择最佳 IIoT 连接解决方​​案

至少可以说，在当今新兴的工业物联网 (IIoT) 环境中构建分布式系统基础设施可能是一项艰巨的任务。如果您是开发人员或系统架构师，您就会知道有许多工具和协议可用于在分布式应用程序中移动数据。更不用说直接在 TCP 或 UDP 套接字上构建您自己的自定义解决方案的可能性。如果在您就下一个基础架构做出决定之前需要完成的大量工作已经为您完成，那不是很好吗？

你知道吗？工作已经完成，现在可以帮助您做出决定。您一定会问，“谁进行了所有这些研究，是否有一些公司希望出售自己的解决方案？”好消息是，这项研究是由一个独立的财团——工业互联网财团 (IIC) 完成的。它以供应商中立、公正的方式进行，现在您可以获得结果信息。

完全免责声明：是的，我确实为一家为工业互联网提供基础设施的公司工作，但我绝不是说我们的解决方案是最好的解决方案。问题的真正答案，“什么是最好的解决方案？”是，“这取决于。”

答案取决于您对基础架构解决方案的需求：

• 您是否只需要从 A 点向 B 点发送字节数据？
• 您是否需要可靠地交付数据？
• 您是否需要任何以数据为中心的意识，以便基础设施能够为更智能的解决方案提供一些有效的交付决策？
• 您希望将多少数据处理交给基础设施？

这些关键问题以及更多问题的答案是我在这篇文章中调查的内容。希望在本文结束时，您将获得所需的信息，以便就针对您的独特应用程序的最佳解决方案做出明智的决定。

关于工业互联网联盟（IIC）

IIC 由工业互联网领域的一些非常大的参与者于 2014 年成立。创始公司（思科、英特尔、AT&T、IBM 和 GE）着手创建一个仅专注于工业互联网应用需求的组织。现在，该财团由 250 多家大大小小的公司组成。该联盟的成果包括一组文件，概述了这些类型的工业互联网应用的需求和潜在解决方案。 IIC 工业互联网连接框架 (IICF) 文件是一份指导文件，非常适合帮助您确定基于市场示例的最佳解决方案。除了各种文件，他们还建立了测试平台，用于证明各种技术满足各种现实市场示例的能力。可以在 IIC 网站上找到有关可用文件和基于市场的测试平台的信息。

交付数据：传输和框架

目前有许多解决方案可用于在应用程序之间获取数据。在 IICF 文档中，这些解决方案分为两类：传输和框架。让我们来看看这两种类型的数据传输解决方案，看看它们在整个连接层堆栈中的位置。下面的图 1 显示了这个连接堆栈。

图 1. IIC 连接框架堆栈

几乎每个阅读本文档的人都见过这样的连接堆栈，但 IIC 的堆栈有一个明显的区别：传输层和框架层。

通常，我们倾向于将您在传输和框架类别中看到的所有解决方案组合在一起，但是传输和框架之间存在一个非常大的区别。传输用于将数据从 A 点传送到 B 点，而框架基本上利用传输的能力，同时提供数据类型系统以实现互操作性。简而言之，当只使用传输时，应用程序必须将数据制定到通用缓冲区中，以便移交给传输。但是，对于框架，应用程序只需要将数据传递给框架，框架将负责为底层传输构建缓冲区以继续发送其数据。在应用程序的数据级别工作对于提供内容过滤和发现等功能的应用程序有很多好处，而如果您的应用程序仅在传输层使用某些东西，则由应用程序在需要时实现发现和过滤。表 1 为您提供了在每个传输层或框架层可用的所有功能。

表 1. 传输和框架功能

您可以使用传输构建分布式工业互联网应用程序吗？是的。可以用框架搭建分布式工业互联网应用吗？是的。这个比那个好吗？真正的答案是：“视情况而定。”哪种解决方案最适合您的基础架构取决于您的应用程序的要求。本文的其余部分将介绍其中的几个框架和传输，以便您可以决定哪种技术适合您的应用程序。

运输

目前有许多解决方案可用于在应用程序之间获取数据。在 IICF 中，调用了利用 UDP 或 TCP 的标准 IP 套接字接口的传输。如果您的应用程序需要可靠的数据传输，那么开发人员会选择 TCP，因为它具有面向连接的功能和可靠的机制。对于更简单的连接和不可靠的数据传输，将选择 UDP，因为它易于使用和多播传送。多年来，大多数网络应用程序都使用这些基本接口来发送和接收数据。更高层传输提供的所有功能（在表 1 中列出）都必须在应用程序中直接构建。在查看 DDS-RTPS、CoAP、MQTT、HTTP 和 OPC-UA Bin 的更高层传输时，我们实际上只会查看 CoAP 和 MQTT 的详细信息。 DDS-RTPS、HTTP 和 OPC-UA Bin 传输基本上分别直接绑定到它们之上的 DDS、Web 服务和 OPC-UA 框架。这些传输的功能将作为后续框架讨论的一部分进行讨论。

MQTT

让我们来看看消息队列遥测传输 (MQTT)。同样，MQTT 在此处被列为传输，因为它不强制或实现应用程序的数据模型。它只提供一个缓冲区，应用程序必须在其上制定用于发送和接收的数据。其创建的主要目的列在其名称中：遥测。让设备或应用程序在现场连接并报告数据到后端云或异地处理位置。这种传输非常适合家庭物联网网关或一组已部署设备的管理器。 MQTT 的主要架构是基于代理的，如图 2 所示。

图2.MQTT Broker架构

在此架构中，所有远程客户端都将其数据发送到 MQTT 代理，代理负责将其数据发送给任何请求该数据的客户端。这种基于代理的架构可以轻松地以松散耦合的方式发送和接收数据，但它不适合支持低延迟、高度确定性的工业应用程序。作为一种传输方式，MQTT 在分布式工业应用的整体格局中占有一席之地。以下是您可以用来确定 MQTT 是否应该用于您的下一个或当前项目的工具。这里有五个“是”或“否”的问题。如果您对其中三个或更多问题的回答是“是”，那么 MQTT 是您的正确选择。

MQTT 问题

1. 您是否将您的应用程序视为数据收集？
2. 设备与设备之间的通信很少吗？
3. 不考虑互操作性吗？
4. 你有很多小设备吗？
5. 软件是一个小挑战吗？

MQTT 是 IICF 文档中列出的唯一一种并未真正与更高层框架绑定的传输。这就是我们将其作为传输单独拆分的原因。现在，我们来看看IIC文档中列出的框架。

框架

如前所述，框架和传输之间的区别在于，框架包括维护和实施数据模型的能力，该数据模型由参与该框架的应用程序使用。在称为 OPC-UA、OneM2M、DDS 和 Web 服务的四个框架中，我们将只关注前三个。 Web Services 是一个非常有名的框架，有大量的在线参考资料可供研究，因此，我们不会在这篇文章中对其进行审查。对于每个选定的框架（OPC-UA、OneM2M 和 DDS），我们将概述该框架的基础知识以及必须回答的关键问题，以确定该框架是否是您的分布式 IIoT 应用程序的正确解决方案。

OPC-UA

让我们来看看 OPC-UA 作为我们的第一个框架。开放平台通信统一架构 (OPC-UA) 在 IICF 文档中被描述为“一种工业通信架构，用于在传感器、现场设备、控制器和应用程序之间实现平台独立、高性能、安全、可靠和语义互操作性。车间级以及车间和企业 IT 云之间的实时连接。”

与 MQTT 一样，OPC-UA 也是基于代理的架构。 OPC-UA 客户端向服务器提供数据对象，然后服务器响应来自其他 OPC-UA 客户端的请求。通常，这些数据对象是以设备为中心的对象，它们基本上是各种设备输入和输出变量的集合。客户端可以构建所需对象的图形，服务器将绘制出所有收集的对象并向请求客户端提供一致的响应。图 3 是一个典型的架构图，显示了给定系统中可用对象的图表。

图 3. OPC-UA 中的典型设备数据对象图

OPC-UA 基础设施主要用于工业自动化和制造环境。以下是应该回答的四个问题，以确定 OPC-UA 是否适合您的应用程序：

OPC-UA 问题

1. 您从事离散制造吗？
2. 您是否与德国工业平台 4.0 计划有关？
3. 您是否正在构建将由控制或过程工程师或技术人员而不是软件工程师集成的设备？
4. 您的产品是否会用于不同系统中的不同应用程序，而不是您控制架构的一种（类型）系统？
5. 您是否在为“工作单元”制造设备？

如果您对其中三个问题的回答为“是”，那么 OPC-UA 就是您应用的正确选择。

OneM2M

IIC文件中提到的第二个框架是oneM2M。 IICF 文档中对 M2M 的描述是，“oneM2M 提供了一个位于应用程序和连接传输之间的公共服务层。它提供了跨不同行业领域的物联网应用程序通常需要的功能。这些功能通过 RESTful API 暴露给应用程序。OneM2M OneM2M 的连接标准允许托管在连接的机器和设备、企业系统和移动设备上的应用程序以高效的方式相互通信。 , 安全的方式。oneM2M 水平平台是可扩展的，因为公共服务元素可以部署在主机上、近端网络边缘或企业云中。”今天使用 oneM2M 的主要应用是家庭自动化和利用移动系统的大规模应用。公共服务层中可用的服务由大型电信公司提供。图4为oneM2M中调用的三层架构。

图 4. oneM2M 架构

以下是您应该回答的五个具体问题，以确定 oneM2M 是否是您应用的正确选择。对这些问题中的 3 个回答“是”将表明 oneM2M 是您的正确选择。

OneM2M 问题

1. 您知道“ICT”代表什么吗？是您吗？ （信息和通信技术）
2. 蜂窝网络是您的主要连接技术吗？
3. 您的目标应用是否主要由移动部件组成？
4. 您的系统组件能否容忍间歇性连接和松散控制的延迟？
5. 您的系统是否会利用通信提供商（例如电信公司）提供的服务？

数据分发服务 (DDS)

我们将探讨的最后一个框架是 DDS。我不得不承认，作为这篇文章的作者和一名 RTI 员工，我偏向于 DDS，因为我已经使用它超过 14 年了。在 IIC IICF 中提到的四个框架中，DDS 是唯一一个提供点对点、发布/订阅架构的框架。使用 DDS，每个应用程序都参与创建共享全局数据空间的“数据总线”。这意味着数据总线包含一组数据主题，每个主题都定义了其独特的数据模型，然后数据总线上的任何参与者都可以发现这些主题。一旦对等应用程序声明其意图发布有关主题的数据或订阅有关主题的数据，DDS 就会通过发现机制将所有适当的发布者与其订阅者联系起来。图 5 是一个分层数据总线架构图，它实例化了三个数据总线，这些数据总线通过位于水平层之间的网关连接。

图 5. 使用 DDS 的分层数据总线架构

此示例图基于您会在医院中找到的医疗保健患者监控应用程序。然而，这只是当今使用 DDS 的多种实时自治应用程序的一个例子。其他应用领域包括智能电网、石油和天然气、自动驾驶汽车、运输和国防系统。以下是关于您的应用程序，您应该问自己的五个问题，以了解 DDS 是否是您的正确选择。

DDS 问题

1. 如果离线几分钟/秒/毫秒会产生严重后果吗？
2. 您在过去两周内说过“毫秒”或“微秒”吗？
3. 你有超过 10 个程序员吗？
4. 您的数据是否有多个目的地？
5. 您是否正在构建下一代 IIoT 设计？
   

结束一切

正如我之前提到的，鉴于我在一家 DDS 公司工作，我偏爱 DDS 基础设施及其为实时自治系统解决的问题。也就是说，我希望这篇文章为您提供了一些工具来确定什么是适合您的 下一个或当前的分布式基础设施项目。因为，实际上，这些传输和框架都擅长解决非常不同的问题。关键是要弄清楚您的应用程序需求在可用解决方案中的哪个位置。此处推荐的工具包括 IIC 工业互联网连接框架 (IICF) 以及每个解决方案的关键问题列表。如果有什么遗漏，请不要犹豫，在评论中与我联系。我很乐意继续讨论，并了解可以帮助开发人员和架构师解决其连接问题而无需使用自定义专有解决方案重新创建轮子的任何其他解决方案。

其他资源：

• RTI 博客>> 工业互联网连接文档评估核心标准：DDS、OPC-UA、Web 服务
• 免费点播网络研讨会：IIC 的连接框架如何指导 IIoT 连接选择