Reacting to a disturbance after it has already hit the process, versus not waiting for it to become an error at all.
Feedback control, by definition, can only correct an error it has already measured — which means the disturbance has already reached the process output before anything happens. Feedforward control takes a different approach entirely: instead of waiting for the disturbance to show up as error, it measures the disturbance directly, the moment it occurs, and uses a model of how that disturbance affects the process to apply a correction immediately — before the output ever significantly moves. The catch is that feedforward only works for disturbances you can actually measure and reasonably predict the effect of. That's exactly why real control systems almost never use one instead of the other — they run both together.
Feedback control is, by its very structure, reactive: it computes error = setpoint − measured output, which means the output has to have already moved before there's anything to react to. Feedforward sidesteps that lag entirely — but only for disturbances you can actually measure. It doesn't watch the outlet temperature at all. It watches the cold inlet flow rate directly, and the instant that flow changes, a model built into the feedforward controller (something like "every 10 gpm of extra cold flow needs roughly X% more steam valve opening") computes the correction and applies it immediately — before the disturbance has had time to propagate through the heat exchanger and actually change the outlet temperature. That model is never perfect, and it can only account for disturbances someone thought to measure. So feedback keeps running underneath it the whole time, quietly trimming out whatever small error the feedforward model didn't quite predict, or catching a disturbance — a fouled tube, a steam pressure fluctuation — that was never instrumented in the first place. Feedforward buys speed on the disturbances you saw coming; feedback is the safety net for everything else.
No — and building a loop this way is exactly how you end up with an outlet temperature that quietly drifts and nothing ever corrects it. Feedforward only works at all for a disturbance that is directly measurable and whose effect on the process is reasonably well modeled. By itself, feedforward has no way whatsoever to detect or correct for an unmeasured disturbance, a sensor that has drifted out of calibration, or simple error in its own predictive model — it isn't even looking at the variable it's supposed to be controlling. Real high-performance control systems combine the two rather than choosing one: feedforward handles the fast, proactive correction for the disturbances that are known and measurable, while feedback keeps running in the background the entire time, watching the actual process output and quietly cleaning up everything feedforward's model gets slightly wrong or never saw coming. Feedforward without feedback isn't a more advanced control strategy — it's an open-loop strategy with better inputs, and it inherits every one of open-loop's blind spots.
Explains the real distinction between feedforward and feedback control — feedback measures the process output and can only correct an error after it has already occurred, while feedforward measures a known, measurable disturbance directly and corrects for its predicted effect before it ever shows up as error — using a side-by-side heat exchanger outlet temperature example under a cold inlet flow surge.
A feedback controller computes error = setpoint − measured process variable. That subtraction only produces a non-zero value once the measured output has actually diverged from setpoint, which means the disturbance has already propagated through the process and altered the output before the controller has anything to act on. This isn't a tuning shortfall or a slow controller — it is a structural property of feedback: no matter how aggressively a PID loop is tuned, it cannot begin correcting a disturbance it has not yet detected through its own process variable measurement.
Feedforward control measures a disturbance variable directly — not the controlled output — and applies a corrective action calculated from a model of how that specific disturbance affects the process. For this to work at all, two conditions have to hold: the disturbance has to be measurable (a flow transmitter on the cold inlet line, for instance), and the process's response to that disturbance has to be reasonably well characterized (a gain or transfer function relating inlet flow changes to required valve position changes). Feedforward has no mechanism whatsoever for correcting a disturbance it cannot measure, and an inaccurate model produces an inaccurate correction — it doesn't fail safely toward zero correction, it fails toward a wrong one.
Because feedforward's correction is only as good as its measurement and its model, it is essentially never deployed alone in a real process. The standard architecture sums a feedforward term and a feedback term at the final control element (the heat exchanger's steam valve, in this example): feedforward supplies a fast, proactive correction for the disturbance it was specifically built to handle, while feedback continues running exactly as it would in a feedback-only loop, watching the actual outlet temperature and trimming out whatever small residual error remains — model inaccuracy, sensor drift, or an entirely different disturbance that was never instrumented for feedforward in the first place. This is why the misconception that feedforward "replaces" feedback is backwards: removing feedback from a feedforward loop removes the only safety net for everything the feedforward model doesn't account for.
Technically yes, but it is then a form of open-loop control with a smarter input — it has no way to detect or correct for an unmeasured disturbance, sensor drift, or its own model error, since it never checks the actual process output. Virtually all real feedforward implementations in SCADA/DCS systems run alongside a feedback loop specifically to cover that gap.
The feedforward correction will be wrong by whatever margin the model is off, producing a residual error at the process output — either an overcorrection or an undercorrection. This residual is exactly what the feedback loop, still running underneath, is there to trim out; it is not something feedforward itself can detect or fix.
Yes. Feedforward specifically measures the disturbance variable (cold inlet flow rate, in the heat exchanger example) rather than the controlled variable (outlet temperature). If the disturbance can't be measured directly with a sensor, feedforward simply cannot be applied to it — there is nothing else it can act on.
No, though they're often used together. Ratio control maintains a fixed proportion between two measured flows; cascade control nests one feedback loop's output as another loop's setpoint. Feedforward is distinct from both: it applies a correction computed directly from a measured disturbance and a process model, independent of any setpoint cascade or flow ratio.
A feedback loop can only be made so fast before it fights the process dynamics and destabilizes — there is a hard limit set by the process's own dead time and lag, no matter how the PID is tuned. Feedforward sidesteps that limit entirely for measurable disturbances because it doesn't wait for the output to move at all; it acts on the disturbance measurement the instant it changes, which is fundamentally faster than any feedback loop reacting to the consequence of that same disturbance.
Try our SCADA Studio
More calculators, simulators, and guides for this discipline.