Documentation |
Simulate switching between multiple MPC controllers
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 – 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, i.e., there is no Design button. You must design all candidate controllers prior to configuring the Multiple MPC Controllers block.
Similarly, there is no Review button. Instead, use the review command or the design tool for this purpose.
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 $$nu\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 $$nmd(\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$$\text{1<N}\le \text{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 non-negative 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 FailuresMonitoring 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 re-tune 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 non-zero 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. For more information, see Display Port 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.
mpc | MPC Controller | mpcmove | mpcstate