Systemarchitektur Gesamtfahrzeug.pdf - Carmeq GmbH
Systemarchitektur Gesamtfahrzeug.pdf - Carmeq GmbH
Systemarchitektur Gesamtfahrzeug.pdf - Carmeq GmbH
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Systemarchitektur</strong> <strong>Gesamtfahrzeug</strong><br />
AUTOUNI, Wolfsburg<br />
Oktober 2006<br />
Dr. Thomas Scharnhorst, <strong>Carmeq</strong> <strong>GmbH</strong><br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 0<br />
page 0 Dr. Thomas Scharnhorst May 2006
Das Auto der Zukunft<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Vernetzung<br />
Emissionen<br />
Bipolar platt e<br />
Luf t<br />
Anode<br />
H 2<br />
Kathode<br />
PEM - Folie<br />
Katalysator<br />
Luf t,H 2O Bipolar platt e<br />
page 1<br />
Fahrkomfort,<br />
Fahrerlebnis<br />
Sicherheit<br />
page 1 Dr. Thomas Scharnhorst May 2006
Steigende Relevanz der Elektronik im Auto<br />
Antriebsstrang<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Passive Sicherheit<br />
& Komfort<br />
page 2<br />
Kommunikation<br />
& Information<br />
Aktive Sicherheit<br />
page 2 Dr. Thomas Scharnhorst May 2006
Lebenszyklus<br />
Automobil<br />
Consumer<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 3<br />
page 3 Dr. Thomas Scharnhorst May 2006
Lebenszyklus<br />
Automobil<br />
Entwicklung<br />
3 Jahre<br />
Consumer<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 4<br />
Life Span 10 Jahre<br />
page 4 Dr. Thomas Scharnhorst May 2006
Lebenszyklus<br />
Automobil<br />
Entwicklung<br />
3 Jahre<br />
Consumer<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 5<br />
Life Span 10 Jahre<br />
Entwicklung 3 Monate<br />
Life Span 6 Monate<br />
page 5 Dr. Thomas Scharnhorst May 2006
Das Auto der Zukunft<br />
Agenda<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Globale Herausforderungen<br />
Elektronik im Fahrzeug<br />
Überblick der Innovationsfelder<br />
Aktive Sicherheit<br />
Telematik<br />
Elektronik bei Volkswagen<br />
Herausforderung der Elektronik<br />
Handlungsfelder<br />
page 6<br />
page 6 Dr. Thomas Scharnhorst May 2006
Aktive Sicherheit<br />
Advanced Front lighting<br />
System (AFS)<br />
ABS, ESP, ...<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Steer-by-wire Autonomes<br />
Fahren<br />
Verkehrszeichenerkennung<br />
Abbiege und<br />
Spurwechselassistent Brake-by-wire<br />
ACC Stop & Go<br />
ACC Stop & Go<br />
Adaptive Cruise<br />
Adaptive Control Cruise (ACC)<br />
Control (ACC)<br />
page 7<br />
Automatische Notbremse<br />
Aktiver<br />
Fußgängerschutz<br />
page 7 Dr. Thomas Scharnhorst May 2006
Automatische Notbremse<br />
Die Aufgabe<br />
ANB sollte automatisch bremsen mit größtmöglicher Verzögerung, wenn ein<br />
Unfall unvermeidbar ist.<br />
ANB unterstützt den Fahrer in kritischen Situationen und kann dadurch die<br />
Schwere des Unfalls reduzieren.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 8<br />
page 8 Dr. Thomas Scharnhorst May 2006
AFS - Advanced Frontlight System<br />
0º 20º<br />
konventionell AFS<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 9<br />
page 9 Dr. Thomas Scharnhorst May 2006
Integriertes Fahrzeug-Sensor-System<br />
Front<br />
Detection<br />
Front<br />
Short Range<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
early crash, pre-crash<br />
page 10<br />
Direct<br />
Visibility<br />
Blind<br />
Spot<br />
Mirrors<br />
Rear<br />
Detection<br />
page 10 Dr. Thomas Scharnhorst May 2006
Die Zahl der vernetzten Steuergeräte ist mit der Einführung der aktuellen VW-<br />
Fahrzeug-Generation um den Faktor 2-3 gestiegen.<br />
Anzahl der Steuergeräte<br />
50<br />
45<br />
40<br />
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
Passat B5<br />
Golf A4<br />
0<br />
1996 1997 1998 1999 2000 2001 2002 2003 2004 2005<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Golf A4,<br />
Polo A04<br />
Passat B5GP<br />
page 11<br />
Phaeton D1<br />
Golf A4<br />
Touareg<br />
Passat B6<br />
Golf A5<br />
page 11 Dr. Thomas Scharnhorst May 2006
Architekturen<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 12<br />
page 12 Dr. Thomas Scharnhorst May 2006
„E/E-Architektur“ bezeichnet die planvolle Verteilung und Verknüpfung der E/E-<br />
Komponenten unter der Maßgabe der funktionalen Anforderungen.<br />
Was ist Architektur?<br />
„…die Kunst oder Wissenschaft des<br />
planvollen Entwurfs der gebauten<br />
menschlichen Umwelt. […]” 1<br />
Für den Architekturbegriff der Architekten<br />
und Stadtplaner wie in der Informatik gilt:<br />
Aus den Anforderungen ergibt sich der<br />
Funktionsumfang, der durch das<br />
Zusammenspiel einzelner Komponenten<br />
realisiert werden muss.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 13<br />
1 Quelle: wikipedia.org<br />
page 13 Dr. Thomas Scharnhorst May 2006
Elektronikarchitekturen<br />
Schwerpunkte einer neuen Architektur<br />
Was ist eine Elektronikarchitektur?<br />
Eine Elektronikarchitektur beschreibt sämtliche Aspekte des Systems und<br />
muss zu einem funktionierenden Gesamtsystem aller beteiligten Komponenten<br />
führen. Sie wird durch die Schwerpunkte Funktion, Technologie und<br />
Topologie charakterisiert.<br />
Funktion<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Elektronikarchitektur<br />
Technologie<br />
page 14<br />
Topologie<br />
page 14 Dr. Thomas Scharnhorst May 2006
Elektronikarchitekturen<br />
Schwerpunkte einer neuen Architektur<br />
Funktion<br />
Funktion<br />
Elektronikarchitektur<br />
Elektronikarchitektur<br />
Technologie<br />
Technologie<br />
� Die Funktion ist das zentrale Element einer Elektronikarchitektur.<br />
� Eine präzise formale Beschreibung ihres Verhaltens und ihrer<br />
Interaktionen definiert die Funktion.<br />
� Mit einer Spezifikationssprache (z.B. UML), die eine modellbasierte<br />
Entwicklung einer funktionalen Architektur unterstützt, gelingt es,<br />
wesentliche Elemente und Schnittstellen transparent zu machen.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Topologie<br />
Topologie<br />
page 15<br />
Funktionale Funktionale Architektur<br />
Analyse<br />
page 15 Dr. Thomas Scharnhorst May 2006
Elektronikarchitekturen<br />
Schwerpunkte einer neuen Architektur<br />
Funktion<br />
Funktion<br />
Elektronikarchitektur<br />
Elektronikarchitektur<br />
Technologie<br />
Technologie<br />
� Mit der Technologie werden die Modelle bzw. funktionalen Architekturen realisiert.<br />
Sie dient zur Beschreibung und Realisierung der Elektronikarchitektur.<br />
� Fahrzeugrelevante Technologien sind:<br />
� HW-Technologien: Prozessoren, Chips<br />
� SW-Technologien: standardisierte SW-Module, Kapselung,<br />
offene Schnittstellen<br />
� Vernetzungs-Techn.: Kommunikationsprotokolle<br />
� Technologien können maßgebliche Wechselwirkungen auf die anderen Architektur<br />
Schwerpunkte haben.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Topologie<br />
Topologie<br />
page 16<br />
page 16 Dr. Thomas Scharnhorst May 2006
Elektronikarchitekturen<br />
Schwerpunkte einer neuen Architektur<br />
Funktion<br />
Funktion<br />
Elektronikarchitektur<br />
Elektronikarchitektur<br />
Technologie<br />
Technologie<br />
� Die Topologie beschreibt die Anordnung der verschiedenen<br />
Architekturkomponenten unter Einbeziehung der Verkabelung, des<br />
elektronischen Netzwerkes, der Software Strukturen, der Partitionierung<br />
und Platzierung der Funktionen auf bestimmte Steuergeräte.<br />
� Fahrzeugrelevante Topologien sind:<br />
� Funktionstopologie: Abhängigkeiten der Funktionen untereinander<br />
� Netzwerktopologie: Anordnung und Verbindung von Komponenten<br />
� Softwaretopologie: modulare SW-Architektur<br />
� Die geometrische Anordnung von Komponenten ist nur eine Untermenge.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Topologie<br />
Topologie<br />
page 17<br />
page 17 Dr. Thomas Scharnhorst May 2006
Der Ausgangspunkt der Architekturplanung sind heute die Fahrzeug-<br />
Anforderungen.<br />
90er<br />
Jahre:<br />
Heute:<br />
Architekturverständnis: Beispiel:<br />
�Beschreibung der Anordnung sämtlicher<br />
Steuergeräte<br />
�Definition der Technologie der<br />
Verbindungen<br />
�Vorgabe des Datenverkehrs zwischen<br />
den Steuergeräten (K-Matrix)<br />
�Ist ein Modell, das sämtliche Aspekte für<br />
den Entwurf und den Betrieb des<br />
gesamten EE-Systems eines<br />
Fahrzeugs beschreibt.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 18<br />
page 18 Dr. Thomas Scharnhorst May 2006
Die Startvoraussetzungen zur Beherrschung der hohen Komplexität der Elektronik<br />
waren Ende der 90er Jahre ungenügend.<br />
Industrie ist komplett fragmentiert.<br />
Elektronik ist für OEMs eine<br />
Black Box.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 19<br />
Jeder Hersteller verwendet eigene<br />
Standards.<br />
Bei gleicher Funktion vor<br />
Kunde werden komplett<br />
verschiedene Geräte<br />
eingesetzt.<br />
Langfristige Verwendung bewährter Komponenten ist bei der Elektronik nicht möglich<br />
bzw. zu teuer.<br />
page 19 Dr. Thomas Scharnhorst May 2006
Zunahme verteilter Funktionen<br />
Antriebs-CAN Komfort-CAN Info-CAN<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Virtueller Knoten<br />
page 20<br />
page 20 Dr. Thomas Scharnhorst May 2006
Zunahme verteilter Funktionen<br />
Skalierbar in unterschiedlichen Fahrzeugklassen<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Fahrzeugklasssen<br />
Antriebs-CAN Komfort-CAN Info-CAN<br />
page 21<br />
page 21 Dr. Thomas Scharnhorst May 2006
Das Resultat ist eine Vernetzungsarchitektur mit einem zentralen Gateway<br />
über das maximal 41 Steuergeräte miteinander kommunizieren<br />
CAN-<br />
Infotainment<br />
Gateway<br />
OBD<br />
Motor-<br />
Steuergerät<br />
Radio<br />
Radionavigation<br />
Telefon / Interface<br />
(Box 2)<br />
Telematik<br />
NAR<br />
Booster<br />
AMP<br />
TV-Tuner<br />
Stand-<br />
Heizung<br />
CAN-<br />
Kombi<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
… ESP-Cluster<br />
NOx<br />
Kombi<br />
(WFS)<br />
OBD<br />
Getriebe-<br />
Steuergerät<br />
Wischer<br />
Bordnetz-<br />
Steuergerät<br />
Airbag<br />
SG<br />
RS/LS<br />
Anhänger-<br />
Steuergerät<br />
Klima-<br />
Steuergerät<br />
Wählhebel<br />
Einparkhilfe<br />
Sitz Fahrer<br />
(Memory)<br />
Komfort-<br />
Steuergerät<br />
LIN<br />
IRÜ Sounder NGS<br />
page 22<br />
Elektrische<br />
Lenkhilfe<br />
Multifunktions-<br />
Steuergerät<br />
Bremsen-<br />
Steuergerät<br />
(ABS, ESP, …)<br />
Tür-<br />
Steuergerät<br />
Fahrer<br />
MFL<br />
Lenkwinkelsensor<br />
LIN<br />
SMLS<br />
(Lenksäule)<br />
Tür- (FH)<br />
Steuergerät<br />
hinten links<br />
Allrad<br />
SG<br />
PTC-<br />
Heizung<br />
Tür-<br />
Steuergerät<br />
Beifahrer<br />
Tür- (FH)<br />
Steuergerät<br />
hinten rechts<br />
CAN-Antrieb<br />
Dynamische<br />
LWR<br />
CAN-Komfort<br />
CAN-Komfort<br />
page 22 Dr. Thomas Scharnhorst May 2006
Bei der Bedienung der Blinkerhebel im Golf V werden 7 Steuergeräte im<br />
Netzwerk angesprochen<br />
Airbag<br />
SG<br />
Kombi Gateway<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Blinker<br />
(links oder rechts) betätigt<br />
SMLS<br />
Bordnetz SG<br />
Anhänger<br />
SG<br />
page 23<br />
Komfort<br />
SG<br />
TSG<br />
Beifahrer<br />
TSG<br />
Fahrer<br />
Blinker VR<br />
Blinker VR<br />
Klemme 15<br />
Warnblinker<br />
Blinker VR<br />
Blinker VL<br />
Blinker HR<br />
Blinker HL<br />
Blinker Kotflügel VR<br />
Blinker Kotflügel VL<br />
Seitlicher Blinker<br />
rechts<br />
Seitlicher Blinker<br />
links<br />
page 23 Dr. Thomas Scharnhorst May 2006
Systementwurf für Elektronikarchitektur<br />
Agenda<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Elektronik im Fahrzeug<br />
Überblick der Innovationsfelder<br />
Anforderungen einer Elektronikentwicklung<br />
Ansätze einer neuen Architektur<br />
Virtuelle Integration<br />
Toolkette<br />
Mögliche Arbeitsbereiche<br />
page 24<br />
page 24 Dr. Thomas Scharnhorst May 2006
Die Herausforderung<br />
Die Systeme wachsen zusammen<br />
• neue Funktionen häufig nur noch im Systemverbund<br />
• Integration von Teilsystemen auch unterschiedlicher Zulieferer<br />
Wertigkeit und Charakter der Fahrzeuge wird zunehmend durch<br />
komplexe Softwarefunktionen bestimmt<br />
• Flexiblere kundenspezifische Gestaltungsmöglichkeiten erforderlich<br />
Beherrschung der wachsenden Systemkomplexität wird für Fahrzeughersteller<br />
und Zulieferer wettbewerbsentscheidend<br />
• Geschwindigkeit, Kosten, Qualität<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 25<br />
page 25 Dr. Thomas Scharnhorst May 2006
Der Entwicklungsprozess<br />
Funktionsanforderungen<br />
Partitionierung<br />
(z.B. Packaging)<br />
Architektur<br />
(HW/SW Plattformen)<br />
Netzwerkfestlegung<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Konzeptphase Integrationsphase<br />
Formulierung der Testanforderung<br />
Integrationsplanung<br />
Implementierung Komponententest<br />
page 26<br />
Breadbordtest<br />
Fahrzeugintensivtest<br />
(FIT)<br />
Dyn. Labcar<br />
(z.B. HiL)<br />
Verifikation<br />
page 26 Dr. Thomas Scharnhorst May 2006
Der Entwicklungsprozess<br />
Funktionsanforderungen<br />
Partitionierung<br />
(z.B. Packaging)<br />
Architektur<br />
(HW/SW Plattformen)<br />
Netzwerkfestlegung<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Konzeptphase Integrationsphase<br />
Formulierung der Testanforderung<br />
Integrationsplanung<br />
Implementierung Komponententest<br />
page 27<br />
Breadbordtest<br />
Fahrzeugintensivtest<br />
(FIT)<br />
Dyn. Labcar<br />
(z.B. HiL)<br />
Verifikation<br />
page 27 Dr. Thomas Scharnhorst May 2006
Elemente einer neuen Architektur<br />
1<br />
2<br />
3<br />
4<br />
Funktionale Architektur:<br />
Welche Ordnung besteht zwischen Fahrzeugfunktionen?<br />
Software Architektur:<br />
Wie werden Fahrzeugfunktionen in Software implementiert?<br />
Netzwerk Architektur:<br />
Wie kommunizieren Hardware Komponenten?<br />
Hardware Verteilung:<br />
Wie sieht die optimale Verteilung der Funktionen aus?<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 28<br />
page 28 Dr. Thomas Scharnhorst May 2006
Elemente einer neuen Architektur<br />
1<br />
2<br />
3<br />
4<br />
Funktionale Architektur:<br />
Welche Ordnung besteht zwischen Fahrzeugfunktionen?<br />
Software Architektur:<br />
Wie werden Fahrzeugfunktionen in Software implementiert?<br />
Netzwerk Architektur:<br />
Wie kommunizieren Hardware Komponenten?<br />
Hardware Verteilung:<br />
Wo werden Fahrzeugfunktionen in Hardware realisiert?<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 29<br />
page 29 Dr. Thomas Scharnhorst May 2006
Funktionale Architektur<br />
Spezifizierung der Funktion<br />
Interface<br />
Brake by<br />
Wire<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
f1<br />
f2<br />
page 30<br />
???<br />
f3<br />
f4<br />
f7<br />
f9<br />
f6<br />
f5<br />
f8<br />
page 30 Dr. Thomas Scharnhorst May 2006
Funktionale Architektur<br />
Am Beispiel ACC (Adaptive Cruise Control) mit UML<br />
Übersichts-Ebene<br />
Fahrzeug-Ebene<br />
Fahrer<br />
- Verkehrssituation : int<br />
- Längsdynamik : int<br />
- SollzustandACC : int<br />
+Auswertung(Verkehrssituation:int)<br />
+Vorgabe(Längsdynamik:int)<br />
+Vorgabe(Sollzustand:int)<br />
Fahrzeug<br />
- Längsdynamik : int<br />
- Sollzustand : int<br />
- Querdynamik : int<br />
+Veränderung(Längsdynamik:int)<br />
+Weiterleitung(SollzustandACC:int)<br />
+Veränderung(Querdynamik:int)<br />
Gelände<br />
- Witterung : int<br />
- Verkehrssituation : int<br />
- Gelände : int<br />
-Lenkwinkel : int<br />
+Veränderung(Witterung:int)<br />
-StatusBE : int<br />
+Veränderung(Verkehrssituation:int)<br />
-Hauptschalter : int<br />
+Veränderung(Gelände:int)<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Fahrze ug<br />
- Läng sdynam ik : int<br />
- Sollzustand : int<br />
- Querdyna mik : int<br />
+Ve rä nde ru ng(Län gsdynam ik:in t)<br />
+W eiterleit ung (Sollzusta ndAC C: int )<br />
+Ve rä nde ru ng(Querdyna mik:int)<br />
Antrieb/Fahrwerk Vorderwagen<br />
Armaturentafel<br />
Motor<br />
-Fahrerwunsch : int<br />
-StatusMSG : int<br />
-Sollbeschleunigung : int<br />
-Istbeschleunigung : int<br />
-StatusACC : int<br />
+Einlesen(Fahrerwunsch:int)<br />
+Senden(Fahrerwunsch:int)<br />
+Senden(StatusMSG:int)<br />
+Generieren(StatusMSG:int)<br />
+Empfangen(Sollbeschleunigung:int)<br />
+Generieren(Istbeschleunigung:int)<br />
+Empfangen(StatusACC:int)<br />
-StatusESP : int<br />
-Raddrehzahl : int<br />
- Gierrate : int<br />
Bremse<br />
+Generieren(StatusESP:int)<br />
+Senden(StatusESP:int)<br />
+Einlesen(Raddrehzahl:int)<br />
+Senden(Raddrehzahl:int)<br />
+Signalverarbeitung(Raddrehzahl:int)<br />
+Einlesen(Gierrate:int)<br />
+Senden(Gierrate:int)<br />
Lenksäulenmodul<br />
-Bedienelemente : int<br />
+Einlesen(Lenkwinkel:int)<br />
+Signalverarbeitung(Lenkwinkel:int)<br />
+Senden(Lenkwinkel:int)<br />
+Einlesen(Bedienelemente:int)<br />
+Signalverarbeitung(Bedienel.:int)<br />
+Senden(Bedienelemente:int)<br />
+Ausgabe(Hauptschalter:int)<br />
Getriebe<br />
-Gang : int<br />
+Generieren(Gang:int)<br />
+Senden(Gang:int)<br />
EPB<br />
ACC<br />
- Längsdynamik : int<br />
P e lle<br />
Relais<br />
- Verkehrssituation : int<br />
-Position : int<br />
-Schalter : boolean<br />
- Sollzustand : int +Veränderung(Position:int)<br />
+Betätigen(Schalter:boolean)<br />
Radar-Funktion<br />
- Querdynamik : int<br />
Abdeckung<br />
-Dämpfung : int<br />
+Veränderung(Dämpfung:int)<br />
Treiber<br />
Kühler<br />
+Vorgabe(Längsdynamik:int)<br />
-Oberflächentemperatur : int<br />
+Auswertung(Verkehrssituation:int)<br />
+Veränderung(Oberflächentemp:int)<br />
+Auswertung(SollzustandACC:int)<br />
Gateway<br />
-ZustandACC : int<br />
-StatusAE : int<br />
+Umsetzen(ZustandACC:int)<br />
+Umsetzen(StatusAE:int)<br />
Halter<br />
-Justage : int<br />
+Veränderung(Justage:int)<br />
+Auswertung(Querdynamik:int)<br />
ACC Steuergerät<br />
KU -M on ta ge trä ge r<br />
-Position : int<br />
-ZustandAufnahm eSG : int<br />
+Veränderung(Position:int)<br />
+Wechsel(ZustandAufnahmeSG:int)<br />
page 31<br />
ACC<br />
- Lä ngsdyn amik : int<br />
- Verkeh rssituat ion : int<br />
- Sollzustand : int<br />
- Querdynamik : int<br />
+Vorga be(Län gsdynam ik: in t)<br />
+Ausw ertun g(Ve rkeh rssituat io n:int)<br />
+Ausw ertun g(So llzusta ndAC C: in t)<br />
+Ausw ertun g(Qu erd ynam ik:int)<br />
ACC-System-Ebene<br />
Objektbildung<br />
Zielbildung<br />
Anzeigeelemente<br />
-ZustandACC : int<br />
-StatusAE : int<br />
+Empfangen(ZustandACC:int)<br />
+Anzeigen(ZustandACC:int)<br />
+Generieren(StatusAE:int)<br />
+Senden(StatusAE:int)<br />
CPU<br />
-Wunschabstand : int<br />
-Wunschgeschwindigkeit : int<br />
-Radarwellen : int<br />
-Objektliste : int<br />
-Zielobjekt : int<br />
-Sollbeschleunigung : int<br />
-ZustandACC : int<br />
-StatusACC : int<br />
-StatusAE : int<br />
-StatusBE : int<br />
- Fahrerwuns ch : int<br />
-Raddrehzahlen : int<br />
- Gierrate : int<br />
-Lenkwinkel : int<br />
-Bedienelemente : int<br />
-Hauptschalter : int<br />
-Gang : int<br />
-Dejustage : int<br />
- Tem peratur : int<br />
-Eigensicherheit : int<br />
Sollgrößenbildung<br />
Längsregelung Netzwerk-Fkt.<br />
+Ändern(Wunschabstand : int)<br />
+Ändern(Wunschgeschwindigkeit:int) +Senden(Radarwellen : int)<br />
+Empfangen(Radarwellen:int)<br />
+Generieren(Objektliste : int)<br />
+Generieren(Zielobjekt : int)<br />
+Generieren(Sollbeschleunigung : int)<br />
+Senden(Sollbeschleunigung : int)<br />
+Generieren(ZustandACC : int)<br />
+Senden(ZustandACC:int)<br />
+Generieren(StatusACC : int)<br />
+Senden(StatusACC:int)<br />
+Einlesen(Hauptschalter:int)<br />
+Empfangen(StatusAE : int)<br />
+Empfangen(StatusBE : int)<br />
+Empfangen(StatusMSG : int)<br />
+Empfangen(StatusESP : int)<br />
+Empfangen(Fahrerwunsch : int)<br />
+Empfangen(Raddrehzahlen : int)<br />
+Empfangen(Gierrate : int)<br />
+Empfangen(Lenkwinkel : int)<br />
+Empfangen(Bedienelemente : int)<br />
+Empfangen(Gang : int)<br />
+Kompensation(Dejustage : int)<br />
+Längsregelung()<br />
Diagnose<br />
Betriebssystem<br />
page 31 Dr. Thomas Scharnhorst May 2006
Elemente einer neuen Architektur<br />
1<br />
2<br />
3<br />
4<br />
Funktionale Architektur:<br />
Welche Ordnung besteht zwischen Fahrzeugfunktionen?<br />
Software Architektur:<br />
Wie werden Fahrzeugfunktionen in Software implementiert?<br />
Netzwerk Architektur:<br />
Wie kommunizieren Hardware Komponenten?<br />
Hardware Verteilung:<br />
Wo werden Fahrzeugfunktionen in Hardware realisiert?<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 32<br />
page 32 Dr. Thomas Scharnhorst May 2006
Software-Architektur<br />
Vorgabe<br />
OEM<br />
OEM<br />
Funktion<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Zulieferer<br />
Funktion<br />
Exklusive<br />
OEM<br />
Funktion<br />
Offene Schnittstelle - API<br />
Basis Systemfunktionen<br />
Kernfunktionen<br />
Treiber<br />
Betriebssystem OSEK<br />
Hardware<br />
page 33<br />
COP<br />
Funktion<br />
Funktion<br />
HAL<br />
page 33 Dr. Thomas Scharnhorst May 2006
Elemente einer neuen Architektur<br />
1<br />
2<br />
3<br />
4<br />
Funktionale Architektur:<br />
Welche Ordnung besteht zwischen Fahrzeugfunktionen?<br />
Software Architektur:<br />
Wie werden Fahrzeugfunktionen in Software implementiert?<br />
Netzwerk Architektur:<br />
Wie kommunizieren Hardware Komponenten?<br />
Hardware Verteilung:<br />
Wo werden Fahrzeugfunktionen in Hardware realisiert?<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 34<br />
page 34 Dr. Thomas Scharnhorst May 2006
Netzwerk Architektur<br />
Standardisierung der Fahrzeugnetzwerke<br />
Datenrate [ bit/s ]<br />
25M<br />
10M<br />
1M<br />
125K<br />
20K<br />
LIN<br />
zeitgesteuert<br />
Master-Slave Prinzip<br />
Eindraht, kein Quartz<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
“embedded control” Multimedia<br />
CAN-C<br />
Arbitration (CSMA)<br />
2 Drahttechnik<br />
CAN-B<br />
Arbitration<br />
fehlertolerant<br />
2 Drahttechnik<br />
TTP, Flexray<br />
zeitgesteuert (TDMA)<br />
fehlertolerant, zuverlässig<br />
2x2 Drähte / optisch<br />
0.5 1 2.5 5<br />
Relative Kommunikationskosten pro Knoten<br />
page 35<br />
MOST<br />
Optisches<br />
Ringnetzwerk<br />
Bluetooth<br />
drahtlose<br />
Übertragung<br />
page 35 Dr. Thomas Scharnhorst May 2006
Netzwerk-Architektur<br />
Strukturierung in Domänen<br />
Anforderungen:<br />
• Strukturierung in Domänen<br />
• Skalierbare Sub-Bus-Systeme<br />
innerhalb der Domänen<br />
• Integration und Konzentration<br />
innerhalb der Domänen<br />
• Vernetzung zwischen den<br />
Domänen<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Powertrain Body Elec. Infotainm.<br />
TTP/Flexray CAN MOST<br />
• Fahrzeugweite Koordination Ziel: Flexibilität des Netzwerkes<br />
page 36<br />
page 36 Dr. Thomas Scharnhorst May 2006
Elemente einer neuen Architektur<br />
1<br />
2<br />
3<br />
4<br />
Funktionale Architektur:<br />
Welche Ordnung besteht zwischen Fahrzeugfunktionen?<br />
Software Architektur:<br />
Wie werden Fahrzeugfunktionen in Software implementiert?<br />
Netzwerk Architektur:<br />
Wie kommunizieren Hardware Komponenten?<br />
Hardware Verteilung:<br />
Wo werden Fahrzeugfunktionen in Hardware realisiert?<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 37<br />
page 37 Dr. Thomas Scharnhorst May 2006
Hardware Verteilung<br />
Steuergeräte Optimierung<br />
f1<br />
f2<br />
f3<br />
f4<br />
f6<br />
f5<br />
SG1 SG2 SG3<br />
SG4 SG5<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Funktionspackage<br />
page 38<br />
f1<br />
f2<br />
f3<br />
f4<br />
f6<br />
f5<br />
SG1 SG2 SG3<br />
SG4 SG5<br />
page 38 Dr. Thomas Scharnhorst May 2006
Elemente einer neuen Architektur<br />
1<br />
2<br />
3<br />
4<br />
Funktionale Architektur:<br />
Welche Ordnung besteht zwischen Fahrzeugfunktionen?<br />
Software Architektur:<br />
Wie werden Fahrzeugfunktionen in Software implementiert?<br />
Netzwerk Architektur:<br />
Wie kommunizieren Hardware Komponenten?<br />
Hardware Verteilung:<br />
Wo werden Fahrzeugfunktionen in Hardware realisiert?<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 39<br />
Wie?<br />
Womit?<br />
page 39 Dr. Thomas Scharnhorst May 2006
Tool Anforderungen<br />
Check Liste<br />
Modellierung der Funktionalitäten auch bei verteilten Funktionen<br />
Wiederverwendung von existierenden Modellen unterschiedlicher<br />
Toolanbieter<br />
Simulation und Modellierung des zeitlichen Verhaltens der Steuergeräte<br />
inkl. Berücksichtigung der Interrupt-Strukturen, etc.<br />
Modellierung des zeitlichen Verhaltens des Systems auch bei<br />
Einspeisung von Fehlern an unterschiedlichen Orten (Fehler-Injektion)<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 40<br />
page 40 Dr. Thomas Scharnhorst May 2006
AUTOSAR<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 41<br />
page 41 Dr. Thomas Scharnhorst May 2006
Although the function based development process has been established, some<br />
deficiencies could not yet be solved satisfactorily.<br />
OEM<br />
Supplier<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
� Proprietary, OEM specific standard<br />
core solutions<br />
� No standardized application interfaces<br />
Tool provider<br />
� Reduction of version proliferation<br />
� Handling of OEM specific adaptations<br />
� Proprietary interfaces with development<br />
processes<br />
� Incomplete tool landscape<br />
page 42<br />
page 42 Dr. Thomas Scharnhorst May 2006
Mit seinem ganzheitlichen Ansatz integriert AUTOSAR bestehende industrieweite<br />
Initiativen zur Etablierung von Elektronik-Standards.<br />
MSR<br />
Manufactor Supplier Relationship<br />
OSEK/VDX<br />
2001<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
ASAM ASAM/ODX ODX 2002<br />
Media Orientated<br />
System Transport<br />
Hersteller Initiative Software<br />
HIS<br />
FlexRay<br />
Local interconnect network<br />
page 43<br />
AUTomotive Open<br />
System ARchitecture<br />
2006<br />
page 43 Dr. Thomas Scharnhorst May 2006
AUTOSAR: Komplexitätsmanagement bei E/E-Architekturen durch verstärkte<br />
Wiederverwendung und Austauschbarkeit von SW-Komponenten.<br />
OEM 2<br />
OEM 1<br />
Platform 2.1<br />
Platform 2.2<br />
Platform 2.n<br />
Platform 1.1<br />
Platform 1.2<br />
Platform 1.n<br />
Austauschbarkeit<br />
zwischen den Herstellern<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Zulieferer A<br />
�Fahrwerk<br />
�Sicherheit<br />
�Aufbau/Komfort<br />
�Multimedia<br />
Zulieferer B<br />
�Fahrwerk<br />
�Sicherheit<br />
�Telematik<br />
�Multimedia<br />
Zulieferer C<br />
�Aufbau/Komfort<br />
�Antriebsstrang<br />
�Telematik<br />
�Multimedia<br />
Austauschbarkeit<br />
zwischen<br />
Fahrzeugplattformen<br />
page 44<br />
Platform m.1<br />
Platform m.2<br />
Platform m.n<br />
OEM m<br />
Platform m.1<br />
Platform m.2<br />
Platform m.n<br />
OEM n<br />
Austauschbarkeit<br />
zwischen Lösungen<br />
verschiedener Zulieferer<br />
page 44 Dr. Thomas Scharnhorst May 2006
OEMs, supplier and tool provider benefit from AUTOSAR.<br />
OEM<br />
Supplier<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
� OEM overlapping reuse of software modules<br />
� Maintaining ability to compete on innovative functions,<br />
heightened design flexibility<br />
� Simplification of the integration task<br />
� Reduction of total SW development costs<br />
Tool provider<br />
� Reduction of version proliferation<br />
� Development partitioning among suppliers<br />
� Increase of efficiency in functional development<br />
� New business models possible<br />
New market<br />
entrant<br />
� Common interfaces with development<br />
processes<br />
� Seamless, manageable, task optimized<br />
(time dependent) tool landscape<br />
page 45<br />
� Transparent and defined<br />
interfaces enable new<br />
business models<br />
page 45 Dr. Thomas Scharnhorst May 2006
AUTOSAR verfolgt seit dem Jahr 2002 das Ziel, einen offenen Standard für<br />
E/E Architekturen im Fahrzeug zu etablieren.<br />
Erste Gespräche mit<br />
BMW, Bosch, Continental<br />
Teves, DaimlerChrysler,<br />
Volkswagen und später<br />
auch Siemens VDO<br />
Einrichtung eines<br />
technischen Teams<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Offizielle Gründung der<br />
Entwicklungspartnerschaft<br />
AUTOSAR (AUTomotive Open<br />
System ARchitecture).<br />
Ford, Peugeot Citroën und<br />
Toyota werden Core Partner<br />
page 46<br />
General Motors wird Core<br />
Partner<br />
08/02 11/02 08/03 11..12/03 12/04<br />
page 46 Dr. Thomas Scharnhorst May 2006
OEMs und Zulieferer beteiligen sich weltweit an AUTOSAR.<br />
10 Core Partners<br />
48 Premium Members<br />
General<br />
OEM<br />
Generic<br />
Tier 1<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Standard<br />
Software<br />
page 47<br />
Tools and<br />
Services<br />
28 Associate<br />
Members<br />
Semiconductors<br />
page 47 Dr. Thomas Scharnhorst May 2006
Die AUTOSAR-Organisation entspricht einem “3-Schalen-Modell” mit<br />
unterschiedlichen Rollen der Mitglieder.<br />
Core Partner<br />
(OEM & Tier 1 Supplier)<br />
� Strategie<br />
� Organisatorische Kontrolle<br />
� Technischer Beitrag<br />
� Administration<br />
� Freigabe für externe Nutzung<br />
� Leitung und Mitarbeit in den Arbeitsgruppen<br />
Premium Members<br />
� Leitung der Arbeitsgruppen<br />
� Mitarbeit in den Arbeitsgruppen<br />
� Technischer Beitrag<br />
� Zugang zu den Informationen<br />
Associate Members<br />
� Zugang zu finalisierten Dokumenten<br />
� Umsetzung des Standards<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 48<br />
Weitere Rollen:<br />
� Development<br />
Member<br />
� Attendee<br />
Organisationsstruktur angelehnt an das FlexRay Konsortium<br />
page 48 Dr. Thomas Scharnhorst May 2006
Projektleitung und organisatorische Kontrolle ist in den Händen der AUTOSAR Core<br />
Partner.<br />
Administration<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Projekt Organisation<br />
Executive Board<br />
Steering Committee<br />
PL Team<br />
System Team<br />
Working Groups<br />
page 49<br />
Spokesperson<br />
Basic SW<br />
Architecture Team<br />
Unterstützende Funktionen<br />
Technical Manager<br />
Project Control<br />
Office<br />
Technical Office<br />
page 49 Dr. Thomas Scharnhorst May 2006
Currently some 650 people are contributing to the development of the<br />
standard, representing a full time equivalent of 175 staff.<br />
62 Modules<br />
57 Deliverables for<br />
Release 1.0<br />
23 active WP / WG<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
10 Core Partners<br />
46 Premium Members<br />
about 9.8 GB on<br />
server<br />
115000 files<br />
page 50<br />
approx.<br />
175 Full Time<br />
Equivalents<br />
approx. 300 Reviews<br />
for Release 1.0<br />
approx.<br />
650 persons<br />
involved<br />
page 50 Dr. Thomas Scharnhorst May 2006
Aus den Zielen von AUTOSAR ergeben sich die Themenschwerpunkte: Basic<br />
Software, Funktionelle Schnittstellen und Software-Integration.<br />
� Verfügbarkeit und Sicherheit<br />
� Redundanz-Aktivierung<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Projektziele Themen<br />
� Skalierbarkeit über Fahrzeuge, Plattformen und<br />
Hersteller<br />
� Implementierung und Standardisierung von<br />
Basisfunktionen als industrieweiter “Standard<br />
Core”.<br />
� Verschiebbarkeit von Funktionen im Netzwerk<br />
� Integration von funktionellen Modulen<br />
verschiedener Zulieferer<br />
� Wartbarkeit über den gesamten Produktlebenszyklus<br />
� Verstärkte Verwendung von “Commercial off the Shelf<br />
Hardware“<br />
� Software Updates und Upgrades über die gesamte<br />
Lebenszeit des Fahrzeuges<br />
page 51<br />
� Basic Software<br />
� Funktionelle Schnittstellen<br />
� Methoden zur Software-<br />
Integration<br />
page 51 Dr. Thomas Scharnhorst May 2006
Die AUTOSAR Steuergeräte-Software-Architektur gliedert sich in die Ebenen<br />
Applikation, AUTOSAR Run Time Environment (RTE) und Basic Software.<br />
Application<br />
Software<br />
Component<br />
AUTOSAR<br />
Interface<br />
Standardized<br />
Interface<br />
Operating<br />
System<br />
Standardized<br />
Inteface<br />
Actuator<br />
Software<br />
Component<br />
AUTOSAR<br />
Interface<br />
AUTOSAR Runtime Environment (RTE)<br />
Standardized<br />
AUTOSAR<br />
Interface<br />
Services<br />
Standardized<br />
Interface<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Sensor<br />
Software<br />
Component<br />
AUTOSAR<br />
Interface<br />
Standardized<br />
Interface<br />
Communication<br />
Standardized<br />
Interface<br />
Basic Software<br />
ECU-Hardware<br />
page 52<br />
AUTOSAR<br />
Software<br />
..............<br />
AUTOSAR<br />
Interface<br />
ECU<br />
Abstraction<br />
Standardized<br />
Interface<br />
Standardized<br />
Interface<br />
Microcontroller<br />
Abstraction<br />
Application<br />
Software<br />
Component<br />
AUTOSAR<br />
Interface<br />
AUTOSAR<br />
Interface<br />
Complex<br />
Device<br />
Drivers<br />
AUTOSAR<br />
Software<br />
Component<br />
Interface<br />
ECU<br />
Firmware<br />
Standard<br />
Software<br />
page 52 Dr. Thomas Scharnhorst May 2006
Nach der AUTOSAR Methode wird die Elektronik-Architektur aus der formalen<br />
Beschreibung von Software- und Hardware-Komponenten abgeleitet.<br />
SW-C<br />
Description<br />
ECU<br />
Descriptions<br />
AUTOSAR<br />
SW-C<br />
1<br />
AUTOSAR<br />
SW-C<br />
1<br />
Tool supporting deployment<br />
of SW components<br />
ECU I ECU II<br />
RTE<br />
Basic Software<br />
SW-C<br />
Description<br />
AUTOSAR<br />
SW-C<br />
3<br />
AUTOSAR<br />
SW-C<br />
2<br />
SW-C<br />
Description<br />
AUTOSAR<br />
SW-C<br />
3<br />
Virtual Functional Bus<br />
AUTOSAR<br />
SW-C<br />
2<br />
RTE<br />
Basic Software<br />
...<br />
...<br />
Gateway<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
SW-C<br />
Description<br />
AUTOSAR<br />
SW-C<br />
n<br />
System Constraint<br />
Description<br />
ECU m<br />
AUTOSAR<br />
SW-C<br />
n<br />
RTE<br />
Basic Software<br />
Functional software is described formally in<br />
terms of “Software Components” (SW-C).<br />
Using “Software Component Descriptions“<br />
as input, the „Virtual Functional Bus“<br />
validates the interaction of all components<br />
and interfaces before software<br />
implementation.<br />
Mapping of “Software Components” to<br />
ECUs and configuration of basic software.<br />
The AUTOSAR Methodology supports<br />
the generation of an E/E architecture.<br />
page 53<br />
page 53 Dr. Thomas Scharnhorst May 2006
The AUTOSAR standard will be completed end of 2006. Development tools are<br />
expected to be available in time.<br />
30.9.2004<br />
Concept<br />
- Autosar concept<br />
finalized<br />
Specification of Templates, BSW and RTE<br />
30.5.2005<br />
Spec R1.0<br />
- Autosar BSW<br />
specifications for<br />
Release 1.0 are<br />
finalized<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Spec R2.0<br />
- Autosar BSW and<br />
RTE<br />
specifications for<br />
Release 2.0 are<br />
finalized<br />
Implementation<br />
and Integration<br />
Methodology<br />
- methodology and<br />
templates<br />
finalized<br />
page 54<br />
Actual timeline<br />
Update BSW and RTE Specifications<br />
via CCB<br />
Test & Validation<br />
15.12.2005 31.5.2006 15.12.2006<br />
Integration<br />
- BSW and RTE<br />
prototype<br />
implementations<br />
and integrations<br />
completed, test<br />
specification<br />
completed<br />
Validation<br />
- All documents<br />
formally released,<br />
specifications<br />
verified on an<br />
application<br />
demonstrator,<br />
proof of concept<br />
demonstrated<br />
2H 2004 1H 2005 2H 2005 1H 2006 2H 2006<br />
Phases<br />
Milestones<br />
t<br />
Status<br />
t<br />
page 54 Dr. Thomas Scharnhorst May 2006
Migrationsszenarien ermöglichen die parallele Verwendung von AUTOSAR-<br />
Modulen und bestehenden proprietären Komponenten.<br />
Today Transition period<br />
Future – AUTOSAR Life<br />
AUTOSAR-development<br />
OEM infrastructure<br />
Proprietary Basic<br />
Software Core<br />
MS<br />
Incorporation of all available<br />
AUTOSAR specifications<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
vehicle infrastructure decision<br />
AUTOSAR Standard<br />
Basic Software Core with<br />
partly proprietary solutions<br />
Implantation of components<br />
not available from AUTOSAR<br />
page 55<br />
AUTOSAR Standard<br />
Basic Software Core<br />
Time<br />
page 55 Dr. Thomas Scharnhorst May 2006
AUTOSAR enables the management of the growing E/E complexity with<br />
respect to quality, technology and economics. AUTOSAR facilitates the<br />
automotive industry to focus on customer needs.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Application Software<br />
Hardware<br />
Customer needs<br />
page 56<br />
• Adaptive Cruise Control<br />
• Lane Departure Warning<br />
• Advanced Frontlighting System<br />
• …<br />
Using standards<br />
page 56 Dr. Thomas Scharnhorst May 2006
Robustheit<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 57<br />
page 57 Dr. Thomas Scharnhorst May 2006
Anforderungen an robuste E/E Systeme<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 58<br />
page 58 Dr. Thomas Scharnhorst May 2006
Was ist Robustheit?<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 59<br />
page 59 Dr. Thomas Scharnhorst May 2006
Fehlerfreie (korrekte) und robuste Systeme sind zuverlässig.<br />
Zuverlässigkeit = Korrektheit + Robustheit *)<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 60<br />
Korrektheit ist das Maß für die<br />
Fehlerfreiheit der Umsetzung der<br />
Produktspezifikation.<br />
Robustheit ist das Maß für die<br />
korrekte Funktion eines Systems<br />
über die Produktspezifikation hinaus.<br />
*) u.a. nach Eiffel Software<br />
page 60 Dr. Thomas Scharnhorst May 2006
Ein Maß für die Robustheit ist der “Sicherheitsabstand” zwischen<br />
den spezifizierten Funktionsgrenzen und den tatsächlichen<br />
Fähigkeiten.<br />
Temp.<br />
max<br />
min<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Spezifikation<br />
min max<br />
page 61<br />
Fähigkeiten<br />
Spannung<br />
page 61 Dr. Thomas Scharnhorst May 2006
Robuste Systeme kehren auch außerhalb der Spezifikation in<br />
einem akzeptierten Bereich in einen sicheren, spezifizierten<br />
Zustand zurück.<br />
Zustand 2<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
“Fail<br />
Safe”<br />
Punkt<br />
2.<br />
1.<br />
Area of<br />
normal<br />
operation<br />
Ungültiger<br />
Betriebspunkt<br />
page 62<br />
1.<br />
Area of<br />
“acceptable<br />
distance” of<br />
normal<br />
operation<br />
2.<br />
Zustand 1<br />
page 62 Dr. Thomas Scharnhorst May 2006
Robustheit bezieht sich sowohl auf Umgebungsbedingungen,<br />
Fehler im System als auch auf Änderungen der Spezifikationen.<br />
Fertigungsprozess /<br />
Einbau<br />
Umwelteinflüsse<br />
Änderung der<br />
Spezifikationen<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Konstruktionsfehler /<br />
Auslegungsfehler<br />
Robuste Systeme<br />
Anwenderverhalten<br />
page 63<br />
Softwarefehler<br />
Toleranzen<br />
Fehlverhalten von<br />
Komponenten<br />
page 63 Dr. Thomas Scharnhorst May 2006
Robustheitsanforderungen existieren bereits heute.<br />
Beispiel: Auszug aus der VW Prüfbedingungen für elektrische und elektronische Baugruppen<br />
Voller Funktionsbereich<br />
Unterspannung Überspannung<br />
Sicherheitsrelevante Funktionen, die erhalten<br />
bleiben müssen, werden im LH spezifiziert<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Sicherstellen aller für den Fahrbetrieb<br />
nötigen Funktionen<br />
page 64<br />
Langzeitüberspannung<br />
U<br />
page 64 Dr. Thomas Scharnhorst May 2006
In der frühen Designphase erfolgt bereits die Weichenstellung für<br />
die Robustheit des E/E Systems.<br />
Architektur<br />
Standards /<br />
Wiederverwendung<br />
Fehlertoleranz /<br />
Reduzierung der Komplexität<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Robustes<br />
Design<br />
Schnittstellen<br />
page 65<br />
Energiemanagement<br />
Diagnose<br />
page 65 Dr. Thomas Scharnhorst May 2006
Netzwerkarchitektur und -management tragen wesentlich zur<br />
Robustheit der Kommunikation bei.<br />
Architektur<br />
Standards /<br />
Wiederverwendung<br />
Fehlertoleranz /<br />
Reduzierung der Komplexität<br />
Robustes<br />
Design<br />
Schnittstellen<br />
Energiemanagement<br />
Diagnose<br />
Zentrales Gateway<br />
- Selektives Wecken / synchrones Schlafen von Bussen<br />
- Optionaler Busguardian überwacht/protokolliert die Buskommunikation<br />
Busauslastung<br />
- zentrale Einheiten, Subbusse<br />
- Kontrolle der Busauslastung, intelligente ID Vergabe<br />
Standards / Reduzierung Komplexität<br />
- Einsatz busunabhängiges AUTOSAR Netzwerkmanagement<br />
- Einsatz ISO Transportprotokoll<br />
Diagnose<br />
Physikalische Trennung des Diagnose-Zugangs<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 66<br />
page 66 Dr. Thomas Scharnhorst May 2006
Ein fehlertolerantes Auswerten von Botschaften und eine<br />
Reduzierung von Weckereignissen erhöhen die Robustheit.<br />
Architektur<br />
Standards /<br />
Wiederverwendung<br />
Fehlertoleranz /<br />
Reduzierung der Komplexität<br />
Robustes<br />
Design<br />
Schnittstellen<br />
Energiemanagement<br />
Diagnose<br />
Fehlertoleranz<br />
Fehlertolerantes Auswerten von Botschaften<br />
Weckereignisse<br />
- Reduzierung oder lokale Begrenzung von Weckereignisse<br />
- ggf. Einsatz externer Wake-Up Leitungen<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 67<br />
page 67 Dr. Thomas Scharnhorst May 2006
Conclusion<br />
1<br />
2<br />
3<br />
4<br />
5<br />
Fast growth of the complexity of E/E architectures is a major challenge<br />
with respect to product quality for aviation and automotive electronics.<br />
Through interconnection of subsystems, new system properties emerge<br />
which have to be understood and controlled.<br />
Systems Engineering is an integrated approach which covers the<br />
development process and the complete product life cycle.<br />
AUTOSAR enables management of the growing E/E complexity with respect<br />
to technology and economics.<br />
AUTOSAR pushes the paradigm shift from an ECU based to a function<br />
based approach in automotive software development.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 68<br />
page 68 Dr. Thomas Scharnhorst May 2006
Thank you for your attention!<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 69<br />
page 69 Dr. Gabriel Thomas Schwab Scharnhorst March May 2006
Thank you for your attention!<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 70<br />
http://www.autosar.org<br />
request@autosar.org<br />
page 70 Dr. Gabriel Thomas Schwab Scharnhorst March May 2006
Backup<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 71<br />
page 71 Dr. Thomas Scharnhorst May 2006
The automotive industry is driven by innovations and high cost effectiveness<br />
in short lifecycles.<br />
Lifecycle<br />
approx. 18 years<br />
Many OEMs and<br />
Tier 1<br />
Large number of<br />
units/Lifecycle<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
High priority on<br />
innovations<br />
Various<br />
changes during<br />
development<br />
page 72<br />
Safety critical<br />
systems under<br />
development<br />
(x-by-wire)<br />
Processes and<br />
guidelines are<br />
used<br />
Focus on cost<br />
effectiveness<br />
page 72 Dr. Thomas Scharnhorst May 2006
The avionic industry is driven by innovations and safety in long lifecycles.<br />
Lifecycle<br />
approx. 60 years<br />
*)<br />
High cabin<br />
functionality<br />
Small number of<br />
units/Lifecycle<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Highest priority<br />
on passenger<br />
safety<br />
Only necessary<br />
changes during<br />
development<br />
page 73<br />
Various safety<br />
critical systems<br />
Stringent<br />
processes are<br />
established<br />
Focus on<br />
reliability<br />
*) Source: Xcc Software AG<br />
page 73 Dr. Thomas Scharnhorst May 2006
Different general characteristics and expertise in both industries enable<br />
bidirectional knowledge transfer.<br />
� Substitution of knowledge feasible<br />
…<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
Highest priority<br />
on passenger<br />
safety<br />
Only necessary<br />
changes during<br />
development<br />
page 74<br />
Various safety<br />
critical systems<br />
� Due to the different characteristics no one-to-one transfer applicable<br />
Lifecycle<br />
approx. 60 years<br />
Small number of<br />
units/Lifecycle<br />
Stringent<br />
processes are<br />
established<br />
Focus on<br />
reliability<br />
page 74 Dr. Thomas Scharnhorst May 2006
Common solutions to manage the growing complexity are applicable.<br />
Standardization<br />
Systems Engineering<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 75<br />
Standardized processes<br />
and commercial tools<br />
Reuse of Hard- and Software<br />
Increased use of<br />
“Commercial off<br />
the shelf” hardware<br />
page 75 Dr. Thomas Scharnhorst May 2006
Conclusion 1/2<br />
1<br />
2<br />
3<br />
4<br />
5<br />
Fast growth of the complexity of E/E architectures is a major challenge<br />
with respect to product quality for automotive electronics.<br />
Systems Engineering is an integrated approach which covers the<br />
development process and the complete product life cycle.<br />
The function based approach is the basis for high quality component<br />
requirement specifications at an early stage of the development process.<br />
Reuse scales down significantly the effort on creating functional<br />
requirement specifications and behavior models.<br />
AUTOSAR enables management of the growing E/E complexity with respect<br />
to technology and economics.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 76<br />
page 76 Dr. Thomas Scharnhorst May 2006
Conclusion 2/2<br />
6<br />
7<br />
8<br />
9<br />
AUTOSAR pushes the paradigm shift from an ECU based to a function<br />
based approach in automotive software development.<br />
Volkswagen has committed to use the AUTOSAR specifications/concept to<br />
develop future automotive software.<br />
A seamless tool chain starting at the modeling phase until code is<br />
generated needs to be in place to support the development process.<br />
VW’s modeling principles are a prerequisite to generate optimized code.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 77<br />
page 77 Dr. Thomas Scharnhorst May 2006
Nach der AUTOSAR Methode wird die Elektronik-Architektur aus der formalen<br />
Beschreibung von Software- und Hardware-Komponenten abgeleitet.<br />
Mit dem „Virtual Functional Bus“ wird<br />
anhand von „Software Component<br />
Descriptions“ plausibilisiert , ob das<br />
Zusammenspiel aller Komponenten und<br />
Schnittstellen funktionieren kann, bevor<br />
die Software implementiert wird.<br />
Die AUTOSAR-Methode erleichtert die<br />
Generierung einer Elektronik-Architektur.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 78<br />
page 78 Dr. Thomas Scharnhorst May 2006
Migrationsszenarien ermöglichen die parallele Verwendung von AUTOSAR-<br />
Modulen und bestehenden proprietären Komponenten.<br />
Heute Übergangszeit<br />
Zukunft – AUTOSAR Life<br />
AUTOSAR-Entwicklung<br />
MS 1<br />
OEM Infrastruktur<br />
Verwendung der verfügbaren<br />
AUTOSAR-Spezifikationen<br />
Proprietärer Basic SW Core<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
MS 2<br />
MS 2’<br />
Einbau der in AUTOSAR<br />
noch nicht verfügbaren<br />
Komponenten<br />
page 79<br />
Teilweise proprietäre Lösung<br />
page 79 Dr. Thomas Scharnhorst May 2006
Mit der Wiederverwendung bewährter Softwarekomponenten<br />
nehmen Korrektheit und Robustheit zu.<br />
Architektur<br />
Standards /<br />
Wiederverwendung<br />
Fehlertoleranz /<br />
Reduzierung der Komplexität<br />
Robustes<br />
Design<br />
Schnittstellen<br />
Energiemanagement<br />
Diagnose<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
bisher AUTOSAR<br />
Software<br />
Hardware<br />
page 80<br />
Funktions-Software<br />
standardisiert<br />
AUTOSAR<br />
HW-spezifisch<br />
Hardware<br />
Hardware und Software werden weitgehend voneinander unabhängig<br />
Entwicklungsprozesse werden vereinfacht. Dadurch sinken<br />
Entwicklungszeit und –kosten.<br />
Die Wiederverwendung von Software steigt, sowohl beim OEM,<br />
als auch beim Zulieferer.<br />
page 80 Dr. Thomas Scharnhorst May 2006
Fazit<br />
1<br />
2<br />
3<br />
4<br />
5<br />
Die rasch wachsende Komplexität der Automotive E/E-Architektur stellt<br />
unter Qualitätsgesichtspunkten eine Herausforderung dar.<br />
Die Vernetzung vieler Subsysteme erzeugt neue Eigenschaften des<br />
Systems, die beherrscht werden müssen.<br />
Systems Engineering ist ein ganzheitlicher Ansatz, der neben der<br />
Entwicklungsphase den gesamten Produktlebenszyklus umfasst.<br />
AUTOSAR trägt wesentlich zur Beherrschung der zunehmenden E/E-<br />
Komplexität in technischer und wirtschaftlicher Hinsicht bei.<br />
AUTOSAR forciert den Paradigmenwechsel von einem Steuergerätehin<br />
zu einem Funktions-orientierten Entwicklungsprozess.<br />
ELEKTRIK<br />
ELEKTRIK<br />
/ /<br />
ELEKTRONIK<br />
ELEKTRONIK<br />
ENTWICKLUNG<br />
ENTWICKLUNG<br />
page 81<br />
page 81 Dr. Thomas Scharnhorst May 2006
Change language