Re: [foxboro] AP and AW roles - historical and current
- From: <Jack.Easley@xxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 11 Feb 2009 15:42:15 -0600
A little further clarification:
P92 - XP can do it all, except Remote Display Managers. Many people use
them as AWs instead of P91s. The only reason I know of to buy a P91 (Win
2003 Server) is to provide Remote Displays to PCs.
You are right in that the CPs do not need the AWs during normal
operations.
As long as the CPs do not reboot, they don't care. Downtime of several
hours on Unix Box AWs was common for tape backups. I guess one
additional reason to use P91s instead of P92s could be that only P91s
have redundant power sources which can be supplied from 2 different AC
sources, if you're into blue-moon redundancy.
You are correct in that APs are no longer offered.
Currently Foxboro appears to be migrating from P91s (Desktop Server) to
P90s (Rack Mount Server). Same animal, but newer and faster.
Jack Easley
Sr. I&C Technician
Luminant Power, Martin Lake Plant
Phone 903.836.6241
jack.easley@xxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of McLaughlin, Sean
Sent: Wednesday, February 11, 2009 2:02 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] AP and AW roles - historical and current
Jack,
Thanks for the answers below. To check that I understand correctly, this
is my interpretation of the current P91/P92 offerings that you
mentioned:
P91 - Server 2003:
Comes with AW (= AP + WP) software capabilities, can host CP's and
provide HMI's.
P92 - XP:
Comes with WP software capabilities, can provide HMI's etc. Lately comes
with full AW capabilities.
I am assuming that a pure "AP only" product (no ability to provide
HMI's) is not currently offered in the latest Windows products -- but
the current WP's have both an AP and an AW letterbug.
As far as the role of AW's go during CP bootup, the #1 point that I am
taking away is from the viewpoint of single failures or common-mode
failures. Even with only one ("non-redundant") AW, I don't see reason to
postulate that a failure of this AW would cause a loss of control
capabilities in any likely event, so long as the CP's themselves are
powered from redundant power (and therefore aren't likely to reboot
unless done by intention). Is there any need for periodic communication
between a CP and AW (or some other caveat) which could cause problems in
a CP if an AW went down? We generally recommend the most conservative
approach with redundancy wherever it is available, so any suggestions
are welcome.
Thanks again, and also to Tim Lowell for your private response.
Regards,
Sean McLaughlin
Controls Engineer I
Zachry Nuclear Engineering
(Formerly Proto-Power Corporation)
860-405-3076
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Jack.Easley@xxxxxxxxxxxx
Sent: Wednesday, February 11, 2009 1:09 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] AP and AW roles - historical and current
Here's a quick answer to most of your questions.
AP (old) Applications Processor Foxboro's Server, no HMI (Wyse
Term.)
WP Workstation Processor HMI for displays, alarms, some
configs.
AW (new) Application Workstation Combination of both above
WP Name of AW mainly used as alarm destination, probably
more.
Foxboro has been installing all Windows WPs as AWs for the last few
versions (no extra charge), even if no historians or other server
functions run on it. Works for me as it simplifies the install process,
even though we still call them WPs because they are just used as HMIs.
The AP/AW/WP nomenclature is still valid, although on Windows MESH you
hear P91 used for AW and P92 used for WP. P91/P92 is really just
hardware/OS description. P92s (XP) can be and are often used for either
WP or AW.
CPs must communicate with the AP/AW when they reboot, with exception of
self-hosting CPs at latest version 8.4.2. I have heard CP self-hosting
at this version still has problems and am not implementing it (although
I had planned to) as it is something we have been looking for a long
time.
I'm sure others can elaborate on your questions further...
Jack Easley
Sr. I&C Technician
Luminant Power, Martin Lake Plant
Phone 903.836.6241
jack.easley@xxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of McLaughlin, Sean
Sent: Wednesday, February 11, 2009 10:42 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] AP and AW roles - historical and current
Hi.
This is my first post here. I'll probably be making a few more in the
next couple weeks, as I'm developing some internal training materials on
Foxboro equipment for our I&C Engineers. Our company does AE work /
consulting for modifications / Spec writing for various nuke plants, who
have various vintages of existing DCS equipment (usually Foxboro). We
often see 51 series, Solaris workstations, etc. Sometimes we'll elect to
go forward with small expansions on this legacy of equipment; other
times we'll upgrade to the latest MESH hardware / software.
I came across the below post (notably older - 2002) from this group,
while trying to research the roles of AW's / AP's / WP's / etc. in the
overall architecture. I realized that I don't have a complete grasp of
the different terminology between AW/AP/WP -- especially the part about
"the AW's WP name". Is this purely an artifact of the Sun Solaris, with
one box hosting the applications, and another connected to it to provide
display / HMI through the X Windowing system? Also: are these terms
still used in the same meaning on today's latest equipment?
Secondly: Can anyone provide a summary of what network processes take
place when "hosting" a CP or FBM? If a power interruption occurs and a
CP / FBM needs to reboot, will it have the config files that it needs in
non-volatile memory, or is it absolutely essential that the AP/WP be
online and available in order to reboot? (i.e. Windows can't have
crashed, etc.)
I haven't been able to find these types of answers in publicly-available
Invensys documents; I'm in the process of signing up for IPS access. Any
pointers to literature would be great. Thanks in advance!
Regards,
Sean McLaughlin
Controls Engineer I
Zachry Nuclear Engineering
(Formerly Proto-Power Corporation)
860-405-3076
Re: [foxboro] AW70 to WP70 via Ethernet
From: Chris Browder <chris_browder@xxxxxxxxx
<mailto:chris_browder@xxxxxxxxx> >
To: foxboro@xxxxxxxxxxxxx <mailto:foxboro@xxxxxxxxxxxxx>
Date: Wed, 23 Jan 2002 08:38:17 -0800 (PST) I think his problem is more
fundamental.
First, how did you install WP and AW? What is the AW's logical name
(letterbug). AW7001? and what is the _AW_'s wp name. AWWP01? (nice to
put AW in there so you don't get confused)
The AW basically has two components a host (or application processor)
and a workstation (or workstation processor). The host (AP part) is the
AW's letterbug. The worstation (WP part) is the AW's secondary
letterbug.
Then you have a second machine with just the WP part (call the WP).
It'll have it's own _separate_ letterbug. WP7001?
Then you'll have node on which they are connected. Make sure this is an
ethernet node (if that's appropriate for you: no dnbi/dnbt's).
What are your AW's letterbugs? What is your WP's letterbug? What is the
node type?
It's been a year since I've done this so forgive me if some of my
terminology is off. Feel free to correct me someone.
chris.
_______________________________________________________________________
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
Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be
advised that any reading, dissemination, forwarding, printing, copying
or other use of this message or its attachments is strictly prohibited.
If you have received this message in error, please notify the sender
immediately by reply message and delete this email message and any
attachments from your system.
_______________________________________________________________________
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
_______________________________________________________________________
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
Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be
advised that any reading, dissemination, forwarding, printing, copying
or other use of this message or its attachments is strictly prohibited. If
you have received this message in error, please notify the sender
immediately by reply message and delete this email message and any
attachments from your system.
_______________________________________________________________________
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:
