Why 60–80% of industrial PID loops run sub-optimally — and what closed-loop data reveals

Ask a room of control engineers what fraction of their loops are genuinely well tuned, and you'll get an uncomfortable pause. The honest answer, backed by two decades of plant audits, is that most aren't — and the gap is rarely where people expect it.

The figure that keeps surfacing in the literature and in our own field work is stark: 60–80% of industrial PID loops operate sub-optimally. Not broken — sub-optimal. They hold the process roughly where it needs to be, so nobody touches them. But they oscillate, they sit in manual, or they've been detuned into a slow crawl to stop the alarms. Each one is a small, permanent tax on yield, energy and equipment life.

The 60–80% number isn't folklore

"Sub-optimal" is a precise condition, not a vibe. In practice a loop earns the label when it shows one or more of these traits:

• Sustained oscillation — the PV cycles around setpoint even with no operator moves, usually from too much gain or an undiagnosed valve problem.
• Time in manual — the loop works only because a human is nudging it. A controller in manual is, by definition, not controlling.
• Over-detuning — gains pulled so low the loop can't reject a disturbance before the next one arrives. Quiet, but slow and lossy.
• Interaction — two loops fighting each other through shared hydraulics or heat, so tuning one detunes the other.

The reason these persist isn't incompetence. It's that the standard tool for diagnosing them — the open-loop step test — is the very thing most plants can't afford to run often, or honestly.

Why the step test lies

The classic identification recipe is to put the loop in manual, step the output, and watch the process respond. It's taught everywhere because, on paper, it gives you a clean model. On a running plant it gives you three problems at once.

First, it's disruptive: pulling a loop out of automatic to bump it perturbs production and, on interacting units, ripples into neighboring loops. Second, operators — rightly — won't allow large moves on a live unit, so the steps are small and the process is under-excited; the resulting model fits the noise as much as the dynamics. Third, a step test captures the open-loop response, but your loop lives in closed loop, where setpoint changes and disturbances interact with the controller you're trying to design. The test answers a question you're not actually asking.

So the disruptive method gets used sparingly, the loops drift, and the 60–80% figure stays remarkably stable decade after decade. Breaking that cycle means identifying models without taking the loop out of service.

What closed-loop identification does

Closed-loop system identification extracts process models — transfer functions — from data collected while every controller stays in automatic. No bump tests, no step changes, no plant disruption. The normal setpoint moves, grade changes and ambient disturbances that already happen are enough excitation when you analyze them the right way.

PiControl's approach with PITOPS works in the time domain and handles genuinely multivariable problems — up to 50×50 input/output matrices — so it captures the interactions between loops rather than pretending each one is isolated. The output is a model you can actually tune against: real gains, real dead time, real lags, derived from the plant as it runs. For the full mechanics, see our guide to closed-loop system identification.

Three loops that looked "fine"

The most useful thing closed-loop models reveal is how often a "fine" loop is quietly costing you. Three recurring patterns from the field:

• The compressor loop that wasn't oscillating — until it was. Stable at steady state, it broke into a slow cycle after every grade change because the tuning was matched to one operating point. The model showed a gain that nearly doubled across the range.
• The level loop in permanent manual. Operators had given up and were controlling by hand. The closed-loop model exposed valve stiction, not bad tuning — no gain change would have fixed it.
• The two temperature loops fighting through a shared exchanger. Each looked acceptable alone; together they traded oscillations back and forth. Only a multivariable model made the interaction visible.

In each case the fix was undramatic once the model was right. That's the point: the hard part was never the tuning math — it was getting an honest model without taking the unit down to get it.

Where to start on your own units

You don't need a plant-wide program to test this. A pragmatic first pass:

• Rank your loops. Continuous monitoring — APROMON tracks 30+ health criteria — will surface the worst oscillators and the loops sitting in manual faster than any walkdown.
• Collect what you already have. A few hours of normal operating data, controllers in auto, across a setpoint move or two. No special test.
• Identify and re-tune offline. Build the model, design the tuning against the real objective — setpoint tracking, disturbance rejection, or both — and validate before you load it.
• Measure variability, not vibes. Standard deviation around setpoint before and after. Reductions of 50% or more are routine when the starting point is one of the sub-optimal 60–80%.

The loops are already telling you what's wrong. Closed-loop identification just lets you listen without switching them off first.