One of the most common issues I come across when reviewing alarms isn't seen as a problem at all by many DCS engineers - using Alarm flags to drive logic and control functions.
For example (in Honeywell TPS), imagine the design calls for low-level protection on a tank pump-out - simples, use the PVLOFL alarm flag on the level Point to drive the pump interlock, quick bit of logic to tie the two together and there you have it.
Why would this be a problem? Well it usually isn't for the first couple of years of operation, then someone decides to do an alarm rationalisation study....the alarm setpoint gets changed..et voila... you've just broken the control action, possibly without realising it (unless you has the diligence and foresight to do a cross-reference check...you do those every time you make a quick alarm setpoint change, right?)
So please, folks, keep your alarm and control actions separate, much better to use a comparator in the logic against a numeric value. That way we can rationalise our alarms without worrying about breaking the control layer...
For example (in Honeywell TPS), imagine the design calls for low-level protection on a tank pump-out - simples, use the PVLOFL alarm flag on the level Point to drive the pump interlock, quick bit of logic to tie the two together and there you have it.
Why would this be a problem? Well it usually isn't for the first couple of years of operation, then someone decides to do an alarm rationalisation study....the alarm setpoint gets changed..et voila... you've just broken the control action, possibly without realising it (unless you has the diligence and foresight to do a cross-reference check...you do those every time you make a quick alarm setpoint change, right?)
So please, folks, keep your alarm and control actions separate, much better to use a comparator in the logic against a numeric value. That way we can rationalise our alarms without worrying about breaking the control layer...
RSS Feed