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 runtime 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.
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:
A cell array of mpc
objects.
A cell array of character vectors, where each element
is the name of an mpc
object in
the MATLAB^{®} workspace.
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 program at each control instant. The Multiple
MPC Controller block passes the output of the active controller
to the mv
outport.
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 stepk =
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.
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 (mv.seq
) that provides the
active controller's computed optimal MV
sequence
for the entire prediction horizon from k=0
to k
= p1
. If n_{u} is
the number of MVs and p is the length of the prediction
horizon, this signal is a p by n_{u} matrix.
The first row represents k=0
and duplicates the
block's MV outport.
For an example of how to use this option, see Understanding Control Behavior by Examining Optimal Control Sequence.
Add an outport (qp.status
) that allows you
to monitor the status of the active controller's 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. Therefore,
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.
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.
qp.status = 2
— The QP
solver has encountered numerical difficulties in solving a severely
illconditioned QP problem.
For all these failure modes, the block holds its mv
output
at the most recent successful solution. In a realtime application,
you can use status indicator 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.
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 inports (umin
, umax
, ymin
, ymax
)
that you can connect to runtime constraint signals. If this check
box is not selected, the block uses the constant constraint values
stored within the active controller.
An unconnected inport is treated as an unbounded signal. The
corresponding variable in the mpc
object must
be unbounded.
For connected inports, the following rules apply:
All connected signals must be finite. Simulink^{®} does not support infinite signals.
If a variable is unconstrained in the controller object, the connected value is ignored.
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
) for a vector signal
containing a nonnegative weight for each controlled output variable
(OV). This signal overrides the MPCobj.Weights.OV
property
of the active controller, which establishes the relative importance
of OV reference tracking.
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
), whose input is a vector
signal defining nu nonnegative weights, where nu is
the number of manipulated variables (MVs). The input overrides the MPCobj.Weights.MV
property
of the active controller, which establishes the relative importance
of MV target tracking.
If you do not connect a signal to the u.wt
inport,
the block uses the Weights.MV
weights property
specified in the active controller, and these values remain constant.
Add an inport (du.wt
), for a vector signal
defining nu nonnegative weights, where nu is
the number of manipulated variables (MVs). The input overrides the MPCobj.Weights.MVrate
property
of the active controller, which establishes the relative importance
of MV changes.
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.
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).
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.
Note: 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).