For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
She followed me in the rented cargo van till I left the New Jersey Turnpike. I had business on Long Island, and my wife was headed to Boston to move the eldest out of his dorm room for the summer break. A day later, meeting over, I headed for our planned rendezvous in Rhode Island.
But I needed cash so dashed into a Wal-Mart and swiped the card through an ATM. The machine accepted my electronic request for $300 and then suddenly returned to its initial welcome screen. "Puzzling," I thought, but assumed the small unit couldn't dispense that much money in a single transaction. "Pretty lame UI if that's the problem." I tried again, now requesting $200. That frustrating "please wait" message that infests all of our equipment appeared.
Nothing happened. A minute went by. Then another. Trying to give up I hit the "cancel" button. More nothing happened. I tried again and again. Pretty soon the machine beeped when any key was hit. That sounded a lot like a full keyboard buffer ping generated by Windows 3.1 when it hung or got busy.
But by this point I was getting panicky. Over 4 minutes had passed. Do I just leave? What if the ATM finally came alive and spit a wad of cash onto the floor? Do I contact a manager? At Wal-Mart? The odds of finding anyone knowledgeable enough to help seemed remote so I stayed and stewed. Finally the machine did something. It didn't squirt greenbacks. Nor did it apologize for a problem with my account or with the unit itself. Instead it again returned to the welcome screen.
I called the bank and changed the PIN code just in case the machine was a front for some phishing operation. But it's unlikely that a unit positioned so prominently in a huge retailer had been compromised. I assume the software crashed. Perhaps it was the OS.
The machine sported a Diebold label, a pretty clear indication the unit uses some version of Windows. We do know that at least some of their electronic voting machines boot CE. A few days later a look at their web site (http://diebold.com/solutions/atms/opteva/html/videos/05pentium_large.htm) confirmed that the ATMs use Pentium 4s with 20 Gb of hard disk and 256 Mb of RAM, which sure sounds Windows-ish to me.
Unlike most techies I really like Windows. My machines run XP, which has been highly reliable, intuitive and offers a wealth of functionality. But these are desktop computers. The occasional crash is simply not a problem. Extensive backup strategies insulate me against OS problems, as well as those from fire, floods and pestilence. Weekly prophylactic reboots keep the systems stable, and consume essentially zero time and energy. Now expending infinite energy dealing with teenagers I just can't get worked up about tiny annoyances.
Embedded flavors of Windows, too, are entirely appropriate for a wide class of systems. Agilent's Infinium oscilloscopes rely on the OS. An occasional crash is barely a nuisance. A CE-based cell phone with 99.9% uptime is good enough.
But some apps require much more reliability. That ATM crash in fact didn't cause any problems; the bank confirms the withdrawals never happened. But I'm left with my faith in the reliability of electronic banking shaken. Next time I see the Diebold label I'll probably look for a different machine. Not only must any bit of technology that manages money be reliable, it must appear to be reliable. The entire banking industry - indeed, even the concept of paper money - is based on trust. Without a perception of ATM integrity people will avoid electronic transactions.
Diebold's AccuVote-TSx was decertified in parts of California this week (http://www.ss.ca.gov/elections/ks_dre_papers/decert.pdf). (For Diebold's side of the story see http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=DBD&script=410&layout=-6&item_id=521776). The State now requires much more extensive proof of correctness for all electronic voting machines. I applaud the new, tighter regulations, but worry that the requirements might still be too loose.
According to http://www.ss.ca.gov/elections/ks_dre_papers/decert1.pdf California's Secretary of State may demand access to any voting machine's source code if, in the case of COTS code, it's available and discloseable by the vendor. Since the Diebold units (and presumably those from other vendors) use Windows, the biggest component, the largest number of lines of code, are inherently proprietary and closed. Despite my liking for Windows, it's huge, it's secret, and it has never been certified to any safety-critical standard. If it were perfect, if it never crashed or behaved oddly, the OS is still a gigantic unknown lurking in the system.
Critical avionics applications would never run a massive chunk of unproven code. A failure causes deaths, injuries and lawsuits. A flaky ATM or voting machine won't hurt (physically, at least) or kill anyone. Lawsuits? Well, the Supreme Court mediated alleged election irregularities in 2000. I'd hate to see the same this year, especially if due to software bugs, real or alleged.
When consumers don't trust ATMs they'll use direct deposit and face-to-face banking. If the electorate doesn't trust voting machines, few options exist. They'll simply stop showing up at the polls. And that's a Bad Thing for our republic.