From press reports it appears that Toyota has known since 2007 that it has a low-incidence problem with full-on acceleration, presumably caused by sticky accelerators but not conclusively linked to a single mechanical cause.
I have no experience with Toyota engine computers, but if they are like European ones they receive input from the brake pedal switch as well as accelerator position via the throttle position sensor and engine RPMs via the crankshaft sensor. The software is contained in flash memory that can be reprogrammed by the dealer.
Thus the problem can be dealt with positively — no matter what the cause — by reprogramming the computer to override the throttle input and shut off gasoline to the injectors (or limit it to idle levels) when the brake pedal is depressed for more than an instant. Even if there is a bug somewhere else in the software this override can be accomplished in a way that has priority over other instructions. This might impair drivability under some race car scenarios but would be much superior to the current state of fear that is being imposed on Toyota drivers.
At the same time, software diagnostics should be added to track discrepancies between throttle position and engine RPMs, to ensure that the cause of the problem is indeed mechanical at the accelerator pedal (or a driver-induced problem) rather than a fault in the computer or other engine component.
This solution seems so obvious that there must be something I am missing!
As a software developer, I’ll tell you that it’s simpler to describe the fix than to do it. Always.
You will have to deal with analog sensors that are not always accurate. Lags in readings, and who knows what else.
Then you have to test it, certify it, make sure there are no unexpected side effects. You can’t get the Blue Screen of Death on your Toyota, but the system can crash anyway.
As another software developer, I often here people suggest an “override” or “monitor” or similar for various situations to serve as bandaids to other problems.
There are two interlocking problems here: one is that, while perhaps this would work in this one instance, the reactions of the software as a whole have to be considered in order to understand what it will do. So a fail-safe, in fact, is really just another nonlinear input. The second is that software development is frequently conservative, in the “don’t fix what isn’t broken” sense, especially after developers come and go, software is written in response litigation, etc. So over time with this approach, multiple special cases end up developed as failsafes, and they invariably end up interacting with one another, frequently in surprising ways.
Stop and think about the potential scenarios for a throttle failsafe, antilock breaking, cruise control and skid detection interacting. Now add in more than one of the sensors involved in those systems slowly losing accuracy over time at unpredictable rates. Now throw in a human controlling some aspects of the car.
Characterizing how software works across potential inputs if extraordinarily difficult. For more reading on the topic in another mission critical system, here is a neat article on part of what happened to cause the great blackout: http://www.securityfocus.com/news/8412
Since my Toyota has a “hill holding” function that won’t turn the brake off until the accelerator is pressed, I’d forsee a bit of a problem for a system determining whether you are having an unintended acceleration despite the brake system operating, a “hill holding” manuever, or are manually holding the brake while revving the engine to start up a hill without drifting back. And then throw in the antilock braking, cruise control, and skid detection problems.
OTOH, as I understand it, a properly operating brake is powerful enough to stop one’s car even if the engine is driving forward at full power.
With so few cases overall and the history of the Audi 5000* I can see Toyota’s response time as reasonably deliberative. From what I’ve heard about the diagnosis of the faulty part, it seems to me a hardware engineering fix is in order.
*(unintended acceleration cases lost the company millions in court awards/settlements and huge market share-the cause determined later — definitively — to be caused by drivers applying the accelerator and THINKING they were pressing on the brake (which drivers couldn’t be convinced they had made that error). For awhile, I was seriously thinking that a used 5000 would be the best car one could buy for the money. Darned if I could find one.)
This is not a topic i ever imagined would appear in my feed reader.
Several other car companies do something extremely similar to this already. It’s just a matter of how many more automated safety systems do you add, because each one has the potential to cause a problem if it gets triggered inadvertently or turns out to not work the way you expected.
As someone who has no relevant expertise but who listens to NPR, I can inform you that they are in fact implementing just such a software fix (brake overrides gas if both are simulataneous) that you describe. I have no idea how they’re combining this with the hill lock described upthread. Also, even if this is implemented it’s not a complete solution to the problem: it only works if you realize the problem and apply the brake for one thing, and for another thing in some circumstances unrestrained braking might be as dangerous as unrestrained acceleration.
I’m assuming you mean “for more than an instant while the computer believes that the gas pedal is also being depressed”. But as Jeff has mentioned, a properly operating brake system is supposed to be able to hold the car still against full engine power, so you may also need to detect when the brakes aren’t doing their thing. And then you have to push it out to millions of cars in a way that doesn’t (on an aggregate basis) cause more damage than you’re averting.