PV status for uncertain

[VickyWu]

Hello All
With reference to AG-181 R3.1 section 5.5.1 fault handling as follows:
"… in previous ITK versions, the PV status would be set to uncertain if the following condition was true:
• If a value is out of the scaled range
Commentary:
FOUNDATION fieldbus specifications no longer support flagging an out-of-range condition as uncertain.
…
When a control algorithm's input is set to bad or uncertain, or in the event of communications
subsystem failure, it shall be possible to configure the output to fail as follows:
•Configured fail state (hold last good value or shed to manual)
•Mechanical fail state (loss of air position)"

Please advise which option is better: “use uncertain as good” or “use uncertain as bad” for petrochemical plant.
thanks
Vicky

[Heather Santos]

Using uncertain as good could increase availability but it may not be safe for some applications. How uncertain is treated should be the result of evaluating the impact of that decision.

Is there a risk to personnel?
What does the control valve action influence downstream?
Is the loop for monitoring or control?
What is the percentage of time a PV would spend in an uncertain status?

Does anyone have any guidelines they follow, or is uncertain treated the same way across a plant?

[jberge]

This setting would come out of the CHAZOP. "as good" would provide greater availability. "as bad" would be "safer" (but it is not an SIS) but may result in more loop shutdowns.

You can read more in the yellow fieldbus book:
http://www.isa.org/fieldbuses

Cheers,
Jonas

[rezabejd]

When a control algorithm's input is set to bad or uncertain, or in the event of communications subsystem failure, it shall be possible to configure the output to fail as follows:
Configured fail state (hold last good value or shed to manual)
Mechanical fail state (loss of air position)

Loss of Communication will always be "BAD". The default behavior is to shed ACTUAL mode to manual. Default is also to return to "TARGET" mode when status returns to GOOD.
"Hold last good value" is the default behavior. Be sure to test this on your system . . . I know it works this way on mine.
Configurable behavior: "TARGET to MAN on BAD IN"
With this option the PID will remain in MAN after IN becomes GOOD. We tried this but operators didn't like that loops went to MAN and they might miss it. Now we don't invoke this option any more.
More configurable behavior: You can use "propagate fault forward" option and "fault state to value" in valve AO block. There is a configurable "fault state time" (how long to delay action when a fault is detected, in seconds) and "fault state value" (the actual output value you want when the fault state is invoked)
I believe you have to set "propagate fault forward" in AI, PID, and AO (? - may be "backward" in this block). I have never used the settings or tested them - be sure to do this (testing) if you aim to use it. As Jonas implied, we choose to "not" rely on the basic controls for safety interlocks. Mechanical and loss of power valve positions are assumed for flare / safety valve sizing and HAZOP cases.

The basic controls are only considered as a "protection layer" when no component is part of an initiating event.


Please advise which option is better: “use uncertain as good” or “use uncertain as bad” for petrochemical plant.
A friend described a case where the "above full scale = uncertain *feature*" almost resulted in a furnace burning down. The temperature (PV) exceeded full scale and the loop was stuck in MAN - kept the heat on. Clearly bad in this case to "use uncertain as good". As you may have some ITK4 or 5 devices slip into the plant I would default to "use uncertain as good" but be sure to alarm to alert operator when the uncertain status PV is being used for control.

That being said, my company is good at lawyering and they would have me say that you're on your own when making these choices and we have no liability for unforeseen consequences, etc.

One more thought . . . we worried alot about comm loss when we designed our plant 12 years ago. It turned out to be much better than we feared. H1 rarely has issues and the ones it has are nearly always self-inflicted or "physical layer" (water in instrument housing, loose terminations, too many terminators, sloppy or crazy shield grounding practices, etc.). Some folks have found ways to break it but they must really work at it. It's good to think about them and thanks for reading AG-181 by the way . . . but a solid install with check-marked devices and hosts should really have minimal comm issues.

[VickyWu]

thank All replies
For the yellow fieldbus book, it was read long time ago. I will read it again.
What I am concerned is the control loops, I will check if any alarm is configured to alert operator when the uncertain status PV is being used for control. We are doing FAT.