Advalorem,
I hadn't notice you posting here before and I thought your question to be a reasonable one that certainly deserved a reasonable response.
Before I make a run at doing so, let me first state clearly that there are _many_ other much more qualified folks on this thread and I hope they will bear with my attempt.
To begin with, if you are serious about understanding what WIND is all about and where it is headed then I would urge you to read as many of Allen Benn's messages on this thread. He is now silent, but wrote the book!
As best as I could, I studied WIND for nearly two years before investing in the stock last Spring when it was 'on sale' for 12-16 share. They had been CEO-less for some time and all the message boards were flooded with nasty messages predicting all manner of awful futures for WIND.
Since investing and continuing to read everything I could find on WIND, I had gradually come to my own conclusion that most of us have been overly optimistic about how quickly we can reasonably expect to see their technology brought to market ... and then I ran across the following clearly written (but somewhat technical) article, loaded with lots of helpful 'Reality Adjustment' content.
I hope you will find it to be helpful to you as well.
--alan
embedded.com
The Current State of Internet Appliance Design
Larry Mittag
> What makes this really exciting, though, is the mismatch of expectations and
> realities. The industry press is talking about Internet appliances as if they
> were waiting in a warehouse ready to be shipped next week. The reality, of
> course, is that they primarily exist in the imaginations of the entrepreneurs.
Embedded system developers are finding themselves at the center of a huge Internet appliance thrust. But do we have the right hardware, software, and know- how at our disposal to deliver on the promise?
The world has discovered embedded systems.
Actually, that's not quite accurate. The world at large has been aware of the output of our work for some time now. They know that VCRs are more capable today, that set-top boxes are available that support a variety of formats. They also know that cars are smarter and that practically every other device is adding features and cutting costs on a regular basis.
What's new is that we are starting to integrate these devices into data communication infrastructures. This makes us an Internet industry, which, to the popular press and the investment community, means that it is New and Happening and will automatically grow exponentially and make mountains of cash for everyone.
I warned about this phenomenon in a keynote speech I made at the Embedded Systems Conference Summer last year in Boston. The good news is that the relatively conservative practice of embedding computer power into dedicated devices has suddenly become a cutting-edge technology in the eyes of the world. This attention brings with it a variety of benefits, not the least of which is the ready availability of money for new development efforts.
But are we ready for this? What is the reality of designing and manufacturing these devices? Is the Internet appliance the next logical step in the evolution of computing power or is this all just another hypefest? What about earlier incarnations of similar devices, such as the much-lauded network computer that never did live up to expectations? These are the questions I will examine in this article.
Three specific areas must converge for these devices to be viable: hardware, software, and communications. Let's examine each of these in turn.
Hardware
Hardware is the newest piece of the puzzle for these devices. The last wave of Internet expansion was built on the PC platform, which had the advantage of presenting a consistent and powerful platform with a fairly constant operating system and hardware platform. This usually draws a look of disbelief from PC engineers, because they have to deal with CPUs from three or four companies that each have minor variations on the x86 architecture. They also have to deal with two or three different operating systems that have similar but varying APIs.
(OK, you guys can stop laughing now. PC engineers just don't know any better.) The reality in the world of embedded systems is that the hardware is tightly tailored to the application. At least five major CPU architectures are available in the 32-bit space and dozens more exist in the 8- and 16-bit spaces.
In the embedded world, display hardware varies from none to fully bit-mapped displays. In fact, an emphasis on display hardware is one of the characteristics of first-generation Internet appliances. This is a result of the "Slap A Browser On iT" (SABOT) school of Internet appliance design, which has led to a sharp increase in the use of high-resolution bit-mapped LCD panels on everything from cell phones to toasters.
The SABOT approach is one of the major cost drivers for Internet appliances in this class. An LCD panel and display controllers can double or triple the materials cost of a low-end system, completely skewing the economics of the device. Volume is beginning to drive down the price of the LCD panels, and supporting hardware is beginning to be included in CPU and integrated peripheral chip designs, but this is happening slowly.
There are other cost drivers as well. A PC has the advantage of a big mass-storage capability, a place to store software when it isn't being used. Embedded systems rarely have that facility. This means that software is generally stored on relatively expensive flash memory.
One option is to boot the device out of flash and execute the firmware out of RAM. This has the added advantage that it makes it possible to update the executable image stored in flash, a common requirement with these devices. This does add to the cost, however, since the amount of RAM must also increase. This approach has other ramifications as well.
Availability
The availability of parts is a serious consideration. Currently, some vendors of flash memory are not even accepting orders for at least a year, which could put a major crimp in the plans of many entrepreneurs planning to deliver the next hot Christmas present this year.
Many of the companies now creating Internet appliances originally cut their teeth in the last Internet expansion to the desktop. They have outlined aggressive expansion plans, scaling to hundreds of thousands of devices within the first year or two. They are accustomed to much more aggressive expansions supported by downloadable software in the desktop Internet expansion. Now they have to consider the fact that Internet appliances are made from atoms instead of bits.
Beyond the availability of parts, other potential pitfalls in hardware await the erstwhile Internet appliance pioneer. A variety of reference designs are out there to provide a starting point for a semicustom design. This is appealing to an audience that grew up on standard PC hardware. Why not just use a generic design with a few modifications to support a specific application? As with most shortcuts, however, there are potential problems. One of these is obsolete parts. Several of the reference designs that I have studied call for parts that are either fully obsolete or are "not recommended for new designs." (The hardware industry's code phrase for a part that is about to become obsolete.)
This is particularly important for SABOT Internet appliance designs. Video hardware is often driven by the PC market and can become obsolete within months of its introduction. Industrial OEMs are looking for products that will have a five-year production cycle. For example, automobile electronics have a two-year development cycle before the first units are sold.
Reference designs have other problems as well. Hardware is designed with particular tradeoffs in mind. A reference design must guess at what is important to the application without direct knowledge of that application. The few changes that might be necessary could easily break the assumptions of the design. For example, adding a peripheral might push the capacitive loading of the data bus over the edge. In this case, you would have to add drivers to the bus, which affects the timing of the bus. By the time you are done you might have a very different design, yet have to pay royalties for the one you started with.
None of these problems are insurmountable. Internet appliance companies new to the hardware world simply must learn to contact vendors early to ensure delivery of parts.
These are the details that don't make the stories in WIRED or the front page of The Wall Street Journal, but they must be taken care of before cutting-edge products can make it past the COMDEX show floor and actually be delivered to customers. This is also the part of Internet appliances where the biggest gap in the knowledge and experience of many of the people trying to break into the market lies. It is therefore up to us to make sure it gets handled well.
Software
The software aspect of Internet appliances is much more specific to the application. It is also the side that is getting most of the attention from the press. It's also pretty much a mess at the moment.
The basis of the software for Internet appliances is the TCP/IP protocol stack, which is generally a well-specified piece of software. TCP/IP has been included in a large percentage of operating systems. Unfortunately, it's difficult for a TCP/IP stack purchaser to judge the relative quality of the implementation. For example, some specific additions to the basic stack, such as a zero-copy option, can be important to embedded applications.
A more immediate concern about TCP/IP is the fact that it was built to be administered. This is only a minor problem for a corporate customer that has an MIS department, but it's a major hurdle for a consumer who just wants to get her new Internet-enabled TV to boot up prior to the Super Bowl kickoff. Capabilities such as DHCP and IP spoofing can solve some of these administration problems, as may some new modifications made to TCP/IP to allow small, self-organizing networks.
Smart networks
Some of these modifications are part of the network software that is beginning to show up to organize these devices. At least three major types of networking software are available today. The names are Universal Plug and Play (UPnP, from Microsoft), Jini (Sun Microsystems), and HAVI (Sony, Philips, Hitachi, and others). The three are, of course, largely incompatible.
One advantage is that this software is not generally needed in SABOT-class devices. This has led to some confusion on the part of those for whom a browser is considered to be the killer application for all Internet appliances. Your typical browser-on-a-toaster does not need enhanced communications (beyond established TCP/IP protocols) to allow you to purchase books online.
Things get more interesting, though, when you look beyond the SABOT generation. In our labs we currently have a dishwasher, a clothes washer, and a refrigerator that pass status messages to each other and are able to convey detailed display warnings and status information to a SABOT-style device. This opens up a whole new set of possibilities for devices that can interact with each other intelligently.
Take, for example, the new class of digital video recorders that has just become available. These devices, from Tivo and Replay, are a major step forward in terms of allowing users to manage their own fixes of the television drug. They are also nowhere near the limits of what can ultimately be done.
Currently at least half of the hardware in these devices is dedicated to converting analog video signals to digital and back. If the input video signal could be IEEE-1394/Firewire/i.Link instead of NTSC, this additional complication and expenses could go away. Add command-level communications to this device and now all control can be generated by the television set itself. The digital video recorder then becomes a black box in the attic instead of yet another piece of equipment taking up space in the entertainment center and requiring an additional remote control. Add an Internet connection to the device and now programming information can be accessed from competitive carriers. In fact, the programs themselves could then be downloaded for later display. Who needs end-to-end full-speed display capability when the data can be dribbled to a local server during off hours?
Networking software suites are the key to allowing these kind of advances. The coordination of stand-alone devices is simply much too complex without them. Each of the software suites has the capability to allow devices to dynamically discover and utilize other devices on a network. This can be something as simple as a light switch controlling an arbitrary light or as complex as coordinating the hot water usage of a variety of appliances. The devices on the network must agree on how to communicate, and so far we don't have that agreement.
There are some good signs, though. I understand that all of the big players are talking to each other about how to have these devices interoperate. The problem is that while they are talking, people are out there attempting to build things that work, and they are not sure which horse to bet on.
Operating systems are in much the same situation. Many of the major players have announced an emphasis on Internet appliances, but none of them have all of the pieces in place to support the connectivity software to enable next-generation Internet appliances. The developer is left to guess which one will support the connectivity suite he or she wants to use.
Increasing complexity
Besides all of the aforementioned software, we have the application code itself. In some ways this will be developed just the same as it has been, but some changes will be made there as well. One major effect will be a weakening of the control that the application code typically exerts over an embedded system. One long-standing assumption of most embedded code is that the environment is static. In other words, no meddling user comes along and loads up software that messes up the operation of the rest of the system.
Internet appliances are going to force the opening of these computing black boxes in some scenarios. For example, the power of Jini is only realized when each connected system can run arbitrary Java code. This means that Jini-enabled embedded systems would have to be tested much more thoroughly to ensure that any problems in downloaded code will not compromise the original firmware. Other changes will revolve around selection of software such as UPnP, Jini, or HAVI. Each of these has a general design philosophy that will require specific background knowledge. UPnP requires some familiarity with XML, for example, while Jini presupposes familiarity with Java.
Application software will probably come more into its own with Internet appliances. My experience is that the application code tends to be bigger and more complex with Internet appliances than it is with many other embedded systems. This is more true of the non-SABOT applications than it is of the SABOTs, where the browser tends to be the application, or at least a major part of it.
The browser itself is also worth discussing. One common misconception is that embedded browsers have the same functionality as familiar PC browsers like Internet Explorer or Netscape Navigator. However, that's not the reality. PC browsers are designed around many assumptions that don't hold up in the embedded model?extensive amounts of memory and disk space, for example.
Some Web sites serving PC browsers can take advantage of assumptions about the PC architecture. Many of the common plug-ins may not be available for embedded architectures, making it difficult for these architectures to work on par with the PC-based versions. Add to that the fact that Web sites can be arbitrarily complex and it becomes difficult to even test the robustness of a web browser, much less prove that it is the equal of a PC-based one.
This is probably one of the biggest problems with the SABOT devices. The rate of change has slowed down somewhat as far as the basic PC browsers are concerned, but new add-ons are available all the time to extend them.
Communications
Internet appliances will not be successful unless a sufficient communication infrastructure is present to support them. The first generation of devices tend to include modem interfaces, but I believe those must disappear quickly. It is simply too expensive for consumers to dedicate a phone line to each new device. Someday people will look back at this communication method and marvel at our foolishness.
Some type of ubiquitous networking arrangement will almost certainly replace dedicated telephone lines. It may be some form of wired connection such as Ethernet or a wireless one based on 802.11 or Bluetooth. Other possibilities are IEEE-1394 and HomePNA. This connection will then be gated out onto the Internet through some kind of device, be it a set-top box, big-screen TV, cable modem, or some other place to hide a router. See Figure 1 for an example.
FIGURE 1: "Home" devices all connecting to the Internet through a single "home gateway" device.
This transition has to happen for Internet appliances to succeed. In my experience, at least half of the architectural and user interface issues in various Internet appliances have revolved around the modem connection. The requirements of the ideal communication medium are simple. It needs to be ubiquitous, brain-dead easy to use, and cost nothing. It would also be nice if it had zero latency and multimegabit-per-second bandwidth.
The reality is that this will be one of the most difficult choices. Most first generation devices are not based on modem connections because their makers particularly like analog POTS (plain old telephone service), but that is the only thing they can absolutely depend on being available.
Of course, customers will be demanding a better solution right away. Consequently, we'll have to make educated guesses about where the market is going. I can say that if you assume a wired connection right now it would be difficult to find a better one than 10baseT Ethernet. It's commonly used for the consumer side of cable modems, and most of the DSL facilities can be wrangled into that medium as well. The only thing going against it at the moment is that most homes don't have the wiring in the walls to support it.
This criticality also holds true for wide-area communications. I was in the Netherlands last fall and took some time to do a little shopping. I was floored by a display I saw in a consumer electronics store of PCS cell phones matched with PDAs. They communicated with each other via IrDA and provided a wide-area Internet capability that was ideal for traveling on a train. The universal acceptance of the GSM protocol has given Europe a significant lead in developing cellular-based data services and they are taking full advantage of it.
One advantage of this for the U.S. is that it gives us a chance to study a market that is ahead of ours to learn from their mistakes and successes. I believe, for example, that a roaming Internet connection via a PCS phone is a tremendous model, one that is much stronger than the simplistic SABOT solution of putting the browser directly into the cell phone. The connection to arbitrary devices can be accomplished via a Bluetooth connection, offering a bubble of connectivity that follows the user around and is associated with them. Ericsson has picked up on this model and is rapidly bringing it to life. I suspect others are doing it the same.
Exciting times await us
This is an exciting time. Many promises have been made over the last year or so, and our industry is now scrambling to fulfill them. This means that we are due for our share of stresses, headaches, and failures, but we also will begin to gain the place in the sun that embedded developers have lacked for so many years.
What makes this really exciting, though, is the mismatch of expectations and realities. The industry press is talking about Internet appliances as if they were waiting in a warehouse ready to be shipped next week. The reality, of course, is that they primarily exist in the imaginations of the entrepreneurs.
Larry Mittag is head of the Embedded Systems Division of Stellcom Inc. He has also been a contributing editor of Embedded Systems Programming longer than anyone can remember. He can be reached at lmittag@stellcom.com. |
