Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: AlarmHandler - filtering vs. HYST
From: Terry Carlino <carlino@jlab.org>
To: tech-talk@aps.anl.gov
Date: Mon, 17 Apr 2006 08:35:40 -0400
Brian McAllister wrote:
[ This is a bit late, just catching up. ]

On 4/7/2006 at 12:31:30 EDT, Terry Carlino wrote:

> Probably the best way to compensate for this problem. thanks.


> Steve Lewis wrote:

>> Try this (one of the best features of ALH): use
>> >> $ALARMCOUNTFILTER count seconds


This will help you, but (IMO) the best solution for any alarm hovering
around a transition value is almost always to set HYST appropriately in the
record. I realize you would have to convince others to modify the databases
for this.

The ALH filters ignore alarms regardless of the size of the change that
induced them, whereas HYST allows you to ignore only changes that are "not
significant".

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.
HYST also has the advantage of controlling alarms at the source, so if you
use alarm status for other purposes, such as colors or visibility on
displays, these will also be "filtered" and users won't get used to
ignoring them if they flash.

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.
[ minor rant follows ]

I believe that *all* analog ADC inputs with alarms should have HYST>0 (as
well as MDEL/ADEL>0, for efficiency).  The minimum value for HYST should be
just over 1 bit, so you won't generate alarms if the ADC is sitting on a
bit transition.

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.


Replies:
Re: AlarmHandler - filtering vs. HYST Randy Flood
References:
Re: AlarmHandler - filtering vs. HYST Brian McAllister

Navigate by Date:
Prev: Re: Alarm Handler in Global mode in and outside the control room Ernest L. Williams Jr.
Next: Re: AlarmHandler - filtering vs. HYST Randy Flood
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Re: AlarmHandler - filtering vs. HYST Ernest L. Williams Jr.
Next: Re: AlarmHandler - filtering vs. HYST Randy Flood
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·