It's not as if the entire burden of differentiating a new vehicle falls on the shoulders of automotive electronics design engineers, but there must be days when it feels that way. Infotainment, telematics, safety, body electronics, engine management and other domains require processors, programming, and power. Combine the breadth of system development with tight time frames, severe cost constraints, and uncertain resources, and the pressure to produce becomes intense.
The more electronic control units (ECUs) a vehicle has, the more important it becomes to manage those devices efficiently, and network bus technologies have become popular for that purpose. But more ECUs translate to more traffic, requiring more bandwidth. For some advanced designs, the popular Controller Area Network (CAN) bus is reaching its limits.
“The widely used CAN network protocol has bandwidth and reliability limitations,” said Serge Leef, General Manager of Mentor Graphics' System-level Engineering Division. “(CAN) has the advantage of being inexpensive; however, it's non-deterministic, and as a result, customers compensate by designing networks that use only a limited portion — frequently no more than 30% — of total bandwidth in order to increase the likelihood that messages will arrive in a sufficiently timely manner. But limiting use of network bandwidth diminishes CAN's price/performance benefits.”
FlexRay solves the bandwidth problems associated with CAN, but at a significantly higher cost. Adopting FlexRay requires designers to negotiate a rather steep learning curve, and the protocol is at an early stage.
“The original plan for FlexRay was to provide a network that enables fault tolerance and redundancy,” said Jens Eltze, Principal Technical Application Engineer for NEC Electronics America's Automotive Strategic Business Unit. “Now, it's also being implemented for bandwidth, and there are other ways of increasing bandwidth. In the current economy, introducing a new network and converting existing modules is not a major priority. The network is a facilitator, not a differentiator or a selling factor.”
TTCAN
Time-triggered CAN (TTCAN) has potential as an interim step between CAN and FlexRay, according to Kyle Williams, Director of Automotive Systems Integration at Robert Bosch LLC. The firm has developed and demonstrated TTCAN modules, and has generated a lot of interest among OEMs. “TTCAN costs about the same as CAN, which is low compared with FlexRay, but it offers twice the bandwidth,” he said, explaining that because TTCAN is deterministic, designers can use more of the available bandwidth in a CAN bus than they would if data collision were an issue.
“It's a lot cheaper to implement TTCAN than it is to put in a second CAN bus,” Williams said, noting that a lot of current-generation vehicles have two or more CAN buses installed. He added that the myriad tools available to support CAN development can also be used with TTCAN.
“We're seeing FlexRay coming out now, but the issue is the cost,” Williams continued. “A lot of OEMs are hesitant to take the step to FlexRay. They are waiting for the cost to come down. Even in the long run the cost won't be comparable to CAN.”
Wolfhard Lawrenz, Chief Executive Officer of C&S Group, a firm that specializes in testing automotive software, systems and networks, disagrees that TTCAN is a viable interim step between CAN and FlexRay. “CAN has one major formula — 40m at 1Mbps. The limiting factor is line length. When you cut down the niceties of CAN, then it's not CAN,” said Lawrenz, one of the original developers of the CAN protocol. “Time-triggered CAN is not applicable except for short extensions, where there is not enough of a market to justify production. FlexRay is better for deterministic and real-time requirements.”
Lawrenz conceded that FlexRay is costly, but he noted that the cost is not likely to come down until the protocol is more widely deployed. “OEMs in Germany and Japan have decided to go with FlexRay,” he noted.
AUTOSAR
AUTOSAR, which holds the promise of reusability, is also an early stage technology that requires a significant investment of time and money. Is it worth the investment to commit to it now, or does it make sense to wait?
AUTOSAR investigations are under way as companies try to leverage standardization to reduce cost while defining the future of software development, according to David Howarth, Director of Marketing at ETAS. “The ultimate goal is an efficient, distributed, hardware-independent process, with increased use of automatic production code generation tools for new programs,” he said.
Bosch's Williams said AUTOSAR is going to be very important in the future because it enables the development of software that is both reusable and portable. “It provides a great amount of flexibility for next-generation architectures. Vehicles are getting more and more complex, and systems that were formerly isolated are now interacting. AUTOSAR-compliant software modules can be used where they are needed; where resources are available.”
Williams said two modules with AUTOSAR went into production last year. The firm will release additional products with AUTOSAR this year and beyond. “We see it becoming a global standard.”
NEW NETWORK TOOLS
Engineers say that one advantage of CAN protocol, and also of LIN, is the availability of development and test tools. Don't expect the knowledge gap between those protocols and FlexRay or AUTOSAR to close anytime soon, but tools for the newer technologies are beginning to appear.
Mentor Graphics, for example, recently launched Volcano Vehicle Systems Architect (VSA), for AUTOSAR-based systems and embedded software design with support for FlexRay, CAN and LIN network protocols.
According to Serge Leef, most automotive application and system debugging is still based on physical prototyping. “Volcano VSA focuses on the model-driven design process and allows customers to reduce their reliance on downstream validation and physical prototyping,” he said. “Automotive companies can achieve substantial cost savings in the development process by moving significant decisions and verification tasks to the front end of the design cycle.”
Based on the open-source Eclipse integrated development environment, Volcano VSA enables an AUTOSAR-based vehicle system design flow from architectural exploration to implementation. Leef said the new technology can improve quality, reliability and time to market, and provide cost advantages, by facilitating the use of standard interfaces and components based on AUTOSAR. Engineers can use VSA to design, explore and compare electronic and software architectures. “It allows users to take advantage of ‘correct-by-construction' design methodology that reduces reliance on test-oriented validation approaches,” Leef noted.
Tools developer dSPACE added a simulation module to SystemDesk version 2.0 that supports AUTOSAR releases 2.1 and 3.0. Users can simulate individual software components and verify the interaction of all software components, even in large-scale ECU networks. Measurement data is presented graphically to facilitate error detection, and errors can be inserted in order to test ECUs' response to failures. Hardware topology can be modeled in SystemDesk, and communication matrixes for CAN and LIN bus protocols can be imported. dSPACE's TargetLink automatically generates code for ECUs from the MATLAB/Simulink/Stateflow environment.
TTTech Automotive has developed an automated tool for validating the consistency of AUTOSAR component configurations in ECUs. TTX-AutoVerify increases system integration efficiency to save time and cost. The tool enables systematic checking of the ECU's software configuration, and supports automatic verification.
The MathWorks and Vector Informatik are collaborating to make their respective tools interoperable for AUTOSAR applications. Customers can define the component architecture in Vector's AUTOSAR design tool, DaVinci Developer, and then export the component description into The MathWorks' Simulink, where the component behavior is designed.
Real-Time Workshop Embedded Coder from The MathWorks automatically generates AUTOSAR-compliant component code and an updated component description that can be read back into DaVinci Developer. The new R2009a versions of Simulink and Real-Time Workshop Embedded Coder support this workflow for AUTOSAR 3.0. Customers can then use DaVinci Developer to configure Vector's AUTOSAR compliant runtime environment, MICROSAR RTE, to integrate the component code with the AUTOSAR basic software.
ETAS is collaborating with NEC Electronics and KPIT Cummins Infosystems to facilitate development of AUTOSAR-compliant systems by combining NEC V850 microcontrollers, KPIT communications control middleware and runtime environment, and ETAS' ASCET automotive C-code development tool and INTECRIO prototyping platform.
NEC Electronics will develop and market AUTOSAR-compliant MCAL microcontroller driver software for its 32-bit V850 F series and one V850E/PH03 MCU with an embedded FlexRay controller. KPIT will produce software to run on the NEC MCUs, and ETAS will offer software development tools to work with both the NEC MCUs and the KPIT modules.
Tools vendors are continuing work on products for CAN and LIN protocols as well as for newer technologies. The MathWorks' Vehicle Network Toolbox (Fig. 1) connects MATLAB directly to a vehicle's CAN network, eliminating the need for additional connectivity tools or time, and creating an environment for streamlining test, verification, and analysis activities. “Automotive designs are complex by nature, and this direct CAN connection simplifies test, diagnostics, and design verification,” said Jon Friedman, The MathWorks Automotive Industry Marketing Manager.
Version 2.1 of Vector CANtech's CANoe/MATLAB Interface is said to simplify data exchange between the two tools. The interface is signal-oriented, thus users do not have to adapt models to CAN, LIN or FlexRay bus systems. Real-time hardware in the loop (HIL) simulations can be implemented by linking CANoe and MATLAB directly. The Simulink Model Viewer integrated in CANoe gives users a detailed look at the MATLAB/Simulink simulation node models and enables direct access to internal model parameters.
Network development aids include hardware as well as software products. Earlier this year austriamicrosystems introduced a FlexRay active star device with an embedded bit-reshaper that reduces the asymmetric delay caused by components in FlexRay networks or introduced by external interferences onto the network.
The AS8224 FlexRay transceiver can reshape single bits in 12.5 ns steps (microtick) up to a total amount of 37.5 ns (3 microticks) for shortened and lengthened bits. In addition to timing reshaping, the device can effect clock-deviation compensation between the input and output streams of the device while the BSS (Byte-Start-Sequence) of the FlexRay frame is shortened or lengthened by one microtick.
The bit-reshaping function can be set as an option and will be functional if an external clock is connected to the device. Otherwise, the reshaper will be bypassed and the device will act as a standard active star without timing reshaping.
Harald Gall, austriamicrosystems Product Manager for in-vehicle networks, said the AS8224 with embedded bit-reshaper enables FlexRay topologies beyond today's applications and allows network topologies with more than one active star. It operates as an active hub for four FlexRay network branches, the communication controller interface, and an interstar interface, and it performs message forwarding for all six communication paths.
OPTIONS FOR INFOTAINMENT
C&S Group's Wolfhard Lawrenz said the only network protocol available for infotainment is MOST (Media Oriented System Transport), which remains popular in Europe. “It's a closed system, and many people are not happy with it,” he added, suggesting “maybe an automotive version of switched Ethernet could have a good chance to take over.”
“MOST is moving up to higher bandwidth that will allow more graphical content,” noted NEC Electronics' Jens Eltze. “Ethernet could be used to connect high-performance components in a car. That's also a motivation for USB. Vehicle-to-vehicle communication is likely to be based on Wi-Fi, which could be used sooner for infotainment.
Another option for infotainment is 1394, for which Fujitsu Microelectronics America introduced a controller that transmits high-definition video over 1394 Automotive in-vehicle multimedia networks at 800 Mbps. The MB88395 can simultaneously transmit multiple streams around the vehicle, such as HD video (1,280 dots × 720 lines) from Blu-Ray DVDs, digital TV, and car navigation images.
Co-developed with Fujitsu VLSI Ltd., the Fujitsu MB88395 controller uses an 800 Mbps physical layer and link layer along with the Fujitsu proprietary SmartCODEC, which compresses video to one-quarter its original size and can compress and decompress high-resolution video in two to three milliseconds without any perceptible time lag or out-of-sync content. Akio Nezu, Senior Marketing Manager in Fujitsu Microelectronics' Automotive Business Group, said this resolves latency issues that can be a problem when different viewers are watching the same content on the front and rear monitors.
Nezu said the combination brings HD-quality video to rear-seat entertainment, while reducing vehicle weight and improving fuel efficiency. The controller and SmartCODEC combination reduces the system cost of in-vehicle multimedia networks by up to 30% while reducing the number of wire harnesses by up to 70%. It can reduce environmental impact by approximately 10kg of carbon dioxide (CO2) per year for a car traveling 10,000km, about the amount of CO2 a tree absorbs in a year.
According to the 1394 Trade Association, Honda, Ford, and Nissan are among the automakers that have expressed an interest in the protocol, also known as FireWire. At a seminar in Dearborn, MI in late April, the Association presented 1394 as a complete ecosystem, ready to be designed into vehicles today.