Info you need to know about TOYOTA

Toyota, drive by wire, and our failure to learn from experience
There simply is no systematic approach to ensuring the quality of an integrated hardware/software system.
posted by By Ron Wilson, Executive Editor of: http://www.edn.com/embeddedmaster/article/ca6720350.html, on 3/4/2010
+++++++++++++++++

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 under way, and evidence is already emerging that the underlying problem is likely in the engine controller, not in the pedal’s mechanical assembly. Now we hear from Japan that the Prius, Toyota’s golden child, has a problem with its brake-by-wire control system.

Decades ago, Audi accidentally introduced drive by wire with its advanced cruise control on the Audi 5000. The cars were allegedly subject to spontaneous acceleration, a problem the company blamed on operator error. At the time, researchers at another European high-end auto company claimed to have 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. The ensuing liability litigation, however, extinguished all hope of diagnosing and documenting the problem so that the rest of the real-time-software community could avoid it.

All this came to mind when I attended a panel on achieving quality closure at last month’s DesignCon in Santa Clara, CA. Despite the subject of the panel—achieving quality closure—the issue of software sat like an elephant in the corner of the room, awaiting notice. One of the panelists pointed out that the most serious quality problem in IC designs now is not the 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.

Read more EDNCOMMENT

This situation is a tragedy. Work was well under way 30 years ago on the problem of formally proving software correctness. One company had designed a completely deterministic microprocessor that made it possible to mathematically prove all of the possible trajectories of a code set. Computer scientists such as Edsger Dijkstra were making strides in a method for creating formally proven software. But along came C, Unix, and the cult of the hobby programmer, and the entire notion of formal correctness vanished under a smokescreen of hacking.

Now, after decades invested in metrics-driven verification, formal verification, and methodology management, designers find that their chips don’t work as expected because the software is still being “verified” by feeding it test cases until the schedule expires. Consumers find that their cars run into these problems for the same reason, and the press blames the problem on “electronics.”

Once again, as in Audi’s day, it is safe to conclude that a gag order as part of a class-action settlement will screen whatever accurate diagnostic work takes place on the Toyota problems so that no one in the industry can benefit from what Toyota engineers learn. In that way, we can repeat the situation with the next generation of software-governed systems, a new set of executives can avoid blame for the tragedies, and a new set of lawyers can make their fortunes from the resulting litigation.

The only parties in this little tragedy with an interest in improving the state of the art are the engineers, whom no one will consult, and the victims, whom the lawyers will silence. It would be better for everyone if it were a principle of civil law that, when a failure inflicts damage, the vendor and independent parties must place all of the diagnostic information they find into the public domain, and the courts may not use this information to assess or assign damages. Such a notion might somewhat restrict the income opportunities of litigators, but it would unquestionably assist the engineering community in learning from its mistakes.

Contact me at ronald.wilson@reedbusiness.com