An inferentials update
Use these techniques to achieve "high-bar" inferential performance
- Low-bar performance refers to the minimum level of inferential performance that can be considered successful, while high-bar refers to the maximum level of achievement.
- The traditional benefits of inferentials are real-time control, analyzer cost avoidance, and laboratory load reduction.
- With automatic updating, the software is simplified, the operator is neither bothered nor relied upon, and the bias history accumulates less anomalies.
By Allan Kern
The simplest and most traditional embodiment of inferentials, also known as soft sensors, is a pressure-compensated temperature, which control technique dates back to the pneumatic age. With the digital age, inferentials "went on steroids," generally with excellent results. Today, a variety of inferential modeling and deployment techniques are commonly employed, and with a little care, it is difficult to go wrong.
For all the benefits and accessibility of inferentials technology, many inferentials remain at "low-bar" performance, compromising operation and control, leaving money on the table, and failing to achieve expected objectives. This article describes several techniques to reach "high-bar" inferential performance, including:
- Using bias trends to reveal the real history of inferential performance
- Using a statistical quality control spreadsheet to achieve lab load reduction
- Implementing automatic bias updating
- "Sanity check" inferential performance against simpler models
"Low-bar" performance refers to the minimum level of inferential performance that can be considered successful, while "high-bar" refers to the maximum level of achievement.
In the low-bar scenario, the inferential is not highly accurate, but it at least "moves in the right direction," thereby facilitating continuous, if approximate, closed-loop control. Operation remains fundamentally dependent on frequent laboratory feedback. The inferential bias (see sidebar) is adjusted significantly with each lab result, and during upsets or mode changes, when reliable feedback is most needed, unscheduled lab samples become necessary to steer operation back on target. With low-bar inferentials, operators tend to live more by the last lab result and their own wits than by the live inferential value.
In the high-bar scenario, or maximum level of achievement, the inferential delivers accurate results over most operating windows and is depended upon like a reliable on-stream analyzer. Control is accurate, and operators rely on the inferential to steer operation through upsets or mode changes, foregoing unscheduled lab requests. Most telling, with a high-bar inferential, the normal scheduled frequency of lab analyses can be reduced or even eliminated except for minimum quality control samples.
The traditional benefits of inferentials are real-time control, analyzer cost avoidance, and laboratory load reduction. While a low-bar inferential captures approximate closed-loop control, only a high-bar inferential fully captures all these benefits, including accurate process control with reliable on-target operation.
The rest of the story
Perhaps the biggest contributor to low-bar complacency is the practice of verifying inferential performance by eyeballing long-term trends of the inferential and associated lab results. The problem is almost any inferential that at least moves in the right direction and whose bias is methodically updated will appear impressive when viewed in a long-term trend this way. In this case, seeing can be highly misleading and often causes more careful validation to go un-pursued.
Have no fear. Inferential performance is still easily gauged by trending the bias-the bias history, not the inferential itself, tells the story of inferential performance. A bias trend that is flat over the long-term, with individual updates less than the update limit, indicates a high-bar inferential. A bias trend that exhibits frequent updates equal to the limit, or successive updates in the same direction ("staircase" appearance), indicates a low-bar inferential that fails to keep operation on target. With minimal practice, inspecting bias trends becomes as intuitive as (you may have thought) inspecting raw inferential trends.
For example, take a trend of a diesel 90% cutpoint inferential, corresponding lab values, and the bias. The bias trend is flat overall with less than 5% of samples hitting the update limit (which is 1.5 F in this case, or 50% of sigma, the lab standard deviation). At this level of performance, hitting the limit is as likely caused by occasional lab error than inferential error. There is only occasional staircase behavior, indicating seamless performance across most operating window changes. Overall, this inferential appears to exhibit high-bar performance (which statistical quality control will shortly confirm). Unfortunately, experience shows many inferentials do not look so pretty.
To further improve your grip on inferential performance, or if a more formal method is needed to guide lab frequency reductions, construct an inferential SQC (statistical quality control) spreadsheet.
Most modern data historians and spreadsheet tools make this easy to do. By clicking the desired inferential from a list, the SQC rules are solved, and the control chart is drawn automatically. With the tool in place, inferential performance is easily verified anytime. SQC is an ongoing validation tool based on the past 20 lab results, but by scrolling backward in time, long-term reliability can also be gauged (as it can by inspecting a long-term bias trend).
Eliminate data anomalies
Since the beginning, that is since inferentials first went on steroids, their imperfect nature has been accepted, along with the need to update a bias term based on lab results. Consensus has also been, since inferentials are normally used for closed loop control, that the operator should manually accept a lab result before the bias update software is allowed to complete its task, to prevent a "bad" lab result from impacting control. While this is all sound thinking and has served reasonably well over the years, the tedious custom software and manual intervention have also established themselves as a well-known source of headaches and reliability breakages. Automatic updating, it turns out, is more reliable, perfectly safe, and less of a headache for operators and engineers.
With automatic updating, the software is simplified, the operator is neither bothered nor relied upon, and the bias history accumulates less anomalies, which contributes to more successful use of bias trending and SQC. An appropriate bias update limit prevents unwanted process bumps. As mentioned, 50% of lab standard deviation is reasonable, since the lab result itself varies by more than this, and noting that a "confidence factor" of 25%-50% is also normally applied in the bias update algorithm. And the update software can still apply appropriate limits to ignore altogether any obviously unrealistic lab result. Looked at this way, one wonders why manual updating has been considered so essential all along. Only a very low-bar inferential, that requires large updates with each lab result, might not be suitable to automatic updating.
Many common inferentials, such as distillation composition, Reid vapor pressure, or flash point, depend heavily upon the pressure-compensated temperature (PCT). In these cases, there is often incentive to build a more complex inferential, with PCT as but one of several inputs, with hopes of greater accuracy. This is a common, but sometimes misguided practice, especially during multivariable control (MPC) projects, when more stock is often put in the modeling software than in process knowledge. In such cases, the more complex inferential can be compared to a simple PCT-based model to establish a minimum performance expectation, and to verify the extra effort has paid off and indeed it has not made matters worse, which is not unknown. This sanity check is easy to do, even for existing inferentials, as follows:
- Pull the previous 100 lab results with timestamps into a spreadsheet, along with corresponding inferential, pressure, and temperature values.
- Calculate the corresponding PCT for each lab result. As an even simpler check, use uncompensated temperature.
- Regress the PCTs to the lab data, and construct a simple linear PCT-based inferential. Compare the standard error of the original inferential with that of the PCT-based inferential for the 100 samples.
If the standard error of the original inferential is not significantly smaller than the PCT-based inferential, then little is gained, and likely much is lost by way of simplicity, robustness, and first-principles predictability by going beyond the PCT-based solution. Inferentials not PCT-based can also usually be "sanity checked" with simpler models to provide a minimum performance expectation.
As with the SQC spreadsheet, unbiased (or constant bias) inferential values should be used if possible. Otherwise, the results will be skewed in favor of the original inferential due to its bias having been adjusted with each sample along the way.
Another cause of low-bar inferential performance is the relationship between inferentials and MPC. Traditional practice is to develop inferentials in conjunction with schedule-driven MPC projects. This often leads to unproven inferentials becoming locked into MPC models, their true performance then becoming obscured within the bigger puzzle of understanding MPC performance. This syndrome of processes under inferential and MPC control that work, but that do not work well and are not easily understood or fixed, is a common industry plight.
To avoid this predicament, allocate a full year for inferentials prior to MPC projects. This can actually accelerate the capture of benefits by more quickly incorporating new inferentials into regulatory (or "base-layer") controls, which in turn are more amenable to performance monitoring and model updating. Experience has shown one year is a realistic timeframe to take inferentials from conception through maturation with proven closed loop performance, prior to consideration of MPC.
It is worth mentioning an identical situation exists with regard to "base-layer reviews," i.e., the practice of verifying regulatory control system health prior to deploying MPC. It has always been well known that base-layer improvements and inferential control comprise two of the most demonstrable sources of MPC project benefits. Failure to address these activities properly undermines every goal and leads to the "embrace of mediocrity" described above, while appropriate attention to inferentials and base-layer control in many cases may preclude the need for MPC at all.
To achieve high-bar performance, not only with regard to inferentials, but also with regard to process control and operation overall, consider these as best practices:
- Always historize the inferential value and the bias as a minimum. For simple visual trend inspection, focus on the bias history rather than the inferential history.
- Employ automatic bias updating to eliminate unwanted practices such as missed, multiple, or mistaken updates, and to increase fidelity of the bias record.
- Adopt active inferential performance monitoring practices such as periodic bias trend inspection and SQC monitoring.
- Use sanity checks to establish minimum performance expectations for inferentials and assure they are met or exceeded.
- Allow one year for inferential development and base-layer review prior to MPC. Avoid the "embrace of mediocrity."
- Incorporate new inferentials into regulatory controls to capture benefits quickly, demonstrate closed loop performance, familiarize operations, and facilitate easy model updates during the first year.
ABOUT THE AUTHOR
Allan Kern (email@example.com) has 30 years of process control experience and has authored several papers on multivariable control, expert systems, and decision support systems, with emphasis on operation and practical process control effectiveness. He is a licensed professional engineer (inactive) and a senior member of ISA.
Introduction to inferentials
The concept behind inferentials is to calculate a stream property that otherwise would require either an online analyzer or periodic laboratory analysis. Online analyzers are expensive to purchase, install, and maintain. Laboratory analysis is also expensive; the results are usually several hours old by the time they arrive; and it is usually only practical to do one analysis per day or per shift. Given these limitations, if an on-stream property can be reliably calculated in real time on the DCS based on existing measurements of pressure, temperature, flow, etc., thus enabling real-time control and avoiding the costs and headaches of on-stream analyzers and lab dependency, it is a no-brainer to do so.
The inferential life-cycle has three steps: modeling, deployment, and support. Modeling, i.e., developing the equation that will be used to calculate the property, is accomplished in several ways, the most common being a spreadsheet regression of historical process data. For example, diesel 90% cutpoint is often modeled as a multi-linear function of draw temperature, pressure, feed gravity, pump-around rate, draw rate ratio, etc. Selecting the best inputs and collecting a good modeling data set are among the usual skills of the inferentials engineer.
Another technique is to rely more heavily on "first principles" by leveraging process design and engineering equations into the form of the model equation. For example, diesel 90% cutpoint is also often modeled as a function of liquid draw temperature (pressure-compensated) and liquid/vapor mole ratio, based on column design equations. The constants that go with this equation are, as before, solved by regressing historical process and lab data.
A third modeling approach utilizes "neural network" technology, whose advantage is nonlinear modeling without a prior knowledge of the equation form. Each method has its pros and cons.
Deployment is the process of putting the inferential equation online. Often, this is a simple matter of configuring the calculation on the DCS, like any other calculated point, where it can be used for monitoring, tied to regulatory controls, or incorporated into MPC. Where commercial modeling software is used, such as inferential toolkits or neural network packages, deployment may involve installing and configuring licensed components on the DCS.
Support is the process of assuring continued reliability of the inferential and generally consists of two activities: updating the "bias" based on ongoing lab results and validating long-term inferential performance by inspecting bias trends or applying statistical quality control (SQC) techniques. Although ideally the inferential serves in lieu of lab analyses, in most cases, lab sampling continues to some degree, and the results are used immediately to adjust the inferential bias and over the long term to validate overall performance.
Bias updating involves comparing each lab result with the inferential value and adjusting the bias, typically by 25% or 50% of the error, and with a maximum update limit based on the lab test standard deviation. The bias update mechanism keeps the inferential on track over the long term and responds, albeit gradually over the course of multiple samples, to process changes that may not be accurately reflected in the inferential inputs, the chosen equation form, or the modeling data set. Unrealistic lab results, i.e., those outside of engineering limits or those resulting in an inferential error of more than 3 sigma, are typically ignored by the bias update routine.
Inferentials for control
Although inferentials are often thought of as working hand-in-hand with multi-variable control (MPC), inferentials are also readily incorporated in regulatory controls. For example, in a crude distillation column, a diesel cutpoint inferential can be cascaded to draw rate at the regulatory level. This is an effective approach to capturing the benefits of inferentials without the overhead, unreliability, and operational difficulty of MPC.
In some cases, an inferential is used to provide a continuing real-time result between online analyzer results, to fill the several-minute cycle gap typical of on-stream analyzers. In this case, inferential accuracy is not as important since there is less time for drift; although if the inferential is expected to fill in for lengthy periods of analyzer downtime, then inferential reliability and bias updating again become essential.
Treating bad actors
Not all process parameters lend themselves to reliable inferential modeling. Those that relate to liquid-vapor equilibrium, such as distillation separation, are generally easy to model and robust in performance. Viscosity, sulfur, and many other properties are generally difficult and often impossible to model. In between are some models wherein low-bar performance may be the best that can be accomplished, but it is still better than nothing.
Where an inferential fails to perform as expected, it is usually due to missing an important input (which may be unavailable or simply overlooked), an incomplete modeling data set (some operating modes are unrepresented), or an inappropriate equation form, whether empirical or first principles based.