Finding Freebies in Fieldbus

March 2, 2009
Can We Use the Standard Deviation Method to Flag a Suspicious Measurement?
This article was printed in CONTROL's March 2009 edition.
By John Rezabek, Contributing Editor

Freebies are good—especially in the current economic climate. And they can be found if you take the time and trouble to look for them.  A neighboring plant last week experienced an unplanned shutdown and some equipment damage due to a measurement that was believed when it shouldn’t have been.  A level with a “displacer” type level transmitter―very common in process plants built before 1980―was well insulated about its external cage, which houses the displacer. But the “torque tube,” which connects the dangling displacer to the transducer/transmitter circuit, was not sufficiently insulated for the 20-year weather event we experienced, and enough ice crystals built up in it to cause the level indicator to show “OK” when, in fact, it was low.

Among other measures, such as improving redundancy and functional checks of things like level switches, my neighbor went searching for other ways to make his operator aware of a suspicious measurement.

Analyzer engineers and their customers on the advanced control side have been deriving means of ensuring that a model-predictive controller doesn’t make any rash moves if a gas chromatograph (GC) is flat-lining. GCs typically produce a measurement every three to 10 minutes or more, so one could write a very simple test―either in the instrument or in the DCS―that compares the latest result to, say, the last three cycles. If all the samples are the same within a tolerance of, say, 0.001 units, the GC is flagged as “offline” or bad and removed from the model-predictive calculation.

My neighbor found a parameter in his PID block called “STDEV.” It appeared to provide a running estimate of the “standard deviation”―a way to “measure” the degree to which a set of data clustered around the mean or average of the set. A big standard deviation means the data is all over the place, while a small one means the data strays little from the average value. Manufacturers use standard deviation to measure how consistently they’re cranking out their widgets. Can we use the same measurement to flag a suspicious measurement?

I was talking with Sean Vincent of Fieldbus, Inc.,  Austin, Texas, last week, and he scoured the Foundation fieldbus standards for this STDEV parameter in AI and PID blocks. Turns out that the parameter my neighbor wanted to use was a “custom” parameter in his particular DCS (DeltaV), and the same parameter appeared in Rosemount fieldbus transmitters. I searched through the DDs of Yokogawa, Endress + Hauser and Foxboro (IPS) transmitters for something similar, but I have not found one yet. Most DP makers offer statistics-based plugged-line detection on digitally integrated devices, but I’m not sure whether it’s free.

The settings and alarm points of a standard deviation alarm demand careful study and testing. If you set the alarm point too high, false detections will make the whole scheme useless. If you set it too low, a frozen or otherwise broken measurement may drive the process down a destructive, wasteful or even dangerous path before it’s brought to the operator’s attention.

I’d suggest finding a similar instrument in a less critical or indicate-only application and hooking up my flat-line detection scheme. After ensuring there were no connections to other loops, I would block it in―shut the manifold or process root valves―and watch the trend of numbers from the flat-line algorithm. If I know I have five minutes to an empty drum or an overflowing tank, I would set my alarm for the standard deviation after 2.5 minutes, apply it to the “real” loop in “log only” mode (no audible alarm), and see how many false alarms I saw over a period of 10 to 30 days. If you can, block in the device in question, and see if you get a detection within your tolerances. If it works, you have just implemented data validation, for “free.” OK, after a little work . . .

Trimmed budgets can give end users and their solution providers motivation to explore the hidden features of their fieldbus-capable systems. Share any jewels you find with us.