做数据采集的人都知道一句话：“Garbage in, garbage out.” 数据质量不行，后面做什么分析、什么AI、什么优化，全是白搭。

一个让我印象深刻的数据质量事故。

一个化工厂的反应釜温度监测项目。反应釜里有强放热反应，温度必须控制在150±5℃。超过160℃就要紧急冷却，超过170℃就要紧急泄压。

系统上线三个月，一直没有问题。温度稳定在150℃左右。

然后有一天，温度突然从150℃涨到了165℃。系统报警了。操作工启动了紧急冷却程序，产线停了。

事后检查发现——温度传感器漂移了。

这个温度传感器用的是PT100。PT100的阻值跟温度的关系是：0℃时100Ω，100℃时138.5Ω，150℃时157.3Ω。

用了三个月之后，传感器的阻值特性漂移了——150℃时实际阻值变成了162Ω，对应的温度显示成了170℃。

实际温度没变，是传感器“老化了”。

传感器漂移的三种类型

类型一：零点漂移。

传感器在零输入时的输出偏离了零点。比如一个压力传感器，没有压力的时候应该输出0kPa，但实际输出2kPa。

类型二：灵敏度漂移。

传感器的输出跟输入的线性关系变了。比如温度传感器，原来100℃对应138.5Ω，现在100℃对应141Ω。

类型三：非线性漂移。

传感器的输出跟输入不再是线性关系。低温区准确，高温区偏差大；或者反过来。

怎么检测传感器漂移？

方法一：交叉验证。

同一个测点装两个传感器，对比两个传感器的读数。如果两个读数偏差超过阈值，说明其中一个漂移了。

这个方法最可靠，但成本高——要多装一个传感器。

方法二：物理模型校验。

有些物理量之间有确定的关系。比如：流量 = 流速 × 截面积。如果流速和截面积都是已知的，流量的计算值应该跟传感器的读数一致。不一致，说明流量传感器可能漂移了。

方法三：历史数据对比。

同一个工况下，传感器的读数应该跟历史数据一致。如果某个传感器的读数突然跟历史同期偏差很大，可能漂移了。

方法四：定期校准。

不管有没有发现漂移，定期校准是必须的。工业现场的传感器一般半年到一年校准一次。校准的时候用标准信号源，检查传感器的输出是否准确。

异常值处理的四种方法

方法一：物理极限过滤。

每个物理量都有物理极限。温度不可能超过2000℃，压力不可能为负，流量不可能超过管道的最大流量。超出物理极限的值，直接丢弃。

方法二：变化率过滤。

物理量的变化率是有限的。温度不可能在1秒内从25℃变成250℃。如果一个温度读数在1秒内跳变超过50℃，大概率是通讯错误或者传感器故障。这个值要标记为“可疑”。

方法三：滑动平均。

用最近N个读数的平均值作为当前值。这样噪声被平滑掉了，异常值的影响也降低了。

缺点是响应变慢——真实的变化会被延迟。

方法四：中值滤波。

用最近N个读数的中位数作为当前值。中值滤波对异常值不敏感——即使有一个异常值，中位数也不受影响。

适合处理“偶发异常值”的场景。

数据质量监控的四个指标

指标一：采集率。

实际采集到的数据量 ÷ 应该采集到的数据量。正常情况下应该在99%以上。

指标二：延迟。

数据从产生到入库的时间差。局域网内应该在1秒以内。超过5秒说明有瓶颈。

指标三：异常率。

被标记为异常的数据量 ÷ 总数据量。异常率应该低于1%。异常率突然上升，说明设备或者网络出了问题。

指标四：漂移率。

传感器的读数跟基准值的偏差。漂移率超过阈值，说明传感器需要校准或更换。

关于工具

做数据质量的时候，需要模拟各种异常场景——传感器漂移、数据跳变、通讯中断、数据丢失。ProtoForge可以模拟这些异常，验证数据质量监控逻辑能不能正确识别和处理。

EdgeLiteGateway支持数据预处理——缩放、死区过滤、限幅、滤波、聚合。在边缘侧把数据清洗一遍，再上传到云端，减少云端的数据处理压力。

ProtoForge： GitHub：suoten/ProtoForge Gitee：suoten/ProtoForge

EdgeLiteGateway： GitHub：suoten/EdgeLiteGateway Gitee：suoten/EdgeLiteGateway