2. 食品SCADA系统架构与数据流

要设计一套可靠的断点续传机制，第一步不是写代码，而是把SCADA系统的分层结构和数据流向画清楚。断点续传不是一个孤立的功能模块，它横跨采集层、通信链路、监控层与历史数据库，只有明确"断点"可能发生在哪一层、"续传"由谁发起、数据最终落到哪里，才能判断哪些环节需要缓冲、哪些环节需要确认机制、哪些环节需要幂等去重。本节围绕食品工厂典型SCADA组成，梳理从现场仪表到监控画面的数据路径，并指出断点续传在架构中的准确位置。

典型食品SCADA的四层组成

食品工厂的SCADA系统通常可划分为现场设备层、数据采集层、监控层和数据应用层。现场设备层包括PLC、智能仪表、变频器、称重终端、温度/压力/液位变送器以及包装线上的喷码机、金属检测机等，它们通过Modbus RTU/TCP、Profibus、Profinet、OPC UA或模拟量信号对外提供过程数据。数据采集层由采集网关、边缘计算机或SCADA通信服务构成，负责按周期轮询或订阅现场数据，完成协议转换、量纲换算、质量戳标注和本地缓存。监控层是操作员站与SCADA服务器，承担画面组态、报警管理、趋势显示、配方下发和权限控制。数据应用层则包括历史数据库、批次报表、MES/ERP接口和能源管理分析等。

对断点续传而言，这四层的职责差异很大：现场设备层通常不具备长期缓存能力，PLC的保持寄存器容量有限；采集层是唯一适合做"断点数据暂存"的位置，因为它离数据源最近、又具备存储与重发能力；监控层负责接收确认与去重入库；应用层则消费补齐后的完整数据。因此，续传机制的设计重心应放在采集层与监控层之间的链路上。

从采集层到监控层的数据路径

以一条乳品灌装线为例，假设采集网关每500 ms读取一次灌装机PLC中的灌装温度、灌装压力和瞬时产量三个变量。一次完整的数据流转大致如下：网关按站号与寄存器地址发起Modbus TCP请求，PLC返回原始整型值；网关按组态的量程把原始值换算为工程值，例如原始值0～27648对应0～150 ℃，则原始值13824换算为75.0 ℃；随后网关为这条记录打上采集时间戳、设备编号、点位编号和一个单调递增的报文序号，形成一条结构化记录；记录先写入本地环形缓存，再通过上行链路发送给SCADA服务器；服务器校验通过后写入实时库与历史库，并回送确认序号；网关收到确认后推进发送游标，释放对应缓存。

这条路径上有三个关键点决定了断点续传的可行性。第一是序号：每条记录携带连续序号，接收端才能判断"缺了哪几条"，而不是只知道"数据变少了"。第二是本地缓存：链路中断期间，网关继续采集并写入缓存，缓存深度决定了可容忍的最长中断时间。若单条记录约120字节、缓存容量为200 MB，则理论上可缓存约170万条记录，按每500 ms三条计算，可覆盖约78小时的中断，实际工程中通常按4～8小时设计并留有余量。第三是确认机制：只有收到接收端确认，发送端才删除缓存，否则在超时后重发，从而保证"至少一次"送达。

断点续传在架构中的位置

断点续传的本质是"采集层与监控层之间的一条带确认的可靠传输通道"，它不改变现场设备与采集层之间的采集逻辑，也不改变监控层内部的组态与报警逻辑，而是插入在上行链路的两端：发送侧负责缓存、编号、重发；接收侧负责校验、去重、按序入库、回送确认。理解这一点非常重要，因为很多项目把续传逻辑错误地放到监控层服务器上实现，结果服务器一旦宕机，缓存随之丢失；也有项目把缓存放在PLC里，受限于寄存器容量，只能覆盖几分钟的数据。

在食品行业还有两个特殊约束需要考虑。其一是批次完整性：食品生产按批次组织，若某批次杀菌温度曲线中间缺失一段，该批次的质量追溯就不可信，因此续传不仅要"补上数据"，还要保证同一批次内时间戳连续、无跳变。其二是清洗与换产时段：CIP清洗期间部分仪表停用，数据本身可能为空，续传机制应能区分"设备停用导致的空值"与"链路中断导致的数据缺失"，前者正常入库为空，后者必须补齐，否则报表会把停机误判为断点。

一个可参考的续传记录结构

为了让上述机制可落地，采集层向上发送的记录可采用如下字段组织（示例为JSON示意，实际可用二进制或Protobuf以降低带宽）：

{
  "seq": 102457,              // 单调递增报文序号
  "device": "FILLER-01",      // 设备编号
  "tag": "FILL_TEMP",         // 点位编号
  "value": 75.0,              // 工程值
  "unit": "degC",             // 工程单位
  "ts": "2025-03-11T08:15:30.500+08:00",  // 采集时间戳
  "quality": "good",          // 数据质量：good/bad/stale
  "batch": "B20250311-03"     // 所属批次
}

接收端按device + tag + ts做幂等去重，按seq检测缺口并请求补传，按batch校验批次内时间连续性。这样，断点续传就从一句笼统的"断网后能补数据"，变成了架构上可定位、可配置、可验证的具体机制。