## May 2021

## Process Controls, Instrumentation and Automation

# Implementation of averaging level control using native DCS functions

When applying averaging level control in a process plant, engineers can typically choose between proportional integral derivative (PID)-based control, such as p-only, gap and non-linear, or a model-based control like optimal averaging level control.

When applying averaging level control in a process plant, engineers can typically choose between proportional integral derivative (PID)-based control, such as p-only, gap and non-linear, or a model-based control like optimal averaging level control. PID controllers allow the level to go outside of limits when disturbances are larger than the assumed maximum disturbance used during tuning. Model-based controllers will be more successful in keeping the level between limits, as no assumed maximum disturbance is used during tuning. However, model-based control requires additional hardware and software and typically runs at a slower execution interval of approximately 1 min.

Two simplifications of model-based averaging level controllers are proposed here. They ensure that levels stay within limits in the same way as model-based controllers. They can run at fast execution intervals, as they can be directly implemented on a standard distributed control system (DCS).

The first method is a simplification of the control of imbalanced ramps in standard advanced process control (APC) software, called the ramp horizon controller. Here, the process model is also simplified to use a gain only. The controller uses a pre-defined time, called the ramp horizon, during which the limits may not be exceeded. If no limits are exceeded within the ramp horizon, then no controller moves are implemented. If a limit violation is predicted, a move is implemented that is large enough to prevent the calculated violation only.

The second method is a simplification of the optimal averaging level controller, called the simplified optimal averaging level controller (SOALC). By simplifying the process model to a gain only, the calculations required by the controller are decreased enough to enable implementation on a standard DCS. The SOALC then calculates the minimum controller moves that must be made continuously to reduce the rate-of-change of the level to zero at the time it reaches the approached limit.

## Averaging level control

Many plants have feed drums with tightly tuned level controllers that essentially reduce a drum to nothing more than a pipe, wasting the initial capital outlay of installing the drum. Averaging level control will allow the level to move away from setpoint to allow the controller to reduce movement of the output, which should stabilize downstream processes.

Averaging level control is typically done by using properly tuned PID-based controllers^{1,2} or by using model-based controllers^{3,4,5,6} designed to minimize controller output (OP) movement. The PID controllers include p-only,^{7} proportional-integral (PI), gap and non-linear techniques,^{2} typically implemented as standard algorithms on modern DCSs^{8} and programmable logic controllers (PLCs) and running at execution cycles of 1 sec or faster.

A shortcoming of PID-based controllers is that they are typically tuned to accommodate an assumed maximum size disturbance.^{2,9,10} If a larger disturbance is encountered, the desired upper or lower limits for the level will be exceeded. This often leads control engineers to make conservative estimates for the maximum size disturbance that may be encountered. If smaller disturbances than these occur, these controllers will not make full use of the buffer capacity.

Model-based control is performed using APC software that will normally operate on dedicated control servers that communicate via a network connection to the DCS or PLC. These controllers typically run at 1-min execution cycles.

Model-based controllers will make full use of the buffer capacity by letting the level move between the high and low limits. Disadvantages of model-based control include:

- Additional hardware and software are required.
- A network connection is used to link the controller to the DCS or PLC.
- Once the controllers have allowed the level to move up to a limit, consecutive disturbances in the same direction will cause the level to exceed the limit, albeit not by a large amount.

Two new control methods are proposed that are simplifications of model-based averaging level control techniques. Benefits include:

- They run on a modern DCS using its standard control functionality.
- They run at ≤ 1-sec execution cycles.
- They take full advantage of the available buffer capacity.
- They do not exceed limits if larger than expected disturbances occur.

## Ramp horizon controller

Ramp horizon control is a simplification of the way level buffering is done by an APC.^{5} A timespan or ramp horizon is selected during which the high and low limits imposed on the level may not be exceeded. The trajectory of the level is estimated, based on the current position and current rate-of-change. OP moves are only made if the estimated trajectory will violate a limit within the ramp horizon. If no violation is predicted, no OP moves are made.

The algorithm is initiated by calculating the current ramp rate (Eq. 1):

*RR* = (*L _{n}* –

*L*)/

_{n–i}*i*(1)

where:

*RR* = Current ramp rate, % per execution cycle

*L _{n}* = Level at current execution cycle,

*n*(%)

*L _{n–i}* = Level at execution cycle,

*n–i*(%)

*i* = Number of execution cycles used to calculate ramp rate.

Consider the example shown in **FIG. 1.** The ramp rate is calculated by subtracting the current process value (PV) of the level (which is 50) from a previous value of 45 at Time 2 and dividing that by the time difference of two intervals to obtain the current rate-of-change of the level of 2.5% per interval. The value of *i* should be large enough to minimize noise and small enough to limit the amount of lag introduced.

Next, the change in level over the ramp horizon is calculated by Eq. 2:

*ΔL = RR × RH* (2)

where:

*ΔL* = Amount that the level is predicted to change over the ramp horizon

*RH* = Ramp horizon.

In the example, the ramp rate of 2.5%/cycle is multiplied by the ramp horizon of 10 execution cycles. This calculates the change in level over the ramp horizon to be 25% (Eq. 3):

*L _{n + RH}* =

*L*+

_{n}*ΔL*(3)

where:

*L _{n + RH}* = Predicted value of level at ramp horizon.

In the example, 25% is added to the current value of the level of 50% to calculate the predicted value of the level at the ramp horizon to be 75%. If this predicted value does not violate the high or low limit, no OP moves are made. However, the predicted value violates the high limit of 70%, so an OP move will be calculated and implemented.

A controller gain is calculated initially by either using step test data or calculating the volume of liquid between the high and low limits on the drum. The gain is the change in the level rate-of-change that will result when the OP is moved up by one engineering unit (Eq. 4):

*Gain* = (*RR _{SS}* –

*RR*)/

_{initial}*∆OP*(4)

where:

*Gain* = Ramp horizon controller gain, % level/ execution cycle/% OP

*RR _{SS}* = Ramp rate when steady state is reached after step was made

*RR _{initial}* = Ramp rate at steady state before step change was made

*ΔOP* = Step change in OP that was made.

For this example, a step test was conducted with the ramp rate of the level at -2 initially. The OP was stepped up by 4 and the ramp rate reached steady state at 6. The gain is calculated as 2 using Eq. 4. This indicates a 2%/execution cycle change in the rate-of-change of the level for every 1% change in OP.

Using the controller gain, it was possible to calculate how much the OP must be changed to prevent the limit being exceeded (Eq. 5):

*∆OP* = (*L _{n + RH}* –

*Limit*)/

*RH*/

*Gain*(5)

where:

*Limit* = Limit towards which the level is moving.

In the example, the PV error is calculated by taking the difference between the predicted value of the level at the ramp horizon and the exceeded limit—this is 5% in the example. We now need to calculate how much the OP should be moved so that the level will be at 70% at the ramp horizon. Dividing the error by the ramp horizon calculates the desired change in the rate-of-change for the level to be 0.5%/interval. Dividing this value by the controller gain shows that the OP must be moved up by 0.25% to change the trajectory of the level just enough so it will be on the limit at the ramp horizon.

This will prevent the level from exceeding the limit at the ramp horizon. However, as the level will still be approaching the limit, the controller during the next execution cycle will once again predict that the limit will be exceeded. It will implement another controller move to ensure that at the ramp horizon, the level will still be inside the limit. If no other process influences the trajectory of the level, this process will be repeated until the rate-of-change of the level reaches 0 as it reaches the high limit.

When a relatively small disturbance causes a change on a level that is controlled by using the ramp horizon method, the prediction will initially not show that a limit will be exceeded within the ramp horizon. As the level then goes towards a limit, no OP moves will be made. As time passes, the level will approach the limit and at some stage a small violation will be predicted. An OP move will be calculated to change the rate-of-change of the level such that the level will be on the limit at the ramp horizon.

At the next execution cycle, the prediction will show a small violation again, as the level is still moving in the direction of the limit. Once again, a small OP movement will be calculated to bring the level to the limit at the ramp horizon. This will be repeated until the cumulative OP moves will bring the rate-of-change of the level to zero when the level reaches the limit. No attempt is made to return the level to a setpoint (SP) value or to move away from limits.

Because this method will allow the level to achieve limits while making small OP moves to ensure the limits are not exceeded, the risk remains that continuous or consecutive disturbances in the same direction may occur once the level has reached the limit. When this happens, the controller will not be able to keep the level between the imposed limits. If this occurs and the level moves outside a limit, the ramp horizon controller will return the level to the limit that was exceeded using the same algorithm.

Because the method simplifies the response of the level by calculating a gain only, it ignores any dynamic behavior. Combining this with measurement noise, unmeasured disturbances and the possibility of an incorrect gain being used may lead to imprecise control action. However, in a short execution cycle, the level measurement that is taken as input and the rate-of-change of the level that is calculated at every execution cycle continuously update the controller error. This compensates for the possible inaccuracies in measurement and control.

## SOALC

Optimal averaging level control^{3,11,12} is accomplished using model-based control software to calculate the smallest moves that can be made continuously to allow the level to attain a zero rate-of-change when it reaches the limit. While optimal averaging level control requires model predictive control software running on a dedicated server, the approach may be simplified in the same way as the ramp horizon controller to allow running the algorithm natively on a standard DCS at a higher frequency.

If the dynamics of the level are ignored and only the absolute value of the level and its current rate-of-change are used to calculate the future trajectory of the level, an approach like the optimal averaging level controller may be developed. If the current rate-of-change of the level is extrapolated from the current value of the level, limit violations can be predicted. The OP move required during every execution cycle until the level is balanced at the limit can then be calculated.

Because dynamics are ignored, this approach will not be as accurate as a model-based controller. Like the ramp horizon controller, a short execution cycle, the level measurement that is taken as input and the rate-of-change of the level that is calculated at every execution cycle will continuously update the controller error and will ensure adherence to limits.

If a level is currently at *PV _{0}*, with a positive rate-of-change of

*ROC*, and a high limit of

_{0}*H*that will be exceeded based on an extrapolation of

*ROC*, then a sequence of

_{0}*n*OP moves of size

*x*must be calculated to balance the level at

*H*. The total move of the OP over the control horizon must be (Eq. 6):

*dOP* = *x.n* (6)

If a controller gain (*G*) is defined as the change per execution cycle in the rate-of-change of the level brought about by increasing the OP by 1%, then (Eq. 7):

*dOP* = *ROC _{0}*/

*G*(7)

Combining Eqs. 1 and 2 yields Eq. 8:

x = *ROC _{0}*/(

*G.n*) (8)

If the level begins at the current PV with the current rate-of-change and ends at the high limit with the rate-of-change at 0, the initial and final conditions must be as shown in** TABLE 1. **

If a step of size *x* is made every execution cycle, then the rate-of-change of the level will be decreased by *x.G* every execution cycle. The level will also increase by the current rate-of-change per execution cycle. Therefore, **TABLE 2** can be calculated.

In **TABLE 2,** the first column shows the Execution cycle. The second column shows the Level measurement, calculated as the previous value of the level plus the change in the level. The change in the level will be the Rate-of-change in the level during the previous Execution cycle, as shown in Column 4.

For example, during Execution cycle 3, the previous value of the level was calculated as *PV*_{0} + *ROC _{0}* +

*ROC*–

_{0}*x.G*. If the change in level seen in Column 4 (

*ROC*– 2.

_{0}*x.G*) is added, the value for the level at Cycle 3 is calculated as

*PV*

_{0}+

*ROC*+

_{0}*ROC*–

_{0}*x.G*+

*ROC*– 2.

_{0}*x.G*. This is simplified in Column 3 to

*PV*

_{0}+ 3.

*ROC*– 3.

_{0}*x.G*.

At the Execution cycle *n*, the controller has made the last move of size *x*, which will cause the rate-of-change of the level to become 0 at the high limit. Therefore, at Row *n* in **TABLE 2, **the value of the level is *H* and the rate-of-change is 0.

To calculate the level at Execution cycle *n* in terms of *x*, *PV*_{0} and *ROC _{0}*, Column 3 of

**TABLE 2**is set equal to

*H*. In calculating the equation in Column 3, Row

*n*, the coefficient of

*PV*

_{0}should be 1 and the coefficient of

*ROC*should be

_{0}*n*. The series of coefficients for the term

*x.G*(0, 1, 3, 6, 10…) shown in Column 3 can be calculated as 0.5

*n*

^{2}– 0.5

*n*. Therefore, the value of the level at Cycle

*n*can be expressed as

*PV*

_{0}+

*n*.

*ROC*– (0.5.

_{0}*n*

^{2}– 0.5

*n*)

*x.G*, as shown in the last row of Column 3 in

**TABLE 2.**

Combining *H* = *PV*_{0} + *n*.*ROC _{0}* – (0.5.

*n*

^{2}– 0.5

*n*)

*x.G*and Eq. 8 yields Eq. 9:

*x* = 0.5 × *ROC _{0}* ×

*ROC*/ [G × (H –

_{0}*PV*

_{0}– 0.5 ×

*ROC*)] (9)

_{0}Eq. 9 calculates by how much the OP must be changed during every execution cycle to balance the level at the high limit. As stated before, dynamics on the level model may cause inaccuracies, but as the value and rate-of-change of the level are measured every execution cycle, the inaccuracies are remedied.

In the same way, it can be calculated in Eq. 10 that:

*x* = 0.5 × *ROC _{0}* ×

*ROC*/[G × (L –

_{0}*PV*

_{0}– 0.5 ×

*ROC*)] (10)

_{0}will balance the level at the low limit (*L*) if the level is moving downward.

# SIMULATION RESULTS

To test the ramp horizon and SOALC, a level was simulated and subjected to step disturbances of different sizes. A standard non-linear or error-squared PID controller^{2} was used as comparison and tuned to handle a maximum disturbance of 5 m^{3}/hr.

To measure the success of the control, the variance of the OP derivative (VOD) was measured.^{2,12,13,14}

If a control method can minimize total OP movement over time or prevent the OP from moving in one direction initially and then moving back later when the limits would not have been exceeded if no moves were made, this would be a big advantage in improving plant stability. There were no performance metrics in literature that highlighted this behavior. To test to what extent this occurs, the average of the absolute moves (AAM) of the OP of a controller, as shown in Eq. 11, was developed as an additional performance indicator:

*AAM* =[∑* _{i}^{N}abs*(

*OP*–

_{i}*OP*

_{i}_{–1})] / N (11)

## Positive step disturbance of 5 m^{3}/hr

When responding to a positive step of 5 m^{3}/hr in the feed to the drum, **FIG. 2** shows how the controllers all managed to keep the level below the high limit of 70%.** FIG. 3** shows how all the controllers moved their OPs by the same total amount. This is as expected, because the volume balance must be restored to bring the rate-of-change of the different levels to zero.

**TABLE 3** shows that the controllers performed similarly when considering the VOD and the same on the AAM. This is because all the controllers moved their OPs by exactly 5% over the time horizon considered.

## Positive step disturbance of 6.25 m^{3}/hr

If the disturbance size is increased by 25%, **FIG. 4** shows how the non-linear controller was unable to keep its level below the high limit of 70%. This is because it was tuned to accommodate an assumed maximum disturbance of 5 m^{3}/hr. Both the ramp horizon controller and the SOALC managed to keep the level within the limit. **TABLE 4** indicates how the VOD showed slightly poorer performance from the SOALC and ramp horizon controllers, while the AAM is the same as before. **FIG. 5** also shows how the ramp horizon controller and SOALC initially moved their OP faster to prevent the level from exceeding the limit. The VOD shows slightly poorer performance from the SOALC, while the AAM is the same as before.^{15,16,17}

## Positive step disturbance of 3.75 m^{3}/hr

If the magnitude of the disturbance is decreased by 25%, **FIG. 6** shows how the non-linear controller did not use the full range allowed for level buffering. **FIG. 7** shows how the ramp horizon controller initially did not move its OP because a limit violation was not predicted within the defined time horizon. Later, the controller then had to move the OP faster to prevent a limit violation, which increased its VOD (**TABLE 5**).

## Plant test

A ramp horizon control was deployed on a feed drum to a reactor in an industrial plant. The feed to the drum varies and the existing PI gap controller was tuned to keep the OP as steady as possible while maintaining the level within limits of 30%–70%. If the low level is exceeded, the reactor feed pumps will cavitate; if the high level is exceeded, a high-level protection controller will send reactor feed material to another process where the feed material would be converted to a lower value product.

The ramp horizon controller results were compared to the original PI gap controller and analyzed using the VOD and AAM, as well as visual inspection of the PV and OP trajectories.

Data of the feed to the drum were collected and used as disturbance data to a simulated level controlled by a ramp horizon controller. Tuning was then refined to minimize the standard deviation of the OP.

The controller was commissioned, and data was collected for a period of 1 mos. This was compared to data collected during the same month of the previous year to eliminate seasonal influences, as far as possible. The data sets show that the ramp horizon controller managed to maintain the level between 30% and 70%, while the PI gap controller allowed the level to vary between 36.7% and 84.7%.

Data where the controllers were switched to MAN were excluded. This accounted for 11.9% of the data for the ramp horizon controller and 19.7% for the PI gap controller.

**FIG. 8** shows one day’s data while the ramp horizon controller was used. When comparing this with one day’s data from the PI gap controller in **FIG. 9,** the ramp horizon controller moved the OP less than the PI gap controller, but it had to move it faster when it was required to remain between limits.

All metrics shown in **TABLE 6** indicate that the ramp horizon controller outperformed the PI gap controller. The simulation results show how the non-linear PI controller will perform similarly to the ramp horizon and SOALC when a disturbance of the exact size that was used to tune the non-linear PI controller occurs.

When a disturbance occurs that is larger than was assumed to tune the controllers, the non-linear PI controller will allow the level to move outside the limits. As the ramp horizon and SOALC calculate a response that is not based on an assumed maximum disturbance, they will maintain the level within limits.

When a smaller disturbance occurs, the ramp horizon may make no changes initially and the SOALC will make small changes throughout. They both allow the level to reach the limit. In this case, the non-linear PI controller will prevent the level from going to the limit, using only part of the available buffer capacity offered by the drum. Consequently, the non-linear PI controller will move the OP more aggressively than the ramp horizon and SOALC controllers.

The plant test shows how the ramp horizon controller outperformed the non-linear PI controller by:

- Keeping the level within limits
- Implementing smaller and fewer moves.

## Takeaway

The proposed SOALC and ramp horizon controllers will maintain levels within limits when disturbances occur that are larger than what was assumed during tuning and commissioning. Both controllers will outperform a traditional PI controller in minimizing OP movement. Additional control hardware and software will not be required to implement them if the plant is controlled by a modern DCS.

Because the level and rate-of-change of the level are calculated at every cycle, and they run at a high execution rate, noise and tuning errors can be accommodated.

As these controllers do not attempt to return the level to SP, consecutive disturbances in the same direction will allow the level to move outside the set limits. When this happens, the ramp horizon controller will return the level to within limits while the SOALC will have to revert to PID control until the level is within limits again.

When attempting averaging level control on a plant with disturbances of varying sizes, ramp horizon control or SOALC can be used. This will ensure that levels remain within desired limits while moving the OP less than traditional PID-based methods, while minimizing OP movement.

However, some challenges exist in the implementation of RH and SOALC. Since both the ramp horizon and SOALC will allow the level to reach limits while making the smallest OP moves to ensure the limits are not exceeded, the risk remains that disturbances that push the level in the same direction as before may occur once the level has reached the limit. If this occurs, the SOALC will not return the level to the limit that was exceeded using the same algorithm. Eqs. 9 or 10 will move the OP in the wrong direction, aiding the disturbance that pushed the level outside its limits. When this happens, the error will grow and the SOALC will accelerate the OP movement in the wrong direction. While this might occur infrequently, reverting to PID control when the PV is outside limits is recommended.** HP**

**LITERATURE CITED**^{}

- Lindholm, A., “Buffer management strategies for improving plant availability,” MSc Thesis, Department of Automatic Control, Lund University, 2009.
- King, M.,
*Process control: A practical approach,*Wiley, December 2010. ^{}McDonald, K. A., T. J. McAvoy and A. Tits, “Optimal averaging level control,”*AIChe Journal,*Vol. 32, No. 1, 1986.^{}Kotze, G. and F. Pieterse, “ROC level control,” Honeywell internal document, 2011.^{}AspenTech DMCplus Advanced Concepts Course, MA305.06.10, 2007.-
^{}Reyes-L´ua, A., C. F. Backi and S. Skogestad, “Improved PI control for a surge tank satisfying level constraints,” 3rd IFAC Conference on Advances in Proportional-integral-derivative control, Ghent, Belgium, May 9–11, 2018. -
^{}Taylor, A. J. and T. G. la Grange, “Optimize surge vessel control,”*Hydrocarbon Processing,*May 2002. -
^{}“Experion control builder components theory,” Vol. 1, Honeywell 2005. -
^{}Shinskey, F.G., “Special rules for tuning level controllers,” 2005, online: www.controlglobal.com/articles -
^{}Friedman, Y. Z., “Tuning of averaging level controllers,” Petrocontrol, 1994, online: http://www.petrocontrol.com/papers/1994 ^{}Ogawa, S., B. Allison, G. Dumont and M. Davies, “A new approach to optimal averaging level control with state constraints,” 41st IEEE Conference on Decision and Control, Las Vegas, Nevada, U.S., December 2002.^{}Rosander, P., A. J. Isaksson, J. Löfberg and K. Forsman, “Robust averaging level control,” AIChe Annual Meeting, Minneapolis, Minnesota, U.S., 2011.^{}Sidhu, M., “Multivariable averaging level control,” BSc Thesis, University of British Columbia, Canada, 2001.^{}Ye, N., T. J. McAvoy, K. A. Kosanovich and M. J. Piovosv, “Optimal averaging level control for the Tennessee Eastman problem,”*The Canadian Journal of Chemical Engineering,*Vol. 73, 1995.^{}Lakerveld, R., B. Benyahia, P. L. Heider, H. Zhang, R. D. Braatz and P. I. Barton, “Averaging level control to reduce off-spec material in a continuous pharmaceutical pilot plant,” MDPI, 2013, online: https://www.mdpi.com/2227-9717/1/3/330^{}Kelly, J. D., “Tuning digital PI controllers for minimal variance in manipulated input moves applied to imbalanced systems with delay,”*The Canadian Journal of Chemical Engineering,*Vol. 76, 1998.^{}Van der Burg, M.W. and P. Djacdan, “Model predictive averaging level control using disturbance prediction,” IFAC Proceedings Volumes, Vol. 28, Iss. 12, June 1995.

## Comments