先把结论放前面：数采仪显示“连接成功”但平台查不到数据，八成不是网络断了，而是协议层对不上——最常见的是设备编号（MN）、污染物因子编码位数、QN/CN 字段格式或 CRC 校验方式与平台侧约定不一致。TCP 建链成功只说明链路通了，不代表报文能被平台解析入库。
客户的原话是怎么说的
“数采仪显示连接成功，平台就是没数据。”这是我们在华东某化工园区现场听到最多的一句。现场看指示灯正常、ping 得通、端口也开着，运维工程师第一反应往往是换卡、换网线，折腾半天问题还在。
数采仪上传异常处理，先分清是哪一层的问题
把上传链路拆成四层看，排查效率会高很多。数采仪上传异常处理的难点通常不在“会不会修”，而在“先修哪一段”。
协议层（出现频率最高）
- MN 设备编号与平台登记的编号不一致，报文发上去，平台认不出是哪台设备。
- 污染物因子编码位数写错，比如平台要 3 位、设备填了 2 位，或者多带了前缀。
- QN 请求编码的时间格式不对，或者 ST 系统编码、PW 访问密码字段没填。
- CRC 校验（多用 CRC16）算错，或者包尾 && 缺失，平台会直接丢包。
- 2011 版与 2017 版的字段划分不同，设备按旧版组包、平台按新版解析。
网络层
- 平台 IP 或端口填错，比如该连数据端口却填成了网页端口。
- 现场防火墙或专网白名单没放开，TCP 能建链但数据被中间设备重置。
- 心跳间隔太长，平台侧会话超时把连接踢掉，看着“连着”其实早断了。
设备层
- 数采仪与仪表之间的串口参数（波特率、校验位、停止位）不一致，采到的值一直是无效值或 0。
- 设备时间跑偏，上传数据的时间戳落在平台有效区间外，被当成异常数据过滤掉。
- 本地存储写满，历史补传启动不了。
平台层
- 平台侧因子表没配、量程没设，数据到了却入库失败。
- 平台正在做停机维护或升级，回包异常。
- 同一 MN 被两台设备同时占用，平台把后到的连接顶掉。
为什么顺序是先协议、再网络、后设备、最后平台
因为每一层的验证成本不一样。协议层只要抓一条报文就能判断，成本最低；平台层要协调对方技术人员，成本最高。反过来查，最容易出现“网线换了三根、平台打了五个电话，最后发现是编码少了一位”。
每一步看什么、怎么处置
- 第一步，看报文。抓一条上传报文，检查包头 ##、QN、ST、CN、MN、Flag、CP 和包尾 CRC、&& 是否齐全。判断标准：字段齐全、CRC 能通过自校验。动作：缺字段就回设备参数页，对照平台下发的对接文档逐项改。
- 第二步，看命令码。实时数据一般走 2000–2999 区间，分钟、小时数据走 2051、2061 一类，历史补传走 3020 一类；平台下发 1014 提取实时数据时，设备必须按约定回包。判断标准：平台下发 1014 后设备有回包，且 CN 与请求一致。动作：不一致就核对命令码映射表。
- 第三步，看心跳与重连。多数平台要求几十秒到几分钟一次心跳，连续超时几次就会断链。判断标准：日志里心跳有规律、无频繁重连。动作：缩短心跳间隔，检查中间设备的 NAT 超时。
- 第四步，看平台回执。平台收到报文后一般会回一条 QN 相同的确认包。判断标准：有对应 QN 的回执。动作：没回执就找平台侧查入库日志，以及设备编号是否重复。
三个容易误判的坑
- 坑一：把“TCP 连接成功”当成“数据上传成功”。建链只是链路层的事，协议层对不上，照样一条数据都进不了库。
- 坑二：只改设备不改平台。设备侧编号改了，平台侧没同步，等于白改，还会让人误以为设备没生效。
- 坑三：以为是网络卡顿，其实是时间戳。设备时间与平台差了几个小时，数据看着发出去了，实际被判为过期数据。
FAQ
“我这个情况到底要不要传？”
只要接入了监管平台、属于重点排污单位，就要按当地要求传，别自己判断“数据不好看就先不传”。
“连接成功，平台就是没数据，是不是数采仪坏了？”
大概率没坏。先抓一条报文看 CRC 和 MN，九成问题出在协议参数上。
“换了新平台，旧参数还能直接搬过去吗？”
不能。新旧平台的因子编码、命令码区间、心跳间隔都可能不一样，要按新平台下发的对接文档重配。
“补传的数据平台不认，怎么办？”
先确认补传走的是哪个命令码、时间戳格式对不对，再看平台侧有没有打开历史数据接收开关。