Compute MPC control law
The MPC Controller block receives the current measured output signal (mo), reference signal (ref), and optional measured disturbance signal (md). The block computes the optimal manipulated variables (mv) by solving a quadratic program (QP).
To use the block in simulation and code generation, you must specify an mpc object, which defines a model predictive controller. This controller must have already been designed for the plant that it will control.
Because the MPC Controller block uses MATLAB Function blocks to implement the QP solver, it requires compilation each time you change the MPC object and block. Also, because MATLAB® does not allow compiled code to reside in any MATLAB product folder, you must use a non-MATLAB folder to work on your Simulink® model when you use MPC blocks.
The MPC Controller block has the following parameter groupings:
You must provide an mpc object that defines your controller using one of the following methods:
Enter the name of an mpc object in the MPC Controller edit box. This object must be present in the base workspace.
Clicking Design opens the MPC design tool where you can modify the controller settings in a graphical environment. For example, you can:
Import a new prediction model.
Change horizons, constraints, and weights.
Evaluate MPC performance with a linear plant.
Export the updated controller to the base workspace.
To see how well the controller works for the nonlinear plant, run a closed-loop Simulink simulation.
If you do not have an existing mpc object in the base workspace, leave the MPC controller field empty and, with the MPC Controller block connected to the plant, click Design. This action constructs a default mpc controller by obtaining a linearized model from the Simulink diagram at the default operating point. Continue your controller design in the MPC design tool.
To use this design approach, you must have Simulink Control Design™ software.
Specifies the initial controller state. If this parameter is left blank, the block uses the nominal values that are defined in the Model.Nominal property of the mpc object. To override the default, create an mpcstate object in your workspace that represents the initial state, and enter its name in the field.
At each control instant, the mo signal must contain the current output variable measurements. Let nym be the number of measured output variables (MO) defined in your predictive controller. If nym=1, connect a scalar signal to the mo inport. Otherwise, connect a row or column vector signal containing nym real, double-precision elements.
At each control instant, the ref signal must contain the current reference values (targets or setpoints) for the ny output variables (ny = nym+ number of unmeasured outputs). You have the option to specify future reference values (previewing).
The ref signal must be size N by ny, where 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 double-precision 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 to enable previewing. Doing so usually improves performance via feedforward information. The first row specifies the ny 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 ny=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.
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 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. The elements are real, double-precision values.
Add an inport (md) to which you can connect a measured disturbance signal.
Your measured disturbance signal (MD) must be size Nxnmd, where is the number of measured disturbances defined in your Model Predictive Controller and 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 nmd). 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 to enable previewing. Doing so usually improves performance via feedforward. In this case, the first row must contain the nmd 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 nmd=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.
Add an inport (ext.mv), which you can connect to the actual manipulated variables (MV) used in the plant. The block uses these to update its internal state estimates. For example, suppose the actual signals saturate at physical limits or the MV is under manual control. In both cases, feeding the actual value back to the MPC Controller block can improve performance significantly, because the prediction model's state estimates are updated more accurately.
The following example shows how a manual switch may override the controller's output. Also see Turning Controller Online and Offline with Bumpless TransferTurning Controller Online and Offline with Bumpless Transfer.
Do not connect this option to leave the ext.mv inport unconnected. In either case, the model predictive controller assumes that the plant uses the MV signals sent by the MPC Controller block. In the preceding example, the external MV signal always provides the model predictive controller that the control signal actually used in the plant. Otherwise, the model predictive controller's internal state estimate would be inaccurate.
Note The MPC Controller block is a discrete-time block with sampling time inherited from the MPC object. The MPC block has direct feedthrough from measured outputs (mo), output references (ref), and measured disturbances (md) to MPC-manipulated variables (mv). There is no direct feedthrough from externally supplied manipulated variables (ext.mv) to MPC-manipulated variables (mv).
Add inports (umin,umax,ymin,ymax ), which you can connect to run-time constraint signals. If this check box is not selected, the block uses the constant constraint values stored within its mpc object. Example connections appear in the following model. See Varying Input and Output ConstraintsVarying Input and Output Constraints for an example of using this option.
Each unconnected limit inport, such as ymin in the following model, is treated as an unbounded signal. The corresponding constraint settings in the mpc object must also be unbounded. For connected limit inports, such as ymax, the signals must be finite and the corresponding variables in the mpc object must also be bounded.
All constraint signals connected to the block must be finite. Also, you cannot change the number or identity of constrained and unconstrained variables. For example, if your mpc object specifies that your first MV has a lower bound, you must supply a umin signal for it.
Add an inport (QP Switch) whose input specifies whether the controller performs optimization calculations. If the input signal is zero, the controller behaves normally. If the input signal becomes nonzero, the MPC Controller block turns off the controller's optimization calculations and sets the controller output to zero. These actions save computational effort when the controller output is not needed, such as when the system has been placed in manual operation or another controller has taken over. The controller, however, continues to update its internal state estimate in the usual way. Thus, it is ready to resume optimization calculations whenever the QP Switch signal returns to zero.
If you select this option, the mask automatically selects the Externally supplied MV signal option. Connect this option to the current MV value in the plant. Otherwise, there would be a "bump" each time the QP Switch signal reactivates optimization.
Add an outport (cost) that provides the calculated optimal cost (scalar) of the quadratic program during operation. The computed value is an indication of controller performance. If the controller is performing well, the value is low. However, if the optimization problem is infeasible, this value is meaningless. (See qp.status.)
Add an outport (mv.seq) that provides the controller's computed optimal MV sequence for the entire prediction horizon from k=0 to k=p-1. If nu is the number of MVs and p is the length of the prediction horizon, this signal is a p by nu matrix. The first row represents k=0 and duplicates the block's MV outport.
The following block diagram (from Analysis of Control Sequences Optimized by MPC on a Double Integrator SystemAnalysis of Control Sequences Optimized by MPC on a Double Integrator System) illustrates how to use this option. The diagram shows how to collect diagnostic data and send it to the To Workspace2 block, which creates the variable, useq, in the workspace. Run the example to see how the optimal sequence evolves with time.
Add an outport (qp.status) that allows you to monitor the status of the 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 MPC 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.
The next diagram shows how to use the status indicator to monitor the MPC Controller block in real time. See Monitoring Optimization Status to Detect Controller FailuresMonitoring Optimization Status to Detect Controller Failures for more details.
A controller intended for real-time applications should have "knobs" you can use to tune its performance when it operates with the real plant. This group of optional inports serves that purpose.
The diagram shown below displays the MPC Controller block's three tuning knobs. In this simulation context, the knobs are being tuned by prestored signals (the ywt, duwt, and ECRwt variables in the From Workspace blocks). In practice, you would connect a knob or similar manual adjustment.
Add an inport (y.wt) whose input is a vector signal defining a nonnegative weight for each controlled output variable (OV). This signal overrides the MPCobj.Weights.OV property, which establishes the relative importance of OV reference tracking.
For example, if the preceding controller defined 3 OVs, the signal connected to the y.wt inport should be a vector with 3 elements. If the second element is relatively large, the controller would place a relatively high priority on making OV(2) track the r(2) reference signal. Setting a y.wt signal to zero turns off reference tracking for that OV.
If you do not connect a signal to the y.wt inport, the block uses the OV weights specified in your MPC object, and these values remain constant.
Add an inport (du.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.MVrate property stored in the mpc object.
For example, if your controller defines four MVs and the second du.wt element is relatively large, the controller would use relatively small changes in the second MV. Such move suppression makes the controller less aggressive. However, too much suppression makes it sluggish.
If you do not connect a signal to the du.wt inport, the block uses the MVrate weights property specified in your mpc object, and these values remain constant.
Add an inport (ECR.wt), whose input is a scalar nonnegative signal that overrides the MPC Controller block's MPCobj.Weights.ECR property. This inport has no effect unless your controller object defines soft constraints whose associated ECR values are nonzero.
If there are soft constraints, increasing the ECR.wt value makes these constraints relatively harder. The controller then places a higher priority on minimizing the magnitude of the predicted worst-case constraint violation.
You may not be able to avoid violations of an output variable constraint. Thus, increasing the ECR.wt value is often counterproductive. Such an increase causes the controller to pay less attention to its other objectives and does not help reduce constraint violations. You usually need to tune ECR.wt to achieve the proper balance in relation to the other control objectives.
Specify the data type of the manipulated variables (MV) as one of the following:
double — Double-precision floating point (default).
single — Single-precision floating point.
You specify the output data type as single if you are implementing the model predictive controller 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 MPC Controller block's sample time.
Inheriting the sample time allows you to conditionally execute the MPC Controller 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.