Simulate switching between multiple implicit MPC controllers
MPC Simulink Library
At each control instant the Multiple MPC Controllers block receives the current measured plant output, reference, and measured plant disturbance (if any). In addition, it receives a switching signal that selects the active controller from a list of candidate MPC controllers designed at different operating points within the operating range. The active controller then solves a quadratic program to determine the optimal plant manipulated variables for the current input signals.
The Multiple MPC Controllers block enables you to achieve better
control when operating conditions change. Using available measurements, you can detect
the current operating region at run time and choose the appropriate active controller
via the switch
inport. Switching controllers for different operating
regions is a common approach to solving nonlinear control problems using linear control
techniques.
To improve efficiency, inactive controllers do not compute optimal control moves. However, to provide bumpless transfer between controllers, the inactive controllers continue to perform state estimation.
The Multiple MPC Controllers block lacks several optional features found in the MPC Controller block, as follows:
You cannot disable optimization. One controller must always be active.
You cannot initiate a controller design from within the block dialog box; that is, there is no Design button. Design all candidate controllers before configuring the Multiple MPC Controllers block.
Similarly, there is no Review button. Instead, use the
review
command or the MPC Designer app.
You cannot update custom constraints on linear combinations of inputs and outputs at run time.
The Adaptive MPC Controller block compensates for operating point variations by modifying its prediction model. The advantages of the Multiple MPC Controllers block over Adaptive MPC Controller block are as follows:
Simpler configuration – There is no need to identify prediction model parameters using online data.
Its candidate controllers form a limited set that you can test thoroughly.
Both the Multiple MPC Controllers block and the Adaptive MPC Controller 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 Multiple MPC Controller block has the following parameter groupings:
Candidate controllers, specified as:
The specified array must contain at least two candidate controllers. The first entry in the cell array is the controller that corresponds to a switch input value of 1, the second corresponds to a switch input value of 2, and so on.
Optional initial states for each candidate controller, specified as:
The switch
input signal must be a scalar
integer between 1 and n_{c},
where n_{c} is the number of
specified candidate controllers. At each control instant, this signal
designates the active controller. A switch value of 1 corresponds
to the first entry in the cell array of candidate controllers, a value
of 2 corresponds to the second controller, and so on.
If the switch
signal is outside of the range
1 and n_{c}, the previous controller
output is retained.
If candidate controllers use default state estimation, this
inport is labeled mo
. Connect this inport to the
measured plant output signals.
If your candidate controllers use custom state estimation, check Use
custom estimated states instead of measured outputs in
the General section. Checking this option changes
the label on this inport to x[kk]
. Connect a signal
providing the controller state estimates. (The controller state includes
the plant, disturbance, and noise model states.) The estimates supplied
at time t_{k} must be based
on the measurements and other data available at time t_{k}.
All candidate controllers must use the same state estimation option, either default or custom. When you use custom state estimation, all candidate controllers must have the same dimension.
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. The active
controller updates its manipulated variable output by solving a quadratic
programming problem using either the default KWIK solver or a custom QP solver.
For more information, see QP Solver.
The Multiple MPC Controller block passes the output of the
active controller to the mv
outport.
If the active controller detects an infeasible QP problem or encounters
numerical difficulties in solving an illconditioned QP problem,
mv
remains at its most recent successful solution,
x.LastMove
.
Otherwise, if the QP problem is feasible and the solver reaches the specified
maximum number of iterations without finding a solution,
mv
:
Remains at its most recent successful solution if the
Optimizer.UseSuboptimalSolution
property of the
active controller is false
.
Is the suboptimal solution reached after the final iteration if the
Optimizer.UseSuboptimalSolution
property of the
active 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. All candidate controllers use 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.
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).
You can configure several optional output signals. At each sampling instant, the active controller determines their values. The following describes each briefly. For more details, see the MPC Controller block documentation.
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 QP solver for the active controller.
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
) for the active controller state
estimates, x[kk]
, at each control instant. These estimates
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. All candidate controllers must use the same state
estimation option, either default or custom. When you use custom state
estimation, all candidate controllers must have the same dimension.
At each control instant, the optional features described below apply to the active controller.
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.
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 the active controller.
You cannot specify timevarying constraints at run time using a matrix signal.
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.
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 the active controller.
You cannot specify timevarying constraints at run time using a matrix signal.
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.
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 the active controller.
You cannot specify timevarying constraints at run time using a matrix signal.
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.
If this parameter is not selected, the block uses the constant constraint values stored within the active controller.
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.
The optional inputs described below function as controller "tuning knobs." By default (or when a signal is unconnected), the stored tuning weights of the active controller apply.
When using these online tuning features, care must be taken to prevent an unexpected change in the active controller. Otherwise, settings intended for a particular candidate controller can instead retune another.
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 the active controller, and these values
remain constant.
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.
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 Weights.MVrate
property specified in the
active controller, and these values remain constant.
Add an inport (ecr.wt
), for a scalar nonnegative signal
that overrides the active controller’s MPCobj.Weights.ECR
property. This inport has no effect unless the active controller defines soft
constraints whose associated ECR values are nonzero.
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).