4. 边缘层数据汇聚与实时处理

在工厂数据分层协同架构中，边缘层承担着“承上启下”的关键角色：向下要面对 PLC、CNC、机器人、传感器、仪表等异构设备产生的海量实时数据，向上要为平台层提供干净、对齐、可用的数据流。如果所有原始数据都直接上传云端，不仅带宽成本高，控制回路的时延也无法保证。因此，边缘层必须完成数据汇聚、缓存、流式处理、清洗与聚合，并在本地闭环完成低延迟协同控制。

一、边缘计算节点的部署形态

边缘计算节点通常部署在车间或产线侧，物理位置靠近数据源，常见形态包括：工控机加装实时网卡、嵌入式边缘网关、机架式边缘服务器，以及部署在产线控制柜内的紧凑型边缘一体机。部署时需重点考虑三类约束：一是网络接入，节点应同时具备工业以太网口（连接 PLC、机器人）和上行网络口（连接厂级网络或 5G CPE）；二是算力与实时性，若节点要参与协同控制，需评估 CPU 隔离、实时内核或硬件时间戳能力；三是环境与供电，车间侧节点需满足宽温、防尘、导轨安装和 24V DC 供电等要求。

一个典型的产线边缘节点可这样规划：节点通过 PROFINET 或 EtherCAT 采集 3 台 PLC 的周期数据，通过 OPC UA 订阅 CNC 状态，通过 Modbus TCP 轮询 8 台智能电表，同时用 MQTT 将聚合结果上传平台层。节点内部按功能划分为采集区、缓存区、流处理区和控制区，避免相互干扰。

二、数据汇聚与缓存策略

数据汇聚的核心问题是“多源、异构、不同频率”。PLC 周期数据可能每 10 ms 产生一次，电表每 1 s 轮询一次，视觉相机每帧几十毫秒。边缘节点需要统一时间基准，通常用 PTP（IEEE 1588）或 NTP 将各源时间戳对齐到同一时钟，再按事件时间进入流处理。缓存则解决“上游抖动、下游断连”的问题：本地可用环形缓冲区暂存最近 5～10 分钟原始数据，用轻量时序库（如 SQLite + 时间索引或本地 InfluxDB）保存聚合结果；当上行网络中断时，数据进入断网续传队列，恢复后按时间顺序补传，避免数据空洞。

缓存容量可按“数据速率 × 保留时长”估算。例如 200 个测点、平均每点 20 字节、采样周期 100 ms，则原始速率约为 200×20/0.1 = 40 KB/s，10 分钟约 24 MB，普通边缘节点完全可承受。若只缓存聚合结果，容量可再降低一个数量级。

三、流式处理框架与边缘侧清洗聚合

边缘流处理框架可选择轻量级方案，如 eKuiper、Flink 边缘版、Node-RED 加自定义算子，或直接在边缘服务中实现滑动窗口。关键概念是“事件时间 + 水位线”：以数据自带时间戳为准，允许少量乱序，当水位线超过窗口结束时间后触发计算。清洗规则通常包括：去除重复上报、对超量程值标记为无效、对短时缺失做线性插补、统一单位（如温度统一为 ℃、功率统一为 kW）。聚合则按业务需要选择均值、最大值、标准差、累计量等。

示例：1 秒滑动窗口聚合规则（伪代码）
输入流: plc.motor.current (A), 采样周期 100 ms
窗口: 滑动窗口, 长度 1 s, 步长 1 s
清洗: 丢弃 <0 或 >500 A 的值; 缺失超过 3 点则标记窗口无效
聚合: avg_current, max_current, std_current
输出: edge.motor.current.1s → MQTT 上传平台层

假设某电机电流在 1 s 内采集到 10 个点：12.1、12.3、12.2、12.4、12.3、12.5、12.4、12.3、12.2、12.4 A。清洗后全部有效，聚合得到 avg≈12.31 A、max=12.5 A、std≈0.12 A。若其中出现 620 A 的异常值，则被量程校验丢弃，不参与聚合，同时产生一条“电流越限”事件。

四、低延迟协同控制案例

以“两台机器人协同搬运 + 一台 PLC 控制输送线”为例。边缘节点以 20 ms 周期读取两台机器人的关节位置和 PLC 的输送线状态，在本地运行状态机：当输送线到位信号为 1 且机器人 A 处于抓取位、机器人 B 处于等待位时，边缘节点在 30 ms 内下发“同步启动”指令给两台机器人；若任一机器人位置偏差超过 2 mm，则立即暂停输送线并上报异常。整个判断与下发在边缘完成，不依赖云端，端到端延迟可控制在 50 ms 以内。平台层只接收聚合后的节拍、良率和异常事件，用于看板与优化。

五、可直接参考的边缘节点配置检查表

边缘层不是简单的“数据转发器”，而是把实时性要求高、数据量大、需要本地闭环的任务留在车间侧完成。部署时先明确节点位置与算力，再设计汇聚与缓存容量，随后用流处理框架完成清洗聚合，最后用低延迟协同控制案例验证闭环是否达标。这样既能减轻平台层压力，也能保证工厂关键控制回路的响应速度。