12 月 3 日，2023 IoTDB 用户大会在北京成功举行，收获强烈反响。本次峰会汇集了超 20 位大咖嘉宾带来工业互联网行业、技术、应用方向的精彩议题，多位学术泰斗、企业代表、开发者，深度分享了工业物联网时序数据库 IoTDB 的技术创新、应用效果，与各行业标杆用户的落地实践、解决方案，并共同探讨时序数据管理领域的行业趋势。
我们邀请到天谋科技欧洲研发负责人、ASF 董事会成员 Christofer Dutz 参加此次大会，并做主题报告——《纳其源：如何用 Apache PLC4X 构建极简工业数据采集》。以下为中文翻译全文。
很遗憾我不能亲自来到现场与大家见面，只能远程做这个报告，但我将尽力和大家分享最近令我十分感兴趣并且全力投入的事情。
我将探讨如何使用 Apache PLC4X 从工业硬件进行通用数据采集，那么这与 IoTDB 有什么关系呢？毕竟我们是在 IoTDB 用户大会。我想说的是，如果你能把数据存储下来，这当然很好，而如果你还能把数据读取出来，那就更好了。我认为如何读取数据仍然是工业自动化领域中最大、最主要的未解决问题之一。我们现在知道如何存储和处理大量数据，但获取它们仍然是一个严峻的问题。
那么我将讲些什么呢？首先，我将为你们简要介绍工业运营技术领域通信的现状。之后，我将介绍 Apache PLC4X。也许你们中的一些人已经听说过它，但为了确保每个人都了解，并且都像我一样喜欢它，我还是要稍微聊聊 Apache PLC4X。最后，我还将分享我对如何将 PLC4X 和 IoTDB 结合起来，以解决真实工业问题的愿景。
01 OT（运营技术）通信现状
第一部分，运营技术通信现状。对于那些不太熟悉这个领域的人来说，OT 类似于工业自动化领域的信息技术（IT）。在其他领域中，与 IT 相关的一切通常涉及软件、计算机和网络。类似地，在工业自动化领域中，OT 涉及到自动化硬件、自动化网络和自动化软件。概括而言，对于来自 IT 领域的我们来说，当我们希望与 OT 领域的设备进行通信时，问题就开始变得棘手了起来。
如果你相信工业界的说法，尤其是结合上个月我们在纽伦堡参加 SPS 智能生产解决方案工业展的经历，当你和与会人员沟通时，你可能会认为工业中的数据采集并不是问题，因为所有人都宣称 OPC-UA 已经解决了这个问题。
但事实上，那只是市场宣传的一面，而如果你深入了解现实的话，可以参考 HMS 公司提供的数据，他们每年都会发布这样的图表。在过去的六七年里，我一直在演讲中使用他们的对比图。而总的来说，它们没有发生太大变化。
从图中可以看到，工业以太网的增长速度比现场总线快得多，因此可以认为，工业以太网就是 OT 通信的主体，即 OT 领域的通信主要是基于普通网络基础设施的，而现场总线通常具有一些专有的有线连接。
除了应用方面，工业以太网比现场总线的增长速度快以外，你可能还会注意到一点，即图中并没有出现 OPC-UA，这是因为 OPC-UA 实际上还并没有被广泛地使用。我推测，OPC-UA 被统计在了“其他以太网连接”这个类别中。也许 OPC-UA 在这里的占比并不是很小，但它依旧是和 MQTT 等其他通讯协议共享这个市场份额。在 PLC4X 中，我们支持许多其他基于以太网的通信协议，它们都在这里共享这些很少的份额。
为什么会这样？我认为 OPC-UA 在过去几年失去了很多信任。一个原因是它相当昂贵。实际中，你不得不用新设备替换故障或者过时的旧设备，而通常，支持 OPC-UA 部署的可编程逻辑控制器（PLC）设备要比不支持的贵一些。而且，如果你想使用 OPC-UA，你必须购买许可证。印象中我上次看到的支持 OPC-UA 部署的设备单价大约在 400 欧元。价格可能因厂商而异，但总的来说，即使只是为了部署在 PLC 设备上，你也必须付费。
但从我的角度来看，最糟糕的是它的性能非常差，你可以拥有一台性能非常强大的 PLC 设备，但只要并发很多简单的请求，它就可能被拖垮。或许可以举一个例子作对比，在一台西门子 S7 设备上，我们能够每 2 秒采集 2600 个数据点，而对 PLC 的负载几乎没有明显影响。然而，当使用 OPC-UA 时，只要每 2 秒采集 200 个数据点，你就可能让它完全宕机，这或许能让你对它的低性能有一些概念。
此外，因为引入 OPC-UA 而导致的新的兼容性问题也越来越常见。这个问题不是在通信层面，而是在更高的系统层级。因为 OPC-UA 引入了配套规范的概念，有点像某个特定领域设备的标准规范。但现在出现了关于哪个配套规范应该主导其他规范的争论，因此我们只是将问题挪到了一个更高的层级，并没有彻底解决。
上述这些原因导致了 OPC-UA 的采用率相对较低，与其所宣称的情况差距较大。我认为目前唯一可行的替代方案是 MQTT，但即便是 MQTT，仍然要求对设备进行改装。
那么如何解决这个问题呢？你可以在网关引入支持 OPC-UA 和 MQTT 的 PLC 设备，但仍然需要为它们支付一定费用。还有一些支持协议转换的网关，不过通常它们的价格也相对较高。你也可以购买一些商业驱动程序，并编写直接与工业硬件通信的软件，但我想上次我看到商业驱动程序的主要供应商，西门子 S7 设备在 Linux 节点上运行驱动程序的价格，大概是每个节点 5000 欧元，所以可以想象这个价格还在急剧上升，非常昂贵。
2017 年我启动 PLC4X 项目时，虽然已经存在一些开源驱动程序，但它们通常有一些许可证方面的问题。这些程序大多采用了 GPL 许可证，这使得在商业应用中使用它们变得困难。此外，很多驱动程序的代码写得很糟糕，从有些程序的代码中你甚至可以看出，开发者是如何不经任何结构上的修改，而将 C 代码直接转换成 Java 的，而且多数驱动程序在当时（2017 年）就已经没人维护了。
02 Apache PLC4X 介绍
为了解决这个问题，我有幸启动了一个新项目，那就是 Apache PLC4X。
PLC4X 是什么？我认为我们的项目描述是一个很好的介绍。PLC4X 是一组用一个共享 API 使用各类协议，与工业 PLC 通信的库。尤其是该描述的“共享 API”是 PLC4X 最与众不同的部分。因为在 PLC4X 出现之前，你需要为你使用的每个驱动程序都单独定义软件架构。而我们尝试构建类似于 JDBC 或 ODBC 的工具，其中你有一个共享 API，并且可以在各种不同的产品中使用。
PLC4X 的核心概念是，当你编写应用程序时，只需使用 API 模块来编写软件。该模块定义了所有用于通信的数据类型和数据结构。对于要支持的每个协议，都有一个驱动程序实现相应的逻辑，并完全负责将该协议的 PLC 数据类型映射为标准数据类型。还有一些集成模块可用于将 PLC4X 集成到其他项目中，如 NiFi、Camel、StreamPipes 等，以及许多其他可用的项目。
之所以称为 PLC4X 而不是 PLC4J 是有原因的，即我们不仅仅是专注于编写 Java 驱动程序，因为我们知道在自动化行业，Java 并不是主导语言。理解一个驱动程序通常是比较困难的，因此我们构建了一个代码生成框架，使我们能够根据我们编写好的模板，用任何我们选择的语言编写驱动程序。目前可用的语言包括 Java、Go 和 C，而社区正努力开发 C#、Python 甚至 Rust 版本的驱动程序。这样做的目标是编写独立于使用的 PLC 的软件。
PLC4X 支持哪些操作呢？首先，它支持发现功能。如果某些 PLC 或工业硬件、自动化硬件支持发现功能，我们的 Discover 模块肯定会捕捉到。一旦找到并连接到设备，你可能会想了解该设备提供了哪些数据，这就是 Browse API 的作用。现在你了解了设备上有哪些数据，可能会想要读取它，这可以通过 Read API 完成，或者你可能想用 Write API 进行写入。一些协议甚至支持订阅功能，因此你还可以订阅变量的变化情况，然后定期地或在变量变化时看到。
还有一个用扳手图标展示的 API，是我们目前正在努力开发的 Publish API。这通常用于 Fieldbus 协议，如 ProfiNet 或 EtherCAT，这些协议中的应用程序也会在一定的时间间隔上报值。不过这个 API 功能仍然正在开发中。
我提到 PLC4X 基于一些概念进行构建，其中之一就是协议，它通常涵盖并实现协议的一般逻辑。它不处理传输，因为我们有单独的传输的概念，但是协议本身处理序列化、反序列化、给定协议的模型类型等事务。它处理协议状态，如何编写标签地址或字段地址，还负责将使用 PLC 的数据类型映射为 PLC4X 的标准数据类型。
对于不熟悉工业协议的人来说，这些协议的复杂度非常不一样。例如 Modbus 协议，通常在为新语言实现驱动程序时，我们会首先使用它，因为它非常简单。
为了让大家对工业协议的复杂性有一点了解，这里有一个简单的示例，展示了 Beckhoff ADS 协议的连接状态图。在黄色部分的一侧，表示连接建立的过程。你可以看到有许多状态和条件，决定了控制流的不同走向。这里面还有，比如红色代表读取，橙色代表写入，还有用于浏览、订阅等等的流程，可以看到这相当复杂。过去，通常你需要在程序中自己处理这种复杂的流程，但 PLC4X 完全替你处理了这一切。你只需要告诉它，比如“我想读取这个变量”，PLC4X 就会处理所有这个请求需要的复杂路径。
截至目前，我们已经支持了哪些协议呢？西门子 S7 协议绝对是第一个。Beckhoff ADS 也已经支持。Modbus 我们支持 TCP 和 Serial 两种方式，即 Modbus/TCP、Modbus/ASCII 和 Modbus/RTU。我们支持 EtherNet/IP，其中还包括 Logix 变体，它增加了一些仅在 Allen-Bradley 设备上可用的附加功能。此外，我们还支持在我们自己的驱动上实现 OPC-UA。我们正在努力开发 BacNet。KnxNet/IP 的支持已经相当稳定。Firmata 是一种在 Arduino 等设备上使用的非常简单的协议，我们也已支持。我们支持了 CAN 协议。你们有些人可能已经知道，去年或今年，我迅速实现了用于燃气轮机的 IEC-60870 协议的支持。目前我正在开发支持 ProfiNet。我的一位同事正在开发支持 C-Bus。Atlas Copco 集团的 Open-Protocol，过去称为 Torque-Tools，是一种用于汽车制造业的自动扳手的协议，我们也在开发中。我目前还在开发支持 Bosch Rexroth CtrlX 连接器。Emerson DeltaV 相对有点特殊，因为我已经没有可用的硬件继续开发，但实际上我们是第一批能够对 Emerson DeltaV 协议进行逆向工程的人。我还有一个协议在计划开发中，而且我真的希望随着最近的改变能够尽快实现，那就是新的西门子 S7 协议，但可能还需要几个月的时间，我才能开始着手处理。
03 PLC4X 与 IoTDB 集成愿景
正如我之前提到的，我对如何将 PLC4X 和 IoTDB 结合使用，以真正在工业领域产生影响有许多构想。
我对于 PLC4X 和 IoTDB 的愿景是构建一个使用 PLC4X 的网关系统，可在边缘侧的小型计算机甚至 PLC 本身上运行。这个网关系统使用 PLC4X 与设备进行通信，并以 Sparkplug B 格式生成数据。Sparkplug B 可能有些人听说过，但它是一个相对较新的协议，在其官网上表示旨在为工业自动化提供即插即用的功能，它实现的效果与 OPC-UA 希望通过配套规范实现的效果有些类似。通过 Sparkplug B，我们不仅可以发送数据，还可以发送数据的结构图。而这个网关系统与 IoTDB 之间的通信应该完全基于 MQTT，这也是 Sparkplug B 数据支持传输的方式。在 IoTDB 中，我们将使用一个新的 Sparkplug B 适配器，能够消费 Sparkplug B 数据，并将其直接写入到 IoTDB 中。
下面是这个架构的示意图。你可以看到，有一些设备可以支持 Sparkplug B 协议，并且这样的设备会越来越多。如果你拥有这类设备，它的数据将发送到 MQTT 代理，而 IoTDB 的 Sparkplug B 适配器将直接消费这些消息。如果你有一些传统的硬件，那么你可以使用 Apache PLC4X 边缘网关与这些设备的协议进行通信，并通过 MQTT 发送 Sparkplug B 消息。然后，这些消息将被 Sparkplug B 适配器消费并写入到 IoTDB 中。
那么想要实现这一架构，还需要哪些工作呢？为了实现这一目标，Apache IoTDB 需要能够连接到外部的 MQTT 代理。目前，如果我们想在 IoTDB 中使用 MQTT，我们会启用嵌入式的 MQTT 代理，但我认为这在设备大规模部署的场景下，可扩展性不够好。因此，我认为我们需要尽快做的一件事情是重构当前的 MQTT 适配器，不再使用嵌入式代理，而是构建一个 MQTT 代理客户端，并基于这些变化，为 IoTDB 实现一个 Sparkplug B 适配器。目前我们的 MQTT 适配器消费的是特殊格式的 JSON 消息，而 Sparkplug B 消费的是使用 Protobuf 编码的二进制有效载荷，因此如果想要实现 Sparkplug B 通信，需要构建一个完全不同的组件。
接下来的问题是，需要对 Apache PLC4X 的功能进行哪些调整或扩展？一方面，就像我前面提到的，PLC4X 支持订阅功能，但目前我们只在那些支持订阅的协议上实现了订阅功能，有 Beckhoff ADS、ProfiNet、KnxNet、BacNet 协议，基本上就是这些了。不过我们一直计划在不支持订阅的驱动程序上实现模拟订阅功能。例如在 Modbus 协议中，我们希望在后台轮询某个值，并根据订阅的设置，只有在这个值改变时才触发一个事件。
另外一点是，PLC4X 中广泛使用的是一个我们称之为 “scraper” 的模块。你可以将其视为一个调度程序，负责在给定链路上，以给定时间间隔，处理多类数据收集任务。这个模块还需要做很多更新，以支持订阅甚至是混合任务。所以我认为我们非常需要的是让 PLC4X 能够通过基于订阅的触发器进行轮询，对一组变量进行实时读取。这种功能当前是不支持的，也是绝对需要解决的问题。
最后一方面是，如果为了实现这个构想中的边缘网关系统，我在 IoTDB 上搭建了一个 Sparkplug B 的消费端，那么我将需要实现一个 Sparkplug B 的发送端。不过这应该是一个比较简单的任务，因为已经有一个 Eclipse 项目提供了实现这个发送端所有必要的基础设施。
通过这些改变，我认为 IoTDB 有望成为工业自动化系统的核心数据枢纽。我们可以利用它来实现在工业自动化领域被称为“统一命名空间”的架构。统一命名空间是一个可以获取有关设备信息的单独层级。它替代了当前逐级向上，每个应用程序都需要单独向工业硬件请求相同信息的等级架构。统一命名空间实现后，这些应用程序将不再直接连接到工业硬件，而是连接到我们的系统，并方便地通过 IoTDB 查询当前信息与数据。
一旦我们实现了这一点，我认为 IoTDB 也可以成为未来构建定制化 MES 系统的真正核心。因为实际上，目前市场上的 MES 系统都不具备高扩展性，至少我不知道有哪一个系统能够跨多个节点进行扩展。它们都是单节点系统，所以通常用户在工厂中的应用效果会受到能够购买的服务器的限制，这并不理想。我过去曾看到，如果用户尝试将 IoT 或 IT 概念应用于工业自动化领域，例如微服务或只是写入服务，应用效果都比现有的 MES 系统要好很多。这就是为什么我非常希望我们能够在未来针对这一方面做出改变。
希望我的分享能为你们提供一些有趣的概念和想法。感谢聆听我的报告，期待下次能够与大家见面，祝各位收获愉快的参会体验。
更多内容推荐：
• 回顾 IoTDB 2023 大会全内容
