Simulate switching between multiple MPC controllers
MPC Simulink Library
As for the MPC Controller block, 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 among a list of two or more candidates. 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 allows you to achieve better control when operating conditions change. In conventional feedback control, you might compensate for this by gain scheduling. In a similar manner, the Multiple MPC Controllers block allows you to transition between multiple MPC controllers in real-time based on the current conditions. Typically, you design each such controller for a particular region of the operating space. Using the available measurements, you detect the current operating region and choose the appropriate active controller.
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.
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, that is there is no Design button. You must 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 MPC Controller block has the following parameter groupings:
Cell array containing an ordered list of at least two mpc
objects, i.e., the candidate controllers.
The first entry in the cell array is the controller to be used when
the switch input equals 1, the second entry when the switch input
equals 2, and so on. These controller objects must exist in your base
workspace.
Optional cell array containing the initial state of each mpc
object
in the cell array of MPC controllers. Each entry in the cell array
of initial controller states must be an mpcstate
object.
The default is the nominal condition defined in each controller object's Model.Nominal
property.
The switch
input signal must be a scalar
integer between 1 and n_{c},
where n_{c} is the number of
controllers listed in your block mask. At each control instant, this
signal designates the active controller.
If all candidate controllers use default state estimation, this
inport is labeled mo
. Connect the measured plant
output variables.
If all candidate controllers use custom state estimation, check Use
custom estimated states instead of measured outputs in
the General tab. Checking that option changes the label on this inport
to x[k|k]
. 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, default or custom. When you use custom state estimation, all candidate controllers must have the same dimension.
At each control instant, the ref
signal must
contain the current reference values (targets or setpoints) for the n_{y}
output
variables (ny = n_{ym}+ number of unmeasured
outputs)
. You have the option to specify future reference
values (previewing).
The ref
signal must be size N
by n_{y}
,
where $$N(1\le N\le p)$$ is the number of time steps
for which you are specifying reference values and p
is
the prediction horizon. Each element must be a real number. The ref
dimension
must not change from one control instant to the next.
When N=1
, you cannot preview. To specify
future reference values, choose N
such that $$1<N\le p$$ to enable previewing. Doing
so usually improves performance via feedforward
information.
The first row 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 to be used 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 controller's 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.
The mv
outport provides a signal defining
the $${n}_{u}\ge 1$$ manipulated variables, which
are to be implemented in the plant. The controller updates its mv
outport
by solving a quadratic program at each control instant.
Add an inport (md
) to which you can connect
a measured disturbance signal.
Your measured disturbance signal (MD)
must
be size N x n_{md}
, where $${n}_{md}\ge 1$$ is the number of measured disturbances
defined in the active Model Predictive Controller and $$\text{N(1}\le \text{N}\le \text{p+1)}$$ is the number of time steps
for which the MD is known. Each element must be a real, double-precision
number. The signal dimensions must not change from one control instant
to the next.
If N = 1
, you cannot preview. At each control
instant, the MD
signal must contain the most recent
measurements at the current time k = 0
(as a row
vector, length n_{md}
). The
controller assumes that the MDs
remain constant
at their current values for the entire prediction horizon.
If you are able to predict future MD
values,
choose N
such that$$1<N\le p+1$$ to
enable previewing. Doing so usually improves performance via feedforward
.
In this case, the first row must contain the n_{md}
current
values at k=0
, and the remaining rows designate
variations over the next N-1
control instants.
If N<p+1
, the last row designates constant MD
values
to be used for the remaining p+1-N
steps of the
prediction horizon.
For example, suppose n_{md} = 2
and p
= 6
. At a given control instant, the signal connected to
the controller's 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 MDs
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 step 3 (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
the actual manipulated variables (MV) used in the plant. All candidate
controllers use this when updating their controller state estimates.
For additional discussion and examples, see the MPC Controller block documentation.
You may configure a number of 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
= p-1
. 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.
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. Thus,
a large value means a relatively slow block execution at this time
interval.
The QP solver may 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
ill-conditioned QP problem.
For all the previous three failure modes, the Multiple
MPC Controllers block holds its mv
output
at the most recent successful solution. In a real-time application,
you can use status indicator to set an alarm or take other special
action.
Add an outport (est.state
) to receive the
active controller's state estimates, x[k|k]
,
at each control instant. These include the plant, disturbance and
noise model states.
Add the x[k|k]
inport for custom state estimation
as described in Required Inports.
All candidate controllers must use the same state estimation option,
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 run-time 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 active controller's stored tuning weights apply.
When using these online tuning features, you should usually prevent an unexpected change in the active controller. Otherwise, settings intended for a particular candidate controller may 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 variable (MV) to track a
target value that changes with time, use this option to add an mv.target
inport
to which you can connect the target signal (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
— Double-precision
floating point (default).
single
— Single-precision
floating point.
Specify the output data type as single
if
you are implementing the MPC Controller block on a
single-precision target.
For an example of double- and single-precision 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 inherited from the parent subsystem as the Multiple MPC Controllers block's sample time.
Inheriting the sample time allows you to conditionally execute the Multiple MPC Controllers block inside the Function-Call Subsystem or Triggered Subsystem blocks. For an example, see Using MPC Controller Block Inside Function-Call and Triggered Subsystems.
Note: When you place an MPC controller inside a Function-Call Subsystem or Triggered Subsystem block, you must execute the subsystem at the controller's design sample rate. You may see unexpected results if you use an alternate sample rate. |
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.