Archive for September, 2001

Safety Patrol

Thursday, September 20th, 2001 Michael Barr

When I was in the sixth grade, I was a member of my school’s Safety Patrol. It was my responsibility to ensure that younger children got on and off the school bus safely. “Safeties” wear bright orange sashes and help other kids cross streets adjacent to their bus stops. This is just one measure in a complex web of overlapping steps taken to protect the most vulnerable members of our communities.

As children and adults alike increasingly place their lives in the hands of computer hardware and software, we need to add layers of safety there as well. No software bug or hardware glitch (or combination) can ever be allowed to bring down an aircraft, whether there are hundreds of passengers on board or just a pilot. The failure of many other systems must be similarly prevented. But software and hardware do fail—perhaps inevitably. As engineers, we use system partitioning, redundancy, protection mechanisms, and other techniques to contain and work around failures when they do occur.
As software’s role in safety-critical systems continues to expand, I expect we’ll see a rapid increase in the number of civil lawsuits filed against companies that design and manufacture embedded systems. (Adding several new levels of meaning to the phrase project post mortem.) Indeed, there is anecdotal evidence that lawsuits of this sort may already be on the rise. With most of the action in hush-hush settlements outside the courtroom, though, the media hasn’t yet noticed the trend.
One organization that has definitely taken notice of the hazards posed by software in products is Underwriter’s Laboratories. An independent, not-for-profit product safety certification and ANSI-accredited standards organization, UL initiated a “Standard for Software in Programmable Components” in 1994. The resulting ANSI/UL-1998 standard addresses “the detailed safety-related characteristics of specific software in a product.”
In addition to focusing on top down design and development processes, it may also be beneficial to utilize an operating system that’s been designed with safety-critical systems in mind. Above all else, an RTOS should not compromise the stability of the system. However, an operating system can go beyond and do many things to reduce the risks inherent in your application code. Keeping software tasks from overwriting each other’s data and stacks is merely the beginning of the matter.
In your rush to select an RTOS for use in a mission critical system or life-critical medical device, do make sure you know what you’re getting, though. It turns out that one prominent new operating system marketed specifically for inclusion in products of these sorts has a potentially dangerous hole in its “innovative” protection mechanism. You don’t want to wind up on the wrong side of something like that in court.
Ultimately, the key to designing safety-critical systems is to include multiple layers of protection. The hardware, the operating system, and your application software must each do everything they can to prevent catastrophe—even if the fault itself lies outside that subsystem.

First, Do No Harm

Monday, September 17th, 2001 Michael Barr

Many of the folks I hang around with own digital watches. I have one myself. In addition to keeping fairly accurate time, mine features a stopwatch, a countdown timer, and a set of five alarms. A friend has a different watch from the same company—one that features a digital compass. To take a compass reading, you stand still, hold the watch level, press the “Compass” button, and read a cardinal point (N, NNE, NE, ENE, E, etc.) and angle in degrees. The reading tells you where the top of the watch is currently pointing.

Multi-function devices like these aren’t unique. Lots of products have multiple features. Today’s buzzword for this phenomenon is “convergence.” Staying only with the watch theme for a minute, there are GPS watches, watches with digital cameras, calculator watches, and full-featured PDAs for your wrist. There are also watches that double as heart rate monitors, pagers, cell phones, and TVs. There’s even one watch that runs Linux—X-Windows and all. It seems the wrist is pretty valuable real estate.

No matter which of these devices you might choose to wear on your favored wrist, the device is still primarily your watch. No one in their right mind would wear a multi-function watch on one wrist and a backup timekeeping device on the other. It’s reasonable to expect that, no matter what goes wrong with the extra features of the watch, you’d at least be able to get the time from the thing. Or is it?

My friend learned the hard way that the failure of a watch extra can interfere with it’s implied ability to keep the time. On a recent trip to Alaska, my friend managed to confuse the digital compass in his watch twice. This happened first on the airplane, several miles above the Earth. The second time it happened he was hiking north of Anchorage. Each time, he attempted to take a compass reading only to have the watch reboot itself. Apparently, the strength of the Earth’s magnetic field isn’t within a useful range in those locations.

The designers of this particular watch must have decided that bad sensor readings were more likely than useless magnetic field values. And they deemed rebooting a good way to “fix” a bad sensor. This might have made sense in a lab environment, where the only bad readings were manufactured. However, in the real world, there are places where compasses—even those of the analog sort—aren’t useful. In the process of rebooting the watch, the current time was lost—a far more costly problem for the wearer than an out of range compass reading.

The lesson here is not exclusive to watch designers. All of us who are designing multi-function devices should consider the functions separate. A problem with one function should never be the cause of problems with another.

NOTE: this article was originally published on 7/13/01.

Out of the Bottle

Sunday, September 16th, 2001 Michael Barr

The genie is really out of the bottle this time. As first reported in Komsomolskaya Pravda newspaper and later by, Russian engineer and entrepreneur Dmitri Zhurin recently invented a talking bottle cap. This is a bottle cap that looks like any other, but houses a tiny battery-powered embedded system that speaks to those gathered around the bottle for a drink.

Why would anyone want a talking bottle cap? For several reasons, according to the inventor. First, because Russians like to drink, but don’t like to drink alone. Initially, the voice in the cap offers only generally helpful instructions like “pour.” As additional drinks are taken from the bottle, however, the cap’s performance gets livelier, ultimately providing a friendly group of incorporeal drinking companions. The second reason for a talking bottle cap is that it can help out with the toasting duties. It seems Russians mostly drink in communal rounds at parties, with a toast preceding each round. Coming up with a large number of toasts in one evening can be a real challenge for the host or hostess.

Clearly, these problems are so compelling that the market had to respond with a solution—hence Mr. Zhurin’s Vodka Genie. Now, whether or not consumers will actually buy the Vodka Genie is an interesting question. What’s more interesting to me, though, is that here’s yet another place where no one expected computing power to turn up—and yet it has.

>It would be a major understatement to say that in 1943, when Thomas Watson commissioned the oft-cited study that concluded there was a total world market for five computers and that IBM would make all of them, no one could have imagined computers inside bottle caps. The first commercial microprocessor wouldn’t even be developed for three more decades!

Yet look at where we are less than three decades after the invention of that first microprocessor. We are literally surrounded by computing engines—the vast majority of them unrecognized as such. And this is only the beginning of the next era in computing—the embedded era.

>So much attention is focused on developments at the high-end—cheaper 32-bit processors, entire systems-on-a-chip, increasing memory budgets, connectivity to the world, millions of lines of code, the need for better development languages and debug tools, and increasing use of off-the-shelf software components—that it’s easy to forget that there are ongoing developments at the low-end of the spectrum too.

Processors of the 16-, 8-, and 4-bit varieties get cheaper every year too. New family members add more on chip memory and peripherals for no additional cost. Some even include specialized capabilities like speech synthesis, for niche applications like talking dolls bottle caps. All for just pennies a chip, at the current 4-bit price-points.

The point I’m trying to make is that 4- and 8-bit micros will never be replaced. In truth, the number of new opportunities for simple 4-bit micros is expanding at a much faster rate than the number of new uses for 32-bitters. And it only takes a single engineer and a few months to design and build a disposable product like the Vodka Genie, which could very well sell millions before this reaches your mailbox.

NOTE: this article was originally published on 6/2/01.


Saturday, September 15th, 2001 Michael Barr

Ergo, Audrey. Entered into eternal cancellation on Wednesday, March 21, 2001. Much-ballyhooed simplifier of modern everyday life; beloved step-sister of Kerbango, also cancelled; preceded in cancellation by Netpliance’s i-opener; survived—so far anyway—by Compaq’s iPAQ, Honeywell’s WebPAD, and parent 3Com’s “core businesses.” In lieu of flowers, the developers request that memorial contributions be made to Nasdaq:COMS.

Depressing isn’t it? Coincident with the announcement of its latest quarterly results, 3Com quietly stated that it would “discontinue its consumer Internet Appliance product lines.” In other words, no more Ergo Audrey home “nerve center” and no more Kerbango “Internet radio.” Even at a time of such opportunity for the emerging Internet Appliance market, the need to satisfy a shaky Wall Street managed to kill off two of the more promising new devices of that genre.

3Com didn’t elaborate on its rationale; perhaps initial sales of Audrey were disappointing. However, five months and four days seems hardly long enough to call any product a failure—at least not in a market poised for a “five-year growth rate of 73 percent” (words used to launch Audrey on October 17th, 2000 and attributed to research by analysts at Cahners In-Stat). The award winning, though much delayed, Kerbango 3Com spent $80 million to acquire less than eight months ago was not even offered a chance to test its market for one day.

One obstacle for such early Internet Appliances is certainly price. Whether they promise a simpler way to access e-mail; schedule and address book synchronization; wireless Web access; electronic books; thousands of channels of digital music; digital video recording; still image capture; or some combination of features from that list, the price of is invariably higher than the general-purpose computers they still very much compete with.

In a period of free-after-rebate 700MHz PCs, the entry price for Audrey (based on a 200MHz National Geode GX1 processor with 16MB of Flash, 32MB of RAM, and the QNX RTOS) was a whopping $499; and it cost $50 more to change the color of the plastic; more still to get a USB Ethernet adapter (for those with broadband connections). All that to accomplish a set of tasks any dunderhead could configure a four-year-old Pentium-90 system to do: e-mail, Web browsing, and synchronization of a PDA with an address book and calendar.

>Sure Audrey was more compact than a PC (not much larger than its 6¼” x 4¾” color touch screen, for those who haven’t seen one). She was also far easier to use and maintain. But a PC can also play games, offers word processing and personal finance software, and oh-so-much-more. It’s hard to compete.

If individual Internet Appliances are to succeed, and I believe many will, they need to find niches that aren’t being filled well right now. And they need to fill them at attractive prices. Check out Kodak’s new mc3 for a perfect example. At Audrey’s launch last October, 3Com asserted that its Internet Appliance product line would offer “the best of the Internet in a convenient and intuitive way.” They forgot to add, “for a limited time only.” That’s too bad. 

Audrey and Kerbango will both be missed; we hardly knew them.

NOTE: this article was originally published on 5/18/01.

Embedded Head Count

Friday, September 14th, 2001 Michael Barr

“Does anyone know how many embedded engineers there are in the U.S.?”

That was the question posed in the comp.arch.embedded newsgroup last August. My first thought was “no, nobody really does.” But then I saw that another poster, a frequent contributor to the group, had already responded:

“There are presently over 2.4 million ‘Embedded Engineers’ in the U.S. This figure increases 21% to 35% annually.”

The author quoted an analysis he had done himself as the source of this information and linked to his website. But when I went to his website I couldn’t find any material related to this topic at all. So I posted a response stating that I felt his figure was way off the mark and asking to see his analysis.

If there were really 2.4 million “embedded heads” in the U.S. we’d account for approximately 1 out of every 110 Americans. While a figure like that is not out of the question for certain occupations—police officers and teachers are even more prevalent in our society—it seems at least an order of magnitude too big for embedded engineers. One out of every 1100—about 250,000 individuals—seems far more reasonable.

Needless to say, after some back and forth (both public and private), it became clear that the guy who seemed so confident that there were 2.4 million of us and so eager to announce this to the world, couldn’t give any actual justification for his numbers. At one point he mentioned that he “based the results on figures obtained from the U.S. Bureau of Labor Statistics.” (He claimed to “have the raw data broken out somewhere”, but never did provide anything of the sort.)

Judging from two-year old statistics I found on the BLS website (, 2.4 million might be an accurate figure for the entire category of “computers/hi-tech” workers. But that group also includes every computer programmer, database analyst, sysop, network administrator, web developer, webmaster, and many others. We are certainly far outnumbered even within that subpopulation.

So what is the true number of embedded engineers? I don’t know; probably nobody does. What I can tell you is that an extrapolation of 1992 data from the National Science Foundation could put the “number of engineers [of all types] in manufacturing” at over a million, and that BLS reported about 350,000 “electronic/electrical engineers” in 1998. IEEE-USA has about 220,000 members (including students), the ACM has “over 80,000 worldwide”, and ESP has 60,000 qualified subscribers. My book aimed at embedded newbies has sold about 20,000 copies in two years—making it an all-time best-seller in the embedded category. Finally, about 10,000 of us (not counting exhibitors) are expected to attend the Embedded Systems Conference in San Francisco in April.

Mulling over all of these numbers and considering the likely weight of each to the calculation, my mind keeps coming back to the figure of 250,000. Though by no means scientific and probably off by as much as 20% one way or the other, that’s about the best estimate I can give you today.

I’m not even going to discuss the ludicrous annual growth rate suggested by the same poster. By no surprise, this guy is now in marketing.

NOTE: this post originally published 3/10/01.