Documentation

### This is machine translation

Translated by
Mouseover text to see original. Click the button below to return to the English version of the page.

To view all translated materials including this page, select Country from the country navigator on the bottom of this page.

# MPC Controller

Compute MPC control law

## Description

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 programming problem using either the default KWIK solver or a custom QP solver. For more information, see QP Solver.

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 controls.

Because the MPC Controller block uses MATLAB Function blocks, 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.

## Dialog Box

The MPC Controller block has the following parameter groupings:

### Parameters

#### MPC Controller

You must provide an `mpc` object that defines an implicit MPC controller. To do so:

• Enter the name of an `mpc` object in the MPC Controller edit box. This object must be present in the MATLAB workspace.

If you want to modify the controller settings in a graphical environment, open the MPC Designer app by clicking . 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 MATLAB 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 MATLAB workspace, leave the MPC controller field empty. With the MPC Controller block connected to the plant, click to open MPC Designer. Using the app, linearize the Simulink model at a specified operating point, and design your controller. For more information, see Design MPC Controller in Simulink and Linearize Simulink Models Using MPC Designer.

To use this design approach, you must have Simulink Control Design™ software.

Once you specify a controller in the MPC Controller field, you can review your design for run-time stability and robustness issues by clicking . For more information, see Review Model Predictive Controller for Stability and Robustness Issues.

#### Initial controller state

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, and enter its name in the field.

### Required Inports

Measured output or State estimate

If your controller uses default state estimation, this inport is labeled `mo`. Connect this inport to the measured plant output signals. The MPC controller uses measured plant outputs to improve its state estimates.

To enable custom state estimation, in the General section, check Use custom estimated states instead of measured outputs. Checking this option changes the label on this inport to `x[k|k]`. Connect a signal that provides estimates of the controller state (plant, disturbance, and noise model states). Use custom state estimates when an alternative estimation technique is considered superior to the built-in estimator or when the states are fully measurable.

Reference

The `ref` dimension must not change from one control instant to the next. Each element must be a real number.

When `ref` is a 1-by-ny signal, where ny 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 N-by-ny signal, where N is the number of time steps for which you are specifying reference values. Here, $1, 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 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 for the remaining p - N steps.

For example, suppose ny = 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.

### Required Outports

#### Manipulated Variables

The `mv` outport provides a signal defining the ${n}_{u}\ge 1$ manipulated variables for controlling the plant. At each control instant, the controller updates its `mv` outport by solving a quadratic programming problem using either the default KWIK solver or a custom QP solver. For more information, see QP Solver.

If the controller detects an infeasible optimization problem or encounters numerical difficulties in solving an ill-conditioned optimization problem, `mv` remains at its most recent successful solution; that is, the controller output freezes.

Otherwise, if the optimization problem is feasible and the solver reaches the specified maximum number of iterations without finding an optimal solution, `mv`:

• Remains at its most recent successful solution if the `Optimizer.UseSuboptimalSolution` property of the controller is `false`.

• Is the suboptimal solution reached after the final iteration if the `Optimizer.UseSuboptimalSolution` property of the controller is `true`. For more information, see Suboptimal QP Solution.

### Additional Inports (General Section)

#### Measured disturbance

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 1-by-nmd 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 N-by-nmd signal, where N is the number of time steps for which the measured disturbances are known. Here, $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 nmd 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 nmd = 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.

#### External manipulated variable

Add an inport (`ext.mv`) to which you connect a vector signal that contains the actual nu manipulated variables (MV) used in the plant. Use this option when the MV applied to the plant between time tk–1 and tk is different than the optimal MV computed at the last control interval, for example due to signal saturation or an override condition. When enabled, the block uses this signal to correct controller state estimates at tk.

Controller state estimation assumes that the MV is piecewise constant. At time tk, the `ext.mv` value must be the effective MV between times tk–1 and tk. For example, if the MV is actually varying over this interval, you might supply the time-averaged value evaluated at time tk.

The following example, from the model `mpc_bumpless`, includes a switch that can override the controller output with a signal supplied by the operator. Also, the controller output may saturate. Feeding back the actual MV used in the plant (labeled `u(t)` in the example) improves the accuracy of controller state estimates.

If the external MV option is inactive or the `ext.mv` inport in unconnected, the controller assumes that its MV output is used in the plant without modification.

### Note

Using this option can cause an algebraic loop in the Simulink model, since there is direct feedthrough from the `ext.mv` inport to the `mv` outport. To prevent such algebraic loops, insert a Memory block or Unit Delay block.

#### Targets for manipulated variables

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 nu, where nu 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).

### Additional Outports (General Section)

#### Optimal cost

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`.)

#### Optimization status

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 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 ill-conditioned QP problem. In this case, the block holds its `mv` output at the most recent successful solution.

In a real-time application, you can use `qp.status` to set an alarm or take other special action.

The following diagram shows how to use the status indicator to monitor the MPC Controller block in real time. For more information, see Monitoring Optimization Status to Detect Controller Failures.

#### Estimated controller states

Add an outport (`est.state`) to receive the controller state estimates, `x[k|k]`, at each control instant. These include the plant, disturbance, and noise model states.

#### Optimal control sequence

Add an outport (`mv.seq`) that provides the predicted optimal MV adjustments (moves) over the entire prediction horizon from `k` to `k+p`, where `k` is the current time and p is the prediction horizon. This signal is a (p+1)-by-nu matrix, where and nu is the number of manipulated variables.

`mv.seq` contains the calculated optimal MV moves at time `k+i-1`, for `i = 1,...,p`. The first row of `mv.seq` is identical to the `mv` outport signal, which is the current MV adjustment applied at time `k`. Since the controller does not calculate optimal control moves at time `k+p`, the last row of `mv.seq` duplicates the previous row.

#### Optimal state sequence

Add an outport (`x.seq`) that provides the predicted optimal state variable sequence over the entire prediction horizon from `k` to `k+p`, where `k` is the current time and p is the prediction horizon. This signal is a (p+1)-by-nx matrix, where nx is the number of states in the plant and unmeasured disturbance models (states from noise models are not included).

`x.seq` contains the calculated optimal state values at time `k+i`, for `i = 1,...,p`. The first row of `x.seq` contains the current states at time `k` as determined by state estimation.

#### Optimal output sequence

Add an outport (`y.seq`) that provides the predicted optimal output variable sequence over the entire prediction horizon from `k` to `k+p`, where `k` is the current time and p is the prediction horizon. This signal is a (p+1)-by-ny matrix, where and ny is the number of outputs.

`y.seq` contains the calculated optimal output values at time `k+i-1`, for `i = 1,...,p+1`. The first row of `y.seq` contains the current outputs at time `k` based on the estimated states and measured disturbances; it is not the measured output at time `k`.

### State Estimation (General Section)

#### Use custom estimated states instead of using the built-in Kalman filter

Replace `mo` with the `x[k|k]` inport for custom state estimation as described in Required Inports.

### Constraints (Online Features Section)

#### Lower MV limits

Add inport `umin` that you can connect to a run-time constraint signal for manipulated variable lower bounds. This signal is a vector with nu finite values. The `i`th element of `umin` replaces the `ManipulatedVariables(i).Min` property of the controller at run time.

If a manipulated variable does not have a lower bound specified in the controller object, then the corresponding connected signal value is ignored.

If this parameter is not selected, the block uses the constant constraint values stored within its `mpc` object.

### Note

You cannot specify time-varying constraints at run time using a matrix signal.

If the `ManipulatedVariables(i).Min` property of the controller is specified as a vector (that is, the constraint varies over the prediction horizon), the `i`th element of `umin` replaces the first finite entry in this vector, and the remaining values shift to retain the same constraint profile.

#### Upper MV limits

Add inport `umax` that you can connect to a run-time constraint signal for manipulated variable upper bounds. This signal is a vector with nu finite values. The `i`th element of `umax` replaces the `ManipulatedVariables(i).Max` property of the controller at run time.

If a manipulated variable does not have an upper bound specified in the controller object, then the corresponding connected signal value is ignored.

If this parameter is not selected, the block uses the constant constraint values stored within its `mpc` object.

### Note

You cannot specify time-varying constraints at run time using a matrix signal.

If the `ManipulatedVariables(i).Max` property of the controller is specified as a vector (that is, the constraint varies over the prediction horizon), the `i`th element of `umax` replaces the first finite entry in this vector, and the remaining values shift to retain the same constraint profile.

#### Lower OV limits

Add inport `ymin` that you can connect to a run-time constraint signal for output variable lower bounds. This signal is a vector with ny finite values. The `i`th element of `ymin` replaces the `OutputVariables(i).Min` property of the controller at run time.

If an output variable does not have a lower bound specified in the controller object, then the corresponding connected signal value is ignored.

If this parameter is not selected, the block uses the constant constraint values stored within its `mpc` object.

### Note

You cannot specify time-varying constraints at run time using a matrix signal.

If the `OutputVariables(i).Min` property of the controller is specified as a vector (that is, the constraint varies over the prediction horizon), the `i`th element of `ymin` replaces the first finite entry in this vector, and the remaining values shift to retain the same constraint profile.

#### Upper OV limits

Add inport `ymax` that you can connect to a run-time constraint signal for output variable upper bounds. This signal is a vector with ny finite values. The `i`th element of `ymax` replaces the `OutputVariables(i).Max` property of the controller at run time.

If an output variable does not have an upper bound specified in the controller object, then the corresponding connected signal value is ignored.

If this parameter is not selected, the block uses the constant constraint values stored within its `mpc` object.

### Note

You cannot specify time-varying constraints at run time using a matrix signal.

If the `OutputVariables(i).Max` property of the controller is specified as a vector (that is, the constraint varies over the prediction horizon), the `i`th element of `ymax` replaces the first finite entry in this vector, and the remaining values shift to retain the same constraint profile.

#### Custom constraints

Add inports `E`, `F`, `G`, and `S` to the block that you can connect to the following run-time custom constraint matrix signals:

• `E` — Manipulated variable constraint matrix with size nc-by-nu, where nc is the number of custom constraints

• `F` — Controlled output constraint matrix with size nc-by-ny

• `G` — Custom constraint matrix with size 1-by-nc

• `S` — Measured disturbance constraint matrix, with size nc-by-nv, where nv is the number of measured disturbances. `S` is added only if the `mpc` object has measured disturbances.

These constraints replace the custom constraints previously set using `setconstraint`.

If you define `E`, `F`, `G`, or `S` in the `mpc` object, you must connect a signal to the corresponding inport, and that signal must have the same dimensions as the array specified in the controller. If an array is not defined in the controller object, use a zero matrix with the correct size.

The custom constraints are of the form `E`u + `F`y + `S`v <= `G`, where:

• u is a vector of manipulated variable values.

• y is a vector of predicted plant output values.

• v is a vector of measured plant disturbance input values.

For more information, see Constraints on Linear Combinations of Inputs and Outputs.

### Weights (Online Features Section)

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 shows three of the MPC Controller tuning inports. In this simulation context, the inports are tuned using pre-stored signals (the `ywt`, `duwt`, and `ECRwt` variables in the From Workspace blocks). In practice, you would connect a knob or similar manual adjustment.

### Note

You cannot specify time-varying weights at run time using a matrix signal.

#### OV weights

Add an inport (`y.wt`) that you can connect to a run-time output variable (OV) weight signal. This signal overrides the `Weights.OV` property of the `mpc` object, which establishes the relative importance of OV reference tracking.

To use the same tuning weights over the prediction horizon, connect `y.wt` to a vector signal with ny elements, where ny is the number of controlled outputs. Each element specifies a nonnegative tuning weight for each controlled output variable. For more information on specifying tuning weights, see Tune Weights.

To vary the tuning weights over the prediction horizon, connect `y.wt` to a matrix signal with ny columns and up to p rows, where p is the prediction horizon. Each row contains the tuning weights for one prediction horizon step. If you specify fewer than p rows, the tuning weights in the final row apply for the remainder of the prediction horizon. For more information on varying weights over the prediction horizon, see Time-Varying Weights and Constraints.

If you do not connect a signal to the `y.wt` inport, the block uses the OV weights specified in your `mpc` object.

#### MV weights

Add an inport (`u.wt`) that you can connect to a run-time manipulated variable (MV) weight signal. This signal overrides the `Weights.MV` property of the `mpc` object, which establishes the relative importance of MV target tracking.

To use the same tuning weights over the prediction horizon, connect `u.wt` to a vector signal with nu elements, where nu is the number of manipulated variables. Each element specifies a nonnegative tuning weight for each manipulated variable. For more information on specifying tuning weights, see Tune Weights.

To vary the tuning weights over the prediction horizon, connect `u.wt` to a matrix signal with nu columns and up to p rows, where p is the prediction horizon. Each row contains the tuning weights for one prediction horizon step. If you specify fewer than p rows, the tuning weights in the final row apply for the remainder of the prediction horizon. For more information on varying weights over the prediction horizon, see Time-Varying Weights and Constraints.

If you do not connect a signal to the `u.wt` inport, the block uses the MV weights specified in your `mpc` object.

#### MVRate weights

Add an inport (`du.wt`) that you can connect to a run-time manipulated variable (MV) rate weight signal. This signal overrides the `Weights.MVrate` property of the `mpc` object, which establishes the relative importance of MV changes.

To use the same tuning weights over the prediction horizon, connect `du.wt` to a vector signal with nu elements, where nu is the number of manipulated variables. Each element specifies a nonnegative tuning weight for each manipulated variable rate. For more information on specifying tuning weights, see Tune Weights.

To vary the tuning weights over the prediction horizon, connect `du.wt` to a matrix signal with nu columns and up to p rows, where p is the prediction horizon. Each row contains the tuning weights for one prediction horizon step. If you specify fewer than p rows, the tuning weights in the final row apply for the remainder of the prediction horizon. For more information on varying weights over the prediction horizon, see Time-Varying Weights and Constraints.

If you do not connect a signal to the `du.wt` inport, the block uses the MV rate weights specified in your `mpc` object.

#### Slack variable weight

Add an inport (`ecr.wt`), for a scalar nonnegative signal that overrides the `MPCobj.Weights.ECR` property of the `mpc` controller. 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.

### Prediction and Control Horizons (Online Features Section)

#### Adjust prediction horizon and control horizon at run time

If you want to vary your prediction and control horizons at run time, select this parameter. Doing so adds the following input ports to the block:

• `p` — Prediction horizon, specified as positive integer signal. The prediction horizon signal value must be less than or equal to the Maximum prediction horizon parameter.

• `m` — Control horizon, specified as one of the following:

• Positive integer signal less than or equal to the prediction horizon.

• Vector signal of positive integers specifying blocking interval lengths. For more information, see Manipulated Variable Blocking.

At run time, the values of the `p` and `m` signals override the default horizons specified in the controller object.

#### Maximum prediction horizon

Specify the maximum prediction horizon value when varying the prediction horizon at run time. This value, Pmax, is used to define:

• The number of rows in the optimal sequence output signals `mv.seq`, `x.seq`, and `y.seq`. When varying your prediction horizon at run time, these signals have Pmax+1 rows.

• The maximum number of rows for the time-varying weights input signals `y.wt`, `u.wt`, and `du.wt`. When varying your prediction horizon at run time, these signals can have at most Pmax rows.

To enable this parameter, select the Adjust prediction horizon and control horizon at run time parameter.

### Default Conditions Section

Specify the default block sample time and signal dimensions for performing simulation, trimming, or linearization.  In these cases, the `mv` output signal remains at zero. You must specify default condition values that are compatible with your Simulink model design.

### Note

These default conditions apply only if the MPC Controller field is empty. If you specify a controller from the MATLAB workspace, the sample time and signal sizes from the specified controller are used.

#### Sample Time

Specify the default controller sample time.

#### Plant Input Signal Sizes

Specify the default signal dimensions for the following input signal types:

• Manipulated variables

• Unmeasured disturbances

• Measured disturbances

### Note

You can specify the measured disturbances signal dimension only if, on the General section, in the Additional Inports section, the Measured disturbance option is selected.

#### Plant Output Signal Sizes

Specify the default signal dimensions for the following output signal types:

• Measured outputs

• Unmeasured outputs

### Others Section

#### Block data type

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

If you are implementing the block on a single-precision target, specify the output data type as `single`.

For an example of double-precision 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.

#### Inherit sample time

Use the sample time of the parent subsystem as the block sample time. Doing so allows you to conditionally execute this block inside Function-Call Subsystem or Triggered Subsystem blocks. For an example, see Using MPC Controller Block Inside Function-Call and Triggered Subsystems.

### Note

You must execute Function-Call 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).

#### Use external signal to enable or disable optimization

Add an inport (`switch`) whose input specifies whether the controller performs optimization calculations. If the input signal is zero, the controller behaves normally. If the input signal is nonzero, the MPC Controller block turns off the controller optimization calculations. This action reduces computational effort when the controller output is not needed, such as when the system is operating manually or another controller has taken over. However, the controller continues to update its internal state estimates in the usual way. Thus, it is ready to resume optimization calculations whenever the `switch` signal returns to zero. While controller optimization is off, the MPC Controller block passes the current `ext.mv` signal to the controller output. If the `ext.mv` inport is not enabled, the controller output is held at the value it had when optimization was disabled.

## Compatibility Considerations

expand all

Behavior changed in R2018b