Class action settlement ETSC?

Which if my understanding of such things is correct, means that in 48 months time you end up with $172.88 and the lawyers get $6,325,204 and everyone else ends up losing out at some time in the future.

 

All paid for by a price increase on new Toyotas, of course.

 

Probably related to that lawsuit in Missouri where it came out that, on a bunch of Toyota models, Toyota really had screwed up. I've read the expert's report: Spaghetti code, unmaintainable, no software MR system, watchdog timers that were rigged so they didn't actually do a watchdog function, and many other sins that set my hair on fire. (I'm a EE by trade, and, yes, sometimes I do program small microcontrollers.) Toyota lost the case (a passenger died and the driver was seriously injured) and, just before they went to end-of-the-world penalty phase, which was looking like a slam-dunk for the plaintiffs, the two parties settled.

And, unlike many other lawsuits involving Large Corporations, the judge and plaintiff made darn sure that the expert's report went public. And citeable by other lawyers. Sounds like a cheap thrill for some Canadian lawyer and a fall-down with a feather hit by Toyota: They'd have a hard time trying to claim it was operator error with that expert's opinion on the open web down in the U.S..

KBeck

 

This the thread you were looking for?
After losing verdict, Toyota settles in sudden acceleration case | PriusChat

KBeck

 

First: The Prius has it. Stomp on the brakes and the gas at the same time and there's software that detects the brake, overrides the throttle signal, and depowers the engine. So you don't have to sweat the problem.

Second: There's a large number of cars from random manufacturers that don't do that.

1. Any old-time car with manual cables and such between the throttle/air intake/whatever and Just Standard Brakes.
2. Many (but not all) of the fly-by-wire cars where pressing on the gas pedal controls a rheostat or some other sensor whose signal goes to a computer that, in turn, controls engine power. That turns out to cover a lot of ground: My wife's 2008 Sienna works that way, as do most modern cars.
   1. On some of these cars, there's software that detects if you're trying to brake; if it detects that that's the case, no matter what the controllers perception of what the accelerator pedal is doing, power from the engine is either reduced or zeroed.
   2. On other cars the engine controller has no input from the brake system, so, if you're braking and accelerating at the same time, you get brakes and power at the same time. Which is, nowadays, considered a Bad Thing.

Toyota's problems in this direction have mainly to do with cars built to the 1.2 standard above, which included many Camrays. In the car involved in the U.S. lawsuit, it was unequivocally proved that the controller software was unmaintainable, full of bugs, primed to kill itself without a whole lot of work, and further shown that in the presence of Death, backup Kill features (watchdog timer) were both poorly designed and turned off in order to get the thing shippable. Toyota also lied to NASA about other hardware features (that might have saved the day in case of the inevitable controller interior corruption) being present when, in fact, they weren't, leading NASA down the wrong path when they tried to analyze what might be going on. (Said mention of the presence of ECC RAM was redacted in the public NASA report - precisely so neither the public nor NASA might ever find out about Toyota's falsehoods.)

While there were tons of bugs of many different flavors, the one that really got to me was there was a high probability that if the controller snozzled itself (high probability) the throttle on the engine would get stuck where it was, and nothing besides turning the car completely off would fix the problem. So, if one were on an on-ramp accelerating to speed and Something Happened in there, one would be stuck with a car that wouldn't stop.

Because the process that handled the throttle also handled DTC codes, anything that killed the throttle control pretty much killed the DTC process so nothing would get saved (ha!); further, this is the same controller that handles that pretty "START" button on the dash. So, in the huge plethora of things that Could Go Wrong, not being able to actually turn off the car is one of those.

Given that it appears that Toyota had lots of chances to know about all this everything that they've done to blame the consumer has to be taken with a big grain of salt: Were they really that ignorant, or was the almighty dollar driving their decisions? Not having a working MR system on their software didn't help any: Any of you involved in major software or hardware development know just how evil that is.

In any case, Big Solid Books were thrown at Toyota during the lawsuit in the U.S. and laid Toyota low. Given that Toyota was lying while people were dieing that sounds very reasonable to me. Sounds like some lawyer in Canada has found the book (no kidding, 900 pages!), reared back, and got set to throw: Toyota saw and folded. Quickly.

By all reports newer cars from Toyota have rejiggered the software, cleaned up the worst of the mess, and have added a brake override. Said override is being retrofitted to certain older cars in the U.S., although exactly what this override looks like I don't know. Likely it would be a reflash of the controller code at a minimum; a new computer box at a maximum, and who knows what inbetween.

Longer term questions of whether one trusts Toyota to carry a dollar across the street is another issue. And why nobody is in jail is another.

KBeck

 

What the heck is an "EE". For starters...

 

Electrical or Electronics Engineer. Not to be confused with the Elementary Education types.

KBeck

 

and "working MR system" ?

 

It's interesting, in the States: every service interval starts with "check installation of driver's floor mat". In Canada it's never mentioned.

 

Less layers per person in CA.

 

Don't know where the term started, but it means, literally, "Modification Request System". Usually, what you have is a serialized list of defects. Defects can be generated by:

1. Normal code development. Weirdly enough, the idea is that one has to have an MR before code can be transferred to the repository, so "Scheduled Work" counts as a defect.
2. Faults found when unit testing the code.
3. Faults found when integration testing the code (i.e., does it play well with other code?)
4. Faults found when system testing (i.e., when the entire software load is running, What Went Wrong is recorded.)
5. Faults found during stress testing.
6. Faults found in the field.

Each MR gets an explanation of what was found, severity (1=It's dead, Jim, and there's no workaround, 2=it barely works with some cruddy workaround, 3=there's workarounds, but it's ugly, 4=it oughta be fixed, but it can wait, 5=Next release, feature enhancement). Your severity list and where the numbers go is up to you.), log files, other data. Once the thing is worked on, analysis results, what was changed, etc. is put in; when fixed, results of the testing, test cases run, etc., and it gets Closed when the bug is exterminated.

The general idea is that MRs get generated on the drop of a hat; "Close - No change" handles those cases where the tester (whoever said tester might be) got the fault wrong. In general, one never ships a blame thing with any Sev 1 MRs around, Sev 2's are extremely unlikely, and a limited number of Sev 3's might ship. This is why Quality Assurance has an existence.

And MR systems aren't just for software, although, natch, they're dead useful over there. Circuit design, hardware design, documentation, you name it. Whenever there's crowds of people building things, MR systems aren't just a nicety, they're required. An MR against software can, if needed, be pushed up to system engineering; a system engineering MR (i.e., the system requirements had a bug) can result in new MRs being spawned to multiple software and hardware systems.

It's possible to bury a development organization in the bureaucracy of an MR system, but the general idea is the Common Sense rules. Such a system is also wonderful for institutional memory, preventing nasty bugs from being forgotten, especially when the Next Software Release comes by, or some developer takes a hike out the door. It also tends to keep gung-ho, "We can do it yesterday!" management types under control, because it's sure hard to claim everything is sweetness and light when there's Sev 1 and 2 showstoppers or so many Sev 3 faults lying around that the phrase, "It's hard to remember that our original objective was to drain the swamp when we're up to our nice person in alligators" becomes pertinent.

The point here is that it is inevitable that People Make Mistakes. Even when they're trying not to. So, into this morass of broken software and hardware we throw quality tools, where the definition of a quality tool could be, "A method of detecting and correcting errors." Look, I'm a grunt-style in the trenches design engineer, and no expert on the topic: But, when it comes to QA, I'm not joking when I say that there are people with degrees and journals devoted to the subject. Most of the furor tends to be concentrated in the Industrial Engineering profession, although it's hard to imagine any professional design type of any stripe who hasn't run into this stuff at one point or another.

MRs and Code Version Repository (CVS) systems are usually linked, tightly or loosely. CVS systems are available all over the place (github, unix/linux cvs, tons of others, including lots of paid-for applications for the purpose) and are so wildly useful and human-error-killing effective that individual developers writing 2000-line stand-alone programs often use the things. It gets difficult to remember the details of that bug that was thought to have been killed last year when it rears its ugly head again, and so on.

And MR systems aren't just for software, although, natch, they're dead useful over there. Circuit design, hardware design, documentation, you name it. Whenever there's crowds of people building things, MR systems aren't just a nicety, they're required. Assuming that you want a product that works, and, in Toyota's case, doesn't kill people.

So, reading the transcript of that Missouri trial and discovering that Toyota hadn't been running an MR system on the engine controller software... There're not enough gibberish keys on my keyboard to express my astonishment over the fact. It's not like this stuff is a new development - I've been working with this kind of stuff since the mid 70's, and it predates that by a heck of a number of years.

KBeck