U.S. finds no defect in Toyota's electronic throttles

U.S. finds no defect in Toyota's electronic throttles Laurn Abdel-Razzaq Automotive News -- February 8, 2011 - 1:55 pm ET

DETROIT -- The U.S. Department of Transportation announced today that electric systems and electromagnetic interference did not play a role in the incidents of unintended acceleration involving Toyota Motor Corp. vehicles.

It was a major victory for Toyota, which has sought to recover from a recall crisis and accidents allegedly linked to unintended acceleration in some of its top-selling models.

"There is no electronic-based cause for unintended high-speed acceleration in Toyotas," U.S. Transportation Secretary Ray LaHood said in a statement to Reuters.

The National Highway Traffic Safety Administration launched the study 10 months ago at Congress' urging. With the help of NASA engineers, the study sought to determine if cases of unintended acceleration in Toyota and Lexus vehicles were caused by something other than sticky gas pedals and trapped floor mats.

In August, the government said it had not found any problems with the software-driven electronic systems in Toyota vehicles during the first six months of the study.

Toyota, which has had electronically controlled throttles in its vehicles since 2002, has said its own tests ruled out electronic interference as a possible cause.

Global recalls

Toyota has recalled more than 18 million vehicles globally since the fall of

2009 -- including more than five million for floor mats and more than four million for gas pedals.

The Japanese automaker has already paid $48.8 million in fines in three separate penalties and faces hundreds of lawsuits. The biggest previous automaker fine was $1 million paid by General Motors Corp. for windshield-wiper failure in vehicles made in 2002-2003.

Regulators are looking into 89 deaths that may be associated with unintended acceleration in Toyota and Lexus vehicles but have so far linked only a handful to the floor mat problem.

Although the investigation turned up no flaws that would prompt another massive recall, Toyota still faces significant risks from scores of civil lawsuits stemming from the recalls.

Those cases in federal and state courts, which may turn on the timing of company disclosures to regulators of already established defects, have an estimated potential liability of up to $10 billion.

Reuters contributed to this report

Read more:

formatting link

Reply to
C. E. White
Loading thread data ...

I can accept this. As I have said before, we own two Toyotas, and trust our lives to them every day, with never any sort of problem. That doesnt mean that no one has ever had some sort of problem, but I havent detected one.

Those who dislike Toyotas and most other things considered unAmerican, I am sure, will not accept this report, and that is fine with me too.

Reply to
hls

I'd be more willing to suspect a race condition in the software than EMI issues, in part because EMI issues are pretty easy to test for. In the past, Toyota has had more electromagnetic compatibility problems than some of the other manufacturers (and in fact Ford seems to be more careful about it than anyone, in part because Ford markets to police departments that want to put high power radios in cars), but you'd think if it were an EMI problem it would be fairly easy to replicate.

The problem with race conditions is that they aren't usually easy to replicate, and that's bad for the people on either side of the debate who want to really figure out what it is.

I think people need to learn how to shut their damn cars down in an emergency. There's a reason you have a prindle....

--scott

Reply to
Scott Dorsey

The NASA folks supposedly examined all of the source code for the PCM and found no software faults. Embedded software for real time controls like a PCM are written quite a bit differently from common software, and generally use no interrupts, multithreading or subroutines. They generally can not have a race condition.

Reply to
Pete C.

That's correct (in theory) but in practice the underlying hardware might be faulty. In my lab I once found a common commercial PC motherboard that _very occasionally_ gave two sensors simultaneous access to the same

16-bit bus (signal pathway) at the same time. When something like that happens all bets are off and the problem is not reproducible.
Reply to
Jack Myers

If you read the paper, they're basically saying they did a code review and didn't find anything obviously wrong. This doesn't mean there isn't something wrong, but it does make it less likely.

They didn't do actual code verification, which isn't surprising since that's a difficult thing to do even on code that is designed to be verified. But until there _is_ actual code verification and correctness proof, as is used in aircraft ECU applications, then you don't really know.

And even WITH that, there have still been wacky interaction issues (which you could argue were hardware or software issues depending on your perspective) with proven code in aircraft ECUs.

So... the answer is basically that the chances are pretty good the Toyota software is clean, but that complex software systems should never be trusted completely. So know where your prindle is and learn how to use it.

--scott

Reply to
Scott Dorsey

Well of course the software is clean. the software in the RTOS that controls the throttle works as intended. But when some not discovered outside event happens the software goes into a undefined state and this could happen. I remember doing some events with the military where high ranking officers would come up to the podium and talk and of a sudden there was strange noises in the sound system unexplained. Took awhile to figure that one out. Turned out their blackberry's were interfering with the sound system. Solution, go up to speak with all blackberry TURNED OFF! That comes under the heading of unexpected interference event.

You can look at Microsoft products operating systems for an example. how many times have they been patched? Hundreds. for products that were supposedly ready for prime time and work as expected most of the time. But unexpected events happened (hackers, sequence of operations and such) and the software was re engineered. Nobody stops using windows because of this. But it being continually updated for such things.

Do you NOT think Toyota is doing the same thing? My question to anyone with one of the suspect cars: have you had your computer(PCM) replaced or reflashed for ANY reason since this has happened under warranty or recall? Do you NOT think toyota was madly working behind the scences on any kind of code updates that would prevent some of these unexpected events? and do you really think they are going to tell you that was what the update was for? Hell no! I am sure if done, they will just tell you it was an emissions update or such. Or, they recalled some seemingly unimportant item on the car and updated the code without telling you. I think legally there suppose to put a sticker somewhere when they do update the PCM for emissions. Not sure if that applys to other issues.

My brother in law just took his corolla S into the dealer last week for some warranty repair of door molding that would always leak, and a slight rough idle at times. He came out of that deal with a NEW PCM. He did not ask for one. And no real explanation of why. Makes me wonder...

He has had small continuing issues with that car since he bought it. Now, he wants to trade it off for a Honda. Five times into the dealer for warranty work was enough for him

bob

Reply to
bob urz

That's what code verification prevents. It describes every possible path through the code and what can happen in every case.

Unfortunately this requires putting some severe limitations into the code.

That shouldn't have been unexpected at all. GSM waveforms are really annoying, and sound systems that are well-designed don't have issues. You design the system properly, you test the system properly, and everything is fine. But, that also isn't a software issue and it has nothing to do with software issues. We're talking about software issues, not EMI. EMI is a different issue altogether.

Sure, but that's because Microsoft software is putrid garbage written by incompetent morons. If anything, Microsoft has reduced the public's expectation of system reliability. This is not the normal state of affairs of software.

Just because Microsoft releases worthless code to the public without doing any testing at all does not mean that proper testing is impossible or that code verification is impossible. Code verification is a huge step above exhaustive testing, and the aviation folks consider it essential for using software in mission critical environment.

No, I certainly don't. Nobody doing any kind of embedded control work, even the folks making toasters and microwave ovens does that kind of crap. That kind of crap gets people killed in the embedded world. Hell, competent applications programmers don't even pull that kind of stuff.

You seem awfully paranoid about this. Sure, that kind of thing could have happened but I don't see any reason to think it has.

And if if has, then the problem will stop once everyone gets updates, and then you'll know.

Often there are PCM updates. One of the nice things about software is that it's effectively free to update.

--scott

Reply to
Scott Dorsey

Oh, also looking at the report, there isn't really any RTOS, just one big loop.

--scott

Reply to
Scott Dorsey

Similar, but different story. Guy working for Walgreens told this to me in an IT class way back. An old batch program had worked flawlessly processing hundreds of thousands of transactions nightly for years. Big program, still using cards then, and it was thousands of cards. Then it blew up. Took him and 2 other guys working on the dump all night to figure it out. There was not a single error in the transactions. First time it had happened. The solution was to add a null transaction with an error to the front of the deck.

Never had a Toyota and probably won't, but I agree with Scott if he's saying know how to shut your car down. Got no idea what "prindle" means. Too many Toyotas running around to be serious problem with them.

--Vic

Reply to
Vic Smith

That kind of "one big loop" structure is common in this type of high reliability application. Every section of code it executed every pass through the loop. Every section can be tested against all possible values of input parameters. I believe each section is normally padded with null instructions so that the execution time through the section is always the same regardless of the input parameters so that there is no timing jitter in the loop.

Reply to
Pete C.

"Pete C." wrote in news:4d531c85$0$18776$ snipped-for-privacy@unlimited.usenetmonster.com:

All I know -- and I do know this -- is that the electronic throttle is designed such that, on the slightest, tiniest, most insignificant non- compliant signal or logic input, the throttle shuts down. Period.

Plus, it is not possible to alter the coding, or the content of any of the chips. Any data buses are unique to the throttle, and are carefully isolated from any other signal paths. There is NO sharing of signal paths between throttle-control and any other sensors.

As of this date, the ONLY problems that have been clearly tied to the electronic throttle have been those early Canadian-made pedal assemblies which suffered mechanical corrosion that led to the pedal sticking slightly. And none of those have been implicated in a single crash, injury, or death. In all reported cases, the drivers were easily able to use the brakes to bring the car to a stop, or to pull the pedal back up with a toe.

The conspiracy theorists will need to find another target. Fluoride is still a big one, as are nanobots and chemtrails.

Reply to
Tegger

Right. This makes testability a whole lot easier and it also makes some kinds of runaway errors easier to find than interrupt-driven scheduled systems. It also makes some harder. Oh, well.

Overall, though, it's a really good architecture for this sort of thing.

--scott

Reply to
Scott Dorsey

I'm not sure I like that failure mode either.

I have had plenty of throttle cable failures on carburated cars, some sticking in one direction and the other sticking in the other direction. None of them killed me or made me more than just annoyed at Volkswagen and Fiat designers. But that's because I knew how to deal with the problem.

I don't know what caused the problem, but I do know that cars break down, they break down in sometimes unpredictable ways, and so any reasonably well-trained driver should know how to deal with things when they break down. If all else fails put the prindle in neutral, coast to the side and then call the dealer...

---scott

Reply to
Scott Dorsey

That is the crux of the matter - driver competence or lack thereof.

Reply to
Pete C.

"Prindle" = PRNDL, a.k.a. Park, Reverse, Neutral, Drive, Low

Reply to
Pete C.

Aha! Thanks.

--Vic

Reply to
Vic Smith

To the contrary, the report addresses hardware interrupts, software tasks, and task priorities. I don't want to take sides; I especially loathe redacted reports, which are a diversion and a waste of time. There should be more analysis of metastability issues where signals cross clock domains. It's especially interesting that a level-set value is associated with each of the throttles.

Reply to
Jack Myers

Well, yes we can be. Its a known fact that cosmic rays or other interference can change a byte in a dynamic ram chip. Some value in the program that changes because of this can cause software issues. I don't personally know if Toyota uses ECC ram in there PCM that would help get around this to an extent. If they did and was properly designed, the operating systems would have a better chance of detecting this kind of error and deal with it.

Even in sound systems, there are unexpected events. In another life, i delt with issues in sound systems. Had a new catholic church once that was getting noise through direct boxes and micropohones at certain times and locations. System was installed by respected local contracor. Designed by respected consultant. All Should have been alrite, but it was not. I came in a verified issues that seemed strange or impossible. Or were they? In this case, i found that dynamic mikes and transformer direct boxes on the floor were picking up noise in certain orientations. Tried different mixers, no change. I then used a dynamic mike as a "witching stick". Then a patten developed. You could track the noise in the floor. Then i asked different questions. Turned out the electrical feeders for the lighting system were buried in plastic conduit under concrete in the area that was having issues. When the dimming system (professional unit) was at 70%, it was radiating noise out of the buried in the floor electrical feeder and the dynamic mikes elements and on the floor direct boxes were picking up this magnetic hash and it got into the sound system. It was good gear. Good sound system design. But another contractors/consultants design of electrical feeder placement caused unexpected issues.

Look at the biggest portion of microsoft (or others for that fact) updates are. There not for a function not working in a normal environment. There because some malicous hacker haas found some obscure issue he can exploit to infect a computer. Issues NO one would have thought about checking under normal software verification. I just read today about how someone has thought of a way to turn smart phones into a bot net. Go figure.

One can only hope that if they did update any of the code to deal with unexpected states or events, that this would make the cars safer. But the public probably would never be told of what got changed and why. It would create a liability issue for Toyota to admit anything could be wrong. They would just take there cars in for warranty repair or emissions recall and the PCM would quietly get reflashed with newer code.

I had been through similar problems and denials with my old 1990 ford Taurus. I had my subframe com detached from the uni-body causing some steering issues with the car. lucky for me, it happened at low speeds and no accident was involved. But it could have caused an accident or injury under the right conditions

What had happened was a long bolt went through a large metal washer which bolted the subframe to the unibody of the car. Due to road salt and corrosion, the bolt pulled through the rotted away large washer and caused detachment of the subframe from the car. Once i found out what caused the problem, i did some research and found i was NOT the only one. Found others on the internet with the same issues. called ford, they denied ANY problems. And that was even though they had issued a secret recall in "11 salt prone states". I even told the Ford rep on the phone the secret recall number and they still denied any issue. Well, six months to a year latter i finally got a recall notice for the subframe bolts in the mail.

by then i bought my own parts and fixed the issue long ago. But why did the manufacture have to lie about a obviously known issue?

Its only free during the warranty period or recall. After that, a PCM reflash will likely cost $100+ at a dealership when all is said and done. Its not like you can download it to your PC and update your car with a flash drive or such. It takes dealer specialty tools to do it for the most part that are NOT cheap. And then access to the control files which are not free either.

bob

Reply to
bob urz

Well, the honest truth is that we have a vast amount of technology being put into vehicles today in an attempt to substitute for driver competence.

In the end I suppose I am resigned to the whole thing, because the technology is a lot cheaper and easier to install than insuring driver skill would be.

--scott

Reply to
Scott Dorsey

MotorsForum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.