One of my posts, Improving Gas Plant Throughput and Robustness with MPC, brought a strong response from a reader. Entitled MPC Unsustainable Benefits, it described his experiences applying MPC in a major U.S. oil company over a ten-year period.
He summed up his thoughts, “MPC is an 800-pound gorilla. It can be big and ugly. Benefits are retained by thin threads. Benefits tend to leak.” You can follow the link to read some of his points around design, control models, valve linearization, MPC engineering, and the monolithic nature of MPC models. Even for someone like me not steeped in the wisdom of advanced process control (APC)–it was readily apparent that he is not a fan of model predictive control.
I forward his comments to members of Emerson’s advanced automation consulting team for their thoughts on some of the impassioned points made. Senior process control consultant, Greg Martin, thought the key phrase in this document was, “Large-scale MPCs are monolithic.”
Greg notes that traditionally there have been two approaches to MPC applications:
- The “big matrix”
- Smaller controllers that fit the process applications, working in parallel
An example “big matrix” would be to put a whole gas plant in one controller. An example of smaller controllers would be to have individual MPCs for each column. He believes the perspective of this response is from the “big matrix” view. In that context, many points made are true. From Greg’s experience, they are not true if the smaller controllers are used.
Automation systems like the DeltaV system have embedded model predictive controller function blocks into its library of control blocks precisely to provide automation engineers a way to apply MPC at a unit level like a distillation column, lime kiln, or fermenter. The advanced automation consultants have created a library of SmartProcess applications to fit these process applications.
Greg had some thoughts on specific points raised in the document. “Keep Regulatory Control Loops closed – Suffer from terrible model mismatch errors.” Greg believes the first step in one of these applications is to fix the regulatory loops through tuning or modifications of the existing devices. No amount of advanced control can help if the control valve is improperly sized or not functioning properly. These loops do not necessarily imply a model mismatch.
MPC applications that reflect the objectives that the operating supervisors seek do stay on for a long time in Greg’s experience. The MPC application should be a “white box” that is understood and owned by the operating supervisor.
To the point, “FCC Unit MPC is still being re-designed and re-done at many sites”, Greg believes that most are due to system changes. Applications that have the greatest success and longevity are usually are process-centric. MPC does best when controlling at the process constraints. When the valve position is a constraint, the best approach may be to change the trim of the valve. Altering this trim will necessitate an MPC model update, but controllers that are smaller in scope are easier to update and maintain.
I consulted my trusty friend, Wikipedia, about the history of MPC, and it has been applied since the 1980s. With the march of technological progress, the applications have migrated from the “big matrix” to smaller, unit-level application as the MPC software has moved from host-level computer systems into automation system controllers.
I appreciate the reader and Greg sharing their thoughts and experiences. Join in if you have some thoughts to share.
One quick note, I’m not in the office this week and don’t have access to my podcasting setup, so this week’s posts will not include podcast entries.
