Hacking a nonlinear process for linear control: Part 3 of 4

Author's note: I wrote the first two parts of this series over two years ago before Microsoft acquired LinkedIn. Since then, Microsoft has made significant changes to the LinkedIn publishing format and authoring features (not for the better, in my opinion). Consequently, editing past articles for corrections or improvements is not possible because of serious incompatibilities. If you notice any formatting issues please let me know.

I realized as I was writing this article the depth of description for a non-linear process exceeded my original narrative and an additional article, the fourth, is needed. This is partly due to my improved knowledge gained over the past two years and partly because I want my articles to be accessible to younger people entering the profession. If I could, I would change the preceding two articles to be 1 of 4 and 2 of 4 from 1 of 3 and 2 of 3. I am considering a rewrite of those two articles. I offer my apologies for the confusing numbering of the series parts.

As always, I welcome questions, improvement ideas, and corrections.

This article is part three of a four-part series (see note above):

1. Introduction and identification of a nonlinear process
2. Data collection, consolidation and cleaning
3. How linearization works and why.
4. Application in code

This article covers:

• Reciprocation of process gain: the math behind "canceling" non-linearity
• The mirror's edge: applying reciprocation to the collected data
• Application proof: an informal proof of functionality
• Why it works: the view from the perspective of the PID

Reciprocation of process gain

Defined as the amount of change in the process variable for a given change in the controlling element, process gain (Gp) quantification over the entire range of controller output is critical. For in-depth details, refer to Part 1.

A Gp of 2 (an aggressive process) tells us the process variable moves 2% for every 1% of change in the controlling element. Likewise, a slow process with a Gp of 0.3 we know the process variable moves 1% for every 3% of change in the controlling element.

For reference, I created an interactive tool demonstrating a function plot of a simplified linear process using the Desmos Graphing Calculator. I recommend its use to demonstrate applicable portions of this article. I include a YouTube video below demonstrating the tool.

For stable process control, accurate PID tuning results in controller output adjustments just enough to counter a change in the process variable. (The I and D terms are not relevant here since they do not have direct application to process gain.) For example, if the process experiences a "load upset" resulting in a process variable change of 1%, then the PID must cause an upset equal but opposite to the load upset. For a Gp of 2, it does this by changing the controller output by 0.5%, in the appropriate direction, resulting in a force to move the process variable by 1% opposite to the load upset. For simplicity's sake, let's say we set the P term to 0.5 for a direct acting PID with the goal of realizing precise load upset cancellation. The correction steps are summed up in a cause and effect sequence in Figure 2.

Likewise, for a Gp of 0.3, the controller output must change 3.33% for every 1% of process variable change due to load upset.

What is evident in these two examples is the controller must have a proportional response to a load upset equivalent to the reciprocal of the process gain. So if Gp = 2 then the controller response must be 1/Gp or 0.5. Similarly, a Gp of 0.3 requires the controller response to be 1/0.3 or 3.33.

This point is referenced later, so I belabor with the obvious:

Equivalently,

Now consider the situation of a variable process gain. A PID is not designed to control a process of this nature. However, if we wanted to use a PID with the added adaptability it would need to maintain reciprocal response: the controller must vary its response by the inverse of the variation in process gain. We could write code to compute a changing P term, but this method opens new complexities (complexities beyond the scope of this article), avoided by changing the process dynamics, as detected by the PID, virtually. We do this using the data we collected, consolidated and cleaned in Part 2 of this article series.

The mirror's edge

Like the above section, I created an interactive tool demonstrating the concepts of this section using the Desmos Graphing Calculator. It is a useful tool for hands-on reference and tinkering as you read this section. I include a YouTube video below demonstrating it's interactive features.

Refer to Chart 1 of Part 2 in this series. Using a bin size of ten and plotting calculated controller output vs.ideal process variable produces the XY plot in Figure 7 below.

As pointed out in the second article, process gain is the slope of this plot, and since the plot is not a straight line, the process gain is variable across the range of controller output; consequently, it is not controllable by a PID unless we can account for this variation.

Observe the constant speed of the input on the x-axis while the output's speed on the vertical axis varies in the following video:

In our control example, the horizontal axis represents the PID control output while the vertical axis represents the impact on process variable. The variation in speed is analogous to the variation in process response while the control input changes at a constant rate.

Ideally, for every 1% of change in controller output, the process exhibits a 1% change in the process variable (Gp=1). With a process gain of 1 utilization of the of the controlling element's full range across the breadth of the process variable's range is realized and precludes controller saturation for a Gp > 1 and a Gp < 1 (explore this in the linear control demonstration I linked in the top of this article ). Observe the same data in the plot above but with the axes reversed: controller output on the vertical and the process variable on the horizontal in Figure 8 below:

Since the process variable and controller output are both in units of percent, their meaning is moot. This allows us to safely plot the data sets against a 0-100% scale on both axes. Now the relationship between the process gain (the varying slope of the blue line) and its reciprocal, the slopes of the orange curve, becomes more evident.

Notice the reflective symmetry between the two plots along an imaginary diagonal mirror. Drawing a line representing the line of symmetry produces the following plot.

The slope of the diagonal line is 1. It is equal to the changing slope of the blue curve multiplied by the changing slope of the orange curve. Remember, Figures 5 and 6? Figure 10 is the graphical representation of that relationship. It is the mirror's edge.

Application proof

Let's perform an informal verification with the diagram below (Figure 11) followed by calculation.

Let's take a step back to Part 1 of this series concerning the control of pH. As explained, pH is an extremely non-linear process. The blue curve is a titration curve representing pH. Here, titration refers to a steady addition of a base to an acid.

The PLC copies the PID's controlling output (CO) to the analog output (AO). The PLC transmits the CO to the controlling device (a valve or metering pump, for example). The controlling element adjusts the amount of high pH chemistry added to the acidic process. Assuming the controlling device is linear in its response, it then varies in lock step with CO from 0% to 100% across the X-axis of the process (the blue cloud). The controlling element adds the basic chemistry causing the process variable on the Y-axis to swing wildly across the range from one pH end to the other (abstracted to 0 - 100% of instrument range.) The pH transmitter transmits the process variable signal to the PLC's analog input (AI). The algorithm converts (we cover "converts" later) to a process variable that has a linear response equivalent to 1 (an effective process gain of 1). Now for a non-formal mathematical proof based on a scenario.

The process is running while the PID is in manual with its controller output locked at 10%. We place the PID in auto with its setpoint at a pH of 8. This pH setpoint is approximately 70% of the instrument range. Immediately, the controller responds by ramping up its output attempting to raise pH to the setpoint. Initially, the process response is almost nothing. The controller is experiencing a process gain much less than 1. Let's calculate Gp between the 3rd and 4th point of the blue curve. Referring to Figure 12 and 13 below.

The point coordinates are:

Calculating the change in process variable and the change in controller output:

As controller output moves by nearly 10%, we observe only a 1% move in process variable, indicative of sluggish process control. "Sluggish" is the qualitative description of a process gain much less than 1:

The process variable moving between 2.41 and 3.58 is transmitted to the analog input and then to the horizontal axis (raw process variable) of the PV conversion algorithm. Let's call it the linearization algorithm. This range also corresponds to the 3rd and 4th points:

Analogous to Figure 14, we see the inverse of the process function's output changes by little over 1% (PVc) while the output changes by almost 10% (PVr):

Similar to Figure 15, the ratio of these changes is the reciprocal of process gain:

The PID experiences the changes at PVc in Figure 11 as the product of the process change, Gp in Figure 15 and the linearization algorithm change (Alin) in Figure 18 above. We can call this the effective process gain (Geff).

Look familiar? Comparing Figure 19 with Figure 5 and 6 you see Alin is equivalent to the reciprocal of Gp. Consequently, the product of Gp and Alin is 1 and the effective process gain experienced by the PID is also 1, the ideal condition. You can perform the same calculations on the segments across the range of the curves to verify a consistent result of 1 for Geff.

Before we proceed to "Why it works," a detail I left out of Figure 11: the setpoint (SP). When the source of non-linearity is a result of the nature of the process itself or the instrumentation measuring and transmitting the PV, as opposed to the controlling element as the non-linear source, the linearization algorithm applied to the PV is also applied to the SP since the PID must compare "apples to apples." At the core of a PID's CO calculations is the difference between SP and PV so they must be equivalent in units and behavior across the value range. In the pH example, the PID's PV is a percentage, and so SP must also be in units of percent. However, a person at an HMI entering a SP value cannot be expected to convert the desired pH to a percentage based on a linearization algorithm. For the sake of operation simplicity, the human entered pH must be converted to the same terms, based on the same algorithm, as the PV. The details of linearization are hidden from the operator just as the internal workings of the PID are hidden, like a couple of black boxes.

You may be asking, "why didn't we apply the linearization algorithm to the controller output and not the process variable since that would remove the need for applying the algorithm to the setpoint?" Yes, that is correct; however, the source of non-linearity is the process itself and not our controlling element. To which you may say, "OK but, the controlling element is not just the metering pump or valve, it is the controlling element AND the chemical injected by the controlling element, and the basis of the curve is the addition of the chemistry to the process." Again this is correct, but when I say "the process sources the non-linear behavior" I am not only speaking of the chemistry the controller is injecting. What about variations in pH due to chemistry changes external to what the controller injects? By placing the algorithm at the input to the PID and not the output we are accounting for the non-linearity of the process by load upsets and the control chemistry injection.

Why it works

We need to go back to the PID internal computations. The following description is a simplified overview, so please allow me the freedom to employ generalizations since this is not the core subject matter of this article. The specifics of the multitude of PID computations vary but the general idea proceeds like this: a PID measure a process variable (PV) and targets a setpoint (SP) by calculating the difference of the two. It then uses the error along with three constants to compute three terms. The controller output (CO) is the sum of the three terms.

1. P for proportional: "P" is the result of control tuning and thus a constant. Multiplying the P constant by the error produces the proportional term. It is the only term that is independent of time and is the key to the linearization algorithms based on a changing process gain.
2. I for integral: "I" is the result of control tuning and thus a constant. It represents the frequency of cumulative summation of the error. Conceptually, the value is analogous to the cumulative time the error has not been at zero.
3. D for derivative: "D" is the result of control tuning and thus a constant. Multiplied by the speed of the process variable or error, it weights the rate of change's contribution to the CO's value.

To aid in conceptualization, I created another interactive tool using the Desmos Graphing Calculator. It is similar to the previous one albeit the two curves are not combined to create the linear behavior with a process gain of 1; also, the plot includes setpoint.

Focus on the vertical axis in Figure 20 below. Notice the distance between the setpoint and the process variable. The difference nearly spans the width of the transmitter range of 100%. In this scenario, the error the PID computes is significant, approximately 80%. Consequently, the PID calculates a large P term causing the output to move aggressively in an attempt to return the error to zero. Also, notice the process behavior between the SP and the PV is nearly vertical signifying a high process gain. The process requires only a small change in CO to cause a significant change in PV thus tuning the PID to this portion of the process results in a small P value. As long as the process is within this range, the controller output eases the PV to the SP.

But what happens when the PV is in the lower end of the instrument range? The scenario depiction illustrated in Figure 21 below shows the PV and SP are close in value. Since the process requirement of no error is nearly satisfied, the PID computes a small P term; consequently, the P terms contribution to controller output is small. However, this portion of the process curve is nearly flat meaning the process is not responsive to changes in controller output. If we tuned our controller to the range in Figure 20, where the process response is extreme, the P constant would be small making our P term even smaller and thus controller response too little for the range between SP and PV below.

If we tuned our controller to range between the SP and PV in Figure 21, we would have a large P constant. When our controller entered the range in Figure 20, the controller response would be aggressive in a range of the process that is also aggressive, resulting in a PV overshoot of SP at best and extreme instability at worse.

Consider the mirror of the above process. Compare figure 20 with Figure 22. While both process depictions have the same horizontal axis setpoint and controller output values, the situation is opposite. In the process depiction of Figure 22, we have a PID nearly satisfied. The controller output changes little, unlike the process in Figure 20.

Similarly, contrasting Figure 21 and Figure 23 we find an opposite situation though horizontal axis values are equivalent.

The above examples illustrate the following: while the real process (Figures 20 and 21) is in ranges of sluggish behavior, the virtual process (Figures 22 and 23) causes the PID to compute large errors resulting in aggressive controller action. On the other hand, when the real process is in ranges of aggressive behavior, the virtual process causes the PID to compute small errors resulting in sluggish controller response. When the virtual process is the "mirror image" of the real process and combined, as depicted in Figure 11, the overall effect is a cancellation of the two processes' varying responses to produce a steady response with a process gain of 1.

So, in conclusion, when attempting to counter a non-linear process consider ways to create an equal but opposite behavior to the overall process behavior. Maybe it can be done programmatically. This article demonstrated the conceptualization of one possible solution to such a scenario.

Remember, target a reflection of the process, just as a mirror produces an equivalent image of reality, but with an opposite orientation.