OS/2's use has never been restricted only to business use. Many of us use it
at home or for internet servers. However OS/2's use in the nuclear power industry
is another branch of its existence which provides unparalleled evidence of its versatility.
For their prototype maintenance vehicle for the International Thermonuclear Experimental
Reactor (ITER), Spar Aerospace programmer Perry Newhook chose to put OS/2 Warp 4.0
to use as both the brains of the on-board computer and the interface to the human
operator remotely controlling it. The L7 Divertor Duct Maintenance vehicle and robot
works under the more dangerous conditions within the fusion reactor where rapid
response time is crucial to the success of any operation.
For more information on the ITER project please see the ITER Canada Homepage
at http://www.cfftp.com/ and the ITER homepage
at http://www.iter.org/. The page describing
the L7 Duct Vehicle is at http://www.cfftp.com/results/stat-rh.htm
Perry Newhook, P.Eng can be reached via email at pnewhook@spar.ca
VOICE contacted Mr. Newhook to ask about his decision to implement OS/2 for this
project.
VOICE> Can you please describe your current use of OS/2 in your workplace?
What kind of hardware and software are you using for this project?
Perry> Currently all of my development is in OS/2 Warp 4. However the decision
on which operating system to use is on a project by project basis, as no one OS
will suit every need. That said, I've used OS/2 on every project I've been on here
at Spar in the past three years.
For the ITER project, we used OS/2 Warp 4 trimmed down to bare bones with a shareware
utility called BootOS2. This ensures that the only things running are my application
and the required operating system files. To the trimmed down OS/2 we added networking
TCP/UDP capability and in the case of the GUI machine, OpenGL.
For hardware, the PC's are just ruggedized Pentium 166's with 32MB ECC memory.
Nothing special. There are two PC's in total; one runs the user interface GUI, that
sports a 3D virtual display of the vehicle and robot, and the second has no screen
or keyboard and is used to control the vehicle and robot. It also runs some of the
safety systems.
VOICE > How was OS/2 chosen for this aspect of the project? What features
were considered important for this project?
Perry> We looked at a variety of operating systems and development environments.
We ended up picking OS/2 because of my familiarity with it, and the successes we
have had with it in previous projects. Before we settled on OS/2 however I had to
write a few performance measuring applications to see if it could match our performance
requirements. Our end pick had to run on a standard PC, meet our real-time requirements,
and have an intuitive and easy to use development/debugging environment.
For the GUI side we wanted something easy to be able to do screen designs, and
since we wanted some kind of visual feedback to the operator, support for a standard
3D API such as OpenGL.
VOICE > What previous experience was there with OS/2 and other operating systems?
Perry> I have been using OS/2 since the 1.21 days; about eight years now I
think. I learned OS/2 working on banking systems at NCR. Before that I was a Windows
programmer so I'm familiar with both sides of the fence. Along the way I've also
picked up in various projects, QNX, OS-9, SGI IRIX, and VxWorks. We have also used
OS/2 in other parts of the space program, such as running QA tests on the space
shuttles' Canadarm, so we knew first hand how reliable an operating system it is.
Lab work here at Spar has also given us experience in a variety of real-time and
non real-time operating systems.
VOICE > What other operating systems if any were under consideration for this
>project?
Perry> I believe the serious contenders were QNX, VxWorks, NT and of course
OS/2. VXWorks is a great product on the Motorola side and we have used it in the
past, although noone had experience with the Intel version.. It was rejected for
this product because we wanted to use an off-the-shelf Intel PC and some periphials
we wanted to talk to didn't come with Intel VxWorks drivers. NT was discarded because
I could show that it's memory management and multitasking were poor compared to
the other choices. Also we needed to be able to disable the virtual memory and remove
the GUI for the embedded PC, as these are two of the major causes of non-deterministic
behaviour. With NT this was not possible, so we could not guarantee response times.
Resource requirements were also very large for NT although this was not a major
concern. To make development easier and cut developement costs we wanted the GUI
PC and the embedded PC to use the same OS. Since we had decided that OS/2 would
be used as the GUI, because of previous GUI work on other projects, we chose OS/2
as the embedded as well. Obviously before this decision was final we had to run
tests to make sure it really was deterministic and that responses were well within
our requirements. If OS/2 failed those tests we would have probably chosen QNX as
it is an extremely good real-time OS. As it turned out OS/2 performed more than
acceptably.
When we announced that we had chosen OS/2 as our embedded and GUI operating system,
there was a bit of an uproar from the NT zealots on-site. Because we wanted to talk
to a DeltaTau motion controller card and DeltaTau does not have a device driver
for OS/2, it meant we would have to write one in house. The people pushing NT cited
this as a reason to not use OS/2 as in their words "it would take six to eight
months to write a driver", and DeltaTau already supplies a driver for NT. As
I've written a Windows driver before, the six to eight month figure for a device
driver for Windows was about right. Looking into OS/2 device drivers I found that
the OS/2 device driver model was far easier than the Windows one. In the end it
took a mere two weeks to complete a full featured device driver with libraries for
the DeltaTau card.
VOICE > Do you foresee continued/increasing use of OS/2 in this fashion?
Perry> I hope so. OS/2 was a bit of an experiment for this project. Historically
we had chosen VxWorks on a VME platform for any serious real-time projects. This
time because of limited resources and budget, we wanted to try out a mainstream
PC operating system. As it turned out we were able to complete the project without
any having any OS related issues or problems. Incidentally this project had about
the same complexity and better a safety implementation than a project we had finished
a year earlier on VxWorks. The software on this project was completed in about half
the time and at about one third of the budget of that previous one. Those familiar
with the project agree that OS/2 was a major contributor to the cost and time savings.
The embedded / real-time market seems to be an area where OS/2 is ignored. While
QNX and VxWorks are great as hard real-time operating systems, in many applications
choosing those would be overkill. Many people and companies are doing backflips
trying to get NT to work in real-time applications, an activity that just boggles
my mind. NT's multitasking, memory management and huge footprint mean that NT is
generally not suited for this task, yet people are still trying, including writing
addons to the operating system in an attempt to make it real-time. For many of these
applications, OS/2 is more than well suited and does not need any modification other
than removing the parts that you don't need.
VOICE > Are there any changes that you would like to see to OS/2 that would
facilitate your continued use or expanded use of OS/2?
Perry> The only problem that we had in OS/2 that we had to design around was
the SIQ (single input queue) problem. We used a lot of threads in this system, over
40 across two PC's, both message queue and non-message queue capable, and we had
to be very careful with the treads that processed messages in that they not be able
to tie up the queue by taking too long in processing something. Because of this
problem, if one message thread stops reading from the queue, no other message threads
can read anything else from the queue until the first message is cleared. This caused
some creative application designing to ensure that this cannot happen. If the SIQ
problem was not there then we could have simplified things a bit. As it turned out
it was not much of a problem, we just had to follow a few simple rules during the
coding phase.
In certain programs at Spar, we have use for a soft real-time OS, that can generate
a virtual reality type 3D display. We have used OS/2 and it's implementation of
OpenGL to some extent for this purpose, including the ITER program, but to do any
significant detail, it quickly becomes apparent that you need 3D hardware acceleration.
OS/2 does not yet support 3D acceleration, and as a result this is one area that
NT is currently more capable.
VOICE> If and when IBM makes Hardware supported OpenGL available, will that
help in this area? Have you contacted IBM about 3D support?
Perry> IBM has already completed some necessary steps in creating hardware
accelerated OpenGL, the most noticable being the release of the GRADD drivers. This
GRADD model is necessary as IBM will provide the core acceleration via the GRADD
drivers, and the card manufacturers simply add their part that links the hardware
specifics to the driver. Since the time to create accelerated drivers is vastly
reduced, it makes it much more likely that card manufacturers will commit the time
to make the drivers.
It was also announced that the OpenGL AIX team has released their toolkit to
the OS/2 division to be ported. This has to be done as it is this toolkit that help
video card makers create the drivers. Letting IBM know that this functionality is
what we need, is the best way of ensuring that this project goes to completion.
You can tell IBM that you want hardware accelerated OpenGL drivers at the OS/2 Requirements
Submission site: http://www3.software.ibm.com/reg/pspreq/pspreq-r/
Another event that has to happen is for video card manufacturers to ask IBM for
the toolkit to create the accelerated drivers. The only way this will happen is
if we the users, POLITELY ask the card manufacturers for 3D OpenGL accelerated drivers.
Without a percieved demand, these drivers will never exist. Without these drivers,
OS/2 penetration into any 3D market, and this market is continuing to grow significantly,
will be limited.
IBM's software implementation of OpenGL is demonstratably faster than the software-only
version of Microsoft's OpenGL. I see no reason why IBM can't make a hardware accelerated
version and make it faster than Microsoft's, just like they did with the software
version.
VOICE > Do you know of any other sites using OS/2 in the Nuclear industry?
Perry> No, not really, but I have had interested people from both inside and
outside the nuclear industry contact me. Spar was one of the first companies to
finish it's deliverable for the ITER program, so it will be interesting to see what
OS's other companies chose and to see how well they hold up in the upcoming years
of use. I've also had some intersting mumblings from within IBM itself.