Toyota's Engineering Process and the General Public

Doofus writes "The Washington Post has published in today's paper an article titled 'Why it's so hard for Toyota to find out what's wrong' by Frank Ahrens on the Toyota situation and the difficulties of adequately conveying to Senators and Representatives — most of whom are non-technical — the debugging process. Ahrens interviews Giorgio Rizzoni, an 'expert in failure analysis' at Ohio State, who describes the iterations of testing that NHTSA will likely inflict on the Toyota sample cars they have purchased, and then moves into the realm of software and systems verification: 'He explained that each vehicle contains "layers of computer code that may be added from one model year to next" that control nearly every system, from acceleration to braking to stability. Rizzoni said this software is rigorously tested, but he added: "It is well-known in our community that there is no scientific, firm way of actually completely verifying and validating software."' Ahrens ends the piece with a quote from a 2009 LA Times interview with former UCLA psychology professor Richard Schmidt about how user reports are often unreliable: 'When the driver says they have their foot on the brake, they are just plain wrong. The human motor system is not perfect, and it doesn't always do what it is told.'" Toyota is currently planning an event to challenge evidence presented by professor David W. Gilbert that called into question Toyota's electronic throttle system.

Comments

"An event to challenge Evidence"

[Oxford_Comma_Lover]

> Toyota is currently planning an event to challenge evidence ...

Macroscopic events generally don't challenge evidence. They challenge the politics of evidence.

One challenges evidence with small, discrete, verifiable events.

Re:"An event to challenge Evidence"

[Pieroxy]

So GM went under and nobody talked about it. Now Toyota has a massive recall and all about GM is forgotten. Instead of criticizing foreign car makers (even if they deserve it), can the Americans bury decently their own car industry? Isn't that worth a minute of silence?

Re:"An event to challenge Evidence"

[ItsJustAPseudonym]

What? You advocate that the public should continue to be injured in and by Toyotas, because GM was a train-wreck? Freaking absurd!

Nobody talked about GM? Ha, what a bunch of B.S.! U.S. politicians and the public beat the SNOT out of the issue, trying to decide whether or not to bail out GM, and what conditions to impose. The US government gave money to banks faster and easier than they gave it to the auto companies. You've got selective-memory now.

Toyota deserves the same scrutiny of any other company whose products endanger the public. When Firestone tires were failing on Fords, both companies were taken to task for it, big time.

Various Toyotas are now having acceleration and/or braking problems. So, no, it is not worth a minute of silence for GM.

Re:"An event to challenge Evidence"

[joker784]

Found the original Gilbert testimony - a very interesting 5 page read: http://energycommerce.house.gov/Press_111/20100223/Gilbert.Testimony.pdf

Re:"An event to challenge Evidence"

[digitalunity]

Don't be stupid. Toyota is marginally more foreign than GM. They both buy parts heavily from foreign manufacturers. Toyota itself, although based in Japan, has been assembling cars right here in the US for over 30 years.

I'd rather buy Toyota than shop at WalMart.

GM isn't forgotten. I'm just hoping they complete this death spiral to its finality. They've been producing a glut of crappy cars(and a few great ones) for a very long time. I blame the auto unions as much as the workers for this - they resisted automation and the end result was a heavily debt saddled company with too many workers and low value products.

I'm ashamed that my government felt compelled to save a company that should have seen its own demise 20 years ago and refused to make the difficult decisions needed to stay competitive.

Re:"An event to challenge Evidence"

[thePowerOfGrayskull]

While your post is offtopic to the comment you're replying to, I agree it was an interesting read. However, the entire testimony has one fundamental flaw: it assumes that because a situation can be induced in which no error code is set, that that exact same situation can occur in the absence of being induced.

The entire testimony is built on that unproven assumption, without venturing to explain how it could occur in normal operations.

Re:"An event to challenge Evidence"

[thePowerOfGrayskull]

An apt comparison might be something like this:

int x = 1;
int y = 2;
// Code proceeds on assumption that x != y

Of course if someone goes in with a debugger and forces x == y, then the code will fail. However, that doesn't mean the scenario is plausible or even possible to begin with.

Sadly, none of the senators reading the report will have enough understanding to realize that simple fact, or even to ask the right questions.

Re:"An event to challenge Evidence"

[blincoln]

Of course if someone goes in with a debugger and forces x == y, then the code will fail. However, that doesn't mean the scenario is plausible or even possible to begin with.

Working with electronic and/or mechanical systems is a lot different than working with pure software code. Read up on switch debouncing to start with, and you may begin to understand. Designers of those systems - especially ones that can kill people when they malfunction - must take into account things like what will happen if there's an electrical short or some other unexpected deviation from the intended design.

Re:"An event to challenge Evidence"

[KarmaMB84]

Either one of the values could end up being reported as a different value then what is set there. Bad memory or processors cause computer crashes or just plain strange behavior all the time.

Re:"An event to challenge Evidence"

[haruharaharu]

That's why you do things like lock the input/output to sane values and have a default failure mode for just about everything. The thing that bothers me is the idea of a wholly electronic gearshift; I love my manual cars for a lot of reasons, not the least of which is that, with runaway throttle, I can clutch in any time I want to.

Re:"An event to challenge Evidence"

[thePowerOfGrayskull]

True, this is outside of my are of expertise. Yet when you have a virtually infinite number of possible failure combinations (when taking it down to the transistor level), it seems that there must come a point where you say "this is what we can reasonably handle".

Re:"An event to challenge Evidence"

[Lehk228]

but if you sent x and y to a remote system (which a sensor is) then just assumed that when you asked that remote system for x and y that the answer is safe and sane without bothering to check, you are negligent.

Re:"An event to challenge Evidence"

[sjames]

More like:
x=inb(some_port);
y=255;

Where some port is from an AtoD converter. All is fine and dandy unless somehow the input pin gets shorted to Vcc OR Vcc drops too far below 5V. Then all hell breaks loose.

Re:"An event to challenge Evidence"

[blincoln]

My understanding is that the way this sort of thing is handled (and this was hinted at by haruharaharu in another reply to my original post) at the component level.
If the component is something simple like a switch, then you would have hardware features (like the debouncing I mentioned) as well as potentially firmware/software-level checks of the switch. Most PCs have a simple variation on this for the keyboard input - if a key's line is held closed during POST, the PC throws an alert because it considers the keyboard broken.
For more complicated components (like a temperature sensor), the checks would be things like "is data being received from the sensor at all?" "is the data within 'sane' limits?" and so on. If any of those checks fail, then the component is treated as failed and data from it isn't processed. So in the case of the temperature sensor, if it suddenly reports that the temperature is 3 million degrees, then the thermal shutdown code is not triggered because the safety check fails the sensor first.
There are some other approaches too - IBM mainframes and the Space Shuttle computers use hardware designs where there are two or three processors doing the job that would be handled by a single processor in a normal computer. All of the processors perform the exact same task. If the results are different, then the system knows that there is a hardware failure in one of the processors. In the case of the mainframe, the processor pair in question is taken offline and the processing is handed off to one of the other pairs in the system. So effectively the system *has* error-checking of each transistor in the processor without explicit checks of them individually.
You're right in that this makes it a lot more work to design and build the system in the first place. I'm sure that's why this sort of thing is generally reserved for situations where people are likely to be killed in the event of a non-graceful failure (or at least situations where people are willing to pay through the nose for a computing system).
It's a really interesting subject to research, if you have the time. I was exclusively a software person when I was younger, and studying the hardware side of things really opened my eyes as to what was going on behind the scenes.

Re:"An event to challenge Evidence"

[drinkypoo]

For more complicated components (like a temperature sensor), the checks would be things like "is data being received from the sensor at all?" "is the data within 'sane' limits?" and so on. If any of those checks fail, then the component is treated as failed and data from it isn't processed.

In the case of a car, in OBD-II there is a "comprehensive" monitor (test) which runs "continuously" (i.e. whenever the ECU has free time) and which fails if any sensor gives bad data. If any major sensor gives bad data, the vehicle will go into limp-home mode. Regardless of how important it is to driving, if it is important to emissions, the malfunction indicator lamp (MIL) is lit on the dash. That lamp is there to tell you that something is wrong with your emissions, and that if you continue driving, you may damage your catalytic converter.

There are some other approaches too - IBM mainframes and the Space Shuttle computers use hardware designs where there are two or three processors doing the job that would be handled by a single processor in a normal computer. All of the processors perform the exact same task. If the results are different, then the system knows that there is a hardware failure in one of the processors.

And in essence this is what we need for automotive electronics. To my mind, the solution is to move to using a bus to move data around the vehicle, and to thus simplify the wiring harness as well as moving more of the wires to well-protected locations. Ideally, the signals would be carried optically, though that does somewhat significantly increase the cost. I would think however that by now you could use home audio technology for these connections, and fairly reasonably at that. It's still useful to maintain separate power wires for many purposes, not least having fuses per-circuit.

Re:"An event to challenge Evidence"

[thePowerOfGrayskull]

That makes a good deal of sense, and gives me a starting point for some digging. Thanks for the info

What?

[Nadaka]

"It is well-known in our community that there is no scientific, firm way of actually completely verifying and validating software."

How wrong can you be? Yes there is. Software is fundamentally the composition of many mathematical functions. Its results can be formally proven if the hardware it is running on is assumed (or preferably also proven) to be error free. Don't get me wrong, it would be incredibly cost, labor and time expensive, and require real computer scientists, but it is certainly possible.

Re:What?

[caffeinemessiah]

Don't get me wrong, it would be incredibly cost, labor and time expensive, and require real computer scientists, but it is certainly possible.

Speaking as a "real" computer scientist, I think you might have underestimated the time requirement. Most problems in automatic verification are either undecidable, or intractable.

Re:What?

[drewhk]

Um, Halting Problem?

Re:What?

[the eric conspiracy]

If possible means getting an answer before the heat death of the universe you are probably wrong.

Re:What?

[0100010001010011]

There's even hardware to do it. dSpace sells some very nice (and very expensive) hardware to do testing. You can setup scripts to test almost any scenario. It'll fake out all the basic sensors and then you can test to see what happens when you hit the brake at 10 mph, 20 mph, 30 mph. You can do burn in tests. Software is very very repeatable. You can often trace right through the Simulink model and find out what is going on.

In the latest versions of CANape you can even view your Simulink Model EXACTLY how you built them and add all of your signal channels to it. If there is a bug or people are experiencing problems, it takes all of an hour at most to figure out what is going on and what is causing it.

And given the short cycle time, you don't have time to rewrite everything. Every company that uses Simulink for models even has verified and validated library blocks. We have a "C to K" block (because one isn't built in). That automatically matches In & Out data types, etc. We have low pass filters that are designed to our companies standards....

And we have engine control models that have been ported from Assembly that have been used for 30 years that 'work'. We're not going to throw that all out the window every development cycle.

Previous comments on how Simulink is used to write code in companies that use it.
SAE Paper on how Caterpillar uses auto coding generation to write their stuff.

Re:What?

[Yokaze]

> Most problems in automatic verification are either undecidable, or intractable.

Who was speaking of automatic verification?

Re:What?

[GNUALMAFUERTE]

So, you are saying there's absolutely bug-free software?
That is akin to saying perfection can be achieved. That truth can be absolute.
Those words, are essentially against science. They sound like the thoughts of a delusional, religious person.

There is no such thing as absolute truth or absolute security. 0K is considered the absolute zero, but It'll probably be challenged eventually (And we are having our doubts about it already). c seems to be the upper limit for information transmission ... unless ... (And yes, most of us consider that we'll find a workaround, eventually).

So, you are saying we can absolutely debug that code? No way.

What we can believe in are thresholds. All we can expect is to set a threshold of fair enough security, and live with that. The most likely problem here is that this companies don't hire real programmers. They hire engineers that visually design their systems on crappy applications that are sadly used by the whole industry. None of this guys have any idea of how the underlying code actually works. And the amount of code generated is so huge that reviewing it by hand would require an impressive workforce.

So, they will just continue to patch the issue with a little voodoo.

When the developing strategies of the vb, .net, java and other stupidities of our industry gets out and are applied to critical systems, we should start to worry.

Re:What?

[tomhudson]

> Most problems in automatic verification are either undecidable, or intractable.

Who was speaking of automatic verification?

Some of these same problems are impossible for humans to verify simply because "solution space" is outside the combined lifetime of every human on the planet. That's why "automatic verification" and why even automatic (or more properly, automated) verification, becomes an intractable problem - simply not enough TIME.

If it will take 100 years to verify every possible code path and input, and the system is needed sometime in the next 50 years, forget it.

Re:What?

[M. Baranczak]

Some people do write software that way. The process is incredibly slow and expensive, which is why a lot of defense contractors use it.

The problem is that every conditional branch in the program greatly increases the complexity of the proof, since the proof has to account for every possible path through the program. So they write their programs using as few branches as possible, which as you may imagine makes it very hard to get anything done.

I don't know much about this stuff. Most of it I learned from a conversation with an old unemployed computer scientist. I would have liked to pick his brain a little more, but he was more interested in bitching about his ex-wife, and about how hard it was to find a $200,000 a year job.

Re:What?

[bunratty]

0K is considered the absolute zero, but It'll probably be challenged eventually

The temperature absolute zero is a temperature we can never reach.

You can actually prove that some small snippets of code are really and truly bug-free, however. You can prove many algorithms correct, and prove that a block of code correctly implements the algorithm.

Re:What?

[Tyren]

Unfortunately, this sort of testing falls short when you start adding asynchronous events into the middle of your program flow. Preemptive operating systems are becoming increasingly common in automotive. With a fully preemptive system, it is impossible to test every possible stackup of task preemption on the bench and time prohibitive to do it in simulation. Concurrency issues are mainly avoided through proper design and implementation practices of both the operating system and the application itself.

When concurrency issues appear in the field or on the bench, you have the same scenario as Toyota... The knowledge of "It did this thing this time" and unless your testing generates the exact sequence of events to microsecond precision, you may never see the problem again...

Re:What?

[Fnkmaster]

Sorry, but you are not correct in the general case. Within a very constrained problem space, you can have formal, verifiable proofs that are turned into programs, yes. But in the broader context of Turing-complete programming languages, you deal with the halting problem. As soon as you add unlimited recursion into the mix, you throw out complete verification.

Which of these paradigms is more appropriate really depends on the scale of the input space and the complexity of the problem you are trying to solve, and how well you can express the requirements formally.

Re:What?

[Nadaka]

Unlimited recursion is not possible without unlimited memory and that does not exist.

I am aware of the halting problem and it is something that may prevent provability. I didn't mean to imply that you could prove ALL software, or even that most software can be proven as written or in a reasonable time-frame, just that you can in fact prove software to be correct.

Re:What?

[maxume]

What about it?

(It is easy to verify that a single, small, simple, correct program will halt...)

Re:What?

[Anonymous Coward]

When I was getting my CS degree I took classes on formal methods for proving that your software is correct. It's not a clear-cut thing. You have to design your language to be verifiable, you have to restrict things like branching and loops to conform to loop controls that preserve base assumptions, and you essentially have to write your code to be verifiable. One thing that I can remember off the top of my head that can impact your ability to formally prove anything about your code are side effects - you might be able to prove that when your loop terminates your loop control variable will be equal to zero, but if your language supports side effects you might not be able to formally prove that variables that the proof methodology suggests should be untouched actually have the same values coming out of the loop that they had going in. You can generate examples on a case-by-case basis, but you can't prove it in the general case because side effects are outside the typical mathematical framework used to do proofs.

Assuming their software is written in bog-standard C and they didn't use these kinds of methods when designing it (which is a reasonable assumption - few areas actually spend the huge amounts of time and money to code this way) then I doubt they could possibly retrofit a proof methodology back onto the system they've built. There's an argument to be made that they should have designed it that way in the first place, but that would have cost money. There's also an argument that they should be using the very expensive redundancy methods that are used to make the code and devices that run airplanes with high safety-critical needs. But, of course, that would also cost money. The market ensures that you're going to get the code that is "good enough" to run the car without killing people rather than the code that you might like to have in the car. External pressure is probably going to end up forcing the auto companies to increase their expectations in what the phrase "good enough" means, but it also will likely mean more expensive testing and coding processes which will mean larger price tags on the cars in the future.

Re:What?

[ItsJustAPseudonym]

"They hire engineers that visually design their systems on crappy applications that are sadly used by the whole industry."

In general, I am also suspicious of "visual programming" tools. The user almost-always has to finish the job with a detailed understanding of the deployment, in terms of source code, or low-level drivers, etc.

However, the use of high-level abstraction to design at the system-level, and then the use of "system-in-the-loop" techniques to drill down to actual implementation, is a very valuable methodology. You can take a huge system spec, implement components from the top down, and successively replace each component with increasingly-specific implementations. In the end, you can have prototype hardware in the mix.

This technique is rather expensive, and I have no idea if Toyota uses it or not. But it works, when done right. Like I said, though, the user has to have a pretty good idea of the final implementation of each system and component. If he/she just glosses over the final details, then he/she will end up with surprises.

Re:What?

[hey!]

Reminds me of a grad student TA I had in comp sci 100 who announced in the first section that she would not accept termination in any of our requirement lists for the exercises because "you can't tell whether a program will terminate."

I had a little side talk with her after about what the halting problem actually means.

Generally undecidable problems can have decidable special cases. Intractable problems can have both tractable special cases and useful approximations.

I'd say that a man software rated system which could not be verified to be within an acceptable approximation of "safe" is faulty by design.

Re:What?

[0100010001010011]

Preemptive operating systems are becoming increasingly common in automotive.

Then that's just plain stupid.

However given that Toyota uses Simulink/RTW, I doubt that they've moved away from Real Time OS yet...

A pathway to innovation. Toyota released a revolutionary hybrid electric vehicle in November 1997. “Simulink had a remarkable effect,” on Toyota’s HEV program, says Mr. Ohata. “It even allowed software developed in Simulink and autocoded with Real-Time Workshop to be used on a real ECU well into the development cycle.”

Re:What?

[GNUALMAFUERTE]

That's all good and fun for an ERP app.

I want my critical apps written in ASM by real hackers.

Re:What?

[drewhk]

"It is easy to verify that a single, small, simple, correct program will halt..."

How?

Re:What?

[Yokaze]

The same way it doesn't "take 100 years to" write code, which takes "every possible code path and input" in account,
it doesn't take it to verify it. Discovering an algorithm might take 100 years, but not writing the code.
Those are separate problems and usually one does the first, not the latter. Especially not in the cited case.

Writing correct code is about implementing an algorithm, which already considers "every possible code path and input"
and implementing it correctly. Software verification is purely checking, whether the written code matches the algorithm
is tedious and time-consuming and error prone in itself, but only takes a simple factor more time, which it took to write the code.
Automated verification is a totally different beast, because there is provably no algorithm for it.

To my understanding, that is the quintessence of the Gödel incompleteness theorems:
There are things, which are intractable for automated systems, which aren't for humans.

The size of the "solution space" is mainly important for testing, which seemed to have failed in the cited case.

Re:What?

[maxume]

The simplest way is to run it and see.

(Turing demonstrated that no general approach can solve the problem for all possible inputs, it doesn't have many implications for subsets of all possible inputs)

Re:What?

[Antique Geekmeister]

Oh, dear, dear, dear. Have you evern _looked_ at the details of the TCP protocol, or how and why RAID works? It's only in a non-existent universe with point sources, frictionless bearings, and perfectly spherical fields that such mathematical precision is completely reliable. Even then, the 3-body problem has _not been solved_, nor is the Schrodinger equation easily solved for even the smallest circuits.

So in the real world, "butterfly effects" of small, difficult to predict and model events can cascade into profound changes in quite large-scale systems. Digitization can help, by driving most such effects below the necessary thresholds to turn a bit "on" or "off", but it's not perfect. And mathematical models of mechanical systems are profoundly _not_ perfect: the actual shape of a piece of metal after manufacture, and especially after changes are made after the original design for expense or other manufacturing reasons, can profoundly change the behavior of the real system produced.

Even with software, unless people can follow the code end-to-end, it's prone to surprising errors. Rounding errors, for example, can creep in. Values that are not tested for because one computer scientist read the API one way, and the other read it another way, are rife, and can be be very difficult to avoid.

Re:What?

[phoenix321]

Given the simplicity of processing the inputs from two pedals for accelerator and brake, I think the time requirement for a formal verification is perfectly affordable for a company the size of Toyota.

As human lives are immediately threatened in even slight and short malfunctions of these devices, and with human lives worth significant amounts of money either through moral obligations or payouts after successful lawsuits, mentioning money and time constraints is an inappropriate way of dealing with criticism and an unsustainable way of doing business.

The entire car system is often quoted as containing 10 million lines of code run on a dozen processors at once and in real-time. Even if this is true, it is not a valid presentation of an intractably large problem or an unaffordable and undue burden on a manufacturer.

10 million lines of code executed on 12 different processors aren't all tasked with monitoring brake and accelerator pedals. If the software was designed properly, it will be compartmentalized, allowing a rigorous verification of the life-threatening functions like accelerator and brake pedal and a simple heuristic testing on non-critical functions like the air conditioning, navigation settings.

On proper software, it is possible to completely verify the software that is necessary for people to survive in the car - accelerator, brake, airbag deployment, power steering and signaling lights. It could be useful economically to also verify the software that is necessary for the car to not damage itself or violate laws and ordinances - valve actuators, engine sensors, additional lights, but that's much less of a priority.

If the software and control system of a modern passenger car does not allow for a complete verification of 2 pedal and 1 steering sensors, 4 brake and 1 steering actuator and 2 brake lights, then this software is unfit for its intended purpose. If the system does not allow specific subset of commands to be scientifically, mathematically verified to work as intended even in cases where non-verified parts of the software return any combination of valid and invalid values, then the subsetting structure of that system must be regarded as a complete failure.

Auditing 10 million lines of code is intractable.
Having 1 million of these lines of code to control 3 simple sensors and 5 equally simple actuators is bloated.
Not refactoring these parts of the code until they become tractable is lazy.
Not compartmentalizing the system to allow the verification of 3 major functions is unclever and equally lazy.
But employing unverified, non-compartmentalized, bloated and intractably large software in autonomous systems at high kinetic energies is criminal neglect bordering on fraud.

Re:What?

[drewhk]

The "run it and see" approach is not exactly "can be formally proven if the hardware it is running on is assumed (or preferably also proven) to be error free." which the original poster assumed.

Also, there is a vast number of undecidable problems, e.g. many variants of type inference, compressability etc. not just the Halting Problem.

Re:What?

[bunratty]

This is why Microsoft is able to have a product to verify that Windows drivers don't hang, even though doing so for any program in general is impossible.

Re:What?

[TheLink]

> When I was getting my CS degree I took classes on formal methods for proving that your software is correct. It's not a clear-cut thing.

And there's also the huge assumption that the requirements are correct :). In the real world, your software might do exactly what the requirements say. But the requirements could be wrong.

Then all that verification becomes a big waste of time and money.

Car analogy: all you are proving with verification is the steering tyres will 100% turn with the steering wheel - they will never turn the wrong direction.
But formal verification doesn't prove that you are turning the steering wheel in the right direction in the first place.

With a lot of bugs, the code is working as designed. The design just happens to be wrong.

Re:What?

[Anonymous Coward]

sum = input0 + input1 + ... + input400;

If inputN is constrained to be {0..3} then I now have a test space of at least 2^100 in order to prove addend uniqueness.

Re:What?

[ailnlv]

Seriously? There's a way to test that every single piece of software works OK? Well, if that's the case just create a piece of software that tests if a certain code will stop no matter what its input is and win a turing award.

Re:What?

[maxume]

Right, but dealing with the complexity is the problem, and the halting problem doesn't create some fundamental block to reducing it or otherwise coping with it.

Re:What?

[drewhk]

If I understand you correctly, your argument is that undecidable problems are rare in practice.

I do not think this is true. The problem that the proof of "simple" programs are usually intractable, even if done by humans, so we do not know how many undecidable problems are out there in practice, as we struggle even with the decidable ones.

Re:What?

[Zerth]

0K is considered the absolute zero, but It'll probably be challenged eventually (And we are having our doubts about it already).

Absolute 0 is the coldest a material can get. You can have a temperature lower than 0 Kelvin, but it doesn't mean what you think it means.

Re:What?

[RogerWilco]

It also depends on the problem.

Some problems can be verified, but a lot can not. Similarly you can write verifiable software, but most real-world software does not fall into that small category.

I've read a book a while back, although I forgot the title. It concerns itself with software that controls an elevator. The professor who wrote the book originally proved that a piece of software he wrote during his master thesis, is the optimal solution for controlling one elevator.
Then he went on in his PhD to work on a system with 2 elevator cars. He thought he had cracked it by the time he got his PhD, but in the 30 years since, students have continuously been finding errors in his theory of the 2 car elevator problem. He now thinks that a solution to the 2 car problem can not be completely proven to be correct with current methods, even though the single car problem is well understood and was done 30+ years ago in his master thesis.

Unfortunately I had borrowed the book and I do no longer remember the title. It was an interesting read, if a bit dated because I think it was from the nineties.

And then the problem of elevator car control is probably considered a simple problem by most.

Re:What?

[maxume]

I don't have the qualifications to say they are rare in practice, I'm just saying that, for example, it didn't stop the engineers behind the F-22 from building a better fly by wire system than the F-117 has.

Re:What?

[JamesP]

So that's why code should be SIMPLER

100Million lines of code, either that's BS through the roof or those guys shouldn't be designing even web games. (even tough they're counting nav / entertainment / etc)

Knowing the procedures and the kind of person that writes this code it's amazing this doesn't happen more often, really...

There are several procedures and architectural solutions that can make sure this doesn't happen (or at least, with greater confidence)

range verification (ada comes to mind), self-checks, assert (this should get the computer to reset - better than accelerate, huh)

and also, the first lines of the loop should be:

if (brakes_are_on) {
        throttle = 0;
        do_throttle();
        continue;
}

Re:What?

[umghhh]

It is of course impossible to test it all and real time systems are darned difficult to debug but it may always be made easier to debug. I had a day job with a telecom company where the significant system events could be divided into two types - ones with the event history and ones without. Automotive industry from what I could see till now wanted to have things on the cheap and opted to have only the later which of course make any trouble shooting into looking at debris for clues and desk checking the code. But I can imagine that there is another great (computer) scientist then have a theory of how it works.

Re:What?

[aGuyNamedJoe]

"It is well-known in our community that there is no scientific, firm way of actually completely verifying and validating software."

How wrong can you be? Yes there is. Software is fundamentally the composition of many mathematical functions. Its results can be formally proven if the hardware it is running on is assumed (or preferably also proven) to be error free. Don't get me wrong, it would be incredibly cost, labor and time expensive, and require real computer scientists, but it is certainly possible.

NOT! -- or rather, SO WHAT?

Let's, for the moment, assume you have a combined hardware and software system that have both been mathematically proved correct. Presume the proof was completed at Noon on 1 Jan, 2010. The particular hardware and software so proved is then installed in a vehicle and driven for 50,000 km throughout the USA -- through rain, snow, desert heat, etc -- and is involved in several minor impacts (backed into a tree, jumped a curb)...
In that process salted water is splashed throughout the engine compartment, one dog got carsick, a kid dropped a coke and it splashed under the seat, Dad dropped a cup of coffee under the same seat, the windows were accidentally left open during a rainstorm, a total of 10,000 km was driven with a smoker in the car, and the car was taken to the "detailer" 5 times, where they sprayed various cleansers on the vinyl surfaces (and into the air), etc.

A lot of those events can have impacted the hardware that was proved correct before Noon on 1 Jan, 2010. Corrosives in the air, moisture, dust, yukky liquids, etc.

Is that proof relevant to the system at the end of that period?

Fact is, the real world may be modeled by a mathematical system, but it is, itself, not a mathematical system. The mathematical system may be incapable of failure, but the physical system still may fail.

Re:What?

[stevelinton]

If the software and control system of a modern passenger car does not allow for a complete verification of 2 pedal and 1 steering sensors, 4 brake and 1 steering actuator and 2 brake lights, then this software is unfit for its intended purpose. If the system does not allow specific subset of commands to be scientifically, mathematically verified to work as intended even in cases where non-verified parts of the software return any combination of valid and invalid values, then the subsetting structure of that system must be regarded as a complete failure.

You've forgotten about the numerous sensors INSIDE the engine, transmission, etc. I don't know what type of engine these cars had, but if its achieving anything like the levels of power, economy and reliability expected in modern cars it will have several hundred sensors inside the engine, and actuators firing many times per engine revolution to control fuel injection, ignition, valve timing, etc. as well as monitoring temperatures, oil pressure, air flow, exhaust composition, brake pad wear, wheel rotation, etc. Making an intenal combustion engine work at peak efficiency is NOT simple.

Re:What?

[Anpheus]

The last thing you want is the computer to reset, that is, the one that's controlling the engine, brakes, and power steering along with traction control and other components.

Re:What?

[tomhudson]

Your model fails. Completely. I hope you never have to write code.

Software verification is purely checking, whether the written code matches the algorithm

In the real world, software interacts with hardware. It also may interact with an environment that has other software running at the same time, creating issues of resource contention and starvation.

Re:What?

[TeknoHog]

0K is considered the absolute zero, but It'll probably be challenged eventually

Temperature is the average kinetic energy of particles. When you go towards 0 K, particles move slower, and hypothetically at 0 K there is no motion. If you can imagine moving slower than zero speed, then you can start challenging this limit.

Re:What?

[tomhudson]

Your code has a serious bug.

1. I'm on a hill. I start the engine. I want to go uphill. Until the engine generates enough torque to move me forward, I have to keep the brakes engaged. What if the electric motors can't generate enough torque on their own?

2. Add a trailer with electric brakes to the scenario. Now it's even worse.

3. What if I'm backing up under the same scenario. The one-way (sprague) in the tranny doesn't do anything in that situation.

4. One wheel stuck against the curb and the opposing wheel slipping on ice. I can still move forward, even without a limited-slip differential, by lightly applying the brakes - the slipping wheel is now partly locked, some torque can now go to the wheel that's jammed against the curb, and I'm no longer stuck.

Re:What?

[DriedClexler]

Okay, now you've got me curious: how the fuck did she get to be a Comp Sci TA in the first place? Or accepted as a CS grad student? Or a fucking Bachelor's?

Re:What?

[DriedClexler]

Making an intenal combustion engine work at peak efficiency is NOT simple.

Giving it a killswitch isn't.

Re:What?

[Z34107]

Toyotas wouldn't halt. This is a problem.

If they did, I could use such a vehicle to solve some fundamental CS problems...

Re:What?

[JamesP]

you're right, there are bugs, even though I was thinking of a manual transmission (n.1 does not apply then)

Even then I'm pretty sure the default behavior for 'pressing the breaks' is cutting the gas (even in automatics, I guess)

Re:What?

[tomhudson]

#1 applies with both manual and automatic transmissions.

With a standard manual transmission wiht spur-cut gears, you need to be able to apply both brakes and gas if you want to be able brake AND downshift w/o having to use the clutch. Ditto for a standard transmission and a roxel (rockwell two-speed rear-end - 5x2 transmission).

Also, on very slippery ice, you don't want the abs to kick in - it will release all 4 wheels and you lose all control - so the best course of action is a small amount of gas and light intermittent taps on the brakes - unless you were smart enough to disconnect the ABS ahead of time.

BTW - Even on dry asphalt, ABS won't stop you as fast as locking the 4 wheels will. ABS is for inexperienced drivers only.

Re:What?

[Nadaka]

Negative kelvin temperature isn't a way to express temperatures that are less than 0. It is a way to express temperatures that are locally more that infinite because the system is approaching its maximum energy state and entropy begins to decrease. Read your own god damn link.

Re:What?

[jyx]

So, you are saying there's absolutely bug-free software?

sure the is, here's one I prepared earlier:

10 REM HELLO WORLD PROGRAM
20 PRONT "HELLO WORLD"
30 END

See, the trick is to start out with a small piece of bug free software. Then, you just keep adding small bug free sections to it.

Its the same principle as staying underwater for ever: You can hold your breath for 5 seconds, but you cant hold your breath for a minute, so instead, just hold your breath for 5 seconds 12 times.

Re:What?

[sjames]

PERHAPS it is possible. It is certainly not practical. By the time the analysis was complete, the car and the chips the system runs on would both be antiques.

I say PERHAPS. If the code is sufficiently complex and inter-dependent then the analysis time will exceed the lifetime of the analyst, necessitating that the entire state of the analysis be conveyed to a younger colleague periodically. If that state takes more than a lifetime to receive and then convey to another, it is actually impossible rather than merely impractical.

Rather than going through all of that with a group of people who've never even written 'hello world' in BASIC, he just cut to the point and said it's impossible.

Re:What?

[sjames]

And then a sensor goes and sends a value you didn't think it could ever send and all your testing means nothing.

I'm not saying it isn't useful. It certainly IS. But it doesn't PROVE in the mathematical sense that the system can never behave in an unanticipated way.

Re:What?

[sjames]

Sure, sufficiently trivial code can be proven correct in a reasonable period of time. However when you combine those pieces, the problem gets much more complex quickly because you now have to also prove that the system as a whole will remain in the correct state.

Re:What?

[jo_ham]

BTW - Even on dry asphalt, ABS won't stop you as fast as locking the 4 wheels will. ABS is for inexperienced drivers only.

That is a shockingly poor description of the benefit of ABS. It sounds like you'd switch off your ABS system because it makes you more macho to be able to drive without it.

On dry asphalt with good grip, ABS can actually decrease your braking distance, and with ABS active you can do something that you can not do with locked up wheels: steer the car while braking. The ABS system itself is tuned to prevent your wheels locking so that you don't have to, and modern systems also monitor the way the wheels react so it can tell if one of your wheels is on ice (or aquaplaning) while another is on dry road and thus control each one independently, and move the brake bias between the front and rear of the car.

It is a driver aid that is an enormous benefit to anyone who is using it - it's not a hinderance to you as an "experienced" driver. It is monitoring the wheels under braking many times per second, which is far more than you can do yourself, and allows you to plant your foot on the brake and concentrate on steering the car to avoid a collision if necessary.

You make it sound like you would be better off without it since you're "experienced".

Re:What?

[ceoyoyo]

Yes, that statement is wrong. They forgot the world "practical."

Yes, it is generally possible to absolutely verify software. If you'd ever had to do it, you'd know that it's absolute hell to do for even the simplest, almost trivial programs. It is done, sometimes, for really critical (and small) programs.

Re:What?

[Yokaze]

Exactly for that reason, proving is done by deductive reasoning, not by testing.
You are working on a different abstraction level.

For proving, the number of variables or configurations are not a sensible measure of complexity.
There are seemingly simple equations, which haven't been proven for decades or even centuries,
and there are equations with an infinite number of scalars, which can take an infinite number of values,
which are well understood and proven from several different angles and used by undergrad students every day.

Re:What?

[hey!]

She got her degree in the Soviet Union before it fell. Apparently the quality of the "top" students that came out of Soviet CS programs was inconsistent. I've also met some Soviet CS grads who were very capable.

Re:What?

[tomhudson]

On dry asphalt with good grip, ABS can actually decrease your braking distance

Who fed you this bullshit? Tests show otherwise. On dry asphalt, locking all 4 wheels is much quicker than ABS. It can spell the difference between an accident and no accident.

ABS is worse than an experienced driver in ALL conditions, including hydroplaning and ice. In theory, ABS should be better - but practice and theory are two different things.

Tests show that ABS increases your stopping distance on snow and gravel. Also, threshold braking (where the wheels are slipping about 20%) gives the maximum stopping force on dry surfaces, and that's above anything ABS can do, since it doesn't allow the wheels to "scrub" the asphalt, and convert tire rubber to heat and particulates.

Re:What?

[sl149q]

Hmmm I wonder if over time we'll see less "experienced" drivers on the road due to Darwinian selection weeding them out.

Re:What?

[jo_ham]

This pdf:

http://www.nhtsa.dot.gov/staticfiles/DOT/NHTSA/NRD/Multimedia/PDFs/VRTC/ca/capubs/NHTSAabsT4FinalRpt.pdf (warning, pdf)

Check page 24.

"Panic brake applications used in conjunction with ABS resulted in the shortest straight line stopping distances on the dry concrete and the wet polished concrete surfaces for all nine test vehicles at both loading conditions"

This was tested with ABS, with no ABS and with "best effort" experienced driver with no ABS with manual brake pumping.

Don't just take my word for it, it has been tested. Read it for yourself.

It also confirms the increase in distance on gravel and loose snow, which is obvious, but if you are in such a situation, you should be driving more carefully (ie slowly) anyway so that the difference between ABS and not isn;t the difference between a crash or not (ie, the difference between having the system and not should not be your margin of error).
 

Re:What?

[jo_ham]

"experienced" in his definition appears to be "I learned to drive with no ABS", which is disingenuous at the best of times. I learned to drive in the UK in a car with ABS, that was disabled by the instructor to show me what a car was like under braking with the system failed.

At any rate, if you are crashing because you really needed 10m less distance in the worst case scenario (say, you are on a loose surface and the ABS is diminished) then you are not driving safely in the first place.

The ability to steer while braking (and the general benefit of the ABS system as a whole, especially its ability to determine the traction conditions for each wheel individually) far outweigh the benefit of training each driver to be "experienced" in the sense of "here is how to brake effectively with no ABS" (although clearly this should be taught as part of the driving test).

Re:What?

[dr2chase]

According to Bicycling Science, 3rd edition, page 237, paragraph 2, you are incorrect. The coefficient of friction falls when two surfaces are sliding. This also agrees with my non-scientific experience on bicycles.

Do you have any references that support your emphatic claims?

Re:What?

[tomhudson]

The drivers were doing "best-effort", on vehicles they were not familiar with, not "just lock the damn wheels and stop". Big difference.

In single-lane change tests, the ABS-equiped cars uniformly performed 27% worse according to the paper you cite, more often losing control because the ABS couldn't compensate. This translates in real life into a 21% increase in single-car "run-off-road" accidents.

Additionally, on surfaces that were NOT uniform (gravel, snow) ABS always performed worse.

Also, braking on curves was worse than locking all 4 wheels.

Re:What?

[tomhudson]

The coefficient of friction is at its maximum with 20% slippage. New, cooler material is continuously presented to the asphalt, and eroded away, scrubbing off speed, turning mechanical energy heat. This is not the same as the wheel being locked, and the tire just skidding along. The wheel is still spinning.

Re:What?

[dr2chase]

and you have a reference for that, right? Care to share it with the rest of us, or is this just supposed to be self-evident?

Re:What?

[lennier]

If it will take 100 years to verify every possible code path and input, and the system is needed sometime in the next 50 years, forget it.

And if the system is also needed to not just 'sometimes sorta work' but also not ever go berserk and kill everyone? Well too bad, because we need a giant death robot NOW and if the giant death robot kills everyone that's just acceptable risk.

Or perhaps there are some classes of systems which, if it's impractical to verify that they won't kill everyone, maybe we shouldn't build them at all.

Nah. Gotta have progress, right?

Re:What?

[emt377]

sum = input0 + input1 + ... + input400;

If inputN is constrained to be {0..3} then I now have a test space of at least 2^100 in order to prove addend uniqueness.

Proof of correctness of implementation is virtually always by induction (see http://en.wikipedia.org/wiki/Mathematical_induction), and almost never black-box. BB testing is more useful for regression testing external interfaces. For something as simple as adding up a series, or similar (e.g. FIR filter) with no discontinuities, induction testing technically requires only one test point. In practice however you can just as well test on a few hundred sequences to verify that you haven't unintentionally created discontinuities. If you DO have discontinuities (such as input rejection) you'll obviously need additional tests the verify they work as intended. Sample input rejection is often also done in BB testing, mainly to detect regressions and to verify behavior (e.g. external signaling to indicate a fault).

Re:What?

[lennier]

Shouldn't that make us wonder why it's so hard?

If we can't verify the behaviour of the software components we're busy assembling into bigger and bigger systems, doesn't that mean that we're doing sort of the architectural equivalent of making the Burj Dubai out of fog?

It's a wonder the whole Internet hasn't completely collapsed by now, instead of only partially rotting into botnets.

Re:What?

[Dare nMc]

I hope this doesn't become popular (no vehicle I have ever driven, will lockout accel with brakes, except electric drive where it is impossible to have dynamic brakes and accel simultaneously) it really helps in performance driving to be able to change car balance for/in a corner. This is also the way I can get a good down shift with many auto's, get it to shift into the gear/engine speed I want a little sooner without speeding up (even the auto-sticks won't let you get a smooth down shift, without doing this, most wont even try to do a downshift if it would result in anything > 80% of red-line at anything but full throttle.)

The other issues could be addressed with a hill-start switch, which is what the electric drive mine trucks have. If forward gear is selected they will automatically apply the brakes if any motion is detected in the opposite direction. Although electric drive required quadrature speed encoders, most speed sensors only know speed, not direction, so would require a different speed sensor.

Re:What?

[jo_ham]

Right, so now you're changing the rules - before you were talking about stopping in a straight line with all 4 wheels locked up, now you're talking about lane changes and braking on a curve. And now you're making excuses for the driver being unfamiliar with the test vehicle.

The tests performed there actually featured all three tests - a full lockup, a best effort stop and an ABS assisted stop, at least for a large number of tests. The conclusions are clearly spelt out that except in the compromise case where the surface is loose (gravel, snow) ABS is beneficial for the driver.

Re:What?

[squizzar]

I concur, ride a motorcycle and lock the back brake up, you will feel the reduced braking effect...

Re:What?

[phoenix321]

Of course not.

But it is simple as heck to read two pedal sensors and make sure the result is either acceleration or deceleration.

It is even simpler to have the brake pedal always take precedence over whatever other settings and systems say.

That's what I said about bad system architecture: when you cannot separate a simple but crucial part and have the entire code en bloc, you will kill people if that code is responsible for driving a car.

NASA verifies everything, so it CAN be done. But for cheap cars, we don't need to verify everything, but the framework of components ("brake takes precedence over everything") and two crucial components ("make sure, human pedal input and brake actuators correspond").

We don't want to have Therac-25 deaths in every branch where software is introduced. I can live with restarting my Windows computer every other day, but for my cars, my x-ray machines and my nuclear reactors I expect meticulously verified software.

Software engineers that cannot manage or think of a solution for this have no place in automotive engineering and that's my final word.

Re:What?

[master_p]

So the question then becomes: why should every possible code path and input be tested? isn't there a way to verify software without having to go through all code and input paths?

Re:What?

[ceoyoyo]

No. There is no other engineering field where you can practically mathematically prove, in the general case, that your design and implementation are perfect. Electronics engineering is similar to software in that it is sometimes technically possible to do but, except in special cases, it is not practical to do so. Why should software engineering be different?

Designers of critical systems like bridges, tunnels and airplanes apply knowledge gained through scientific experiment and mistakes made in the past, add in a healthy safety margin, and then test to make sure they've gotten it right. Just like software engineers do. Sometimes bridges, tunnels and airplanes fail. In that case engineers try to learn from their mistakes. Just like they do with software.

Toyota has had a handful of incidents out of the millions of cars that they make. The incident rate is just as high for mechanical issues in cars, airplanes, bridges, space shuttles, whatever you'd like to name.

Re:What?

[tomhudson]

ABS has been shown to result in a 21% increase in single-car accidents because of "run-off-road" incidents where the driver tried to execute a quick lane change rather than stop.

In snowy climes like where I live (the only place ABS will get a real workout if you have decent tread on your tires) ABS is a disaster. Try it on glare ice. On vehicles w/o ABS, you have a chance. Lock the wheels - you're sliding anyways (and only release them when you need to make steering inputs), but at least the occasional patch of grit or sand will help reduce your momentum. ABS won't let you do this. I've driven in ice storms with road surfaces completely covered in ice many times - ON SUMMER TIRES - and I'm still accident-free, while everyone else is spun out. The key isn't your brakes - in those conditions, you have to drive as if your master cylinder has failed (had that happen once ... still managed to drive home without incident, because at 35 below in the middle of the night, I'm not going to just sit there) - anticipate, use only the engine to slow down, etc.

Re:What?

[tomhudson]

The tests you pointed to were a very SMALL number of tests, on a very SMALL number of cars. The testers admit this, as well as the fact that the people doing the tests were unfamiliar with the vehicles.

If your car has decent tread, the "common case" will be snow or ice, not hydroplaning - and hydroplaning, the simplest thing to do is slip it into neutral.

On glare ice, particularly when covered with a film of water because of a rapid rise in temperature, renders ABS a real hazard. You have to lock all 4 wheels and depend on the occasional salty/gritty/dry patch to slow you down - neither ABS nor pumping the brakes manually will do it. Been there (plenty of times), always recovered, watched everyone with ABS just sail through unable to stop.

Re:What?

[tomhudson]

Unfortunately, no. The only way to be 100% sure would involve verifying not just the software, but the hardware as well in every possible use-case scenario. That's why programmers have to be alert.

Re:What?

[Agronomist Cowherd]

He did. Read what he wrote again. He said that it can go negative, "but it doesn't mean what you think it means".

Re:What?

[jthuck]

You mean the ignition switch? That's typically standard on most vehicles now days

Re:What?

[DriedClexler]

I was (failing at) being sarcastic: no matter how complex the fuel efficiency optimization system is, it's pretty simple to have a killswitch, and so the complexity of the electronics is no excuse; by design, there should be an emergency engine shutoff. Cars typically permit this through simply turning off the ignition.

Toyota, brilliant designers they, decided that "hold the on button for three seconds" is a good enough emergency killswitch. What a fucking joke.

V&V

[HellYeahAutomaton]

From Wikipedia:
Verification and Validation (V&V) is the process of checking that a software system meets specifications and that it fulfils its intended purpose.

Since they already said the software is "rigorously tested" does this mean Toyota doesn't have specifications, or that their software doesn't fulfill its intended purpose?

Their software sounds like its written as a monolithic device driver (NVidia unified device model) comes to mind. Perhaps they should be looking for best practices in TDD, as well as dropping support for older models as time passes on.

Re:V&V

[ClosedSource]

We are talking about a real-time control system. It's unlikely to be structured anything like a video driver on a PC.

Re:V&V

[Rich0]

Don't underestimate the complexity of these kinds of systems. Rigorously testing them is actually incredibly difficult and expensive. Yes, there are formalized methods that help, and I'd be shocked if something like a car's braking system didn't use them extensively.

How many spacecraft have been lost so far? Consider that every part and system in them has been subjected to the most rigorous quality control systems in the world, with exactly the kinds of testing methodologies you referred to. The problem is that there is ALWAYS a variable you don't account for, and that means the possibility of failure.

Even formal risk assessments only take into the account the risk factors they examine. The problem isn't the things you think about - it is the thing that nobody thought of.

Re:V&V

[SoapBox17]

In this case we aren't talking about spacecraft under extreme conditions. We're talking about a typical consumer vehicle under normal operating conditions.

Re:V&V

[HellYeahAutomaton]

I'm not underestimating the complexity. I'm calling them out for trivializing the existence of V&V and then implying there is basically nothing they could have done about it.

Spacecraft have a higher rate of failure (space shuttle 1 in 65, or J2 rocket based engines 1 in 300) , they are also not as prone to collisions with other similarly designed vehicles.

>The problem is that there is ALWAYS a variable you don't account for, and that means the possibility of failure.

This is precisely why you need complete code coverage, and need to test all possible code paths. I am not saying that it is easy, and it may be quite expensive, but when lives are on the line, thats the price to pay as a cost for being in business. TCO and SDLC are expensive.

Both Toyota and NHTSB are on the hook for being responsible parties that should have caught this and are shirking their responsibility by implying that it is intractable.

 

Re:V&V

[ClosedSource]

Neither of us have any idea what the code is like, but it is true that traditional desktop or server approaches usually aren't appropriate for a real-time system. Of course in recent years people have been watering-down the definition of real-time, but in this case, it's the real thing.

Re:V&V

[phoenix321]

I don't know what is worse:

Producing life-critical software in the millions of lines of code that cannot be verified even in the most crucial parts.
or
Employing that software knowing full well that it isn't verified and cannot ever be verified in a life-threatening application
or
Shrugging off your responsibility for human deaths caused by your product by presenting software failures to be as natural as night and day.

I always held Toyota in high esteem for their environmental efforts, but the mindset in their current line of failures expresses laziness, stupidity, criminal neglect and an insolent attitude.

The only thing worse than that is knowing all other manufactures would've swept it under the rug and not even publicly accepted any failure at all. Toyota may be one-eyed king of the blind, but it's still a pity.

Re:V&V

[timeOday]

Your whole post is based on the false notion that anything can be exhaustively tested. It can't. Not just the software in cars, but also the mechanical systems in them, the aerodynamics and control systems aboard aircraft, anything... there is simply no point at which you can say you tested every possible unforeseen circumstance and you're all done. Of course that doesn't absolve them from doing everything within reason.

The whole Toyota situation has become irrational. People knowingly sell and buy cars with varying levels of safety every single day. The safety differences between all the different models of cars on the road, of varying sizes, ages, and safety features, utterly swaps any marginal risk Toyota is even alleged to have caused. Go ahead and take the model Toyota has recalled the most of, and I guarantee I can find many, many other makes/models with many more deaths per million miles driven. Again, certainly Toyota should fix it. But at some point, paranoia on one small issue just diverts resources away from other bigger problems.

dismissing user reports?

[jonpublic]

Dismissing user reports is what got Toyota in trouble in the first place. Keep doing that. See how far it gets you.

Re:dismissing user reports?

[Rich0]

Humans are fallible. You can't dismiss user reports. You can review them skeptically, or examine them for trends.

EVERYBODY knows that cell phones cause cancer. So, why hasn't somebody fixed that?

EVERYBODY knows that vaccines cause autism. So, why hasn't somebody fixed that?

EVERYBODY knows that they're smarter than average. So, how did the last few presidents get elected? :)

Re:dismissing user reports?

[jonpublic]

"Humans are fallible. You can't dismiss user reports. You can review them skeptically, or examine them for trends."

Agreed. For example, if you have a hundred times the number of reported cases of unintended acceleration of all other automakers combined. You might want to review it.

Re:dismissing user reports?

[RAMMS EIN]

``Dismissing user reports is what got Toyota in trouble in the first place. Keep doing that. See how far it gets you.''

Right. Nobody I know about actually has a problem with there being a defect in the vehicles. The defect should not have been there and it's a great shame that it was, but everybody understands that it happens. If it happens too often, that gives you a poor reputation, but it doesn't happen to Toyota a lot so their reputation there is good.

Where Toyota went wrong is in how they handled the incident. What they should have done was err on the side of caution, notify people of a possible issue, and encourage them to be careful and report anything that might be related to Toyota to help them investigate the issue. Only after they would have done their best to confirm the issue could they have concluded that the issue does not actually seem to occur, and even in that case they should not have told people that there is no issue, especially not the people who report experiencing it.

What they did instead was deny that there was an issue before they had properly investigated it, and effectively called the reporters of the issue liars. Calling your customers liars is a very bad idea, and doing so with those who report a rarely occurring issue not only insults them, but also deprives you of an important source of information. It's probably the very worst thing they could have done.

Figuring out the parallel between this and full disclosure in computer security is left as an exercise to the reader.

Re:dismissing user reports?

[BusterB]

It is definitely not hundreds of times more - here, you can compare every manufacturer for the last 20 years.

http://www.npr.org/templates/story/story.php?storyId=124235858

Re:dismissing user reports?

[timeOday]

Dismissing user reports is what got Toyota in trouble in the first place.

How many very similar reports are lodged against other car brands every year? If you sell enough units, you'll get complaints of every description sooner or later. It doesn't necessarily mean there's anything to them.

Re:dismissing user reports?

[General Wesc]

That you corrected only one of three intentionally incorrect statements is very telling.

Re:dismissing user reports?

[jonpublic]

There were enough accidents caused by this that State Farm notified the NHTSA that there was a problem with Toyotas.

Re:dismissing user reports?

[Pence128]

"Sure they killed a bunch of people, but monumental fuckups happen."

This isn't rocket surgery. Mash gas, car goes. Mash breaks, car stops. If you think you are supposed to be accelerating as much as possible, something is wrong. Fail as gracefully as possible.

Re:dismissing user reports?

[jonpublic]

There was enough accidents that State Farm notified the NHTSA that there was a problem.

Re:dismissing user reports?

[dr2chase]

But that's not answering the question. How many, and how did it compare? State Farm could have other reasons.

Why?

[Darkness404]

Why exactly is there a congressional case going on about this? It becomes even more worrying when you realize that the US government has a controlling interest in most of Toyota's competitors in the USA. In short, why, in a country where states are going bankrupt, privacy is an illusion, healthcare reform has boiled down to if you are pro or anti Obama, rampant spending and tax increases. In short, why do I care about this? File a class action lawsuit and let the courts settle it. Nothing is worse then a bunch of politicians knowing nothing about engineering, with stock in competitor's companies and large problems they haven't solved wasting their time with this crap.

Re:Why?

[jonpublic]

Question: Why is there a congressional case about this?

Answer: The 911 call. Toyota not fixing the problem.

http://consumerist.com/2009/10/toyota-911-call-of-familys-fatal-lexus-crash-due-to-gas-pedal-stuck-on-floormats.html

Retort to conspiracy theory: This is a Toyota problem. They paid off the NHTSA people to get the scope of the investigation limited to accelerations of less than one second. This has nothing to do with GM, it has to do with Toyota fucking up and getting caught.These cases have been in the courts and Toyota keeps citing user error.

Re:Why?

[Anonymous Coward]

Sorry guy I call Bullshit. Yes Toyota has a problem, but it pales in comparison to some of the major problems that all the other "Big 3" have had. (Exploding gas tanks, steering columns falling apart while driving). However, this would be a lot easier to believe "if" the current administration didn't just start to own GM. Now a company called Government Motors. I use to be a person who would almost always buy American, but I will rot in Hell before I EVER buy another American car. They got my @#$@# money for nothing, and they can fabricate all the stories they want about their competition now, but all that does is make me cement my decision to buy a Toyota for my next car.

Ford, you are somewhat forgiven for this, but your company did also ask for money.

Re:Why?

[Blakey Rat]

Would you prefer Congress look into this, or steroid use in baseball? Believe me, this is *good* as far as Congressional investigations go-- they're usually unbelievably petty.

Re:Why?

[Planesdragon]

Why exactly is there a congressional case going on about this?

1: Because Toyota @#'ed its regulators, and is either malicious or incompetent. The responsive part of the federal government (Congress) is entertaining modifying the regulations, to ensure this doesn't happen with anyone else. (Did YOU know that most cars have a black-box, but Toyota uses a proprietary system that only they can access?)

2: Because there's no real difference between the government of Japan and the business of Japan. JAPAN should be the one hauling their executives before a committee.. but they're too "pro-business" to do that over such a small thing as "unintended acceleration."

3: Because it's an Election Year.

the US government has a controlling interest in most of Toyota's competitors in the USA

The fed has a controlling interest in TWO car companies, and it's the most passive owner either have ever had. Ford, Kia, Honda, and Hyndai are all, well, NOT owned in whole or in part by the federal government.

Oh, and while I don't own a Toyota (and after this, never will), I care because, well, I live in the United States, and drive on the US highways. You know, where the toyotas are randomly accelerating and crashing into other cars and houses and things.

Re:Why?

[wiredlogic]

Why exactly is there a congressional case going on about this?

It's an election year. 'Nuff said.

Re:Why?

[dr2chase]

How much does it raise the overall automobile accident rate? I care about that much. When I see people chatting on their phones, eating, shaving, and knitting while they drive, car-caused unintended acceleration (as opposed to fallible-human-caused unintended acceleration) is not high on the list of stuff I worry about.

Re:Why?

[Mr. Slippery]

Why exactly is there a congressional case going on about this?

Because Congress (under its Constitutional authority to regulate interstate and international commerce) makes laws that regulate the auto industry.

It becomes even more worrying when you realize that the US government has a controlling interest in most of Toyota's competitors in the USA.

Toyota is directly or indirectly responsible for 170,000 U.S. jobs -- jobs held by voters. Congress has plenty of interest in Toyota's well being.

In short, why do I care about this?

If you do not care that people are dying because of defective products, please seek psychiatric attention.

File a class action lawsuit and let the courts settle it.

A class action lawsuit would compensate those injured, and the families of those killed. It will not stop the killing, whereas revised regulations might.

Re:Why?

[konohitowa]

Why exactly is there a congressional case going on about this?

Why exactly was there a Congressional investigation into Ford when their Explorers were prone to rollover? Really - heaven forbid Toyota get the same treatment as other automotive manufacturers. No one even said anything when Toyota redesigned their trucks to fix a serious safety issue but didn't bother to recall the trucks with the problem.

If you want to bitch about irrelevant issues, let's ask why the DoJ is threatening to investigate the BCS.

falsely blaming the user

[SuperBanana]

When the driver says they have their foot on the brake, they are just plain wrong. The human motor system is not perfect, and it doesn't always do what it is told.'

This was true with Audi in the 80's, when 60 Minutes did a report where, among other things, they faked a car accelerating out of control (the car was modified extensively.) And yes, a large number of drivers, particularly the elderly, hit the wrong pedal all the time.

However, there are cases where driver reports are plenty accurate. A great example of this would be the problems Volvo V70R and S60R owners have with brake failure while going up hills.

I've experienced it three times in the 6 months or so that I've owned my car. Each time, I was headed up a hill towards a stop sign, put my foot on the brake, and there was nothing there- I had to push so hard I was pulling against the steering wheel for leverage. This is a car with big, high-performance brakes that can stop on a dime.

Volvo claims there's no problem, despite numerous reports on the V70R.com and Swedespeed forums. No other models demonstrate the behavior.

Re:falsely blaming the user

[bunratty]

I just love anecdotes. Don't you? They're cool!

Re:falsely blaming the user

[Win Hill]

Professor Richard Schmidt says user reports are often unreliable: 'When the driver says they have their foot on the brake, they are just plain wrong." My '08 Prious has had three "surge" events. I was able to stop all three times. In the most serious case there was a group of people standing about 20 feet in front of me, and my car stated surging towards them. I jammed my foot on the brake but was not winning the battle. Normally the Prius brakes are very sensitive and do not have to be pressed hard, so I was using my normal braking force. Quickly becoming alarmed, I pushed harder on the brake, with some effect, but still fighting the electric motor and the gas engine trying to power the car forward. I had to push harder than I ever recall doing to stop the car. At that point engine activity ceased. The people, now about 10-feet away, looked at me like I was an idiot, gunning my car toward them! I was just glad to be stopped. I challenge professor Richard Schmidt: If my foot was on the accelerator, how did I in fact stop? The Toyota people have told me they'll be reflashing the processors of all the Prius cars in a few months so any brake signal will shut down the engine. Why wasn't that done from the beginning? But anyway, I'm looking forward to the modification. In the meantime, I'm practicing quickly hitting the Neutral gear lever.

Re:falsely blaming the user

[wfolta]

When the driver says they have their foot on the brake, they are just plain wrong. The human motor system is not perfect, and it doesn't always do what it is told.'

This was true with Audi in the 80's, ...

I think the key here was that the brake/gas pedals were not well-designed. Or rather, were designed for a racing technique called, I believe, heel-n-toe shifting. This made it way easier than necessary to accidentally hit the accelerator when you meant to hit the brake. At least that's my understanding of how it worked out in the end. Both sides were essentially wrong: the drivers had in fact hit the gas pedal, but Audi had an easy-to-mess-up design.

The Toyota problems, to the extent that they were actually due to floor mats getting stuck, would also be poor design. There's no need to have the gas pedal reach close to the floor, where a mat might catch on it. Nor to have the behind-the-pedal mechanisms within reach of a severely-jammed-forward mat, either. Perhaps 30 years ago, when things were mechanical and they needed some leverage, but not today.

Reminds me of Phineas and Ferb when you hear, "In hindsight, I question the decision to put a self-destruct button on this device in the first place."

Re:falsely blaming the user

[multisync]

I've experienced it three times in the 6 months or so that I've owned my car. Each time, I was headed up a hill towards a stop sign, put my foot on the brake, and there was nothing there- I had to push so hard I was pulling against the steering wheel for leverage.

I experienced a vehicle accelerating out of control in a late 90s Dodge Caravan. I had just gotten on to the highway and set the cruise control when the car started to accelerate. The floor mats were not on the pedal. Disengaging the cruise control had no effect. The car continued to accelerate.

I had to put both feet on the brake pedal and pull up on the steering wheel to slow down until I could get to an off ramp. I threw the car in neutral and turned the engine off. When I started it back up it was fine, and it never did it again, but I never used the cruise control in that vehicle again.

I don't think it was a mechanical linkage problem, as the vehicle was going at a steady speed when I engaged the cruise (I didn't engage it and then use it to accelerate). I think it was most likely the cruise control system, and to this day I'm hesitant to use one.

I think this type of thing probably happens more than we hear about, and it's not limited to any one manufacturer. As the guy who wrote the article said, cars are complex machines, with over 20,000 parts, and anticipating every possible failure is impossible.

But I also agree people are notoriously unreliable as witnesses, and agree a lot of incidents are more likely caused by the driver's own actions. I don't think that was the case with the incident I experienced, but being the only person there at the time, who's to say? I said earlier I didn't set my speed with the cruise control, but then I went through a few minutes of intense pressure as I tried to keep the vehicle under control until I could get it safely off the highway.

I'm sure there's a good chance I could get a detail like that wrong, which would greatly diminish the value of my anecdotal evidence.

Re:falsely blaming the user

[Registered Coward v2]

Professor Richard Schmidt says user reports are often unreliable: 'When the driver says they have their foot on the brake, they are just plain wrong." My '08 Prious has had three "surge" events. I was able to stop all three times. I challenge professor Richard Schmidt: If my foot was on the accelerator, how did I in fact stop? The Toyota people have told me they'll be reflashing the processors of all the Prius cars in a few months so any brake signal will shut down the engine. Why wasn't that done from the beginning? But anyway, I'm looking forward to the modification. In the meantime, I'm practicing quickly hitting the Neutral gear lever.

He's not saying every human report is wrong, it's just humans often think they saw or did one thing when they didn't. My experience conducting crew assessments in operational and simulator scenarios backs that up - someone will swear they did or say X when multiple observers and the event logger shows they didn't. It's not that they are lying just that we are often unreliable observers.

One of the hardest things in event investigation is sifting through eyewitness statements - which are often misleading or wrong; especially people seem not to be able to say what they saw; but rather interpret it. For example, instead of "I saw smoke" they say "the engine was on fire;" the former is a statement of what they saw, the latter conjecture.

Re:falsely blaming the user

[Kessler]

Commercial and military pilots spend hours upon hours training in simulators to handle failure scenarios. Look at all the failure contingency training NASA puts astronauts through. Yet here in the US, any idiot who can pass an eye test and answer a few basic questions about traffic laws can get a license to operate a motor vehicle.

How many drivers will instinctively reach for the parking brake if the brake pedal fails? How may will reach for neutral if the accelerator sticks? How many have even the vaguest notion how to handle a skid or a blow out? How many have their vehicle fully inspected at least annually?

Bottom line is, stuff breaks. Maybe it's defective by design, maybe it wears out, maybe it has to deal with a combination of events no one ever predicted. If there are things you could do to prepare for these contingencies but you chose not to, who is really responsible for the results?

Re:falsely blaming the user

[tomhudson]

I'll bet it was a Grand Caravan. Faulty transmission sensor would feed current into the cruise control wiring in sub-zero weather. Solution was to disconnect the sensor.

Re:falsely blaming the user

[tomhudson]

How many drivers will instinctively reach for the parking brake if the brake pedal fails?

Your parking brake - which only actuates the much smaller braking system on the rear wheels - isn't going to do sh*t for you. Either turn off the engine - but don't turn the key so far as to lock your steering (automatic) or downshift through the gears like crazy (manual).

Your parking brake pawl will snap (automatic transmission) instead of slowing you down. Your parking brake (manual) will hold you im place once you're stopped - but only if you haven't burned through it's adjustment trying to slow down in the first place.

Most important: Drive defensively in the first place - don't get into situations where brake failure means you HAVE to have an accident.

I've had several complete failures, including air-over-hydraulic brake systems on diesels that suddenly failed completely due to a design defect, a runaway diesel (turbo bearing oil seal broke, hot engine oil continued to fuel the engine even with the engine shut-off pulled - stopped, then covered the air intake with my coat to finally choke it before it ran out of oil).

Stuff happens. If you don't panic, you'll probably figure it out before you hit something - unless you didn't give yourself a couple seconds room or were too busy playing with your stupid iPod.

Re:falsely blaming the user

[haruharaharu]

In the meantime, I'm practicing quickly hitting the Neutral gear lever.

Good luck with that. From what I've heard, that may not do anything.

Re:falsely blaming the user

[tresho]

a runaway diesel (turbo bearing oil seal broke, hot engine oil continued to fuel the engine even with the engine shut-off pulled - stopped, then covered the air intake with my coat to finally choke it before it ran out of oil You're a braver man than I am. I wonder how many seconds of hyper-revving a diesel can take before it violently dissassembles itself.

Re:falsely blaming the user

[RMH101]

Runaway diesels are terrifying - had this on a 1987 VW campervan. Started it up in the drive, got a *massive* continous clous of white smoke out of the back of it, racing engine that went up to the redline, took keys out of ignition and it still carried on. The shock meant it took a good couple of seconds before I thought of just whacking it in a high gear and dropping the clutch to stall it - I hadn't heard that it was possible, and it took me a good 4-5 seconds of "WTF?" as I took the ignition key out and it carried on. In the VW rear engine config I wouldn't have dared try blocking the intake in case something grenaded.

Re:falsely blaming the user

[tomhudson]

At Hewitt Equipment they had a diesel where the governor failed (this is back in the '70s) - it DID disassemble itself. But it takes time to rev up that far. Everyone had time to clear the area first.

So I knew I had a few seconds, so there was no danger unless I slipped.

Mind you, the guy who worked there (and told me about it) also liked to connect the toilet up to the 110 to initiate the newbies (metal mezzanine).

Re:falsely blaming the user

[tresho]

My only experience was second hand, from an amateur mechanic who races farm tractors at contests. An engine he had been working on suddenly started to rev uncontrollably for no reason, fortunately it was parked & not in gear. He had just enough time to warn everyone, and he ran behind the tractor on the end opposite the engine before the engine exploded. I don't know how long the whole process took, but he described the explosion as a bomb going off with pieces of shrapnel flying & ricocheting in all directions. I would only try the remedy of blocking the air intake on a runaway diesel if I was already under the hood & the air cleaner was already off the machine. It takes too long to open the hood, remove the obstructing parts, and block the air intake with something. The basic cause of this problem is the diesel feeding on its own oil supply through an internal leak, which could be a bad seal, a crack in the block, or whatever. The only limit to the engine's speed would then be how fast the engine oil was getting sucked into the cylinders (something a witness can't determine until later, and maybe never), the amount of oil in the engine, and whether or not a key part seizes up due to overheating or oil starvation. That's why I said it would take a braver man than I to try to strangle a runaway diesel engine.

Re:falsely blaming the user

[tomhudson]

The air intake was exposed on that model, so it was only a couple of seconds. But yes, especially a hot engine that's been running all night running light-weight winter oil (10W - the engine treats it almost the same as #2 diesel when the turbo bearing seal leaks) - I guess I'm just lucky that way :-)

Then again, I've also had the "pleasure" of getting a phone call - "I just put 5 gallons of diesel in the car - what do I do?" "Fill it to the top with gasoline, drive around for an hour, and fill it to the top again." Since it was winter, it was probably #1 diesel and not #2, so it worked with no issues - and the added bonus of extra lubricant for the valve stems - but the exhaust sure smelled funny for a while ...

tin.foil.hat

[Anonymous Coward]

come on, it's just a big conspiracy.
it's not like 100, 200, one thousand toyotas are
skidding of the highway and into a tree everyday.
there are like a handful of incidents.
-
naw, this is just a big PR campaign of american motor
industry to smear superior japanese tech.
the prius is like a 5 year old car model and in all this
time american "muscle" motor never came up with an answer.
-
big oil and big car a big happy american family.
-
the engine (sic) that drives the (u.s.) capitalistic machine needs
consumption and waste, not innovation and thriftiness.

Re:tin.foil.hat

[Planesdragon]

the prius is like a 5 year old car model and in all this time american "muscle" motor never came up with an answer.

The Prius is a car that, for a car of comparable size, is more expensive to build, more complex to repair, and nets out as more expensive over the general lifetime of a car. (Even if YOU don't own it for the whole time, most US cars run for a few hundred thousand miles before being scrapped.)

GM, who tried an electric car WAY back in the early 90's, decided to largely pass on the paralell hybrid tech of the Prius and its ilk, opting for only a small pseudo-hybrid option on a few of its models. (Essentially, a small electric motor/brake assist on the drive wheels.) Instead, they're rolling out an actually innovative serial hybrid this year. And if you take a moment to understand the difference, the change is profound.

The Prius and its ilk are "parallel hybrids." You have an underpowered classic internal-combustion motor driving the wheels via direct kinetic energy, with an electric motor also contributing kinetic energy from electrical power it gets from regenerative breaking or, for the modified ones, being plugged into a wall. It will NOT perform its full performance without any gas in the tank, and for most models you can't even drive it to a gas station 1 mile away if you don't have enough gas to start.

GM's Volt and its ilk are "serial hybrids", like diesel-electric trains. The wheels are powered ONLY by an all-electric drivetrain, and the internal combustion engine serves only to produce additional electricity. The engine only runs at its peak efficiency, and doesn't need to run at all if the batteries have enough of a charge in them. You could literally drain your fuel tank dry, top off the battery charge, and then drive to a gas station 40 miles away. (And with fewer moving parts, a mass-market volt should last longer and be easier to maintain than its paralell-hybrid ilk.)

Re:tin.foil.hat

[raygundan]

the prius is like a 5 year old car model and in all this

A minor nit-- the Prius has been available in Japan since 1997, and in the US since late 2000. It's a 13-year-old car.

Re:tin.foil.hat

[johncadengo]

I don't know. GP sounds pretty sarcastic to me.

Re:tin.foil.hat

[drinkypoo]

The only problem with the Volt is that you still have to carry around both drivetrains. This might not be so silly if we were using turbines, which don't waste so much weight. Chrysler had the technology in the 1960s, and there's a company which is IIRC called Capstone which is kicking out engine-generators right now. Nissan is bringing out an all-EV this year (supposedly) called the LEAF, perhaps there will be a retrofit. The Capstone turbine has been put into some five-door Ford by an independent group, perhaps a school? Sorry, too lazy to link right now. Give me a volt with a turbine and I'll get interested. Until then I figure any of this stuff is most appropriate for people with multiple vehicles, and the other vehicle should be a mechanical turbodiesel that you can actually work on and get fuel for.

Anyone else think it odd?

[jhoegl]

I find it odd that the systems in vehicles do not have a default "debugging" which should basically trigger the vehicle to stop.
Why does the vehicle ABS (from what I know from the news) get tripped up on instant breaking? Really? ABS... the thing that is supposed to pump the break to allow for cleaner stops triggers breaking problems and increased acceleration?

I just think bad coding in general here. Regardless of "testing"

Re:Anyone else think it odd?

[sciguy125]

Why does the vehicle ABS (from what I know from the news) get tripped up on instant breaking?

You're confusing two different issues. Some (many) models have having an accelerator problem. Supposedly, the car takes off and there's no way to stop it.

Then, there's the brake issue with the Prius. If you press on the brake lightly, it only uses the regenerative braking (electric). If you hit a pothole, the ABS kicks in and there's a switchover to the friction brakes. You temporarily lose some braking force and it feels like the car is floating or (as some have reported) accelerating.

I own the affected Prius model. I've experienced the issue and I don't think it's a problem. It was a little unnerving until I realized what it was. If I really need to stop sooner when the brakes "fail", all I have to do is hit the pedal harder and it does what I expect.

Re:Anyone else think it odd?

[couchslug]

I find it interesting that, in quest of featuritis, designers implement consumer-quality systems that lack VERY SIMPLE safeguards. Direct physical connection of steering columns, braking systems, and throttles (so they act as a stopcock, it's good enough for jet fighters!) should be mandatory.

Yes, I know some commercial systems have done acceptably, but consumer shit will NEVER be of that quality due to price competition, and consumers won't maintain their vehicles like aircraft.

Re:Anyone else think it odd?

[jhoegl]

Yeah, that is a good point as well. Some kind of mechanical override to the computer when in emergency situations.

Re:Anyone else think it odd?

[hAckz0r]

If you can duplicate it on demand then don't stop, run to the nearest phone and collect your million dollars. http://www.insideline.com/car-news/who-wants-to-be-a-millionaire-edmunds-com-offers-big-money-for-unintended-acceleration-research.html

btw - I hope your are right. I own a Prius, but not one with the problem, so I am unable to even try to help. If I did have one I would be disassembling the software system looking for potential overwrites of the variables that control the throttle calculation.

Re:Anyone else think it odd?

[Mashiki]

I find it odd that the systems in vehicles do not have a default "debugging" which should basically trigger the vehicle to stop.

Not stop but most vehicles have a thing called limp mode, which causes the vehicle to kick into a safe state where it can only go upto 45-50mph and has very low acceleration. There was a time when limp mode only had a drivable range of 60mi to get you to a service center of some kind, but the distance is much larger now.

Re:Anyone else think it odd?

[nxtw]

I find it interesting that, in quest of featuritis, designers implement consumer-quality systems that lack VERY SIMPLE safeguards. Direct physical connection of steering columns, braking systems, and throttles (so they act as a stopcock, it's good enough for jet fighters!) should be mandatory.

The positive effect of computer controlled systems far outweighs the risks. ABS, electronic stability control, etc. were introduced because they reduce accident rates. Period.

Without computer-controlled systems, todays' cars would be dirtier and less safe.

Good time to buy a Toyota

[DogDude]

Of course Toyota is right. The most likely cause of these "sudden acceleration" problems is humans with their foot on the gas pedal. I've owned plenty of Toyotas, and I wish that my current Toyota was in need of replacing right now, because now is a great time to buy one. Unfortunately, my current Toyota only has 150K miles, meaning that I have a good 5-10 years of life in my vehicle. After that... I'll buy another Toyota.

Re:Good time to buy a Toyota

[Anonymous Coward]

Over 40% of sudden acceleration are from Toyota drivers http://blogs.consumerreports.org/cars/2009/12/sudden-unintended-acceleration-sua-analysis-2008-toyota-lexus-ford-gm.html. Which is far higher then Toyota's share vehicle parc (number of vehicles in use). This is an indication that there may something other then human error. (Ford is also higher then it should be, with most of its complaints coming from the F-series, the common explanation for this is the shape of the transmission tunnel in certain bodystyle causes the driver to place his or her right foot in an unusual manner causing the driver to hit the wrong peddle)

Re:Good time to buy a Toyota

[T Murphy]

I understand Toyota isn't the first to get complaints of brake failure/sudden acceleration, but the concentration of complaints makes it hard to be sure that human error just happens to be more common with certain vehicles (not impossible, if certain vehicles attract the right kind of driver). With the secrecy on the black boxes, I have to give the consumers the benefit of the doubt, as Toyota should have access to the data it needs to prove their case. As much as I agree that rare, unusual reports should be treated with skepticism, when people's lives are at stake you have to give them a fair shake, but Toyota doesn't seem to be doing that.

That said, at the very least Toyota should look into the driver error cases and try to improve safety there. For example, a "big red button" for emergency stops would be impossible to mistake for the accelerator, and could be implemented to circumvent code that could contain a bug causing this whole issue.

Re:Good time to buy a Toyota

[raftpeople]

Of course Toyota is right.

Mr. Watanabe? Is that you?

Re:Good time to buy a Toyota

[magus_melchior]

I'm not sure if you were being ironic, but I'm inclined to agree solely based on cost. After this media drubbing, Toyota dealers will be desperate for sales when they resume sales of affected model lines.

Re:Good time to buy a Toyota

[DrDitto]

I own a Nissan. But my next car will be a Ford. As someone involved with the higher education of engineering students, Ford and GM recruit engineers from American universities and Toyota/Nissan/Honda do not. What do you think will happen if engineering students in this country cannot find jobs? What jobs are more important, hourly manufacturing jobs or higher-end engineering jobs?

Re:Good time to buy a Toyota

[Strange Ranger]

"40% of sudden acceleration are from Toyota drivers"

While it certainly deserves a thorough looking into, let's not forget that most victims of alien abduction will draw a similar alien face. We all know the face. Does that mean it exists? The face must've come from somewhere, but it has spread into the public conscious. And there are no insurance claims on alien abduction. But now when I accelerate into a wreck in my Toyota, I know what I'm going to tell my insurance company. wink wink.

I bet that 40% goes up before it comes down.

Re:Good time to buy a Toyota

[bsDaemon]

Without the engineers, the factory workers have nothing to build, but without the factory workers to build it, the engineers aren't bloody likely to do it themselves. Sure, maybe they build robots and completely automate the factory, but then what are all the people who are now out of work because their jobs were automated away supposed to do?

A significant portion of them weren't ever going to be engineers anyway, no matter how much time and effort was spent educating them. It just wasn't going to happen due to lack of aptitude or interest. Now, faced with no prospect, their choices are probably either join the military or become criminals. The ones that join the military, when they get out, still having no prospects because engineers star-trek'd all the jobs away, are either going to have to become criminals anyway, or police.

Sure, this is kind of a "slippery slope" argument, but realistically the point I'm trying to get at is, how can you possibly say that one job is "more important" than another, as long as they're both actually productive work? (besides, if we want to make it a value contest, agriculture is arguably the only necessary economic activity. Everything else, while wealth producing, doesn't make it possible for us to live, just live more easily).

Verification needs serious improvements

[js3]

My 2005 G6 used to shake a lot at high speeds. Took it to the dealer 4 times, they would always "do something" but the problem never went away, after the 4th i came to the obvious conclusion they had no bloody idea what they were doing, either sucking my money or just plain clueless. So I took it to a tireshop, one test drive and they informed me one of the back tires was worn and imbalanced. In just 2 hours they fixed what took the dealer a month to figure out.

The auto industry needs to emerge from the smoke & mirrors age and start taking shit like this seriously. It's just mind boggling how a problem like unintended acceleration and exist for so long with no root cause found.

Re:Verification needs serious improvements

[ekhben]

Yeah, I read the first sentence, and I was going to suggest you get a wheel balance :-) My car's shaking at 90k and over right now, needs two new tyres and balance (and alignment, but that manifests through the car veering to the side a little if you let go of the wheel).

Hmm, should book that now.

Re:Verification needs serious improvements

[drinkypoo]

Just be glad it has a modern suspension. Bad alignment (which can result from tire wear alone, but wasn't in my case) can produce a symptom called the "wobble of death" in IFS 4x4 ford pickups. All KINDS of bad alignment and bad tires, though, and my 1989 240SX still rode pretty well and could be driven hard and tossed around. A 1984 300ZX would wobble like mad on bad rubber.

Software has no business

[n6kuy]

... being in control of braking and acceleration.

Re:Software has no business

[megla]

If you believe that then man, I hope you never find out how an Airplane works!

Re:Software has no business

[peragrin]

How about fuel air mix? there is software in there to get the best out of fuel efficiency. What about cruise control? there is software that monitors the current speed and adjusts the fuel flow automatically.

if you want a gas guzzlling, monster car with linkages that have a habit of wearing out, then go by a car form the 50's personally today's cars are far safer than anything from back then.

Re:Software has no business

[raddan]

Given the proportion of software-caused car accidents to human-caused accidents, I think we can more reasonably state that humans have no business being in control of braking and acceleration.

Re:Software has no business

[drinkypoo]

if you want a gas guzzlling, monster car with linkages that have a habit of wearing out, then go by a car form the 50's personally today's cars are far safer than anything from back then.

Alternatively, you can have a mechanical diesel. My 1982 300SD gets 30 MPG on the freeway if driven gently... but at a good clip. It does smoke a little at low RPMs if I accelerate any way other than very slowly, but once the Rs are up it's very clean. It has seatbelt pre-tensioners and crumple zones, and airbags were an option, as was ABS. My car has neither, which is fine with me. In inclement weather I slow the hell down. I had a Subaru but I wanted a diesel. When my alternator failed (at least it was cheap and easy to replace) I was able to complete my drive to work. If I could change one this about this car, it would be to give it automatically-adjusting valves.

Re:Software has no business

[RAMMS EIN]

``Software has no business ... being in control of braking and acceleration.''

I used to think so, as well. But I've come to realize that it's not software or no software that matters. It's the result. If the result is that I'm safer, I'll take the software. So the real question then is: has the transition to software-controlled braking and acceleration improved or deteriorated safety/reliability/energy efficiency/cost-effectiveness/whatever other metrics are important?

Re:Software has no business

[ceoyoyo]

I've never drive a drive-by-wire car (but I've flown in lots of fly-by-wire planes) but the only problem I've ever had with my brakes was when a hydraulic line burst.

Non-electronic systems fail too.

Re:Software has no business

[peragrin]

you haven't driven a vehicle that was built in the last 10 years? Anti- lock brakes? just how do you think a mechanical linkage would rapidly adjust the braking?

the technology has been slowly inserted into the cars as the pricing comes into the target range for the designers and builders.

Re:Software has no business

[ceoyoyo]

ABS isn't really drive by wire. The electronics can modify the input from the driver but there is still a mechanical (or hydraulic, rather) linkage between the pedal and the brake. It seems it's the lack of a non-electronic connection that really bothers people, although there are the die hards who think ABS is the devil as well.

The car with the burst brake line had ABS.

Can't be verified as safe?

[erroneus]

So they have created a system by which cars with problems that threaten the lives of those within the vehicle and those in the vicinity of the vehicle but cannot be tested or verified adequately?

That rather sounds like cause to deny further sales of these cars until such time that they can be tested and verified as safe. After all, do we expect less from other safety committees and boards? The FDA? The FAA?

Re:Can't be verified as safe?

[ediron2]

Erroneus wrote:

(mumble mumble) created a system (mumble) threaten lives (mumble) cannot be tested or verified adequately (mumble) sounds like cause to deny sales

Wow. Just wow. Never has a nick been so apt.

This isn't a Toyota thing. It isn't even exclusive to the auto industry. System complexity was where so many cliches like "Fast, complete, cheap: pick any two" come from.

Sure, we can put missile-guidance software protocols into all sorts of software development; If I remember the metric, every line of code costs 10x as much as in general industry.

Another thought: Airbags took 15 years to get acceptance from their 1970's invention -- the industry quickly realized their safety value, but nobody wanted to pony up $800 (1980 estimated per-car cost) or increase the cost of a car to eat that cost.

And don't even get me started on FAA vs. adequate safety. Or Seldane and the FDA.

tl;dr: Toyota *DOES* test extensively. Shit happens.

Re:Can't be verified as safe?

[RAMMS EIN]

``That rather sounds like cause to deny further sales of these cars until such time that they can be tested and verified as safe. After all, do we expect less from other safety committees and boards? The FDA? The FAA?''

Indeed, we do. The reason is that we _cannot_ expect things to be tested and verified as safe. The first reason for that is that the number of possible interactions is infinite, so you can never test them all. You can verify a model, but that transfer completely to the Real World. We can never be CERTAIN that something is safe.

Secondly, with cars as with many other things, we actually do have certainty, and it's the certainty that they are NOT SAFE. You can get yourself killed with a car, and virtually everybody knows it. So even if it were possible to test and verify them conclusively, there would be no point, because we already know the answer.

Cars aren't 100% safe and almost certainly never will be. Water isn't 100% safe, either. We can debate where to draw the line and say good enough is good enough, but it has to be somewhere before "tested and verified as safe", because we will never get there.

Re:Can't be verified as safe?

[erroneus]

We are talking about under normal usage scenarios where the car takes over and does bad things that the operator cannot override. And "reasonable" safety has to be established. Sure, no car makes a quick turn at 50MPH. They might roll. But that's not normal and it is testable.

Here we have a system that is taking control away from the driver in favor of the machine and the machine kills people. Big problem. If it were an aircraft, I think we would see a much more profound reaction from just about everyone who is interested -- passengers, operators, owners, regulators and dessigners.

It's not about certainty of safety under unusual or user misuse conditions. No one ever made that assertion and to interpret that as my meaning is ridiculous hyperbole.

What we know in this case is that tragedies that are most certainly NOT "floormats" are still not completely explained and they aren't even testable. Black-box forensic evidence is being withheld as trade secret so Toyota, despite its apologies, are not forthcoming with answers or much in the way of assistance in the interests of resolving the problem. What's more, this issue is 10 years old! Toyota has been offering nonsense excuses and useless recalls to placate any investigative activities to this point.

This is a big problem with signs that Toyota has been less than honest and forthcoming with information and resources.

Re:Can't be verified as safe?

[RAMMS EIN]

I completely agree with you that Toyota mishandled this case. As I've posted elsewhere, they did what is quite possibly the very worst thing they could have done by denying the problems and effectively saying that those who were providing them with valuable information about a possible very serious issue were lying - rather than what they should have done: everything in their power to show they were taking it seriously, investigating it with full openness, and erring on the side of safety.

Of course, that is a completely different argument from the one you were making earlier. And to be sure, I agree with you there, too: if it were possible, I would like to be certain that the car is safe, too. The reality is, though, that we just can't be certain of that.

You can say that you are only interested in normal conditions, make a comparison with aircraft, say that I misinterpreted your words, and make a good argument about Toyota having mishandled the case, and I won't disagree with you. But you have to be clear about what you want. To quote your earlier post:

``That rather sounds like cause to deny further sales of these cars until such time that they can be tested and verified as safe.''

I interpreted that as you saying you don't want Toyota to be allowed to sell cars until they can be tested and verified as safe. To me, "tested and verified as safe" means that we must have investigated every possible scenario, and concluded that none of these scenarios result in something that violates the conditions we have set for safety. And I am telling you that that is never going to happen. So if you meant something different, do please explain.

Formal verification?

[Pegasus]

"It is well-known in our community that there is no scientific, firm way of actually completely verifying and validating software."

Um ... did this guy ever heard of formal verification? Or is math proof not good enough for him?

Re:Formal verification?

[Rich0]

Um ... did this guy ever heard of formal verification? Or is math proof not good enough for him?

How about this reformulation, then:

"It is well-known in our community that there is no scientific, firm way of actually completely verifying and validating a system that is Turing-complete."

And yes, there is a math proof for that. :)

Well, there is brute-force - just run the program start to finish for every possible combination of branch conditions. Just take 2 to the power of the number of if statements in the program and that's the number of tests you need to perform. Good luck doing that for anything more complicated than a thermostat, however...

Re:Formal verification?

[Pence128]

To be fair, this isn't much more complicated than a thermostat.

Re:Formal verification?

[sjames]

There is the minor matter of time. Trivial programs can be proven correct (and have been). Non-trivial ones are intractable.

Re:Formal verification?

[Ihlosi]

Well, there is brute-force - just run the program start to finish for every possible combination of branch conditions.

Ohh. Have fun doing that in a real-time system, where a branch (to an ISR/SWI/whatever) can happen almost any time while the program is running. ;)

Re:Formal verification?

[Rich0]

Well, I'm sure the sendmail configuration file doesn't really need to be Turing complete, but I heard that it is.

Keep in mind a Turing machine just has access to two bits of memory at a time, and follows the simplest of rules. It isn't hard to make something with this level of complexity almost accidentally.

I couldn't agree more, however, that there is no reason that things like brakes can't have completely manual failsafes. All you need to do is have the throttle give completely electronic commands until it hits 80% of full scale, and then in the last 20% it hits a completely mechanical stop and begins to apply direct braking.

Google has the anser

[moteyalpha]

Did you mean to apply brake instead of accelerate,
Here are the results for brake 1. alive
Here are the results for accelerate 1. dead. 2. I'm feeling lucky.
Select your option. And yes I know I typed anser instead of answer. It is because I am not pefect.

Halting

[Vahokif]

It is well-known in our community that there is no scientific, firm way of actually completely verifying and validating software.

Looks like Toyota's suffering from a halting problem. ;)

Another way to stop a car

[ItsJustAPseudonym]

Interestingly, the heat death of the universe provides an alternative solution to the Toyota braking problem: It will probably stop the cars. (I say "probably" because I don't have time to do a formal verification.)

here is the problem

[KevMar]

Less than 100 cars out of 8,000,000 have had this problem. That is a 0.001% failure rate.

Of those 0.001% of cars that had the problem, how many times did someone drive them before they failed?

I don't want to say this is user error, but I have seen some users do stupid stuff and not even know they did it.

Re:here is the problem

[KevMar]

My point was more how hard this will be to track down because it is so rare. A mistake that kills one person is too many. when you have 99.999% of them working correctly all the common and normal test cases have passed. How many software products get released and never have a bug or problem?

I'm not trying to justify the failure, but somethings are near impossible to track down.

I have a factory radio in my car that I purchased in 2003 that has locked up 4 times. By lock up, the radio sounded fine but non of the controls responded. I could spin the volume full circle, I could try and eject the disk, I could press the power button. I had to turn the car all the way off to get it back. My car has a handy feature of keeping power to the console and windows for a few secs after turning the car off, so if I turned the car back on before that time then it would still be stuck.

I tried everything I could to reproduce it and I even got it into a dealership with the radio stuck and they had no clue. An intermittent radio lock is much better than a gas pedal lock up.

Little attention was given. Read Consumer Reports.

[Futurepower(R)]

General Motors has been making cars with poor reliability literally since I was a child. Read your library's old copies of Consumer Reports for verification.

Insufficient attention was given to the poor reliability of G.M. cars, in my opinion.

As long as G.M. cars could continue to be sold, making unreliable cars was more profitable. That's similar to making a sloppy computer operating system that is vulnerable to attacks. The sloppiness helps sell new versions.

followup comments

[SuperBanana]

A couple of follow-up comments: If you find yourself in a car of any brand where the engine is accelerating without command, put the car in neutral (your engine will be fine, as the engine computer has several "rev limiters" built-in) and apply the brakes STRONGLY. Don't "ride" the brakes or use them to "control" the speed. Get over to the side of the road and STOP IMMEDIATELY. On virtually every production car made on the planet, the brakes have vastly more torque than the engine. 60-0MPH is something most cars can do in 100-150 feet. There are VERY few cars which can do 0-60 in 100 feet (and they are race cars, and have really, really big brakes.)

If neutral won't work- you can also turn off the ignition, but don't turn the key completely off, or you'll engage the steering lock(ie, go to the 'accessory' position.) You will not "lose steering"; at any speed over about 2-3MPH, steering assist becomes less and less necessary, particularly if you don't have very wide tires.)

If you "ride" the brakes, the pad and rotor will heat up and "cook"; consumer, mass-market pads are designed to have good "cold" (ie instant) grab, be easily modulated, quiet, not cause excessive wear on the rotor, and not generate brake dust that is impossible to remove from the wheels. Racing pads are designed for higher temperatures (where among other things, you get much more heat transfer from the rotor to the air blowing past/through it), but they have very lousy "cold" bite. Also, heat up the calipers enough, and you will cause the moisture in the brake fluid to boil (your brake fluid should be changed at a MINIMUM every 2 years, because it is hygroscopic), and that boiling will result in "vapor lock"- no brakes. The brakes MUST be bled after such an incident.

Audi successfully defended itself from several lawsuits and even won a countersuit in a case where a mother crushed her boy against their garage wall (after going through the garage door!). Interviewed by an officer afterwards, she repeatedly said she'd hit the wrong pedal. They sued a few months later claiming the car had "gone out of control". As someone who knows Audis well, particularly the mid-80's 5000 turbo series- the idle stabilization valve (the only way the car computer can increase engine speed) simply cannot allow enough air to bypass the throttle enough to cause the car to lay down burnt rubber, crash through a garage door, and embed itself in a house wall.

The problems with the Volvo "R" models have been reported in a number of other european cars; you'll also see the words "ice mode" thrown around occasionally. Many ABS controllers since 1990 or so have an accelerometer to detect when all the wheels stop simultaneously but there is no corresponding negative acceleration. "Ice mode" is supposedly some sort of variant of this, and there has been great debate as to whether this "mode" is internet folklore, but you'll find many, many posts on all sorts of varying car enthusiast forums.

Re:followup comments

[FrankSchwab]

The other critical item - apply the brakes and DON'T LET UP.
    1. Engine vacuum is a necessity to modern power brake systems.
    2. There is a vacuum reservoir in the brake system that allows a couple of brake applications even if vacuum is disrupted.
    3. With the throttle fully open, there is little to no engine vacuum available
    4. If the car is accelerating uncontrollably, and you pump the brakes, you're going to die.

Try it - I have on my Ford Explorer and my wife's Acura. The next time you're on the freeway onramp with no one in front of you, floor the throttle, wait a second or two, then pump the brakes a few times. On the first application, you'll feel the brakes start to slow the car. After the second or third pump, brake effort will rise dramatically, and you probably won't be able to slow the car. /frank

Re:followup comments

[Anonymous Coward]

Your advice would be great were it not for the fact that most driver education courses in America teach student drivers to use only relatively delicate applications of the brakes (to avoid skids), almost nobody has ever experimented in their own car to find out just how hard you have to press the pedal to achieve maximum braking, and studies have shown that many drivers are afraid to use maximum braking even in emergency conditions.

Oh, and also that fly-by-wire engine and transmission systems may well accept driver control inputs as mere suggestions rather than commands.

Re:followup comments

[Ma8thew]

You don't have to learn how to do an emergency stop? In the British driving test you will need to perform an emergency stop to pass 50% of the time (hence you need to learn how to do it). If I had never practiced emergency stops I'm not sure if I'd appreciate just how hard you need to step on the brakes to get the shortest possible stopping distance.

Re:followup comments

[Gordonjcp]

I prefer diesels, in which the braking servo assist works differently due to the lack of a throttle (and hence vacuum).

I prefer my old Citroen CX, where the brakes (and steering and suspension) are powered by a hydraulic pump the size of a beer can driven off the engine, and maintained for a couple of hours after shutdown by two large hydraulic accumulators. The pedal has no travel, and requires a fairly firm push to operate the brakes. The front discs and calipers are huge, and the rear discs are about the size of the front discs on a Prius (of course, it weighs about twice as much as a Prius).

It's got a really nice drive-by-wire system too; there is a bit of steel wire clamped to the end of the throttle pedal that connects to the little lever on the side of the carburettor, and a little spring that pulls the lever back to close the throttle. There's none of this "just one laptop in the country can read the diagnostics" either, because the diagnostics are simple. If you put your foot on the throttle and the car doesn't accelerate, that's because the wire has fallen off. If you take your foot off the throttle and the car doesn't slow down, that's because the spring has fallen off. I've had both happen at one time or another. No real drama, easy to fix.

Re:followup comments

[sjames]

When I took my driving test (in the U.S.) we never exceeded 25MPH. The "emergency stop" test consisted of the examiner saying STOP! If you hit the brake, you passed that part. Note that driving exams are not standardized in the U.S. so people in other areas of the US may have had an entirely different test.

Re:followup comments

[Nefarious Wheel]

If you put your foot on the throttle and the car doesn't accelerate, that's because the wire has fallen off.

Yes, I noticed that on my old Citroen too.

Re:followup comments

[merreborn]

If you find yourself in a car of any brand where the engine is accelerating without command, put the car in neutral (your engine will be fine, as the engine computer has several "rev limiters" built-in)

I had an accelerator cable stick on me in a Dodge Caravan, years ago. I can't help but to think back to that every time I read how some Toyota owners have ended up in accidents as a result of this issue. In my experience, it wasn't that hard to address the problem safely.

    In my case, the problem was really the result of poor maintenance on my part -- the accelerator cable passes above the battery, and I'd let the battery leak so badly, a mound of crystalized acid built up and was rubbing against the cable. To make matters worse, I was driving the POS 120 miles a day.

Finally, one day on the highway, I pressed the gas, let off, and the damn thing kept accelerating. The cable had stuck. While I'd imagine downshifting comes naturally if you've driven a manual, I've never driven anything other than an automatic in my life. Fortunately, my father had taught me to downshift when descending steep grades, rather than ride the breaks. As a result, I had the presence of mind to downshift, and pull off at the next off-ramp.

In retrospect, I probably should have immediately brought the thing to a complete stop on the shoulder and had it towed, but I actually managed to navigate several blocks and stop lights shifting between first and neutral. Parked it at a Chevron that had an attached garage.

I suppose my purpose in relating this is twofold: first it provides real world confirmation of your advice. Secondly, I suppose it serves as a reason for anyone teaching someone to drive to also teach them about the concept of "engine breaking". That extra bit of knowledge probably saved me from ending up in a high speed collision.

Yes, interesting.

[Futurepower(R)]

The most relevant thing I've read about the problems with Toyota vehicles is this quote from the bottom of page 3 of that PDF linked above:

"... it was determined that [Toyota] Electronic Control Module (ECM) malfunction detection strategies were not sufficient to identify all types of fundamental APP sensor and/or circuit malfunctions. Some types of Electronic Throttle Control (ECT) circuit malfunctions were detectable by the ECM, and some were not. Most importantly, the Toyota detection strategies were unable to identify malfunctions of the APP sensor signal inputs to the ECM. APP sensor signal circuits must be undeniably correct to electrically convey the appropriate driver commands to the ECM."

Next paragraph:

"With the two APP sensor signals shorted together through a varying range of resistances, all four Toyota vehicles tested thus far reacted similarly and were unable to detect the purposely induced abnormality. The types of signal faults introduced into the APP circuit should have triggered the vehicles' ECM to illuminate a warning lamp within seconds."

Bottom of page 4:

"In addition, the shorted APP signal circuits were connected momentarily to the sensor's five-volt supply circuit with the vehicle in drive. In all test vehicles, the ECM did not set a DTC and the engine speed increased rapidly to full throttle. This result shows that unusual or sudden unintended acceleration of the vehicle was possible in the ETC test vehicles."

Re:Yes, interesting.

[Zurk]

The gilbert problem is the reading from the toyota ECM when the two redundant APP (accln pedal position) signal circuits are shorted together (main and sub), From the toyota camry VSRM :
DESCRIPTION
This ETCS (Electronic Throttle Control System) does not use a throttle cable. The Accelerator Pedal Position (APP) sensor is mounted on the accelerator pedal bracket and has 2 sensor circuits: VPA (main) and VPA2 (sub). This sensor is a non-contact type, and uses Hall-effect elements, in order to yield accurate signals, even in extreme driving conditions, such as at high speeds as well as very low speeds. The voltage, which is applied to terminals VPA and VPA2 of the ECM, varies between 0 V and 5 V in proportion to the operating angle of the accelerator pedal (throttle valve). A signal from VPA indicates the actual accelerator pedal opening angle (throttle valve opening angle) and is used for engine control. A signal from VPA2 conveys the status of the VPA circuit and is used to check the APP sensor itself. The ECM monitors the actual accelerator pedal opening angle (throttle valve opening angle) through the signals from VPA and VPA2, and controls the throttle actuator according to these signals.

FAIL-SAFE
The accelerator pedal position sensor has two (main and sub) sensor circuits. If a malfunction occurs in either of the sensor circuits, the ECM detects the abnormal signal voltage difference between the two sensor circuits and switches to limp mode. In limp mode, the functioning circuit is used to calculate the accelerator pedal opening angle to allow the vehicle to continue driving. If both circuits malfunction, the ECM regards the opening angle of the accelerator pedal as being fully closed. In this case, the throttle valve remains closed as if the engine is idling.
If a pass condition is detected and then the ignition switch is turned off, the fail-safe operation stops and the system returns to a normal condition.

VPA and VPA2 are coming from the PCM with .5-1.1v at one of the sensors and 1.2-2.0v at the other when the pedal is at its relaxed position. When there's force at the pedal, one sensor will operate between 2.6-4.5v and the other at 3.4-5.0v.

Toyota specs normal voltage for both the VPA sensors between between .4-4.8v for VPA, and .5-4.8v for VPA2 with a .2v deviation between the 2 sensors. Anything out of those ranges will trigger a DTC

An internal short could occur within one or more of the paths from the circuits leading to the ecm. That could lead to a situation where the computer cannot detect its own failure.Therefore, when the system gets conflicting information, it arbitrarily ignores half the conflicting information. It does not know which of the circuits are lying or if they both are lying and shorted together. different resistance values will lead to arbitrary acceleration. Having the brake override it is a stopgap, but fixing the real problem (perhaps with a third circuit in voting mode which will require replacing the entire circuit path) or reversed sensors or log and opposing log sensors.

There might also be emi problems with induced magnetic fields in the CTS pedal assembly which detects induced emf as acceleration since it relies on induced emf to operate in the first place and is made of plastic. replacing with conventional denso rather than cts will also help.

Re:Yes, interesting.

[RzUpAnmsCwrds]

There might also be emi problems with induced magnetic fields in the CTS pedal assembly which detects induced emf as acceleration since it relies on induced emf to operate in the first place and is made of plastic. replacing with conventional denso rather than cts will also help.

Actually, the CTS pedal has more metal than the Denso pedal, which is almost entirely plastic.

Re:Yes, interesting.

[aristofanes]

IIRC back in the fifties a BOAC aircraft crashed in the caribbean. It had 2 radio direction finders, one of which developed a small fault which caused it to indicate a different direction.The pilot had no other source of information, and picked the wrong instrument.
This problem with only 2 sources of information was not new.
Ships captains, before radio etc. never had just 2 chronometers as they had no way of knowing which was correct. So they had either one or 3 or more

Re:Yes, interesting.

[zeet]

Those specs stink.

If the two sensors are being used to cross-check each other, they need to run in opposite directions. 0v-5v for the one sensor, 5v-0v for the other. That's the only way to get anything close to a sensible cross-check. Of course you won't be able to spot a shot at the crossover, but that should be easy to determine.

Re:Gods fault

[morari]

The real problem is people who think that not having any sort of actual linkage is a good idea. Vehicles have only become more and more problematic since the late 70s due to increased reliance on electronics in place of actual mechanical parts.

Shift to neutral.

[Anonymous Coward]

How bloody difficult is it to shift to neutral in an automatic or put the clutch in on a manual? I can do either of these tasks in a fraction of a second when I find there's a problem.

Isn't this taught in Driver's Ed? I know I was taught to do this if my car ever goes nuts or the gas pedal gets stuck down. Sure it's bad for the engine to be running it that high, but it's a lot better for it than being crunched into a wall or car is.

Re:Shift to neutral.

[RAMMS EIN]

``How bloody difficult is it to shift to neutral in an automatic or put the clutch in on a manual? I can do either of these tasks in a fraction of a second when I find there's a problem.''

Not as easy as one might suppose. Driving depends a lot on trained responses, and shifting to manual is just not one of them. That means it takes conscious effort. And conscious effort is difficult when the world suddenly goes out of control - the first reaction most people have is surprise, and the second reaction usually panic. Rational thought is difficult under those circumstances.

``Isn't this taught in Driver's Ed?''

What is this Driver's Ed you speak of? My experience in California is that you can get a license if you manage to drive a car around a block or two. In the Netherlands, where I got my license, it's at least customary to take several lessons before attempting the exam, but the lessons don't cover emergency scenarios, and those certainly aren't part of the exam. Long story short, if you got this as part of your education, your education is better than what I've seen.

Re:Shift to neutral.

[BoRegardless]

What happens when HAL says "I'm sorry Dave, I can't let you do this."

Re:Shift to neutral.

[dr2chase]

I dunno, I've had a hood come unlatched at highway speeds, dealt with it, had a fuel line come undone (spraying fuel all over the engine compartment as the car decelerated from highway speeds), and encountered (twice) people changing their tire in a 55mph travel lane. My wife had her brakes fail years ago, considered her options (intersection full of cars was one of them) and intentionally drove it into the side of a building to stop. Had a couple of DOZEN cats dash out in front of me once, I (sadly) coped. Stuff happens, you are not supposed to freak. Brake before the curve, steer into the skid, tap your brakes a lot if you don't have ABS. And if you don't like what you see (or can't see), your first choice is the brake pedal; speed usually makes bad stuff worse.

And every year when it snows, I go skidding in a parking lot, and back when ABS was a novelty (still don't have it on my car), when I'd rent a car with ABS, I would go try it out to see what it was like.

Testing shows the presence, not the absence of bug

[egnop]

The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.

Edsger...

Got to love the guy

Re:Remove all electroncis from the accelerator

[flyingfsck]

Uhmm and remove the ECu and fuel injector too I guess.

Dude, it is not the 1970s anymore...

Really?

[Kupfernigk]

You do know modern jet fighters are dynamically unstable and can't be flown mechanically, they must use fly by wire? You do know that if the Airbus that came down in the Hudson had been a previous generation aircraft most of the people on board would probably have died, because the Airbus computer is able to support landing on water and most aircraft aren't?

The simple fact is that overall a Prius with its minor brake transfer problem is far safer than any pre-ABS/traction control car. The fault is far less serious than, say, brake fade in drum brakes. And I don't even own a Toyota. You don't need any kind of tinfoil hat to think this is about bashing the part of the motor industry that is not US-owned.

Re:Little attention was given. Read Consumer Repor

[maxume]

Warning, made up numbers follow, but they illustrate the real situation:

G.M. may produce cars with 1/2 the quality of Toyota, but 20 defects per 1000 (or whatever) is merely inconvenient compared to 10 defects per 1000, not catastrophic.

Re:Little attention was given. Read Consumer Repor

[Igmuth]

But people have 'known' that most cars made by the big 3 sucked for decades. All of the various imports have been trumpeting their safety and reliability as a major selling point. (And importantly people accepted it as true). When a car manufacturer in that position starts have issues people are more likely to notice.

Absolutely Impossible to Verify!!!

[BoRegardless]

Opinions on verifying code as a means to tell whether a Toyota will have 'sudden acceleration' above are UTTERLY, well, let us say, ill thought out in my opinion, in most cases. Code is only ONE part of an almost hopelessly complex system when ALL THE POSSIBLE VARIABLES are analyzed.

Failure analysis may start with code, but these systems then can encounter intermittent connections, power surges, static generated by multiple known and unknown items (including the rare intermittent connections), induced currents in parallel wires, temperature induced changes, faulty seals & water/condensation intrusion, etc. By the time an accident investigator looks at a vehicle that had a problem, the transients are long gone.

Intermittent Mechanical (& thus often electrical) changes & failures are an absolute bane of complex systems.

In my opinion, the only way you can find these rare transient problems is to find vehicles who have been reported to have these problems (& didn't crash) and then you load them up with data loggers and drive the hell out of them in all sorts of environments.

Personally, I really like a 1972 Blazer...with a manual transmission. Minimal plastic, no electronics beyond the turn signal module, fix it myself and I can start it with a bit of a downhill run. Yup, I drive my Highlander, but I'm thinking of putting a 72 Blazer back in as new shape.

Re:Absolutely Impossible to Verify!!!

[hduff]

Personally, I really like a 1972 Blazer...with a manual transmission. Minimal plastic, no electronics beyond the turn signal module, fix it myself and I can start it with a bit of a downhill run.

I drive this a lot: 1937 Plymouth business coupe, Corvette LT-1 powered. Emissions-legal and easy to work on. Plus, people let me have the good parking spaces. http://www.socuteurl.com/tinyfuzzbutterbug

Example - car brought to dealer

[raftpeople]

Here is an example of a person that brought a car to the dealer while it was pegged - mechanic played with pedal and studied the situation:

http://www.leftlanenews.com/feds-investigate-toyota-electronics-for-unintended-acceleration.html

Not lawyers, use professional engineering bodies

[Morgaine]

Your suggestion that politicians are inappropriate while courts are appropriate doesn't make much sense. They're both of the same class, namely, both preoccupied with law and both clueless about technology. Even worse, the court system is adversarial and leads towards dollar damage limitation, not technological analysis.

This is an engineering problem, and the right institutions to handle it are the professional engineering bodies, particularly in Electrical Engineering and Electronics and in Mechanical Engineering, who for the most part are not corrupt, and they most definitely are not clueless about the technology.

Furthermore, they have a professional interest in staying outside of the financial and legal skirmishes, because their reputations depend on it. In a world that's truly messed up politically, economically and legally, Chartered Engineer is one of the few labels that still means something solid, at least to those who actually produce real things.

And in this particular subject, we really do need objective and trustworthy analysis of a very complex problem.

Really?

[raftpeople]

Here's one brought to the dealer with engine pegged:

http://www.leftlanenews.com/toyota-avalon-displays-unintended-acceleration-without-floor-mat.html

Re:Little attention was given. Read Consumer Repor

[publiclurker]

The last American car my parents owned was a GM. They spend a lot of time getting warranty work done on that thing and driving it while parts were non-functional. People pay good money for their cars to use them , not to be inconvenienced.

Re:Little attention was given. Read Consumer Repor

[ircmaxell]

The thing you're missing, is the level of those defects. The problems that GM had with quality were almost never safety related (And when they were, they weren't major and were fixed rapidly). Say what you want that their cars sucked, but in the 100 years they have been selling cars in the USA, they have never had as major of an issue such as this. Ford has (Remember the exploding gas tanks?). Chrysler has (They had an issue with cruise control that caused some accidents). I'm not saying that GM is good (I got rid of my last GM car 2 years ago, and I don't know if I will buy another one). What I am saying is that comparing quality by shear number of defects (As consumer reports does) is ignoring the much more important bigger picture...

Why so long to address safety issues

[sfm]

While I can sympathize with the general comment that witnesses are inaccurate, if Toyota acceleration problems are reported 10 times as often as those from other manufacturers, there is something worth investigating. Be it software, floor mats, bad springs, poor pedal placement or whatever, there is enough evidence that some kind of problem exists. I am disappointed it has taken Toyota so long to address these issues.

Black Box Info

[hduff]

Toyota should be more forthcoming with the black box info on these cars to validate exactly what the driver was doing at the time of the accident. But they won't because lawyers would be all over that data to file lawsuits. still, knowing the truth is best for all involved. Far less finger pointing; far better remediation of the problem.

Re:Black Box Info

[RandCraw]

It's just a matter of time before BB data is subpoenaed in a lawsuit, thereby opening the floodgate to BB data inclusion in *all* car liability lawsuits and probably most traffic violation litigation. Frankly I'm surprised BB's haven't become a mainstay in traffic court already. It'd be an unbiased improvement on the he-said-she-said prosecutions of today's grievously-flawed law enforcement process. Turn on those cameras!

OT: the shame

[thePowerOfGrayskull]

it assumes that because a situation can be induced in which no error code is set, that that exact same situation...

I am deeply ashamed by the above pathetic excuse for a sentence, and apologize.

Cars have brakes

[Joce640k]

Car&Driver did some tests and found that even with the throttle wide open the brakes can still stop a car, even a 500hp muscle car. With a normal car the distance wasn't even significantly greater than with closed throttle.

Re:Cars have brakes

[Lehk228]

that only works if the driver does the right thing the first time. if they first try to slow down, or do slow down to driving speed, by the time they decide to try to stop fully, the brake pads have cooked off.

And even wrong at that...

[gillbates]

I suspect the author was misquoted. There is no *inexpensive* way of formal verification of the software, but it is possible. Just ask Knuth; maybe even NASA.

Right now, we don't know the process Toyota uses for producing their engine control code. Was it outsourced? Did it go through formal review? Was it tested with a test suite designed to simulate all *possible* driving conditions? Did they test error recovery and adaptation scenarios? (physical sensors can be fickle things, you know).

I am a software engineer, and have seen some real abominations pass a code review. One piece of code used an uninitialized pointer, and not only did it pass the review, there were explanatory comments indicating this wasn't a problem in practice! Another piece of code, also reviewed, had a rather obvious race condition.

Granted, the task of producing bug free code is difficult, but surely Toyota knows this; I have a hard time believing Toyota produced a car in which a failure of the software module would produce fatal results. Surely they did not design the car so that an ECU failure would prevent the driver from shifting into neutral and applying the brakes!? Or is the Congressional testimony wrong?

ALAN TURING: HOW WRONG, INDEED?

[mosel-saar-ruwer]

How wrong can you be? Yes there is. Software is fundamentally the composition of many mathematical functions. Its results can be formally proven if the hardware it is running on is assumed (or preferably also proven) to be error free. Don't get me wrong, it would be incredibly cost, labor and time expensive, and require real computer scientists, but it is certainly possible.

The 1930s just called, and they want their Halting Problem back...

Re:ALAN TURING: HOW WRONG, INDEED?

[Nadaka]

I see a ridiculous number of people bringing up the halting problem as if it actually contradicts what I said. It doesn't.

Just because any program can be expressed as a Turing machine does not mean that they all are expressed as Turing machines. Nor does it mean that you can not prove that SOME SPECIFIC Turing machines will halt. The halting problem is that it is impossible to prove that EVERY Turing machine will halt.

Some problems can be intractable, that no matter how you express them, they can not be proven. But they are in the minority.

The assertion made by the Toyota representative was that it was impossible for software to ever be proven scientifically. This is unquestionably false. Most algorithms solved by computers can be mathematically proven. Software can be proven to conform to any algorithm. Do both and software is proven.

Re:ALAN TURING: HOW WRONG, INDEED?

[MechaStreisand]

Most of the people responding to you are definitely too stupid to have thought through the implications of the halting problem, and it is definitely true that you can prove that a subset of Turing machines can halt. However, the fundamental problem in actually verifying software is that if you specify the program's operation in sufficient detail that it completely specifies what the program must do, then the specification is itself executable, just without a compiler or interpreter to run it. Because of that, you're never actually verifying that a program is correct, only that it is equivalent to some other program. But you can't prove that that program does what you want it to do because you have no way of expressing "what we want it to do" as opposed to "what we wrote it to do". Testing is the only way you can become convinced of that.

It could still be useful to write programs in that specification language instead of using software engineers as hideously expensive compilers, which is essentially all they are in these situations. And it could also be useful to prove certain properties of a program.

Mod parent up!!

[Futurepower(R)]

I see you posted that earlier. I didn't read it then. What is a Toyota Camry VSRM? What is VSRM? Is that taken from a manual on a Voltage-Sensitive Release Mechanism?

To me, that seems in the direction that inquiry should go.

I've done design like that myself, although less complicated. It's not the design itself that I suspect. It is a reasonable guess, among other guesses, that the problem is something that has been overlooked, but associated with the components discussed above.

Re:Mod parent up!!

[mzs]

I think the obvious thing would be to trust the errer detection code in the ECM too much. This error path code that is not fully tested likely. What happens if there is some rare sort of error where the main/sub voltages read something like 4.5V and before then the ECM goes into lala land due to some bug (like error detected that main and sub do not match) and because of a coding error now is in an infinite loop handling that error say. Now the throttle position at the engine is at almost full open and stays there since the ECM never sends it anything else. Do they have something like a watchdog timer or this? Could this explain the 1s sudden acceleration on the Prius?

Formal Techniques

[Stonefish]

One thing that this article ignores is that software can be proven correct. The problem is that its expensive, time consuming and most programmers don't understand the techniques. In wikipedia look up Formal verification, if they can develop a provably correct OS then a provable correct braking system is achievable. The fact that programming has evolved into a trade rather than a profession has not improved matters. One thing of note is that Microsoft has employed the developer behind the coyotos operating system and has been throwing money at languages like haskell. How does a stratveegy of forcing carmakers to use a certified developer toolset made by microsoft sound from a business perspective.

Re:Formal Techniques

[Whuffo]

While your on Wikipedia, look up "halting problem". Next, fix yourself a nice dish of crow and eat up.

70s nostalgia

[sjbe]

The real problem is people who think that not having any sort of actual linkage is a good idea.

A mechanical linkage is not necessarily more reliable or safer. The fact that you can put your hands on it doesn't by itself make it better or worse. You are making an assumption based on your intuition that you cannot back up with data.

Vehicles have only become more and more problematic since the late 70s due to increased reliance on electronics in place of actual mechanical parts.

Nice sound bite but problematic in what way? Cars today are in general demonstrably more reliable, last longer, rust less, are (generally) safer in crashes, more powerful, and emit less pollution. At one point I made my living selling classic cars from the 70s and earlier. I'm very familiar with them first hand. You might like the styling better but performance-wise they are inferior to modern cars in almost every way I can think of.

Re:70s nostalgia

[Hognoxious]

He wasn't discussing cars as a whole, just the aspects relevant to the Toyota fiasco[1]. And he didn't even mention such things as performance and economy.

On old cars there's nothing second guessing you. When I press the left pedal, it disconnects the transmission. When I press the middle one, it applies the brakes.

Yes, obviously some things are better on modern cars, but that's not the point here.

[1] No, that's not their latest model.

Re:70s nostalgia

[AVee]

When I press the middle one, it applies the brakes.

Or the cable snaps and nothing happens. Luckily that is rather unlikely, and will only happen if you suddenly have to break really hard...

Compare withmachi machine tools

[calidoscope]

You made a good point.

One of the design "features" of the Toyota product involved in the 2009 fatal accident in San Diego was that the driver needed to press the engine start button for three seconds to kill the engine. Can you imagine any machine tool company making a product that required the emergency stop switch to be depressed for three seconds to turn off the machine?

Another issue with that car was that getting the tranny into neutral was not trivial (sport shifting option).

Toyota screwed up big-time here.

It may remain a mystery.

[WhatDoIKnow]

100 incidents out of millions of cars, each driven for years and thousands of miles... There is a good chance Toyota may NEVER discover the actual cause.

No way of verifying/validating software?

[Hurricane78]

"It is well-known in our community that there is no scientific, firm way of actually completely verifying and validating software."

It’s called Haskell with QuickCheck, idiots! Look it up!
And yes! It gives you guarantees on the level of mathematical proof, that it’s doing what it’s supposed to do!

How can someone work in an area where it’s about life and death of real people, and not know that??
Imagine someone saying that who works in the business of heart-lung-machine development. It’s hair-raising!

Re:No way of verifying/validating software?

[Cassini2]

It's called Haskell with QuickCheck, idiots! Look it up! And yes! It gives you guarantees on the level of mathematical proof, that it's doing what it's supposed to do!

Software developers that think the cause of most severe software failures is purely software, are the source of many of these software bugs.

The nasty bugs all revolve around complex system interactions, that just happen to involve software. No amount of Haskell code can fix them. Don't believe the marketing hype. Software bugs will be with us, long after the introduction and widespread use of functional programming.

Additionally, it isn't even obvious in a complex environment like an engine, that Haskell's sequential monad order for external I/O is both applicable and correct. Welcome to the modern micro-controller, where I/O sequencing is no longer a function of sequence of program execution.

AC not a troll

[DriedClexler]

While the tone could have been nicer, the AC was correct at least here:

if you have enough time to call 911 you have enough time to stop the car

Yes you probably might forget "the trick" they taught you in driver's ed when you're panicking. I probably would.

Yes people are being tremendously callous when they scoff that "Duh, why didn't you just put it in neutral lolz"

Still, if you really can't come up with SOMETHING to avert plowing into an intersection at 135 mph in the 60+ seconds they had, and you seriously expect someone miles away to get to you in two seconds, well, you were probably living on borrowed time anyway.

Toyota's new ad slogan

[reboot246]

Take off in a Toyota!

Re:Little attention was given. Read Consumer Repor

[Anonymous Coward]

Does Not Safe at Any Speed ring a bell?

Re:Gods fault

[TapeCutter]

I would hazzard a guess that frayed sticky cables are much more common than the sticky electronic type. I had one jam on my motorbike in the late seventies, not a big deal since it had a clutch.

As for your assertion that cars were less problematic in the 70's that is simply nonesense. The only way in which a 1970's car was superiour is that it was easier to do your own servicing and repairs.

Oh the Irony ...

[GNUALMAFUERTE]

Error 26: Syntax error at line No. 2

Yes ... PRONT won't work, I think PRINT would be much better. I just found a bug on your 2 line program (3 if you count Line 10, which is just a comment)

BMW

[Tromad]

How is BMW not #1? The gas and brake peddle are so close together on my 5 series they are practically the same pedal. Everyone in my family has had at least one accidental acceleration (but never an accident). I don't know why they have to put the pedals so close to each other.

Mechanical linkages != automatically safer

[sjbe]

He wasn't discussing cars as a whole, just the aspects relevant to the Toyota fiasco[1].

No he wasn't. He said "The real problem is people who think that not having any sort of actual linkage is a good idea." That has nothing whatsoever to do with Toyota specifically.

On old cars there's nothing second guessing you.

That doesn't automatically translate to better or safer. It's simpler but that is all you can say for certain unless you want to compare specific cases. Just as newer is not always better, older is not always safer.

Yes, obviously some things are better on modern cars, but that's not the point here

No that's exactly the point. The grandparent post was implying that a mechanical linkage is intrinsically safer while providing no evidence to back up that assertion. If you are going to declare drive-by-wire to be more dangerous than the alternatives, you had better back up that declaration with data.

I've seen this "mechanical linkages are safer" argument before and I've never seen anyone making it actually back it up with facts. They just pre-suppose that the simpler, older technology is safer. It may be or it may not be but I've yet to see anyone prove it.

Re:Mechanical linkages != automatically safer

[ffreeloader]

In most instances, if you have a total mechanical failure you will have previously had symptoms/warnings so that you could find the problem before total failure. If you have a mechanical failure in an accelerator pedal linkage you can bounce the pedal, pull it up with your foot, etc.... That won't stop every stuck accelerator but it will solve a few of them and I have done so a few times. Under drive-by-wire there's nothing you can do.

Same with manual clutch and brake systems. Failure usually comes gradually and you have some indication of problem before total failure.

Give me a car that I can still work on and troubleshoot without spending a lot on expensive electronic tools and I'll take that any day over the new technology.

Re:Mechanical linkages != automatically safer

[Dare nMc]

The problems here are not about mechanical being safer (it isn't.) But about simpler is much easier to make safe. Toyota is doing thing like adaptive shift logic, cruise control, traction control, taking out shock of things like Air Conditioners, etc. Having this many inputs makes it difficult, not to mention they replace a single linkage with a system that reads the pedal position sends it to a ECM that does lots of other things as well, then sends it to a servo motor, that moves a mechanical air restriction valve, then air flow is read by a MAF sensor that then determines fuel based on RPM, and finally injects the right amount of fuel.
My Diesel has electronic throttle that is much simpler, it reads the throttle, with RPM+boost it determines injection. Being a manual I do have a mechanical override right their as well, it's simplicity should make it much easier.
All this said, the ability to do multiple pickups with a electronic throttle and thus throw faults without any "oh shit" warnings like you describe is a big advantage of electronic, if done right. I have worked on vehicles with electronic throttles for the past 13 years (on Diesel) they can be replaced in a minute, with little skill set, they self tune, they keep a log of what went wrong, and on the systems I work on, you can click a few buttons on a display to show the actual reading and verify the whole system without leaving the drivers seat, they can easily be moved to the best position in the cab without linkage redesign, concern for what stress goes into what linkage, or heat, frozen water penetration, etc, etc.

Re:Mechanical linkages != automatically safer

[squizzar]

Obviously never had a cable based throttle jam open then. That has never ever happened to anyone...

Re:Mechanical linkages != automatically safer

[ffreeloader]

The problems here are not about mechanical being safer (it isn't.) But about simpler is much easier to make safe.

Ummm.... Mechanical linkage is simpler than electronic control, and this makes it easier to make safe. Thus it's safer than electronic control by your own definition.

Re:Mechanical linkages != automatically safer

[Dare nMc]

No, easier to make safe, doesn't equal safer end product. IE it may take more work and more verification to have redundant systems, but the payoff is greater safety. It is much simpler to have redundant system with the electrical throttle, than mechanical. Also a diesel with electronic throttle is much simpler than the gas mechanical throttle system. If you add in Cruise control, and a dual purpose pedal that needs a electronic feed to the auto transmission anyway, then you mis-fire the engine for traction control/rev limiter...
Granted the mechanical systems failures are more often a lack of accel, than a full accel (also more likely to blow the engine, waste fuel...) That can be more dangerous depending on when it decides not to accelerate (IE lack of acceleration stuck on RR crossing, in intersection, on interstate...

Re:Mechanical linkages != automatically safer

[ffreeloader]

My experience in of 40+ years of using all types of mechanical equipment from vehicles, to construction equipment, to farm vehicles, to recreational vehicles, is that I've never had a mechanical linkage fail without warning. There are always symptoms beforehand: stiff pedal, soft pedal, sticky pedal easily broken loose, noise when using linkage, limited pedal travel, etc.... You don't get that with drive by wire. It's also repairable by a much larger percentage of drivers.

To me that makes mechanical linkages much more "user friendly" and safer.

As to No, easier to make safe, doesn't equal safer end product.

Well, take a look at your own words.

But about simpler is much easier to make safe.

I fail to see how something that is much easier to make safe is not safer in the long run. It's the KISS principle. The more complex something is the more chances it has to break. It's that way with mechanical things and with software/electronic_equipment too. Keeping things simple is almost always the most cost-effective way to do things too.

Re:Mechanical linkages != automatically safer

[Dare nMc]

>never had a linkage fail without warning.
  exactly my point, sure both systems if designed right give you warning, the electronic system tells you which system and where and can then do what is deemed safest (fall over to backup tell operator to stop.) Those mechanical systems had warnings, but as it still failed, the warning sure wasn't clear enough. IE I have had many many mechanical linkage failures most the only warning was noticed after the fact, their may have been a 5 second whine before complete failure, or the throttle that stuck on me had rust on the spring that broke, a warning that was never seen until after the fact. Throttle cable on my cycle broke, sure it was a little more difficult to turn than usual, a sign that it might break in minutes, or weeks, or never; but a sign that did me no good since it was realized more as a "oh yeah" it was harder, I should have caught that.
> I fail to see how something that is much easier to make safe is not safer
I guess after years of doing FMEA on safety critical systems, it is second nature to me, that is hard to explain to the lay person. Read the article, then you may understand some of why most, if not all, commercial flights use fly by wire. Those with direct mechanical connections require constant direct supervision (generally before every flight) and require replacement after only a fraction of their useful life, out of fear of un-expected failures. With "by wire" the system will have triple redundancy, and self detection of all critical failures. So while having 3* the amount of parts, it is 3* more likely you will have some failure. But when their is 0 chance that the failure will affect the operation, other than raising a alarm for the need for repair.

But I also pointed out that the drive by wire system can be simpler. on my Dodge truck, it is much simpler than the drive by cable system on my previous Toyota truck. Both had cruise control, the Toyota required a separate linkage and motor, and cables and springs to link in the cruise control motor. Both have the same capability of a software glitch giving full throttle. Also the Toyota pedal turns a baffle which is read by a MAF sensor, which is fed into software that determines how much fuel to inject; instead the dodge has a sensor on the throttle that gives all the information directly (both had camshaft sensors, to give timing, and rpm etc, and fuel pressure gauges, temperature gauges, etc that is the other details needed.)
Since most cars now have Cruise control, and electronic automatic transmissions, they require a throttle position sensor, and electronic throttle control anyway. So which is simpler, the ones with drive by wire (that can override the mechanical linkage) and mechanical linkage. Or the ones without the linkage?
>repairable by a much larger percentage of drivers.
What % think they are capable but only duct tape something that make it worse? In my experience it is impossible to find someone who could replace a linkage but not the electronic pedal. I know which one I feel more comfortable replacing (hint, it's the one that tells me if I screwed up.) Granted the electronic is a bit costlier to just repair, but they last much longer anyway (except for the current Toyota problem.)

Re:Mechanical linkages != automatically safer

[ffreeloader]

I'll just comment on your last paragraph.

What's the % of people who can diagnose a failed electronic/electrical component compared to a failed mechanical component? In my experience, and I spent ~20 years as an HVAC service tech, even in professional trades only a small % of people who can diagnose mechanical problems can diagnose electrical problems. In HVAC service, where understanding electrical issues is a big deal, the number of experienced service men who understand such basic fundamentals as what the difference between 6 ohms and 6 megohms means in a circuit is very small.

I only ran across 1 person, besides myself, in the HVAC service business who had a decent electrical background. That doesn't mean people with a decent understanding of electrical fundamentals don't exist, it just means they are a lot more rare than people who understand mechanical issues.

Re:Mechanical linkages != automatically safer

[Dare nMc]

My experience is similar, but the number of people who can take the car to Autozone for a free diagnostic code reading; that tells them to replace the pedal should be everyone, just a matter of confidence.
Unfortunately me experience with dealers is that's also the best they will do regardless if it is electrical or mechanical as well (doesn't really help either argument though.)

Re:Mechanical linkages != automatically safer

[Hognoxious]

If you're going to declare drive-by-wire to be less dangerous than the alternatives, you had better back up that declaration with data.

Fixed that for you.

Go on. I'm waiting.

Re:Mechanical linkages != automatically safer

[DRACO-]

I've had borrowed my brother's '02 ford ranger that I experienced a throttle stuck open problem that was caused by a frayed cable linkage. I couldn't pull the pedal up. I had to shift to neutral and stop while then engine roared to 6000 rpm then dropped to 3000 rpm when the computer noticed no load. I shut the engine off after I stopped, popped the hood, spotted the fray in the throttle cable and pulled the throttle shut and drove it another 60 miles to get parts and home to fix it.

Re:Gods fault

[morari]

The only way in which a 1970's car was superiour is that it was easier to do your own servicing and repairs.

Exactly. Less problems due to over complicated designs. Having a computer decided what the computer should do is nonsense when you could simply have the pedal directly linked to the carburetor.

How to fix this sticky problem

[gamecrusader]

there is one way that Toyota can fix this problem FULLY REFUND THEIR CUSTOMERS and start over from scratch.

Re:Little attention was given. Read Consumer Repor

[ffreeloader]

As long as G.M. cars could continue to be sold, making unreliable cars was more profitable. That's similar to making a sloppy computer operating system that is vulnerable to attacks. The sloppiness helps sell new versions.

I agree. All three of the Big 3 car companies first introduced built-in obsolescence back in the 70's.

By the 80's Chevy's 350 cid engines were complete junk. The cam lobes would wear out in 50,000 miles and cylinder walls in many of them were already so badly worn the blocks couldn't be saved during an attempted rebuild. Ford and Chrysler were not much, if any, better than GM, quality wise.

The Japanese got a stranglehold on the car business by building reliable, fuel-efficient vehicles. Their cars were running 250-300,000 miles without major repairs compared to less than 100,000 for the Big 3's cars, and cost a lot less to drive, even without looking at the reliability factor. Figure that in and there was no economic reason to "buy American".

The Big 3 screwed themselves by screwing over their own countrymen and then started advertising that you weren't "patriotic" if you didn't buy their unreliable, expensive-to-drive, expensive-to-maintain pieces of junk. The hypocrisy of it all really stunk to high heaven.

Halting Problem solved? (was Re:What?)

[sl149q]

Alan Turing is rolling in his grave and Donald Knuth is waiting for your phone call to explain how you have solved the Halting Problem.

Re:electric

[scdeimos]

The scrapped electric vehicles story is well-known and well-documented. That's what happens when fossil-fuel companies own shares in vehicle manufacturing companies.

And, the "100 million lines of code" quote never came from Toyota - it came from Any Chou at Coverity (an software and security analysis company) who got it from Robert N. Charette at IEEE Spectrum.

Book: Unsafe at Any Speed

[Futurepower(R)]

Unsafe at Any Speed: The Designed-In Dangers of the American Automobile

Re:Little attention was given. Read Consumer Repor

[ffreeloader]

I've owned 5 Japanese vehicles now. A Mazda, a Subaru, a Toyota pickup, and 2 Hondas. None of them ever had any issues with rust, and the Mazda and Toyota spent almost 4 years in the ocean spray on the Oregon coast. On 4 out the 5 vehicles the odometers went/have_gone past 220,000 miles and two are still being used as daily drivers.

The Mazda was retired when a water hose broke and my wife ran the engine out of water completely frying the engine. At the time it was 15 years old, had over 220,000 miles on the odometer, and had no reliability issues. The only reason it was retired was there were no used engines to be found for it on the West Coast according to all the junk yards I talked to.

The Subaru was a gem of a car for the approximately 60,000 miles I drove it. I ended up needing a full-sized pickup though and so traded it in on a Ford F100.

My "newest" Honda is 11 years old and has 250,000+ miles on it. It burns no oil--the dipstick still says full at every 3000 mile oil change, gets 33 mpg on the highway, and the body panels, paint, and interior are still in good shape. No cracks in the dash, no tears in the rugs on the floors, and the seats are in good, if not great, condition. Even the trunk liner and trunk floor are still in good shape. It's a very reliable, very well-built car. All I do for it is fill it with gas, change the oil, and change the timing belt at recommended intervals, and buy tires. I haven't even had to do the brakes yet, although I've only had the car for the last 80,000 miles.

Nothing surprises me anymore.

[sr8outtalotech]

I'm with Toyota on this. How do they know if someone hit the wrong pedal or there was a software glitch. How many people are killed/injured a year because of people having senior moments? The DMV test in CA is a joke, they don't test you on the freeway/highway or check to see if you can navigate a country road at the speed limit without blowing the double yellow.

Re:Gods fault

[Dare nMc]

Do you seriously believe a carburetor is more reliable? Maybe the first 10 years of EFI was a pain, but it was competing against something with a 100 year old history of development but still requires constant fiddling and tuning that only a few people could do reasonably well, even after 120 years of carburetor development. Not to mention they were incapable of meeting emissions, mpg, compensate for altitude, or run at extreme angles, etc. About the only issue with current EFI, is the high pressures now required to meet emissions is difficult to produce reliable fuel pumps that don't cost big $$$ (and the cooling for this wasted energy.)

Re:Gods fault

[canadian_right]

Wrong. Cars have become MUCH more reliable over the years. Lots can go wrong with mechanical systems. A spring breaks, a rod binds, whatever. A friend had a car break the throttle return spring on a old muscle car and it took off like a rocket, hit a k-rail, ripped off both front wheels, went airborne and landed on a nice Cadillac.

Know what a tune-up is? You used to have to do one at least once a year to keep your car going. Not really done anymore.

I could go on like this for quite a while. I like working on old cars because they are simple. But the new cars are more reliable.

Re:Gods fault

[morari]

Know what a tune-up is? You used to have to do one at least once a year to keep your car going. Not really done anymore.

You don't check and change the oil in your car? You don't swap out the spark plugs and check the plug wires? You just wait until your breaks begin to squeak and the dummy lights on the dashboard pop on before taking your car to an overpriced dealer for anything, right? Man, I'd really hate to be your car.

Re:Little attention was given. Read Consumer Repor

[dotancohen]

The last American car my parents owned was a GM.

Toyotas are American cars too, in everything but name. They are assembled in America, and have no more foreign parts than do GM or Ford.

By the way, I loved this quote from TFS:

"The human motor system is not perfect, and it doesn't always do what it is told."

Right, because Toyotas' motor systems _are_ perfect, and always do as they are told! (full throttle! faster! faster!)

what Turing & Church proved

[mosel-saar-ruwer]

The assertion made by the Toyota representative was that it was impossible for software to ever be proven scientifically. This is unquestionably false.

What Turing [& Church] proved is that algorithms CANNOT be examined "scientifically" - that there can exist no [interesting, non-trivial] algorithm for examining algorithms - that there can be no "meta-theory" of algorithms.

In the end, there can only be eyeballs [accompanied by trial and error].

Re:what Turing & Church proved

[statusbar]

Yes, there can be no "meta-theory" of all algorithms in general.

But if you restrict your implementation of an algorithm to a minimal subset of a turing machine, then you can make an algorithm for analyzing it.

However the minimal subset may be not useful for the task at hand. And the programmers would cry because they couldn't just use visual studio to drag and drop their C code....

--jeffk++

Re:Bug-Free Software Is Indeed Possible

[Ihlosi]

Examples are thermostat programs that control the temperature of a room.

Yes, if your time scale is "minutes to hours", then you can write a nice linear program that doesn't use any interrupts, etc. Now, get that down to milli- or microseconds, and things get interesting.

And you don't just need to prove the software itself error-free. You'll also need the compiler to be error-free (or write everything in assembly), and of course the hardware needs to be error-free (or all known and unknown hardware errors need to be taken into consideration in the program).

Drive by wire

[snmpkid]

In my opinion the drive by wire systems in modern cars are not trustworthy enough to own. It amazes me that people who are advocates of Open Source systems to read their email trust their families lives to a proprietary computer every time they drive that shiny new prius.

The halting problem

[Eric Green]

It is theoretically provable that there are software problems that cannot be detected algorithmically. See: Halting Problem. This isn't new, boys, this was proven back in 1936 by both Alan Turing and John von Neumann.

Meanwhile, David Gilbert's testimony is quite interesting. What it appears to say is that Toyota is failing to detect a boundary condition -- two circuits that are supposed to have a differential output that instead are grounded to each other, but the computer instead accepting them and failing to signal any error -- and that this might be an indication that Toyota has a problem inside their software with detecting error conditions in the throttle circuit. Gilbert did not say that what he discovered is *the* problem causing runaway accelerations, just that it indicated *a* problem. Toyota can try to spin this all they want, but as someone who has an EE+software engineering background, I agree with Gilbert that this seems to indicate that Toyota's throttle control software is not as robust as they claimed and thus cannot be eliminated as a possible cause of the problem. All Toyota is accomplishing with their dog and pony show is making them look like the cigarette companies -- i.e., a bunch of lying b*****ds more concerned about the bottom line than about the health and safety of their customers.

Re:Little attention was given. Read Consumer Repor

[treeves]

My 1993 Ford Thunderbird has *only* 160,000 miles on it, but I've only had to replace the headlight switch, starter and alternator - no other problems. Anecdotes are AWESOME!

Emergency stops

[KMSelf]

I tested that capability of my car during the test drive. Since most cars now offer at least ABS (and some will give traction control), understanding what happens is very helpful. Level, straight, deserted stretch of road. Sped up to ~60 MPH. Stood on the brakes. Did that in several different vehicles I tried. More recently I had the opportunity to drive from San Francisco to Chicago for Christmas. Again, a deserted, level stretch of road, this time: how does the car handle braking at low speeds (10-20 MPH) in a panic stop on snow and ice? Familiarize yourself with such behavior, in a safe setting. Understand how your car handles differently on different surfaces: dry asphalt, wet roads, sand/gravel, snow/ice. For my own perspective, sand/gravel are the worst -- they appear without warning, vary greatly in quality, and have a bad habit of jumping up and leaving an impression on your windscreen. Oh well. In practice, the main problem with panic stops is the idiot following too closely behind you. I defend that space vigorously. NB: most insurance companies will pay completely fix the windshield if damaged as it's a safety hazard.

Re:Little attention was given. Read Consumer Repor

[stewbacca]

Awesome post. I couldn't think of two better examples of companies that let the bottom line dictate everything (GM and Microsoft).

Re:Little attention was given. Read Consumer Repor

[stewbacca]

Your anecdote is indeed awesome, but your car sucked even when it was brand new. My 1999 Ford Contour SVT has been nicknamed "Old Reliable" in our family. Yeah, the fit and finish has sucked from day one, and it's all creaky and old, but it has had exactly notdivisiblebyzero percent fewer problems than my 2 year old Mazdaspeed3 (also heavily Ford influenced).

Re:Gods fault

[TapeCutter]

No, not less problems. MORE problems but they were problems you could fix at home with a set of spanners.

Re:Gods fault

[canadian_right]

An oil change is not a tune up. A traditional tuneup was changing the plugs, adjusting the points, checking/adjusting the timing, and making sure the carb wasn't too bad out of adjustment.

Cars don't have points now, there is no carb to adjust, and the plugs can go for 100k before needing changed.

Oil changes are very important to do regularly, and you should get the brakes inspected regularly. There is other routine maintenance you should do, but it still isn't a "tune up" in the traditional sense of the phrase.

Re:Gods fault

[DRACO-]

Have you heard of mechanical computation? Analog computers? Water computers? We could do all this fancy eco crap with more mechanical parts in the linkage but software is cheaper.