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 using one of the following
methods:
Solving a quadratic problem using either the default KWIK solver or a custom QP solver. For more information, see QP Solver.
Solving a nonlinear optimization problem for an economic MPC controller. For more information, see Economic MPC.
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.
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 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.
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.
umin
and umax
are vectors with
n_{u}
elements. ymin
and ymax
are vectors
with n_{y} elements.
If this parameter is not selected, the block uses the constant constraint values stored within the active controller.
If any of these inports are unconnected, their associated variables are treated as unbounded
signals. The corresponding variable in the mpc
object must also
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.
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
) 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.
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).