Vorlesung Automotive Software Engineering Teil 7 Normen...

INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG

Vorlesung Automotive Software EngineeringTeil 7 Normen und Standards (1)

TU Dresden, Fakultät Informatik

Sommersemester 2012

Prof. Dr. rer. nat. Bernhard Hohlfeld

[email protected]

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2012

Vorlesung Automotive Software Engineering

2

Motivation und ÜberblickMotivation und ÜberblickMotivation und Überblick

Beispiele aus der Praxis

SW-Entwicklung

Normen und Standards


E/E-Entwicklung


Beispiele aus der Praxis Das Automobil Normen und

StandardsBeispiele aus

der Praxis

Die Automobilherstellung



Die Automobilbranche

Normen und Standards OSEK/ VDX

ASAM

ISO 26262 Road vehicles - Functional safety


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 Dresden, Fakultät Informatik, Sommersemester 2012 2

1. AUTOSAR

2. ARTOP

3. Vorgehensmodelle und funktionale Sicherheit

7. Normen und Standards

4


1. AUTOSAR

2. ARTOP

3. Vorgehensmodelle und funktionale Sicherheit

7. Normen und Standards

5


Software im Fahrzeug - siehe Teil 2 Die Automobilbranche

6

Kupferband(Halbzeug)

Anwärmen

Fräsen

Querteilen

Längsteilen

kalt Vorwalzen

Zwischen und Fertigwalzen

Warmwalzen

Inspektion

Bleche

Bänder

Schema der Fertigung vonBändern und Blechen

14

Steckverbinder

Türe

Fahrzeug

SW-Entwicklungs-werkzeuge

Engineering Dienstleistungen

Halbleiter

PressenSteuergerät

Neue Beziehungen, Kompetenzen und Verantwortlichkeiten zwischen OEM und Zulieferer erforderlich


Anforderungen

7


1. Organisation

2. Schichtenmodell

3. Systementwicklung

4. Bussysteme im KFZ

5. Software-Architektur

6. Anwendungsbeispiele

7. Geplante AUTOSAR-Anwendungen

7. Normen und Standards 1. AUTOSAR

8


AUTOSAR ist ganz einfach zu verstehen

9

DB

DB

DB

ATM


1. Organisation

2. Schichtenmodell







10


AUTOSAR – Core Partners and Members (Phase II)

Ca. 170 Firmen (Stand Ende 2009)

11


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


AUTOSAR Membership Levels

Core Partners

Organizational control

Technical contributions

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

Involvement in Working Groups


Access to current information


Associate Members

Access to finalized documents


Development Members (for small companies with specific expertise)


Access to current information


Attendee (e.g. Universities)

Support Role

13


Executive Board

Legal Team Follow-up Team

Core Partner

Core Partner, Premium and Development Member

Subcontractor

System Architecture

Application Interfaces

Software and Test Specification Validation

Quality Manager

Change Manager

Release Manager

Technical Office

… … … …

Administration

General Manager

AUTOSAR Phase III Organization

14

Steering Commitee

Technical Steering Team

Communica-tionTeam


Initial WP Structure Phase III

Existence of Work Packages will

depend on sufficient

participation

Work Packages

Functional Safety

WP-1.3

Body and Comfort

WP-10.1

Powertrain

WP-10.2

Chassis Control

WP-10.3

Occupants and Pedest. Safety

WP-10.4

Methodology and Configuration

WP-1.2

Conformance Test Specification

WP-2.2

Software Architecture

1.1


and OS

WP-1.1.1Vehicle and

Application Mode Mgmt.

WP-1.1.2

COM Stack

WP-2.1.1

MCALWP-2.1.3

Diagnostics

WP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2

Software and Test Specification

3

Validation

Coordination of Appl. Interfaces

WP-10.0

10


LibrariesWP-2.1.5

VFB and RTE

WP-1.1.5

Lead Work Package

WP-x.y

Work Package

WP-x.y

15


Initial WP structure Phase III



participation

Work Packages

Functional Safety

WP-1.3

Body and Comfort

WP-10.1

Powertrain

WP-10.2

Chassis Control

WP-10.3


WP-10.4


WP-1.2


WP-2.2


1.1


and OS

WP-1.1.1Vehicle and


WP-1.1.2

COM Stack

WP-2.1.1

MCALWP-2.1.3

Diagnostics

WP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2


3

Validation


WP-10.0

10


LibrariesWP-2.1.5

VFB and RTE

WP-1.1.5

Lead Work Package

WP-x.y

Work Package

WP-x.y

16


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





participation

Work Packages

Functional Safety

WP-1.3

Body and Comfort

WP-10.1

Powertrain

WP-10.2

Chassis Control

WP-10.3


WP-10.4


WP-1.2


WP-2.2


1.1


and OS

WP-1.1.1Vehicle and


WP-1.1.2

COM Stack

WP-2.1.1

MCALWP-2.1.3

Diagnostics

WP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2


3

Validation


WP-10.0

10


LibrariesWP-2.1.5

VFB and RTE

WP-1.1.5

Lead Work Package

WP-x.y

Work Package

WP-x.y

18


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 inthe automotive community

Internal and external libraries for off-the-shelf applications

Convenient integration into the development chain of Tier1s and OEMs

Faster SW integration processes

Standard application interfaces for‘SW as a product’

19

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

ApplicationInterfaces Methodology

Architecture/Basic Software

Workflow

.xml

Data Exchange


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

20

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


AUTOSAR TutorialOct. 23rd 20089

Technical scope of AUTOSAR

Industry-wide

consolidation of

‚existing‘ basic

software designs

New

concepts

OS Kernel

Memory

Services

µController

Abstraction

ECU

Abstraction

Diagnostics

Complex

Drivers

Bus systems

Mode

Management

Gateway

Network

Management

Comm.

Services

Drivers

RunTime

Environment

Configuration

Concept

Exchange

Formats

Input

Templates

Methodology

Virtual Function

Bus (VFB)

Meta Model

Error

Handling



Technical scope of AUTOSAR

Industry-wide

consolidation of

‚existing‘ basic

software designs

New

concepts

OS Kernel

Memory

Services

µController

Abstraction

ECU

Abstraction

Diagnostics

Complex

Drivers

Bus systems

Mode

Management

Gateway

Network

Management

Comm.

Services

Drivers

RunTime

Environment

Configuration

Concept

Exchange

Formats

Input

Templates

Methodology

Virtual Function

Bus (VFB)

Meta Model

Error

Handling


1. Organisation

2. Schichtenmodell 09.07.2012







23


AUTOSAR Architekturkonzept

24


AUTOSAR-Schichtenmodell Abstraktionsschichten der Steuergerätesoftware

25

Anwendungsschicht (Application Layer)

Laufzeitumgebung (Runtime Environment, RTE)

Basissoftware (BSW)

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell Anwendungsschicht (Application Layer)

26

Der Application Layer realisiert die Anwendungsfunktionalität des Steuergeräts mittels Anwendungs-Softwarekomponenten (SWC - Software Component).

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell Laufzeitumgebung (Runtime Environment, RTE)

27

Die Laufzeitumgebung (Runtime Environment, RTE) integriert den Application Layer mit der Basissoftware (BSW). Sie implementiert den Datenaustausch zwischen Anwendungs-Softwarekomponenten (SWC) und steuert die Interaktion zwischen SWCs und der BSW.

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell BSW - Service Layer

28

Der Service Layer stellt verschiedene Arten von Hintergrunddiensten wie Netzwerkdienstze, Speicherverwaltung und Buskommunikationsdienste bereit. Das Betriebssystem ist ebenfalls in dieser Schicht enthalten.

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell BSW - ECU Abstraction Layer

29

Der ECU Abstraction Layer bietet einen einheitlichen Zugriff auf alle Funktionalitäten eines Steuergeräts wie Kommunikation, Speicher oder E/A.

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

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell BSW - Microcontroller Abstraction Layer

30

Der Microcontroller Abstraction Layer (MCAL) bietet beispielsweise Treiber für den Zugriff auf Kommunikation, Speicher und E/A des Mikrocontrollers.

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

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell BSW - Complex Drivers

31

Die Complex Drivers enthalten die in AUTOSAR nicht standardisierten Treiber für die spezifischen Eigenschaften eines Mikrocontrollers oder Steuergeräts.

Bas

isso

ftwar

e (B

SW

)



32

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)


Beispiel Zeitbeschränkungen

Bremsen mit Verwendung des AUTOSAR-Schichtenmodells: Zu langsam durch die vielen Software-Schichten

Bremspedal Bremse

Kommunikationsbus43


Beispiel Zeitbeschränkungen

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

Bremspedal Bremse

Kommunikationsbus44



35

Weiterverwendung

Bewährtes BSW-Modul



36

Weiterverwendung

RTE-Schnittstelle




37

Weiterverwendung

RTE-Schnittstelle

Anwendungssoftware


= Complex

Driver


AUTOSAR Basis Software Module

38 20

AUTOSAR Runtime Environment (RTE)

Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver

Microcontroller Drivers

Watchdog D

river

MC

U D

river

GP

T D

river

Communication Drivers

CA

N D

river

LIN D

river

SP

I Handler D

riverMemory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river

Communication Services

Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer

Communication Hardware Abstraction

Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services

Function Inhibition M

anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S

I/O Hardware Abstraction

Memory Hardware Abstraction

Memory Abstraction Interface

Onboard Device Abstraction

External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver

Flash EEPROM Emulation

FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN InterfaceC

AN

transcD

river

Ext. F

R

Driver

FR Interface

FR

transcD

riverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager


AUTOSAR Basic Software Modules

CANSM

LINSM

FRSM

EC

U S

tate Manager


1. Organisation

2. Schichtenmodell







39


SystementwicklungAUTOSAR 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

40


Systementwicklung

Die Anwendungssoftware wird unabhängig vom konkreten Steuergerät als ein System von untereinander verbundenen SWCs entworfen

41


Systementwicklung

Die Anwendungssoftware wird unabhängig vom konkreten Steuergerät als ein System von untereinander verbundenen SWCs entworfen

42


SystementwicklungFormale Definition der Schnittstellen

Sender/Empfänger-Ports

Client/Server-Ports

43


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.

44

Quelle: http://www.autosar.org


SystementwicklungClient/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.

45

Quelle: http://www.autosar.org


Beispiel

Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)

Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)

46

!"#$%!&'%()*+,-.'!-/01*./*2-. 34

!"#$%&'


Beispiel



46

!"#$%!&'%()*+,-.'!-/01*./*2-. 34

!"#$%&'

TSG Fahrer

TSG 2, ...


Beispiel



46

!"#$%!&'%()*+,-.'!-/01*./*2-. 34

!"#$%&'Welche Komponente kommuniziert noch mit dem Light Master?

TSG Fahrer

TSG 2, ...


Beispiel



46

!"#$%!&'%()*+,-.'!-/01*./*2-. 34

!"#$%&'Welche Komponente kommuniziert noch mit dem Light Master?

Wie?

TSG Fahrer

TSG 2, ...


Weitere Informationen zu Ports

Dr. Stefan Bunzel – AUTOSAR Spokesperson (Continental): Hardware-independent Software Development with AUTOSAR8. Workshop Automotive Software Engineering30 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

47












AUTOSAR Service

47

✔












AUTOSAR Service

47

✔

✔


AUTOSAR Development MethodologyVirtual Functional Bus Concept



Application software functionality implemented in „Software Components“ (SWC)


...

AU

TOSA

RSW

Cn

AU

TOSA

RSW

C3

AU

TOSA

RSW

C2

AU

TOSA

RSW

C1



Handling of vehicle wide functions, independent from ECUs or network


...

AU

TOSA

RSW

Cn

AU

TOSA

RSW

C3

AU

TOSA

RSW

C2

AU

TOSA

RSW

C1




SWCs can communicate between each other and access functions from the standardized set of infrastructure functions


...

AU

TOSA

RSW

Cn

AU

TOSA

RSW

C3

AU

TOSA

RSW

C2

AU

TOSA

RSW

C1





Communication needs of a SWC are formally described in a standard template, i.e. the SWC Description

SWCDescription

SWCDescription

SWCDescription

SWCDescription


...

AU

TOSA

RSW

Cn

AU

TOSA

RSW

C3

AU

TOSA

RSW

C2

AU

TOSA

RSW

C1






Any SWC interaction runs via „Ports“, which implement different communication paradigms, e.g. sender-receiver or client-server

SWCDescription

SWCDescription

SWCDescription

SWCDescription


Virtual Functional Bus

...

AU

TOSA

RSW

Cn

AU

TOSA

RSW

C3

AU

TOSA

RSW

C2

AU

TOSA

RSW

C1






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

SWCDescription

SWCDescription

SWCDescription

SWCDescription


AU

TOSA

R S

WC

Virtual Functional Bus

...

PPort, provides a Sender-Receiver Interface

RPort, requires a Sender-Receiver Interface

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

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

PPort, provides data to AUTOSAR Service

PPort, provides AUTOSAR Service (in BSW only)

AU

TOSA

RSW

Cn

SWCDescription

PPort, provides a Calibration Interface

RPort, requires a Calibration Interface

RPort, requires AUTOSAR Service as client

RPort, requires data from AUTOSAR Service

AU

TOSA

RSW

C3

SWCDescription

AU

TOSA

RSW

C2

SWCDescription

AU

TOSA

RSW

C1

SWCDescription

AUTOSAR Development MethodologyVirtual Functional Bus Concept – Ports and Interfaces


SystementwicklungVirtual Function Bus (VFB)

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

50


SystementwicklungSystem Description

Zuordnung der Komponenten zu den Steuergeräten

Beschreibung der Netzwerkkommunikation im Fahrzeug

51


SystementwicklungAUTOSAR-Methode (1)

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

52



Erstellung von SWC Description, System Description und System Communication-Matrix unter Berücksichtigung der System Constraints (Beispiel: Übernahme einer Kommunikationsmatrix aus dem Vorgängerfahrzeug)

53



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

54



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

55


Integration ins Fahrzeug

Steuergeräte

Bussysteme

56


1. Organisation

2. Schichtenmodell







57


Bussysteme im KFZ - ÜberblickQuelle: Vector Informatik GmbHDetails siehe 5.5.5 Protokolle und Bussysteme

58



59

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager



60

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager

LIN CAN Flexray

LIN CAN Flexray



61

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager

LIN CAN Flexray

IP


TCIP/IP-Erweiterung in Release 4.0

62

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

Communication HW Abstraction

RTE


AUTOSAR COM

FlexRay Interface CAN Interface LIN Interface (incl. LIN TP)

N-PDU

Communication Manager

Signals

FlexRay Driver CAN Driver LIN Low Level Driver

FlexRay TP

I-PDU

DCMDiagnostic

Communication Manager

CAN TP

I-PDU

I-PDU

I-PDU

I-PDU

N-PDU

L-PDU L-PDU L-PDU

IPDU multi- plexer

I-PDU

NM Coordinator

GenericNM interface

FlexRayState

Manager

NM Module

CAN State Manager

LIN State Manager

NM ModuleNM

ModuleEth State Manager

UDP NM Module

Socket adaptor

Ethernet Interface

Ethernet Driver

Eth- Frame

COTS TCP/IP Stack

Streams

IP

TCPUDP

Segment

Messages

Packet

ARP ICMP

Socket Interface

Datagram

I-PDU

I-PDU

DHCP

DoIPPDU Router

I-PDU

May 13, 2010 AUTOSAR Technical Overview24


1. Organisation

2. Schichtenmodell







63


Systementwurf

64

Kommunikation über Virtual Function Bus (VFB)

AUTOSAR Interface

Standardized AUTOSAR Interface


Systementwurf

65

Kommunikation über Virtual Function Bus (VFB)

AUTOSAR Interface



Systementwicklung

Abbildung der SWCs auf ECUs

Abbildung der Kommunikation über VFB auf

Kommunikation über RTE

Kommunikation über Bussysteme

66


Systementwicklung





67


Systementwicklung





68


Logische Kommunikation über RTE

69


! Ports implement the interface according

to the communication paradigm (here

client-server based).

! Ports are the interaction

points of a component.

! The communication is

channeled via the RTE.

! The communication layer

in the basic software is

encapsulated and not

visible at the application

layer.

Appli-

cation

SW-C

A

RTE

BSW

ECU I

Appli-

cation

SW-C

B

RTE

BSW

ECU II

Appli-

cation

SW-C

C

VFB

Sensor

Communication Bus

Communication Path

Hardware

AUTOSAR

Infrastructure

Ports

Application

Intra- and Inter-ECU Communication

Innerhalb eines Steuergerätes

Zwischen Steuergeräten über Kommunikationsbus



70













layer.

Appli-

cation

SW-C

A

RTE

BSW

ECU I

Appli-

cation

SW-C

B

RTE

BSW

ECU II

Appli-

cation

SW-C

C

VFB

Sensor

Communication Bus

Communication Path

Hardware

AUTOSAR

Infrastructure

Ports

Application






71













layer.

Appli-

cation

SW-C

A

RTE

BSW

ECU I

Appli-

cation

SW-C

B

RTE

BSW

ECU II

Appli-

cation

SW-C

C

VFB

Sensor

Communication Bus

Communication Path

Hardware

AUTOSAR

Infrastructure

Ports

Application




AUTOSAR Interface


Standardized Interface


AUTOSAR SW-Architektur

72

AUTOSAR Interface





73

AUTOSAR Interface





74

AUTOSAR Interface





75

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



76


1. Organisation

2. Schichtenmodell







77



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



! Implementation of functions independent on distribution on different ECU

as communication will be done via ECU-individual AUTOSAR-RTE exclusively

Use Case ‘Pedal Management’ view for one ECU

void distribute_v(void)

{

…

Rte_Write_p_v(rte_i, v)

…

}

void v_warn(void)

{

…

Rte_Read_p_v(rte_i, v)

…

}

distribute_v()



Use Case ‘Pedal Management’ view for two ECUs

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

Technical benefits

e.g. FlexRay, CAN, etc.

distribute_v()


SystementwicklungAUTOSAR-Methode

Verteilung auf 2 Steuergeräte

81

unverändert

neu


ECU-Hardware

AUTOSAR RTEStd. AUTOSAR

Interface

Services

Std. InterfaceComplexDeviceDrivers

AUTOSARInterface

StandardizedInterface

OperatingSystem


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


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent


Microcontroller Abstraction

Std. AUTOSARInterface

Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface

ComplexDeviceDrivers

AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

AUTOSAR Interface

Headlight




ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

AUTOSAR Interface

Headlight




ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

AUTOSAR Interface

Headlightswitch_event(event)

switch_event (event)




ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

AUTOSAR Interface

Headlightswitch_event(event)


request_light (type, mode)

request_light(type, mode)




ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

CAN Driver

switch_event(event)







ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

CAN Driver

switch_event(event)




set_light(type, mode)





ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

set_current (…)

CAN Driver

switch_event(event)






PWM




ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

set_current (…)

CAN Driver

switch_event(event)






PWM


set_dboard(type, mode)



ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

set_current (…)

CAN Driver

switch_event(event)






PWM



Software Architecture – AUTOSAR Defined InterfacesUse Case ‘Front Light Management’ mapped to AUTOSAR architectureIntegrator Supplier B OEM Supplier A

Silic

on v

endo

r AIn

tegr

ator


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()

AUTOSAR Interface

Headlight

set_current (…)

CAN Driver

switch_event(event)






PWM



Software Architecture – AUTOSAR Defined InterfacesUse Case ‘Front Light Management’: Exchange type of Front LightIntegrator Supplier B OEM Supplier A

Silic

on v

endo

r AIn

tegr

ator


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()set_current (…)

CAN Driver

switch_event(event)






PWM



Software Architecture – AUTOSAR Defined InterfacesUse Case ‘Front Light Management’: Exchange type of Front Light

AUTOSAR Interface

Xenonlightset_light(type, mode)

set_current (…)

Integrator Supplier B OEMSi

licon

ven

dor A

Inte

grat

orSupplier C


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


AUTOSARInterface


Communi-cation

Std. Interface


OperatingSystem

DIO

check_switch ()

AUTOSAR Interface

LightRequest

AUTOSAR Interface

Front-Light Manager

get_keyposition()set_current (…)

CAN Driver

switch_event(event)








Software Architecture – AUTOSAR Defined InterfacesUse Case ‘Front Light Management’: Exchange type of Front Light

DIO

AUTOSAR Interface


set_current (…)

Integrator Supplier B OEMIn

tegr

ator

Silic

on v

endo

r BSupplier C



Wechsel von Scheinwerfer auf Xenon-Scheinwerfer

84

unverändert

neu


Verteilung auf drei Steuergeräte

85

13

Use case ‘Front-Light Management’ – Multiple ECUs

CAN Bus

ECU-Hardware

AUTOSAR RTE



ECUAbstraction

AUTOSARInterface

Std. Interface


Communi-cation

Std. Interface

CAN Driver PWM

AUTOSAR Interface

Xenonlight


set_current (…)

ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface

Std. Interface


Communi-cation

Std. Interface

DIO

check_switch ()

AUTOSAR Interface

LightRequest

switch_event(event)

switch_event

(event)request_light

(type, mode)

AUTOSAR Interface

Front-Light Manager

get_keyposition()






Communi-cation

Std. Interface

CAN Driver

ECU-Hardware

AUTOSAR RTE

CAN Driver

Operating System

Communication Control

Memory Management

Drivers

Hardware

ECU3

Operating System

Communication Cont.

Memory Management

Drivers

Hardware

ECU4

Operating System

Communication Cont.

Memory Management

Drivers

Hardware

ECU5



Verteilung auf 3 Steuergeräte

86

unverändert

neu


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

87


Xenon-Scheinwerfer

88

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.


Xenon-Scheinwerfer

89

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.


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.

90



Anpassung Limousine - Kabrio, Kombi

91

neu (teilweise)

neu (eventuell)

neu (teilweise)



Anpassung an andere Modelle

92



Anpassung an andere Modelle bei gleicher Funktionsarchitektur

93

unverändert



Anpassung an andere Modelle bei gleicher E/E-Architektur

94

unverändert



Anpassung an andere Modelle bei gleicher Vernetzung/Verkabelung

95

unverändert



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

96

unverändert

unverändert

unverändert


Verteilung der Karosseriefunktionen auf Steuergeräte

97

Türsteuergerät F (TSG F)

Türschliessen vorne F

Türschliessen hinten F

Fensterheber vorne F

Fensterheber hinten F

Dachsteuergerät (DSG)

Schiebedach

Beleuchtung Innenraum

Türsteuergerät BF (TSG BF)

Türschliessen vorne BF

Türschliessen hinten BF

Fensterheber vorne BF

Fensterheber hinten BF

Hecksteuergerät (HSG)

Heckklappe

Verdeck



97

Limousine







Schiebedach








Heckklappe

Verdeck



97

Limousine

Coupé







Schiebedach








Heckklappe

Verdeck



97

Limousine

Coupé

Kombi







Schiebedach








Heckklappe

Verdeck



97

Limousine

Coupé

Kombi

Cabriolet







Schiebedach








Heckklappe

Verdeck



97

Limousine

Coupé

Kombi

Cabriolet

SWC DescriptionBeschreibung der SW-Funktionen







Schiebedach








Heckklappe

Verdeck



97

Limousine

Coupé

Kombi

Cabriolet


System DescriptionVerteilung der Funktionen auf die Steuergeräte







Schiebedach








Heckklappe

Verdeck



97

Limousine

Coupé

Kombi

Cabriolet



System Communication-MatrixVernetzung der Steuergeräte







Schiebedach








Heckklappe

Verdeck



98

Limousine

Coupé

Kombi

Cabriolet










Schiebedach








Heckklappe

Verdeck



99

Limousine

Coupé

Kombi

Cabriolet










Schiebedach








Heckklappe

Verdeck



100

Limousine

Coupé

Kombi

Cabriolet










Schiebedach








Heckklappe

Verdeck


Soweit zur Theorie, in der Praxis

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

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.

101

Das AUTOSAR-Diagnosemodul DCM:Diagnostic Communication ManagerDas Bemühen um eine Reduzierung der Fehleranfälligkeitrückt besonders die Diagnose in den Mittelpunkt. Deshalbhat die Qualität der so genannten Onboard- und Offboard-Diagnose und der Entwicklung von Diagnosesoftware inden letzten Jahren immer mehr Bedeutung gewonnen.Auch AUTOSAR hat sich diesem Thema eingehend gewid-met. Während ältere Implementierungen von Diagnose-modulen im Wesentlichen auf proprietären Schnittstellenaufsetzen und Diagnosedienste größtenteils nicht umfas-send konfiguriert werden konnten, stellt AUTOSAR ein uni-verselles und flexibles Diagnosemodul zur Verfügung. AlleSchnittstellen des DCM-Moduls sind standardisiert –sowohl zwischen DCM und Applikation als auch zu denanderen BSW-Modulen. Dadurch kann das Diagnosemodul

problemlos ausgetauscht und wieder verwendet werden.Durch seine einfache Konfigurierbarkeit wird die Integra-tion in die Anwendung wesentlich erleichtert. Für die Konfiguration der Basissoftware ergeben sichbesondere Vorteile, wenn auf bereits bestehende Daten-quellen, zum Beispiel eine Diagnosespezifikation im ODX-Format, zurückgegriffen werden kann. Ziel der Softing-Aktivitäten ist es, an geeigneter Stelle die Verbindung zwi-schen Standards wie ASAM-ODX oder FIBEX und AUTO-SAR in einer einheitlichen Werkzeugumgebung anzubietenund damit das Potenzial für erhebliche Kosten- und Quali-tätsvorteile zu schaffen.Aufgabe des DCM-Moduls ist es, die von den unteren Lay-ern empfangenen Requests entgegenzunehmen, nachDiagnosediensten (OBD – ISO 15031-5 [3] und UDS – ISO14029-1 [4]) zu untersuchen und die Verarbeitung in derApplikation oder in anderen AUTOSAR-BSW-Modulenanzustoßen. Neben der Überprüfung der Timingparameterund der Abarbeitung des „Suppress Handlings“ nimmt dasDCM-Modul die Responses von der Applikation entgegenund reicht die Nachrichten an die unteren Layer weiter. DasDCM-Modul verfügt somit über Schnittstellen zur Applika-tion, zum DEM (Diagnostic Event Manager) und Commu-nication Manager sowie zum PDU-Router (Bild 2).

Das DCM ermittelt also die Service-ID der eingegangenenNachricht und ruft die vorgesehene Applikationsfunktionaus der „Service Identifier Table” auf. Des Weiteren wer-den in der Service Identifier Table “Security Access Level”und “Session Control Level” der Service-IDs konfiguriert.Die Applikation kann die Verarbeitung der Dienste startenund nach Beendigung der Verarbeitung die Diagnose-Response an das DCM-Modul übergeben. Wird diese Ant-wort nicht innerhalb der konfigurierten Zeit gegeben, sosendet das DCM selbstständig die „ResponsePending-Nachricht“. Die Applikationsschnittstelle wird über dasAUTOSAR Runtime Environment (RTE) mit dem DCM ver-bunden.Um die aktuellen oder gespeicherten Fehlereinträge unddie zugehörigen Freeze-Frame-Daten des Steuergerätsauszulesen oder zu löschen, werden vom DEM (Diagnostic

Event Manager) zahlreiche Schnittstellen-funktionen bereitgestellt, die vom DCM ingeeigneter Reihenfolge aufgerufen werdenkönnen. Die Schnittstelle zum Communica-tion Manager (COM) beschränkt sich imWesentlichen auf den Austausch der Infor-mationen zum aktuellen Kommunikations-status. Vom PDU-Router werden die Nach-richten von den Modulen der verschiedenenBussysteme (CAN/LIN/ FlexRay) an denDCM weitergereicht.Das DCM-Modul besteht aus drei Schichten:! DSL – Diagnostic Session Layer! DSD – Diagnostic Service Dispatcher! DSP – Diagnostic Service ProcessingDie DSL-Schicht stellt die Schnittstelle zumPDU-Router zur Verfügung. Die Verarbeitungder Kommunikationsnachrichten besteht auseinem synchronen und asynchronen Anteil:

Asynchrone Funktion: Eine Nachricht wird empfangenund das DSL-Modul prüft, ob die Nachricht zugelassenwerden soll. Gegebenenfalls wird eine aktive Kommunika-tionen mit geringerer Priorität unterbrochen. Darüber hin-aus werden Timer zur Kommunikationsüberwachunggestartet.Synchrone Funktion: Zyklisch hingegen wird der Ablaufder Timer überwacht, das „Session Handling” und “Secu-rity Access Handling” verwaltet und das „SpecificRespon-se-Verhalten“ (z. B. Antwort auf den Service „TesterPre-sent“) abgearbeitet.Aufgabe der DSD-Schicht ist das Aufbereiten des empfan-genen Diagnosedatenstroms. Dazu gehört:! Weiterverarbeitung des empfangenen Diagnose-Re-quests und Weiterreichen der vorverarbeiteten Daten andie vorgesehene Anwendungsfunktion! Entgegennahme und Aufbereitung der Diagnose-Res-ponse von der Applikation sowie Starten des Sendevor-gangs durch Ansteuerung der unteren Layer! Spezielle Funktionen wie Entgegennahme sehr langerDiagnose-Responses von der Applikation, Unterdrückungvon „positiven“ Responses bei funktionalen Requests undselbstständiges Senden bestimmter „negativer“ Respon-ses (z. B. „ServiceNotSupported“)

42 lA U T O M O T I V E 11- 12. 200 5 lS Y S T E M E

Bild 2: Schnittstellen und Aufbau des DCM-Moduls© automotive


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

102


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.

103


AUTOSAR Consulting

6

Microcontrollers by XYZ

Microcontroller abstraction layer to be

developped

Provided by customers of XYZ


Artop – AUTOSAR Tool Platform

105

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

012'3+.'4#

!"#$%&'$()

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

!"#$%&'()*+,-.&-

/,0&12&-(3445


1. Organisation

2. Schichtenmodell







106





participation

Work Packages

Functional Safety

WP-1.3

Body and Comfort

WP-10.1

Powertrain

WP-10.2

Chassis Control

WP-10.3


WP-10.4


WP-1.2


WP-2.2


1.1


and OS

WP-1.1.1Vehicle and


WP-1.1.2

COM Stack

WP-2.1.1

MCALWP-2.1.3

Diagnostics

WP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2


3

Validation


WP-10.0

10


LibrariesWP-2.1.5

VFB and RTE

WP-1.1.5

Lead Work Package

WP-x.y

Work Package

WP-x.y

107

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2012 108AUTOSAR TutorialOct. 23rd 200861

! 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

! 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

! 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

AUTOSAR Application Interfaces

Compositions under Consideration

Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2012 108AUTOSAR TutorialOct. 23rd 200861

! 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

! 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

! 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

AUTOSAR Application Interfaces

Compositions under Consideration

UnterhaltungselektronikEntertainment

Telematik ?


AUTOSAR Release 4.0 Examples for Application Interfaces

20

CAN Bus

ECU-Hardware

AUTOSAR RTE



ECUAbstraction

AUTOSAR Interface

Std. Interface


Communi- cation

Std. Interface

CAN Driver PWM

AUTOSAR Interface


set_current (…)

ECU-Hardware

AUTOSAR RTE



Std. AUTOSAR Interface

Services

Std. Interface

ECUAbstraction

AUTOSAR Interface

Std. Interface


Communi- cation

Std. Interface

DIO




Communi- cation

Std. Interface

CAN Driver

ECU-Hardware

AUTOSAR RTE

CAN Driver

AUTOSAR Int.

SwitchEventcheck_switch ()


AUTOSAR Interface

LightRequestswitch_event(event)


AUTOSAR Interface

Front-Light Manager

get_keyposition()request_light(type, mode)


Park Distance Control

Exterior light

Mirror adjustments

Seat adjustments

Anti Theft System

Interior light

Defrost control

Remote keyless entry

and many more

May 13, 2010 AUTOSAR Technical Overview



110

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager

LIN CAN Flexray



110

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager

LIN CAN Flexray

IP



110

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager

LIN CAN Flexray

IP

AUTOSAR 4.0



110

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager

LIN CAN Flexray

IP

MOST!!

AUTOSAR 4.0



110

20


Application Layer

Microcontroller

AD

C

DIO

CC

U

PW

M

LIN

CA

N

SP

I

EE

PR

OM

FLA

SH

WD

T

GP

T

Ext. B

US

MC

U

Pow

er &

Clock U

nit

µC

e.g. CC

U

e.g. PC

P

e.g. TP

U

FlexR

ay

SC

I

I/O Drivers

PO

RT

Driver

AD

C D

river

DIO

Driver

PW

M D

river

ICU

Driver


Watchdog D

river

MC

U D

river

GP

T D

river


CA

N D

river

LIN D

river

SP

I Handler D

river

Memory Drivers

RA

M T

est

internal EE

PR

OM

D

river

internal Flash D

river


Generic NM Interf.

FlexR

ay NMFlexRay

TP

DCMDiagnostic

Com.Manager

IPDU Multi-plexer


Memory Services

NVRAM Manager

CR

C Lib

Flash C

heck

System Services


anager FIM

Watchdog M

anager

Developm

ent Error

Tracer

Diagnostic E

vent M

anager DE

M

AU

TO

SA

R O

S





External Watchdog

Driver

CAN NM

CAN TP

Ext. Flash Driver


FR

Driver

LIN Interface

Ext. C

AN

D

river

CAN Interface

CA

N transc

Driver

Ext. F

R

Driver

FR InterfaceF

R transc

DriverExt. EEPROM

Driver

EEPROM Abstraction

Watchdog Interface

PDU Router

LIN TP

AUTOSAR COM

LIN C

omm

unication S

tack

BS

W S

cheduler

Com

munication

Manager



CANSM

LINSM

FRSM

EC

U S

tate Manager

LIN CAN Flexray

IP

MOST!!

Mittlerweile Realisierungen von

BSW-Anbietern

AUTOSAR 4.0


AUTOSAR Basis Software ModuleMicrosar von Vector Informatik

111


AUTOSAR Roll-Out

The AUTOSAR Core Partner Exploitation Plan (2008 - 2012)

8. October 200926

Core Partner 2008 2009 2010 2011 2012

! !10 AUTOSAR BSW

modules as part of Std Core in

vehicles, tool / serial support in

place

! Powertrain-, Chassis-,

Safety-, Body- ECUs use

AUTOSAR architecture

! Body Computer with subset

of AUTOSAR specs

incorporated

! Instrument Cluster with

subset of AUTOSAR specs

incorporated

! ACC ECU using

AUTOSAR architecture.

! Powertrain EDC/ME(D)17

ECUs using AUTOSAR

architecture

! Domain Control Unit using

AUTOSAR BSW

! Chassis ECU using


! Body Computer using


! Complete BSW Stack as

Product

! AUTOSAR Configuration

Tool

! Body ECUs using


! Powertrain ECUs using


! Chassis ECUs using


! Engine Systems Platform

based on AUTOSAR

architecture

! First usage of AUTOSAR

modules in vehicles

! First AUTOSAR compa-

tible ECUs in vehicles

! Introduction of AUTOSAR

architecture and methodology

in vehicles

! 1-2 AUTOSAR conformant

ECUs; first use of conformant

tools/methodology

! Continuous roll-out of ECUs

into vehicle architecture

increased use of conformant

tools / methodology


modules

! First use of AUTOSAR

architecture ECU

! Powertrain ECU using

AUTOSAR architecture! Body ECU using



modules! AUTOSAR Architecture ECU

! First AUTOSAR modules

in series production

! First complete ECUs

in series production

AUTOSAR – A Worldwide Standard is on the Road


Weiterführende Literatur

O. Kindel, M. Friedrich:Softwareentwicklung mit AUTOSARGrundlagen, Engineering, Management in der Praxisdpunkt.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 GlossaryVector Informatik GmbH.(In der Vorlesung verteilt)

113

Vorlesung Automotive Software Engineering Teil 7 Normen...

Documents

Transcript of Vorlesung Automotive Software Engineering Teil 7 Normen...