When considering safety critical applications, extreme care must be taken to keep a microcontroller from running amok. Quite often there is a second, smaller "safing" micro that runs alongside the main micro constantly checking if the main micro is doing the right stuff. If the main microcontroller starts acting outside the normal expected routine, then the safing micro disables it and, in some cases, takes over.
In an engine or power train controller, such methodology translates to initiating a "limp home" mode if the main micro loses its brains. In an airbag application the safing micro can prevent inadvertent air bag deployments. The focus for power train applications is keeping things running as well as possible. In an airbag application, the intent is to prevent bad things from happening.
One airbag application used just a "pat-the-dog" type watchdog for cost reasons. Apparently, this wasn't enough security for when the main microcontroller lost its brains, it caused an "inadvertent deployment" at ignition start-up. Very disconcerting indeed. (I think I'll get a (micro-controlled) remote starter!)
L4979 Voltage regulator with a "pat-the-dog" watchdog
Watchdogs are really needed in most embedded automotive applications because there is never enough time or ability to test for absolutely everything the code will experience once in the vehicle. No code is flawless. The trick is to design modules and write code such that when flaws show up they are "undetectable" or self correcting.
Embedded microcontrollers use on-board memory to store the program code. Quite often automotive OEMs require that it be flash memory to keep the code flexible during the product life cycle. Occasionally, stuff shows up that wasn't thought of during the development. As a result, the modules that are already in cars may need reprogramming.
Unfortunately, flash memory has a niggley little problemdropping bits on occasion. Imagine, if one bit gets dropped out (goes from a 1 to a 0) in the execution code, anything can happen. Murphy dictates that what will happen, will not be benign. This dropping of bits gets exacerbated by ever-shrinking semiconductor lithographies. Please keep in mind this is a little problem. Due to the fact that the micros are the most critical component of the safety system, any problem with a bit dropping is unacceptable.
To combat this little problem with flash memory, extra bits are added to each byte, and error correction algorithms are implemented. These algorithms and extra bits can catch a bit dropping out and automatically correct for it. A good many automotive applications and all safety critical applications require this error correction stuff in the flash memory array. If a second bit drops out, bad stuff happens. Fortunately, this doesn't happen often enough to worry about, too much.
Some of the higher end microcontrollers can correct for one bit dropping out and detect for a second bit dropping out, but not correct for it. Detecting the second bit dropping out causes the microcontroller to stop executing code as opposed to doing something totally unpredictable. This strategy minimizes inadvertent airbag deployments and other such bad stuff from happening.
Many times, there is the software/hardware trade-off situation. Typically, the software guy wins. If something can be done in software versus doing it in hardware, trust me, it gets done in software. After all, as long as there is space and bandwidth, additional software is "free."
Side two: Software
Which leads us to the second point: Software. The software has to be robust, fault free, and quick-to-market. Why quick-to-market? This is because most business wins require an early prototype within a few months of winning the business. Sometimes even before winning the business, the potential customer will want to see something wiggling.
The V-cycle of module development (below) requires software to be developed concurrently with the hardware. But it is fairly difficult to debug software without the hardware it is embedded with. Many times, this forces the software engineer to throw stuff together in a panic and hope for the best. As a result, there are many fleet-of-foot software designers worth their weight in gold.
To ease the burden, the automotive OEMs have enforced three standards to try to simplify the coding process. In the end, this code is not as simple, but is easier to slap together quickly.