105

AUTOSAR
Simon Frst, Stefan Bunzel

7.1

Motivation fr AUTOSAR 106

7.2

Organisation der Partnerschaft AUTOSAR 106

7.3

Die neun Projektziele von AUTOSAR 107

7.4

Die drei Bereiche der Standardisierung 109

7.5

Systemarchitektur der virtuelle Funktionsbus (VFB) 112

7.6

Softwarearchitektur 112

7.7

Auswirkungen und Besonderheiten

bei der FAS-Entwicklung 116

7.8

Zusammenfassung 122
Literatur 122

H. Winner, S. Hakuli, F. Lotz, C. Singer (Hrsg.), Handbuch Fahrerassistenzsysteme, ATZ/MTZ-Fachbuch,

DOI 10.1007/978-3-658-05734-3_7, Springer Fachmedien Wiesbaden 2015

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

106

Kapitel 7 AUTOSAR

7.1

Motivation fr AUTOSAR

Softwareentwicklung im Fahrzeugbau gewann in

den letzten Jahrzehnten mehr und mehr an Bedeutung. Immer anspruchsvollere Anforderungen
an Sicherheit, Umweltschutz und Komfort fhrten
zu einem massiven Anstieg der Anzahl elektronischer Systeme im Fahrzeug. Neben immer strikteren gesetzlichen Auflagen, z. B. zu Emissionen
und Sicherheit, untermauert die rasante Zunahme
von Fahrerassistenzsystemen den Trend zu immer komplexeren elektronischen Systemen. Die
Funktionen von Fahrerassistenzsystemen setzen
verlssliche simultane Interaktionen zwischen den
vielfltigen Sensoren, Aktoren und Kontrollsystemen voraus. Kaum verwunderlich ist, dass mittlerweile fr mehr als 90 % aller Innovationen im
Fahrzeug Elektronik und Software verantwortlich
sind (vgl. [1]).
Diese rasante Entwicklung und die zunehmende Integration von Funktionen und Regelsystemen stellen eine Herausforderung fr alle Fahrzeughersteller dar. Um die wachsende Komplexitt
und die steigende Anzahl der Abhngigkeiten auf
der einen Seite zu beherrschen, die Kosten auf der
anderen Seite aber im akzeptablen Rahmen zu halten, mssen die Schnittstellen zwischen Hardware
und Basissoftware sowie zwischen Anwendungssoftware und Systemdiensten standardisiert werden.
AUTOSAR (AUTomotive Open System ARchitecture) arbeitet genau an dieser Standardisierung und hat mittlerweile mehrere Versionen des
AUTOSAR Standards verffentlicht, die in Serienprojekten zum Einsatz kommen. Im Vordergrund
steht das Beherrschen der Komplexitt durch Austauschbarkeit und Wiederverwendung von Softwarekomponenten wie beispielsweise bei Fahrerassistenzsystemen.
7.2

Organisation der Partnerschaft

AUTOSAR

Im Juli 2003 wurde AUTOSAR von fhrenden

Automobilherstellern und Zulieferern gegrndet.
Heute sind BMW, Bosch, Continental, Daimler,
Ford, General Motors, PSA, Toyota und Volks-

wagen die Core Partner von AUTOSAR. Sie sind

verantwortlich fr die Steuerung von AUTOSAR
sowie fr seine Verwaltung und Organisation. Darber hinaus ldt AUTOSAR andere Firmen ein,
sich zu beteiligen, ihre Erfahrung und ihr Wissen
einzubringen und im Gegenzug von AUTOSAR
und damit vom Wissen und der Erfahrung aller
Beteiligten zu profitieren. Es gibt verschiedene
Partnertypen: Core-Partner als auch Premium-,
Development- und Associate-Partner sowie Attendees wie in . Abb. 7.1 dargestellt.
Premium- und Development-Partner tragen
durch Wissen und aktive Teilnahme zur Entwicklung von Konzepten und Spezifikationen bei und
bestimmen dadurch den technischen Standard mit.
Associate-Partner profitieren, wie Premium- und
Development-Partner auch, von der kommerziellen
Nutzung des Standards. Forschungsinstitute und
Firmen, die als Dienstleister von AUTOSAR beauftragt werden, knnen sich als Attendee engagieren.
Attendees beteiligen sich an der Entwicklung von
AUTOSAR, haben aber keine Rechte an der kommerziellen Nutzung der AUTOSAR-Spezifikationen.
Zwei Gremien der Core-Partner steuern die Organisation: das Executive Board und das Steering
Committee. Das Executive Board ist das hchste
Entscheidungsgremium von AUTOSAR und legt
die Strategie und den bergeordneten Zeitplan fest.
Das Steering Committee koordiniert die tglichen,
nicht-technischen Unternehmungen und ist fr die
langfristigen Ziele verantwortlich.
Fr technische Angelegenheiten und fr die Koordination der technischen Work Packages ist das
Project Leader Team verantwortlich. Ebenso wie das
Executive Board und das Steering Committee ist das
Project Leader Team ein Core-Partner-Gremium.
Die Arbeit an den AUTOSAR-Spezifikationen
findet in Work Packages statt, die je nach Bedarf
in Untergruppen aufgeteilt sind. Hieran nehmen
Core-, Premium- und Development-Partner sowie
Attendees teil. . Abbildung 7.2 verdeutlicht die Einordnung der verschiedenen Gremien und Arbeitsgruppen zueinander.
Die AUTOSAR Support Functions untersttzen
die Partner bei der Administration, dem Projektund Qualittsmanagement, dem Spezifikationsmanagement und bei der technischen Entwicklung des
Standards.

107
7.3 Die neun Projektziele von AUTOSAR

. Abb.7.1 Struktur der

AUTOSAR-Partnerschaft [2]

Core Partners
! Organizational control
! Administrative control
! Leadership of Working
Groups
! Involvement in Working
Groups

Associate Partners
! Users of the AUTOSAR
standard
Attendee
Involvement in Working
Groups

Premium Partners
! Leadership of Working
Groups
! Involvement in Working
Groups

Development Partners
! Dedicated expertise
contributions
! Involvement in Working
Groups

Project Management

Administration

Quality
Management

Steering
Committee

Legal Team

Specification Management

Project Leader
Team

Communication
Team

Release
Management
Quality
Assurance

Work Packages

Change
Management

Support Functions

Technical
Management

Executive
Board

Engineering

Technical
Office

Project Organization
Core-Partner
Core-, Premium- and Development-Partner and Attendees
Sub-Contractors

. Abb.7.2 Struktur der AUTOSAR-Organisation [2]

Die technische Arbeit war zunchst zeitlich begrenzt und in Phasen untergliedert. Durch den groen Erfolg und das weitere zuknftige Potenzial arbeitet die AUTOSAR Partnerschaft seit 2013 nach
AUTOSAR PhaseI, II und III bis auf Widerruf
zeitlich unbegrenzt.

7.3

Die neun Projektziele

von AUTOSAR

Inhaltlich leitet sich die Arbeit der Partnerschaft aus

dem bergeordneten Ziel ab, die Komplexitt durch
Wiederverwendung und Austauschbarkeit von Softwarekomponenten, wie beispielsweise Fahrerassis-

108

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Kapitel 7 AUTOSAR

tenzsystemen, zwischen Fahrzeugherstellern und

Zulieferern zu beherrschen.
Dies fhrt zur Definition von neun Top-Zielen,
die als Project Objectives bezeichnet werden:
1. bertragbarkeit von Software.
OEM und Zulieferer sollen Software innerhalb
der Fahrzeugnetzwerke wiederverwenden knnen. Dadurch ist es z. B. mglich, die gleiche
Software auf unterschiedlichen Fahrzeugplattformen und bei unterschiedlichen Automobilherstellern zu verwenden.
2. Skalierbarkeit fr unterschiedliche Fahrzeuge
und Plattformvarianten.
AUTOSAR soll Mechanismen bereitstellen, damit Softwaresysteme entwickelt werden knnen,
die auf unterschiedliche Fahrzeuge, Fahrzeugplattformen und Hardware angepasst werden
knnen. Das heit, AUTOSAR soll konfigurierbar sein, so dass AUTOSAR-Systeme in unterschiedliche Fahrzeuge integriert werden knnen.
3. Untersttzung einer Vielzahl von Funktionsdomnen.
AUTOSAR soll die Verwendung von Softwarekomponenten in mglichst vielen Funktionsdomnen im Fahrzeug ermglichen. Dies schliet
den Datenaustausch zu Nicht-AUTOSAR-Systemen mit ein, wie z. B. die Kommunikation mit
dem Infotainmentsystem eines Fahrzeugs.
4. Definition einer offenen Architektur.
Die AUTOSAR-Architektur soll gewartet, angepasst und erweitert werden knnen. So knnen Fehler kontinuierlich behoben, zuknftige
Anforderungen und individuelle Erweiterungen
realisiert werden.
5. Untersttzung der Entwicklung von zuverlssigen Systemen.
Verfgbarkeit, Verlsslichkeit, Betriebssicherheit, Integritt, Wartbarkeit und Security sollen
durch AUTOSAR umsetzbar sein. So werden
beispielsweise Anforderungen an die funktionale Sicherheit bercksichtigt.
6. Nachhaltige Nutzung natrlicher Ressourcen.
Technologien zum effizienten Umgang mit natrlichen Ressourcen sowie der Einsatz erneuerbarer Energien sollen untersttzt werden.
7. Zusammenarbeit zwischen zahlreichen Partnern.
Die Automobilindustrie ist geprgt von der
weitreichenden Zusammenarbeit zwischen

Partnern. Durch die Definition von Datenaustauschformaten und einer Architektur, die die
Integration von Basis- und Anwendungssoftware von verschiedenen Partnern erlaubt, soll
AUTOSAR dies untersttzen.
8. Standardisierung von Basissoftwarefunktionalitt von Steuergerten (ECU) im Automobilbereich.
Die Basissoftware soll fr unterschiedliche
Funktionsdomnen, Fahrzeughersteller und
Zulieferer wiederverwendbar sein. So kann die
Basissoftware als Produkt am Markt angeboten
werden.
9. Untersttzung von relevanten internationalen
Automobilstandards und etablierten technischen Lsungen.
AUTOSAR soll mit existierenden und relevanten internationalen Standards kompatibel sein.
Dies ermglicht den Einsatz von AUTOSAR in
heutigen und zuknftigen Fahrzeugsystemen.
Ein Beispiel ist die Untersttzung existierender
und zuknftiger Bussysteme wie FlexRay, CAN,
Ethernet etc.
Diese Projektziele werden in der AUTOSAR Main
Requirements Specification in bergeordnete Anforderungen an das System detailliert. Ein Beispiel
verdeutlicht das:
Das Projektziel bertragbarkeit von Software
wird auf die folgenden Hauptanforderungen heruntergebrochen:
Die Softwarearchitektur von AUTOSAR soll in
funktionale Schichten gegliedert werden.
AUTOSAR soll eine Entkopplungsschicht
von der Hardware bereitstellen, um mglichst
groe Teile der Software hardwareunabhngig
zu gestalten.
AUTOSAR soll die freie Verteilung von Anwendungssoftware im Bordnetz erlauben.

Von den bergeordneten Anforderungen werden die

Haupteigenschaften und Kernfunktionen des Systems
abgeleitet, die sogenannten Features. Aus diesen folgen wiederum die Software Requirements Specifications (SRS). Die Detaillierung dieser Anforderungen
an die Software findet sich dann in den Software
Specifications (SWS). Diese Zusammenhnge sind in
. Abb. 7.3 dargestellt. Die Software Specifications

109
7.4 Die drei Bereiche der Standardisierung

Project Objectives

Main Requirements

Features

Requirements

Specifications

Feature 1

SRS

SWS

PO 2

Main11

Feature 2

SRS

SWS

PO 3

...

...

SRS

SWS

...
...

PO 7

...

PO 8

...

PO 9

Main n

Level 1

...

PO 6

...

...

PO 5

Concretization

PO 4

SRS

SWS

SRS

SWS

RS

TPS

...

RS

TPS

Feature x

RS

TPS

...
...
...
...

Level 2

Specification of Software

Main10

Detailing and Specification

PO 1

Level 3

Level 4

Level 5

. Abb.7.3 Beziehung zwischen den AUTOSAR-Spezifikationen [2]

bilden schlielich die Grundlage fr die Implementierung des AUTOSAR-Standards in Software.

7.4

Die drei Bereiche

der Standardisierung

Die Standardisierung von AUTOSAR unterteilt sich

in die drei Bereiche Softwarearchitektur, Entwurfsmethodik und Anwendungsschnittstellen.
7.4.1

Softwarearchitektur

Das Hauptkonzept der standardisierten ECU-Softwarearchitektur, siehe . Abb. 7.4, besteht aus der
Trennung von hardwareunabhngiger Anwendungssoftware und hardwareorientierter Basic Software
(BSW). Dies wird erreicht durch die Software-Abstraktionsschicht Runtime Environment (RTE).
Auf der einen Seite ermglicht diese Abstraktionsschicht die Entwicklung von OEM-spezifischen
und wettbewerbsrelevanten Software-Anwendungen wie Fahrerassistenzsystemen. Auf der anderen
Seite erlaubt sie die Standardisierung von OEM-unabhngiger BSW. Sie ist ferner die Voraussetzung
fr die Skalierbarkeit der ECU-Software fr ver-

schiedene Fahrzeugproduktlinien und -varianten,

die Mglichkeit, Anwendungen auf mehrere ECUs
zu verteilen und Softwarekomponenten aus unterschiedlichen Quellen zu integrieren, wie in Abschn. 7.6.4 dargelegt.
Die BSW innerhalb der AUTOSAR-Softwarearchitektur ist weiter unterteilt in die Schichten
Services, ECU Abstraction und Microcontroller Abstraction, die in Abschn. 7.6.3 ausfhrlich
beschrieben werden. Die Separation der Anwendungsschicht von der BSW ist durch die RTE realisiert, die Kontrollmechanismen zum Datenaustausch zwischen diesen Schichten enthlt. Dies
bildet die Grundlage fr eine komponentenorientierte, hardwareunabhngige Softwarestruktur auf
Anwendungsebene mit Softwarekomponenten als
eigenstndigen Einheiten.
Beispielsweise wird die Funktion eines Fahrerassistenzsystems durch Softwarekomponenten
umgesetzt, welche die Anwendung bilden. Die
einzelnen Softwarekomponenten kommunizieren
direkt nur mit der RTE. Damit gestaltet sich die
Kommunikation transparent, unabhngig davon, ob
sie innerhalb eines Steuergertes oder ber Steuergertegrenzen hinweg stattfindet.
Durch diese Unabhngigkeit wird es ermglicht, Softwarekomponenten ohne spezifisches

Kapitel 7 AUTOSAR

110

Software
Components

Application Layer

2
3
4
5
6
7
8
9
10

13
14
15
16
17
18
19
20

System Services

Memory
Services

Communication
Services

Onboard
Device
Abstraction

Memory
Hardware
Abstraction

Communication
Hardware
Abstraction

Microcontroller
Drivers

Memory
Drivers

Communication
Drivers

I/O Hardware
Abstraction

Complex
Drivers

Services

ECU
Abstraction

Microcontroller
Abstraction

ECU
Resources

I/O Drivers

Microcontroller

. Abb.7.4 AUTOSAR-Softwarearchitektur [2]

Wissen ber die verwendete oder geplante Hardware zu entwickeln bzw. die bestehenden Softwarekomponenten flexibel zwischen den ECUs zu
verteilen.

11
12

Runtime Environment

Middle Ware
Basic Software

7.4.2

Entwurfsmethodik

Neben der Softwarearchitektur standardisiert

AUTOSAR auch die Methodik der Softwareentwicklung im Automobilbereich, vor allem, um die Zusammenarbeit der beteiligten Partner zu erleichtern.
Die AUTOSAR-Entwurfsmethodik adressiert
besonders Aspekte, die notwendig sind, um Softwarekomponenten in eine ECU und verschiedene
ECUs in die gesamte Netzwerkskommunikation mit
unterschiedlichsten Bussystemen zu integrieren.
Sie definiert die Abhngigkeiten von Aktivitten
fr Arbeitsprodukte und untersttzt Aktivitten,
Beschreibungen und Nutzung von Werkzeugen in
AUTOSAR. Die Methodik wird in der Entwicklung
der Anwendungssoftware, siehe Abschn. 7.6.1, der
Laufzeitumgebung, siehe Abschn. 7.6.2, sowie in
der Systemkonfiguration, siehe Abschn. 7.6.4, angewandt.
Fr Informationen, die in der AUTOSAR-Entwurfsmethodik entstehen oder verwendet werden,
hat AUTOSAR ein formales Datenaustauschformat

(AUTOSAR-Schema) mit entsprechenden semantischen Randbedingungen definiert. Die Informationen werden dann als formale Beschreibungen
in AUTOSAR XML (.arxml)-Dateien gespeichert.
Zahlreiche Tools verwenden diese Beschreibungen
fr die Konfiguration und Generierung von RTE
und BSW. Beispielsweise bietet die Softwarekomponentenbeschreibung ein standardisiertes Komponentenmodell fr Anwendungssoftware. Ein
anderes Beispiel ist die Systembeschreibung. Sie
definiert die Beziehung zwischen der reinen Softwaresicht auf das System und der physikalischen
Systemarchitektur mit vernetzten ECU-Instanzen.
Sie beschreibt die Netzwerktopologie, die Kommunikation fr jeden Kanal und die Zuteilung
der Softwarekomponenten auf die verschiedenen
ECUs.
Das Prinzip der AUTOSAR-Entwurfsmethodik
ist in . Abb. 7.5 dargestellt.
Neben der Grundfhigkeit, E/E-Systeme im
Automobilbereich zu beschreiben, gibt es viele
Aspekte, die durch praktische Austauschformate
untersttzt werden mssen, wie Dokumentation,
Anforderungsverfolgung und Lebenszyklen verschiedener Artefakte.
Das integrierte Variantenmanagement erlaubt
OEMs und Zulieferern darber hinaus, grundlegende AUTOSAR-Produktlinien zu formulieren

111
7.4 Die drei Bereiche der Standardisierung

Component
API
Generator

SWComponent
Description

ECU
Resource
Description
(HW only)

System
Constraint
Description

Component
API
e.g. app.h

SWC
Implementation
ECU Configuration
Description

System
Configuration
Description

AUTOSAR
System
Configuration
Generator

Decisions
(e.g. mapping)

AUTOSAR
ECU
Configuration
Generator

ECU extract
of System
Configuration

ECU extract
of System
Configuration

Information / Database
Generation step:
complex algorithm or engineering work

Decisions
(e.g. scheduling)

System per ECU

RTE Extract of
ECU Configuration

AUTOSAR
RTE
Generator

OS Extract of
ECU Configuration

OS, COM,
Generator

e.g. OIL
Basic SW
Basic SW
ModuleBasic
A extract
SW
Module A extract
of
ECUA Extract
Module
of ECU
configuration
of ECU
configuration
Configuration
List of
Implementations
of SW
Components

Other Basic
SW Generator

MCAL
Generator

. Abb.7.5 Prinzip der AUTOSAR Entwurfsmethodik [2]

Software
Components

Application
Software
Component

Actuator
Software
Component

Sensor
Software
Component

AUTOSAR
Interface

AUTOSAR
Interface

AUTOSAR
Interface

Middle Ware

Application Layer

Application
Software
Component
AUTOSAR
Interface

Runtime Environment

. Abb.7.6 AUTOSAR-Anwendungsschnittstellen die dargestellten Schnittstellensymbole sind in . Abb. 7.9 beschrieben. [2]

und diese Informationen, wann immer notwendig, mit ihren Partnern auszutauschen. Denn das
gemeinsame Verstndnis und die abgestimmte Interpretation ber diese Varianten sind ein Schlsselelement fr die erfolgreiche Zusammenarbeit in
gemeinsamen Projekten.
7.4.3

Anwendungsschnittstellen

Die Anbindung der Anwendungskomponenten

an die RTE wird durch Anwendungsschnittstellen sichergestellt, wie in . Abb. 7.6 dargestellt.
AUTOSAR standardisiert zum einen den grundstzlichen Schnittstellenmechanismus mit der Syntax
und zum anderen auch die Semantik der Anwen-

dungsschnittstellen in den Fahrzeugbereichen Karosserie, Innenraum und Komfort, Antriebsstrang,

Fahrwerk, sowie Insassen- und Fugngerschutz.
Dabei liegt der Fokus auf den Schnittstellenspezifikationen fr allgemein eingefhrte Applikationen,
um die Wiederverwendung und den Austausch von
Softwarekomponenten zu ermglichen. Schlielich
ist der Einsatz von standardisierten Anwendungsschnittstellen fr die Wiederverwendung von Anwendungen von entscheidender Bedeutung.
Die Schnittstellenspezifikationen werden von
Experten aller AUTOSAR-Partner standardisiert.
Dies umfasst beispielsweise verwendete Datentypen, Einheiten und Skalierungsfaktoren. Sie ermglichen Software-Architekten und -Entwicklern, sie
im Falle von Erweiterungen oder Wiederverwen-

112

Kapitel 7 AUTOSAR

SWC Description
Virtual Integration
SWC 1

2
3
4

SWC 2

Introduction of HW
Attributes

ECU
Descriptions

ECU Configuration

System
Description

11
12
13
14
15
16
17
18
19
20

ECU II
SWC 2

ECU n

SWC 3

RTE

RTE

BSW

BSW

Systemarchitektur
der virtuelle Funktionsbus
(VFB)

Zur Entwicklung der funktionalen Systemarchitektur hat AUTOSAR das Konzept des virtuellen Funktionsbusses, des VFB, eingefhrt. Der VFB erlaubt
es, die funktionale Interaktion von Anwendungskomponenten systemweit also bis hin zu einem
Gesamtfahrzeug zu beschreiben. Diese Beschreibung ist unabhngig von der tatschlichen Steuergertearchitektur sowie dem realisierten Netzwerk.
Damit abstrahiert der VFB die Anwendungen von
der Hardware. Einzelne Anwendungen werden bei
AUTOSAR als Softwarekomponenten (SWC) beschrieben. Der VFB stellt den Softwarekomponen-

SWC n
...

RTE
BSW

Gateway

FlexRay

dungen von Softwarekomponenten unabhngig von

einer spezifischen Hardware bzw. ECU zu nutzen.
Anwendungen wie Fahrerassistenzsysteme
enthalten wettbewerbsdifferenzierende Merkmale.
Daher standardisiert AUTOSAR nicht das interne
funktionale Verhalten einer Anwendung, wie z. B.
Algorithmen, sondern die Informationen, die zwischen den Anwendungen ausgetauscht werden. Typische Beispiele fr Anwendungen sind Fahrerassistenzsysteme, wie sie in TeilI beschrieben werden.
7.5

System
Constraint
Description

ECU
Description

ECU I
SWC 1

10

SWC n

Tools supporting development

of software components

...

SWC 3

Virtual
Functional Bus

5
6

Application
Layer

. Abb.7.7 berblick
ber die AUTOSAR-Entwurfsmethodik [2]

CAN

ten sowohl die Mechanismen fr die Kommunikation untereinander als auch die Mechanismen fr
die Nutzung der Dienste der Basissoftware zur Verfgung, siehe . Abb. 7.7, oberer Teil. Die verschiedenen Mechanismen werden durch sogenannte
Ports dargestellt (vgl. Abschn. 7.6.1).
Die funktionale Systemarchitektur wird im
weiteren Verlauf der Entwicklung auf eine physikalische Architektur, d. h. auf eine Steuergerte- und
Netzwerktopologie, abgebildet. Hierbei werden die
Softwarekomponenten den Steuergerten zugewiesen; auf jedem Steuergert wird die Funktion des
VFB durch die RTE und die darunterliegende Basissoftware realisiert, siehe . Abb. 7.7, unterer Teil.
Zur Vermeidung von Missverstndnissen sei
explizit darauf hingewiesen: AUTOSAR hat das
VFB-Konzept spezifiziert. Fr Entwickler anwendbar umgesetzt ist dieses Konzept in diversen auf
dem Markt verfgbaren Werkzeugen zur Systemarchitekturentwicklung.
7.6
7.6.1

Softwarearchitektur
Anwendungssoftware

Das Schichtenmodell der AUTOSAR-Softwarearchitektur platziert Anwendungssoftware in Form

113
7.6 Softwarearchitektur

. Abb.7.8 Kommunikationspfade innerhalb

eines Steuergertes und
zwischen mehreren Steuergerten [2]

ECU I

ECU II

SWC
A

SWC
B

SWC
C

Application

Ports
RTE

VFB

RTE

BSW

AUTOSAR
Infrastructure

BSW

Hardware
Communication Bus

Sensor

Communication Path

von Softwarekomponenten in der Anwendungsschicht, siehe . Abb. 7.6. Softwarekomponenten

knnen zu Kompositionen gruppiert werden, die
sich wiederum nach auen wie eine Softwarekomponente verhalten. Durch dieses generische Komponentenkonzept lassen sich beliebig verschachtelte
Hierarchien von Softwarekomponenten als System
realisieren. Die Anwendungssoftware kann somit
sowohl hardwareunabhngig als auch hierarchisch
ausgelegt und entwickelt werden.
Softwarekomponenten kommunizieren ber
Ports, die jeweils einen bestimmten Kommunikationsmechanismus abbilden. Die wichtigsten Mechanismen in der Kommunikation zwischen Anwendungen sind Sender-Receiver fr vom Sender der
Daten initiierte Kommunikation sowie Client-Server fr vom Empfnger initiierte Kommunikation.
Darber hinaus gibt es weitere Ports zur Ablaufsteuerung (External trigger events) oder zum Zugriff auf
bestimmte Parameter (Kalibrierung, Betriebsmodi,
Non-Volatile-Memory). Jeder Port besitzt ein Interface, in dem die zu kommunizierenden Datentypen
festgelegt sind. AUTOSAR hat eine przise Abbildung
der Ports auf die Programmiersprache C definiert.
. Abbildung 7.8 zeigt den Kommunikationspfad innerhalb eines Steuergertes und zwischen Anwendungen in unterschiedlichen Steuergerten auf.
Eine Softwarekomponente wird formal durch
eine spezielle AUTOSAR-Beschreibung, durch

das Software Component Template, beschrieben,

siehe . Abb. 7.9. Darin wird neben den Ports und
den Interfaces auch das sogenannte Internal Behavior beschrieben. Dieser Begriff ist bei AUTOSAR
historisch gewachsen, fhrt aber leider immer wieder zu Missverstndnissen. Internal Behavior
beschreibt die Komponente hinsichtlich zeitlicher
oder ereignisbezogener Ablaufsteuerung (Events
und Scheduling). Dazu gehrt auch die Definition
der Runnable Entities, d. h. der kleinsten ber das
unterlagerte Betriebssystem auf Ereignisse oder
Zeiten hin einplanbaren Softwareeinheiten. Zum
Internal Behavior gehren ausdrcklich nicht die
in der Komponente zu implementierenden Algorithmen.
In der Praxis gibt es mehrere typische Wege, die
Softwarekomponentenbeschreibung auszufllen
oder zu editieren: Viele Entwurfswerkzeuge fr die
modellbasierte Entwicklung knnen direkt die zu
einem grafischen Modell gehrige Softwarekomponentenbeschreibung generieren bzw. erlauben
die Bearbeitung der entsprechenden Eintrge darin. Auch der RTE-Generator (vgl. Abschn. 7.6.2)
erlaubt in der Regel eine Bearbeitung der Softwarekomponentenbeschreibung.
Fr Anwendungen mit spezifischen Hardwareanforderungen wie beispielsweise Software, die auf
bestimmte Sensoren oder Aktoren angewiesen ist,
hat AUTOSAR sogenannte Sensor-/Aktor-Soft-

Kapitel 7 AUTOSAR

114

1
2
3

SWC
Description

10
11
12
13
14
15
16
17
18
19
20

RPort, requires a Client-Server Interface, i.e. client of a service

PPort, provides a Calibration Interface
RPort, requires a Calibration Interface
PPort, provides data to AUTOSAR Service
RPort, requires data from AUTOSAR Service
PPort, provides AUTOSAR Service (in BSW only)

. Abb.7.9 AUTOSARSoftwarekomponentenbeschreibung [2]

PPort, provides a Client-Server Interface, i.e. implements service

AUTOSAR
SWC

RPort, requires a Sender-Receiver Interface

Ports
Interfaces
Internal Behavior
Runnable Entities
Events

PPort, provides a Sender-Receiver Interface

RPort, requires AUTOSAR Service as client

ware-Komponenten vorgesehen, bei denen derartige Randbedingungen in der Softwarekomponentenbeschreibung vermerkt werden knnen.
7.6.2

Laufzeitumgebung (RTE)

Die AUTOSAR-Laufzeitumgebung (Runtime Environment, RTE) abstrahiert die Anwendungen

von jeglichen Implementierungsdetails der Basissoftware und von der Hardware eines Steuergertes.
Es stellt die Laufzeitimplementierung des VFB (vgl.
Abschn. 7.5) auf einer spezifischen ECU dar. Die
RTE bietet allen Anwendungen eines Steuergertes
die Mechanismen fr die Kommunikation untereinander sowie die Mechanismen fr den Zugriff auf
Dienste der Basissoftware. Dazu gehrt auch die Bereitstellung von Datenpuffern und Warteschlangen
fr die Kommunikation.
Der tatschliche Programmcode der RTE ist
von den Anwendungen, deren Kommunikation,
den verwendeten Basissoftwarediensten und dem
Scheduling abhngig. Der Code wird in der Praxis
vom RTE-Generator entsprechend den Informationen aus den Softwarekomponentenbeschreibungen
erzeugt.
Genau genommen ist die RTE eine Middleware-Schichttechnologie, die die Verschiebbarkeit
von Komponenten der Anwendungsschicht ber
ein dezentralisiertes Netzwerk ermglicht.

7.6.3

Basissoftware (BSW)

Die Basissoftware stellt den Anwendungen ber

die RTE alle Systemdienste und -funktionen zur
Verfgung. Die Funktionen der Basissoftware sind
fr die Anwendungen zwar essenziell, werden aber
typischerweise von einem Fahrzeugnutzer nicht
wahrgenommen. Die Basissoftware gliedert sich
weiter in Schichten mit zunehmender Abhngigkeit
von der Hardware: Service- bzw. Diensteschicht,
ECU-Abstraktionsschicht, Mikrocontroller-Abstraktionsschicht. Jede dieser Schichten enthlt
wiederum einzelne Module, die jeweils einen von
AUTOSAR genau spezifizierten Funktionsumfang
abbilden. Insgesamt enthlt die AUTOSAR-Basissoftware rund 80 verschiedene Module, fr die der
Standard jeweils eine Anforderungs- und eine Softwarespezifikation enthlt. Darin sind das funktionale Verhalten des Moduls und seine Schnittstellen
in C definiert. Somit sind zwei verschiedene, aber
standardkonforme Implementierungen eines Moduls direkt austauschbar. Die Parametrierung des
funktionalen Verhaltens eines Basissoftwaremoduls
bzw. seine Konfiguration verwendet den gleichen
formalen Beschreibungsmechanismus wie Anwendungskomponenten. Die Konfigurationsbeschreibungen der Basissoftwaremodule eines Steuergertes werden in der ECU-Konfigurationsbeschreibung
zusammengefasst.

115
7.6 Softwarearchitektur

7.6.3.1

Services

Die Schicht der Services umfasst Systemdienste

wie Kommunikationsdienste, Diagnoseprotokolle,
Speicherdienste, Management der ECU-Betriebsmodi, aber auch das AUTOSAR-Betriebssystem
(OS) als ein eigenstndiges Modul. Das AUTOSAR
OS basiert auf dem Echtzeitbetriebssystemstandard
OSEK/VDX und wurde in einigen Bereichen erweitert, in anderen auch eingeschrnkt. Es wird statisch
konfiguriert und skaliert und bietet priorittsbasiertes Echtzeitverhalten sowie die Behandlung von Interrupts. Zur Laufzeit sind diverse Schutzmechanismen fr Speicherzugriffe bzw. fr das Zeitverhalten
verfgbar. Das AUTOSAR OS eignet sich auch fr
kleine, leistungsschwchere Mikrocontroller, untersttzt aber inzwischen auch den Multicore-Einsatz
und die Verwendung mehrerer Speicherpartitionen
sowohl fr Code als auch fr Daten.
Die Module der Services sind abgesehen vom
Betriebssystem hardwareunabhngig. Diese Systemdienste stehen den Anwendungen ber die
RTE zur Verfgung. Auf darunterliegende Basissoftwaremodule knnen Anwendungen nicht direkt zugreifen. Dies ist den Services vorbehalten,
um im Rahmen ihrer Funktion auf ECU- oder
Mikrocontroller-Ressourcen zuzugreifen. Ein Servicemodul und seine darunterliegenden Module
werden auch als funktionale Stacks bezeichnet, beispielsweise der Kommunikationsstack fr FlexRay.
Solche Stacks werden oft als Einheit implementiert
und integriert. Dies unterluft zwar das Abstraktionsprinzip und reduziert die Flexibilitt, ermglicht aber eine hhere Effizienz und Leistung einer
Implementierung.

7.6.3.2

Hardwareabstraktion

Die Schichten unterhalb der Services dienen

der Hardwareabstraktion. Zunchst trennt die
ECU-Abstraktionsschicht das ECU-Layout (d. h.
wie die Peripheriemodule mit dem Mikrocontroller verbunden sind) von den oberen Schichten. Obwohl diese Schicht ECU-spezifisch ist, ist
sie unabhngig vom Mikrocontroller. Die nchste
Abstraktionsstufe wird durch die Mikrocontroller-Abstraktionsschicht erreicht, die mikrocontrollerspezifische Treiber umfasst. Diese Treiber sind
beispielsweise I/O-Treiber fr digitale Ein- und
Ausgnge oder ADC-Treiber zur Wandlung analo-

ger Signale in digitale Werte. Damit wird standardisierte Hardware direkt vom AUTOSAR-Standard
untersttzt.
Die Schicht der komplexen Treiber dient zur
Behandlung von Spezialfllen, z. B. zur Ansteuerung von komplexen Sensoren oder Aktoren mit
besonderen Echtzeitanforderungen oder mit spezifischen elektromechanischen Hardwareanforderungen. Solche Module werden von AUTOSAR
nicht als Basissoftwaremodule standardisiert, da
hierzu spezifisches Fachwissen und geistiges Eigentum der Automobilhersteller oder der Zulieferer erforderlich wre. Allerdings mssen die
komplexen Treiber ebenso wie die standardisierten Module den Anforderungen fr Schnittstellenmechanismen in der AUTOSAR-Basissoftware
gengen.
7.6.4

Systemkonfiguration

Im AUTOSAR-Kontext bezieht sich System auf

einen Verbund vernetzter Steuergerte, der auch
smtliche Steuergerte eines Fahrzeugs umfassen
kann. Die Systemkonfiguration schliet sich an die
Entwicklung der funktionalen Systemarchitektur
auf der VFB-Ebene an, siehe . Abb. 7.10. Mit der
Systemkonfiguration werden Designentscheidungen zur tatschlichen, physikalischen Architektur
des Systems getroffen. Diese Entscheidungen betreffen vor allem die Systemtopologie, d. h. welche
Steuergerte vorhanden und wie diese vernetzt
sind. Zu den einzelnen Steuergerten kommt eine
Beschreibung der verfgbaren Ressourcen bezglich Prozessorarchitektur, Prozessorkapazitten,
Speicher, Schnittstellen, Peripherien oder Signalisierungsmethoden hinzu. Die Beschreibung der
Netzwerktopologie reicht von den Bussystemen
bis zur Kommunikationsmatrix einzelner Kanle. Hinzu kommt auch die Festlegung, welche
Anwendungssoftwarekomponenten auf welchem
Steuergert laufen sollen. All diese Informationen
werden in der Systembeschreibung eingetragen: In
der Praxis erfolgt dies entweder mittels Systemarchitekturdesigntools wie auch fr das VFB-Design
dann spricht man auch vom Systemgenerator
oder aber mittels der Konfigurationstools fr die
Basissoftwaremodule.

116

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Kapitel 7 AUTOSAR

Component modeling
Data model development
VFB Timing

Functional
architecture
VFB level

Develop
VFB System Description

Physical
architecture
System &
ECU level

Design
System

Internal behavior
Implementation
Component timing

System topology
Network, buses
Mapping of
components to ECUs

Develop
Application Software Component

BSW Implementation
BSW Configuration
Deliver
Basic Software

Generate
ECU Extract

Build
ECU Software

Hardware
dependent

Hardware
independent

. Abb.7.10 Von der funktionalen Architektur zur ausfhrbaren Software [2]

Nach der Systemkonfiguration erfolgt die

weitere Konfiguration der einzelnen Steuergerte
und schlielich auch die Softwareintegration unabhngig voneinander, d. h. nach Bedarf parallel.
Hierzu werden aus der Systemkonfiguration alle
fr ein bestimmtes Steuergert relevanten Informationen in die ECU-Beschreibung kopiert, was als
ECU-Extrakt der Systembeschreibung bezeichnet
wird. In der ECU-Beschreibung werden auch die
Konfigurationsbeschreibungen der einzelnen Basissoftwaremodule aggregiert. Viele Parameter der
Basissoftwarekonfiguration ergeben sich direkt aus
der Systembeschreibung oder den Softwarekomponentenbeschreibungen. Die verbleibenden freien
Parameter werden mithilfe des Basissoftwarekonfigurationstools eingestellt. Bei den meisten Basissoftwaremodulen wird nach der Konfiguration wie
bei der RTE der zur Konfiguration gehrige Code
von einem Generator erzeugt.
Die Implementierung der Anwendungssoftwarekomponenten also die Erstellung der Algorithmen und deren Codierung kann vllig parallel zur Systemkonfiguration erfolgen, da dieser
Schritt hardwareunabhngig ist. Letztlich wird fr
jedes Steuergert der gesamte Code der Basissoftware mit dem RTE-Code und dem Code aller Anwendungssoftwarekomponenten zur ECU-Software
integriert.

7.7

Auswirkungen
und Besonderheiten
bei der FAS-Entwicklung

Der AUTOSAR-Standard wurde fr die Entwicklung der Software des gesamten elektrischen/elektronischen Systems im Fahrzeug entworfen. Die
einzige Ausnahme bilden Infotainmentsysteme, da
deren Softwaregestaltung sehr nahe an der Consumer Electronic liegt, wodurch viele von deren
grundstzlichen Mechanismen wie beispielsweise
dynamische Speicherverwaltung verwendet werden.
Fahrerassistenzsysteme liegen damit im
Anwendungsbereich des AUTOSAR-Standards.
Auf einige der speziellen Mechanismen, die der
AUTOSAR-Standard fr die Fahrerassistenzsysteme
bereithlt, wird im Nachfolgenden eingegangen.
7.7.1

Entwicklung verteilter
Echtzeitsysteme

Fahrerassistenzsysteme sind hufig durch komplexe

Algorithmen, hohe Sicherheitsanforderungen und
vielfltige Sensorik charakterisiert. Sie eignen sich
besonders fr eine Realisierung als verteiltes Echtzeitsystem, weil z. B. Sensordaten auf einem Steuergert vorverarbeitet werden und der eigentliche

117
7.7 Auswirkungen und Besonderheiten bei der FAS-Entwicklung

Regelalgorithmus auf einem anderen Steuergert

abgearbeitet wird oder weil berwachungs- oder
Diagnosefunktionen auf einem separaten Steuergert implementiert sind. AUTOSAR vereinfacht die
Entwicklung verteilter Echtzeitsysteme hinsichtlich
verschiedener Aspekte:
Die Implementierung von Anwendungssoftware die Codierung ist entkoppelt vom
Entwurf der funktionalen und physikalischen
Architektur bzw. von der Systemkonfiguration.
Die AUTOSAR-Entwurfsmethodik erlaubt
eine flexible Verteilung von Anwendungssoftware auf mehrere Steuergerte. Obwohl
die Systemkonfiguration und damit auch die
Verteilung der Softwarekomponenten auf Steuergerte statisch ist, kann die Verteilung zwar
nicht zur Laufzeit, aber vergleichsweise einfach
whrend des Entwurfsprozesses gendert
werden.
Fr Softwarekomponenten knnen Anforderungen an Lauf- und Ausfhrungszeiten
bercksichtigt werden. So knnen Voraussetzungen fr einzelne Steuergerte oder fr das
Gesamtsystem definiert werden, aber auch
fr andere verfgbaren Ressourcen. Diese
Informationen sind whrend des gesamten
Entwicklungsprozesses verfgbar und werden
durch geeignete Softwareentwicklungswerkzeuge bercksichtigt. Beispielsweise kann fr
einen Spurhalteassistenten nun eine maximale
Laufzeitverzgerung von 200 ms vorgegeben
und auf einzelne Ressourcen heruntergebrochen werden.
Die standardisierten Austauschformate fr
Beschreibungen vereinfachen die Entwicklung
eines verteilten Systems durch mehrere Entwicklungspartner.

von einer Systembeschreibung und einer daraus

abgeleiteten Gefahrenanalyse und Risikobewertung prozessorale und technische Anforderungen an die Entwicklung und die technischen Manahmen eines elektrischen/elektronischen Systems
im Fahrzeug stellt (siehe Kap. 6). Diese werden in
einem funktionalen und daraus abgeleiteten, technischen Sicherheitskonzept im Rahmen der Entwicklung des Systems spezifiziert. Aus dem technischen Sicherheitskonzept leiten sich weiterhin auch
Anforderungen an die Software des Systems ab.
Band6 der ISO26262 enthlt die entsprechenden
Anforderungen an die Entwicklung sicherheitsrelevanter Software. Da der AUTOSAR-Standard
eine Entwicklungsmethodik und eine Softwareinfrastruktur definiert, knnen durch ihn immer nur
Teilaspekte eines technischen Sicherheitskonzeptes umgesetzt werden. Deswegen kann AUTOSAR
gem der Nomenklatur der ISO26262 auch als
Safety Element out of Context (SEooC) bezeichnet werden (siehe [3], Part 10, Chapter 9). Dies
bedeutet, dass die konkreten Sicherheitsanforderungen in einem Entwicklungsprojekt mit den im
AUTOSAR-Standard getroffenen Annahmen zum
technischen Sicherheitskonzept zur Deckung gebracht werden mssen.
Bei der Entwicklung von AUTOSAR wurden
typische technische Sicherheitskonzepte sowie die
technischen Anforderungen aus der ISO 26262
analysiert und daraus abgeleitet eine Reihe von
Mechanismen fr die funktionale Sicherheit in den
AUTOSAR-Standard integriert. Besonders hervorzuheben sind hierbei:
Speicherpartitionierung,
Absicherung der Kommunikation von End- zu
Endpunkt,
berwachung der Ablaufprogramme,
defensives Verhalten.

AUTOSAR-Mechanismen
fr funktionale Sicherheit
(ISO26262)

In der Entwicklung sicherheitsrelevanter Fahrerassistenzsysteme sollte beim Entwurf des technischen

Sicherheitskonzeptes darauf geachtet werden, die
von AUTOSAR bereitgestellten Sicherheitsmechanismen einzusetzen, um einen zustzlichen Entwicklungs- und Absicherungsaufwand zu vermeiden.

7.7.2

Die grundlegende Herangehensweise bezglich der

funktionalen Sicherheit fr Kraftfahrzeuge wird
in der im November2011 verffentlichten Norm
ISO26262 [3] beschrieben. Bei der ISO26262 handelt es sich um eine Systemnorm, die ausgehend

---

118

Kapitel 7 AUTOSAR

Partition 0

Partition 1

Application
Software
Component

Actuator
Software
Component

Sensor
Software
Component

AUTOSAR
Interface

AUTOSAR
Interface

AUTOSAR
Interface

4
5
6

Standardized
Interface

Standardized
Interface

Operating
System

Standardized
AUTOSAR
Interface

Standardized
Interface

Services

Communication

Standardized
Interface

Standardized
Interface

Partition 5

. Abb.7.11 AUTOSAR-Speicherpartitionierung [2]

12

7.7.2.1

15
16
17
18
19
20

AUTOSAR
Interface

AUTOSAR
Interface

AUTOSAR
Interface

ECU
Abstraction
Standardized
Interface

Complex
Device
Drivers

Microcontroller
Abstraction

ECU-Hardware

11

14

Application
Software
Component

..............

Standardized
Interface

Basic Software

10

13

AUTOSAR
Software

Runtime Environment

7
8

Partition 4

Speicherpartitionierung

Die Speicherpartitionierung ermglicht die

Schaffung von Schutzgrenzen um eine Gruppe
von Softwarekomponenten. Gruppen von Softwarekomponenten werden hierbei in logische Anwendungspartitionen organisiert, wie in . Abb. 7.11
dargestellt. Sie haben begrenzten Schreibzugriff auf
Speicher einschlielich des Hauptspeichers und
nichtflchtigen Speichers und speicherbezogene
Hardware. Darber hinaus laufen Anwendungen in
der Anwendungspartition im Anwendungsmodus
der CPU, was bedeutet, dass sie begrenzten Zugriff
auf spezielle Funktionsregister der CPU und auf Befehle im berwachungsmodus haben.
Wenn eine Softwarekomponente, die in einer
Anwendungspartition luft, versucht, unberechtigt
auf Speicher zu schreiben, entdeckt dies die Hardware-Speicherschutzeinheit (Memory Protection
Unit, MPU) und verhindert den Zugriff. Dies fhrt
zu einer Unterbrechung der Ausfhrung und die
Anwendungspartition, die diesen Fehler verursacht

hat, wird durch das Betriebssystem und die RTE

kontrolliert beendet. Falls entsprechend konfiguriert, werden alle Softwarekomponenten in dieser
Partition neu gestartet. Dieselben Mechanismen treten auch in Kraft, falls eine Softwarekomponente in
einer Anwendungspartition versucht, auf CPU-Register zuzugreifen, die nur im berwachungsmodus
verndert werden drfen.

7.7.2.2

Absicherung
der Kommunikation
von End- zu Endpunkt

Das Konzept der Absicherung der Kommunikation von End- zu Endpunkt geht davon aus, dass
sicherheitsrelevanter Datenaustausch whrend
der Laufzeit gegen Auswirkungen von Fehlern
im Kommunikationspfad zwischen zwei Softwarekomponenten, die ber einen physischen Bus
kommunizieren, abgesichert werden soll. Dies sind
beispielsweise zufllige Hardwarefehler wie beschdigte Register im sendenden oder empfangenden

119
7.7 Auswirkungen und Besonderheiten bei der FAS-Entwicklung

SWC 1
Sender
Application
Logic

E2E
protection
wrapper

3: Call E2E protect

on array
E2E_P0x_Protect()

SWC 2
Receiver
Application
Logic

1: Produce
safe data elements
2: Invoke safe transmission
request
E2EPW_Write_<p>_<o>()

4: Invoke RTE
RTE_Write_<p>_<o>()
to transmit the data element

E2E
protection
wrapper

7: Invoke RTE read

RTE_Read_<p>_<o>()
to get the data element

Libraries

6: Invoke safe read

to get the data element
E2EPW_Read_<p>_<o>()

8: Call E2E check

on array
E2E_P0xCheck()

Runtime Environment

Runtime Environment
E2E
Lib

9: Consume
safe data elements

5: RTE communication (intra or inter ECU),

either through COM, IOC, or local in RTE

E2E
Lib
Libraries

. Abb.7.12 Funktionsweise der End- zu-Endpunkt-Absicherung [2]

Netzwerkcontroller, Interferenzen durch elektromagnetische Wellen und systematische Fehler in der

Softwareimplementierung der Kommunikation
des virtuellen Funktionsbusses, z. B. in der RTE, im
Kommunikationssystem oder im Netzwerkstack.
Die Absicherung der Kommunikation von Endzu Endpunkt kann diese Fehler im Kommunikationspfad entdecken und sie whrend der Laufzeit
handhaben: Die End- zu-Endpunkt-Bibliothek
von AUTOSAR stellt hierbei die Mechanismen
zur Verfgung, welche die Anforderungen an eine
sicherheitsrelevante Kommunikation bis zur Automotive-Sicherheitsintegrittsstufe D (ASIL) erfllen
knnen. Dazu werden Mechanismen wie Prfsummen (CRC), Nachrichten-IDs und Alive-Counter
verwendet.
Diese Algorithmen der Absicherungsmechanismen sind in der Spezifikation der sogenannten
End- zu-Endpunkt-Bibliothek von AUTOSAR definiert und werden von den Softwarekomponenten
bei Bedarf aufgerufen. . Abbildung 7.12 stellt die
Funktionsweise in der Kommunikation zwischen
zwei Anwendungssoftwarekomponenten vor.

7.7.2.3

berwachung
des Programmablaufs

Die berwachung des Programmablaufs zielt auf

die Entdeckung von Fehlern in den Kontrollablu-

fen der Anwendungssoftware ab. Ein fehlerhafter

Programmablauf findet statt, wenn ein oder mehrere Programmbefehle entweder in der falschen
Reihenfolge, nicht zeitgerecht oder berhaupt nicht
ausgefhrt werden. Fehler in den Kontrollablufen
knnen aus systematischen Softwarefehlern oder
aus zuflligen bzw. systematischen Hardwarefehlern entstehen. Sie knnen zu Datenverflschung,
Programmabbrchen und in letzter Konsequenz
zu Verletzungen von Sicherheitszielen fhren.
Die berwachung des Programmablaufs beinhaltet grundstzlich zwei Arten des berwachens:
erstens die berwachung des zeitlichen Verhaltens
und zweitens die berwachung der logischen Ausfhrungsreihenfolge von Programmblcken.
Die Kernfunktion zur berwachung des Programmablaufs wird durch das AUTOSAR-Basissoftwaremodul Watchdog-Manager zur Verfgung
gestellt. Abhngig von der Sicherheitsrelevanz der
Softwareeinheiten und den Sicherheitsanforderungen des Gesamtsystems kann eine berwachte Einheit eine Gruppe von Softwarekomponenten oder
nur eine ausfhrbare Softwareeinheit innerhalb einer Komponente sein. Die berwachten Softwareeinheiten rufen an zuvor festgelegten Stellen den
Watchdog-Manager mit einem Kontrollcode auf.
Daraus kann dieser ermitteln, ob die berwachten
Softwareeinheiten in der richtigen Reihenfolge und

120

1
2
3

Kapitel 7 AUTOSAR

in den zulssigen Zeitfenstern ausgefhrt wurden.

Kommt es dabei zu einer Verletzung der Vorgaben,
werden zuvor festgelegte Sicherheitsmechanismen
ausgefhrt, was bis zu einem sofortigen Reset des
Steuergertes gehen kann.

7.7.2.4

Defensives Verhalten

12

Defensives Verhalten von Software zielt darauf ab,

Fehlerbertragung bzw. Fehlerausbreitung in der
Software zu verhindern. Es handelt sich dabei um eine
nicht-funktionale Eigenschaft der Software und wird
im Allgemeinen durch entsprechende Programmierrichtlinien und Code-Muster erreicht. Damit ist defensives Verhalten der Basissoftware von AUTOSAR
eine Eigenschaft, die nicht der Standard selbst festlegt, sondern die vom Implementierer des Standards
sichergestellt wird. Eine typische Manahme ist
beispielsweise die Absicherung gegen Verflschung
von sicherheitsrelevanten Daten eines Moduls der
Basissoftware. Hierbei werden die entsprechenden
Daten direkt vor dem Verlassen des entsprechenden
Softwaremoduls mit einem Sicherheitscode versehen.
Beim erneuten Aufruf dieses Softwaremoduls wird
der Sicherheitscode zu den Daten erneut ermittelt.
Ist er nicht identisch zu dem zuvor abgespeicherten,
wurden die Daten in der Zwischenzeit unberechtigt
verndert und das Softwaremodul kann eine entsprechende Fehlerbehandlung auslsen.

13

7.7.3

4
5
6
7
8
9
10
11

14
15
16
17
18
19
20

Virtualisierung
in der Funktionsabsicherung

Der Aufwand fr Tests zur Absicherung der Funktionsweise aller Komponenten steigt rapide an: Verteilte Entwicklung der Softwarekomponenten durch
Zulieferer und durch den Automobilhersteller, das
Parallelisieren der Entwicklung von Basissoftware
und Softwarekomponenten sowie die anschlieende Integration auf mehrere Steuergerte durch
den Automobilhersteller oder durch einen anderen
Zulieferer erfordert neue Wege in der Absicherung.
Die Funktion der Softwarekomponente an sich, ihr
Zusammenspiel mit der RTE und der Basissoftware,
die Wirksamkeit von Sicherheitsmechanismen, wie
in Abschn. 7.7.2 beschrieben, oder die Einhaltung
von Anforderungen an die Laufzeit von Fahrerassistenzsystemen, vgl. Abschn. 7.7.1, sind einige

Beispiele von Mechanismen und Funktionen, die

zum frhestmglichen Zeitpunkt validiert werden
mssen. Je spter Fehler gefunden werden, desto aufwendiger wird ihre Behebung, und desto grer das
Risiko fr das Entwicklungsprojekt. Es geht im Kern
um die Fragestellung: Wie knnen Funktionen, beispielsweise die eines Spurhalteassistenten, in der verwendeten Umgebung frhzeitig abgesichert werden?
Eine wirksame Mglichkeit bietet die virtuelle Absicherung. In einer PC-Umgebung wird die
AUTOSAR-Basissoftware integriert. Hierbei knnen
die Implementierungen verschiedener Hersteller inklusive kundenspezifischer Anpassungen integriert
werden. Mithilfe von speziellen Anpassungen in der
Hardwareabstraktion ist das Verhalten der Basisund Anwendungssoftware vergleichbar mit dem im
Steuergert und dessen integrierten Mikroprozessor.
Die gesamte virtuelle Absicherungsplattform
kann entweder rein durch Software oder mit verbundenen Hardwarekomponenten realisiert werden. Im letzteren Fall werden am PC Schnittstellenkonverter angeschlossen, die die Verbindung mit
den Fahrzeugschnittstellen sicherstellen. Des Weiteren enthlt die Basissoftware die fr die Hardware
kompatible Microcontroller Abstraction-Schicht
mit den entsprechenden Hardwaretreibern.
Whrend der Entwicklung von Softwarekomponenten knnen auf der einen Seite deren Funktionen noch vor der Integration in das Steuergert
getestet und abgesichert werden. Auf der anderen
Seite knnen die direkt auf dem PC-Betriebssystem
verfgbaren Entwicklungswerkzeuge, wie z. B. Debugger, benutzt werden, wodurch die Arbeitsablufe
effizienter gestaltet werden. Die standardisierte Basissoftware ermglicht die Verwendung der Werkzeuge fr die AUTOSAR-Entwurfsmethodik, wie
unter Abschn. 7.4.2 beschrieben.
Dieses System sichert die Funktionen von Softwarekomponenten in einer frhen Entwicklungsphase ab und kann dabei bestehende Software bzw.
Steuergerte aus Serienfahrzeugen und neue Technologien von beispielsweise Sensoren mit einbeziehen. Die vorgesehene Steuergertehardware muss
dabei noch gar nicht verfgbar sein.
Sicherlich ist dies auch mit fahrzeugherstellerspezifischer Software mglich. Doch nur AUTOSAR
ermglicht die durchgngige Portierung und somit
Wiederverwendung der Testflle herstellerbergrei-

121
7.7 Auswirkungen und Besonderheiten bei der FAS-Entwicklung

fend fr andere Projekte. Durch die standardisierten

Anwendungsschnittstellen, vgl. Abschn. 7.4.3, ist
die Implementierung einer virtuellen Absicherungsplattform zudem modular und strukturiert, so dass
sie effizient realisierbar ist.
Essenzielle Vorteile bietet die virtuelle Absicherung bei der Einfhrung agiler Softwareentwicklungsmethoden (vgl. [4]): Hierbei werden Funktionen in relativ kurzen Iterationen entwickelt und
im Idealfall wird nach jeder Iteration eine getestete
und funktionsfhige Software geliefert. Fr komplexe Systeme, die mit verschiedenen Partnern entwickelt werden, ist dies mit vertretbarem Aufwand
nur durch eine virtuelle Absicherung zu erreichen.
Auch die im Rahmen agiler Entwicklung fast immer
eingesetzte kontinuierliche Integration, verbunden
mit kontinuierlicher Validierung und Softwarelieferung zwischen den Partnern, lsst sich mittels einer
virtuellen Absicherungsplattform wesentlich effizienter realisieren.
7.7.4

Beherrschung
von Komplexitt und
Entwicklungszeitverkrzung

Aus technischer Sicht stehen wir durch die steigende

Zahl von Fahrerassistenzsystemen und dem steigenden Grad der Vernetzung immer komplexeren Systemen gegenber. Dies birgt nicht nur Risiken in
der Entwicklung, sondern auch in der Absicherung
von Softwaresystemen. Der beschriebene modulare
Aufbau von AUTOSAR ermglicht es, wesentliche
Teile der Software wiederzuverwenden. Des Weiteren bieten die in Abschn. 7.7.1 beschriebenen
strukturierten Entwicklungsmechanismen die
Mglichkeit, eine hohe Anzahl von Anwendungen
zu integrieren. Ein Steuergert wird fr neue Anwendungen nicht neu entwickelt, sondern durch
Generierung und Konfiguration knnen vielmehr
neue Anwendungen in eine bestehende Architektur
integriert werden. Dies hat positive Auswirkungen
auf Qualitt und Entwicklungszeit.
Aus organisatorischer Sicht entsteht nun eine
neue Komplexitt. Entwicklungsprojekte beziehen
eine Vielzahl von Lieferanten ein und adressieren
eine groe Anzahl an Schnittstellen zwischen den
Funktionsbereichen. In der Entwicklung spezifi-

scher Softwarearchitekturen sind extensive multilaterale Diskussionen und Verhandlungen ntig,

um die technischen Schnittstellen zwischen den
Liefergegenstnden und den projektspezifischen
Schnittstellen zwischen den Lieferanten zu klren.
Die AUTOSAR-Entwurfsmethodik hilft, dies zu
vereinfachen. Aufgrund der standardisierten Austauschformate auf XML-Basis sowie der standardisierten Anwendungsschnittstellen sind Inhalte und
Zusammenspiel definiert.
Darber hinaus ergibt sich die Mglichkeit,
durchgngige Toolketten zu nutzen. Die Elemente
der Entwurfsmethodik und die AUTOSAR-Spezifikationen an sich werden von Toolherstellern aufgegriffen. Zurzeit sind diverse Entwicklungstools auf
dem Markt, die es ermglichen, eine durchgngige
Entwicklungslandschaft zu schaffen (vgl. [5]).
7.7.5

Flexibilisierung
von kooperativer und verteilter
Entwicklung

Mit der Einfhrung einer standardisierten Basissoftware geht auch ein fundamentaler Wandel in
den Geschfts- und Arbeitsmodellen einher: Automobilhersteller verwenden nicht lnger ihre eigene,
meist proprietre ECU-Basissoftware, sondern Mikroprozessorhersteller, Zulieferer bzw. Softwarelieferanten entwickeln und testen die AUTOSAR-Basissoftware.
Die Anwendungen kommunizieren mit der Basissoftware ber standardisierte Schnittstellen. Auf
diese Art und Weise werden viele Anwendungen gemeinsam von vielen Automobilherstellern verwendet. Als Beispiel seien an dieser Stelle Anwendungen fr Fensterheber oder Zentralverriegelungen
erwhnt. Dies bedeutet, dass der Lieferant fr eine
dieser Anwendungen nicht mehr kundenspezifische
Produkte entwickelt, sondern mehrere Kunden mit
dem gleichen Produkt anspricht. Diese Softwareanwendungen sind somit wiederverwendbar und
durch ihre weitere Verbreitung auch stabiler.
Wettbewerbsrelevante Anwendungen werden
weiterhin herstellerspezifisch sein. Sie knnen
durch die Nutzung der bereits erwhnten standardisierten Schnittstellen fr verschiedene Modelle
eines Herstellers verwendet werden.

122

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

Kapitel 7 AUTOSAR

Die Entwicklung dieser wettbewerbsrelevanten

Anwendungen kann sowohl beim Automobilhersteller selbst, bei Lieferanten oder zusammen mit
Lieferanten erfolgen. Erleichtert wird dies durch die
formalen Beschreibungen der Softwarekomponenten, der Steuergerte und des Gesamtsystems. Sie
liegen in standardisierten Austauschformaten vor
und ermglichen so eine werkzeuguntersttzte Integration der Software.
Die Integrationsarbeit verlagert sich hierbei auf
die Softwareebene und somit zum Automobilhersteller, da er, um eine optimale Wiederverwendung
zu gewhrleisten, die Architektur bzw. die Konfiguration des Steuergertes und des Gesamtnetzwerks
entwerfen muss.
Betrachtet man nicht nur die Fahrerassistenzsysteme allein, sondern auch deren jetzige und zuknftige Vernetzung miteinander fahrzeugbergreifend, Fahrzeug mit Fahrzeug, Fahrzeug mit
Verkehrssystemen oder internetbasierten Diensten
wird deutlich, dass Innovationsgeschwindigkeit
ein entscheidender Faktor fr die erfolgreiche Einfhrung solcher Systeme in Fahrzeugen ist. Die Innovationsgeschwindigkeit wird mageblich durch
Softwarewiederverwendung und gemeinschaftliche
Entwicklungen bestimmt.
7.8

Zusammenfassung

In den zehn Jahren seit Beginn seiner Entwicklung

hat sich AUTOSAR in der Fahrzeugindustrie als der
weltweite Standard fr Softwareinfrastruktur, Systembeschreibung mit einem durchgngigen Entwurfsprozess und standardisierten Austauschformaten zwischen allen beteiligten Entwicklungspartnern (Stand
Oktober2014: ber 180Firmen) etabliert. Damit sind
seit der Einfhrung von AUTOSAR-Release4.0 im
Jahr2009 in den nicht-differenzierenden Softwareanteilen der Steuergerte im Fahrzeug die proprietren
Lsungen weitgehend abgelst. Ein entscheidender
Grund fr diesen Erfolg von AUTOSAR drfte in dem
Grundprinzip der Partnerschaft liegen:

Cooperate on standardization,
compete on implementation.

Das Kernergebnis der AUTOSAR-Partnerschaft

liegt somit in der Spezifikation des AUTOSAR-Standards. Bereits dessen Implementierung unterliegt
dem freien Wettbewerb.
Eine weitere grundlegende nderung, die mit
AUTOSAR eingefhrt wurde, ist der Paradigmenwechsel fr den Anwender: weg vom Implementieren der Software hin zum Konfigurieren und
Generieren der Software. Damit knnen mit den geeigneten Werkzeugen aus den Systembeschreibungen von AUTOSAR sehr schnell Umsetzungen in
Software erzeugt und somit ein bisher unerreichter
Abstraktionsgrad in der Entwicklung der Software
fr Steuergerte erreicht werden. Dieser Abstraktionsgrad zusammen mit der Unabhngigkeit von
spezifischer Hardware erlaubt eine neue Stufe der
Wiederverwendbarkeit von Software. AUTOSAR
ermglicht damit eine Konzentration auf die Entwicklung neuer, innovativer Kundenfunktionen, die
heute vor allem im Bereich der Fahrerassistenzsysteme entstehen.
Literatur
1

2
3
4
5

Von der Beek, M.: Development of logical and technical architectures for automotive systems. In: Software & Systems
Modeling 6(2), Springer Verlag, Berlin Heidelberg, 205219
(2006)
AUTOSAR Webseite: Verfgbar unter: http://www.autosar.
org
ISO, ISO 26262 Road vehicles Functional safety, Parts 1
10, First edition, 2011
Sims, C., Johnson, H.L.: Scrum: A Breathtakingly Brief and
Agile Introduction. Dymaxicon, Foster City, Calif. (2012)
ATZ Extra: 10 Years AUTOSAR, The Worldwide Automotive
Standard for E/E Systems, Springer Verlag, October 2013