数采仪连上智慧渡运系统却没数据,先查这四处

先说结论:连接成功不等于数据传上去了

“数采仪显示连接成功,智慧渡运系统平台上就是没数据。”这是我们在华东某渡口的船舶生活污水接收点和渡口周边水质监测站都遇到过的原话。结论先给:八成不是网络断了,而是报文到了平台门口没被收下。最常见的是三种——MN 设备编号与平台台账对不上、污染物因子编码不在平台字典里、设备时钟漂移导致 QN 时间戳被判为无效数据。TCP 连接成功只能证明链路通,证明不了应用层握手成功。

故障分四层,一层一层往里剥

协议层:报文格式和平台字典

走 HJ 212 的场合,一条上传报文由 QN(时间戳)、ST(系统编码)、CN(命令码)、PW(密码)、MN(设备编号)、Flag(标志位)、CP=&&数据段&& 以及末尾两位 CRC 组成。渡运平台按 CN=2011 收污染物数据时,应答一般是 9011 一族;如果抓包只看到自己往外发、收不到任何应答,说明平台根本没确认收下。

  • 因子编码对不上:平台自建字典不用 a01001 那套标准编码,报文再规范也入不了库
  • 2000–2999 是参数类命令,平台下发上报间隔、量程时设备回错包,后续数据可能被静默丢弃
  • Flag 位设置不对,数据会被判为“不参与统计”,库里查不到
  • CRC 两位十六进制算错,平台直接丢包,不会有任何提示

网络层:连上了,但连接是“半开”的

  • 专网 APN 下的 NAT 老化时间常见为 300 秒,设备心跳却是 60 秒以上,链接看着在线,实际发不出去
  • 定向卡未备案、流量池耗尽、机卡绑定被拆
  • 端口或地址改过但设备侧没同步
  • CN=3020 的设备状态报文也上不去,基本可判定在链路而不是数据

设备层:数据源头就有问题

  • 串口参数 9600/8/N/1 与仪表不一致,或 Modbus 从站地址冲突
  • 浮点字序 ABCD 与 CDAB 弄反,解析出来是固定值
  • 24V 供电波动、RS485 未共地,读数跳变
  • 设备未做 NTP 校时,QN 与平台时间偏差超出允许范围

平台层:收下了,但没进业务库

  • MN 未在平台备案,或台账里多了空格、大小写不一致
  • 数据落在“待审核”状态,业务页面不显示
  • 平台按 UTC 存储,页面显示差 8 小时,看着像没数据

排查顺序本身就是知识

顺序建议是:协议层 → 网络层 → 设备层 → 平台层。理由很简单,应答码是整个链路上唯一确定的证据,先把它拿到手,能一次性排除掉一半可能;反过来先去换卡、换表、重启设备,往往折腾半天,问题还在原地。我们见过一台 PS-S01 被反复断电重启十几次,最后发现只是 MN 少了一位数。

每一步的判断标准与处置动作

  • 只有发送没有应答:判断在协议层或平台侧 → 核对 MN、ST、因子编码,用平台给的样例报文做逐字段比对
  • 能收到 9011 应答但业务库没数:判断在平台字典或入库规则 → 请平台方调接收日志与入库条件
  • 历史数据完整、实时数据断续:判断在网络层 → 心跳改到 30 秒,或改为定时重连
  • 3020 也上不去:判断在链路 → 查卡状态、APN、端口连通性
  • 数值长期不动或为固定值:判断在设备层 → 换从站地址、核对浮点字序,用串口工具单独读寄存器验证
  • 时间戳差 8 小时或差几分钟:判断在时钟 → 开 NTP,或与平台约定校时周期

三个最容易误判的坑

  • 看到“连接成功”就去换卡。TCP 建连成功只说明三次握手过了,NAT 半开连接下设备照样显示在线,实际一个字节都发不出去。
  • 本地历史数据都在,就认定是平台丢数。设备本地存得好好的,恰恰说明采集没问题;真正丢的是 QN 时间戳越界的那部分,平台按规则丢弃,日志里往往只有一行。
  • 仪表读数不动,就判数采仪坏了。多数情况是解析问题——从站地址冲突或字序弄反,数采仪只是把错误的值如实转发出去,它自己没错。

FAQ

问:数采仪显示在线,智慧渡运系统就是没数据,是不是数采仪坏了?
先别换设备。抓一段报文看有没有应答,没有应答就查 MN 和因子编码,这一步能解决大半。

问:我这个情况到底要不要传?渡口这边的数据是不是必须进平台?
以属地渡运管理和环保部门给的口径为准,各地要求不一样。我们能做的是把数据稳定送到平台,要求本身请向属地确认,别听我们或同行拍脑袋。

问:换张流量卡是不是就好了?
只有链路层问题换卡才有用。定向卡、流量池、机卡绑定确实会导致假在线,但如果报文本身就不合法,换十张卡也一样。

问:能不能先手动补传历史数据?
可以,但要先确认平台允许补传的时间窗口和命令码,否则补上去也会被当成无效数据。补传前记得先校时。