构建工业数据基础

I4.0 Insight

4分钟

2024年7月18日

本文旨在解密一个既支持又挑战数字供应商的概念，提供清晰的解释和实施最佳实践。

当前情况

工业数据基础通常是指将各种类型的数据源整合到一个地方，以便其他应用程序便捷使用。

在当今的IIoT（工业物联网）市场，工业数据基础的实施方式如下：

通过RESTful API与现有客户软件集成，以解释和处理通过TCP/UDP传输的上层工业协议。
使用脚本或ETL工具从现有客户关系数据库中提取数据，并将其存储在数据库中。
建模或格式化收集到的数据，并通过RESTful API发布。

然而，这种方法存在缺陷：它将数据孤岛变成了数据“意大利面”。平台数据的消费者会发现这并不方便，而现有系统通过平台进行的通信效率也不会提高。

为什么会发生这种情况?

在信息时代，RESTful API 和网络服务已成为系统数据集成的主要方法。随着工业物联网（IIoT）概念的兴起，RESTful API 已成为数据消费层集成的主导方法。

然而, 它们并不是为了双向数据传输和互操作性而设计的。例如，当客户希望集成一个消耗各种类型数据的应用程序时：

采用 IIoT 平台之前 ⬇️

采用 IIoT 平台之后 ⬇️

即使在将平台视为“中心”之后，每条独立的连接仍然存在。显然，仅通过更改 RESTful 请求的地址，并不能简化或标准化数据集成任务。

RESTful API 的无状态设计带来了极大的便利，但这也意味着两个系统无法相互感知，必须不断轮询以获取最新信息。在采用 IIoT 平台后，编写轮询脚本的步骤仍然不能省略；这个任务仅仅转移给了 IIoT 平台的工程团队。

以上示例假设系统配备了全面的 RESTful API。然而，在现实中，IIoT 平台供应商经常需要自定义编码各种微服务和脚本，直接与数据库互动以实现集成和通讯。这种方法远非 IIoT 的标准化和产品化愿景。

我们应该做什么？

如上所述，RESTful、Web服务器 + ODBC/JDBC、OPC和Modbus等流行协议都是基于轮询机制的。

即使数据源没有变化，网络中仍然会有周期性请求泛洪，导致带宽浪费、计算开销以及额外的问题，如延迟、缺乏可扩展性和难以分层（设计和使用RESTful请求常常成为工业OLTP+OLAP的障碍）。最重要的是，围绕RESTful中心的集成架构无法形成一个标准化的基础产品，从而简化和标准化数据集成。

因此，事件驱动框架应运而生

当温度变化（事件发生）时，温度传感器会向网络推送（发布）一条消息，公告其新温度。此公告会同时广播给所有对此变化感兴趣（订阅）的消费者（MES，ERP）。

MQTT协议的订阅和发布机制使事件驱动的系统和网络成为可能。鉴于工业数据的特点，我们可以大胆构建一个基于消息代理的星型拓扑，而不是继续将数据意大利面串在一起进行点对点通信！

基于EDA（事件驱动架构）的统一命名空间

利用MQTT代理集成所有数据源，实现无缝订阅和双向通信。
针对所有输入的数据执行基于ISA-95、Sparkplug B或OPC UA的语义建模。这将实现不同系统之间通信格式的语义统一。

统一命名空间（UNS）可以分为两个层次：

MQTT代理及其订阅者层充当实时数据交换的枢纽。此处流动的信息是瞬时的（快照）。
数据湖层。来自第一层的信息存储用于时间序列用例（例如，根据三轴传感器数据的一个周期预测电机故障、查询历史标签趋势和汇总员工信息）。

由于MQTT 3.1的协议级别限制（实际上是为了简化而进行的权衡，未来的文章将详细说明），在流数据处理方面有时会不可靠。为了确保可靠性，UNS的先驱者往往并行使用Kafka和MQTT。然而，基于我们的经验，仅使用MQTT远比RESTful "数据意大利面" 更可靠。利用消息代理和发布-订阅机制的事件驱动架构，可以建立一个标准化的工业数据基础。

感谢工业4.0解决方案的总裁沃克·雷诺兹，提出并积极推广UNS概念。