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?'"
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.
technically that is what part of the update does. It forces the computer to always choose the brake over the accelerator when both pedals are registering. So if the car does accelerate a tap on the brakes should disengage it.
i thought once I was found, but it was only a dream.
Something to understand about those statistics: This is a self selected group based largely on income. Camrys may be everywhere but Prius' tend to be expensive.
bob@Osprey:~>
i'd feel much better with drivers who know they should pop the car into NEUTRAL if it starts accelerating out of control for any reason, rather than trying to stand on the brake pedals while dialing 911 ...
To me it suggests that older drivers are having more difficulty coping with the situation once it arises.
Forbes says that the guy who got himself plastered all over cable last week was 'afraid' to put the vehicle into neutral, or to turn off the engine:
http://www.forbes.com/2010/03/12/toyota-autos-hoax-media-opinions-contributors-michael-fumento.html?boxes=financechannelforbes
(They link the 911 recording:
http://www.thetruthaboutcars.com/the-jim-sikes-911-call-23-minutes-of-unintended-acceleration/
)
So apparently being an idiot is also a likely factor in the failing to cope with the incident before it becomes lethal.
But they key observation is that the higher number of fatalities among older drivers doesn't really point to the source of the problem being driver error (rather, the driver error is in failing to deal with the situation once it arises).
Nerd rage is the funniest rage.
> 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.
Any vehicle built in the last thirty or fourty years will not allow the steering column to lock unless the transmission is in park. If you're in drive (or neutral) you can only turn it to "off", not all the way to "lock". This was to prevent an errant knee from locking the steering while you're doing 70 on the freeway. Happened to me once, except I was only doing 45 on a bumpy ass gravel road when my knee smacked into my keychain. It was startling, but not particularly dangerous.
> 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
Yep, normally that results in death
You can't handle the truth.
This one comment makes me wonder about the veracity of the balance of your account.
Then there is crunchy bit of FUD, which fails to mention that more than a few of those accidents are also associated with extreme control surface movements (inducing extreme stresses) prior to the failure.
And more examples of how wrong things can get can be found here: http://thedailywtf.com/
There are some good examples there, but you'll find more on comp.risks.
Several years ago, I designed the software for a real-time automotive test system called HP ECUTEST (I think the official name was HP Design Span DS5470, but let's not waste time on HP's cold dead fish naming conventions). It simulated a car from an electric point of view. You connected an electronic control unit (ECU), and it had basically no way to tell it was not in a real car. Think of it as The Matrix for car electronics.
One of our first customers wanted us to test it with a reliable, proven, tested, tried and true ECU, something that was on the road in cars for several years already. So we did. And I noticed something odd. The ECU worked fine when we "drove" a car normally, but at idle, it would basically slow down, one RPM at a time, until it stopped. However, if I changed the value of the input corresponding to the accelerator pedal, it would reset the idle speed to the default, something like 800rpm.
Finally, after eliminating the possible bugs on our side, we tell the customer. Their first reaction was "no way". But after a week and a demo of the problem, they finally made a connection. They had this elusive bug of some car customers complaining that their car would sometimes stop when idle. It turns out that in a real car, chassis vibrations generally caused minute changes in the input value for the accelerator. So the ECU would correctly recompute its idle speed. However, if there was no change, like if the pedal was more rigid than usual, the bug would trigger.
The root cause was a routine that wanted to optimize idle speed to be as low as possible, but for some reason kept cached data if the accelerator had not changed, so it thought the engine was still running smoothly.
We found such bugs in practically all ECUs we tested for the first time. The most impressive one was in a V8 ECU that was basically a V8 until 1200rpm, then a V7, then a V6, and basically a V2 above 4000 rpm. The customer had hoped we'd find something, because they didn't get all the power they expected from the engine. Obviously. It was hard to find without our system, because the injectors that fired were differnt from cycle to cycle, so more simple instrumentation saw all cylinders running. The root cause here was that the software badly exceeded its real-time envelope... Ouch.
-- Did you try Tao3D? http://tao3d.sourceforge.net
No, it was an example of one the computer CAN deal with (if it's anticipated in the programming.
A computer is limited by the creativity of the guy writing the IF THEN statements (setting aside the possibly of adaptive AI, but that raises other issues).
Derek, as you might have noticed I was keeping it short on the comet disaster. But to expand. yes of course metal fatigue as a phenomena was known before the Comet disaster. What my Dad told me was they learned that they did not know about how to design for it yet. They did not have any computer modeling to know what flight stress really did to winds and to metal. they hardly had any way to measure material strength changes in-place. The people who built the Comet we no dummies so clearly they discovered a scaling issue in metal no one had encountered before nor new how to design for at that time. The point I was making was that just because you can't foresee a problem in something new does not mean you cant anticipate there might be problems you can't foresee. The switch to composites opened up the same sort of issues that the comet did.
Some drink at the fountain of knowledge. Others just gargle.
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".
From working in the field of emergency response, quite a number of newer cars (somewhere around 2000 they started putting them in) do have a "blackbox" of some kind (some more detailed than others). Having said that, I'm not the one to examine them nor do I pull them out of cars after an accident. But, having talked with the guys that do, they get a surprising amount of data from them. It tells them whether or not the air-bags were deployed, the highest speed before "sudden" deceleration, the time it took the car to come to rest, whether the breaks had been applied, whether the seatbelts were engaged, traction of the tires (if the car has one of those "smart" traction-control features), and all time-stamped (sure there is more, but that's all I can remember from the conversation).
Just thought I would point that out for those that are unaware.
Cheers.
I say don't drink and drive, you might spill your drink. Before you get behind the wheel just stop and think.