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.
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.
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.
The question of whether engineers could have foreseen the shortcut maintenance procedures that led to the crash of American Airlines Flight 191 in 1979 will probably linger for as long as there is an engineering profession.
More than 35 years later, the post-mortem on one of the country’s worst engineering disasters appears to be simple. A contractor asked for a change in an original design. The change was approved by engineers, later resulting in a mammoth structural collapse that killed 114 people and injured 216 more.
If you’re an embedded systems engineer whose analog capabilities are getting a little bit rusty, then you’ll want to take note of an upcoming Design News Continuing Education Center class, “Analog Design for the Digital World,” running Monday, Nov. 17 through Friday, Nov. 21.
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.