Process Performance Improvement - Part 1

July 12, 2010
Gaining a Perspective on Tools and Metrics for Process Performance
By Greg McMillan and Stan Weiner

Greg McMillan and Stan Weiner bring their wits and more than 66 years of process control experience to bear on your questions, comments, and problems. Write to them at [email protected].

Stan: Last month we discussed the importance of controller tuning and valve response on loop performance. This month we gain a perspective on tools and metrics for process performance from Mike Brown.

Greg: Mike worked on several innovative MPC applications at Solutia. He and I worked together on an MPC application to improve the control of plastic sheets for the safety interlayer of shatter-resistant glass. The application minimized off-spec recycle by controlling the sheet thickness profile while meeting optical quality constraints by manipulating die bolt heaters. It also maximized production rate by controlling sheet speed and average thickness while honoring constraints on extruder speed, resin availability and sheet moisture by manipulating melt flow and sheet line speed.

Stan: Since those days as an MPC consultant, Mike has focused on the bottom-line performance of tools for improving the performance of both basic and advanced control systems in his role as vice president, North America Solutions at Matrikon Inc.

Greg: I connected with Mike again at the 2008 ISA convention as panelists in a session titled "The Future of Process Control." The panel concluded that there were not enough good young engineers entering the field of process control. Dick Morley proposed that we need put a much stronger focus on technology and software tools. Is it really all about getting better tools out there?

Mike: I believe that the issue goes far beyond the tools and should be focused on the delivery of actual performance improvement as opposed to process improvement technology. The tools are just enablers, and the key is the ability to have tools that can support the people in the plants who are responsible for improving the process. To do this, we need to be able to clearly link the understanding and drivers for process improvement with the actions taken, fully supported by the tools and technology. The tools themselves need to be able to reduce people's time and effort and simplify the complexity of the problems we are trying to solve.

Stan: What do you mean by tools?

Mike: The tools I'm talking about really fall into two processes. The first is to ensure that we have good tools to monitor process control performance and, more importantly, how this performance is affecting plant performance. The second is to ensure that we have good tools to improve the performance once opportunities for improvement have been identified. All the monitoring in the world does not make a penny unless people can undertake the effort to fix the problems.

The converse also applies if we have good "fix-it" tools, such as loop-tuning software, that seldom get used because no one explicitly owns the task of ensuring PID performance. There are many good tools available.

We need to be much better at thinking about how these tools need to be used in today's plant environment, especially by young engineers. The tools need to support their abilities and how they do their work. We too often let the tools force a workflow that the plant people cannot support.

We also need to be much better at simplifying the systems requirements side of these tools. We should not need the support of an IT department, a specialist in firewalls or an expert in DCOM settings to install and use process control software aimed at performance improvement. Otherwise, we end up with a situation where the people owning the tools have stronger systems skills than process understanding—and this will not lead to plant performance improvement.

Greg: What is the plant environment situation today?

Mike: At the automation layer, we have too few resources and too many resources managing the systems side of process control. Most large process control initiatives are system configuration and systems upgrades, without clear direction about how these improvements lead to better plant performance. We need to turn this around so that control opportunities are clearly linked to process improvement.

One area for opportunity in today's plant environment is to leverage the capability of the software tools and to move performance improvement to the process/operations engineering layer. If we can get the tools to focus more on productizing some simple workflows for monitoring and fixing the problems, then the technology can help make the transition of ownership to an engineering function that better understands plant performance.

Stan: In what areas are process control tools not delivering?

Mike: The tools are still too often being developed by theoretical control engineers who are simply delivering more technology, more math and more features. The tools are becoming more complex at the systems level—which is the opposite of the direction they need to go, given the shift in plant resources.

We see improvement as adding functionality, where if the real challenge today is people bandwidth and resource flexibility, then we need to be going in the opposite direction. Technology developers need to understand the real performance improvement opportunities. For example, alarm management tools need to ensure that plants are compliant with standards, but the real opportunity in performance is in how alarm management contributes to making better operators, since that is where the money will be.

Greg: We kicked off this year with a four-part series, "Drowning in Data, Starving for Information" (Feb.-May.) How can these tools address this problem?