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