Vorlesung Automotive Software-Engineering

Transkript

1 INFORMATIK CONSULTING SYSTEMS AG Vorlesung Automotive Software-Engineering Technische Universität Dresden Fakultät Informatik Professur Softwaretechnologie Sommersemester 2011 Dr. rer. nat. Bernhard Hohlfeld

2 Automotive Systems Engineering Motivation und Überblick SW-Entwicklung E/E-Entwicklung Beispiele aus der Praxis Das Automobil Normen und Standards OSEK/ VDX Die Automobilherstellung ASAM Die Automobilbranche 2

3 1. Motivation und Überblick 1. Motivation Automotive Software Engineering 2. Verteilte und komplexe Systementwicklung zwischen OEM und Zulieferern: Beispiel Türsteuerung 3. Software Entwicklungsprozess 4. Standards zur Softwareentwicklung 5. Software Architekturen 6. AUTOSAR 7. Lessons Learned 8. GI-Fachgruppe Automotive Software Engineering 9. Lehrveranstaltungen X

4 Software im Fahrzeug - siehe Teil 2 Die Automobilbranche Schema der Fertigung von Bändern und Blechen Anwärmen Warmwalzen Fräsen Inspektion Fahrzeug Engineering Dienstleistungen Türe Halbleiter kalt Vorwalzen 14 X Pressen Steuergerät Zwischen und Fertigwalzen Querteilen Bleche Längsteilen Bänder Kupferband (Halbzeug) Steckverbinder SW-Entwicklungswerkzeuge

5 Anforderungen Neue Beziehungen, Kompetenzen und Verantwortlichkeiten zwischen OEM und Zulieferer erforderlich X

6 Noch einfügen Folien mit Bezug zu AUTOSAR aus Teil 6 SW-Entwicklung Vortrag Schelling Vortrag Bunzel AUTOSAR Bilder Vortrag Fürst AUTOSAR OPen Conference 2010 X

7 INFORMATIK CONSULTING SYSTEMS AG Automotive Software Engineering und AUTOSAR 21. Januar 2010, Technische Universität Darmstadt Dr. Bernhard Hohlfeld ICS AG

8 Automotive und AUTOSAR Ein paar Worte zur Person und zur ICS AG Automotive Software Engineering Was sind die Probleme Fachgruppe Automotive Software Engineering (ASE) in der Gesellschaft für Informatik (GI) AUTOSAR Weiterführende Literatur 2

12 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 X2

13 AUTOSAR ist ganz einfach zu verstehen X DB DB DB ATM

14 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 X2

15 AUTOSAR Core Partners and Members (Phase II) Ca. 170 Firmen (Stand Ende 2009) X

16 AUTOSAR Core Partners and Members (Phase II) Ca. 170 Firmen (Stand Ende 2009) X

17 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 development contract Phase III planning started and is well under way X

18 AUTOSAR Membership Levels Core Partners Organizational control Technical contributions Administrative control Definition of external Information (web-release, clearance, etc.) Leadership of Working Groups Involvement in Working Groups Utilization of AUTOSAR standard Premium Members Utilization of AUTOSAR standard Development Members (for small companies with specific expertise) Technical contributions Access to current information Utilization of AUTOSAR standard Attendee (e.g. Universities) Support Role Leadership of Working Groups Involvement in Working Groups Technical contributions Access to current information Utilization of AUTOSAR standard Associate Members Access to finalized documents X

19 AUTOSAR Phase III Organization Core Partner Executive Board Core Partner, Premium and Development Member Subcontractor Administration Steering Commitee General Manager Technical Steering Team Legal Team CommunicationTeam Follow-up Team System Architecture Software and Test Specification Validation Application s Quality Manager Change Manager Release Manager Technical Office X

20 Initial WP Structure Phase III 1 System Architecture 1.1 Software Architecture Work Packages 2 Software and Test Specification 2.1 Basic Software 3 Validation WP-3.1 Basic Software Validation 10 Application s WP-10.0 Coordination of Appl. s Existence of Work Packages will depend on sufficient participation WP Software Architecture and OS WP VFB and RTE WP Vehicle and Application Mode Mgmt. WP COM Stack WP MCAL WP WP-10.1 Body and Comfort WP-10.2 Powertrain WP-1.2 Methodology and Configuration WP-1.3 Functional Safety Diagnostics WP Libraries WP-2.2 Conformance Test Specification WP-10.3 Chassis Control WP-10.4 Occupants and Pedest. Safety WP-x.y Lead Work Package WP-x.y Work Package WP-10.5 MM / T / HMI X

21 Initial WP structure Phase III 1 System Architecture 1.1 Software Architecture Work Packages 2 Software and Test Specification 2.1 Basic Software 3 Validation WP-3.1 Basic Software Validation 10 Application s WP-10.0 Coordination of Appl. s Existence of Work Packages will depend on sufficient participation WP Software Architecture and OS WP VFB and RTE WP Vehicle and Application Mode Mgmt. WP COM Stack WP MCAL WP WP-10.1 Body and Comfort WP-10.2 Powertrain WP-1.2 Methodology and Configuration WP-1.3 Functional Safety Diagnostics WP Libraries WP-2.2 Conformance Test Specification WP-10.3 Chassis Control WP-10.4 Occupants and Pedest. Safety WP-x.y Lead Work Package WP-x.y Work Package WP-10.5 MM / T / HMI X

22 Elektronische Systeme im Fahrzeug (4.1 Domänen) Anwendungsdomänen und elektronische Subsysteme (in diesem Abschnitt nach Schäuffele / Zurawka: Automotive Software Engineering) Antriebsstrang (Powertrain) Fahrwerk (Chassis) Karosserie (Body) Multi-Media (Telematics) Auch andere Klassifizierungen gebräuchlich (Beispiel Mercedes-Benz Technik transparent) Aktive Sicherheit Passive Sicherheit Karosserie Fahrwerk Innenraumtechnik Elektronik Motoren/Getriebe X

23 Initial WP structure Phase III 1 System Architecture 1.1 Software Architecture Work Packages 2 Software and Test Specification 2.1 Basic Software 3 Validation WP-3.1 Basic Software Validation 10 Application s WP-10.0 Coordination of Appl. s Existence of Work Packages will depend on sufficient participation WP Software Architecture and OS WP VFB and RTE WP Vehicle and Application Mode Mgmt. WP COM Stack WP MCAL WP WP-10.1 Body and Comfort WP-10.2 Powertrain WP-1.2 Methodology and Configuration WP-1.3 Functional Safety Diagnostics WP Libraries WP-2.2 Conformance Test Specification WP-10.3 Chassis Control WP-10.4 Occupants and Pedest. Safety WP-x.y Lead Work Package WP-x.y Work Package WP-10.5 MM / T / HMI X

24 What Daimler expects from AUTOSAR Provisioning of an interoperable reliable software kit. Increase of quality and development speed through a comprehensive and standardized design and implementation approach. Inter OEM exchange through interoperable software kits Reduction of testing effort in the automotive community Internal and external libraries for off-the-shelf applications Convenient integration into the development chain of Tier1s and OEMs Faster SW integration processes Standard application interfaces for SW as a product Application s Architecture/ Basic Software Data Exchange.xml Methodology Workflow Source: AUTOSAR PM Conference / AUTOSAR - a key enabler for comprehensive E/E standardization / S. Wolfsried, Daimler AG X

25 Preconditions for the introduction of AUTOSAR Introduction of a standard depends on its maturity and the benefits of its Geplante AUTOSAR- Anwendungen: Daimlers assessment is positive for AUTOSAR 3.0. Remaining issues: Conformance tests are essential for guaranteeing AUTOSAR s integrity as a standard. Furthermore, the standard appears overloaded. Maturity of a new standard has to be assured The release of AUTOSAR 3.0 has been determined to be the sweet spot for introduction according to our maturity and benefit assessment Maintenance shall be managed The AUTOSAR community is seen capable to assure this Conformance tests must be available to ensure the standard s continuous integrity Conformance tests not yet available Today the standard appears overloaded: too many requirements with a one-size-fits-all approach Source: AUTOSAR PM Conference / AUTOSAR - a key enabler for comprehensive E/E standardization / S. Wolfsried, Daimler AG X

26 Technical scope of AUTOSAR Methodology New concepts Exchange Formats Input Templates Meta Model Virtual Function Bus (VFB) RunTime Environment Configuration Concept Error Handling Memory Services Mode Management Network Management Comm. Services Industry-wide consolidation of existing basic software designs OS Kernel µcontroller Abstraction Diagnostics ECU Abstraction s Gateway Complex s Bus systems 9 Oct. 23rd 2008 AUTOSAR Tutorial X

32 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 32

33 AUTOSAR Architekturkonzept 4

34 AUTOSAR-Schichtenmodell Abstraktionsschichten der Steuergerätesoftware Anwendungsschicht (Application Layer) Laufzeitumgebung (Runtime Environment, RTE) Basissoftware (BSW) Basissoftware (BSW) 5

35 AUTOSAR-Schichtenmodell Anwendungsschicht (Application Layer) Der Application Layer realisiert die Anwendungsfunktionalität des Steuergeräts mittels Anwendungs-Softwarekomponenten (SWC - Software Component). Basissoftware (BSW) 6

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

37 AUTOSAR-Schichtenmodell BSW - Service Layer Der Service Layer stellt verschiedene Arten von Hintergrunddiensten wie Netzwerkdienstze, Speicherverwaltung und Buskommunikationsdienste bereit. Das Betriebssystem ist ebenfalls in dieser Schicht enthalten. Basissoftware (BSW) 8

38 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. Ziel: Unabhängigkeit der höheren Schichten von der Steuergeräte-Hardware Basissoftware (BSW) 9

39 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. Ziel: Unabhängigkeit der höheren Schichten von der Mikrocontroller-Hardware Basissoftware (BSW) 10

40 AUTOSAR-Schichtenmodell BSW - Complex s Die Complex s enthalten die in AUTOSAR nicht standardisierten Treiber für die spezifischen Eigenschaften eines Mikrocontrollers oder Steuergeräts. Beispiele: Sensorauswertung, direkter Zugriff auf Mikrocontroller Basissoftware (BSW) 11

41 AUTOSAR Basis Software Module AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) ECU State Manager System Services Function Inhibition Manager FIM Diagnostic Event Manager DEM Watchdog Manager Communication Manager Development Error Tracer Memory Services NVRAM Manager IPDU Multiplexer AUTOSAR COM LIN TP Communication Services PDU Router CAN TP DCM Diagnostic Com. Manager FlexRay TP CAN SM LIN SM FR SM Generic NM Interf. CAN NM FlexRay NM I/O Hardware Abstraction I/O Hardware Abstraction AUTOSAR OS BSW Scheduler CRC Lib Flash Check Microcontroller s GPT Onboard Device Abstraction Watchdog MCU External Watchdog Watchdog Memory Hardware Abstraction Memory Abstraction EEPROM Abstraction Ext. EEPROM RAM Test Memory s internal EEPROM Flash EEPROM Emulation Ext. Flash internal Flash SPI Handler LIN LIN Communication Stack Communication Hardware Abstraction Communication s LIN CAN CAN transc Ext. CAN CAN FR FR transc Ext. FR FR ICU I/O s DIO ADC PWM PORT Microcontroller GPT MCU Power & Clock Unit WDT Ext. BUS EEPROM FLASH SPI SCI LIN CAN FlexRay CCU PWM ADC DIO e.g. TPU µc e.g. PCP e.g. CCU 12 20

42 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 13 2

43 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 14

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

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

46 Systementwicklung Formale Definition der Schnittstellen Sender/Empfänger-Ports Client/Server-Ports 17

47 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: 18

48 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: 19

49 Beispiel Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver) Komfort-Lichtsteuerung schickt Licht anschalten an Lichtsteuerung (Client/Server) 20!"#$%!&'%()*+,-.'!-/01*./*2-. 34

52 Beispiel Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver) Komfort-Lichtsteuerung schickt Licht anschalten an Lichtsteuerung (Client/Server) TSG 2,... TSG Fahrer 20!"#$%!&'%()*+,-.'!-/01*./*2-. 34

53 Beispiel Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver) Komfort-Lichtsteuerung schickt Licht anschalten an Lichtsteuerung (Client/Server) TSG 2,... Welche Komponente kommuniziert noch mit dem Light Master? TSG Fahrer 20!"#$%!&'%()*+,-.'!-/01*./*2-. 34

54 Beispiel Regen-Licht-Sensor meldet Helligkeit an Komfort-Lichtsteuerung (Sender/Receiver) Komfort-Lichtsteuerung schickt Licht anschalten an Lichtsteuerung (Client/Server) TSG 2,... Welche Komponente kommuniziert noch mit dem Light Master? Wie? TSG Fahrer 20!"#$%!&'%()*+,-.'!-/01*./*2-. 34

55 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, Data, Service RPort: Requires, Data, Service Sender-Receiver Client-Server Calibration Data of AUTOSAR Service AUTOSAR Service 21

58 AUTOSAR Development Methodology Virtual Functional Bus Concept September, 2010 Hardware-independent Software Development with AUTOSAR

59 AUTOSAR Development Methodology Virtual Functional Bus Concept Application software functionality implemented in Software Components (SWC) September, 2010 Hardware-independent Software Development with AUTOSAR

60 AUTOSAR Development Methodology Virtual Functional Bus Concept Application software functionality implemented in Software Components (SWC) Handling of vehicle wide functions, independent from ECUs or network AUTOSAR SWC 1 AUTOSAR SWC 2 AUTOSAR SWC 3... AUTOSAR SWC n September, 2010 Hardware-independent Software Development with AUTOSAR

61 AUTOSAR Development Methodology Virtual Functional Bus Concept 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 AUTOSAR SWC 1 AUTOSAR SWC 2 AUTOSAR SWC 3... AUTOSAR SWC n September, 2010 Hardware-independent Software Development with AUTOSAR

62 AUTOSAR Development Methodology Virtual Functional Bus Concept SWC Description AUTOSAR SWC 1 SWC Description AUTOSAR SWC 2 SWC Description AUTOSAR SWC 3... SWC Description AUTOSAR SWC n 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 September, 2010 Hardware-independent Software Development with AUTOSAR

63 AUTOSAR Development Methodology Virtual Functional Bus Concept SWC Description AUTOSAR SWC 1 SWC Description AUTOSAR SWC 2 SWC Description AUTOSAR SWC 3... SWC Description AUTOSAR SWC n 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 September, 2010 Hardware-independent Software Development with AUTOSAR

64 AUTOSAR Development Methodology Virtual Functional Bus Concept SWC Description AUTOSAR SWC 1 SWC Description AUTOSAR SWC 2 SWC Description AUTOSAR SWC 3... Virtual Functional Bus SWC Description AUTOSAR SWC n 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 September, 2010 Hardware-independent Software Development with AUTOSAR

65 AUTOSAR Development Methodology Virtual Functional Bus Concept Ports and s SWC Description SWC Description SWC Description SWC Description PPort, provides a Sender-Receiver RPort, requires a Sender-Receiver PPort, provides a Client-Server, i.e. implements service AUTOSAR SWC 1 AUTOSAR SWC 2 AUTOSAR SWC 3... AUTOSAR SWC n AUTOSAR SWC RPort, requires a Client-Server, i.e. client of a service PPort, provides a Calibration RPort, requires a Calibration PPort, provides data to AUTOSAR Service RPort, requires data from AUTOSAR Service Virtual Functional Bus PPort, provides AUTOSAR Service (in BSW only) RPort, requires AUTOSAR Service as client September, 2010 Hardware-independent Software Development with AUTOSAR

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

67 Systementwicklung System Description Zuordnung der Komponenten zu den Steuergeräten Beschreibung der Netzwerkkommunikation im Fahrzeug 25

68 Systementwicklung AUTOSAR-Methode (1) Beschreibt Abläufe von der Systemkonfiguration zur Generierung von Code für Steuergeräte 26

69 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) 27

70 Systementwicklung AUTOSAR-Methode (3) Aus SWC Description, System Description und System Communication-Matrix wird die ECU Extract of System Description generiert 28

71 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 29

72 Integration ins Fahrzeug Steuergeräte Bussysteme 30

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

75 AUTOSAR Basis Software Module AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) ECU State Manager System Services Function Inhibition Manager FIM Diagnostic Event Manager DEM Watchdog Manager Communication Manager Development Error Tracer Memory Services NVRAM Manager IPDU Multiplexer AUTOSAR COM LIN TP Communication Services PDU Router CAN TP DCM Diagnostic Com. Manager FlexRay TP CAN SM LIN SM FR SM Generic NM Interf. CAN NM FlexRay NM I/O Hardware Abstraction I/O Hardware Abstraction AUTOSAR OS BSW Scheduler CRC Lib Flash Check Microcontroller s GPT Onboard Device Abstraction Watchdog External Watchdog MCU Watchdog Memory Hardware Abstraction Memory Abstraction EEPROM Abstraction Ext. EEPROM RAM Test Memory s internal EEPROM Flash EEPROM Emulation Ext. Flash internal Flash SPI Handler LIN LIN Communication Stack Communication Hardware Abstraction Communication s LIN CAN CAN transc Ext. CAN CAN FR FR transc Ext. FR FR ICU I/O s DIO ADC PWM PORT Microcontroller GPT MCU Power & Clock Unit WDT Ext. BUS EEPROM FLASH SPI SCI LIN CAN FlexRay CCU PWM ADC DIO e.g. TPU µc e.g. PCP e.g. CCU 20 33

76 AUTOSAR Basis Software Module AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) ECU State Manager System Services Function Inhibition Manager FIM Diagnostic Event Manager DEM Watchdog Manager Communication Manager Development Error Tracer Memory Services NVRAM Manager IPDU Multiplexer AUTOSAR COM LIN TP Communication Services PDU Router CAN TP DCM Diagnostic Com. Manager FlexRay TP CAN SM LIN SM FR SM Generic NM Interf. CAN NM FlexRay NM I/O Hardware Abstraction I/O Hardware Abstraction AUTOSAR OS BSW Scheduler CRC Lib Flash Check Microcontroller s GPT Onboard Device Abstraction Watchdog External Watchdog MCU Watchdog Memory Hardware Abstraction Memory Abstraction EEPROM Abstraction Ext. EEPROM RAM Test Memory s internal EEPROM Flash EEPROM Emulation Ext. Flash internal Flash LIN Communication scan I/O s Flexray SPI Handler LIN LIN Communication Stack Communication Hardware Abstraction LIN CAN CAN transc Ext. CAN CAN FR FR transc Ext. FR FR ICU PWM ADC DIO PORT Microcontroller GPT MCU Power & Clock Unit WDT Ext. BUS EEPROM FLASH SPI SCI LIN CAN FlexRay CCU PWM ADC DIO e.g. TPU µc e.g. PCP e.g. CCU 20 LIN CAN Flexray 34

77 AUTOSAR Basis Software Module AUTOSAR Basic Software Modules Application Layer AUTOSAR Runtime Environment (RTE) ECU State Manager System Services Function Inhibition Manager FIM Diagnostic Event Manager DEM Watchdog Manager Communication Manager Development Error Tracer Memory Services NVRAM Manager IPDU Multiplexer AUTOSAR COM LIN TP Communication Services PDU Router CAN TP DCM Diagnostic Com. Manager FlexRay TP CAN SM LIN SM FR SM Generic NM Interf. CAN NM FlexRay NM I/O Hardware Abstraction I/O Hardware Abstraction AUTOSAR OS BSW Scheduler CRC Lib Flash Check Microcontroller s GPT Onboard Device Abstraction Watchdog External Watchdog MCU Watchdog Memory Hardware Abstraction Memory Abstraction EEPROM Abstraction Ext. EEPROM RAM Test Memory s internal EEPROM Flash EEPROM Emulation Ext. Flash internal Flash SPI Handler LIN LIN Communication Stack Communication Hardware Abstraction Communication s LIN CAN CAN transc Ext. CAN CAN FR FR transc Ext. FR FR ICU I/O s DIO ADC PWM PORT Microcontroller GPT MCU Power & Clock Unit WDT Ext. BUS EEPROM FLASH SPI SCI LIN CAN FlexRay CCU PWM ADC DIO e.g. TPU µc e.g. PCP e.g. CCU IP 20 LIN CAN Flexray 35

78 TCIP/IP-Erweiterung in Release 4.0 AUTOSAR Release 4.0 TCP/IP Extension of the CommStack Overview RTE Signals IPDU multiplexer AUTOSAR COM DCM Diagnostic Communication Manager Communication Manager Socket adaptor DoIP I-PDU I-PDU PDU Router I-PDU I-PDU Generic NM interface Messages UDP DHCP ARP Socket Packet IP COTS TCP/IP Stack Datagram Ethernet TCP Streams Segment ICMP I-PDU FlexRay TP N-PDU Communication HW Abstraction FlexRay I-PDU I-PDU CAN TP N-PDU I-PDU CAN I-PDU FlexRay State Manager CAN State Manager LIN State Manager Eth State Manager LIN (incl. LIN TP) NM Coordinator NM NM Module NM Module UDP NM Module Module Eth- Frame Ethernet L-PDU L-PDU L-PDU Communication s FlexRay CAN LIN Low Level 24 May 13, 2010 AUTOSAR Technical Overview 36

80 Systementwurf Kommunikation über Virtual Function Bus (VFB) AUTOSAR Standardized AUTOSAR 38

81 Systementwurf Kommunikation über Virtual Function Bus (VFB) AUTOSAR Standardized AUTOSAR 39

82 Systementwicklung Abbildung der SWCs auf ECUs Abbildung der Kommunikation über VFB auf Kommunikation über RTE Kommunikation über Bussysteme 40

85 Logische Kommunikation über RTE d Inter-ECU Communication Innerhalb eines Steuergerätes implement the interface according communication paradigm (here -server based). are the interaction s of a component. ommunication is neled via the RTE. ommunication layer basic software is psulated and not e at the application. Zwischen Steuergeräten über Kommunikationsbus ECU I Application SW-C A RTE BSW VFB Application SW-C B ECU II RTE BSW Application SW-C C Application Ports AUTOSAR Infrastructure Sensor Hardware 43 Communication Bus Communication Path

88 AUTOSAR SW-Architektur AUTOSAR Standardized AUTOSAR Standardized 46

92 AUTOSAR SW-Architektur AUTOSAR 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 Vordefiniert durch AUTOSAR Standard Zugriff von SWC auf BSW-Module des Service Layer Standardized Im AUTOSAR-Standard als C-API vordefiniert Zwischen BSW-Modulen in einem Steuergerät Zwischen RTE und Betriebssystem Zwischen RTE und Kommunikations BSW 50

94 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 Oct. 23rd 2008 AUTOSAR Tutorial 52

95 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 Oct. 23rd 2008 AUTOSAR Tutorial 53

96 Use Case Pedal Management view for two ECUs distribute_v() e.g. FlexRay, CAN, etc. Technical benefits! Reuse of Intellectual Property! Increase in design flexibility! Simplification of the integration task! Reduction of SW development costs 19 Oct. 23rd 2008 AUTOSAR Tutorial 54

97 Systementwicklung AUTOSAR-Methode Verteilung auf 2 Steuergeräte unverändert neu 55

98 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. AUTOSAR Complex Device s ECU-Hardware September, 2010 Hardware-independent Software Development with AUTOSAR

99 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent LightRequest Front-Light Manager Headlight AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. Standardized Communication Std. Standardized AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s Microcontroller Abstraction ECU-Hardware September, 2010 Hardware-independent Software Development with AUTOSAR

100 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent check_switch () LightRequest Front-Light Manager Headlight AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

101 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent check_switch () LightRequest switch_event(event) Front-Light Manager Headlight switch_event (event) AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

102 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent check_switch () LightRequest switch_event(event) Front-Light Manager request_light(type, mode) Headlight switch_event (event) request_light (type, mode) AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

103 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent check_switch () LightRequest switch_event(event) Front-Light Manager request_light(type, mode) Headlight switch_event (event) request_light (type, mode) get_keyposition() AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. Standardized Communication Std. Standardized AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s DIO CAN Microcontroller Abstraction ECU-Hardware September, 2010 Hardware-independent Software Development with AUTOSAR

104 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent check_switch () LightRequest switch_event(event) Front-Light Manager request_light(type, mode) Headlight set_light(type, mode) switch_event (event) request_light (type, mode) get_keyposition() set_light(type, mode) AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. Standardized Communication Std. Standardized AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s DIO CAN Microcontroller Abstraction ECU-Hardware September, 2010 Hardware-independent Software Development with AUTOSAR

105 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent check_switch () LightRequest switch_event(event) Front-Light Manager request_light(type, mode) Headlight set_light(type, mode) switch_event (event) request_light (type, mode) get_keyposition() set_light(type, mode) set_current ( ) AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. Standardized Communication Std. Standardized AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s DIO PWM CAN Microcontroller Abstraction ECU-Hardware September, 2010 Hardware-independent Software Development with AUTOSAR

106 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture SwitchEvent check_switch () LightRequest switch_event(event) Front-Light Manager request_light(type, mode) Headlight set_light(type, mode) switch_event (event) request_light (type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) set_current ( ) AUTOSAR Int. AUTOSAR AUTOSAR AUTOSAR AUTOSAR RTE Standardized Operating System Standardized Std. AUTOSAR Services Std. Standardized Communication Std. Standardized AUTOSAR ECU Abstraction Std. AUTOSAR Complex Device s DIO PWM CAN Microcontroller Abstraction ECU-Hardware September, 2010 Hardware-independent Software Development with AUTOSAR

107 Software Architecture AUTOSAR Defined s Use Case Front Light Management mapped to AUTOSAR architecture Integrator Supplier B OEM Supplier A SwitchEvent check_switch () switch_event (event) AUTOSAR Int. LightRequest switch_event(event) request_light (type, mode) AUTOSAR Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) AUTOSAR AUTOSAR RTE Headlight set_light(type, mode) set_current ( ) AUTOSAR Silicon vendor A Integrator Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized PWM Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. CAN AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

108 Software Architecture AUTOSAR Defined s Use Case Front Light Management : Exchange type of Front Light Integrator Supplier B OEM Supplier A SwitchEvent check_switch () switch_event (event) AUTOSAR Int. LightRequest switch_event(event) request_light (type, mode) AUTOSAR Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) AUTOSAR AUTOSAR RTE Headlight set_light(type, mode) set_current ( ) AUTOSAR Silicon vendor A Integrator Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized PWM Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. CAN AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

109 Software Architecture AUTOSAR Defined s Use Case Front Light Management : Exchange type of Front Light Integrator Supplier B OEM Supplier A SwitchEvent check_switch () switch_event (event) AUTOSAR Int. LightRequest switch_event(event) request_light (type, mode) AUTOSAR Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) AUTOSAR AUTOSAR RTE Headlight set_light(type, mode) set_current ( ) AUTOSAR Silicon vendor A Integrator Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized PWM Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. CAN AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

110 Software Architecture AUTOSAR Defined s Use Case Front Light Management : Exchange type of Front Light Integrator Supplier B OEM SwitchEvent check_switch () switch_event (event) AUTOSAR Int. LightRequest switch_event(event) request_light (type, mode) AUTOSAR Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) AUTOSAR AUTOSAR RTE Supplier C Xenonlight set_light(type, mode) set_current ( ) AUTOSAR Silicon vendor A Integrator Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized PWM Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. CAN AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

111 Software Architecture AUTOSAR Defined s Use Case Front Light Management : Exchange type of Front Light Integrator Supplier B OEM SwitchEvent check_switch () switch_event (event) AUTOSAR Int. LightRequest switch_event(event) request_light (type, mode) AUTOSAR Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) AUTOSAR AUTOSAR RTE Supplier C Xenonlight set_light(type, mode) set_current ( ) AUTOSAR Integrator Silicon vendor B Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized DIO Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. CAN AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

112 Software Architecture AUTOSAR Defined s Use Case Front Light Management : Exchange type of Front Light Integrator Supplier B OEM SwitchEvent check_switch () switch_event (event) AUTOSAR Int. LightRequest switch_event(event) request_light (type, mode) AUTOSAR Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) set_dboard(type, mode) AUTOSAR AUTOSAR RTE Supplier C Xenonlight set_light(type, mode) set_current ( ) AUTOSAR Integrator Silicon vendor B Standardized Operating System Standardized Std. AUTOSAR Services Std. DIO Standardized Communication Std. Standardized DIO Microcontroller Abstraction ECU-Hardware AUTOSAR ECU Abstraction Std. CAN AUTOSAR Complex Device s September, 2010 Hardware-independent Software Development with AUTOSAR

113 Systementwicklung AUTOSAR-Methode Wechsel von Scheinwerfer auf Xenon-Scheinwerfer neu unverändert 58

114 Verteilung auf drei Steuergeräte Use case Front-Light Management Multiple ECUs SwitchEvent check_switch () switch_event (event) AUTOSAR Int. LightRequest switch_event(event) request_light (type, mode) AUTOSAR AUTOSAR RTE ECU3 Front-Light Manager request_light(type, mode) get_keyposition() set_light(type, mode) AUTOSAR ECU4 AUTOSAR RTE Xenonlight set_light(type, mode) set_current ( ) AUTOSAR ECU5 AUTOSAR RTE Std. AUTOSAR Services Std. AUTOSAR Operating System Communication Control ECU Abstraction Memory Management Std. s Hardware Standardized Microcontroller Abstraction ECU-Hardware Standardized Std. DIO CAN Standardized Operating System Communication Cont. Communication Communication Communication Memory Management Standardized CAN Std. s Hardware Microcontroller Abstraction ECU-Hardware Standardized Operating System Std. Standardized Microcontroller Abstraction ECU-Hardware AUTOSAR Communication Cont. ECU Abstraction Memory Management s Hardware Std. CAN PWM CAN Bus 13 59

115 Systementwicklung AUTOSAR-Methode Verteilung auf 3 Steuergeräte unverändert neu 60

116 technik-lexikon.html 61

117 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 bis Volt zu erzeugen und das automatische Wiederzünden und den konstanten Betrieb (bei nur 35 Watt Leistung) zu gewährleisten. 62

118 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 bis Volt zu erzeugen und das automatische Wiederzünden und den konstanten Betrieb (bei nur 35 Watt Leistung) zu gewährleisten. 63

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

120 Systementwicklung AUTOSAR-Methode Anpassung Limousine - Kabrio, Kombi neu neu neu 65

121 Systementwicklung AUTOSAR-Methode Anpassung an andere Modelle 66

122 Systementwicklung AUTOSAR-Methode Anpassung an andere Modelle bei gleicher Funktionsarchitektur unverändert 67

123 Systementwicklung AUTOSAR-Methode Anpassung an andere Modelle bei gleicher E/E-Architektur unverändert 68

124 Systementwicklung AUTOSAR-Methode Anpassung an andere Modelle bei gleicher Vernetzung/Verkabelung unverändert 69

125 Systementwicklung AUTOSAR-Methode Anpassung an andere Modelle bei gleicher Funktionsarchitektur, gleicher E/E-Architektur und gleicher Vernetzung/Verkabelung unverändert unverändert unverändert 70

126 71 Soweit zur Theorie, in der Praxis Es gibt nur wenige AUTOSAR- Schnittstellen weils so aufwendig ist. Folgende Punkte aus dem Vortrag von Dipl.-Phys. Andreas Möstel, Robert-Bosch GmbH sollten in Erinnerung bleiben: Bosch verwendet für die Implementierung des Steuergerätes DCM ein Autosar Stack von Elektrobit mit 7 BMW spezifischen Modulen und einer MCAL Anpassung von Infineon. Die jetztige Tool Landschaft und Unterstützung macht die Einbindung von neuen Funktionalitäten (wie z.b. eines neuen Signals) sehr aufwändig, an vielen Komfigurationsdateien des AUTOSAR Stacks muss geändert werden und die Konsistenz wird nicht durch die Tools unterstützt. Die Konfiguration des AUTOSAR Stacks erlaubt keinen Merge-Funktion. Beispiel 80% ist von Projekt übernehmbar und nur 20% wäre auszutauschen für eine andere Baureihe oder OEM. Dazu muss der komplette Stack getrennt und isoliert verwaltet und konfiguriert werden. den letzten Jahren immer mehr Bedeutung gewonnen. 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 Bild 2: Schnittstellen und Aufbau des DCM-Moduls 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 ODX- Format, zurückgegriffen werden kann. Ziel der Softing- Aktivitäten ist es, an geeigneter Stelle die Verbindung zwischen Standards wie ASAM-ODX oder FIBEX und AUTO- SAR 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 Layern empfangenen Requests entgegenzunehmen, nach Diagnosediensten (OBD ISO [3] und UDS ISO [4]) zu untersuchen und die Verarbeitung in der und nach Beendigung der Vera Response an das DCM-Modul übe wort nicht innerhalb der konfigur sendet das DCM selbstständig Nachricht. Die Applikationsschn AUTOSAR Runtime Environment bunden. Um die aktuellen oder gespeiche die zugehörigen Freeze-Frame-D auszulesen oder zu löschen, werd Event Manager) za funktionen bereitge geeigneter Reihenfo können. Die Schnitt tion Manager (COM Wesentlichen auf d mationen zum aktu status. Vom PDU-R richten von den Mod Bussysteme (CAN/ DCM weitergereicht Das DCM-Modul be! DSL Diagnostic! DSD Diagnostic! DSP Diagnostic Die DSL-Schicht ste PDU-Router zur Verf der Kommunikations einem synchronen u Asynchrone Funktion: Eine Nac und das DSL-Modul prüft, ob di werden soll. Gegebenenfalls wird tionen mit geringerer Priorität unt aus werden Timer zur Komm gestartet. Synchrone Funktion: Zyklisch h der Timer überwacht, das Sessio rity Access Handling verwaltet u se-verhalten (z. B. Antwort auf sent ) abgearbeitet. Aufgabe der DSD-Schicht ist das A genen Diagnosedatenstroms. Daz! Weiterverarbeitung des emp quests und Weiterreichen der vo die vorgesehene Anwendungsfun automotive