"数据连续"的假象——轮询丢数与线性补值

事件

某泵站监测系统：

• 采集器通过 RS485（Modbus RTU）轮询 8 台从设备，共 32 个寄存器
• 轮询周期 1 min，平台侧展示 1 min 分辨率曲线
• 平台统计"数据完整率 100%"

一次水泵启停造成的水锤事件后，工程师调曲线看峰值：

• 平台曲线：压力从 0.42 MPa 平滑升到 0.58 MPa，再平滑回落
• 现场压力表录像（检修时恰好拍到）：瞬时冲到 0.82 MPa

差了 0.24 MPa，29%。

调查

第一步：比对本地原始记录

采集器本地 SD 卡存了原始采集结果（未补值），逐条比对：

峰值那两拍，一拍超时、一拍被补值抹平。

第二步：为什么超时

查 RS485 总线：

• 8 台从设备挂同一条总线，波特率 9600
• 单台设备一次完整查询（请求 8 B + 响应 ~40 B）约 50 ms
• 32 个寄存器分 12 帧查询，理论耗时 600 ms
• 实测平均轮询耗时 780 ms，最坏 1.4 s（超出 1 s 窗口）
• 超时重传一次再放弃，该拍记为"无值"

9600 波特率下每字节约 1.04 ms，加从设备响应延迟与总线换向时间，帧间隔不可忽略。总线越长、设备越多，超时率越高。

第三步：为什么平台显示 100%

平台侧的"完整率"定义为：统计时段内的记录条数 / 应有记录条数。

采集器的补值逻辑：上一拍有值、这一拍超时，就线性插值补一个值写进去。于是：

• 记录条数永远是满的 → 完整率 100%
• 但其中 18% 是插值造出来的数

完整率统计的是"有没有数"，不是"有没有真数"。

根因

1. 总线带宽不足：9600 波特率 + 8 台设备 + 32 寄存器，1 min 窗口余量不够（实测 780 ms / 1000 ms）
2. 超时处理策略错误：超时后直接线性补值，且不打标记
3. 质量标记被丢弃：采集器本地其实记了"超时"，但上报平台时只报数值不报质量位
4. 完整率定义错误：按记录数统计，掩盖了补值比例
5. 采样定理的忽视：水锤是 ~0.5 s 的过程，1 min 轮询本来就采样不到，补值只是让"采样不到"看起来像"没发生"

防范

1. 完整率必须双指标：

- 采集完整率 = 原始成功采集数 / 应有采集数（不补值） - 展示完整率 = 展示记录数 / 应有记录数 两个都要报，且采集完整率 < 95% 要告警

1. 质量位随数据走：每个数值带一个 quality 字段（good / interpolated / stale / timeout / suspect），平台按质量位渲染（补值用虚线或空心点）
2. 补值要有上限：连续补值不超过 3 拍，超过就留空（留空比假数据安全）
3. 峰值场景提高采样率：水锤、冲击、启停这类过程，用 10 Hz 以上独立采集（触发式或独立高速通道），不能靠 1 min 轮询
4. 总线参数核算：

- 轮询耗时 = Σ(帧字节数 × 10 / 波特率 + 从设备响应延迟 + 换向时间) - 实测轮询耗时 < 轮询周期的 50% - 达不到就提波特率（19200/38400）、拆总线、或减少每帧寄存器数

1. 关键量本地留原始档：SD 卡或采集器本地存未补值的原始记录，保留 30 天以上，出事后可回溯

教训

"没有缺数"不等于"数据完整"，只等于"每个时间点都有个数"。

补值是必要的（下游算法需要等间隔序列），但补出来的数必须：

• 带质量标记
• 不参与峰值统计
• 不参与报警判定
• 参与完整率统计时按"缺失"计

平台把补值和真值混在一起展示，是数据链路里最常见也最隐蔽的失真。它不会触发任何报警，看起来一切正常，直到某天需要拿这条曲线做责任判定——那时才发现"连续"是假的。

给工程项目的启示

数据链路要列一张"失真清单"，逐项确认：

清单里每一项都问一句：这一项发生后，平台能不能发现？ 不能发现的，就是下一个事故。