工厂数据提取

真实的工厂现场是一个大杂烩。来自不同厂商、不同年代、采用不同协议的控制器并排而立——一个橇装设备上是西门子 S7，旁边一台是 Allen-Bradley PLC，变电所里有 Modbus 电能表和变频器，包装线上是 IO-Link 传感器，车间里有 CNC 机床，楼宇的暖通空调则由 BACnet 控制器运行。它们几乎都不是为了与其他任何设备共享数据而设计的。

工厂数据提取的任务，就是把所有这些设备上可信的、带名称、带时间戳的测量值采集到一处——无需重新布线、更换控制器或重写 PLC 程序。在实践中，这意味着用每台设备的原生协议进行通信，将原始寄存器和标签转换为带单位的、有名称的工程量值，附加一个质量信号以便你知道某个读数是否可信，并在边缘端可靠地完成这一切，哪怕网络中断也不例外。

IronFlock 通过一系列轻量级、部署在边缘端的采集应用来解决这个问题——每个协议族对应一个应用。每个应用都作为普通的 Docker 容器运行在任何 Linux 网关上，尽可能自动发现设备，将原始地址规范化为带名称的值，在中断期间进行缓冲，并将所有数据流式传输到你项目的时序数据库中。每个采集器都完全在浏览器中配置，并附带演示模式，因此你可以在连接任何硬件之前就评估完整的使用体验。

棕地现实

没有任何一种协议能覆盖整个工厂。实际要问的问题始终是*“哪个采集器能读取我的设备？”*下表将你可能遇到的设备映射到处理它的采集器。

Modbus 和 OPC UA 现已可用，IO-Link、MTConnect 和 BACnet 也是如此。Industrial Collector 的西门子 S7（S7comm）和 Allen-Bradley（EtherNet/IP）驱动由 Apache PLC4X 引擎提供支持，目前正在跨设备进行验证——S7-1200/1500 控制器如今已可通过其内置的 OPC UA 服务器读取。

IronFlock 采集器共通的方法

无论你采集哪种协议，所有五个应用在底层的工作方式都相同。它们写入相同的项目级数据库表（gateways、assets、datapoints、measurements、assetstatus），在本地缓冲读数，并在与平台的上行链路恢复时按顺序转发，将每台设备相互隔离，使一台无法访问的机器永远不会拖累其他机器，并且在浏览器中实时配置，无需配置文件或重启。无论 IronFlock 以哪种方式部署——托管云、私有云或完全离线的本地一体机——这一点都成立。下面的每个页面都会重复这些共通特性，以便各自独立成篇。

已知限制

某些老旧设备目前还没有直接的接入途径。老旧的 Allen-Bradley MicroLogix / SLC（基于 DF1 的 PCCC）、没有空余以太网口的纯 Profibus 单元、仅从工厂 DCS 操作的成套设备，以及完全没有数字控制器的设备（仅硬接线）需要网关、协议桥接或传感器改造。如果你不确定你的设备是否被覆盖，请与我们联系——如果设备支持 Modbus 或 OPC UA，那么它几乎肯定现在就能工作，新的驱动和配置包会按需添加。

各个采集器

• Industrial Collector — 一个应用覆盖整个现场：西门子 S7、Allen-Bradley、Modbus 和 OPC UA 并排运行，并配有预映射设备配置文件的目录。
• IO-Link Collector — IO-Link 主站和智能传感器，支持自动发现，并通过 HTTP、OPC UA 或 MQTT 自动进行 IODD 解码。
• Modbus Collector — 读取庞大的 Modbus 电表、变频器和控制器装机量的最轻量方式。
• MTConnect Collector — 通过开放的 MTConnect 标准接入 CNC 机床和车间设备，支持零配置发现。
• BACnet Collector — 通过 BACnet/IP 接入楼宇自动化、暖通空调和能源系统，支持自动网络和测点发现。

数据的去向

每个采集器都将其读数存储在你项目的私有时序数据库中，在那里这些数据立即可供平台的其余部分使用：通过 Data Backend 进行查询和建模，在 IoT 仪表盘和 SCADA 面板中实时可视化，并使用 Alarms 应用进行监视以获取短信/邮件通知。要让设备上线并安装这些应用，请参阅设备管理和应用管理。

从采集到洞察：一种典型的实施模式

提取是基础，而不是目的。没有人真正想要寄存器和标签——工厂想要的是 OEE 数字、主轴故障前的早期预警、单件能耗，以及一份自动生成的班次报告。因此，典型的 IronFlock 部署由两个保持清晰分离的层组成：

第 1 层——采集。 在设备旁边的网关上安装与你的设备匹配的采集应用，并在浏览器中映射你的机器。从这一刻起，带名称、带时间戳、带质量标记的测量值就会持续累积到你项目的标准化数据库中——每个项目得到的都是同一个数据库，因此采集器无论安装在哪里，行为都完全一致，而项目所有者则获得一个可以集中检查所有采集数据的入口。在这个数据库内部，每个应用的数据都位于自己隔离的 schema 中：一份不断增长、完全属于你的资产，默认按应用私有。

第 2 层——消费。 安装（或构建）将这些测量值转化为决策的应用，并让它们通过跨应用数据访问读取采集器的数据：

• 现成的 OEE 仪表盘应用消费机器状态和产量计数器，按产线交付可用率、性能和质量——实时呈现在墙上，无需任何一次集成会议。
• 预测性维护应用基于采集器已经收集的数月振动、电流和温度历史进行训练，然后对实时数据流进行评分，标记出已经开始漂移的轴承。
• 能源分析将 Modbus 电表的能耗与机器的产量计数器关联起来，报告单件能耗、空载损耗和峰值负荷风险。
• 报表和质量应用读取同样的表，自动填写班次日志、批次记录和审计跟踪。
• 一个 Node-RED 运行时（或任何通用工作台）声明它以单个通配符消费所有项目数据，然后在运行时发现可用的表——这样，工程师无需为每一个都编写集成，就能跨现场的每一个采集器和分析应用编排流程。

每个消费方应用都会声明它需要哪些采集器数据——可以是一份具体的列表，也可以用 - app: "*" 表示全部——并且你通过一个开关按项目批准或撤销该访问——始终只读。由于每个 IronFlock 采集器写入的都是相同的表结构（gateways、assets、datapoints、measurements、assetstatus），针对一个采集器编写的消费方应用适用于所有采集器：OEE 仪表盘并不关心机器状态是通过 S7、Modbus、MTConnect 还是 IO-Link 到达的。

其结果是一个随你一起成长、而不是把你锁死的架构：先从一条产线上的一个采集器开始，准备好后再添加分析应用，独立替换或扩展任何一层——如果现成的应用不合适，就基于你已经在采集的数据构建你自己的消费方应用。