Design and simulate adaptive and timevarying model predictive controllers
MPC Simulink Library
The Adaptive MPC Controller block uses the following input signals:
Measured plant outputs (mo
)
Reference or setpoint (ref
)
Measured plant disturbance (md
), if any
In addition, the required model
input signal specifies the
prediction model to use when computing the optimal plant manipulated variables
mv
. The linear prediction model can change at each control
interval in response to changes in the real plant at run time. The prediction model can
represent a single LTI plant used for all prediction steps (adaptive MPC mode) or an
array of LTI plants for different prediction steps (timevarying MPC mode). Two common
ways to modify this model are as follows:
Given a nonlinear plant model, linearize it at the current operating point.
Use plant data to estimate parameters in an empirical lineartimevarying (LTV) model.
By default, the block estimates its prediction model states. Since the prediction model parameters change at run time, the static Kalman filter used in the MPC Controller block is inappropriate. Instead, the Adaptive MPC Controller block uses a lineartimevarying Kalman filter (LTVKF). For more information, see Adaptive MPC.
In all other ways, the Adaptive MPC Controller block mimics the MPC Controller block. Since the adaptive version involves additional overhead, use the MPC Controller block unless you need to control a nonlinear plant across a wide range of operating conditions where plant dynamics vary significantly.
Both the Adaptive MPC Controller block and the Multiple MPC Controllers block enable your control system to adapt to changing operating conditions at run time. The following table lists the advantages of using each block.
Block  Adaptive MPC Controller  Multiple MPC Controllers 

Adaptation approach  Update prediction model for a single controller as operating conditions change  Switch between multiple controllers designed for different operating regions 
Advantages 


The Adaptive MPC Controller block has the following parameter groupings:
An mpc
controller object designed at
the nominal operating point. At run time, the controller replaces the original
prediction model (A
, B
,
C
, D
) and nominal values
(U
, Y
, X
,
DX
) with the data specified in the
model
inport at each control instant.
By default, the block assumes all other controller object properties (for example tuning weights, constraints) are constant. You can override this assumption using the options in the Online Features section.
The following restrictions apply to the mpc
controller
object:
It must exist in the MATLAB^{®} workspace.
Its prediction model must be an LTI discretetime, statespace object
with no delays. Use the absorbDelay
command to
convert delays to discrete states. The dimensions of the
A
, B
, C
,
and D
matrices in the prediction determine the
dimensions required by the model
inport
signal.
Specifies the initial controller state. If this parameter is
left blank, the block uses the nominal values that are defined in
the Model.Nominal
property of the mpc
object.
To override the default, create an mpcstate
object
in your workspace, and enter its name in the field.
Connect a bus signal to the model
inport. This
signal modifies the controller object Model.Plant
and
Model.Nominal
properties at the beginning of each
control interval.
The Adaptive MPC Controller requires
Model.Plant
to be an LTI discretetime
statespace object with no delays. The following command extracts the
statespace matrices comprising such a model:
[A,B,C,D] = ssdata(MPCobj.Model.Plant)
The purpose of the model
inport is to replace these
matrices with new ones having the same dimensions, and representing the
same control interval. You must also retain the sequence in which the
input, output, and state variables appear in
Model.Plant
.
When operating in:
Adaptive MPC mode, the bus you connect to the
model
inport must contain the following
signals, each identified by the specified name:
A
—
n_{x}byn_{x}
matrix signal, where
n_{x} is the
number of plant model states.
B
—
n_{x}byn_{u}
matrix signal, where
n_{u} is the
total number of plant model inputs (i.e., manipulated
variables, measured disturbances, and unmeasured
disturbances).
C
—
n_{y}byn_{x}
matrix signal, where
n_{y} is the
number of plant model outputs.
D
—
n_{y}byn_{u}
matrix signal.
X
— Vector signal of length
n_{x},
replacing the controller
Model.Nominal.X
property.
Y
— Vector signal of length
n_{y},
replacing the controller
Model.Nominal.Y
property.
U
— Vector signal of length
n_{u},
replacing the controller
Model.Nominal.U
property.
DX
— Vector signal of length
n_{x},
replacing the controller
Model.Nominal.DX
property. It
must be appropriate for use with a discretetime model
of the assumed control interval. For more information,
see Adaptive MPC.
Timevarying MPC mode, the bus you connect to the
model
inport must contain the following
3–dimensional bus signals:
A
—
n_{x}byn_{x}by(p+1)
matrix signal
B
—
n_{x}byn_{u}by(p+1)
matrix signal
C
—
n_{y}byn_{x}by(p+1)
D
—
n_{y}byn_{u}by(p+1)
matrix signal
X
—
n_{x}by(p+1)
matrix signal
Y
—
n_{y}by(p+1)
matrix signal
U
—
n_{u}by(p+1)
matrix signal
DX
—
n_{x}by(p+1)
matrix signal
Here, p is the controller prediction horizon. For each signal, specify p+1 values representing the model and nominal conditions at each step of the prediction horizon. For more information, see TimeVarying MPC.
One way to form the bus is to use a Bus Creator block.
If your controller uses default state estimation, this inport
is labeled mo
. Connect this inport to the measured
plant output signals. The MPC controller uses measured plant outputs
to improve its state estimates.
To enable custom state estimation, in the General section,
check Use custom estimated states instead of measured outputs.
Checking this option changes the label on this inport to x[kk]
.
Connect a signal that provides estimates of the controller state (plant,
disturbance, and noise model states). Use custom state estimates when
an alternative estimation technique is considered superior to the
builtin estimator or when the states are fully measurable.
The ref
dimension must not change from one control instant to the next.
Each element must be a real number.
When ref
is a 1byn_{y} signal,
where n_{y} is the number of outputs, there is no
reference signal previewing. The controller applies the current reference values across the
prediction horizon.
To use signal previewing, specify ref
as an
Nbyn_{y} signal, where
N is the number of time steps for which you are specifying reference values.
Here, $$1<N\le p$$, and p is the prediction horizon. Previewing usually
improves performance, since the controller can anticipate future reference signal changes. The
first row of ref
specifies the n_{y}
references for the first step in the prediction horizon (at the next control interval k = 1), and so on for N steps. If N < p, the last row designates constant reference values for the remaining p  N steps.
For example, suppose n_{y} =
2 and p =
6. At a given control instant, the signal connected
to the ref
inport is:
[2 5 ← k=1 2 6 ← k=2 2 7 ← k=3 2 8] ← k=4
The signal informs the controller that:
Reference values for the first prediction horizon
step k = 1 are 2
and 5
.
The first reference value remains at 2
,
but the second increases gradually.
The second reference value becomes 8
at
the beginning of the fourth step k =
4 in the prediction horizon.
Both values remain constant at 2
and 8
respectively
for steps 5–6 of the prediction horizon.
mpcpreview
shows how to use reference previewing
in a specific case. For calculation details on the use of the reference
signal, see Optimization Problem.
The
mv
outport provides a signal defining the $${n}_{u}\ge 1$$ manipulated variables for controlling the plant. At each control
instant, the controller updates its mv
outport by solving a
quadratic programming problem using either the default KWIK solver or a custom QP
solver. For more information, see QP Solver.
If the controller detects an infeasible
optimization problem or encounters numerical difficulties in solving an
illconditioned optimization problem, mv
remains at its most
recent successful solution; that is, the controller output freezes.
Otherwise, if the optimization problem is feasible
and the solver reaches the specified maximum number of iterations without finding an optimal
solution, mv
:
Remains at its most recent successful solution if the Optimizer.UseSuboptimalSolution
property of the controller is false
.
Is the suboptimal solution reached after the final iteration if the Optimizer.UseSuboptimalSolution
property of the controller is true
. For more information, see Suboptimal QP Solution.
Add an inport (md
) to which you connect a
measured disturbance signal. The number of measured disturbances defined
for your controller, $${n}_{md}\ge 1$$, must match the
dimensions of the connected disturbance signal.
The number of measured disturbances must not change from one control instant to the next, and each disturbance value must be a real number.
When md
is a 1byn_{md} signal,
there is no measured disturbance previewing. The controller applies the current disturbance values
across the prediction horizon.
To use disturbance previewing, specify md
as an
Nbyn_{md} signal, where
N is the number of time steps for which the measured disturbances are known.
Here, $$1<N\le p+1$$, and p is the prediction horizon. Previewing usually improves
performance, since the controller can anticipate future disturbances. The first row of
md
specifies the n_{md} current
disturbance values (k = 1), with other rows specifying disturbances for subsequent control intervals. If N < p + 1, the controller applies the last row for the remaining p  N + 1 steps.
For example, suppose n_{md} =
2 and p =
6. At a given control instant, the signal connected
to the md
inport is:
[2 5 ← k=0 2 6 ← k=1 2 7 ← k=2 2 8] ← k=3
This signal informs the controller that:
The current MD
values are 2
and 5
at k =
0.
The first MD
remains at 2
,
but the second increases gradually.
The second MD
becomes 8
at the beginning of the third
step k = 3 in the prediction horizon.
Both values remain constant at 2
and 8
respectively
for steps 4–6 of the prediction horizon.
mpcpreview
shows how to use MD
previewing
in a specific case.
For calculation details, see MPC Modeling and QP Matrices.
Add an inport (ext.mv
) to which you connect
a vector signal that contains the actual manipulated variables (MV)
used in the plant. The controller uses this signal to update their
controller state estimates at each control interval. Using this inport
improves state estimation accuracy when the MVs used in the plant
differ from the MVs calculated by the block, for example due to signal
saturation or an override condition.
Using this option can cause an algebraic loop in the Simulink^{®} model,
since there is direct feedthrough from the ext.mv
inport
to the mv
outport. To prevent such algebraic loops,
insert a Memory block or Unit Delay block.
For additional information, see the corresponding section of the MPC Controller block reference page.
If you want one or more manipulated variables (MV) to track
target values that change with time, use this option to add an mv.target
inport.
Connect this port to a target signal with dimension n_{u},
where n_{u} is the number of
MVs.
For this to be effective, the corresponding MV(s) must have nonzero penalty weights (these weights are zero by default).
Add an outport (cost
) that provides the optimal
quadratic programming objective function value at the current time
(a nonnegative scalar). If the controller is performing well and no
constraints have been violated, the value should be small. If the
optimization problem is infeasible, however, the value is meaningless.
(See qp.status
.)
Add an outport (qp.status
) that allows you to monitor the
status of the QP solver.
If a QP problem is solved successfully at a given control interval, the
qp.status
output returns the number of QP solver iterations used in
computation. This value is a finite, positive integer and is proportional to the time
required for the calculations. Thus, a large value means a relatively slow block execution
for this time interval.
The QP solver can fail to find an optimal solution for the following reasons:
qp.status = 0
— The QP solver cannot find a solution within
the maximum number of iterations specified in the mpc
object. In this case, if the Optimizer.UseSuboptimalSolution
property of the MPC controller is false
, the block holds its
mv
output at the most recent successful solution.
Otherwise, it uses the suboptimal solution found during the last solver
iteration.
qp.status = 1
— The QP solver detects an infeasible QP
problem. See Monitoring Optimization Status to Detect Controller Failures
for an example where a large, sustained disturbance drives the OV outside its
specified bounds. In this case, the block holds its mv
output
at the most recent successful solution.
qp.status = 2
— The QP solver has encountered numerical
difficulties in solving a severely illconditioned QP problem. In this case, the
block holds its mv
output at the most recent successful
solution.
In a realtime application, you can use qp.status
to set an alarm or
take other special action.
Add an outport (est.state
) to receive the
controller state estimates, x[kk]
, at each control
instant. These include the plant, disturbance, and noise model states.
Add an outport (mv.seq
) that provides the predicted optimal MV
adjustments (moves) over the entire prediction horizon from k
to
k+p
, where k
is the current time and
p is the prediction horizon. This signal is a
(p+1)byn_{u} matrix,
where and n_{u} is the number of manipulated
variables.
mv.seq
contains the calculated optimal MV moves at time
k+i1
, for i = 1,...,p
. The first row of
mv.seq
is identical to the mv
outport signal,
which is the current MV adjustment applied at time k
. Since the
controller does not calculate optimal control moves at time k+p
, the last
row of mv.seq
duplicates the previous row.
Add an outport (x.seq
) that provides the predicted optimal state
variable sequence over the entire prediction horizon from k
to
k+p
, where k
is the current time and
p is the prediction horizon. This signal is a
(p+1)byn_{x} matrix,
where n_{x} is the number of states in the plant and
unmeasured disturbance models (states from noise models are not included).
x.seq
contains the calculated optimal state values at time
k+i
, for i = 1,...,p
. The first row of
x.seq
contains the current states at time k
as
determined by state estimation.
Add an outport (y.seq
) that provides the predicted optimal output
variable sequence over the entire prediction horizon from k
to
k+p
, where k
is the current time and
p is the prediction horizon. This signal is a
(p+1)byn_{y} matrix,
where and n_{y} is the number of outputs.
y.seq
contains the calculated optimal output values at time
k+i1
, for i = 1,...,p+1
. The first row of
y.seq
contains the current outputs at time k
based
on the estimated states and measured disturbances; it is not the measured output at time
k
.
Replace mo
with the x[kk]
inport for
custom state estimation as described in Required Inports.
To operate your controller in timevarying MPC mode, select this option. When
operating in this mode, connect a 3–dimensional bus signal to the
model
inport as described in Required Inports.
For an example, see TimeVarying MPC Control of a TimeVarying Plant.
Add inport umin
that you can connect to a runtime constraint signal for
manipulated variable lower bounds. This signal is a vector with
n_{u} finite values. The
i
th element of umin
replaces the
ManipulatedVariables(i).Min
property of the controller at run
time.
If a manipulated variable does not have a lower bound specified in the controller object, then the corresponding connected signal value is ignored.
If this parameter is not selected, the block uses the constant constraint values stored
within its mpc
object.
You cannot specify timevarying constraints at run time using a matrix signal.
If the ManipulatedVariables(i).Min
property of the controller is
specified as a vector (that is, the constraint varies over the prediction horizon), the
i
th element of umin
replaces the first finite
entry in this vector, and the remaining values shift to retain the same constraint
profile.
Add inport umax
that you can connect to a runtime constraint signal for
manipulated variable upper bounds. This signal is a vector with
n_{u} finite values. The
i
th element of umax
replaces the
ManipulatedVariables(i).Max
property of the controller at run
time.
If a manipulated variable does not have an upper bound specified in the controller object, then the corresponding connected signal value is ignored.
If this parameter is not selected, the block uses the constant constraint values stored
within its mpc
object.
You cannot specify timevarying constraints at run time using a matrix signal.
If the ManipulatedVariables(i).Max
property of the controller is
specified as a vector (that is, the constraint varies over the prediction horizon), the
i
th element of umax
replaces the first finite
entry in this vector, and the remaining values shift to retain the same constraint
profile.
Add inport ymin
that you can connect to a runtime constraint signal for
output variable lower bounds. This signal is a vector with
n_{y} finite values. The
i
th element of ymin
replaces the
OutputVariables(i).Min
property of the controller at run time.
If an output variable does not have a lower bound specified in the controller object, then the corresponding connected signal value is ignored.
If this parameter is not selected, the block uses the constant constraint values stored
within its mpc
object.
You cannot specify timevarying constraints at run time using a matrix signal.
If the OutputVariables(i).Min
property of the controller is
specified as a vector (that is, the constraint varies over the prediction horizon), the
i
th element of ymin
replaces the first finite
entry in this vector, and the remaining values shift to retain the same constraint
profile.
Add inport ymax
that you can connect to a runtime constraint signal for
output variable upper bounds. This signal is a vector with
n_{y} finite values. The
i
th element of ymax
replaces the
OutputVariables(i).Max
property of the controller at run time.
If an output variable does not have an upper bound specified in the controller object, then the corresponding connected signal value is ignored.
If this parameter is not selected, the block uses the constant constraint values stored
within its mpc
object.
You cannot specify timevarying constraints at run time using a matrix signal.
If the OutputVariables(i).Max
property of the controller is
specified as a vector (that is, the constraint varies over the prediction horizon), the
i
th element of ymax
replaces the first finite
entry in this vector, and the remaining values shift to retain the same constraint
profile.
Add inports E
, F
, G
, and S
to the block that you can connect to the following runtime custom constraint matrix signals:
E
— Manipulated variable constraint matrix with size n_{c}byn_{u}, where n_{c} is the number of custom constraints
F
— Controlled output constraint matrix with size n_{c}byn_{y}
G
— Custom constraint matrix with size 1byn_{c}
S
— Measured disturbance constraint matrix, with size n_{c}byn_{v}, where n_{v} is the number of measured disturbances. S
is added only if the mpc
object has measured disturbances.
These constraints replace the custom constraints previously set using setconstraint
.
If you define E
, F
, G
, or S
in the mpc
object, you must connect a signal to the corresponding inport, and that signal must have the same dimensions as the array specified in the controller. If an array is not defined in the controller object, use a zero matrix with the correct size.
The custom constraints are of the form E
u + F
y + S
v <= G
, where:
u is a vector of manipulated variable values.
y is a vector of predicted plant output values.
v is a vector of measured plant disturbance input values.
For more information, see Constraints on Linear Combinations of Inputs and Outputs.
A controller intended for realtime applications should have "knobs" you can use to tune its performance when it operates with the real plant. This group of optional inports serves that purpose.
Add an inport (y.wt
) that you can connect to a runtime output variable
(OV) weight signal. This signal overrides the Weights.OV
property of the
mpc
object, which establishes the relative importance of OV
reference tracking.
To use the same tuning weights over the prediction horizon, connect
y.wt
to a vector signal with
n_{y} elements, where
n_{y} is the number of controlled outputs.
Each element specifies a nonnegative tuning weight for each controlled output variable. For
more information on specifying tuning weights, see Tune Weights.
To vary the tuning weights over the prediction horizon, connect y.wt
to
a matrix signal with n_{y} columns and up to
p rows, where p is the prediction horizon. Each
row contains the tuning weights for one prediction horizon step. If you specify fewer than
p rows, the tuning weights in the final row apply for the remainder
of the prediction horizon. For more information on varying weights over the prediction
horizon, see TimeVarying Weights and Constraints.
If you do not connect a signal to the y.wt
inport, the block uses the OV
weights specified in your mpc
object.
Add an inport (u.wt
) that you can connect to a runtime manipulated
variable (MV) weight signal. This signal overrides the Weights.MV
property of the mpc
object, which establishes the relative importance
of MV target tracking.
To use the same tuning weights over the prediction horizon, connect
u.wt
to a vector signal with
n_{u} elements, where
n_{u} is the number of manipulated variables.
Each element specifies a nonnegative tuning weight for each manipulated variable. For more
information on specifying tuning weights, see Tune Weights.
To vary the tuning weights over the prediction horizon, connect u.wt
to
a matrix signal with n_{u} columns and up to
p rows, where p is the prediction horizon. Each
row contains the tuning weights for one prediction horizon step. If you specify fewer than
p rows, the tuning weights in the final row apply for the remainder
of the prediction horizon. For more information on varying weights over the prediction
horizon, see TimeVarying Weights and Constraints.
If you do not connect a signal to the u.wt
inport, the block uses the
MV weights specified in your mpc
object.
Add an inport (du.wt
) that you can connect to a runtime manipulated
variable (MV) rate weight signal. This signal overrides the
Weights.MVrate
property of the mpc
object, which
establishes the relative importance of MV changes.
To use the same tuning weights over the prediction horizon, connect
du.wt
to a vector signal with
n_{u} elements, where
n_{u} is the number of manipulated variables.
Each element specifies a nonnegative tuning weight for each manipulated variable rate. For
more information on specifying tuning weights, see Tune Weights.
To vary the tuning weights over the prediction horizon, connect du.wt
to a matrix signal with n_{u} columns and up to
p rows, where p is the prediction horizon. Each
row contains the tuning weights for one prediction horizon step. If you specify fewer than
p rows, the tuning weights in the final row apply for the remainder
of the prediction horizon. For more information on varying weights over the prediction
horizon, see TimeVarying Weights and Constraints.
If you do not connect a signal to the du.wt
inport, the block uses the
MV rate weights specified in your mpc
object.
Add an inport (ecr.wt
), for a scalar nonnegative signal that overrides the
MPCobj.Weights.ECR
property of the mpc
controller.
This inport has no effect unless your controller object defines soft constraints whose
associated ECR values are nonzero.
If there are soft constraints, increasing the ecr.wt
value makes these
constraints relatively harder. The controller then places a higher priority on minimizing
the magnitude of the predicted worstcase constraint violation.
You may not be able to avoid violations of an output variable constraint. Thus, increasing the
ecr.wt
value is often counterproductive. Such an increase causes the
controller to pay less attention to its other objectives and does not help reduce constraint
violations. You usually need to tune ecr.wt
to achieve the proper balance
in relation to the other control objectives.
If you want to vary your prediction and control horizons at run time, select this parameter. Doing so adds the following input ports to the block:
p
— Prediction horizon, specified as positive
integer signal. The prediction horizon signal value must be less than or
equal to the Maximum prediction horizon
parameter.
m
— Control horizon, specified as one of the
following:
Positive integer signal less than or equal to the prediction horizon.
Vector signal of positive integers specifying blocking interval lengths. For more information, see Manipulated Variable Blocking.
At run time, the values of the p
and m
signals override the default horizons specified in the controller object.
For more information, see Adjust Horizons at Run Time.
Specify the maximum prediction horizon value when varying the prediction horizon at run time. This value, P_{max}, is used to define:
The number of rows in the optimal sequence output signals
mv.seq
, x.seq
, and
y.seq
. When varying your prediction horizon at
run time, these signals have
P_{max}+1 rows.
The maximum number of rows for the timevarying weights input signals
y.wt
, u.wt
, and
du.wt
. When varying your prediction horizon at
run time, these signals can have at most
P_{max} rows.
The maximum dimensions of the plant and nominal condition matrices
specified in the model
input signal (when the
Linear TimeVarying (LTV) plants parameter is
selected). When varying your prediction horizon at run time, the third
dimension of these matrices can be at most
P_{max}+1.
To enable this parameter, select the Adjust prediction horizon and control horizon at run time parameter.
For more information, see Adjust Horizons at Run Time.
Specify the block data type of the manipulated variables as one of the following:
double
— Doubleprecision floating point (default)
single
— Singleprecision floating point
If you are implementing the block on a singleprecision target,
specify the output data type as single
.
For an example of doubleprecision and singleprecision simulation and code generation for an MPC controller, see Simulation and Code Generation Using Simulink Coder.
To view the port data types in a model, in the Simulink Editor, select Display > Signals & PortsPort Data Types.
Use the sample time of the parent subsystem as the block sample time. Doing so allows you to conditionally execute this block inside FunctionCall Subsystem or Triggered Subsystem blocks. For an example, see Using MPC Controller Block Inside FunctionCall and Triggered Subsystems.
You must execute FunctionCall Subsystem or Triggered Subsystem blocks at the sample rate of the controller. Otherwise, you can see unexpected results.
To view the sample time of a block, in the Simulink Editor, select Display > Sample Time. Select Colors, Annotations, or All. For more information, see View Sample Time Information (Simulink).
Add an inport (switch
) whose input specifies
whether the controller performs optimization calculations. If the
input signal is zero, the controller behaves normally. If the input
signal is nonzero, the MPC Controller block turns off
the controller optimization calculations. This action reduces computational
effort when the controller output is not needed, such as when the
system is operating manually or another controller has taken over.
However, the controller continues to update its internal state estimates
in the usual way. Thus, it is ready to resume optimization calculations
whenever the switch
signal returns to zero. While
controller optimization is off, the MPC Controller block
passes the current ext.mv
signal to the controller
output. If the ext.mv
inport is not enabled, the
controller output is held at the value it had when optimization was
disabled.