Microcontrollers for the Automobile

In order to deal with the new range of system requirements, the automotive microcontroller will be further developed to facilitate new functions.

Communications
Communications between electronic control units (ECU's) is a growing trend. Multiplexed communications in vehicles was originally developed to reduce weight, interconnections, cost and complexity. It soon became apparent however that vehicular systems could be enhanced greatly with the opportunity to share data from different ECUs, in real time.

Unfortunately, a single communications protocol, which can cost-effectively address every automotive application, does not exist. Instead a number of different communications subsystems are integrated together in a modern vehicle. This is illustrated in Figure 2.

Figure 2 shows five distinct communications systems, which are implemented on a vehicle. In addition it is likely that there will be a number of additional 'sub-bus' networks for sensors and actuators. Gateways exist between these networks to share information across 'boundaries'. The chassis control functions are grouped on a redundant network, which meets fault tolerant criteria; only safety critical information is allowed on these buses. Likewise a highly robust independent network is provided for the airbag system.

Many new automotive microcontrollers will have more silicon devoted to communications capabilities than the CPU! Already, microcontrollers such as the M68HC912DG128 are being offered with two independent CAN (Controller Area Network) modules along with several more synchronous and asynchronous communications systems. These communications interfaces are as autonomous as possible, so that the CPU does not need to devote a great deal of overhead to managing communications. 

              Figure 2 - The networked vehicle

Algorithm complexity
The increasing complexity of automotive electronic systems has had a dramatic effect on the throughput requirements and peripheral integration of automotive microcontrollers. Algorithms are now required to handle the inputs from many sensors and communications systems, execute real-time control cycles and control the outputs of many actuators. 

Figure 3 illustrates the effect that this growing complexity has had on the physical characteristics of microcontrollers. Three generations of powertrain microcontroller are shown. In the space of three generations, the microcontroller has become around 100 times more powerful in terms of CPU throughput, the program memory (holding the algorithm) has grown 40 times bigger and the number of transistors on the chip has increased by a factor of 300. The powertrain application is by no means unique - many controller systems in the vehicle have kept pace with these developments and 32-bit RISC processors are being used for new generations of Airbag and ABS systems.

Algorithm complexity is also leading to the widespread implementation of operating systems. Although most operating systems are still developed in-house by the application specialists, the industry will migrate very quickly towards standardization of the operating system and network management. The OSEK/VDX operating system has been adopted by many as the open standard (OSEK is a German acronym for 'Offene Systeme und deren Schnittstellen fur die Elektronik im Kraftfahzeug'). This standard was developed specifically to decouple the application code (algorithm) from the network management tasks and avoid incompatibility problems between the application code and the hardware. It includes a standardized application programming interface, behavior and protocol. Implementation of OSEK/VDX should facilitate reusability and portability of software and predictable system behavior. It is expected that many automotive microcontrollers in the near future will be implemented with an OSEK operating system.

Figure 3 - Automotive microcontroller complexity

Smart nodes
As well as the growth in electronic control systems and communications networks, which will lead to an increased number of microcontrollers in the vehicle, there will also be a growth in the number of sensors and actuators. In conventional systems sensors and actuators were connected directly to the appropriate electronic control unit, usually by a twisted pair. As the number of sensors and actuators increases, there are several problems, which are faced. Handling their interrupts or sampling their outputs, providing different interfaces for each sensor / actuator becomes problematic, as well as processing / sharing the (usually analog) information which is exchanged between the control unit and the sensor / actuator.

As the cost of electronics is coming down and the need for simplification of such systems is increasing, it will become more common to implement smart sensors and actuators. A smart sensor / actuator need not include a microcontroller (but mostly will have a small CPU) and will be connected to the ECU on a bus system. Much of the growth in automotive microcontrollers, which is shown in Figure 1 will be a result of smart nodes.

Today's smart nodes are usually composed of a package containing a microcontroller die, sensor die and sometimes an analog-interfacing die (depending on how much functionality is included on the sensor die). It is anticipated that it will be cost effective in the not-too-distant future to integrate MicroElectroMechanical sensors (MEMs) and microcontrollers on a single monolithic silicon chip. Such a concept for a pressure sensor is shown in Figure 4. The sensing element, analog interface and microcontroller functionality are all contained on a single silicon die.

Figure 4 - Integrated single chip smart pressure sensor

Safety critical operation
Microcontrollers have been at the heart of safety critical systems for many years. Almost all of the safety critical automotive systems in which they have been used have provided a fail-safe function. In the near future, there will be an added requirement for fault-tolerant microcontroller based systems.

There is an important difference between fail-safe systems and fault-tolerant systems. Today's Antilock Braking Systems are fail-safe: if an electrical system error is detected, the ECU switches to a safe 'off' mode, allowing the foundation hydraulic brakes to operate without the faulty ABS system interfering. A fault-tolerant system must not only recognize that an electrical fault has occurred, but must continue to operate safely with the existing known fault. Antilock braking systems use redundancy to facilitate a fail-safe system. Typically the CPU at the heart of the system supervises the continual testing of all the major system components. The CPU can only validate these components however, if the CPU itself is known to be 'sane'. Hence a second, redundant CPU is used to validate the sanity of the first CPU. A redundant CPU can either be implemented as a second standalone microcontroller or as an error detection CPU with comparison logic on the same microcontroller.

Emerging automotive applications such as Brake-by-wire and Steer-by-wire systems will not be satisfied by a fail-safe system; they will require a fault-tolerant solution, as a hydraulic back-up mode will not exist. Therefore if a fault is detected, the system must continue to operate safely in a 'limp home' mode. Although simple redundancy of components and a voting algorithm can be used, this is normally a very expensive solution (voting requires at least three CPUs). There has been an increasing amount of work done in the field of time-triggered communications protocols (such as TTP/C), which will be used to satisfy fault-tolerant automotive system requirements. A cost-effective microcontroller based control system, which provides fault-tolerance will require control modules (like a TTP/C controller) integrated with microcontrollers to support the new fault-tolerant communications systems.

Microcontroller Technology
Because of advanced system requirements such as increased communications, algorithm complexity, safety critical requirements and such like, microcontroller technology requirements will be impacted.

CPU trends
An effect of the increased throughput requirements driven by algorithm complexity is the requirement for very high performance, low cost CPUs. As well as providing a very high throughput and fast interrupt handling capabilities, the CPU must also be conducive to generating efficient dense code when a C compiler is used. As the CPU is now usually a relatively small area of the die with respect to memory arrays, if a CPU is designed in a high-level language friendly way, a significant amount of memory (and hence cost) can be saved.

There is also a trend to use high-performance RISC CPUs in automotive microcontrollers in preference to the traditional CISC units. This trend will continue. Traditionally, what has set RISC apart from CISC is the ability to execute an instruction in a single clock cycle and the fact that RISC machines do not use microcode to decode instructions, but are hardwired.

It has been argued that the vast majority of most software consists of very simple instructions. The philosophy of RISC is to produce processors that can execute these simple instructions (such as ADD, SUB, SHIFT, etc.) in one clock cycle. More complex instructions such as MUL and DIV were not available on early RISC processors. 

When an opcode is generated by a line of software in a CISC machine, this opcode is basically an address for a microcode memory (also sometimes called a 'control store') which points to a certain string of control bits that are applied to the execution unit (via a small amount of combinational control logic). These bits include many control signals to ensure that the execution unit performs the desired function. This microcode memory is a regularly structured array, which is straightforward to design and offers flexibility to the designer, allowing him to design the optimum microcode.

A RISC processor does not have a microcode memory. Therefore the opcode, which is generated in software, is applied directly to a larger array of combinational control logic in order to generate all the appropriate signals to operate the execution unit. This is a more complex design, which results in a smaller silicon size (as there is no microcode memory) and usually faster operating speed. 

The distinction of single clock instructions for RISC only is becoming more vague as many RISC CPUs now include complex instructions which can take several cycles to execute. RISC processors only allow operations to be performed directly between registers in the CPU. This means that if we had two bytes in memory that we wanted to AND together, we would have to first load them into CPU registers. CISC machines would normally allow you to AND a user register with a location outside the programmers model.

Memory trends
The standard microcontroller memory types which have become established in automotive systems are ROM, EPROM and Flash EEPROM for program store, RAM for stack and scratch-pad memory, and byte erasable EEPROM for storage of calibration and security data. As Flash EEPROM is becoming more cost effective, it will ultimately replace ROM as the favored memory solution.

Automobile manufacturers often wish to revise software in the field. Unless there is a method of reprogramming the memory array remotely, typically this problem requires the sealed ECU to be removed and replaced. This is a time-consuming and expensive process for the Automobile manufacturer, not to mention a greater inconvenience to the owner. Flash EEPROM provides the technology, which allows such field revisions.

This system can be used for software upgrades as well as software revisions. It is now becoming more common for ECU suppliers to build generic platforms, which may have slightly different features, implemented in software. For example, some automobiles automatically adjust the side view mirrors (which turn to point to the rear wheels) when the vehicle is placed in reverse gear. This feature is implemented in software and feasibly could be offered as a 'software upgrade' in the after-sales market.

Memory sizes for most automotive applications will continue to grow, leaving the CPU on the microcontroller occupying a relatively small portion of the chip. Figure 5 illustrates a die photograph of the M68HC912DG128, for use in automotive applications. The relative sizes of the memory modules and other microcontroller functions can be seen clearly on the photograph.

Figure 5 - M68HC912DG128 Microcontroller

The microcontroller shown has 128K of Flash EEPROM memory in four 32K arrays. Each array can be bulk erased separately. Having only two arrays of 64K would reduce the die size but erasing the memory would not be as flexible. In addition, a 4K RAM is included and 2K of byte erasable EEPROM. Typically a ratio of 32:1 is considered appropriate between program memory and RAM on modern microcontrollers. Certain applications, which are RAM intensive may require more, although modern design techniques are usually helpful in estimating exact codesize requirements early in the design cycle.

The memory system in future automotive microcontrollers may be enhanced in certain cases to allow simplified memory verification. In a safety critical system, it may be desirable to check that memory contents are stable and have not been corrupted during the course of operation. There are several techniques that can be implemented to validate memory contents, each having its own merits and problems. The most straightforward way is to implement a parity bit on the entire memory array. Whenever a byte is written to memory, a parity generator adds an extra bit and whenever a byte is read from memory a parity checker will ensure that a parity error has not occurred. Another scheme, which has been widely discussed, is the use of a Linear Feedback Shift Register to perform signature analysis on blocks of memory. 

Packaging trends
It can no longer be assumed that automotive microcontrollers packaging requirements are conventional PCB mounted plastic / ceramic units. Processing is becoming distributed around the vehicle as dictated by the locations of sensors and actuators, and packaging requirements are changing accordingly. A mechatronic approach is now being taken for microcontroller packaging. 

Mechatronics is a discipline, which has arisen from a need to look at systems as a whole, rather than component parts, such as electrical/electronic engineering and mechanical engineering. It aims to bring about completely optimized systems by integrating the individual components of design into a process, rather than the traditional approach, which often yields a collection of electrical, mechanical and hydraulic subsystems interfaced together with a control unit. There is much opportunity for mechatronic technology to improve today's automobile systems.

Figure 6 shows two approaches to an electronic motor controller. On the left, the electronic control circuit uses a number of different interconnect technologies including rivets, solder, surface mount devices and wire bonding to a silicon die. The diagram on the right is an example of a mechatronic solution where an electronic microsystem has been constructed using a multi-chip module and 'connectorized' for robust and efficient interfacing with a motor housing. This type of mechatronic system would usually have many less interconnections than the traditional solution. 

Both motor control circuits are connected to a bus via a plug. On a modern automobile, this interface is likely to be a communications bus, linking several motor control circuits (such as window lifters, seat positioners and mirrors).

Figure 6 - Mechatronic motor solution

Noise reduction
ECUs and all electronic components contained within are thoroughly tested to measure Electromagnetic Compatibility (EMC) performance. EMC is becoming a bigger issue for automobile manufacturers as the operating speed of electronic components is becoming faster (higher frequencies lead to increased electromagnetic emissions) and the number of ECUs, which could potentially affect each others operation is increasing.

Worst-case, the result of an ECUs operation being corrupted by radio frequency emissions (from either another ECU or external source from the vehicle) could be a potential compromise on safety. Electromagnetic compatibility can be optimized by careful design of the integrated circuit and the printed circuit board. A system is considered electromagnetically compatible if it satisfied three criteria:

· It does not cause interference with other systems
· It is not susceptible to emissions from other systems
· It does not generate interference with itself

In recent times, the automobile manufacturers have been putting more pressure on the ECU suppliers to produce units with better EMC performance - this pressure has, in turn, been put on the semiconductor suppliers to produce more robust microcontrollers. At the integrated circuit design level, there are many considerations that can enhance the EMC performance of the design: Using less clocks and turning off clocks when not in use, reducing output power buffer drive, using multiple power and ground pins and reducing internal trace impedance on these pins, eliminating integrated charge pump circuitry and positioning high frequency signals next to a ground bus are all steps which are now taken to improve EMC.

Power consumption
Until only recently, low power consumption was never considered a priority requirement for automotive ECUs. This has changed on account of the number of systems, which are required to operate when the ignition is switched off. These systems would quickly drain the battery unless special attention was given to their power consumption. The door modules are a good example. These ECUs need to exist in a 'ready' mode permanently in order to recognize a signal from a 'Remote Keyless Entry' device. 

All automotive MCUs are now optimized for power consumption. This is mainly done by switching off the chip's internal clock source, when the chip is inactive. This also results in reduced noise emission. Power consumption is also a consideration for Airbag ECUs. Airbag ECUs need to function in the event that a crash situation disconnects the electrical power supply for the ECU. A large capacitor is normally used to ensure that under these circumstances, there is enough energy available to fire the bag(s). By careful design attention to power consumption requirements, the size of this capacitor may be reduced, thus reducing ECU cost. Airbag microcontrollers are often selected primarily by measuring maximum MCU performance while operating at a speed defined by a given power consumption limit.

Integration
All microcontrollers follow a roadmap of integration that has seen the feature sizes drop from several microns to about 0.5 um effective gate width, in today's state of the art devices. This feature size shrinkage is set to continue and will result in lower costs, higher operating speeds and an increased functionality of the chip. One of the challenges which offsets these benefits is the reduced operating voltage requirements (the smaller gate oxide cannot withstand the higher voltage). In order to function at 0.5 um, a 3.3v power supply is required for the CPU. Below 0.5 um will bring a further requirement for 1.8v power supply. This means that additional power supply capabilities of the system are required in order to take advantage of the integration technology advances of the microcontroller.

For a number of years, mixed signal devices which include high voltage / high current capabilities have been produced for automotive applications. Mixed signal capable microcontrollers will continue to be developed where it is cost effective to do so and if it makes sense from a system partitioning perspective. Partitioning functions in the Electronic Control Unit (ECU) and satellite modules (sensors, actuators, other ECUs) is not always straightforward. The problem is multi-dimensional as functions may be implemented in different semiconductor technologies, as hardware or in software, and may include other considerations such as the physical location of the function. The first step is usually to isolate each function to be performed (like sampling a sensor output or driving a motor) and then examine each possible implementation. When all functions are identified and their inter-relationship understood, the lowest cost / most efficient solution may be determined.

When re-partitioning any existing system, it is important to always look at basic functions rather than existing solutions. New technologies may be available which will allow a better implementation of that function. By using a new type of sensor which doesn't require costly interfacing, a cheaper solution may result. Perhaps the sensor can have a digital interface integrated which will allow the information to be shared on a common bus with other systems. The best solutions always result with close cooperation between semiconductor integration experts and systems experts.

The semiconductor vendor is uniquely positioned to assist in partitioning the system. It is possible to integrate power functions onto microcontrollers, digital functions onto analog chips, signal conditioning and digital interfaces with MEMs sensors (i.e. accelerometers, pressure sensors, etc.), and many other combinations of these functions are possible. Software is an important element that must be considered too. As microcontroller bus speeds have increased enormously, it is no longer necessary to use complex hardware to off-load interrupts. The processor may be more than capable of handling these interrupts due to vastly increased bandwidth. Conversely, a great deal of bandwidth may be consumed by software, which can be replaced by minimal hardware. Figure 7 gives an example of a 'system chip', with various types of technology implemented on the same silicon.

Figure 7 - System Chip

The most highly integrated product is not necessarily the best product. When reduced cost is the sole motivation for integration, there will be a point on the curve, which determines the optimum level. Other motivations for increased integration may exist however, such as reduced chip-count/size, reduced power consumption, general simplification, increased reliability, etc. More highly integrated products also tend to have less generic appeal. This translates to reduced economies of scale and usually slightly higher costs. Often however, this additional cost is more than offset by a more competitive product in the market. 

Electronic Design Automation
Future automotive microcontrollers will be impacted by changes in the design methodology, which is being adopted in the automotive electronics industry. There is a trend to take a systems engineering approach, which is an integrated design methodology incorporating electronic, mechanical, hydraulic and design for manufacturing considerations. Simulation, code generation, optimization and fast prototyping tools are now more commonly used in order to reduce time to market, generate more highly integrated designs, reduce costs and increase reliability. 

The modern automotive microcontroller must now be supported early in the cycle with software models that can be integrated into simulation environments. A conventional system design is illustrated in Figure 8.

Figure 8 - Conventional system design

The conventional system design process starts with abstracting a software and hardware specification from the systems specification. Both hardware and software are developed independently and are then integrated and tested/debugged. If a functional problem exists at this stage (as it often does), it is usually very difficult to redesign hardware, so it is most common that software fixes are developed as far as possible. The main problem with this methodology is that both the hardware and the software are being debugged at the same time, thus it is more difficult to determine the source of faults. It is estimated that over 50% of the entire development cycle is spent at this stage.

Often, a new microcontroller design is undertaken as part of the 'develop hardware' effort. This design will usually take an existing CPU and existing peripheral functions (i.e. timers, serial communications, etc.) and integrate these together with the required memory arrays for the particular system. These memory arrays are based on the estimated software size, which is being developed independently, so are rarely efficient. Quite often, a new 'custom' peripheral is also developed for integration with the microcontroller. This could be a 'knock' detect module for a powertrain system or a wheel speed interface for an ABS system.

In order to resolve the problems of optimizing a systems design, new software-based toolsets have been developed which allow alternative implementations to be evaluated rapidly. The new approach allows trade-offs to be made quickly and an efficient design to be generated with confidence that little or no problems will surface later. The new systems design process that is being adopted is illustrated in Figure 9.

Figure 9 - Modern systems design methodology

The control algorithm development is now usually a model-based operation. The algorithm is simulated on a workstation in an environment that simulates the behavior of the physical system. The algorithm can be tweaked and simulated in the model on an iterative basis until the algorithm development has been completed. The control algorithm model, usually mathematically based, is then processed using an Automatic Code Generation (ACG) tool that will provide a High Level Language file representative of the control strategy. This High Level Language can be compiled to run on any execution unit based system (such as a microcontroller). In order to verify the code, it is tested in a hardware environment by downloading the code to a rapid prototyping board, usually a very powerful array of processors/DSPs. The rapid prototyping board is connected to a hardware environment of inputs (sensors, serial communications links) and outputs (actuators) in order to verify the operation of the control algorithm. After the model-based algorithm development is complete, it is time to partition the hardware and software.

Software tools are again used at the partitioning stage to simulate the system operating with different configurations of software and hardware. The goal is to understand the trade-offs involved in implementing different functions as either software routines or as a dedicated hardware block. For example, a routine that constantly services certain low-level interrupts which occur very frequently might best be implemented as an autonomous (or 'smart') peripheral on a microcontroller. The algorithm is run on a model of a CPU and peripheral modules can also be implemented as behavioral models.

The outcome of the hardware/software co-design stage is to determine the final specification for the hardware. In the most part, the software will already exist and have been verified at this stage. The hardware requirements that are identified at this stage will be optimized to meet exactly the system requirements and a new microcontroller can be developed which suit the specification exactly. It is estimated that the overall development time required using the model-based development methodology can be around half of the time required for the conventional systems design methodology.

The impact on the microcontroller is that that there will be a requirement for quality software models of not only the CPU but of the peripheral modules, which could be used in the system. The models will be required very early in the design cycle and its likely that there will be many different types of models required for use with different toolsets (i.e. Verilog, VHDL, C++). These models will someday be regarded as essential to the design process as a databook is considered today. 

Advanced automotive microcontrollers
Probably the best example of a 'next generation' modern automotive microcontroller is the MPC555, which was designed for powertrain control and Intelligent Transportation Systems (ITS) applications. A block diagram of the MPC555 is shown in Figure 10.

Figure 10 - MPC555