After losing verdict, Toyota settles in sudden acceleration case

Didn't NASA check the software and find it was not at fault?

 

No! Nasa tested the system and could not find an electronic fault with working cars, that was causing the problem beyond a reasonable doubt. That does not mean there was not faults that caused the accidents. Toyota prevented many investigations on autos by refusing to read black boxes.

That was a source of major anger at Toyota, and Toyota has now agreed to actually read black boxes, and have them work.

We do know that Toyota gave a wink and a nod to dealers that there were no problems, and directly worked against the NHTSA in their effort to have a brake interlock installed. They also hired former regulators to lobby against the NHTSA.

We have 2 things that toyota has admitted to problems with.

Doubled floor matts installed at dealers entrapping the pedal, leading to uninteneded acceleration.

Sticky pedals, that Toyota illegally hid from the NHTSA, and has now paid fines for hiding safety information.

Toyota did enough bad in the past to create reasonable doubt in lawsuits. We may never know if there were really electronics or software problems, but we can definitely know that if toyota had installed brake interlocks and not hidden safety information, fewer deaths and accidents would have occurred. They are best off settling, changing their behavior, and putting the incidents behind them.

 

After losing verdict, Toyota settles in sudden acceleration case - chicagotribune.com

 

Juries and courts do not always reach the correct scientific decision.

History will show many examples of humans making decisions that are non-technically supportable.

The most current example of this are the lawsuits that bankrupt the Blitz Gas Can manufacturer.

The Last Week: How Lawsuits Doomed an American Icon « Faces of Lawsuit Abuse

 

It is interesting to me that we have not heard much from sudden acceleration since this case and the media blitz that followed, along with the copy cats that followed. As far as I know Toyota has not modified the software in all of their vehicles in the meantime. So if this was the fault of Toyota's software would not one expect many more events such as this?

 

i would.

 

The Prius brake transition delay problem described above is a totally different issue than the sudden acceleration that was supposed to be the topic of this thread.

I get the brake transition issue every now and then but accept it as a characteristic of regen braking and do not really see this as a problem.

I fully agree that Toyota could definitely improve on their software. I am sure that would be true for all manufacturers.

 

Bob,

Back when I first started hanging out on Prius Chat, I thought long and hard about what was going on in the ECU, listened to the Senate hearings on runaway Toyotas, and thought about that lady with the runaway Camry and that trooper in California. I noted the rumored existence of "Black Books" in Japan, which detailed problems in cars made by the Japanese automakers, which could not be subpoenaed across the Pacific.

I listened to the NASA story with regard to their analysis, and noted the very careful wording: That the software could not be "proved" correct, but that they didn't find anything.

I showed up here and spoke my mind about the subject; analyzed what I could from the Gen II ECU that was brought to our attention, watched videos from Toyota and others and thought about it. At that time I said that it sure sounded like firmware/software bugs. I only shut up on the subject when it was pointed out that Priuses have to have an engine limiter and brake override, lest they blow their motor-generators. And this is Prius Chat, after all.

I think I stand vindicated. And what really gets my knickers in a twist is that the black box itself was faulty and didn't record data properly.

And, as a result of all this, people have died.

I wonder how those officials at the NHTSA who bad-mouthed all the unintended acceleration cases on Toyotas feel now? Do they get demerits on their performance reviews by being too buddy-buddy with Toyota?

Sheesh.

KBeck

 

A major problem in identifying these events is that they are mixed in with similar events having other causes, and it is often difficult to separate them by cause. There is strong statistical reason to believe that 'driver error' causes many more of these events than do software, hardware, and other mechanical causes combined.

 

Good enough for me, but then I don't spend any time chasing the tooth fairy even though you would say it has never been proven she does not exist.

 

Verdicts like this make me salivate at the chance that a Google autonomous car runs over a pedestrian. Such a car should never get onto a accident. It would be completely Google's fault.

 

Are you volunteering ?
We should probably use a dead pedestrian and have the accident in space so that pedestrian or road cause can be reliably excluded.

Now, how to keep all the space junk out of the way.

 

Agreed. However, and this is the picky point: Sometimes the only way to nail a software problem is to attack it from two directions:

1. Look at the external symptoms and say, "What could have caused this". Write down a gazillion reasons. Since the engine controller is directly involved, both in hardware and software, it's high (but not proven) on that list.
2. Since the software is on the list, and high on that list to boot, really take a look at the software.

NASA or no NASA, that kind of work takes time, people with a vicious mindset, and the source code. And not just the top and medium application code, but the low level OS code as well.

In case you were wondering, there are reasons why Microsoft software doesn't end up in mission and life-safety software. Partly because the OS is Microsoft's deep, dark secret: Partly because it is (from all reports) spaghetti code dating back to DOS 1.0.

Apparently, from the EE Times article, NASA never got the OS code that runs on the engine controller. They also did not get a lot of time. And, once the Evil Software Engineers started seriously looking, they found that bit flips could cause unintended acceleration.

I'm mainly a hardware engineer by trade and training. So, during and after I do a circuit design, I pull out my evil eye, look at every trace I'm laying down, and ask questions:

1. What happens if this lead is shorted to ground?
2. What happens if this lead is shorted to VCC?
3. What happens if this lead is open?
4. What happens if this lead is shorted to the adjacent pins, if any, in either direction?

The idea is that when one of those things happen, the hardware/software system should, with high probability, detect the fault. Silent Failures are Evil. Designing parity and similar tricks so that stuck-at faults can't escape are very good ideas, especially if one can have interlocking parity areas (that is, the parity generated in one area has an end point after the beginning of the next parity area). Background diagnostics (those things that run at the same time as the system) that detect Funny Stuff are very useful: So is software that does diagnostics on boot.

And, when one writes and designs the software that diagnoses all this garbage, one does it one careful step at a time. Building fault boards to verify these algorithms and actually adding hardware that induces faults so one can detect stuck-at faults in hardware are important, too.

And everything I mentioned above is pretty much Standard Design Practice. What the NASA guys do when they send a satellite across the cosmos makes the above look silly. (In general, there are no repair trucks in space.)

For software, bit flips is what happens when Things Go Wrong in an otherwise correct design. I am not kidding now: Cosmic rays can and do come down from on high and flip bits, especially in DRAM. Especially if one is not using RAD-hard hardware. And, yeah, exposed to cosmic rays, some DRAM cells might flip, some might not, and on a sample-by-sample basis, the results one gets from this kind of thing vary all over the map. Note: This stuff is not a deep, dark secret, and it's not new, either.

So, OF COURSE one designs around these problems. Firmware loads have checksums. One can write software that, in the background, checks the RAM area for load checksums and such. Parity and ECC memory are well-known, and paying attention to the error bits when they flip up are important.

Amongst the many things in that EE article, which, unfortunately, seems to have been written by somebody who thinks that all software is an "App", was that independent software routines that should have been running could die and stop - and the overall OS wouldn't notice. That's double-plus ungood, as you might guess.

By the by: The watchdog timer mentioned in the article is an old-time favorite: If the software doesn't reset the watchdog register from time to time, the watchdog times out and resets the hardware. If having N processes all running is critical to safe operation, then there are things One Can Do that guarantee the Watchdog only gets reset when everything that is supposed to be running is running. That's another one.

The thing was: The guy who did the analysis didn't say that there was, say, a single fault: He said that there were Lots. And the equivalent of Open Barn Doors to drive them through. It sounds like he got tired of the Nth iteration through, "this mission critical byte bit-flip doesn't get detected", called a halt to it, and wrote his report - all 800 pages of it. I suspect that there were 800 pages not because the fault-finding was that complex: It was likely because he kept on repeating himself over and over and over again. Lawyers like that, but I'd hate the be the one doing the cutting, pasting, and doublechecking, especially since you could bet the automaker would be looking for misplaced commas.

And, really? Toyota never knew any of this? Sheesh.

KBeck

 

Toyota has since

- Carved gas pedals and replaced sticky ones
- modified sticky pedals
- Changed software in many existing cars that would except it
- Modified new cars, so that all new cars would have a brake interlock
- made black box readers available to check out unintended acceleration claims
- Media has made it almost criminal when toyota dealers doubled up floor matts- putting stories on local tv (this was the case with the fatal lexus case - car dealer pretending the untintended acceleration was fake, sent it out again with a different driver with doubled matt).

Toyota is acting completely differently than before the NHTSA called them out for lying about unintended acceleration being a non issue. Don't sugar coat the bad behavior on toyota's part. They covered up illegally unsafe conditions. We just don't know how far the cover ups went.

Gen III prius never had any of the reported problems, although some drivers did report unintended acceleration, none was validated, and afaik no fatalities occured from a gen III prius UI acceleration.

 

I am not trying to sugar coat anything here. I am just asking an obvious question about the software. If it was a software problem why have we not seen many more such sudden acceleration accidents?

Most of what you said above has nothing to do with the software.

Don't get me wrong, I am not a Toyota fan and think their response was totally wrong. I just do not understand why we have not seen additional incidents.

 

I have no idea if there are software or electronics problems. I doubt that they occur often if they even exist.
We do know past behavior by Toyota, along with real possibilities of problems, mean that a jury would be much more likely to find against toyota, and long court cases are not good for the company. It needed to settle and put this behind them.

I do know that if there are these problems, reading the black box immediately afterwards will help find faults. We also know that having a break interlock will prevent accidents if software or electronic problems were occurring. Toyota because of the deaths and court cases have now changed their cars to minimize the problems. The NHTSA had asked them to do this in the past and they had refused.