Rate-predictive control (RPC®) in a nutshell (and in 1 slide)

Rate-predictive control (RPC) was “reverse-engineered” based on how operators manually control process variables in the absence of a closed-loop controller.

RPC can be used for single-loop control (as a drop-in alternative to PID) and it can be used for multivariable control (it is the internal method used by XMC, a model-less method of multivariable control, but that is another story).

RPC has several claims to fame. Its primary (and patented) claim is that it is inherently adaptive to changes in process gain. This is a profound claim, considering industry’s storied history of loop tuning, industry’s more recent (but largely unsuccessful) efforts at auto-tuning (RPC is inherently auto-tuning, you could say), and considering that changing process gains has been a root cause of model-based control “degraded performance” and “model-maintenance”. In many ways, an inherently adaptive control algorithm is the grail of process control, even if (as in Indiana Jones) it is unexpectedly humble and may be hard to recognize and appreciate at first glance.

In RPC (refer to Figure 1), the controller output is moved at a pre-set move rate (which is selected based on safe operating practice, not tuning). The future value of the process variable is predicted based on its ongoing rate-of-change and settling time. RPC tapers (reduces and ultimately stops) the moves predictively, so that the process variable settles right on target, based on first-order process dynamics. This is inherently adaptive because, as gain changes, the rate-of-change and prediction are affected accordingly, so that RPC tapers the moves correspondingly sooner (or later). Executing in real-time, such as once per second, this simple algorithm delivers stable, robust and performant control, to both disturbances and setpoint changes.

Importantly, and in the same way, RPC is also adaptive to changes in the preset move rate. This means the move rate can be readily adjusted (sped up or slowed down) for desired operational performance. It also means the move rate can be dynamically adjusted to address a variety of control performance goals. For example, the RPC move rate can be (routinely is) increased when more severe constraint limits or alarm limits surrounding the setpoint are (predictively) violated.

RPC mirrors how operators control process variables manually, i.e. they make a series of output step moves (implement a preset move rate) based on experience, and monitor the actual process response. As the process variable approaches its target, the steps are tapered, so that the process variable settles on target with minimal overshoot or oscillation. Operators often use this method (i.e. take manual control) even where PID or model-based control is available, because of its safe and reliable nature.

RPC is at once more responsive to disturbances and more stable as it returns to setpoint. This is because RPC is based on the predicted value – or apparent future value – which is based not only on its ongoing value, but also on its ongoing rate-of-change. For example, where PID or model-based control may respond to an error of 1.0, RPC may respond to an effectively larger error, since it also looks at the ongoing rate-of-change and the already-apparent future value. For the same reason, RPC tapers moves predictively, as soon as the predicted value reaches setpoint, which minimizes overshoot and cycling.

To operators, an RPC controller looks the same as a PID controller -- it has setpoint, mode, output, alarms, etc. Only when viewing point details does RPC become apparent. For engineers, once accustomed to RPC, it is more intuitive to tune than PID. Also, RPC is tolerant to process dead-time to the same extent as PID, i.e. unless deadtime becomes much larger than response time, tuning is minimally affected. (For control of deadtime dominant processes, RPC has additional novel features, which will be addressed in a later post, as will XMC®.)