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, ue 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.

Was this topic helpful?