Back in June 1969, the first Apollo moon shot had less computing power than simple greeting cards that these days play tunes. Even with all those monitors in Houston’s “Mission Control”, virtually all of the “computing” was analog. And to think that they designed all that with slide rules!
In 1969, there was absolutely nothing electronic about a car except for the radio (and that was pure analog circuitry as well). Ignition was electromechanical and anything with injectors was purely mechanical. The alternator might have had a zener to control a relay but that was about it.
Forty years later the radio alone can have as many as two or three embedded microcontrollers in it. The rest of the car is chock full of microcontrollers ranging from 32 bit 150+MHz Power PCs running the powertrain to a simple eight-pin SOIC microcontroller running the keyless entry key fob merrily chugging along at 4MHz or less. Embedded microcontroller designs are so well done that they quite often perform much better and more reliably than the analog functions they replaced.
It’s now a marketing feature to be micro-controlled. It seems that if engineers can throw a microcontroller at it, they will. And with that toss, there are a lot of efforts in place to ensure smooth developments and robust embedded designs.
SIDE ONE: HARDWAREThere are two sides to embedded microcontroller-based module development in automotive applications. The first aspect to address is the hardware. The microcontroller needs to be protected from the rugged automotive electronics environment. Microcontrollers are inherently susceptible to electrical trash that can enter either through the supply or through the I/O. The automotive electrical environment throws stuff at a module that is not normally seen in, say, a washing machine application. Subduing this electrical environment is not impossible; it just takes thought and money.
Conversely, control modules must also protect the environment from the electromagnetic noise generated by the microcontroller at high frequencies. Microcontrollers, being CMOS, have minute current spikes every time a bit changes state, which in turn generates EMI (electromagnetic interference) that can interfere with other devices outside the module, such as a radio. Some microcontrollers try to phase the internal clock to keep the bit banging more evenly distributed. The noise is more consistent but kept to a lower level that way.
The level of acceptable noise is regulated by module level EMC standards that must be adhered to. These standards are set up by the OEMs to keep modules from interfering with each other. Most module level noise is generated by the switching of higher current outputs, say, PWMing a lamp load, for instance. But noise from a micro can exit the module at any pin because micro noise is both conducted and radiated into the circuit board. To both shunt micro noise and protect against ESD (electrostatic discharge) small (typically 0.01µF), caps are placed at each pin of the connector. Each pin has its own capacitor with one side tied to the pin and the other to a ground ring around the connector. This does an effective job of shunting microcontroller noise as well as suppressing the standard human body model ESD event.
Power supplies used for micros can range from the basic shunt regulator (i.e., a resistor, capacitor, and zener diode) to the complex. Engine controller voltage regulators, for example, can contain a buck regulator, a boost regulator, several linear regulators, low-voltage detectors, and several voltage trackers as well as other higher level functions. Some circuits that interface with the engine control module microcontroller are “off board” from the engine control module. In many cases this requires the engine control module to provide buffered or protected supplies to these external modules to keep the main microcontroller happy and stable.
Watchdog circuits keep tabs on the micro in case the code decides to branch off for unknown parts. The simplest form requires that the microcontroller “pat the dog” within a specific frequency range. If the micro doesn’t do this, then the watchdog forces a reset, and things start over. This happened to me while driving my wife’s minivan several years ago. While driving, suddenly all of the gauges went to zero and then to full on before getting back to normal running. The watchdog wasn’t being patted properly and forced a reset. That could have happened due to EMI glitching the micro or a bug in the code.
When considering safety critical applications, extreme care is 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 doing stuff outside the normal expected routine, then the safing micro disables it and, in some cases, takes over.
In an engine or powertrain controller, this 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 powertrain 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 when the main microcontroller lost its brains and caused an “inadvertent deployment” at ignition start-up.
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 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 the 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 problem with dropping bits on occasion. Imagine, if one bit gets dropped out (goes from a “1” to a “0”) in the execution code, anything can happen. This dropping of bits gets exacerbated by ever-shrinking semiconductor lithographies. 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 hardware 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: SOFTWAREThe software has to be robust, fault free, and quick to market. Why quick to market? Because most won business requires an early prototype within a few months of winning the business.
The V-cycle of module development requires software to be developed concurrently with the hardware. 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, the code is not as simple but is easier to slap together quickly.
The most radical change to how stuff is coded is AUTOSAR (AUTomotive Open System ARchitecture). AUTOSAR defines itself as “an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers.” This standard divides the task of software writing into layers for ease in modularization. The layers start at the hardware interface defining the basic interfaces for the hardware specific peripherals and the rest of the code. The purpose of this layer is to make the higher layers more hardware independent.
The ECU Abstraction layer provides further microcontroller independence. This layer interfaces with the micro abstraction layer as a high level controller. The Microcontroller Abstraction Layer is a fairly universal bit of code in that it allows for every option the peripheral may have. The ECU Abstraction layer further defines what is used, thus reducing some of that extra code necessary in the one-size-fits-all format of the first layer. The Services layer is the highest layer in the basic software. It provides the complex functions such as the operating system, high level protocols for communication, and memory management for instance.
The AUTOSAR RTE (Run Time Environment) is the layer that the OEMs use to “program.” I am not sure that this would be called programming at this level. It is more of a putting a software version of Legos together. At this level, simulation is much more universal and the application software is fairly hardware independent. This translates to OEM code that can remain at the OEM regardless of which vendor they choose.
The AUTOSAR format works well with well-defined peripherals such as CAN and memory interfaces. However, when stuff like complex timers (serial HETs for instance) are brought into the mix, things get a bit tricky. These more complex peripheral functions are not so “portable” to other microcontrollers.
OSEK-VDX (Open Systems and the Corresponding Interfaces for Automotive Electronics) is a European standard for communication, operating systems, and network management set up by Siemens AG. OSEK is a registered trademark of Siemens AG, hence the German name. The entire purpose of the OSEK-VDX standard is to further modularize the software for higher portability between platforms. Here, the OSEK-VDX standard would fit into the AUTOSAR Services layer. The OSEK-VDX and the AUTOSAR standards are being looked at by folks in the US as a possible standard to adopt.
Lastly is the MISRA (Motor Industry Software Reliability Association) standard of coding. MISRA essentially regulates syntax and structures in code writing to prevent unintended side effects and inhibits the writing of “obscure code.” As with all things, the regulations can get quite silly as one-size-fits-all doesn’t work here either. As a result, the OEMs can specify the level of MISRA standards that must be applied to any given application.
There are programs out there like PC-lint by Gimpel Software that indirectly checks for MISRA-C compliance.
What MISRA brings to the table is the ability to safely modularize the code into functional blocks. Modular coding is the current mantra in software development.
The more software is modularized, the more experience the software engineer has with a specific block of code. With experience, the hope is that fewer bugs will be encountered at the last minute (like during production validation). As software requirements grow to the megabyte levels, software engineers need all the reliable shortcuts available. Oddly enough, the more code is modularized, the more bloated the code becomes, thus encouraging further modularization. This recursive phenomenon feeds on itself and is only limited by the memory size available and the willingness to pay for it.
There are still issues with extra unused features within code modules and the unintended interactions between code modules. Issues like stack problems, interrupt servicing delays, and other unintended interactions can occur when code modules are stuck together without too much thought. With the standards discussed here, these issues are minimized as much as possible as a cost of memory size.
Microcontrollers are definitely a major part of the automotive electronics experience. Not very many things are done electronically without a microcontroller today. They are flexible, versatile, and becoming cheaper every day. Who would have thought back in 1969 that a 60 MIPs controller with 256kB of memory would cost around $2? No wonder they are used in everything. After all, software is free, isn’t it?
