There are Integrated 2oo3 for PID control in DCS systems? How to prevent PID malfunctions due to instrument failure different to bad PV or step change fails?
Lately we have faced in my plant a few shoot downs due to instrument fails associated to PID controllers. I'm not talking about the SIS or Interlock system, The shoot downs has occurred after erroneous movements of the PID associated valves. That happened because the instrument didn't went to bad PV or showed a strong change in an step; instead of that, the instrument transmitted a smooth increasing or decreasing signal deviating itself from the real value. The DCS in my plant is a HONEYWELL TDC-3000. I already searched for an integrated 2oo3 PV regulatory and I didn't find it. So the idea that came to my mind was if there is this tool in other DCS, or if this problem is frequent in other plants. And of course, how other engineers has solved this problem. I already created a Control Language Program which track important instruments going to PID controllers in order to detect step changes and automatically set the controller in MANUAL mode. But this algorithm doesn't work for smooth increasing o decreasing signal fails.

The typical approach for dealing with a single instrument failure causing process upset, is to use multiple sensors. If you use 3 sensors, a simple median select of the process values from the three sensors is used as the PV input to the PID algorithm.

If you had a system that was Foundation Fieldbus enabled, you could rationalize going to 2 sensors using the integral quality of the process variable to select the value for the PID controller.

Yes! a simple an effective median of three will work! thanks!.

I didné quite understand about mating a rationalization to two sensor using the integral quality. Could you explain a little more?

Foundation Fieldbus sensors send the process value and a quality value associated with it. This can indicate general health (GOOD, BAD, UNCERTAIN) along with amplifying substatus (Not Connected, Configuration Error, High Limited). Use of these status conditions can lead to better overall reliability figures when using diagnostics on 2 sensors when compared with basic median select on three sensors.

Ohh I see. We are making an FDM (Field Device Management) project which is almost frozen. It could bring me more reliability.

Thank you!

One other solution comes to mind, but it requires an intimate knowledge of the process physics, and more than just minimum instrumentation.

Often, when your process shows an increased flow, for instance, there are other variables that change directly with that change. For instance, an increased flow would be accompanied by a higher pressure drop across the piping, a lower or higher temperature at your destination, perhaps a higher load on a pump, or the flow corresponds to a given control valve position. Also, your mass balance will deviate over time, in an unusual slope, that could also cause an alarm, or take a loop out of automatic. A tank will empty in an inconsistent amount of time, or show an impossible slope, knowing the capability of the process equipment.

This is the basis for process modeling. So in some cases, you may find it more reliable to use the implied knowledge of all of your instruments to verify the current action of your control equipment, that to install duplicate instruments.

I have found that whenever you have two instruments reading the exact same process variable, an inordinate amout of time is spent on making them match up, probably more than is useful, in many cases.
I know the Triconex system by Invensys has two of 3 arbitration built into the hardware design, so it might be easier to manage with the progression of control engineers through a facility.

Hi Carlos I recommend you to use a three or four sensor measurement system with a median algorithm implemented. Each of the PV has to be not used in case of cut wire, overload or with a high deviation from the median.
Just in case, if the system has a total malfunction, a nice security protection is to set the PID controler in forced manual mode and trigger an high high alarma and keep the PID output as it was before the problem occurs.
Best Regards.

I have a pit tank with a level controller that drives the suction pumps. It is important to maintain the level and at 2300 gpm it can get out of hand very quickly. Sometime in the past the programmer/engineer used two level sensors. The PID loop worked off one sensor. If the sensors did not agree the PID loop would work off the other sensor. This worked for a number of years until one day the sensors did not agree and the PID switched sensors, to the bad sensor. The pit tank immediately overflowed and the problem came to my attention.
My investigation showed the logical flaw, which was, how to determine which sensor was bad? After much deliberation I instead decided on an easier method. I averaged the two sensors since an average of a real value with either 0% or 100% fail of the second sensor yielded an acceptable operation. I then alarmed that there was a difference of over 10% between the two sensors. Maintenance could repair/replace the damaged sensor and all would be well.
The reason for using three sensors is to help determine which sensor is bad, this assumes that only one will go bad. Then that leads to using three sensors using different technology or means to determine the value, again to determine the failed sensor, assuming only one will go bad. I have seen 2 out of 3 go bad, or one goes bad and is ignored until the second goes bad.
Too many times we build so that if something goes wrong the machine will still operate normally to maintain up time. However this is thwarted by humans that think it is working ok now, it’s not a priority, until it really goes bad. So add your back ups but create alarms that cannot be ignored. I had one machine that if the sensor failed it would run, but not restart, and it would run with a countdown clock to a controlled shutdown, forcing a repair.

As an example of my earlier comment, in Mr. Baker's case, having load sensors on the suction pumps, or comparing supply side flow instruments or inventory with destination tank inventory could help you determine whether the level instrument reading was reasonably valid.

If the tank level is low, at the suction pickup of the pump, the pump load will be very low, and not smooth. If the level is too high, the load will be high, due to the extra flow possible from the reduced head.

Some experiments with a $200 sensor and a spare 4-20mA loop would show you if the concept would work, for your particular equipment. I like motor load sensors, as they are much more difficult to fool than any level sensor, and they can be calibrated for a particular motor to indicate mechanical load, using design parameters from the motor manufacturer (saves buying a kilowatt transducer).

Of course, if this part of the process is completely open loop (no mass balance closure), you'd want to thoroughly test the high-low pump load indicator. Usually, someone keeps track of 2300 gpm flows, even if going to the sewer. A combination of two abnormal conditions could at least tell someone they need to look at it, or fail the equipment to a safe state for the process, as Mr. Baker illustrates above.

Mr Raymond, yes, if I would have two instruments I could make the philosophy of takeing the average and put the controller in manual after any deviation. But in my case I only have one instrument, so if we decide to ad instruments, we for sure will put three and apply a 2oo3 strategy like the medium of three values with deviation alarms.

Mr Williams, Making some modeling sounds very interesting. In fact, I could make an inference of the level based on the two inlet flows and in the downstream level-valve opening (next vessel). For sure I could determine if the level has a correct measurement making the comparison between the inference and the measured value. I even can create a logic which will put the controller in manual mode if the fail shows up.

But there is a tricky thing. if I make this inferential model, probably it would be more accurate with transfer functions models, and that kind of models has to run in my Advanced Process Control APP. That means that a basic control loop will depend, in a certain way, on the APC server to go to a safety manual mode. If I decide to make the inference on the HPM (basic philosophies), I highly doubt that the prediction would be as good as I'd wanted because there will be only linear calculations. Consider that it's not an small process. we are talking of the bottom level of a column (6 m diameter, 5 meter high) and with 3000 m3/h of flow rate. But I could try.

The other option is simply change the diaphragm based level transmitter with a displacement-based one. Consider that this problem happened for the firs time in this column after 15 year of operation, but it has happen a couple of times in other sections.

So, at the end, if it will be a matter of money. Definitely, making the inference modeling could be the cheaper one.

Thank you all for your responses !.

Carlos,
1- Did you have to change those faulty transmitters ?
2- Can you explain what process this is?
3- did u try to use SIS transmitters for comparison . - specially if voting transmitters .
Hope we can get clear picture on that.

As Ron already said before, if you don't have redundant instrumentation, use other variables to infer the one you are using for control (that variables can be flow rates, pressures, valve openings, etc.), and with them build a discrepancy tag to check its validity, to alarm the Console Operator and/or to put the control in MAN.

In your case, where the faulty instrument is a level indicator, a useful extra variable could be pump's suction pressure (it will tell you how close you are of cavitation), or column's bottom and top pressures to calculate level assuming a standard density.

But no matter whatever you do, you should do it on your HPM (second best alternative is going to be your AM, the ideal place to build control applications tags that require CLs or use tags from multiple HPMs/UCNs), where availability is high, but never on a server outside your control system (MPCs are nice to have applications, but not imprescindible for you plant operation).