Re: [foxboro] Reports

Kevin,
        I am particularly interested in what mechanisms you use for
number 1) in both your daily and weekly list.

Daily
1) Query system monitors and report on stations which are failed to
single, off line, failed, have failed devices or have alarms inhibited.

Weekly
1) Task telnets in to each AW and rlogin to each WP and generates a
systems admin report based on response to a series of commands.  Also
summarizes info in a table.

I didn't mention our mechanisms for capturing and serving System and
process alarms as well as Operator Actions, (I'm a bit embarrassed), but
we still direct them to dedicated printer ports on Comm processors and
then connect the ports to terminal servers that stream to formatted
ASCII text files.  The files are actively served from a webhost to our
desktop browsers.  The actively updating daily text file for each
category is closed at midnight and then displayed as a daily log file
for that category from then on.
        Although it is better than nothing its lack of relation to the
other categories make it very clumsy when trying to do event
re-construction that requires operator actions, process alarms, and
System Alarm information for a specific process during a given time
frame.  If all of these things were in a relational SQL Server database
it would be possible to provide a browser based query that used a
process identifier, start, and stop time as inputs to return just the
records needed for an effective event reconstruction.
        I'm sure Ted Jirik is out there saying, "They haven't done that
yet?  He talked to me about doing that 2 years ago."  It boils down to
time, money, and business drivers to do it.  Maybe IEE will do it for
us.  How about it Alex?
        Again, I think the reason the IEE reporting thread has gained so
much attention is because so many customers are spending a significant
amount of time manipulating the data they input into a proprietary
database and then have to use disjointed tools to get it back out.  In
addition, the data coming out of the system after processing, (Alarms,
Actions, Control Information), is not easily organized for use in a
relational way.  We are so used to spending time data mining in this
fashion that we lose site of how much resource we devote to it.  This is
currently the nature of the beast on many systems so it's not specific
to Foxboro/Invensys and since we already have some mechanisms, most
aren't willing to spend a lot more money to have Foxboro provide it.
Still, it was a very interesting topic and I learned a lot because of
it.

Tom VandeWater

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Kevin_Fitzgerrell@xxxxxxx
Sent: Tuesday, March 27, 2007 11:30 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Reports

Regarding reporting, I do the following:

Daily
1) Query system monitors and report on stations which are failed to
single, off line, failed, have failed devices or have alarms inhibited.
2) Query system monitor messages and report all messages for prior and
current day, filtering out checkpoint and icc access messages.
3) Generate iccprt listings, historian tag lists, foxapi tag lists,
system monitor station information, d_edit report of points used in
graphics, sequence and PLB code listings.  Using these, generate static
HTML pages with full cross indexing of all tags, control database
configuration, block connection diagrams, hyperlinks for all tags, I/O
reports, listings of tags used in each graphic, historian, FoxAPI, list
of bad blocks, and line drawings of system, each node, and I/O cabinet
layouts.  These web pages are located on a server and are available
across our intranet.

Weekly
1) Task telnets in to each AW and rlogin to each WP and generates a
systems admin report based on response to a series of commands.  Also
summarizes info in a table.
2) Generate a snapshot of control database (iccprt, sequence, plb) each
week and provide reporting of changes (block additions, block deletions,
parameter changes).=3D20

I'd be keen to know what reporting others are doing.  Most of the above
is done in Perl by processing ascii files generated by various Foxboro
tools.  If anyone wants more detail of what reporting I'm doing or how,
just ask.

Regards,

Kevin FitzGerrell

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Johnson, Alex P (IPS)
Sent: Wednesday, March 28, 2007 11:33 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] client server

<snip>

Re: Reports
I appreciate your thoughtful explanation of the types of queries you do.
A discussion of the reports that people use is a good topic as well.


Regards,
 =3D3D

Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx


=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:             http://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:             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: