Re: [foxboro] Recommended practices for assigning Alarm Priorities
- From: "tjvandew@xxxxxxxxx" <tjvandew@xxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 15 Mar 2006 21:41:10 -0500
We have begun to apply a similar strategy to the one Brad mentions,
which uses a matrix of risk vs. urgency. Alarms that announce a
situation of high risk and immediate urgency are considered to be SIS or
safety related items and we assign those to Priority 1. We design a
control action, or strategy to address the situation automatically
because these situations are too urgent and too important to count on
the correct human response to be taken in the timeframe required. So
our prioritization scheme looks like this:
Priority Criticality Urgency Timing
1. Extremely Critical Extremeley Urgent Immediate
2. Critical Urgent <10 minutes
3. Critical Moderate >10 but <20
4. Critical Slow > 20 minutes
5. Informational - Aids Operator Awareness of developing issues.
We are also striving to use analog controller deviation alarms instead
of absolute alarms. The PIDA controllers provide all of the functions
we feel we need. We use setpoint clamping to define our operational
boundaries and then Deviation Alarm limits to define maximum allowable
setpoint deviations. We often establish a .DEVTIM limit, (MAX time in
seconds to allow deviation excursion before Deviation alarm is sounded
to avoid nuisance alarm bounces).
Our assumption is that if all of our analog controllers are able to
maintain acceptable control of Measurement to Setpoint, then the process
is running in a parametric release state that insures good product is
being made. When the measurement strays from setpoint a meaningful
alarm will be issued that tells the operating technicians it is time for
them to begin problem solving. Is it a sticky valve, cavitating pump,
poor tuning, etc. that is causing the deviation.
Employing this strategy can greatly reduce the number of alarms that
need to be issued and focuses the operators on troubleshooting the root
cause with out flooding them with the cascading effect of alarm
avalanche. We have achieved > 70% reduction in both configured alarms,
and alarm activation in the processes that we have employed this
strategy, but it is a time consuming process to make the initial
evaluation, eliminate old alarms, and set the new ones. An added side
benefit is a significant reduction in operator actions needed to
acknoledge and or silence the excess alarms that used to be generated.
Cheers,
Tom VandeWater
brad.s.wilson@xxxxxxxxxxxxxx wrote:
> We have 3 levels of alarms - 1, 2, 3
> We have 3 levels of consequence of inaction - high, medium, and low
> We have 3 levels of operator response to prevent the consequence - fast (<
> 15 mins), medium (15-45 mins), slow (> 45 mins)
>
> A table balances consequence of inaction against urgency of operator
> response to assign alarm levels.
> For example,
> a low consequence that requires a fast response is level 2
> a medium consequence that requires a fast response is level 1
> a medium consequence that requires a medium or slow response is level 2
> a high consequence that requires a medium response is level 1
> a high consequence that requires a slow response is level 2
>
> The holes in this table are:
> high consequence that requires a fast response - this should be handled by
> a dedicated emergency shutdown system
> low consequence that requires a medium or slow response should not be
> categorized as alarms, but rather as alerts
>
> How alerts are handled has been discussed on this list previously.
> How to determine what high, medium and low consequence means is up to each
> plant.
>
> Foxboro I/A provides for 5 priorities, so there's enough flexibility to
> expand this table, or handle alerts as PRI 5 "alarms".
>
> Brad Wilson
> Process Control Engineer
> ExxonMobil Chemical Co
> Edison Synthetics Plant
> 732-321-6115
> 732-321-6177 fax
> Brad.S.Wilson@xxxxxxxxxxxxxx
>
>
>
> _______________________________________________________________________
> 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
>
>
_______________________________________________________________________
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
Other related posts:
