Re: [foxboro] Alarm Management

From: Alan J Schaff <schaffa@xxxxxxxxxxxxx>
To: foxboro@xxxxxxxxxxxxx
Date: Tue, 9 Apr 2002 11:13:14 -0400

We use the INHIB parameter to disable alarms based on process conditions.
The only problem we have with using the INHIB parameter is there is a
message sent to the Alarm Manager when you disable and enable the block.
In our case we disable 10 blocks at a time causing 10 messages to be sent
to the Alarm Display. Does anyone know of a way to disable this function?
At one time we asked Foxboro but the response was it couldn't be turned
off. I was curious if this is still the case.

Alan Schaff
BASF Corp.

>-------------------------------------------------------------------------------------------------------------------------------|
|
|
|
|
|o
|
| To: foxboro
|
|
|
|
|
|
|
| cc:
|
| Subject: Re: [foxboro] Alarm
Management |

>-------------------------------------------------------------------------------------------------------------------------------|

Simon,

Following are methods and notes on alarm management that I've implemented,
mostly at the plant I worked with before I came to Foxboro.

Startup/shutdown - as a plant area starts up or shuts down, large numbers
of process alarms may occur. It is important that critical alarms don't
get lost in a sea of "normal" alarms. Two convenient ways of dealing with
this include:
1) Disable downstream alarms when key piece of equipment is stopped.
Enable those alarms when key equipment starts plus appropriate delay.
Alarms can be enabled in stages to allow for processes that take longer to
stabilize.
2) Startup/shutdown sequence logic can help reduce alarm frequency.
Detailed alarm inhibiting and enabling can be implemented in sequence
logic. Also, the uniformity achieved with startup/shutdown scripts reduce
the incidence of valid alarm events during startup/shutdown, especially for
plants or plant areas where shutdowns are infrequent.

Equipment problems -
1) Group alarm inhibits works well for key equipment failure, as do group
inhibit keys.
2) Consider identifying common offenders (at my last plant the major one
was seal water flow switches) and build a simple graphic for inhibiting
these problem alarms.
3) Bad i/o, out of range, and hi/low alarms can occur as a result of
equipment failure. Some of these can re-alarm continuously until the
problem is corrected. Letting operator/supervisor/technician inhibit these
alarms until repairs can be completed will reduce the frequency of this
type of alarm. Ensuring a system is in place to re-enable the alarm when
repairs are complete is the challenge. I have had good success with a
shift report showing inhibited alarms, filtered to eliminate those alarms
that were inhibited by design. Group alarm inhibits based on key equipment
failure works well too.

Process disturbance alarms - If a given process disturbance typically
generates a wave of predictable alarms, feed forward control may be
appropriate for managing the process, thus reducing alarms.

Re-alarming problems - use appropriate deadbands, delays and re-alarm
setpoints to manage alarms that occur repeatedly as the result of a single
event.

Maintenance issues with alarm management:
1) Plant standards for alarm management can raise awareness that there will
commonly be connections to the INHIB and/or INHALM parameter of block with
alarms configured.
2) If plant practices allow for operator/supervisor/technician alarm
inhibiting, make sure your alarm management standards allow a practical
method for manual alarm inhibit of a given alarm.

Some things to consider:
1) Take advantage of the ability to selectively inhibit alarms in a given
block via the INHALM parameter, ie. disable the hi, low and low low, but
leave the high high enabled.
2) Take advantage of the ability to inhibit alarming at the compound level
if appropriate.
3) Consider using the ability to disable alarming below a given priority
under some conditions.
4) Alarm priorities are connectable and settable, so you can dynamically
modify these, ie. to cause an alarm to sound horns under some plant
conditions but not others. Also useful if 3) above is implemented.
5) Take advantage of the advanced alarm features of the control blocks
(REALM, PID family, etc) to generate the most appropriate alarms.

Regards,

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand
------------------------------------
Tel: +64 (9) 573 7690
Fax: +64 (9) 573 7691

swardvc3@xxxxxxxxx
om To: Foxboro@xxxxxxxxxxxxx
Sent by: cc:
foxboro-bounce@fre Subject: [foxboro] Alarm
Management
elists.org

08/04/2002 10:33
PM
Please respond to
foxboro

Hi Everyone,

We are currently trying to reduce the numbers of process alarms on our
system,
especially when a unit shutdown occurs. We realise that there are a number
of
ways of doing this and know how most of them work, the question is which is
the
best? We have already gone through every alarm and reviewed its necessity
then
set its priority.
Our next phase is to start disabling alarms when they are not required.
Mode
driving is one of the options we are considering, i.e. disabling of an
alarm if
it comes as a consequence of something else happening that also produces an
alarm.
I am very interested to hear from anyone who has tackled the problems of
excessive numbers of alarms successfully, what methods have you used and is
maintenance on the system more of a problem than it was previously.

Thanks in advance,

Simon

Simon Ward
VC3 Computer Engineer
VC3 Plant
Castner Kellner Works
Runcorn
Cheshire
WA7 4JE

_______________________________________________________________________
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: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Re: [foxboro] Alarm Management

Other related posts: