There is something spooky about having a premonition and then watching it materialize. I have known, for at least a year, that Internet-based embedded devices were the next steps in the logical progression of the computing world. Industry analysts have been saying the same thing, causing venture capitalists to be very visible on the floor of the last Embedded Systems Conference. And, the desktop computing community seemed to have finally figured it out at the recent COMDEX.
In all
fairness that really isn’t true. Most of the major PC manufacturers have been working for a while to develop devices for the so-called “post-PC era.” Some members of the PC press have realized that something is going on as well. But COMDEX nicely highlighted the dual facts that the PC world was suffering from a bout of stagnancy, and that there was a tidal wave of smart, connected devices on the horizon.
Oddly enough, these devices have been characterized more by what they aren’t than
by what they are. They are definitely not computers, which is to say they are not PCs. It’s fascinating that in a little over a decade, the PC has gone from a toy to the popular definition of a computer. Embedded devices are at the beginning of a similar trail, but they are not destined to become computers. Rather, they will redefine any number of standalone devices.
This will only happen if they can take advantage of ubiquitous communications. There must be a common language among all
devices, a way for them to interact in ways that we cannot imagine today. This is not marketing doublespeak or Far-Eastern mysticism, but simply a statement of fact. The only way to enable revolutionary advances is to build an infrastructure that supports general cases. Once this infrastructure is in place, people will come up with ingenious uses for it that will go far beyond the imaginations of the infrastructure’s creators. I cannot think of a single useful reason to enable communications between a
dishwasher and a VCR, but somewhere out there someone has an idea that needs that capability. This is what Internet appliances are all about.
The key to this capability is a communication infrastructure that will allow devices to interact freely. Obviously, this infrastructure must be built on a hardware framework, and it must also be isolated from that framework at the application software level. This is the goal of an emerging class of interface software. This software has been created to enable
communications between Internet devices. There are currently three sets of this software that are in various stages of development. The most mature of these is Jini from Sun Microsystems. Microsoft is in the process of defining a set of interface standards dubbed “Universal Plug and Play.” Finally, a considerable consortium of consumer electronics firms have come together to back a specification named HAVI.
I have been reading a fair amount of press about these interface specifications. A
good deal of it is simply incorrect. I would like to dedicate this and the next two columns to explaining some details about each of these standards in an attempt to bring some light to the ongoing discussions. I will add some humble opinions to each as well, but feel free to agree, disagree, or ignore these as you wish.
The first interface to be discussed is the Home Audio-Video Interface specification (HAVI). This standard is backed by a relatively small number of sponsors, but they are the
“Who’s Who” of the consumer electronics world. This list includes Sony, Matsushitu, Philips, and just about everyone else whose name is on a TV set or VCR. This is obviously an important group, since they control the development and manufacturing of most of the electronics in the world.
Many of these companies have already tried the proprietary route as far as device command and control is concerned. Nothing exemplifies the results of this fiasco better than the concept for an infrared
remote control. These remote controls do pretty much the same thing for every device, but they do it using dfferent coding for each. For example, the ‘On’ button for a Sony TV sends a different code than the ‘On’ button for a Sylvania or a Philips device. The fact that so-called universal remotes exist at all is a pain, and the fact that each of them requires a booklet of device codes is just plain stupid.
The HAVI standard is an attempt to fix this lack of interoperability as
much as it is a way of taking consumer electronics to the next level. It defines the functionality of devices such as television sets, VCRs, and stereo systems in terms of a network command interface. This means that a VCR will be able to set the channel on a cable set-top box, for example, instead of the user having to coordinate multiple device timers or to set up the devices ahead of time. It should be possible to have a truly universal remote control that requires little or no user setup to use. This
capability alone makes HAVI worth consideration, but there is a lot more where that came from.
The next level in HAVI comes from the capability to manage streams of digital audio/video data. This means that the signal from the cable box can be routed to digital storage on a next-generation VCR with no loss of signal integrity. It can then be played back as a complete data set, rather than as a free-form stream of analog data. In other words, a recorded program will exist as a file rather than as a
stream of data. These files can be routed over shared network connections, rather than requiring dedicated wiring links as is often the case for contemporary home setups.
The final advance for HAVI is the integration of audio and video streams with the digital data from the Internet. It will finally be a no-brainer to surf the Web from a television set, rather than the complex analog and digital integration necessary for devices such as WebTV to work. Conversely, it should be just as simple to watch
a television signal in a window on a desktop PC.
This is the good news. There are, however, some concerns I have about the HAVI specification. I had the oddest sense of déjà vu when I was reading it. It reminded me of the communication protocols I used to design during the mid-1980s when I worked in the defense industry. At the time, I was designing large, complex systems and the communication systems that allowed them to operate. The dominant criteria at the time was efficiency, and it
was not particularly important if the general case of a problem was addressed. However, it was important that the specific system communicated consistently and efficiently. As a result, we built communication protocols on a set of shared assumptions between the sender and the receiver. These assumptions were codified into the data in a very strict, compact binary form. There was a set of message types defined, and each type had a strict, albeit variant format.
This is the form of the messages
defined in the HAVI specification. The behavior of a device is characterized by a set of well-defined messages. A television set has one set of capabilities, while a VCR has another. Each device has a category and is expected to fill it.
The problem with this technique is that the control codes are built around the controls for the devices as they exist today, with little or no room for expandability. This is a limitation that will not be a problem initially, but over time newer systems will fall prey
to the inertia of legacy expectations. A digital VCR that is based on a hard drive rather than tape will be forced to either emulate a legacy VCR or to define a whole new class. New categories of devices could conceivably break the whole control paradigm.
The same kind of thinking has also constrained the network architecture. There is a statement of good intentions at the beginning of the specification which states that it is independent of the network interface, although all of the examples are
given in terms of an IEEE 1394 (nee i.link) bus. Unfortunately, there are some specific sequences that heavily depend on the special characteristics of IEEE 1394. Specifically, device discovery is triggered automatically by connection or disconnection of a device. IEEE 1394 has the capability to detect that occurance, since each such event will trigger a bus reset. How exactly could that be done with, for example, Ethernet?
Even with these misgivings I applaud the ideas behind HAVI. Just as
computers were forced away from proprietary architectures by the need to interoperate, consumer devices must follow the same path. There will be problems with integrating particular devices, and eventually something will come along that will require rethinking the whole thing, but I, for one, am looking forward to the next generation.
On the other hand, there are a couple of much more general- case protocols that we have not yet examined. Next month, I will take a look at Microsoft’s entry,
Universal Plug and Play. After that we will examine the granddaddy of all of these protocols, Jini.
Puzzled by a network processing design issue?
