Documentation

# Multiple MPC Controllers

Simulate switching between multiple implicit MPC controllers

## Description

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 a list of candidate MPC controllers designed at different operating points within the operating range. 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 enables you to achieve better control when operating conditions change. Using available measurements, you can detect the current operating region at run time and choose the appropriate active controller via the `switch` inport. Switching controllers for different operating regions is a common approach to solving nonlinear control problems using linear control techniques.

To improve efficiency, inactive controllers do not compute optimal control moves. However, to provide bumpless transfer between controllers, the inactive controllers continue to perform state estimation.

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 box; that is, there is no Design button. 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.

• You cannot update custom constraints on linear combinations of inputs and outputs at run time.

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.

Both the Multiple MPC Controllers block and the Adaptive MPC Controller 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 Multiple MPC Controller block has the following parameter groupings:

### Parameters

Cell Array of MPC Controllers

Candidate controllers, specified as:

The specified array must contain at least two candidate controllers. The first entry in the cell array is the controller that corresponds to a switch input value of 1, the second corresponds to a switch input value of 2, and so on.

Cell Array of Initial Controller States

Optional initial states for each candidate controller, specified as:

• A cell array of `mpcstate` objects.

• A cell array of character vectors, where each element is the name of an `mpcstate` object in the MATLAB workspace.

• `{[],[],...}` or `{'[]','[]',...}` — Use the nominal condition defined in `Model.Nominal` as the initial state for each controller.

### Required Inports

Controller Selection

The `switch` input signal must be a scalar integer between 1 and nc, where nc is the number of specified candidate controllers. At each control instant, this signal designates the active controller. A switch value of 1 corresponds to the first entry in the cell array of candidate controllers, a value of 2 corresponds to the second controller, and so on.

If the `switch` signal is outside of the range 1 and nc, the previous controller output is retained.

Measured output or State estimate

If candidate controllers use default state estimation, this inport is labeled `mo`. Connect this inport to the measured plant output signals.

If your candidate controllers use custom state estimation, check Use custom estimated states instead of measured outputs in the General section. Checking this 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 tk must be based on the measurements and other data available at time tk.

All candidate controllers must use the same state estimation option, either default or custom. When you use custom state estimation, all candidate controllers must have the same dimension.

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. The active controller updates its manipulated variable output by solving a quadratic programming problem using either the default KWIK solver or a custom QP solver. For more information, see QP Solver.

The Multiple MPC Controller block passes the output of the active controller to the `mv` outport.

If the active controller detects an infeasible QP problem or encounters numerical difficulties in solving an ill-conditioned QP problem, `mv` remains at its most recent successful solution, `x.LastMove`.

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

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

• Is the suboptimal solution reached after the final iteration if the `Optimizer.UseSuboptimalSolution` property of the active 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. All candidate controllers use 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.

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

You can configure several 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.

#### 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 QP solver for the active controller.

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`) for the active controller state estimates, `x[k|k]`, at each control instant. These estimates 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. All candidate controllers must use the same state estimation option, either default or custom. When you use custom state estimation, all candidate controllers must have the same dimension.

### Constraints (Online Features Section)

At each control instant, the optional features described below apply to the active controller.

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

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 the active controller.

### Note

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

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

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 the active controller.

### Note

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

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

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 the active controller.

### Note

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

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

If this parameter is not selected, the block uses the constant constraint values stored within the active controller.

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.

### Weights (Online Features Section)

The optional inputs described below function as controller "tuning knobs." By default (or when a signal is unconnected), the stored tuning weights of the active controller apply.

When using these online tuning features, care must be taken to prevent an unexpected change in the active controller. Otherwise, settings intended for a particular candidate controller can instead retune another.

#### 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 the active controller, and these values remain constant.

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

#### 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 `Weights.MVrate` property specified in the active controller, and these values remain constant.

#### Slack variable weight

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.

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

## Compatibility Considerations

expand all

Behavior changed in R2018b