Derivative action - the D in PID, also called rate - responds not to the error itself but to how fast the error is changing. In theory it lets a controller anticipate where the process is heading and damp it before it overshoots. In practice, the majority of oil and gas flow and pressure loops run with derivative set flat to zero, because the same sensitivity that makes it anticipatory also makes it amplify measurement noise and kick the valve on every setpoint change. This page treats rate action on its own so you can decide, loop by loop, whether the payoff is worth the trouble.
Derivative Time (Rate Time) in one line: Derivative time, or rate, is the PID parameter that makes a controller respond to the rate of change of error rather than its magnitude, adding a predictive, damping action. It is powerful on slow thermal processes but is commonly set to zero on fast, noisy oil and gas flow and pressure loops because it amplifies noise and causes derivative kick.
Proportional action reacts to how far off you are and integral action reacts to how long you have been off, but neither pays attention to how quickly the situation is developing. Derivative action fills that gap by responding to the slope of the error signal. If the process variable is racing toward setpoint, derivative action pulls the output back early to keep the loop from overshooting; if the PV is diverging, it pushes harder sooner. Derivative time sets how far ahead the controller effectively looks.
This anticipation pays off on processes that are slow and dominated by lag, where overshoot is expensive and the measurement is clean. Temperature loops on heaters, reactors, and large thermal masses are the classic home for derivative action, because the process moves slowly enough that its rate of change is a meaningful, uncontaminated signal. On those loops, a well-tuned derivative term genuinely shortens settling time and reduces overshoot.
The key requirement is a clean measurement. Derivative action operates on the slope of the signal, and any process where the useful dynamics are slower than the noise is a good candidate. That description fits many temperature loops and very few flow loops, which is the root of why derivative is common in one and rare in the other.
Flow and pressure measurements are inherently noisy - turbulence, pump pulsation, and fast valve dynamics all show up as high-frequency jitter on the signal. Derivative action differentiates that signal, and differentiation amplifies high-frequency content far more than low-frequency content. The result is that a small amount of measurement noise, harmless to proportional and integral action, gets magnified by the derivative term into large, rapid output swings that hammer the valve and wear out the final element.
Because flow and pressure loops are also fast, they rarely need the anticipatory benefit derivative provides in the first place. A well-tuned PI controller already responds quickly enough on these processes, so there is little overshoot for derivative to prevent, and adding it buys instability and valve wear in exchange for a benefit the loop did not need. The standard field practice - derivative set to zero on flow and pressure - is a considered engineering choice, not laziness.
There is a related hazard called derivative kick. When an operator or a program steps the setpoint, the error changes instantly, and if the controller computes derivative on error it sees a near-infinite slope and slams the output for one scan. Many controllers avoid this by computing derivative on the process variable rather than on error, which eliminates the kick from setpoint changes while keeping the useful damping. If your controller offers derivative-on-PV, it is almost always the better configuration.
The symptoms of misapplied derivative action are easy to read on a historian once you know what to look for. A controller output that is fuzzy or noisy - visibly jittering even while the process variable is holding roughly steady - is a strong sign derivative is amplifying measurement noise. A sharp output spike that lines up exactly with a setpoint change is derivative kick. Trending output alongside PV and setpoint, as a cloud SCADA platform such as Merobix does across remote sites, makes both patterns obvious without standing at the panel.
For remote and unmanned oil and gas sites, this diagnostic value matters because nobody is there to hear the valve chattering. The historian is the only record that the output is thrashing, and the wear that thrashing causes accumulates silently until the valve fails. Alarming on excessive output activity, or simply reviewing output trends during routine loop checks, catches a derivative problem before it becomes a maintenance callout.
When a trend shows this behavior on a flow or pressure loop, the first move is usually to set derivative to zero and confirm the output settles, rather than to filter the signal harder. If a loop genuinely needs anticipation and the measurement is clean enough to support it, switching to derivative-on-PV and using a modest rate time is the disciplined way to add it back - verified against the historized response, not guessed.
Most oil and gas control is flow and pressure, which are fast and noisy. Derivative action differentiates the signal, which amplifies high-frequency noise into large output swings that wear the valve without improving control, and these fast loops rarely need the anticipation derivative provides. Setting it to zero is a deliberate practice, not an oversight.
Derivative kick is a sudden spike in controller output that occurs when the setpoint is stepped and the controller computes derivative on error. The instantaneous change in error looks like an enormous rate of change, so the derivative term momentarily slams the output. It is avoided by computing derivative on the process variable instead of on error.
Derivative action helps on slow processes dominated by lag where the measurement is clean and overshoot is costly - temperature loops on heaters, reactors, and large thermal masses are the classic examples. On those loops it shortens settling time and reduces overshoot by anticipating where the process is heading. It is far less useful on fast, noisy flow and pressure loops.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.