|
Embedded Muse 50 Copyright 2000 TGG August 1, 2000
You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.
EDITOR: Jack Ganssle, jack@ganssle.com
CONTENTS:
- Editor’s Notes
- Embedded Failures
- Contest!
- Thought for the Week
- About The Embedded Muse
Editor’s Notes
Many folks have written asking about the status of The Embedded Muse, as the last issue was a couple of months ago. It’s just a case of holidays; each summer my real life goes on hiatus for June and July in favor of sailing. Alas, it’s back to the grindstone now, so the Muse is back on-line.
The Write Only Memory contest (see info later in this email) closes in two weeks. Many of you have submitted entries, some quite funny. Stay tuned next issue for the winner.
Embedded Failures
On March 12 Sea Launch attempted to boost a communications satellite into orbit from their ocean-based platform, and failed. A single line of code was in error, which allowed the vehicle to blast off with an open second stage pneumatic valve.
So here’s an example of a hideously-expensive failure of an embedded system, one where the firmware was at fault. I have no other details of the failure, but ask any reader who has information to send it to me at mailto:jack@ganssle.com.
The firmware content of all products is skyrocketing, yet “reliable code” seems to be an oxymoron. Surely we’ll see a breathtaking surge in the number of embedded system failures. Some will be of little consequence, perhaps just annoying our customers. Others will threaten life and limb.
Did you know that Ford recalled some Explorers on June 6, 2000 because air bags, windshield wipers and other accessories could fail? The culprit: a missing pull-up resistor on the computer module.
Surely we can learn from these disasters if we develop a lore of catastrophe. For instance, what does the Los Alamos near-nuke failure of 1998 and Ariane 5’s maiden flight explosion have in common? Poor error handling. And error handling is a huge problem for all software, as it’s dreadfully hard to anticipate and test all error possibilities.
So I’m collecting stories of embedded disasters, to share with readers. If you know of a disaster - and can validate it - please send me information or references. Just as civil engineers learn from stories of collapsing bridges and skywalks, we can – and should – tune into these problems in our own field.
Contest!
When Signetics created their Write Only Memory part as a joke a quarter century ago, they probably had no idea so many people would be so entranced.
I have a copy of the part’s original datasheet, as well as an actual part (marked “NFG” in case there’s any doubt).
Just for fun, here’s a contest with the datasheet and the Write Only Memory chip as grand prize. Come to https://www.ganssle.com, select the link to the contest, enter your email address, and your name will be tossed into the ring to win the prize. If you’d like, also enter in a suggestion for what you’d use a write-once, read-never part for.
The winner will be announced in this newsletter, and some of the funnier uses for the part will run as well.
Thought for the Week
To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be.