Windows CE, Part 1 (long)
==========================
As a software and systems engineer with 23+ years of experience,
including real-time embedded systems design and development, I
thought I would share my perspective on Windows CE (WinCE). My
primary objective in this post is to help investors distinguish
between consumer electronics (CE) and embedded systems, which is
WIND's primary market. FYI, I do not work for any company in the
RTOS sector; I am a long term WIND investor.
Ignoring the fact that WinCE is not a "hard" RTOS, its main
differentiating feature, compared to WINDs VxWorks, is its user
interface. However, embedded systems do not require this Graphic
User Interface (GUI). This is, in fact, the characteristic that
best defines "embedded" systems. An automobile engine control
system does not need a user interface, nor the electronic
components necessary to support it (video or LCD controller and
display, keyboard/keypad and/or pointing device, and additional
memory). Neither does a laser printer, nor a cable modem, nor
a data communication switch, nor a weather monitoring station,
for example. In many embedded system applications, these user
interface components would equal or exceed the cost of the
entire product ( e.g. a modem ). That's not to say that these
devices do not need to be controlled or configured, but the
whole idea behind distributed computing and client/server
architecture is that you put the functionality where you need
it. Desktops (PCs, workstations), laptops, PDAs, palmtops, STBs,
etc. need a windowed GUI; other devices do not - they simply
need to be able to connect to a communication link. Why would
an embedded system design that does not require a GUI pay the
added cost of the MSFT Windows functionality? The answer is that
it won't, and can't, if the product is going to compete successfully.
To illustrate my point, let's examine several types of embedded
systems:
- automobiles,
- data communication equipment, and
- soda vending machines.
Due to the harsh environment present in automobiles, the normal
processors used in office equipment are not appropriate. The
processor of choice in the auto industry is the Siemens C166. GM
paid WIND to port a subset of VxWorks, with some custom enhancements,
to the C166 a couple of years ago. Since then, Siemens paid WIND to
do a complete port of VxWorks and Tornado to the C166; the port was
completed during the 3RD quarter of last year. GM already has the
C166/VxWorks slated for its fuel injector controller and has
specified the C166 for its new automatic transmission. WIND provides
the ONLY commercial RTOS for the C166. Around the turn of the
century, millions of GM vehicles per year will be produced with at
least two C166s under the hood. Neither of these controller
applications need a user interface - they are "black boxes" embedded
in the engine and transmission of the car. The only user access to
these controllers will be through a engine diagnostic machine at
your friendly auto repair shop. WinCE could possibly be used in a
next-generation engine diagnostic machine, with a TOTAL production
of less than 100,000. However, WinCE would never be used in place
of VxWorks for these embedded controller applications, which should
produce quantities approaching 10 million PER YEAR, several years
down the road. These quantities are by no means formal projections,
but are simply presented to show the magnitudes that separate the
embedded application from the user interface application. Also note
that I am only including what I know about GM's plans. It is
possible, even likely, that the C166/VxWorks combo will be used in
other automobile lines in the future.
For my data communication equipment example, let's look at a
typical Internet Service Provider POP (Point of Presence) in an
average city. There would be a number of equipment locations spread
around the metro area to provide local telephone access - let's say
there are 6 locations. Each location would have a collection of
modems to answer incoming customer connection requests - let's say
there are 2000 modems at each location or 12,000 for the metro area.
At each location each modem is connected to a port on a terminal
server. The number of modems attached to a terminal server depends
on the particular equipment being used; for this example let's
attach 16 modems per terminal server. Thus, each location would have
2000 / 16 = 125 terminal servers, or 750 terminal servers for the
metro area. The terminal servers at each location are connected to
one or more LANs along with one or more routers. The routers direct
the data traffic to and from the terminal servers onto the ISP's data
network comprised of a number of T1 and/or T3 data links. So, in the
metro area there are 12,000 modems, 750 terminal servers, and at
least 12 routers. None of this equipment has or requires a user
interface of its own - it is all controlled and configured remotely
from a networked console. The console is typically a UNIX workstation
or PC. In the entire metro area, there may be a total of a dozen
network consoles, tops. The modems, terminal servers, and routers
are all running a RTOS, but it will never be WinCE for the simple
reason given above - none of this equipment needs the Windows GUI.
The user interface that IS required at the network console is provided
by existing workstation/PC equipment running HP OpenView, SUN
NetManager or the like, along with standard TCP/IP connection
utilities (telnet, ftp). The equipment can actually be controlled
from any computer capable of accessing the ISP's network, given the
required port and password authorization. The communication equipment
sector has been a traditional stronghold for VxWorks and WinCE offers
no threat whatsoever to WIND's market share. If anything, I expect
expansion of the Internet infrastructure and deployment of ATM to
bolster WIND's position in this sector.
As a final example of embedded systems, let's look a soda vending
machine. Someone on this thread scoffed at the notion of using
VxWorks in a lowly soda machine, believing that it would be massive
overkill. I disagree. I'll grant that counting coins, detecting a
button press, and releasing a selected soda down a chute is not a
very demanding set of tasks. What possibilities open up, though,
when the soda machine is viewed from the distributed computing
perspective? If the vending machine is given access to a phone
line, why can't it report refrigeration failures, coin jams, or
other malfunctions back to a district service desk? Why can't
unauthorized movement of the machine, or forced entry into it, be
detected and reported? How about reporting the sales of the
various soda flavors each night, so that re-stocking can be scheduled
in the most efficient manner? Adding these capabilities to the soda
machine might add $100 to the cost of manufacturing it, including
the modest royalty to WIND. The phone line usage would be so
incidental that the machine could easily share the line already
present at the business where it is located. The rewards would be
a decrease in machine outages and vandalism, and an increase in
re-stocking efficiency. VxWorks facilitates these improvements by
providing the reliable communication protocols necessary to
dependably deliver data back to the soda machine service bureau.
These improvements are not limited to soda machines - any vending
machine would benefit equally. I would estimate that there are
several million vending machines in the U.S.. Again, this embedded
application has no requirement for, and would not benefit from, the
GUI functionality of WinCE. The consumer has exactly what is needed
to operate the vending machine and is very familiar with it. Adding
a GUI to a vending machine would be about as successful as the
"digital dashboard" offered as an option in automobiles several
years ago - it was a total flop.
In conclusion, WinCE's primary attribute, as stated by MSFT's press
releases, is its Windows GUI. However, this functionality is
precisely what embedded systems, by their very nature, do not
require. Embedded system applications far outnumber those consumer
products, like WebTV and PDAs, where the WinCE GUI is appropriate.
In addition to the embedded applications described above,
I2O/IxWorks is yet another classic embedded system example that
clearly has no requirement for a user interface. The list of
possible embedded system applications is endless. WIND is the leader
in the embedded RTOS and development tools market. Through third-
party offerings like WILLOW, WIND can also provide open system
solutions in the consumer products arena. Last, but not least,
the native support of JAVA within VxWorks/Tornado allows WIND to
compete aggressively in other GUI applications, as evidenced by
its selection as a core platform for the second generation NC
product. In short, WinCE will have little, if any, impact on
WIND's future revenue stream.
=================
In Part 2 of this post (after I get my taxes done ;), I'll comment
on hardware/software integration in embedded systems development,
and how it demonstrates WIND's true strength and WinCE's obvious
weakness.
-Dave Lehenky |
