How Model Predictive Control Handles Constraints

Model predictive control, often abbreviated MPC, is a control strategy that repeatedly predicts future plant behaviour, solves a constrained optimisation problem, applies the first control move, and then repeats the calculation at the next sample. Its distinctive engineering value is not simply prediction. Its value is that actuator limits, rate limits, output limits, state limits, and economic objectives can be handled inside the control calculation.

Classical feedback methods such as PID are often excellent when the plant is mostly single-input single-output, constraints are mild, and tuning goals can be expressed through gain, phase, damping, and settling time. MPC becomes attractive when the controller must decide among competing future actions while respecting explicit limits.

Core Mechanism

At each control update, an MPC controller does five things:

1. estimates or measures the current state;
2. predicts future behaviour over a finite horizon;
3. searches for a sequence of future control moves;
4. rejects or penalises sequences that violate constraints;
5. applies only the first move and repeats the calculation at the next sample.

This is called receding-horizon control because the prediction window moves forward in time after every update.

The basic state-space prediction model is:

where x_k is the state, u_k is the input, and y_k is the output at sample k.

An MPC problem usually minimises a cost such as:

where:

• N_p is the prediction horizon;
• N_c is the control horizon;
• r is the future reference trajectory;
• Q weights tracking error;
• R weights control movement;
• \Delta u is the change in control input.

The optimisation is solved subject to constraints such as:

These constraints are the reason MPC is widely used in process control, energy systems, robotics, aerospace, autonomous systems, and advanced thermal or motion-control applications.

Why Constraints Change the Control Problem

A conventional controller may compute a command that is mathematically desirable but physically impossible. A valve cannot open beyond 100 percent. A motor drive has current and voltage limits. A spacecraft reaction wheel has momentum limits. A battery has temperature, power, current, and state-of-charge limits. A chemical reactor may have strict concentration and temperature envelopes.

When a controller ignores these limits, the real system can saturate. Saturation changes the plant seen by the controller and can produce overshoot, windup, slow recovery, oscillation, equipment stress, or unsafe operation.

MPC treats limits as part of the decision. It may choose a slower path to the target because the faster path violates a future constraint.

Worked Example: Temperature Limit

A heating loop must raise a tank temperature toward a production target while keeping the outlet temperature below a safety-related operating limit.

Use a simple one-sample prediction model:

where:

• T_k is outlet temperature in deg C;
• u_k is heater command in percent;
• 0.06u_k is the heating contribution over one sample;
• 2.8\ ^\circ\text{C} is the approximate heat loss and load effect over one sample.

Current conditions:

The production target is:

but the operating limit is:

The actuator constraints are:

and:

Aggressive Candidate

A controller that only tries to reduce tracking error might choose:

The rate limit is satisfied because the first move changes from 50 percent to 65 percent:

Predicted temperatures are:

The third prediction violates the operating limit:

This candidate may improve tracking, but it is infeasible.

Feasible Candidate

A constrained candidate is:

Predicted temperatures are:

The plan remains below:

and respects the actuator and rate limits. The MPC controller may therefore choose this slower plan even though it does not reach the production target as quickly.

Engineering Comment

The target and limit conflict. A controller that blindly chases 96\ ^\circ\text{C} can violate the 94\ ^\circ\text{C} operating limit. MPC makes this conflict explicit. It does not magically remove the conflict; it chooses the best feasible move under the stated model, weights, constraints, and horizon.

Only the first move, u_0=65\%, is applied. At the next sample, the measured temperature, disturbance estimate, and model state are updated, and the optimisation is solved again. If heat loss changes, the next plan may change.

Hard and Soft Constraints

Some constraints must not be violated. Examples include:

• maximum safe pressure;
• actuator current limit;
• physical valve stroke;
• flight envelope boundary;
• battery voltage limit;
• collision boundary.

These are hard constraints in the control design. If the optimisation cannot find a feasible solution, the controller must have a fallback action.

Other constraints can be softened with a penalty. For example, a temperature target band, economic optimum, comfort target, or production-rate preference may be allowed to deviate temporarily if a higher-priority constraint is protected. Soft constraints are useful, but the penalty must match the engineering consequence. A low penalty can silently permit violations that operators thought were protected.

Why the Horizon Matters

The prediction horizon must be long enough to see the consequence of current actions. If the horizon is too short, the controller may choose actions that look safe immediately but violate constraints later. If the horizon is too long, the optimisation can become expensive, sensitive to model error, or difficult to validate.

The control horizon limits how many future moves are independently optimised. A shorter control horizon can reduce computation and make the action smoother. A longer horizon can improve flexibility but increases design and validation burden.

The horizon is therefore an engineering choice, not only a software parameter.

Digital Implementation Limits

MPC is usually implemented in software. That introduces practical constraints:

• the optimisation must finish before the next control deadline;
• numerical scaling must be robust;
• infeasible optimisation results must be handled predictably;
• measurements must be time-aligned;
• actuator commands must be held or updated consistently;
• cybersecurity and configuration control matter when constraints affect safety or production.

If the optimisation occasionally misses its deadline, the plant does not wait. The fallback command, hold behaviour, alarm, and operator response must be designed explicitly.

Validation Requirements

MPC validation should prove more than nominal tracking. Useful validation checks include:

Check	Why it matters
model identification range	Confirms the prediction model is valid where MPC operates.
constraint tests	Proves actuator, rate, state, and output limits are enforced.
infeasibility handling	Shows what happens when no feasible plan exists.
disturbance scenarios	Tests whether receding-horizon updates recover safely.
computation timing	Confirms optimisation completes before the deadline.
fallback behaviour	Defines command hold, safe mode, alarm, and operator action.
model mismatch sensitivity	Shows whether the controller is fragile outside the nominal model.
change control	Prevents silent edits to weights, horizons, constraints, or solver settings.

Simulation is useful, but it is not enough when the controller affects real equipment. Commissioning should include constrained test cases, hardware-in-the-loop tests where appropriate, and trend evidence from real operating conditions.

Common Mistakes

• Calling a controller MPC because it has a model, even though it does not solve a constrained future optimisation problem.
• Setting constraints in software without validating sensor scaling, actuator limits, and units.
• Using a horizon too short to see delayed constraint violations.
• Penalising a safety-related limit as if it were only an economic preference.
• Reporting good tracking while ignoring infeasible solver events or missed deadlines.
• Retuning weights without reviewing stability, robustness, and operator consequences.
• Trusting nominal simulation after plant dynamics, delays, loads, or actuator authority have changed.

Principle Summary

Model predictive control handles constraints by evaluating future control moves before applying them. It uses a plant model to predict future outputs, an optimisation objective to rank candidate actions, and constraints to reject unsafe or impossible plans. Then it applies only the first move and repeats the process with new measurements.

The principle is powerful because it turns limits into explicit design objects. It is risky when the model, horizon, constraint priority, solver timing, or fallback action is poorly validated. MPC should be treated as a control system with software, optimisation, measurement, actuation, and safety boundaries, not only as an advanced algorithm.