One assumes that the hardware and software gaps identified in this ECU implementation is sobering for anyone implementing driver assistance systems, drive by wire controls as well as those pushing fully autonomous cars.
Most automobiles today have multiple cpu's communicating over non-redundant networks with a non-zero error rates; as the complexities of control increase in drivers assisted, drive by wire and autonomous vehicles the ability to fully test and verify the implementation reduces. Even though the software and hardware may be designed to meet strict standards, the standard themselves have limitations and are open to some interpretation.
My major concern is that automation systems built by multiple organizations have an almost zero chance of reaching the same decision in the same time in any given emergency (and faults are just another emergency) event. Putting lots of these systems in close proximity in high speed flowing traffic may be a classical Butterfly Effect when things do fowl up.
We have so many things to fix to make these systems safe, and it is not helped by the performance achieved by some vehicles. Who on earth needs 0-60 in under 4 seconds where unintended acceleration means the vehicle may be pulling 0.7g from a standing start. With human perception/reaction times in the 0.5 seconds range at best (for a fully attentive driver to brake as here: http://www.ecu.edu/cs-dhs/ot/upload/AOTA_Brake_Reaction_Poster.pdf ) the vehicle moved about 11ft before you had any chance to react. (Just as disconcerting and deadly would be un-intended braking at highway speeds on those around your vehicle).
Big red buttons for emergency disconnects, brakes expected to dissipate the full engine power or any other human activated device you care to describe will not help. The reaction time of the automation will always be far shorter than any human reaction, so putting reliance on the human to be the arbiter in case of emergencies IMO verges on asinine.
For all this talk of unuusal software failures, one should recall that broken throttle return springs on a mechanical linkage are by no means unheard of. I've had one, several of my friends have, back in the 70s and 80s.
All this talk of "sudden acceleration" and the ensuing potential carnage is really a comment on appropriate driver training. A 70s muscle car going wide open throttle is going to accelerate pretty quickly, and you don't have the saving grace of a modern rev limiter, so the "shift to neutral" aspect is likely to wind up wiht engine damage.
Back then, the argument for neutral was "you'll lose your power steerng and power brakes" both of which are bogus. You're not going to be parallel parking, you're steering to the side of the road, and the turning effort isn't all that high when the power steering pump is off: People do have the belt fail or the pump fail, and nobody leaps up to sue because the car was uncontrollable. Likewise, power brakes are an assist, and vacuum operated. With the engine at WOT, there's not much vacuum anyway. In any case, you can still stomp on the brake and bring the car to a stop.
The real reason for the shift to tneutral advice is because people would turn the switch to the LOCK position and remove the key, and then be unable to turn the steering wheel.
In any case, this is just a matter of appropriate training. Everyone should have the instructor turn the engine off while driving, so they know what it's like. My driving instructor did this, my father did it.
Now lets talk about "I stood on the brake and it didn't stop". There are lots of documented cases where drivers have believed they were on the brake, and were on the gas instead. But leaving that aside, there is no car made where the brakes cannot overpower the engine, IF and only IF, you apply the brakes hard. Again this comes back to trianing. if you try to "ride the brake" to slow down (as opposed to stop), yes, you will overheat the brakes and they lose their effectiveness.
I have analyzed systems many times, where a minor, unnoticed software error could prove catastrophic. In one particular case, the probability of an incremental error happening was extremely small. However, the cumulative effect over a long period of time eventually proved catastrophic to the system's operation. The company had spend hundreds of thousands of dollars testing, in an attempt to figure out what was happening. I was brought in as an independent cousultant for another purpose, but needed to examine the relevant code to do my performance analysis. In my final report, I mention the errors I had found in the code, and their potential impact. The rresponse was, "OMG, we've been trying for months to figure out what was going wrong." I billed them heavily that month and they gratefully paid it.
There is in my opinion no way of 100% preventing an uncommanded wide open throttle condition occurring from time to time somewhere in a world population of over 1000 million vehicles. However the effects of a wide open throttle could be largely prevented by means of a totally independent fail-safe, a kill switch for example, that reduces engine power in an emergency. The present situation in which drivers have to brake against full engine power is totally unnecessary and potentially very dangerous. From a functional safety point of view it is unacceptable to make the driver the fail-safe for the malfunctioning electronics.
Hot News for 1897 – Preventing runaway electric taxis
Improved electric hansom cabs introduced by the Electric Vehicle Company in New York powered by two Westinghouse motors of 1.5 kW and 8oo RPM.
An emergency button operated by the driver's heel, could render the whole system powerless
Moms,Gijs: The Electric Vehicle –Technology and Expectations in the Automobile Age
This may be true for other auto maker. The speed at which new technology come to market, they are also prone to similar error. What are the steps suggested to prevent future errors like this. Is it really possible to prevent it 100%?
One of the safety standards for automotive electronics systems is ISO 26262, which was adapted from the standard IEC 61508, a popular safety standard followed in the industry for "Functional Safety" of programmable electrical and electronics system. I have worked on a number of safety programs per IEC 61508. From my experience, the possible causes of failures: such as "unprotected critical variables", "...tasks can die without the watchdog resetting the processor", erroneous bit-flip undetected etc. could have been averted if the embedded design of the throttle control system was compiled as per the safety standard. Unfortunately ISO 26262 was introduced after 2007 (most probably in 2010-2011 time frame) and I guess it was not mandatory for the automotive industry to comply with IEC 61508 for the automotive electronics system safety before that.
In most of the automated machine control systems - either hardwired, PLC based , or computerized, there is one big RED push button on the control panel, labelled "EMERGENCY STOP" This button when pushed deactivates all electronic controls and brings the machine to halt at whatever state it is.
A similar master stop button in the hand of the driver may be the solution for all kind exigencies arising out of hardware/software malfunction and avoid many a accidents because of the systems failures which require emergency manual intervention.
For the much touted "self-driven" car designers this is a lesson to learn.
I am in no way trying to defend buggy software or buggy hardware, I'm just asking how far does one have to go, and will it ever be far enough?
A fair question, but you don't want to go with the logical fallacy of "If it isn't 100% then it is useless." Examples of this type of thinking:
A seat belt won't protect you from all accidents, so you might as well not wear one at all.
A car lock won't protect your car from all theives, so you shouldn't even bother locking the car. In fact, make it more convenient for yourself by leaving the keys in the ignition.
Is a seat belt good enough if people are still dying in car crashes? Do you see the fallacy of this type of thinking?
We'll never get 100% safe, but I'll defintely go for 'safer'. And we can have standards and tests for what is considered safe design practices that lead to what is safe enough.
We understand SEUs and their effect pretty well. To support military projects, many logical synthesis tools can automatically implement logic that isn't vulnerable to single bit flips. People here have given examples of how code can be designed to handle unexpected jumps or variable flips, and these kinds of effects can be predicted and tested.
You can never get 100% error free, but implementing certain design styles and testing can definitely improve safety. I'll go with that, over nothing at all.