First, Do No Harm - Embedded.com

First, Do No Harm

All of us who design multi-function devices should consider their functions separate. A problem with one subsystem should never create problems with another.

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. His 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, and so on) and the angle in degrees. The reading tells you where the top of the watch is currently pointed.

Multi-function devices like these aren't unique. Lots of products have multiple features. Today's buzzword for this phenomenon is convergence. Most Internet appliances have multiple functions.

Staying with the watch theme, 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 (www.research.ibm.com/WearableComputing/factsheet.html). It seems the wrist is pretty valuable real estate these days.

But no matter which of these devices you might choose to wear on your favored wrist, the device is still primarily your watch. Not many people would want to 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 watch's extra features, you'd at least be able to get the time. Or is it?

My friend, Jim, learned the hard way that the failure of a watch extra can interfere with its implied ability to keep the time. On a recent trip to Alaska, Jim managed to confuse the digital compass in his watch on two occasions. This happened first on the airplane, several miles above the Earth; then it happened while 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 either of 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 artificially. However, in the real world, there are places where compasses-even those of the analog sort-don't work. That's unfortunate, but it's a physical fact. The user would certainly understand and tolerate an out-of-range error under such circumstances.

Instead, this watch (or this version of the firmware) reboots itself. In the process, it loses the current time. This is a more costly problem for the wearer than an out-of-range compass reading. Keeping the time should've been viewed as the number one requirement for this product.

The lesson here is not exclusive to watch designers. All of us who design multi-function devices should consider their functions separate. A problem with one subsystem should never create problems with another.

Return to July 2001 Table of Contents

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.