6 ms·
This issue returns to Hacker News and to public consciousness every few months, and each time there is something missing: namely, some kind of direct proof that
by yaakov34 11y ago
This issue returns to Hacker News and to public consciousness every few months, and each time there is something missing: namely, some kind of direct proof that an actual failure of this software resulted in unintended acceleration, anywhere, ever. Let alone a case of runaway acceleration which the driver is unable to stop with the brakes (requiring a simultaneous brake failure). Since the accelerator pedals in these Toyota vehicles have been pressed no fewer than tens of trillions of times in recent years, that's not an appalling safety record at all. In fact, stuck pedals (whether due to bad lubricants or rolled-up floor mats) are many orders of magnitude more likely to cause stuck throttle than software failures, while runaway vehicles (ones with brakes not working either) are generally caused by "pedal misapplication", i.e. stomping on the gas instead of the brakes.
The fact that software has an execution pathway leading to something bad does not mean that this pathway can ever be entered, since in a closed realtime system like this, it is not possible to receive every combination of inputs, unlike in a system loading user data from a file. This is not to say that Toyota shouldn't clean up and verify its code, but the moral panics over what this code says about programmers, the human condition, Japan, etc. etc. are unwarranted.
Quote from http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_recalls http://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle_...:
On February 8, 2011, NASA and the NHTSA announced the findings of a ten-month study concerning the causes of the Toyota malfunctions of 2009. According to their findings, there were no electronic faults in the cars that could have caused the sudden-acceleration problems.
- tunesmith 11y agoEvery time this article comes up on hacker news there are a few comments that show up talking about how no one was able to prove that the bugs definitely caused the crashes, and thus the criticisms of Toyota are overblown. I'm left wondering how on earth to reconcile those viewpoints with general software engineering (which is a huge part of what this community is about), where we regularly see articles about new concurrency frameworks, fault-tolerant programming, formal methods to prove correctness of code, etc. If it's important enough for Amazon to use TLA+ to prove correctness of DyanmoDB then shouldn't it be considered outrageous that Toyota doesn't do the same thing for something that is potentially an accelerating death machine?
- Gibbon1 11y agoThe reason generally given is that in at least standard cars the brakes can apply far more torque than the engine can. It's telling how naive people are, they think the problem is 'unintended acceleration' A mechanical engineer thinks the problem describe is 'unintended brake failure'
- jessaustin 11y agoAnd if the brakes won't stop the car, try the key switch! An engine that is not running will not cause acceleration. (Sure there are probably some oddball push-button ignitions that can't be turned off while in gear, but most vehicles can be.)
- fr0sty 11y agoTurning off the ignition may deactivate your airbags* which could make a bad situation worse.You would be much better off attempting to shift your car into Neutral first. * This was what made the GM Ingnition switch problem so deadly. The engine shut off (taking power steering and vaccuum-assist braking with it) and the airbags deactivated making any subsequent crash less survivable.
- jessaustin 11y agoYou're right that shifting is better. That is a pretty terrible failure mode for airbags, however. How much would it cost to put a big reliable capacitor in the airbag circuit, to keep the power on for 30 seconds? A dollar?
- yaakov34 11y agoAbsolutely right. After reading any number of stories about these "runaway death machines", what becomes clear is that the only realistic way for a car to accelerate at full power against the wishes of the driver is for the driver to be flooring the gas while thinking he is on the brakes. We should be adding smarter automatic systems to the cars to assist drivers, rather than e.g. throwing out drive-by-wire linkages and replacing them with mechanics, which are generally less reliable. There are already cars which will slam on the brakes in any collision which is strong enough to deploy airbags - it stops the car from careening around too much. It should be possible for cars to detect an impending collision and slam the brakes 1/2 second early to prevent or reduce it.
- tremon 11y agoOh please. Your arguments are exactly the same as creationists' arguments against evolution. There exists no definitive proof for a chaotic system. The whole point of software engineering is to manage and avoid complexity, not to obfuscate/complexify your software beyond any control and then weasel your way out of it by saying that your software can't be proven wrong. The fact that no proof can be given either way is a failure of the design process, not of the claimant. "The fact that software has an execution pathway leading to something bad does not mean that this pathway can ever be entered" On the contrary, that's exactly what the term "execution pathway" implies. "there were no electronic faults in the cars that could have caused the sudden-acceleration problems." No electronic faults? Sounds to me like they tested for wire insulation, not runaway code.
- taejo 11y ago> There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -Tony Hoare
- lambdaelite 11y ago> Un bon mot ne prouve rien. (A witty saying proves nothing.) —Voltaire