Re: [foxboro] Bad I/O vs. high/low alarming

Corey,
From my experience with alarm management, you are right on the money from an
operator interface stand point.
You may however want to generate the Bad alarms and direct them to a
different group with your historian but not containing your workstations.
This has the advantage of not overwhelming the operator with both process
and hardware related alarms that are essentially from the same root cause.
At the same time, you have a means of backtracking from a maintenance
standpoint to see exactly what happened.
Of course, if you have only intelligent transmitters, then your system
management messages will cover all transmitter losses. Also, don't forget to
set your BADOPT accordingly to determine if out of range signals will cause
a bad as well or if it is only a faulty channel.
My 2 cents,

Howard C. Cossitt
National Training Coordinator, Lifetime Learning Center
Invensys Systems Canada
Phone: +1-514-421-8095
Fax: +1-514-421-8059
Email:  howard.cossitt@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Corey R Clingo
Sent: Monday, June 12, 2006 10:17 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Bad I/O vs. high/low alarming

Hi list,

We are undertaking an "alarm management" (well, at this stage, alarm 
elimination) project in one of my plants.  The question of why we need bad 
I/O (BAO) alarming when we have high and low alarms on an AIN block was 
raised.  Most of our bad I/O alarms are due to sensor/transmitter 
failures, which typically either open the loop or drive the signal high, 
so it is a valid question.


So I was trying to think of a situation where one might get a bad I/O 
alarm but not a high or low when both high and low are enabled.  We set 
LASTGV = 0 as a rule (why it defaults to 1 is beyond me), and card 
failures would show up in system management.  Any other scenarios I might 
have overlooked?  What is the general feeling on this topic?


Thanks,

Corey Clingo
BASF Corporation

 
 
_______________________________________________________________________
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
 


 
 
_______________________________________________________________________
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: