Toyota's Engineering Process and the General Public 345
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.
"An event to challenge Evidence" (Score:4, Insightful)
> 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: (Score:2, Insightful)
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" (Score:4, Insightful)
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.
Little attention was given. Read Consumer Reports. (Score:5, Insightful)
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.
Re:Little attention was given. Read Consumer Repor (Score:4, Insightful)
Book: Unsafe at Any Speed (Score:3, Informative)
Re: (Score:2, Informative)
Yes, interesting. (Score:5, Informative)
"... 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. (Score:5, Interesting)
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:"An event to challenge Evidence" (Score:5, Insightful)
The entire testimony is built on that unproven assumption, without venturing to explain how it could occur in normal operations.
Re: (Score:3, Insightful)
int x = 1;
// Code proceeds on assumption that x != y
int y = 2;
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" (Score:4, Insightful)
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" (Score:4, Insightful)
Re:"An event to challenge Evidence" (Score:4, Insightful)
What? (Score:2, Insightful)
"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? (Score:5, Informative)
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: (Score:2)
> Most problems in automatic verification are either undecidable, or intractable.
Who was speaking of automatic verification?
Re:What? (Score:4, Informative)
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: (Score:2, Insightful)
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 ch
Re: (Score:3, Insightful)
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: (Score:3, Informative)
Do you have any references that support your emphatic claims?
Re: (Score:3, Insightful)
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 syste
Re: (Score:2)
Re: (Score:2, Insightful)
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 criticis
Re:What? (Score:4, Informative)
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: (Score:2)
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
Re:What? (Score:4, Funny)
If possible means getting an answer before the heat death of the universe you are probably wrong.
Another way to stop a car (Score:2, Funny)
Re:What? (Score:5, Informative)
There's even hardware to do it. dSpace [dspaceinc.com] 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 [vector.com]. 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 [slashdot.org] is used to write code in companies that use it.
SAE Paper on how Caterpillar [mathworks.co.kr] uses auto coding generation to write their stuff.
Re: (Score:2)
Preemptive operating systems [wikipedia.org] are becoming increasingly common in automotive.
Then that's just plain stupid.
However given that Toyota uses Simulink/RTW [mathworks.com], 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: (Score:3, Insightful)
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 ... (An
Re: (Score:3, Informative)
The temperature absolute zero [wikipedia.org] 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? (Score:4, Informative)
Absolute 0 is the coldest a material can get. You can have a temperature lower than 0 Kelvin [wikipedia.org], but it doesn't mean what you think it means.
Re: (Score:2)
That's all good and fun for an ERP app.
I want my critical apps written in ASM by real hackers.
Re: (Score:2)
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 c
Re: (Score:3, Informative)
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 solv
Re: (Score:2)
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: (Score:2, Informative)
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
Re: (Score:2)
And there's also the huge assumption that the requirements are correct
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
Re:What? (Score:5, Informative)
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.
dismissing user reports? (Score:2, Flamebait)
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? (Score:4, Insightful)
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: (Score:2)
"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? (Score:4, Interesting)
``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.
Why? (Score:5, Insightful)
Re: (Score:2, Interesting)
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 [consumerist.com]
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
AC not a troll (Score:3, Insightful)
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 we
Not lawyers, use professional engineering bodies (Score:2)
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 En
falsely blaming the user (Score:5, Informative)
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 [google.com].
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: (Score:2)
followup comments (Score:5, Informative)
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: (Score:2)
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
Re:followup comments (Score:4, Informative)
Re: (Score:2, Interesting)
Re:falsely blaming the user (Score:5, Informative)
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: (Score:2)
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
Re: (Score:3, Interesting)
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
tin.foil.hat (Score:3, Interesting)
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 (Score:4, Informative)
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.)
Anyone else think it odd? (Score:4, Informative)
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: (Score:3, Insightful)
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 af
Re:Anyone else think it odd? (Score:4, Interesting)
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: (Score:3, Insightful)
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.
Really? (Score:4, Insightful)
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: (Score:3, Insightful)
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, toda
Compare withmachi machine tools (Score:3, Interesting)
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
Re: (Score:3, Informative)
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.
Good time to buy a Toyota (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
Mr. Watanabe? Is that you?
Re: (Score:3, Insightful)
Verification needs serious improvements (Score:2)
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 smo
Software has no business (Score:5, Insightful)
... being in control of braking and acceleration.
Re:Software has no business (Score:4, Insightful)
Re: (Score:3, Insightful)
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: (Score:2)
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 ch
Re:Software has no business (Score:5, Insightful)
Re:Software has no business (Score:4, Insightful)
``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?
Can't be verified as safe? (Score:2)
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? (Score:5, Insightful)
Erroneus wrote:
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.
Formal verification? (Score:3, Insightful)
"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: (Score:3, Interesting)
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
Google has the anser (Score:2)
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 (Score:5, Funny)
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. ;)
here is the problem (Score:5, Interesting)
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.
Example - car brought to dealer (Score:3, Insightful)
http://www.leftlanenews.com/feds-investigate-toyota-electronics-for-unintended-acceleration.html
Absolutely Impossible to Verify!!! (Score:3, Interesting)
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.
Black Box Info (Score:4, Insightful)
Re: (Score:2)
We are talking about a real-time control system. It's unlikely to be structured anything like a video driver on a PC.
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3, Insightful)
The whole Toyota situation has become irrational. People knowingly sell and buy ca
Re: (Score:2, Insightful)
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.
70s nostalgia (Score:4, Insightful)
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.
Mechanical linkages != automatically safer (Score:3, Interesting)
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 w
Re: (Score:3, Insightful)
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 work
Cars have brakes (Score:3, Interesting)
Car&Driver did some tests [motortrend.com] 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: (Score:2)
Uhmm and remove the ECu and fuel injector too I guess.
Dude, it is not the 1970s anymore...