I think the answer is - if people are having a higher rate of accidents than the norm, and the cause is due to the layout of the controls, then yeah, that sounds like the design engineer failed.
Frankly, that's the answer I expected...A bit of a side step when it gets to specifics.
But, it gives me a feel for where you stand, and to be honest, you aren't alone on these forums.
From what I infer from your (and some others) position, there really isn't any responsibility for the vehicle operator to become knowledgable about the controls of his/her vehicle before operating it.
I disagree. After all, its not like the gas and brake pedals are reversed. Now, I would agree something like that would be a ligitimate issue.
Thank goodness we don't allow airline pilots the same latitude (they are checked out on each specific aircraft design), and I sure wouldn't want to fly in a new airliner with 1970's controls and capabilities. Of course, cars aren't planes, but then again, would it be that much to ask a driver to know his vehicle? Most would expect anyone working on a mechanized assembly line to know the equipment they are using.
Until we revise our vision of expecting the automobile to make up for all the driver's mistakes and inattention, I predict more episodes like the Audi and Toyota ones. And, as these cars get more and more complex (to combat the owner's refusal to learn about his vehicle), of course there will be more failures, and we as a society will tend to blame the manufacturer, all because we refuse to assign responsibility accordingly.
Its been happening in the medical/drug field for quite some time.
But, I think you and Henry Ford would have gotten along famously. "Any color, as long as its black". His resistance to vehicle evolution paved the way for one of his competitors, the Dodge Brothers, who were former suppliers that had improvements that Henry Ford resisted incorporating in his cars. His philosophy also helped GM quite a bit as a competitor.
Hey, wait a minute. I thought we were at loggerheads. :-)
Do manuals now have drive by wire shift points then? Most automatics no longer have a physical linkage to the gears as I understand it. You move the shifter to "2" and the sensor tells the solenoid to downshift or whatever?
Busiris, next time you rent a car, check the glove box for an owner's manual. I bet the odds are 50/50 that it won't be there. Remember that Saylor went from his Lexus to a loaner Lexus. And yet he couldn't seem to figure out how to get it into neutral (his Lexus didn't have the push button on/off switch).
We're not at loggerheads now Steve since you are accepting other reasons for SUA besides what Edmund's is looking for.
I don't understand the point your are trying to make with the "do manuals no have..."
Have you considered Saylor ran out of time and may have been dodging traffic with the road running out? I take it you have most definitely did not read the Saylor investigation by the SDSD.
As host it is inappropriate to make statements such as "didn't have the push button.." The investigation clearly states this on pg 19 and if you check, it will clearly state that Saylor's own car was an 06 IS250 and it most definitely had a push button start, and his manual was in the glove box.
Really? I thought his was a different model than the one that crashed. So the '06 IS250 operated the same as the loaner '09 ES350? Three seconds to shut down, etc?
So ... even more reason to wonder why he couldn't shift to neutral. It's not like he didn't have 19 years on the force with CHP, and surely he had lots more driver training than most of us.
One theory that's been floated is that the drive by wire wouldn't let Saylor shift out of drive (the shifter may have moved, but the transmission may have "rejected" the input). So I was wondering if any of the newer manual transmissions were also drive by wire.
btw, you (and other interested parties and contestants) may want to follow this thread:
Plekto, How do you reconcile your positions on aircraft ETCs?
In your post 606 you said this: "Also, the ETC systems on aircraft are properly safeguarded and redundant."
In your post 634 you said this: "But as we've seen with even aircraft, screw-ups happen"
We know for a fact that there isn't hardly ANY car out there that doesn't have at least a few service or defect issues to deal with(TSBs or recalls or whatever they want to cal it, it's still a defect).
But to get more in depth, yes, the issue here is, if you bothered to follow the *second* link I posted on the other page, that there is a way to design a fail-safe system so that it operates as two entirely independent and redundant machines working together. The analysis of the assembly being taken apart on that page(and others) shows that FROM AN ENGINEERING STANDPOINT IT FAILS A 100% FAIL-SAFE TEST. 99% isn't good enough.
If it's not 100% then it can have a critical failure out of the hundreds of millions of activations a day in the millions of cars that have such systems. How? Well, I'll get to that in a minute.
Is it possible to design a system that is fail-safe and completely redundant? Absolutely. Aircraft designers(why I used that example) and NASA and engineering firms do it every day. Is it possible to do if you cut even one corner? No. You either do the system correctly or it just simply doesn't work. But human errors still happen and lead to things like software telling cargo doors to open while in flight(as a real life example).
**** But let's get to the crux of the computer issue. Given that that one vehicle gave a value of 255 brake presses, which is unreasonable to assume a human did in such a short amount of time, it points to somewhere in the chain there being a simple 8-bit processor and an I/O routine with software to monitor the sensors. Now, this makes perfect sense form a design standpoint. Low power, very robust and reliable, and pretty near idiot-proof.
But let's stand back and look at it from another angle...
Q: What is the #1 way in which computer operating systems have errors and crash? . . . . .
..
. . . (so you don't cheat...) A: more than 75% of computer operating system problems can be traced to hardware issues.
Surprising, isn't it? Bad memory, faulty power supplies, a failing hard drive, crud in the vents causing it to overheat, or even a power surge are usually the reasons. Now, to be sure, the other real OS problems do happen all too often, but the majority are actually hardware related.
Now, how exactly does this tie into the Toyota problem? 8 bit processors and simple I/O routines have a critical design flaw in that they respond poorly to external hardware problems. As an example, if you are over 40, you'll know exactly how 8-bit computers behaved when they crashed.
There was no task manager. There was no crash to desktop. What did they do? What they did, was to run one program flawlessly like a tank. But the second the hardware glitched or had an issue, it would freeze doing the very last thing that it was doing.
It literally would show the same image on the screen forever or play the same sound forever. Simple processors behave that way when they crash. No blank screen, no error - just simply get stuck. And require a reboot to fix. Nothing other than a reboot usually works, either.
16 and 32 bit OSs and processors, while more complex, did finally have crash handling built in, but the systems in a car simply do not. The Hosts' comments about Cell phones and the like crashing was dead-on. When simple computers like they use in automobiles(ie - dozens and dozens of small hard-coded processors and PRAMs) crash from external forces, they tend to exhibit this behavior.
So if you have a throttle sensor that crashes due to an external problem, if it is improperly designed, it will continue to blindly do whatever it was last doing. If that value for the throttle was, say, 212, then it is stuck at 212 until you reboot it and clear the error.
A previous poster also mentioned three incidents where he had to cycle the ignition to fix his vehicle that was reacting counter to his wishes. Naturally this is counter-intuitive to most people who either aren't old enough to remember computers and how they behaved back then or are unable to realize that it's truly "hard crashed" and only a manual power cycling will fix it.
I think what happened was Toyota's engineers were lax and assumed that because the Hall Effect Sensor was "super reliable" that they didn't worry about the computer connected TO it nearly enough.
Of course, as I stated, if they didn't USE such a sensor, there wouldn't be a need to design a proper fail-safe system in the first place. My Toyota has almost 400K miles on it and is 23 years old. With the same throttle cable. It's never failed to work exactly as it is supposed to.
Yes Steve Really - claiming his own car did not have push button start is a completely false statement being spread by some people. His ignition system was identical to the loaner car he had. Like most people he hadn't read the owners manual cover to cover - is this hard for everyone to believe?
So.. even less reason to speculate on this accident given your lack of background information. His driver training most certainly would not have included how to stop a runaway vehicle with fading brakes. Why people would think this worn out comment about his driving skills is beyond reason. The job he had at the time was "Special Duties School Bus Program Officer" A new transmission electronic theory? Besides being wild speculation, it's completely unsupported by any facts whatsoever. If you have a source for this I'd like to see it. And no, before your newest speculation spreads, no manual transmissions I know of are without a mechanical control.
I didn't find your link very useful at all since there is no technical information in it just more anonymous anecdotal complaints. In each story the usual information is missing, driver profile, circumstances of road, weather etc. passenger witnesses etc. and the usual I had the car inspected by a qualified individual technician who tested the car and found nothing wrong.
Busiris, next time you rent a car, check the glove box for an owner's manual. I bet the odds are 50/50 that it won't be there. Remember that Saylor went from his Lexus to a loaner Lexus. And yet he couldn't seem to figure out how to get it into neutral (his Lexus didn't have the push button on/off switch).
That's a bit of a "cop-out", Steve.
First of all, you continue to use an example of an auto with a known issue (incorrectly installed floor mats) that the dealer, for whatever reason, didn't correct. This car was already set up for a crash... almost guaranteed to have some sort of incident. We can hypothesize about why the driver didn't do a lot of things, but that's all. And, we can't rule out the possibility that he just "simply froze" at a critical time. That very thing has happened to pilots, etc.
We probably (may never) know exactly what happened there.
You may be right about the rental car issue, but tell us...How many UA complaints are made by rental users? Judging by what I read on these forums, the vast majority are auto owner-operators...although, I concede that there are a few examples (like the Prius up north that the maid drove into a wall) that are non-owner-operators.
But, as an old statistics teacher told me once, one or two points on a graph don't make a trend.
But, since you brought it up, try this.
Get a clipboard and a pencil. Go someplace where there are lots of cars...say,a shopping mall on a busy day. Act as if you are taking a survey, and ask 50 (25, 100, you decide what is enough) people these questions:
1- Do they own a car, and the year and model of their car?
2- Have they ever completely read the owner's manual?
3- If the car is 5 years old or less...Do they have anti-lock brakes?
My prediction is that the answer to # 2 is "No", and that well over 50% will give an answer other than "Yes" to # 3 (maybe, I think so, I don't know, I'll have to check, let me ask my husband, etc.).
If I am correct, then, for that percentage that doesn't give a definite "Yes", anti-lock brakes offer little to no advantage to those people. If you don't know you have a safety feature, how can one adequately employ it?
And, you did tell on youself a little, when you mentioned the push-button transmission in a response to my earlier post (humor intended).
Here's another "age" test.... Remember the early automatic's that had a different shift pattern, with reverse being all the way to the right? I'm sure it was changed to the pattern we have now, because so many were used to the "3-speed on the column", and the automatic "reverse" location was similar to the "1st gear location" in the 3-speed manual.
I guess...sometimes, its best to simply conform than to fight the forces of entrenched behavior.
Well Plekto I guess I got my answer. You now no longer believe your own statement in post 606 "Also, the ETC systems on aircraft are properly safeguarded and redundant." and prefer your second statement that contradicts it "But as we've seen with even aircraft, screw-ups happen" .
A child could understand that all your computer analogies start with a faulty premise - that someone, some where at some time must have physical proof of a faulty Toyota sensor, therefore ....This leads to a faulty conclusion every time no matter how many times you rephrase it.
Until you theorists get off your computers and under the hood all you're going to have is unsubstantiated rehashed rumors and theories. What you'll need to win this contest is physical proof to show a judge. Start by collecting components and test them one by one and eliminate them as suspects if they function correctly. Eventually if any of your theories are correct you should come across a faulty part.
So, if you truly were interested in finding a solution you need to start a real investigation involving real parts -
Some play fast and loose with the facts, twisting them to fit their agenda... conveniently ignoring the facts that don't easily fit into the equation.
Others simply re-hash items that claim to be facts, but in reality, are no more than hearsay, or even worse, outright fabrications.
And yet, others simply get it wrong. Thay make assumptions that have no basis in fact and are wrong from the get-go, and go down a road to nowhere.
I pop in and out of forums such as this once and a while, hoping to find one where posters actually stick with the facts (hey, nothing wrong about hypothesizing, as long as that's the way its stated).
So far, I'm batting zero.
One last item... I went to school with a fellow that wound up in the Highway Patrol, flying helicopters for the service until he had to retire for medical reasons 20 odd-years later. He had no more advanced driving instruction in automobiles that any average citizen, simply because he was an aircraft pilot, and that training would be a useless expense for the department. He did have adequate aircraft pilot training, as one would expect.
Kind of like making the assumption that anyone that served in the military has had front-line combat experience and is a weapons expert.
I'm just tossing ideas out there because it just doesn't add up to me.
Inability to shift into neutral isn't some wild speculation I just made up; that theory has been floating around for months now. It's all related to computer driven systems and whether they are failsafe.
Remember the reason why this discussion was started - we're looking for a novel and plausible cause of unintended acceleration in a consumer vehicle. Not every case of UA has involved floor mat issues. And not every case of UA happens to a technological savvy individual who can then log onto a bulletin board and post every last detail of what was going on when they experienced UA.
Afaik, there's only been one case where a car had SUA and the driver got it to a dealer and left it running so that the techs there could witness the engine racing. That driver got it to the dealer by shifting in and out of neutral. Haven't heard anything on that one lately.
I'm just tossing ideas out there because it just doesn't add up to me.
I don't take issue with that process.
However, one should stick to the factual, known information when suggesting possibilities. Example: Your mis-information in the CHP incident easily leads to incorrect conclusions.
If we don't stick within the facts as they are known, then we might as well suggest that little green space aliens are creating these incidents with superior alien technology and are forcing these incidents in order to destroy our confidence in technology, thereby making an eventual planetary takeover easier for them.
Frankly, that theory is probably just as plausable as some of the wild things that have been thrown out there.
Well Plekto I guess I got my answer. You now no longer believe your own statement in post 606 "Also, the ETC systems on aircraft are properly safeguarded and redundant." and prefer your second statement that contradicts it "But as we've seen with even aircraft, screw-ups happen" . No, I believe both statements. Let me explain. The control systems of commercial aircraft are designed to be properly redundant and will still work if any single part of the system fails for any reason whatsoever. That's what "fail-safe" means.
Anything other than that and it's smoke and mirrors and marketing BS. The Toyota system is not properly redundant. That's a simple fact. VW and GM, for instance, do design their systems properly - it's a design choice and not a matter of opinion. So my first statement is absolutely correct.
So is my second statement. Mistakes and problems do still happen. In a commercial airplane, or in a properly designed vehicle, a defect or physical problem won't cripple the entire thing. It will keep running because someone had the foresight to design it so that it would keep running even if some of the electronics were to fail.
A child could understand that all your computer analogies start with a faulty premise - that someone, some where at some time must have physical proof of a faulty Toyota sensor,
No, if you bothered to read what I wrote more carefully, you would understand what I'm saying:
1: That mistakes can happen and unless Toyota can prove to us that the computers and software aren't part of the equation, we cannot remove it as a potential variable. A faulty sensor isn't even part of my premise aside from the fact that, well, stuff does actually break and wear out. My concern is what happens when it eventually does suffer a critical failure.
ie - think UL labs and physical abuse-testing - did Toyota design for this or have it properly tested? How many auto manufacturers even design their computer systems to be fault-tolerant? From what I've seen of recent vehicles, when the computer has problems, the entire car becomes undriveable. My computer examples were based upon what I have seen happen when simple ICs and processors such as are used in a vehicle's sensors crash while they are running. Usually it's that they jam the system in its last state and this would completely explain the behavior that we are observing. Nothing works because the brain went dead and has to be rebooted. Obviously doing this while the car is still running might be a problem as some cars won't let you remove the key and cycle the ignition while it is in drive.
Well, Toyota hasn't come clean on this and there isn't a single engineering firm in Japan or the U.S. that has been given access to their computer code to analyze it to see if there's a simple mistake somewhere. Because Toyota is taking a hard-line on this and refusing to hand it over. Yet they blather on in the news about how they are concerned with safety and state that it couldn't have been their software. Yet no proof has been offered to back that statement up.
As my cousins in Missouri would say: "I'm from the show me state. Where's your proof?"
2: My main point is that all of this doesn't really matter. Because we have bigger fish to fry here. If you read the statement by Edmunds concerning the contest, it actually states *two* objectives. One is to find the cause in the Toyota case, and the other is mentioned as problems in the industry with issues like this as a whole. My main point from the beginning was to put Toyota's problems(which are likely software or computer hardware related(physical issue crashing said computers) in a box over to the side and leave it alone.
I've since the beginning been more concerned with the problem of Hall Effect sensors and how you have to design needlessly complex systems to monitor them and to be properly fail-safe. If auto manufacturers stopped using them, there would be no possible way that this scenario could happen.
Note - this isn't making any statement at all about whether this actually is happening or not. I'm talking from a scientific perspective. Can it possibly fail and give bad data to the processor monitoring it and/or can the processor mess up and pass along the faulty data to the rest of the system? The answer is that unless you design it very carefully, it can under some circumstances. It's a known issue with Hall Effect sensors.(also optical ones)
Basic analysis of the Toyota system shows potential problems with an improperly implemented fail-safe system. Is it the cause? We don't know. But it is worrying to myself and many others that it's cobbled-together and done improperly when there's no excuse for cutting corners on such a critical part of the vehicle.
That's the advantage of an analog system in this case. It's crude, but it's also incredibly fault-tolerant. GM and VW (as examples) use potentiometers and their fail-safe systems work as designed and to date there hasn't been a single issue aside from more warranty repairs for parts wearing out. The few out there that still use throttle cables, well, they have no issues at all. The computer can be a brick but the accelerator and steering is still under your control. As it should be.
It was said that we should "get under the hood". I tend to agree because you need to see what is there and how it is working. You can measure, examine, and test things you can get to.
The software isn't one of those things.
What we are trying to point out is that for software the hood is welded shut so we can't see inside, measure anything inside, probe or test. We have to just pretend we can solve the problem without opening the hood.
If the problem is there, we will never find it because we aren't allowed to look there.
You didn't explain why you hold both opinions and I didn't ask for a definition of failsafe.
Keeping in mind the advancement of the primary question "what is the cause of SUA?" How about we come up with a forum rule that politely asks all posters to list their primary source when stating something as a fact? Otherwise we can all waste our time checking what someone said only to find out its gossip instead of fact.
Let me give you an example; "The Toyota system is not properly redundant." You stated the following in post 657; From this claim you go on to build your conclusion once again. Maybe its true and maybe your conclusions based on it are true, on the other hand, if it is false then you are simply once again drawing conclusions based on a faulty premise. I could waste my time checking for proof of your supposed fact but it would save me a lot of time if you just simply listed it - its the nice thing to do and builds your credibility. I'll say this about their ETC system and components - "that they were likely built and designed to meet or exceed industry standards and that their rate of failure is likely the same as any other manufacturer in the world or lower. I used the word "likely" and didn't use the word 'fact" since I consider most people will accept the reputation of most manufacturers quality and lack of it and will place Toyota at or near the top. However if someone can provide convincing evidence to the opposite maybe we can look at it and learn something new.
I've caught Toyota, Ford, GM, Chrysler hiding defects before - but I (and any other mechanic) could always hold the part in my hand. Until you can let me touch your theory and look at it to my satisfaction you are not likely to get very far unless your whole objective is to obfuscate.
It was said that we should "get under the hood". I tend to agree because you need to see what is there and how it is working. You can measure, examine, and test things you can get to.
The software isn't one of those things.
What we are trying to point out is that for software the hood is welded shut so we can't see inside, measure anything inside, probe or test. We have to just pretend we can solve the problem without opening the hood.
If the problem is there, we will never find it because we aren't allowed to look there.
That really isn't a correct statement of fact. To be a bit basic...
A car is just like a modern heat pump. Both are mechanical devices, monitored and executed by electronic circuits, and programmed by software. The difference is, you drive one, and the other keeps you comfortable.
If your heat pump fails, you have it examined by a technician, just like your car.
The technician then checks inputs and outputs to the individual parts until he finds a condition that isn't congruent with the expected result. I don't think he calls up the corporate headquarters and request source code to solve the problem.
Unlike what many folks think, there is a limited number of inputs and outputs to examine in the control circuitry that controls an automobile. Until one of those shows an error or unexpected condition, looking at the software is practically useless... if your intent is to solve the "problem". So far, I haven't seen anyone show a single one of these conditions.
For a more basic example, I have seen mechanics diagnose faulty car voltage regulators by doing the exact procedure described above, never once taking the regulator apart. If the inputs and outputs are within expected parameters, the mechanic simply looks elsewhere until the problem is solved. If not, the regulator is replaced.
If one is knowledgable, there isn't anything "magic" about software at all.
Given there have been no known complaints of SUA in manual transmission Corollas.
1. Find an owner of a Corolla (#1) complaining of SUA (I found one for aVibe) 2. Obtain a second Corolla (#2) of the same year that has a standard transmission 3. Without the owners knowledge, switch the gas pedal, computer and throttle body in one car with the same parts of the other car.
If any of the ETC system is faulty then you can expect Corolla #1 owner will have no further complaints since the only components changed were the ETC. If the owner is still complaining than the ETC could not be the problem since Corolla #2 is known to be without complaints.
There must be a difference between the two types of vehicles for any ETC theories to be correct since there are no SUA complaints with manual transmissions. So just start changing parts till you find it. For a million bucks you'd think thousands of people would try this.
Sure I did. Aircraft are built with *PROPERLY DESIGNED* hall effect sensors in their controls and as such are immune to failure without being detected in enough time to be serviced and fixed. Automobiles are not. This is a design problem that is purely the fault of sloppy engineers and designers. Because if it is done correctly, it will operate without any possibility of an incident. But that costs extra money and time to design and has to be done exactly the right way.
It's a lot like a random number generation routine. There are dozens of ways to do it wrong and only a couple of ways that are truly 100% random. It's specialized knowledge, though, and more than 90% of computer science graduates probably have no clue or have not dealt with it, since it's not normally taught in their courses. I suspect that Toyota's engineers also didn't realize the intricacies of designing such a system, since they aren't likely to have designed such a system before for the military or aerospace fields where proper redundancy is required as a normal part of the design specs.
The second is merely my restating that again. IF there is a failure, be it by accident or not, can the system handle it? Toyota's cannot. Now, whether this is part of the problem or not has yet to be determined, but we have already found one point where it could be a potential problem.
Let me give you an example; "The Toyota system is not properly redundant."
Yes, I did state this. If you read this thread from the beginning, there are links and postings by others who are engineers and who deal with this field specifically that go into depth as to the intricacies of how and why it isn't properly redundant.
Read it and then come back, or look it up yourself. I'm not going to re-hash and re-quote stuff from over a month ago.
Its a common myth the investigation was sealed, never made public, etc. ...completely false
Well, maybe sealed is not the right right word. I was basing my comment on this from EDN magazine:
One has to recall Audi, which decades ago accidentally introduced drive-by-wire with its advanced cruise control on the Audi 5000. The cars were allegedly subject to spontaneous acceleration. The company blamed the problem on operator error. At the time, I was told that researchers at another European high-end auto company had uncovered a problem in Audi's engine-control firmware and reproduced the acceleration without requiring a driver to mistake the gas pedal for the brake. But in the ensuing liability litigation, all hope was lost of diagnosing the actual problem and documenting it so that the rest of the real-time software community could avoid it
So is my second statement. Mistakes and problems do still happen. In a commercial airplane, or in a properly designed vehicle, a defect or physical problem won't cripple the entire thing. It will keep running because someone had the foresight to design it so that it would keep running even if some of the electronics were to fail.
But, they don't always keep running.
Remember the design issues with the DC-10 aircraft? Triple redundancy in the critical flight control systems and hydraulics, IIRC. Only problem is, those 3 systems were run in close proximity to each other so that another failure that was not anticipated took out all 3 systems.
In one case, it was the loss of a cargo door, which led to depressurization of the cargo compartment, which led to the collapsing of the deck above it, which took out the triple redundant system.
In another case, it was the disintegration of a turbine or compressor disk in the tail mounted engine that again severed all three hydraulic lines, rendering the plane uncontrollable.
So despite best intentions and engineering, we still sometimes don't get it right.
One of the things that the airline industry and NASA does do (along with the FAA, NTSB, etc) is to try and drill down to the root cause of an incident and take steps to prevent that failure from occurring again. You usually don't see this same amount of diligence in the automotive world.
This is a great example of why listing sources is very helpful
Thank you for providing the source info. I just double checked and have this to say;
EDN Executive Editor Ron Wilson made a fatal mistake in his first sentence by stating something false and building on it until his conclusion - he made a number of technical (auto) mistakes. He may well be a genius with electronics but as he himself demonstrates his knowledge about particular automotive electrical system components is woefully lacking and elemental at best. I'll deal with his most glaring error in the first sentence;
"One has to recall Audi, which decades ago accidentally introduced drive-by-wire with its advanced cruise control on the Audi 5000." - This is a completely false statement. The Audi he's referring to were from the mid 80's and it had a standard vacuum operated control with a solid mechanical connection to the engines throttle valve. Below is a link to an image of an 88 Audi 5000 turbo engine - you can clearly see the vacuum servo on the cam cover. The 86 was identical, I worked on them.
He also stated there was evidence "and already evidence is emerging that the underlying problem is likely in the engine controller," Completely false again - to date there is no physical evidence whatsoever - even after 100's of investigations.
Given the date of Feb 4th this fellow may be responsible for starting this famous rumor.
Lets just say EDN wouldn't be your first choice for Toyota recall information
Given there have been no known complaints of SUA in manual transmission Corollas.
1. Find an owner of a Corolla (#1) complaining of SUA (I found one for aVibe) 2. Obtain a second Corolla (#2) of the same year that has a standard transmission 3. Without the owners knowledge, switch the gas pedal, computer and throttle body in one car with the same parts of the other car.
If any of the ETC system is faulty then you can expect Corolla #1 owner will have no further complaints since the only components changed were the ETC. If the owner is still complaining than the ETC could not be the problem since Corolla #2 is known to be without complaints.
There must be a difference between the two types of vehicles for any ETC theories to be correct since there are no SUA complaints with manual transmissions. So just start changing parts till you find it. For a million bucks you'd think thousands of people would try this.
Any comments?
Yes, that should eliminate several variables. Its what I would call a "field test" trial and error method, as compared to setting the electronic equipment and sensors up in a lab (across several tables, perhaps), and then beginning to manipulate the system by introducing input to the various sensors that correspond to what we find in the actual operating environment ( as I suggested in a few postings back). Trial and error again, but in a lab environment (and also in a better controlled environment).
If the "folks in the know" (ie., those with the most accurate information and closest to the investigation) haven't attempted something like either of these test-cases yet, then I would make the argument that they either are 1- incompetent, or 2- have serious doubts about widespread vehicle induced UA in these vehicle lines.
One of the things that the airline industry and NASA does do (along with the FAA, NTSB, etc) is to try and drill down to the root cause of an incident and take steps to prevent that failure from occurring again. You usually don't see this same amount of diligence in the automotive world.
That's true, for several reasons.
Some, but not necessarily all of them:
1- Commercial airliners/space craft costs several million $$$ or more EACH. The potential loss of that kind of money tends to make one wish to minimize losses, and willing to pay a bit extra in order to achieve that result.
2- Commercial aircraft operate in a much wider range of environmental pressures.
3- Operators (pilots) are, in theory, much better trained that the average driver and can give much better and accurate information feedback.
4- A single "event" can result in 100's of lost lives. Not so many in a car wreck.
5- Operation of aircraft is much more structured than operating a vehicle.
6- Every pilot has been checked out and qualified on EACH individual plane design before being allowed to transport passengers. Once one has an automobile driver's license, he/she can drive any number of different vehicle makes and models. And, in most cases, never EVER take a course or test again in his/her driving lifespan, possibly a span of 60 years or more.
I could go on, but I think you get the idea. However, with the advent of data recorders in cars, we are moving in that general direction.
Just curious...What percentage of auto owners do you think read their operating manual cover to cover?
Anyone want to throw out a number? Off hand, based on my experience, less that 10%. Even if I am off by a factor of 9 (lets say that 90% actually DO read their manuals), that still leaves an enormous REAL number of drivers with less than an optimum BASIC understanding of their vehicle.
Now, what investigator would seriously take input from that group of people regarding vehicle malfunctions, other than a cursory evaluation of what they have to say?
To me, that's like a court taking a medical opinion from an actor that plays the role of a doctor on TV.
Personally, if a professional race car driver were to cite vehicle UA, I would be far more prone to believe that there is an actual problem than someone else who is not nearly as familiar with their individual vehicle's operation and features..
Thanks for bringing up the airplane examples. They immediately came to mind when I was taking about this originally, but I assumed that it was common knowledge that even with a properly designed system, well, sometimes it hits the fan anyways. This may not be Toyota's fault. ie - who knew to shield ICs versus certain cell phone frequencies? Or that some surge in a component in the lighting system would cause specific cascade effect. Or something else that was un-forseen. These obviously are not real examples but made up ones - sometimes the oddest crap happens and cripples it.
But nothing in any automotive system that I know of is designed with any redundancy. At best the computer detects a problem and goes into "service/limp-home" mode and that's that. But if the computer itself is in trouble, well, anything can happen. Now, in the past when that has happened, odd things start happening, but with manual control over brakes, steering, and acceleration, you can deal with it. What has happened in, say, a Prius is:
Throttle and brakes are controlled by computer. Transmission is controlled by computer. Ignition is controlled by computer. Steering is electric/controlled by a computer.
That's the full boat, folks. It's a video game on wheels. There is nothing that will save you if the computer system hard crashes and locks itself in its last state. Normally you would have a last-ditch option of yanking the fuses to the computer but the fuses are under the hood. I'm amazed that problems with the things aren't common. In a way that's a testament to Toyota's skills, but in another, well, the 2nd generation vehicles aren't even close to ten years old, so electrical failures due to age are fairly rare.
Is it too much to still expect manual control over our vehicles? Apparently Toyota seems to think so.
He also stated there was evidence "and already evidence is emerging that the underlying problem is likely in the engine controller," Completely false again - to date there is no physical evidence whatsoever - even after 100's of investigations
This from the Center for Auto Safety:
The only study to pinpoint a specific defect within the vehicle, "Risk Assessment of Cruise Control," by Mats Gunnerhed, was conducted by the Swedish Defense Research Establishment of the Department of Information Technology. Issued in May of 1988, it concluded that within certain types of cruise control systems "there is a single-point-fault mode that leads to sudden acceleration at high power." The specific fault pointed out by the Swedish agency was a "bad solder joint" in the Hella cruise control used on 1981-83 Audis. All of the Audis experiencing sudden acceleration which are the subject of the class action were with cruise control systems.
The technician then checks inputs and outputs to the individual parts until he finds a condition that isn't congruent with the expected result. I don't think he calls up the corporate headquarters and request source code to solve the problem.
Generally there are only two or three inputs - a temperature sensor, a setpoint value, and on/off, with a simple PID loop for a heatpump. Some don't have even that. Engine controllers have over a dozen sensors and are required to perform certain diagnostic tests (OBD2) to meet emissions. You are comparing a dimming light switch to a color tv. I wouldn't need the schematic to diagnose problems with the dimmer, but I would need the schematic to the TV. The schematic is the source code. Unlike what many folks think, there is a limited number of inputs and outputs to examine in the control circuitry that controls an automobile. Until one of those shows an error or unexpected condition, looking at the software is practically useless... if your intent is to solve the "problem". So far, I haven't seen anyone show a single one of these conditions.
And the complexity goes up with the square of that number, and there are more than a dozen on any modern car. There are also internal states (timers and counters - on my car, if it is moist the MIL light goes on because the O2 sensor on the catalytic converter gets a bad signal - I need 5 keyon-keyoffs to clear it; if the gas cap is loose, it will come on after some time, not immediately).
Another simple example is idle speed control. The engine has to run faster to warm up to meet emissions. This is usually a combination of timing and engine coolant temperature.
Tell me how to set these purely internal states on a bench? The condition is inside the black box and unknowable. I can't show you what I can't see, but it exists. Toyota is likely to have similar timers/counters. If I give you a car, can you tell me if the counter will expire next key-on? In three? In 10?
The "unexpected condition" may be purely in one of these internal virtual states. A counter or timer might be causing a divide by zero or overflow confusing the calculations.
My contention is that if you took a factory fresh ECU (or set) and played back precisely the conditions that led to the SUA, it would demonstrate the problem. But I can't . These aren't recorded, and although I can simulate external conditions, I can't know the internal state. So I could theoretically recreate the condition (break sensor indicates on, engine still energized), but I probably couldn't repeat it since I can't reset the ECU to factory fresh (if I could it would be odometer tampering). It also might only happen once every two days, but not consistently - if it is an internal state, with a band of external states, it would only show up when the ECU was in a specific state.
For a more basic example, I have seen mechanics diagnose faulty car voltage regulators by doing the exact procedure described above, never once taking the regulator apart. If the inputs and outputs are within expected parameters, the mechanic simply looks elsewhere until the problem is solved. If not, the regulator is replaced.
If one is knowledgable, there isn't anything "magic" about software at all.
A regulator has one input and one output. I can simply ramp the input voltage and see if the output is within the envelope.
The ECU has brake, throttle position, O2 sensors (on the exhaust and to verify the catalytic converter), engine coolant temperature, maybe anti-knock, often gets loading over the bus (e.g. A/C on-off), cruise control settings, transmission gear, engine degrees from TDC, battery voltage... It controls the phase and duration of injectors, the advance and dwell of the spark, the throttle (for idle if nothing else), sends RPM and MIL light and whatever else to the instrument cluster, controls the emissions system components...
It isn't magic, but it is complex, or more properly chaotic as in "the butterfly effect" - and even that is only one variable. If I give you exact values for all the inputs listed, I defy you to tell me the expected and correct state of all of the outputs just like the regulator. And that is at one multidimensional one point. You are claiming that the transfer function between all the inputs and outputs is something you can calculate in your head or on the back of an envelope.
It isn't so. I haven't mentioned internal states above because there may be an answer that is correct or wrong depending on the internal state.
The atmosphere is well known and the physics of fluids and thermodynamics have simple equations. Is it going to rain or be sunny on Memorial Day weekend (two weeks from now)? You have all the inputs - current pressure, temp, humidity, and the equations. Just run the calculation. It should be simple.
The (x,y,z,w...) = f(a,b,c,d...) equation for any modern ECU would be mind numbingly complex (it was even going back to carburetors and the spaghetti of vacuum hoses where the ECU was just used to position a valve like mechanism to get to stoichiometry).
Can you even say if at any given point if you dropped the engine coolant temperature input 20 degrees C, would the idle speed increase or the MIL light come on indicating the coolant temp sensor was defective or something else?
If you do know the complete equation for even one vehicle that experienced SUA, please post it here. Even then, does the software implement it correctly?
...but I assumed that it was common knowledge that even with a properly designed system, well, sometimes it hits the fan anyways
That was probably a bad assumption . Not sure just how "common" that point of view is. I happen to agree with you - that even in the best of systems, it sometimes happens. But, that viewpoint is probably not widespread in the general consuming public.
They expect complex systems to work perfectly, under all conditions, no matter what people do with them (remember the dude that sued the lawnmower manufacturer when he injured himself trying to trim his hedge with the lawnmower). However, as some of us know, it is impossible to anticipate all conditions/situations that may arise over the life of a product. You can do your best to anticipate the known unknowns, but it's the unknown unknowns that get you :shades: .
Another example of "the complexity syndrome", in that you seem to think its far too complicated to know all of the input information at once. Its not, and indeed, the designers of these (as in any complcated systems) did exactly that. And, every authorized Toyota dealer has the information from Toyota that tells them the acceptable ranges on each input and output. Its no trade secret.
Exaclty how do you think computerized assembly lines are created?
Of course, all of these things are tested together and coordinated.
Thats a fact, or else Toyota (and every other car company) would be flying in factory engineers to do any repairs related to electronics.
I never suggested that it would be a quick experiment or test.
As far as doing this, companies have done the `very same thing in developing competitive processors to compete against Intel. That technique is called "reverse engineering", and it goes on daily in countries like China.
Every single thing one needs to determine a possible fault in the electronics of ANY vehicle is within the vehicle itself.
Now, if you wish to go to the next step, which is ....
What happens when an actual fault is detected?
I will agree that viewing the source code may indeed be necessary. But, if its just bad input from a faulty sensor, its the sensor....not the code. And, one may even be able to add another fault tolerance level at that point in the routine.... and maybe not.
You can attempt to program a system to be 100% fault tolerant, but no one has succeeded in doing that yet, at least, to my knowledge. The necessary additional components to do that would be mind boggling. A great example...the space shuttle.
There seems to be some pre-conception by some that cars were fault-tolerant until electronics came along. That's simply not the case. Suffer a broken tie-rod end, a strut collapses, an axle breaks...any of these can certainly be catastrophic at 60 MPH. And, if you spend much time on the highway, you can see cars that experience these very events.
Its like the Y2K scare. So many "experts" predicted planes falling from the sky, complete computer system collapses, etc.
I remember seeing a 60 Minutes segment of some guy who was a well-qualified IT "expert" who had bought acreage in a desolate, remote place, fenced it in with barbed wire, built a house and stocked it with disaster supplies and moved his family there. All because of the impending disaster. I would love to where that dude is today...LOL!!!
1. Ron Wilson said "already evidence is emerging.." clearly he wasn't referring to a report from 1988.
2. Given Mr. Wilsons background he was clearly talking about Toyotas main ECM and faulty computer code, whereas Mr Gunnerhed claimed a badly soldered joint could cause a single failure. Both are talking cars and electrical systems but Wilson was talking about computer code and Gunnerhed was talking about faulty circuit design and manufacturing errors - difinitely not the same thing. It has never been claimed that Gunnerhed found real world examples of it in any car let alone Audi, only that it was possible - its the same old Sam Sero theory. (or did Sam take his theory?)
3. It may interest you to know that Mr. Gunnerhed has approx 11 published papers listed in the Swedish Defense Research Establishment of the Department of Information Technology. (FOI) but none are about Audi's cruise control and he has nothing listed for the year 1988, so unless anyone has the actual study (if there is one and its odd that Ditlow didn't post it) maybe Ditlow got his facts wrong.
I'd be glad to help you out. I think I'm qualified to offer an unbiased perspective and advice for the following reasons;
1. I'm Canadain 2. I'm not and have never been emploed by any automotive manufacturer including Toyota. 3. I find the issue of SUA one of the most fascinating automotive issues to have ocurred in my lifetime. 4. My main form of employment would be that of an automotive instructor forthe past 24 years. 5.You can check me out at carquestions.ca or on youtube - carquestions
The atmosphere is well known and the physics of fluids and thermodynamics have simple equations. Is it going to rain or be sunny on Memorial Day weekend (two weeks from now)? You have all the inputs - current pressure, temp, humidity, and the equations. Just run the calculation. It should be simple.
I wanted to respond to this comment all by itself.
I highly doubt anyone educated in meteorology would agree with your assessment. In fact, we don't even know all of the input sources to the weather systems, much less what they are at any given time.
In contrast, we do know each and every input source in an automobile, since they were designed and constructed by humans. There is a dozen or more technicians at the local Toyota dealership 10 miles from my home that can give us that information....as well as what the expected ranges of those inputs should be.
Its a relatively simple task to set a lab environment up and test an ECM, varying each and every input (to infinity, if we wish) to see what the ECM outputs. We can even do things we can't to in a car with an operator...bombard it with radiation, submerge it under water...even simulate a sensor condition that makes it think its sitting on the surface of the sun.
EVERY SINGLE STATEMENT ABOVE IS FACT.
For those who continue to simply take the word of a driver, consider this...
Hundreds (maybe thousands) make the claim of vehicle induced UA.
Of course, many more have made the claim of alien abduction. What factor(s) cause you to believe the first claim without believing the second? Or, maybe you believe both?
While the condition of widespread Toyoya vehicle caused UA may eventually win out in the court of public opinion, reality may end up with a completely different conclusion.
In fact, much of this argument is following in the very same footsteps of the "vaccination causes autism" claim, and after many years of investigation and numerous studies, not one peer-reviewed study has successfully made the case for that condition, either.
If you have a Toyota vehicle that has displayed this issue multiple times, then I would say the electronic components (ECM and supporting sensors) would provide an execellent basis for a testing regimen as I described above.
What concerns me to a great extent is that so many have condemned Toyota's software and yet ignored the possibility of a bad run of ancilliary equipment that interfaces with the ECM.
I hope you get an acceptable resolution to your problem, one that actually resolves the issue.... Not a solution that simply enriches a group of lawyers and leaves you out in the cold.
Its a relatively simple task to set a lab environment up and test an ECM, varying each and every input (to infinity, if we wish) to see what the ECM outputs
Sorry, I disagree with that statement.
If an ECM has 4 inputs, and each input can take on 256 values (quantized to 8 bits), then the number of input combinations that have to be tested is not 256+256+256+256=1024, but rather 256*255*254*253=4,195,023,360. And even this estimate does not allow for the order in which those inputs may change, which may (or may not) affect the state of the system, and which would add another couple of orders of magnitude to the number of test cases.
You cannot do what I thought you suggested - test each input as if its effects on the system is independent of the other inputs, without some apriori knowledge of the design of the system to help you chose your test cases in an educated fashion - knowing what the corner cases are, what the stressing input combinations may be, etc.
You cannot, except for the most simplistic of systems, prove their correctness just by throwing test cases at it.
Just because you can't understand the process in no way invalidates it.
And just because you have a process in no way validates what you are trying to demonstrate.
IF you have a good understanding of the way the product was designed, understand it's nuances, know where the corner conditions may be, understand the structure and control flow of any software, etc, THEN you might have a shot of coming up with a well controlled set of tests that would help uncover any weaknesses in the product. But lacking that knowledge, you or anyone else is just flying blind thinking that just by throwing a bunch of tests at it, you are going to uncover critical problems. Sure, you'll find some, but no amount of testing will guarantee that you've found all problems. That's why there's no substitute for a thorough understanding of the product under investigation.
You cannot test quality into a product - it has to be designed in from the start.
There was the Therac-25 that mostly worked, but backspacing in a field ended up literally killing people. There is that Breathalyzer with several bugs only visible in the source code (when DUIs were challenged - I posted a link much earlier in the thread) - it didn't follow any spec, weighted samples differently and had other problems but literally sent people to jail. Then there's that European rocket launching a satellite and that mars probe.
This might end up being another chapter in "fatal defect", or perhaps it is not there, but again the problem is I can't look there. I would like nothing better than to exonerate the software, but I can't decide either way without looking.
You cannot, except for the most simplistic of systems, prove their correctness just by throwing test cases at it.
That's the flaw in your argument.
I don't have to ( and never can, for that fact) prove there are no problems within a system. However, I can prove that there are problems.
That's a subtle, but very real difference.
If you don't understand that concept, then you really should leave the testing of complex systems to those who have a grasp of the concept.
And, after all, isn't that the goal here? To prove there is a fault (not every fault) within the Totota ECM software?
If the problem is as widespread as so many seem to think, and examples abound, do I really have to simulate a condition as if I were driving the car at 1 million MPH on the surface of the sun? Wasn't that the falacy in Dr. Gilbert's test? Creating an error condition that would most likely never be found in the operating environment? Exactly what did that prove, other that you can inject a variable into a circuit that it never reasonably expected to see, and then got a result that also was never expected? What do you think that proved?
An example...Take a 6 sided game die, for instance.
If I tell you to search for all possible 6's (call the 6 an error condition), and the conditions of the test don't let you inspect the die before the test (you have no idea how many sides there are on the die with a 6..ie, Toyota's ECM software), how many rolls will it take you to conclusively tell me how many 6's there are on it?
But, if I give you the same die, along with the same information, but now tell you to tell me if there are ANY 6's on it, how many times will you need to roll the die to give me an answer of "at least one"?
There was the Therac-25 that mostly worked, but backspacing in a field ended up literally killing people. There is that Breathalyzer with several bugs only visible in the source code (when DUIs were challenged - I posted a link much earlier in the thread) - it didn't follow any spec, weighted samples differently and had other problems but literally sent people to jail. Then there's that European rocket launching a satellite and that mars probe.
This might end up being another chapter in "fatal defect", or perhaps it is not there, but again the problem is I can't look there. I would like nothing better than to exonerate the software, but I can't decide either way without looking.
To be honest, I'm not familiar with any of these devices. But, let's take a look at the Breathalyzer mentioned.
Seems to me that a minimal amount of decently designed control testing could have easily turned up inconsist results, if there were as many widespread errors as your comment implies.. If the bugs can be detected in the code, they are bugs. And bugs show up in the device the code is controling. Now, it may be easier and faster to find blatant errors by examining the code, but it certainly isn't a requirement.
How about a link to some info on the device, as well as a link to how the problems were found? I'd like to read a bit more about it. Sounds a little like what I have read about some traffic cameras, but those weren't exactly "bugs", but faulty parameter assumptions.
An explanation of the Therac-25. Just for the record, the problem was well recognized before the code was examined to determine the exact cause of the failure. Examining the code simply explained how the failure occured. There was real evidence of the failure that could be examined after the failure (ie, the radiation effects on the body).
Still, an interesting example of what can go wrong....
Your examples are a continuation of a flawed premise - "the computer code errors theory ..." In each and every one of your examples the machines you refer to demonstrated in some manner that they were malfunctioning and demonstrating the defective behaviour was repeatable in front of many people. The Toyota has hundreds of individual complaints of malfunctioning but each has a seperate car and none are repeatable.
For your examples to be relevent to the discussion there would have had to be hundreds of individual complaints, each with their own machine and none of them would malfunction in the presence of independant witnesses.
If you don't understand that concept, then you really should leave the testing of complex systems to those who have a grasp of the concept
But I do understand the concept. I've got an MSEE and 42 years experience designing, testing, integrating, and debugging highly complex systems including airborne radar and satellite systems.
And, after all, isn't that the goal here? To prove there is a fault (not every fault) within the Totota ECM software?
Yes
how many rolls will it take you to conclusively tell me how many 6's there are on it
What do you mean by conclusively? 100% sure, not just 99% sure? If it's the former, then no number of rolls will prove it to that degree of certainty. You can get closer and closer to 100% the more times you roll the die, but it will never get to 100%.
But back to your proposal that Its a relatively simple task to set a lab environment up and test an ECM, varying each and every input (to infinity, if we wish) to see what the ECM outputs. We can even do things we can't to in a car with an operator...bombard it with radiation, submerge it under water...even simulate a sensor condition that makes it think its sitting on the surface of the sun.
I agree with that. If you do what you suggested, and you get an output indicative of a UAE, then that's great. Then just keep narrowing down the range of inputs, reducing the number of variables if you will until you have hopefully, the smoking gun.
My comment was what happens if you don't get a UAE? You do all the things you suggested and still don't see anything out of the ordinary. Then what? Like you said, that doesn't prove that the system is error free.
As you know, what you have here is more like a black box system - not a telecommunications product about which you have intimate knowledge.
"If you don't understand that concept, then you really should leave the testing of complex systems to those who have a grasp of the concept"
And a reply for the win.
"But I do understand the concept. I've got an MSEE and 42 years experience designing, testing, integrating, and debugging highly complex systems including airborne radar and satellite systems."
You can attempt to program a system to be 100% fault tolerant, but no one has succeeded in doing that yet, at least, to my knowledge. The necessary additional components to do that would be mind boggling. A great example...the space shuttle.
I would settle for even a simple fault tolerance level. But cars are more and more dependent upon a cobbled together chain of (often)non-redundant sensors and computers with every generation. They build a great piece of machinery, but a single surge, electrical fault, or computer error and poof - you're on the side of the road.
Something as critical as the brake and throttle should have at least a complete second backup system on it just in case. Even if it is merely adequately designed, it's far better than nothing at all. That said, it's not impossibly expensive, either. GM and VW/Audi do it in their cars(Others may but I know that these two do for sure), but then again, they use potentiometers which are an order or magnitude or two easier to design a properly fail-safe system around.
edit - and no, by "properly" I'm referring to "works at all" versus nothing put in place to deal with any sort of critical failure. At this point, I'd settle for something rather than nothing at all.
My comment was what happens if you don't get a UAE? You do all the things you suggested and still don't see anything out of the ordinary. Then what? Like you said, that doesn't prove that the system is error free.
No, it doesn't. But, it does provide significant information. If, after an exhaustive battery of tests, you still find no error in the system being examined, you move on to the next likely "candidate". And, most would find it foolish to chase after problems that cannot be duplicated. What judgment call would you make? How much testing would you do, finding no errors, before you concluded all was working as intended?
Remember, we are discussing a product manufactured for sale to generate a profit. When does one stop the examination process and OK the system?
I guess, if you are careening down a busy highway with no control of your car, the answer would be "a little bit longer". LOL!
As in the die example, without examining the die and knowing exactly how many 6's are on it, you would have to roll it into infinity in order to see how many actual 6's there are on it.
However, you can be sure to a high level of degree of accuracy that there is only one six after a few dozen rolls...actually, many less than that.
There is no 100% level of accuracy in any system that can be determined in a real world environment in any system. You can approach it, but never get there.
It seems, however, that you and a few others have already made the assumption that a problem exist (correct me if that statement is incorrect), and are now making guesses as to what the problem actually is... or at least, making the attempt to prove a problem exist.... specifically, a software problem.
Since you have the background you stated, I'm sure you can see the falacy of the argument. I don't work for Toyota, and I don't think you do either, so neither of us can accurately say how much effort Toyota put into its ECM design and testing. When did they stop rolling the die? Did they roll it at all?
Simply put, when would you stop rolling the die?
But let me add something else.
Would having access to the source code speed up the process?
Without a doubt, it would help. More information quite often is better than less in a situation such as this. And, from a PR standpoint, I think it would be in Toyota's best interest to have it evaluated by a 3rd party, under close supervision to make sure the code isn't "leaked" to additional sources.
That's probably not a real world scenario, though...Simply because of all the legal issues involved.
And, let's not forget this fact. Even if a bug or software fault exist, having the code examined by others is like the die example. The more that examine it get us closer to the 100% accuracy level, but we can never get there completely. Just as the fellow that wrote the code may have missed something, the examiner may very well miss the same error. Ooops! We have the same exact problem as before, when we were testing without the source code available.
Sometimes, we get so caught up in chasing down a problem, being convinced that it must be at "A", we lose sight of other possibilities, and miss seeing the problem was really at "B".
One can go to the doctor for a checkup and have the doctor (after a complete battery of tests) tell him he doesn't have cancer. But, he actually might. The test may have missed it. And, he can continue to have the tests run day after day, year after year, until some positive result is found. The question is...was the cancer there before the original diagnosis, or did it surface sometime later? How much time and how many tests before he feels safe enough to move on and live his life? How many rolls of the die before he feels comfortable with knowing the number of 6's?
Plekto - can you source any of your ridiculous claims such as "But cars are more and more dependent upon a cobbled together chain of (often)non-redundant sensors and computers with every generation. They build a great piece of machinery, but a single surge, electrical fault, or computer error and poof - you're on the side of the road."
"brake and throttle should have at least a complete second backup system.." They do have backup systems - it is utterly ridiculous to claim they don't.
No car maker can or should be expected to design detection strategies for artificially created events in the absence of any evidence that such an event can occur or is likely to occur in the real world. So I'll ask you for the 5th time - do you have any real world automotive examples of what you are saying? If not, perhaps joining a forum dealing with real observable problems such as malfunctioning LCD screens on TV's would be a better use of your time.
It seems, however, that you and a few others have already made the assumption that a problem exist (correct me if that statement is incorrect), and are now making guesses as to what the problem actually is... or at least, making the attempt to prove a problem exist.... specifically, a software problem
No, not really. I have offered my opinion that IF there really are UAEs caused by the ECU malfunction, that the root cause is probably a combination of things (input levels or a particular sequence of inputs; voltage fluctuation caused by, for instance, the AC compressor kicking in; EMI hitting at a particular point in time, aliens, ...) whose probability of occurring is very small. Hence, the relatively small number of UAEs reported given the number of vehicle miles driven or hours of operation, taken across all Toyotas.
The software is a sticky point because after signal conditioning of the sensor outputs and sampling by an ADC someplace in the ECU, all of the functionality is in the software. Yet, I have seen nothing in writing nor have I heard anything relative to the software in the ECU. Hence, it is big unknown. Things that would be useful to know would include (this list is not all inclusive): 1. What's the source line of code count (SLOC)? 2. What is the complexity of the SW (function points or some other metric)? 3. What language was used to develope the software? 4. What development standards were use? 5. What was their review process? 6. What was their testing process? Was IV&V used? 7. What was the bug report history? 8. How were the requirements for the SW developed? Remember, this software is basically replacing a throttle cable.
And, from a PR standpoint, I think it would be in Toyota's best interest to have it evaluated by a 3rd party, under close supervision to make sure the code isn't "leaked" to additional sources.
I agree, I do not know why something could not be done with an appropriate NDA in place. The more Toyota drags its feet, the more it's going to look like they have something to hide. I mean come on, it's just an engine ECU, not the launch codes for missiles.
Hmmm... It seems that we are pretty much in agreement after all.
And, I appologize if I offended you with my comment about not understanding the process, Looking back, I could/should have worded it much better. Typing isn't my forte', and I often (to my disadvantage, as in this case) attempt to be a little too brief in my particular responses.
Back to the subject...Another thing that certainly would be a good "predictor" relating to software would be the number of revisions...While a few updates are to be expected, if there are a significantly large number of revisions, in my experience, that usually spells trouble.
As for seeing the code, we must remember that many of the functions of the ECM is to keep the user from abusing the product (over-reving the engine, etc.). Keeping abilities for changing things such as this from the public serves as a significant benefit for the manufacturer, both in warranty protection as well as legal liability..
Its not a stretch to see a scenario where a "hack" diddles with the code to get more performance, things don't go as well as plannned, and his car becomes an airplane with very poor lift characteristics...immediately before he crashes, burns and dies....or maybe dies and then burns.
Then, the ambulance chasers arrive...You know the rest of the story.
Sometimes you're damned if you do, damned if you don't....
"Plausible - we are seeking to galvanize the search for answers that can have an impact on the automotive industry, for the purposes of the Contest, the unintended acceleration must be demonstrated under conditions that, in the opinion of the judges, could reasonably be expected to explain unintended acceleration in the real world."
Interestingly there is a clause that lets them waive a condition at their discretion
I have a Camry Hybrid. At first it was exempt from the recall. Later they recalled my Hybrid because of a potential floor mat interference problem, I explained to the Service department where I bought my Camry that I have carpeted floor mats that have little holes in them that tabs stick through and my floor mats can't move forward as result. This was the response, "Some people may put them in wrong and we have to check it out." I said, "Anyone that stupid should be removed from the gene pool." The real point of this story is that Hybrids have a fail safe throttle mechanism to protect the traction battery. It is different software than that which may be the cause of UA. So Toyota does make software that putting on the brakes will override any acceleration,as does VW. Toyota puts that system on their Camry hybrid. In later 2010 models , Toyota is putting that sytem on all models. Why would they do that if was a "floor mat problem" ? I believe this is an admission of a software glitch which they are aware of.
It seems pretty clear that the fix is intended to stop the gas and brake being applied at the same time. It is more likely a "bio mechanical" glitch that they are attempting to solve. In other words - driver error, a well known and well documented ocurrance. No car company will ever come out and say it is driver error after what happend to Audi. Would you want your sales to plummet 70%?
Comments
Frankly, that's the answer I expected...A bit of a side step when it gets to specifics.
But, it gives me a feel for where you stand, and to be honest, you aren't alone on these forums.
From what I infer from your (and some others) position, there really isn't any responsibility for the vehicle operator to become knowledgable about the controls of his/her vehicle before operating it.
I disagree. After all, its not like the gas and brake pedals are reversed. Now, I would agree something like that would be a ligitimate issue.
Thank goodness we don't allow airline pilots the same latitude (they are checked out on each specific aircraft design), and I sure wouldn't want to fly in a new airliner with 1970's controls and capabilities. Of course, cars aren't planes, but then again, would it be that much to ask a driver to know his vehicle? Most would expect anyone working on a mechanized assembly line to know the equipment they are using.
Until we revise our vision of expecting the automobile to make up for all the driver's mistakes and inattention, I predict more episodes like the Audi and Toyota ones. And, as these cars get more and more complex (to combat the owner's refusal to learn about his vehicle), of course there will be more failures, and we as a society will tend to blame the manufacturer, all because we refuse to assign responsibility accordingly.
Its been happening in the medical/drug field for quite some time.
But, I think you and Henry Ford would have gotten along famously. "Any color, as long as its black". His resistance to vehicle evolution paved the way for one of his competitors, the Dodge Brothers, who were former suppliers that had improvements that Henry Ford resisted incorporating in his cars. His philosophy also helped GM quite a bit as a competitor.
Whatever...
Hey, wait a minute. I thought we were at loggerheads. :-)
Do manuals now have drive by wire shift points then? Most automatics no longer have a physical linkage to the gears as I understand it. You move the shifter to "2" and the sensor tells the solenoid to downshift or whatever?
Busiris, next time you rent a car, check the glove box for an owner's manual. I bet the odds are 50/50 that it won't be there. Remember that Saylor went from his Lexus to a loaner Lexus. And yet he couldn't seem to figure out how to get it into neutral (his Lexus didn't have the push button on/off switch).
I don't understand the point your are trying to make with the "do manuals no have..."
Have you considered Saylor ran out of time and may have been dodging traffic with the road running out? I take it you have most definitely did not read the Saylor investigation by the SDSD.
As host it is inappropriate to make statements such as "didn't have the push button.." The investigation clearly states this on pg 19 and if you check, it will clearly state that Saylor's own car was an 06 IS250 and it most definitely had a push button start, and his manual was in the glove box.
So ... even more reason to wonder why he couldn't shift to neutral. It's not like he didn't have 19 years on the force with CHP, and surely he had lots more driver training than most of us.
One theory that's been floated is that the drive by wire wouldn't let Saylor shift out of drive (the shifter may have moved, but the transmission may have "rejected" the input). So I was wondering if any of the newer manual transmissions were also drive by wire.
btw, you (and other interested parties and contestants) may want to follow this thread:
smsgtretired, "Toyota 4Runner Sudden Unintended Acceleration" #1, 9 May 2010 2:04 pm
I think this link has been posted before too, but in case anyone missed it:
Anyone experience Sudden Unintended Acceleration in a Santa Fe
Plekto, How do you reconcile your positions on aircraft ETCs?
In your post 606 you said this: "Also, the ETC systems on aircraft are properly safeguarded and redundant."
In your post 634 you said this: "But as we've seen with even aircraft, screw-ups happen"
We know for a fact that there isn't hardly ANY car out there that doesn't have at least a few service or defect issues to deal with(TSBs or recalls or whatever they want to cal it, it's still a defect).
But to get more in depth, yes, the issue here is, if you bothered to follow the *second* link I posted on the other page, that there is a way to design a fail-safe system so that it operates as two entirely independent and redundant machines working together. The analysis of the assembly being taken apart on that page(and others) shows that FROM AN ENGINEERING STANDPOINT IT FAILS A 100% FAIL-SAFE TEST. 99% isn't good enough.
If it's not 100% then it can have a critical failure out of the hundreds of millions of activations a day in the millions of cars that have such systems. How? Well, I'll get to that in a minute.
Is it possible to design a system that is fail-safe and completely redundant? Absolutely. Aircraft designers(why I used that example) and NASA and engineering firms do it every day. Is it possible to do if you cut even one corner? No. You either do the system correctly or it just simply doesn't work. But human errors still happen and lead to things like software telling cargo doors to open while in flight(as a real life example).
****
But let's get to the crux of the computer issue. Given that that one vehicle gave a value of 255 brake presses, which is unreasonable to assume a human did in such a short amount of time, it points to somewhere in the chain there being a simple 8-bit processor and an I/O routine with software to monitor the sensors. Now, this makes perfect sense form a design standpoint. Low power, very robust and reliable, and pretty near idiot-proof.
But let's stand back and look at it from another angle...
Q: What is the #1 way in which computer operating systems have errors and crash?
.
.
.
.
.
..
.
.
.
(so you don't cheat...)
A: more than 75% of computer operating system problems can be traced to hardware issues.
Surprising, isn't it? Bad memory, faulty power supplies, a failing hard drive, crud in the vents causing it to overheat, or even a power surge are usually the reasons. Now, to be sure, the other real OS problems do happen all too often, but the majority are actually hardware related.
Now, how exactly does this tie into the Toyota problem? 8 bit processors and simple I/O routines have a critical design flaw in that they respond poorly to external hardware problems. As an example, if you are over 40, you'll know exactly how 8-bit computers behaved when they crashed.
There was no task manager. There was no crash to desktop. What did they do? What they did, was to run one program flawlessly like a tank. But the second the hardware glitched or had an issue, it would freeze doing the very last thing that it was doing.
It literally would show the same image on the screen forever or play the same sound forever. Simple processors behave that way when they crash. No blank screen, no error - just simply get stuck. And require a reboot to fix. Nothing other than a reboot usually works, either.
16 and 32 bit OSs and processors, while more complex, did finally have crash handling built in, but the systems in a car simply do not. The Hosts' comments about Cell phones and the like crashing was dead-on. When simple computers like they use in automobiles(ie - dozens and dozens of small hard-coded processors and PRAMs) crash from external forces, they tend to exhibit this behavior.
So if you have a throttle sensor that crashes due to an external problem, if it is improperly designed, it will continue to blindly do whatever it was last doing. If that value for the throttle was, say, 212, then it is stuck at 212 until you reboot it and clear the error.
A previous poster also mentioned three incidents where he had to cycle the ignition to fix his vehicle that was reacting counter to his wishes. Naturally this is counter-intuitive to most people who either aren't old enough to remember computers and how they behaved back then or are unable to realize that it's truly "hard crashed" and only a manual power cycling will fix it.
I think what happened was Toyota's engineers were lax and assumed that because the Hall Effect Sensor was "super reliable" that they didn't worry about the computer connected TO it nearly enough.
Of course, as I stated, if they didn't USE such a sensor, there wouldn't be a need to design a proper fail-safe system in the first place. My Toyota has almost 400K miles on it and is 23 years old. With the same throttle cable. It's never failed to work exactly as it is supposed to.
So.. even less reason to speculate on this accident given your lack of background information. His driver training most certainly would not have included how to stop a runaway vehicle with fading brakes. Why people would think this worn out comment about his driving skills is beyond reason. The job he had at the time was "Special Duties School Bus Program Officer"
A new transmission electronic theory? Besides being wild speculation, it's completely unsupported by any facts whatsoever. If you have a source for this I'd like to see it. And no, before your newest speculation spreads, no manual transmissions I know of are without a mechanical control.
I didn't find your link very useful at all since there is no technical information in it just more anonymous anecdotal complaints. In each story the usual information is missing, driver profile, circumstances of road, weather etc. passenger witnesses etc. and the usual I had the car inspected by a qualified individual technician who tested the car and found nothing wrong.
That's a bit of a "cop-out", Steve.
First of all, you continue to use an example of an auto with a known issue (incorrectly installed floor mats) that the dealer, for whatever reason, didn't correct. This car was already set up for a crash... almost guaranteed to have some sort of incident. We can hypothesize about why the driver didn't do a lot of things, but that's all. And, we can't rule out the possibility that he just "simply froze" at a critical time. That very thing has happened to pilots, etc.
We probably (may never) know exactly what happened there.
You may be right about the rental car issue, but tell us...How many UA complaints are made by rental users? Judging by what I read on these forums, the vast majority are auto owner-operators...although, I concede that there are a few examples (like the Prius up north that the maid drove into a wall) that are non-owner-operators.
But, as an old statistics teacher told me once, one or two points on a graph don't make a trend.
But, since you brought it up, try this.
Get a clipboard and a pencil. Go someplace where there are lots of cars...say,a shopping mall on a busy day. Act as if you are taking a survey, and ask 50 (25, 100, you decide what is enough) people these questions:
1- Do they own a car, and the year and model of their car?
2- Have they ever completely read the owner's manual?
3- If the car is 5 years old or less...Do they have anti-lock brakes?
My prediction is that the answer to # 2 is "No", and that well over 50% will give an answer other than "Yes" to # 3 (maybe, I think so, I don't know, I'll have to check, let me ask my husband, etc.).
If I am correct, then, for that percentage that doesn't give a definite "Yes", anti-lock brakes offer little to no advantage to those people. If you don't know you have a safety feature, how can one adequately employ it?
And, you did tell on youself a little, when you mentioned the push-button transmission in a response to my earlier post (humor intended).
Here's another "age" test.... Remember the early automatic's that had a different shift pattern, with reverse being all the way to the right? I'm sure it was changed to the pattern we have now, because so many were used to the "3-speed on the column", and the automatic "reverse" location was similar to the "1st gear location" in the 3-speed manual.
I guess...sometimes, its best to simply conform than to fight the forces of entrenched behavior.
A child could understand that all your computer analogies start with a faulty premise - that someone, some where at some time must have physical proof of a faulty Toyota sensor, therefore ....This leads to a faulty conclusion every time no matter how many times you rephrase it.
Until you theorists get off your computers and under the hood all you're going to have is unsubstantiated rehashed rumors and theories. What you'll need to win this contest is physical proof to show a judge. Start by collecting components and test them one by one and eliminate them as suspects if they function correctly. Eventually if any of your theories are correct you should come across a faulty part.
So, if you truly were interested in finding a solution you need to start a real investigation involving real parts -
Yes, there is a lot of that on forums like these.
Some play fast and loose with the facts, twisting them to fit their agenda... conveniently ignoring the facts that don't easily fit into the equation.
Others simply re-hash items that claim to be facts, but in reality, are no more than hearsay, or even worse, outright fabrications.
And yet, others simply get it wrong. Thay make assumptions that have no basis in fact and are wrong from the get-go, and go down a road to nowhere.
I pop in and out of forums such as this once and a while, hoping to find one where posters actually stick with the facts (hey, nothing wrong about hypothesizing, as long as that's the way its stated).
So far, I'm batting zero.
One last item... I went to school with a fellow that wound up in the Highway Patrol, flying helicopters for the service until he had to retire for medical reasons 20 odd-years later. He had no more advanced driving instruction in automobiles that any average citizen, simply because he was an aircraft pilot, and that training would be a useless expense for the department. He did have adequate aircraft pilot training, as one would expect.
Kind of like making the assumption that anyone that served in the military has had front-line combat experience and is a weapons expert.
It just isn't so.....
Inability to shift into neutral isn't some wild speculation I just made up; that theory has been floating around for months now. It's all related to computer driven systems and whether they are failsafe.
Remember the reason why this discussion was started - we're looking for a novel and plausible cause of unintended acceleration in a consumer vehicle. Not every case of UA has involved floor mat issues. And not every case of UA happens to a technological savvy individual who can then log onto a bulletin board and post every last detail of what was going on when they experienced UA.
Afaik, there's only been one case where a car had SUA and the driver got it to a dealer and left it running so that the techs there could witness the engine racing. That driver got it to the dealer by shifting in and out of neutral. Haven't heard anything on that one lately.
I don't take issue with that process.
However, one should stick to the factual, known information when suggesting possibilities. Example: Your mis-information in the CHP incident easily leads to incorrect conclusions.
If we don't stick within the facts as they are known, then we might as well suggest that little green space aliens are creating these incidents with superior alien technology and are forcing these incidents in order to destroy our confidence in technology, thereby making an eventual planetary takeover easier for them.
Frankly, that theory is probably just as plausable as some of the wild things that have been thrown out there.
I'm heading out for a quickie road trip for a couple of days. Y'all stay safe out there.
No, I believe both statements. Let me explain. The control systems of commercial aircraft are designed to be properly redundant and will still work if any single part of the system fails for any reason whatsoever. That's what "fail-safe" means.
Anything other than that and it's smoke and mirrors and marketing BS. The Toyota system is not properly redundant. That's a simple fact. VW and GM, for instance, do design their systems properly - it's a design choice and not a matter of opinion. So my first statement is absolutely correct.
So is my second statement. Mistakes and problems do still happen. In a commercial airplane, or in a properly designed vehicle, a defect or physical problem won't cripple the entire thing. It will keep running because someone had the foresight to design it so that it would keep running even if some of the electronics were to fail.
A child could understand that all your computer analogies start with a faulty premise - that someone, some where at some time must have physical proof of a faulty Toyota sensor,
No, if you bothered to read what I wrote more carefully, you would understand what I'm saying:
1: That mistakes can happen and unless Toyota can prove to us that the computers and software aren't part of the equation, we cannot remove it as a potential variable. A faulty sensor isn't even part of my premise aside from the fact that, well, stuff does actually break and wear out. My concern is what happens when it eventually does suffer a critical failure.
ie - think UL labs and physical abuse-testing - did Toyota design for this or have it properly tested? How many auto manufacturers even design their computer systems to be fault-tolerant? From what I've seen of recent vehicles, when the computer has problems, the entire car becomes undriveable. My computer examples were based upon what I have seen happen when simple ICs and processors such as are used in a vehicle's sensors crash while they are running. Usually it's that they jam the system in its last state and this would completely explain the behavior that we are observing. Nothing works because the brain went dead and has to be rebooted. Obviously doing this while the car is still running might be a problem as some cars won't let you remove the key and cycle the ignition while it is in drive.
Well, Toyota hasn't come clean on this and there isn't a single engineering firm in Japan or the U.S. that has been given access to their computer code to analyze it to see if there's a simple mistake somewhere. Because Toyota is taking a hard-line on this and refusing to hand it over. Yet they blather on in the news about how they are concerned with safety and state that it couldn't have been their software. Yet no proof has been offered to back that statement up.
As my cousins in Missouri would say: "I'm from the show me state. Where's your proof?"
2: My main point is that all of this doesn't really matter. Because we have bigger fish to fry here. If you read the statement by Edmunds concerning the contest, it actually states *two* objectives. One is to find the cause in the Toyota case, and the other is mentioned as problems in the industry with issues like this as a whole. My main point from the beginning was to put Toyota's problems(which are likely software or computer hardware related(physical issue crashing said computers) in a box over to the side and leave it alone.
I've since the beginning been more concerned with the problem of Hall Effect sensors and how you have to design needlessly complex systems to monitor them and to be properly fail-safe. If auto manufacturers stopped using them, there would be no possible way that this scenario could happen.
Note - this isn't making any statement at all about whether this actually is happening or not. I'm talking from a scientific perspective. Can it possibly fail and give bad data to the processor monitoring it and/or can the processor mess up and pass along the faulty data to the rest of the system? The answer is that unless you design it very carefully, it can under some circumstances. It's a known issue with Hall Effect sensors.(also optical ones)
Basic analysis of the Toyota system shows potential problems with an improperly implemented fail-safe system. Is it the cause? We don't know. But it is worrying to myself and many others that it's cobbled-together and done improperly when there's no excuse for cutting corners on such a critical part of the vehicle.
That's the advantage of an analog system in this case. It's crude, but it's also incredibly fault-tolerant. GM and VW (as examples) use potentiometers and their fail-safe systems work as designed and to date there hasn't been a single issue aside from more warranty repairs for parts wearing out. The few out there that still use throttle cables, well, they have no issues at all. The computer can be a brick but the accelerator and steering is still under your control. As it should be.
The software isn't one of those things.
What we are trying to point out is that for software the hood is welded shut so we can't see inside, measure anything inside, probe or test. We have to just pretend we can solve the problem without opening the hood.
If the problem is there, we will never find it because we aren't allowed to look there.
Keeping in mind the advancement of the primary question "what is the cause of SUA?" How about we come up with a forum rule that politely asks all posters to list their primary source when stating something as a fact? Otherwise we can all waste our time checking what someone said only to find out its gossip instead of fact.
Let me give you an example; "The Toyota system is not properly redundant." You stated the following in post 657; From this claim you go on to build your conclusion once again. Maybe its true and maybe your conclusions based on it are true, on the other hand, if it is false then you are simply once again drawing conclusions based on a faulty premise. I could waste my time checking for proof of your supposed fact but it would save me a lot of time if you just simply listed it - its the nice thing to do and builds your credibility. I'll say this about their ETC system and components - "that they were likely built and designed to meet or exceed industry standards and that their rate of failure is likely the same as any other manufacturer in the world or lower. I used the word "likely" and didn't use the word 'fact" since I consider most people will accept the reputation of most manufacturers quality and lack of it and will place Toyota at or near the top. However if someone can provide convincing evidence to the opposite maybe we can look at it and learn something new.
I've caught Toyota, Ford, GM, Chrysler hiding defects before - but I (and any other mechanic) could always hold the part in my hand. Until you can let me touch your theory and look at it to my satisfaction you are not likely to get very far unless your whole objective is to obfuscate.
The software isn't one of those things.
What we are trying to point out is that for software the hood is welded shut so we can't see inside, measure anything inside, probe or test. We have to just pretend we can solve the problem without opening the hood.
If the problem is there, we will never find it because we aren't allowed to look there.
That really isn't a correct statement of fact. To be a bit basic...
A car is just like a modern heat pump. Both are mechanical devices, monitored and executed by electronic circuits, and programmed by software. The difference is, you drive one, and the other keeps you comfortable.
If your heat pump fails, you have it examined by a technician, just like your car.
The technician then checks inputs and outputs to the individual parts until he finds a condition that isn't congruent with the expected result. I don't think he calls up the corporate headquarters and request source code to solve the problem.
Unlike what many folks think, there is a limited number of inputs and outputs to examine in the control circuitry that controls an automobile. Until one of those shows an error or unexpected condition, looking at the software is practically useless... if your intent is to solve the "problem". So far, I haven't seen anyone show a single one of these conditions.
For a more basic example, I have seen mechanics diagnose faulty car voltage regulators by doing the exact procedure described above, never once taking the regulator apart. If the inputs and outputs are within expected parameters, the mechanic simply looks elsewhere until the problem is solved. If not, the regulator is replaced.
If one is knowledgable, there isn't anything "magic" about software at all.
1. Find an owner of a Corolla (#1) complaining of SUA (I found one for aVibe)
2. Obtain a second Corolla (#2) of the same year that has a standard transmission
3. Without the owners knowledge, switch the gas pedal, computer and throttle body in one car with the same parts of the other car.
If any of the ETC system is faulty then you can expect Corolla #1 owner will have no further complaints since the only components changed were the ETC. If the owner is still complaining than the ETC could not be the problem since Corolla #2 is known to be without complaints.
There must be a difference between the two types of vehicles for any ETC theories to be correct since there are no SUA complaints with manual transmissions. So just start changing parts till you find it. For a million bucks you'd think thousands of people would try this.
Any comments?
Sure I did. Aircraft are built with *PROPERLY DESIGNED* hall effect sensors in their controls and as such are immune to failure without being detected in enough time to be serviced and fixed. Automobiles are not. This is a design problem that is purely the fault of sloppy engineers and designers. Because if it is done correctly, it will operate without any possibility of an incident. But that costs extra money and time to design and has to be done exactly the right way.
It's a lot like a random number generation routine. There are dozens of ways to do it wrong and only a couple of ways that are truly 100% random. It's specialized knowledge, though, and more than 90% of computer science graduates probably have no clue or have not dealt with it, since it's not normally taught in their courses. I suspect that Toyota's engineers also didn't realize the intricacies of designing such a system, since they aren't likely to have designed such a system before for the military or aerospace fields where proper redundancy is required as a normal part of the design specs.
The second is merely my restating that again. IF there is a failure, be it by accident or not, can the system handle it? Toyota's cannot. Now, whether this is part of the problem or not has yet to be determined, but we have already found one point where it could be a potential problem.
Let me give you an example; "The Toyota system is not properly redundant."
Yes, I did state this. If you read this thread from the beginning, there are links and postings by others who are engineers and who deal with this field specifically that go into depth as to the intricacies of how and why it isn't properly redundant.
Read it and then come back, or look it up yourself. I'm not going to re-hash and re-quote stuff from over a month ago.
Well, maybe sealed is not the right right word. I was basing my comment on this from EDN magazine:
One has to recall Audi, which decades ago accidentally introduced drive-by-wire with its advanced cruise control on the Audi 5000. The cars were allegedly subject to spontaneous acceleration. The company blamed the problem on operator error. At the time, I was told that researchers at another European high-end auto company had uncovered a problem in Audi's engine-control firmware and reproduced the acceleration without requiring a driver to mistake the gas pedal for the brake. But in the ensuing liability litigation, all hope was lost of diagnosing the actual problem and documenting it so that the rest of the real-time software community could avoid it
Toyota Prius and Camry, drive-by-wire, and our failure to learn from experience
But, they don't always keep running.
Remember the design issues with the DC-10 aircraft? Triple redundancy in the critical flight control systems and hydraulics, IIRC. Only problem is, those 3 systems were run in close proximity to each other so that another failure that was not anticipated took out all 3 systems.
In one case, it was the loss of a cargo door, which led to depressurization of the cargo compartment, which led to the collapsing of the deck above it, which took out the triple redundant system.
In another case, it was the disintegration of a turbine or compressor disk in the tail mounted engine that again severed all three hydraulic lines, rendering the plane uncontrollable.
So despite best intentions and engineering, we still sometimes don't get it right.
One of the things that the airline industry and NASA does do (along with the FAA, NTSB, etc) is to try and drill down to the root cause of an incident and take steps to prevent that failure from occurring again. You usually don't see this same amount of diligence in the automotive world.
Thank you for providing the source info. I just double checked and have this to say;
EDN Executive Editor Ron Wilson made a fatal mistake in his first sentence by stating something false and building on it until his conclusion - he made a number of technical (auto) mistakes. He may well be a genius with electronics but as he himself demonstrates his knowledge about particular automotive electrical system components is woefully lacking and elemental at best. I'll deal with his most glaring error in the first sentence;
"One has to recall Audi, which decades ago accidentally introduced drive-by-wire with its advanced cruise control on the Audi 5000." - This is a completely false statement. The Audi he's referring to were from the mid 80's and it had a standard vacuum operated control with a solid mechanical connection to the engines throttle valve. Below is a link to an image of an 88 Audi 5000 turbo engine - you can clearly see the vacuum servo on the cam cover. The 86 was identical, I worked on them.
He also stated there was evidence "and already evidence is emerging that the underlying problem is likely in the engine controller," Completely false again - to date there is no physical evidence whatsoever - even after 100's of investigations.
Given the date of Feb 4th this fellow may be responsible for starting this famous rumor.
Lets just say EDN wouldn't be your first choice for Toyota recall information
http://www.cargurus.com/images/2009/03/09/22/55/pic-33409.jpeg
1. Find an owner of a Corolla (#1) complaining of SUA (I found one for aVibe)
2. Obtain a second Corolla (#2) of the same year that has a standard transmission
3. Without the owners knowledge, switch the gas pedal, computer and throttle body in one car with the same parts of the other car.
If any of the ETC system is faulty then you can expect Corolla #1 owner will have no further complaints since the only components changed were the ETC. If the owner is still complaining than the ETC could not be the problem since Corolla #2 is known to be without complaints.
There must be a difference between the two types of vehicles for any ETC theories to be correct since there are no SUA complaints with manual transmissions. So just start changing parts till you find it. For a million bucks you'd think thousands of people would try this.
Any comments?
Yes, that should eliminate several variables. Its what I would call a "field test" trial and error method, as compared to setting the electronic equipment and sensors up in a lab (across several tables, perhaps), and then beginning to manipulate the system by introducing input to the various sensors that correspond to what we find in the actual operating environment ( as I suggested in a few postings back). Trial and error again, but in a lab environment (and also in a better controlled environment).
If the "folks in the know" (ie., those with the most accurate information and closest to the investigation) haven't attempted something like either of these test-cases yet, then I would make the argument that they either are 1- incompetent, or 2- have serious doubts about widespread vehicle induced UA in these vehicle lines.
Just my opinion, however...
That's true, for several reasons.
Some, but not necessarily all of them:
1- Commercial airliners/space craft costs several million $$$ or more EACH. The potential loss of that kind of money tends to make one wish to minimize losses, and willing to pay a bit extra in order to achieve that result.
2- Commercial aircraft operate in a much wider range of environmental pressures.
3- Operators (pilots) are, in theory, much better trained that the average driver and can give much better and accurate information feedback.
4- A single "event" can result in 100's of lost lives. Not so many in a car wreck.
5- Operation of aircraft is much more structured than operating a vehicle.
6- Every pilot has been checked out and qualified on EACH individual plane design before being allowed to transport passengers. Once one has an automobile driver's license, he/she can drive any number of different vehicle makes and models. And, in most cases, never EVER take a course or test again in his/her driving lifespan, possibly a span of 60 years or more.
I could go on, but I think you get the idea. However, with the advent of data recorders in cars, we are moving in that general direction.
Just curious...What percentage of auto owners do you think read their operating manual cover to cover?
Anyone want to throw out a number? Off hand, based on my experience, less that 10%. Even if I am off by a factor of 9 (lets say that 90% actually DO read their manuals), that still leaves an enormous REAL number of drivers with less than an optimum BASIC understanding of their vehicle.
Now, what investigator would seriously take input from that group of people regarding vehicle malfunctions, other than a cursory evaluation of what they have to say?
To me, that's like a court taking a medical opinion from an actor that plays the role of a doctor on TV.
Personally, if a professional race car driver were to cite vehicle UA, I would be far more prone to believe that there is an actual problem than someone else who is not nearly as familiar with their individual vehicle's operation and features..
But nothing in any automotive system that I know of is designed with any redundancy. At best the computer detects a problem and goes into "service/limp-home" mode and that's that. But if the computer itself is in trouble, well, anything can happen. Now, in the past when that has happened, odd things start happening, but with manual control over brakes, steering, and acceleration, you can deal with it. What has happened in, say, a Prius is:
Throttle and brakes are controlled by computer.
Transmission is controlled by computer.
Ignition is controlled by computer.
Steering is electric/controlled by a computer.
That's the full boat, folks. It's a video game on wheels. There is nothing that will save you if the computer system hard crashes and locks itself in its last state. Normally you would have a last-ditch option of yanking the fuses to the computer but the fuses are under the hood. I'm amazed that problems with the things aren't common. In a way that's a testament to Toyota's skills, but in another, well, the 2nd generation vehicles aren't even close to ten years old, so electrical failures due to age are fairly rare.
Is it too much to still expect manual control over our vehicles? Apparently Toyota seems to think so.
This from the Center for Auto Safety:
The only study to pinpoint a specific defect within the vehicle, "Risk Assessment of Cruise Control," by Mats Gunnerhed, was conducted by the Swedish Defense Research Establishment of the Department of Information Technology. Issued in May of 1988, it concluded that within certain types of cruise control systems "there is a single-point-fault mode that leads to sudden acceleration at high power." The specific fault pointed out by the Swedish agency was a "bad solder joint" in the Hella cruise control used on 1981-83 Audis. All of the Audis experiencing sudden acceleration which are the subject of the class action were with cruise control systems.
Audi Sudden Acceleration
The technician then checks inputs and outputs to the individual parts until he finds a condition that isn't congruent with the expected result. I don't think he calls up the corporate headquarters and request source code to solve the problem.
Generally there are only two or three inputs - a temperature sensor, a setpoint value, and on/off, with a simple PID loop for a heatpump. Some don't have even that. Engine controllers have over a dozen sensors and are required to perform certain diagnostic tests (OBD2) to meet emissions. You are comparing a dimming light switch to a color tv. I wouldn't need the schematic to diagnose problems with the dimmer, but I would need the schematic to the TV. The schematic is the source code.
Unlike what many folks think, there is a limited number of inputs and outputs to examine in the control circuitry that controls an automobile. Until one of those shows an error or unexpected condition, looking at the software is practically useless... if your intent is to solve the "problem". So far, I haven't seen anyone show a single one of these conditions.
And the complexity goes up with the square of that number, and there are more than a dozen on any modern car. There are also internal states (timers and counters - on my car, if it is moist the MIL light goes on because the O2 sensor on the catalytic converter gets a bad signal - I need 5 keyon-keyoffs to clear it; if the gas cap is loose, it will come on after some time, not immediately).
Another simple example is idle speed control. The engine has to run faster to warm up to meet emissions. This is usually a combination of timing and engine coolant temperature.
Tell me how to set these purely internal states on a bench? The condition is inside the black box and unknowable. I can't show you what I can't see, but it exists. Toyota is likely to have similar timers/counters. If I give you a car, can you tell me if the counter will expire next key-on? In three? In 10?
The "unexpected condition" may be purely in one of these internal virtual states. A counter or timer might be causing a divide by zero or overflow confusing the calculations.
My contention is that if you took a factory fresh ECU (or set) and played back precisely the conditions that led to the SUA, it would demonstrate the problem. But I can't . These aren't recorded, and although I can simulate external conditions, I can't know the internal state. So I could theoretically recreate the condition (break sensor indicates on, engine still energized), but I probably couldn't repeat it since I can't reset the ECU to factory fresh (if I could it would be odometer tampering). It also might only happen once every two days, but not consistently - if it is an internal state, with a band of external states, it would only show up when the ECU was in a specific state.
For a more basic example, I have seen mechanics diagnose faulty car voltage regulators by doing the exact procedure described above, never once taking the regulator apart. If the inputs and outputs are within expected parameters, the mechanic simply looks elsewhere until the problem is solved. If not, the regulator is replaced.
If one is knowledgable, there isn't anything "magic" about software at all.
A regulator has one input and one output. I can simply ramp the input voltage and see if the output is within the envelope.
The ECU has brake, throttle position, O2 sensors (on the exhaust and to verify the catalytic converter), engine coolant temperature, maybe anti-knock, often gets loading over the bus (e.g. A/C on-off), cruise control settings, transmission gear, engine degrees from TDC, battery voltage... It controls the phase and duration of injectors, the advance and dwell of the spark, the throttle (for idle if nothing else), sends RPM and MIL light and whatever else to the instrument cluster, controls the emissions system components...
It isn't magic, but it is complex, or more properly chaotic as in "the butterfly effect" - and even that is only one variable. If I give you exact values for all the inputs listed, I defy you to tell me the expected and correct state of all of the outputs just like the regulator. And that is at one multidimensional one point. You are claiming that the transfer function between all the inputs and outputs is something you can calculate in your head or on the back of an envelope.
It isn't so. I haven't mentioned internal states above because there may be an answer that is correct or wrong depending on the internal state.
The atmosphere is well known and the physics of fluids and thermodynamics have simple equations. Is it going to rain or be sunny on Memorial Day weekend (two weeks from now)? You have all the inputs - current pressure, temp, humidity, and the equations. Just run the calculation. It should be simple.
The (x,y,z,w...) = f(a,b,c,d...) equation for any modern ECU would be mind numbingly complex (it was even going back to carburetors and the spaghetti of vacuum hoses where the ECU was just used to position a valve like mechanism to get to stoichiometry).
Can you even say if at any given point if you dropped the engine coolant temperature input 20 degrees C, would the idle speed increase or the MIL light come on indicating the coolant temp sensor was defective or something else?
If you do know the complete equation for even one vehicle that experienced SUA, please post it here. Even then, does the software implement it correctly?
That was probably a bad assumption
They expect complex systems to work perfectly, under all conditions, no matter what people do with them (remember the dude that sued the lawnmower manufacturer when he injured himself trying to trim his hedge with the lawnmower). However, as some of us know, it is impossible to anticipate all conditions/situations that may arise over the life of a product. You can do your best to anticipate the known unknowns, but it's the unknown unknowns that get you :shades: .
Exaclty how do you think computerized assembly lines are created?
Of course, all of these things are tested together and coordinated.
Thats a fact, or else Toyota (and every other car company) would be flying in factory engineers to do any repairs related to electronics.
I never suggested that it would be a quick experiment or test.
As far as doing this, companies have done the `very same thing in developing competitive processors to compete against Intel. That technique is called "reverse engineering", and it goes on daily in countries like China.
Every single thing one needs to determine a possible fault in the electronics of ANY vehicle is within the vehicle itself.
Now, if you wish to go to the next step, which is ....
What happens when an actual fault is detected?
I will agree that viewing the source code may indeed be necessary. But, if its just bad input from a faulty sensor, its the sensor....not the code. And, one may even be able to add another fault tolerance level at that point in the routine.... and maybe not.
You can attempt to program a system to be 100% fault tolerant, but no one has succeeded in doing that yet, at least, to my knowledge. The necessary additional components to do that would be mind boggling. A great example...the space shuttle.
There seems to be some pre-conception by some that cars were fault-tolerant until electronics came along. That's simply not the case. Suffer a broken tie-rod end, a strut collapses, an axle breaks...any of these can certainly be catastrophic at 60 MPH. And, if you spend much time on the highway, you can see cars that experience these very events.
Its like the Y2K scare. So many "experts" predicted planes falling from the sky, complete computer system collapses, etc.
I remember seeing a 60 Minutes segment of some guy who was a well-qualified IT "expert" who had bought acreage in a desolate, remote place, fenced it in with barbed wire, built a house and stocked it with disaster supplies and moved his family there. All because of the impending disaster. I would love to where that dude is today...LOL!!!
Othe than minor issues, none of it happened.
A couple of points -
1. Ron Wilson said "already evidence is emerging.." clearly he wasn't referring to a report from 1988.
2. Given Mr. Wilsons background he was clearly talking about Toyotas main ECM and faulty computer code, whereas Mr Gunnerhed claimed a badly soldered joint could cause a single failure. Both are talking cars and electrical systems but Wilson was talking about computer code and Gunnerhed was talking about faulty circuit design and manufacturing errors - difinitely not the same thing. It has never been claimed that Gunnerhed found real world examples of it in any car let alone Audi, only that it was possible - its the same old Sam Sero theory. (or did Sam take his theory?)
3. It may interest you to know that Mr. Gunnerhed has approx 11 published papers listed in the Swedish Defense Research Establishment of the Department of Information Technology. (FOI) but none are about Audi's cruise control and he has nothing listed for the year 1988, so unless anyone has the actual study (if there is one and its odd that Ditlow didn't post it) maybe Ditlow got his facts wrong.
http://www.foi.se/FOI/templates/PublicationPage____1621.aspx?qu=gunnerhed&au=&yr- =&fomr=&sort=
1. I'm Canadain
2. I'm not and have never been emploed by any automotive manufacturer including Toyota.
3. I find the issue of SUA one of the most fascinating automotive issues to have ocurred in my lifetime.
4. My main form of employment would be that of an automotive instructor forthe past 24 years.
5.You can check me out at carquestions.ca or on youtube - carquestions
M. Whinton
I wanted to respond to this comment all by itself.
I highly doubt anyone educated in meteorology would agree with your assessment. In fact, we don't even know all of the input sources to the weather systems, much less what they are at any given time.
In contrast, we do know each and every input source in an automobile, since they were designed and constructed by humans. There is a dozen or more technicians at the local Toyota dealership 10 miles from my home that can give us that information....as well as what the expected ranges of those inputs should be.
Its a relatively simple task to set a lab environment up and test an ECM, varying each and every input (to infinity, if we wish) to see what the ECM outputs. We can even do things we can't to in a car with an operator...bombard it with radiation, submerge it under water...even simulate a sensor condition that makes it think its sitting on the surface of the sun.
EVERY SINGLE STATEMENT ABOVE IS FACT.
For those who continue to simply take the word of a driver, consider this...
Hundreds (maybe thousands) make the claim of vehicle induced UA.
Of course, many more have made the claim of alien abduction. What factor(s) cause you to believe the first claim without believing the second? Or, maybe you believe both?
While the condition of widespread Toyoya vehicle caused UA may eventually win out in the court of public opinion, reality may end up with a completely different conclusion.
In fact, much of this argument is following in the very same footsteps of the "vaccination causes autism" claim, and after many years of investigation and numerous studies, not one peer-reviewed study has successfully made the case for that condition, either.
Yet, many are still convinced.
Go figure...
What concerns me to a great extent is that so many have condemned Toyota's software and yet ignored the possibility of a bad run of ancilliary equipment that interfaces with the ECM.
I hope you get an acceptable resolution to your problem, one that actually resolves the issue.... Not a solution that simply enriches a group of lawyers and leaves you out in the cold.
Good luck!
Sorry, I disagree with that statement.
If an ECM has 4 inputs, and each input can take on 256 values (quantized to 8 bits), then the number of input combinations that have to be tested is not 256+256+256+256=1024, but rather 256*255*254*253=4,195,023,360. And even this estimate does not allow for the order in which those inputs may change, which may (or may not) affect the state of the system, and which would add another couple of orders of magnitude to the number of test cases.
You cannot do what I thought you suggested - test each input as if its effects on the system is independent of the other inputs, without some apriori knowledge of the design of the system to help you chose your test cases in an educated fashion - knowing what the corner cases are, what the stressing input combinations may be, etc.
You cannot, except for the most simplistic of systems, prove their correctness just by throwing test cases at it.
Just because you can't understand the process in no way invalidates it.
It IS done all the time.
And just because you have a process in no way validates what you are trying to demonstrate.
IF you have a good understanding of the way the product was designed, understand it's nuances, know where the corner conditions may be, understand the structure and control flow of any software, etc, THEN you might have a shot of coming up with a well controlled set of tests that would help uncover any weaknesses in the product. But lacking that knowledge, you or anyone else is just flying blind thinking that just by throwing a bunch of tests at it, you are going to uncover critical problems. Sure, you'll find some, but no amount of testing will guarantee that you've found all problems. That's why there's no substitute for a thorough understanding of the product under investigation.
You cannot test quality into a product - it has to be designed in from the start.
This might end up being another chapter in "fatal defect", or perhaps it is not there, but again the problem is I can't look there. I would like nothing better than to exonerate the software, but I can't decide either way without looking.
That's the flaw in your argument.
I don't have to ( and never can, for that fact) prove there are no problems within a system. However, I can prove that there are problems.
That's a subtle, but very real difference.
If you don't understand that concept, then you really should leave the testing of complex systems to those who have a grasp of the concept.
And, after all, isn't that the goal here? To prove there is a fault (not every fault) within the Totota ECM software?
If the problem is as widespread as so many seem to think, and examples abound, do I really have to simulate a condition as if I were driving the car at 1 million MPH on the surface of the sun? Wasn't that the falacy in Dr. Gilbert's test? Creating an error condition that would most likely never be found in the operating environment? Exactly what did that prove, other that you can inject a variable into a circuit that it never reasonably expected to see, and then got a result that also was never expected? What do you think that proved?
An example...Take a 6 sided game die, for instance.
If I tell you to search for all possible 6's (call the 6 an error condition), and the conditions of the test don't let you inspect the die before the test (you have no idea how many sides there are on the die with a 6..ie, Toyota's ECM software), how many rolls will it take you to conclusively tell me how many 6's there are on it?
But, if I give you the same die, along with the same information, but now tell you to tell me if there are ANY 6's on it, how many times will you need to roll the die to give me an answer of "at least one"?
This might end up being another chapter in "fatal defect", or perhaps it is not there, but again the problem is I can't look there. I would like nothing better than to exonerate the software, but I can't decide either way without looking.
To be honest, I'm not familiar with any of these devices. But, let's take a look at the Breathalyzer mentioned.
Seems to me that a minimal amount of decently designed control testing could have easily turned up inconsist results, if there were as many widespread errors as your comment implies.. If the bugs can be detected in the code, they are bugs. And bugs show up in the device the code is controling. Now, it may be easier and faster to find blatant errors by examining the code, but it certainly isn't a requirement.
How about a link to some info on the device, as well as a link to how the problems were found? I'd like to read a bit more about it. Sounds a little like what I have read about some traffic cameras, but those weren't exactly "bugs", but faulty parameter assumptions.
Thanks.
Addendum:
http://en.wikipedia.org/wiki/Therac-25
An explanation of the Therac-25. Just for the record, the problem was well recognized before the code was examined to determine the exact cause of the failure. Examining the code simply explained how the failure occured. There was real evidence of the failure that could be examined after the failure (ie, the radiation effects on the body).
Still, an interesting example of what can go wrong....
For your examples to be relevent to the discussion there would have had to be hundreds of individual complaints, each with their own machine and none of them would malfunction in the presence of independant witnesses.
But I do understand the concept. I've got an MSEE and 42 years experience designing, testing, integrating, and debugging highly complex systems including airborne radar and satellite systems.
And, after all, isn't that the goal here? To prove there is a fault (not every fault) within the Totota ECM software?
Yes
how many rolls will it take you to conclusively tell me how many 6's there are on it
What do you mean by conclusively? 100% sure, not just 99% sure? If it's the former, then no number of rolls will prove it to that degree of certainty. You can get closer and closer to 100% the more times you roll the die, but it will never get to 100%.
But back to your proposal that Its a relatively simple task to set a lab environment up and test an ECM, varying each and every input (to infinity, if we wish) to see what the ECM outputs. We can even do things we can't to in a car with an operator...bombard it with radiation, submerge it under water...even simulate a sensor condition that makes it think its sitting on the surface of the sun.
I agree with that. If you do what you suggested, and you get an output indicative of a UAE, then that's great. Then just keep narrowing down the range of inputs, reducing the number of variables if you will until you have hopefully, the smoking gun.
My comment was what happens if you don't get a UAE? You do all the things you suggested and still don't see anything out of the ordinary. Then what? Like you said, that doesn't prove that the system is error free.
As you know, what you have here is more like a black box system - not a telecommunications product about which you have intimate knowledge.
And a reply for the win.
"But I do understand the concept. I've got an MSEE and 42 years experience designing, testing, integrating, and debugging highly complex systems including airborne radar and satellite systems."
You were a lot nicer than I would have been. John
I would settle for even a simple fault tolerance level. But cars are more and more dependent upon a cobbled together chain of (often)non-redundant sensors and computers with every generation. They build a great piece of machinery, but a single surge, electrical fault, or computer error and poof - you're on the side of the road.
Something as critical as the brake and throttle should have at least a complete second backup system on it just in case. Even if it is merely adequately designed, it's far better than nothing at all. That said, it's not impossibly expensive, either. GM and VW/Audi do it in their cars(Others may but I know that these two do for sure), but then again, they use potentiometers which are an order or magnitude or two easier to design a properly fail-safe system around.
edit - and no, by "properly" I'm referring to "works at all" versus nothing put in place to deal with any sort of critical failure. At this point, I'd settle for something rather than nothing at all.
No, it doesn't. But, it does provide significant information. If, after an exhaustive battery of tests, you still find no error in the system being examined, you move on to the next likely "candidate". And, most would find it foolish to chase after problems that cannot be duplicated. What judgment call would you make? How much testing would you do, finding no errors, before you concluded all was working as intended?
Remember, we are discussing a product manufactured for sale to generate a profit. When does one stop the examination process and OK the system?
I guess, if you are careening down a busy highway with no control of your car, the answer would be "a little bit longer". LOL!
As in the die example, without examining the die and knowing exactly how many 6's are on it, you would have to roll it into infinity in order to see how many actual 6's there are on it.
However, you can be sure to a high level of degree of accuracy that there is only one six after a few dozen rolls...actually, many less than that.
There is no 100% level of accuracy in any system that can be determined in a real world environment in any system. You can approach it, but never get there.
It seems, however, that you and a few others have already made the assumption that a problem exist (correct me if that statement is incorrect), and are now making guesses as to what the problem actually is... or at least, making the attempt to prove a problem exist.... specifically, a software problem.
Since you have the background you stated, I'm sure you can see the falacy of the argument. I don't work for Toyota, and I don't think you do either, so neither of us can accurately say how much effort Toyota put into its ECM design and testing. When did they stop rolling the die? Did they roll it at all?
Simply put, when would you stop rolling the die?
But let me add something else.
Would having access to the source code speed up the process?
Without a doubt, it would help. More information quite often is better than less in a situation such as this. And, from a PR standpoint, I think it would be in Toyota's best interest to have it evaluated by a 3rd party, under close supervision to make sure the code isn't "leaked" to additional sources.
That's probably not a real world scenario, though...Simply because of all the legal issues involved.
And, let's not forget this fact. Even if a bug or software fault exist, having the code examined by others is like the die example. The more that examine it get us closer to the 100% accuracy level, but we can never get there completely. Just as the fellow that wrote the code may have missed something, the examiner may very well miss the same error. Ooops! We have the same exact problem as before, when we were testing without the source code available.
Sometimes, we get so caught up in chasing down a problem, being convinced that it must be at "A", we lose sight of other possibilities, and miss seeing the problem was really at "B".
One can go to the doctor for a checkup and have the doctor (after a complete battery of tests) tell him he doesn't have cancer. But, he actually might. The test may have missed it. And, he can continue to have the tests run day after day, year after year, until some positive result is found. The question is...was the cancer there before the original diagnosis, or did it surface sometime later? How much time and how many tests before he feels safe enough to move on and live his life? How many rolls of the die before he feels comfortable with knowing the number of 6's?
"brake and throttle should have at least a complete second backup system.." They do have backup systems - it is utterly ridiculous to claim they don't.
No car maker can or should be expected to design detection strategies for artificially created events in the absence of any evidence that such an event can occur or is likely to occur in the real world. So I'll ask you for the 5th time - do you have any real world automotive examples of what you are saying? If not, perhaps joining a forum dealing with real observable problems such as malfunctioning LCD screens on TV's would be a better use of your time.
No, not really. I have offered my opinion that IF there really are UAEs caused by the ECU malfunction, that the root cause is probably a combination of things (input levels or a particular sequence of inputs; voltage fluctuation caused by, for instance, the AC compressor kicking in; EMI hitting at a particular point in time, aliens, ...) whose probability of occurring is very small. Hence, the relatively small number of UAEs reported given the number of vehicle miles driven or hours of operation, taken across all Toyotas.
The software is a sticky point because after signal conditioning of the sensor outputs and sampling by an ADC someplace in the ECU, all of the functionality is in the software. Yet, I have seen nothing in writing nor have I heard anything relative to the software in the ECU. Hence, it is big unknown. Things that would be useful to know would include (this list is not all inclusive):
1. What's the source line of code count (SLOC)?
2. What is the complexity of the SW (function points or some other metric)?
3. What language was used to develope the software?
4. What development standards were use?
5. What was their review process?
6. What was their testing process? Was IV&V used?
7. What was the bug report history?
8. How were the requirements for the SW developed? Remember, this software is basically replacing a throttle cable.
And, from a PR standpoint, I think it would be in Toyota's best interest to have it evaluated by a 3rd party, under close supervision to make sure the code isn't "leaked" to additional sources.
I agree, I do not know why something could not be done with an appropriate NDA in place. The more Toyota drags its feet, the more it's going to look like they have something to hide. I mean come on, it's just an engine ECU, not the launch codes for missiles.
And, I appologize if I offended you with my comment about not understanding the process, Looking back, I could/should have worded it much better. Typing isn't my forte', and I often (to my disadvantage, as in this case) attempt to be a little too brief in my particular responses.
Back to the subject...Another thing that certainly would be a good "predictor" relating to software would be the number of revisions...While a few updates are to be expected, if there are a significantly large number of revisions, in my experience, that usually spells trouble.
As for seeing the code, we must remember that many of the functions of the ECM is to keep the user from abusing the product (over-reving the engine, etc.). Keeping abilities for changing things such as this from the public serves as a significant benefit for the manufacturer, both in warranty protection as well as legal liability..
Its not a stretch to see a scenario where a "hack" diddles with the code to get more performance, things don't go as well as plannned, and his car becomes an airplane with very poor lift characteristics...immediately before he crashes, burns and dies....or maybe dies and then burns.
Then, the ambulance chasers arrive...You know the rest of the story.
Sometimes you're damned if you do, damned if you don't....
The Edmund's contest rules specifically state;
"We are not looking for mere speculation"
"Plausible - we are seeking to galvanize the search for answers that can have an impact on the automotive industry, for the purposes of the Contest, the unintended acceleration must be demonstrated under conditions that, in the opinion of the judges, could reasonably be expected to explain unintended acceleration in the real world."
Interestingly there is a clause that lets them waive a condition at their discretion
I said, "Anyone that stupid should be removed from the gene pool."
The real point of this story is that Hybrids have a fail safe throttle mechanism to protect the traction battery. It is different software than that which may be the cause of UA. So Toyota does make software that putting on the brakes will override any acceleration,as does VW. Toyota puts that system on their Camry hybrid.
In later 2010 models , Toyota is putting that sytem on all models.
Why would they do that if was a "floor mat problem" ?
I believe this is an admission of a software glitch which they are aware of.