内容概览
先给结论
先查链路哪一段：断网恢复后历史数据丢失时，先查终端缓存是否溢出，再查补传策略；缓存容量按最长断网天数设计，溢出后旧数据被覆盖。
下表汇总本页覆盖的典型故障现象、可能原因数量与排查步骤数量，便于按优先级快速定位。排查顺序遵循"先现场机械/电气，后通信/平台"的通用原则。
| 故障现象 | 可能原因数 | 排查步骤数 | 优先级 |
|---|---|---|---|
| 断网超过 N 天后，历史数据被覆盖丢失 | 4 | 5 | 高 |
| 补传数据时间戳乱序 | 4 | 5 | 中 |
| 补传数据重复入库 | 3 | 5 | 中 |
症状、原因与排查步骤
断网超过 N 天后，历史数据被覆盖丢失
可能原因
- 终端缓存容量不足
- 补传策略设为"缓存满覆盖"
- 断网时间超过设计最长天数
- 缓存损坏
排查步骤
- 第 1 步：查终端缓存容量，按日条数×最长断网天数×1.5 倍余量设计
- 第 2 步：核对补传策略，重要数据应设为"缓存满停止写入"而非覆盖
- 第 3 步：断网超过设计天数时现场导出数据
- 第 4 步：缓存损坏则更换终端
- 第 5 步：重要站点双通信链路
处置清单
- 更换件/备件：大缓存终端
- 记录项：缓存容量、断网天数、丢失时段
- 预防措施：缓存按最长断网 7 天设计，留 1.5 倍余量
补传数据时间戳乱序
可能原因
- 终端补传按倒序发送
- 平台未按时间戳排序入库
- 终端时钟在断网期间复位
- 多终端共用一个平台设备号
排查步骤
- 第 1 步：要求终端补传按时间正序、单包条数≤20 条发送
- 第 2 步：平台按时间戳去重入库
- 第 3 步：核对终端 RTC 时钟，断网期间应仍走时
- 第 4 步：每个终端有独立平台设备号
- 第 5 步：历史乱序数据人工清洗
处置清单
- 更换件/备件：RTC 电池
- 记录项：乱序时段、时间戳偏差
- 预防措施：终端上电自动对时，RTC 电池每年更换
补传数据重复入库
可能原因
- 终端重试未去重
- 平台实时与补传通道未做时间戳去重
- 终端补传标志位未置位
排查步骤
- 第 1 步：平台按时间戳去重入库
- 第 2 步：终端每条数据带唯一序号
- 第 3 步：补传成功后终端清除缓存记录
- 第 4 步：历史重复数据人工清洗
- 第 5 步：设置重试次数（典型 3 次）
处置清单
- 更换件/备件：无
- 记录项：重复条数、去重规则
- 预防措施：上线前做断网恢复补传演练
常见问题
终端缓存能存多久？
按 1 分钟一条算，1MB Flash 约存 17 小时；实际应按最长断网天数×日条数×1.5 倍余量设计。
缓存溢出后能恢复吗？
不能；溢出后旧数据被覆盖，只能现场导出或从其他备份恢复。
补传数据会触发告警吗？
应标记为"补传入库"，不参与实时告警阈值判断，避免断网恢复后批量误告警。
内容边界与下一步
本手册排查建议为通用工程参考，具体故障以设备说明书与厂商支持为准；涉及电气开盖、登高、带电、开盖测量等安全事项，须由持证专业人员操作。
