Your mention of Metrowerk’s entrance into the embedded systems space brings into focus an earlier question about the strength and persistence of WIND’s franchise, which I promised to address. This is by far the most important issue affecting the outlook for WIND.
The third wave of ubiquitous computing promises to ramp faster and to exceed most forecasts. As it quickly passes the $200 billion/year Personal Computing paradigm, and spreads to hundreds of thousands if not millions of hidden applications, it will take every form conceivable. Re-read Peter Smith’s post #189 about which legacy software languages are in use today by telecoms to get a small sense of the breath of software/hardware that will be deployed in future embedded systems. At the current time one-half or more of all embedded OS’s deployed are so-called roll-your-owns, invented-here solutions that evolved over years within organizations.
One of the easiest ways to create an embedded application, is to take a familiar OS, such as MS-DOS or Apple’s OS, add familiar libraries and use familiar compilers to generate the hidden application. On the hardware side, simply start with a small computer, yank out the guts, attach an I/O device through the serial port, repackage and voila! An embedded application is born.
Compare this casual approach to developing an embedded system with how serious embedded systems engineers develop robust solutions for high-volume applications, and then value-engineer them to minimize both production costs and physical real estate. A potential solution that is limited to a single processor or data bus generally is unacceptable. A potential solution that adds extra memory because an inflated OS (e.g. one derived from a desktop computer) must be stored, or that adds extra MIPS to approximate hard real-time by force generally is unacceptable. Try telling GM that the embedded engine analyzer usually should fire off OK, as long as event-driven communications with the braking and transmission systems don’t get too lengthy or numerous.
To appreciate how these competing forces will play in the market place, consider HP, an emerging commodity products company. Some divisions use their own homemade OS’s, one uses pSOS for settop boxes, many others now use VxWorks for cable modems, X-terminals, printers, etc. At some point management must have become aware that a corporate relationship with a single, full-featured RTOS vendor was essential to preserve flexibility in assigning highly trained and skilled staff, and to minimize the infrastructure needed for developing, testing and maintaining embedded systems. After making that decision, only full-featured RTOS and toolset vendors qualified for consideration - and they chose WIND.
Once a corporate-wide strategic relationship has been in place long enough for numerous design teams to learn a single vendor-centric toolset, and to deploy embedded products using the vendor’s RTOS, the switching costs to replace the vendor increase exponentially. To see this, start with the obvious direct costs of replacing toolsets (simulators, compilers, debuggers, etc.), perhaps new development equipment to complement the new software, and training engineers and programmers to use the new tools. But these costs are insignificant compared to what it takes to re-design and re-code legacy applications, and to re-work the entire support infrastructure for the maintenance and servicing of products. But usually even these costs pale when compared to the turf battles and religious wars that break out around software/hardware choices. The greater the learning curve for a software toolset, the greater are the territorial turf battles and religious wars that are fought often to the death in organizations. There is nothing more complicated and subject to unending debate than working with real-time embedded systems. Thus, once ensconced, nothing will have higher switching costs than embedded systems toolsets and RTOS. Is Tornado simply a cute GUI overlay, or is it the greatest advancement in embedded systems development of the decade? You have read both sides of this argument in this thread alone. Imagine what goes on in organizations charged with developing embedded systems products?
In my view, ubiquitous computing will become dominated by commodity companies that can afford large investments to engineer and produce cost-effective products. Each such company will gravitate toward a strategic RTOS supplier that meets a host of requirements. Marginal approaches for developing embedded systems will find respite for a time in niche markets, but they will slowly whither and ultimately fail in competition with full-featured, relatively inexpensive RTOS and toolset vendors that supply the commodity market for embedded systems. (Unlike vendors of marginal toolsets, niche markets for embedded products will prosper in the shadows of commodity giants.) Corporations that mistakenly rely at the outset on marginal solutions for embedded systems sooner or later will pay the high price of switching to a sound strategic partner. The RTOS market leader that has the most strategic alliances with such companies will be positioned to dominate the world of ubiquitous computing forever.
Essential requirements of a strategic RTOS and toolset vendor include at least the following:
1. The vendor’s OS must be multi-tasking and multi-threaded with a hard real-time capability. (Most desktop OS’s fail this criterion.). Most embedded applications "require" real-time, even if many don’t actually need it.
2. The vendor’s RTOS must be scalable to enable engineers to limit OS services only to those needed for the application.
3. The vendor’s RTOS must support multiple processors for high-end applications.
4. The vendor’s RTOS must execute on most popular embedded processors, with assurance that it will be ported to new processors as they emerge. This gives the value engineer, as well as a commodity company the flexibility to pick and choose processors without having to re-write tons of application libraries.
5. There must be a complete and growing set of third party tools and proven libraries, including all common communication protocols, to speed robust product development. (This is a major reason why strategic RTOS and toolset vendors ultimately will defeat marginal suppliers in niche as well as commodity markets.)
6. The vendor’s RTOS must be certified as trustworthy for mission critical applications (e.g. used by NASA to fly to Mars, or GM for a fuel injector system.)
7. When combined with third party tools and libraries, the vendor’s tools must be arguably best at minimizing time and cost to market.
8. The vendor must provide training and technical support, with an international presence to match the internationally organized development efforts of large-scale global enterprises.
9. The vendor’s OS and toolset must be popular so as to ease the job of hiring engineers experienced using the RTOS.
10. The vendor must not be significantly aligned with companies that compete with the one doing the assessment. For example, Ford would be uncomfortable strategically aligning with a vendor owned by GM.
11. The vendor must be financially sound with a focused presence that is expected to persist indefinitely as measured by market share.
I can imagine heated debate engendered by claims that WIND or INTS best meets all the above criteria, and lively discussions about whether or not MWAR meets most of them satisfactorily. But there can be no disputing that the following entrants in the embedded systems space each fail utterly to meet many of the criteria: Metrowerks "code warrior"; Geoworks Geos; Magic Cap; Microsoft’s MS-DOS, Pegasus and Windows 95/NT; Sun’s JavaOS and Solaris 2; Apple’s OS and Newton; ATT’s Plan 9; all flavors of Unix (although a few are real-time); Radisys Intel- and Multibus-based products; Microtec Research (part of Mentor Graphics); all commercial RTOS’ developed by IBM, HP, MOT, Hitachi, etc.; all roll-your-own RTOS’.
Allen |
