vorlesung automotive software-engineering - tu dresden ase ss 2011 normen und... · dr. bernhard...

INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG

Vorlesung Automotive Software-Engineering

Technische Universität DresdenFakultät InformatikProfessur Softwaretechnologie

Sommersemester 2011

Dr. rer. nat. Bernhard Hohlfeld

[email protected]

Dr. Bernhard Hohlfeld: Embedded Software-Engineering im Bereich Automotive, TU Dresden, Fakultät Informatik, Sommersemester 2011 2

Motivation und Überblick

Die Automobilbranche

Das Automobil

Die Automobilherstellung

E/E-Entwicklung

SW-Entwicklung

Normen und

Standards

Beispiele aus der Praxis

Automotive Systems Engineering

OSEK/ VDX

ASAM

Dr. Bernhard Hohlfeld: Embedded Software-Engineering im Bereich Automotive, TU Dresden, Fakultät Informatik, Sommersemester 2011

1. Motivation und Überblick

1. Motivation Automotive Software Engineering

2. Verteilte und komplexe Systementwicklung zwischen OEM und Zulieferern: Beispiel Türsteuerung

3. Software Entwicklungsprozess

4. Standards zur Softwareentwicklung

5. Software Architekturen

6. AUTOSAR

7. Lessons Learned

8. GI-Fachgruppe Automotive Software Engineering

9. Lehrveranstaltungen

X


Software im Fahrzeug - siehe Teil 2 Die Automobilbranche

X

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

X


Noch einfügen

Folien mit Bezug zu AUTOSAR aus Teil 6 SW-Entwicklung

Vortrag Schelling

Vortrag Bunzel

AUTOSAR Bilder

Vortrag Fürst AUTOSAR OPen Conference 2010

X

INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG

Automotive Software Engineering und AUTOSAR

21. Januar 2010, Technische Universität Darmstadt

Dr. Bernhard Hohlfeld

ICS AG


Ein paar Worte zur Person und zur ICS AG

Automotive Software Engineering Was sind die Probleme

Fachgruppe Automotive Software Engineering (ASE) in der Gesellschaft für Informatik (GI)

AUTOSAR

Weiterführende Literatur

Automotive und AUTOSAR





AUTOSAR



✔





AUTOSAR



✔

✔





AUTOSAR



✔

✔

✔


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

X


AUTOSAR ist ganz einfach zu verstehen

X

DB

DB

DB

ATM


1. Organisation

2. Schichtenmodell







X


AUTOSAR – Core Partners and Members (Phase II)

Ca. 170 Firmen (Stand Ende 2009)

X


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

X


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

Technical contributions

Access to current information


Associate Members Access to finalized documents


Development Members (for small companies with specific expertise) Technical contributions

Access to current information


Attendee (e.g. Universities) Support Role

X


Executive Board

Legal Team Follow-up Team

Core Partner

Core Partner, Premium and Development Member

Subcontractor

System Architecture

Application Interfaces

Software and Test

SpecificationValidation

Quality Manager

Change Manager

Release Manager

Technical Office

… … … …

Administration

General Manager

AUTOSAR Phase III Organization

X

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 StackWP-2.1.1

MCALWP-2.1.3

DiagnosticsWP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2Software 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

X


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 StackWP-2.1.1

MCALWP-2.1.3

DiagnosticsWP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2Software and

Test Specification

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

X


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

X





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 StackWP-2.1.1

MCALWP-2.1.3

DiagnosticsWP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2Software and

Test Specification

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

X


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’

X

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

X

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

Dr. Bernhard Hohlfeld: Embedded Software-Engineering im Bereich Automotive, TU Dresden, Fakultät Informatik, Sommersemester 2011 X

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


1. Organisation

2. Schichtenmodell







3


AUTOSAR Architekturkonzept

4


AUTOSAR-Schichtenmodell Abstraktionsschichten der Steuergerätesoftware

5

Anwendungsschicht (Application Layer)

Laufzeitumgebung (Runtime Environment, RTE)

Basissoftware (BSW)

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell Anwendungsschicht (Application Layer)

6

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)

7

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

Bas

isso

ftwar

e (B

SW

)


AUTOSAR-Schichtenmodell BSW - Service Layer

8

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

9

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

10

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

11

Die Complex Drivers enthalten die in AUTOSAR nicht standardisierten Treiber für die spezifischen Eigenschaften eines Mikrocontrollers oder Steuergeräts. Beispiele: Sensorauswertung, direkter Zugriff auf Mikrocontroller

Bas

isso

ftwar

e (B

SW

)


AUTOSAR Basis Software Module

12 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

riverCAN Interface

CA

N transc

Driver

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







13


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

14


Systementwicklung

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

15


Systementwicklung

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

16


SystementwicklungFormale Definition der Schnittstellen

Sender/Empfänger-Ports

Client/Server-Ports

17


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.

18

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.

19

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)

20

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

!"#$%&'


Beispiel



20

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

!"#$%&'

TSG Fahrer

TSG 2, ...


Beispiel



20

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

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

TSG Fahrer

TSG 2, ...


Beispiel



20

!"#$%!&'%()*+,-.'!-/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

21












AUTOSAR Service

21

✔












AUTOSAR Service

21

✔

✔

Hardware-independent Software Development with AUTOSAR30 September, 201022

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

24


SystementwicklungSystem Description

Zuordnung der Komponenten zu den Steuergeräten

Beschreibung der Netzwerkkommunikation im Fahrzeug

25


SystementwicklungAUTOSAR-Methode (1)

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

26



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

27



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

28



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

29


Integration ins Fahrzeug

Steuergeräte

Bussysteme

30


1. Organisation

2. Schichtenmodell







31


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

32



33

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



34

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



35

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

36

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







37


Systementwurf

38

Kommunikation über Virtual Function Bus (VFB)

AUTOSAR Interface

Standardized AUTOSAR Interface


Systementwurf

39

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

40


Systementwicklung




41


Systementwicklung




42


Logische Kommunikation über RTE

43


! 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



44













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






45













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

46

AUTOSAR Interface





47

AUTOSAR Interface





48

AUTOSAR Interface





49

AUTOSAR Interface 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 Vordefiniert durch AUTOSAR Standard

Zugriff von SWC auf BSW-Module des Service Layer

Standardized Interface Im AUTOSAR-Standard als C-API vordefiniert

Zwischen BSW-Modulen in einem Steuergerät

Zwischen RTE und Betriebssystem

Zwischen RTE und Kommunikations BSW



50


1. Organisation

2. Schichtenmodell







51



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

55

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


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


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


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


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


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


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


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


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


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




Integrator Supplier B OEM Supplier ASi

licon

ven

dor A

Inte

grat

or


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface


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 Light

Integrator Supplier B OEM Supplier ASi

licon

ven

dor A

Inte

grat

or


ECU-Hardware

AUTOSAR RTE

AUTOSAR Int.

SwitchEvent




Services

Std. Interface

ECUAbstraction

AUTOSARInterface


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




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


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)









DIO

AUTOSAR Interface


set_current (…)

Integrator Supplier B OEMIn

tegr

ator

Silic

on v

endo

r BSupplier C



Wechsel von Scheinwerfer auf Xenon-Scheinwerfer

58

unverändert

neu


Verteilung auf drei Steuergeräte

59

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

60

unverändert

neu


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

61


Xenon-Scheinwerfer

62

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

63

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.

64



Anpassung Limousine - Kabrio, Kombi

65

neu

neu

neu



Anpassung an andere Modelle

66



Anpassung an andere Modelle bei gleicher Funktionsarchitektur

67

unverändert



Anpassung an andere Modelle bei gleicher E/E-Architektur

68

unverändert



Anpassung an andere Modelle bei gleicher Vernetzung/Verkabelung

69

unverändert



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

70

unverändert

unverändert

unverändert


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.

71

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

72


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.

73


AUTOSAR Consulting

6

Microcontrollers by XYZ

Microcontroller abstraction layer to be

developped

Provided by customers of XYZ


Artop – AUTOSAR Tool Platform

75

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

012'3+.'4#

!"#$%&'$()

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

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

/,0&12&-(3445


1. Organisation

2. Schichtenmodell







76





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 StackWP-2.1.1

MCALWP-2.1.3

DiagnosticsWP-2.1.4

Basic Software

2.1Basic Software

Validation

WP-3.1

MM / T / HMI

WP-10.5

1

System Architecture

2Software and

Test Specification

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

77



! 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



! 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



80

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



80

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



80

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



80

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



80

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

81


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



O. Kindel, M. Friedrich:Softwareentwicklung mit AUTOSARGrundlagen, Engineering, Management in der Praxisdpunkt.verlag, 2009.

AUTOSAR: Automotive Open System Architecture, "http://www.autosar.org".

AUTOSAR Software Modules, Specialized GlossaryVector Informatik GmbH.(In der Vorlesung verteilt)

83

vorlesung automotive software-engineering - tu dresden ase ss 2011 normen und... · dr. bernhard...

Documents