The sudden unintended acceleration problems in Toyota’s vehicles have touched off a firestorm of controversy over the cause(s). Now, a professor of automotive technology at Southern Illinois University has entered the fray, testifying before Congress that the trouble locating the problem’s source could stem from a missing defect code in the affected fleet’s diagnostic computer.
In testimony before a house subcommittee Tuesday, David W. Gilbert, a Ph.D. with almost 30 years experience in automotive diagnostics and troubleshooting, said his initial investigation has found problems with the “integrity and consistency” of Toyota’s electronic control modules to detect potential throttle malfunctions.
Specifically, Prof. Gilbert disputed the notion that every defect would necessarily have an associated code. The “absence of a stored diagnostic trouble code in the vehicle’s computer is no guarantee that a problem does not exist.”
In fact, using a 2010 Toyota Tundra, Prof. Gilbert discovered electrical circuit faults could indeed be introduced into the electronic throttle control system without setting a diagnostic trouble code. “Without a diagnostic trouble code set, the vehicle computer will not logically enter into a fail-safe mode of operation. … Since the vehicle computer will only react to defective sensor inputs outside of the range of programmed limitations if the circuit is not defective; it must be good.” In other words, because a code did not exist for the sensor to inform the on-board computer of a problem, when a short occurred the computer did not recognize the problem, and therefore it took no steps to mitigate it. And absent the code, no defect was entered into the database for post-incident tracking.
Prof. Gilbert further determined that electronic control module malfunction detection strategies were not sufficient to
identify all types of fundamental APP sensor and/or circuit malfunctions. “Some types of electronic throttle control circuit malfunctions were detectable by the ECM, and some were not,” he testified. “Most importantly, the Toyota detection strategies were unable to identify malfunctions of the APP sensor signal inputs to the ECM.” (Watch this video of Dr Griffin’s test at his university test track.)
Yikes! If Prof. Gilbert is correct, this could explain why Toyota engineers have failed to diagnose the electronics as a potential source of sudden unintended acceleration. As one reliability expert told me, this could be the smoking gun.
We await Toyota’s response to this revelation.
Why did it take an outside Expert to find this out. What kind of engineers does Toyota have? Apparently, not any that can detect troublesome code. (Oh by the way Jim, we forgot to check if the electronic control module malfunction detection strategies were applied to the GAS, duh!)
So now that Prof. Gilbert solved the problem does he win a new Toyota? Will he drive it? If he did, He’d probably reverse engineer it to make a better one.
There are two (at least) issues being “brought into the light” with this video.
1) conflicting commands (brake and accel/AAP sensor ) are not being defaulted to a “safe” condition (assuming brake has priority over gas in a standard car)
This conflict has many “gray” areas concerning the operation of a car and how to resolve them.
I am sure there are “two footed” drivers (?) that want the ability to ride the engine against the brake … purpose in the “old” days? to create a temporary “limited slip” differential on snow / ice.
I doubt anyone could explain a valid situation for standard driving – involving full throttle against the brake – on a Toyota sedan. ( maybe a Lambo or Ferrari max launch?)
2) the reporting of error codes…
Often, short term “errors” or “noise” in active electro-mechanical systems, are ignored or filtered out, if they don’t last long too long.
Reason: these systems often have electrical noise created by mechanical components- with noise levels and frequency content that cannot be re-created or duplicated in a controlled environment. result? .. ignore the abnormal/temporary signal.
However .. in the video.. the shorted accel pot (AAP sensor) was much longer in duration than what I would expect to be “filtered”. Indeed, if the ECU wasn’t able to tell the difference between a “full throttle” command and a short.. there is a primary flaw in the design.
I am not familiar with the details of the Toyota AAP sensors involved.
Based on the apparent “Shorting” in the video… these AAP sensors are variations of Potentiometers …. the following comments are based on this assumption.
I would have expected “full throttle” to equate to something less than 100% pot position.
same should be true of “idle” (should be higher than 0% position)
positions of less than 3%.. or….more than 95%..
should indicate “shorted or open” wiring to the pot.. a failure (and be recorded as “error”) .
This is simple / basic fault handling.. well within the expectations of the consumer for this product.
I don’t believe we should expect 100% safety in complex systems.. but IF this video is truthful in it’s representation of the facts…. this system isn’t reasonably safe.
It is reasonable to expect shorts / opens on the throttle position, and reasonable to expect the ECM to detect it.
I do have experience with the subject.
I program the ECM (Electronic Control Module – main computer) on my car.. (personal note)
And I do design custom (hardware) ECMs for other cars (professional note) … millions of people yearly , depend on my knowledge for safe travel in their cars (not Toyota).
Lambert is right on!
Some of the data I saw specified 70% as a valid WOT signal on some models. I don’t know what Prius wants to see for a valid WOT.
With a throttle cable and spring, a failure defaults to idle unless the cable is jammed.
With my experience in remote control, the design must be such that the input signal is verified in some way that determines the signal is either valid or not. Any invalid signal shall result in a fail to safe condition. It would seem Toyota could at least use voltage references and comparators to calibrate for normal inputs and fail-safe for abnormal inputs. The better solution would be to build the peddle as a unit that provides an error- corrected serial I/O to the computer, so that it could at least know when it saw a valid signal. That would require a substantial design update.