A value that's drifted from target for a long time may mean the target is stale, not the controller
Aliases: obsolete setpoint diagnosis · process control display
What it is
When process value drifts from setpoint for a long time, the first suspects are usually "the controller is broken" or "the operator mistuned it." There is a third possibility: the target itself no longer fits current equipment condition, recipe, or environment — an obsolete setpoint, not a control failure. That is a governance and change-management question — who approved this number, under what conditions, and do those conditions still hold — not something an operator should keep compensating for by hand indefinitely.
Why it happens
Setpoints are usually fixed once during commissioning and rarely reviewed systematically afterward, while process gain, load, feedstock batch, and equipment wear keep changing slowly. As the gap between reality and a frozen target widens, it shows up as one of two symptoms: sustained controller output saturation (pushed to its limit and still not closing the gap), or repeated manual correction. Both symptoms are usually treated as a tuning problem — retune the PID, swap the algorithm — but if the real cause is that the target no longer fits the operating condition, retuning just makes the controller chase the wrong target harder. The symptom eases while the underlying fact — that the basis for the target has expired — stays hidden.
Where it stops holding
Persistence alone does not prove the setpoint is wrong. Long-standing sensor bias, a travel-limited actuator, or a continuous external disturbance can all produce something that looks like a "long-term deviation," and these more easily fixed causes must be ruled out first. Safety-related setpoints in particular must never be adjusted on field judgment alone — even with strong evidence that the original target no longer applies, changing the number without formal hazard and change review just trades a known old risk for an unverified new one.
Applying it
Review long-term deviation together with controller output saturation, the frequency of manual overrides, and the original provenance of the setpoint — who set it, and under what conditions — rather than looking at the deviation number in isolation.
- Order of investigation: verify sensor readings and actual actuator travel first, to rule out measurement or actuation faults, before questioning whether the target itself is out of date.
- How to check: route any confirmed setpoint change through management of change, and validate the new value against both the new operating condition and historical worst-case bounds — not merely against "the current deviation went away."
Related
- Same group: Y3.08.1 Co-displayed setpoint and process value · Y3.08.2 Deviation-band indication · Y3.08.4 Hidden control target
- Nearby: Y3.10 Parameter limits and safety interlocks · Y7.03 Procedural deviation
- Search terms:
Obsolete setpoint diagnosis·process control display·industrial human factors
Cards in the same group
- Y3.08.1Seeing the actual value without its target next to it hides how far off the process really is
- Y3.08.2Whether the error between setpoint and actual has crossed its limit deserves its own visual cue
- Y3.08.4Showing only the current reading with no target hides whether control is actually working at all