现象：连接是成功的，平台上就是没有核查记录
“数采仪上显示连接成功，流量计的核查数据平台能看见，COD、氨氮的核查记录一条都没有。”这是运维工程师在华东某化工园区驻场时反馈的原话。遇到这种情况，第一反应往往去查网络、换卡、重启设备，但多数时候方向就错了。
结论先给出来：先别动网络。先看数采仪本地的核查数据表里有没有COD、氨氮的记录。如果本地就是空的，那平台收不到并不是传输问题，而是数采仪根本没有采到、或者采到了但没有通过校验，最终被自行丢弃。只有流量计要传核查数据这个印象，通常来自平台页面只展示了流量计那一条，并不代表其他因子的核查项在协议里不存在。
为什么偏偏是流量计“看起来”能传
流量计的核查项，比如零点核查、量程核查，多数设备本身就带数字接口，核查记录写在设备自己的寄存器里，数采仪按固定地址周期读取，读到就写进本地核查表，再按交互命令打包发出去。COD、氨氮这些分析仪的核查记录往往需要单独配置寄存器地址，或者依赖分析仪主动上报。数采仪的核查配置表里如果这几项地址是空的，读上来就是默认值0，数采仪判断为无效数据，直接不发。所以不是“只有流量计要传核查数据”，而是只有流量计这条链路是通的。
按四层拆开看，可能坏在哪
设备层：本地核查表
- 数采仪核查配置表里，COD、氨氮的核查寄存器地址为空，或者填了但和厂家手册对不上。
- Modbus读保持寄存器（功能码03）返回异常码0x83，数采仪按超时处理，取默认值后判无效。
- 分析仪做了核查，但只写进自己的历史记录，没有开放对应的读地址。
协议层：核查类交互命令
- 核查数据一般走交互类命令，现场常见的是9011标样核查、9013零点核查、9014量程核查这一类，具体以平台下发为准。命令编码（CN）填错，平台就归不到核查记录里。
- 报文里的MN设备编号、ST系统编码、Flag数据标志位必须和平台登记的一致，Flag位标错会被当成实时数据丢掉。
- 数据区CP里核查时间、核查类型、核查结果三个字段缺一个，平台解析就会失败。包尾CRC校验不过，平台侧直接丢弃且不一定回错误。
网络层：心跳通不等于长包通
- 3020连接命令能通，只说明TCP链路活着。部分现场防火墙或NAT只放行小包，核查报文稍长就被截断。
- 专网卡流量池限速时，小包正常、稍大的交互包超时，表现就是“连接成功、数据不全”。
平台层：接收开关
- 平台侧的核查数据接收是按因子勾选的，只勾了流量计，其他因子即使发上来也不入库。
- 平台把核查记录挂在1014日数据下的标志位里展示，独立上传的核查包只存不显示。
排查顺序：先本地，再报文，最后才看平台
顺序本身就是判断依据。本地没有记录，后面查网络、查平台全是白费；本地有记录但报文里没有，问题在协议配置；报文发出去了平台没有，才轮到网络和平台侧。
- 第一步，翻数采仪本地核查数据表，看COD、氨氮最近一次核查的时间和数值。有值往下走，没值就回去补寄存器地址和读取周期。
- 第二步，抓数采仪发出的报文，确认CN是不是9011、9013这一类，CP里的核查时间是否连续。报文里没有，说明是数采仪判断无效后没有发，不是发失败。
- 第三步，看平台对这条命令的回执。有回执但页面不显示，属于平台展示或勾选问题；没有回执，再查链路和防火墙。
- 第四步，用3020心跳单独验证链路，只能作为链路证据，不能作为数据已送达的证据。
三个容易误判的坑
- 把“连接成功”当成“数据已上传”。3020心跳只证明TCP通，不证明9011发出去了，更不证明平台入库了。
- 只盯平台页面，不看数采仪本地。本地核查表是空的，重发多少次都是空包，换卡、重启都解决不了。
- 为了让平台显示，把核查数据硬塞进1014日数据的标志位。结果是页面有了记录，但核查时间和实际对不上，后面做数据有效性判定时反而更麻烦。
FAQ
我这个情况到底要不要传核查数据？
要看平台下发的命令和当地管理要求。平台发9011、9013这类命令，就按命令回；平台只在1014日数据里取核查标志，就按日数据填。两头都做，容易出现时间对不上的重复记录。
流量计能传，为啥COD的不行？
大概率不是协议问题，是COD那一路的核查寄存器地址没配，或者分析仪没开放读地址。先把数采仪本地核查表填上值，再谈上传。
数采仪显示上传成功，平台就是没有，是谁的问题？
先抓报文看CN和CP字段全不全，再看平台回执。有回执没数据，找平台侧；没回执，查链路和防火墙。别一上来就换设备。
是不是所有仪表都得传核查数据？
不是。哪几项要传，以平台下发的命令编码为准。只有流量计要传核查数据这个说法本身就不准确，先核对平台侧的因子勾选，再决定配哪几路。