# Multiple MPC Controllers

Simulate switching between multiple MPC controllers

## Description

As for the MPC Controller block, at each control instant the Multiple MPC Controllers block receives the current measured plant output, reference, and measured plant disturbance (if any). In addition, it receives a switching signal that selects the active controller from among a list of two or more candidates. The active controller then solves a quadratic program to determine the optimal plant manipulated variables for the current input signals.

The Multiple MPC Controllers block allows you to achieve better control when operating conditions change. In conventional feedback control, you might compensate for this by gain scheduling. In a similar manner, the Multiple MPC Controllers block allows you to transition between multiple MPC controllers in real-time based on the current conditions. Typically, you design each such controller for a particular region of the operating space. Using the available measurements, you detect the current operating region and choose the appropriate active controller.

The Adaptive MPC Controller block compensates for operating point variations by modifying its prediction model. The advantages of the Multiple MPC Controllers block over Adaptive MPC Controller block are as follows:

• Simpler configuration – There is no need to identify prediction model parameters using online data.

• Its candidate controllers form a limited set that you can test thoroughly.

The Multiple MPC Controllers block lacks several optional features found in the MPC Controller block, as follows:

• You cannot disable optimization. One controller must always be active.

• You cannot initiate a controller design from within the block dialog, that is there is no Design button. You must 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.

## Dialog Box

The MPC Controller block has the following parameter groupings:

### Parameters

Cell Array of MPC Controllers

Cell array containing an ordered list of at least two `mpc` objects, i.e., the candidate controllers. The first entry in the cell array is the controller to be used when the switch input equals 1, the second entry when the switch input equals 2, and so on. These controller objects must exist in your base workspace.

Cell Array of Initial Controller States

Optional cell array containing the initial state of each `mpc` object in the cell array of MPC controllers. Each entry in the cell array of initial controller states must be an `mpcstate` object. The default is the nominal condition defined in each controller object's `Model.Nominal` property.

### Required Inports

Controller Selection

The `switch` input signal must be a scalar integer between 1 and nc, where nc is the number of controllers listed in your block mask. At each control instant, this signal designates the active controller.

Measured output or State estimate

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

If all candidate controllers use custom state estimation, check Use custom estimated states instead of measured outputs in the General tab. Checking that option changes the label on this inport to `x[k|k]`. Connect a signal providing the controller state estimates. (The controller state includes the plant, disturbance, and noise model states.) The estimates supplied at time tk must be based on the measurements and other data available at time tk.

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

Reference

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 $N\left(1\le N\le p\right)$ is the number of time steps for which you are specifying reference values and `p` is the prediction horizon. Each element must be a real number. The `ref` dimension must not change from one control instant to the next.

When `N=1`, you cannot preview. To specify future reference values, choose `N` such that $1 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.

### Required Outports

#### Manipulated Variables

The `mv` outport provides a signal defining the ${n}_{u}\ge 1$ manipulated variables, which are to be implemented in the plant. The controller updates its `mv` outport by solving a quadratic program at each control instant.

#### Measured disturbance

Add an inport (`md`) to which you can connect a measured disturbance signal.

Your measured disturbance signal `(MD)` must be size `N x nmd`, where ${n}_{md}\ge 1$ is the number of measured disturbances defined in the active 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$1 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.

For calculation details, see MPC Modeling and QP Matrices.

#### Externally Supplied MV signals

Add an inport (`ext.mv`) to which you connect the actual manipulated variables (MV) used in the plant. All candidate controllers use this when updating their controller state estimates.

For additional discussion and examples, see the MPC Controller block documentation.

You may configure a number of optional output signals. At each sampling instant, the active controller determines their values. The following describes each briefly. For more details, see the MPC Controller block documentation.

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

#### Optimal control sequence

Add an outport (`mv.seq`) that provides the active controller's computed optimal `MV` sequence for the entire prediction horizon from `k=0` to ```k = p-1```. If 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.

#### Optimization status

Add an outport (`qp.status`) that allows you to monitor the status of the active controller's QP solver.

If a QP problem is solved successfully at a given control interval, the `qp.status` output returns the number of QP solver iterations used in computation. This value is a finite, positive integer and is proportional to the time required for the calculations. Thus, a large value means a relatively slow block execution at this time interval.

The QP solver may fail to find an optimal solution for the following reasons:

• `qp.status = 0` — The QP solver cannot find a solution within the maximum number of iterations specified in the `mpc` object.

• `qp.status = -1` — The QP solver detects an infeasible QP problem. See Monitoring Optimization Status to Detect Controller Failures for an example where a large, sustained disturbance drives the OV outside its specified bounds.

• `qp.status = -2` — The QP solver has encountered numerical difficulties in solving a severely ill-conditioned QP problem.

For all the previous three failure modes, the Multiple MPC Controllers block holds its `mv` output at the most recent successful solution. In a real-time application, you can use status indicator to set an alarm or take other special action.

#### Estimated plant, disturbance, and noise model states

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

### State Estimation (General tab)

#### Use custom estimated states instead of measured outputs

Add the `x[k|k]` inport for custom state estimation as described in Required Inports. All candidate controllers must use the same state estimation option, default or custom. When you use custom state estimation, all candidate controllers must have the same dimension.

### Constraints (Online Features tab)

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

#### Plant input and output limits

Add inports (`umin`, `umax`, `ymin`, `ymax`) that you can connect to run-time constraint signals. If this check box is not selected, the block uses the constant constraint values stored within the active controller.

An unconnected inport is treated as an unbounded signal. The corresponding variable in the `mpc` object must be unbounded.

For connected inports, the following rules apply:

• All connected signals must be finite. Simulink® does not support infinite signals.

• If a variable is unconstrained in the controller object, the connected value is ignored.

### Weights (Online Features tab)

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

When using these online tuning features, you should usually prevent an unexpected change in the active controller. Otherwise, settings intended for a particular candidate controller may instead retune another.

#### Weights on plant outputs

Add an inport (`y.wt`) for a vector signal containing a nonnegative weight for each controlled output variable (OV). This signal overrides the `MPCobj.Weights.OV` property of the active controller, which establishes the relative importance of OV reference tracking.

If you do not connect a signal to the `y.wt` inport, the block uses the OV weights specified in the active controller, and these values remain constant.

#### Weights on manipulated variables

Add an inport (`u.wt`), whose input is a vector signal defining nu nonnegative weights, where nu is the number of manipulated variables (MVs). The input overrides the `MPCobj.Weights.MV` property of the active controller, which establishes the relative importance of MV target tracking.

If you do not connect a signal to the `u.wt` inport, the block uses the `Weights.MV` weights property specified in the active controller, and these values remain constant.

#### Weights on manipulated variable changes

Add an inport (`du.wt`), for a vector signal defining nu nonnegative weights, where nu is the number of manipulated variables (MVs). The input overrides the `MPCobj.Weights.MVrate` property of the active controller, which establishes the relative importance of MV changes.

If you do not connect a signal to the `du.wt` inport, the block uses the `Weights.MVrate` property specified in the active controller, and these values remain constant.

#### Weight on overall constraint softening

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.

### MV Targets (Online Features tab)

#### Targets for manipulated variables

If you want one or more manipulated variable (MV) to track a target value that changes with time, use this option to add an `mv.target` inport to which you can connect the target signal (dimension 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).

### Others tab

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

Specify the output data type as `single` if you are implementing the MPC Controller block on a single-precision target.

For an example of double- and single-precision simulation and code generation for an MPC controller, see Simulation and Code Generation Using Simulink Coder.

To view the port data types in a model, in the Simulink Editor, select Display > Signals & PortsPort Data Types.

#### Inherit sample time

Use the sample time inherited from the parent subsystem as the Multiple MPC Controllers block's sample time.

Inheriting the sample time allows you to conditionally execute the Multiple MPC Controllers block inside the Function-Call Subsystem or Triggered Subsystem blocks. For an example, see Using MPC Controller Block Inside Function-Call and Triggered Subsystems.

 Note:   When you place an MPC controller inside a Function-Call Subsystem or Triggered Subsystem block, you must execute the subsystem at the controller's design sample rate. You may see unexpected results if you use an alternate sample rate.

To view the sample time of a block, in the Simulink Editor, select Display > Sample Time. Select Colors, Annotations, or All. For more information, see View Sample Time Information.