My third book is released! Learn what you'll need to know in order to become an embedded engineer.
Check out my second book; learn practical stuff about building robots and control systems around Linux PCs and the Atmel AVR.
My first book gives you all the intro you need on developing 32-bit embedded systems on a hobbyist budget.
Designing for Common Sense
If, like me, you ever rashly checked a "management" or "IT" box on a reply mailer card, you doubtless receive several unsolicited publications aimed at middle and upper management, and designed to flagellate that group into buying into specific (advertiser-sponsored) technology buzzwords. If you ever leaf through these publications before using them to line your ferret's cage, you will have seen much mention of "pervasive computing", which is a buzzword in some favor at the present. The term is used to describe systems for interconnecting miscellaneous small embedded systems, mostly consumer appliances (air conditioners, TV sets, refrigerators and so on), especially where such interconnection is over or accessible via the Internet.
The interesting thing about this particular buzzword is that in all probability its coffin will eventually be nailed shut by precisely the same people who are currently promoting it; i.e. the bean-counters. At the moment, the bean-counters are happy to ride the free publicity that goes with being able to say "We are a member of the XYZ Protocol Forum, showcased at [major trade show]". However, there will someday be a need to pay the piper by implementing real products based on these protocols, and the purpose of this essay is to illustrate in a small way how this need will pass down from sales and management to engineering, be implemented, and then bounce back up to sales and management, who will then reject it on profitability or other grounds.
The first thing to point out is that "pervasive computing" truly arrived in our lives a very long time ago. Almost every appliance already contains a microcontroller of some caliber. So the drive towards pervasive computing would be better described as a drive towards standardized control networking. Although I have most intimate experience with Microsoft's Universal Plug'N'Play protocol (UPnP), being a forum member, the rest of this essay is almost or entirely applicable to UPnP's competitors also (Jini most certainly; possibly also HAVi et al), so I will hereafter refer to all such protocols as "SCNs".
The sophism most frequently employed by the proponents of SCNs is that the price of networkable microcontrollers is decreasing so rapidly that the costs of adding network connectivity can be absorbed and made invisible to the consumer. The biggest problem with this reasoning is that most consumer electronics are highly commoditized with ever-shrinking profit margins and, furthermore, new models have a very short product life cycle. Products such as VCRs and television sets are often superseded before they even reach their destination port. Any reduction in parts cost must therefore seized by the manufacturer to provide a modicum of protection against bloodthirsty price competition in the consumer electronics market.
(It should also be pointed out also the current horror story that is the semiconductor market has prices diving artificially as manufacturers seek to recover some proportion of sunk inventory and development costs. 2001 has seen major component manufacturers visit even small companies like the one I work for, essentially begging us to design in their silicon and offering to undercut any competitor. Many products in development have been cancelled, and all manufacturers are "rationalizing" their efforts at this time; it is prudent to believe that all these products being pulled out of the pipeline now will result in severe shortages of new devices 12-24 months from now, and hence pricing that is unpredictable at best, gouging at worst).
In short: For SCNs to be successful, it must be demonstrated to the average consumer that the SCN functionality adds value that justifies a higher cost. Although it?s a cliché, it really does help to remember how many VCRs there are in America that blink "--:--" because the owner doesn?t know how or doesn't care to set the time. Certain appliances such as the TV, VCR, refrigerator, oven, CD player and so on have a basic use that has been assimilated completely into the daily lifestyle. The consumer needs the device to provide essentially one function - displaying a TV picture, playing videotapes, keeping food cool, and so on. Products that fulfil a basic need like this are differentiated by price and by how well they perform that single basic function (e.g. the size of a TV screen, the capacity of a refrigerator, or the heat-exchange capability of an air conditioner). Peripherally related features are much harder to sell. As anyone who has worked a trade show floor will know, if you need to explain to someone why he needs something, he probably isn't going to walk away feeling he needs the feature and has to buy it. To put this another way: Consumers are simple creatures with mainly simple needs, and the ebb and flow of consumer-on-the-street interest in specific functionality is a massive phenomenon that is hard to divert. Home automation technologies have been available for a very long time, and their penetration is infinitesimal. The message I glean from this is that most consumers do not want to control their lawnmower from a touch screen on the front of their refrigerator, but others appear to disagree with me on this.
From the technical perspective, SCN design and implementation is made much harder by the fact that the particular software corporation in charge of each major protocol is trying to arrange matters so that implementing their particular SCN flavor leans appliance manufacturers towards other technologies promoted by that particular software corporation. For instance, Sun is pushing embedded Java. Microsoft is trying to push .NET and licenses for Windows CE, and is making vigorous efforts to ensure that UPnP promotes the use of the PC as the central component of the household SCN. (In a piece of traditional doublethink, this goal is simultaneously acknowledged and repudiated by Microsoft. All the design documents you'll ever get to read talk about gloriously OS-agnostic protocols). Worse, the SCN is steered so that it does not compete with other products from the controlling software corporation. This sometimes results in bizarre hoop-jumping in the SCN design, to avoid the possibility that (for instance) a cheap device intended to serve MP3 content and graphics files to stereo systems and digital picture frames around your house might replace the functionality of an expensive server operating system.
A related issue that I have never seen addressed adequately is the apparent contradiction between the stated goal of SCNs (to allow universal interconnectivity without the need for an intermediary PC) and the fact that many of the appliances in question are physically incapable of connecting to any but a limited range of other devices. Unless a physical interface standard is developed, it's a simple fact that universal appliance interconnectivity will require a universal gateway device of some kind, capable of joining RS-232C, USB, IEEE-1394, Ethernet, 802.11b, Bluetooth, IrDA, HomePNA, HomeRF, and dozens of other technologies. The single device that already has many of these technologies (and also the device where most users will be familiar with manipulating data) is the home PC. So the idea that SCNs will remove the PC as a data conduit doesn't seem very rational (not that it was ever really anyone?s goal, of course - especially not Microsoft's. It just sounds good to say "We're eliminating the need for a PC and allowing any device to talk to any other device directly" without getting down into the details of how that does - or doesn't - work).
Of course, individual appliance manufacturers are also trying to push their own agendas. This has the very undesirable side-effect of muddying the simplest usage scenarios with manufacturer-specific issues. Manufacturers are understandably anxious to ensure that the money they're spending on this technology will enable them to showcase entire systems built of their own appliances, without referring to vague nebulous products from other companies. Unfortunately, in the process, the baseline standard is further complicated by these manufacturers' need to support specific types of communications between specific combinations of appliances.
The already unsteady apple cart is completely upset by the last major remaining group of players in the SCN design forums, who are best characterized as the intellectual zealots. These players fall mostly into two categories: small productless companies that see a market for ready-rolled SCN IP and consultancy services, and theoreticists from mega-corporations such as Intel and IBM, with titles similar to "Designer In Charge Of Ideas That Sound Really Good In Press Releases But Which Can't Be Made Into Economical Products". The former group obviously stands to profit from making SCN implementation so complicated that specialists are needed for the job, though it is doubtful that they are consciously pursuing that aim. These people can be recognized at SCN forum meetings by the way they vigorously encourage every weird scenario proposal, while never actually delivering anything concrete in the way of code or products.
The second group, which is much more dangerous, consists of people who would probably see intrinsic value in paying $50 extra for a TV set that can talk over TCP/IP to a security camera in Sri Lanka (even if the security camera isn't designed yet) using a video compression format that hasn't been finalized yet and might not even be released due to patent issues. That might sound silly, but if you think so, you've never sat through an SCN forum conference. It's agitation from this sector that is mostly responsible for decisions such as basing an embedded communications protocol around XML. (By the way, don't get me wrong. XML is great in the applications for which it was designed - exchanging transactional data amongst heterogeneous business systems. However, it's terribly byte-inefficient and adds nothing except implementation complexity to what should be a simple protocol for communication amongst embedded systems). People in this group are responsible for prolific generation of documents describing exceedingly complex standards that solve nonexistent problems. In their quest for the holy grail of a standard that can cover all current and future possible ideas, they neglect two points:
An extremely unpleasant phenomenon has emerged as a combination of the zealots' efforts and the software corporations' market protection efforts (with possibly a dash of marketing's "let's be buzzword-compliant" influence thrown in). This is the trend to reinvent proprietary wheels where perfectly adequate, well-understood protocols exist already. The Transport service in UPnP is a perfect example of this. UPnP - and other such protocols - have been advertised as discovery protocols. A discovery protocol should allow a networked device to enumerate the other appliances within the scope of the network, and it should provide a standardized way to query the capabilities of those appliances - and at that point, the discovery protocol should bow out and let the two devices talk using whatever system they find convenient. The aim of the discovery protocol should be to perform the bare minimum required to allow two appliances to find each other and agree on a communications method. This design criterion has a number of desirable effects, including:
In an attempt to provide an intellectually satisfying solution to various problems, such as content searching, that could quite reasonably have been solved with simple extensions to standard protocols, such as an index file on the abovementioned FTP server, UPnP in particular has reinvented a lot of wheels and completely lost any hope that UPnP appliances could retain simple compatibility with non-UPnP systems. (I am currently writing a white paper describing some of the attributes of an ideal SCN. This issue features very prominently in my paper).
IBM has a large technology demonstration room in their Austin, TX Executive Briefing Center, which I was lucky enough to visit early this year, and which illustrates very nicely the results of zealots let loose with a large budget. The room showcases some of the pervasive computing technologies that IBM has developed primarily for their "gee, wow" value. As a confirmed geek, and avid consumer of electronic gadgets, I found some of the devices in that demo most interesting. As an engineer for a company that expects to make a profit on its products, I found myself repeatedly shaking my head in disbelief. In order to sit in my living room and send MP3s from the Internet to my car using an Internet-enabled TV set and a Coke vending machine that acts as a wireless Internet relay point, I don't just need $100,000 worth of custom-built hardware - I also need to make a radical change in the way I perceive the underlying technology. The average consumer is not sophisticated enough to work with networks this complex, let alone troubleshoot them. The average consumer is more than happy to put a CD (or, if you insist, a flash card loaded with MP3s) into his briefcase so he can listen to specific music as he drives to work, and let us not forget that it is the average consumer who is mostly buying our products and ultimately writing our paychecks.
Your mileage may vary, but in my experience of analyzing technical support information and end-user feedback, most people are incapable of analyzing the causal relationships in a system containing more than two or at most three components. Trying to explain to such a person that he must use device A (an SCN remote control device) to tell device B (an SCN DVD player) to fetch content from device C (an SCN storage device) and play it on device D (an SCN TV set) is futile, and furthermore the user will not usually be able to decide correctly, in the event of a malfunction, which component is the culprit.
From an end-user standpoint, SCNs also have serious security implications. Let's look at some of the goals of a typical SCN design:
A very simple security rule is that if you don't allow information traffic, you don't have any complicated interaction models to scrutinize for holes. The more traffic you generate, the more holes you open and the more information you risk exposing to outsiders, and SCNs generate a huge amount of traffic. The privacy issues alone here are enormous. There is a huge amount of information in your daily life which has a cash value to marketers, but which they currently have no easy means to capture. For instance, the settings on which you run your air conditioner might be of interest to companies that want to sell you insulation. The CDs and DVD titles you play are of interest to companies like Amazon, who can try to infer from your listening and viewing tastes what other media you might care to buy. And of course, the cable channels you watch and the amount of channel-surfing you do are of great interest to the cable company. (They'd also be interested to know which shows you watch live, and which shows you tape, since only live viewing counts for ratings and hence advertising rates. And they'd also like to know if you have a DSS dish, and what channels you watch on DSS). All this information could easily be captured and transmitted using UPnP, and presumably the other SCN technologies also.
That's not even counting the possibility of malicious attacks on the household network. When cable Internet access was first introduced in the corner of Australia from which I hail, it was the source of a huge debacle: everyone who signed up could see the shared hard drives of every other user in their local cable segment, and could steal and/or modify the data contents of other users' home PCs. Connecting entire households full of equipment to the Internet is a much more dangerous such accident poised to happen, especially if SCN technology is introduced silently in devices such as Internet access gateway devices. As broadband uptake increases, more people will be buying simple routers that might well include such functionality. The more remote-controllable appliances they add, the more things an attacker can do to that household over the Internet, with complete anonymity. At the very least, SCN functionality should ship disabled on such appliances, so that consumers are not obliged to work out how to change default passwords and so on, and so that they can simply plug in the appliance and work with it at maximum safety.
Most people reading this essay probably already had conclusions before the end of the second paragraph, but for the sake of neatness, I will summarize mine for you:
From all of the above, I derive the opinion that SCNs are of interest only as a technology demonstration for the foreseeable future. Large corporations might be interested in designing a flagship model (for promotional purposes) that is SCN-capable, but it is unlikely that there will be significant consumer penetration until a compelling application appears. So the best posture, especially for a small company that doesn?t want to waste engineering resources on vaporware technologies, is to wait-and-see, smile sweetly at all the SCN controlling bodies, and promise them much while delivering little. It is unlikely that a winner will emerge before at least a couple of years have passed, and by that time there may well be free, open-source, easily adaptable IP for the popular protocol(s).
-- Lewin A.R.W. Edwards (firstname.lastname@example.org)
July 22, 2001