The challenges facing engineers doing embedded Internet product development include selecting which communications infrastructure will become ubiquitous and building devices that use that architecture to their best advantage.

I am sitting in my den at home typing this article on a device that has full access to the research capabilities of the Internet. I am also listening to music I got from the same source. There is no longer any debate about whether or not the Internet is going to touch every corner of our lives. It already has. The debate is over the extent to which those changes will affect us as the technology improves.

The 'Net's omnipresence comes about from the capability to connect a PC to the Internet—the current state of the art, as far as home interconnectivity is concerned. This setup is definitely an example of first-generation communications, where the exciting part is that you can talk at all. It is the equivalent of owning a single telephone that occupies a place of honor and respect in your home. After a while, the kids start complaining about how they need one in their room because they can use it to work on their homework (“Really, I promise that's what I'll do with it!").

The suspect reliability of this promise is just another indicator of the effect that ubiquitous communications have already had. The computer will just as likely be used to communicate with old friends down the block as it will to play games online with new friends around the world. Online communication has become a new fixture in our environment, and we find new uses for it every day.

But what if that communication medium travels to every corner of the house? What if it spreads throughout the office as well? What if every computer embedded in the devices in our home and office could communicate as easily and transparently as our desktop computers can today?

Front-door (Level 1) communications
To predict the future, we need to understand where we are today. Conceptually, we have communications to the "front door," the personal computer. This means we have either a phone-line connection or a cable modem connection that is hard-wired to the same machine we use to do the family finances and to blast aliens. We can use that connection to peruse the Web, send e-mail, or catch the latest update on the stock market.

This level of communications has some opportunities for embedded systems, as long as they can be used in conjunction with the PC. The assumption is that the PC can be used to establish communications over the Internet with a content provider of some kind and will relay that content to a device attached in turn to the PC. This model of operation is shown in Figure 1 .

What are the characteristics of this class of device? Because the class actually exists, finding examples of it "in the wild," so to speak, is easy. From these examples we can explore the capabilities and limitations of Level 1 devices.

Rio. One example of this is the Rio from Diamond ( www.diamondmm.com ), a device used to store and play back MPEG Layer 3 (MP3) audio files. These files can be obtained from a number of sources on the Internet, as well as from local sources like CDs inserted into the PC. This device is the equivalent of a portable tape or CD player, but the content is inserted into it as a data stream rather than a physical storage device. It is the first of such devices to totally divorce the intellectual property of the music from the carrier medium. You don't buy a CD or record or tape, you buy the song itself.

Pfaff Model 7570 Sewing Machine. Sewing has also gone high-tech. These days, sewing machine manufacturers have borrowed heavily from the robots on the factory floor, allowing them to preprogram complex sequences of operations. These sequences can then be repeated flawlessly any number of times. The Internet allows these patterns to be distributed worldwide. My wife has already filled a couple of CDs with a variety of patterns for monograms and fonts.

Analysis . What do these devices have in common? The most immediate characteristic is their dependence on a central PC resource, preferably one that is connected to the Internet. They both act as part-time peripherals to this PC. They aren't dependent on it for operation, but they are dependent on it for the content with which they operate.

The advantage to this dependence, as far as the embedded system is concerned, is that difficult operations can be performed on the general-purpose PC instead of the embedded device. The process of designing a sewing pattern is extremely user-interface intensive. If this user interface had to be built into the sewing machine, the cost of that machine would skyrocket. Likewise, the MP3 audio compression is extremely CPU-intensive. On the Rio device, the encoding takes place on a desktop computer that isn't part of the Rio itself. This allows the Rio to have much lower requirements for CPU and memory use. It is essentially just a storage and playback device.

Most devices of this class benefit similarly from the PC. Interestingly enough, this means that they are at least one level removed from the Internet. As a result, it is difficult for them to count on being able to communicate directly with a content provider. Because of this I have difficulty thinking of these devices as being truly in the class of embedded Internet devices, even though their usefulness would be much diminished without it.

Major appliance (Level 2) communications
The first embedded devices to be directly dependent on the Internet will undoubtedly be major (and some relatively minor) appliances. In a sense, these appliances are the path for penetration of truly ubiquitous communications into our homes and workplaces.

The obvious member of this set will revolve around the set-top box or more directly, in a digital television. The problem with this application of embedded devices to the Internet is that it essentially duplicates functionality we already have in the PC. If I already have a PC, I'm not going to be all that interested in WebTV.

These devices get interesting when I can do things I couldn't do before, or when I can do something much more easily than I can now. Give me the capability to program my VCR at home from my desk at work, for example. Or let me tell my VCR that I want to record Buffy the Vampire Slayer , rather than telling it to turn on at 8 p.m. on Tuesday nights and off an hour later. Or was that 9 p.m.?

Some devices in this class are emerging already. The company I work for has designed two such devices that I will now describe.

CMI Advantage 2000. This is essentially a small television set that has a video CD player and the capability to connect via a telephone line to the Internet. The interesting thing about it is that it's primarily a device that teaches the user how to cook. A series of CDs contains static lessons on specific dishes or techniques. The Internet connection makes new content continuously available at the other end of the connection. It also means that the user is directly connected to the content provider.

The hardware inside this box is very different from that of a normal small TV set. It includes a 32-bit RISC CPU, 8MB of flash, and 16MB of RAM. The digital video is mixed with the NTSC signal using a sophisticated video processor from IGS.

This hardware is necessary to support the Web browser and the TCP/IP stack that allow it to act as a functioning entity on the Internet. The device doesn't depend on a home PC or anything else locally besides a phone line. Figure 2 shows a block diagram of the system.

Total Control Products QuickPanel. This is in many ways a familiar embedded device. It's a box that communicates with, and provides a user interface for, a variety of programmable-logic controllers (PLCs). It is normally used in a factory floor environment, although it has also been used in the control system of a certain prominent computer executive in Redmond.

A 10baseT Ethernet connector in this case provides the network connectivity. This connectivity allows the customer to either limit the communications to a private Intranet or to allow the device to be a full citizen on the Internet. It can be used to host a Web server on the device to make local information available to management, or to allow the resources controlled by the device to be retasked from a central source.

The computer hardware inside this system is similar to that of the previous one, although the software platform is quite different. The system diagram is shown in Figure 3 .

Analysis . The most obvious difference between this generation of devices and the previous one is that they have the capability to communicate directly on the Internet in the absence of a PC. The computational resources of the device are therefore much more extensive, and they can do things the previous ones could not. These generally involve direct continuous communications, rather than the store-and-forward designs of the previous generation.

The conceptual implications of this level are much more interesting. These devices each have stand-alone capabilities separate from just being platforms for Web browsers. The connectivity aspects of the devices enhance those capabilities. It's the difference between using the phone line to call someone across the country just because you can and a company using the telephone to conduct business around the world. Simply marveling that we can communicate is no longer enough, it's now time to put that capability to work to enhance our lives.

Some false starts are bound to occur at this primary stage of development. Does it really make sense to talk to your automatic dishwasher while you're on vacation in Hawaii? Do we really want to be able to order groceries from inside the refrigerator door? How much will consumers pay for these or other capabilities? How hard do we have to work to make sure that only the appropriate people are doing the accessing? How much effort do we have to put into making sure that Junior doesn't access Web sites from the refrigerator that will melt the butter?

This is an important time for Level 2 devices. So far, the "geek factor" has driven development of the technologies that enable these devices to be created. The question is whether there is enough innate worth to create mass markets for consumption of devices based on that technology.

Assumed (Level 3) communications
This level is where things get really interesting. Imagine the possibilities if every device that had power also had communications. Every clock in your house would read exactly the same time, and that time would be correct. Each light switch would be able to control any light, even if that light were across the country. The hot-water heater could coordinate usage between the washing machine, the dishwasher, and the bathroom to avoid those chilling surprises we sometimes get.

These examples are what I refer to as assumed communications . Right now we have assumed power. I can build a device without having to worry about setting up a power link to the closest hydroelectric dam or nuclear power plant. I also don't have to worry about adapting to the protocols used by the PSP (power service provider). The instructions to the user for getting power to a device consist of:

1. Find a wall socket

2. Stick the plug into it

This model should eventually be followed for communications. The current state of TCP/IP is certainly an improvement over previous incarnations. DHCP allows for much easier setups at the IP level. Unfortunately, things get complex pretty quickly above that. How is Grandma going to deal with assigning domain names to her pretty new lamp?

Jini model . Some efforts are now underway to try to reach this level of simplicity and usefulness. The one with the best press agent so far is Sun's Jini initiative, but Microsoft has already announced that they are working on a competing technology. Jini represents some of the most interesting thinking along the lines of the general case for third-generation embedded Internet appliances. Figure 4

"General case" is the operative phrase. The Jini architecture is an abstracted analysis of the problem of small systems providing and using services in a networked environment. Sun opted for a primarily centralized service, which solves many of the hookup problems inherent in a distributed architecture.

An example of this is a simple wall switch. This kind of device is normally used to control a light, but it can also be used to switch on a ceiling fan or an air conditioner. The decision as to what the switch controls is currently made by the electrician (via how the wiring in the house is hard-coded). This very definitive form of early binding is rather difficult for the user to change at a later date without risk to life and limb.

The software abstraction of the light switch is a two-state input device. A fully programmable system would allow any number of devices to react to that input device, either in serial or in a programmed sequence. Flipping a light switch in a software-defined architecture could cause the light to come on at half-intensity, the fireplace to light, the stereo to come on tuned to the local classical music station, and the doggy door to open so that Fido can fetch your slippers (the robotic Fido will be an option next year).

This is the power of a software-defined system. It can be customized to the specific needs or desires of the user on an individual basis. This power is what Jini is all about. It abstracts services and control devices so that they can be configured and programmed by the user in a very late binding operation. The generic architecture of a Jini system is shown in Figure 4.

The key to this power is how it is programmed. The VCR is ample evidence that we cannot simply assume that the customer base will be able to adapt to the user interface provided. Every VCR that is flashing "12:00," or every tape that contains an hour of the Home Shopping Network instead of the final episode of Seinfeld , is a testimonial to the fact that many consumers cannot program.

The Jini's answer to this is to provide a central computing resource that matches up the service providers with the service requestors. This also neatly allows a good deal of the computing overhead of the system to be paid for once by the user, instead of forcing each of those light switches to have a keyboard and a monitor. This central controller acts as a services broker, storing information on each service provider device that plugs into the network and passing the interface information to devices that request those services. In fact, the Level 2 devices described previously could also be used as this central resource.

This approach still has some thorny problems. How do you explain to Grandpa that unplugging the TV in the kitchen makes the light switches stop working because that TV is the house's central controller? Also, the programming problem has been centralized, but it hasn't been solved. There are plenty of opportunities for the user interface on that central controller to be at least as user-unfriendly as that of many VCRs.

Bluetooth . One of the other problems with Jini is that it is so highly abstracted. Its creators just assume that there will be some hardware that connects all of these devices together and allows them to communicate. This frame of mind is necessary because it enables the manufacturers to solve a different set of problems; but it does assume that someone else will create that hardware.

Bluetooth is one hardware yin to that software yang. It is a specification for wireless communications that allows devices to create ad hoc network connections based on the fact that they are relatively close to each other. This solution has the huge advantage that no one will have to figure out how to plug in the device. It will join the network simply by being present in the same room.

In many respects Bluetooth is much simpler than Jini. But complex protocol issues remain: retransmission of flawed communications, identification of devices and the services provided by those devices, and security. But the advantage of hardware is that it simply has to provide a path to communicate. Bluetooth's developers have concentrated on the problems of cheap, wireless communications that can become a true "Ether" net.

Analysis . This section is definitely the fuzziest, as far-future examinations tend to be. What's amazing is that the definition of far-future in this case is within the next five years. The frameworks I've described in this section, though cutting edge, are still examples of technology in its infancy. Just when it seems devices like these will be on sale next week at K-Mart, we run into the inevitable last-minute road block.

Such is the nature of emerging technologies. Sun has put a lot of good academic analysis into Jini, but someone has to make the technology practical before it will go anywhere. Java's situation was very similar; the original Java VM worked, but it wasn't ready for prime time. Third-party implementations of Java that may be useful in the real world are only now starting to appear. This process must also take place on the Jini architecture before we will be able to really take advantage of the ideas inherent in it. Some of these implementations will provoke horror in the minds of academicians, but the products will sell.

The underlying communications technology is a different matter. Software has the advantage in that it can be deployed quickly, but hardware has to be manufactured and designed into systems before it can be used. Product designers must therefore make relatively long-range bets regarding the viability and popularity of communications interfaces such as Bluetooth. What if it works great in the labs but not in the field? What if it causes cancer?

That is why the communications infrastructure is the limiting factor on third-generation Internet embedded devices. This infrastructure must be in place before the devices will be useful, but the devices must prove they are useful before anyone will invest in creating the infrastructure.

Technological staples
The next few years promise to be an exciting time for embedded systems. The assumption that all Internet activity takes place by a user sitting in front of a general-purpose PC has already been challenged, and I suspect that it will soon crumble entirely. The engineering challenge with which we'll be presented involves selecting which communications infrastructure will become ubiquitous and building practical devices that utilize that architecture to best advantage.

The key to meeting this challenge is to create devices that will be useful to the common consumer. Some of them will be the same ones we technogeeks think are useful, but they must be created in such a way that they can be used without having to instantiate a new user class or use a soldering iron.

The overriding question we must answer is whether or not people want this stuff. The same question was asked about telephones, personal computers, and the Internet. I believe the answer will eventually be as self-evident for embedded Internet devices as it is now for these current technological staples.

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 .

Illustrations

Figure 1 Figure 2 Figure 3 Figure 4

Return to Table of Contents