Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Toyota's Engineering Process and the General Public

Soulskill posted more than 4 years ago | from the try-explaining-software-bug-hunting-to-your-grandma dept.

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

cancel ×

345 comments

Sorry! There are no comments related to the filter you selected.

"An event to challenge Evidence" (4, Insightful)

Oxford_Comma_Lover (1679530) | more than 4 years ago | (#31390356)

> 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" (1, Insightful)

Pieroxy (222434) | more than 4 years ago | (#31390646)

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" (1)

ItsJustAPseudonym (1259172) | more than 4 years ago | (#31390788)

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.

Little attention was given. Read Consumer Reports. (4, Insightful)

Futurepower(R) (558542) | more than 4 years ago | (#31390910)

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.

Re:Little attention was given. Read Consumer Repor (1)

maxume (22995) | more than 4 years ago | (#31391464)

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 (1)

Igmuth (146229) | more than 4 years ago | (#31391468)

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.

Re:"An event to challenge Evidence" (3, Insightful)

digitalunity (19107) | more than 4 years ago | (#31391162)

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" (3, Informative)

joker784 (741265) | more than 4 years ago | (#31390818)

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

Yes, interesting. (5, Informative)

Futurepower(R) (558542) | more than 4 years ago | (#31391076)

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:"An event to challenge Evidence" (4, Insightful)

thePowerOfGrayskull (905905) | more than 4 years ago | (#31391202)

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" (2, Insightful)

thePowerOfGrayskull (905905) | more than 4 years ago | (#31391608)

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.

Gods fault (0)

Anonymous Coward | more than 4 years ago | (#31390362)

Toyota shouldn't bother to fix problems until human falability has been removed.

The real bug is upstream.

Re:Gods fault (1, Insightful)

morari (1080535) | more than 4 years ago | (#31391226)

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.

What? (2, Insightful)

Nadaka (224565) | more than 4 years ago | (#31390382)

"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? (4, Informative)

caffeinemessiah (918089) | more than 4 years ago | (#31390430)

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? (1)

Yokaze (70883) | more than 4 years ago | (#31390590)

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

Who was speaking of automatic verification?

Re:What? (3, Informative)

tomhudson (43916) | more than 4 years ago | (#31390630)

> 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? (1, Insightful)

Yokaze (70883) | more than 4 years ago | (#31391132)

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? (0)

Anonymous Coward | more than 4 years ago | (#31391302)

The Incompleteness Theorem has more to do with what is True -- in the Logical sense -- versus what can be _proven_ to be True within any given system. Importantly, it say that for any given set of rules and operations, there will be some True statement that cannot be proven as such, regardless of how much anyone -- human, machine, or other -- beats it over the head with Ye Olde Logic Stick; in order to prove that statement, one needs a more complete system of rules and operations.

Re:What? (1, Informative)

Anonymous Coward | more than 4 years ago | (#31391460)

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? (2, Insightful)

hey! (33014) | more than 4 years ago | (#31390984)

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? (1)

bunratty (545641) | more than 4 years ago | (#31391350)

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

Re:What? (1, Insightful)

phoenix321 (734987) | more than 4 years ago | (#31391232)

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? (1)

drewhk (1744562) | more than 4 years ago | (#31390494)

Um, Halting Problem?

Re:What? (1)

maxume (22995) | more than 4 years ago | (#31390946)

What about it?

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

Re:What? (1)

drewhk (1744562) | more than 4 years ago | (#31391120)

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

How?

Re:What? (1)

maxume (22995) | more than 4 years ago | (#31391182)

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? (1)

drewhk (1744562) | more than 4 years ago | (#31391340)

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? (1)

maxume (22995) | more than 4 years ago | (#31391510)

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? (3, Funny)

the eric conspiracy (20178) | more than 4 years ago | (#31390542)

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

Another way to stop a car (2, Funny)

ItsJustAPseudonym (1259172) | more than 4 years ago | (#31390862)

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

Re:What? (5, Informative)

0100010001010011 (652467) | more than 4 years ago | (#31390584)

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:What? (1)

Tyren (1170959) | more than 4 years ago | (#31390770)

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? (1)

0100010001010011 (652467) | more than 4 years ago | (#31391046)

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:What? (2, Insightful)

GNUALMAFUERTE (697061) | more than 4 years ago | (#31390620)

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? (2, Informative)

bunratty (545641) | more than 4 years ago | (#31390710)

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

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? (0, Flamebait)

Anonymous Coward | more than 4 years ago | (#31390916)

You are so simpled minded.

Re:What? (1)

ItsJustAPseudonym (1259172) | more than 4 years ago | (#31390974)

"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? (1)

GNUALMAFUERTE (697061) | more than 4 years ago | (#31391084)

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

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

Re:What? (1)

M. Baranczak (726671) | more than 4 years ago | (#31390690)

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? (2, Informative)

Fnkmaster (89084) | more than 4 years ago | (#31390808)

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? (1)

Nadaka (224565) | more than 4 years ago | (#31390900)

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? (2, Informative)

Anonymous Coward | more than 4 years ago | (#31390966)

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? (1)

TheLink (130905) | more than 4 years ago | (#31391366)

> 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? (4, Informative)

Antique Geekmeister (740220) | more than 4 years ago | (#31391186)

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? (0)

Anonymous Coward | more than 4 years ago | (#31391308)

This is 100% correct. See the halting problem.

Re:What? (1)

ailnlv (1291644) | more than 4 years ago | (#31391486)

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.

V&V (1, Interesting)

HellYeahAutomaton (815542) | more than 4 years ago | (#31390404)

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 (1)

ClosedSource (238333) | more than 4 years ago | (#31390678)

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 (0)

Anonymous Coward | more than 4 years ago | (#31390860)

Chances are the code is a complete mess and handles too much( all possible cases, delays/timer loops etc), which isn't unlike a video driver on a PC.

It probably works like a collective of hacks.

Re:V&V (1)

ClosedSource (238333) | more than 4 years ago | (#31391310)

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 (1)

Rich0 (548339) | more than 4 years ago | (#31390804)

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 (1)

SoapBox17 (1020345) | more than 4 years ago | (#31390940)

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 (1)

HellYeahAutomaton (815542) | more than 4 years ago | (#31391194)

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 (1)

phoenix321 (734987) | more than 4 years ago | (#31391358)

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.

dismissing user reports? (1, Flamebait)

jonpublic (676412) | more than 4 years ago | (#31390472)

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? (3, Insightful)

Rich0 (548339) | more than 4 years ago | (#31390840)

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? (0)

Anonymous Coward | more than 4 years ago | (#31391040)

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

LOTS OF PEOPLE suspect that vaccines cause autism. So, why hasn't somebody fixed that?

There. I fixed that for you.

I didn't know that Jenny McCarthy was on slashdot.

Re:dismissing user reports? (0)

Anonymous Coward | more than 4 years ago | (#31391188)

Nice, but it hardly means that everything that everyone knows is not true.

Re:dismissing user reports? (1)

jonpublic (676412) | more than 4 years ago | (#31391380)

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

Why? (5, Insightful)

Darkness404 (1287218) | more than 4 years ago | (#31390512)

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? (2, Interesting)

jonpublic (676412) | more than 4 years ago | (#31390894)

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 courts and Toyota keeps citing user error.

Re:Why? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31391552)

Sorry, but if you have enough time to call 911 you have enough time to stop the car. Put it into neutral, stop the car and turn the engine off. I only drive with manual transmission, but I read putting it to neutral would work with automatic as well. I guess to people who don't drive stick shifting to neutral might not be as obvious, but that's no excuse for not knowing how to handle a car in emergency situations. The "stuck accelerator" scenario is one I learned in driving school along with other, much more common problems.

falsely blaming the user (5, Informative)

SuperBanana (662181) | more than 4 years ago | (#31390524)

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:falsely blaming the user (1)

bunratty (545641) | more than 4 years ago | (#31390988)

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

followup comments (4, Informative)

SuperBanana (662181) | more than 4 years ago | (#31391036)

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 (1)

FrankSchwab (675585) | more than 4 years ago | (#31391644)

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:falsely blaming the user (2, Interesting)

Win Hill (1594463) | more than 4 years ago | (#31391178)

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 (4, Informative)

Registered Coward v2 (447531) | more than 4 years ago | (#31391630)

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 (1)

wfolta (603698) | more than 4 years ago | (#31391298)

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 (2, Interesting)

multisync (218450) | more than 4 years ago | (#31391386)

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.

tin.foil.hat (3, Interesting)

Anonymous Coward | more than 4 years ago | (#31390574)

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.

Anyone else think it odd? (4, Informative)

jhoegl (638955) | more than 4 years ago | (#31390606)

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? (3, Insightful)

sciguy125 (791065) | more than 4 years ago | (#31390732)

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? (3, Interesting)

hAckz0r (989977) | more than 4 years ago | (#31391348)

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 [insideline.com]

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? (2, Insightful)

couchslug (175151) | more than 4 years ago | (#31390796)

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? (1)

jhoegl (638955) | more than 4 years ago | (#31391082)

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

Really? (3, Insightful)

Kupfernigk (1190345) | more than 4 years ago | (#31391458)

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.

Good time to buy a Toyota (4, Insightful)

DogDude (805747) | more than 4 years ago | (#31390648)

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 (1, Informative)

Anonymous Coward | more than 4 years ago | (#31391136)

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 [consumerreports.org] . 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 (0)

Anonymous Coward | more than 4 years ago | (#31391272)

Maybe it's all FUD, but when it comes to the safety of myself and my family, there are already enough dangers on the road and I'm not going to add even the possibility of another. "It can't happen to me" ... famous last words.

I'll stick with my Honda, thanks.

Re:Good time to buy a Toyota (1)

T Murphy (1054674) | more than 4 years ago | (#31391362)

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.

Verification needs serious improvements (1)

js3 (319268) | more than 4 years ago | (#31390662)

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.

Software has no business (5, Insightful)

n6kuy (172098) | more than 4 years ago | (#31390680)

... being in control of braking and acceleration.

Re:Software has no business (3, Insightful)

megla (859600) | more than 4 years ago | (#31390926)

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

Re:Software has no business (2, Insightful)

peragrin (659227) | more than 4 years ago | (#31391028)

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 (5, Insightful)

raddan (519638) | more than 4 years ago | (#31391086)

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.

Can't be verified as safe? (1)

erroneus (253617) | more than 4 years ago | (#31390702)

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? (4, Insightful)

ediron2 (246908) | more than 4 years ago | (#31391098)

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.

Formal verification? (2, Insightful)

Pegasus (13291) | more than 4 years ago | (#31390720)

"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? (2, Interesting)

Rich0 (548339) | more than 4 years ago | (#31390906)

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

Google has the anser (1)

moteyalpha (1228680) | more than 4 years ago | (#31390726)

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 (4, Funny)

Vahokif (1292866) | more than 4 years ago | (#31390752)

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 (4, Interesting)

KevMar (471257) | more than 4 years ago | (#31390884)

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 (0)

Anonymous Coward | more than 4 years ago | (#31391290)

I've also been a user who's been dead-on correct about an error I've witnessed but wanted to file it as "eyes playing tricks on me". Niels Bohr did research that showed improved reaction time in a life-or-death situation. If a user tries to do something, and believes that what they did was correct, and that the system acted incorrectly, I definitely believe it is worth looking into. I'm a software engineer and every anecdotal time that I've seen an error, it's been an error with configuration changes required to fix it, and not some transient weird user error.

They admit that the floor mats caused problems. They admit that the pedal sometimes gets stuck. How can they possibly guarantee that the software is working flawlessly? In a signal based environment, there are almost guaranteed to be race conditions that happen in certain situations. To find them it usually takes thinking outside the model or design that you've put in place. Maybe your RMA schedules are all perfect. But what if the clock is heated to a high temperature? What if the cruise control shorts out? What if there is EM interference from a shorted window? What if the firmware to some piece of equipment is buggy? I don't envy the engineers who are working on a problem that is hard to find. But the first thing to do is to believe that the problem is there. As long as they don't believe a problem is there, it will be impossible to find.

Remove all electroncis from the accelerator (0, Flamebait)

smalleyster (1711542) | more than 4 years ago | (#31391122)

Remove all electroncis from the accelerator mechanism. Including Cruise Control. All electronics fail, way too often for comfort. Electronics are fine for radios, air conditioning, moving your mirrors...but they have absolutely no place in between the driver and the accelerator, the brakes and the steering. All critical functions should be mechanical. By Law!

Re:Remove all electroncis from the accelerator (1)

flyingfsck (986395) | more than 4 years ago | (#31391384)

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

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

Shift to neutral. (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31391268)

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.

Testing shows the presence, not the absence of bug (1)

egnop (531002) | more than 4 years ago | (#31391284)

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

Absolutely Impossible to Verify!!! (2, Interesting)

BoRegardless (721219) | more than 4 years ago | (#31391570)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?