“数采仪显示连接成功，平台就是没数据。”华东某化工园区一位运维工程师反馈，现场 PS-S01 数采仪实时上报正常，但历史数据补传后平台仍缺数。先给结论：最常见原因不是网络断，而是补传报文里的时间戳、MN/设备编号与平台侧不一致，或补传命令码未按平台要求使用 1014、3020 对应区间，平台收到应答但数据不入库。先查平台补传日志和应答，再查网络。
原因分层：从协议到平台逐层看
协议层：补传命令码用错。实时上报常用 2011、2061 类命令，补传常用 1014 或 3020，部分平台要求 2000–2999 区间内按分钟数据打包；命令码与平台约定不一致时，平台可能返回确认但数据不入库。报文字段缺失也常见，QN、ST、CN、PW、MN、Flag、CP 中 DataTime 与 PolId 不对，或 CRC16/CRC32 校验方式与平台配置不一致，都会导致补传失败。包序号与总包数不匹配时，平台会丢弃半包。
网络层：补传走长连接，中间防火墙会话老化后，短连接重连未带原补传队列；4G 信号弱导致大包分片丢失，表现为实时正常、补传失败。设备层：补传缓存满、存储卡写保护、时钟偏差超过平台允许窗口，或设备重启后补传任务未恢复。平台层：补传接口与实时接口分开，补传地址、端口填错；平台按小时或日冻结，补传数据落在已锁定时段。
排查顺序：先平台后设备，先协议后网络
平台应答是唯一能证明“报文到没到、格式对不对”的证据；网络通只能说明 TCP 可达，不代表业务入库。建议顺序：一、看平台补传日志与应答；二、对数采仪补传队列和命令码；三、抓包看报文字段与校验；四、查网络链路；五、查设备存储与时钟。这个顺序本身就是数采仪数据补传排查中省时间的关键。
判断标准与处置动作
- 现象：平台显示连接成功但补传记录为 0。判断：补传命令码或补传地址不对。动作：核对平台文档，确认 1014 或 3020 及 2000–2999 区间用法，改补传地址和端口。
- 现象：平台有应答但数据缺失。判断：MN、DataTime、PolId 与平台档案不一致。动作：导出报文对照平台设备档案，修正字段后重排队列。
- 现象：补传小包成功、大包失败。判断：MTU 分片或缓存不足。动作：减小单包条数，检查存储余量。
- 现象：设备时钟与平台差几分钟。判断：DataTime 超出平台补传窗口。动作：校时，重排队列。
三个容易误判的坑
- 把“连接成功”当“补传成功”。TCP 连接成功只是链路层，平台入库要看补传应答和日志。
- 只查实时数据不查补传队列。实时正常会掩盖补传命令码错误。
- 反复重启设备。补传队列未落盘时重启会丢任务，先导出日志再操作。
FAQ
我这个情况到底要不要传？
要。只要平台有历史缺数，按当地要求补传；具体时段和频次以平台通知为准。这里说的是数采仪数据补传，不是实时上报。
补传和实时上报用同一个地址吗？
不一定。部分平台补传接口单独配置，地址、端口、命令码都可能不同，先看平台接入文档。
平台说收到了，为什么报表还是没有？
收到报文不等于入库。重点查 DataTime、MN、PolId 和平台冻结时段。
补传一直失败，重启数采仪有用吗？
先别重启。先看补传队列和平台应答，重启可能丢未落盘任务。