先把答案给出来：数采仪面板上写着“连接成功”、智慧渡运系统平台上却一条数据都看不到，最常见的原因是两个——一是设备的MN号（设备唯一标识）没在平台侧备案，或者跟台账上的号对不上，平台收到报文后找不到对应对象，直接丢弃、不回确认；二是TCP长连接已经被运营商的NAT超时掐断，数采仪本地的socket状态还停在“已连接”，报文照发，回执一个没有。智慧渡运系统这类平台通常按渡口、渡船、设备三层挂关系，任何一层对不上，现场看到的都是“在线”，平台看到的都是“空”。
客户原话里的那个现象
“数采仪显示连接成功，智慧渡运系统上就是没数据，重启一下能好半天，过一夜又断了。”这是华东某汽渡码头一位运维工程师的原话。现场是三台设备共用一个4G专网卡，接的是渡船生活污水接收装置和岸电计量侧的采集单元，白天有人看着基本正常，夜里没人管，早上来看平台就是断档。
这类描述里有两个关键词值得盯住：“重启能好半天”说明链路本身能通，问题不在物理层；“过一夜又断”说明是保活或者超时机制的问题，不是配置完全错。真正完全配错的设备，重启一百次也上不来。
按四层拆开看，别一上来就拆机柜
平台层：先确认报文有没有到
- MN号未备案：平台侧设备台账里没有这个号，或者录成了另一台设备的号，报文到了也归不了档。
- 挂接关系缺失：设备号有了，但没绑到对应的渡口或渡船下面，数据进了“游离”状态，列表里刷不出来。
- 因子字典不匹配：平台上只配了pH和化学需氧量，设备却把流量、累计量一并上传，超出字典的因子被整条或部分丢弃。
- 时间判定：设备时钟漂移几天，平台按接收时间判定为“超期数据”，只入库不进报表。
网络层：连接成功不等于通路还活着
- 专网APN或VPDN没做白名单，平台IP和端口被挡在外面，TCP三次握手都过不去。
- NAT老化：运营商侧对空闲长连接有回收时间，设备不发心跳，链路上其实已经没有这条会话了。
- 双卡或多APN切换后，出口IP变了，平台侧按源IP做的绑定失效。
- DNS解析异常，域名形式的平台地址解析不到，改用IP直连反而正常。
协议层：HJ 212那套报文最容易错在细节
数采仪和平台之间走的是HJ 212协议，报文结构是## + 4位数据段长度 + 数据段 + 4位CRC校验，数据段里的字段用&&分隔、以;结尾。数据段里几个字段是排查的重点：QN（请求编号，17位时间戳加3位随机数）、ST（系统编码）、CN（命令编码）、PW（访问密码）、MN（设备唯一标识）、Flag（数据标志位）、CP（数据区）。
- 连接类用9011请求连接、平台回9012确认；不少设备把9011发出去了却收不到9012，仍然认为自己在线的状态里。
- 实时数据上传用2011，设备状态和心跳类走2051，历史补发走3020这一类命令。有些平台只认2011，设备却把数据塞在2051里发，平台上自然没有数据。
- CRC算错、数据段长度少一位，平台侧直接判为非法报文，连日志都只记一行“格式错误”。
- Flag标志位里如果带了故障位或维护位，部分平台会把这条数据按无效处理，不入库也不报错。
设备层：串口和量程的问题往往藏在后面
- RS485参数不一致，波特率9600、8位数据位、无校验、1位停止位对不上，读回来全是0或固定值。
- 从站地址冲突，两台仪表挂在同一条总线上，读到的数据来回跳。
- 模拟量通道量程配错，4–20mA对应关系反了，平台上有数但数不对，容易被当成“上传故障”。
- 本地存储写满后覆盖，断网期间的数据没留住，补发时无数据可补。
为什么排查顺序是平台、网络、协议、设备
这个顺序不是随便排的，它对应的是“数据从设备往外走”的逆序。先看平台日志里有没有报文落地，一步就能把问题范围砍掉一半：报文到了，问题在协议字段或平台配置；报文没到，问题在链路或设备。反过来先拆机柜、先换卡，往往折腾半天，最后发现只是MN号少了一位。
第二步看链路是否真的活着，用带时间戳的抓包或者平台侧的连接日志，确认9011发出去、9012有没有回来。第三步才去逐字段核对报文，最后才回到串口和仪表。顺序本身就是经验：越靠平台侧的证据越便宜，越靠现场的排查越贵。
每一步的判断标准和处置动作
- 平台日志有报文、无数据：判断为MN号或挂接关系问题。动作是拿设备屏幕上的MN号与平台台账逐位核对，补录挂接关系，再让设备重发一次2011。
- 平台日志一条都没有：判断为链路或设备未发出。动作是在设备侧看发送计数是否在涨，涨说明发出去了是链路问题，不涨说明设备根本没在发。
- 发送计数在涨、平台无记录：判断为专网白名单或NAT问题。动作是核对平台IP端口是否在白名单内，把心跳间隔调到小于运营商回收时间，先缩短到30秒观察一轮。
- 平台记录“格式错误”：判断为CRC或数据段长度问题。动作是用调试工具手工拼一条最短报文试发，能通说明是设备组包逻辑，不能通说明是平台侧解析版本。
- 平台有数但数值异常：判断为设备层。动作是旁路接一台仪表直读，比对模拟量与数字量两条通道。
三个容易误判的坑
- 把“连接成功”当“数据已送达”。面板上的连接状态读的是本地socket，链路被NAT回收后，本地状态不会立刻翻转。这个坑在夜间断传的场景里几乎是标配。
- 用调试工具能传，就认定设备没问题。工具里手填的是旧的MN和PW，设备里存的是新的，两边用的根本不是一套身份，结论自然对不上。
- 一断传就重启数采仪。重启会清掉本地的补发队列，断网期间的数据本来能靠3020补回去，反复重启反而把历史数据洗成了空白，事后追溯全断档。
FAQ
我这个情况到底要不要传？
只要设备挂在智慧渡运系统里有台账，数据就得传，断传本身就是问题，不是“传不传”的选择题。真正要判断的是断在链路还是断在配置，别急着改参数。
是不是随便填个MN号就能传上去？
不行。MN号是平台认设备的唯一凭据，填错了平台要么丢弃要么归到别人名下，短时间看着“有数据”，对账的时候全乱。换号必须同步改平台台账。
断网两天的数据还能补回来吗？
看两件事：设备本地存储有没有留住，平台侧允许多长窗口的补发。存储留住了、窗口内，用历史补发命令能传回去；存储被覆盖了，谁也补不回来。
平台说收到报文但“无效数据”，啥意思？
多数是Flag标志位带了故障或维护标记，或者时间戳超出了平台判定范围。先对设备时钟，再对Flag，最后才对因子编码。