「数采仪屏幕上写着连接成功，非现场监管平台那边一条数据都没有。」这是华东一家印染厂运维工程师打来电话时的原话。设备面板上链路灯常亮、TCP 状态显示已连接，平台按排口一查，空白。
先给结论：这种情况九成不是网断了，而是会话没建起来，或者数据其实上去了但被平台判成无效。正确的顺序是——先让平台方按设备编号查有没有登录记录，再看数采仪发出去的连接报文，然后才动网络和现场。顺序反了，往往在现场折腾一整天，问题其实在平台的一张档案表里。
四层拆开看，故障落在哪一层
- 协议层。连接报文（命令编码 9011，平台应答 9012）里的 MN 设备唯一编号，和平台备案的对不上，平台收到直接丢包、不回应答，设备端就一直停在「已连接」；PW 访问密码改过没同步；QN 请求编码里的时间戳超前或滞后太多；报文缺 && 结束符、CRC 校验不过，同样是静默丢弃。
- 网络层。能 ping 通不等于能建会话。专网 APN 拿到的是内网地址，卡在 NAT 后面，会话表老化之后设备以为还连着；防火墙只放行出站，回包被挡；域名解析到了备用地址，而备用地址的端口没开。
- 设备层。上传模块正常但采集侧断线，发上去的是空 CP；设备掉电重启后配置回滚到出厂参数；本地缓存写满，新数据直接丢；系统时钟跑偏，QN 时间戳对不上。
- 平台层。设备档案没审核、MN 没绑定排口，按未备案设备处理；数据其实收到了，但被打上停运、校准、故障这类无效标记，查询页看着就是空的。
为什么先查平台、再查报文、最后查网络
平台的一条连接日志，能把问题一刀切成两半：有登录记录，说明链路、编号、密码都是对的，故障在数据内容或平台标记；没有登录记录，才需要往下走。这一步花五分钟，能省掉半天现场跑动。第二刀切在报文上——把数采仪串口抓一段原始报文下来，看 QN、MN、CN、CP 几个字段是否齐全，比反复改配置有用得多。网络放到最后，是因为它最容易验证，也最少出问题。
每一步的判断标准和处置动作
- 查平台连接记录。有记录无数据，说明 9011/9012 走通了，转去看 CP 里的数据时间和因子编码；无记录，进入下一步。
- 抓设备原始报文。看到 9011 反复重发、始终没有 9012 回来，问题在平台识别或网络丢包；看到报文本身就残缺，先修设备配置。处置重点：核对 MN 与备案是否逐位一致，注意大小写和前后空格。
- 看心跳。9015 心跳正常应答，说明会话还活着，问题在业务数据；心跳也不回，会话已经掉了，而设备面板不一定有提示。
- 看 3020 设备状态。状态报文能上去、监测数据上不去，多半是因子编码或数据有效性标记的问题，不是通道问题。
- 最后才查网络。用设备所在的这张卡、这个 APN，在同样位置做长连接测试，看多久掉一次，比 ping 有说服力。
三个最容易踩的坑
- 把「TCP 已连接」当成「平台收到了」。数采仪面板显示的是链路层状态，跟业务层有没有被接收是两回事。这个误解浪费的时间最多。
- 换了设备只改现场、不改平台。新数采仪的 MN 变了，平台档案还是旧的，设备这边一切正常，平台一条不认。换机之前先把备案信息改掉。
- 时钟不同步。设备断电后时钟归零，QN 里的时间戳变成几年前，平台按过期数据处理。看着像丢包，其实是时间对不上。校时是最便宜的一次排查。
FAQ
问：我这台数采仪显示在线，非现场监管平台上就是查不到，是不是平台的问题？
不一定。先让平台方按 MN 查连接日志，有日志就是数据内容或标记的事，没日志再查设备和网络。
问：换了台新数采仪，线还是原来的线，怎么就没数据了？
十有八九是 MN 和密码没更新到平台档案里，或者因子编码顺序跟原来不一样。先对档案，再对报文。
问：白天有数据，晚上就断，是不是运营商的问题？
先看设备日志里断开的时间点是不是固定。固定时段断开，多半是心跳周期和会话保持时间对不上；不固定，才考虑链路质量。
问：平台说数据收到了但无效，这个算谁的？
看 3020 状态报文里当时是什么状态。设备上报了停运或校准，平台就会标无效，这是正常逻辑，不是丢数据。