通信中断十分钟，设备应该自己做什么

■ 一、中断是常态，不是异常

现场设备与上位机的连接，中断十分钟很常见：网络抖动、交换机重启、运营商链路切换。设计时如果把"中断"当成异常事件，代码里就会到处是临时补丁；把它当成常态，才可能写出干净的状态机。

下面按"短断、中断、长断"三档，说清设备该做什么。

■ 二、短断（秒级）：重连要退避

立即重连是最差的做法：链路刚恢复就发起连接，往往再次失败，形成风暴。

正确做法是指数退避：1 秒、2 秒、4 秒、8 秒，上限 30 秒；连接成功后重置计数。同时记录重连次数与最近一次失败原因，便于事后判断是链路问题还是对端问题。

■ 三、中断（分钟级）：缓存与标记

这一档的核心是"数据不能丢，也不能被当成实时数据"。

· 数据进本地缓存，带序号与设备时间戳；
· 缓存写入要有落盘机制，不能只在内存；
· 每条数据打"未确认"标记，补传成功后清除；
· 缓存接近满时，覆盖最旧并记录溢出计数。

溢出计数很重要——它决定了这段时间的数据能不能用于统计。

■ 四、长断（小时级）：降级运行

链路长时间不通，设备要继续采集，但可以降级：降低上传频率、只保留特征值、暂停非关键诊断。

同时本地要有可见提示（指示灯或屏幕），让现场人员知道"设备在跑，只是没传上去"。很多"设备坏了"的投诉，其实是通信断了没人知道。

■ 五、恢复之后：顺序比速度重要

重连成功不等于问题解决。补传要按序号从小到大，逐段确认；上位机按序号去重；补传数据入库但标记为"历史"，不参与实时告警。

如果补传和实时数据同时涌入，最容易出现的是时序错乱——实时数据被历史数据"挤"到后面，报表看起来像时光倒流。

■ 六、看门狗与自恢复

通信任务要有独立看门狗：连续 N 次重连失败，重启通信模块；连续 M 次重启无效，整机软复位，并记录复位原因。

复位原因要能读出来，否则现场只能靠猜。

■ 七、一个检查清单

· 重连是否指数退避
· 缓存是否落盘、是否有序号
· 溢出是否有计数
· 长断是否有降级策略与本地提示
· 补传是否按序号、是否去重
· 补传数据是否标记为历史、是否排除在实时告警外
· 通信任务是否有看门狗与复位原因记录

■ 八、最后一句

通信中断考验的不是"能不能连上"，而是"断开这段时间，设备有没有把事情记清楚"。记清楚了，恢复就只是补一次数据；没记清楚，恢复才是麻烦的开始。