[cryptnoob]

I've designed systems like this. You use redundant potentiometers to sense throttle position. If they don't match within 5%, you power down.

You also toggle bits in your code. One in the main loop, another in any interrupt service routine that you are dependent upon. These bits then go to a GPIO so that the GPIO toggles. If the ISR freezes or the main loop freezes, the GPIO quits toggling. You then have an hardware, RC-Diode type circuit, that stays high if it's input toggles, but goes low, if it's input goes low and stays low, or goes high and stays high. The output of this circuit drives a relay, so that if the CPU quits toggling the GPIO, the relay clicks off. The output of that relay is a dead-man's switch that powers down the vehicle. The end result is a hardware fail-safe if the CPU misbehaves. There are other tests to confirm that the relay isn't frozen, that the RC-Diode circuit isn't frozen, etc.

So, in theory, if a high-school sophomore designed the vehicle, you might have a problem. Otherwise, I think you don't give the engineers that design these systems enough credit.

[jonknee]

... And yet there are out of control cars without the pedal being stuck.

"Well, I have many models of Prius that got recalled, but I have a new model that didn't get recalled. This new model has an accelerator that goes wild, but only under certain conditions of cruise control. And I can repeat it over and over and over again--safely."

"This is software. It's not a bad accelerator pedal. It's very scary, but luckily for me, I can hit the brakes," he said.

-- Steve Wozniak

http://news.cnet.com/8301-13924_3-10445564-64.html

[cryptnoob]

This is more believable to me, as the "set-point" for cruise control is not dependent upon throttle position, but instead, is remembered by the computer. There's nothing to check against to insure believability.

More suspect, in my opinion, is that in a cruise control, you have a feedback system, based on car speed. The car speed is almost certainly redundantly sensed, so that's no worries, but the feedback loop itself could potentially go oscillatory if there were other variables introduced that hadn't been designed for. Those variables could be pretty subtle. For example, maybe the gear motor that you use to mechanically control the engine gets sourced from another distributor, and they give you a better one, that has more torque. Perhaps that throws off the stability analysis that you had done. Tons of things could change somewhere between the 500K's car and 1M's car you produced, lots of different vendors and permutations could come into play that could throw off the stability of a cruise control, I would think.

EDIT: They're probably using feedback in the control motors as well (servos), so that's a non-realistic example, but it illustrates the problem.

[CamperBob]

To be fair, Woz's account seems to be limited to the case where someone uses the cruise control above 80 MPH, far from what the control loop was optimized for. I didn't see anything in what he wrote that could possibly have any bearing on the cases being examined.

Brain-dead cruise control behavior is nothing new. My '92 Porsche 968 would cheerfully redline the engine if you disengaged the clutch with cruise active.

[snom370]

Still, this doesn't account for the case where the CPU and the watchdog signal is working, but the algorithm isn't. Pure software malfunctions, have happened on commercial airliners, where there are quite stringent FAA requirements regarding how the software is developed and maintained. So it wouldn't be surprising if it happens in automotive systems, where you might not have the redundancy of multiple CPUs running concurrently.

I'm not sure if automotive systems are held to any certification standards. Maybe someone working in this field could answer that?