Autosar Open Standard to Tackle Automotive Electronic Complexities

At the pace at which electronics is proliferating in modern vehicles it may become difficult to manage the complexity of hardware and software systems if proprietary solutions continue to play a major role in future automobiles. In response to this growing complexity of electrical/electronic (E/E) systems in future automobiles, leading German automotive manufacturers, BMW Group, DaimlerChrysler and Volkswagen, in cooperation with electronic component suppliers like Bosch, Continental and Siemens VDO launched an initiative in July 2003 to establish an open standard upon which future vehicle applications would be implemented. Called Automotive Open System Architecture or Autosar, the E/E architecture standard initiative has gained worldwide momentum since its inception 18 months ago.

The Autosar’s vision is improved management of highly integrated E/E architectures through an increased reuse and exchangeability of software modules between OEMs and suppliers. Simply put, this open standardized central architecture for the global auto industry will provide modularity, scalability, transferability and reusability of functions (Figure 1). While scalability will ensure adaptability of common software modules to different vehicle platforms, and thereby prohibit proliferation of software with similar functionality, transferability will optimize the use of resources available throughout a vehicle’s electronic architecture.

Today, this open initiative has become a global effort with giant OEMs like Ford Motor Co., General Motors Corp., Toyota Motor Corp., and PSA Peugeot Citroen joining the core partners. While dozens of other OEMs (Honda Motor Co., Mazda, Porsche, Nissan, and Volvo) and tier-one suppliers (Delphi, Visteon, Denso, Valeo, and Lear Corp.) have come on board as premium members. In fact, Autosar’s organizational chart consists of core, premium and associate members. While the premium members will be involved in the working groups of the standard and make technical contributions to the standardization process, as well as have access to the latest information on the Autosar standard, the associate members will only have access to the finalized documents and utilization of the standard.

Presently, there are some 10 core members, and about 33 premium members from across the globe. Some key semiconductor names in the premier class include Freescale Semiconductor, Infineon Technology, NEC, Renesas Technology, and STMicroelectronics Corp. IBM has also recently joined as a second-tier premium member. “With a world that grows increasingly dependent on the functions supplied by embedded software, it’s a fact that embedded software development and management is immature as compared to other engineering disciplines,” said Janette Beauchamp, general manager, IBM Global Automotive Industry. “In joining Autosar, we see significant opportunity to share our thought leadership, experience, processes and frameworks to address the growing complexity in embedded and distributed computing systems in vehicles with some of the finest players in the automotive, electronics and software industries—and do so in an environment that so strongly supports open standards around the world, noted Beauchamp.”

While Autosar officials expect the first Autosar-based car to be on the road in the 2008 timeframe, some OEMs at last year’s Convergence show in Detroit indicated that Autosar vehicles could go into production within seven years. Nevertheless, this standardization is expected to have a positive impact on the industry wherein automotive electronic development processes are accelerating at an unprecedented pace. Since embedded systems involve interrelationship between hardware, software, and electrical systems in a single vehicle, they are becoming difficult to manage. The lack of automotive embedded-systems standards for architecture and software makes it difficult for automotive suppliers and OEM’s to efficiently handle the increasingly complex engineering workload. By shifting from proprietary to standardized hardware and software architecture, the Autosar will not only benefit OEMs and its electronic suppliers, but it will also help the tools providers and third parties working with member companies, stated Autosar executives in a paper given at last year’s Convergence 2004 in Detroit, MI.[1]

Project objectives The primary objective of the initiative is the standardization of basic system functions and functional interfaces around a central hardware/software architecture, thereby allowing the industry to focus on implementation. The Auotsar scope includes body electronics, powertrain, chassis and safety as well as multimedia systems, telematics and man-machine-interface. Some key objectives outlined by the Autosar body include: • consideration of availability and safety requirements; • redundancy activation; • scalability to different vehicle and platform variants; • implementation and standardization of basic system functions as an OEM wide standard core solution; transferability of functions throughout the network; integration of functional modules from multiple suppliers; maintainability throughout the whole product life cycle; increased use of commercial off-the-shelf hardware; and software updates and upgrades over the vehicle’s lifetime. By decoupling the applications from the underlying hardware and basic software architecture, and using standardized open interfaces, the Autosar will enable innovative functions for differentiation.

Autosar layers As shown in Figure 2, Autosar’s main elements include ECU hardware, basic software, runtime environment (RTE), and applications software. At the architectural level any communication between software components and elements of any other layer is routed through the Autosar RTE. The RTE acts as a communication center for inter- and intra-ECU information exchange between architectural elements of layers connected to the Autosar RTE. All communication between Autosar components has to be compliant to the standardized interface definitions.

Standardized interfaces for software components, operating systems and basic software are the major requirement to enable scalability and transferability of functions across electronic control units (ECUs) of different vehicle platforms. According to the Autosar presentation, the Autosar interfaces should not be considered as pieces of software dedicated to adapting any software module to an Autosar environment. Rather, they are an integral part of each software module running in an Autosar-compliant ECU. At the present time, different vehicle domains are using different operating systems (OS) tailored to their specific needs. However, the Autosar promises to simplify the process. Since Autosar architecture will be common for all vehicle domains, it will specify the requirements for an OS to be compliant to the emerging open automotive standard. Thus, the Autosar-compliant OS will offer configurability and scalability. The plan is to take into consideration existing products such as OSEK, VxWorks, Windows CE and other RTOS for automotive and their derivatives in defining the Autosar OS.

Likewise, the basic software layer, which provides services to the software components and is necessary to run the functional part of the software, is situated below the Autosar RTE environment. It could contain NVRAM management, transport layers for different communication technologies (e.g. CAN, LIN), network management, and system services such as diagnostic protocols. The basic software layer accesses the hardware via the microcontroller abstraction layer to avoid direct access to microcontroller registers. Speaking of hardware, the microcontroller abstraction is a hardware-specific layer that ensures a standard interface to the basic software layer. It manages the microcontroller peripherals and provides the basic software layer with microcontroller-independent values. Key features offered by this layer include digital I/O, analog/digital conversion, pulse-width modulation (PWM), pulse-width demodulation (PWD), EEPROM driver, flash driver, and communication interfaces (e.g. CAN, LIN).

The applications software, which resides above the RTE, consists of software components that encapsulate automotive functionality or pieces of it (i.e. interfaces resource requirements, timing etc.). According to the Autosar paper at Convergence 2004[1], its specification covers requirements and attributes that are prerequisites to run the software component in an Autosar-compliant environment.

Methodology and plan The Autosar methodology that describes the process from system design to implementation is also in place. Furthermore, the consortium has also organized a number of technical work packages for associated working groups with overall project timeframe. Each technical work package is further subdivided (e.g. WP 1.1.1, 4.2.2.1, etc.). Figure 3 illustrates the scope of the individual work packages with respect to the overall context. It can be seen that work packages follow the presented approach, concentrating on the individual steps with clearly identified interconnections. The focus of each work package is outlined below1: • WP1—Autosar concept It is concentrating on principal and conceptual issues, such as specification of mechanism and interfaces of the virtual functional bus, specification of Autosar requirements on the basic software modules, and reviewing the effects caused by dependable systems (high availability and safety-relevant) on the concept.

• WP2—Input formats for system generation This step will look into description of formats like templates for software components, system constraints, and ECU descriptions and the associated set of design tools.

• WP3—ECU configuration Delivering configuration files of the particular RTE module for each specific ECU from the information generated by the Autosar system generator.

• WP4—ECU software generation Defining the process of generating software executavbles out of the ECU configuration files. This includes specification/standardization of the input formats, tools to create and visualize the input formats, algorithms for and generation of the Autosar RTE, as well as qualification and implementation of existing basic-software.

• WP5—Test and integration process Subjects of interest for the WP5 package are systems integration and test.

• WP10—Data description This division focuses on the formulation of unified functional interfaces of all vehicle domains. This includes body/comfort, powertrain, chasis/driver dynamics, safety, telematics/multimedia and man-machine interface. All specified functions have to satisfy the Autosar software component template.

• WP20—Conformance test and standard maintenance Definition of the conformance test and licensing procedures, version control management and continuous maintenance of the Autosar standard. According to the project plan (Figure 4), the consortium hopes to finalize the RTE environment by summer of this year, and generate a final standard before the year-end. Consequently, the test and integration process is projected to begin in early 2006 with plans to test and verify specifications on an application by third quarter of 2006.

Reference: 1. Harald Heinecke, Klaus-Peter Schnelle, et al, AUTOSAR Partnership, “AUTomotive Open System Architecture- An industry-wide initiative to manage the complexity of emerging automotive E/E-architectures”, Convergence 2004 Proceedings, October 2004, Detroit, MI. 2. www.autosar.org.