Re: [foxboro] Alarms one line
- From: <tom.vandewater@xxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 25 Oct 2005 11:04:36 -0400
Terry Doucet brings up a good point about alarm management that
ties into this thread about historizing and displaying alarms. In order
to know if you really have an alarm problem you need a way to
count/track/measure the alarms that each operator is dealing with on a
daily basis.
=20
1. The old COMM Processor connected to an alarm printer did historize
the alarms but it really wasn't designed for alarm analysis unless you
like digging through reams of paper. =20
2. Porting the printed ASCII text into electronic text files that could
be electronically searched was the next step, and although much better,
left a lot to be desired in terms of compiling and sorting the data. =20
3. Enter spreadsheets to parse the text based alarm strings into columns
and rows that could be sorted/manually analyzed.
4. Enter packages that periodically FTP the almhist file from AW's and
place it into proprietary databases that can count and analyze the
alarms, but only in the way the application supports. New queries or
features can only be implemented by the application provider.
5. Enter SQL databases that automatically collect alarms and operator
actions from AW spoolers, (eliminates COMM Processor interfaces), via
2nd Ethernet and place them into tables that can be queried via browser
based interfaces by anyone on your intranet. These tables can be
relational to other SQL databases and tables. This enables users access
to virtual real-time event analysis.
6. Enter a WonderWare/Archestra browser based HMI interface that allows
Process-Control/Alarms/Operator-Actions/Sequence-of-Events info to be
displayed and queried in a unified environment along with other
enterprise SQL databases.
Oops. I forgot. Number 6 is not yet available. 1-5 is already
being done and I like #5 the best at this time. We are doing #3 at this
time. My limited research led me to:
Ted Jirik, Real Time Solutions, Inc. Ted.Jirik@xxxxxxxxxxxxxxx
He can help users get to #5. I know we don't encourage vendors to pump
their products on this list but if there are users that have experience
with specific vendor products, please speak up for the benefit of the
rest of us.
Cheers,
Tom VandeWater
P.S. More on alarm analysis/strategies in a later note
_______________________________________________________________________
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
- Follow-Ups:
- Re: [foxboro] Alarms one line
- From: Bakke, Richard A
Other related posts:
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- » Re: [foxboro] Alarms one line
- Re: [foxboro] Alarms one line
- From: Bakke, Richard A