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

Scott Dorsey wrote:
>
> bob urz > wrote:
> >Well of course the software is clean. the software in the RTOS that
> >controls the throttle works as intended.
>
> Oh, also looking at the report, there isn't really any RTOS, just one big
> loop.

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.

"Pete C." > wrote in
ster.com:

>
> Scott Dorsey wrote:
>>
>> bob urz > wrote:
>> >Well of course the software is clean. the software in the RTOS that
>> >controls the throttle works as intended.
>>
>> Oh, also looking at the report, there isn't really any RTOS, just one
>> big loop.
>
> 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.
>


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.

--
Tegger

Pete C. > wrote:
>Scott Dorsey wrote:
>>
>> bob urz > wrote:
>> >Well of course the software is clean. the software in the RTOS that
>> >controls the throttle works as intended.
>>
>> Oh, also looking at the report, there isn't really any RTOS, just one big
>> loop.
>
>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.

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

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Tegger > wrote:
>
>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.

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

>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.

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.

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

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
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey wrote:
>
> 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.

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

Vic Smith wrote:
>
> Got no idea what "prindle" means.

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

On Wed, 09 Feb 2011 19:40:21 -0600, "Pete C." >
wrote:

>
>Vic Smith wrote:
>>
>> Got no idea what "prindle" means.
>
>"Prindle" = PRNDL, a.k.a. Park, Reverse, Neutral, Drive, Low

Aha! Thanks.

--Vic

Scott Dorsey > wrote:
> bob urz > wrote:
> >Well of course the software is clean. the software in the RTOS that
> >controls the throttle works as intended.

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

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.
--
Jack Myers / Westminster, California, USA

Aibohphobia: The fear of palindromes.

On 2/9/2011 9:49 AM, Scott Dorsey wrote:
> bob > wrote:
>>
>> 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.
>
> 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.
>
>> 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.
>
> 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.
>
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.



>> 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.
>
> 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.
>
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.



> 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.
>
>> Do you NOT think Toyota is doing the same thing?
>
> 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.
>
>> 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.
>
> 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.
>
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?





>> 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
>
> Often there are PCM updates. One of the nice things about software is that
> it's effectively free to update.

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

> --scott

Pete C. > wrote:
>Scott Dorsey wrote:
>>
>> 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.
>
>That is the crux of the matter - driver competence or lack thereof.

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
--
"C'est un Nagra. C'est suisse, et tres, tres precis."