📚 课程目录第3章工业现场数据采集与协议适配

3. 工业现场数据采集与协议适配

工业边缘计算平台的第一道门槛不是算力，而是“能不能把现场设备的数据稳定、低时延、语义一致地拿进来”。本节围绕四类典型工业协议——Modbus、OPC UA、Profinet、EtherCAT——说明它们在 Intel Edge Insights for Industrial（EII）中的接入位置、采集机制，以及多源异构数据归一化的落地方法。

一、四类协议的接入定位与采集方式

这四种协议在工业现场处于不同层级，接入方式差异很大，不能一概而论。

Modbus（RTU/TCP）属于典型的轮询式主从协议。边缘侧通常以 Modbus TCP 客户端身份，按寄存器地址周期读取。例如读取一台电表的保持寄存器：从站地址 1、功能码 03、起始地址 40001、数量 10，轮询周期 500 ms。Modbus 只给“地址+数值”，没有语义，必须靠外部点表把 40001 映射为“A 相电压”，并声明数据类型（uint16、int32、float32）与字节序（大端/小端、字交换）。这是后续归一化最容易出错的地方。

OPC UA是面向信息模型的协议，天然带语义。接入时边缘侧作为 OPC UA Client，通过 Endpoint（如 opc.tcp://192.168.1.20:4840）建立会话，浏览 AddressSpace 得到 NodeId，再以 Subscription + MonitoredItem 方式订阅。关键参数是 PublishingInterval（如 200 ms）和 SamplingInterval（如 100 ms），并可按需启用 Deadband 抑制冗余上报。相比 Modbus，OPC UA 直接给出节点路径、数据类型和质量码（StatusCode），归一化负担小很多。

Profinet是实时以太网现场总线，通常由 PLC 作为控制器。边缘平台一般不直接做 Profinet 控制器，而是通过两种方式获取数据：一是经 PLC 侧开放接口（如 OPC UA 服务器、S7 通信）间接读取；二是通过支持 Profinet 的采集网关或抓包/镜像方式获取过程数据。其数据以 IO 数据（输入/输出字节区）形式存在，需要按 GSDML 描述的模块结构解析字节偏移。

EtherCAT是高性能实时总线，周期可达 100 μs～1 ms，从站通过 ESC 处理过程数据。边缘侧接入通常依赖 EtherCAT 主站（如 IgH EtherCAT Master、SOEM）或专用采集卡，读取过程数据映像（Process Data Image）中的 PDO 映射。由于周期极短，边缘采集往往做“降采样+聚合”，例如每 10 ms 汇总一次再上传，避免把实时总线拖入通用计算路径。

二、Intel Edge Insights for Industrial 的数据采集机制

EII 的采集机制可以理解为“可插拔的 Ingest 层 + 统一消息总线”。它并不要求所有协议都走同一条路径，而是通过不同 Ingest 模块把数据汇入统一出口。

对于 Modbus，EII 侧通常使用基于轮询的采集插件，按点表配置从站、功能码、地址、数据类型和周期，采集结果以消息形式发布。对于 OPC UA，EII 提供 OPC UA 采集模块，配置 Endpoint、安全策略、订阅节点列表，节点值变化或周期上报时进入总线。对于 Profinet/EtherCAT，EII 更多依赖网关或主站程序先把过程数据转成 MQTT/OPC UA/共享内存，再由 EII 的对应 Ingest 接入。

EII 的关键设计在于：采集与消费解耦。采集模块只负责“拿到原始值+时间戳+质量”，通过消息总线（如 MQTT、ZeroMQ 或内部总线）发布；归一化、存储、推理、可视化作为独立消费者订阅。这样新增一种协议只需增加一个 Ingest 模块，不影响下游。

三、多源异构数据归一化实战

归一化的目标不是“把数据变好看”，而是让不同协议、不同设备、不同量纲的数据在同一语义模型下可比较、可计算、可存储。下面以一个具体示例说明。

假设现场有三台设备：一台 Modbus 电表、一台 OPC UA 温控器、一台 EtherCAT 伺服。我们要统一采集“电压”“温度”“转速”三个指标。

第一步：建立统一测点模型。每个测点至少包含：设备 ID、测点 ID、指标名、单位、数据类型、采集源、原始地址/NodeId、缩放系数、偏移量、质量码规则。例如：

device_id: meter_01
point_id: voltage_a
metric: voltage
unit: V
source: modbus_tcp
raw_addr: 40001
data_type: uint16
scale: 0.1
offset: 0
quality_rule: status==0 ? Good : Bad

第二步：原始值到工程值换算。Modbus 读到 40001 = 2296，scale=0.1，则工程值 = 2296 × 0.1 = 229.6 V。OPC UA 温度节点直接返回 68.5（float，单位 ℃），无需换算，但需确认单位与目标单位一致。EtherCAT 伺服转速 PDO 为 int32，单位 0.001 r/min，读到 1500000，则转速 = 1500000 × 0.001 = 1500 r/min。

第三步：时间戳与质量码统一。所有数据统一打 UTC 毫秒时间戳，质量码统一映射为 Good / Bad / Uncertain。Modbus 通信超时标记 Bad；OPC UA StatusCode 为 Good 则 Good，Uncertain 则 Uncertain；EtherCAT 主站工作状态异常时标记 Bad。

第四步：统一输出格式。归一化后每条消息形如：

{
  "ts": 1710000000123,
  "device_id": "meter_01",
  "point_id": "voltage_a",
  "metric": "voltage",
  "value": 229.6,
  "unit": "V",
  "quality": "Good",
  "source": "modbus_tcp"
}

这样，无论数据来自 Modbus、OPC UA 还是 EtherCAT，下游时序库、推理服务和可视化都只面对同一种结构。

归一化最容易踩的坑有三个：一是字节序和字交换（Modbus 的 float32 常出现高低字颠倒）；二是量纲不一致（有的设备给 0.1 V，有的给 mV）；三是质量码缺失，导致坏值被当成正常值参与计算。建议在点表中显式声明这三项，并在归一化层做校验。

四、接入与归一化的检查要点

协议侧：Modbus 确认从站地址、功能码、寄存器地址、数据类型、字节序；OPC UA 确认 Endpoint、安全策略、NodeId、订阅周期；Profinet 确认 GSDML 与 IO 字节偏移；EtherCAT 确认 PDO 映射与主站周期。
采集侧：确认轮询/订阅周期与现场实时性匹配，避免过密轮询拖垮设备，也避免过疏丢失变化。
归一化侧：确认单位、缩放、偏移、时间戳、质量码五项一致，并保留原始值以便追溯。
验证侧：用已知标准源或手持表比对工程值，检查坏值是否被正确标记，检查时间戳是否单调、是否与采集时刻一致。

把协议接入和归一化做扎实，后续的边缘推理、时序分析和云端协同才有可靠的数据基础。否则再强的算力，也会被“地址对不上、单位不一致、坏值混入”这类问题拖住。