I myself have learned a great deal in following the Oklahoma case. The thing is, though, that this is not the end of the Toyota's unintended acceleration trial.
Toyota is facing another trial early Nov. -- this one will be in federal court in Santa Ana, Calif.
In many of the death and injury lawsuits, including Bookout's, plaintiffs claim that loose floor mats and sticky pedals don't explain all episodes of sudden acceleration and that the electronic throttle control system is at fault.
The reason why EE Times is following the case so closely is that the Oklahoma trial was the first instance when any of the testimonies by expert witnesses focused on software and hardware issues -- outside the floormat and sticky pedals -- became publicly available. Until now, such reports and testimonies have been sealed under the court order.
And one more disturbing fact. Bookout's vehicle, a 2005 Camry, wasn't included in the Toyota's recalls.
There have been many-many posts here about how the braking system should always be able to override the engine.
What about the anti-lock braking system?
Virtually every car has them and the control computer has the ability to release the brakes at any time depending on factors like invididual wheel rotation speed and so on. I don't know how the ABS is tied into "Task-X" but if they all use the same microprcessor, it's entirely possible the ABS will be affected too.
Thus, pushing on the breaks would have no effect if the ABS has released them, falsely thinking the car was in a skid condition. This seems to correlate closely to what some drivers have reported; that the brakes had no effect.
It seems there should always be a mechanical overide for emergencies like these. The parking brake, otherwise known as the "Emergency Brake" which it isn't, applys only the back brakes. And the actual brake pads are tiny compared to the front pads. It would be of no use in an engine runnaway situation.
I'd really like to know how the ABS ties into all of this.
Thanks Junko for the thorough coverage. I've learned a lot about the case.
There seems to be serious design flaw. In order to avoid any serious issue in any software system, the design shall always avoid deadlock. There shall always be a simple task to monitor the health of the system. A watchdog to reboot the system in case of deadlock is an avoidance mechanism; system engineer shall not rely on it.
To be honest, I'm quite surprise to read the report. Toyota is a very good company. They should know better. I wonder whether there is anything missing n the findings.
Nonetheless, Toyota will learn from it and make themselves better.
Actually, in every cruise control system I've used, if the desired speed (set by the accelerator pedal position) exceeds the current CC set speed, the system will still throttle up; when the pedal is released, it smoothly returns to the set speed. So when things are working, the pedal is not ignored. If task X failed, you'd notice that you couldn't speed up, either.
"I think that what you may have meant to say was that the accelerator pedal signal was not examined when in the cruise control mode."
Indeed. The angle of the accelerator pedal. Sorry for the ambiguity.
In at least some older cruise control systems, perhaps also on some new ones (I certainly haven't done any study on this), the cruise control system actually moved the accelerator pedal. So that the same linkage between accelerator pedal and carburator was used in cruise control mode, to maintain a constant speed.
"In cruise control, presumably the throttle angle is not examined at all, and the fuel/air command is supplied as a function of vehicle speed vs requested speed."
I think that what you may have meant to say was that the accelerator pedal signal was not examined when in the cruise control mode.
I understand that in cruise control there is still an inner throttle position control loop and an outer speed control loop is added. In effect the driver input via the accelerator pedal is disabled or ignored.
The outer control loop is a speed control loop - where a speed signal is fed back and compared with a set speed (speed reference) to give a speed error. Presumably it is the speed error that is fed in as a torque request to either speed up the vehicle or slow it down to match the actual speed to the set speed.
Actually, what this throttle position algorithm does is translate the pedal position (which is apparently determined by an unregulated analog voltage, corrected by the program, according to a separate article) into fuel and air delivery to the fuel injection system. When the car is not in cruise control. In cruise control, presumably the throttle angle is not examined at all, and the fuel/air command is supplied as a function of vehicle speed vs requested speed.
Worrisomely, brake application did not override these control signals if that control algorithm app died. *That's* the crux of the issue here, I think.
I have to agree that monitoring functions, especially in safety-critical systems, should be done independent of the control functions. A totally separate loop, software and also hardware.
What caused the so-called "stuck pedal" wasn't the issue in this case. At issue was the software controlling the electronic throttle control system.
As the expert witness explained, the software in electronic throttle control is responsible for performing the sparking and the throttle control.
But there is another part of the software that is looking at the driver controls-- looking at the accelerator pedal and cruise control. So there is a part of the software looking at what the accelerator pedal position is, is it down, is it up, how much down. Then that is translating that into a calculatedthrottle angle.
That malfunction was the crux of the issue that was argued in this trial.
Blog Doing Math in FPGAs Tom Burke 13 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...