INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG

Vorlesung Automotive Software Engineering Teil 7 Normen und Standards (1)

Technische Universität Darmstadt Fachbereich 18 Elektrotechnik und Informationstechnik Fachgebiet Echtzeitsysteme Fachbereich 20 Informatik Wintersemester 2012/2013 Prof. Dr. rer. nat. Bernhard Hohlfeld [email protected]

Vorlesung Automotive Software Engineering

Motivation und Überblick

SW-Entwicklung

E/E-Entwicklung

Beispiele aus der Praxis

Das Automobil

Die Automobilherstellung

Die Automobilbranche

2

Normen und Standards

OSEK/ VDX

ASAM

ISO 26262 Road vehicles Functional safety

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Lernziele Normen und Standards

 Die Bedeutung von Normen und Standards für industrielle Entwicklung verstehen.  AUTOSAR Automotive Open System Architecture kennenlernen  Motivation  Technik  Beispiele

 ISO 26262 Road Vehicles Functinal Safety kennenlernen

3

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards

1. AUTOSAR 2. ARTOP 3. Vorgehensmodelle und funktionale Sicherheit

42

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards

1. AUTOSAR 2. ARTOP 3. Vorgehensmodelle und funktionale Sicherheit

52

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software im Fahrzeug - siehe Teil 2 Die Automobilbranche

Fahrzeug Engineering Dienstleistungen Schema der Fertigung von Bändern und Blechen

Anwärmen

Warmwalzen

Fräsen

Inspektion

Türe

Halbleiter kalt Vorwalzen

14

6

Pressen

Steuergerät

Zwischen und Fertigwalzen

Querteilen

Bleche

Längsteilen

Bänder

Kupferband (Halbzeug)

Steckverbinder

SW-Entwicklungswerkzeuge

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Anforderungen

 Neue Beziehungen, Kompetenzen und Verantwortlichkeiten zwischen OEM und Zulieferer erforderlich

7

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

82

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR ist ganz einfach zu verstehen

⛔ว䉲䉴䊁䊛䈮ኻᔕ䈜䉎↥ᬺ⇇䈱ᨒ⚵䉂䉕⿥䈋䈢ㅪ៤ᒝൻ „ ወӳἉἋἘἲểỊऴ‫إ‬ἉἋἘἲểኵᡂἉἋἘἲỂನ঺ẰủỦ‫ᙹٻ‬೉ἉἋἘἲ „ ᣻ᙲễᅈ˟ỶὅἧἻỉ‫ٶ‬ẪỊወӳἉἋἘἲ z ऴ‫إ‬ἉἋἘἲҥ˳ẆኵᡂἉἋἘἲҥ˳ỉࣱ̮᫂Ὁ‫ܤ‬μࣱỉᄩ̬ẻẬỂỊễẪẆወӳἉ

ἋἘἲμ˳ỉࣱ̮᫂Ὁ‫ܤ‬μࣱỉᄩ̬ầ᣻ᙲ

„ ወӳἉἋἘἲỉЎ᫏ z ҥɟ‫׹‬ወӳἉἋἘἲᾉ ҥɟႸႎỉẺỜỆऴ‫إ‬ἉἋἘἲểኵᡂἉἋἘἲẦỤನ঺Ằủ

ẺἉἋἘἲ z ኽӳ‫׹‬ወӳἉἋἘἲᾉ ီễỦႸႎỂನሰẰủẺऴ‫إ‬ἉἋἘἲểኵᡂἉἋἘἲầẆẸ ủẹủỉἉἋἘἲỉМࣱ̝ử᭗ỜỦႸႎỂኽӳẰủẺἉἋἘἲ න৻ဳ⛔ว䉲䉴䊁䊛䈱଀

⚿วဳ⛔ว䉲䉴䊁䊛䈱଀

㌁ⴕൊቯ♽䉥䊮䊤䉟䊮䉲䉴䊁䊛

੤ㅢ▤೙䉲䉴䊁䊛䈫䉦䊷䊅䊎䉭䊷䉲䊢䊮䉲䉴䊁䊛

ᖱႎ䉲䉴䊁䊛䋺 ൊቯ♽䉲䉴䊁䊛䇮 㘈ቴ䊶༡ᬺᐫ⥩▤ ℂ䉲䉴䊁䊛䈭䈬

⚵ㄟ䉲䉴䊁䊛䋺 㪘㪫㪤䇮䊈䉾䊃䊪䊷䉪 䊦䊷䉺䇮Ꮽ␿ශ೚ ⵝ⟎䈭䈬

䉟䊮䉺䊷䊈䉾䊃䊋䊮䉨䊮䉫䉲䉴䊁䊛 䉮䊷䊦䉶䊮䉺䊷䉲䉴䊁䊛

ᖱႎ䉲䉴䊁䊛 䇮㘈ቴ䊶༡ᬺᐫ⥩ ▤ℂ 㘈ቴᖱႎDB 䉲䉴䊁䊛 ൊቯ♽DB

ൊቯ♽䉲䉴䊁䊛

༡ᬺᐫ⥩ᖱႎDB

ฦᐫ⥩ ATM

⚵ㄟ䉲䉴 䊁䊛

੤ㅢ▤೙䉲䉴䊁䊛஥䈱 ⋡⊛䋺 ʩᡫሥСἉἋἘἲ ίऴ‫إ‬ἉἋἘἲὸ

ታゞਔ䈱૏⟎ᖱႎ䉇ㅦ ᐲᖱႎ䈮䉋䉍䇮㆏〝੤ㅢ ⁁ᴫ䈱䉋䉍ᱜ⏕䈭ᛠី䈏 䈪䈐䉎 䉦䊷䊅䊎䉭䊷䉲䊢䊮䉲䉴䊁 䊛஥䈱⋡⊛䋺 ੤ㅢ▤೙䉲䉴䊁䊛䈱ᷦ ṛᖱႎ䈎䉌㆏〝䈱ᷦṛ ⁁ᴫ䉕⠨ᘦ䈚䈢⚻〝᩺ౝ 䈏䈪䈐䉎

ἜἥἄὊ ἉἹὅ ἉἋἘἲ ίኵᡂἉ ἋἘἲὸ

ᵕ 9

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

10 2

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR – Core Partners and Members (Phase II)

 Ca. 170 Firmen (Stand Ende 2009)

11

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Core Partners in Phase III

 Initial discussions 2002: BMW, Bosch, Continental, DaimlerChrysler and Volkswagen, partners were

joined soon afterwards by Siemens VDO.  Additional Core Partners 2003: Ford, Peugeot Citroën, Toyota, 2004: GM  2008 Siemens VDO became part of Continental.  Phase III will start with 8 Core Partners

 GM announced to continue in phase III as Premium Member  The 8 Core Partners agreed on the phase III 2010-2012 development contract  Phase III planning started and is well under way

12

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Membership Levels

 Core Partners

 Associate Members

 Organizational control

 Access to finalized documents

 Technical contributions

 Utilization of AUTOSAR standard

 Administrative control  Definition of external Information

(web-release, clearance, etc.)  Leadership of Working Groups  Involvement in Working Groups  Utilization of AUTOSAR standard

 Premium Members  Leadership of Working Groups

 Development Members

(for small companies with specific expertise)  Technical contributions  Access to current information  Utilization of AUTOSAR standard

 Attendee (e.g. Universities)  Support Role

 Involvement in Working Groups  Technical contributions  Access to current information  Utilization of AUTOSAR standard

13

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Phase III Organization

Core Partner Core Partner, Premium and Development Member

Executive Board

Administration

General Manager

System Architecture

Subcontractor

Steering Commitee

Technical Steering Team

Software and Test Specification

Legal Team

Validation

CommunicationTeam

Application Interfaces

Follow-up Team

Quality Manager

Change Manager

…

…

…

… Release Manager

Technical Office

14

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Initial WP Structure Phase III

Work Packages 1

2

3

10

System Architecture

Software and Test Specification

Validation

Application Interfaces

2.1

WP-3.1

WP-10.0

Basic Software

Basic Software Validation

Coordination of Appl. Interfaces

1.1 Software Architecture WP-1.1.1

WP-1.1.2

Software Architecture and OS

Vehicle and Application Mode Mgmt.

WP-2.1.1

WP-10.1

COM Stack

Body and Comfort

WP-2.1.3 WP-1.1.5

MCAL

VFB and RTE

WP-2.1.4

Existence of Work Packages will depend on sufficient participation

WP-10.2 Powertrain

Diagnostics WP-10.3

WP-1.2 Methodology and Configuration WP-1.3 Functional Safety

WP-2.1.5

Chassis Control

Libraries WP-2.2 Conformance Test Specification

Lead Work Package

WP-10.4 Occupants and Pedest. Safety WP-10.5 MM / T / HMI

15

WP-x.y

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

WP-x.y Work Package

Initial WP structure Phase III

Work Packages 1

2

3

10

System Architecture

Software and Test Specification

Validation

Application Interfaces

2.1

WP-3.1

WP-10.0

Basic Software

Basic Software Validation

Coordination of Appl. Interfaces

1.1 Software Architecture WP-1.1.1

WP-1.1.2

Software Architecture and OS

Vehicle and Application Mode Mgmt.

WP-2.1.1

WP-10.1

COM Stack

Body and Comfort

WP-2.1.3 WP-1.1.5

MCAL

VFB and RTE

WP-2.1.4

Existence of Work Packages will depend on sufficient participation

WP-10.2 Powertrain

Diagnostics WP-10.3

WP-1.2 Methodology and Configuration WP-1.3 Functional Safety

WP-2.1.5

Chassis Control

Libraries WP-2.2 Conformance Test Specification

Lead Work Package

WP-10.4 Occupants and Pedest. Safety WP-10.5 MM / T / HMI

16

WP-x.y

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

WP-x.y Work Package

Elektronische Systeme im Fahrzeug (4.1 Domänen)

Anwendungsdomänen und elektronische Subsysteme (in diesem Abschnitt nach Schäuffele / Zurawka: Automotive Software Engineering)  Antriebsstrang (Powertrain)  Fahrwerk (Chassis)  Karosserie (Body)  Multi-Media (Telematics)

Auch andere Klassifizierungen gebräuchlich (Beispiel Mercedes-Benz Technik transparent)  Aktive Sicherheit  Passive Sicherheit  Karosserie  Fahrwerk  Innenraumtechnik  Elektronik  Motoren/Getriebe

17

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Initial WP structure Phase III

Work Packages 1

2

3

10

System Architecture

Software and Test Specification

Validation

Application Interfaces

2.1

WP-3.1

WP-10.0

Basic Software

Basic Software Validation

Coordination of Appl. Interfaces

1.1 Software Architecture WP-1.1.1

WP-1.1.2

Software Architecture and OS

Vehicle and Application Mode Mgmt.

WP-2.1.1

WP-10.1

COM Stack

Body and Comfort

WP-2.1.3 WP-1.1.5

MCAL

VFB and RTE

WP-2.1.4

Existence of Work Packages will depend on sufficient participation

WP-10.2 Powertrain

Diagnostics WP-10.3

WP-1.2 Methodology and Configuration WP-1.3 Functional Safety

WP-2.1.5

Chassis Control

Libraries WP-2.2 Conformance Test Specification

Lead Work Package

WP-10.4 Occupants and Pedest. Safety WP-10.5 MM / T / HMI

18

WP-x.y

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

WP-x.y Work Package

What Daimler expects from AUTOSAR

 Provisioning of an interoperable reliable software kit. Increase of quality and development speed through

a comprehensive and standardized design and implementation approach.  Inter OEM exchange through

interoperable software kits  Reduction of testing effort in

the automotive community  Internal and external libraries

for off-the-shelf applications  Convenient integration into

Architecture/ Basic Software

the development chain of Tier1s and OEMs  Faster SW integration processes

Data Exchange

 Standard application interfaces for

‘SW as a product’

Application Interfaces

.xml

Methodology Workflow

Source: AUTOSAR PM Conference 02-2008 / AUTOSAR - a key enabler for comprehensive E/E standardization / S. Wolfsried, Daimler AG

19

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Preconditions for the introduction of AUTOSAR

 Introduction of a standard depends on its maturity and the benefits of its Geplante AUTOSAR-

Anwendungen: Daimlers assessment is positive for AUTOSAR 3.0.  Remaining issues:  Conformance tests are essential for guaranteeing AUTOSAR’s integrity as a standard.  Furthermore, the standard appears ‚overloaded‘.

 Maturity of a new standard has to be assured  The release of AUTOSAR 3.0 has been determined to be the sweet spot for introduction according to our maturity and benefit

assessment

 Maintenance shall be managed  The AUTOSAR community is seen capable to assure this

 Conformance tests must be available to ensure the standard’s continuous integrity  Conformance tests not yet available

 Today the standard appears overloaded:

too many requirements with a “one-size-fits-all” approach

Source: AUTOSAR PM Conference 02-2008 / AUTOSAR - a key enabler for comprehensive E/E standardization / S. Wolfsried, Daimler AG

20

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Technical scope of AUTOSAR

Methodology

New concepts

Input Templates

Memory Services

Industry-wide consolidation of ‚existing‘ basic software designs 9

21

Oct. 23rd 2008

Meta Model

Exchange Formats

Configuration Concept Virtual Function Bus (VFB) Error Handling

RunTime Environment Mode Management

Network Management

Diagnostics

Gateway

OS Kernel µController Abstraction

Comm. Services

Bus systems

ECU Abstraction

Complex Drivers Drivers

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Technical scope of AUTOSAR

Methodology

New concepts

Input Templates

Memory Services

Industry-wide consolidation of ‚existing‘ basic software designs 9

21

Oct. 23rd 2008

Meta Model

Exchange Formats

Configuration Concept Virtual Function Bus (VFB) Error Handling

RunTime Environment Mode Management

Network Management

Diagnostics

Gateway

OS Kernel µController Abstraction

Comm. Services

Bus systems

ECU Abstraction

Complex Drivers Drivers

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Technical scope of AUTOSAR

Methodology

New concepts

Input Templates

Memory Services

Industry-wide consolidation of ‚existing‘ basic software designs 9

21

Oct. 23rd 2008

Meta Model

Exchange Formats

Configuration Concept Virtual Function Bus (VFB) Error Handling

RunTime Environment Mode Management

Network Management

Diagnostics

Gateway

OS Kernel µController Abstraction

Comm. Services

Bus systems

ECU Abstraction

Complex Drivers Drivers

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Technical scope of AUTOSAR

Methodology

New concepts

Input Templates

Memory Services

Industry-wide consolidation of ‚existing‘ basic software designs 9

21

Oct. 23rd 2008

Meta Model

Exchange Formats

Configuration Concept Virtual Function Bus (VFB) Error Handling

RunTime Environment Mode Management

Network Management

Diagnostics

Gateway

OS Kernel µController Abstraction

Comm. Services

Bus systems

ECU Abstraction

Complex Drivers Drivers

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Technical scope of AUTOSAR

Methodology

New concepts

Input Templates

Memory Services

Industry-wide consolidation of ‚existing‘ basic software designs 9

21

Oct. 23rd 2008

Meta Model

Exchange Formats

Configuration Concept Virtual Function Bus (VFB) Error Handling

RunTime Environment Mode Management

Network Management

Diagnostics

Gateway

OS Kernel µController Abstraction

Comm. Services

Bus systems

ECU Abstraction

Complex Drivers Drivers

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Technical scope of AUTOSAR

Methodology

New concepts

Input Templates

Memory Services

Industry-wide consolidation of ‚existing‘ basic software designs 9

22

Oct. 23rd 2008

Meta Model

Exchange Formats

Configuration Concept Virtual Function Bus (VFB) Error Handling

RunTime Environment Mode Management

Network Management

Diagnostics

Gateway

OS Kernel µController Abstraction

Comm. Services

Bus systems

ECU Abstraction

Complex Drivers Drivers

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

23 2

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Architekturkonzept

24

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell Abstraktionsschichten der Steuergerätesoftware

 Anwendungsschicht (Application Layer)  Laufzeitumgebung (Runtime Environment, RTE)

Basissoftware (BSW)

 Basissoftware (BSW)

25

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell Anwendungsschicht (Application Layer)

 Der Application Layer realisiert die Anwendungsfunktionalität des Steuergeräts mittels Anwendungs-

Basissoftware (BSW)

Softwarekomponenten (SWC - Software Component).

26

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell Laufzeitumgebung (Runtime Environment, RTE)

 Die Laufzeitumgebung (Runtime Environment, RTE) integriert den Application Layer mit der

Basissoftware (BSW)

Basissoftware (BSW). Sie implementiert den Datenaustausch zwischen AnwendungsSoftwarekomponenten (SWC) und steuert die Interaktion zwischen SWCs und der BSW.

27

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - Service Layer

 Der Service Layer stellt verschiedene Arten von Hintergrunddiensten wie Netzwerkdienstze,

Basissoftware (BSW)

Speicherverwaltung und Buskommunikationsdienste bereit. Das Betriebssystem ist ebenfalls in dieser Schicht enthalten.

28

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - ECU Abstraction Layer

 Der ECU Abstraction Layer bietet einen einheitlichen Zugriff auf alle Funktionalitäten eines Steuergeräts

wie Kommunikation, Speicher oder E/A.

Basissoftware (BSW)

 Ziel: Unabhängigkeit der höheren Schichten von der Steuergeräte-Hardware

29

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - Microcontroller Abstraction Layer

 Der Microcontroller Abstraction Layer (MCAL) bietet beispielsweise Treiber für den Zugriff auf

Kommunikation, Speicher und E/A des Mikrocontrollers.

Basissoftware (BSW)

 Ziel: Unabhängigkeit der höheren Schichten von der Mikrocontroller-Hardware

30

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - Complex Drivers

 Die Complex Drivers enthalten die in AUTOSAR nicht standardisierten Treiber für die spezifischen

Basissoftware (BSW)

Eigenschaften eines Mikrocontrollers oder Steuergeräts.

31

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - Complex Drivers

 Die Complex Drivers enthalten die in AUTOSAR nicht standardisierten Treiber für die spezifischen

Eigenschaften eines Mikrocontrollers oder Steuergeräts.  Beispiele  Sensordatenauswertung  Direkter Zugriff auf Mikrocontroller  Einfachlösungen für geringe Stückzahlen  Zugriffszeiten (siehe unten)  Weiterverwendung (siehe unten)

32

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel Zeitbeschränkungen

 Bremsen mit Verwendung des AUTOSAR-Schichtenmodells:

Zu langsam durch die vielen Software-Schichten

Bremspedal

Bremse

Kommunikationsbus 43

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel Zeitbeschränkungen

 Lösung: Direkter Zugriff auf die ECU-Hardware mit „Complex Drivers“

Bremspedal

Bremse

Kommunikationsbus 44

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - Complex Drivers

 Weiterverwendung

Bewährtes BSWModul

35

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - Complex Drivers

 Weiterverwendung  RTE-Schnittstelle

Bewährtes BSWModul

36

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR-Schichtenmodell BSW - Complex Drivers

 Weiterverwendung  RTE-Schnittstelle  Anwendungssoftware

Bewährtes BSWModul = Complex Driver

37

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Case Study Entwicklung einer Treiberbibliothek für Motorsteuerungen mit AUTOSAR Complex Device Driver (CDD) (1) Quelle: Vector Informatik GmbH  Der Kunde

Die FAW Group Cooperation, die „First Automotive Works“, mit Sitz in Changchun ist der größte chinesische Hersteller von Dieselmotoren, PKWs, sowie mittleren bis schweren Bussen und LKWs. FAW produziert mehr als 2,5 Millionen Fahrzeuge pro Jahr und gehört zu den ersten chinesischen OEMs, die AUTOSAR einsetzen.  Die Herausforderung

Entwicklung einer Treiberbibliothek für Motorsteuerungen mit AUTOSAR Complex Device Driver (CDD) FAW entwickelt eine neue Generation ihrer Motorsteuerungen und setzt dabei konsequent AUTOSAR-Basissoftware ein. Die Software wird als eine einzige Plattform realisiert, mit der sich sowohl Benzin- als auch Dieselmotoren steuern lassen. Da in AUTOSAR keine entsprechenden Treiber für Motorsteuerungen definiert sind, möchte FAW die benötigten Sensoren und Aktuatoren aus einer erweiterten AUTOSAR-Treiberbibliotek auswählen und in der gewünschten Anzahl und Ausprägung mit Hilfe einer durchgängigen Werkzeugkette konfigurieren.

Case Study Entwicklung einer Treiberbibliothek für Motorsteuerungen mit AUTOSAR Complex Device Driver (CDD)

Der Kunde

Die FAW Group Cooperation, die „First Automotive Works“, mit Sitz in Changchun ist der größte chinesische Hersteller von Dieselmotoren, PKWs, sowie mittleren bis schweren Bussen und LKWs. FAW produziert mehr als 2,5 Millionen Fahrzeuge pro Jahr und gehört zu den ersten chinesischen 38 Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013 Die FAW Group Cooperation, die „First Automotive Works“, Eine durch FAW erweiterbare domänenspezifische TreiberOEMs, die AUTOSAR einsetzen.

Der Kunde

Die Vorteile

und setzt dabei konsequent AUTOSAR-Basissoftware ein. Die Bibliothek und konfigurieren sie mit dem DaVinci Software wird als eine einzige Plattform realisiert, mit der sich Configurator Pro entsprechend ihrer spezifischen Motorsowohl Benzin- als auch Dieselmotoren steuern lassen. Da in Case Study steuerung. AUTOSAR keine entsprechenden Treiber für MotorsteuerunEntwicklung einer Treiberbibliothek für Motorsteuerungen mitvorgegebene Prozess und die SchnittstelDer in AUTOSAR gen definiert sind, möchte FAW die benötigten Sensoren und AUTOSAR Complex Device Driver (CDD) (2) len werden eingehalten: Die Regelalgorithmen für die Aktuatoren aus einer erweiterten AUTOSAR-Treiberbibliotek Quelle: Vector Informatik GmbH Motorsteuerung werden weiterhin mit Matlab und Simulink auswählen und in der gewünschten Anzahl und Ausprägung entwickelt und als AUTOSAR-Softwarekomponenten (SWC) mit Hilfe einer durchgängigen Werkzeugkette konfigurieren. realisiert. Diese sind über die RTE mit der AUTOSAR-Basis Die Lösung software und den motorspezifischen Treibern verbunden.

V1.0 2011/05 PES_CS_FAW_CDD-Motortreiber_DE

Die Lösung

Konfiguration und Code-Generierung der Konfiguration und Treiber Code-Generierung der motorspezifimotorspezifischen mit der vorhandenen schen Treiber mit der vorhandenen AUTOSAR-WerkzeugAUTOSAR-Werkzeugkette von Vector Die kette von Treiber zurVector Ansteuerung der motorspezifischen Sensorik und von Vector als Die Treiber zurAktuatorik Ansteuerungwurden der motorspezifischen Sensorik sogenannte Complex Driver (CDD) Complex und Aktuatorik wurden Device von Vector als sogenannte realisiert. Für (CDD) die Konfiguration der Trei- ber der TreiDevice Driver realisiert. Für die Konfiguration wurden entsprechende Basissoftware Module ber wurden entsprechende Basissoftware Module Description Description (BSWMD) Dateien mit Hilfe des (BSWMD) Dateien mit Hilfe des DaVinci Configurator Kit erDaVinci Configurator Kit erzeugt. Ebenso wurden Ebenso wurden die mit Code-Generatoren mit dem DaVinci diezeugt. Code-Generatoren dem DaVinci Configurator Kit DerDer DaVinci Configurator Pro liest die Configurator Kiterstellt. erstellt. DaVinci Configurator und bindet die zugehörigen Code Generatoren ProBSWMD-Dateien liest die BSWMD-Dateien und bindet die zugehörigen Code Generatoren ein. Damit kann ein. Damit kann er die Treiber für die Motorsteuerung und die er AUTOSAR-Basissoftware die Treiber für die Motorsteuerung und die konfigurieren. AUTOSAR-Basissoftware konfigurieren.

 Camshaft Nockenwelle Ihr Ansprechpartner bei Vector: Embedded Sales Team

 Crankshaft Kurbelwelle [email protected] www.vector.com

39

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

LIN TP

FlexRay TP

CAN Interface

Memory Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

CAN transc Driver

Flash EEPROM Emulation

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

I/O Hardware Abstraction

Communication Hardware Abstraction

Memory Abstraction Interface

External Watchdog Driver

CAN TP

LIN Interface

Watchdog Interface

Microcontroller Drivers

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

µC

DIO Driver

ADC Driver

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

20 Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

PWM Driver

ICU Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SPI Handler Driver

internal Flash Driver

FLASH

SCI

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

40

PDU Router

IPDU Multiplexer

EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Microcontroller

Communication Services

Memory Services

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

41 2

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR Software Komponenten (SWC)

Grundsätzlicher Design-Ansatz:  Trennung zwischen Steuergerät (Infrastruktur) und Anwendung (Funktionalität)  Eine Anwendung besteht aus miteinander verbundenen Software Komponenten  Die Software Komponenten sind atomar, d.h. sie können nicht über mehrere Steuergeräte verteilt

werden.  Die Implementierung der Software Komponenten ist unabhängig vom Steuergerät.  Methodik  Beispiele

42

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung

 Die Anwendungssoftware wird unabhängig vom konkreten Steuergerät als ein System von untereinander

verbundenen SWCs entworfen

43

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung

 Die Anwendungssoftware wird unabhängig vom konkreten Steuergerät als ein System von untereinander

verbundenen SWCs entworfen

44

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung Formale Definition der Schnittstellen

 Sender/Empfänger-Ports  Client/Server-Ports

45

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung Sender/Empfänger-Ports

 The sender-receiver pattern gives solution to the asynchronous distribution of information, where a

sender distributes information to one or several receivers. The sender is not blocked (asynchronous communication) and neither expects nor gets a response from the receivers (data or control flow), i.e. the sender just provides the information and the receivers decides autonomously when and how to use this information.  The sender component does not know the identity or the number of receivers to support transferability

and exchange of AUTOSAR Software Components.

Quelle: http://www.autosar.org

46

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung Client/Server-Ports

 The client initiates the communication, requesting that the server performs a service, transferring a

parameter set if necessary. The server waits for incoming communication requests from a client, performs the requested service, and dispatches a response to the client‘s request.  The client can be blocked (synchronous communication) or non-blocked (asynchronous communication),

respectively, after the service request is initiated until the response of the server is received.

Quelle: http://www.autosar.org

47

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel

 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)  Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)

!"#$%&'

48

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel

 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)  Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)

!"#$%&'

48

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel

 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)  Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)

!"#$%&'

48

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel

 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)  Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)

!"#$%&'

TSG 2, ...

TSG Fahrer

48

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel

 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)  Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)

!"#$%&'

Welche Komponente kommuniziert noch mit dem Light Master? TSG 2, ...

TSG Fahrer

48

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Beispiel

 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)  Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)

!"#$%&'

Welche Komponente kommuniziert noch mit dem Light Master? TSG 2, ... Wie? TSG Fahrer

48

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Weitere Informationen zu Ports

 Dr. Stefan Bunzel – AUTOSAR Spokesperson (Continental):

Hardware-independent Software Development with AUTOSAR 8. Workshop Automotive Software Engineering 30 September, 2010, Leipzig  O. Kindel, M. Friedrich: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management für

die Praxis. dpunkt.verlag, 2009

 Insgesamt 2 x 5 = 10 verschiedene Typen von Ports  PPort: Provides Interface, Data, Service  RPort: Requires Interface, Data, Service  Sender-Receiver Interface  Client-Server Interface  Calibration Interface  Data of AUTOSAR Service  AUTOSAR Service

49

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Weitere Informationen zu Ports

 Dr. Stefan Bunzel – AUTOSAR Spokesperson (Continental):

Hardware-independent Software Development with AUTOSAR 8. Workshop Automotive Software Engineering 30 September, 2010, Leipzig  O. Kindel, M. Friedrich: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management für

die Praxis. dpunkt.verlag, 2009

 Insgesamt 2 x 5 = 10 verschiedene Typen von Ports  PPort: Provides Interface, Data, Service  RPort: Requires Interface, Data, Service  Sender-Receiver Interface

✔

 Client-Server Interface  Calibration Interface  Data of AUTOSAR Service  AUTOSAR Service

49

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Weitere Informationen zu Ports

 Dr. Stefan Bunzel – AUTOSAR Spokesperson (Continental):

Hardware-independent Software Development with AUTOSAR 8. Workshop Automotive Software Engineering 30 September, 2010, Leipzig  O. Kindel, M. Friedrich: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management für

die Praxis. dpunkt.verlag, 2009

 Insgesamt 2 x 5 = 10 verschiedene Typen von Ports  PPort: Provides Interface, Data, Service  RPort: Requires Interface, Data, Service  Sender-Receiver Interface  Client-Server Interface

✔

✔

 Calibration Interface  Data of AUTOSAR Service  AUTOSAR Service

49

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept

50

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept  Application software functionality implemented in „Software Components“ (SWC)

50

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept

50

...

AUTOSAR SWC n

AUTOSAR SWC 3

AUTOSAR SWC 2

AUTOSAR SWC 1

 Application software functionality implemented in „Software Components“ (SWC)  Handling of vehicle wide functions, independent from ECUs or network

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept

50

...

AUTOSAR SWC n

AUTOSAR SWC 3

AUTOSAR SWC 2

AUTOSAR SWC 1

 Application software functionality implemented in „Software Components“ (SWC)  Handling of vehicle wide functions, independent from ECUs or network  SWCs can communicate between each other and access functions from the standardized set of infrastructure functions

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept

50

...

SWC Description

AUTOSAR SWC n

SWC Description

AUTOSAR SWC 3

SWC Description

AUTOSAR SWC 2

AUTOSAR SWC 1

SWC Description

 Application software functionality implemented in „Software Components“ (SWC)  Handling of vehicle wide functions, independent from ECUs or network  SWCs can communicate between each other and access functions from the standardized set of infrastructure functions  Communication needs of a SWC are formally described in a standard template, i.e. the SWC Description

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept

50

...

SWC Description

AUTOSAR SWC n

SWC Description

AUTOSAR SWC 3

SWC Description

AUTOSAR SWC 2

AUTOSAR SWC 1

SWC Description

 Application software functionality implemented in „Software Components“ (SWC)  Handling of vehicle wide functions, independent from ECUs or network  SWCs can communicate between each other and access functions from the standardized set of infrastructure functions  Communication needs of a SWC are formally described in a standard template, i.e. the SWC Description  Any SWC interaction runs via „Ports“, which implement different communication paradigms, e.g. sender-receiver or client-server

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept

...

Virtual Functional Bus

50

SWC Description

AUTOSAR SWC n

SWC Description

AUTOSAR SWC 3

SWC Description

AUTOSAR SWC 2

AUTOSAR SWC 1

SWC Description

 Application software functionality implemented in „Software Components“ (SWC)  Handling of vehicle wide functions, independent from ECUs or network  SWCs can communicate between each other and access functions from the standardized set of infrastructure functions  Communication needs of a SWC are formally described in a standard template, i.e. the SWC Description  Any SWC interaction runs via „Ports“, which implement different communication paradigms, e.g. sender-receiver or client-server  The VFB  enables a virtual integration of SWCs and  allows to formally verify structural and dynamic compatibility of SWCs

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Development Methodology Virtual Functional Bus Concept – Ports and Interfaces

PPort, provides a Sender-Receiver Interface

SWC Description

SWC Description

SWC Description

SWC Description

RPort, requires a Sender-Receiver Interface

AUTOSAR SWC

...

AUTOSAR SWC n

AUTOSAR SWC 3

AUTOSAR SWC 2

AUTOSAR SWC 1

PPort, provides a Client-Server Interface, i.e. implements service 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)

Virtual Functional Bus

51

RPort, requires AUTOSAR Service as client

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung Virtual Function Bus (VFB)

 Während der Systementwurfsphase werden die SWCs auf Basis des Virtual Function Bus (VFB) logisch

integriert

52

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung System Description

 Zuordnung der Komponenten zu den Steuergeräten  Beschreibung der Netzwerkkommunikation im Fahrzeug

53

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode (1)

 Beschreibt Abläufe von der Systemkonfiguration zur Generierung von Code für Steuergeräte

54

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode (2)

 Erstellung von SWC Description, System Description und System Communication-Matrix unter

Berücksichtigung der System Constraints (Beispiel: Übernahme einer Kommunikationsmatrix aus dem Vorgängerfahrzeug)

55

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode (3)

 Aus SWC Description, System Description und System Communication-Matrix wird die ECU Extract of

System Description generiert

56

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode (4)

 Aus ECU Extract of System Description und BSW Module Description (Herstellerabhängig) werden die

ECU Configuration Description, die konkreten BSW-Module und die RTE (Herstellerunabhängig) generiert

57

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Integration ins Fahrzeug

 Steuergeräte  Bussysteme

58

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

59 2

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Bussysteme im KFZ - Überblick Quelle: Vector Informatik GmbH Details siehe 5.5.5 Protokolle und Bussysteme

60

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

Memory Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

Flash EEPROM Emulation

CAN transc Driver

Microcontroller Drivers

CAN Interface

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

FlexRay TP

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

µC

DIO Driver

ADC Driver

ICU Driver DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

20

61

I/O Hardware Abstraction

Communication Hardware Abstraction

Watchdog Interface

External Watchdog Driver

CAN TP

LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Microcontroller

Communication Services

Memory Services

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

LIN

Memory Drivers

Communication Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

Flash EEPROM Emulation

CAN transc Driver

Microcontroller Drivers

CAN Interface

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

FlexRay TP

I/O Hardware Abstraction

Communication Hardware Abstraction

Watchdog Interface

External Watchdog Driver

CAN TP

LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

CAN

Flexray

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

µC

DIO Driver

ADC Driver

ICU Driver

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

Microcontroller

Communication Services

Memory Services

20

LIN 62

CAN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Flexray

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

Memory Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

Flash EEPROM Emulation

CAN transc Driver

Microcontroller Drivers

CAN Interface

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

FlexRay TP

I/O Hardware Abstraction

Communication Hardware Abstraction

Watchdog Interface

External Watchdog Driver

CAN TP

LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

µC

DIO Driver

ADC Driver

ICU Driver

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

Microcontroller

Communication Services

Memory Services

IP 20

LIN 63

CAN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Flexray

TCIP/IP-Erweiterung in Release 4.0

AUTOSAR Release 4.0 TCP/IP Extension of the CommStack – Overview RTE Signals

IPDU multiplexer I-PDU

Socket adaptor

DCM Diagnostic Communication Manager

AUTOSAR COM

Communication Manager

I-PDU

I-PDU

I-PDU

PDU Router

DoIP

Generic NM interface

I-PDU I-PDU

Socket Interface Messages

FlexRay TP

CAN TP

Streams

UDP Packet

ARP

Segment

IP

FlexRay State Manager CAN State Manager

I-PDU

TCP

DHCP

NM Coordinator

I-PDU

N-PDU

LIN State Manager

N-PDU

I-PDU

ICMP

COTS TCP/IP Stack Datagram

Communication HW Abstraction Ethernet Interface EthFrame

Ethernet Driver

24

64

May 13, 2010

FlexRay Interface

CAN Interface

L-PDU

LIN Interface (incl. LIN TP)

L-PDU

L-PDU

Communication Drivers FlexRay Driver

CAN Driver

LIN Low Level Driver

AUTOSAR Technical Overview

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Eth State Manager

NM NM NM Module UDP NM Module Module Module

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

65 2

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwurf

 Kommunikation über Virtual Function Bus (VFB)  AUTOSAR Interface  Standardized AUTOSAR Interface

66

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwurf

 Kommunikation über Virtual Function Bus (VFB)  AUTOSAR Interface  Standardized AUTOSAR Interface

67

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung

 Abbildung der SWCs auf ECUs  Abbildung der Kommunikation über VFB auf  Kommunikation über RTE  Kommunikation über Bussysteme

68

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung

 Abbildung der SWCs auf ECUs  Abbildung der Kommunikation über VFB auf  Kommunikation über RTE  Kommunikation über Bussysteme

69

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung

 Abbildung der SWCs auf ECUs  Abbildung der Kommunikation über VFB auf  Kommunikation über RTE  Kommunikation über Bussysteme

70

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Logische Kommunikation über RTE

Inter-ECU Communication  Innerhalb eines Steuergerätes  Zwischen Steuergeräten über Kommunikationsbus

mplement the interface according ommunication paradigm (here erver based). ECU I re the interaction Appliof a component. cation SW-C mmunication is A led via the RTE. mmunication layer asic software is ulated and not RTE at the application BSW

ECU II Application SW-C B

Application SW-C C

Application

Ports VFB

RTE

AUTOSAR Infrastructure BSW

Sensor

Hardware

Communication Bus Communication Path 71

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Logische Kommunikation über RTE

Inter-ECU Communication  Innerhalb eines Steuergerätes  Zwischen Steuergeräten über Kommunikationsbus

mplement the interface according ommunication paradigm (here erver based). ECU I re the interaction Appliof a component. cation SW-C mmunication is A led via the RTE. mmunication layer asic software is ulated and not RTE at the application BSW

ECU II Application SW-C B

Application SW-C C

Application

Ports VFB

RTE

AUTOSAR Infrastructure BSW

Sensor

Hardware

Communication Bus Communication Path 72

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Logische Kommunikation über RTE

Inter-ECU Communication  Innerhalb eines Steuergerätes  Zwischen Steuergeräten über Kommunikationsbus

mplement the interface according ommunication paradigm (here erver based). ECU I re the interaction Appliof a component. cation SW-C mmunication is A led via the RTE. mmunication layer asic software is ulated and not RTE at the application BSW

ECU II Application SW-C B

Application SW-C C

Application

Ports VFB

RTE

AUTOSAR Infrastructure BSW

Sensor

Hardware

Communication Bus Communication Path 73

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR SW-Architektur

 AUTOSAR Interface  Standardized AUTOSAR Interface  Standardized Interface

74

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR SW-Architektur

 AUTOSAR Interface  Standardized AUTOSAR Interface  Standardized Interface

75

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR SW-Architektur

 AUTOSAR Interface  Standardized AUTOSAR Interface  Standardized Interface

76

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR SW-Architektur

 AUTOSAR Interface  Standardized AUTOSAR Interface  Standardized Interface

77

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR SW-Architektur

 AUTOSAR Interface: Innerhalb Anwendungssoftware  Generische Schnittstelle, abgeleitet aus den Ports einer SWC.  Werden von RTE bereitgestellt  Schnittstellen zwischen SWCs (VFB)  Schnittstellen zwischen SWC und Steuergeräte-Firmware

 Standardized AUTOSAR Interface: Zwischen Anwendungssoftware und Basissoftware  Vordefiniert durch AUTOSAR Standard  Zugriff von SWC auf BSW-Module des Service Layer

 Standardized Interface: Innerhalb Basissoftware  Im AUTOSAR-Standard als C-API vordefiniert  Zwischen BSW-Modulen in einem Steuergerät  Zwischen RTE und Betriebssystem  Zwischen RTE und Kommunikations BSW

78

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

79 2

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Use Cases of AUTOSAR Results ! Exchange of SW-Components ! Re-use of SW components for different platforms … shown by uses cases pedal management front light management

17

80

Oct. 23rd 2008

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Use Case ‘Pedal Management’ view for one ECU

!

Implementation of functions independent on distribution on different ECU as communication will be done via ECU-individual AUTOSAR-RTE exclusively

void distribute_v(void) { … Rte_Write_p_v(rte_i, v) … }

distribute_v()

void v_warn(void) { … Rte_Read_p_v(rte_i, v) … }

18

81

Oct. 23rd 2008

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Use Case ‘Pedal Management’ view for two ECUs

distribute_v()

e.g. FlexRay, CAN, etc.

Technical benefits

19

82

Oct. 23rd 2008

! ! ! !

Reuse of Intellectual Property Increase in design flexibility Simplification of the integration task Reduction of SW development costs

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Verteilung auf 2 Steuergeräte

unverändert

neu

83

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture

AUTOSAR RTE Standardized Interface

Std. AUTOSAR Interface

AUTOSAR Interface

Services Standardized Interface

Operating System

Std. Interface Complex Device Drivers

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent

LightRequest

Front-Light Manager

Headlight

AUTOSAR Int.

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface

Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent

LightRequest

Front-Light Manager

Headlight

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR Interface

check_switch ()

AUTOSAR Int.

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent check_switch ()

LightRequest

Front-Light Manager

Headlight

AUTOSAR Interface

AUTOSAR Interface

switch_event(event)

switch_event (event)

AUTOSAR Int.

AUTOSAR Interface

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent check_switch ()

LightRequest

Front-Light Manager

switch_event(event)

request_light(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

AUTOSAR Interface

Headlight

AUTOSAR Interface

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent check_switch ()

LightRequest

Front-Light Manager

switch_event(event)

request_light(type, mode)

Headlight

get_keyposition()

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

CAN Driver Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent check_switch ()

LightRequest

Front-Light Manager

Headlight

switch_event(event)

request_light(type, mode)

set_light(type, mode)

get_keyposition() set_light(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

CAN Driver Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent check_switch ()

LightRequest

Front-Light Manager

Headlight

switch_event(event)

request_light(type, mode)

set_light(type, mode)

get_keyposition() set_light(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…)

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture SwitchEvent check_switch ()

LightRequest

Front-Light Manager

Headlight

switch_event(event)

request_light(type, mode)

set_light(type, mode)

get_keyposition() set_light(type, mode) set_dboard(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…)

AUTOSAR Interface

AUTOSAR Interface

AUTOSAR RTE Standardized Interface

Standardized Interface

Operating System

Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

84

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’ mapped to AUTOSAR architecture Integrator

SwitchEvent check_switch ()

Supplier B

OEM

Supplier A

LightRequest

Front-Light Manager

Headlight

switch_event(event)

request_light(type, mode)

set_light(type, mode)

get_keyposition() set_light(type, mode) set_dboard(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…)

AUTOSAR Interface

AUTOSAR Interface

84

Standardized Interface

Operating System

Standardized Interface

Silicon vendor A

Integrator

AUTOSAR RTE Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’: Exchange type of Front Light Integrator

SwitchEvent check_switch ()

Supplier B

OEM

Supplier A

LightRequest

Front-Light Manager

Headlight

switch_event(event)

request_light(type, mode)

set_light(type, mode)

get_keyposition() set_light(type, mode) set_dboard(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…)

AUTOSAR Interface

AUTOSAR Interface

85

Standardized Interface

Operating System

Standardized Interface

Silicon vendor A

Integrator

AUTOSAR RTE Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’: Exchange type of Front Light Integrator

SwitchEvent check_switch ()

Supplier B

OEM

Supplier A

LightRequest

Front-Light Manager

Headlight

switch_event(event)

request_light(type, mode)

set_light(type, mode)

get_keyposition() set_light(type, mode) set_dboard(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…)

AUTOSAR Interface

AUTOSAR Interface

85

Standardized Interface

Operating System

Standardized Interface

Silicon vendor A

Integrator

AUTOSAR RTE Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’: Exchange type of Front Light Integrator

SwitchEvent check_switch ()

Supplier B

OEM

Supplier C

LightRequest

Front-Light Manager

Xenonlight

switch_event(event)

request_light(type, mode)

set_light(type, set_light(type, mode) mode)

get_keyposition() set_light(type, mode) set_dboard(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…) (…) set_current

AUTOSAR Interface

AUTOSAR Interface

85

Standardized Interface

Operating System

Standardized Interface

Silicon vendor A

Integrator

AUTOSAR RTE Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

PWM

CAN Driver

Microcontroller Abstraction

ECU-Hardware

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’: Exchange type of Front Light Integrator

SwitchEvent check_switch ()

Supplier B

OEM

Supplier C

LightRequest

Front-Light Manager

Xenonlight

switch_event(event)

request_light(type, mode)

set_light(type, set_light(type, mode) mode)

get_keyposition() set_light(type, mode) set_dboard(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…) (…) set_current

AUTOSAR Interface

AUTOSAR Interface

85

Standardized Interface

Operating System

Standardized Interface

Silicon vendor B

Integrator

AUTOSAR RTE Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

DIO

CAN Driver

Microcontroller Abstraction

ECU-Hardware

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Software Architecture – AUTOSAR Defined Interfaces Use Case ‘Front Light Management’: Exchange type of Front Light Integrator

SwitchEvent check_switch ()

Supplier B

OEM

Supplier C

LightRequest

Front-Light Manager

Xenonlight

switch_event(event)

request_light(type, mode)

set_light(type, set_light(type, mode) mode)

get_keyposition() set_light(type, mode) set_dboard(type, mode)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

set_current (…) (…) set_current

AUTOSAR Interface

AUTOSAR Interface

85

Standardized Interface

Operating System

Standardized Interface

Silicon vendor B

Integrator

AUTOSAR RTE Std. AUTOSAR Interface

Standardized Interface

AUTOSAR Interface

Services

Communication

ECU Abstraction

Std. Interface

Std. Interface

Std. Interface

AUTOSAR Interface

Complex Device Drivers Standardized Interface DIO

DIO

CAN Driver

Microcontroller Abstraction

ECU-Hardware

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Wechsel von Scheinwerfer auf Xenon-Scheinwerfer

neu

unverändert

86

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung auf drei Steuergeräte

Use case ‘Front-Light Management’ – Multiple ECUs LightRequest

Front-Light Manager

check_switch ()

switch_event(event)

switch_event (event)

request_light (type, mode)

request_light(type, mode) get_keyposition() set_light(type, mode)

SwitchEvent

AUTOSAR Int.

AUTOSAR Interface

ECU3

AUTOSAR RTE

AUTOSAR Standardized Std. AUTOSAR Operating System Interface Interface Interface ECU Communication Control CommuniServices Abstraction cation

Memory Management

Std. Interface

Std. Interface

Std. Interface

Drivers

Hardware

Standardized Interface DIO

CAN Driver

Microcontroller Abstraction

ECU-Hardware

AUTOSAR Interface

ECU4

AUTOSAR RTE Standardized Operating System Interface

Communication Communi- Cont. cation

Memory Management Std. Interface

Drivers

Hardware

Standardized Interface CAN Driver Microcontroller Abstraction

ECU-Hardware

CAN Bus

13

87

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Xenonlight set_light(type, mode) set_current (…)

AUTOSAR Interface

ECU5

AUTOSAR RTE Standardized Operating Interface

AUTOSAR System Interface

Communication Cont. ECU Communication

Abstraction

Std. Interface

Std. Interface

Memory Management Drivers

Hardware

Standardized Interface CAN Driver

PWM

Microcontroller Abstraction

ECU-Hardware

Systementwicklung AUTOSAR-Methode

 Verteilung auf 3 Steuergeräte

unverändert

neu

88

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

http://www.volkswagen.de/de/Volkswagen/InnovationTechnik/ technik-lexikon.html

89

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Xenon-Scheinwerfer

Xenon-Scheinwerfer bieten deutliche Verbesserungen gegenüber konventionellen Halogenlampen. Sie entlasten den Fahrer bei Nachtfahrten durch ihr dem Tageslicht ähnliches Lichtspektrum und führen damit zu mehr Sicherheit. Sie zeichnen sich durch eine große Reichweite sowie eine sehr gute Seitenausleuchtung aus. Weitere Pluspunkte sind der geringe Energieverbrauch sowie die Haltbarkeit, die konventionellen Halogen-Lampen überlegen ist. Als Lichtquelle dient eine so genannte "Gasentladungslampe": Durch einen Funkenüberschlag zwischen zwei Elektroden entsteht in der Xenongas-Atmosphäre im Lampenkolben ein ionisierter Gasschlauch, durch den dann elektrischer Strom fließt, der das Gasgemisch in Form eines Lichtbogens zum Leuchten anregt. Für den Betrieb dieser Lampen ist eine aufwendige Elektronik erforderlich, um unter anderem die hohe Zündspannung von 18.000 bis 30.000 Volt zu erzeugen und das automatische Wiederzünden und den konstanten Betrieb (bei nur 35 Watt Leistung) zu gewährleisten.

90

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Xenon-Scheinwerfer

Xenon-Scheinwerfer bieten deutliche Verbesserungen gegenüber konventionellen Halogenlampen. Sie entlasten den Fahrer bei Nachtfahrten durch ihr dem Tageslicht ähnliches Lichtspektrum und führen damit zu mehr Sicherheit. Sie zeichnen sich durch eine große Reichweite sowie eine sehr gute Seitenausleuchtung aus. Weitere Pluspunkte sind der geringe Energieverbrauch sowie die Haltbarkeit, die konventionellen Halogen-Lampen überlegen ist. Als Lichtquelle dient eine so genannte "Gasentladungslampe": Durch einen Funkenüberschlag zwischen zwei Elektroden entsteht in der Xenongas-Atmosphäre im Lampenkolben ein ionisierter Gasschlauch, durch den dann elektrischer Strom fließt, der das Gasgemisch in Form eines Lichtbogens zum Leuchten anregt. Für den Betrieb dieser Lampen ist eine aufwendige Elektronik erforderlich, um unter anderem die hohe Zündspannung von 18.000 bis 30.000 Volt zu erzeugen und das automatische Wiederzünden und den konstanten Betrieb (bei nur 35 Watt Leistung) zu gewährleisten.

91

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Bi-Xenon-Scheinwerfer

Der Bi-Xenon-Scheinwerfer ("Bi" = Zwei) ist eine Weiterentwicklung des Xenon-Scheinwerfers. Mit einem Scheinwerfer können sowohl Abblend- als auch Fernlicht erzeugt werden. Eine bewegliche Blende (Shutter) schirmt beim Abblendlicht einen Teil des Lichtstrahls ab. Wird die Lichthupe, beziehungsweise das Fernlicht betätigt, wird die Blende aus dem Lichtstrahl bewegt und gibt die zusätzliche Leuchtkraft frei.

92

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Anpassung Limousine - Kabrio, Kombi

neu (teilweise)

neu (teilweise)

neu (eventuell)

93

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Anpassung an andere Modelle

94

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Anpassung an andere Modelle bei gleicher Funktionsarchitektur

unverändert

95

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Anpassung an andere Modelle bei gleicher E/E-Architektur

unverändert

96

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Anpassung an andere Modelle bei gleicher Vernetzung/Verkabelung

unverändert

97

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Systementwicklung AUTOSAR-Methode

 Anpassung an andere Modelle bei gleicher Funktionsarchitektur, gleicher E/E-Architektur und gleicher

Vernetzung/Verkabelung unverändert

unverändert

unverändert

98

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

99

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

Schiebedach

Heckklappe

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

99

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

Schiebedach

Heckklappe

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine  Coupé

99

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

Schiebedach

Heckklappe

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine  Coupé  Kombi

99

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

Schiebedach

Heckklappe

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 Coupé

99

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 Coupé

99

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 Coupé

 SWC Description

Beschreibung der SW-Funktionen

99

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 Coupé

 SWC Description

Beschreibung der SW-Funktionen  System Description

Verteilung der Funktionen auf die Steuergeräte

99

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 Coupé

 SWC Description

Beschreibung der SW-Funktionen  System Description

Verteilung der Funktionen auf die Steuergeräte  System Communication-Matrix

Vernetzung der Steuergeräte

99

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 Coupé

 SWC Description

Beschreibung der SW-Funktionen  System Description

Verteilung der Funktionen auf die Steuergeräte  System Communication-Matrix

Vernetzung der Steuergeräte

100

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine  Coupé

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 SWC Description

Beschreibung der SW-Funktionen  System Description

Verteilung der Funktionen auf die Steuergeräte  System Communication-Matrix

Vernetzung der Steuergeräte

101

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Verteilung der Karosseriefunktionen auf Steuergeräte

 Limousine

Dachsteuergerät (DSG)

Hecksteuergerät (HSG)

 Kombi

Schiebedach

Heckklappe

 Cabriolet

Beleuchtung Innenraum

Verdeck

Türsteuergerät F (TSG F)

Türsteuergerät BF (TSG BF)

Türschliessen vorne F

Türschliessen vorne BF

Türschliessen hinten F

Türschliessen hinten BF

Fensterheber vorne F

Fensterheber vorne BF

Fensterheber hinten F

Fensterheber hinten BF

 Coupé

 SWC Description

Beschreibung der SW-Funktionen  System Description

Verteilung der Funktionen auf die Steuergeräte  System Communication-Matrix

Vernetzung der Steuergeräte

102

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Soweit zur Theorie, in der Praxis

Auch AUTOSAR hat sich diesem Thema eingehend gewidmet. Während ältere Implementierungen von Diagnosemodulen im Wesentlichen auf proprietären Schnittstellen aufsetzen und Diagnosedienste größtenteils nicht umfassend konfiguriert werden konnten, stellt AUTOSAR ein universelles und flexibles Diagnosemodul zur Verfügung. Alle Schnittstellen des DCM-Moduls sind standardisiert – sowohl zwischen DCM und Applikation als auch zu den anderen BSW-Modulen. Dadurch kann das Diagnosemodul

 „Es gibt nur wenige AUTOSAR-Schnittstellen

weils so aufwendig ist.“  Folgende Punkte aus dem Vortrag von Dipl.-

Phys. Andreas Möstel, Robert-Bosch GmbH sollten in Erinnerung bleiben:  Bosch verwendet für die Implementierung des

Steuergerätes DCM ein Autosar Stack von Elektrobit mit 7 BMW spezifischen Modulen und einer MCAL Anpassung von Infineon.  Die jetztige Tool Landschaft und Unterstützung macht die

Einbindung von neuen Funktionalitäten (wie z.B. eines neuen Signals) sehr aufwändig, an vielen Komfigurationsdateien des AUTOSAR Stacks muss geändert werden und die Konsistenz wird nicht durch die Tools unterstützt.

Bild 2: Schnittstellen und Aufbau des DCM-Moduls

 Die Konfiguration des AUTOSAR Stacks erlaubt keinen

Merge-Funktion. Beispiel 80% ist von Projekt übernehmbar und nur 20% wäre auszutauschen für eine andere Baureihe oder OEM. Dazu muss der komplette Stack getrennt und isoliert verwaltet und konfiguriert werden.

103

problemlos ausgetauscht und wieder verwendet werden. Durch seine einfache Konfigurierbarkeit wird die Integration in die Anwendung wesentlich erleichtert. Für die Konfiguration der Basissoftware ergeben sich besondere Vorteile, wenn auf bereits bestehende Datenquellen, zum Beispiel eine Diagnosespezifikation im ODXFormat, zurückgegriffen werden kann. Ziel der SoftingAktivitäten ist es, an geeigneter Stelle die Verbindung zwischen Standards wie ASAM-ODX oder FIBEX und AUTOSAR in einer einheitlichen Werkzeugumgebung anzubieten und damit das Potenzial für erhebliche Kosten- und Qualitätsvorteile zu schaffen. Aufgabe des DCM-Moduls ist es, die von den unteren LayProf. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013 ern empfangenen Requests entgegenzunehmen, nach Diagnosediensten (OBD – ISO 15031-5 [3] und UDS – ISO

Response an das DCM-Modu wort nicht innerhalb der kon sendet das DCM selbststän Nachricht“. Die Applikation AUTOSAR Runtime Environm bunden. Um die aktuellen oder gesp die zugehörigen Freeze-Fra auszulesen oder zu löschen, w Event Manage funktionen ber geeigneter Rei können. Die Sc tion Manager Wesentlichen mationen zum status. Vom PD richten von den Bussysteme ( DCM weiterge Das DCM-Mod ! DSL – Diagn ! DSD – Diagn ! DSP – Diagn Die DSL-Schich PDU-Router zu © automotive der Kommunika einem synchro Asynchrone Funktion: Eine und das DSL-Modul prüft, werden soll. Gegebenenfalls tionen mit geringerer Prioritä aus werden Timer zur K gestartet. Synchrone Funktion: Zyklis der Timer überwacht, das „S rity Access Handling” verwa se-Verhalten“ (z. B. Antwort sent“) abgearbeitet. Aufgabe der DSD-Schicht ist genen Diagnosedatenstroms ! Weiterverarbeitung des quests und Weiterreichen d

Unterschiedliche Interessen

 Automobilhersteller  Wiederverwendung  Austauschbarkeit von Zulieferern  Kostensenkung durch geringere Einkaufspreise

 Zulieferer  Wiederverwendung  Verkauf an verschiedene Kunden  Kostensenkung durch höhere Stückzahlen  Keine Austauschbarkeit

 Werkzeughersteller, BSW-Anbieter  Keine Austauschbarkeit

 Halbleiterhersteller  Ein MCAL für alle BSW unabhängig vom BSW-Anbieter

104

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

CUBAS

 Bosch entwickelt eine eigene AUTOSAR-Basis-Software, die für alle Steuergeräteplattformen der

Geschäfts- und Produktbereiche des gesamten Unternehmensbereichs Kraftfahrzeugtechnik (UBK) eingesetzt wird. Sie wird als CUBAS (Common UBK Basis-Software) bezeichnet.

105

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Consulting

Provided by customers of XYZ

Microcontroller abstraction layer to be developped

Microcontrollers by XYZ

66

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Artop – AUTOSAR Tool Platform !"#$%!&'#(()' *)+,-(./ 012'3+.'4#

*'+,-$. */)01*2$),,3$43&+5,'67 *'+,-7

!"#$%&'()*+,-.&/,0&12&-(3445

!"#$%&'$() 107

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

7. Normen und Standards 1. AUTOSAR

1. Organisation 2. Schichtenmodell 3. Systementwicklung 4. Bussysteme im KFZ 5. Software-Architektur 6. Anwendungsbeispiele 7. Geplante AUTOSAR-Anwendungen

108 2

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Initial WP structure Phase III

Work Packages 1

2

3

10

System Architecture

Software and Test Specification

Validation

Application Interfaces

2.1

WP-3.1

WP-10.0

Basic Software

Basic Software Validation

Coordination of Appl. Interfaces

1.1 Software Architecture WP-1.1.1

WP-1.1.2

Software Architecture and OS

Vehicle and Application Mode Mgmt.

WP-2.1.1

WP-10.1

COM Stack

Body and Comfort

WP-2.1.3 WP-1.1.5

MCAL

VFB and RTE

WP-2.1.4

Existence of Work Packages will depend on sufficient participation

WP-10.2 Powertrain

Diagnostics WP-10.3

WP-1.2 Methodology and Configuration WP-1.3 Functional Safety

WP-2.1.5

Chassis Control

Libraries WP-2.2 Conformance Test Specification

Lead Work Package

WP-10.4 Occupants and Pedest. Safety WP-10.5 MM / T / HMI

109

WP-x.y

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

WP-x.y Work Package

AUTOSAR Application Interfaces Compositions under Consideration !

Body Domain " " " " " " " "

!

" Central Locking " Interior Light " Mirror Adjustment " Mirror Tinting " Seat Adjustment " Wiper/Washer " Anti Theft Warning System " Horn Control "

Exterior Lights Defrost Control Seat climatization Cabin climatization Steering wheel climatization Window Control Sunroof/Convertible control Steering column adjustment Roller blind control

Chassis Control Domain Vehicle Longitudinal Control Electronic Stability Program Electronic Parking Brake Adaptive Cruise Control Roll Stability Control Steering System Suspension System Stand Still Manager High Level Steering " Vehicle Stability Steering " Driver Assistance Steering " All Wheel Drive/ Differential Lock

" " " " " " " " "

61

110

Oct. 23rd 2008

!

Powertrain Domain " Powertrain Coordinator " Transmission System " Combustion Engine " Engine torque and mode management " Engine Speed And Position " Combustion Engine Misc. " Electric Machine " Vehicle Motion Powertrain " Driver Request " Accelerator Pedal Position " Safety Vehicle Speed Limitation

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Application Interfaces Compositions under Consideration !

Body Domain " " " " " " " "

!

" Central Locking " Interior Light " Mirror Adjustment " Mirror Tinting " Seat Adjustment " Wiper/Washer " Anti Theft Warning System " Horn Control "

Exterior Lights Defrost Control Seat climatization Cabin climatization Steering wheel climatization Window Control Sunroof/Convertible control Steering column adjustment Roller blind control

Chassis Control Domain Vehicle Longitudinal Control Electronic Stability Program Electronic Parking Brake Adaptive Cruise Control Roll Stability Control Steering System Suspension System Stand Still Manager High Level Steering " Vehicle Stability Steering " Driver Assistance Steering " All Wheel Drive/ Differential Lock

" " " " " " " " "

61

110

Oct. 23rd 2008

!

Powertrain Domain " Powertrain Coordinator " Transmission System Unterhaltungselektronik " Combustion Engine Entertainment " Engine torque and mode management Telematik ? " Engine Speed And Position " Combustion Engine Misc. " Electric Machine " Vehicle Motion Powertrain " Driver Request " Accelerator Pedal Position " Safety Vehicle Speed Limitation

AUTOSAR Tutorial

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Release 4.0 Examples for Application Interfaces SwitchEvent

LightRequest

check_switch ()

switch_event(event)

switch_event (event)

request_light (type, mode)

AUTOSAR Int.

AUTOSAR Interface

AUTOSAR RTE Services

AUTOSAR Interface ECU Abstraction

Standardized Interface Communication

Std. Interface

Std. Interface

Std. Interface

Std. AUTOSAR Interface

Standardized Interface DIO

CAN Driver

Microcontroller Abstraction

ECU-Hardware

Front-Light Manager ¾ Park Distance Control

¾

request_light(type, mode) get_keyposition() set_light(type, Exterior lightmode)

AUTOSAR Interface

¾ Mirror adjustments

AUTOSAR RTE

¾ Seat adjustments Standardized

Interface ¾ Anti Theft System Communication

¾ Interior light Std. Interface ¾ Defrost control

Standardized Interface

CAN Driver

¾ Remote keyless entry

Microcontroller Abstraction

ECU-Hardware ¾ and many more

Xenonlight set_light(type, mode) set_current (…)

AUTOSAR Interface

AUTOSAR RTE Standardized Interface Communication

AUTOSAR Interface ECU Abstraction

Std. Interface

Std. Interface

Standardized Interface CAN Driver

Microcontroller Abstraction

ECU-Hardware

CAN Bus

20

111

May 13, 2010

PWM

AUTOSAR Technical Overview

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

Memory Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

Flash EEPROM Emulation

CAN transc Driver

Microcontroller Drivers

CAN Interface

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

FlexRay TP

I/O Hardware Abstraction

Communication Hardware Abstraction

Watchdog Interface

External Watchdog Driver

CAN TP

LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

µC

DIO Driver

ADC Driver

ICU Driver

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

Microcontroller

Communication Services

Memory Services

20

LIN 112

CAN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Flexray

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

Memory Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

Flash EEPROM Emulation

CAN transc Driver

Microcontroller Drivers

CAN Interface

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

FlexRay TP

I/O Hardware Abstraction

Communication Hardware Abstraction

Watchdog Interface

External Watchdog Driver

CAN TP

LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

µC

DIO Driver

ADC Driver

ICU Driver

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

Microcontroller

Communication Services

Memory Services

IP 20

LIN 112

CAN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Flexray

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

Memory Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

Flash EEPROM Emulation

CAN transc Driver

Microcontroller Drivers

CAN Interface

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

FlexRay TP

AUTOSAR 4.0

I/O Hardware Abstraction

Communication Hardware Abstraction

Watchdog Interface

External Watchdog Driver

CAN TP

LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

µC

DIO Driver

ADC Driver

ICU Driver

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

Microcontroller

Communication Services

Memory Services

IP 20

LIN 112

CAN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Flexray

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

Memory Drivers

Ext. FR Driver

Ext. Flash Driver

FR Interface FR transc Driver

Flash EEPROM Emulation

CAN transc Driver

Microcontroller Drivers

CAN Interface

Ext. CAN Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Ext. EEPROM Driver

CAN NM FR SM

FlexRay TP

AUTOSAR 4.0

I/O Hardware Abstraction

Communication Hardware Abstraction

Watchdog Interface

External Watchdog Driver

CAN TP

LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

µC

DIO Driver

ADC Driver

ICU Driver

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

Microcontroller

Communication Services

Memory Services

IP 20

MOST!! 112

LIN

CAN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Flexray

AUTOSAR Basis Software Module

AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) System Services

PDU Router

IPDU Multiplexer

LIN TP

CAN TP

CAN Interface

Memory Drivers

Ext. FR Driver

Microcontroller Drivers

Ext. CAN Driver

Emulation Mittlerweile Ext. Ext. Flash EEPROMRealisierungen von Driver Driver BSW-Anbietern

FR Interface FR transc Driver

Flash EEPROM

CAN transc Driver

CRC Lib

BSW Scheduler

AUTOSAR OS

Watchdog Interface

External Watchdog Driver

CAN NM FR SM

FlexRay TP

AUTOSAR 4.0

I/O Hardware Abstraction

Communication Hardware Abstraction LIN Interface

Memory Abstraction Interface EEPROM Abstraction

LIN SM

FlexRay NM

Development Error Tracer

Communication Manager

Watchdog Manager

Diagnostic Event Manager DEM

Function Inhibition Manager FIM

ECU State Manager

NVRAM Manager

I/O Hardware Abstraction

Generic NM Interf.

CAN SM

DCM Diagnostic Com. Manager

AUTOSAR COM

Memory Hardware Abstraction

Onboard Device Abstraction

Communication Drivers

I/O Drivers

PORT Driver e.g. CCU

e.g. PCP

e.g. TPU

DIO

ADC

PWM

CCU

FlexRay

CAN

LIN

µC

DIO Driver

ADC Driver

ICU Driver

PWM Driver

FR Driver

CAN Driver

LIN Driver

LIN Communication Stack

SPI

SCI

internal Flash Driver

FLASH

SPI Handler Driver

internal EEPROM Driver

EEPROM

Ext. BUS

WDT

MCU Power & Clock Unit

GPT

RAM Test

Watchdog Driver

MCU Driver

GPT Driver

Flash Check

Microcontroller

Communication Services

Memory Services

IP 20

MOST!! 112

LIN

CAN

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Flexray

AUTOSAR Basis Software Module Microsar von Vector Informatik

113

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

AUTOSAR Roll-Out The AUTOSAR Core Partner Exploitation Plan (2008 - 2012) Core Partner

2008

2009

2010

! ! 10 AUTOSAR BSW modules as part of Std Core in vehicles, tool / serial support in place ! Body Computer with subset of AUTOSAR specs incorporated ! Instrument Cluster with subset of AUTOSAR specs incorporated ! Complete BSW Stack as Product ! AUTOSAR Configuration Tool

2011 ! Powertrain-, Chassis-, Safety-, Body- ECUs use AUTOSAR architecture

! ACC ECU using AUTOSAR architecture. ! Powertrain EDC/ME(D)17 ECUs using AUTOSAR architecture ! Domain Control Unit using AUTOSAR BSW ! Body ECUs using AUTOSAR architecture ! Powertrain ECUs using AUTOSAR architecture

! Chassis ECU using AUTOSAR architecture ! Body Computer using AUTOSAR architecture

! 1-2 AUTOSAR conformant ECUs; first use of conformant tools/methodology

! First AUTOSAR compatible ECUs in vehicles

! First use of AUTOSAR architecture ECU

! Body ECU using AUTOSAR architecture ! First usage of AUTOSAR modules

! First AUTOSAR modules in series production

! Introduction of AUTOSAR architecture and methodology in vehicles

! Continuous roll-out of ECUs into vehicle architecture increased use of conformant tools / methodology ! First usage of AUTOSAR modules

! Powertrain ECU using AUTOSAR architecture

! Engine Systems Platform based on AUTOSAR architecture

! Chassis ECUs using AUTOSAR architecture ! First usage of AUTOSAR modules in vehicles

114

2012

! AUTOSAR Architecture ECU

! First complete ECUs in series production

26 8. October 2009 AUTOSAR – A Worldwide Standard is on the Road Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013

Weiterführende Literatur

 O. Kindel, M. Friedrich:

Softwareentwicklung mit AUTOSAR Grundlagen, Engineering, Management in der Praxis dpunkt.verlag, 2009.  AUTOSAR: Automotive Open System Architecture, "http://www.autosar.org".  AUTOSAR Tutorial: http://www.autosar.org/download/conferencedocs/03_AUTOSAR_Tutorial.pdf  AUTOSAR Software Modules, Specialized Glossary

Vector Informatik GmbH. (In der Vorlesung verteilt)

115

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Darmstadt, Fachbereich Elektrotechnik und Informationstechnik, Wintersemester 2012/2013