Normen und Standards Teil 1 AUTOSAR

Transcrição

Normen und Standards Teil 1 AUTOSAR
INFORMATIK ▪ CONSULTING ▪ SYSTEMS AG
Vorlesung
Automotive Software Engineering
Teil 7 Normen und Standards (1)
Sommersemester 2013
Prof. Dr. rer. nat. Bernhard Hohlfeld
[email protected]
Technische Universität Dresden, Fakultät Informatik
Honorarprofessur Automotive Software Engineering
Vorlesung Automotive Software Engineering
Motivation und Überblick
SW-Entwicklung
E/E-Entwicklung
Beispiele aus
der Praxis
Das Automobil
Normen und
Standards
Die Automobilherstellung
Die Automobilbranche
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
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
 Den Begriff COTS einordnen
 Entwurfs- und Codierstandards kennenlernen
3
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
7. Normen und Standards
1. AUTOSAR
2. ARTOP
3. ISO 26262 - Road Vehicles - Functional Safety
4. COTS
5. Entwurfs- und Codierstandards
42
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
7. Normen und Standards
1. AUTOSAR
2. ARTOP
3. ISO 26262 - Road Vehicles - Functional Safety
4. COTS
5. Entwurfs- und Codierstandards
52
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software im Fahrzeug
- siehe Teil 2 Die Automobilbranche
Fahrzeug
Engineering
Dienstleistungen
Schema der Fertigung von
Bändern und Blechen
Anwärmen
Warmwalzen
Fräsen
Inspektion
Türe
Halbleiter
kalt Vorwalzen
14
6
Pressen
Steuergerät
Zwischen und Fertigwalzen
Querteilen
Bleche
Längsteilen
Bänder
Kupferband
(Halbzeug)
Steckverbinder
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
SW-Entwicklungswerkzeuge
Anforderungen
 Neue Beziehungen, Kompetenzen und Verantwortlichkeiten zwischen OEM und Zulieferer erforderlich
7
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
82
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR ist ganz einfach zu verstehen
⛔ว䉲䉴䊁䊛䈮ኻᔕ䈜䉎↥ᬺ⇇䈱ᨒ⚵䉂䉕⿥䈋䈢ㅪ៤ᒝൻ
„ ወӳἉἋἘἲểỊऴ‫إ‬ἉἋἘἲểኵᡂἉἋἘἲỂನ঺ẰủỦ‫ᙹٻ‬೉ἉἋἘἲ
„ ᣻ᙲễᅈ˟ỶὅἧἻỉ‫ٶ‬ẪỊወӳἉἋἘἲ
z ऴ‫إ‬ἉἋἘἲҥ˳ẆኵᡂἉἋἘἲҥ˳ỉࣱ̮᫂Ὁ‫ܤ‬μࣱỉᄩ̬ẻẬỂỊễẪẆወӳἉ
ἋἘἲμ˳ỉࣱ̮᫂Ὁ‫ܤ‬μࣱỉᄩ̬ầ᣻ᙲ
„ ወӳἉἋἘἲỉЎ᫏
z ҥɟ‫׹‬ወӳἉἋἘἲᾉ ҥɟႸႎỉẺỜỆऴ‫إ‬ἉἋἘἲểኵᡂἉἋἘἲẦỤನ঺Ằủ
ẺἉἋἘἲ
z ኽӳ‫׹‬ወӳἉἋἘἲᾉ ီễỦႸႎỂನሰẰủẺऴ‫إ‬ἉἋἘἲểኵᡂἉἋἘἲầẆẸ
ủẹủỉἉἋἘἲỉМࣱ̝ử᭗ỜỦႸႎỂኽӳẰủẺἉἋἘἲ
න৻ဳ⛔ว䉲䉴䊁䊛䈱଀
⚿วဳ⛔ว䉲䉴䊁䊛䈱଀
㌁ⴕൊቯ♽䉥䊮䊤䉟䊮䉲䉴䊁䊛
੤ㅢ▤೙䉲䉴䊁䊛䈫䉦䊷䊅䊎䉭䊷䉲䊢䊮䉲䉴䊁䊛
ᖱႎ䉲䉴䊁䊛䋺
ൊቯ♽䉲䉴䊁䊛䇮
㘈ቴ䊶༡ᬺᐫ⥩▤
ℂ䉲䉴䊁䊛䈭䈬
⚵ㄟ䉲䉴䊁䊛䋺
㪘㪫㪤䇮䊈䉾䊃䊪䊷䉪
䊦䊷䉺䇮Ꮽ␿ශ೚
ⵝ⟎䈭䈬
䉟䊮䉺䊷䊈䉾䊃䊋䊮䉨䊮䉫䉲䉴䊁䊛
䉮䊷䊦䉶䊮䉺䊷䉲䉴䊁䊛
ᖱႎ䉲䉴䊁䊛
䇮㘈ቴ䊶༡ᬺᐫ⥩
▤ℂ 㘈ቴᖱႎDB
䉲䉴䊁䊛
ൊቯ♽DB
ൊቯ♽䉲䉴䊁䊛
༡ᬺᐫ⥩ᖱႎDB
ฦᐫ⥩
ATM
⚵ㄟ䉲䉴
䊁䊛
੤ㅢ▤೙䉲䉴䊁䊛஥䈱
⋡⊛䋺
ʩᡫሥСἉἋἘἲ
ίऴ‫إ‬ἉἋἘἲὸ
ታゞਔ䈱૏⟎ᖱႎ䉇ㅦ
ᐲᖱႎ䈮䉋䉍䇮㆏〝੤ㅢ
⁁ᴫ䈱䉋䉍ᱜ⏕䈭ᛠី䈏
䈪䈐䉎
䉦䊷䊅䊎䉭䊷䉲䊢䊮䉲䉴䊁
䊛஥䈱⋡⊛䋺
੤ㅢ▤೙䉲䉴䊁䊛䈱ᷦ
ṛᖱႎ䈎䉌㆏〝䈱ᷦṛ
⁁ᴫ䉕⠨ᘦ䈚䈢⚻〝᩺ౝ
䈏䈪䈐䉎
ἜἥἄὊ
ἉἹὅ
ἉἋἘἲ
ίኵᡂἉ
ἋἘἲὸ
ᵕ
9
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
10
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR – Core Partners and Members
(Phase II)
 Ca. 170 Firmen (Stand Ende 2009)
11
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Core Partners in Phase III
 Initial discussions 2002: BMW, Bosch, Continental, DaimlerChrysler and Volkswagen, partners were
joined soon afterwards by Siemens VDO.
 Additional Core Partners 2003: Ford, Peugeot Citroën, Toyota, 2004: GM
 2008 Siemens VDO became part of Continental.
 Phase III will start with 8 Core Partners
 GM announced to continue in phase III as Premium Member
 The 8 Core Partners agreed on the phase III 2010-2012 development contract
 Phase III planning started and is well under way
12
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Membership Levels
 Core Partners
 Associate Members
 Organizational control
 Access to finalized documents
 Technical contributions
 Utilization of AUTOSAR standard
 Administrative control
 Definition of external Information
(web-release, clearance, etc.)
 Leadership of Working Groups
 Involvement in Working Groups
 Utilization of AUTOSAR standard
 Premium Members
 Leadership of Working Groups
 Development Members
(for small companies with specific expertise)
 Technical contributions
 Access to current information
 Utilization of AUTOSAR standard
 Attendee (e.g. Universities)
 Support Role
 Involvement in Working Groups
 Technical contributions
 Access to current information
 Utilization of AUTOSAR standard
13
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Phase III Organization
Core Partner
Core Partner, Premium and Development Member
Executive Board
Administration
General Manager
System
Architecture
Subcontractor
Steering
Commitee
Technical
Steering Team
Software and Test
Specification
Legal Team
Validation
CommunicationTeam
Application
Interfaces
Follow-up Team
Quality Manager
Change Manager
…
…
…
…
Release Manager
Technical Office
14
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Initial WP Structure Phase III
Work Packages
1
2
3
10
System
Architecture
Software and Test
Specification
Validation
Application
Interfaces
2.1
WP-3.1
WP-10.0
Basic Software
Basic Software
Validation
Coordination of
Appl. Interfaces
1.1
Software
Architecture
WP-1.1.1
WP-1.1.2
Software
Architecture
and OS
Vehicle and
Application Mode
Mgmt.
WP-2.1.1
WP-10.1
COM Stack
Body and Comfort
WP-2.1.3
WP-1.1.5
MCAL
VFB and RTE
WP-2.1.4
Existence of Work
Packages will
depend on
sufficient
participation
WP-10.2
Powertrain
Diagnostics
WP-10.3
WP-1.2
Methodology and
Configuration
WP-1.3
Functional Safety
WP-2.1.5
Chassis Control
Libraries
WP-2.2
Conformance Test
Specification
Occupants and
Pedest. Safety
MM / T / HMI
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Lead Work Package
WP-10.4
WP-10.5
15
WP-x.y
WP-x.y
Work Package
Initial WP structure Phase III
Work Packages
1
2
3
10
System
Architecture
Software and Test
Specification
Validation
Application
Interfaces
2.1
WP-3.1
WP-10.0
Basic Software
Basic Software
Validation
Coordination of
Appl. Interfaces
1.1
Software
Architecture
WP-1.1.1
WP-1.1.2
Software
Architecture
and OS
Vehicle and
Application Mode
Mgmt.
WP-2.1.1
WP-10.1
COM Stack
Body and Comfort
WP-2.1.3
WP-1.1.5
MCAL
VFB and RTE
WP-2.1.4
Existence of Work
Packages will
depend on
sufficient
participation
WP-10.2
Powertrain
Diagnostics
WP-10.3
WP-1.2
Methodology and
Configuration
WP-1.3
Functional Safety
WP-2.1.5
Chassis Control
Libraries
WP-2.2
Conformance Test
Specification
Occupants and
Pedest. Safety
MM / T / HMI
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Lead Work Package
WP-10.4
WP-10.5
16
WP-x.y
WP-x.y
Work Package
Elektronische Systeme im Fahrzeug
(4.1 Domänen)
Anwendungsdomänen und elektronische Subsysteme
(in diesem Abschnitt nach Schäuffele / Zurawka: Automotive Software Engineering)
 Antriebsstrang (Powertrain)
 Fahrwerk (Chassis)
 Karosserie (Body)
 Multi-Media (Telematics)
Auch andere Klassifizierungen gebräuchlich
(Beispiel Mercedes-Benz Technik transparent)
 Aktive Sicherheit
 Passive Sicherheit
 Karosserie
 Fahrwerk
 Innenraumtechnik
 Elektronik
 Motoren/Getriebe
17
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Initial WP structure Phase III
Work Packages
1
2
3
10
System
Architecture
Software and Test
Specification
Validation
Application
Interfaces
2.1
WP-3.1
WP-10.0
Basic Software
Basic Software
Validation
Coordination of
Appl. Interfaces
1.1
Software
Architecture
WP-1.1.1
WP-1.1.2
Software
Architecture
and OS
Vehicle and
Application Mode
Mgmt.
WP-2.1.1
WP-10.1
COM Stack
Body and Comfort
WP-2.1.3
WP-1.1.5
MCAL
VFB and RTE
WP-2.1.4
Existence of Work
Packages will
depend on
sufficient
participation
WP-10.2
Powertrain
Diagnostics
WP-10.3
WP-1.2
Methodology and
Configuration
WP-1.3
Functional Safety
WP-2.1.5
Chassis Control
Libraries
WP-2.2
Conformance Test
Specification
Occupants and
Pedest. Safety
MM / T / HMI
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Lead Work Package
WP-10.4
WP-10.5
18
WP-x.y
WP-x.y
Work Package
What Daimler expects from AUTOSAR
 Provisioning of an interoperable reliable software kit. Increase of quality and development speed through
a comprehensive and standardized design and implementation approach.
 Inter OEM exchange through
interoperable software kits
 Reduction of testing effort in
the automotive community
 Internal and external libraries
Architecture/
Basic Software
for off-the-shelf applications
 Convenient integration into
the development chain of Tier1s
and OEMs
 Faster SW integration processes
Data Exchange
 Standard application interfaces for
‘SW as a product’
Application
Interfaces
.xml
Methodology
Workflow
Source: AUTOSAR PM Conference 02-2008 / AUTOSAR - a key enabler for comprehensive E/E standardization / S. Wolfsried, Daimler AG
19
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Preconditions for the introduction of AUTOSAR
 Introduction of a standard depends on its maturity and the benefits of its Geplante AUTOSAR-
Anwendungen: Daimlers assessment is positive for AUTOSAR 3.0.
 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 are essential for guaranteeing AUTOSAR’s integrity as a standard.
 Conformance tests not yet available
 Today the standard appears overloaded:
too many requirements with a “one-size-fits-all” approach
Source: AUTOSAR PM Conference 02-2008 / AUTOSAR - a key enabler for comprehensive E/E standardization / S. Wolfsried, Daimler AG
20
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Technical scope of AUTOSAR
Methodology
New
concepts
Input
Templates
Memory
Services
Industry-wide
consolidation of
‚existing‘ basic
software designs
9
21
Oct. 23rd 2008
Meta Model
Exchange
Formats
Configuration
Concept
Virtual Function
Bus (VFB)
Error
Handling
RunTime
Environment
Mode
Management
Network
Management
Diagnostics
OS Kernel
µController
Abstraction
ECU
Abstraction
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Gateway
Bus systems
Complex
Drivers
Drivers
Comm.
Services
Technical scope of AUTOSAR
Methodology
New
concepts
Input
Templates
Memory
Services
Industry-wide
consolidation of
‚existing‘ basic
software designs
9
21
Oct. 23rd 2008
Meta Model
Exchange
Formats
Configuration
Concept
Virtual Function
Bus (VFB)
Error
Handling
RunTime
Environment
Mode
Management
Network
Management
Diagnostics
OS Kernel
µController
Abstraction
ECU
Abstraction
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Gateway
Bus systems
Complex
Drivers
Drivers
Comm.
Services
Technical scope of AUTOSAR
Methodology
New
concepts
Input
Templates
Memory
Services
Industry-wide
consolidation of
‚existing‘ basic
software designs
9
21
Oct. 23rd 2008
Meta Model
Exchange
Formats
Configuration
Concept
Virtual Function
Bus (VFB)
Error
Handling
RunTime
Environment
Mode
Management
Network
Management
Diagnostics
OS Kernel
µController
Abstraction
ECU
Abstraction
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Gateway
Bus systems
Complex
Drivers
Drivers
Comm.
Services
Technical scope of AUTOSAR
Methodology
New
concepts
Input
Templates
Memory
Services
Industry-wide
consolidation of
‚existing‘ basic
software designs
9
21
Oct. 23rd 2008
Meta Model
Exchange
Formats
Configuration
Concept
Virtual Function
Bus (VFB)
Error
Handling
RunTime
Environment
Mode
Management
Network
Management
Diagnostics
OS Kernel
µController
Abstraction
ECU
Abstraction
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Gateway
Bus systems
Complex
Drivers
Drivers
Comm.
Services
Technical scope of AUTOSAR
Methodology
New
concepts
Input
Templates
Memory
Services
Industry-wide
consolidation of
‚existing‘ basic
software designs
9
21
Oct. 23rd 2008
Meta Model
Exchange
Formats
Configuration
Concept
Virtual Function
Bus (VFB)
Error
Handling
RunTime
Environment
Mode
Management
Network
Management
Diagnostics
OS Kernel
µController
Abstraction
ECU
Abstraction
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Gateway
Bus systems
Complex
Drivers
Drivers
Comm.
Services
Technical scope of AUTOSAR
Methodology
New
concepts
Input
Templates
Basis-SW
Industry-wide
consolidation of
‚existing‘ basic
software designs
9
22
Oct. 23rd 2008
Meta Model
Exchange
Formats
Memory
Services
Configuration
Concept
Virtual Function
Bus (VFB)
Error
Handling
RunTime
Environment
Mode
Management
Network
Management
Diagnostics
OS Kernel
µController
Abstraction
ECU
Abstraction
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Gateway
Bus systems
Complex
Drivers
Drivers
Comm.
Services
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
23
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Architekturkonzept
24
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
Abstraktionsschichten der Steuergerätesoftware
 Anwendungsschicht (Application Layer)
 Laufzeitumgebung (Runtime Environment, RTE)
Basissoftware (BSW)
 Basissoftware (BSW)
25
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
Anwendungsschicht (Application Layer)
 Der Application Layer realisiert die Anwendungsfunktionalität des Steuergeräts mittels Anwendungs-
Basissoftware (BSW)
Softwarekomponenten (SWC - Software Component).
26
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
Laufzeitumgebung (Runtime Environment, RTE)
 Die Laufzeitumgebung (Runtime Environment, RTE) integriert den Application Layer mit der
Basissoftware (BSW)
Basissoftware (BSW). Sie implementiert den Datenaustausch zwischen AnwendungsSoftwarekomponenten (SWC) und steuert die Interaktion zwischen SWCs und der BSW.
27
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - Service Layer
 Der Service Layer stellt verschiedene Arten von Hintergrunddiensten wie Netzwerkdienstze,
Basissoftware (BSW)
Speicherverwaltung und Buskommunikationsdienste bereit. Das Betriebssystem ist ebenfalls in dieser
Schicht enthalten.
28
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - ECU Abstraction Layer
 Der ECU Abstraction Layer bietet einen einheitlichen Zugriff auf alle Funktionalitäten eines Steuergeräts
wie Kommunikation, Speicher oder E/A.
Basissoftware (BSW)
 Ziel: Unabhängigkeit der höheren Schichten von der Steuergeräte-Hardware
29
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - Microcontroller Abstraction Layer
 Der Microcontroller Abstraction Layer (MCAL) bietet beispielsweise Treiber für den Zugriff auf
Kommunikation, Speicher und E/A des Mikrocontrollers.
Basissoftware (BSW)
 Ziel: Unabhängigkeit der höheren Schichten von der Mikrocontroller-Hardware
30
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - Complex Drivers
 Die Complex Drivers enthalten die in AUTOSAR nicht standardisierten Treiber für die spezifischen
Basissoftware (BSW)
Eigenschaften eines Mikrocontrollers oder Steuergeräts.
31
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - Complex Drivers
 Die Complex Drivers enthalten die in AUTOSAR nicht standardisierten Treiber für die spezifischen
Eigenschaften eines Mikrocontrollers oder Steuergeräts.
 Beispiele
 Sensordatenauswertung
 Direkter Zugriff auf Mikrocontroller
 Einfachlösungen für geringe Stückzahlen
 Zugriffszeiten (siehe unten)
 Weiterverwendung (siehe unten)
32
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel Zeitbeschränkungen
 Bremsen mit Verwendung des AUTOSAR-Schichtenmodells:
Zu langsam durch die vielen Software-Schichten
Bremspedal
Bremse
Kommunikationsbus
43
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel Zeitbeschränkungen
 Lösung: Direkter Zugriff auf die ECU-Hardware mit „Complex Drivers“
Bremspedal
Bremse
Kommunikationsbus
44
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - Complex Drivers
 Weiterverwendung
Bewährtes
BSWModul
35
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - Complex Drivers
 Weiterverwendung
 RTE-Schnittstelle
Bewährtes
BSWModul
36
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR-Schichtenmodell
BSW - Complex Drivers
 Weiterverwendung
 RTE-Schnittstelle
 Anwendungssoftware
Bewährtes
BSWModul
=
Complex
Driver
37
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Case Study
Entwicklung einer Treiberbibliothek für Motorsteuerungen mit
AUTOSAR Complex Device Driver (CDD) (1)
Quelle: Vector Informatik GmbH
 Der Kunde
Die FAW Group Cooperation, die „First
Automotive Works“, mit Sitz in Changchun ist der
größte chinesische Hersteller von Dieselmotoren,
PKWs, sowie mittleren bis schweren Bussen und
LKWs. FAW produziert mehr als 2,5 Millionen
Fahrzeuge pro Jahr und gehört zu den ersten
chinesischen OEMs, die AUTOSAR einsetzen.
 Die Herausforderung
Entwicklung einer Treiberbibliothek für
Motorsteuerungen mit AUTOSAR Complex
Device Driver (CDD) FAW entwickelt eine neue
Generation ihrer Motorsteuerungen und setzt
dabei konsequent AUTOSAR-Basissoftware ein.
Die Software wird als eine einzige Plattform
realisiert, mit der sich sowohl Benzin- als auch
Dieselmotoren steuern lassen. Da in AUTOSAR
keine entsprechenden Treiber für
Motorsteuerungen definiert sind, möchte FAW
die benötigten Sensoren und Aktuatoren aus
einer erweiterten AUTOSAR-Treiberbibliotek
auswählen und in der gewünschten Anzahl und
Ausprägung mit Hilfe einer durchgängigen
Werkzeugkette konfigurieren.
Case Study
Entwicklung einer Treiberbibliothek
für Motorsteuerungen mit AUTOSAR
Complex Device Driver (CDD)
Der Kunde
Die FAW Group Cooperation, die „First Automotive Works“,
mit Sitz in Changchun ist der größte chinesische Hersteller
von Dieselmotoren, PKWs, sowie mittleren bis schweren
Bussen und LKWs. FAW produziert mehr als 2,5 Millionen
Fahrzeuge pro Jahr und gehört zu den ersten chinesischen
38
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Die FAW Group Cooperation, die „First Automotive Works“,
Eine
durch
FAW
erweiterbare
domänenspezifische TreiberOEMs,
die
AUTOSAR
einsetzen.
Der Kunde
Die Vorteile
und setzt dabei konsequent AUTOSAR-Basissoftware ein. Die
Bibliothek und konfigurieren sie mit dem DaVinci
Software wird als eine einzige Plattform realisiert, mit der sich
Configurator Pro entsprechend ihrer spezifischen Motorsowohl
Benzin- als auch Dieselmotoren steuern lassen. Da in
Case
Study
steuerung.
AUTOSAR keine
entsprechenden
Treiber für MotorsteuerunEntwicklung
einer
Treiberbibliothek
für Motorsteuerungen
mitvorgegebene Prozess und die SchnittstelDer in AUTOSAR
gen definiert sind, möchte FAW die benötigten Sensoren und
AUTOSAR Complex Device Driver (CDD) (2)
len werden eingehalten: Die Regelalgorithmen für die
Aktuatoren aus einer erweiterten AUTOSAR-Treiberbibliotek
Quelle: Vector Informatik GmbH
Motorsteuerung werden weiterhin mit Matlab und Simulink
auswählen und in der gewünschten Anzahl und Ausprägung
entwickelt und als AUTOSAR-Softwarekomponenten (SWC)
mit Hilfe einer durchgängigen Werkzeugkette konfigurieren.
realisiert. Diese sind über die RTE mit der AUTOSAR-Basis Die Lösung
software und den motorspezifischen Treibern verbunden.
V1.0 2011/05 PES_CS_FAW_CDD-Motortreiber_DE
Die Lösung
Konfiguration und Code-Generierung der
Konfiguration und Treiber
Code-Generierung
der motorspezifimotorspezifischen
mit der vorhandenen
schen Treiber mit der vorhandenen
AUTOSAR-WerkzeugAUTOSAR-Werkzeugkette
von Vector
Die
kette von
Treiber
zurVector
Ansteuerung der motorspezifischen
Sensorik
und
von Vector als
Die Treiber
zurAktuatorik
Ansteuerungwurden
der motorspezifischen
Sensorik
sogenannte
Complex
Driver
(CDD) Complex
und Aktuatorik
wurden Device
von Vector
als sogenannte
realisiert.
Für (CDD)
die Konfiguration
der
Trei- ber der TreiDevice Driver
realisiert. Für die
Konfiguration
wurden
entsprechende Basissoftware Module
ber wurden entsprechende Basissoftware Module Description
Description (BSWMD) Dateien mit Hilfe des
(BSWMD) Dateien mit Hilfe des DaVinci Configurator Kit erDaVinci Configurator Kit erzeugt. Ebenso wurden
Ebenso wurden die mit
Code-Generatoren
mit dem DaVinci
diezeugt.
Code-Generatoren
dem DaVinci
Configurator Kit
DerDer
DaVinci
Configurator
Pro liest die
Configurator
Kiterstellt.
erstellt.
DaVinci
Configurator
und bindet die zugehörigen
Code Generatoren
ProBSWMD-Dateien
liest die BSWMD-Dateien
und bindet
die
zugehörigen
Code
Generatoren
ein. Damit kann
ein. Damit kann
er die
Treiber für die Motorsteuerung
und die
er AUTOSAR-Basissoftware
die Treiber für die Motorsteuerung
und die
konfigurieren.
AUTOSAR-Basissoftware konfigurieren.
 Camshaft
Nockenwelle
Ihr Ansprechpartner
bei Vector:
Embedded Sales Team
 Crankshaft
Kurbelwelle
[email protected]
www.vector.com
39
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
LIN
TP
FlexRay
TP
CAN Interface
Memory Drivers
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
CAN transc
Driver
Flash EEPROM
Emulation
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
I/O Hardware
Abstraction
Communication Hardware Abstraction
Memory Abstraction Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Watchdog Interface
Microcontroller Drivers
Communication Drivers
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
µC
DIO Driver
ADC Driver
PWM Driver
ICU Driver
FR Driver
CAN Driver
CAN
LIN
20
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
LIN Driver
LIN Communication
Stack
SPI
SPI Handler Driver
internal Flash Driver
FLASH
SCI
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
40
PDU Router
IPDU
Multiplexer
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Microcontroller
Communication Services
Memory
Services
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
41
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR Software Komponenten (SWC)
Grundsätzlicher Design-Ansatz:
 Trennung zwischen Steuergerät (Infrastruktur) und Anwendung (Funktionalität)
 Eine Anwendung besteht aus miteinander verbundenen Software Komponenten
 Die Software Komponenten sind atomar, d.h. sie können nicht über mehrere Steuergeräte verteilt
werden.
 Die Implementierung der Software Komponenten ist unabhängig vom Steuergerät.
 Methodik
 Beispiele
42
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
 Die Anwendungssoftware wird unabhängig vom konkreten Steuergerät als ein System von untereinander
verbundenen SWCs entworfen
43
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
 Die Anwendungssoftware wird unabhängig vom konkreten Steuergerät als ein System von untereinander
verbundenen SWCs entworfen
44
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
Formale Definition der Schnittstellen
 Sender/Empfänger-Ports
 Client/Server-Ports
45
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
Sender/Empfänger-Ports
 The sender-receiver pattern gives solution to the asynchronous distribution of information, where a
sender distributes information to one or several receivers. The sender is not blocked (asynchronous
communication) and neither expects nor gets a response from the receivers (data or control flow), i.e. the
sender just provides the information and the receivers decides autonomously when and how to use this
information.
 The sender component does not know the identity or the number of receivers to support transferability
and exchange of AUTOSAR Software Components.
Quelle: http://www.autosar.org
46
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
Client/Server-Ports
 The client initiates the communication, requesting that the server performs a service, transferring a
parameter set if necessary. The server waits for incoming communication requests from a client,
performs the requested service, and dispatches a response to the client‘s request.
 The client can be blocked (synchronous communication) or non-blocked (asynchronous communication),
respectively, after the service request is initiated until the response of the server is received.
Quelle: http://www.autosar.org
47
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel
 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)
 Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)
!"#$%&'
48
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel
 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)
 Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)
!"#$%&'
48
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel
 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)
 Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)
!"#$%&'
48
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel
 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)
 Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)
!"#$%&'
TSG 2, ...
TSG Fahrer
48
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel
 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)
 Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)
!"#$%&'
Welche Komponente kommuniziert
noch mit dem Light Master?
TSG 2, ...
TSG Fahrer
48
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Beispiel
 Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver)
 Komfort-Lichtsteuerung schickt „Licht anschalten“ an Lichtsteuerung (Client/Server)
!"#$%&'
Welche Komponente kommuniziert
noch mit dem Light Master?
TSG 2, ...
Wie?
TSG Fahrer
48
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Weitere Informationen zu Ports
 Dr. Stefan Bunzel – AUTOSAR Spokesperson (Continental):
Hardware-independent Software Development with AUTOSAR
8. Workshop Automotive Software Engineering
30 September, 2010, Leipzig
 O. Kindel, M. Friedrich: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management für
die Praxis. dpunkt.verlag, 2009
 Insgesamt 2 x 5 = 10 verschiedene Typen von Ports
 PPort: Provides Interface, Data, Service
 RPort: Requires Interface, Data, Service
 Sender-Receiver Interface
 Client-Server Interface
 Calibration Interface
 Data of AUTOSAR Service
 AUTOSAR Service
49
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Weitere Informationen zu Ports
 Dr. Stefan Bunzel – AUTOSAR Spokesperson (Continental):
Hardware-independent Software Development with AUTOSAR
8. Workshop Automotive Software Engineering
30 September, 2010, Leipzig
 O. Kindel, M. Friedrich: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management für
die Praxis. dpunkt.verlag, 2009
 Insgesamt 2 x 5 = 10 verschiedene Typen von Ports
 PPort: Provides Interface, Data, Service
 RPort: Requires Interface, Data, Service
 Sender-Receiver Interface
✔
 Client-Server Interface
 Calibration Interface
 Data of AUTOSAR Service
 AUTOSAR Service
49
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Weitere Informationen zu Ports
 Dr. Stefan Bunzel – AUTOSAR Spokesperson (Continental):
Hardware-independent Software Development with AUTOSAR
8. Workshop Automotive Software Engineering
30 September, 2010, Leipzig
 O. Kindel, M. Friedrich: Softwareentwicklung mit AUTOSAR. Grundlagen, Engineering, Management für
die Praxis. dpunkt.verlag, 2009
 Insgesamt 2 x 5 = 10 verschiedene Typen von Ports
 PPort: Provides Interface, Data, Service
 RPort: Requires Interface, Data, Service
 Sender-Receiver Interface
 Client-Server Interface
✔
✔
 Calibration Interface
 Data of AUTOSAR Service
 AUTOSAR Service
49
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept
50
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept
 Application software functionality implemented in
„Software Components“ (SWC)
50
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept
50
...
AUTOSAR
SWC
n
AUTOSAR
SWC
3
AUTOSAR
SWC
2
AUTOSAR
SWC
1
 Application software functionality implemented in
„Software Components“ (SWC)
 Handling of vehicle wide functions, independent from
ECUs or network
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept
50
...
AUTOSAR
SWC
n
AUTOSAR
SWC
3
AUTOSAR
SWC
2
AUTOSAR
SWC
1
 Application software functionality implemented in
„Software Components“ (SWC)
 Handling of vehicle wide functions, independent from
ECUs or network
 SWCs can communicate between each other and access
functions from the standardized set of infrastructure
functions
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept
50
...
SWC
Description
AUTOSAR
SWC
n
SWC
Description
AUTOSAR
SWC
3
SWC
Description
AUTOSAR
SWC
2
AUTOSAR
SWC
1
SWC
Description
 Application software functionality implemented in
„Software Components“ (SWC)
 Handling of vehicle wide functions, independent from
ECUs or network
 SWCs can communicate between each other and access
functions from the standardized set of infrastructure
functions
 Communication needs of a SWC are formally described
in a standard template,
i.e. the SWC Description
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept
50
...
SWC
Description
AUTOSAR
SWC
n
SWC
Description
AUTOSAR
SWC
3
SWC
Description
AUTOSAR
SWC
2
AUTOSAR
SWC
1
SWC
Description
 Application software functionality implemented in
„Software Components“ (SWC)
 Handling of vehicle wide functions, independent from
ECUs or network
 SWCs can communicate between each other and access
functions from the standardized set of infrastructure
functions
 Communication needs of a SWC are formally described
in a standard template,
i.e. the SWC Description
 Any SWC interaction runs via „Ports“, which implement
different communication paradigms,
e.g. sender-receiver or client-server
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept
...
Virtual Functional Bus
50
SWC
Description
AUTOSAR
SWC
n
SWC
Description
AUTOSAR
SWC
3
SWC
Description
AUTOSAR
SWC
2
AUTOSAR
SWC
1
SWC
Description
 Application software functionality implemented in
„Software Components“ (SWC)
 Handling of vehicle wide functions, independent from
ECUs or network
 SWCs can communicate between each other and access
functions from the standardized set of infrastructure
functions
 Communication needs of a SWC are formally described
in a standard template,
i.e. the SWC Description
 Any SWC interaction runs via „Ports“, which implement
different communication paradigms,
e.g. sender-receiver or client-server
 The VFB
 enables a virtual integration of SWCs and
 allows to formally verify structural and dynamic
compatibility of SWCs
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Development Methodology
Virtual Functional Bus Concept – Ports and Interfaces
PPort, provides a Sender-Receiver Interface
SWC
Description
SWC
Description
SWC
Description
SWC
Description
RPort, requires a Sender-Receiver Interface
AUTOSAR SWC
...
AUTOSAR
SWC
n
AUTOSAR
SWC
3
AUTOSAR
SWC
2
AUTOSAR
SWC
1
PPort, provides a Client-Server Interface,
i.e. implements service
RPort, requires a Client-Server Interface,
i.e. client of a service
PPort, provides a Calibration Interface
RPort, requires a Calibration Interface
PPort, provides data to AUTOSAR Service
RPort, requires data from AUTOSAR Service
PPort, provides AUTOSAR Service
(in BSW only)
Virtual Functional Bus
51
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
RPort, requires AUTOSAR Service as client
Systementwicklung
Virtual Function Bus (VFB)
 Während der Systementwurfsphase werden die SWCs auf Basis des Virtual Function Bus (VFB) logisch
integriert
52
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
System Description
 Zuordnung der Komponenten zu den Steuergeräten
 Beschreibung der Netzwerkkommunikation im Fahrzeug
53
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode (1)
 Beschreibt Abläufe von der Systemkonfiguration zur Generierung von Code für Steuergeräte
54
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode (2)
 Erstellung von SWC Description, System Description und System Communication-Matrix unter
Berücksichtigung der System Constraints
(Beispiel: Übernahme einer Kommunikationsmatrix aus dem Vorgängerfahrzeug)
55
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode (3)
 Aus SWC Description, System Description und System Communication-Matrix wird die ECU Extract of
System Description generiert
56
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode (4)
 Aus ECU Extract of System Description und BSW Module Description (Herstellerabhängig) werden die
ECU Configuration Description, die konkreten BSW-Module und die RTE (Herstellerunabhängig)
generiert
57
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Integration ins Fahrzeug
 Steuergeräte
 Bussysteme
58
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
59
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Klassifikation von Bussystemen - Weiterentwicklung
Klasse
Übertragungsraten
Anwendung
Vertreter
Klasse A
Geringe Datenraten
(bis 10 kBit/s)
Vernetzung von Aktoren und Sensoren
LIN
Klasse B
Mittlere Datenraten
(bis 125 kBit/s)
Komplexe Mechanismen zur
Fehlerbehandlung, Vernetzung von
Steuergeräten im Komfortbereich
Lowspeed-CAN
Klasse C
Hohe Datenraten
(bis 1 MBit/s)
Echtzeitanforderungen, Vernetzung von
Steuergeräten im Antriebs- und
Fahrwerksbereich
Highspeed-CAN
bis zu 15 MBit/s
Wie Klasse C, zusätzlich
- Mehr ECUs / CAN
- Schnellere Kommunikation über lange CAN
CAN FD (Flexible
Data Rate)
Klasse C+
Sehr hohe Datenraten
(bis 10 MBit/s)
Echtzeitanforderungen,
Sicherheitsanforderungen, Vernetzung von
Steuergeräten im Antriebs- und
Fahrwerksbereich
FlexRay
Klasse D
Sehr hohe Datenraten
(> 10 MBit/s)
Vernetzung von Steuergeräten im Telematikund Multimediabereich
Verliert an Bedeutung
MOST
in Einführung
Ethernet
Quelle: BOSCH: Kraftfahrtechnisches Taschenbuch, Vieweg+Teubner, 27. Auflage, 2011.
Gelbe Felder ergänzt
60
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
Memory Drivers
Communication Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CCU
FlexRay
CAN
LIN
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
I/O Drivers
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
20
61
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
Flash EEPROM
Emulation
CAN transc
Driver
Microcontroller Drivers
CAN Interface
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Microcontroller
Communication Services
Memory
Services
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
LIN
Memory Drivers
Communication Drivers
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
Flash EEPROM
Emulation
CAN transc
Driver
Microcontroller Drivers
CAN Interface
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
CAN
Flexray
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
CAN
LIN
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
20
LIN
62
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN
Flexray
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
Memory Drivers
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
Flash EEPROM
Emulation
CAN transc
Driver
Microcontroller Drivers
CAN Interface
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Communication Drivers
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
CAN
LIN
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
IP
20
LIN
63
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN
Flexray
TCIP/IP-Erweiterung in Release 4.0
AUTOSAR Release 4.0
TCP/IP Extension of the CommStack – Overview
RTE
Signals
IPDU multiplexer
I-PDU
Socket adaptor
DCM
Diagnostic
Communication
Manager
AUTOSAR
COM
Communication
Manager
I-PDU
I-PDU
I-PDU
PDU Router
DoIP
Generic
NM interface
I-PDU
I-PDU
Socket
Interface
Messages
FlexRay
TP
CAN TP
Streams
UDP
Packet
ARP
Segment
IP
FlexRay
State
Manager
CAN State
Manager
I-PDU
TCP
DHCP
NM
Coordinator
I-PDU
N-PDU
LIN State
Manager
N-PDU
I-PDU
ICMP
COTS TCP/IP Stack
Datagram
Communication HW Abstraction
Ethernet Interface
EthFrame
Ethernet Driver
24
64
May 13, 2010
FlexRay Interface
CAN Interface
L-PDU
L-PDU
LIN Interface
(incl. LIN TP)
L-PDU
Communication Drivers
FlexRay Driver
CAN Driver
AUTOSAR Technical Overview
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
LIN Low Level Driver
Eth State
Manager
NM
NM
NM
Module
UDP NM
Module
Module
Module
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
65
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwurf
 Kommunikation über Virtual Function Bus (VFB)
 AUTOSAR Interface
 Standardized AUTOSAR Interface
66
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwurf
 Kommunikation über Virtual Function Bus (VFB)
 AUTOSAR Interface
 Standardized AUTOSAR Interface
67
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
 Abbildung der SWCs auf ECUs
 Abbildung der Kommunikation über VFB auf
 Kommunikation über RTE
 Kommunikation über Bussysteme
68
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
 Abbildung der SWCs auf ECUs
 Abbildung der Kommunikation über VFB auf
 Kommunikation über RTE
 Kommunikation über Bussysteme
69
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
 Abbildung der SWCs auf ECUs
 Abbildung der Kommunikation über VFB auf
 Kommunikation über RTE
 Kommunikation über Bussysteme
70
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Logische Kommunikation über RTE
Inter-ECU Communication
 Innerhalb eines Steuergerätes
 Zwischen Steuergeräten über Kommunikationsbus
mplement the interface according
ommunication paradigm (here
erver based).
ECU I
re the interaction
Appliof a component.
cation
SW-C
mmunication is
A
led via the RTE.
mmunication layer
asic software is
ulated and not
RTE
at the application
BSW
ECU II
Application
SW-C
B
Application
SW-C
C
Application
Ports
VFB
RTE
AUTOSAR
Infrastructure
BSW
Sensor
Hardware
Communication Bus
Communication Path
71
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Logische Kommunikation über RTE
Inter-ECU Communication
 Innerhalb eines Steuergerätes
 Zwischen Steuergeräten über Kommunikationsbus
mplement the interface according
ommunication paradigm (here
erver based).
ECU I
re the interaction
Appliof a component.
cation
SW-C
mmunication is
A
led via the RTE.
mmunication layer
asic software is
ulated and not
RTE
at the application
BSW
ECU II
Application
SW-C
B
Application
SW-C
C
Application
Ports
VFB
RTE
AUTOSAR
Infrastructure
BSW
Sensor
Hardware
Communication Bus
Communication Path
72
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Logische Kommunikation über RTE
Inter-ECU Communication
 Innerhalb eines Steuergerätes
 Zwischen Steuergeräten über Kommunikationsbus
mplement the interface according
ommunication paradigm (here
erver based).
ECU I
re the interaction
Appliof a component.
cation
SW-C
mmunication is
A
led via the RTE.
mmunication layer
asic software is
ulated and not
RTE
at the application
BSW
ECU II
Application
SW-C
B
Application
SW-C
C
Application
Ports
VFB
RTE
AUTOSAR
Infrastructure
BSW
Sensor
Hardware
Communication Bus
Communication Path
73
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR SW-Architektur
 AUTOSAR Interface
 Standardized AUTOSAR Interface
 Standardized Interface
74
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR SW-Architektur
 AUTOSAR Interface
 Standardized AUTOSAR Interface
 Standardized Interface
75
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR SW-Architektur
 AUTOSAR Interface
 Standardized AUTOSAR Interface
 Standardized Interface
76
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR SW-Architektur
 AUTOSAR Interface
 Standardized AUTOSAR Interface
 Standardized Interface
77
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR SW-Architektur
 AUTOSAR Interface: Innerhalb Anwendungssoftware
 Generische Schnittstelle, abgeleitet aus den Ports einer SWC.
 Werden von RTE bereitgestellt
 Schnittstellen zwischen SWCs (VFB)
 Schnittstellen zwischen SWC und Steuergeräte-Firmware
 Standardized AUTOSAR Interface: Zwischen Anwendungssoftware und Basissoftware
 Vordefiniert durch AUTOSAR Standard
 Zugriff von SWC auf BSW-Module des Service Layer
 Standardized Interface: Innerhalb Basissoftware
 Im AUTOSAR-Standard als C-API vordefiniert
 Zwischen BSW-Modulen in einem Steuergerät
 Zwischen RTE und Betriebssystem
 Zwischen RTE und Kommunikations BSW
78
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
79
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Use Cases of AUTOSAR Results
! Exchange of SW-Components
! Re-use of SW components for different platforms
… shown by uses cases
pedal management
front light management
17
80
Oct. 23rd 2008
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Use Case ‘Pedal Management’ view for one ECU
!
Implementation of functions independent on distribution on different ECU
as communication will be done via ECU-individual AUTOSAR-RTE exclusively
void distribute_v(void)
{
…
Rte_Write_p_v(rte_i, v)
…
}
distribute_v()
void v_warn(void)
{
…
Rte_Read_p_v(rte_i, v)
…
}
18
81
Oct. 23rd 2008
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Void
 In den Programmiersprachen C, C++, Java und C# wird void für Funktionen bzw. Methoden ohne
Rückgabewert (sog. Prozeduren) benutzt. In diesen Sprachen muss syntaktisch für jede Funktion/
Methode ein Rückgabetyp angegeben werden; wenn kein Wert zurückgegeben wird, steht stattdessen
void.
Quelle: Wikipedia
82
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Use Case ‘Pedal Management’ view for two ECUs
distribute_v()
e.g. FlexRay, CAN, etc.
Technical benefits
19
83
Oct. 23rd 2008
!
!
!
!
Reuse of Intellectual Property
Increase in design flexibility
Simplification of the integration task
Reduction of SW development costs
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode
 Verteilung auf 2 Steuergeräte
unverändert
neu
84
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
AUTOSAR RTE
Standardized
Interface
Std. AUTOSAR
Interface
AUTOSAR
Interface
Services
Standardized
Interface
Operating
System
Std. Interface
Complex
Device
Drivers
ECU-Hardware
85
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
LightRequest
Front-Light Manager
Headlight
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
LightRequest
Front-Light Manager
Headlight
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR Interface
check_switch ()
AUTOSAR Int.
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
DIO
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
check_switch ()
LightRequest
Front-Light Manager
Headlight
AUTOSAR Interface
AUTOSAR Interface
switch_event(event)
switch_event
(event)
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
DIO
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
check_switch ()
LightRequest
Front-Light Manager
switch_event(event)
request_light(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR Interface
Headlight
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
DIO
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
check_switch ()
LightRequest
Front-Light Manager
switch_event(event)
request_light(type, mode)
Headlight
get_keyposition()
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
DIO
CAN Driver
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
check_switch ()
LightRequest
Front-Light Manager
Headlight
switch_event(event)
request_light(type, mode)
set_light(type, mode)
get_keyposition()
set_light(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
DIO
CAN Driver
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
check_switch ()
LightRequest
Front-Light Manager
Headlight
switch_event(event)
request_light(type, mode)
set_light(type, mode)
get_keyposition()
set_light(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
DIO
PWM
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
SwitchEvent
check_switch ()
LightRequest
Front-Light Manager
Headlight
switch_event(event)
request_light(type, mode)
set_light(type, mode)
get_keyposition()
set_light(type, mode)
set_dboard(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
AUTOSAR Interface
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Standardized
Interface
Operating
System
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
Complex
Device
Drivers
Standardized Interface
DIO
PWM
Microcontroller Abstraction
ECU-Hardware
85
AUTOSAR
Interface
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’ mapped to AUTOSAR
architecture
Integrator
SwitchEvent
check_switch ()
Supplier B
OEM
Supplier A
LightRequest
Front-Light Manager
Headlight
switch_event(event)
request_light(type, mode)
set_light(type, mode)
get_keyposition()
set_light(type, mode)
set_dboard(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
AUTOSAR Interface
AUTOSAR Interface
85
Standardized
Interface
Operating
System
Standardized
Interface
Silicon vendor A
Integrator
AUTOSAR RTE
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
AUTOSAR
Interface
Complex
Device
Drivers
Standardized Interface
DIO
PWM
Microcontroller Abstraction
ECU-Hardware
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’: Exchange type of Front
Light
Integrator
SwitchEvent
check_switch ()
Supplier B
OEM
Supplier A
LightRequest
Front-Light Manager
Headlight
switch_event(event)
request_light(type, mode)
set_light(type, mode)
get_keyposition()
set_light(type, mode)
set_dboard(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
AUTOSAR Interface
AUTOSAR Interface
86
Standardized
Interface
Operating
System
Standardized
Interface
Silicon vendor A
Integrator
AUTOSAR RTE
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
AUTOSAR
Interface
Complex
Device
Drivers
Standardized Interface
DIO
PWM
Microcontroller Abstraction
ECU-Hardware
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’: Exchange type of Front
Light
Integrator
SwitchEvent
check_switch ()
Supplier B
OEM
Supplier A
LightRequest
Front-Light Manager
Headlight
switch_event(event)
request_light(type, mode)
set_light(type, mode)
get_keyposition()
set_light(type, mode)
set_dboard(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
AUTOSAR Interface
AUTOSAR Interface
86
Standardized
Interface
Operating
System
Standardized
Interface
Silicon vendor A
Integrator
AUTOSAR RTE
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
AUTOSAR
Interface
Complex
Device
Drivers
Standardized Interface
DIO
PWM
Microcontroller Abstraction
ECU-Hardware
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’: Exchange type of Front
Light
Integrator
SwitchEvent
check_switch ()
Supplier B
OEM
Supplier C
LightRequest
Front-Light Manager
Xenonlight
switch_event(event)
request_light(type, mode)
set_light(type,
set_light(type, mode)
mode)
get_keyposition()
set_light(type, mode)
set_dboard(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
(…)
set_current
AUTOSAR Interface
AUTOSAR Interface
86
Standardized
Interface
Operating
System
Standardized
Interface
Silicon vendor A
Integrator
AUTOSAR RTE
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
AUTOSAR
Interface
Complex
Device
Drivers
Standardized Interface
DIO
PWM
Microcontroller Abstraction
ECU-Hardware
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’: Exchange type of Front
Light
Integrator
SwitchEvent
check_switch ()
Supplier B
OEM
Supplier C
LightRequest
Front-Light Manager
Xenonlight
switch_event(event)
request_light(type, mode)
set_light(type,
set_light(type, mode)
mode)
get_keyposition()
set_light(type, mode)
set_dboard(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
(…)
set_current
AUTOSAR Interface
AUTOSAR Interface
86
Standardized
Interface
Operating
System
Standardized
Interface
Silicon vendor B
Integrator
AUTOSAR RTE
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
AUTOSAR
Interface
Complex
Device
Drivers
Standardized Interface
DIO
DIO
Microcontroller Abstraction
ECU-Hardware
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Software Architecture – AUTOSAR Defined Interfaces
Use Case ‘Front Light Management’: Exchange type of Front
Light
Integrator
SwitchEvent
check_switch ()
Supplier B
OEM
Supplier C
LightRequest
Front-Light Manager
Xenonlight
switch_event(event)
request_light(type, mode)
set_light(type,
set_light(type, mode)
mode)
get_keyposition()
set_light(type, mode)
set_dboard(type, mode)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
set_current (…)
(…)
set_current
AUTOSAR Interface
AUTOSAR Interface
86
Standardized
Interface
Operating
System
Standardized
Interface
Silicon vendor B
Integrator
AUTOSAR RTE
Std. AUTOSAR
Interface
Standardized
Interface
AUTOSAR
Interface
Services
Communication
ECU
Abstraction
Std. Interface
Std. Interface
Std. Interface
AUTOSAR
Interface
Complex
Device
Drivers
Standardized Interface
DIO
DIO
Microcontroller Abstraction
ECU-Hardware
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN Driver
Systementwicklung
AUTOSAR-Methode
 Wechsel von Scheinwerfer auf Xenon-Scheinwerfer
neu
unverändert
87
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung auf drei Steuergeräte
Use case ‘Front-Light Management’ – Multiple ECUs
LightRequest
Front-Light Manager
check_switch ()
switch_event(event)
switch_event
(event)
request_light
(type, mode)
request_light(type, mode)
get_keyposition()
set_light(type, mode)
SwitchEvent
AUTOSAR Int.
AUTOSAR Interface
ECU3
AUTOSAR RTE
AUTOSAR
Standardized
Std. AUTOSAR
Operating
System
Interface
Interface
Interface
ECU
Communication
Control
CommuniServices
Abstraction
cation
Memory Management
Std. Interface
Std. Interface
Std. Interface
Drivers
Hardware
Standardized Interface
DIO
CAN Driver
Microcontroller Abstraction
ECU-Hardware
AUTOSAR Interface
ECU4
AUTOSAR RTE
Standardized
Operating
System
Interface
Communication
Communi- Cont.
cation
Memory Management
Std. Interface
Drivers
Hardware
Standardized Interface
CAN Driver
Microcontroller Abstraction
ECU-Hardware
CAN Bus
13
88
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Xenonlight
set_light(type, mode)
set_current (…)
AUTOSAR Interface
ECU5
AUTOSAR RTE
Standardized
Operating
Interface
AUTOSAR
System
Interface
Communication
Cont.
ECU
Communication
Abstraction
Std. Interface
Std. Interface
Memory Management
Drivers
Hardware
Standardized Interface
CAN Driver
PWM
Microcontroller Abstraction
ECU-Hardware
Systementwicklung
AUTOSAR-Methode
 Verteilung auf 3 Steuergeräte
unverändert
neu
89
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
http://www.volkswagen.de/de/Volkswagen/InnovationTechnik/
technik-lexikon.html
90
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Xenon-Scheinwerfer
Xenon-Scheinwerfer bieten deutliche Verbesserungen
gegenüber konventionellen Halogenlampen. Sie entlasten den
Fahrer bei Nachtfahrten durch ihr dem Tageslicht ähnliches
Lichtspektrum und führen damit zu mehr Sicherheit. Sie
zeichnen sich durch eine große Reichweite sowie eine sehr
gute Seitenausleuchtung aus. Weitere Pluspunkte sind der
geringe Energieverbrauch sowie die Haltbarkeit, die
konventionellen Halogen-Lampen überlegen ist.
Als Lichtquelle dient eine so genannte "Gasentladungslampe":
Durch einen Funkenüberschlag zwischen zwei Elektroden
entsteht in der Xenongas-Atmosphäre im Lampenkolben ein
ionisierter Gasschlauch, durch den dann elektrischer Strom
fließt, der das Gasgemisch in Form eines Lichtbogens zum
Leuchten anregt. Für den Betrieb dieser Lampen ist eine
aufwendige Elektronik erforderlich, um unter anderem die hohe
Zündspannung von 18.000 bis 30.000 Volt zu erzeugen und
das automatische Wiederzünden und den konstanten Betrieb
(bei nur 35 Watt Leistung) zu gewährleisten.
91
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Xenon-Scheinwerfer
Xenon-Scheinwerfer bieten deutliche Verbesserungen
gegenüber konventionellen Halogenlampen. Sie entlasten den
Fahrer bei Nachtfahrten durch ihr dem Tageslicht ähnliches
Lichtspektrum und führen damit zu mehr Sicherheit. Sie
zeichnen sich durch eine große Reichweite sowie eine sehr
gute Seitenausleuchtung aus. Weitere Pluspunkte sind der
geringe Energieverbrauch sowie die Haltbarkeit, die
konventionellen Halogen-Lampen überlegen ist.
Als Lichtquelle dient eine so genannte "Gasentladungslampe":
Durch einen Funkenüberschlag zwischen zwei Elektroden
entsteht in der Xenongas-Atmosphäre im Lampenkolben ein
ionisierter Gasschlauch, durch den dann elektrischer Strom
fließt, der das Gasgemisch in Form eines Lichtbogens zum
Leuchten anregt. Für den Betrieb dieser Lampen ist eine
aufwendige Elektronik erforderlich, um unter anderem die
hohe Zündspannung von 18.000 bis 30.000 Volt zu erzeugen
und das automatische Wiederzünden und den konstanten
Betrieb (bei nur 35 Watt Leistung) zu gewährleisten.
92
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Bi-Xenon-Scheinwerfer
Der Bi-Xenon-Scheinwerfer ("Bi" = Zwei) ist eine
Weiterentwicklung des Xenon-Scheinwerfers. Mit einem
Scheinwerfer können sowohl Abblend- als auch Fernlicht erzeugt
werden. Eine bewegliche Blende (Shutter) schirmt beim
Abblendlicht einen Teil des Lichtstrahls ab. Wird die Lichthupe,
beziehungsweise das Fernlicht betätigt, wird die Blende aus dem
Lichtstrahl bewegt und gibt die zusätzliche Leuchtkraft frei.
93
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode
 Anpassung Limousine - Kabrio, Kombi
neu (teilweise)
neu (teilweise)
neu (eventuell)
94
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode
 Anpassung an andere Modelle
95
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode
 Anpassung an andere Modelle bei gleicher Funktionsarchitektur
unverändert
96
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode
 Anpassung an andere Modelle bei gleicher E/E-Architektur
unverändert
97
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode
 Anpassung an andere Modelle bei gleicher Vernetzung/Verkabelung
unverändert
98
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Systementwicklung
AUTOSAR-Methode
 Anpassung an andere Modelle bei gleicher Funktionsarchitektur, gleicher E/E-Architektur und gleicher
Vernetzung/Verkabelung
unverändert
unverändert
unverändert
99
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Karosseriefunktionen: Varianten und Gleichteile
100
Steuerung von
12 Funktionen
Limousine mit
Schiebedach
Limousine ohne
Schiebedach
Coupé mit
Schiebedach
Coupé ohne
Schiebedach
Kombi mit
Schiebedach
Kombi ohne
Schiebedach
Cabrio
7
Türschliessen
vorne F
Variante L
Variante L
Variante L
Variante L
Variante L
Variante L
Variante L
1
Türschliessen
vorne BF
Variante L
Variante L
Variante L
Variante L
Variante L
Variante L
Variante L
1
Türschliessen
hinten F
Variante L
Variante L
entfällt
entfällt
Variante L
Variante L
entfällt
1
Türschliessen
hinten BF
Variante L
Variante L
entfällt
entfällt
Variante L
Variante L
entfällt
1
Fensterheber
vorne F
Variante L
Variante L
Variante Coupé
Variante Coupé
Variante L
Variante L
Variante Cabrio
3
Fensterheber
vorne BF
Variante L
Variante L
Variante Coupé
Variante Coupé
Variante L
Variante L
Variante Cabrio
3
Fensterheber
hinten F
Variante L
Variante L
Variante Coupé
Variante Coupé
Variante L
Variante L
Variante Cabrio
3
Fensterheber
hinten BF
Variante L
Variante L
Variante Coupé
Variante Coupé
Variante L
Variante L
Variante Cabrio
3
Schiebedach
Variante L
entfällt
Variante L
entfällt
Variante L
entfällt
entfällt
1
Beleuchtung
Innenraum
Variante L
Variante L
Variante Coupé
Variante Coupé
Variante K
Variante K
Variante Cabrio
4
Heckklappe
Variante L
Variante L
Variante L
Variante L
Variante K
Variante K
Variante Cabrio
3
Verdeck
entfällt
entfällt
entfällt
entfällt
entfällt
entfällt
Variante Cabrio
1
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
Schiebedach
Heckklappe
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
Schiebedach
Heckklappe
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
 Coupé
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
Schiebedach
Heckklappe
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
 Coupé
 Kombi
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
Schiebedach
Heckklappe
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 Coupé
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 Coupé
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 Coupé
 SWC Description
Beschreibung der SW-Funktionen
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 Coupé
 SWC Description
Beschreibung der SW-Funktionen
 System Description
Verteilung der Funktionen auf die
Steuergeräte
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 Coupé
 SWC Description
Beschreibung der SW-Funktionen
 System Description
Verteilung der Funktionen auf die
Steuergeräte
 System Communication-Matrix
Vernetzung der Steuergeräte
101
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 Coupé
 SWC Description
Beschreibung der SW-Funktionen
 System Description
Verteilung der Funktionen auf die
Steuergeräte
 System Communication-Matrix
Vernetzung der Steuergeräte
102
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
 Coupé
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 SWC Description
Beschreibung der SW-Funktionen
 System Description
Verteilung der Funktionen auf die
Steuergeräte
 System Communication-Matrix
Vernetzung der Steuergeräte
103
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Verteilung der Karosseriefunktionen auf Steuergeräte
 Limousine
Dachsteuergerät
(DSG)
Hecksteuergerät
(HSG)
 Kombi
Schiebedach
Heckklappe
 Cabriolet
Beleuchtung
Innenraum
Verdeck
Türsteuergerät F
(TSG F)
Türsteuergerät BF
(TSG BF)
Türschliessen
vorne F
Türschliessen
vorne BF
Türschliessen
hinten F
Türschliessen
hinten BF
Fensterheber
vorne F
Fensterheber
vorne BF
Fensterheber
hinten F
Fensterheber
hinten BF
 Coupé
 SWC Description
Beschreibung der SW-Funktionen
 System Description
Verteilung der Funktionen auf die
Steuergeräte
 System Communication-Matrix
Vernetzung der Steuergeräte
104
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Soweit zur Theorie, in der Praxis
Auch AUTOSAR hat sich diesem Thema eingehend gewidmet. Während ältere Implementierungen von Diagnosemodulen im Wesentlichen auf proprietären Schnittstellen
aufsetzen und Diagnosedienste größtenteils nicht umfassend konfiguriert werden konnten, stellt AUTOSAR ein universelles und flexibles Diagnosemodul zur Verfügung. Alle
Schnittstellen des DCM-Moduls sind standardisiert –
sowohl zwischen DCM und Applikation als auch zu den
anderen BSW-Modulen. Dadurch kann das Diagnosemodul
 „Es gibt nur wenige AUTOSAR-Schnittstellen
weils so aufwendig ist.“
 Folgende Punkte aus dem Vortrag von Dipl.-
Phys. Andreas Möstel, Robert-Bosch GmbH
sollten in Erinnerung bleiben:
 Bosch verwendet für die Implementierung des
Steuergerätes DCM ein Autosar Stack von Elektrobit mit 7
BMW spezifischen Modulen und einer MCAL Anpassung
von Infineon.
 Die jetztige Tool Landschaft und Unterstützung macht die
Einbindung von neuen Funktionalitäten (wie z.B. eines
neuen Signals) sehr aufwändig, an vielen
Komfigurationsdateien des AUTOSAR Stacks muss
geändert werden und die Konsistenz wird nicht durch die
Tools unterstützt.
Bild 2: Schnittstellen und Aufbau des DCM-Moduls
 Die Konfiguration des AUTOSAR Stacks erlaubt keinen
Merge-Funktion. Beispiel 80% ist von Projekt übernehmbar
und nur 20% wäre auszutauschen für eine andere Baureihe
oder OEM. Dazu muss der komplette Stack getrennt und
isoliert verwaltet und konfiguriert werden.
105
problemlos ausgetauscht und wieder verwendet werden.
Durch seine einfache Konfigurierbarkeit wird die Integration in die Anwendung wesentlich erleichtert.
Für die Konfiguration der Basissoftware ergeben sich
besondere Vorteile, wenn auf bereits bestehende Datenquellen, zum Beispiel eine Diagnosespezifikation im ODXFormat, zurückgegriffen werden kann. Ziel der SoftingAktivitäten ist es, an geeigneter Stelle die Verbindung zwischen Standards wie ASAM-ODX oder FIBEX und AUTOSAR in einer einheitlichen Werkzeugumgebung anzubieten
und damit das Potenzial für erhebliche Kosten- und Qualitätsvorteile zu schaffen.
Aufgabe des DCM-Moduls ist es, die von den unteren LayProf. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester
ern2013empfangenen Requests entgegenzunehmen, nach
Diagnosediensten (OBD – ISO 15031-5 [3] und UDS – ISO
Response an das DCM-Modu
wort nicht innerhalb der kon
sendet das DCM selbststän
Nachricht“. Die Applikation
AUTOSAR Runtime Environm
bunden.
Um die aktuellen oder gesp
die zugehörigen Freeze-Fra
auszulesen oder zu löschen, w
Event Manage
funktionen ber
geeigneter Rei
können. Die Sc
tion Manager
Wesentlichen
mationen zum
status. Vom PD
richten von den
Bussysteme (
DCM weiterge
Das DCM-Mod
! DSL – Diagn
! DSD – Diagn
! DSP – Diagn
Die DSL-Schich
PDU-Router zu
© automotive
der Kommunika
einem synchro
Asynchrone Funktion: Eine
und das DSL-Modul prüft,
werden soll. Gegebenenfalls
tionen mit geringerer Prioritä
aus werden Timer zur K
gestartet.
Synchrone Funktion: Zyklis
der Timer überwacht, das „S
rity Access Handling” verwa
se-Verhalten“ (z. B. Antwort
sent“) abgearbeitet.
Aufgabe der DSD-Schicht ist
genen Diagnosedatenstroms
! Weiterverarbeitung des
quests und Weiterreichen d
Unterschiedliche Interessen
 Automobilhersteller
 Wiederverwendung
 Austauschbarkeit von Zulieferern
 Kostensenkung durch geringere Einkaufspreise
 Zulieferer
 Wiederverwendung
 Verkauf an verschiedene Kunden
 Kostensenkung durch höhere Stückzahlen
 Keine Austauschbarkeit
 Werkzeughersteller, BSW-Anbieter
 Keine Austauschbarkeit
 Halbleiterhersteller
 Ein MCAL für alle BSW unabhängig vom BSW-Anbieter
106
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CUBAS
 Bosch entwickelt eine eigene AUTOSAR-Basis-Software, die für alle Steuergeräteplattformen der
Geschäfts- und Produktbereiche des gesamten Unternehmensbereichs Kraftfahrzeugtechnik (UBK)
eingesetzt wird. Sie wird als CUBAS (Common UBK Basis-Software) bezeichnet.
107
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Consulting
Provided by customers of
XYZ
Microcontroller
abstraction layer to be
developped
Microcontrollers by XYZ
66
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Artop – AUTOSAR Tool Platform
!"#$%!&'#(()'
*)+,-(./
012'3+.'4#
*'+,-$. */)01*2$),,3$43&+5,'67
*'+,-7
!"#$%&'()*+,-.&/,0&12&-(3445
!"#$%&'$()
109
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
7. Normen und Standards
1. AUTOSAR
1. Organisation
2. Schichtenmodell
3. Systementwicklung
4. Bussysteme im KFZ
5. Software-Architektur
6. Anwendungsbeispiele
7. Geplante AUTOSAR-Anwendungen
110
2
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Initial WP structure Phase III
Work Packages
1
2
3
10
System
Architecture
Software and Test
Specification
Validation
Application
Interfaces
2.1
WP-3.1
WP-10.0
Basic Software
Basic Software
Validation
Coordination of
Appl. Interfaces
1.1
Software
Architecture
WP-1.1.1
WP-1.1.2
Software
Architecture
and OS
Vehicle and
Application Mode
Mgmt.
WP-2.1.1
WP-10.1
COM Stack
Body and Comfort
WP-2.1.3
WP-1.1.5
MCAL
VFB and RTE
WP-2.1.4
Existence of Work
Packages will
depend on
sufficient
participation
WP-10.2
Powertrain
Diagnostics
WP-10.3
WP-1.2
Methodology and
Configuration
WP-1.3
Functional Safety
WP-2.1.5
Chassis Control
Libraries
WP-2.2
Conformance Test
Specification
Occupants and
Pedest. Safety
MM / T / HMI
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Lead Work Package
WP-10.4
WP-10.5
111
WP-x.y
WP-x.y
Work Package
AUTOSAR Application Interfaces
Compositions under Consideration
!
Body Domain
"
"
"
"
"
"
"
"
!
"
Central Locking
"
Interior Light
"
Mirror Adjustment
"
Mirror Tinting
"
Seat Adjustment
"
Wiper/Washer
"
Anti Theft Warning System "
Horn Control
"
Exterior Lights
Defrost Control
Seat climatization
Cabin climatization
Steering wheel climatization
Window Control
Sunroof/Convertible control
Steering column adjustment
Roller blind control
Chassis Control Domain
Vehicle Longitudinal Control
Electronic Stability Program
Electronic Parking Brake
Adaptive Cruise Control
Roll Stability Control
Steering System
Suspension System
Stand Still Manager
High Level Steering
" Vehicle Stability Steering
" Driver Assistance Steering
" All Wheel Drive/ Differential Lock
"
"
"
"
"
"
"
"
"
61
112
Oct. 23rd 2008
!
Powertrain Domain
" Powertrain Coordinator
" Transmission System
" Combustion Engine
" Engine torque and mode management
" Engine Speed And Position
" Combustion Engine Misc.
" Electric Machine
" Vehicle Motion Powertrain
" Driver Request
" Accelerator Pedal Position
" Safety Vehicle Speed Limitation
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Application Interfaces
Compositions under Consideration
!
Body Domain
"
"
"
"
"
"
"
"
!
"
Central Locking
"
Interior Light
"
Mirror Adjustment
"
Mirror Tinting
"
Seat Adjustment
"
Wiper/Washer
"
Anti Theft Warning System "
Horn Control
"
Exterior Lights
Defrost Control
Seat climatization
Cabin climatization
Steering wheel climatization
Window Control
Sunroof/Convertible control
Steering column adjustment
Roller blind control
Chassis Control Domain
Vehicle Longitudinal Control
Electronic Stability Program
Electronic Parking Brake
Adaptive Cruise Control
Roll Stability Control
Steering System
Suspension System
Stand Still Manager
High Level Steering
" Vehicle Stability Steering
" Driver Assistance Steering
" All Wheel Drive/ Differential Lock
"
"
"
"
"
"
"
"
"
61
112
Oct. 23rd 2008
!
Powertrain Domain
" Powertrain Coordinator
" Transmission System
Unterhaltungselektronik
" Combustion Engine
Entertainment
" Engine torque and mode management
Telematik ?
" Engine Speed And Position
" Combustion Engine Misc.
" Electric Machine
" Vehicle Motion Powertrain
" Driver Request
" Accelerator Pedal Position
" Safety Vehicle Speed Limitation
AUTOSAR Tutorial
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Release 4.0
Examples for Application Interfaces
SwitchEvent
LightRequest
check_switch ()
switch_event(event)
switch_event
(event)
request_light
(type, mode)
AUTOSAR Int.
AUTOSAR Interface
AUTOSAR RTE
Services
AUTOSAR
Interface
ECU
Abstraction
Standardized
Interface
Communication
Std. Interface
Std. Interface
Std. Interface
Std. AUTOSAR
Interface
Standardized Interface
DIO
CAN Driver
Microcontroller Abstraction
ECU-Hardware
Front-Light Manager
¾ Park
Distance Control
¾
request_light(type, mode)
get_keyposition()
set_light(type,
Exterior
lightmode)
AUTOSAR Interface
¾ Mirror adjustments
AUTOSAR RTE
¾ Seat adjustments
Standardized
Interface
¾ Anti Theft
System
Communication
¾ Interior
light
Std.
Interface
¾ Defrost control
Standardized Interface
CAN Driver
¾ Remote keyless entry
Microcontroller Abstraction
ECU-Hardware
¾ and many more
CAN Bus
20
113
May 13, 2010
AUTOSAR Technical Overview
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
Xenonlight
set_light(type, mode)
set_current (…)
AUTOSAR Interface
AUTOSAR RTE
Standardized
Interface
Communication
AUTOSAR
Interface
ECU
Abstraction
Std. Interface
Std. Interface
Standardized Interface
CAN Driver
PWM
Microcontroller Abstraction
ECU-Hardware
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
Memory Drivers
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
Flash EEPROM
Emulation
CAN transc
Driver
Microcontroller Drivers
CAN Interface
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Communication Drivers
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
CAN
LIN
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
20
LIN
114
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN
Flexray
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
Memory Drivers
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
Flash EEPROM
Emulation
CAN transc
Driver
Microcontroller Drivers
CAN Interface
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Communication Drivers
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
CAN
LIN
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
IP
20
LIN
114
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN
Flexray
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
Memory Drivers
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
Flash EEPROM
Emulation
CAN transc
Driver
Microcontroller Drivers
CAN Interface
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
AUTOSAR 4.0
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Communication Drivers
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
CAN
LIN
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
IP
20
LIN
114
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN
Flexray
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
Memory Drivers
Ext. FR
Driver
Ext. Flash
Driver
FR Interface
FR transc
Driver
Flash EEPROM
Emulation
CAN transc
Driver
Microcontroller Drivers
CAN Interface
Ext. CAN
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Ext.
EEPROM
Driver
CAN NM
FR
SM
FlexRay
TP
AUTOSAR 4.0
I/O Hardware
Abstraction
Communication Hardware Abstraction
Watchdog Interface
External
Watchdog
Driver
CAN
TP
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Communication Drivers
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
CAN
LIN
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
IP
20
MOST!!
114
LIN
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN
Flexray
AUTOSAR Basis Software Module
AUTOSAR Basic Software Modules
Application Layer
AUTOSAR Runtime Environment (RTE)
System Services
PDU Router
IPDU
Multiplexer
LIN
TP
CAN
TP
CAN Interface
Memory Drivers
Ext. FR
Driver
Microcontroller Drivers
Ext. CAN
Driver
Emulation
Mittlerweile
Ext.
Ext. Flash
EEPROMRealisierungen
von
Driver
Driver
BSW-Anbietern
FR Interface
FR transc
Driver
Flash EEPROM
CAN transc
Driver
CRC Lib
BSW Scheduler
AUTOSAR OS
Watchdog Interface
External
Watchdog
Driver
CAN NM
FR
SM
FlexRay
TP
AUTOSAR 4.0
I/O Hardware
Abstraction
Communication Hardware Abstraction
LIN
Interface
Memory Abstraction Interface
EEPROM
Abstraction
LIN
SM
FlexRay NM
Development Error
Tracer
Communication
Manager
Watchdog Manager
Diagnostic Event
Manager DEM
Function Inhibition
Manager FIM
ECU State Manager
NVRAM
Manager
I/O Hardware
Abstraction
Generic NM
Interf.
CAN
SM
DCM
Diagnostic
Com.
Manager
AUTOSAR
COM
Memory Hardware Abstraction
Onboard Device
Abstraction
Communication Drivers
I/O Drivers
PORT Driver
e.g. CCU
e.g. PCP
e.g. TPU
DIO
ADC
PWM
CCU
FlexRay
CAN
LIN
µC
DIO Driver
ADC Driver
ICU Driver
PWM Driver
FR Driver
CAN Driver
LIN Driver
LIN Communication
Stack
SPI
SCI
internal Flash Driver
FLASH
SPI Handler Driver
internal EEPROM
Driver
EEPROM
Ext. BUS
WDT
MCU
Power &
Clock Unit
GPT
RAM Test
Watchdog Driver
MCU Driver
GPT Driver
Flash Check
Microcontroller
Communication Services
Memory
Services
IP
20
MOST!!
114
LIN
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
CAN
Flexray
AUTOSAR Basis Software Module
Microsar von Vector Informatik
115
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
AUTOSAR Roll-Out
The AUTOSAR Core Partner Exploitation Plan (2008 - 2012)
Core Partner
2008
2009
2010
! ! 10 AUTOSAR BSW
modules as part of Std Core in
vehicles, tool / serial support in
place
! Body Computer with subset
of AUTOSAR specs
incorporated
! Instrument Cluster with
subset of AUTOSAR specs
incorporated
! Complete BSW Stack as
Product
! AUTOSAR Configuration
Tool
2011
! Powertrain-, Chassis-,
Safety-, Body- ECUs use
AUTOSAR architecture
! ACC ECU using
AUTOSAR architecture.
! Powertrain EDC/ME(D)17
ECUs using AUTOSAR
architecture
! Domain Control Unit using
AUTOSAR BSW
! Body ECUs using
AUTOSAR architecture
! Powertrain ECUs using
AUTOSAR architecture
! Chassis ECU using
AUTOSAR architecture
! Body Computer using
AUTOSAR architecture
! 1-2 AUTOSAR conformant
ECUs; first use of conformant
tools/methodology
! First AUTOSAR compatible ECUs in vehicles
! Introduction of AUTOSAR
architecture and methodology
in vehicles
! Continuous roll-out of ECUs
into vehicle architecture
increased use of conformant
tools / methodology
! First usage of AUTOSAR
modules
! Powertrain ECU using
AUTOSAR architecture
! Engine Systems Platform
based on AUTOSAR
architecture
! Chassis ECUs using
AUTOSAR architecture
! First usage of AUTOSAR
modules in vehicles
! First use of AUTOSAR
architecture ECU
! Body ECU using
AUTOSAR architecture
! First usage of AUTOSAR
modules
! First AUTOSAR modules
in series production
116
2012
26
8. October 2009
AUTOSAR – A Worldwide Standard is on the Road
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013
! AUTOSAR Architecture ECU
! First complete ECUs
in series production
Weiterführende Literatur
 O. Kindel, M. Friedrich:
Softwareentwicklung mit AUTOSAR
Grundlagen, Engineering, Management in der Praxis
dpunkt.verlag, 2009.
 AUTOSAR: Automotive Open System Architecture, "http://www.autosar.org".
 AUTOSAR Tutorial: http://www.autosar.org/download/conferencedocs/03_AUTOSAR_Tutorial.pdf
 AUTOSAR Software Modules, Specialized Glossary
Vector Informatik GmbH.
(In der Vorlesung verteilt)
117
Prof. Dr. Bernhard Hohlfeld: Automotive Software Engineering, TU Dresden, Fakultät Informatik, Sommersemester 2013

Documentos relacionados