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