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