1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 <2006> 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: AlarmHandler - filtering vs. HYST |
From: | Randy Flood <[email protected]> |
To: | [email protected] |
Date: | Mon, 17 Apr 2006 07:51:17 -0500 |
Operationally "Not Significant " is a situational term. If I have degrading vacuum, which hits a MINOR I want someone to look at it ONCE, to evaluate the need for intervention. What I don't need is for vacuum sitting at the MINOR setpoint to constantly alarm, as it goes above and below. Most would think that the likelihood of something like that happening with any regularity is small. When you have hundreds of vacuum pumps the regularity goes way up. What I really need is a way to disable just individual MINOR alarms while allowing the channel to still alarm on a MAJOR.
But in some cases I want users to get at least the initial flash, so conditions can be evaluated. Once I know there is a problem to be watched I only want to know if conditions deteriorate to the MAJOR condition.
You should look at the "NOACK Transient" mask in ALH. With this set, when
the PV goes out of alarm ALH will stop beeping at you.
Except when the value is hovering around the setpoint. HYST could be a reasonable to deal with this, provided you can get someone to decide what a reasonable value is for a couple of thousand different channels. A better way to deal with it is just to give the user the ability to disable MINOR alarms easily without affecting the MAJOR alarms, or having to go into the configuration tools.
One thing we've done at APS is to utilize $FORCEPV. If you are in a mode where you only care about major alarms (e.g. Conditioning power supplies), the $FORCEPV disables/modifies the alarm until that mode is over. It cuts down on nuisance alarms a lot.
I certainly agree.
I also believe that alarm limits, especially MINOR alarms, should be influenced by operational reality as well as engineering design. If the normal value of an analog input is close enough to an alarm limit to generate alarms when no action is actually required, that limit should probably be changed.
Based on personal experience I can state that any significant number of
"nuisance" alarms will lead to users becoming less reactive to real alarms.
We were having enough issues with operators silencing ALH "forever" (so
they wouldn't be annoyed by "false" alarms) that I modified ALH to put a
black border around the button on the screen so you could tell it was
silenced without opening the alarm window.
We have had similar problems in the past for the same reasons. A re-evaluation of the which parameters were monitored by the AH and of their setpoints has help fix this problem. Off loading alarms which were not operational driven also helped. (The trend is often to place non-operational alarms in the control room because the control room is always manned. Setting up AH which can page or email interested parties makes this mostly unnecessary.) We have eliminated many MINOR alarms and the situation is better than before.
-- Randy Flood Chief of Operations ASD Operations Group 630-252-1767 4-1767