CHAPTER 1: AUTOSAR Fundamentals

Topics Covered:

Evolution of AUTOSAR – Motivations and Objectives

AUTOSAR consortium – Stake holders – work Packages,
AUTOSAR Partnership – Goals of the partnership, Organization of the partnership,
AUTOSAR specification -- AUTOSAR 4.0 & 3.0
AUTOSAR Current development status
BSW Conformance classes: ICC1, ICC2, ICC3
Drawbacks of AUTOSAR.
What is AUTOSAR?
AUTomotive Open System ARchitecture (AUTOSAR).

Motivation
Today, development of electronic control units (ECUs) is characterized by several driving factors:

• Demands for more services, security, economy, and comfort

• Increasing complexity due to more ECUs and the growth in sharing software and functionality
• More diversity of ECU hardware and networks (controller area network [CAN], local interconnect
network [LIN], FlexRay, MOST, etc.)

As a result of these driving factors, communication between ECUs is increasing. Unfortunately, the ECU
networks are oriented for a distribution of automotive functions which, despite the fact that it has been
evolving for some time, is still not structured with respect to the newest technologies. The ECUs are
grouped into several sub domains, for example, power train, body, telematics, chassis, etc. Before
AUTomotive Open System ARchitecture (AUTOSAR), the networks of ECUs were neither standardized in
accordance with their interfaces across these sub domain borders nor developed with respect to the
interrelationships between the nodes of the network.
Comparable statements can be made for the development processes. The software development
processes for different ECUs evolved according to the individual history of the sub-domains, and were
quite divergent for a long time. In the automotive industry, most of the widespread system development
processes assign functional requirements to software and hardware components on a one-to-one basis.
2.1.1 Shortcomings in Former Software Structures

The increasing total share of software resulted in high complexity and high costs. This became more
critical with non standardized development processes and inadequate networks. In addition, the
incorporation of third-party software made the collaboration between companies even more complex.
An appropriate level of abstraction in the software architecture modeling and appropriate integration
concepts were still missing. The architectures did not reflect the effects of quality requirements. As a
consequence, these often remained vague and unexplored. The architectures evolving with a single
solution development strategy did not represent long-term solutions.
To further complicate matters, a lot of the functionalities are distributed over several ECUs, for example,
the software that controls the lights of the indicator functionality is distributed over up to eight ECUs in
high-end vehicles. Moreover, some of the future functionalities are not realizable with a loose side-by-side
of the ECUs, for example, drive-by-wire will need a very close and safe interlocking of ECUs across
different domains .The traditional split of automotive functions will require more and more interconnectivity
with the new upcoming functionalities.

2.1.2 Setting up AUTOSAR

With respect to this background, the leading automobile companies and their first-tier suppliers formed a
partnership in 2003.This partnership has established an industry wide standard for the automobile
electronic, AUTOSAR, which is headed by the following 10 “core partners”: BMW Group, Bosch,
Continental, DaimlerChrysler, Ford Motor Company, General Motors, PSA Peugeot Citroen, Siemens
VDO, Toyota Motor Corporation, and Volkswagen. The first phase of AUTOSAR started in 2003 and
ended in 2006. During this phase, 52 “premium members,” companies of the suppliers, and software and
semiconductor industries joined the development of this standard and made major contributions in the
consortium. In addition to these premium members, there are “associate members,” “development
members,” and “attendees,” whose roles in AUTOSAR varied with respect to their contribution and
exploitation (www.autosar.org).
The first phase of AUTOSAR finished at the end of 2006, and the first AUTOSAR products were made
available on the market. The members of AUTOSAR agree that AUTOSAR makes it possible to control
the complexity of the electrical and electronic components, together with an increase in quality and
profitability. The future of automotive engineering is in these modular and scalable AUTOSAR software
architectures.
Partnership
The partnership will actively involve third parties in its development by means of various
agreements, which will have specific roles and responsibilities associated with them.

The partnership has adopted a three-tier partnership structure which has been proven in similar
initiatives. Each tier of the partnership has specific rights and duties which are outlined in
appropriate agreements. Such third parties may have commercial supply or demand side
relationships with the partners and their admission will be permitted throughout the AUTOSAR
project life cycle.

Benefits Partnership
The realization of the AUTOSAR industry standard will provide significant benefits for OEMs,
leading suppliers as well as for tool providers and new market entrants.

Benefits for OEM:

• Establish development distribution among suppliers

• Compete on innovative functions with increased design flexibility
• Simplify software and system integration
• Reduce overall software development costs

Benefits for supplier:

• Reduce version proliferation

• Reuse software modules across OEMs
• Increase efficiency of application development
• Invent new business models

Benefits for tool provider:

• Interface with development processes

• Embed tools into an overall tool environment

Benefits for new market entrant:

• Enable new business models by means of standardized interfaces

Types Partnership
The partnership will involve third parties in the development of AUTOSAR
through the following types of partnership:

Premium Partners

Development Partners

Associate Partners

Attendees

Premium Partners
Every partner has rights and duties in the development partnership. The rights of a Premium
Partner are as follows:

• Right to use the AUTOSAR technology royalty-free and with a free-of-charge license for
automotive applications
• Access to current information and specifications
• Leadership of and cooperation in working groups
• Free of charge access to AUTOSAR related IP of all other AUTOSAR partners

The Premium Partner has to assign staff with such skills as it is required in the participating
working group. To achieve the targets of the working group, the Premium Partner contributes
work package related Intellectual Properties.

Development Partners
Every partner has rights and duties in the development partnership. The rights of a Development
Partner are as follows:

• Right to use the AUTOSAR technology royalty-free and with a free-of-charge license for
automotive applications
• Access to current information and specifications
• Cooperation in working groups
• Access to AUTOSAR related IP of all other AUTOSAR partners free of charge
The Development Partner has to assign staff with such skills as it is required in the participating
working group. To achieve the targets of the working group, the Development Partner
contributes work package related Intellectual Properties

Associate Partners
Every partner has rights and duties in the development partnership. The rights of an Associate
Partner are as follows:

• Right to use the AUTOSAR technology royalty-free and with a free-of-charge license for
automotive applications
• Access to information and the results of the development via administrator or homepage

Attendees
Each Attendee has rights and duties in the development partnership. The rights of an Attendee
are as follows:

• Access to current and relevant information and specifications

• Cooperation in working groups

2.1.3 Main Objectives of AUTOSAR

The main principle of AUTOSAR is “cooperate on standards, compete on implementation.” Thus, the
members established a set of main objectives, which also needed to be standardized because they were
not considered primary factors for competitiveness.
• Consideration of availability and safety requirements
• Redundancy activation
• Scalability to different vehicle and platform variants
• Implementation and standardization of basic functions as an industry wide “standard core” solution
• Transferability of functions from one ECU to another within the network of ECUs
• Integration of functional modules from multiple suppliers
• Maintainability throughout the whole product life cycle
• Increased use of commercial-off-the-shelf (COTS) hardware
• Software updates and upgrades over vehicle lifetime.

On all levels of modeling, an object-oriented eXtensible Markup Language (XML) classmodel, specified in
UML2.0, is used. Starting with the explanation of the description language you have to go down (via the
meta model-level) to a concrete user model, which can be realized as a concrete XML file.
The most important consequence of the stringent component-based approach of AUTOSAR, concerning
the development process, is a separation of application development from the lower levels of the
integration development (basic software [BSW]).
The separator between these two parts is the AUTOSAR runtime environment (RTE), which concretely
realizes the concept of a virtual functional bus (VFB) as an abstracting communication principle. The idea
of this concept is that an application does not need to know the concrete paths from data and signals
below RTE when two applications communicate together.

This simplifies matters for the application developer. He or she, de facto, needs no further knowledge
about concrete architectures, even if a deeper knowledge about the interfaces, made available to an
application on top of the RTE, is still indispensable (Figure 2.1).
Executive Board
The Executive Board is established to focus on the following areas:

• Decides on the overall strategy and roadmap of the AUTOSAR Development Partnership
• Takes office of organizational and administrative control like the appointment and
revocation of a Spokesperson, a Deputy Spokesperson and a Project Leader Team
Speaker of the AUTOSAR development cooperation
• Defines external information (web-release, clearance)

Steering Committee
The Steering Committee is established to focus on the following areas:

• Manages the admission of partners, public relations and contractual issues

• Coordinates the day-to-day non-technical operation of the AUTOSAR Development
Partnership
• Recommends changes to the development agreement
• Recommends changes to the annual contributions to the partners
• Admits Premium Partners, Associate Partners, Development Partners and Attendees

Project Leader Team

The Project Leader Team is established to focus on the following areas:

• Projects plans, financial plans and budgets within the budget framework
• Rules of procedures and establishes Working Groups
• Gives technical information throughout the AUTOSAR development cooperation
• Decides on technical questions related to the appropriateness of the respective Core
Partners' contributions to the AUTOSAR development

Working Groups
Working Groups are established to focus on the following areas:

• Specifies the AUTOSAR Runtime Environment to provide inter- and intra-ECU

communication across all nodes of a vehicle network
• Defines standardized interfaces across the different vehicle domains
• Defines requirements and analysis of existing solutions in the area of basic software
modules and automotive operating systems
• Defines data exchange formats for describing necessary elements of a vehicle’s E/E
system architecture

Each working group is staffed by the AUTOSAR partner companies who represent the extensive
knowledge and experience of the partnership partners from the various automotive domains.

Support Functions
The Administration is established to focus on the following areas:

• Supports the AUTOSAR Development Partnership in all organizational and

administrative issues
• Serves as the primary contact for all information requests from the public, partnership
applications, etc.
• Maintains the partnership server and homepage
• Supports processes of the technological, quality, specification and engineering
management
AUTOSAR specifications
From AUTOSAR 4.0:
• System Extract of System Description: For each ECU, the OEM reduces the System Description to a
System Extract of System Description, which the OEM can share with the suppliers of the relevant
ECU. This file replaces the .dbc, FIBEX or .ldf files that were previously used for configuration of the
BSW modules.
• ECU Extract of System Description (ECUEX): A process referred to as a “Flattening” is used to generate
an ECU Extract of System Description from the System Extract of System Description. This matches
the System Extract, but only contains the atomic SWCs in a flat perspective. The Tier1 can extend the
ECU Extract with SWCs generated in-house.

AUTOSAR 3:
• ECU Extract of System Description (ECUEX): For each ECU, the OEM reduces the System Description to
an ECU Extract of System Description, which the OEM can pass to the suppliers of the relevant ECU.
This file replaces the .dbc, FIBEX or .ldf files that were previously used for configuration of the BSW
modules.
• Complete ECU Extract of System Description: Starting from the ECU Extract of System Description, the
supplier integrates its own SWCs. The result is a complete and up-to-date ECU Extract of System
Description, which now contains a description of all SWCs of an ECU, from both the OEM and the
supplier.
2.3.2 BSW Conformance Classes

It would be a huge effort to switch from an existing platform to AUTOSAR in one step, as this would mean
implementing all 63 BSW modules, adapting the existing interfaces, and adapting the ASW to the
AUTOSAR interfaces. Furthermore, during the migration period, it is expected that in the next-generation
automotive systems there will be a mix of AUTOSAR and non-AUTOSAR software and ECUs.
In order to support and ease this migration, AUTOSAR defines three implementation conformance
classes (ICCs) for the BSW. The basic idea is to cluster the BSW modules so that only the interfaces
between these clusters have to be AUTOSAR conform, and it is not necessary to implement each BSW
module as a unit of its own.
Note that the ICCs only affect the BSW and the RTE. The interfaces of the software components above
the RTE are not affected. Thus, an ASW component can always be employed without changes to its
interface or implementation, regardless of the ICC of the underlying RTE and BSW.

ICC1
ICC1 is the “lowest” implementation conformance class. Here, the RTE and the entire BSW are put into
one cluster. Only the interface between the RTE and the ASW components and the interface to the bus
have to be AUTOSAR-conform. The interface between the RTE and the BSW is not standardized in this
case. Therefore, the RTE implementation is proprietary.
Nevertheless, an ICC1 implementation of BSW and RTE still has to provide the functionality and behavior
as standardized by AUTOSAR, for example, the scheduling of the runnable entities of the ASW
components or the communication between ASW components has to be the same as if the BSW
modules were not clustered. Furthermore, ASW components expect certain functionality from the BSW,
especially AUTOSAR services like the NVRAM manager or DEM. This functionality has to be provided,
although not necessarily, in the form of separate BSW modules.
An ICC1 implementation would typically be the first step in migrating from an existing proprietary
implementation to AUTOSAR.

ICC2
In ICC2 logically related modules are bundled into separate clusters, for example, all communication-
related modules form one cluster. The RTE is one cluster on its own.
The interfaces between the clusters, as well as the interfaces to the ASW components and to the bus
have to be AUTOSAR-conform.
ICC2 allows for integrating BSW clusters from different vendors, for example, one could use a
communication stack from vendor A and an operation system from vendor B.

ICC3
ICC3 implements the “highest” level of AUTOSAR compatibility. Here, all BSW modules as defined by
AUTOSAR are present with their corresponding interfaces. There is no clustering of modules.

What are the benefits of AUTOSAR for manufacturers, suppliers,

tool developers?
General benefits:
Increased re-use of software,
Increased design flexibility, Clear design rules for integration
Reduction of costs for software development and service in the long term
Focus on protected, innovative and competitive functions
Specific benefits for OEMs:
Functions of competitive nature can be developed separately
Later sharing of innovations is accessible
Standardized conformance process

Specific benefits for suppliers:

Reduction of version proliferation
Development sharing among suppliers
Increase of efficiency in functional development
New business models
Preparation for upcoming increase in software volume

Specific benefits for tool developers:

Common interfaces with development processes
Seamless, manageable, task optimized (time dependent) tool landscape

Specific benefits for new market entrants:

Transparent and defined interfaces enable new business models
Clear contractual task allocation and outsourcing of software-implementation accessible.

Drawbacks of AUTOSAR: The methodology used for mapping AUTOSAR concepts on

existing has serious drawbacks.

•If both the existing concept and the newly introduced AUTOSAR concept carry the same
information, there is a risk of inconsistency. There is also a risk of confusion over which
concepts to use, but this is easily resolved by making the old concept abstract thereby forcing the
use of the new concept

• Conflicting inheritance. Even if individual concepts map perfectly on each other, they can be
parts of inheritance structures violating AUTOSAR. On behalf of multiplied information and the
risk of inconsistency the problem can theoretically be resolved with multiple inheritances. In
practice the problems cannot be resolved; System Weaver does not support multiple inheritances.
The final part of the implementation of the prototype meta model in an existing meta model is
more of a demonstration piece; the implementation is what usually is called “ugly hack” In order
to implement a fully working AUTOSAR meta model the usual customization of the System
Weaver is necessary, not only with respect of customers needs but also with respect to
AUTOSAR´s requirements.