[foxboro] Alarm horn/lights, Alarm Manager Application, Alarm Panel and Table Configuration, Alarm Conventions and Strategies on Fox IA

List,
        If you are not interested in Alarm horns and lights, Alarm
Manager Application, Alarm Panel and Table Configuration, or Alarm
Conventions and Strategies, on Foxboro IA systems, flush this note now
and save yourself a lot of time.  If you ARE interested, let me warn you
that I can't convey my message to my satisfaction without using 25 years
of my historical observations around these issues.  Rest assured that
there are some things of immediate value that you COULD take away from
this, and some reccomendations that COULD be made by a group of
interested users, for product enhancements in these areas.
        The list recently touched on a subject that is near and dear to
my heart because I have had to fight a battle with our production people
over this issue and I see a real need for a better solution from
Foxboro.  The issue is much larger than being able to silence an alarm
horn with an external button, but that is a good place to start.
        We started with the same problem described by many of you in the
past.  The old WP-20 and 30 QWERTY keyboards had a Red Horn Silence
button imbedded in them, much like the old Annunciator keyboards.  Newer
style WP-30 QWERTY keyboards were PC keyboards and didn't have the Red
horn silence button so Foxboro provided a solution that used the F-10 or
F-12 key, (I can't remember now), to perform the "horn silence"
function.  When the Sun boxes came out, that function wasn't perpetuated
to the SUN keyboards.  They recommended silencing the horn through use
of the "Alarm" key on the top menu bar of the DM or Foxview window or by
adding the expensive Annuciator Keyboard that also required an expensive
GCIO interface.  Either pick issued the "horn silence" command. =20
        We opted to use the top menu "Alarm" pick from the DM to silence
the horn but technicians complained that it also called up the unwanted
"Alarm Manager" window over the DM window they were using.  That forced
them to look at the alarm that caused the unwanted horn. It is my
contention, that if you have an alarm important enough to sound a horn,
it should have a corrective action required to be taken by the recipient
of the horn sound, and he/she needs to verify/look at each alarm to
determine what to do about them.  If an external button is provided it
lets the recipient silence the object of annoyance without ever
recognizing what may have caused the alarm.  Having said that, my
experience also tells me that we have too many nuisance alarms that
"could be" occurring in processes that the tech is responsible for
operating.  Some processes may not be running or aren't currently as
important as other process alarms being received.  The old
Annuciator/Modular Keyboards allowed a tech to have a visual overview of
where new alarms were being initiated based on the graphic screen it was
displayed on.  The Alarm Manager application does a tabular listing of
alarms but doesn't easily convey where the alarm fits in relationship to
operating processes. =20
        We liked the Annuciator keyboard concept and organized our
initial process graphic overview screens in the same familiar rows and
columns used by the panels of the Annunciator KYBD.  We started using
the keyboards and configured the Alarm Panels and Alarm Tables to make
them work correctly.  We found that techs that had a single top mount
CRT with a correctly configured Annunciator KYBD mounted in the panel
directly below it, used the Annunciator KYBD's most of the time to
access graphics in alarm.  If they had multiple graphics in alarm they
could see a flashing light next to the buttons that had new active
alarms and could decide which was the most important to look at first,
based on what they were doing at the time.  To access the graphic, they
pushed the appropriate button and that graphic was displayed on the CRT
immediately above the ANN KYBD.  As an added bonus that action also
initiated a "dmcmd" horn silence. =20
        As a single operating technician took over responsibility for
operating additional processes, their need for more CRT's increased.  We
went to an in-bay and top mount CRT configuration and moved the ANN
KYBDs into a wedge or into an adjoining bay.  When this arrangement was
used we found that many of the techs quit touching the ANN KYBD to call
up the display but sometimes visually used the lights to tell them which
graphic the new alarm was coming from.  They silenced the horn by using
the Red Button or the function key on the Alpha KYBD mentioned above, (I
think because it was directly in front of them and in line with their
focus on the CRT's!), instead of reaching over and pushing the ANN KYBD
button that might call up the user display on a CRT that they were using
for another function.  They used our ANN KYD "graphic" imitation to
access the graphic on whatever CRT they wanted.  In our case, the name
of each operating seat that a tech "runs" is displayed on the Top menu
bar of the DM whenever a tech logs into his/her operating environment.=20
        A pick on that seat from the top menu bar causes a single
graphic, (we call it the "Initial Seat Graphic"), to be displayed.  The
"Initial Seat Graphic" has pickable rectangles that call graphics just
like pushing the ANN KYBD button. All graphics associated with that
operating seat have pick points used to call up graphics from any
process that is within the "SEAT Operator's" domain.  Using this
strategy, an operating technician, who often controls multiple
processes, is never more than two mouse clicks away from accessing any
of the graphics in his/her operating environment.  One click on the top
menu bar to access the correct "Initial Seat Graphic", and the 2nd pick
to call up the custom process graphic that depicts that section of the
process. =20
        Each "Initial Seat Graphic" is a fullscreen display that
contains 192 rectangles laid out just like the 12 panels containing 16
graphics each as defined by the IA "Alarm Panel Configurator".
Essentially, we have created a single graphic that mimics what is
configured in an individual WP's "Alarm Panel Configurator".  I know you
all must think this thing looks really clumsy and it might, but it has
been easily accepted and even welcomed by production because it allows
an operating tech to access any graphic he/she is responsible for from
one sheet of glass.  I am including a link to a graphic display that my
good friend Duc ??, (I can never remember his complicated last name),
posted on the Cassandra website today.  I have added the panel and
button text in an unobtrusive gray color so everyone can understand the
layout.  That text isn't shown on our actual "Initial Seat Graphic":

http://www.thecassandraproject.org/temp/Initial_Seat_Graphic.jpg

        We also developed a convention using the "Display Conventions"
configurator and the .ALMSTA parameter that is available in every block
that has alarm capability. Our convention changes the background color
of "Normal Text".  Our text displays the "engineering units" .EI1 next
to each .PNT or .MEAS variable on the graphic. The text changes
background color based on the following .ALMSTA conditions:

   Condition                     Background Color
1. Normal (No alarm or inhibits) Black text on White background  (color
#15)
2. Alarm Inhibit Active          Black text on Gray background   (color
#23)
3. Unack'ed but not Active       Black text on Yellow background (color
#11)
4. Active and Ack'ed             Black text on Red background    (color
#9)
5. Active and Unack'ed           Black text on Red-flash bckgrnd (color
#21)

        We use the same .ALMSTA convention and attach it to fill color
of rectangles that are moved to the back of discrete valves, pumps, and
motors so that they can indicate the current alarm status of discrete
devices as well.        This convention allows operating personnel to
quickly recognize the alarm status of all loops once they are looking at
the detail process graphic and it allows us to use d_edit to search
through the display file and capture all Compound:Blocks using .ALMSTA
connections.  This makes it possible to build the alarm table
configuration for all of the graphics automatically!  The Alarm Panel
Configuration can also be derived from the configuration of our "Initial
Seat Graphic.
        Flashing lights or colors are very effective "attention
grabbers" and I was disappointed to see that flashing colors are not
inherently supported by Foxview on Windows based IA machines.  The
"Flashing Red" light on the old Annuciator Panels, as well as the
"Flashing Red" color on our process graphics allow operators to quickly
focus their attention where it is needed.
        I have finally laid the background for the product enhancement I
am interested in:
        Building Alarm Panels and Alarm Tables on WP's or AW's causes
memory in the station to be setup to accept, store, and track alarm
status and conditions.  That memory is used to drive or refresh the
Annunciator lights.  For each of the possible, (12pnls x 16buttons =3D
192lights).  Each light has 4 possible conditions:

0 =3D No light =3D No Alarms on this graphic, (either Unack'ed but not
Active, Active and Ack'ed, or Active and Unack'ed)

1 =3D Solid Yellow Light =3D Only Unack'ed but not Active Alarms exist =
on
this graphic.

2 =3D Solid Red Light =3D At least one Active and Ack'ed Alarm and no =
Active
and Unack'ed Alarms exist on this graphic, (Don't Care about Unack'ed
but not Active alarms)

3 =3D Flashing Red Light =3D At least one Active and Unack'ed Alarm =
exist on
this graphic, (Don't Care about Active and Ack'ed or Unack'ed but not
Active alarms)

        If these memory resident variables were mapped to Global Objects
in the WP memory, you could create a graphic that could access and
display the alarm status of any process graphic in your system and techs
could operate their process and/or monitor another one from a remote
location.  My "Initial Seat Graphic" tries to convey what an operating
tech would be looking at.  The lighter red color on that graphic is
really configured to be a light-red/dark-red flashing color.  Hopefully
you can all envision what I spent so many words attempting to describe.
http://www.thecassandraproject.org/temp/Initial_Seat_Graphic.jpg

        My observation has been that the Tabular Format Alarm Manager,
(with all of it's sorting and organizing tools), isn't the best tool for
real time process decision making.  When operating multiple processes it
is difficult to evaluate which process needs the most attention, and the
use of the AM requires the techs to switch between the AM and DM/FV
windows to do their jobs.  I have heard them voice frustration over this
time and again.

        The global objects for each panel light could be named something
obvious like this:
WPNAME  PNL#BTN#        PARAMETER       0=3DNo_Lt 1=3DYellow_Lt 2=3DRed_Lt
3=3DRed_Flash
01WP01  :P01_B01        .ALMSTA 01WP01 Panel-01 Button-01 Status
04WP02  :P15_B16        .ALMSTA 04WP02 Panel-15 Button-16 Status

        Overall, I think that Fox IA has a good alarm handling and
routing structure that is flexible for the users.  It is a bit complex
to understand but that is the result of giving users flexible
configuration tools.  Maybe next time I will bore you with a method used
to evaluate and dramatically reduce the number of configured and
actuated process alarms on a system, but I've already "Talked Too Much"
today and Duc will have to open the door on Foxboro@xxxxxxxxxxxxx to let
this big email tank roll through.

Cheers,
Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corporation
Carrollton, KY   USA
 
 
_______________________________________________________________________
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: