MPC: Only one constraint active at one time?

Hello,

as per the Model Predictive Control Toolbox User Guide, the following can be stated about the handling of constraints:

• The slack variable quantifying the severeness of a constraint violation enters the MPC cost function (page 2-9)
• The slack variable is the "worst case constraint violation" (page 2-9)
• The slack variable is a scalar (page 2-10)

From that, I infer the following:

• Exclusion of many constraints: No matter how many constraints are set up in the MPC, only the most severe constraint violation (in terms of cost) makes its way into the MPC cost function
• Exclusion of many time samples: No matter how long the prediction horizon and no matter how long the duration of the constraint violation in the prediction, only the one time step at which the most severe constraint violation (in terms of cost) exists makes its way into the MPC cost function

Are these conclusions correct?

If yes, I wonder why the MPC is implemented like this. From an end-users perspective, I would wish that multiple or all constraints in the MPC can, if necessary, be active at the same time, because constraints usually are not mutually exclusive. Furthermore, I would wish that a constraint violated during multiple prediction time steps will impose more cost on the controller than a violation in only one time step.

Why was the implemented chosen as it was? Was it a design decision (if so, could a Mathworks representative please outline what the rationale was?) or was it due to a algorithmic / numerical motivation?

[Robert Schiemann]

Happy new year everyone! Is there anyone who can shed some light on above question?

Answer 1

[Kyle Rawding]

Hi -

Thanks for reaching out! Your conclusions aren't quite correct - all the constraints defined in MPC are indeed "active" at the same time. What might be causing confusion is how MPC Toolbox uses "soft constraints".

For the sake of computational efficiency, we intentionally chose to use a single "global slack variable" for all the soft constraints, instead of assigning one slack variable to each soft constraint.

For example, say your problem has 10 prediction steps and 2 outputs. If each output has a soft lower bound across the prediction horizon, that would amount to 10*2 = 20 soft constraints in total. One approach would be to define 20 slack variables such that OV(i).Min(j) – slack[i,j] <= y[i,j] where “i” is the OV channel and “j” is the prediction step. This would give you the most flexible soft constrain handling but adds 20 decision variables to the QP problem.

Another approach - used in MPC Toolbox - is to define 1 slack variable such that OV(i).Min(j) – slack * ECR[i,j] <= yi,j. Here “ECR[i,j]” (defined as constant OV(i).MinECR(j) in MPC Toolbox) stands for “Equal Concern for Relaxation”. The larger the ECR value, the more likely the controller will deem it optimal to violate the constraint in order to satisfy your other performance goals. So in practice, you can specify different ECR values for different outputs, to create different effects of "softness". For example, if OV(1).MinECR is 10 and OV(2).MinECR is 1, OV(1) is 10 times softer than OV(2) and MPC Toolbox will choose a slack value such that it cares more about not violating OV(2) bounds instead of OV(1).

In this way, with a single slack variable plus the ECR values, MPC Toolbox only adds 1 extra decision variable to the QP problem. The price we pay is that this implementation focuses on avoiding the "worst case" violation.

Hope that helps-

-Kyle