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.