Note: This page has been translated by MathWorks. Click here to see

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

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

Recommended practice is to choose the control interval duration (controller property
*T _{s}*) initially, and then hold it constant as
you tune other controller parameters. If it becomes obvious that the original choice was
poor, you can revise

Qualitatively, as *T _{s}* decreases, rejection of
unknown disturbance usually improves and then plateaus. The

However, as *T _{s}* becomes small, the
computational effort increases dramatically. Thus, the optimal choice is a balance of
performance and computational effort.

In Model Predictive Control, the prediction horizon, *p* is also an
important consideration. If one chooses to hold the prediction horizon duration (the
product *p***T _{s}*) constant,

Consider the following when choosing
*T _{s}*:

As a rough guideline, set

*T*between 10% and 25% of your minimum desired closed-loop response time._{s}Run at least one simulation to see whether unmeasured disturbance rejection improves significantly when

*T*is halved. If so, consider revising_{s}*T*._{s}For process control,

*T*>> 1 s is common, especially when MPC supervises lower-level single-loop controllers. Other applications, such as automotive or aerospace), can require_{s}*T*< 1 s. If the time needed for solving the QP in real time exceeds the desired control interval, consider the Explicit MPC option._{s}For plants with delays, the number of state variables needed for modeling delays is inversely proportional to

*T*._{s}For open-loop unstable plants, if

*p***T*is too large, such that the plant step responses become infinite during this amount of time, key parameters needed for MPC calculations become undefined, generating an error message._{s}

The controller inherits its time unit from the plant model. Specifically, the
controller uses the `TimeUnit`

property of the plant model LTI object.
This property defaults to seconds.

Suppose that the current control interval is *k*. The
*prediction horizon*, *p*, is the number of future
control intervals the MPC controller must evaluate by prediction when optimizing its MVs at
control interval *k*.

Recommended practice is to choose

*p*early in the controller design and then hold it constant while tuning other controller settings, such as the cost function weights. In other words, do not use*p*adjustments for controller tuning. Rather, the value of*p*should be such that the controller is internally stable and anticipates constraint violations early enough to allow corrective action.If the desired closed-loop response time is

*T*and the control interval is*T*, try_{s}*p*such that*T*≈*pT*._{s}Plant delays impose a lower bound on the possible closed-loop response times. Choose

*p*accordingly. To check for a violation of this condition, use the`review`

command.Recommended practice is to increase

*p*until further increases have a minor impact on performance. If the plant is open-loop unstable, the maximum*p*is the number of control intervals required for the open-loop step response of the plant to become infinite.*p*> 50 is rarely necessary unless*T*is too small._{s}Unfavorable plant characteristics combined with a small

*p*can generate an internally unstable controller. To check for this condition, use the`review`

command, and increase*p*if possible. If*p*is already large, consider the following:Increase

*T*._{s}Increase the cost function weights on MV increments.

Modify the control horizon or use MV blocking (see Manipulated Variable Blocking).

Use a small

*p*with terminal weighting to approximate LQR behavior (See Terminal Weights and Constraints).

The control horizon, *m*, is the number of MV moves to be optimized at
control interval *k*. The control horizon falls between 1 and the
prediction horizon *p*. The default is *m* = 2. Regardless
of your choice for *m*, when the controller operates, the optimized MV move
at the beginning of the horizon is used and any others are discarded.

Reasons to keep *m* << *p* are as
follows:

Small

*m*means fewer variables to compute in the QP solved at each control interval, which promotes faster computations.If the plant includes delays,

*m*<*p*is essential. Otherwise, some MV moves might not affect any of the plant outputs before the end of the prediction horizon, leading to a singular QP Hessian matrix. To check for a violation of this condition, use the`review`

command.Small

*m*promotes (but does not guarantee) an internally stable controller.

You can define the sample time, prediction horizon, and control horizon when creating an
`mpc`

controller at the command line. After creating a controller,
`mpcObj`

, you can modify the sample time and horizons by setting the
following controller properties:

Sample time —

`mpcObj.Ts`

Prediction horizon —

`mpcObj.p`

Control horizon —

`mpcObj.m`

Also, when designing an MPC controller using the **MPC
Designer** app, in the **Tuning** tab, in the
**Horizon** section, you can modify the sample time and horizons.