2. 在线监测数据采集与传输链路
在线监测数据的“有效性”并不是在平台端才第一次被决定的。从探头接触被测介质的那一刻起，到数据最终写入平台数据库，中间要经过采样、模数转换、本地组态、协议封装、网络传输、平台解析、校验入库等多个环节。任何一个环节出现偏差，最终呈现给管理者的数值都可能失真。理解这条链路的构成与各环节的职责，是判断数据质量问题“出在哪一段”的前提。
一、链路的四个基本环节
典型的在线监测数据链路可以划分为四段：传感器（含变送器）、数据采集仪（数采仪/数采终端）、传输协议、监控平台。四段之间是串行依赖关系，前一段的输出就是后一段的输入，因此上游的异常往往会被下游“继承”甚至放大。
传感器与变送器负责把物理量（如COD、氨氮、pH、流量、烟气浓度）转换为电信号或数字信号。这一环节的典型质量问题包括：探头污染或结垢导致响应漂移、标液过期或校准周期超期、量程设置与被测浓度不匹配造成截断、温度/压力补偿参数错误。传感器输出的常是4–20 mA模拟量或RS-485数字量，模拟量在长距离传输中易受干扰，数字量则可能存在地址、波特率配置不一致的问题。
数采仪是链路的“本地大脑”，承担采集、缓存、补传、打标等职责。它按设定周期（例如每5分钟或每1小时）从传感器读取瞬时值，按规则计算分钟均值、小时均值，并附加时间戳、设备编号、监测因子编码等标识。数采仪内部通常有本地存储，网络中断时先缓存，恢复后补传——这正是“缺失数据”与“补传数据”标识产生的源头。数采仪时钟不准、缓存容量不足、断电后未正确恢复，都会直接造成时间戳错位或数据断档。
传输协议决定数据如何封装与交互。污染源在线监测常用HJ 212协议，环境空气质量常用HJ 212或地方协议，部分场景使用MQTT、Modbus TCP。协议层的关键点在于：报文结构（数据段、指令编码）、编码方式（如ASCII或BCD）、校验字段（CRC）、以及心跳与超时重传机制。协议版本不一致、因子编码映射错误、校验失败被丢弃，都会表现为平台“收不到”或“收到但解析为异常值”。
平台入库是最后一环，负责接收报文、解析、校验（范围校验、逻辑校验、连续性校验）、写入数据库并生成有效性标识。平台侧的常见问题包括：解析规则与现场协议版本不匹配、时区处理错误导致时间偏移、重复报文未去重、入库失败未告警。
二、各环节如何“制造”数据质量问题
把链路拆开看，每一段都有其特有的失效模式，识别这些模式是定位问题的关键。
传感器段的问题通常表现为“数值缓慢偏离”。例如一台COD在线分析仪使用重铬酸钾法，若消解温度传感器偏差2℃，消解效率下降，测得值会系统性偏低；若采样管路结晶堵塞，则表现为响应时间变长、恒值或跳变。这类问题在平台上往往呈现为“数据连续但趋势异常”，单看某一时刻的数值很难发现，需要结合校准记录和质控样比对来判断。
数采仪段的问题更偏向“时间与完整性”。数采仪若未与NTP服务器对时，日积月累可能偏差数分钟甚至数小时，导致平台按小时统计时把数据归入错误时段；缓存容量若只够存2小时数据，而网络中断持续6小时，则中间4小时数据永久丢失，平台侧表现为“缺失”。此外，数采仪在计算小时均值时，若对无效瞬时值（如超量程）未剔除而直接参与平均，会把异常值“稀释”进均值，造成看似正常的假象。
协议段的问题常表现为“平台收不到或解析异常”。HJ 212协议中，数据段采用“因子编码+数值”的定长或变长结构，若现场数采仪固件版本较旧，因子编码表与平台不一致，平台可能把氨氮数值解析到COD字段下。CRC校验失败时，平台通常直接丢弃报文，若重传机制不健全，就形成数据缺口。MQTT场景下，QoS等级设置过低（QoS 0）在弱网时丢包，也会造成缺失。
平台段的问题集中在“解析与入库”。时区是最容易被忽视的一点：现场设备按本地时间打戳，平台按UTC存储，若转换规则未统一，会出现整点偏移。重复报文若未按“设备编号+时间戳+因子”去重，补传时会产生重复记录，统计时被重复计数。入库失败（如字段超长、主键冲突）若没有告警，数据会静默丢失。
三、按链路顺序排查的实用方法
面对一条“数据异常”的告警，建议按链路顺序自下而上排查，而不是直接怀疑平台。具体可按以下顺序操作：
- 核对时间戳连续性：在平台导出该点位近24小时的原始报文记录，检查时间戳是否等间隔、有无跳变或重复。若时间戳本身错乱，问题大概率在数采仪时钟或补传逻辑。
- 检查数值合理性：对照量程上下限、历史同期值、相邻点位值，判断是恒值、跳变还是缓慢漂移。恒值多为传感器故障或数采仪采集通道卡死；缓慢漂移多为探头污染或校准失效。
- 核对协议与解析：抽取一条原始报文，按协议文档手工解析，与平台展示值比对。若手工解析正确而平台显示错误，问题在平台解析规则或因子映射。
- 检查补传与标识：确认缺失时段是否有补传记录、补传数据是否带有正确的标识（如“补传”“无效”），避免补传数据被当作正常数据参与统计。
四、一个示例：小时均值缺失的归因过程
假设某污水排放口平台显示10:00—11:00的COD小时均值为空。按上述方法排查：首先导出原始报文，发现10:00—11:00期间共有8条报文到达平台，但每条报文的CRC校验均失败。进一步查看数采仪日志，发现该时段数采仪固件升级后协议版本由HJ 212-2005变为HJ 212-2017，而平台解析模块仍按旧版校验规则处理，导致全部报文被丢弃。这就是典型的“协议段”问题，而非传感器或平台入库故障。处理方式为统一协议版本或让平台兼容双版本解析，并对该时段数据进行补传和标识。此例中涉及的版本号、报文条数均为教学假设，实际排查应以现场日志为准。
理解链路各环节的职责与失效模式，才能在面对“数据无效”或“数据缺失”时，快速判断问题出在探头、数采仪、协议还是平台，从而采取针对性的处理措施，而不是笼统地归因于“设备故障”。