Model Predictive Control Constraint Handling Exercises

These exercises practise model predictive control as an engineering calculation, not only as an algorithm name. Each problem uses a simplified plant model so that the constraint logic can be inspected by hand.

The purpose is to build the habits needed before using MPC on real equipment:

• predict the plant response over a finite horizon;
• check actuator, rate, state and output constraints before applying a move;
• distinguish hard safety limits from soft economic preferences;
• recognise infeasible cases before the solver result is trusted;
• include computation timing, measurement age, stale-state guards and fallback behaviour in the control design;
• check solver output with feasibility, active-set and multiplier evidence;
• translate scaled solver residuals and tolerances back into physical units before release;
• tighten future constraints when model-error evidence accumulates over the prediction horizon;
• prove that terminal predictions leave a credible fallback margin when the next solve is unavailable;
• verify that command quantization and rounding do not turn a feasible continuous first move into an unsafe applied move;
• validate the model over the operating region where constraints matter.

All models here are deliberately compact. A real MPC release would also require plant identification, estimator design, constraint ownership, safety review, software verification, hardware-in-the-loop testing when appropriate, and trend evidence from commissioning.

Release Evidence Notes

Use these worked problems as constraint-handling screens until the controller release evidence proves the same assumptions. A credible MPC release package should connect plant model scope, constraint ownership, sensor freshness, estimator behavior, solver status, active-set evidence, timing statistics, fallback action and operator handover.

For constrained control decisions, the strongest evidence is agreement between model, solver and installed behavior:

• identified model error is measured in the operating region where constraints become active;
• hard constraints have owners, units, physical limits, protection-layer relationships and fallback actions;
• solver reports include feasibility status, active constraints, multiplier signs, residuals, scaling checks and watchdog behavior;
• sample time, communication delay, measurement age, estimator latency, jitter and missed solves are converted into guarded constraints or fallback rules;
• commissioning tests include infeasible cases, actuator saturation, bad data, stale measurements, late solver results, handover and degraded operation.

When those evidence paths disagree, do not trust the displayed first move just because it is inside actuator limits. Identify the wrong model region, stale state, hidden delay, misowned soft constraint, bad solver status, untested fallback or missing terminal guard before enabling automatic operation.

Engineering Boundary Notes

These exercises use compact MPC prediction and constraint screens. They do not replace plant identification, estimator validation, formal constraint ownership, solver qualification, software verification, safety-layer analysis, hardware-in-the-loop testing, operator procedure review or commissioning trend evidence. A feasible predicted move applies only to the stated model, horizon, state estimate, constraints, scaling, solver status and fallback rule.

Separate optimizer feasibility from safe applied control. A continuous solution can become unsafe after quantization, stale measurement, delayed solver return, actuator rate limit, bad estimator state, model mismatch or protection-layer conflict. Release evidence should prove that the first applied move remains valid after timing, scaling, fallback and implementation effects are included.

Common Release Mistakes

• accepting a feasible solver result without checking active constraints, residuals, scaling and status flags;
• treating soft economic constraints as if they were hard safety or equipment limits;
• validating normal operation while skipping stale data, late solve, infeasible case and fallback tests;
• applying continuous first moves after rounding or quantization without rechecking feasibility;
• using one identified model outside the operating region where constraints become active;
• enabling automatic MPC without operator handover, protection-layer ownership and degraded-mode evidence.

Scenario Map

Scenario	Exercises	Engineering decision
Prediction and hard constraints	1, 2, 5, 10, 18	Reject candidate plans that violate output, actuator, rate, quantized-command or tightened limits.
Objective design	3, 4	Compare feasible plans using tracking, movement and soft-constraint penalties.
Real-time implementation	6, 12, 13	Check solver timing, missed deadlines, stale measurements and fallback release evidence.
Model validation and horizon design	7, 8, 16	Verify model error, cumulative uncertainty and horizons long enough to see delayed violations.
Solver and commissioning readiness	9, 11, 13, 14, 15, 17	Confirm evidence, blocked moves, first-move behavior, guarded state assumptions, active-set checks, scaling tolerance and terminal feasibility before automatic operation.

Validation Package Checklist

• plant model scope, state estimate, controlled boundary, horizon and sample time are documented;
• hard constraints, soft preferences, units, owners, protection layers and fallback actions are separated;
• solver status, active-set evidence, residuals, scaling, multiplier signs and watchdog behavior are recorded;
• computation timing, measurement age, communication delay, jitter, missed solves and stale-state guards are bounded;
• quantization, command rounding, actuator rate limits and terminal fallback remain feasible for the first applied move;
• commissioning tests cover infeasible cases, saturation, bad data, late solver results, handover and degraded operation;
• final release decision states accept, tighten constraints, retune weights, improve model, modify fallback, restrict mode or hold.

Exercise 1: Check an active output constraint

A heating loop is controlled by an MPC layer. The simplified prediction model is:

where:

• T_k is outlet temperature in ^\circ\text{C};
• u_k is heater command in percent;
• the term 1.5\ ^\circ\text{C} represents heat loss and load removal during one sample.

The current state is:

The operating limit is:

The actuator command must satisfy:

Evaluate whether this candidate command sequence is feasible over three predictions:

Solution

Use the prediction model step by step.

First prediction:

Second prediction:

Third prediction:

The actuator bounds are satisfied because all commands are between 0 percent and 80 percent. The output constraint is not satisfied:

and:

The sequence is infeasible even though the individual actuator values are physically possible.

Engineering Comment

The second predicted sample is where the limit first becomes active. An MPC controller should reject this sequence before it is applied. A conventional controller that only reacts after the measured temperature crosses the limit can be too late when the plant has thermal inertia or measurement delay.

Plausibility Check

The command sequence heats more than the loss term removes after the first step, so temperature should keep rising. Once T_2 is already above 88.5^\circ\text{C}, a larger T_3 is expected.

Exercise 2: Include rate limits in the first move

Use the same model:

The current conditions are:

The constraints are:

Check this candidate sequence:

Solution

First check the rate limits.

The first move is:

The second move is:

The third move is:

All three rate changes satisfy:

Now predict the temperatures.

First prediction:

Second prediction:

Third prediction:

The sequence respects the actuator bounds, rate limits and output limit. It is feasible.

Engineering Comment

Only the first move, u_0=52\%, would be applied. The later moves are provisional. At the next sample, the controller measures the plant again and solves a new optimisation problem. This receding-horizon update is what lets MPC adapt when the disturbance or model state changes.

Plausibility Check

The first and third moves sit exactly at the 12\% rate limit, so this is a boundary-feasible plan. The predicted temperatures rise but remain below 88.5^\circ\text{C}, which is consistent with a feasible constrained solution.

Exercise 3: Compare feasible plans with a quadratic cost

An MPC controller compares two feasible command sequences for the same heating loop. The target temperature is:

Use the cost:

where:

• T_i is the predicted temperature;
• \Delta u_0=u_0-u_{-1};
• u_{-1}=40\%.

Two candidate plans are:

Use:

and:

Which plan has the lower cost?

Solution

Plan A predictions were computed in the previous exercise:

The tracking-error cost is:

The move changes are:

The move penalty is:

Therefore:

Now evaluate plan B.

First prediction:

Second prediction:

Third prediction:

Tracking-error cost:

Move changes:

Move penalty:

Total:

Plan B has the lower cost.

Engineering Comment

Plan A tracks slightly closer early in the horizon, but it moves the actuator more aggressively. With this weight on actuator movement, plan B is preferred. This is not a universal result. If tracking error had a higher consequence, or if actuator wear and valve movement were less important, the weights could justify a different plan.

Plausibility Check

Plan B has slightly worse tracking error but much smaller move penalty. Since the move penalty for plan A is more than four times the move penalty for plan B, the lower total cost for plan B is expected.

Exercise 4: Treat a soft constraint as a penalty

An MPC controller has already rejected all hard-limit violations. Two remaining feasible plans are compared for a cooling system.

Plan C has tracking cost:

but exceeds a soft compressor-power preference by:

Plan D has tracking cost:

and no soft-constraint violation:

The soft-constraint penalty is:

Which plan is preferred?

Solution

Plan C total cost:

Plan D total cost:

Plan D is preferred because:

Engineering Comment

Soft constraints are useful for economic preferences, comfort targets, smooth operation and noncritical bands. They are not a substitute for hard safety limits. If the power preference represented an electrical protection limit, transformer thermal limit or safety-related envelope, it should not be softened without a separate protection argument.

Plausibility Check

The 6\ \text{kW} soft violation is squared, so its penalty is large enough to dominate plan C’s lower tracking cost. A soft constraint can therefore change the preferred plan even when both plans satisfy hard limits.

Exercise 5: Detect an infeasible hard constraint

A heater-only actuator cannot remove heat. The prediction model is:

where:

• u_k is heater command in percent;
• 0\%\le u_k\le80\%;
• the 1.5\ ^\circ\text{C} term is an unmeasured exothermic load during the next sample.

The current condition is:

The hard operating limit is:

Find whether any admissible u_0 can keep the next predicted temperature at or below the limit.

Solution

Require:

Substitute the model:

The actuator lower bound is:

Therefore no admissible heater command can satisfy the hard limit. The MPC problem is infeasible for this model and current state.

Engineering Comment

This is not a tuning problem. The controller cannot meet the constraint with the available actuator authority. A credible implementation must define fallback behaviour: command minimum heat, stop the setpoint ramp, raise an alarm, transfer to a safe mode, start an independent cooling or shutdown action if available, and record the infeasible optimisation event for review.

Plausibility Check

Even at the minimum heater command, the model predicts a 1.5^\circ\text{C} rise from the exothermic load. Starting at 99.0^\circ\text{C} makes the next-step limit impossible without a cooling or shutdown action.

Exercise 6: Check solver timing against the sample period

An MPC controller runs every:

The implementation timing budget is:

Item	Time
sensor conversion and measurement age	8 ms
network jitter allowance	6 ms
estimator update	10 ms
optimisation solver, 99th percentile	54 ms
command output and zero-order hold update	8 ms
engineering timing guard	10 ms

1. Does the 99th percentile timing meet the sample deadline?
2. If the observed worst-case solver time is 74 ms, does the controller still meet the deadline?

Solution

For the 99th percentile budget:

Since:

the 99th percentile timing fits the nominal sample deadline.

Now use the observed worst-case solver time:

Since:

the worst-case timing misses the deadline.

Engineering Comment

Average or 99th percentile timing is not enough for a controller that must act predictably. The design needs defined missed-deadline behaviour: hold previous command, apply a certified fallback command, reduce horizon length, use warm starts, simplify constraints, increase sample period, or move the calculation to hardware with deterministic timing. The plant continues evolving while the solver is late.

Plausibility Check

The nominal timing budget has only 4\ \text{ms} spare, so replacing the 54 ms solver time with a 74 ms worst case must miss the 100 ms sample period. The deadline failure is arithmetically unavoidable.

Exercise 7: Validate prediction error before release

An MPC model is identified for a thermal process:

During a validation run, the command is held at:

and:

The measured temperatures are:

Sample	Measured temperature
T_1	80.6\ ^\circ\text{C}
T_2	81.1\ ^\circ\text{C}
T_3	81.7\ ^\circ\text{C}

The validation rule is:

where:

Does the model pass this three-sample validation check?

Solution

First prediction:

Second prediction:

Third prediction:

Residuals:

The first two residuals pass the rule. The third does not:

The model fails this validation check.

Engineering Comment

The residual grows in one direction, which suggests model bias rather than random noise alone. Before release, the engineer should check load condition, heat-loss estimate, sensor calibration, valve gain, dead time, operating range and whether the validation run matches the region where constraints become active.

Plausibility Check

The model predicts a steady 1.0^\circ\text{C} rise each sample, while measurements rise more slowly. The increasingly negative residuals are consistent with an over-aggressive heat-gain model.

Exercise 8: Choose a horizon long enough to see a delayed violation

A buffer level has delayed actuation. For the next two samples, a discharge command cannot yet affect the buffer because of transport delay. The predicted level therefore rises by 3 percent of capacity per sample for two samples.

At the third prediction, an additional delayed inflow arrives and the model predicts a 5 percent rise if no earlier action was scheduled.

Current level:

Limit:

If the prediction horizon is only two samples, the controller predicts:

If the horizon is three samples and no corrective action has been scheduled early enough, it predicts:

Is a two-sample horizon adequate for protecting this limit?

Solution

With a two-sample horizon, the largest predicted level is:

This appears feasible because:

With a three-sample horizon, the predicted level is:

This violates:

The two-sample horizon is not adequate because it cannot see the delayed violation.

Engineering Comment

The horizon must cover the relevant delay and dominant plant response. A horizon that is shorter than the consequence of the current decision can make a controller look feasible while it is steering toward a future violation. Increasing the horizon is not free: it can increase computation time and model uncertainty. The correct horizon is a design choice tied to delay, plant time constant, constraint severity, solver timing and validation evidence.

Plausibility Check

The two-sample horizon sees levels of 93\% and 96\%, both below the limit. The third sample reaches 101\%, so the two-sample horizon misses exactly the delayed violation it should protect against.

Exercise 9: Decide what evidence is needed before commissioning

An engineering team wants to release an MPC controller for a multivariable oven. The controller limits zone temperatures, heater power, heater ramp rate and product exit temperature. The nominal simulation tracks the recipe well.

List the minimum evidence that should be reviewed before the controller is enabled in automatic operation.

Solution

A reasonable commissioning package should include:

Evidence	What it proves
model identification data	The model was fitted over the operating region where the controller will run.
independent validation data	The model predicts data not used for fitting.
constraint test cases	Hard limits, soft limits and active constraints behave as intended.
infeasibility scenarios	The controller has predictable behaviour when no feasible plan exists.
solver timing records	Optimisation finishes before the control deadline with margin.
fallback command definition	Operators and software know what happens after solver failure, bad data or missed deadline.
sensor and actuator scaling checks	Units, ranges, signs and saturations match the real plant.
trend plots from staged tests	The plant response matches prediction during safe commissioning steps.
change-control record	Weights, horizons, constraints and solver settings are configuration-controlled.
operator handover	Alarms, override modes, constraint status and manual recovery steps are understood.

Engineering Comment

Nominal tracking in simulation is only one part of the evidence. MPC changes plant behaviour most strongly when constraints become active, when the model is wrong, when the solver is late, or when a sensor or actuator is degraded. Commissioning should therefore test the edges of the operating envelope, not only the comfortable centre.

Plausibility Check

The evidence list is intentionally broader than model fit because an MPC release can fail through timing, scaling, fallback behavior or operator handover even when the nominal simulation tracks well.

Exercise 10: Constraint Tightening for Disturbance Uncertainty

An MPC prediction for a thermal loop gives:

The true process may be hotter than the model by one-sigma disturbance uncertainty:

The hard operating limit is:

The release rule tightens the prediction limit by:

before allowing automatic operation. Decide whether the predicted plan passes the tightened constraint.

Solution

The tightened prediction limit is:

The largest predicted value is:

Compare:

The plan violates the tightened constraint by:

The nominal hard limit is not crossed, but the uncertainty-tightened release gate fails.

Engineering Comment

Constraint tightening is a practical way to protect hard limits when model error or disturbances are not negligible. It should be tied to measured validation error, operating region and consequence of violation. Tightening that is too small hides risk; tightening that is too large can make the controller unnecessarily conservative or infeasible.

Plausibility Check

The nominal headroom to the hard limit is 0.7^\circ\text{C}, while the uncertainty guard is 1.0^\circ\text{C}. A tightened-constraint failure is therefore expected.

Exercise 11: Move Blocking and First-move Feasibility

To reduce solver size, an MPC uses move blocking over a four-sample prediction horizon:

and:

The previous command is:

The candidate blocked plan is:

The rate limit is:

Use the same thermal model:

with:

and:

Check rate feasibility and predicted output feasibility.

Solution

Move changes are:

All satisfy the rate limit.

Temperature predictions are:

The largest predicted value is:

The blocked plan is feasible in this simplified screen. Only the first move, u_0=48\%, would be applied before the next optimization.

Engineering Comment

Move blocking reduces the number of decision variables, but it also restricts what the controller can do later in the horizon. It can improve solver timing and robustness, but it may miss a better unblocked trajectory. The blocking pattern should be validated near active constraints, not only in nominal tracking.

Plausibility Check

The plan backs off from 48\% to 36\% before the temperature reaches the limit, so the predicted values approach but do not cross 88.5^\circ\text{C}. The -12\% move sits exactly at the rate limit.

Exercise 12: Empirical Solver-deadline Release

During a hardware-in-the-loop test, an MPC task runs:

control cycles. The deadline is missed:

times. The release criterion allows no more than:

missed deadlines, and every miss must enter the certified fallback command.

Compute the observed miss rate and decide whether the controller can be released on timing evidence.

Solution

Observed missed-deadline rate is:

Allowed missed-deadline count is:

Compare:

The release criterion fails. Even if fallback handled every miss safely, the solver timing is not reliable enough for this release rule.

Engineering Comment

Empirical timing evidence should be treated like a control requirement, not a performance note. If the deadline miss rate is too high, the team can reduce horizon length, warm-start more aggressively, simplify constraints, tune solver tolerances, move computation to deterministic hardware or lengthen the sample period if the plant allows it.

Plausibility Check

The observed miss count is more than three times the allowed count. This is not a borderline release failure and should not be waived without changing the timing design or acceptance rule.

Exercise 13: Measurement Age and Stale-State Constraint Tightening

An MPC task receives a valid temperature measurement:

but the measurement is stale by:

The worst-case unobserved temperature rise is estimated as:

The hard temperature limit is:

The prediction model used by the controller is:

The previous applied command was:

and the rate limit is:

A candidate plan computed from the stale measurement is:

Check whether the plan can be released after guarding for measurement age. Then test the fallback plan:

Solution

First compute the age guard:

The tightened prediction limit is:

Predict the candidate plan from the stale measurement:

The nominal prediction does not cross the hard limit:

but it violates the tightened limit:

The guarded violation is:

The candidate plan must not be released against the stale state.

Now check the fallback plan. Rate changes are:

All satisfy:

Fallback predictions are:

The maximum fallback prediction is:

Compare with the tightened limit:

The fallback plan passes the stale-measurement guard and rate limits in this simplified screen.

Engineering Comment

A numerically feasible plan can be unsafe if it is based on an old state. Measurement age, communication delay, estimator freshness and sensor validity must be part of the constraint calculation, not only part of logging. A practical controller should reject stale data, tighten limits when age is bounded, enter fallback when age is excessive and record the event for commissioning review.

Plausibility Check

The candidate plan has only 0.3^\circ\text{C} nominal headroom to the hard limit, while the stale-measurement guard is 1.2^\circ\text{C}. A guarded failure is therefore expected. The fallback commands reduce heater output at the maximum first allowed rate, so the predicted temperature stops rising and clears the tightened limit.

Exercise 14: Active Rate Constraint and KKT Multiplier Check

A one-step MPC check chooses the next heater command u by minimizing:

with:

The current values are:

and:

The actuator bounds are:

and the first-move rate limit is:

so the upper rate-limited command is:

The solver reports:

with multiplier \lambda=0.20 on the active constraint:

Check the unconstrained optimum, the active constraint, the stationarity residual and whether the multiplier sign supports the solver result.

Solution

Substitute the prediction equation into the objective:

Therefore:

The derivative is:

The unconstrained optimum satisfies:

so:

The unconstrained optimum violates the rate-limited upper command:

so the active-constrained solution should sit at:

Predicted temperature at the reported move:

The objective gradient at the reported move is:

For the active upper constraint g(u)=u-62\le0, stationarity is:

Since:

the multiplier required for stationarity is:

Stationarity residual with the reported multiplier is:

The active constraint residual is:

The multiplier is nonnegative:

The solver result is consistent with this one-dimensional convex QP screen: the unconstrained optimum wants more heat, the rate limit is active, the multiplier has the correct sign, and the stationarity residual is zero in the stated scaling.

Engineering Comment

Solver output should not be accepted only because it returns a command. A release review should check primal feasibility, active constraints, multiplier signs, stationarity residuals, scaling and fallback behavior. A negative multiplier on an active upper bound, a nonzero stationarity residual, or a command outside the rate limit would indicate a formulation, scaling or solver-status problem even if the displayed move looks plausible.

Plausibility Check

The target is far above the one-step predicted temperature, so the unconstrained optimizer wants to increase heater command from 50\% to 70\%. The rate limit allows only 62\%, so the upper rate constraint should be active. A positive multiplier is physically consistent: relaxing the upper rate limit would let the controller reduce tracking error.

Exercise 15: Terminal Feasibility with a One-Step Fallback

An MPC controller for a heated reactor uses the prediction model:

where:

• T_k is reactor temperature in ^\circ\text{C};
• u_k is heater command in percent;
• d_k is an unmeasured heat-release disturbance in ^\circ\text{C} per sample.

The nominal horizon calculation uses:

The hard operating limit is:

Current temperature is:

The controller evaluates this nominal three-move plan:

If the next optimization is unavailable, the certified fallback command is:

for one sample. During that fallback sample, the worst accepted unmeasured heat-release disturbance is:

The release rule requires the terminal prediction T_3 to leave enough margin for that fallback sample:

Check whether the nominal plan passes the hard horizon limit and whether it passes the terminal fallback guard. Then test a revised last move:

Solution

Nominal prediction with the original plan:

The hard horizon limit is not violated:

Now compute the terminal limit implied by the one-step fallback. Since:

the terminal state must satisfy:

The original plan fails this terminal guard:

The predicted fallback temperature would be:

so the one-step fallback case would violate the hard limit.

Now revise only the final planned move to u_2=40\%. The first two predictions stay the same:

The revised terminal prediction is:

Fallback prediction after the revised terminal state:

The revised plan passes the terminal fallback guard with margin:

Engineering Comment

A finite-horizon plan can look feasible inside the displayed prediction window and still leave the plant in a state where the next missed solve has no safe continuation. A terminal constraint is a way to encode that continuation requirement. It does not prove full closed-loop stability by itself, but it forces the horizon result to leave room for fallback, actuator limits, disturbance allowance and the next receding-horizon update.

For a production MPC release, this guard should be tied to the certified fallback action, disturbance evidence, solver-miss statistics, sample time, actuator response, independent protection layers and the consequence of crossing the hard limit. The terminal state should not be treated as a cosmetic end-of-horizon value.

Plausibility Check

The original plan ends only 0.2^\circ\text{C} below the hard limit, but the certified fallback can add 0.4^\circ\text{C} under the accepted disturbance case. The terminal failure is therefore expected. Reducing the last move by 10\% lowers the terminal prediction by 0.4^\circ\text{C} because 0.04(10)=0.4, which exactly creates the needed fallback room plus a small hard-limit margin.

Exercise 16: Cumulative Uncertainty Tightening Over the Horizon

An MPC controller protects a reactor outlet temperature with hard limit:

Validation data in the active constraint region shows that one-step prediction error can be biased high by as much as:

per sample. The release rule uses a conservative cumulative tightening:

where j is the prediction step number. A candidate four-step plan gives nominal predictions:

Check the nominal hard limit, the tightened limits and the release decision. Then check a revised final prediction:

with the first three predictions unchanged.

Solution

The nominal predictions all remain below the hard limit:

so the plan is nominally feasible.

Now compute the cumulative tightened limit at each prediction step.

Step 1:

Step 2:

Step 3:

Step 4:

Tightened margins:

The candidate plan fails the tightened horizon check at step 4 even though it passes the raw hard limit.

For the revised final prediction:

The revised plan passes the cumulative tightening screen, but with only 0.20^\circ\text{C} of final-step margin.

Engineering Comment

A single uncertainty allowance can be misleading when the prediction horizon is long enough for model bias to accumulate. If validation evidence shows one-step error that can repeatedly push the process toward a constraint, later predictions need a larger guard than earlier predictions.

The conservative rule in this exercise is simple, but the release principle is general: model-error evidence should be converted into horizon-dependent constraint guards, not left as a note in the validation report. The guard should be tied to the active operating region, estimator correction, disturbance persistence, sample time, fallback behavior and independent protection layers.

Plausibility Check

The first three nominal predictions have enough headroom for cumulative uncertainty, but the fourth prediction is only 0.9^\circ\text{C} below the hard limit. Four samples of 0.35^\circ\text{C} possible upward error require a 1.4^\circ\text{C} guard, so the fourth-step failure is expected. Reducing the final prediction by 0.7^\circ\text{C} changes the final tightened margin from -0.50^\circ\text{C} to 0.20^\circ\text{C}.

Exercise 17: Constraint Scaling and Solver-Tolerance Gate

An MPC controller protects a reactor outlet temperature with a hard software constraint:

Inside the optimizer, the temperature constraint residual is scaled as:

with:

The solver reports feasibility when:

The current solver tolerance is:

For a candidate first move, the solver report shows:

The release rule allows at most:

of numerical temperature-limit violation after converting all scaled residuals back into physical units. Check whether the current solver result can be released. Then find the maximum scaled solver tolerance compatible with the release rule and test a revised solver setting:

Solution

The solver accepts the current result because:

But the physical temperature violation represented by the scaled residual is:

The corresponding predicted temperature is:

The maximum violation that could be hidden by the current solver tolerance is:

Both the reported physical residual and the tolerance envelope exceed the release allowance:

and:

So the current solver result fails the release screen even though the optimizer reports it as feasible.

The maximum scaled solver tolerance compatible with the physical release allowance is:

The revised solver tolerance passes this numerical screen:

The revised reported physical residual is:

and:

The revised setting passes the simplified scaling-and-tolerance gate. It still needs a hard-limit release review because a small numerical violation is not the same as safety evidence.

Engineering Comment

Scaled optimization variables are necessary in many MPC implementations, but the release decision belongs in physical units. A residual that looks small in normalized form can be too large for a tight temperature, pressure, speed or position limit after the scale factor is restored.

Release evidence should record the scaling basis, physical units, solver feasibility tolerance, maximum hidden physical violation, active constraints, residual signs, fallback action and independent protection relationship. For a hard safety constraint, the numerical tolerance should be inside an explicit guard band rather than consuming the whole physical safety margin.

Plausibility Check

A scale factor of 50^\circ\text{C} makes a residual of only 10^{-3} equal to 0.05^\circ\text{C}. That is small for some thermal processes but too large for a release rule that allows only 0.030^\circ\text{C} numerical violation. Reducing the scaled tolerance from 1.5\times10^{-3} to 5.0\times10^{-4} is therefore a credible correction, and the revised residual of 0.020^\circ\text{C} sits inside the stated numerical allowance.

Exercise 18: Quantized First-Move Constraint Gate

An MPC solver returns a continuous first move for the same simplified heating model:

The current temperature is:

The tightened one-step output limit is:

The previous applied command was:

and the rate limit is:

The continuous optimizer reports:

The installed actuator accepts only 5 percent command increments and the current firmware rounds to the nearest increment before applying the move.

Check the continuous first move, the quantized applied move, the output constraint, the rate constraint and the release decision. Then find the maximum continuous command allowed by the tightened output constraint and the largest safe 5 percent actuator command.

Solution

Continuous first-move prediction:

Continuous output margin:

Continuous rate move:

The continuous optimizer result satisfies the rate limit and just satisfies the tightened output limit.

The actuator command is rounded to the nearest 5 percent increment:

Quantized rate move:

The quantized move still satisfies the rate limit exactly.

Quantized output prediction:

Quantized output margin:

The applied command violates the tightened output constraint even though the continuous solver output looked feasible.

Find the maximum continuous command from the output limit:

The largest 5 percent command that does not exceed this limit is:

Check it:

Safe-command margin:

The release decision is a hold unless command quantization is included inside the prediction, the firmware uses a safe directed-rounding rule near active constraints, or a post-solve quantized feasibility check rejects the rounded move.

Engineering Comment

An MPC controller does not apply mathematics; it applies a command through real firmware and a real actuator. If the optimizer assumes continuous commands but the output stage rounds, clips, rate-limits or deadbands the first move, the applied command can violate a constraint that the solver report marked feasible. Release evidence should include the quantization rule, saturation rule, previous applied command, rate limit, post-solve feasibility check, fallback command and trace showing the exact value sent to the actuator.

Plausibility Check

The continuous result leaves only 0.02^\circ\text{C} of temperature margin, so a 2.4 percent upward rounding is enough to matter. The 5 percent command grid creates a 0.25^\circ\text{C} temperature increment in this model because 0.05(5)=0.25. Rounding from 47.6\% to 50\% therefore adds 0.12^\circ\text{C} relative to the continuous command, turning the small positive margin into a 0.10^\circ\text{C} violation.

Review Table

Check	Result	Interpretation
Active constraint	T_2=89.25^\circ\text{C}	Candidate plan is infeasible despite valid actuator bounds.
Rate-limited plan	T_3=88.1^\circ\text{C}	Feasible at the output and rate boundaries.
Quadratic cost	J_B=7.90<J_A=12.11	Move penalty changes the preferred plan.
Soft constraint	J_D=14.0<J_C=19.4	Soft economic violation can dominate tracking benefit.
Hard infeasibility	u_0\le-12.5\% required	Available heater cannot satisfy the limit.
Timing budget	96\ \text{ms} nominal, 116\ \text{ms} worst case	99th percentile passes; worst case misses.
Validation residual	$	e_3
Horizon length	L_3=101\%	Two-sample horizon misses delayed violation.
Commissioning evidence	10 evidence classes	Release needs edge-case evidence, not only nominal simulation.
Tightened constraint	87.8>87.5^\circ\text{C}	Uncertainty guard blocks automatic operation.
Move blocking	T_4=88.4^\circ\text{C}	Blocked plan is feasible but sits near the limit.
Deadline release	0.17\% miss rate	Fails the 0.05\% timing release criterion.
Measurement age	88.2>87.3^\circ\text{C}	Nominally feasible plan fails the stale-state guard.
KKT active-set check	\lambda=0.20,\ r_s=0.00	Reported solver move is consistent with the active rate limit.
Terminal fallback guard	T_{4,fb}=90.2^\circ\text{C}	Nominal horizon feasibility can fail the next-step fallback case.
Cumulative uncertainty	M_4=-0.50^\circ\text{C}	Nominal hard-limit feasibility can fail horizon-dependent tightening.
Solver scaling tolerance	0.060^\circ\text{C}>0.030^\circ\text{C}	Scaled solver feasibility can fail the physical-unit release rule.
Quantized first move	M_{T,q}=-0.10^\circ\text{C}	Continuous feasibility can fail after actuator command rounding.

Review Checklist

Before accepting an MPC constraint-handling calculation, check:

• whether every hard constraint has an owner, unit, boundary and fallback action;
• whether rate limits are checked from the previous applied command, not only between planned moves;
• whether soft constraints are limited to preferences that can be safely violated;
• whether infeasibility behavior is specified before commissioning;
• whether prediction horizon covers transport delay and dominant plant response;
• whether uncertainty tightening reflects measured validation error in the active constraint region;
• whether model-error guards grow across the horizon when bias or disturbance persistence can accumulate;
• whether stale measurements, estimator age and communication delay are converted into guarded constraints or fallback actions;
• whether move blocking is validated near constraints and not only in nominal tracking;
• whether active constraints, multiplier signs and stationarity residuals are reviewed for solver-output plausibility;
• whether scaled solver residuals and feasibility tolerances are converted back into physical units;
• whether actuator command quantization, rounding, clipping and deadband are included before accepting the first move;
• whether terminal predictions leave enough margin for the certified fallback if the next solve is unavailable;
• whether solver timing is evaluated with missed-deadline statistics and fallback evidence;
• whether commissioning tests include active constraints, bad data, late solver, actuator saturation and operator handover.

Common Mistakes

• Treating a constraint as hard in the optimizer while no physical owner, protection layer, fallback action or operator response exists for that limit.
• Checking rate limits only between planned moves and forgetting the previous applied command, actuator slew limits and manual-mode return.
• Using soft constraints for limits that must never be violated, then hiding unsafe behavior inside a penalty weight.
• Accepting a solver output without checking feasibility status, active constraints, multiplier signs, stationarity residuals, scaling and timeout behavior.
• Validating the model in nominal tracking data while the controller will operate near saturation, rate limits, transport delay or disturbance extremes.
• Applying a one-step uncertainty guard at every horizon point even when model bias can accumulate across predictions.
• Ignoring measurement age, estimator latency and communication jitter until the calculated first move uses stale state information.
• Accepting a scaled solver residual without converting it into physical temperature, pressure, speed or position violation.
• Treating the optimizer first move as applied when actuator resolution, rounding, clipping or deadband changes the actual command.
• Choosing a horizon that looks efficient in nominal operation but cannot see delayed constraint violations or terminal fallback risk.
• Treating move blocking as a harmless computation shortcut without checking first-move feasibility near active constraints.
• Reporting a 99th percentile solve time while missed deadlines, watchdog actions, fallback commands and recovery behavior remain untested.
• Commissioning only smooth setpoint changes and skipping infeasible requests, bad sensors, actuator saturation, operator handover and degraded plant modes.

Summary

Model predictive control is useful because it can rank future control moves while respecting explicit limits. The calculations above show the engineering work behind that statement: predict the response, reject infeasible actions, account for rate limits and quantized actuator commands, choose weights carefully, detect impossible constraints, check active-set solver evidence, convert scaled residuals back into physical units, tighten limits for uncertainty and measurement age, preserve terminal fallback feasibility, respect software deadlines, validate model error and select a horizon that sees the relevant plant behaviour.

The final controller is only as trustworthy as its model, constraints, timing, fallback behaviour and validation evidence.