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