Sensor drift screening
Unsupervised monitoring of sensor reading distributions that flags when a stream has shifted, without asserting that the equipment itself is failing.
Discovery, not a referral queueTechnique: Anomaly Detection
Sensor drift screening watches each instrumented reading’s own recent history rather than checking it against a fixed threshold or a trained failure pattern, and it flags a stream once its distribution has moved further than the plant’s normal operating variation explains.
It exists because vibration RMS, motor current, and bearing temperature readings drift for reasons that have nothing to do with equipment health: a sensor gets recalibrated, a sensor gets physically replaced, or an operator changes a line setpoint, and any of those silently shifts the baseline every downstream alarm and model was built on.
Its output is a candidate for review, not a verdict, so it routes to a reliability engineer who checks the flag against the plant’s calibration and setpoint change logs before deciding whether anything about the equipment itself has actually changed.
This is a discovery tool, not a referral source: a high drift score means a stream looks different from its own recent past, and that difference is just as often benign as it is a sign of a developing fault.
It is the wrong tool for deciding whether to dispatch a technician, since it was never built to assess equipment condition, only to say that the ground a threshold or a model was standing on has moved.
Feed a confirmed, non-benign drift back into the failure risk model as a trigger for revalidation, since this is the mechanism that catches the silent degradation those models are otherwise blind to.
Strengths for this problem
- Catches a shift in vibration RMS, motor current, or bearing temperature readings caused by recalibration, sensor replacement, or a changed setpoint, before that shift quietly corrupts a threshold or a risk score.
- Works without labelled failure examples, since it is comparing a stream to its own recent baseline rather than to a known failure pattern.
- Generates candidates worth investigating even when no rule or model for the underlying cause exists yet.
Limitations for this problem
- A drift flag says the distribution has changed, not why, so it cannot distinguish a genuine degradation trend from a routine recalibration on its own.
- Precision is low by design: many flagged shifts trace back to a benign instrumentation event rather than equipment health.
- Sensitive to how the baseline window is chosen, since too short a window flags normal seasonal or load variation and too long a window misses a real shift for months.
Data needed
- Raw vibration RMS, spindle motor current, bearing temperature, and oil particulate count streams over a rolling baseline window per asset.
- Sensor calibration and replacement event log, to check a flagged shift against a known cause.
- Setpoint change log, since a deliberate process change can shift readings just as a sensor fault can.
How it is measured
- Time between a drift flag and confirmation of its cause.
- Share of drift flags that trace to a known, logged calibration, replacement, or setpoint-change event versus an unexplained shift.
- Reduction in false alarms on downstream threshold alarms and the failure risk model after a confirmed drift is corrected.
Pitfalls
- Treating a drift flag as a failure alarm and dispatching a technician for an unnecessary teardown.
- Ignoring a drift flag and letting the failure risk model keep scoring against a distribution that no longer reflects reality.
- Not logging calibration and replacement events, so every drift looks unexplained and the queue becomes noise nobody trusts.
Human oversight
A reliability engineer reviews every drift flag and confirms its cause before any downstream alarm or model output built on that sensor is trusted again. No drift flag triggers a teardown or a line stoppage on its own.