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 life-cycle and software updates and upgrades over the vehicle's lifetime as some of the key goals.
- 1 Goals
- 2 Design model
- 3 Software architecture
- 4 Methodology
- 5 Members
- 6 Implementers
- 7 Criticism
- 8 References
- 9 Further reading
- 10 External links
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
As stated in the official website, the goals of AUTOSAR are:
- Implementation and standardization of basic system functions as an OEM wide "Standard Core" solution
- Scalability to different vehicle and platform variants
- Transferability of functions throughout network
- Integration of functional modules from multiple suppliers
- Consideration of availability and safety requirements
- Redundancy activation
- Maintainability throughout the whole "Product Life Cycle"
- Increased use of "Commercial off the shelf hardware"
- Software updates and upgrades over vehicle lifetime
The above mentioned goals are pursued by choosing a 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 ECUs, starting from the design model and the properties and physical topology of the hardware. This way the AUTOSAR-project tries to create a paradigm shift in automotive software development from an ECU based approach to a function based approach.
VDC Research reports in 2008 that adherence to AUTOSAR is expected to double in the next two years (from 7% to 14%).
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 conceptualization 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 do not 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.
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 does not have any functionality 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. This layer itself is not entirely hardware independent but makes the upper layers hardware independent.
- 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 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 ECUs. The designers select a number of software components that do not know on which ECU certain software components are installed or hardware is connected. The Runtime Environment (or the Virtual Functional Bus more specifically) makes sure that the software components can communicate with one another or with the hardware, without concern if both components are on different ECUs or not.
Step 1: Input Descriptions
The input description step contains three descriptions:
- Software (s/w) 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 ECUs) 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 ECUs. This is an iterative process where ECU-resources and system-constraints are taken into account. For example, there needs to be a check whether or not the necessary communication-speeds are met.
Step 3: ECU-configuration
In this step, the Basic Software and the Run Time Environment of each Electronic control unit (ECU) is configured. This is based on the allocation 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 that 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 related information on the methodology, 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
There are four types of membership for AUTOSAR:
- Core (founding) members
- Premium members
- Associate members
- Development members
Core membership is only available for leading car manufacturers and Tier1 suppliers. Other types of membership are available.
Core members include the BMW Group, Daimler AG, Ford Motor Company, General Motors, Opel, Toyota Motor Corporation, PSA Peugeot Citroën, Volkswagen and automotive suppliers Bosch, Continental AG and Siemens VDO (now Continental AG).
As of October 2012[update] there are a total of 146 corporate members.
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 run-time 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.
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:
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.
With version 4.0 of AUTOSAR provides timing extensions effectively allowing for specification and verification of AUTOSAR models with respect to timing.
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 is due to non-functional time-delays (e.g., buffering of signals, allocation of memory). These are problems that the OEMs will have to solve during the implementation of the entire system.
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.
In 2007, Christoph Hammerschmidt wrote in the EE Times:
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.
He quoted an anonymous expert in the process as saying:
Things like this bloat the standard’s definition at the expense of clarity. The consequence will be that many suppliers offer different subsets of the standard definition.
- "Automated Defect Prevention for Embedded Software Quality" white paper by VDC Research
- Specification of the Virtual Functional Bus, V1.0.2, R3.1, Rev 0001 - Available on http://www.autosar.org
- Development of AUTOSAR Software Components within Model-Based Design - By Sandmann G., Thompson R. - 2008 World Congress, Detroit, Michigan, April 14–17, 2008 - SAE Paper 2008-01-0383
- Autosar Tutorial Presentation - Available on http://www.autosar.org
- Achievements and Exploitation of the AUTOSAR Development Partnership - By Fennel H., Bunzel S. et al. - Convergence 2006, Detroit, Michigan, October 16–18, 2006 - SAE Paper 2006-21-0019
- News link., News link. Mentor Graphics acquires Mecel Picea AUTOSAR Development Suite.
- "AUTOSAR Timing Extensions" (PDF). AUTOSAR. Retrieved 8 May 2014.
- Hammerschmidt, Christoph (22 May 2007). "Autosar standard not ready to plug-and-play". EE Times Europe. Retrieved 2009-06-30.
- Kai Barbehön, Axel Englisch, Andre Lajtkep (8 Oct 2008). "AUTOSAR – BMW’s strategy to introduce AUTOSAR." (PDF). Vector Congress 2008. Retrieved 2009-06-29.
- Oliver Scheid (2015). AUTOSAR Compendium - Part 1: Application & RTE. p. 406. ISBN 978-1-50275-152-2.
- Olaf Kindel, Mario Friedrich (2009). Softwareentwicklung mit AUTOSAR (Software Development with AUTOSAR). dpunkt.verlag. p. 300. ISBN 978-3-89864-563-8.
- Chip vendors facing up to AUTOSAR challenge
- Official website
- Chip vendors facing up to AUTOSAR challenge in AutomotivedDesign Europe
- AUTOSAR Group on Xing
- About AUTOSAR AUTOSAR on the Renesas Homepage
- E-Learning module AUTOSAR on the VectorAcademy Website.
- AUTOSAR BSW Platform COMASSO
- ARTOP AUTOSAR Tool Platform User Group
- Homepage of the book "AUTOSAR Compendium - Part 1: Application & RTE"