Slashdot Mirror
Toyota Acceleration and Embedded System Bugs
An anonymous reader writes "David Cummings, a programmer who worked on the Mars Pathfinder project, has written an interesting editorial in the L.A. Times encouraging Toyota to drop claims of software infallibility in their recent acceleration problems. He argues that embedded systems developers must program more defensively, and that companies should stop relying on software for safety. Quoting: 'If Toyota has indeed tested its software as thoroughly as it says without finding any bugs, my response is simple: Keep trying. Find new ways to instrument the software, and come up with more creative tests. The odds are that there are still bugs in the code, which may or may not be related to unintended acceleration. Until these bugs are identified, how can you be certain they are not related to sudden acceleration?'"
Always going forward.
o hai
Most software is nearly -impossible- to test under flawless conditions. Especially embedded systems with small amounts of CPU power and memory.
Plus, all this hype around these Toyota acceleration problems is just that, hype.
Taxation is legalized theft, no more, no less.
Drive by wire is great and all, but I'd feel much better with a physical fail-safe than their "infallible" software. I am aware of the physical remedies for the issue, but I'd like to see the brake pedal override the accelerator.
Some more data here
Testing only confirms the absence of known bugs. Never forget that.
David Cummings does seem to know what he's talking about, but as it is written, there is some strange logic in the article.
Testing cannot prove the absence of bugs, only their presence. There are two things that do not follow from this:
It sounds to me as if Toyota is saying the former, while Cummings says the latter. Neither is a correct conclusion.
I'm loving this conversation here because I've gotten crucified in slashdot before for making simmilar comments to the whole thread here. I grew up in a family of top managers of Boeing systems engineers. They hated computers. My dad never even learned how to turn one on. He hired other monkey to use the computers. As A child I was regailed with wonderful stories of every hard lesson in safety my dad had learned over his lifetime. He loved world war II because they got to use cutting edge designs for balls out performance yet at the same time learned how to make things reliable by disecting the accident. He would tell me about the accident that taught them that the engine pumps need to be at full speed but flow stalled on take off so that there's no lag when you hot swap after a pump fails. He told me of the accident where they learned not to route 100% of the control system wiring through any one junction box. etc...
Probably because of all these hard won lessons boeing for years insisted on fully mechanical or hydraulic flight surface controls. Whereas Airbus and other jumped on the fly-by-wire concept early. My dad would spit after hearing some youg person tout all the advantages of fly by wire. He knew them perfectly well. He was big on accepting new innovations to reduce fuel costs and increas performance. He was not a luddite. But he had a safety background that told him these electonic systems were hard as hell to validate and hard as hell to make truly independent from each other.
For example they often used triple redundant computers and if one of them disagreed the other two would vote it off the island and stop listening to it. From what I've read it's now suspected that the latest airbus crash in the pacific had one of it's root problem in the voting nexus where a superior computer over ruled a more primitive safety system.
While we all know that computer software validation is hard if not impossible. It's not something we readily admit here on slash dot. It's because for years people like my dad would throttle the innovations the computer engineeers wanted to implement. I think as a result there became this culture of computer engineers that presented the case that embedded computing could be made safer than it really could be to offset that.
So now we come full circle and have to admit there is this middle ground. Just because a computer can improve perfromance does not mean it's reliable and safe. The old guys had a point after all when it came to safety.
Next week I'll tell you about how the ancient shocking lesson of the British Commet aluminum aircraft wings falling off led to the unanticipated discovery of metal fatigue and probably was the reason Boeing was slow to move to composite materials in commercial aircraft (but not in military aircraft). In hind sight we have heard of many tales of the composite tails of plane falling off as the reason for the loss of control before a crash. Conversely, composite wings on UAVs allow them to absorb a lot of bullet holes with no loss of control and to operate under higher perfromance conditions.
The point is that safety and performance are trade offs when both are pushed to the limit. The old guys know a lot more about safety than you might expect. The young guys are all about performance.
Some drink at the fountain of knowledge. Others just gargle.
They should just implement a huge red panic button to shut everything off :)
They could even buy them at Staples. Need to stop your out of control Toyota? That's easy.
Unfortunately the update assumes the computer will actually respond to the brake being pressed or any input for that matter. Toyota doesn't know for certain what is causing all of these sudden acceleration problems in which fiddling with the gas pedal, brake and even putting the vehicle in neutral won't stop the vehicle. The software update, while a sensible modification that should've been in the software all along, is sort of a hail mary toward preventing any new cases in updated vehicles.
> And I know how to hit the brakes...
With the engine past the redline there is very little vacuum to operate the power brakes. Without power assist the brakes may not be able to overcome the engine (this is, IMHO, a fundamental design defect).
> ...shift into neutral...
The computer may not let you do that with the car moving and the engine at high rpm. After all, the engine and/or transmission might be damaged (another design defect).
> ...and/or turn off the key...
Some of these vehicles don't have keys: just a radio remote. The emergency shutdown procedure is to hold a button down for three seconds (another design defect).
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I worked on an embedded flight system there, and deeply respected people like your dad.
Boeing works under the eye of a certification authority who has to approve the safety of a design including, at least in the system I worked on, human factors. If there's anything comparable for cars, I haven't heard of it.
Boeing would not have made a pilot have to guess at how to turn an engine off (people with older cars, it's no longer a matter of turning a key).
Inputs were checked for consistency and validity. The specs would have anticipated what to do if the accelerator and brake were both full on at the same time.
There was a culture of worst-case planning and redundancy.
Also, if Boeing built a car, it would have a flight data recorder which investigators could examine and say for example "Looks like both(*) potentiometers on the accelerator went hard over at the same time, so we go look on the branches of the fault tree where there's a common-mode failure in the potentiometers or the pedal is down due to mechanical or pilot error".
(*) If I remember correctly from my obsessive pre-purchase research on Priuses, there are two separate sensors for accelerator position.
... why does everyone assume it is a software bug? I agree that it very well could be an undiscovered software bug. But there are so many more sources of erroneous behavior in an embedded system that *even* *if* the software were flawless (ummm... just go with me a minute... :) an automotive environment can cause all manner of strange glitches. I work with robots, lots of DC motors causing commutation noise on the power supply, long (several inch) distances between units that must talk to each other and therefore may have a different opinion as to ground reference voltage... many things can get wacky. Even flawless code needs a watchdog timer to get you out of weird states that power glitches that put you into. Power supply spikes can cause the program counter to jump to very odd places, with odd, corrupted stuff in RAM. Ground level shifting can cause communication glitches. CAN bus is *extremely* robust, so bad data should not get through... but what does get through? Does the system as a whole get into a weird state if packets drop?
> With the engine past the redline there is very little vacuum to operate the power brakes. Without power assist the brakes may not be able to overcome the engine
apparently not true
On the flip side, the USN replaced complicated and heavy hardware analog computing systems for [SSBN] missile guidance systems with software running on a digital computer, and MTBF went through the roof and maintenance man hours and MTTR through the floor. The same thing happened when they replaced the analog torpedo fire controls with digital ones. The same thing happened again when the hovering system controls were upgraded to digital.
Now, before you claim that is a limited set of examples, I invite you to consider the millions of incident free flight hours accumulated by fly-by-wire aircraft. Or the replacement of DIP switches in PC's with software configuration. Etc... Etc...