AUTOSAR has held the promise of simplifying software development and providing a flexible architecture to address the increasing complexity of vehicle electronics since its establishment in 2003. Release 2.1 of the specifications in March 2007 concluded phase 1 and provided a major milestone in the standardization effort. At the same time, significant development toward ultimate vehicle implementation has occurred at partner companies.
Starting with the enabling technology provided by semiconductor companies and development tools from tool providers, significant pieces of the AUTOSAR puzzle are beginning to fall into place. The “if it happens” is more of a “when it happens” situation and companies that participate could have a significant advantage over those who stand by and watch it happen.
AUTOSAR FUNDAMENTALS
The AUTOSAR Consortium consists of automakers, tier one electronics manufacturers, semiconductor companies and software tool suppliers. One of the major goals of AUTOSAR is the reuse of software components between different platforms, OEMs and suppliers. Today, because electrical architectures are not consistent, even reuse between platforms within an automaker may not be at the level the company desires. AUTOSAR will change this and provide additional benefits as well.
AUTOSAR stands for automotive open system architecture, a design approach intended to change the way the industry develops the vehicle's electrical and electronic (E/E) architecture. Other acronyms developed to discuss the open system architecture are shown in Table 1.
For AUTOSAR to deliver on its promise(s), automakers and suppliers must work together not only on specifications but implementation, too. “For all of them, what AUTOSAR really means is the bringing together of all the best practices for development of an ECU from the design of the network to the validation and maintenance of the network and ECUs,” said Robert Miller, embedded software product line manager, Vector CANtech.
With revision 2.1 many of the key aspects of AUTOSAR have been specified. Jon Friedman, automotive industry marketing manager, The MathWorks explained, “AUTOSAR defines a set of message standards and application program interfaces (API).” Basic software (BSW) below the RTE provides the additional non-functional services. To distinguish between hardware-dependent and hardware-independent functionalities, the BSW is divided into a services layer, ECU abstraction layer, a microcontroller abstraction layer and complex drivers (Figure 1).
Release 2.0 additions include a generic configuration editor and the runtime environment (RTE) to link basic software and applications. Portions of the complex drivers were added between the application layer and the microcontroller. This release also includes documents on development methodology and templates.
The virtual functional bus (VFB) shown in Figure 2, was introduced to allow the design of the overall system in the absence of knowing how the system will ultimately be implemented. For example, explained Friedman, in a climate control system, a sensor generates a temperature signal that is sent to an actuator that moves a flap to a certain angle. If a legacy system does not exist, the designer does not need to know whether the signal is sent over a LIN or CAN bus. By abstracting the system, the function can be designed independent of the implementation. The VFB handles the data exchange between components. Later in the design process, it can be determined whether the end points are on the same MCU, resulting in simple internal commands or on different MCUs in the system and require a message on a system bus. Mapping of functions is the next step that determines where the functions reside and how the communication is handled.
Thomas Heurung, worldwide business development manager for automotive networking business unit, Mentor Graphics noted that while AUTOSAR ultimately aims to reduce component cost, design and validation complexity will increase[1]. Not surprisingly, toolmakers have already played a pivotal role in advancing AUTOSAR.
Joni Gruszczynski, project engineer, Vector CANtech observed a lot of interest at the 2007 SAE Congress earlier this year that has spurred increased development activity. “They want to see the suite of tools in use in Europe now and how it (DaVinci) can define a network and system under the AUTOSAR guideline and approach and take it all the way down to the hardware level,” said Gruszczynski. “They're in a state where they are getting more and more technical questions all the time.” The questions are getting more difficult to answer as engineers actively try to determine how AUTOSAR is going to work for them.
USING AUTOSAR TODAY
Aimed at improving complexity management of integrated E/E architectures through increased reuse and exchangeability of SW modules, the European-initiated AUTOSAR effort should be important to the worldwide automotive community. However, until it is actually applied, the promises of AUTOSAR are just that, promises.
One real-world demonstration of AUTOSAR comes from a collaboration of Volkswagen, Hella, NEC Electronics and Elektrobit[2]. Using a microcontroller and development tool chain from NEC automotive, ECU, application software and integration provided by Hella, and AUTOSAR basic software release 1.0 implemented by Elektrobit, Volkswagen and Hella jointly developed a fully functional body/comfort ECU for a Volkswagen series-production Passat. The MathWorks provided the AUTOSAR development kit (ADK) to implement model-based development (MBD). The development process is shown in Figure 3.
According to The MathWorks' Friedman, many OEMs are already coping with the transition to MBD and the VW project shows how the transition to AUTOSAR can be accomplished and simplified based on MBD. VW took existing proprietary Simulink models from model-based design. “They developed their application algorithm in Simulink and they wanted to generate AUTOSAR-compliant software,” said Freidman. The program showed that MBD with Simulink models using Real-Time Workshop Embedded Coder can generate AUTOSAR-compliant code. VW used the model and essentially has an AUTOSAR module operating in a production vehicle, where the module itself acts like an AUTOSAR-compliant unit behaving in a manner consistent with the AUTOSAR requirements. Additional software allows the two worlds to co-exist.
Other tool suppliers are actively pursuing AUTOSAR solutions. “Our goal is to have a tool that supports the logical design of the complete network, of the complete system,” said Heurung.” This would run in parallel and complement CHS, Mentor Graphic's tool that supports vehicle electrical system design and wire harness engineering.
Vector CANtech, another premium member of the AUTOSAR consortium, is developing tools for customers to implement AUTOSAR. Vector CANtech's Gruszczynski, said, “We have broken off every piece that has specifically to do with hardware and we keep it at its own level.” The pieces of Vector's process are shown in Figure 4 including CANoe, DaVinci System Architect and Network Designer, DaVinci Developer and MICROSAR configuration suite.
AVAILABLE AUTOSAR HARDWARE AND SOFTWARE
With version 2.1 of the AUTOSAR specification available earlier in 2007, several suppliers have announced products to support implementation and vehicle development effort. Semiconductor suppliers that are members of the consortium include Freescale, Fujitsu, Infineon, Micron, NEC and Renesas at the premium level status. Several other suppliers have associate memberships. In addition, several tool suppliers have either premium or associate membership grades. Many of these members have started to provide AUTOSAR implementations in recent products.
“We are offering AUTOSAR driver software for our XC2000 and also for our TriCore family,” said Bjoern Steurich, senior product manager for microcontrollers, Infineon Technologies North America.
One is a low-end 32-bit family and the other is a high-end 32-bit microcontroller/DSP family. To implement the microcontroller-specific portions of AUTOSAR, Infineon developed AUTOSAR-compliant low-level drivers as part of MC-ISAR, which stands for MicroController — Infineon Software Architecture. The three pieces consist of a microcontroller core with certain I/O peripherals, and separate communication and memory. Each section has several subsections as shown in Table 2.
Traditionally, users had to be familiar with the microcontroller and what it could do. “By having a standardized driver set, they can focus more now on doing the functions they want for the vehicle instead of using all their effort on developing the lowest-level hardware control,” said Edward Wiley, applications specialist, Infineon Technologies North America. For designers in the development phase, the standardized drivers for AUTOSAR have proven to simplify their job.
Infineon's TC1766 went into mass production in 2006. Some customers are taking advantage of portions of the software. “The full AUTOSAR implementation, that's what we see coming in the 2008 to 2009 time frame,” said Steurich.
Another supplier with AUTOSAR-capable hardware and software is NEC, whose V850 microcontroller and development tool chain was used in the Volkswagen Passat project. NEC's V850E 32-bit MCU has an embedded FlexRay AUTOSAR driver. In addition to the FlexRay driver, NEC has developed Micro Controller Abstraction Layer (MCAL) and a configuration tool called the AUTOSAR starter kit so designers can initiate activity. Specific NEC microcontroller modules are shown in Figure 5.
MORE THAN PASSENGER VEHICLES?
At its current stage, AUTOSAR proponents in the consortium are reluctant to extend the methodology beyond the scope of passenger cars and light-duty vehicles but one demonstration has already shown its viability for commercial vehicles. Volvo Truck and Mentor Graphics recently completed redevelopment of the existing climate control system using AUTOSAR technology.
The project's goal was to evaluate AUTOSAR from a commercial vehicle manufacturer's perspective by applying the concept to a real-world application of a dual-climate control system. As the main contractor, Mentor Graphics performed the development and integration of basic software modules as well as the network scheduling. Live Devices of ETAS Group provided the RTE generator. Using its Volcano network architect (VNA), Mentor Graphics successfully re-implemented the control system including the communication over the CAN protocol in an AUTOSAR environment and Volvo Truck has the prototype working in an actual truck. Another protocol in the project was SAE J1587, a commercial vehicle-specific protocol.
Mentor Graphics plans to deliver a complete AUTOSAR software stack in 2007. Other AUTOSAR tools in development include Vehicle System Builder, an advanced configuration and generation suite, and Vehicle Systems Architect for system-level design and optimization. Figure 6 describes Mentor Graphics approach to AUTOSAR development.
AUTOSAR DOWN THE ROAD
The first partial implementation of AUTOSAR in production vehicles should appear in 2008, possibly from several manufacturers. Today, vehicles with AUTOSAR-compliant MCUs are on the road but AUTOSAR's capability has not been used or has had limited usage in those vehicles. By 2010, AUTOSAR expects that all its core partners will have implemented AUTOSAR software in a new electronic control unit or in a vehicle. With the ink still drying on the 2.1 version, the next major milestone, revision 3.0 is scheduled for this fall.
According to The MathWorks' Friedman, some companies are looking at a new platform that will be completely AUTOSAR-compliant to obtain all the promised advantages. Others are considering subsystems and will partition part of the architecture to continue to leverage modules with well-established track records that do not need to be updated.
AUTOSAR version 4.0 is expected at the end of 2009. As a result, the real benefits of AUTOSAR on vehicles may not start until 4.0 is available — in the 2009 and beyond time frame. According to Mentor Graphic's Heurung, “There's a bunch of benefits that can be reaped fairly early but the overall big picture where you have fully relocatable software components, automatically driving cost-optimized electrical and software design, I think that's a few decades down the road.”
References
-
Thomas Heurung, “In-Vehicle Network Design Methodology,” http://www.mentor.com/products/vnd/techpubs/mentorpaper_29385.cfm.
-
Andreas KÖhler, Volkswagen AG, Wolfsburg, Germany and Tillman Reck, Carmeq GmbH, Berlin, “AUTOSAR-Compliant Functional Modeling with MATLAB, Simulink, Stateflow and Real-Time Workshop Embedded Coder of a Serial Comfort Body Controller,” Germany, MathWorks Automotive Conference '07, http://www.mathworks.com/industries/auto/mac2007/abstracts.html.
ABOUT THE AUTHOR
Randy Frank is president of Randy Frank & Associates Ltd., a technical marketing consulting firm based in Scottsdale, AZ. He is an SAE and IEEE Fellow and has been involved in automotive electronics for more than 25 years. He can be reached at [email protected].
TABLE 1
Acronyms and terms in AUTOSAR's layered software architecture.
TABLE 2
Components of Infineon's MC-ISAR.