For the PDF version of this article, click here.
The market for in-vehicle communications network technology looks neat and tidy — from a distance. Controller area network (CAN) handles most of the heavy lifting. Local interconnect network (LIN) provides a lower-cost, lower-speed complement for door locks, windows, seat adjustments and the like. While media-oriented systems transport (MOST) and intelligent transportation systems data buses using IEEE1394 Firewire (IDB-1394) divvy up audio and video requirements, FlexRay is waiting in the wings to handle X-by-wire requirements.
From a ground-level perspective, however, the market is far more complex. “It was true 10 years ago and it's still true today, even with CAN, that each OEM has its own particular set of networking requirements,” said Paul Fox, director of marketing for the automotive business unit at Renesas Technology America Inc. He cited as just two examples General Motors' use of single-wire (vs. two-wire) CAN, and Ford's CAN-based FNOS vehicle network operating system software. “The challenge for Tier One, but also for Tier Two,” said Fox, “is how to make products that meet everyone's requirements.”
Fox noted that GM's version of CAN incorporates features beyond those called for in other CAN implementations. “The biggest in-vehicle network challenge, in terms of time, money and complexity, is coordinating implementation among OEMs, Tier Ones and Tier Twos,” he said. “(As a semiconductor manufacturer) We've got to look up the food chain for the OEM to drive the basic requirements; to give us a subsystem design specification (SDS), from which we can get drivers written.”
A study released in January by the research firm Frost & Sullivan noted that in-vehicle network architectures and associated protocols are “generating considerable excitement” in the automotive industry. Point-to-point wiring is largely being replaced by bus systems, according to program manager Franck Leveque, and since the adoption of CAN in the early 1990s a multitude of protocols have been developed, most of them in Europe.
Leveque predicted a compound annual growth rate of 37% through 2010 for high-speed/safety networks including FlexRay, which he estimated would launch in 2007. Despite the potential for competition from time-triggered protocol (TTP), Leveque believes that FlexRay is likely to emerge as the dominant protocol in the category. On the multimedia side, he expects Firewire to dominate, although like FlexRay, it isn't expected to surface for automotive applications much before 2007.
“While CAN is the prevailing industry standard and has been adopted by almost all vehicle manufacturers, standardization efforts are now under way for other protocols such as LIN or MOST,” said Leveque. In fact, the LIN protocol was developed in the late 1990s and since then has been widely deployed in the Americas, Europe and Asia.
He cautioned vehicle manufacturers to collaborate with suppliers on interfaces in order to develop communication protocols and subsequent applications in a commercially viable manner. “[Manufacturers] must also work toward standardization. Standardizing interfaces between various devices and the basic in-vehicle network architecture would provide vehicle manufacturers and suppliers with a cost-effective way of implementing electronics in cars. However, in order to differentiate themselves and their products, we recommend that vehicle manufacturers must further focus on competing on applications.”
A report from ABI Research (Oyster Bay, NY), “In-vehicle Networking,” finds “significant momentum” among OEMs migrating from proprietary standards to CAN, LIN, FlexRay, MOST and IEEE 1394. “There is strong international will to establish standards,” noted ABI Automotive analyst Dan Benjamin. “The benefits are clear: automakers can draw from a ‘global parts bin,’ suppliers aren't tied to one customer, costs are lowered, and developers' skills are better focused.”Japanese automakers entered the standards arena last fall via Japan Automotive Software Platform and Architecture (JASPAR), formed by Toyota and Nissan, and later joined by Honda. JASPAR is “a significant departure” for Japanese OEMs who were slow to climb on the FlexRay bandwagon, according to Benjamin. Products based on the JASPAR consortium's efforts aren't likely to appear until 2009.
“Ten or more years ago there were a variety of possible protocols. Everyone had one, and the carmakers were all independent, with no reason to talk to each other,” recalled Jörg-Michael Schneider, Global System marketing manager, GMS Automotive, at Royal Philips Electronics.
“Philips, along with Bosch and Daimler Chrysler, decided to cooperate in promoting CAN, and we were able to put silicon on the table early enough and provide broad enough volume to enable CAN to become the de facto global standard for automotive networking. But that didn't happen without a struggle that proved to be very costly.”
Virtually every semiconductor manufacturer offers devices with at least one CAN interface. Fujitsu Microelectronics America Inc. recently introduced a 32-bit MB912xx series microcontroller based on a core 32-bit RISC CPU from the firm's FR60 Lite series. It features a CAN interface in addition to three 10-bit analog-to-digital converters (ADCs) and a microDSP (Figure 1).
Keith Horn, vice president of marketing at Fujitsu Microelectronics America, said CAN is “a vital capability” for automotive applications. “The CAN bus and microDSP combination suits the MP912xx for networking intelligent devices and also sensors and actuators in a system.”
Renesas Technology America recently introduced six 16-bit M16C/29 group MCUs with flash memory, peripherals, and a CAN 2.0B interface circuit (Figure 2). Available in 64-pin (10 mm × 10 mm) or 80-pin (12 mm × 12 mm) LQFPs, with 128 Kbytes, 96 Kbytes or 64 Kbytes of on-chip flash and up to 12 Kbytes of RAM, the MCUs target automotive and other applications that control three-phase or single-phase AC motors.
Similarly, ON Semiconductor introduced a CAN transceiver as well as three LIN transceivers, and ESD/EMI protector chips for both buses. The NCV7356 single-wire CAN transceiver meets the GMW 3089 2.3 specification and provides undervoltage lockout, timeout for faulty blocked input signals, output blanking time in case of bus ringing, and a low sleep mode current, according to Sri Jandhyala, ON Semiconductor's director of automotive market development. It comes in a 14-lead SOIC fused package. An eight-lead SOIC fused package is in development.
The NCV7380 is a LIN physical layer device for ECU applications with hard standby current requirements, where no sleep/wake up control from the microprocessor is necessary, or for single-wire data link applications that don't require high-speed data rates. Designed according to the physical layer definition of the LIN protocol specification (rev. 1.3 and 2.0) the part comes in an eight-lead SOIC and is said to offer low current consumption. The NCV7382, otherwise identical, includes a wake-up function to detect incoming dominant bus messages and to enable the module voltage regulator.
The NCV7361A is a 5 V/50 mA voltage regulator with an integrated LIN transceiver. Designers can use it to develop simple, yet powerful LIN bus slave nodes that offer wake-up via the LIN bus.
ON Semi's NUP2105L and NUP1105L are 27 V dual, bidirectional transient voltage suppressors (TVS) designed to protect CAN and LIN transceivers, respectively, from EMI and ESD. Mamoon Rashid, director of marketing for small signal products, said the parts are among the only such devices to offer an integrated solution for dual wire data line protection based on an avalanche TVS technology. The bidirectional configuration prevents inadvertent clamping of normal data line signals due to common mode voltage offset in systems with long cable lengths. Both devices come in SOT-23 packages.
Texas Instruments offers the TPIC1021, a LIN 2.0 transceiver with electrostatic discharge (ESD) protection up to 17 kV IEC and 12 kV human body model, or about twice that of competing devices, according to the company. It's said to survive ISO 7637 transients and to offer fault protection for -40 V to 40 V on the LIN bus (Figure 3). It can be used with resistance-capacitance (RC) oscillator-based MCU systems at speeds of up to 20 kbps in next-generation of LIN-based automotive body applications such as door modules, window lifters, seat controls, intelligent sensors and intelligent actuators.
Bernd Rucha heads Freescale Semiconductor's Munich-based Computing-in-the-Car laboratory. He is responsible for Freescale's R&D projects in the automotive sector, and since 2000 has also chaired the LIN Consortium.
Founding members of the LIN Consortium at the time of its launch five years ago were Audi AG, BMW AG, DaimlerChrysler AG, Volvo Car Corporation AB, and Volkswagen AG; communications specialist Volcano Communications Technologies AB (VCT), and Motorola Semiconductor Products Sector (now Freescale Semiconductor). Today, the Consortium has more than 50 members, including OEMs, Tier One suppliers, semiconductor vendors, tool suppliers and test houses.
“The firms set out to define and implement an open standard for class A serial buses in hierarchical vehicle networks; essentially a lower-cost alternative to CAN, where the data-handling capacity and speed of CAN — up to 1 Mbps compared with 20 kbps for LIN — was not needed and the cost of CAN — approximately twice the cost of LIN — was not justifiable,” explained Rucha.
“LIN is sufficiently cost-sensitive to enable the introduction of mechatronic elements, such as smart sensors and actuators that can be connected easily to the car network and made available to various types of diagnostics and services.”
Applications suitable for a LIN bus, according to Rucha, include stepper motors in HVAC systems and light control, dc motors for wipers, power windows, and seats, central locking modules, outside and inside rear view mirror (positioning), switch sampling (e.g. in the steering wheel and at the doors), various sensors for engine (engine monitoring) and vehicle environment (e.g. rain sensor), and auxiliary heaters and preheaters.
Before LIN was developed, automakers used a variety of low-end serial communication systems accompanied by proprietary toolsets and software drivers. Standardization on a single protocol reduced the costs of development, production, service and logistics in vehicle electronics,” according to Rucha.
“A sufficient number of standards existed to jump-start the development of LIN; for example, the UART/SCI concept, K-Line diagnostics, and an API,” Rucha noted. “These and other building blocks were available during development, and participants generally agreed among themselves about the protocol's features and specifications. Developers applied lessons learned from earlier protocol development efforts in which the focus was mainly on hardware, with development tools coming later.”
Semiconductor firms are currently focused on integrating LIN transceivers and controllers, especially for applications able to benefit from smart slaves. The integration is increasingly application-specific. OEMs want LIN solutions that can be deployed across their entire product line. Application-specific LIN devices include Freescale's MM908E624 triple hi-side switch with embedded MCU, designed for the control of automotive high-current motor applications using relays (e.g., window lifts, fans and sun roofs), and the MM908E625 quad half H-bridge, for the control of automotive mirror, door lock, and light-leveling applications.
“In the late 1990s there was a need for a high-speed, in-vehicle bus for transferring audio and video — CD, DVD, navigation — to reduce the number of cable runs,” noted Andrew Poliak, automotive business manager at QNX Software Systems, Ottawa Ontario, which offers a MOST driver. The MOST network was created by many of the automotive manufacturers and vendors developing telematics solutions, including Audi, BMW, DaimlerChrysler, Harman/Becker, Motorola, Oasis Silicon Systems, Johnson Controls, and Delphi-Delco.
“The 1394 protocol has higher bandwidth, but presents a few issues,” said Poliak. “They didn't get the IDB spec ratified until less than a year ago, and they missed a window.”
“MOST has a capacity of only about 25 Mbps, which is suitable for audio, and one compressed video stream, but there's cost involved in compression,” countered Jason Cole, U.S. automotive business development manager in Texas Instruments' Mixed Signal Automotive Group (Dallas). “MOST doesn't have copy protection built in, and MOST can't work over copper. It's not a cost-effective solution,” he added.
“Just as with consumer electronics for the home, 1394 is well suited for moving audio and video within a vehicle. Some are also using it for telemetry in collision avoidance or other intelligent transportation system (ITS) applications. Currently available 1394 chips can be used for in-vehicle applications. We're introducing industrial-grade products and looking at others. It's possible for MOST and 1394 to coexist within a vehicle, with a gateway between the two,” noted Cole.
Henry Muyshondt, who works for Oasis Silicon Systems but is also technology coordinator for the MOST cooporation, which manages the MOST spec, said MOST is currently being implemented on some 30 vehicles. Only one automaker has shown interest in 1394. And while MOST currently operates at 25 Mbps, the next generation will offer 50 Mbps and 150 Mbps operation.
According to QNX's Poliak, “The biggest trend is not that one bus will win, but that mini gateways will be created that provide access to CAN, XM, Bluetooth and more.”
FlexRay is the “hottest” protocol being discussed, according to Jim Trent, general manager of the automotive business unit at NEC Electronics America. “After two years of debate, (FlexRay) looks like the choice for high-speed, deterministic fault-tolerant applications (Figure 4), but TT-CAN will also be used a lot, especially in engine control applications. We're offering TT-CAN with the latest CAN peripherals, and will also offer FlexRay.
Trent conceded that FlexRay is “behind where customers need it to be. “It took way too long, with three OEMs and global standards, for everyone to come to agreement. Combining all of the specs into one protocol was difficult, and the initial silicon didn't have every bell and whistle.” Nevertheless, the push toward automotive communications standards continues.
ABOUT THE AUTHOR
Formerly senior editor of an electronics industry trade publication, John Day writes regularly about automotive electronics and other technology topics. He holds a BA degree in liberal arts from Northeastern University and an MA degree in Journalism from Penn State. He is based in Michigan and can be reached by e-mail at [email protected].