Jeez so much misinformation in one post.
The fines were levied by the NHTSA not Congress Cite
You must have a very funny calendar since the hearings before Congress did not take place until 2010 Cite
Update:
18 month analysis by 7 experts found many flaws in Toyota software and were able to duplicate the unintended acceleration with ineffective braking (on a real car driving on a dynamometer) by flipping 1 single bit in primary control “Task X”.
The main CPU doesn’t have error detecting/correcting memory (nice job Toyota).
They found many way to kill tasks and cause unintended acceleration and they found that the fail-safes did not always work. Furthermore, they found conditions for unintended acceleration where the black box recorded “no braking” even though the brake pedal was pressed.
http://embeddedgurus.com/barr-code/2013/10/an-update-on-toyota-and-unintended-acceleration/
Thanks for that response!
I had a rental car with that kind of setup last. It was dumbest, stupidest way to shift gears I had ever seen. :smack:
Plus, the car had no traction in snow, so I had to constantly shift back and forth to get the car even out of my driveway, and I always over shot the correct gear!
Not to excuse the lack fo design and development rigor on the part of Toyota, but implementing error detection and correction in real time operating systems (which the engine controller is) is a non-trivial challenge. Error detection and the exception handling methods for correcting found errors need to operate at speed which allows the overall system (i.e. the entire powertrain) to recover or shift to a fail-safe mode, while at the same time not interfering with the normal operation of the vehicle. For RTOS applications, this is generally done with a parity bit, but the actual configuration needs to be incorporated into the overall system requirements such that the operating speed of the system can accomodate the error checking operations.
In flight-critical avionics in modern aircraft, launch vehicles, and spacecraft the OS level checking is often backed up by having completely redundant systems (three and even four are not unheared of) and performing a hash comparison at certain points (colloqually referred to as “voting”) to assure that the systems, including the computing hardware, software, and network are as reliable as they can be practically made. Even with this and rigorous software requirements specifications (which in aerospace systems are often as volumous as all of the other detail design specifications combined) errors frequently crop up as the system evolves and is testing, requiring regression testing (recursively correcting and repeating tests until it is essentially certain to a high degree of confidence that all error modes have been detected and the EDAC algorithms are robust enough to ensure fail-safe operation.)
For automobiles, where redundancy is viewed as unnecessary cost and code is often reused from platform to platform in order to reduce development costs, the rigor of both design and test practices may be reduced. I suspect that this problem is not limited to Toyota (and in fact have experienced a firmware related glitch on another model of car from a different manufacturer which could have resulted in a safety-critical failure). As real time embedded systems are progressively intregrated into more and more safety-critical systems (and errors are copied from system to system without thorough regression testing) the issues and occurance of software-iniitated failures will likely increase.
There are not, as far as I am aware, an IEEE or ACM standards governing the application of EDAC requirements to commercial hardware, and so every manufacturer implements safety systems as they see fit, which given how often code and parts of embedded systems are reused across products is an invitation for disaster. We’ve seen this on the aerospace side as the pressure to use Commerical Off The Shelf (COTS) hardware and software has been driven by perceived cost savingings only to have to go to such lengths to test, modify, and implement additional robustness in order to insure the necessary degree of fault tolerance that the overall cost is as much or greater, and with lower functional reliability, as the more tightly controlled mil-spec components.
Stranger
-My 72yo. mom drove her big mercury ‘lead sled’ into the local post office, no one hurt but her, she did bruise her chest, when rebuilt, they put up big metal poles set in concrete. WHY- she kept pushing on the gas-not the brake, this thing had a huge brake pedal and the gas pedal was a pinky width away[I checked]. I thought I read many incidents were with the ‘elderly’?
It’s called pedal misapplication. The driver is convinced that they are on the brake when in fact they are on the gas.
I did this once 30 years ago I shifted into R from P without my foot on either pedal. The car surged back a bit faster than I liked so I put my foot down on what I thought was the brake. Wrong it was the gas. The difference between me and most of these cases is I realized I had screwed up so I instantly lifted my foot moved it to the left and put it down again.
Are you saying the control software is flawless? Despite the confirmed bugs?
Either you didn’t read any of the details of the software/hardware analysis or you don’t understand the implications.
Actually I not only read the link, I read the PDF of his trial testimony. I was responding to auntlohimein’s comment about his mother and her Mercury “lead Sled” which in most likely hood doesn’t have an electronic throttle, and for a fact does not use the same software instructions that Toyota uses.
Look up and read about the Audi unintended acceleration fiasco of the 1980s. The final root cause of all of those incidents was pedal misapplication. Here you can read what the NHTSA(PDF) has said about pedal misapplication
So are you saying that people never step on the wrong pedal, despite the evidence to the contrary?
If the “glitch” is a logic error, then it is far from certain that it would affect all cars in all situations. Software bugs tend to clump into orders of magnitude of complexity. Difficulty in reproduction tends to correlate to difficulty to diagnose, not unlike mechanical problems or health problems. Often many conditions have to occur in just the right order for a bug to manifest itself. Bugs can be a simple logic error, something more complex like a memory leak, or in some cases emergent flaws after integration of multiple complex systems that would not be evident in any of the systems in isolation.
I know very little about CPU design but error detection at this level does not detect logic errors, it detects hardware failures. If a programmer typed “x && y” when he should have typed “x || y” no CPU is ever going to figure that out. Being able to simulate the acceleration behavior by forcing a bit to flip in no way proves this to be the cause of the behavior “in the wild.” Suppose you went to your doctor and said, “I can’t move my shoulder, I have this stabbing pain sometimes, but it doesn’t hurt right now.” And the doctor shoves a 6-inch needle into your shoulder and says, “Does it kind of feel like that? Well, don’t shove any needles into your shoulder and you should be OK.”
This is a fine explanation, of which I’ve excerpted only a part, but I believe this reinforces my point that this type of error detection, especially when we talk about parity checking, is for hardware or very low-level flaws in a system, not for software logic errors. There were four synchronized computers on early Space Shuttle flights although I’m not sure that operations were compared, or if they were just hot backups in case of total failure of one or more computers. I worked on a Stratus system in 1987 that was branded as IBM System/88 at the time. It had two parallel processors that would compare results. Again, this is executing the same instructions at the same time to ensure that there is no low-level failure causing a fault. If there is a software bug, that bug will be faithfully reproduced by both processors.
Your post started with the title of this thread “Was the…ever figured out” and you stated “pedal misapplication”, I interpreted that to mean you thought there was no possibility of hardware/software error in the Toyota situations.
Looks like I misinterpreted your post.
You trust the NHTSA to determine after the fact what the cause was?
I don’t because there simply isn’t enough money available to perform an exhaustive analysis.
I think most unintended accelerations are most likely operator error.
I’m also quite sure that any electronic control system as complex as Toyota’s is not perfect and therefore some cases are almost for sure not operator error.
Bits flip in the wild all the time which is why ECC/EDAC were invented.
I have personally used a Sun system that famously did not have ECC in the CPU cache and we would get memory errors about once a month which would essentially shut down the tasks on that cpu.
Certainly flipping a bit manually does not prove this to be the cause “in the wild”, but given the number of different flaws found and different ways to cause the acceleration, the chances that the control system are responsible for more than 0 raises quite a bit.
Just using the bit flip alone you could calculate a very approximate frequency of causing this problem.
It’s unclear what point you are making.
When bits flip in cache/memory/registers/etc. the software that is running can encounter problems.
In this case, a particular bit flip causes the exact problems reported due to software failure.
Toyota also had two other issues- pedals too close together and bad floormats.
In fact the NHTSA did not ascribe any failures on Toyota’s to “operator failure” iirc.
Toyota has been doing some pretty good dis-information spreading and astro-turfing, it seems.
There is one huge difference you are overlooking is that the Audi’s in the 1980’s had mechanical throttles, and the computers had no way to open the throttle as it was connected by a cable to the accelerator pedal, they were not fly by wire systems as is common now.
Also a huge percentage of the Audi’s involved in UA incidents were either being driven by new to Audi drivers that had recently come over to the brand from large American cars which have the pedals spaced differently than the Audi does, or elderly drivers. Interesting computer bug that only affects new owners and elderly people, wouldn’t you say?
Also Road and Track were able to duplicate pedal misapplication by rigging a car to get the idle motor to open wide (giving about 3,000 RPM) via a switch on the passenger’s side of the car. They then invited drivers to come test drive these cars. They would have a driver backing around a corner and hit the switch. A very large percentage of the drivers hit the gas, and stated they were hitting the brake. The in car video showed they had hit the gas. Shit happens.
When I first heard about Toyota’s issues, I was shocked to learn of the lack of redundancy in the system,and I recall commenting at the time to several technical types I know that I was fairly sure there was software bug somewhere as some of these Toyota crashes didn’t match a standard pedal misapplication scenario.
I am in no way attributing Toyota’s issues to pedal misapplication, but PM does exist, it has been proven to exist and not every accident where “the car ran away uncontrollably” is a software issue.
I wasn’t implying the Audi thing was software, just that I don’t trust conclusions when there is limited data to reconstruct the past.
The best they could do is rule out some form of detectable failure after the fact, and in the absence of that assume it was operator error.
I completely agree.
We got a recall notice for our Honda Odyssey. The recall is for a problem that causes the brakes to lock up while driving. This is not user error - the brakes lock up even though the driver is pressing the accelerator and is not touching the brake pedal. You can read about how the problem was discovered at the following links:
Honda Couldn’t Find The Problem – Hometown Did, Now A Honda Recall
What Did We Find? & How Did We Find It?
Note that the problem was originally found in a Honda Pilot but it affects Honda vehicles with Vehicle Stability Assist, which is why our Odyssey was recalled.
This is evidence that these sorts of problems are not always user error. If the garage which found the problem had dismissed it as user error the problem would probably still be undiagnosed and the people it happened to would still be blamed for causing it.