Flexible microcontroller architectures handle modern automotive powertrain applications.
By Richard Soja
Edited by Miles Budimir
It's no secret that automotive powertrain systems are growing in complexity. Factors contributing to the trend include ever more stringent legislative requirements and a need to deliver ever more sophisticated features. These trends have forced semiconductor manufacturers who supply the automotive industry to rethink the fundamental structure of the powertrain-controller unit (PCU).
It is interesting to examine some of the ways controller architectures and ancillary electronics are evolving to meet modern vehicle needs. One example is in-vehicle networking. The main motivation behind networking the vehicle was to cut the cost and weight of wiring. Before the introduction of multiplexed networks, a luxury vehicle could easily carry over 1 mile of insulated wiring and over 2,000 terminals. Besides being expensive and heavy, wiring systems were also a source of reliability issues.
North American auto manufacturers currently use a mix of networking protocols to satisfy similar but subtly different needs. There is J1850 (DaimlerChrysler), GMLAN and GM Class 2 (GM), SCP and UBP (Ford), J1587, and J1939. European serial protocols include CAN, ISO9141 and Keyword 2000. North America is poised to accept the use of CAN.
One of the most interesting trends in vehicle networking is the need to support fault tolerance, especially in safety-sensitive systems, such as by-wire control where a networked command on a wire replaces conventional mechanical control of an actuator or switch. Existing protocols are generally event-triggered which means that a message is sent only when something changes. A system with multiple unpredictable events (which typifies realtime applications) will cause an uncertainty in the timing of transmitted messages. This uncertainty, coupled with a lack of fault-tolerance, makes those protocols unsuitable for by-wire needs. New fault-tolerance time-triggered protocols are being developed to overcome the problem and provide greater reliability and operational certainty. Examples of these are TTP/C and FlexRay.
Semiconductor manufacturers have to respond to such needs by devising microcontroller units (MCU) with architectures flexible enough to handle a diverse set of needs. But the shrinking chip geometries of these devices has brought up another issue: As device size drops, the core voltage must go down. Interfacing the core to external devices requires use of level-shifting circuits. These are costly because of the additional steps needed to get the higher voltage. To keep costs down, semiconductor makers would ideally like to avoid such measures. But the designer of the electronic module in which the MCU sits would ideally like to use 8 V to better handle sensors and actuators. Current MCUs don't support voltage this high, so designers have reluctantly accepted 5 V for sensor and actuator interfaces.
However, there is already a trend to provide interfaces at a lower voltage to support memory devices, communication chips, and some ASICs. The general trend is currently to a 3.3, 2.6 or 2.5-V interface. But change is slow because module makers have sunk a lot of effort into their existing designs and are reluctant to change. In some technologies, it's possible to get 5-V interfaces with little or no added cost because they are a by-product of some other feature such as on-chip flash memory.
However, it is more difficult to devise a 5-V interface for analog-to-digital converters (ADC) used extensively throughout most vehicle modules. The problem is that ADCs don't scale as well as digital circuits. This is because the bias currents and component matching needed to fix the highly accurate measurements and conversion process are a function of component physical dimensions. It might be possible to get 12-bit ADC resolution in a 0.13-micron process, but not at a cost automakers are willing to pay. All in all, it could be awhile before analog component geometries make such a device cost effective.
Another trend is the move towards more complex software algorithms. The traditional lookup-table approach is gradually giving way to models or algorithms that provide better adaptive control over a wider range of input conditions. For example, an algorithm can detect a misfire over a larger range of engine speed and load, or compensate for wear on certain mechanical components or sensors over the lifetime of the vehicle.
These features and many more are part of fulfilling the OBD and EURO emissions requirements in the next few years. Modeling techniques may also involve autocoding, where code is generated by the tool. There are already many such tools available today, and their use is growing steadily. Model-based design tools can also help systematically find optimal calibrations.
Complex modeling and the overhead associated with autocoding are only practical with powerful CPUs. The size of the average controls program has risen over the last 10 years because of factors such as programming in C instead of assembly language, adding support for OBDII and EUROIII diagnostics, and catalytic converter and fuel evaporation monitoring.
Modeling often requires filters. One type that is being considered for powertrain control is the Kalman filter. Its main attribute is its ability to estimate the state of a system using measurements that contain random errors. Applied to powertrain control, it can provide estimations of exhaust pollutants and required corrections to the air-fuel mixture. The processing power needed to implement a Kalman filter increases dramatically as the number of measurements increases. For example, doubling the filter inputs from two to four increases the number of multiplications from 86 to 640, and additions from 55 to 480.
Microcontroller manufacturers are continually developing cores to keep up with rising demands. The recently announced Motorola MPC5500 family of MCUs will use the e500 core to perform complex algorithms using multiple parallel execution units. In addition to providing floating-point capability, one of the execution units (the SPU, or signal processing unit) in the e500 core has digital-signal-processing capability. As well as being able to perform operations on two data paths in parallel using SIMD instructions, it can execute multiply-and-accumulate, fractional, and bit-reversed addressing.
Using the SPU opens the door to newer, more powerful algorithms. For example, a knock and misfire algorithm can be implemented as a 256-point complex 32-bit FFT, using 5,000 clock cycles. Using a 200-MHz clock speed equates to 25 µsec of total CPU time, a mere 0.7% of total CPU bandwidth. Such low CPU usage now lets the design engineer replace the off-chip knock processing hardware with software, saving the cost of a component. It is also one less custom chip for the module manufacturer to stock.
Though the core runs at 200 MHz over typical automotive temperature ranges, the main memory presents a bottleneck because of its longer data paths and need for sense amplifiers. The e500 core circumvents these problems by making use of tightly coupled instruction and data caches, which prevent stalling of the core's instruction pipeline. The software developer may also use the cache like static RAM by locking specific code sequences or data blocks into cache lines. This makes code execute faster and more deterministically.
One concern with real-time systems is interrupt response time. The e500 is a PowerPC-compatible core with less than 100-nsec response to real-time interrupts. In addition, special registers and instructions ease overhead normally associated with interrupts and context switching. Another performance enhancer is a split transaction bus. It reads data without holding up the address or data buses. This lets the core access other high-speed devices attached to the same bus without waiting for a slow device to complete its transaction.
The real-time nature of controlling actuators in a vehicle powertrain system requires a different type of performance. Real-world events such as delivering signals to initiate a spark and inject fuel into cylinders calls for submicrosecond accuracy and response to changing operating parameters in the engine within a few tens of microseconds. The timer system needed to support such performance generally requires a different architecture than the core. For instance, a hardware state machine or simple code sequencer can synthesize the high-data-rate timed output and input functions needed to drive fuel injectors, transmission actuators, and decode camshaft and crankshaft timing signals. The lack of flexibility of this approach is overcome in the MPC5500 family by using an autonomous module that executes a special instruction language, and is tightly coupled to its timer hardware system. The large number of concurrent data and control paths of this module minimizes the latency in response to real-time events.
For semiconductor manufacturers who deal with the automotive industry, these changes have several important consequences. In the near future, low-voltage, high-speed memory interface buses will run in excess of 200 MHz at ambient temperatures of 125°C. Unfortunately, cost and reliability issues prevent the use of CPU cooling fans. Sensor and actuator interfaces will support standard 5-V levels, and in some cases the 42-V bus. Flash-programmable memories of 2 Mbytes will be needed to store the large, complex programs.
To ease development, powerful software and hardware tools are essential. In most cases, these tools will be identical in look and feel to today's tools. In some cases, new skills will be required to maximize the use of performance enhancing on-chip components such as operating system hardware accelerators, instruction and data caches, and programmable subsystem modules that provide networking, sensor, and actuator interfaces to the external world.