Re: [foxboro] RE : Barriers to migration to Windows
- From: "Kevin Fitzgerrell" <fitzgerrell@xxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Thu, 30 Aug 2007 07:57:00 +0900
Alex,
Barriers to moving to Windows fall in to a few specific categories for me:
1) Unsupported software - this is not just a Windows issue - it will
is a barrier to my move to Solaris on the Mesh also. My current plant
uses DM and Legacy historian, so we'll have to migrate those. It's
very difficult to justify a budget for migrating DM and historian
because the existing graphics and historians work very well, arguably
better than their replacements. Although the new software offers
additional functionality, we have no specific needs that are addressed
by upgrading. We have about 200 DM licenses in use and 14 2000 point
legacy historians in use. An advantage upgrade offering for these
migrations would be helpful. We've also made use of the Foxboro
provided libraries & header files on the 51 series to build our own
applications - this is far more complex under Windows and may be
problematic on SOTM.
2) Missing functionality - As has been seen on the users group lists
many times before, there are lots of things that either don't work as
well on Windows or don't work at all. Others are a standard part of
the Solaris offering but to achieve similar functionality under
Windows requires extra Foxboro packages, extra 3rd party packages or
creative workarounds which are not documented/tested/supported by
Foxboro.
3) Management - Windows boxes are very easy to manage remotely,
automatically and in large groups. IT groups all over the world do
it, some do it well. Why can't we manage Foxboro I/A boxes that way?
Instead, Foxboro has made it even harder to manage workstations
remotely under Windows than they were under Solaris. My plant is
spread out across 120km, and ranges from sea-level to 13000 ft - it's
just not realistic to visit every AW/WP whenever something (ie.
committals or QFs) needs to be done.
4) Stability & Implementation - Although vastly better than under NT,
system and process stability appears to still be an issue under
Windows. I remain concerned with the system's reliance on
MKS/Nutcracker, Exceed and ported software. I'd be far happier to go
to a completely Windows system rather than a Windows box running some
Windows software, some Unix software, an emulation layer and an X11
visualization layer.
Specific Solaris to Windows issues (similar to the list I posted a
month or so ago, but updated):
---------------------------------------
1) You can easily do tape backup/restore of the Solaris boxes.
Windows it's fairly straightforward to do backups but full restores
are not possible - need to re-install Windows, re-install I/A,
re-commit and then restore custom files. A number of users have well
developed whole machine backup/restore methods using Norton Ghost or
Acronis True Image, however this is not part of the Foxboro offering
and not covered in their documentation. Foxboro does have a new
offering for scheduled or on-demand live Windows backup but this is
not part of the standard offering. We're currently using BackupPC for
doing live network backups of both Solaris and Windows workstations
including things like our PI server and APC machines.
2) On Solaris, you can use ICC from any workstation to any control
station no matter which workstation you are working on and which host.
On windows boxes you can only use ICC for a given control station from
it's host AW. If you use IACC this does not appear to be an issue.
This issue can be partially offset by accessing the AW remotely.
3) All Solaris workstations are servers. It is easy to open a remote
DM/FV from any workstation to any other workstation. Telnet, ftp,
rmount, rcp, rlogin, rsh, nfs all just work. SSH can be made to work.
XP boxes are not really servers. FTP works pretty well. Telnet under
the Nutcracker suite has some issues. If you remotely access an XP
box it's a shared screen (although methods have been posted to the
group to work around this). The P91 boxes running Win2003Server
largely offset these issues.
4) The nutcracker shell on Widows workstations gives an approximation
of a Unix shell to try to preserve compatibility of many Foxboro and
user software and scripts under Windows. All the user friendliness of
Unix and all the reliability of Windows. Documentation for
MKS/NutCracker is largely non-existant.
5) I've had problems with AHD on windows WPs. Not sure if this can be
made to work. We had off-platform AIM* and Solaris AWs - Windows WP
could not retrieve AHD. My understanding is that Windows WPs can't
retrieve AHD from Nodebus or off-platform historians.
6) Commits and QFs on a Windows box are more of a hassle than on a
Solaris box. With Solaris you can do them remotely, and often don't
need a reboot at all. Windows you can't do remotely. You have to
reboot with I/A off, do the commit/QF, and reboot again with I/A on.
If memory serves, some require extra reboots.
7) Multiple monitors on Solaris are very simple - each has it's own
desktop. Multiple monitors on Windows are actually a single desktop
across two windows. Managing things so they stay on one monitor or
the other can be a pain - like warnings and install menues which often
pop up centered on the desktop spanning monitors.
8) If you shut down a Foxboro Windows box using the traditional
Start-> Shut Down sequence you will hang the box. You have to use
CTRL-ALT-DEL -> Shut Down or run foxshutdown.exe.
9) In Solaris, switching to the appropriate environment can give you
full administrative access to the workstation. If you want to secure
the box from Operators using Windows you can boot to FV only, but then
you have to reboot to FV+Windows to get full administrative access to
the workstation. You can work around this using the task manager, but
really the task manager should be locked down too.
10) Because Foxboro has to qualify all the Microsoft patches, the
patch levels of I/A boxes will be well behind current. This is true
of Solaris also, but your MIS department is likely to be far more
concerned about Windows patch levels on boxes connected to their
network than about Solaris patch levels on Sun boxes connected to
their network.
11) Anti-virus software is available on the Windows boxes - this may
be a pro or a con depending on your point of view. Managing updates
for this software is not automatic. After the initial license there
will be an ongoing license cost. If your MIS department already has a
McAfee Corporate license this may be easy, although the version
running on the I/A boxes (Enterprise 7 I think, maybe 8) may not match
the Corporate version.
12) I've had problems with frequent shell windows popping up and
closing too quickly to see what they said on the windows boxes.
Appears to be related to the OPC server and/or AIM*. I've seen this
on both off-platform AIM*/OPC server boxes and on P91 I/A servers.
13) A failed process can be easily restarted on an UNIX box. A failed
process on a Windows box is far more likely to require a reboot of the
workstation. Having said this, I rarely see failed processes on
either platform any more. XP and Win2003 appear to be far more stable
than NT.
14) If you run a mixed system with both Solaris and Windows,
maintaining graphics across the system is not trivial. Most of us
have some version of a copy script that lets you change a graphic on
your workstation and copy it to all other appropriate workstations.
With the new FV, all changes must be done on the Windows platform.
Changed files can easily be copied to other Windows workstations but
need to be changed to .g files to copy to Solaris boxes where they
have to be changed back to .fdf files under Solaris. This can still
be scripted but it is more complicated.
15) If you are using a V7.x system, telnets to F boxes across the
switches seem to be extremely slow sometimes. I haven't seen this
problem with the Windows boxes (and it may be fixed now for the
Solaris boxes).
16) On Solaris you can develop your own software to interface to the
I/A system using a compiler (pick your flavor) and the Foxboro
header/library files for ICCAPI, FoxAPI and Object Manager. The
Foxboro files to do the same on a Windows workstation are not all
supplied, although the last time I asked I could buy them from Foxboro
($25-50K if memory serves). Also, support from Foxboro for
interacting with their DLL files was almost non-existant last time I
tried. You may as well forget things like threaded applications, DLL
COM methods, other standard Microsoft programming methods. All of the
programming examples in the Foxboro documentation are UNIX only.
17) I find it much more complicated to secure a Windows workstation
than a Solaris one. As I understand it, I still can't change the
Foxboro passwords on a Windows workstation. I'd like workstations to
come secure from Foxboro with clear documentation for keeping them
secure and/or relaxing security in some areas.
18) It's easy to manage Solaris workstations remotely. Windows has
built in functionality that SHOULD make it even easier to manage a
large group of PCs than to manage a similar sized group of Solaris
2.5.1 workstations, but Foxboro has made it so you have to be
physically present in front of each PC to do most administration. I'd
like to be able to manage policy across all workstations, administer
patches, do committals, etc without having to visit 120km of plant.
As with #18 above, I want windows workstations to come this way from
Foxboro, with clear documentation. With Solaris under 2.5.1 I'm
willing to live with "The New Yankee DCS" where DIY is a fundamental
part of managing the system (and I like it that way). Under Windows
it's too complex for me to roll my own for everything, as there are
far more ways for things to go horribly wrong.
19) The cron scheduler under Unix is much more functional than the
Windows task scheduler. It's also easier to manager remotely. Having
said this, I'd really prefer tools and procedures to manage my system
as a whole rather than having to schedule tasks on individual
workstations.
20) Windows FV displays don't look the same (alignment issues)
on-screen as they do when you build them in FoxDraw. I don't recall
this being an issue under Solaris.
Regards,
Kevin FitzGerrell
_______________________________________________________________________
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:
