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.

Design and simulate adaptive and time-varying model predictive controllers

## Description

The Adaptive MPC Controller block uses the following input signals:

• Measured plant outputs (`mo`)

• Reference or setpoint (`ref`)

• Measured plant disturbance (`md`), if any

In addition, the required `model` input signal specifies the prediction model to use when computing the optimal plant manipulated variables `mv`. The linear prediction model can change at each control interval in response to changes in the real plant at run time. The prediction model can represent a single LTI plant used for all prediction steps (adaptive MPC mode) or an array of LTI plants for different prediction steps (time-varying MPC mode). Two common ways to modify this model are as follows:

• Given a nonlinear plant model, linearize it at the current operating point.

• Use plant data to estimate parameters in an empirical linear-time-varying (LTV) model.

By default, the block estimates its prediction model states. Since the prediction model parameters change at run time, the static Kalman filter used in the MPC Controller block is inappropriate. Instead, the Adaptive MPC Controller block uses a linear-time-varying Kalman filter (LTVKF). For more information, see Adaptive MPC.

In all other ways, the Adaptive MPC Controller block mimics the MPC Controller block. Since the adaptive version involves additional overhead, use the MPC Controller block unless you need to control a nonlinear plant across a wide range of operating conditions where plant dynamics vary significantly.

Both the Adaptive MPC Controller block and the Multiple MPC Controllers block enable your control system to adapt to changing operating conditions at run time. The following table lists the advantages of using each block.

Adaptation approachUpdate prediction model for a single controller as operating conditions changeSwitch between multiple controllers designed for different operating regions
• Only need to design a single controller offline

• Less run-time computational effort and smaller memory footprint

• More robust to real-life changes in plant conditions

• No need for online estimation of plant model

• Controllers can have different sample time, horizons, and weights

• Prediction models can have different orders or time domains

• Finite set of candidate controllers can be tested thoroughly

## Dialog Box

The Adaptive MPC Controller block has the following parameter groupings:

### Parameters

An `mpc` controller object designed at the nominal operating point. At run time, the controller replaces the original prediction model (`A`, `B`, `C`, `D`) and nominal values (`U`, `Y`, `X`, `DX`) with the data specified in the `model` inport at each control instant.

By default, the block assumes all other controller object properties (for example tuning weights, constraints) are constant. You can override this assumption using the options in the Online Features section.

The following restrictions apply to the `mpc` controller object:

• It must exist in the MATLAB® workspace.

• Its prediction model must be an LTI discrete-time, state-space object with no delays. Use the `absorbDelay` command to convert delays to discrete states. The dimensions of the `A`, `B`, `C`, and `D` matrices in the prediction determine the dimensions required by the `model` inport signal.

#### 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

Model

Connect a bus signal to the `model` inport. This signal modifies the controller object `Model.Plant` and `Model.Nominal` properties at the beginning of each control interval.

The Adaptive MPC Controller requires `Model.Plant` to be an LTI discrete-time state-space object with no delays. The following command extracts the state-space matrices comprising such a model:

`[A,B,C,D] = ssdata(MPCobj.Model.Plant) `

The purpose of the `model` inport is to replace these matrices with new ones having the same dimensions, and representing the same control interval. You must also retain the sequence in which the input, output, and state variables appear in `Model.Plant`.

When operating in:

• Adaptive MPC mode, the bus you connect to the `model` inport must contain the following signals, each identified by the specified name:

• `A`nx-by-nx matrix signal, where nx is the number of plant model states.

• `B`nx-by-nu matrix signal, where nu is the total number of plant model inputs (i.e., manipulated variables, measured disturbances, and unmeasured disturbances).

• `C`ny-by-nx matrix signal, where ny is the number of plant model outputs.

• `D`ny-by-nu matrix signal.

• `X` — Vector signal of length nx, replacing the controller `Model.Nominal.X` property.

• `Y` — Vector signal of length ny, replacing the controller `Model.Nominal.Y` property.

• `U` — Vector signal of length nu, replacing the controller `Model.Nominal.U` property.

• `DX` — Vector signal of length nx, replacing the controller `Model.Nominal.DX` property. It must be appropriate for use with a discrete-time model of the assumed control interval. For more information, see Adaptive MPC.

• Time-varying MPC mode, the bus you connect to the `model` inport must contain the following 3–dimensional bus signals:

• `A`nx-by-nx-by-(p+1) matrix signal

• `B`nx-by-nu-by-(p+1) matrix signal

• `C`ny-by-nx-by-(p+1)

• `D`ny-by-nu-by-(p+1) matrix signal

• `X`nx-by-(p+1) matrix signal

• `Y`ny-by-(p+1) matrix signal

• `U`nu-by-(p+1) matrix signal

• `DX`nx-by-(p+1) matrix signal

Here, p is the controller prediction horizon. For each signal, specify p+1 values representing the model and nominal conditions at each step of the prediction horizon. For more information, see Time-Varying MPC.

One way to form the bus is to use a Bus Creator block.

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.

#### 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 manipulated variables (MV) used in the plant. The controller uses 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.

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

For additional information, see the corresponding section of the MPC Controller block reference page.

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

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

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

### Prediction Model (Online Features Section)

#### Linear Time-Varying (LTV) plants

To operate your controller in time-varying MPC mode, select this option. When operating in this mode, connect a 3–dimensional bus signal to the `model` inport as described in Required Inports.

For an example, see Time-Varying MPC Control of a Time-Varying Plant.

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

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

• The maximum dimensions of the plant and nominal condition matrices specified in the `model` input signal (when the Linear Time-Varying (LTV) plants parameter is selected). When varying your prediction horizon at run time, the third dimension of these matrices can be at most Pmax+1.

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

### 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