APC — Productivity Tool or Shelfware?

Figure 1. The hierarchical approach to APC design identifies the causes of disturbances in each part of the process and then layers solutions that deal with disturbances on top of the basic control system from the bottom up.

Unless implemented with some rather sophisticated decoupling control action, most ARC and ASC strategies tended to ignore multivariable control interactions, that is, the fact that one dependent control variable (CV) can be influenced by more than one independent, manipulated variable (MV). MPC was developed to deal with the multivariable nature of many control problems, and it has become the preferred technology for multivariable control problems and just about any control problem more complicated than simple cascades and ratios.

Prior to MPC, most successful APC engineers used a process engineering-based, hierarchical approach to developing APC solutions (Figure 1). The foundation of the control hierarchy is “basic” process control, and these single loops and simple cascades appear on P&IDs and provide the operator with the first level of regulatory control.

Most process units in refineries and chemical plants are very complex, highly interactive and subject to frequent disturbances. The basic control system is incapable of maintaining fully stable operation when challenged by these disturbances. Thus, the emergence of APC. The hierarchical approach to APC design identifies the causes of disturbances in each part of the process, and then layers solutions that deal with disturbances on top of the basic control system from the bottom up. Each layer adds complexity, and its design depends on the disturbances being dealt with. In reality, the ASC/ARC borderline in Figure 1 is rather fuzzy, and so this picture is somewhat oversimplified, but useful for discussion purposes. Some of the important advantages of this approach are

• Operators can understand the strategies. They appeal to human logic because they use a “systems” approach to problem solving–solving a big problem by breaking the big problem down into smaller problems and solving each of those–and they can be presented to the operator to look like normal cascades;
• The control structure is more suitable for solution at a lower level in the control system and often can be implemented without requiring added hardware and software;
• The controls “degrade gracefully.” When a problem prohibits a higher-level APC from being used, the lower-level controls can still be used and can capture much of the associated benefit.

Figure 2. MPC replaces the entire middle section of Figure 1, and the control hierarchy degrades to this diagram.

MPC replaces the entire middle section of Figure 1, and the control hierarchy degrades to Figure 2. The industry-accepted approach to MPC design is non-hierarchical, that is, the controller outputs directly to basic control set points or valves. There is, in fact, no hierarchy–just one large, flat MPC controller on top of the basic controllers moving all of them at the same time. Operators rarely understand them or what they are doing. In addition, they do not degrade gracefully. They are either “on” or “off.”

Whereas the design of traditional APC considers each individual disturbance at the appropriate level of the hierarchy, MPC attempts to handle all disturbances simultaneously—regardless of the time constant of the disturbance being dealt with. This highlights an important weakness of MPC. Each MPC controller can have only one “time to steady state” or time horizon that the controller considers when making moves at each controller execution. A high-frequency disturbance (a time constant of a few minutes) can’t be compensated for adequately when the time horizon of the controller is hours, rather than minutes, which is almost always the case. The high-frequency disturbance would have been much better handled by a lower level ARC.

There are several other weaknesses of MPC. In many real control situations, even mild model mismatch introduces seriously inappropriate controller moves, leading to inherent instability as the controller tries at each execution to deal with the error between where it thinks it’s going and where it really is.

MPC is not well-suited for processes with non-continuous phases of operation, such as delayed cokers. The problem here is how to “model” the transitory behavior of key control variables during coke drum pre-warming and switching. Unfortunately, every drum switching operation is different. This means that both the “time to steady state” and ultimate CV gain are, at best, only approximations, leading to model mismatch during every single drum operation. No wonder they are so difficult to “tune” during these transitions.

As mentioned earlier, the licensors of MPC software will tell you that their algorithms “optimize” operation by operating at constraints using the least costly combination of manipulated variable assets. That is certainly correct, mathematically, which is the way the LP or QP works. In practice, however, any actual “optimizing” is marginal at best, for two reasons:

• One MV usually dominates others for control of a particular CV, so the controller will tend to use it for control of the CV, regardless of cost;
• The optimum “corners” of the CV/MV space are usually determined by discretionary, operator-driven limits on the MVs or by valve position. These corners would have been pushed by any well-designed APC and would have “optimized” just as well.

When analyzing the MPC controller models that result from plant testing, control engineers often encounter CV/MV relationships that appear inappropriate and which are usually dropped because the engineer doesn’t want that particular MV moved to control that particular CV. Thus, the decoupling benefit that could have been achieved with simpler ASC is lost.

If every combination of variables and constraint limits has not been tested during controller commissioning (as is often the case), then the controller behavior under these untested conditions is unknown and unpredictable. For even moderately sized controllers, the possible combinations become unreasonably large, so that all combinations can’t be tested, even in simulation mode.

Control engineers often drop models from the model matrix to ensure a reasonably stable solution (avoiding approach to a singular matrix in the LP solution). This is most common where controllers are implemented on fractionation columns with high-purity products, and where the controller is expected to meet product purity specifications on both top and bottom products. The model matrix then reduces to one that is almost completely decoupled. In this case, single-loop controllers, rather than an MPC, would be a clearly superior solution.

What about some of the other MPC “selling points?” One that’s often mentioned is that, unlike traditional APC, MPC eliminates the need for custom programming. This is just not true. Except for very simple MPC solutions, custom code is almost always required, for example, to calculate a variable used by the controller to estimate a flow from a valve position, etc.

The benefits of “standardization” are often touted. Using the same tool across the whole organization for all control problems will reduce training and maintenance costs. However, this is like saying that an airline should use Boeing 747s for all routes, regardless of how many passengers are on board. Such an approach ignores the nature of real control problems in refineries and chemical plants and relegates control engineers to “pointers and clickers.”

The above discussion has focused on the overall design philosophy applied to APC implementation. Another critical cause of APC success is management commitment to it. The key ingredient often missing when management decides to invest in MPC is that it represents a “lifelong” commitment. This is because MPC is very complex and requires trained personnel to maintain its effectiveness. MPC controllers, particularly complex ones implemented on complex units with lots of interactions, require lots of babysitting due to changes in the process, such as exchanger fouling and catalyst degradation, changes in operating objectives and targets, personnel changes and others.

In almost all cases, the decision to license and install MPC is a capital expenditure, depreciable over the life of the project. Rarely, if ever, is a decision to allocate annual operating expense money for controller maintenance even considered. Thus, when the MPC implementer completes the project and walks away, there’s nothing in place to support and maintain the controller. A local control engineer may be tasked to do it, but that individual must also perform many other jobs, and these personnel tend to rotate in and out of various jobs, taking knowledge and continuity with them.

How to Avoid Degradation to Shelfware

Perhaps the previous discussion paints an overly pessimistic picture of MPC and APC. Certainly many companies, particularly large refiners, recognize the potential return of MPC, have invested heavily in it, and maintain large, trained staffs to ensure that their MPCs function properly. On the other hand, managers of many other companies have been seduced by the popular myth that MPC is easy to implement and maintain. This misconception is fostered at the highest management levels by those most likely to benefit from proliferation of MPC software.

So, what can companies do to improve effective use of APC and MPC? There are several things, all focused on the way we analyze operating problems and design APC solutions to solve problems. Here are some ideas.

As mentioned earlier, APC’s main goal is to isolate operating units from process disturbances. What does this mean when designing an APC solution? First, identify the disturbance and determine its breadth of influence. Does the disturbance affect the whole unit? If so, how? For example, the most common unit-encompassing disturbance is a feed rate change. But, how is the disturbance propagated? In many process units, this disturbance propagates in one direction only (upstream to downstream) with no other complicating effects. In this case, a straightforward APC solution involves simple ARCs for inventory and load control—adjusting inter-unit flows with feed-forward for inventory control and load related variables. These include distillation column reflux, with ratio controls or with feed-forward action in the case of cascades, for example, controlling a PCTC by adjusting an IRC. No MVC is required here to improve unit stability.

If the effect of the disturbance can be isolated, then design the APC for that isolated part of the unit and ignore potential second-order effects on other parts. A good example is disturbances due to reflux temperature changes on a light-ends distillation column. In this case, simple internal reflux control is adequate. The internal reflux set point can then be used as an MV in a higher level control strategy, for example, to control a pressure-compensated tray temperature (as an indicator of product composition) or an overhead product inferred property.

What about unmeasured disturbances, like feed composition, where the control strategy must react on feedback alone? We’ve had much success with “intelligent” PID feedback control algorithms, which include special logic that determines whether integral action is advised, and then determines the magnitude of the integral move. This improves transient controller response, especially in loops with significant dead time and/or lag. Another successful approach is to use model-based, adaptive control algorithms, such as those incorporated in BrainWave’s products.

Using a hierarchical approach suggests implementing lower-level APC strategies as low in the control system as possible. Most modern DCSs will support a good bit of ARC and ASC at the DCS level. We’re implementing very effective, first-level APC in DCSs from Invensys Foxboro, Yokogawa, Emerson Delta-V and Honeywell.

When available and assuming the analyses are reliable, use lab data as much as possible in designing APCs. Develop inferred property correlations for controlling key product properties and update the model correlations with the lab data.

Track APC performance by calculating, historizing and displaying a variable that indicates “quality of control.” We often use the variance (standard deviation) in engineering units of the error between SP and PV of the key APC (for example, an inferred property). Degradation in the long-term trend of this variable suggests that careful process analysis is needed to identify the cause of the degraded performance and the corrective action needed to return the control to its original performance level.

Use consulting professionals for APC implementation and contract with them for periodic web-based or on-site controller maintenance. Use your in-house control engineers for operator guidance, target setting and APC program management.

Recommendations for Using MPC

If MPC is considered for solving a control problem, apply it intelligently and hierarchically. Intelligent application of MPC involves asking important questions, such as:

• Is the control problem to be solved truly multivariable? Can (and should) several MVs be adjusted to control one CV? If not, don’t use MPC.
• Are both significant dead time and lag present, so the model-based, predictive power of MPC would provide better control performance than a simple feed-forward action?
• In the model matrix are there significant interactions between many dependent variables and many independent variables, or are there just isolated “islands” of interactions, where each island represents a fairly simple control problem that could be just as easily solved with simpler technology?
• How big does the controller really have to be? Could the problem be solved with two or three small controllers without sacrificing the benefits provided by a unit-wide controller?

Applying MPC hierarchically means:

• Handling high-frequency, isolated disturbance variables with lower level ARC. For example, stabilize and control a fired heater outlet temperature with ARC, not MPC. The ARC can handle disturbance variables such as feed rate, inlet temperature, fuel gas pressure, etc.
• Using the lower level ARCs, such as the fired heater outlet temperature, as MVs in the MPC controller.
• Using intensive variables when possible as MVs in the controller. For example, use a distillate product yield, rather than flow rate, as the MV in a controller designed to control the quality of that product. This eliminates unit charge rate as a disturbance variable.

Conclusion

Process automation and APC continue to improve, especially with advances in measurement technology, equipment reliability and modeling. Nonetheless, APC will remain imperfect, and require experienced and quality process engineering analysis and APC experience for successful implementation. The most successful future APC programs will have the following characteristics:

• The APC solution will solve the operating problem and will use appropriate control technology. MPC will be employed only when required.
• The total APC solution will use the principle of hierarchy. Lower-level, simpler solutions will solve lower-level problems, with ascending, higher-level, more complex solutions achieving higher-level control and optimization objectives.
• An intermediate level of model-based APC technology, somewhere between simple PID and MPC, will be used more as a lower cost solution, but will provide an effective means of dealing with measured and unmeasured disturbances.
• The whole sub-field of APC known as “transition management” (such as handling crude switches) will become more dominant and important as an adjunct to continuous process control.
• APC solutions will make greater use of inferred properties, and these will be based on the physics and chemistry of the process (not “artificial intelligence,” such as neural nets).
• In-house control engineers will evolve from being purely technician to being more like program managers. Operating companies will rely more on APC companies to do the “grunt work,” allowing the in-house engineers to manage projects and monitor the performance of the control system.

APC technology has endured and survived its growing pains. It has reached a relatively stable state of maturity. And, it has shaken out its weaker components and proponents. Those of us who survived this process are wiser, humbler and more realistic about how to move forward. Our customers and employers will be best served by a pragmatic, process engineering-based approach to APC design that applies the specific control technology that’s most appropriate to achieve the desired control and operating objectives at lowest cost and with the greatest probability of long-term durability and maintainability.

Dr. James Ford is director of strategic initiatives, global business unit, at Maverick Technologies.