[foxboro] Named application packages
- From: "Johnson, Alex P" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Mon, 27 Jun 2005 20:01:57 -0400
The topic has come up a lot lately so I thought I might enumerate the
"named" application packages available from Invensys IPS. This list contains
information about all of the application packages that have received enough
reuse to earn a name.
This is not every low volume package available, but it is an interesting
list.
NA Operations
Power Group - Jim Canty
* Ethernet Integration Package - Superseded by INI51/70
* Post-trip Review - Gathers process data and generates a before and
after report of the data triggered by a process event. V8 has a new standard
package.
* SOE - Collects SOE messages and reports on them. AIM*Historian is
generally preferred now, but some plants don't have it. V8 has a new
standard package as well.
* Tag Out - Allows the user to mark devices as out of service
* Time Synchronization - Superseded by Foxboro Canada offering and
V8 offering
* WASP - "PanAlarm"-style display for I/A Series Alarm messages
I know this list is incomplete. Typically, these packages are re-worked on
each order to update them; they are not updated automatically. I do not have
sales literature. These are not listed in www.buyautomation.com
Foxboro Canada - Sylvain Nadeau
* AIM* Archive Server
* AIM*Redundancy (Main/Backup remote collectors) - Allows
off-platform AIM* to support redundant data collectors
* Alarm Extractor - Exraction of Alarm and Operator Action messages
into Excel
* Block Processor (BPROC) and derivatives (AGA Flow Metering) -
Allows one to build and maintain block-like algorithms on an AW.
* EDDC (Event Driven Data Collection)
* Gensym G2 Bridge - links I/A Series systems to Gensym's G2
* PLC Alarm FIFO
* TCP Timesynch - Keeps V6/7 synchronized with outside time sources
* WISE - Web Server for I/A Series graphics and other information
I've attached the sales literature. These are not official PSSs and the
products are not in www.buyautomation.com.
Houston Applications Group - Dave Gaertner
* AGA3/AGA8 calculations - CP based implementation
* FoxMPC - Simple, multiple-in/single-out, CP based multivariable
controller
These tend to be less "packaged" and more "applied". The products are not in
www.buyautomation.com.
Advanced Development Group - Alex Johnson
* Application Object Services for Solaris - Allows the creation of
block-like OM data structures in the AW and allows for their alarming.
* Application Object Services for Windows - Allows the creation of
block-like OM data structures in the AW and allows for their alarming.
* DMCplus Bridge for Solaris - Integrates Aspen's controller with
the I/A Series
* DMCplus Bridge for Windows - Integrates Aspen's controller with
the I/A Series
* Event Driven Scripts for Solaris - Like FoxPage w/o the paging
software - can run any command line utility and pass it arguments based on
fields from alarm or event message
* Event Driven Scripts for Windows - Like FoxPage w/o the paging
software - can run any command line utility and pass it arguments based on
fields from alarm or event message
* FoxCTS for Hybrid Systems - Change Tracking Software for I/A
Series
* FoxCTS for Solaris - Change Tracking Software for I/A Series
* FoxCTS for Windows - Change Tracking Software for I/A Series
* FoxPage for Solaris - Alarm and Event driven Paging software
(numeric, alphanumeric, e-mail, SMS, etc.)
* FoxPage for Windows - Alarm and Event driven Paging software
(numeric, alphanumeric, e-mail, SMS, etc.)
* FoxRemote - Remote dial-up access to Solaris based systems
* Information Network Interface (INI51) for Solaris - Links separate
I/A Series Systems over a Customer Supplied Network
* Information Network Interface (INI70) for Windows - Links separate
I/A Series Systems over a Customer Supplied Network
All of the above have PSS and B0 documents and can be found
www.buyautomation.com. So, I have a little problem calling them "project
specials". They don't go through the normal I/A Series development group,
but they are well documented, tested, and updated for each I/A Series
release.
There is also a group of utilities known as I/A Series Tools for Solaris
that is in www.buyautomation.com, but lack PSS and final B0 documentation.
These include: cpShell, Baseline, FBMTrack, and a few others. Work continues
to finish their documentation as time allows.
Foxboro Germany - Gerrit Gurk
Alarms Online - PC/Software replacement for an I/A Series alarm printer
using MySQL DBMS. (see attached Application Data Sheet)
Display Distribution Tool - Supports file copy/move operations (Displays,
Display Element Files, etc.) in any I/A Series System network. It supports
both 51 -and 70 Series platforms.
FoxLogin - Software that provides access to I/A Series via chip card reader.
(see attached Application Data Sheet)
IA-Connect - OPC DA server that provides very fast read and write access to
the I/A Series System including support for Supervisory Setpoint Control.
(see attached description)
IACS (Server & Client) - OEM Product from company Leikon/University of
Aachen. Client/Server application that provides real time access and
browsing for I/A Series Tags/Values. (see attached Application Data Sheets
for Client & Server)
IACS-Hist - OEM Product from company Leikon/University of Aachen. Client
application that provides accesst to I/A Series historical data. (see
attached Application Data Sheet)
LogicView - Displays graphically the operation of a single CALC, CALCA,
Logic block
OFHA II - Online File Hierachical Archive is an application that enables you
to mirror files and file systems in an I/A network to provide the basics for
a "two step roll back " backup strategy. In addition it can provide an
archive of up to 7 revisions of plant critical configuration or operation
data. (see attached user manual).
TrendView - Enhanced trending application
Foxboro Netherlands - Cor Swart
*** Strictly speaking this are not reusable application engineering.
Their home is within the SimSci/Esscor on-line applications group
along with ROMeo (optimizer) and Connoisseur (MVC).
BOSS - Blending
IRIS - Reporting package that works well with sequence blocks.
ODIS - Component that allowed operator interaction with sequence block
message facility. Enhanced OMI - a standard package that has been dropped.
OMIS (Oil Movement and Information System) - Oil Movements
OMM (Order Movement Manager) - Supports product delivery and receipt
monitoring tracking and archiving.
PERC - Calculation Package
RBATCH - Recipe batch product. Generally superseded with problematic
on-going support at this time.
TIS - Tank Information System
All info on the packages available on the website: www.off-sites.com. These
are not listed in www.buyautomation.com. However, they are considered
standard products by the Solutions group.
Regards,
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Jim Kahlden
Sent: Monday, June 27, 2005 3:17 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Alarm horn/lights, Alarm Manager Application, Alarm
Panel and Table Configuration, Ala
Tom,
The Foxboro WASP package is actually an application package supported by
the Power Utility Group in Foxboro, Mass and has been around for a while.
It is used by many power sites to emulate the old window annunciator alarms
on the old panel boards.
Jim Kahlden
jim.kahlden@xxxxxxxx
Lower Colorado River Authority
Fayette Power Project
6549 Power Plant Road
La Grange, TX 78945
(979) 249-8514 (Ph)
(979) 249-8390 (Fax)
>>> tom.vandewater@xxxxxxxxxxxxxx 6/27/2005 2:04:20 PM >>>
Alan and Patrick,
Sorry for the delay in responding. I was very interested in
what both of you had to say but haven't had a chance to reply until
today.
Patrick, you said:
"We use the Foxboro WASP package to drive these icons and if I read your
posting correctly this might be the product enhancement you were looking
for!?"
Yes, this sounds almost exactly like what I am looking for. I
tried searching the Foxboro CSC website for more information about
"WASP", (Window Alarm Scanner Package), and found a CAR reference to an
overview of the WASP package, and a User's Guide but was unable to
actually find either document. Can anyone from Foxboro help me locate
this information? Dick Staun, this is a sales opportunity! =20
I suspect that this is one of those, never fully commercialized
applications that seem to be developed and readily available in the
Netherlands or Germany but not so easy to get in the USA. It sounds
like what I want. I am interested in running an instance of WASP on
each of several WP51D's to split the load and segregate process alarm
functions rather than having all my alarm "eggs in one basket". This
global alarm object functionality, in my humble opinion, should be the
direction that Foxboro moves, replacing the Annunciator and FoxPanels
that tie everything to a user interface specific location.
Patrick, the hierarchy you have created with your process
overview graphics populated with "icons" is a great structure. It
enables the operator to recognize the "Current" alarm status for all
processes and equipment and make an informed decision about what process
or piece of equipment is the highest priority. With a single click of
the mouse, (on an icon), the tech can be at the process detail graphic
where corrective action can be initiated.
Patrick said:
"The top 2 screen graphics are fixed (not operator changeable) and
display a sort of annunciator keyboard but in a much more graphical way.
With one blink of the eye, the operator has a complete overview of which
section has current alarms."
As I said before, your graphical process and alarm overview is a
more complete and elegant replacement for the Alarm Manager tabular
listing that was disjointed when used in conjunction with the FV/DM
interface. You have managed to combine the FV/DM/AM functionality on
one "piece of glass" in a display format that can be accessed from
anywhere in your system.=20
Alan Armour said:
"Currently we have a density of over 8000 installed alarms/operator at
best case (all operators in the control room) and over 25000 installed
alarms per operator at worst case (only one operator in the control
room)and still comply with The EEMUA guideline for alarm traffic per
operator. These densities can only be achieved by using advanced alarm
masking techniques, and changing alarm destination for different
situations is one of those techniques to reduce alarm floods."
Alan, it has been my contention with our management that we have
to go through an alarm evaluation for each process in order to determine
which alarms, (of the thousands that exist), give "unique" and helpful
information to the operators so they can begin the troubleshooting the
process. "Unique" is the key word here. The reason "Alarm
Avalanche/Flooding" occurs, is because there are many alarms that are
very closely related to the same condition. When that condition occurs
you will get ALL of those alarms. It helped me to boil this all down by
asking myself the question:
"What is the primary purpose of the control system?
And myself said:
"Controlling the Process!"
The answer, although blatantly obvious, most often gets lost in
the shuffle. We keep adding alarms, never asking ourselves whether or
not this condition already has an alarm that tells us the process is
unable to control. For me, it makes sense to start with the controllers
used to control each process. If I can set all of the set points, and
the controllers always maintain those set points, then we are making
good product. Only when the controllers begin to deviate from set
point, do I need an alarm.
At that point, I need the operator to find out why the
controller can't maintain set point. One deviation alarm should be
enough to get the troubleshooting process started, and additional alarms
related to the same condition will only distract/hamper the operators
from their jobs. I go so far as saying that there is no need to alarm a
pump failure if the pump flow is also controlled by a flow controller,
because the flow controller will have a deviation alarm and when the
operator looks at the graphic, the failed pump will be obvious. If the
flow controller doesn't deviate from set point when the pump fails then
I don't need the pump anyway.
Evaluating your alarms in this way will insure that you minimize
the number of alarms needed. Each alarm added needs to be justified and
a corrective action defined for each condition. We were able to
achieve, both a 70% reduction in configured alarms as well as a 70%
reduction in actuated alarms when we applied this evaluation technique,
and I don't think we cut enough alarms yet. =20
My goal is to:
1. Eliminate all unnecessary or redundant alarms using a structured
evaluation process.
2. Manage the remaining alarms using advanced masking techniques as you
described above.
3. Establish a graphical interface that makes it as easy as possible for
the operators to find, evaluate, and correct operational problems.
Thanks again to Patrick and Alan for their helpful and detailed
response!
Tom VandeWater
Control System Developer/Analyst
Dow Corning Corporation
Carrollton, KY USA
_______________________________________________________________________
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
_______________________________________________________________________
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:
- » [foxboro] Named application packages