The expert witness aptly describes the Task X as "kitchen-sink" task. It is designed to do just so many thing. So what happens when the Task X does? So many things could go wrong, and one of which is a loss of throttle control. Talk about a bad design.
It is true that the throttle function will be affected by the software malfunction, but why the throttle function is not being tested again in the worst case scenario again to justify the findings after Toyota Trial?
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.
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.
"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.
"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.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.