AUTOSAR

AUTOSAR (Automotive Open System Architecture) is an open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers and tool developers. It is a partnership of automotive OEMs, suppliers and tool vendors whose objective is to create and establish open standards for automotive E/E (Electrics/Electronics) architectures that will provide a basic infrastructure to assist with developing vehicular software, user interfaces and management for all application domains. This includes the standardization of basic systems functions, scalability to different vehicle and platform variants, transferability throughout the network, integration from multiple suppliers, maintainability throughout the entire product lifecycle and software updates and upgrades over the vehicle's lifetime as some of the key goals.

AUTOSAR has been devised to:

• pave the way for innovative electronic systems that further improve performance, safety and environmental friendliness
• be a strong global partnership that creates one common standard: "Cooperate on standards, compete on implementation"
• be a key enabling technology to manage the growing electrics/electronics complexity. It aims to be prepared for the upcoming technologies and to improve cost-efficiency without making any compromise with respect to quality
• facilitate the exchange and update of software and hardware over the service life of the vehicle

The above mentioned goals are pursued by choosing an software architecture that supports a design model based on component based design. The model is supported by an automated methodology to create the software executable for the ECU’s, starting from the design model and the properties and physical topology of the hardware. This way the Autosar-projects tries to create a paradigm shift in automotive software development from an ECU based approach to a function based approach.

Design model

The AUTOSAR-standard enables the use of a component based software design model for the design of a vehicular system. The design model uses application software components which are linked through an abstract component, named the virtual function bus.

The application software components are the smallest pieces of application software that still have a certain functionality. The software of an application can then be composed by using different application software-components. Standardized interfaces for all the application software components necessary to build the different automotive applications are specified in the Autosar-standards. By only defining the interfaces, there is still freedom in the way of obtaining the functionality.

The virtual function bus connects the different software components in the design model. This abstract component interconnects the different application software components and handles the information exchange between them. The virtual function bus is the virtualization of all hardware and system services offered by the vehicular system. This makes it possible for the designers to focus on the application instead of the infrastructure software.

By using the virtual function bus, the application software components don’t need to know with which other application software components they communicate. The software components give their output to the virtual function bus, which guides the information to the input ports of the software components that need that information. This is possible due to the standardized interfaces of the software components which specifies the input and output ports as well as the format of data exchange.

This approach makes it possible to validate the interaction of all components and interfaces before software implementation. This is also a fast way to make changes in the system design and check whether the system will still function.

Software Architecture

To make a component based design possible, the AUTOSAR-project uses a layered architecture that ensures the decoupling of the functionality from the supporting hardware and software services.

• Basic Software Layer: The Basic Software is standardized software that doesn’t have any functionalities but offers hardware-dependent and hardware-independent services to the layer above (the Run Time Environment). This is realized through the use of Application Programming Interfaces (link naar wiki pagina). This layer itself is not entirely hardware independent but makes the upper layers hardware independent.

• Runtime environment: The Runtime Environment handles the information exchange between the application software components and connects the application software components to the right hardware. This layer decouples the application software components from the hardware as well as the application software components from the themselves.

• Application Layer: The application layer is the only layer that is not composed of standardized software, it is also the layer where the actual functionality is situated. The layer is composed of application software components that interact with the run time environment.

The Basic Software and Runtime Environment are the technical realization of the virtual function bus in the design model.

The layered architecture is used on every ECU and makes it possible to design a vehicle system without thinking in terms of the ECU’s. The designers select a number of software components that don’t know on which ECU certain software components are installed or hardware is connected. The Runtime Environment makes sure that the software components can communicate with one another or with the hardware, it doesn’t matter whether both components are on different ECU’s or not.

Methodology

The AUTOSAR-project created a methodology that can be used to create the E/E system architecture starting from the design-model. This approach uses 4 steps:

Step 1 Input Descriptions

The input description step contains three descriptions:

• Software Components: This description is independent of the actual implementation of the software component. Among the necessary data to be specified are the interfaces and the hardware requirements.
• System: The system topology (interconnections between ECU’s) need to be specified together with the available data busses, used protocols, function clustering and communication matrix and attributes (e.g. data rates, timing/latency, …).
• Hardware: The available hardware (processors, sensors, actuators, …) needs to be specified together with the signal processing methods and programming capabilities

Step 2 System Configuration

This step distributes the software component descriptions to the different ECU. This is an iterative process where ECU-resources and system-constraints are taken into account. For example, there needs to be checked whether the necessary communication-speeds are met.

Step 3 ECU-configuration

In this step, the Basic Software and the Run Time Environment of each ECU is configured. This is based on the dedication of the application software components to each ECU.

Step 4 Generation of Software Executables

Based on the configuration of the previous step, the software executables are generated. For this step, it’s necessary to specify the implementation of each software component.

This methodology is automated by using tool-chains. All subsequent methodology steps up to the generation of executables are supported by defining exchange formats (using XML) and work methods for each step.

To support the Autosar-methodology, a meta-model is developed. This is a formal description of all methodology related information, modeled in UML. This leads to the following benefits:

• The structure of the information can be clearly visualized
• The consistency of the information is guaranteed
• Using XML, a data exchange format can be generated automatically out of the meta-model and be used as input for the methodology.
• Easy maintenance of the entire vehicular system

Members

There are four types of membership for AUTOSAR:

• Core (founding) members
• Premium members
• Associate members
• Development members

Core membership only is available for leading car manufacturers and Tier1; the other types of membership are open to other companies as well.

Core members include the PSA Peugeot Citroën, Toyota Motor Corporation, Volkswagen, BMW Group, Daimler AG, Ford Motor Company, Opel, and automotive suppliers Bosch, Continental AG and Siemens VDO (now Continental AG).

There are a total of 35 corporate members as of September 2005.

The professed goals are modularity, scalability, transferability and re-usability of functions to provide a standardized platform for automotive systems. This will enable system wide configuration and optimization to meet runtime requirements of automotive devices. Many of the low-level components of AUTOSAR (the real time operating system and communications layer) are derived from OSEK work.

Implementers

According to the AUTOSAR-paradigm "Common standard, concurring implementations", several software suppliers offer software implementations of the AUTOSAR standard. Some of the suppliers of AUTOSAR standard software are:

• NEC Electronics (NEC AUTOSAR MCAL for V850 platform)
• Mecel (Mecel Picea)
• Bosch (CUBAS)
• Vector Informatik GmbH
• EB / Elektrobit (EB AutoCore)
• Tata Elxsi([1])
• OpenSynergy([2])
• Time Partition Testing - model based testing of AUTOSAR components. cf. PikeTec
• Kpit Cummins Infosystems Limited

News and releases

As of August 2008, the specifications are up to version 3.0. This version introduces some significant changes from the previous version 2.1, as well as some minor tweaks. Version 3.1 is due out very soon. It is expected that this will be mostly review comments on 3.0. Version 4.0 is expected in 2009.

Scaleo Chip, French designer of ARM-based system-on-chip, and India-based automotive service company Tata Elxsi Ltd. have joined forces to develop an automotive platform compliant to Autosar standard .

Criticism

Timing

AUTOSAR lacks information about timing requirements in its meta-model. On the one hand there are high-level requirements like end-to-end latencies that specify temporal behaviour of the system on the logical abstraction of system functions. On the other hand there exist timing relevant implementation details of the system-level. Based on these ideas a meta-model to capture high-level requirements and an implementation to calculate the corresponding latencies on system-level was developed.

Although a meta-model to capture high-level requirements can aid in the development of vehicular systems, there still can be problems to find timing-issues like buffer-overflow or missed deadlines. This due the non-functional time-delays (buffering of signals, the allocation of memory). These are problems that the OEM’s will have to solve during the implementation of the entire system.

Efficiency

Tailored-fit systems can be designed to be more efficient than software built from ‘plug-and-play’ software components. Hence small systems designed according to the AUTOSAR standard need more memory and more computing power. The extra cost of the ECU resources is a major issue in the highly cost-driven automotive business. For complex ECUs the situation is different. Here the availability of a common core definition allows efficient re-use of basic functions by application software.

Too much standard

During the standard creation process, many participants – OEMs as well as tier-one companies – lobbied and managed to get functions and elements established as a part of the standard that not all the members of the Autosar consortium were interested in. This bloats the standard’s definition at the expense of clarity. The consequence will be that many suppliers offer different subsets of the standard definition

Further reading

• Olaf Kindel, Mario Friedrich (2009). Softwareentwicklung mit AUTOSAR (Software Development with AUTOSAR). dpunkt.verlag. p. 300. ISBN 978-3-89864-563-8.

External links

• Official website
• AUTOSAR FORUM
• AUTOSAR Group on Xing