Re: [foxboro] Alarms one line
- From: <tom.vandewater@xxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 25 Oct 2005 13:32:36 -0400
Excellent feedback, Sean. When talking about your alarm
management project I know you are "right on" in saying that:
"This task would have seemed impossible had it not been for reports
generated by the alarm database."
I talked with Ted Jirik in the past and I was impressed with the
RTS solution which isn't a proprietary application but a more open "Real
Time" solution that gives users a way to view/manage data generated by
Fox IA using a Browser based HMI. Yes it is built on a MS backbone:(,
but it provides what I want to see in a browsable/queriable environment.
I want it to be known that I haven't purchased or used any RTS solutions
myself and have no personal or business ties to them. I just like their
concepts and implementation strategy. My #6 comments were directed to
Foxboro to say there is a market for a Control System that stores all of
it's information in relational databases instead of individual
proprietary ones for each unique Foxboro application. I personally
think that is the intent of Archestra, but who knows when it will be
available or what it will cost to implement?
We have to remember that those legacy Foxboro applications were
written/designed in mid-late 1980's and the designers were limited by
disk storage, processor speed, available memory, network bandwidth, and
relational DB's that were in their infancy. They did a great job given
those constraints but it is past time for those applications to be
replaced. Maintaining backward compatibility with the legacy apps is a
huge yoke for Foxboro to carry along. Maintaining the existing Object
Manager for data access consistency, while totally replacing the legacy
apps with state-of-the-art ones that are more flexible and capable
should be the goal. Talented and capable users and 3rd parties are
already devising home cooked applications that give them a lot of what
they want, so Foxboro's new HMI and apps will have to be competitively
priced and feature rich in order to be accepted, (another tall order).
Cheers,
Tom VandeWater
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Meltvedt, Sean
Sent: Tuesday, October 25, 2005 11:33 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Alarms one line
Tom, We do use Realtime Solutions Inc software. The latest stuff does
perform item number 6, although it uses a web browser instead of Wonder
Ware/Archestra to query alarms and operator actions. These items are
interleaved in the same report. It the greatest tool for incident
investigations, as it shows the process alarms and associated operator
actions in sequential time order. And as an aside, it also has the
control configuration database that will pickup C:B.P calls from within
Sequence code, and display connections as well as block connections.
We also are in the middle of an alarm management project. This task
would have seemed impossible had it not been for reports generated by
the alarm database. =3D20
Just my two cents.
Sean Meltvedt
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of
tom.vandewater@xxxxxxxxxxxxxx
Sent: Tuesday, October 25, 2005 7:05 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Alarms one line
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.
=3D3D20
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. =3D3D20
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. =3D
=3D3D20
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
=3D20
=3D20
_______________________________________________________________________
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
=3D20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe: =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=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: //www.freelists.org/list/foxboro
to subscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=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
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:
