[foxboro] Unique Nature of the UNACK Parameter

I wanted to share a bit of interesting information.  Recently we updated
some alarm routing to send all messaging to a single AIM* instance.  In 
the
process we mistakenly reconfigured some message groups that had previously
only been routed for annunciator usage.  Within hours of making all the
changes, it was noted that the message database was becoming unexpectedly
large.  We found that HLBL code used to consolidate area alarm status into
a single tag was the source of our problem. 
The code scans compound alarm parameters, and places a single CIN in a 
alarm
status, priority and, UNACK status matching the compounds scanned.  The 
code
clears the UNACK on the CIN on the completion of each scan if no
unacknowledged alarms are found.  The setting the UNACK parameter to FALSE
causes an alarmack message, even if UNACK was already FALSE.  We corrected
the code to clear the UNACK only if UNACK is TRUE. 

Before...
   IF ( NOT OVERALL_UNACK ) THEN
      ::AREA_ALM.UNACK := OVERALL_UNACK;
   ENDIF;

After...
   IF (( NOT OVERALL_UNACK ) AND ::AREA_ALM.UNACK ) THEN
      ::AREA_ALM.UNACK := OVERALL_UNACK;
   ENDIF;

Does anyone have similar experience with UNACK.  Our concern is that
acknowledge buttons are likely to be pressed on custom graphics when no
alarm exists.  An alarmack message that cannot be paired with an alarm
condition may make our alarm logs appear incomplete, cause confusion, and
draw suspicion.

Jim
-----------------------------
James D. Murphy
Sr. Process Control Engineer
Eli Lilly and Company
Lilly Corporate Center
Drop Code 3413
Indianapolis, IN 46285
-----------------------------
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: