Re: [foxboro] FW: Anybody Using IACC??
- From: Stan Ruth <Stan_Ruth@xxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 25 Aug 2004 09:58:16 -0500
One of the concerns we have on our system in using IACC is the
incompatibility with ICC. If you are writing a new configuration program
(IACC) to replace a legacy configuration program (ICC), you would think
that there would be a plan to accommodate both on larger systems that
could conceivably have newer nodes and older nodes mixed together. The
direction of IACC seems to be oriented towards new installations, or at
least ones that are segregated from other older nodes still using ICC.
Regarding Windows Desktop sharing -
I know this can be done if you use something like Windows Server 2003 (we
are doing this with Vendor V's DCS system), but I have yet to see Windows
server mentioned as being used in the I/A product.
Stan Ruth
Process Control Engineer
Huntsman Performance Products
tom.vandewater@xxxxxxxxxxxxxx
Sent by: foxboro-bounce@xxxxxxxxxxxxx
08/24/2004 03:36 PM
Please respond to foxboro
To: foxboro@xxxxxxxxxxxxx
cc:
Subject: Re: [foxboro] FW: Anybody Using IACC??
List,
This has been a very interesting survey. Not a single
list user
responded yes to the question: "Anybody Using IACC?" It appears that
everyone is waiting for Foxboro to introduce some Windows based products
and
applications that are "too good" to pass up. They may not be there with
the
"Windows Based" stuff yet, but if there are satisfied Windows users out
there it's not too late to speak up. If you send comments directly to me
I
will be gald to post them anonymously to the list
This thread also begs the question: Are Foxboro
application group
programmers, (COG, Pulp and Paper, Power, etc..), still using ICC or
FOXCAE
to accomplish their control confuguration tasks? If the answer is "YES"
then Foxboro may want to ask why "they" have choosen not to use IACC.
I am not personally opposed to Windows based applications
because I
use them everyday. However, I am opposed to paying additional money for
new
applications that are less functional, stable, and secure than the ones I
am
using today. Included in the text below are all of our issues concerning
use of MS-XP AW's in our plant. Immediately following our comments I have
anonymously compiled what other users have sent to me directly instead of
sending to the list. Thanks to everyone who participated!
Tom VandeWater
1. XP workstations don't offer as much functionality as the
Unix
workstations
a: The XP workstation cannot serve Display Manager/FoxView
screen to
remote PCs or X-terminals like the Unix workstations using X protocols.
b: Windows "Remote Desktop Sharing" is a weak substitution
for the X
protocols: only one user (remote or local) has control of the desktop at
any
time - in other words, the remote location steals the desktop from the
local
user and the local user steals it back. (While the XP AW is limited to a
single user interface, the Unix AW provides as many remote user interfaces
as memory and bandwidth allow. That capability has saved us over $240,000
in
HMI costs in our Central Control Room!)
c: Can only configure CPs hosted by the XP AW host while
working on the
host itself. The Unix-hosted CPs can establish ICC session without the
user
needing to know which Unix AW is the host. This also allows users to
connect
to multiple CPs hosted from the same Unix AW host simultaneously. This is
not possible with an XP AW using the ICC but we use that functionality
every
day at DC CTON on our Unix AWs.
d: Can't copy a block or compound from one XP AW host to
another via
the ICC, or from a Unix AW to an XP AW. We routinely copy blocks and
sometimes compounds across our I/A carrierband system. This allows all of
our DCS team members to share best-in-class configurations without having
to
manually re-enter them at a remote location.
e: The X applications written specifically to run in a Unix
environment
have been ported to run on the Windows platforms by running in a Unix
shell
(Nutcracker) on the XP/NT AWs. However, this shell doesn't have all of the
same functionalities that are built into Unix/Solaris on the Sun
workstations. As a result, most of the scripts that Solaris users have
developed to make life easier to live while using I/A won't function in
the
Unix shell on the Windows boxes.
2. Security - After treating security and access management
issues on
the Unix platform as an afterthought, Foxboro is doing the same thing (or
worse) on the Windows platform. The password for the default user (ia)
cannot be changed lest everything else breaks and stops working. How
utterly
insecure can you get?
3. Kludgy Interface - "Start | Shutdown" is a sure-fire way
to hang the
XP box, why can't Foxboro modify the registry to remove or disable that
pick? And speaking of shutdown, this is another reason why the Windows
boxes
are such poor substitute for the Sun workstation: every time some settings
have to be changed, it's another 4-5 minutes of waiting while the box
reboots. They all add up to a lot of frustration for the users. And for
what
improvement?
4. IO Gates functionality was not the same on the NT
platform as the XP
platform
a: After purchasing the OPC and Modbus TCP IO Gates we were
told that
only one IO Gate interface could run at a time on an XP AW but both could
run on an NT AW. We spent days trying to make it work by communicating
with
CSC before we were told about this problem, and then we had to write a CAR
explaining the problem to get it fixed.
5. Licensing for OPC and ModbusTCP IOGate applications
require manual
communication and registration with a single person at FoxMass and
restricts
the customer from moving the application to a different AW if needed
without
calling and getting a new license key issued. This is a non-value added
function (from the customer's point of view) and can cause unacceptable
delay if that key person is not available, therefore is an unacceptable
solution. Foxboro has the pieces in place to be able to do license
validation by comparing the user's System Definition to the P.O.'s that
Foxboro has shipped to that customer. That should indicate what hardware
and
software the customer is licensed to run.
6. System Security and the likelihood of virus infections or
network
attack of Microsoft products via the 2nd Ethernet will be ever present and
only increasing in likelihood.
a: Foxboro hypes the functionality of connecting to outside
networks
via the second Ethernet interface (in fact, OPC and Modbus TCP IOgates
require it). After connecting to the corporate LAN and almost immediately
being infected by a network virus, we contacted Foxboro to see how they
recommend protecting the XP box. We received a fix for viruses that were
already defined but there doesn't appear to be any plan for automatic
virus
definition updates that are a pre-requisite on almost any MS OS system
being
used in these days. This makes the Unix AWs, that also are connected via
2nd
Ethernet to the same network as our XP AWs, much more desirable as a DCS
solution, since they have never experienced a virus or security breach.
b: Service Pack and patch management is another area that
the users
have to rely on Foxboro to test and ascertain that service packs released
by
Microsoft will not unintentionally break some I/A applications. When the
service packs and/or patches are needed to patch security holes, time is
of
the essence and a few days' to a few weeks' wait for Foxboro to bless the
service packs/patches is totally unacceptable. A few examples follow:
1. "Wonderware recommends customers DO NOT install SP2 for Windows
XP
until SP2 is fully supported by Wonderware. Some Wonderware FactorySuite
applications may stop working if this XP service pack is installed." -
from
Wonderware web site
2. "We have determined that a loss of I/A Series functionality can
occur after loading and applying Windows XP Service Pack 2. Additionally,
I/A Series software will not load correctly on a machine that has Windows
XP
Service Pack 2 applied to the machine prior to the installation of I/A
Series software." - from Foxboro Customer Advisory 2004022ABI, August 13,
2004
We are forced to use the XP AWs only because we have to:
a. integrate OPC and Modbus data from external systems such
as
analyzer, electrical, and flame safety systems that are moving in that
direction into the DCS for information and control.
b. plan for future growth since Foxboro and Invensys have
indicated
that any future application development will be done in a MS environment.
It is likely that our OPC and Modbus needs will best be answered by new
IO/FBM solutions that will be hosted by redundant CPs or gateways. This
will
be much more reliable than a single Windows AW that is running a bunch of
other MS applications that can crash, taking our critical apps with it.
In conclusion, had we been able to realize even the same level of
security,
reliability, and application functionality from the new XP AWs compared to
the Solaris AWs, we would currently be trying to migrate our Unix AWs to
that platform. That, of course, hasn't been the case. Most of the
applications utilized on Windows-based Fox IA have been rather clumsily
ported to run in a Unix shell and, in the process, the user is penalized
with reduced functionality instead of reaping the benefits of
improvements.
Additional anonymous comments from other users follow:
"The only use of Microsoft OS based machines we have relative to Foxboro
is
that we have started using cheap PC's with Hummingbird attached to
additional
NIC's in the Sun Boxes to add more operator windows. I plan on replacing
these with diskless PC's based on the Linux Terminal Server Project soon."
"The ability to configure control logic from any station is a large
benefit
that we don't want to give up. Also, the ability to do remote display
managers using X is much superior to Windows terminal services."
"As the software releases move forward we are noticing more products which
are being developed for Windows only. Some of the new features are
compelling and are beginning to convince us we will have to move to
Windows
and deal with a mixed system in order to get some of the new features.
Nobody is pleased with this, everyone feels we are being forced to abandon
a
superior product in order to adopt a flawed system which will cause more
system down time."
"concerned about the deletion of system features (Informix) from the
Solaris
systems and the closed nature of the Windows systems. Foxboro does not
provide the header files needed to develop applications for their Windows
systems so customers will be dependent on Foxboro only solutions."
"The release of XP SP2 brings up another issue. Microsoft has made a major
change to the way DCOM and other network applications function with this
update. This could be a major whack to OPC and network applications.
Foxboro
and all the other Windows control vendors will need to make their control
applications comply requiring more testing and another round of bug
fixing.
This will result in more instability for awhile from all of the Windows
vendors."
"The ability to load other applications on an AW70 because it runs Windows
does not appear to be viable either because of the customized and closed
environment on the Foxboro platform. I see the same approach from ABB and
Honeywell too."
"I don't think the move to Windows is very good for customers, it is best
suited for sales and marketing."
I can't speak about going to Windows in Foxboro because we don't have any
and don't have any plans to ever go to it. Unfortunately, we upgraded a
competitor system from the tried and true to a Windows based system. It
has
had problems ever since, all due to issues with Windows/Service Packs and
the applications not getting along. I won't even get into the issues
with
security. Also, there is the ever-present finger pointing between MS and
the vendor about who is responsible for fixing the issues. My last major
issue with Windows system is that they seems to require constant
attention.
I don't have the time or the people to keep this thing running. I had the
old system 10 years and spent very little time maintaining it."
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of stan
Sent: Monday, August 23, 2004 8:31 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FW: Anybody Using IACC??
On Mon, Aug 23, 2004 at 01:31:55PM -0500, Jeremy Milum wrote:
> On Mon, 23 Aug 2004 14:20:40 -0400, tom.vandewater@xxxxxxxxxxxxxx wrote:
> > I received several good responses to my original question
"Anybody
> > Using IACC?" from list members. Most were sent directly to me instead
of
> > the entire list.
>
> Could you summarize the comments you got for us?
>
Feel free to put my comments that I sent diretly to you
in a summary, if you wish.
--
"They that would give up essential liberty for temporary safety deserve
neither liberty nor safety."
-- Benjamin Franklin
_______________________________________________________________________
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
_______________________________________________________________________
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:
