4. 实时数据流架构设计

实时看板的价值不在于“能显示数据”，而在于“显示的数据足够新、足够全、足够稳”。同样是设备状态看板，一条灌装线停机后 2 秒内看板变红，与 40 秒后才变红，对现场调度意味着完全不同的响应窗口。因此本节要解决的核心问题是：从设备层到看板展示，数据要经过哪几段链路、每段用什么方式采集与传输、在哪些节点做处理、刷新节奏如何确定，以及延迟和吞吐指标如何落到具体参数上。

一、四段式数据链路的职责划分

食品工厂的设备状态数据流通常可以划分为四段：设备层采集、边缘汇聚、服务端处理、看板推送。四段的分工必须清晰，否则容易出现“采集端做业务判断、看板端做数据清洗”的错位，导致链路难以维护。

设备层采集负责把物理信号变成结构化数据。食品设备常见的数据源有三类：PLC（西门子 S7、三菱 MC、欧姆龙 FINS 等）中的运行/故障/产量寄存器；仪表与传感器（温度、压力、液位、流量）的模拟量；以及部分新设备的 OPC UA 或 MQTT 原生接口。采集侧的关键决策是“采什么、多久采一次”。对于状态量（运行、待机、故障、清洗中），建议采用变化上报加心跳兜底；对于模拟量，按工艺需求设定采样周期，例如杀菌温度 1 s、冷库温度 30 s、电表功率 5 s。

边缘汇聚部署在车间侧网关或工控机上，承担协议转换、数据缓存和初步聚合。它的重要性在于隔离：当网络抖动或服务端升级时，边缘节点可以本地缓存 10～30 分钟数据，恢复后补传，避免看板出现数据空洞。边缘侧还适合做高频数据的降采样，例如把 100 ms 的振动信号聚合成 1 s 的均值与峰值再上传，显著降低上行带宽。

服务端处理负责数据校验、状态判定、指标计算与持久化。典型处理包括：用时间戳对齐多源数据、按停机原因码归类、计算 OEE 中的可用率与性能率、生成设备状态变更事件。这里要特别注意“状态判定放在服务端”这一原则——同一台设备的状态口径应唯一，若各采集端各自判断，看板与报表必然对不上。

看板推送负责把变化推给前端。推荐采用 WebSocket 或 SSE 长连接推送增量事件，而不是前端定时轮询全量接口。轮询在设备数量上百后会产生明显的数据库压力，且刷新周期与数据变化无关，既浪费又迟钝。

二、延迟预算：把“实时”拆成可验收的数字

“实时”必须量化。建议以端到端延迟为总指标，并拆成四段预算，逐段验收。以上图为例，一条合理的示例预算是：采集周期 1 s、边缘转发 0.5 s、服务端处理 1 s、推送与渲染 0.5 s，合计约 3 s。这个数字对状态看板足够，但对高速灌装机的故障捕捉可能偏慢，此时应把采集周期降到 200 ms，并让边缘侧直接上报状态变化事件，把总延迟压到 1 s 以内。

延迟预算的落地方式是给每段打时间戳：采集时间 t1、边缘发出时间 t2、服务端入库时间 t3、前端收到时间 t4。看板后台保留这四个字段，运维时即可定位瓶颈。例如发现 t2−t1 长期超过 2 s，说明网关负载过高或协议轮询过密；若 t4−t3 偏大，则多半是推送连接数过多或前端渲染阻塞。

三、吞吐估算：从设备数量反推链路容量

吞吐要求应由设备规模和数据点数量推算，而不是凭感觉设定。假设一个车间有 60 台设备，每台平均 20 个数据点，状态量按变化上报（估约每分钟 6 次），模拟量按 1 s 采样，则每秒消息量约为：60×20×1 ≈ 1200 条/秒（模拟量为主），加上状态事件约 120 条/秒，合计约 1300 条/秒。若每条消息 300 字节，上行带宽约 390 KB/s，即约 3 Mbps，普通工业以太网完全可承载。

真正的压力往往不在带宽，而在写入与查询。若每条消息都直接写主表，1200 条/秒在普通关系库上会迅速成为瓶颈。工程上常用两种做法：一是边缘侧先做 1 s 聚合，把 20 个点合并为一条设备快照再上传，消息量降为 60 条/秒；二是服务端采用“最新值表 + 历史表”分离，看板只读最新值表，历史数据批量落盘。前者适合点数多、变化快的场景，后者适合需要保留原始曲线的场景。

四、刷新策略：事件驱动与周期聚合并用

看板上不同信息的刷新节奏应当不同。设备状态色块、告警灯属于“变化即重要”的信息，采用事件驱动推送，状态一变立即下发；产量、OEE、温度曲线属于“趋势型”信息，采用 1～5 s 的周期聚合推送即可。若把趋势数据也做成事件驱动，前端会收到大量无意义更新，反而造成渲染卡顿。

一个可执行的配置示例如下（示例参数，需按现场调整）：

# 采集与上报配置示例
status_points:
  report_mode: on_change      # 状态量变化上报
  heartbeat_interval: 30s     # 心跳兜底，防止假在线
analog_points:
  sample_interval: 1s         # 模拟量采样
  edge_aggregate: 1s          # 边缘聚合成 1s 快照
transport:
  protocol: mqtt
  qos: 1
  buffer_offline: 30min       # 断网本地缓存时长
server:
  latest_table_ttl: 24h       # 最新值表保留
  history_batch: 500rows      # 历史批量写入
push:
  channel: websocket
  status_event: immediate
  metric_refresh: 3s

五、可靠性设计：断网、乱序与重复

实时链路必须假设“网络会断、消息会重、时间会乱”。断网时边缘节点缓存并补传，补传数据要带原始采集时间戳，服务端按时间戳去重与排序，避免看板出现“时间倒流”。消息重复在 QoS 1 下是常态，服务端应以“设备编码 + 数据点 + 采集时间戳”作为幂等键。此外，看板前端应显示数据新鲜度，例如“最后更新 2 秒前”，当超过阈值（如 30 s）时置灰并提示链路异常，而不是继续展示过期状态误导调度。

综上，实时数据流架构的设计顺序应是：先按业务确定端到端延迟目标，再据此分配四段预算；然后由设备规模推算吞吐，决定边缘聚合与存储分离策略；最后用事件驱动与周期聚合相结合的方式确定刷新节奏，并以时间戳、幂等键和新鲜度提示保证链路可观测、可恢复。