A quiet revolution is sweeping through automotive in-vehicle, vehicle-to-vehicle, and vehicleto- infrastructure communications and networking. Companies as well as standards organizations continue to successfully tackle major design challenges, such as the adoption of hardware and software approaches to meet demanding bandwidth, fault-tolerance, determinism, and reliability requirements.
In fact, there’s marked improvement among a number of communications and control protocols, both hardware and software. These include FlexRay, Controller Area Network (CAN), the Japan Automotive Software Program ARchitecture (JASPAR), the Local Interconnect Network (LIN), the Society of Automotive Engineers (SAE) J1850, the AUTomotive Open System ARchitecture (AUTOSAR), the Media-Oriented Systems Transport (MOST), and the FireWire (1394) standard. The MOST protocol is finding its way into more automotive infotainment systems, mainly in European cars (see “The Line Between Telematics And Infotainment Blurs Even Further”). It isn’t on the road yet, but Toyota is using a 25-Mbyte/s version of MOST in its Prius. Release of the MOST specification Rev. 3 for 150-Mbit/s networks is expected soon.
As for body, powertrain, chassis, and other controls, no one protocol and architecture can be considered as a “one size fits all” solution. Quite often, combinations and refinements of these approaches prove valuable in providing flexibility and meeting automotive control and communications needs. For example, JASPAR was recently adopted for the upcoming version of FlexRay targeting next-generation in-car networks. The FlexRay Consortium will incorporate a JASPAR technical proposal in the main modification points of FlexRay’s Protocol Specification V3.0 and the Physical Layer Specification V3.0, to be released in the 2009/2010 timeframe.
FlexRay continues to serve as a major backbone for automotive applications (Fig. 1). German and Japanese OEMs decided to adopt FlexRay in their car networks. In fact, the first vehicles to commercially use the FlexRay protocol are BMW’s flagship X5 sport utility vehicles (SUVs) and its 7 series of cars.
FlexRay defines a dual-channel 10-Mbit/s data structure. Each channel can be used to implement a redundancy mechanism in a standalone manner, for an aggregate data rate of 20 Mbits/s.
Core members of the FlexRay Consortium (BMW, General Motors, Volkswagen, Daimler-Chrysler, Bosch, Freescale Semiconductor, and NXP Semiconductor) expect FlexRay to become the standard for advanced powertrain, chassis, and x-by-wire automotive systems, even though it presently costs more than the widely used 1-Mbit/s CAN protocol. Most members feel FlexRay will integrate with other protocols rather than replace them.
“FlexRay was originally designed for fault tolerance and redundancy. Now it is also being used for bandwidth where greater bandwidth can be achieved with other networks like CAN,” says Jens Eltze, principal technical application engineer for NEC Electronics America’s Automotive Strategic Business Unit.
“There’s a natural reluctance on the part of some automakers to adopt a standard based on a new technology like FlexRay, FireWire, etc. They don’t want to take a chance that it may or may not succeed until others join in,” says Dave Stone, marketing manager for NEC Electronics America’s Automotive Strategic Business Unit.
BRIDGING THE GAP Some IC chip manufacturers are trying to narrow the costdifferential margin between FlexRay and CAN. Austria Microsystems (AMS) and TTTech Automotive are joining forces to develop lower-cost FlexRay transceiver devices. They plan to intensify their R&D efforts to create FlexRay automotive networking nodes.The goal of the joint effort is to improve the reliability of invehicle data communication and reduce costs. For instance, optimized FlexRay topologies could integrate a larger number of nodes. In addition, the companies designed a bit re-shaper circuit that will let automotive OEMs and tier 1 suppliers reduce cabling costs by using less costly wiring types. Both companies also plan to collaborate in creating test processes for the FlexRay chips.
“The price of FlexRay chips will come down to mitigate the large cost differential between FlexRay and CAN implementations,” says Toni Versluij, senior director and general manager in the Business Line Automotive Safety & Comfort Unit at NXP Semiconductors.
NXP introduced the first FlexRay transceiver IC, the TJA 1080A, in 2006. The TJA1081 and TFA1082 node transceivers soon followed (Fig. 2). There’s also the TJA1085 active star coupler. NXP has shipped 1 million FlexRay transceivers that comply with the physical layer. The company has been a supplier of FlexRay chips, as well as CAN and LIN, for over a decade.
“CAN will be the choice for automotive networking nodes over the next decade,” says Versluij (Fig. 3). He points out that although FlexRay with its dual channels was originally designed for x-by-wire applications needing redundancy, the vast majority of automotive applications uses a single-channel topology that CAN is able to handle. CAN works with the SAE’s J1850 bus, which is widely used for on-board diagnostics (OBD) II.
Versluij also notes that at the component level, FlexRay costs more than CAN to implement. Not so at the systems level, though. Serg Leef, general manager of Mentor Graphics’ Systems Engineering Division, concurs.
“CAN has bandwidth and reliability limitations. Users tend to compensate for this by designing networks that use only a limited portion of total bandwidth to increase the likelihood that messages will arrive in a sufficiently timely manner, which diminishes CAN’s price/performance ratio,” says Leef.
Continue to page 2
IC manufacturers like NEC Electronics America continue to upgrade their automotive product lines in terms of smart sensors and advanced controllers to support all popular automotive networks like FlexRay, CAN, LIN, MOST, USB, and Ethernet. Texas Instruments also supplies ICs for FlexRay, CAN, and LIN.
“We provide standard cells and cores for these networks that go into transceivers,” says Scott Monroe, systems engineer at Texas Instruments’ analog/mixed-signal group. He indicates that while there’s a large increase in the use of CAN in cars, “you try to separate those CAN nodes that are less time-critical from those that are safety-critical.”
Microprocessor control units (MCUs) are also being used in greater numbers in FlexRay networks. One of the latest examples, the Freescale Semiconductor S12XF MCU, includes integrated FlexRay technology. Adura Systems opted for this IC in its Modular Electric Scalable Architecture (MESA) powertrain, which offers up to 100 miles of pure electric-vehicle drive technology.
The greater number of MCUs used in a vehicle—often acting as electronic control units (ECUs)—poses a potential problem. Not only does it increase costs, but the plethora of control functions they provide ratchets up the complexity. The trend is to employ modular control units, each controlling a specific subset of automotive functions within a car’s network.
Designers are now attempting to slim a car’s typical 35 to 40 MCUs (up to 100 in some cases) down to about 20 to 25 units that pack the same functionality. Nevertheless, for some advanced designs with many ECUs, CAN may be reaching its limits.
The need for a high level of determinism and real-time response is critical for automobiles. Results obtained by the National Institute of Technology (NIST) in 2007 from tests on two automotive collision-warning systems underscore this point. According to NIST, both systems passed most but not all of the 3D performance tests.
Warning-system problems occurred in detecting whether or not forward-moving vehicles were in-lane or out-of-lane on curves or during lane changes. NIST says that automotive collision-warning systems must operate in real time at highway speeds and use multiple low-cost sensors to measure complex 3D scenes.
A CORNUCOPIA OF CAN
There are many versions of CAN, a protocol that traces back to 1994 for use in cars. The three most popular versions are fault-tolerant CAN (FT-CAN), highspeed CAN (HS-CAN), and single-wire CAN (SW-CAN). All are used in auto-body control functions for the doors, roof, dashboard, climate control, and other areas. HSCAN also finds homes in powertrain applications, including the engine, transmission and gearbox, and anti-locking braking systems (ABSs).
Another variation is time-triggered CAN (TT-CAN). Robert Bosch LLC demonstrated low-cost TT-CAN systems that deliver roughly twice the bandwidth of CAN. However, many are skeptical about TT-CAN, mainly due to its length limitations. Bandwidth is kept to 1 Mbit/s at up to 40 m, limiting it for use in short-distance applications.
“When you cut down the niceties of the CAN protocol by using it in longer line lengths, then it is not CAN,” says Wolfhard Lawrence, one of the original developers of the CAN protocol and CEO of C&S Group, which specializes in testing automotive software, systems, and networks.
Large and variable jitter is a liability in the CAN protocol. To make TT-CAN more predictable and dependable, researchers Juan R. Pimentel of Kettering University and Jason Paskvan of Mentor Graphics performed various experiments designed to characterize jitter in an actual CAN-based communication architecture. They came up with a more deterministic FlexCAN, a topology for x-bywire applications, without compromising flexibility (Fig. 4).
LOCATING THE SWEET SPOT B. Perry Compton at tier 1 supplier Delphi Corp. has proposed a serial communications protocol that finds the “sweet spot” in trading off overhead, complexity, throughput, cost, and real-time performance between CAN and FlexRay. Calling his proposal “Goldilocks,” Compton points out that it’s not a single protocol, but a continuum of protocols based on a single philosophy of message scheduling—namely deadline monotonic analysis, or DMA (Fig. 5).Goldilocks is consistent with CAN’s priority arbitration. However, it’s designed to perform scheduling and simulation offline based on DMA principles. Also, it doesn’t constrain arbitration bus speed.
In terms of low cost, the LIN bus offers the lowest cost per node for automotive networking applications. The serial bus interconnects intelligent sensors and actuators at a maximum speed of 19,200 baud, possible for up to 40 m of cable length. It also is often used as a CAN sub-bus.
Atmel offers a second-generation family of highly integrated LIN system basic chips that feature 6-kV electrostatic-discharge (ESD) protection and enhanced electromagnetic interference (EMI) performance. These products include a LIN transceiver with an integrated voltage regulator that has an output voltage of 3.3/5 V. Chips with integrated watchdog timers in addition to a voltage regulator will follow.
Continue to page 3
Russian firm Finprom Resource adopted its MSP LIN technology for automotive seating control in Audi’s A6 model. According to the company, it provides a maximized combination of economy, flexibility, and functionality.
Finprom also offers its AVAS digital vehicle control technology for an adaptable vehicle system. It’s based on identical electronic elements, a common channel, and a communication protocol that increases information density in a vehicle communication channel up to 97% and decreases the share of service information in it by 3%. The technology employs a standard power cable for communications and is compatible with CAN and LIN topologies.
SOFTWARE HOLDS THE KEY Given the complexity of the large number of control devices, actuators, sensors, and the interconnecting wiring they entail in a vehicle, it comes as no surprise that software is a crucial part of automotive networking design. Bruce D. Emaus, president of Vector CANtech, points out that automotive embedded software is enormous in size, with today’s high-end cars requiring hundreds of megabytes of software code.Emaus makes the case that adhering to an open software standard like AUTOSAR promises software-code reusability and reduced software development costs, as well as portability. Robert Bosch LLC, which has delivered automotive products that support AUTOSAR, expects it to become a global standard.
The impact of software like AUTOSAR on vehicle-to-vehicle and vehicle-to-infrastructure communications will be even greater, according to Emaus. He sees an increase in customer feature content, government regulatory requirements, the use of vehicle multiplexing in networking, communications protocols, and OEM-specific network operating strategies being used, as well as an increase in system architecture variations, especially with the use of x-by-wire subsystems. “All of this will mean a massive increase in software growth,” Emaus adds.
“Vehicles will be like cell phones,” says Kieran O’Sullivan executive vice president at tier 1 supplier Continental Automotive Systems’ Connectivity Business Unit. “They’ll become a node on a much broader network.”
NEC Electronics America plans to develop AUTOSAR-compliant MCAL microcontroller driver software for its 32-bit V850 series of MCUs and one V850E/PH03 MCU with an embedded FlexRay controller. The company is working with ETAS and KPIT Cummins Infosystems in this effort.
Mentor Graphics unveiled the first in its series of support tools for AUTOSAR. Its Volcano Vehicle Systems Architecture (VSA) tool also supports embedded software design for FlexRay, CAN, and LIN. Volcano’s model-driven design process allows users to reduce the amount of downstream validation and physical prototyping employed in designing auto components, embedded software, and networks. Users can move key design decisions and verification tasks to the front of the software-program flow, expediting the time-to-market for products.
Vector Informatik introduced the Fieldbus- Exchange Format FIBEX, a dataexchange format for message-based bus communication systems, to aid the development of AUTOSAR software. Based on XML, it includes all of the information needed to describe an entire on-board vehicle network.
This information includes the network topology, configuration parameters, schedules, frames, and signals as well as their coding on the bit level. FIBEX has become established as a standard for the FlexRay bus system.
Vector Informatik also is collaborating with the MathWorks to make its design tools interoperable for AUTOSAR applications. Users can define the component architecture in Vector Informatik’s DaVinci Developer, which is used for AUTOSAR, and then export the components into the MathWorks’ Simulink.
Leading automotive manufacturers and tier 1 companies like Toyota, Denso, Motorola, and Delphi use the MathWorks’ software products to improve the design and understanding of highly complex and integrated automotive networking systems. That’s because they can create a common platform for sharing system specifications and development ideas. Such networking systems include AUTOSAR, FlexRay, CAN, and LIN.
Another company in the AUTOSAR mix is dSPACE, which supplies development tools. It added a simulation module to its SystemDesk version 2.0, which supports AUTOSAR versions 2.1 and 3.0. With the module, users can simulate individual software components and verify the interaction of all software components for complex large-scale ECU-based networks.
Synopsys offers its Saber development environment for in-vehicle networking simulation and analysis to ensure signal integrity. Thorsten Gerke, head of technical marketing at Synopsys, says many automotive networking components and network layouts affect signal integrity, including inductors, varistors, cable types and lengths, and cable terminations.
For more, see “Placing Automotive OEMs Inside The Quality, Cost, And Technology/ Innovation Triangle”.