With the average new vehicle containing 50 to 100 or more electronic control units (ECUs)—requiring as much as a mile of wire to connect them over several different networks—it’s no wonder that semiconductor firms are competing fiercely for a place in your car.
In the powertrain there are separate control systems for fuel injection, ignition, throttle, cooling, automatic transmission, and on-board diagnostics. There are chassis control systems for power steering, brakes, and airbags. Advanced Driver Assistance Systems (ADAS) involve four separate MCUs. There are separate body control systems for headlights, wipers, power doors, power windows, and HVAC.
In addition to technical complexity there are serious technical and regulatory barriers to entry. There are scores of separate Society of Automotive Engineers (SAE) standards for electronics involved in engine control, driver assistance, drive train monitoring, passenger comfort, infotainment, and more. Any MCU that is “automotive qualified” is guaranteed to meet some pretty high standards, after which the choice depends primarily on the application.
Getting the MOST out of vehicle networking
Just as the poet observed that “no man is an island,” neither is there an isolated MCU in a car; all are part of one network or another, depending on their function. The primary networks are CAN, LIN, FlexRay, MOST, and Ethernet AVB (Figure 1).
The Controller Area Network (CAN) is currently the primary automotive network in the cabin, powertrain, chassis, and body systems.
- Active Safety CAN might control millimeter-wave radar, which can sense an oncoming vehicle and initiate a warning sound, braking, and even steering control.
- Car instrumentation, responding to a warning from radar over the CAN bus, could initiate a warning, whether by a sonic alert, spoken warning, and/or a heads-up display.
- Reacting to a warning from radar the Brake Control CAN might initiate weak or strong brake control, depending on wheel speed and the proximity of another car.
- Also reacting to warning of a possible crash, an MCU connected to seatbelts could pre-tension the belts; lightly at first but strongly if the crash looked imminent.
Figure 1: Vehicle networks (Courtesy of Renesas).
The Local Interconnect network (LIN) is a low-data-rate master/slave network that controls things like remote keyless entry, lighting, mirrors, and doors. Via the LIN network the doors may automatically lock when the car starts moving; an alarm sounds when seatbelts are not fastened or the car is turned off when the lights are still on; or the rearview mirror and seats automatically re-adjust to previous settings depending on who is driving the car.
In contrast to LIN, FlexRay is a high-speed, reliable protocol for next-generation application such as drive-by-wire. FlexRay systems provide greater accuracy in response to proximity alerts, adding the ability to consider acceleration angle to actively steer and brake a car to avoid a pending collision. This can be especially useful when a braking car starts to skid and slide on a rain-slicked street.
The Media Oriented Systems Transport (MOST) networks handle in-car multimedia, routing high-quality video, audio, and data within the vehicle. They are responsible for hands-free phone calls and playing your cell phone music over the car sound system.
Ethernet is too well established and trusted not to have made it into the car, where it generally provides the backbone for polling ECUs in the engine, chassis, and body systems for faults. Ethernet Audio Video Bridging (AVB) competes with MOST to provide high-fidelity digital audio to passengers.
In choosing between MCUs that are qualified for automotive applications, a glance at their datasheets will often reveal for which applications they are best suited. One or more CAN ports are common, as are Ethernet ports; though Ethernet AVB (IEEE 802.1Q) is harder to come by. FlexRay and MOST networks require MCUs that can handle high-speed packet processing; LIN is far simpler. These latter protocols are not often supported directly, though as long as the hardware is sufficiently capable this should not present a problem.
The Renesas V850ES/JG-3H
is a low-power 48 MHz 32-bit RISC MCU developed for real-time control applications. The original NEC V850 has a long history in automotive applications, for which Renesas has further refined it. V850ES peripherals include DMA, LVD, PWM, WDT, A/D converter, D/A converter, and DMA, CAN, and USB controllers. The V850ES CPU executes almost all instructions such as address calculation, arithmetic, and logical operations and data transfer in one clock by using a five-stage pipeline. In automotive applications the V850ES targets engine control and antilock braking systems.
Freescale makes a wide range of MCUs for use in automotive power train, chassis, advanced driver assistance, body, instrument cluster, and infotainment applications. The Freescale Qorivva MPC5554
(Figure 2) is a 132 MHz 32-bit MCU designed for powertrain applications including multipoint fuel injection control, electronically controlled transmissions, and direct fuel injection (gas and diesel). In addition to numerous high-speed I/O channels, the chip includes three CAN modules with 64 buffers each. Non-automotive application areas include industrial control, high-end motor control, avionics, and military components.
Figure 2: Freescale MPC 5554 for powertrain applications (Courtesy of Freescale).
The Microchip MCP2561 and MCP2021A
are CAN and LIN transceivers, respectively. The MCP2661
is a high-speed CAN transceiver that serves as an interface between a CAN protocol controller and the physical two-wire CAN bus. The device meets the automotive requirements for high-speed (up to 1 Mb/s), low quiescent current (5 μA typical), electromagnetic compatibility (EMC), and electrostatic discharge (ESD).
is a LIN transceiver with voltage regulator. The MCP2021A
/2A provides a bidirectional, half-duplex communication physical interface to meet the LIN bus specification Revision 2.1 and SAE J2602-2. The device incorporates a voltage regulator with 5 V or 3.3 V 70 mA regulated power supply output.
The Atmel AT90CAN32
is a 16 MHz 8-bit MCU based on the AVR RISC architecture. The chip combines 32 KB of Flash memory, 2K x 8 of RAM, an 8-channel/10-bit A/D converter, a byte-oriented two-wire serial interface, and an ISO 16484-certified CAN controller. By executing most instructions in a single clock cycle the device achieves throughputs approaching 1 MIPS per MHz, balancing power consumption and processing speed. The AT90CAN32
meets the requirements of ISO-TS-16949 Grade 1 for automotive use and is AEC-Q100 qualified.
The STMicroelectronics SPC564A80L7CFAR
is a 150 MHz 32-bit MCU designed for automotive powertrain applications. The chip’s superscalar SIMD architecture and support for DSP and floating point instructions enables high-speed data processing and throughput. Serial channels include three eSCI; three DSPI; three FlexCAN with 64 messages each; and one FlexRAY module with up to 10 Mbps with dual single-channel and 128 message objects with ECC.
The Silicon Labs C8051F530A
is a 25 MHz C8051 MCU designed for LIN networks. It includes a programmable 12-bit 200 ksps ADC; programmable 16-bit counter/timer array; and hardware SPI and UART serial ports. The C8051F530A
covers a temperature range of -40 to +125°C and is AEC-Q100 qualified.
The Texas Instruments TMS570LS31370
is a high-performance automotive-grade MCU designed for safety-critical applications. Its 180 MHz ARM Cortex-R4F 32-bit RISC CPU uses an eight-stage pipeline to achieve 1.66 DMIPS/MHz. Of particular interest to automotive designers, the chip includes three CAN controllers (64 mailboxes); a FlexRay controller with two channels and a dedicated transfer unit; a LIN interface controller; a 10/100 Mbps Ethernet MAC; plus SCI, I²C, SPI (2), and three multi-buffered serial peripheral interfaces (MibSPI). Target automotive applications include braking systems, power steering, active driver assistance, and HEV/EV inverter and battery management systems.
While the automotive semiconductor market is large and growing fast, getting an MCU qualified to operate in this demanding environment can be a challenging process, with the stringency of the requirements depending on how critical the application will be. After noting that an MCU you are considering is automotive qualified, see if it directly supports the networks to which it will be connected. If not, ensure that it has sufficient speed, communication ability, and I/Os to handle the application you have in mind.
Designers of devices intended for other challenging environments would do well to consider using MCUs that have been qualified for the harsh environmental conditions typical of automotive applications.
For more information on the MCUs discussed in this article, use the links provided to access product pages on the Hotenda website.