Sudden Unintended Design Failure

I’ve written about the sudden unintended acceleration (SUA) problem being encountered on Toyota, VW, and other makes of automobiles before. Toyota has reached a settlement with one of the plaintiffs suing them over the matter:

OKLAHOMA CITY — Toyota Motor Corp. on Friday reached a settlement with the victims of a deadly 2007 car crash, a day after an Oklahoma Country jury became the first in the country to find the company liable in a case of sudden unintended acceleration.

On Thursday, the jury awarded a total of $3 million in monetary damages to the injured driver of the 2005 Camry involved in the crash, and to the family of the passenger, who was killed.

The ruling was significant because it was the first case where plaintiffs argued that a car’s electronics — in this case the software connected to the Camry’s electronic throttle-control system — caused the unintended acceleration. The Japanese automaker recalled millions of cars, starting in 2009, following claims of sudden acceleration in Toyota vehicles. It has denied that electronics played any role in the problem.

I’ve long suspected that the problem was real and it was either a software problem or a problem caused by some combination of the vehicles’ computer hardware and its software (which is another type of software problem). Here’s an interesting, if tech-y, analysis that finds that the problem is caused by “misbehaviors” of Toyota’s electronic throttle control system. They report a host of bad hardware and software design issues.

There are quite literally millions of vehicles that might potentially be subject to this problem and also quite literally billions in potential damages. The stakes are pretty darned high for Toyota and, unsurprisingly, their first line of defense was denial while the second was blame the users. I have 100% confidence that some proportion of the instances of SUA were not caused by driver error.

There are all sorts of reasons that problems of this magnitude can creep in. Designers can get away with it—the users can always be blamed. Management sometimes won’t pay to have things done right. It might even be true that they don’t have and for cultural reasons won’t hire people who are capable of doing things right. Hardware engineers are notoriously bad software developers.

This whole subject relates to the problems being encountered with Healthcare.gov. It ain’t just the public sector who fall in their faces with important software development projects. The private sector can flop, too. They just do it privately.

IMO it’s terribly difficult to implement massive software developments, particularly when they’re being second-guessed by politicians. An honest team could say “No problem. We can do it in ten years and it’ll cost $10 billion”. They’d be laughed out of the room. Instead, they say they can do it in six months for a tiny fraction of that cost. It’ll still take ten years and cost the same amount but then we’ll be committed.

4 comments… add one
  • michael reynolds Link

    It’s all very comforting as I set off on a bit of a road trip in my new fly-by-wire car.

  • jan Link

    Michael,

    You have wonderful weather and a convertible to fully enjoy the views of whereever you are traveling. Have fun on your road trip!

  • sam Link

    “It ain’t just the public sector who fall in their faces with important software development projects. The private sector can flop, too. They just do it privately.”

    Or not so privately: How to lose $172,222 a second for 45 minutes.

    This is probably the most painful bug report I’ve ever read, describing in glorious technicolor the steps leading to Knight Capital’s $465m trading loss due to a software bug that struck late last year, effectively bankrupting the company.

    The tale has all the hallmarks of technical debt in a huge, unmaintained, bitrotten codebase (the bug itself due to code that hadn’t been used for 8 years), and a really poor, undisciplined devops story.

  • Jimbino Link

    Funny, I’d say it the other way around: Software engineers are notoriously bad hardware designers. In order to write a device driver, you have to have a good understanding of hardware, and especially if writing the operating system software.

Leave a Comment