MPC stability

Hello, I was just wondering: Can implementing MPC on a stable linear system, gives unstable closed loop behavior?
In case of PID control, if we make PID more aggressive (increase Kc
beyond some point), stable system gives unstable closed loop behavior. What is equivalent of making controller aggressive in MPC?
To me it seems that MPC will never give unstable closed loop behavior for stable linear system. It can only become infeasible. Need your help to resolve doubt.
Thanks Rahul
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

I'm not an MPC maven by any means, but what I know plus common sense tells me: if you haven't adequately modelled your plant and you place constraints on the system response speed that are overly tight, then the result will be high gains that lead to instability.
Common sense also tells me that if you have modelled not just the system behavior, but you have annotated your model with its uncertainties _and_ your MPC algorithm takes these uncertainties into account then yes, the algorithm won't let you drive the system into instability.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
MPC uses a dynamic model of the process, so if the model is 100 percent accurate, the closed loop response will never go unstable. In practice, models are never 100 percent accurate so the closed loop response can and do go unstable.
With MPC you can adjust weighting coefficients to set the relative importance of keeping each controlled variable close to its required value and also to penalise manipulated variable moves. Adjusting the weights to penalise manipulated variable moves is making the MPC more (or less) aggressive, similar to adjusting the Kc of a PID controller.
For example, if the equivalent dead time to lag ratio of the process is large and you have significant modelling uncertainties, you should detune the MPC by adjusting the weights to penalise MV moves thus detuning the controller, otherwise the closed loop response could become unstable.
Pieter Steenekamp
snipped-for-privacy@gmail.com wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

In addition to the comments already made, plant nonlinearity can result in instability (although purists may argue whether a nonlinearity 'limit cycle' is in that category)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

Many MPC control applications allow the user to set the control horizon. The better the model matches the process the shorter the control horizion can be set and yield a stable system. The shorter the control horizion the more agressive the MPC. Shorter control horizion results in more manipulated variable movement. Low quality models are often compensated by increasing the control horizion.
Tom
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
tom a crit :

Tom, Can u please provide some few explanations about 'control horizon'
tks a lot
Olivier
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
teramo snipped-for-privacy@YAHOO.FR wrote:

The control horizion is when the MPC will have a CV within the CV limits. If the control horizion is set equal to the open loop respones time the MPC can make a single move at time zero bring the CV's within limits and then sit and watch. Shortening the control horizion will speed up the MPC and require additional MV movment.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hello,

Since there are various MPC formulations, the term control horizon may have a slightly different meaning: for example, the "control horizon" can mean the time frame in which the controller may change manipulated variables, subject to constraints. The predictive horizon is the time frame where the controller predicts state and/or output trajectories. Usually, the control horizon is shorter than the predictive horizon and the values of MVs outside the former are kept constant and equal to the last calculated value.
On a related topic: MPC stability may be improved using the endpoint or terminal constraint that forces the state or output variables at the end of the predictive horizon to be equal to the value of the corresponding setpoint.
Hope this helps.
Andrey Romanenko // Ciengis www.ciengis.com
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@gmail.com wrote:

Yes, in theory it can. All MPC algorithms without constraints can be translated into a state space form (Li, Fisher 1989). Then following the standard formula for state-space, the closed loop of MPC solution can be obtained. The closed loop poles are the eigenvalues of (Phi - Kmpc*H) where Phi is the open loop matrix, H is for the observer and Kmpc is a function of the tuning parameters of MPC. See Lee and Morari (1993) for details.
For constrained MPC, it becomes very complicated since the active constraint equations become part of the state space formula. Depending on which constraints are active, the closed loop matrix changes so does the stability. You should be able to find more literatures in mid 90's from Zafiriou.

In practice, I have never seen an unstable MPC application after having done MPC for over 11 years since left school. Soon or later, it would hit some constraints on inputs. Then, the controller is saturated and becomes an open loop problem.
Hope that helps. Kent

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hello every ones...
I am new in model based ctrl so let take all the follow with critical eyes....
First we want to use model based ctrl when normal loop ctrl (PID) is not suitable, (usually because the process brought a significant dead time in the loop).
Model based ctrl is actually DIRECT ctrl, that mean we move the manipulated value (MV) to reach the disered control value SP (CV SP) not based on error (CV SP - CV PV) neither CV PV deviation but directly and only using CV SP, to achive that objective we need to now the steady state equation which is linking MV to CV
e.i: CV = a * MV where (a) is the steady state gain between CV & MV note that is a steady state equation : no matter how long CV will take to reach a * MV
If the steady state equ. match perfectly the process : job is done ! Unfortunetly the process often respond close but never exaclty like we were expecting so finally we got : CV PV = a * MV PV + delta, where delta is a deviation cause by some process disturbances
by comparing what we really have (CV PV real) and what we were expecting to have (CV PV equ) we can extract delta then feed back the control equation. so finaly we have somthing like : MV SP = (CV SP - delta) / a MV SP = CV SP / a - delta / a
where : [CV SP / a] is the direct action (hope 95 % of the action) & [delta / a] is a feed back action based on process deviation (hope no more than 5% of the action)
Conclusion : since disturbances are not functions of MV (that mean disturbances or not linked with the actions we take on MV) there is no reasons than the corrective action on MV produce an 'Over shoot'
but get in mind than if the model time cst we are using to calc deltat is not fitting right the process : during the transition step (when CV SP move and MV move), delta will be reflecting disturbance and model error ( in this case delta is function of MV )
If we plot a trend of delta during transition step and : 1- delta is zero model is perfect and no disturbances affect process 2- delta is not zero but constant (or mooving slowly compare to transition step) : model is good, and disturbance are existing (but correct by the feed back action) 3- delta is mooving during transition step : model accuratie is not good enought
please tell me more if u know Olivier Teramo
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.