>>The standards for almost all software are being defined by Microsoft - and they are based on Windows. [With the Willows Win32 API announcement]It looks like WRS has started to recognize the fact that Microsoft standards will come to dominate the embedded market.
Close, but you are a little off. Extrapolating that "little bit off" into the future will cost you bundle if you bet on the wrong horse. Let me explain.
You are correct when you indicated the announcement is an explicit recognition of the importance of the Win32 API. Your error was in concluding that this announcement presages an inevitable encroachment by Microsoft in the embedded systems space. Actually, what little reason there may have been for choosing Microsoft is diminished considerably with this annoucement.
To see this, let's take a specific design win and try to imagine what is going on, and what will be happening over the next few years. A fun example would be to consider QualComm (QCOM). Last May, while announcing its quarterly earnings, WIND stated the following:
"Qualcomm selected Tornado for use throughout its Globalstar project. Globalstar consists of a constellation of 48 low-earth orbit (LEO) satellites, gateways, fixed and mobile handsets, and will provide wireless telephone service, data, fax, paging and position location services to customers around the world. Globalstar satellites will begin launching in the second half of 1997, with commercial operations slated to begin in 1998."
Last spring you would have been forgiven if you were skeptical about QCOM's and Globalstar's future; today it is a dead on certainty. They are extending their on-schedule $300 million dollar development contract for Globalstar infrastructure, handsets, etc. to $500 million. QCOM's PCS systems started rolling out late in 1996, first in Asia (Hong Kong and Korea), and then very rapidly in the United States. By next year, QCOM's CDMA will be operating for millions of subscribers all over the world - competing head-to-head with Ericsson's GSM, which also will have millions of wireless subscribers. This year QCOM will begin rolling out Wireless Local Loop systems that can provide much higher bandwidth and can substitute for last-mile telephone and other connectivity. QCOM already, and has for a long time, run a location and messaging service for mobile vehicles like trucks and tankcars, called OmniTracs, using satellite communications.
According to the announcement, VxWorks must be being used for satellite and ground station communications. It would be insane for QCOM to even consider replacing VxWorks with anything from Microsoft for this purpose. This is great for WIND investors, but still the really big numbers are, per usual, on the client side - the handsets and gadgets that will be built to utilize the Globalstar communication network.
Now, suppose you are tasked with developing a smart widget that uses the QCOM/Globalstar wireless communication network. How would you do it? The answer is there are two starting points for development, and which one you would favor will depend on who you are and what user interface and algorithms you will need for your widget. If the interface is to be a full screen, graphical, windows-type and you have a Windows programming background (which most programmers do) with a garage full of high-level algorithms (such as distance calculations between coordinate points, fuzzy logic, statistical routines, optimal routing routines, etc. - all in Win32) you would naturally incline toward using Windows in some fashion - like Windows CE or an embedded version of Windows NT, and somehow punting on the low-level details. If the widget has a simple interface and is extremely resource restricted, like a message pager, or one of a billion kinds of hidden computers that will be coming out of the wood work to take full advantage of QCOM's network, then naturally you will lean toward an embedded RTOS like VxWorks. In the case of QCOM's network, you would generally lean toward VxWorks if only because of the availability of proven, reliable low-level routines for handling all the arcane aspects of CDMA wireless communication, soft handoffs, error-correction, etc.
Since we know that eventually thousands of widgets will be needed for every widget sporting a fancy user interface - in keeping with the emerging 3rd wave of computing (the ubiquitous computing wave) - we know that VxWorks would dominate over Embedded Windows even without the Willows announcement. That's why Windows CE, and the existence of embedded Windows NT, for example, are not lethal to WIND.
But the Willows announcement does change things, and what it changes does not favor Microsoft. With Willows Win32 API, it is possible to have all the robust, low-level capability on your platform of choice using VxWorks, and layer-on your favorite high-level algorithms, database connections, and Windows interface routines - probably all developed using a Wintel PC - to complete the widget in record time and convenience. High-level Wintel software developers can now work comfortably along with low-level, embedded systems engineers - all within the domain of VxWorks, not Microsoft. The effect of the Willows announcement is that the Windows CE, NT, etc. option is only justified for full PC-type widgets, where Independent Software Developers would be expected to provide add-on, shrink-wrapped software - an insignificant portion of the future wireless devices market.
While the VxWorks/Willows solution will minimize the development cost of most wireless products needing significant intelligence on the client-side, it also has the important benefit of being radically less expensive to produce in production quantity. This win-win capability makes the Microsoft alternative useful only in prototype situations or market niches where the developer has limited embedded systems experience. This will rarely be the case for large Consumer Electronics firms, and it most certainly is not the case for QCOM.
Let's forget MSFT and finish the story. As QCOM begins to deploy wireless local loops in homes, offices, sub-divisions, airports (this is the best way to "wire" an airport, to interconnect literally thousands of remote devices) and all over the developing world, these systems will seamlessly integrate with PCS and cellular systems covering a wider area (but with reduced bandwidth), and PCS and cellular systems will integrate seamlessly with Globalstar, providing coverage throughout most of the world. Data systems will emerge quickly by the tens of thousands (systems not users!) to utilize this capability, with each system addressing anywhere from hundreds to millions of potential client devices.
The bottom line for WIND is the potential for billions of royalty-bearing targets growing out of the QCOM Globalstar design win. Both the I2O and NC potential are very big, but the potential for growth by helping QCOM taxes the imagination. And this doesn't even count GSM-based wireless devices.
And if you find these numbers staggering, keep in mind that I never explicitly mentioned military systems, which will be using encrypted CDMA and much deployed using Globalstar by Loral and others - who mostly use VxWorks for embedded applications. (Loral is a major owner of Globalstar; QCOM owns 7% through a partnership with Loral.)
Allen |
