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 life-cycle and software updates and upgrades over the vehicle's lifetime as some of the key goals.

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-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%).[1]

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 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.[2]

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.[3]

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.

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:[4][5]

Step 1: Input Descriptions

The input description step contains three descriptions:

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:

Members

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.

9 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 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.

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:

Implementer BSW/MCAL Implementation BSW Configurator RTE Generator System Tooling License
ArcCore Arctic Core - Open source AUTOSAR BSW Builder RTE Builder SWC Builder and Extract Builder GPL (Arctic Core and base version of Arctic Studio) / Commercial licenses available for all products
COMASSO_eV BSW BSWDT No No Community
Continental Engineering Services Yes Yes Yes Yes Commercial
dSPACE No No SystemDesk RTE Generator SystemDesk Commercial
Elektrobit EB Tresos AutoCore EB Tresos Studio EB Tresos studio No Commercial
ETAS Yes Yes RTA ISOLAR-A Commercial
Freescale Yes [6] No Yes [6] Unknown Commercial
Dassault Systèmes No GCE RTEG AAT Commercial
KPIT Technologies Ltd. K-SAR Suite K-SAR Editor Yes K-SAR Editor Commercial
Mecel Yes Yes Yes Unknown Commercial
Mentor Graphics Volcano VSTAR Volcano VSTAR Volcano VSTAR Volcano Vehicle Systems Architect Commercial
OpenSynergy COQOS (OS and BSW Scheduler only) COQOS COQOS No Commercial
Renesas Electronics Yes No No No Commercial
see4sys Yes Yes Yes ECU-Designer Commercial
Vector Informatik GmbH MICROSAR DaVinci Configurator Pro MICROSAR Rte Generator PREEvision / DaVinci Developer Commercial

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.

With version 4.0 of AUTOSAR provides timing extensions[7] 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.

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.[8] 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.[9]

Standards process

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.[8]

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.[8]

References

  1. ↑ "Automated Defect Prevention for Embedded Software Quality" white paper by VDC Research
  2. ↑ Specification of the Virtual Functional Bus, V1.0.2, R3.1, Rev 0001 - Available on http://www.autosar.org
  3. ↑ 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
  4. ↑ Autosar Tutorial Presentation - Available on http://www.autosar.org
  5. ↑ 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
  6. ↑ 6.0 6.1 http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=AUTOSAR_CS&tid=vanAutoSAR
  7. ↑ "AUTOSAR Timing Extensions". AUTOSAR. Retrieved 8 May 2014.
  8. ↑ 8.0 8.1 8.2 Hammerschmidt, Christoph (22 May 2007). "Autosar standard not ready to plug-and-play". EE Times Europe. Retrieved 2009-06-30.
  9. ↑ Kai Barbehön, Axel Englisch, Andre Lajtkep (8 Oct 2008). "AUTOSAR – BMW’s strategy to introduce AUTOSAR.". Vector Congress 2008. Retrieved 2009-06-29.

Further reading

External links