Model Predictive Control Commissioning Project

This project produces a commissioning and release package for a constrained model predictive control controller. The goal is not to prove that MPC works in simulation. The goal is to prove that the installed controller respects the plant boundary, constraints, timing, fallback behaviour, operator workflow and validation requirements before it is enabled in automatic operation.

The example uses a multizone thermal process, but the workflow transfers to chemical reactors, furnaces, HVAC plants, battery systems, motion axes, aerospace test rigs, robotic cells and other systems where future constraint violations matter.

Project objective

Commission an MPC controller for a two-zone industrial oven. The controller adjusts two heater commands to track product temperature while respecting zone temperature, heater power, heater ramp rate and solver timing limits.

The project deliverable is an engineering release package containing:

• plant boundary and controller authority;
• model identification and validation evidence;
• controlled variables, manipulated variables and measured disturbances;
• hard and soft constraint register;
• objective weights and scaling check;
• solver timing budget;
• infeasibility and fallback behaviour;
• staged commissioning test matrix;
• operator handover and change-control record;
• release decision with open limitations.

The MPC layer is supervisory. Existing hardwired trips and safety interlocks remain independent. The MPC controller may adjust heater setpoints and ramp rates; it may not bypass high-temperature protection, access guards or emergency shutdown functions.

System boundary

Item	Project value
Process	Two-zone continuous oven for a coated product.
Controlled outputs	Product exit temperature, zone 1 air temperature, zone 2 air temperature.
Manipulated variables	Zone 1 heater command, zone 2 heater command.
Measured disturbances	Line speed, inlet product temperature, exhaust damper position.
Sample period	T_s=5\ \text{s}.
Prediction horizon	12 samples, or 60\ \text{s}.
Control horizon	4 samples, or 20\ \text{s}.
Existing protection	Independent high-temperature trip, airflow permissive, heater contactor interlock.
Controller role	Production optimisation and constraint-aware setpoint management.

The release boundary matters. The MPC controller is allowed to improve tracking and reduce overshoot, but it is not credited as the only safety layer. If a zone exceeds the independent trip threshold, the protection system must act regardless of the MPC optimisation result.

Acceptance criteria

Use these commissioning criteria.

Requirement	Acceptance value
Product exit temperature error after a recipe step	\le2.0\ ^\circ\text{C} within 90\ \text{s}
Zone air temperature hard limit	never exceed 185\ ^\circ\text{C} in commissioned tests
Heater command limit	0\%\le u_i\le90\%
Heater ramp-rate limit	$
Solver completion time	\le3.5\ \text{s} per 5\ \text{s} sample, including guard
Infeasible optimisation response	safe fallback within one sample
Manual override	bumpless transfer with documented output freeze or ramp-down
Required evidence	model validation, constraint tests, timing log, fallback tests, operator signoff

These values are project values. A reactor, medical process, flight-control application or safety-instrumented function would require a separate hazard analysis, stronger independence and formal safety lifecycle evidence.

Step 1: Define the model and units

Use a simplified linear discrete model for commissioning checks:

where:

• x_k is the model state vector in ^\circ\text{C} deviation units;
• u_k is the heater command vector in percent;
• d_k is the disturbance vector;
• y_k contains predicted product and zone temperatures;
• k advances every 5\ \text{s}.

For the release package, the model matrices are less important than the boundary evidence:

Model item	Required commissioning evidence
state definition	each state has units, source and physical interpretation
input scaling	percent command in software matches heater power command in the drive or controller
output mapping	predicted outputs align with the historian tags and HMI values
disturbance signs	line-speed and inlet-temperature effects match test trends
operating range	identification data covers recipes, line speeds and loads used by MPC
validation data	model residuals are checked on data not used for fitting

Worked model-validation check

During an independent validation run, the predicted product exit temperature and measured product exit temperature are:

Sample	Predicted	Measured
1	148.0\ ^\circ\text{C}	149.1\ ^\circ\text{C}
2	151.5\ ^\circ\text{C}	152.3\ ^\circ\text{C}
3	155.0\ ^\circ\text{C}	154.4\ ^\circ\text{C}
4	158.0\ ^\circ\text{C}	157.2\ ^\circ\text{C}

The validation rule is:

where:

Compute the residuals:

The largest absolute residual is:

Because:

this validation segment passes the residual screen.

Engineering comment

Passing one segment does not release the model. The release package should also include high and low line-speed cases, warm restart, disturbance changes, low-load operation and the region near active constraints. MPC performance is most fragile where the controller is asked to use the model to avoid a future limit.

Step 2: Build the constraint register

List every limit with an owner and a consequence. Do not bury constraints as anonymous numbers inside the solver configuration.

Constraint	Value	Type	Owner	Consequence if violated
zone 1 air temperature	\le185\ ^\circ\text{C}	hard	process engineering	product damage, trip risk
zone 2 air temperature	\le185\ ^\circ\text{C}	hard	process engineering	product damage, trip risk
heater command	0\% to 90\%	hard	automation	actuator saturation
heater ramp rate	\le12\% per sample	hard	electrical and automation	relay stress, supply disturbance
product target band	\pm1.0\ ^\circ\text{C}	soft	production quality	quality deviation
energy preference	lower heater sum	soft	operations	energy cost
solver deadline	\le3.5\ \text{s}	hard implementation limit	controls/software	stale command

Hard constraints protect equipment, safety, actuator physics or contractual operating envelopes. Soft constraints express preferences or penalties. If a team wants to soften a limit, the release record must state who owns the consequence and why the violation is acceptable.

Step 3: Check one candidate move against limits

At one commissioning point, the current heater commands are:

The MPC solver proposes first moves:

The ramp-rate limit is:

Check whether the first move can be applied.

Solution

For heater 1:

For heater 2:

Heater 2 satisfies the ramp-rate limit. Heater 1 does not:

The first move cannot be applied as proposed.

A clipped admissible heater 1 command is:

Engineering comment

Clipping outside the optimiser can break the predicted plan because the solver believed it would apply 72 percent. The better release requirement is that the optimiser itself enforces the ramp constraint. If an external limiter remains, the model prediction, alarms and fallback behaviour must account for the command actually applied.

Step 4: Confirm solver timing

The controller runs every:

The timing budget is:

Item	Time
input acquisition and validation	0.35\ \text{s}
state estimation	0.45\ \text{s}
optimisation solve, 99th percentile	1.85\ \text{s}
output checks and command write	0.25\ \text{s}
engineering timing guard	0.60\ \text{s}

Acceptance requires the total to be no more than:

Solution

Sum the timing budget:

The budget exactly meets the acceptance value:

There is no unused timing margin.

Engineering comment

Meeting the limit exactly is weak. The team should review worst-case solve time, cold-start solve time, historian load, communication jitter and processor sharing. Good release evidence would either demonstrate deterministic timing margin or define automatic fallback when the solver misses a deadline.

Step 5: Define infeasibility handling

During a disturbance test, the MPC solver reports infeasible because the predicted zone 2 temperature cannot remain below 185\ ^\circ\text{C} while also meeting the production target and heater ramp constraints.

The fallback mode must be specified before commissioning. Use this fallback sequence:

1. hold last valid heater command for one sample only if all measured temperatures are below alarm limits;
2. freeze recipe ramp;
3. command both heaters toward a validated safe standby level at the maximum allowed negative ramp rate;
4. raise an HMI alarm that identifies MPC infeasibility, active constraints and fallback state;
5. require operator acknowledgement and engineering review before re-enabling MPC.

Check the first fallback command if:

safe standby command is:

and:

Solution

The fallback should ramp down toward 40 percent without exceeding the negative ramp limit.

For heater 1:

For heater 2:

Both remain above the standby command, so the first safe-ramp commands are:

Engineering comment

The fallback is not “turn MPC off” as a vague instruction. It is a defined control mode with command limits, alarms, operator workflow and re-enable criteria. If fallback behaviour is not tested, an infeasible optimisation can turn into an undocumented manual intervention.

Step 6: Stage the commissioning tests

Do not jump from simulation to full automatic production. Use staged tests.

Stage	Test	Acceptance evidence
1	shadow-mode prediction only	predictions, residuals and constraint flags are logged while existing control remains active
2	open-loop advisory mode	recommended moves match engineering review, but commands are not applied
3	single-zone limited authority	one manipulated variable is enabled with conservative limits
4	two-zone constrained authority	both heaters are enabled with hard constraints and fallback active
5	recipe disturbance test	line-speed and inlet-temperature changes are handled without limit violations
6	fault and bad-data test	stale input, invalid tag, solver timeout and infeasibility paths are exercised
7	production trial	controlled run with operator signoff and rollback plan

Worked release decision

At the end of stage 4, the evidence is:

Criterion	Result
no hard zone limit violation	pass
product error within 2.0\ ^\circ\text{C} after 90\ \text{s}	pass
solver timing below 3.5\ \text{s}	marginal pass
infeasibility fallback tested	pass
bad sensor data handling tested	not tested
operator handover complete	pass

Can the controller be released to stage 5?

Solution

The controller should not be released to stage 5 yet because bad sensor data handling has not been tested. MPC depends on current state and disturbance measurements. A stale or invalid input can make a mathematically feasible optimisation unsafe for the real plant.

The correct decision is conditional hold:

• keep stage 4 authority disabled or limited;
• run bad-data tests with simulated stale, out-of-range and frozen inputs;
• confirm fallback mode and HMI alarm behaviour;
• only then approve stage 5.

Engineering comment

The marginal solver timing is also a warning. It may not block stage 5 by itself if worst-case timing evidence is acceptable, but it should remain an open risk item. Release decisions should record residual risks explicitly instead of hiding them behind a pass/fail table.

Handover package

The final package should include:

• approved controller boundary and authority;
• model identification and independent validation report;
• constraint register with owners;
• weights, scaling and horizon settings;
• solver version, timing log and hardware target;
• infeasibility and missed-deadline tests;
• fallback mode test record;
• staged commissioning results;
• operator alarm and override instructions;
• rollback plan;
• configuration-control record;
• limitations and retest triggers.

Retest is required after a recipe family changes, heater hardware changes, sensor range changes, zone airflow changes, solver settings change, process dead time changes materially, or operators report repeated constraint alarms.

Project deliverable

The deliverable is a signed MPC commissioning report. It should state whether the controller is:

1. rejected for release;
2. approved only for shadow mode;
3. approved for limited authority;
4. approved for production automatic operation;
5. approved with restrictions and explicit retest triggers.

For the example evidence above, the decision is limited authority pending bad-data testing and timing-margin review.

MPC commissioning is a release of a model, optimiser, software implementation and operating workflow. Treating it as a tuning adjustment is the main failure mode this project is designed to prevent.