「数采仪上显示连接正常，数据也在往外发，平台那边高锰酸盐指数一直是 0.00，COD 和氨氮都好好的。」这是上周华东某化工园区一位运维工程师发来的原话。先说结论：这类「链路通、数值不通」的故障，八成不是网络问题，而是数采仪采集通道的工程量换算（量程上、下限）与分析仪输出量程对不上，或者 HJ 212 报文里 Rtd 字段取到的就是通道默认值 0。剩下两成，出在平台侧的污染物编码匹配和数据有效性判定上。下面按层拆，按顺序查。
一、故障现场：TCP 是通的，数据是死的
现场情况是这样的：分析仪面板显示 3.62 mg/L，数采仪触摸屏上对应通道显示 0.00；数采仪日志里能看到「连接平台成功」「发送成功」，平台侧该因子的曲线是一条贴着零轴的直线。用调试工具在数采仪侧抓包，能看到 CN=1011 的分钟数据包在按周期发出，包体结构完整，QN（请求编号）、MN（设备编码）、ST（系统编码）、CP 都在，唯独里头的 w01019-Rtd=0.00。
这说明什么？说明从数采仪到平台的链路、协议封装、CRC 校验这一路大概率是通的，问题出在「分析仪 → 数采仪」这一段，或者数采仪内部取值、映射环节。链路是好的，数据是死的。
另外提一句，高锰酸盐指数在 212 报文里的污染物编码，常见写法是 w01019，但具体以平台下发的编码表为准，有些平台用自定义编码，别想当然。
二、按层拆：每一层都可能「看着正常」
协议层
- CN 命令码用错：分钟数据走 1011、小时数据走 1012、日数据走 1013，平台用 2011/2012/2013 应答。有的现场把实时值塞进 1014 发，平台侧只落了历史表，实时表就是空的。
- QN 重复或格式不合法：QN 是 17 位时间戳加 3 位流水号，重复的 QN 平台会判重丢弃，日志上照样显示发送成功，数据却没进库。
- CRC 校验算错：HJ 212 的 CRC16 校验范围是从 ## 之后到 && 之前，多算一个字节或少算一个字节都会失败。校验不过平台直接丢包，TCP 层不报任何错。
- Length 包长与实际不符：Length 是 ## 后到包尾的字节数，中文、全角字符会让字节数对不上，平台截包失败。
- CP 字段缺项：DataTime 必须是 14 位（yyyyMMddHHmmss），Rtd 与 Flag 要成对出现，Flag 用 N（正常）、F（故障）、M（维护），漏了 Flag 平台可能按无效值处理。
网络层
- TCP 长连接被运营商 NAT 老化踢掉，数采仪没检测到半开连接，还在往一个死 socket 里写。心跳包 CN=9011 的间隔设得太长（有的现场设 300 秒），NAT 早就把会话回收了。
- 平台侧只回 TCP ACK、不回应用层应答，数采仪以为发成功了。
- 专网或 APN 卡定向访问变更、端口映射调整、DNS 解析到旧 IP，这类问题表现为「时通时不通」，最容易和上面几种混在一起。
设备层（本例高发区）
高锰酸盐指数分析仪常见的输出方式是 4–20 mA 模拟量或 RS232/RS485 数字量，两种走法出问题的点不一样。
- 4–20 mA 量程不匹配：分析仪输出 4–20 mA 对应 0–5 mg/L，数采仪 AI 通道里量程上下限填成 0–20 mg/L，读数会被压成实际值的四分之一；如果上下限填反或填成 0，直接钳位到 0.00。
- Modbus 寄存器错位：从站地址、功能码 03、寄存器 40001 对应 PLC 地址 0，差一位就取到空白寄存器；32 位浮点的字序（ABCD 还是 CDAB）搞反，解出来就是 0 或者极小的数。
- 小数位与单位：分析仪按 mg/L 输出，数采仪按 μg/L 解析，或者小数位设成 0 位，3.62 被取整再乘倍率，看着就像「不动」。
- 通道未启用或取的是保持值：模拟量通道没做零点标定，或者采集周期比分析仪的测量周期还短，读到的永远是上一次的保持值。
平台层
- 污染物编码没匹配上，数据进了库却没挂到高锰酸盐指数这个因子上。
- 平台侧量程上下限、检出限配置过窄，0.00 被当成无效值过滤掉。
- 小时数据由分钟数据算术平均生成，有效分钟值数量不够时整条判无效——分钟数据本身就是 0，平均值自然也是 0。
三、排查顺序：为什么先看屏幕，最后动平台
顺序本身就是效率。一句话：从下游往上游查，别从平台往设备查。
- 第一步，比对两个数：分析仪面板值对比数采仪通道显示值。两个数不一致，问题就在设备层，后面全不用查。
- 第二步，看数采仪本地历史：本地存储里如果也是 0，说明根本没采到，跟网络一点关系没有。
- 第三步，抓包看报文：本地有值、报文里 Rtd=0.00，问题在组包和映射环节。
- 第四步，看平台入库情况：报文里值是对的、平台没有，才轮到查编码、量程和有效性判定。
为什么这么排？因为前三步都在现场、几分钟能出结果，第四步要协调平台方、动辄半天。先易后难，也避免在电话里互相推责任。查完记得留痕：两个数值的截图、报文原文、平台入库记录，这三样攒齐了，后面是谁的问题一目了然。
四、每一步的判断标准和处置动作
| 现象 | 判断 | 动作 |
|---|---|---|
| 分析仪面板 3.62，数采仪通道 0.00 | 采集侧量程、接线或寄存器问题 | 核对回路正负极，核对 AI 通道量程上下限与分析仪输出量程是否一致；走 Modbus 的核对从站地址、寄存器地址和字序 |
| 通道值正常，本地历史全为 0 | 通道未启用或未绑定因子 | 在参数配置里把该通道关联到对应污染物编码，确认采集周期不大于上报周期 |
| 本地有值，抓包 Rtd=0.00 | 组包映射取错字段 | 检查因子与通道的映射表，确认取的是实时值而不是默认值或保持值 |
| 报文 Rtd 正确，平台无数据 | 协议层被丢弃 | 看平台应答码，核对 CN、QN 唯一性、CRC、Length |
| 平台收到包但没有值 | 编码或有效性判定 | 核对污染物编码表、量程上下限、小时数据有效分钟数规则 |
五、三个最容易误判的坑
坑一：把「连接成功」当成「数据通了」。TCP 三次握手成功只说明网络可达，应用层的应答码、CRC 校验、QN 判重，任何一环不过，平台照样丢包。判断标准只有一个：平台能不能查到这条数据，别的都不算。
坑二：看到 0.00 就去换试剂、换一台高锰酸盐指数分析仪。面板值正常、数采仪为 0，问题基本都在采集侧。先量一下 4–20 mA 回路的电流，或者读一次 Modbus 寄存器，比换耗材便宜得多，也快得多。
坑三：直接去平台改量程上下限，把数「调」出来。这是最危险的做法。改上下限不会让错的数据变对，只会让错的数据看起来合理，后面的总量核算、超标判定全部失真，追溯起来也说不清是谁改的。改配置前先截图留底，这是底线。
六、FAQ
问：我这个情况到底要不要传？
看环评批复和排污许可证里的自行监测方案怎么写的，写了的因子就得传。拿不准的，把许可证副本翻到监测点位、因子、频次那几页，或者直接问属地生态环境部门，别凭经验拍板。
问：数采仪显示连接成功，平台就是没数据，是不是平台的问题？
不能这么判断。先按上面的顺序，从分析仪面板值一路对下来，确认本地有值、报文里有值，再去问平台。手里有报文截图，沟通效率完全不一样。
问：COD 传得上去，就高锰酸盐指数传不上去，怎么回事？
两个因子走的是同一个 212 报文，链路和协议肯定没问题，问题只可能在该因子对应的通道映射、污染物编码、量程配置这三处。重点查这三个地方，别去折腾网络。
问：抓包看到 Rtd=0.00，但我分析仪上明明显示 3.62？
说明数采仪根本没从分析仪那里拿到值。要么模拟量通道量程配错被钳位，要么 Modbus 寄存器地址和字序不对，要么采集周期比分析仪的测量周期短，读到了上一次的保持值。先量电流，再读寄存器，两条路二选一。
问：现场断电重启后就好了，还用管吗？
要管。重启能好，说明是连接保持或通道初始化的问题，大概率还会复发。把心跳间隔调到平台要求的范围内，检查数采仪的重连机制，顺手把日志导一份存着。