2. 制造时序数据采集链路的高可用设计
制造现场的数据采集链路，本质上是一条从设备信号到平台存储的“长链路”：PLC、CNC、机器人、传感器等设备产生原始信号，边缘网关完成协议解析与本地缓存，再经网络上传至时序平台。这条链路上任何一环失效，都会造成数据缺失。高可用设计的目标不是让每个环节永不故障，而是让故障发生时数据不丢、链路可恢复、缺口可补齐。本节围绕设备接入、边缘网关冗余、协议转换容错、断点续传与数据补采四个关键环节展开。
设备接入：先解决“连得上、读得稳”
设备接入层的高可用，核心是连接管理与采集周期控制。以一台西门子 S7-1200 PLC 为例，边缘网关通过 S7 协议周期性读取 DB 块中的生产计数与状态字。若采用单连接、单线程轮询，一旦网络抖动导致连接断开，采集就会中断。更稳妥的做法是：为每个设备维护独立连接会话，设置连接超时（如 3s）与重连退避（首次 1s、二次 2s、上限 30s），并将采集任务与连接生命周期解耦——连接断开时任务进入等待队列，重连成功后自动恢复，而不是让整个采集进程退出。
采集周期也需要区分优先级。高频信号（如振动、电流）周期可设为 100ms～500ms，低频状态量（如设备运行状态、报警字）可设为 1s～5s。若所有点位统一按 100ms 采集，网关 CPU 与网络带宽会被迅速耗尽，反而降低整体稳定性。一个可参考的示例参数是：单网关接入 30 台设备、总点位 3000 个，按“高频 500ms、中频 1s、低频 5s”三档分组，实测（示例估算）CPU 占用可控制在 40% 以内，为突发补采留出余量。
边缘网关冗余：主备切换与数据不丢
边缘网关是采集链路中最容易成为单点故障的环节。冗余设计通常有两种形态：主备热冗余与双活采集。主备模式下，主网关正常采集并上传，备网关通过心跳（如每 1s 一次）监测主网关状态；主网关失联超过 3 个心跳周期，备网关接管采集任务。关键在于“接管后从哪里继续”——备网关必须持有主网关最近的数据位点（如最后成功上传的时间戳或序列号），否则会出现重复上传或数据空洞。
双活模式则让两台网关同时采集同一批设备，但只由主网关上传，备网关本地缓存。这种方式切换更快，但要求设备支持多客户端连接，且需要去重机制。对于不支持多连接的 PLC，主备热冗余更现实。无论哪种模式，网关本地都应使用持久化队列（如 SQLite 或嵌入式消息队列）缓存未确认上传的数据，队列满时按“先丢最旧、保最新”或“阻塞采集”策略处理，具体取决于业务对实时性与完整性的权衡。
协议转换容错：解析失败不能拖垮整条链路
制造现场协议种类繁多，Modbus、OPC UA、Profinet、MQTT、私有 TCP 协议并存。协议转换层最常见的故障是“单点解析异常导致采集线程阻塞”。例如某台设备返回的报文长度与预期不符，若解析函数直接抛出异常且未被捕获，整个采集任务可能中断。容错设计应做到三点：一是解析函数必须捕获异常并返回“无效值”而非崩溃；二是对连续解析失败的设备进行隔离，如连续 5 次失败后暂停该设备采集 30s，避免无效重试占用资源；三是保留原始报文快照，便于事后定位是设备侧问题还是解析规则问题。
另一个容易被忽视的问题是字节序与数据类型映射。不同 PLC 对 32 位整数的字节序可能不同（大端/小端），若网关配置错误，解析出的数值会完全失真。建议在协议模板中显式声明字节序、寄存器偏移、数据类型（INT16/UINT32/FLOAT32），并在上线前用已知值做校验。例如向 PLC 写入 12345，网关读取后应得到 12345，若得到 14640 则说明字节序配置反了。
断点续传与数据补采：把缺口补回来
断点续传解决的是“上传中断后从哪继续”的问题。网关本地队列中的每条数据都应携带单调递增的序列号或采集时间戳，平台按序列号确认（ACK）。网关收到 ACK 后才删除本地数据；未收到 ACK 的数据在重连后重新上传。平台侧需要按“设备 ID + 时间戳 + 序列号”做幂等去重，避免重复写入。
数据补采则针对已经确认丢失的时间窗口。常见触发方式有三种：平台定时扫描发现某设备在 [T1, T2] 区间无数据，向网关下发补采指令；网关在重连后主动上报本地缓存中未上传的数据；人工在平台界面指定设备与时间范围发起补采。补采时要注意：若设备本身不支持历史数据读取（如部分老式 PLC 只有当前值寄存器），则只能补采网关本地缓存过的数据，无法补采设备侧未缓存的数据。因此，网关本地队列的保留时长（如 7 天）直接决定了可补采的最大窗口。
链路健康度判断与恢复验证
高可用设计是否生效，不能只看“有没有报警”，而要看数据完整性指标。建议关注三个指标：采集成功率（成功采集点数 / 应采集点数）、上传延迟（数据产生到平台可查的时间差）、补采覆盖率（补采成功点数 / 缺口点数）。以 1 小时为统计窗口，若采集成功率低于 99.5%、上传延迟 P95 超过 10s、补采覆盖率低于 98%，则说明链路存在需要处理的薄弱环节。
恢复验证可以按以下顺序进行：先断开主网关网络，观察备网关是否在 3～5s 内接管并开始上传；再恢复主网关，确认其重新加入后不会造成重复数据；最后人为制造一段 10 分钟的数据缺口，触发补采任务，检查平台中该时间窗口的数据是否被完整回补且无重复。只有这三步都通过，才能认为该采集链路具备可接受的高可用能力。