# Documentation

### This is machine translation

Translated by
Mouse over text to see original. Click the button below to return to the English verison of the page.

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

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 program at each control instant. The Multiple MPC Controller block passes the output of the active controller to the `mv` outport.

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

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

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

For an example of how to use this option, see Understanding Control Behavior by Examining Optimal Control Sequence.

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

• `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 these failure modes, the 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`) for the active controller state estimates, `x[k|k]`, at each control instant. These estimates include the plant, disturbance, and noise model states.

### State Estimation (General Section)

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

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.

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

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

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

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