For both implicit and adaptive MPC controllers, you can adjust the prediction and control horizons while the controller operates. Doing so can be useful for:
Efficiently evaluating different horizon choices at run time during prototyping
Adjusting horizons without redeployment after plant dynamics change significantly, such as in a batch process
To adjust the horizons at run time from the command line, at each control interval,
specify the following properties of the
PredictionHorizon — Run-time prediction horizon signal, specified
as a positive integer
ControlHorizon — Run-time control horizon signal, specified as a
positive integer or a vector of positive integers
In Simulink®, to adjust the horizons for an MPC Controller or Adaptive MPC Controller block, select the Adjust prediction horizon and control horizon at run time parameter. Doing so adds the following input ports to the block:
p — Run-time prediction horizon signal, specified as a scalar
m — Run-time control horizon signal, specified as a scalar or
You must specify the maximum prediction horizon using the Maximum prediction
horizon parameter. Doing so ensures that the optimal sequence output ports of
the block (
y.seq) have constant sizes with
pmax+1 rows, where
pmax is the maximum prediction horizon.
Run-time horizon tuning supports code generation in both MATLAB® and Simulink. Generating code for a controller that supports run-time horizon changes allows you to tune your horizon values on your deployed controller hardware.
After tuning the horizon values, to improve the computational efficiency of your final deployed controller, you can generate code for a constant-horizon controller using the tuned values.
Deploying your controller with run-time horizon tuning enabled significantly increases the computational load and memory footprint of your MPC application. If you plan to use run-time horizon tuning only for prototyping to find the proper horizon values, after tuning, ensure that this feature is disabled. You can then generate code with a constant-horizon controller using the tuned values.
If your controller uses manipulated variable blocking and you generate code for your controller, the size of the control horizon vector must remain constant at run-time. In this case, you can still tune the values within the control horizon vector.
To generate code for a controller that uses run-time horizon tuning, your deployed
hardware target must support dynamic memory allocation. For example, if your embedded
system does not support the
malloc C function, then the generated code
will not run.
To generate code in MATLAB, set the
'UseVariableHorizon' name-value argument of
true. At each control interval,
you can then specify the horizons before calling
[configData,stateData,onlineData] = getCodeGenerationData(mpcobj,'UseVariableHorizon',true); ... onlineData.Horizons.p = 10; onlineData.Horizons.m = 3; [u,stateData] = mpcmoveCodeGeneration(configData,stateData,onlineData);
If your application uses controller parameters or signals that vary over the prediction horizon, adjusting the prediction horizon at run time affects the behavior of these time-varying parameters.
If you define time-varying constraints in your controller object, the profile of the constraints across the prediction horizon does not change at run time. If your run-time prediction horizon value pr is:
Greater than the length of the constraint profile specified in your controller, then the controller uses the final value of the constraint profile for the remainder of the prediction horizon
Less than the length of the constraint profile specified in your controller, then the controller truncates the constraint profile after pr steps
For more information on adjusting constraints, see Update Constraints at Run Time and Setting Time-Varying Weights and Constraints with MPC Designer.
To vary tuning weights or specify signal previews across the prediction horizon, you specify signal arrays where the rows correspond to prediction horizon steps.
If you adjust the prediction horizon at run time, it is best practice to define the weight and preview arrays with N rows, where N is based on the maximum prediction horizon pmax according to the following table.
At run time, you specify the first pr rows of each signal array (pr+1 rows for measured disturbances). The controller ignores any extra rows in the arrays.
|Signal Type||Command-Line Usage||Block Input Port||Maximum Number of Rows N|
|MV tuning weights||pma|
|MV rate weights||pmax|
|Reference preview||Input to ||pmax|
|Measured disturbance preview||Input to ||pmax+1|
If you specify any signal array with fewer than pr rows (pr+1 rows for measured disturbances), the controller uses the values from the final row for the remainder of the prediction horizon.
For more information on tuning weights, see Tune Weights at Run Time and Setting Time-Varying Weights and Constraints with MPC Designer.
For more information on previewing reference or measured disturbance signals, see Signal Previewing.
For a linear time-varying MPC controller, you vary the plant model and nominal
conditions across the prediction horizon by passing arrays to
mpcmoveAdaptive or the Adaptive MPC Controller
block, where the first element in each array is the current value and each additional
array element corresponds to a prediction horizon step.
If you adjust the prediction horizon at run time, it is best practice to define the plant model and nominal condition arrays with pmax+1 elements. At run time, you specify the first pr+1 elements of each array and the controller ignores the extra elements.
If you specify either array with fewer than pr+1 elements, the controller uses the final element for the remainder of the prediction horizon.
For more information on linear time-varying MPC, see Time-Varying MPC.