Toyota Prius and Camry, drive-by-wire, and our failure to learn from experience

[steven johnson]

This author has come to the conclusion that the software is too complicated to ever be adequately tested considering the number of permutations and combinations of inputs that could be stress the software.

Toyota internal documents reveal that software caused surges and had been implementing software corrections as early as 2005.

Toyota Software Caused Surges, Docs Show

Now that it has been shown that the software can't handle several postential short circuits, the fail safes really seem to lack redundancy that are needed to prevent runaway accelerations.

Expert: Electronic Design Flaw Linked to Runaway Toyotast

I see from the morning news that Toyota's adventure into the world of embedded software is going badly. The company's second attempt to find a quick fix for unintended acceleration in its conventionally-powered vehicles is barely underway, and already evidence is emerging that the underlying problem is likely in the engine controller, not in the pedal mechanical assembly. And now we hear from Japan that the Prius, Toyota's golden child, has a problem with its brake-by-wire control system.

One has to recall Audi, which decades ago accidentally introduced drive-by-wire with its advanced cruise control on the Audi 5000. The cars were allegedly subject to spontaneous acceleration. The company blamed the problem on operator error. At the time, I was told that researchers at another European high-end auto company had uncovered a problem in Audi's engine-control firmware and reproduced the acceleration without requiring a driver to mistake the gas pedal for the brake. But in the ensuing liability litigation, all hope was lost of diagnosing the actual problem and documenting it so that the rest of the real-time software community could avoid it.

The reason all this came to mind this morning was actually not the newspapers, but a panel I attended yesterday at DesignCon. The subject was achieving quality closure. But the issue of software sat like an elephant in the corner of the room, awaiting notice. One of the panelists—I believe it was Design Rivers president Camille Kokozaki—pointed out that perhaps the most serious quality problem in IC designs now is not quality closure on the hardware, but the integrity of the firmware and software that will run on the chip. There simply is no systematic approach to ensuring the quality of an integrated hardware/software system.

So now, after decades invested in metrics-driven verification, formal verification, and methodology management, we find that our chips don't work as expected because the software is still being "verified" by feeding it test cases until the schedule expires. And we find that our cars run into things for the same reason, and the press of course will blame the problem on "electronics."

Toyota Prius and Camry, drive-by-wire, and our failure to learn from experience