Adaptive and intuitively simple optimization

Rate-Predictive Control is engineered to run a process like an expert operator.

By Greg McMillan and Stan Weiner

1 of 2 < 1 | 2 View on one page

Greg: There is an incredible gap between what could be and what is actually done in terms of optimizing processes by better use of control technologies. There are many reasons, foremost being the fact that the dynamic models are dynamically changing. Process gains and valve gains change with operating point and conditions. The process, valve and sensor dead times and time constants not only change with operating point and conditions, and but also, in some cases, with direction (e.g., heating versus cooling and pH up or down). All of these dynamics can change with step size. Fortunately, there are very few true steps in actual process operation. What we see if we look more closely is more like a ramp due to valve response time and PID integral action. There is an innovative paradigm shift that addresses these fundamental challenges by a new control algorithm developed and patented by Allan G. Kern, owner and president, APC Performance, LLC.

The core technology is Rate-Predictive Control (RPC), where the “prediction value” is the current value of the Indirect Control Variable (ICV) plus its ramp rate (ongoing rate-of-change) multiplied by the 63% response time (total dead time plus primary time constant in a first-order approximation). As the prediction value is seen to reach its target, further moves of the Direct Control Variable (DCV) are tapered and stopped, such that the ICV settles exactly on its target. Each DCV moves at a preselected “move rate.” As we will see, the resulting algorithm is inherently adaptive to changes in the process gain and move rate, and is robust (relatively insensitive) to changes in process response time. A person implementing RPC only needs to know gain direction of the process interaction, i.e. direct or reverse control action, so a detailed model is not required.

The ICV is similar to a PID process variable or MPC controlled variable or constraint variable. The DCV is comparable to a PID output or MPC manipulated variable or “handle.” DCVs are directly controlled, in order to indirectly control the ICVs, hence the terminology. The XMC multivariable version uses RPC as its internal control mechanism, and a matrix where each ICV can be affected by multiple DCVs and vice-versa. Allan describes RPC and XMC as having “operational handles” on the process via the DCV move rate with “eyes on” the process via the ICV prediction value. The RPC target is like the PID setpoint.

Stan: How do you choose the RPC move rate?

Allan: In any APC effort, I like to involve the three key players, who are the process engineer, operations representative and control engineer—in that order. The process engineer has a focus every day on process reliability and optimization, and is usually the most reliable source for input about automation objectives. Operations representatives are experienced operators or supervisors who bring additional detailed insight into process behavior and real constraints. The control engineer, as I see it, is responsible for automation implementation according to the criteria laid out by the process engineer and operating team, brings control system know-how, and understands limitations in transmitters, valves and closed-loop control capabilities.

The RPC move rate can be chosen intuitively. It’s conceptually similar to a process “speed limit”—operators usually know from experience appropriate DCV move rates, just as drivers know appropriate speed limits. Speed limits aren’t based on how far you’ve got to go or how soon you’d like to get there, but on keeping things safely under control along the way.

Move rate also can be determined objectively. For example, if the operator normally moves a temperature two degrees at a time, while waiting 10 minutes between moves to gauge the response, then the corresponding RPC move rate would be 0.2 degrees per minute. For some loops, allowable move rates are spelled out explicitly in operating procedures.

Greg: How is RPC inherently adaptive?

Allan: If the process gain doubles, the ICV response doubles, and the prediction value arrives twice as soon at the target, so that DCV moves stop in half the time. In this way, the control response is based on the actual, real-time process response, not on some prior expectation (model) of process response. This is what is meant by “inherently adaptive” or “naturally self-tuning.”

The same way RPC is adaptive to process gain, it’s also adaptive to changes in the move rate. This means the move rate can be freely adjusted for operational performance, without undermining control performance. This has huge implications for those of us who have spent large parts of our careers trying to balance these competing priorities.

White Paper: The

Greg: My June 28, 2012 Control Talk Blog, “Future PV values are the future;” September, 2012 Control article, “Get the most out of your batch;” and May, 2006 Control article, “Full throttle batch and startup response” show how I use the rate of change of a process variable (PV) multiplied by the dead time to predict where the PV will be.

Stan: What are the tuning parameters for RPC and XMC?

Allan: I think RPC tuning ultimately is easier than PID tuning.

RPC has three main tuning parameters: move rate, prediction time and “control band.” All three can be set either intuitively or by simple objective methods. Setting move rate was already discussed.  Prediction time, ideally, is the 63% response time that is readily seen in the time offset of the DCV and ICV ramps. It can also be set as the typical time between setpoint moves—how long does an operator wait to see the effect of one move before making another? The third RPC tuning parameter, control band, is a kind of proportional band. RPC’s internal move rate is reduced proportionately (tapered) as the error becomes less than the control band, so the internal move rate goes to zero as the error goes to zero. Typical control band values range from 2 to 10 (in ICV units), and intuitively can be thought of as the point where operators begin to reduce step size to manage overshoot and settle on target. Where there is significant dead time, there is an RPC dead time rule that can be applied to verify sufficient band to avoid overshoot.

Each instance of RPC has these three tuning parameters. For an XMC application, each DCV has a move rate, and each ICV has a prediction time and a control band.

Greg: What happens if the ICV stops approaching setpoint, which can occur due resolution limits in the automation system and increasing loads?

Allan: If the prediction value equals the current value, i.e. the ICV is not moving, and the error is non-zero, the DCV will continue to move according to its move rate to bring the ICV to the target. The DCV continues to move according to the error, gain direction and speed limit, even if ICV movement temporarily pauses or otherwise behaves non-ideally, such as an inverse response.

It’s worth mentioning that, although RPC uses a preset move rate, it’s not limited to a single choice. The move rate is often dynamically adjusted based on ongoing conditions and performance objectives. For example, a constraint limit violation versus an optimization move, or (as already described) RPC continuously adjusts the move rate within the control band. This adds a lot of control flexibility and power, but doesn’t create complications, because RPC is adaptive to move rate at the same time.

Stan: How is feedforward implemented?

Allan: A feedforward signal is added to the DCV similar to how a feedforward summer is implemented in conventional PID controllers. Dynamic compensation of the feedforward signal is done externally. As with any feedforward signal, it needs to be robust and reliable, especially with regard to dynamics (timing) more so than gain.

I call this a “classic,” “selective” or “ARC” (advanced regulatory control) style approach to feedforward, as opposed to the wholesale—in my view, often reckless—approach used in conventional MPC.

Stan: What about unmeasured load disturbances?

Allan: Load disturbances are seen by RPC as changes in ICV ramp rate and prediction value, and are controlled in the same way as setpoint changes—the load response is the same as the setpoint response. A University of Wyoming research project showed that the RPC transfer function is identical for setpoint changes and load disturbances. RPC already has operational performance, so there is not much incentive to add functionality to treat setpoint changes differently from load disturbances.

RPC is responsive to load disturbances, since it acts not only on the magnitude of the error, but on its manifest future value based on its momentum, i.e. the prediction value. By the same token, as control returns to setpoint, RPC is stable, thanks to the same rate-predictive control action.

Greg: PID setpoint response is smooth without overshoot of the process variable when a PID is tuned to give aggressive disturbance rejection if a setpoint filter is set equal to the reset time, or a PID structure of proportional and derivative action on process variable rather than error is used. For integrating or runaway processes, PID output overshoot of its final resting value is needed to get the process to its target. For runaway processes that are open or unstable (e.g., highly exothermic reactors), the control action must be very aggressive for stability and safety. How does RPC address these requirements?

Allan: RPC by default is tuned for operational performance, since it was developed in part to address this need. Operational performance means several things, including preset move rates and minimal overshoot. Operating teams generally prefer this type of performance, because rapid movement and overshoot can result in trips or alarms, and oscillation can cause or mask process instability. But RPC also can be tuned for aggressive performance in applications where it is operationally or economically desirable, or where it is required by the nature of the process, as in the examples you mention.

In general, for aggressive response, RPC is tuned with a faster move rate, larger control band, and (especially) a shorter prediction time (less than actual process response time). For example, in a recent test, a prediction time of one-half the actual process response time resulted in a damped 25% DCV overshoot but no overshoot of the ICV. With a prediction time of one-quarter the actual process response time, ICV overshoot began to appear. Just as move rate is the main tuning parameter for operational performance, prediction time is the main tuning parameter for aggressive performance.

1 of 2 < 1 | 2 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments