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

Tom,
    You are not on your own with Alarm Management battles! I would like
to point out that the ISA  are currently developing a new standard for
DCS and SCADA alarm ststems, called SP18.2. There is an Invensys person
on that committee (Danny Crow). Maybe we could get him involved with how
he feels Foxboro I/A fits with complying with the new standards.The
direction that the new standard is heading appears that the person
configurating alarm systems will have defined responsibillity, and under
that regime I would definitely not like to be explaining to some higher
authourity (ie Major Incedent Investigator) how more nebulous techniques
like using sequence blocks and setpars etc comply with new requirments.
 As I mentioned before, a lot of the anguish about alarm destinations
could be better managed if all alarm group paramaters were connectable
and setable. The recent Australian User Group Conference included this
in their wish list, and I forgot to ask for it at the last USA User
Group Conference. There is an increased demand for an increase in
installed alarm/operator ratio (because that is a money thing), so alarm
traffic is becoming more important. The EEMUA guidelines recommend that
for DCS's with a ratio higher than 1000 installed alarms per operator,
advanced alarm management techniques should be used. Currently we have a
density of over 8000 installed alarms/operator at best case (all
operators in the control room) and over 25000 installed alarms per
operator at worst case (only one operator in the control room)and still
comply with The EEMUA guideline for alarm traffic per operator. These
densities can only be achieved by using advanced alarm masking
techniques, and changing alarm destiation for different situations is
one of those techniques to reduce alarm floods.
Regards,
          Alan Armour.
  P.S by the way, it is already Thursday here in Australia, and it is
beautiful, so all you folks "Stateside" have something to look forward
to.


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Thursday, 23 June 2005 4:28 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [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. =3D20
        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. =3D20
        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. =3D20
        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.=3D20
        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. =3D20
        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 =3D3D
192lights).  Each light has 4 possible conditions:

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

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

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

3 =3D3D Flashing Red Light =3D3D At least one Active and Unack'ed Alarm =
=3D
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=3D3DNo_Lt 1=3D3DYellow_Lt
2=3D3DRed_Lt
3=3D3DRed_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
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
                                DISCLAIMER

The contents of this electronic message and any attachments are intended only
for the addressee and may contain legally privileged, personal, sensitive or
confidential information. If you are not the intended addressee, and have
received this email, any transmission, distribution, downloading, printing or
photocopying of the contents of this message or attachments is strictly
prohibited. Any legal privilege or confidentiality attached to this message and
attachments is not waived, lost or destroyed by reason of delivery to any
person other than intended addressee. If you have received this message and
are not the intended addressee you should notify the sender by return email and
destroy all copies of the message and any attachments.  Unless expressly
attributed, the views expressed in this email do not necessarily represent the
views of the company.
 
 
_______________________________________________________________________
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: