Embed Size (px)
Citation preview
1
Simulation und Evaluation von Echtzeit-Ethernet inFahrzeugnetzen
Till SteinbachHochschule für Angewandte WissenschaftenHamburgBerliner Tor 720099 [email protected] Steinbach ist wissenschaftlicher Mitarbeiter ander Hochschule für Angewandte Wissenschaften(HAW) Hamburg, wo er zuvor Informatik studierte.Anfang 2011 schloss er seine Masterarbeit zur Simu-
lation von Echtzeit-Ethernet basierten Fahrzeugnetzen ab, für die er mit demHermann-Appel-Preis in der Kategorie Elektronikentwicklung ausgezeichnetwurde. Er ist Mitgründer der Arbeitsgruppe Communication over Real-timeEthernet (CoRE). Seine Interessen liegen im Bereich der Echtzeitkommuni-kation und dem Design und der Analyse von neuen Kommunikationstechno-logien, Netzwerkprotokollen und Architekturen für Fahrzeugnetze.
Franz KorfHochschule für Angewandte WissenschaftenHamburgBerliner Tor 720099 [email protected]. Dr.-Ing. Franz Korf leitet die ArbeitsgruppeCommunication over Real-time Ethernet (CoRE)an der Hochschule für Angewandte Wissenschaften(HAW) Hamburg. Nach dem Studium der Informatik
an der RWTH Aachen promovierte er in den Gebieten High Level Syn-thesetechniken und formale Verifikationstechniken bei Prof. Dr. W. Damm.Nach einer 10-jährigen Tätigkeit in der Industrie, wo er unterschiedlicheAufgaben im Bereich der Entwicklung innovativer Server-Architekturen undOEM Entwicklung verantwortete, wechselte er an die HAW Hamburg. Dortliegt sein Schwerpunkt im Bereich eingebetteter Echtzeitsysteme.
Thomas C. SchmidtHochschule für Angewandte WissenschaftenHamburgBerliner Tor 720099 [email protected]. Dr. Thomas C. Schmidt leitet die Arbeitsgrup-pe Internet Technologies (INET) an der Hochschulefür Angewandte Wissenschaften (HAW) Hamburg.Er studierte Mathematik, Physik und Germanistik an
der Freien Universität Berlin, der University of Maryland und der TechnischenUniversität Berlin. 1993 promovierte er zur Quantendynamik von Vielteilchen-systemen bei Prof. Dr. D.H.E. Groß. Seine Forschungsschwerpunkte umfas-sen derzeit das Internet der nächsten Generation, mobile und multimedialeKommunikation, P2P-Netze sowie Hypermedia-Systeme. Thomas Schmidtbeteiligt sich aktiv an der Internet-Standardisierung und ist Co-Chair der SAMResearch Group.
Zusammenfassung—Die Zunahme von elektronischen Syste-men insbesondere im Fahrerassistenz- und Komfortbereich derFahrzeuge drängt die etablierten Automotive-Kommunikations-technologien an die Grenze ihrer Leistungsfähigkeit. Ein neu-er Ansatz für die Kommunikation zwischen Steuergeräten istEthernet im Automobil. Echtzeiterweiterungen haben den Ein-satzbereich von Standard-Switched-Ethernet auf zeitkritischeAnwendungen ausgedehnt.Diese Arbeit stellt eine simulationsbasierte Evaluationsstrategiefür Echtzeit-Ethernet-basierte Vermittlungsinfrastrukturen imFahrzeug vor. Wir führen eine gründliche Analyse des zu-grundeliegenden Simulationsmodells durch, welche die Simula-tionsergebnisse mit Berechnungen eines mathematischen Modellsund Messungen auf echter Hardware vergleicht. Sehr präziseÜbereinstimmungen belegen die Gültigkeit der Implementierungund der mit ihr ermittelten Kenngrößen.
I. EINFÜHRUNG & MOTIVATION
In einem modernen Kraftfahrzeug wird der Fahrer von einerVielzahl an Fahrerassistenzsystemen unterstützt. Mit bis zu70 Steuergeräten in Oberklassemodellen sind heutige Fahr-zeuge komplexe verteilte Echtzeitsysteme, deren Kommuni-kationsflüsse zwischen den verteilten Modulen einen signifi-kanten Einfluss auf ihre Zuverlässigkeit, die Sicherheit undden Komfort der Insassen haben. Durch die Zunahme vonelektronischen Systemen im Automobil sind auch die Anfor-derungen an leistungsfähige Kommunikationskanäle zwischenden einzelnen Steuergeräten gestiegen. Dieser Anstieg wirdsich auch in den kommenden Jahren, insbesondere durchkamerabasierte Assistenzsysteme, unvermindert fortsetzen. Eswerden neue Entwürfe benötigt, welche diesen zunehmendenAnforderungen gerecht werden können.
Auch die Heterogenität und Komplexität der Datenübertra-gung in aktuellen Serienfahrzeugen erfordert die Weiterent-wicklung des Fahrzeugnetzwerkes. Je nach Anwendung undDatenbedarf kommen spezialisierte Bussysteme zum Einsatz.Eine Kommunikation zwischen den verschiedenen Technolo-gien wird durch Gateways ermöglicht, welche die Nachrichtenzwischen den verschiedenen Systemen übersetzen. Die hierausentstehende heterogene Struktur macht das Fahrzeugnetzwerkkompliziert und dadurch insbesondere in der Entwicklungteuer. Anzustreben ist eine neue Technologie, die sich weit-gehend durchgängig im gesamten Fahrzeug einsetzen lässt.Solch ein neuer Architekturansatz für die Kommunikation imAutomotive-Bereich basiert auf einem sogenannten Backbone-Netzwerk, einer intelligenten Vermittlungsinfrastruktur, welchedie verteilten Steuergeräte des Fahrzeugs strukturiert verbin-det. Dieser zentrale Fahrzeug-Backbone muss nicht nur starkerLast gewachsen sein, sondern dabei auch eine deterministischeNachrichtenübertragung garantieren können.
Die in Computernetzen etablierte Ethernet-Technologie bil-det zunächst einen Ansatz zur skalierbaren, strukturiertenVernetzung. Der Ethernet-Basisstandard kann jedoch nicht die
2
für eine Echtzeitkommunikation im Fahrzeug erforderlicheVorhersagbarkeit und Zuverlässigkeit in der Paketweiterleitungund dem Medienzugriff garantieren. Echtzeiterweiterungenvon Standard-Ethernet versprechen zuverlässige, isochroneÜbertragungseigenschaften und haben im Bereich der Prozes-sautomatisierung bereits umfangreichen Einsatz in Produktiv-systemen gefunden. Time-Triggered Ethernet (TTEthernet) [1]ist eine solche Echtzeiterweiterung, welche insbesondere diespeziellen Bedürfnisse der Fahrzeugkommunikation adressiert.In TTEthernet werden alle sendenden Echtzeitteilnehmer überein ausfallgesichertes Protokoll synchronisiert und operierenanschliessend nach einem vordefinierten gemeinsamen Zeit-plan, der das simultane Senden zweier Echtzeitnachrichtenüber dieselbe physikalische Verbindung ausschließt. Damiterweitert TTEthernet das Standard-Ethernet-Protokoll um dieFähigkeit, zeitkritische Daten deterministisch zu transportie-ren.
Vorarbeiten [2] haben gezeigt, dass TTEthernet eine er-folgversprechende Technologie für eine zukünftige intelligenteVermittlungsinfrastruktur in Fahrzeugen ist. Es greift Konzepteaus verschiedenen in Flug- und Fahrzeugen bewährten Proto-kollen wie FlexRay, TTP oder AFDX auf und integriert diesein einer physikalisch geteilten Infrastruktur.
Diese Arbeit stellt eine simulationsbasierte Evaluierungs-strategie für TTEthernet im Fahrzeug vor. Relevante Metrikenwerden identifiziert, an ausgewählten Fahrzeugszenarien eva-luiert und sorgfältig verifiziert. Als Ergebnis dieses Prozesseserhält der Anwender automatisiert einen Analysebericht überdie vermessenen Metriken und ihre Konformität mit denAnforderungen. Durch eine präzise Abbildung der zeitlichenEigenschaften im Simulationsmodell können die Ergebnissedirekt auf ein mit demselben Netzwerkmodell konfiguriertesreales Netzwerk übertragen werden.
Der Beitrag gliedert sich wie folgt: Im Abschnitt II wird derHintergrund sowie die vergleichbaren und verwandten Arbei-ten vorgestellt. Das Konzept der simulationsbasierten Evaluie-rung und die Architektur der Plattform wird in Abschnitt IIIgezeigt. Abschließend werden in Abschnitt IV Ergebnisse derEvaluierung vorgestellt sowie ein zusammenfassendes Fazitmit dem Ausblick auf weitere Ziele in Abschnitt V gegeben.
II. HINTERGRUND & VERWANDTE ARBEITEN
Fahrzeugnetzwerke sind wohldefinierte, geschlossene Sys-teme. In der Regel werden Komponenten nicht spontan indas System eingefügt oder entfernt, so dass Kommunikations-und Zeitverhalten weitgehend im voraus berechenbar sind. DasSystem kann statisch konfiguriert werden und muss sich nichtan veränderliche Topologien oder variierende Teilnehmerzah-len anpassen, wie es etwa in lokalen (LAN) oder Weitverkehrs-Computer-Netzwerken (WAN) erforderlich ist.
Echtzeitanwendungen im Automobil haben hohe Anforde-rungen an das Zeitverhalten der Datenübertragung zwischenden Steuergeräten. Die Güte von Regelungssystemen wiebeispielsweise der Antriebsschlupfregelung (ASR) hängt vomZeitverhalten der Datenübertragung, insbesondere der Nach-richtenlaufzeit (Latenz) und der Varianz der Nachrichtenlauf-zeit (Jitter) ab, denn sie hat wesentlichen Einfluss auf die
Totzeit der verteilten Regelung. Je länger die Totzeit ist, destoschlechter wird das Regelverhalten. Dies kann soweit führen,dass die Regelung unbrauchbar wird.
Zur Zeit ist das Datenübertragungsnetz in Serienfahrzeugenheterogen aufgebaut. Je nach Anwendung und zu übertra-genden Daten kommen spezielle Bussysteme zum Einsatz[3]. Gängige Technologien sind der LIN-Bus, der CAN-Bus,FlexRay und der MOST-Bus.
A. Die Echtzeit-Ethernet-Technologie
Grundsätzlich lassen sich die am Markt befindlichenEthernet-Technologien in die drei Hauptfelder time-triggeredSysteme, Token-basierte Systeme und bandbreitenbasierteSysteme einordnen, da sie jeweils die wichtigsten Eigenschaf-ten vereinen.
Time-triggered (zeitgesteuerte) Protokolle arbeiten synchronund zyklisch. Sie sind ein verbreiteter Ansatz, um Echtzeit-fähigkeit auf Kommunikationssystemen herzustellen. Dabeisynchronisieren sie sich über eine globale Zeit. Jeder Teil-nehmer hat eine lokale Uhr, welche möglichst genau mit denUhren der anderen Teilnehmer synchronisiert werden muss.Zugewiesene Zeitschlitze definieren für jeden Teilnehmer,wann er das Medium zum Senden nutzen darf. Damit istsichergestellt, dass immer nur ein Teilnehmer zur Zeit aufdas Medium zugreift. Diese Technik wird auch als koor-diniertes Time-Division-Multiple-Access (TDMA) bezeichnet.Diverse Echtzeit-Ethernet-Produkte, darunter auch TTEthernetbasieren auf dem time-triggered Konzept.
Die Grundlage von Token-basierten Systemen ist der wech-selseitige Ausschluss mit Hilfe einer zwischen allen Teilneh-mern geteilten Ressource, dem Token. Das Token wandertvon Teilnehmer zu Teilnehmer, wobei nur derjenige sendendarf, der das Token hält. Damit ist sichergestellt, dass dasMedium stets frei ist, wenn Daten gesendet werden. In derProzessautomatisierung wird das Token-basierte EtherCAT-Protokoll eingesetzt.
Bandbreitenbasierte Systeme arbeiten ohne eine Form derSynchronisierung. Es werden virtuelle Bandbreitenkontingen-te konfiguriert. Jeder Teilnehmer sendet in einem solchenKontingent. Da keine Synchronisierung stattfindet, ist in Sys-temen mit Bandbreitenkontingenten die berechnete längsteVerzögerungszeit und damit auch der Jitter weit höher als imRegelfall zu beobachten. Dies hängt damit zusammen, dassim worst-case alle Teilnehmer zur gleichen Zeit ihre Nach-richten versenden. Das AFDX-Protokoll [4] ist ein typischesbandbreitenbasiertes Protokoll.
B. Time-triggered Ethernet
TTEthernet wird von der Firma TTTech entwickelt. DieStandardisierung der TTEthernet-Spezifikation [1] durch dieSociety of Automotive Engineers (SAE) wird momentan ab-geschlossen [5]. TTEthernet basiert auf Standard-Switched-Ethernet, wobei die Topologie aus full-duplex Punkt-zu-PunktLinks zusammengesetzt wird.
TTEthernet definiert drei Nachrichtenklassen: Für die time-triggered Kommunikation weisen offline konfigurierte Schedu-les jedem Teilnehmer definierte Zeitschlitze je Link zu. Die-
3
TTE-Switch
Diagnose
Fahrwerk
LIN-GatewayTür
BE BE BE0 t
RC0 t
TTTT RC BE BE BE
TTTT
Zyklus0
t
TT Time-Triggered NachrichtRC
BE
Rate-Constrained NachrichtBest-Effort Nachricht
TTE-Switch
LIN-BUS
Zyklus0
t
Abbildung 1. TTEthernet-Beispielanwendung — Fahrzeugkommunikationmit drei unterschiedlichen Verkehrsklassen
ses Netzwerk-Zugriffsverfahren erlaubt vorhersagbare Über-tragungszeiten in definierten Grenzen ohne Warteschlangenbil-dung in den Switches und damit Kommunikation mit niedrigerLatenz und geringem Jitter. Ein fehlergesichertes Synchroni-sierungsprotokoll implementiert die globale Zeit.
Neben den time-triggered Nachrichten definiert TTEthernetnoch zwei weitere Nachrichtenarten. Rate-constrained Nach-richten sind für die Übertragung von Daten mit weniger hartenZeitanforderungen bestimmt und basieren auf dem AFDX-Protokoll [4]. Best-effort Nachrichten basieren auf Standard-Ethernet und haben in der Übertragung die niedrigste Priorität.Eine Fähigkeit von TTEthernet-Netzwerken ist dadurch, Teil-nehmer zu integrieren, die das time-triggered Protokoll nichtunterstützen. Diese Teilnehmer bleiben unsynchronisiert undkommunizieren ausschließlich über best-effort Nachrichten.
Abbildung 1 visualisiert eine Beispiel-Anwendung aus demAutomotive-Umfeld, in der die drei Nachrichtenarten aufdemselben physikalischen Link koexistieren. Während time-triggered Nachrichten — beispielsweise für die Übertragungvon Fahrwerksinformationen — unter strikter Einhaltung desÜbertragungszyklus und mit der höchsten Priorität weitergelei-tet werden, werden rate-constrained Pakete in freien Zeitschlit-zen übertragen. Die darüber hinaus noch freie Bandbreite wirdfür die Übertragung von best-effort Datenverkehr verwendet.
C. Vorarbeiten, verwandte und vergleichbare ArbeitenIn Vorarbeiten wurde für einen Vergleich zwischen TTEther-
net und FlexRay auf Basis analytischer Methoden bereitsein mathematisches Modell für die TTEthernet-Technologieerstellt [2]. Dieses Modell wurde in dieser Arbeit insbesonderefür die Validierung der Simulationsergebnisse herangezogen.
Der Einsatz von neuen Vermittlungsinfrastrukturen in Kraft-fahrzeugen wird durch verschiedene Institutionen untersucht.Insbesondere ist die BMW-Group zu erwähnen, welche imJahre 2007 als technische Demonstration einen IP-basiertenFahrzeug-Prototyp vorstellte und den Einsatz von Ethernet fürAnwendungen im Fahrzeug anstrebt. Insbesondere in Zusam-menarbeit zwischen der Technischen Universität München undBMW (CAR@TUM) entstanden verschiedene Forschungs-projekte und Veröffentlichungen zu Grundlagenthemen wiedem Design von vereinheitlichten Kommunikationsinfrastruk-turen [6], [7], der Abbildung von Kommunikationsstrukturenaktueller Fahrzeuge auf Ethernet-basierte Vermittlungsinfra-strukturen [8] oder der Koexistenz von Verkehrsklassen mit
Evaluierungsprozess
Einrichtungsphase Simulationsphase Auswertungsphase
Simulations-Konfiguration
Simulations-ergebnis
Netzwerk-modell
Reales Netzwerk
Anforderungen
AnalyseberichtFahrzeug-modell
Abbildung 2. Überblick über die Phasen des Evaluierungsprozesses undseine Ein- und Ausgabegrößen
verschiedenen Eigenschaften in switched Netzwerken [9]. DieArbeiten basieren fast ausschließlich auf Standard-Ethernetund grenzen sich damit von dieser Arbeit ab.
Nach aktuellem Kenntnisstand sind keine vollständi-gen Implementationen von time-triggered Echtzeit-Ethernet-Erweiterungen für OMNeT++ öffentlich verfügbar. Für andereSimulationswerkzeuge wie den OPNET-Modeler gibt es Mo-delle für Protokolle aus der Anlagensteuerung [10], [11]. Dadie Protokolle jedoch von TTEthernet abweichen, sind dieseModelle nicht als Vorlage für ein Simulationsmodell geeignet.
III. KONZEPT, ARCHITEKTUR & IMPLEMENTIERUNG
Da das analytische Modell [2] nur mit großem Aufwand denbenötigten Detailgrad liefert, wurde ein simulationsbasierterEvaluierungsprozess entwickelt.
Abbildung 2 zeigt die Struktur des Evaluierungsprozesses,sowie die Ein- und Ausgangsgrößen. Die Simulation wirddurch eine Netzwerkkonfiguration gespeist, die zuvor manuelloder mit Werkzeugunterstützung aus dem Fahrzeugmodellerstellt wurde. Zusätzlich definieren die Anwendungen diesesModells die Anforderungen an die Vermittlungsinfrastruktur,die in der Evaluierung analysiert werden.
Der Evaluierungsprozess selbst ist in drei Phasen unterteilt.Zunächst wird die Simulation auf Basis der Netzwerkkonfigu-ration und Anwendungsanforderungen definiert. Anschließendwird in der Simulationsphase das abgeleitete Modell in derSimulationsumgebung vermessen und dokumentiert. Abschlie-ßend werden die Ergebnisse in der Auswertungsphase mit denzuvor erstellten Anforderungen verglichen und bewertet. DieseInformation hilft dem Nutzer, in einem iterativen Vorgehendie Konfiguration anzupassen, bis sie alle Vorgaben erfüllt.Als Ergebnis erhält der Nutzer eine Übersicht über alle fürihn relevanten Metriken zusammen mit einer Netzwerkkonfi-guration, welche direkt in vorhandene Hardware eingespieltwerden kann.
Die Basis für den Evaluierungsprozess ist eine Netzwerk-konfiguration im Format von TTEthernet. Diese XML-Dateienthält bereits die wichtigsten Informationen für die Simulati-on und wird vom Evaluierungs-Framework eingelesen und indas Format der Simulationsumgebung übersetzt. Als weitereEingabe in den Evaluierungsprozess wird eine formale Be-schreibung der Datenflüsse und ihrer Anforderungen definiert.Diese Beschreibung ist notwendig, um in der Simulation fürdie spätere Anwendung charakteristische Datenflüsse zu gene-rieren und ein gutes Simulationsergebnis, welches die späterenrealen Eigenschaften wiedergibt, zu erzielen. Im nächstenSchritt werden die globalen Parameter der Simulation, bei-
4
TTEthernet Anwendung
TTEthernet API
TTEthernet LLCTTE-Protokoll
MAC
Physical Link Physical Link
MAC
TTEthernetMAC Relay Unit
TTEthernet Anwendung
TTEthernet API
TTEthernet LLCTTE-Protokoll
MAC
Physical Link
INET-ModellTTEthernet-Modell
Anwendungs Ebene
Daten/Link Ebene
Physikalische Ebene
TTE Host A TTE Host BTTE Switch
erweitertes INET-Modell
Abbildung 3. TTEthernet-Integration in das INET-Framework
spielsweise die Simulationsdauer oder die zeitliche Auflösung,festgelegt. Anschließend wird die Simulation durchgeführt.
Im letzten Schritt generiert das System einen Bericht überdie simulierten Metriken. Als Eingabe dient hier, neben denErgebnissen der Simulation, die Beschreibung der Datenflüsseund Anforderungen. Erfüllt die Konfiguration alle Anforde-rungen, kann der Nutzer auf Basis des Berichtes entscheiden,ob die evaluierte Konfiguration in dieser Form eingesetztwerden soll. Werden Anforderungen nicht erfüllt, muss dieKonfiguration angepasst und erneut evaluiert werden. DieEvaluierung unterstützt den Nutzer nun so lange in einemzyklischen Prozess, bis das gewünschte Ergebnis erzielt wird.
A. Elemente des Simulationsmodells
Die Simulation setzt sich aus drei Schichten zusammen. DieBasis bildet die OMNeT++-Simulationsumgebung. Darauf ba-sierend wird das INET-Framework eingesetzt. Da TTEthernetStandard-Ethernet erweitert, wird durch Vererbung im daraufaufbauenden Simulationsmodell die grundlegende Netzwerk-funktionalität vom physikalischen und Link-Layer aus demINET-Framework abgeleitet.
Auf Basis des INET-Frameworks wird die TTEthernet-Simulationsschicht [12] implementiert. Sie erweitert das Mo-dell um die Echtzeiteigenschaften des TTEthernet-Protokolls.Dabei muss besonders auf eine präzise Abbildung des Zeit-verhaltens geachtet werden. Nur so lassen sich die Ergebnisseder Simulation zuverlässig auf ein echtes Szenario übertragen.
Abbildung 3 zeigt die wichtigsten Komponenten desTTEthernet-Modells und ihre Integration in die Schichten derSimulationsplattform. Dadurch, dass TTEthernet auf Standard-Ethernet basiert, müssen ausschließlich Komponenten desINET-Frameworks oberhalb der MAC-Ebene erweitert oderangepasst werden. Für das Modell des Ethernet-Hosts wirdder Protokollstack in einer Erweiterung des Ethernet-LLCimplementiert. Darüber liegen die TTEthernet-API und dieAnwendungen in neuen Modulen. Für den TTEthernet-Switchkann die Protokoll-Implementierung direkt als Erweiterung derMACRelayUnit aus dem INET-Framework umgesetzt werden.
B. Uhrenmodell
Die global synchronisierte Zeit und das Scheduling vonjeder Komponente sind die wichtigsten Unterschiede vonTTEthernet gegenüber Standard-Ethernet. Daher benötigt jederTeilnehmer des Netzwerks ein eigenes Uhrenmodell, das überein fehlergesichertes Synchronisationsprotokoll mit den Uhrender anderen Teilnehmer synchronisiert wird. Die kleinste Ein-heit der Uhr in TTEthernet ist ein Tick. Dabei ist die Längedes Ticks konfigurierbar.
Bei der Modellierung der Uhr muss beachtet werden, dassjeder Oszillator eine gewisse Ungenauigkeit besitzt, welcheals Clock-Drift bezeichnet wird. Diese Clock-Drift hat signifi-kanten Einfluss auf das Verhalten des Protokolls und mussdaher überlegt in das Uhrenmodell integriert werden. AusLeistungsgründen kann die Clock-Drift nicht dadurch model-liert werden, dass jeder Tick als separates Ereignis simuliertwird. Stattdessen werden die Ticks zwischen zwei Ereignissenzusammengefasst. Dabei wird ein Clock-Drift-Faktor einge-führt, welcher die Ungenauigkeit der Uhr nachbildet. DieserFaktor wird für dieses Intervall als konstant angenommen. DieGleichung 1 zeigt die Formel für die Berechnung des aktuellenWertes der Uhr.
t′ = t+ δ · (∆tTick + ∆tDrift) (1)
Dabei ist t′ die Zeit für das nächste geplante Ereignis, t istdie aktuelle Simulationszeit, δ ist die Anzahl von Ticks imSchedule für das nächste Ereignis, ∆tTick ist die konfigurier-bare Zeit eines Ticks und ∆tDrift ist die für das aktuelleIntervall berechnete Clock-Drift. Dieses Modell der Uhrenist eine zulässige und ausreichend genaue Vereinfachung desVerhaltens von realen Uhren, da während eines Zyklus dieVarianz der Clock-Drift in der Realität nur gering ist.
C. Switchmodell
Der TTEthernet-Switch kombiniert ein Standard-Switched-Ethernet-Gerät für die Weiterleitung von best-effort Daten miteinem Modul, welches das Synchronisierungsprotokoll unddas Weiterleiten von zeitkritischen Daten (time-triggered undrate-constrained) unterstützt.
Für die Implementierung des TTEthernet-Switches wird dasMACRelayUnit Interface aus dem INET-Framework imple-mentiert. Die Logik für die Weiterleitung des zeitkritischenDatenverkehrs verwendet das beschriebene Uhrenmodell (sie-he Abschnitt III-B).
Wie durch die TTEthernet-Spezifikation vorgegeben, wer-den ankommende Pakete anhand ihrer Zieladresse klassifiziertund dann, basierend auf ihrer Nachrichtenart, weitergeleitetoder bearbeitet: Synchronisationsnachrichten werden überprüftund an das Synchronisationsmodul des Gerätes weitergeleitet.Time-triggered Nachrichten werden in einem Puffer bis zuihrem geplanten Weiterleitungszeitpunkt zwischengespeichertund dann abgesendet. Rate-constrained Nachrichten werden,sofern keine time-triggered Kommunikation ansteht, sofortweitergeleitet. Best-effort Nachrichten werden in der übrigenZeit weitergeleitet.
Direkt nach dem Empfang eines Ethernet-Frames überprüftder TTEthernet-Switch die Nachricht auf Konformität mit
5
1 ; 1 0 2 ; 2 0 3 ; 3 0 4 ; 4 0 5 ; 5 0 6 ; 6 0 7 ; 7 00
2 0
4 0
6 0
8 0
1 0 0
1 2 0
1 4 0
T e i l n e h m e r [ # S w i t c h e ; # E n d s y s t e m e ]
CPU-
Zeit [
s]
01 0 0 0 0 02 0 0 0 0 03 0 0 0 0 04 0 0 0 0 05 0 0 0 0 06 0 0 0 0 07 0 0 0 0 08 0 0 0 0 0
Virtual Memory [kB]
Abbildung 4. Lineares Skalierungsverhalten des Simulationsmodells beiabstrakten Topologien verschiedener Größe
den vorkonfigurierten Regeln. Für zeitkritischen Datenverkehrsind die Konformitätsüberprüfungen in der Critical-Traffic-Configuration (CTC)-Tabelle abgelegt. Der Switch kann unteranderem überprüfen, ob die Nachricht auf dem richtigen Portund zum korrekten Zeitpunkt angekommen ist. Während fürrate-constrained Nachrichten die Einhaltung des BandwidthAllocation Gap (BAG) überprüft wird, ist für time-triggeredDaten zu prüfen, ob die Nachricht zur geplanten Zeit eintraf.Diese Analyse ist wichtig, um das System vor der Störungdurch fehlerhafte oder bösartige Sender zu schützen.
D. HostmodellFür die Simulation von TTEthernet-Endsystemen muss
der Standard-Ethernet-Protokollstack um die time-triggeredFunktionalität erweitert werden. Dafür muss das Nachrichten-Scheduling und der zugehörige Scheduler, die Klassifizierungvon eingehenden Nachrichten und das Synchronisationsmodulimplementiert werden. Das Nachrichten-Scheduling legt fest,wann eine time-triggered Nachricht gesendet oder empfangenwird. Es wird offline konfiguriert. Für unterschiedliche Ereig-nisse, darunter das Versenden oder Empfangen von Nachrich-ten, aktiviert der Scheduler sogenannte Tasks.
Für die direkte Integration von Anwendungen in das Simu-lationsmodell wird die TTEthernet-API für das Simulations-modell implementiert. Über Code-Integration können darüberAnwendungen, die gegen die API programmiert wurden, di-rekt in der Simulation verwendet werden. Dabei verwendetdas Hostmodell die gleichen Datenstrukturen wie die reale Im-plementierung. Alle Nachrichten werden in Puffern zwischenAnwendungs- und Protokoll-Layer ausgetauscht.
IV. EVALUIERUNG & ERGEBNISSE
In diesem Abschnitt werden ausgewählte Simulationser-gebnisse, sowie eine Evaluierung der Simulationsperformanceaufgezeigt. Weiterhin wird die vorgestellte Simulationsumge-bung realen Hardwaremessungen und Ergebnissen aus demanalytischen Modell gegenübergestellt.
A. Simulationsergebnisse und PerformanceDie entwickelte TTEthernet-Implementierung wird zunächst
auf Basis künstlich generierter Topologien für Fahrzeug-Backbones getestet. Um zu überprüfen, ob das Modell den
TTE-HostSender
Switch Switch
TTE-HostEmpfänger
EtherHostSender
EtherHost Empfänger
TT TTTT
BE BE BE
Abbildung 5. Simulierte Topologie für den Nachweis der Protokollkonfor-mität — Parallele Übertragung von time-triggered und best-effort Nachrichten
Anforderungen an die Skalierbarkeit gerecht wird, werden To-pologien innerhalb der erwarteten maximalen Backbonegrößegeneriert. Basierend auf aktuellen Designs wird eine Topologievon maximal 70 Hosts und 7 Switches simuliert.
Die Simulation läuft auf Standard-PC-Hardware auf einemProzessorkern mit 2,4 GHz und 2 GB Arbeitsspeicher. Ex-perimente zeigen eine lineare Abhängigkeit zwischen demSpeicherverbrauch und der Netzwerkgröße sowie der Anzahlvon time-triggered Botschaften im Zyklus. Abbildung 4 zeigtdie benötigte CPU-Zeit und den Speicherverbrauch bei Simu-lationen unterschiedlicher Größe. Dabei wird jeweils über 30Echtzeitsekunden simuliert. Auf der X-Achse ist die Topolo-giegröße (Anzahl Switche und Anzahl Hosts) aufgetragen. Eswird dabei eine synthetisch generierte Topologie ausgemessen.Simulationen auf verschiedenen Topologien gleicher Größeund Summe der Switching-Hops je Nachricht zeigen, dass dieRechenzeit und der Speicherverbrauch ausschließlich von derGröße und nicht von der Struktur der Topologie abhängt.
Um die Metriken und Protokollkonformität des TTEthernet-Modells zu zeigen, wird weiterhin die Latenz und der Jittereines Beispiel-Netzwerkes mit TTEthernet- und Standard-Ethernet-Switches aus dem INET-Framework verglichen. Diedafür verwendete Topologie besteht aus zwei verbundenenSwitches, an denen zwei TTEthernet-Hosts für time-triggeredund zehn Standard-Ethernet-Hosts für die Erzeugung von best-effort Hintergrunddatenverkehr hängen (siehe Abbildung 5).Alle Links im simulierten Netzwerk haben eine Bandbreitevon 100 Mbit/s. Die Clock-Drift wird mit 200 ppm konfigu-riert. Die Signallaufzeit des Kabels beträgt 100 ns je Link.
Um den Einfluss des best-effort Datenverkehrs auf die Über-tragung über den Link zwischen den beiden Switches zu mes-sen, wird dieser zusätzlich zu den time-triggered Nachrichtenzwischen 0 % und 100 % mit best-effort Frames ausgelastet.Während dieser Simulation wird die minimale und maximaleEnde-zu-Ende Latenz über 10.000 Nachrichten gemessen. DieExtremwerte der Ende-zu-Ende Latenz sind die wichtigsteMetrik für die Echtzeit-Fahrzeugkommunikation.
1) Exemplarische Simulationsergebnisse: Die Ende-zu-Ende Latenz zwischen den time-triggered Hosts wird für dieINET-Ethernet-Switch-Implementierung und das TTEthernet-Modell gemessen. Die Ergebnisse (siehe Abbildung 6) zeigendie maximale und minimale Nachrichtenlatenz für die Bei-spieltopologie (Abbildung 5) in einer Messung über 10.000Nachrichten, während das Netzwerk zusätzlich mit einer va-riablen Anzahl von best-effort Frames belastet wird.
TTEthernet verspricht zuverlässige Kommunikation inner-halb definierter zeitlicher Grenzen. Abbildung 6 zeigt, dassdurch das synchronisierte Protokoll, die Priorisierung und dieMechanismen zur deterministischen Medienreservierung eine
6
0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 1 0 03 5 03 6 03 7 03 8 03 9 04 0 04 1 04 2 04 3 04 4 04 5 0
Laten
z [µs
]
L i n k A u s l a s t u n g [ % ]
S t a n d a r d m a x . S t a n d a r d m i n . T T E t h e r n e t m a x . T T E t h e r n e t m i n .
Abbildung 6. Vergleich der Ende-zu-Ende Latenz — Standard INET-Switchund TTEthernet-Switch
gleichförmige, von der Linkauslastung unabhängige Latenz er-reicht wird. Die geringen Schwankungen zwischen minimalerund maximaler Latenz entstehen durch Clock-Drift der lokalenUhren (siehe Abschnitt III-B). Der Einfluss der Clock-Drift istin den Vorarbeiten bereits analytisch verifiziert worden [2].
Demgegenüber steigt beim INET-Ethernet-Switch die Dif-ferenz zwischen minimaler und maximaler Latenz mit zuneh-mender Linkauslastung. Dieser Effekt entsteht durch das Auf-stauen von Nachrichten an den ausgehenden Ports der Switche.Wird der Link voll ausgelastet, ist die Kommunikation nichtmehr zuverlässig. Es werden Nachrichten verworfen, da dieÜbertragungskapazität nicht balanciert ist.
Eine weitere wichtige Analyse, welche die Topologie undKonfiguration eines Netzwerkes charakterisiert, ist die La-tenzverteilung. Graphen zur Latenzverteilung können die Ent-scheidung unterstützen, ob ein Netzwerk die Anforderungender Applikationen an die Weiterleitung von event-triggeredDatenverkehr erfüllt. Abbildung 7 zeigt die Latenz für diedrei Nachrichtenarten von TTEthernet auf demselben voll aus-gelasteten TTEthernet Netzwerk, entsprechend des im Evalu-ierungsprozess automatisch generierten Analyseberichts. Wiegefordert haben die time-triggered Nachrichten eine nahezukonstante Latenz. Die rate-constrained Nachrichten werdenmit einer variablen, jedoch auf 500 µs begrenzten Verzöge-rung ausgeliefert. Durch das Aufstauen und die Mechanismenzur Linkreservierung ist im Vergleich dazu beim best-effortDatenverkehr der Jitter hoch.
B. Verifikation des Simulationsmodells
Der Vergleich der Simulationsergebnisse mit Ergebnissenaus dem analytischen Modell [2] und Messungen mit echterTTEthernet-Hardware [13] zeigt die korrekte Abbildung desProtokolls im TTEthernet-Simulationsmodell. Da zum Zeit-punkt der Messungen nur ein Hardware-Switch zur Verfügungstand, ist eine einfachere Topologie für die Verifikation genutztworden. Die Verifikation kann wie hier beschrieben jedoch aufjegliche Topologie angewendet werden.
Die Evaluierung nutzt eine Topologie mit einem Switch undmehreren Hosts. Dabei läuft die Kommunikation zwischen denTeilnehmern stets durch einen Switching-Hop. Während der
5 0 0 7 5 0 1 0 0 0 1 2 5 0 1 5 0 0 1 7 5 0 2 0 0 0 2 2 5 0 2 5 0 00
1 02 03 04 05 06 07 08 09 0
1 0 0
Meng
e der
Nach
richte
n je K
lasse
[%]
L a t e n z [ µs ]
T i m e - T r i g g e r e d R a t e - C o n s t r a i n e d B e s t - E f f o r t
3 5 0 3 7 5 4 0 0 4 2 5 4 5 0 4 7 5 5 0 0 5 2 5 5 5 002468
1 01 2
9 8
1 0 0
Abbildung 7. Latenzverteilung der drei Verkehrsklassen von TTEthernet beieinem voll ausgelasteten Link
Evaluierung werden im Switch verschiedene Schedules mitunterschiedlichen Weiterleitungsverzögerungen eingesetzt.
Die Simulation läuft über 10.000 Nachrichten jeweils fürverschiedene Switch-Schedules, gezeigt sind Schedules mit350 µs und 9 µs Verzögerung zwischen Empfang und Weiter-leitung des Frames im Switch. Eine Verzögerung von 9 µs istzur Zeit das Minimum für eine zuverlässige Weiterleitung.
Der Schedule mit 9 µs führt zu einer simulierten Ende-zu-Ende Latenz von 19,5 µs für einen Frame mit minima-ler Payload und 252,0 µs für einen Frame mit maximalerPayload. Für den Schedule mit 350 µs Weiterleitungsverzö-gerung beträgt die Ende-zu-Ende Latenz, abhängig von derPayloadgröße, 360,5 µs bis 593,0 µs. Im Folgenden werdendiese Simulationsergebnisse mit dem mathematischen Modellund der Hardwaremessung verglichen.
1) Vergleich mit mathematischem Modell: Das mathemati-sche Modell der TTEthernet-Komponenten ist in einer Vorar-beit für einen theoretischen Vergleich der Leistungsmerkmalevon TTEthernet und FlexRay entwickelt und veröffentlichtworden [2].
Die folgenden Gleichungen sind Teil dieses Frameworks.Mit ihrer Hilfe lässt sich das zeitliche Verhalten einerTTEthernet-Komponente berechnen: Die Latenz tL wird dabeifür minimale und maximale Payload berechnet. Sie setztsich zusammen aus der physikalischen Signallaufzeit auf demKabel tWD · lW , der Zeit für die Datenübertragung — jeweilsbeim Sender und dem weiterleitenden Switch — 2 · lF · tb undder Verzögerung durch den Switch-Schedule tSD:
tL(tSD) = tWD · lW + 2 · lF · tb + tSD (2)
tLmin(tSD) = 10ns
m· 0, 5 m + 2 · 5, 12µs + tSD (3)
tLmax(tSD) = 10ns
m· 0, 5 m + 2 · 121, 44µs + tSD (4)
Wie erwartet besteht eine lineare Abhängigkeit zur Frame-länge lF . Für den Schedule mit tSD = 350 µs liegt dieberechnete Latenz je nach Payload-Größe zwischen 360,245 µsund 592,885 µs. Dieselbe Berechnung für den Schedule mit derminimalen Verzögerung von tSD = 9 µs ergibt eine Latenzzwischen 19,245 µs und 251,885 µs.
Die Ergebnisse des mathematischen Frameworks sind ge-ringfügig (<300 ns) niedriger als die Simulationsergebnisse.
7
Tabelle IVERGLEICH DER LATENZGRENZWERTE BEI MINIMALER UND MAXIMALER
PAYLOAD FÜR VERSCHIEDENE SWITCH-SCHEDULES
Weiterleitungs-verzögerung Payload Simulation Theorie Messung350 µs Schedule minimum 360,5 µs 360,245 µs 360 µs
maximum 593,0 µs 592,885 µs 592 µs
9 µs Schedule minimum 19,5 µs 19,245 µs -maximum 252,0 µs 251,885 µs -
Der Grund sind Vereinfachungen im mathematischen Modellbei der Abbildung von Hardware-Verzögerungen. Diese Ver-zögerungen werden in der Simulation präzise berücksichtigt.
2) Vergleich mit Messungen auf TTEthernet-Hardware:Um die Qualität des Simulationsmodells besser bewerten zukönnen, werden die Ergebnisse mit dem Verhalten echterTTEthernet-Hardware verglichen. Dazu wird eine in Vorar-beiten erstellte, auf einem Echtzeit-Linux-Kernel basierendeMessmethode [13] verwendet. Diese Methode erlaubt die Mes-sung von Latenz und Jitter des angeschlossenen Netzwerkesmit einer Genauigkeit im einstelligen Mikrosekunden-Bereich.
Für das simulierte Netzwerk mit einem Schedule von 350 µsVerzögerung ergibt sich eine gemessene Latenz zwischen360 µs und 592 µs je nach Framegröße. Bei Vernachlässigungder niedrigeren Präzision der Messmethode gegenüber derSimulation sind die Ergebnisse als vergleichbar anzusehen.Der Schedule mit 9 µs Verzögerung konnte nicht gemessenwerden, da die Messmethode auf einer Softwareimplemen-tierung des TTEthernet-Stacks basiert, dessen Präzision derSynchronisierung nicht ausreicht. Infolgedessen ergeben sichbei diesem Schedule partielle Paketverluste bei der software-basierten Messmethode.
3) Bewertung der Verifikation: Das Simulationsmodell im-plementiert das erwartete Verhalten eines TTEthernet-Systemsmit einer hohen Genauigkeit. Die Ergebnisse der Experimen-te zeigen, dass das Modell konform mit der TTEthernet-Spezifikation, dem mathematisch-analytischen Modell undder Hardwaremessung arbeitet. Die Latenz der time-triggeredNachrichten ist unabhängig vom simultan gesendeten best-effort Datenverkehr. Tabelle I zeigt die Ergebnisse der ver-schiedenen Messungen und Experimente für die Schedules mit9 µs und 350 µs im Vergleich.
V. ZUSAMMENFASSUNG & AUSBLICK
Durch die Zunahme von elektronischen Systemen im Au-tomobil sind die Anforderungen an Kommunikationsverbin-dungen stark gestiegen. Ein neuer Architekturansatz siehtein Backbone-Netzwerk vor, das als zentrales Element allerDatenverbindungen hoher Last gewachsen sein muss unddabei eine vorhersagbare, deterministische Nachrichtenüber-tragung garantiert. Eine mögliche Technologie für zukünfti-ge Fahrzeug-Backbones ist Echtzeit-Ethernet. Um frühzeitigAussagen zur Eignung von Ethernet-basierter Fahrzeugkom-munikation machen zu können, spielt die Simulation vonkonkreten Anwendungsszenarien eine wichtige Rolle für OEMund Zulieferer. Ein flexibler Evaluierungsprozess unterstütztdabei die Entwicklung.
Diese Arbeit stellt ein präzises, gut skalierendes Simula-tionsmodell für Echtzeit-Ethernet-basierte Kommunikation in
Fahrzeugen vor. Durch die sorgfältige Validierung auf Basisvon mathematischen Berechnungen in einem analytischenModell und Messungen auf echter TTEthernet-Hardware kannsichergestellt werden, dass die Ergebnisse der Simulation aufreale Probleme anwendbar sind.
In einer Fallstudie wurde der Evaluierungsprozess mit einerrealen Automotive-Anwendung getestet. Dabei wurde eine re-ale Fahrzeuganwendung mit hohen Bandbreitenanforderungen— die kamerabasierte Fahrzeugumfelderkennung — durchden Evaluierungsprozess verarbeitet. Hierdurch konnte diepraktische Relevanz eines simulationsbasierten Ansatzes fürdie Automotive-Entwicklung gezeigt werden.
Zukünftige Simulationsarbeiten auf Basis konkreter Auto-mobiltopologien und realistischer Anwendungsdaten begleitendie Analyse, wie time-triggered Ethernet-Systeme in einemzukünftigen Fahrzeug-Backbone umgesetzt werden können.Dabei unterstützt der in dieser Arbeit vorgestellte Evaluie-rungsprozess und die darin enthaltene Simulationsumgebungdie Entwicklung von prototypischen Umsetzungen und kon-kreten Lösungen wie der Konsolidierung aktueller automotiveBussysteme zu einer intelligenten Ethernet-basierten Vermitt-lungsinfrastruktur.
LITERATUR
[1] W. Steiner, “TTEthernet Specification,” TTTech Computertechnik AG,Nov. 2008. [Online]. Available: http://www.tttech.com
[2] T. Steinbach, F. Korf, and T. C. Schmidt, “Comparing Time-TriggeredEthernet with FlexRay: An Evaluation of Competing Approaches toReal-time for In-Vehicle Networks,” in 8th IEEE Intern. Workshop onFactory Communication Systems. Piscataway, New Jersey: IEEE Press,May 2010, pp. 199–202.
[3] T. Dohmke, “Bussysteme im Automobil: CAN, FlexRay und MOST,”Technische Universität Berlin, DaimlerChrysler AG, Tech. Rep., 2002.
[4] Aeronautical Radio Incorporated, “Aircraft Data Network,” ARINC,Annapolis, Maryland, Standard 664, 2002.
[5] SAE - AS-2D Time Triggered Systems and Architecture Committee,“Time-Triggered Ethernet (AS 6802),” 2009. [Online]. Available:http://www.sae.org
[6] B. Müller-Rathgeber, M. Eichhorn, and H.-U. Michel, “A unified car-itcommunication-architecture: Design guidelines and prototypical imple-mentation,” in IEEE Intelligent Vehicles Symposium, 2008, Jun. 2008,pp. 709–714.
[7] ——, “A unified car-it communication-architecture: Network switchdesign guidelines,” in IEEE International Conference on VehicularElectronics and Safety, 2008, Sep. 2008, pp. 16–21.
[8] B. Müller-Rathgeber and H.-U. Michel, “Automotive network planning- a genetic approach,” in IEEE Intelligent Vehicles Symposium, 2009,Jun. 2009, pp. 1088–1092.
[9] J. Hillebrand, M. Rahmani, R. Bogenberger, and E. Steinbach, “Coexi-stence of Time-Triggered and Event-Triggered Traffic in Switched Full-Duplex Ethernet Networks,” in International Symposium on IndustrialEmbedded Systems, 2007. SIES ’07., Jul. 2007, pp. 217–224.
[10] L. Seno and C. Zunino, “A simulation approach to a Real-Time Ethernetprotocol: EtherCAT,” in IEEE Int. Conference on Emerging Technologiesand Factory Automation 2008, Sep. 2008, pp. 440–443.
[11] P. Ferrari, A. Flammini, and S. Vitturi, “Performance analysis ofPROFINET networks,” Computer Standards & Interfaces, vol. 28, pp.369–385, Apr. 2006.
[12] T. Steinbach, H. Dieumo Kenfack, F. Korf, and T. C. Schmidt, “AnExtension of the OMNeT++ INET Framework for Simulating Real-time Ethernet with High Accuracy,” in 4th International Conference onSimulation Tools and Techniques (SIMUTools), 2011.
[13] F. Bartols, T. Steinbach, F. Korf, and T. C. Schmidt, “Per-formance Analysis of Time-Triggered Ether-Networks Using Off-the-Shelf-Components,” in 14th IEEE International Symposium onObject/Component/Service-Oriented Real-Time Distributed ComputingWorkshops (ISORCW) 2011. Piscataway, New Jersey: IEEE Press,Mar. 2011, pp. 49–56.
