Control system safety has always been a vital part of control systems, and in times past it was mandatory that the emergency-stop system not depend on any programmable logic. The reason is clear, not that the hardware was unreliable, but that the software could be corrupted. That was acknowledged by all involved, and the rules written accordingly.
Now we get to where there are all kinds of software controlled functions in a car, with quite a few of them being important to vehicle safety. This has certainly increased the probability that a failure coud have very bad results. After only a few dozen unexpected acceleration incidents it has become apparent that perhaps some effort should go toward guarding against software failures. Of course, only a fool would release a system whose "emergency stop"function was dependant on part of the software in the control program. Those responsible for assuring the safety of cars on the road should have refused to allow the sale of any vehicle that could not be switched off manually in the event of a control program failure. IT would seem that economic considerations were far more important than user safety. In this case especially, providing an "emergency stop" function would not have added any major cost to the system and it would have shown due dilligence in providing a safety feature.
So now the makers of the automotive systems are at last admitting that things can fail, at least a bit, on occasion, and so they have decided to provide a means to reduce the effect of a failure. This is certainly good, and it should benefit all. But I still would demand that all vehicles have a means to shut the engine off, independent of the control program. And I don't believe that is at all paranoid, not one bit.
While it is no easy task right now, with the advances in electronics and chips, it will not take long for it to become easier.
MCU's are becoming the working horse of industry. As their reliability and acceptacle occurs, it won't be long before they are in everything. As long as Engineers keep in mind that they need to implement code to compensate for the lack of inherent robustness that the MCU lacks versus PLCs, MCUs are a very strong contender.
I expected this subject would come up sooner or later with microprocessors now controlling the functions of automobiles. PLC's have been used for years to control elevators and amusemnet park rides. Generally for critical situations such as this, there are two PLC's and they monitor each other in a 'watchdog' configuration. There are few if any failures in these systems that can be traced back to the controller... I have been in the automation business for 30 years and have never seen a PLC fail or had to replace one. Obviously this same robustness needs to be applied to embedded automotive control systems. And work under many varied modes and enviromental conditions. No easy task.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.