Summary: Ammunition For Choosing VxWorks
Simon Pryor
In article <20...@alcbel.be>, on 2 Jun 93, I ask the questions:
> We are evaluating solutions to a forthcoming embedded project,
> that we have planned, and would appreciate any comments.
>
> The project is to be in C++, on a (probable) VME target with
> Sun SPARC hosts. We have used ObjectCenter on a previous
> project (Sun host & target), so the VxWorks & WindC++ Gateway
> would be one obvious (and interesting) solution.
>
> We are also looking at a full OOA, OOD and Cadre's latest
> TeamWork, appears to also link directly into ObjectCenter,
> closing the loop from Analysis to real-time embedded code.
>
> We will need a very high data throughput, maybe FDDI or
> Ethernet, which makes VxWorks networking also attractive.
>
> We could also envisage using things like SNMP in the future and
> I note there have been ports to VxWorks; What about other RT OSs?
>
> An alternative might be VRTX using the Velocity cross-development
> environment (or indeed others).
>
> Does anyone have any convincing arguments as to why VxWorks is
> best (or otherwise). Either technical and/or commercial (financial)
> arguments would be of interest.
>
> I realise the I'll get scores of hate-mail, but I get the impression
> that VxWorks is winning the "real-time os" wars, with people moving
> from things like VRTX, pSOS+, LynxOS, etc, to VxWorks. Is this true?
Since then I have had several replies, some of them asking me to summarize
my replies back to the net which I have done here.
I was unsure of normal practise, but I have suppressed the names of
respondents, as I thought appropriate, to protect their right to anonymity
(as they e-mailed me, and any entry direct to the net may have been worded
differently).
A US government worker wrote (it receives may gold "Best Reply" award):
> I never believe that there's one *true* answer to all questions. I
> think that the answer depends on the situation, and that each situation
> needs to be examined on it's own.
>
> VRTX32 and PSOS+ have long histories as robust, reliable, fast RT
> kernels for resource-limited, embedded applications, like telephones.
>
> However, the world is changing. People are developing real-time systems
> which are *not* resource limited. VMEbus systems typically have Mbytes of
> RAM and ROM, as well as network and disk connections, all at a reasonable
> cost. WRS started off by added support for these things *on top* of PSOS
> and VRTX, i.e. making theses kernels less suitable for their intended
> application, but more suitable for this 'new' type of application.
> Since both SCG (PSOS) and Ready Systems (VRTX) are grafting VxWorks-like
> development facilities on top of their core systems,
> it appears that they are 'caving in'. However, last I checked, they still
> offer a 'core' kernel at a ridiculously low price. With VxWorks you *have* to
> buy all the bells and whistles.
>
> Systems like QNX and LynxOS seem (to me) to be approaching the problem
> from a much different angle. It seems that they are relying on the
> fact the standards (defacto and de jure) tend to make systems more competitive.
>
> Both of these systems will run on an off-the-shelf IBM PC, and support
> POSIX standards for programming. VxWorks is now scrambling to add POSIX
> support (some of 1003.1 and 1003.4, draft 12), but will never be able
> to fully support these standards. VxWorks also doesn't work on iNTEL machines.
>
> before LynxOS and QNX, there was OS-9 (and OS-9000). This was touted as
> something of a UNIX work-alike, tho it never complied with POSIX, so
> it seems not to have caught on as much as it could have.
>
> Soo..... I see the real-time world as divided into three segments :
>
> 1) 'small' realtime systems, like my GPS, or my laser printer, constrained
> in resources and price. VRTX32 and PSOS+ are ideal. VxWorks could be used, but
> mostly because of it's development environment, not because of it's features.
>
> 2) 'medium' systems, usually one programmer, one computer,
> dedicated to a specific task. Many scientific experiments fall into this
> category. Take some data, massage said data. Use the results to control
> some apparatus, log the results. The segment seems to be dominated by turn-key
> systems, like Lynx or QNX on a PC. I've also seen Lynx and OS-9 on VME systems
> in this environment. VxWorks is ill-suited, 'cause you need to buy 2 computers,
> not one. VxWorks is not a self-hosting system.
>
> 3) 'big' networked realtime systems, like the particle accelerator
> control system we're building, or N.Y. City's integrated traffic light system.
> VxWorks is ideal. The cost of VxWorks is small WRT the cost of the whole
> system. A well-integrated, and easy-to-use development environment is a
> requirement for a large system, with many people working on it.
>
> If VxWorks is 'winning' it's because it's essentially unrivalled in category
> 3) applications, and category 3) applications are becoming more prevalent.
> VRTX velocity and PSOS 'quick start' (or whatever it's called) aren't quite
> as well integrated into the UNIX host as VxWorks is. I *don't* think VxWorks will
> make great inroads in category 2) applications against firmly entrenched
> competitors like Lynx and QNX.
>
> BTW, you never stated what your application was. Since you mentioned goodies
> like C++, Cadre, and FDDI (not ATM?), it sounds like your application fits
> into category 3). If I were you, I'd use VxWorks.
To this I would add:
WRS have released MicroWorks which is presumably to address the category 1)
applications and means you don't have to buy all the bells & whistles.
Ready Systems seem to dumping the monolithic VRTX32 and moving to VRTXsa which is a
micro-kernel with scalable, preemptable library kernel routines, and their Spectra
development evironment, competing with most things the WRS have for category 3).
A disgruntled Hardware/BSP developer wrote (against WRS):
> The one comment I would make is that the customer support is definitly
> substandard. The level 1 support people seem to know less then I do and if
> you are running a custom board, they take very little interest in assisting
> you w/ problems that might very likely be theirs.
>
> I find this particularly puzzling in light of the fact that we are
> evaluating their OS for use in multiple platforms, and if it were my
> company, I would be kissing mucho butt to make a good impression.
A nuclear physicist at a Belgian university wrote:
> I'm using VxWorks since 3 years for RT data acquisition. I'm really happy
> with it and I am still convinced that it is the more powerful RT kernel
> right now ! However, one choice to consider now is also Lynx OS which
> follows closely the 1003.x suite - this might be an advantage despite
> lower performances !
An ISI employee dbar...@isi.com (David Barnett) wrote:
> I am Product Marketing Manager for Networking Products at Integrated
> Systems, producers of the pSOSystem (and pSOS and pSOS+) real-time
> operating system and development environment.
>
> You mention that you require C++ development. I believe that ISI was the
> first RTOS vendor to have fully integrated and supported C++ support, which
> began shipping in November, 1992. In addition to including a C++ compiler
> our C++ support also includes class libraries for all OS services. We have
> also made several major enhancements to standard C++ to make it more
> suitable for real-time use. One of these is replacing the standard C++
> memory allocator (malloc) with one optimized for C++ use. Our allocator
> (whose use is transparent to the programmer, of course) solves the C++ heap
> fragmentation problem be utilizing several heaps for data structures of
> different sizes. These sizes are selected by the programmer based upon the
> sizes of data structures in the application. Another optimization is an
> "object register". This allows objects to be automatically freed when the
> task which owns them exits.
>
> With regards to SNMP, I believe that pSOSystem is the only RTOS to include
> an integrated SNMP agent, which may also function as a proxy. We include a
> MIB compiler so that you may extend or restrict its functionality. We have
> also instrumented out TCP/IP stack so that it fully suports all MIB-II
> objects and operations (except for the EGP group), including read-write,
> row insertion and row deletion. There is a standard ioctl() programming
> interface to our MIB-II functionality so SNMP may be bypassed when just
> MIB-II functionality is needed or so our MIB-II implementation may be used
> with other SNMP agents.
>
> With regard to networking support, we have a complete TCP/IP stack which
> includes the source code to both Ethernet and FDDI device drivers (as well
> as SLIP). Our networking device driver interface is protocol and upper
> layer-implementation independent. This both simplifies the effort and code
> involved in writing a driver and also allows our drivers to be shared
> between the TCP/IP and other protocol stacks (such as OSI). It is not
> necessary to modify our networking drivers to use them with other protocol
> stacks.
>
> Since you are interested in both object oriented design and networking, you
> may also be interested in a new product we have just introduced. It is
> called the "Distributed Systems Generator" (pSOSystem/DSG) and consists of
> development tools, libraries and application programming interfaces
> designed to facilitate the design and development of real-time distributed
> systems. With pSOSystem/DSG, an application is specified in terms of state
> machines. Each state machine is designated a "worker". Workers
> communicate using either synchronous remote procedure calls or asynchronous
> message queues. Inter-worker communication is optimized based upon whether
> the two communicating workers reside in the same task, different tasks on
> the same CPU, different CPUs of the same type or with the same data
> representation or different CPUs of different types. Faciltities are also
> provided for fault tolerance and to support dynamic reconfiguration.
> pSOSystem/DSG also runs under several UNIX variants (including SunOS).
> This has two advantages: it allows code sharing and seamless communications
> in a heterogeneous UNIX/pSOSystem environment and also allows applications
> to be fully developed under UNIX and later executed on top of pSOSystem.
> The pSOSystem/DSG programming interface hides the differences in the
> underlying tasking and timer interfaces between UNIX and pSOSystem.
Another ISI employee nlet...@isi.com wrote:
> Financial:
> Integrated Systems (the company that produces pSOS+) is a public-owned
> company with a consistent record of profitability and growth. We have been
> publically owned for much longer than WindRiver and have a large amount of
> cash in the bank (>$25 million). Financially, we are the stongest RTOS
> company.
>
> Although I'm not sure of Alcatel Bell relationship to other parts of
> Alcatel, Alcatel has made very significant investments in pSOS+ in Dallas
> and on the east coast.
>
> Technical:
> pSOS+ is very suitable for your project requirements.
>
> 1. C++. We have offered a C++ solution for over a year, whereas WindRiver
> is only just introducing their solution. Our solution is also more
> complete, addressing issues such as optimized memory management for C++
> and providing an object-oriented interface to some pSOS+ services. Since we
> have been supporting C++ projects for more than a year, our technical
> suport staff are more experinced in C++ issues than WindRiver's. We also
> have a training course for pSOS+ C++ users. While we do not provide formal
> integration with ObjectCenter, there is no reason why you cannot continue
> to use it. Certainly, I know at least one pSOS+ C++ user that uses
> ObjectCenter extensively.
>
> 2. Networking. We have good networking support including etherent and
> FDDI. Unlike WindRiver, we already supply a fully supported version of SNMP
> for pSOS+.
A disgruntled pSOS users wrote (psos+ hate mail, let me be the first):
> We recently had a merger of **<text deleted>** and had
> the *priviledge* of moving from vxworks to psos.
> Let me count the ways I hate psos+
>
> 1) no on line man pages
> 2) the manual is broken down by products. There is no master
> index. If you change from looking up socket() to
> looking up bcopy() you must pull out a different manual
> 3) Intuititive names like
> sm_p acquire a semaphore
> sm_v give a semphore
> 4) Needing a 4 character identifier when createing each semaphore
> and task. This makes porting a real pain
> 5) Total incompability with unix makes using widely available
> anon ftp packages very hard.
> 6) No mail exploder. *Total* isolation from other users.
> 7) The old phone-call system for getting tech support. How many
> times have I seen the answer from a VxWorks engineer
> posted right to the vxworks mail exploder.
> 8) totally unfamiliar debugger.
> 9) absolutely unbelievably gross makefiles. They use many includes
> of other files which makes it very hard to use any
> compile directives in your makefiles.
> 10) that nagging feeling that my unix knowledge and therefore general
> marketability is slowly draining away.
>
> I produced a 2 page position paper on why choosing psos would cost
> us more in devlopment time and reduce the labor pool we could hire
> from. If it isn't obvious why using psos will cost you more from
> the above points just think about the learning curve and retraining
> time you waste when hiring someone unix literate and expecting
> them to start producing psos code.
Well, that was about it. I'll leave you to make your own conclusions.
No doubt the debate will continue.
A big thankyou to all who gave of their time to reply.
sp_...@space.alcbel.be (Simon Pryor)