介绍

物联网（IoT）一词用于各种上下文中，其中它经常被误解，因为它可以被其他术语所取代，以更好地描述我们处理的问题，或者定义彼此不兼容。让我提醒你这个学期生命的开始。

那个“物联网”的东西

“物联网”一词始于1999年发表的演讲的标题，旨在解释供应链绩效背景下射频识别（RFID）的新概念。很明显，这并不意味着某人有权控制其他人如何使用这个短语，但我的观点是，一个精确的术语定义对于共同的规则，架构，解决方案，要求，功能，限制等一起工作非常重要。在实践中具有共同的定义，可以对照有权使用该术语的应用程序的要求来检查选定的技术、解决方案或产品功能。

本文的主要目标是为旨在区分物联网应用程序域功能的社区工作做出贡献。面临的主要挑战是缩小定义范围，使其明确而有意义。

在大多数出版物中，我知道术语物联网可以简单地替换为以下众所周知的术语：

• SCADA – 监控和数据采集
• DCS – 分布式控制系统

文本仍然完全正常。在这种情况下，“传感器”一词扮演“事物”的角色，节点的网络是互联网的同义词。通常没有人关心我们是在谈论卧室中的温度传感器还是发电厂的锅炉鼓中的温度传感器，除了在发电厂的情况下有时会添加前缀Industrial。为了使我们的生活更轻松，让我们忘记“I”（工业）前缀，因为它不会改变最重要的应用程序域功能。

为了说明进一步的讨论，让我提供可以分别识别为SCADA / DCS和物联网应用的示例。

SCADA/DCS 示例

假设 OPC UA 服务器公开了表示原油精炼过程的123456值。在此服务器上使用SCADA，我们可以监视和手动控制该过程。使用DCS可以实现监控算法以提供宏优化。

对于此方案，我们可以应用以下工作流：

• 服务器实例化原油精炼过程的 OPC UA 信息模型。
• 所有配备传感器的工厂车间设备都在获取代表当前过程状态的数据（例如，支持Modbus RTU通信协议的流量计#A-4321），并正在等待来自服务器通信引擎的数据请求。
• 服务器中嵌入的通信引擎轮询所有工厂车间设备，包括流量计#A-4321，以恢复当前过程状态。
• 最后，OPC UA服务器在其地址空间管理组件（即根据原油精炼过程的信息模型实例化的地址空间中）公开数据（更新相关变量节点的值属性，例如，表示虚拟流量计#A-4321的#A-4321对象）。
• 连接到此服务器的 OPC UA 客户端以标准化方式进行更新。

请注意，在这种情况下，OPC UA客户端和OPC UA服务器可以使用任何现有的传输协议（例如HTTP，HTTPS，TCP，UDP，AMQP）通过Internet建立连接。客户端和服务器之间传输协议的选择由 OPC UA 规范协商和限制.

物联网示例

你认为一盒（甚至一包）香烟可能是“东西”吗？它有一个条形码，所以它是数据的来源。是传感器吗 - 否，因为在这种情况下，条形码阅读器（工业扫描仪）是传感器。我们能否将条形码阅读器识别为“事物” - 如果目标是提供GLOBAL卷烟跟踪系统，答案是否定的。例如，这同样适用于药物。它是物联网解决方案吗 - 我的答案是肯定的，毫无疑问。是SCADA / DCS吗 - 答案是否定的，因为服务器（未铺设的通信引擎）无法轮询世界上所有可能出现盒子的地方。原因有二：

• 管理如此庞大的地址集是不切实际的，甚至是不可能的。
• 服务器不知道何时轮询，因为相关数据显示为事件而不是进程状态值。

假设服务器有兴趣，甚至只允许收集一个供应商的产品数据 - 并非所有条形码阅读器获取的代码都与服务器相关。

“东西”是聪明的吗 - 我不认为我们可以称条形码为智能的东西。它是可控的吗 - 不。

最有趣的观察是，我们可以将这个用例识别为物联网应用程序，但我们根本没有提到OPC，AMQP，MQTT，SOA，Internet，WI-FI，无线，Modbus等，而只是我们有重要的移动数据，解决方案是全球范围的。这很好，因为我们可以根据此应用程序要求检查可用的技术功能。正如我所说，选择通信技术不是目标，但我们必须知道它如何扩展到这样的应用。

现在，让我们用LOCAL替换“GLOBAL”这个词（例如，商店里的收银台农场），同一个应用程序不再是物联网部署，不是吗？即使收银台使用IP协议（例如内联网）互连，也是如此！

有时需要强调的是，任何物联网应用都必须保证高水平的鲁棒性，但传感器和数据鲁棒性要求的重要性适用于各种应用，例如在飞行过程中控制飞机发动机。通过使用本地WI-FI降落机场后，可以通过将存档数据上传到中央高级分析系统（如香烟盒条形码）来监控和跟踪相同的引擎。是物联网吗？它不是在飞行期间，但解决方案对生命敏感。登陆后是物联网，但数据的可靠性和数据传输并不那么重要，不是吗？

物联网范式

我对物联网定义的建议如下：

物联网是关于：

• 移动数据获取 - 如何从移动设备（事物）收集数据;
• 移动数据订阅 - 如何通过互联网将数据传输到可以处理的地方;
• 移动数据处理 – 如何将数据集成到选定的应用程序中，以提高过程行为性能。

数据获取与各种最后一英里通信技术有关，例如RFID，WI-FI，VHF，蓝牙等。可以使用消息传递系统（例如 AMQP、MQTT 等）支持订阅。例如，利用数据消耗的一个很好的候选者是OPC统一架构。

参考前面的示例，在这两种情况下，数据获取过程看起来非常相似 - 我们有一个数据源和一个传感器在某个时间点耦合在一起，负责对数据进行采样。从应用程序功能的角度分析示例，我们无法比较它们，因为根本没有定义任何需求 - 只提供了非常一般的描述。看起来应用程序功能与术语定义无关。这就是为什么术语SCADA，DCS和IoT可以互换使用的原因，忽略了以下数据采集模式之间的根本差异：

• 数据轮询 – 连续检查传感器以查看它们所处的状态，通常是在多点或多点通信（连接了共享同一条线路的多个设备的通信引擎）中，通过向每个设备发送一条消息，一次一个，要求每个设备响应并发送新数据。
• 数据订阅 – 包含传感器获取的过程数据的消息的发送者（称为发布者）不准备要直接发送给特定接收方（称为订阅者）的消息，而是将已发布的消息分类为主题，而不知道哪些订阅者（如果有）可以接收消息。同样，订阅者对一个或多个主题表示兴趣，并且只接收感兴趣的消息，而不知道存在哪些发布者（如果有）。

值得强调的是，在这两种情况下，获取数据的可重用性都是有保证的。在数据轮询方案中，与通信引擎耦合的服务器可能同时由许多客户端连接。在数据订阅方案中，发布者负责使用代理直接或间接将数据多播到所有连接的订阅服务器。

要部署 IoT 方案，请执行以下操作：

• 移动数据必须使用消息通过互联网（或内联网）发送;
• 这些消息的有效载荷由负责在地址空间中公开它的服务器（例如OPC UA服务器）异步使用;
• 应用程序（例如OPC UA客户端）处理公开的数据以达到选定的关键绩效指标（KPI）。

要求以标准化的方式格式化消息的有效负载，以便在获取站点上进行分解，并由分析应用程序（例如OPC UA客户端）有意义地使用。

数据采集模式

在上面的讨论中，应用程序功能已被排除为一个因素，可用于识别物联网应用程序。现在，让我们分析一下数据采集模式对应用程序行为模型的影响。

使用数据轮询，我们必须处理同步数据采集模式。在这种情况下，应用程序必须遵循交互式行为模型，因为它通过从表示处理状态的序列中提取数据来主动轮询数据源以获取更多信息。此类行为由迭代器表示，迭代器用于循环访问数据流。应用程序在数据检索过程中处于活动状态 - 它通过自己方便地发送请求消息来控制检索的速度。此枚举模式是同步的，这意味着在轮询数据源时可能会阻止应用程序。这种投票模式类似于访问书店并查看书籍。读完这本书后，你再去一次，看看另一本书。如果这本书不可用，您必须等待，但您可以阅读您选择的内容。

另一方面，在反应式行为模型中，通过订阅数据流为应用程序提供更多信息，并从源向其提供更新。应用程序在数据检索过程中是被动的：除了订阅源数据流之外，它不会主动轮询源，而只是对推送到它的数据做出反应。在这种情况下，应用程序不会因等待源更新而被阻止。这是物联网采用的推送模式。这类似于加入一个读书俱乐部，在这个俱乐部中，您注册了您对特定流派的兴趣，并且符合您兴趣的书籍会在出版时自动发送给您。你不需要等待，但你必须阅读你所得到的。在许多情况下，采用推送模式非常有用，尤其是在数据作为事件异步可用时。

IoT 实现的推送模型需要额外的资源，负责将推送的数据多播到所有订阅者。此功能可以通过履行代理角色的中间件或由网络基础设施（例如IP多播）支持来完成。

交互式和反应式行为模型之间的根本差异必须明显影响最终的应用程序功能，例如：

• 过程可控性;
• 数据目标可发现性;
• 可维护性。

使用数据轮询请求消息还可以包含用于控制选定致动器状态的数据。在这种情况下，响应消息通常包含肯定或否定确认，应用程序可以使用这些确认作为选择进一步活动的条件。例如，在通信中断的情况下，请求消息可能会被重新发送。在执行器故障的情况下，可能会发出警报。在推送数据的情况下，很难以类似的方式实现远程控制功能，因为通信路径就像单向路由。

在交互式行为模型中，通信引擎必须具有包括事先寻址在内的所有信息，以便正确准备请求消息。消息必须是自包含的，才能由网络路由机制使用。在反应式行为模型的情况下，应用程序事先不知道数据源。因此，传感器的职责是格式化消息并将其推送到适当的分发渠道。在这种情况下，消息不是自包含的，因为它们携带的信息仅由路由机制间接使用。

对于轮询数据方案，如果数据源对于数据采集过程不是同构的，则在更换传感器后可能需要进行配置修改。另一方面，推送数据方案要求对数据源的任何替换或修改都不需要对应用程序配置进行任何修改。

结论

从上面的讨论中，我们可以推导出以下依赖模型：

Interactive applications (e.g. SCADA, DCS):

• 应用引擎依赖于同步数据采集引擎 – 数据被观察为实体流。
• 采集引擎取决于过程设备（传感器或执行器），它必须事先知道。

Reactive applications (e.g. IoT):

• 应用引擎依赖于异步数据采集引擎 - 数据被观察为事件流。
• 数据源取决于数据分发渠道。
• 异步采集引擎取决于分销渠道。
• 数据源和采集引擎都与数据分发通道的专有机制相关联。