Model predictive control is a way of controlling a process that thinks ahead. Instead of reacting to the error right now, the way a single PID loop does, it uses a model of how the process responds to work out where the outputs are heading over a future window, then chooses the sequence of moves that will best steer them toward target while respecting every limit. It is the workhorse of advanced process control, and it earns its place on units where variables push and pull on each other and where the money is made by running close to constraints. This guide explains the idea in plain terms, how the optimization repeats every scan, and where MPC sits relative to the regulatory DCS and SCADA layer beneath it.
Model Predictive Control (MPC) in one line: Model predictive control (MPC) is a multivariable control method that uses a dynamic process model to predict future outputs over a prediction horizon, then solves an optimization each control interval to pick the move plan that drives those outputs toward setpoint while honoring constraints on inputs and outputs. Only the first move is applied, the horizon shifts forward, and the whole calculation repeats on the next scan.
The heart of MPC is a model of the process: a description, usually built from step or pulse response tests, of how each manipulated variable and measured disturbance affects each controlled variable over time. On every control cycle the controller reads the current measurements, uses the model to project where the controlled variables are heading over a prediction horizon of many future steps, and compares that trajectory against the setpoints or target ranges it has been given. This forward look is what separates MPC from feedback control that only sees the present error, because it can anticipate that a move made now will overshoot in twenty minutes and temper it accordingly.
Having predicted the future, the controller solves an optimization. Over a shorter control horizon it searches for the sequence of moves that minimizes a cost function, typically a weighted sum of predicted deviation from target and the size of the moves themselves, subject to hard limits on how far and how fast each output may travel and on where each controlled variable may end up. The weights let the engineer say which targets matter most and how aggressively the controller may push, and the constraints let it say which lines must never be crossed.
The subtle part is that the controller does not commit to the whole plan. It applies only the first move in the optimal sequence, then throws the rest away. On the next scan it takes fresh measurements, shifts the horizon one step forward, and solves the problem again from the new starting point. This receding-horizon or rolling-horizon scheme is what gives MPC its feedback character: because it re-plans continuously against the latest data, model error and unmeasured disturbances get corrected every cycle rather than accumulating.
The reason facilities reach for MPC rather than more PID loops is interaction. On a distillation column or a reactor, moving one valve shifts several qualities at once, and independent single-loop controllers fight each other, one loop's correction becoming another loop's disturbance. MPC holds the whole picture in one model, so when it decides to move reflux it already knows what that does to top composition, bottom composition, and column loading, and it coordinates every handle at once to reach a consistent outcome. This is what people mean when they call MPC multivariable: it controls a set of outputs with a set of inputs as one connected problem rather than a stack of separate ones.
Constraint handling is the other headline capability, and it is where MPC pays for itself. Real value in a process is usually made by running against a limit, a maximum column loading, a valve near full open, a temperature ceiling, and a controller that respects those limits explicitly can safely nudge the process right up to whichever one is binding. MPC bakes the constraints into the optimization, so as one limit is approached it automatically gives ground on lower-priority objectives to stay within bounds, and if a constraint is temporarily violated it prioritizes getting back inside feasibility. This lets a unit operate closer to its best economic point than an operator watching a screen ever could sustain by hand.
Because MPC understands the dynamics, it also handles processes that would trip up simple control: long dead times, inverse response where a variable first moves the wrong way, and disturbances it can measure and feed forward into the prediction. The tradeoff is that all of this depends on the model being reasonably faithful. When the process drifts far from the conditions the model was identified under, predictions degrade, and part of running MPC well is watching model quality and re-identifying when performance falls off.
MPC almost never talks directly to valves. It sits as a supervisory layer above the regulatory control that lives in the DCS or PLC, and it works by adjusting the setpoints of those lower loops rather than driving field outputs itself. A flow controller, a temperature controller, and a pressure controller keep doing their fast, reliable job of holding their own setpoints, and the MPC decides, more slowly and with the whole unit in view, what those setpoints should be from moment to moment to keep the process at its best. This layering means that if the MPC is switched off or loses a signal, the regulatory loops keep the plant safely running on their last targets.
That position in the hierarchy shapes how MPC runs. It executes on a longer interval than the base loops because its job is to coordinate and optimize, not to reject fast noise, and it relies on the regulatory layer being well tuned underneath it, since MPC assumes a setpoint it hands down will actually be reached. It also needs a graceful way to switch in and out: when it releases control back to the operator or a loop drops out of its scope, the handoff has to be bumpless, with the base loops picking up on the last values without a jolt.
For teams whose process data and regulatory control live in a SCADA environment, the same hierarchy applies. SCADA and its historian supply the measurements MPC learns from and the trends operators use to judge whether it is helping, while the supervisory optimization writes setpoints back down to the field. A cloud SCADA that reliably historizes every tag and surfaces controller status makes it far easier to see when an advanced control layer is actually holding the process against its constraints and when a model has drifted and needs attention, which is often the difference between an MPC application that keeps earning and one that quietly gets switched off.
PID is a single-loop feedback controller: it reacts to the current error between one measurement and one setpoint and adjusts one output, with no knowledge of other loops or of the future. MPC uses a model to predict several outputs over a future horizon and optimizes a coordinated plan of moves across several inputs at once, explicitly respecting constraints. PID is ideal for fast, well-behaved single loops, while MPC earns its keep on interacting, constrained, multivariable problems, and the two usually work together, with MPC adjusting the setpoints of PID loops beneath it.
Applying only the first move and then re-solving on the next scan is what makes MPC a feedback controller rather than an open-loop schedule. Between scans, unmeasured disturbances hit the process and the model is never perfect, so committing to a whole future plan would let those errors accumulate. By re-planning from fresh measurements every cycle in a receding horizon, the controller corrects for model error and disturbances continuously, keeping the predicted trajectory anchored to reality.
No. MPC is a supervisory layer that runs above the regulatory control in the DCS, PLC, or SCADA layer and adjusts the setpoints of those existing loops rather than driving valves directly. The base loops still handle fast control and keep the plant safe if the MPC is turned off. The SCADA and historian also supply the data the model is built from and the trends operators use to judge whether the controller is doing its job.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.