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.
AUTOSAR has been devised to:
As stated in the official website, the goals of AUTOSAR are:
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-projects tries to create a paradigm shift in automotive software development from an ECU based approach to a function based approach.
Contents |
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.[1]
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.[2]
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 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.
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[3][4]:
The input description step contains three descriptions:
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.
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.
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:
There are four types of membership for AUTOSAR:
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 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. 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.[5]
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.[6] 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.[7]
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[6]