Re: AlarmHandler - filtering vs. HYST

[Terry Carlino <carlino@jlab.org>]

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.