AUTOSAR – The Standardized Software Architecture

The functional contents of the application software are different and related to the brand identity and the desired characteristics of the car manufacturer, or its system suppliers, whereas the functionality of the basic software is not visible to the customer and thus could been standardized by AUTOSAR in detail. 

The AUTOSAR layered architecture is offering all the mechanisms needed for software and hardware independence. It distinguishes between three main software layers which run on a Microcontroller (µC): Application Software, Runtime Environment (RTE) [4], and Basic Software (BSW) [5], Figure 2.

The AUTOSAR Basic Software is divided into the BSW layers: Services, ECU abstraction, microcontroller abstraction and complex drivers. The Basic Software layers are further divided into functional groups, for example System, Memory and Communication Services.

The complex drivers layer spans from the hardware to the Runtime Environment. It provides the possibility to integrate special purpose functionality, for instance drivers for devices which are not specified within AUTOSAR, having very high timing constrains, or are implemented because of migration purposes. The Runtime Environment abstracts the application layer from the basic software and organizes the data and information traffic between them. Above the RTE the software architecture style changes from “layered“ to “component style“. The application layer above the RTE is divided into software components. All software components are completely ECU-independent. The defined transfer interfaces of the RTE allow application software components to be developed without specific knowledge of what hardware will be used later. Also, existing software components can be transferred between ECUs freely. 

Although the memory footprint of an AUTOSAR software e.g. depends on the detail implementation, the contained application functions and their required basic software services, appropriate ECUs need at least 16bit architecture. Currently leanest AUTOSAR ECUs on the market seem to require about 256kB ROM or flash memory. 

 In addition to defining architecture and interfaces, AUTOSAR also includes a development methodology description [6, 7]. The AUTOSAR methodology describes the major development steps of an overall AUTOSAR system, which means the entire software for a network of interconnected ECUs in a vehicle. In AUTOSAR Release 4.0 the methodology is specified as a model yielding a set of HTML-documentation [8]. It addresses the wide range of software development from the system-level configuration to the generation of an ECU executable, and it supports a widely decoupled development and implementation of application functionality, as well as a seamless integration and configuration of both, the overall system and its individual ECUs. So the methodology is a guiding framework of how to use the AUTOSAR architecture. 

The methodology bases on the so-called “meta-model”. The meta-model precisely defines all elements to describe a self-contained AUTOSAR system. It is described in UML by means of a tailored profile. Any AUTOSAR description template is derived from this meta-model. The templates are XML files, usually with the extension ‘.arxml’. Figure 3 depicts an abstract top-level view on the methodology.

The functional architecture level deals with the Virtual Functional Bus (VFB) which enables the development of the functional architecture of the entire system independent from the actual hardware topology of ECUs and network. It is a partitioning or clustering of the application functions into components, i.e. the so called AUTOSAR software components (SWC). In order to formally handle and model SWCs and their interaction, each SWC needs a formal description: the SWC description. 

The next level considers the physical architecture of the entire system, i.e. the activity ‘design system’ leads to a system description that defines the system topology of ECUs, the network, and the mapping of components to ECUs. Before the software for each ECU can be built, the information regarding to this ECU have to be extracted from the system description. This allows building and integrating the software for each ECU separately from other ECUs. Of course, building the ECU software requires appropriate basic software for the ECU and all application software components mapped to the ECU.

 By now there is a broad variety of basic software implementations from different vendors for many hardware platforms on the market, so that the basic software and corresponding configuration tools can be regarded as off-the-shelf products. The development of the application software components with the definition of the internal behavior, coding, and implementation are independent from hardware and can be done separately for each component. In particular many model-based design tools on the market already can handle e.g. the SWC description and thus address the AUTOSAR methodology.

AUTOSAR supports software sharing by providing architecture, infrastructure, methodology and the basic software. AUTOSAR simplifies the combination of software by different providers. Baseline for such a scenario is the non-exclusive usage of AUTOSAR basic software provided by the host ECU. Software can be shared by vehicle platforms of the same OEM. In addition, standardized application interfaces support the exchangeability of software between suppliers. AUTOSAR specifies the interfaces of mature and often used applications from all automotive domains regarding their syntax and semantics [9]. This specification is aggregated in a common table, which contains by now nearly 2500 different ports and more than 500 interfaces. These are clustered into about 40 different compositions, and they use 770 data types and 26 units. 

For AUTOSAR Phase II (2007 - 2009) three releases had been planned, providing a continuous improvement of the specifications and introducing new concepts. Additionally, the experiences from the validation at the end of Phase I and generally considered feedback from all AUTOSAR stakeholders were incorporated. Release 3.0 was published early 2008 and included a large number of improvements, for example the harmonization of the ECU wake-up and the network start-up, and corrections with respect to the previous releases. Release 3.1 was dedicated to the incorporation of On-Board-Diagnostics (OBD) regulations support mechanisms. At the end of Phase II Release 4.0 integrated many new features, e.g. related to functional safety or communication, and was delivered by the end of 2009 after its validation. Conformance test specifications followed in an update of Release 4.0 by the end of 2010. In order to cover all vehicle functionalities, AUTOSAR has started working on two new car domains in the area of standardized application interfaces during Phase II including Telematics/Multimedia/HMI and Occupants and Pedestrian Safety Systems. Moreover, Powertrain, Chassis, and Body and Comfort interfaces have performed their first steps of integration. In the MM/T/HMI domain the focus was on HMI related application interfaces. A generic approach enables the separation of HMI related functions into a) a pure application service component – independent of the look and feel, b) user interface device components, e.g. for buttons, joysticks, etc., and c) an application controller, which is responsible for both, the HMI logic and the connection to the user interface. In the occupant and pedestrian safety domain the standardized interfaces belong to the eight compositions: sensor pool, actuator pool, seat belt reminder, vehicle crash detection, occupant restraint system detection, pedestrian protection crash detection, pedestrian protection system activation, and occupant detection. 

After having developed the standard specifying mature software architecture, AUTOSAR will selectively enhance the standard by adding specific features. Additionally, maintenance of the different releases used for series production will continue in order to support the distribution of AUTOSAR into the market. Consequently, AUTOSAR Phase III will center on one major release, Release 4.1, planned for end 2012 [10]. The proposed concepts for Release 4.1 are going to be elaborated and approved within a dedicated project phase similar as for Release 4.0. The approved concepts will jointly be worked out in 2010, Figure 4. 

Maintenance and selective additions to the standard are the main topics for Phase III. The additions will be specified in such a way that it is possible to ensure backward compatibility wherever feasible and/or to make reliable compatibility statements. In general, the additions shall support new technologies and trends, and shall extend existing functions. The detailed content will be defined during the concept phase of Release 4.1. 

As a result of its activities AUTOSAR has already provided several Releases, which comprise a set of specifications describing software architecture components and defining their interfaces. With Release 2.1 and Release 3.0/3.1 the majority of partners and members started their series roll-out of AUTOSAR. In order to ensure a smooth integration of basic software into a vehicle’s architecture, an AUTOSAR conformance test system has been defined. It addresses most basic software modules. The test will be conducted by accredited conformance test agencies. When introducing the AUTOSAR standard in series products dedicated migration scenarios need to be applied. Release 4.0 was the next big step of AUTOSAR in providing the features that were demanded by the different applications of the domains AUTOSAR is covering. The AUTOSAR community starts its implementation in 2010. The migration plans of the AUTOSAR Core Partners and Members are proving that it will become the standard for E/E systems in the automotive domain.

1. AUTOSAR Website, www.autosar.org 

2. Heinecke, Harald et al.: AUTOSAR – Current results and preparations for exploitation, Euroforum conference May 3rd 2006 

3. Fennel, Helmut et al.: Achievements and Exploitation of the AUTOSAR Development Partnership, SAE Convergence Congress, Detroit, 2006

 4. AUTOSAR Specification of RTE Software: AUTOSAR_SWS_RTE.pdf 

5. AUTOSAR BSW Layered Architecture: AUTOSAR_LayeredSoftwareArchitecture.pdf

 6. AUTOSAR Methodology: AUTOSAR_Methodology.pdf 

7. Bunzel, S.; Fennel, H.: The AUTOSAR Methodology. In (VDI): FISITA World Automotive Congress, Springer Automotive Media, September 2008; FISITA 2008/F2008-10-023.

 8. AUTOSAR R4.0 Specification: Methodology Model 

9. AUTOSAR R4.0 Specification: Table of Application Interfaces 

10. Fürst, Simon et al.: AUTOSAR – A Worldwide Standard is on the Road, 14th International VDI Congress Electronic Systems for Vehicles 2009, Baden-Baden 

Dr. Stefan Bunzel 
Continental Systems & Technology Automotive 
Guerickestr. 7
60488 Frankfurt/Main
E-Mail

© 2011 Informatik Spektrum, Springer-Verlag Berlin Heidelberg