“数采仪上显示连接成功，平台那边一条数据都没有，补传也点了，还是空的。”这是运维工程师在华东某化工园区现场发来的一句话。结论先说：连接成功只说明TCP链路和2011心跳正常，不代表补传链路通。数采仪数据补传失败，最常见的原因不是设备断网，而是平台下发的1014历史数据请求没有真正落到设备，或者设备本地缓存与时钟条件不满足，导致1013补传报文发出去也被平台丢弃。
一、先分清“连接成功”和“补传成功”是两件事
HJ 212协议里，现场机和平台之间至少跑三类报文：2011心跳维持链路，1000段实时数据按周期上传，1013负责历史数据补传。平台发起补传时下发1014，携带起始时间和结束时间。设备收到1014后，从本地存储里按DataTime检索，打包成1013报文回传。三步里任何一步断了，平台都表现为“没数据”。
二、按四层拆原因
协议层：1014报文里的QN、MN、PW与设备注册信息不一致；Flag数据标志位没有带历史数据标志；CP字段里DataTime格式不是yyyyMMddHHmmss；一次补传条数超过平台单包上限，CRC校验失败被整包丢弃。
网络层：TCP长连接被NAT老化断开，心跳间隔大于运营商保活时间；设备侧4G信号强度够但上行丢包；防火墙对2000–2999交互端口有限制。
设备层：本地存储只保留最近若干天，请求区间超出缓存；设备时钟与平台偏差超过平台容差；MN烧录错误，一台设备用了两个编号；断电重启后缓存索引损坏。
平台层：补传数据入库时按“数据时间+MN”去重，实时数据已占位导致补传被覆盖；平台对补传区间有最大跨度限制；3020类参数设置命令未回执，平台认为设备不在线。
三、排查顺序：先看命令到没到，再看设备有没有，最后看平台收不收
顺序本身就是知识。先抓1014，是因为补传是“平台要、设备给”的问答模式，请求没到设备，后面查缓存和网络都是白费。确认1014到了设备，再核对设备时钟和本地缓存条数，这两项决定设备“有没有东西可补”。最后才看1013回传后的CRC和平台入库规则，这一步决定“发出去的数据算不算数”。反过来先重启设备、先换卡，往往把现场状态破坏掉，问题更难复现。
四、每一步的判断标准和处置动作
- 现象：平台补传记录里有1014下发，设备日志无对应QN。判断：请求没到设备，查网络层和平台侧MN路由。动作：在设备侧抓包，确认TCP连接四元组和1014报文长度。
- 现象：1014到了，设备回1013但条数为零。判断：本地缓存区间不覆盖请求时间段。动作：查存储天数与DataTime索引，必要时先补最近时段再补历史时段。
- 现象：1013有报文，平台入库为零。判断：CRC或Flag字段不被接受。动作：核对数据段长度四位、CRC四位十六进制，检查Flag是否带历史标志。
- 现象：补传一部分成功、一部分丢失。判断：单包条数超限或网络抖动。动作：把补传区间拆小，先按小时再按天，观察丢包是否跟随包长变化。
五、三个容易误判的坑
第一个坑，把心跳当数据。2011有回执就认为链路健康，实际上心跳包很小，能过不代表1013大包能过，MTU和分片问题常在这里。
第二个坑，只看设备时间不看平台时区。设备面板显示北京时间，报文DataTime却按UTC生成，平台按北京时间入库，数据落在八小时前，运维以为没补上。
第三个坑，一次补太多被平台限流，误判成设备不补传。把区间拆成小时段后能补上，就说明是包长或频率问题，不是设备存储问题。
六、FAQ
问：数采仪显示连接成功，平台就是没数据，是不是设备坏了？答：先别换设备。让平台重发一次1014，看设备日志有没有对应QN，没有就查链路和MN，有就查本地缓存和时钟。
问：平台点了补传，设备也回了命令，数据还是空的，咋回事？答：重点看1013的CRC和Flag，再看平台是否按“数据时间+MN”去重，实时数据占位会把补传覆盖掉。
问：我这个情况到底要不要传？停产的时段也要补吗？答：停产时段按平台要求上传对应状态标记，不要用零值顶替，具体区间以平台补传任务为准。
问：补传的数据和实时数据对不上，哪个算数？答：以平台入库规则为准，通常同一DataTime只保留一条，排查时先确认哪条先入库，再决定是否重补。
我们做PS-S01数采仪时，把1014接收、本地索引、1013分包和CRC校验都放在设备日志里，目的就是让运维先看清是哪一层断了，再动手。数采仪数据补传不是“点一下按钮”的事，命令、缓存、时钟、校验四件事对齐，平台才会有数。