Sensor Drift: Why It Happens, What It Costs You, and How to Catch It Before It Lies to Your Control System

Sensor Drift: Why It Happens, What It Costs You, and How to Catch It Before It Lies to Your Control System

The sensor is working. That's the problem.

It's sending a signal. The loop is closed. The PLC is receiving a value, the HMI is displaying a number, and nobody has raised an alarm. Every indicator says the system is behaving normally. But the reading is wrong — has been wrong for months — and every decision made from that data has been made on a lie.

That's sensor drift. Not a failure. Not a fault code. A slow, invisible departure from accuracy that your PM program probably isn't designed to find.

What Sensor Drift Actually Is

Drift is a gradual shift in a sensor's output relative to the actual process value. The sensor is still functional. It's still producing a reading. That reading just no longer corresponds to reality.

A pressure transmitter that reads 42 PSI when the actual process pressure is 47 PSI isn't broken. It's drifted. The output looks reasonable. It's within an operating range. Nothing in the control system flags it as a fault. And yet every decision made from that number — every setpoint, every interlock, every process adjustment — is based on a value that's five PSI off from what's actually happening in the pipe.

The full picture on what your sensor program is and isn't catching starts with understanding your pillar topic why most programs don't know when their data is wrong.

Drift is not a binary state. It exists on a continuum. A sensor might be off by 0.5% today. By 1.5% in six months. By 4% in two years. At some point on that continuum, the error starts affecting process control, product quality, safety margins, or energy consumption. The question is whether you find it before it costs you something — or after.

Why Sensors Drift

The causes vary by sensor type. But the underlying mechanisms fall into a handful of categories that repeat across almost every measurement technology in industrial use.

Electrode degradation is the dominant drift mechanism in electrochemical sensors — pH, dissolved oxygen, ORP, conductivity. The sensing element itself changes over time. Membrane fouling, reference junction poisoning, and depletion of fill solution all produce output errors that accumulate gradually. The sensor doesn't fail. It just stops being accurate.

Mechanical and physical fouling affects sensors with process-wetted surfaces: flow meters, pressure taps, level sensors, temperature wells. Scale, biofilm, corrosion byproducts, and particulate accumulation change the way the sensor interacts with the process. A pressure transmitter with a fouled impulse line reads the process through a filter of debris. The reading shifts. The shift is slow. Nobody notices.

Thermal stress and aging affects virtually every sensing technology. Repeated thermal cycling causes fatigue in sensing elements, changes in reference junction characteristics, and drift in the signal conditioning electronics. An RTD that's been through ten thousand heating cycles is not the same device it was when it was calibrated.

Reference drift in transmitters happens when the internal components used to compare and scale the signal change over time. Capacitor aging, resistor drift, and changes in reference voltage sources all introduce errors that weren't present at the time of the last calibration.

Process chemistry changes affect sensors that are calibrated for a specific medium. A conductivity sensor calibrated for one process solution will drift — or appear to drift — if the composition of that solution changes. The sensor may be working perfectly. The calibration is just no longer valid for the current conditions.

The important point: none of these mechanisms produce sudden failure. They all operate slowly. Which is exactly why a PM program that only responds to faults will never find them.

What Drift Costs You

The cost of sensor drift is almost always underestimated — because the cost is invisible until it isn't.

Process control degradation is the most direct consequence. A control loop running on drifted sensor data is controlling to the wrong setpoint. It's compensating for a process condition that doesn't exist, or failing to compensate for one that does. PID loops are particularly vulnerable — a drifted input drives the controller to make adjustments that push the actual process further from where it needs to be. The loop looks like it's working. It's making things worse.

Quality failures happen when process parameters drift outside acceptable ranges — and the control system doesn't know because the sensors have drifted with them. The product is off-spec. The measurement says it isn't. By the time the lab catches it, you've produced a shift's worth of rejects.

Energy waste is one of the quietest costs of sensor drift. A drifted temperature sensor in a heating application drives the system to heat more than necessary. A drifted flow sensor drives a pump to move more fluid than the process requires. These losses are real, measurable, and chronic. They don't show up on a maintenance work order — they show up on the utility bill.

Safety margin erosion is the version that keeps process engineers up at night. A pressure transmitter that's reading 8% low has effectively shrunk your safety margin by 8%. That margin exists because the process was analyzed and a safe operating limit was established. Drift quietly narrows the distance between normal operation and a situation that warrants action. When the safety interlock finally triggers, it may trigger late.

Misleading condition monitoring is the problem that directly affects maintenance. A drifted vibration sensor in a CbM program isn't detecting early bearing failures — it's generating baseline data that's wrong. Trend lines built on drifted data don't reflect actual equipment condition. They reflect the combined effect of actual condition plus sensor error. You can't separate the two without calibration verification.

Where Drift Shows Up First

The sensors most prone to meaningful drift under industrial conditions are not the ones most maintenance programs prioritize.

Electrochemical sensors — pH, dissolved oxygen, ORP — are probably the worst offenders for rapid and significant drift. They're calibrated frequently in some facilities, but that frequency is often calendar-based rather than driven by any understanding of the conditions that accelerate drift.

Pressure transmitters and differential pressure transmitters drift more slowly than electrochemical sensors, but the consequences can be more severe because they're often in critical process control loops. A fouled impulse line drifts. A sensor with aging electronics drifts.

Temperature sensors — particularly thermocouples in high-temperature applications — drift from thermoelectric EMF changes, junction oxidation, and contamination of the thermocouple wire. An RTD drifts from insulation resistance changes and mechanical stress.

Conductivity sensors drift from fouling, cell constant changes, and electrode aging. In a process where conductivity is used for quality or concentration control, a 5% conductivity drift can translate directly to out-of-spec product.

Ammeters and current measurement devices used in motor monitoring applications drift from shunt resistance changes and connection resistance. An ammeter that's reading low on a motor current measurement will miss the early load increase that signals a mechanical problem.

The broader question of why sensors stop telling the truth — including failure modes that produce drift rather than outright failure — is covered in why sensors stop telling the truth long before they stop sending a signal.

How to Catch Drift Before It Lies to Your System

Catching sensor drift requires a different approach than catching sensor failure. Failure announces itself. Drift doesn't.

Reference comparison is the primary tool. The simplest way to find drift is to compare the sensor's reading against a known reference at the same process condition. That reference might be a calibrated reference instrument brought in periodically, a redundant sensor installed in parallel, a grab sample analyzed in the lab, or a reference measurement taken at a known process condition. If the readings diverge, drift is present. How much drift is acceptable depends on the application — but the divergence gives you something to act on.

Trend the span, not just the reading. A sensor that's reading consistently high isn't drifted — it might be installed correctly and the process is genuinely running high. What reveals drift is a change in reading at a stable process condition over time. That requires trending. Which requires that your PM program actually records specific values rather than checkmarks. "Pressure transmitter — checked" tells you nothing. "PT-204 reading 42.3 PSI at 0800 with process at normal steady-state" is something you can trend.

Two-point verification catches span errors. A sensor with a zero drift reads incorrectly across the entire span by a fixed offset. A sensor with a span drift reads increasingly wrong as the process variable moves away from zero. Verifying at one point only reveals zero drift. Verifying at two points — typically at zero or low reference and at a known elevated process condition — reveals span drift that a single-point check would miss entirely.

This is where calibration intersects with PM. Calibration verification — confirming that a sensor still reads accurately against a reference — is the formal version of drift detection. Most PM programs treat calibration as a separate function performed by instrumentation technicians on a fixed calendar schedule. The problem with that approach is explored in what most PM programs get wrong about sensor calibration.

Process data patterns can reveal drift before a calibration event. A PID controller that's hunting more than usual. A flow loop that's making larger-than-normal corrections. A temperature controller running at an unusual output percentage to hold setpoint. These behavioral signatures can indicate a drifted input. They're not definitive — they could also indicate process changes, mechanical wear, or valve problems. But a process engineer or experienced tech who knows what normal looks like will recognize when a loop is working too hard. That recognition is the first step.

The relationship between sensor drift and process measurement errors extends beyond individual sensor performance into how those errors compound in multi-sensor control schemes. That's covered in how bad sensor data becomes bad decisions.

What a Drift Detection PM Task Actually Looks Like

Most PM tasks around sensors are inspection tasks: check connections, check mounting, check for physical damage. Those tasks matter. They don't catch drift.

A drift-detection task looks different:

At a stable process condition, record the sensor reading and the reference reading simultaneously. Calculate the deviation. Record it with a timestamp. Compare it to the previous entry. Flag any deviation that has changed by more than your acceptable tolerance since the last check.

That's it. The task is simple. The discipline required to execute it consistently, to record specific values rather than vague assessments, and to actually trend the data over time — that's where most programs fail.

The first record is baseline. The second gives you a direction. The fifth starts to show a rate of change. By the tenth check, you have something that tells you when this sensor will require calibration or replacement — before the drift becomes a problem.

Acceptable drift tolerances vary by application and sensor type. They're defined by process requirements, not by manufacturer specifications. A sensor that's within its manufacturer accuracy specification may still be out of tolerance for a tight process control application. Know what your process needs, not just what the datasheet says.

Where to Start

These are the task list posts most directly relevant to drift detection across the sensor types where drift has the most significant process impact:

The sensor is still sending a signal. It always will be, right up until it doesn't. The question your PM program should be asking isn't whether the signal is present — it's whether the signal is true.