Ethernet-basierte Fahrzeugnetzwerkarchitekturen für zukünftige Echtzeitsysteme im Automobil [1. Aufl.] 978-3-658-23499-7;978-3-658-23500-0

Table of contents :
Front Matter ....Pages I-XXXIV
Einführung (Till Steinbach)....Pages 1-10
Stand der Wissenschaft und Technik (Till Steinbach)....Pages 11-58
Bewertungsgrundlage und Elemente zukünftiger Architekturen (Till Steinbach)....Pages 59-102
Evaluierung in der Simulation (Till Steinbach)....Pages 103-220
Evaluierung im Versuchsfahrzeug (Till Steinbach)....Pages 221-254
Schlussfolgerungen und Designempfehlungen (Till Steinbach)....Pages 255-270
Zusammenfassung, Bewertung und Ausblick (Till Steinbach)....Pages 271-286
Back Matter ....Pages 287-337

Citation preview

Till Steinbach

Ethernet-basierte Fahrzeugnetzwerkarchitekturen für zukünftige Echtzeitsysteme im Automobil

Ethernet-basierte Fahrzeugnetzwerkarchitekturen für zukünftige Echtzeitsysteme im Automobil

Till Steinbach

Ethernet-basierte Fahrzeugnetzwerk­ architekturen für zukünftige Echtzeitsysteme im Automobil Mit einem Geleitwort von Prof. Dr. Werner Damm und Prof. Dr.-Ing. Franz Korf

Till Steinbach Fakultät Technik und Informatik, Department Informatik Hochschule für Angewandte Wissenschaften Hamburg Hamburg, Deutschland Zugl.: Dissertation, Carl von Ossietzky Universität Oldenburg, 2018/Hochschule für Angewandte Wissenschaften Hamburg, 2018 Gedruckt mit freundlicher Unterstützung des Department Informatik der Hochschule für Angewandte Wissenschaften Hamburg

ISBN 978-3-658-23500-0  (eBook) ISBN 978-3-658-23499-7 https://doi.org/10.1007/978-3-658-23500-0 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen National­ bibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. Springer Vieweg © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informa­ tionen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Springer Vieweg ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Geleitwort Mit Blick auf aktuelle und zukünftige Fahrerassistenzsysteme sowie hochautomatisiertes beziehungsweise autonomes Fahren spielt die zeitkritische und stark vermaschte Kommunikation zwischen Sensoren, Aktoren und ECUs, die das Herzstück dieser verteilten, sicherheitskritischen und hochkomplexen Systeme bilden, eine immer wichtigere Rolle in Fahrzeugen. Aufgrund von hohen Bandbreitenanforderungen, die aus verteilten Anwendungen wie z. B. Rohdatenfusion von Laserscannern und Kameras folgen, werden die Grenzen aktueller automobiler Kommunikationssysteme um mehr als eine Größenordnung überschritten. Bezüglich des Spektrums der Relevanz für sicherheitskritische Aufgaben und der Zeitanforderungen wächst die Heterogenität der automobilen Kommunikationsdaten. Erschwerend steigt der Bedarf an domänenübergreifender Kommunikation kontinuierlich. Die von der Automobilindustrie getriebene Open Alliance Special Interest Group, die sich auf die Standardisierung der auf der Bitübertragungsschicht angesiedelten BroadR-Reach-Technologie konzentriert, bildet die Grundlage für automobile Ethernet Varianten, die Echtzeitanforderungen erfüllen. Da etablierte Automobilzulieferer diese Technologie anbieten beziehungsweise vor der Markteinführung stehen, wird Ethernet ein neues Kommunikationsmedium in Fahrzeugen sein. Diese Arbeit zeigt Wege zur evolutionären Weiterentwicklung von Fahrzeugarchitekturen auf, um den oben dargestellten Anforderungen an zukünftige Ethernet-basierte automobile Kommunikationsarchitekturen Rechnung zu tragen. In diesem Kontext untersucht die Arbeit verschiedene Variationen von Ethernet-basierten Protokollen und deren Mischformen, wie sie zum Beispiel in TSN (Time Sensitive Network) definiert werden. Diese Analyse führt zu Entwurfsrichtlinien unterschiedlicher Anwendungsklassen. OEMs müssen ihre Investitionen in existierende und praxiserprobte Teilsysteme schützen. Eine Gateway-basierte Migrationsstrategie wird in dieser Arbeit entwickelt und erprobt. Methodisch werden diese Untersuchungen mit ereignisbasierten Simulationen durchgeführt. Die Simulationsmodelle, die als Open Source Software verfügbar sind, basieren auf der OMNeT++ Simulationsumgebung und dem

VI

Geleitwort

INET-Framework für diese Umgebung. Diese Arbeit entwickelt Datenverkehrsmodelle, die die Grundlage für die Stimuli der Simulation bilden. Zur Gewinnung praxisrelevanter Ergebnisse werden diese Datenverkehrsmodelle auf Basis der Kommunikationsanforderungen realer Fahrzeuge der gehobenen Mittelklasse entworfen. Die Nagelprobe dieser simulationsbasierten Analysen wird durch die Umsetzung einer ausgewählten Kommunikationsarchitektur in einem Prototypenfahrzeug erbracht. Oldenburg Hamburg

Prof. Dr. Werner Damm Prof. Dr.-Ing. Franz Korf

Inhaltsverzeichnis Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII Verzeichnis der Farbkodierung . . . . . . . . . . . . . . . . . . . . . . . . . . XIX Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXI Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XXVII 1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Problemstellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Zielsetzung, Forschungsansatz und methodisches Vorgehen 1.4 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

2 Stand der Wissenschaft und Technik . . . . . . . . . . . . . . . . . 2.1 Stand der Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Heutige Fahrzeugnetzwerktechnologien . . . . . . . . . 2.1.2 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Echtzeit-Ethernet-Protokolle . . . . . . . . . . . . . . . . 2.2 Stand der Wissenschaft . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Sicherheit in eingebetteten IP-basierten Systemen . 2.2.2 Protokollvergleiche . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Time-triggered Kommunikation . . . . . . . . . . . . . . 2.2.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.5 Formale Zeitanalyse . . . . . . . . . . . . . . . . . . . . . . 2.2.6 Topologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.7 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.8 Anwendungen. . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.9 Modellbasierte Entwicklung . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . .

1 3 6 7 10 11 11 11 22 27 43 43 46 48 49 50 53 53 55 56

VIII

Inhaltsverzeichnis

2.3 Zusammenfassung und resultierender Handlungsbedarf . . . . . . 57 3 Bewertungsgrundlage und Elemente zukünftiger Architekturen. 3.1 Anforderungen und Netzwerkmetriken . . . . . . . . . . . . . . . . . 3.1.1 Bandbreite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Latenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.3 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Fahrzeugdatenverkehrsmodelle . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Allgemeines Seriendatenverkehrsmodell. . . . . . . . . . . . 3.2.2 Komprimiertes domänenbasiertes Datenverkehrsmodell 3.3 Topologien für Ethernet-basierte Fahrzeugnetze . . . . . . . . . . 3.3.1 Heutige Topologie in Serienfahrzeugen . . . . . . . . . . . . 3.3.2 Domänen-Gateway-Topologie. . . . . . . . . . . . . . . . . . . 3.3.3 Domänen-Zonen-Topologie . . . . . . . . . . . . . . . . . . . . 3.3.4 Flache Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Kommunikationstechnologien und -strategien . . . . . . . . . . . . 3.4.1 Global geplante Kommunikation und Überprovisionierung . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Deterministische Übertragung . . . . . . . . . . . . . . . . . . 3.4.3 Limitierung von Frame-Größen — Runts und Giants . . 3.5 Gateway-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 Tunnel-Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.2 Übersetzende Gateways. . . . . . . . . . . . . . . . . . . . . . . 4 Evaluierung in der Simulation . . . . . . . . . . . . . . . . . . . . . . . . 4.1 DES (Diskrete ereignisbasierte Simulation) . . . . . . . . . . . . 4.2 Simulationsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Simulationsplattform OMNeT++ . . . . . . . . . . . . . . . 4.2.2 Fahrzeugnetzwerksimulation . . . . . . . . . . . . . . . . . . 4.2.3 Echtzeit-Ethernet-Modelle . . . . . . . . . . . . . . . . . . . . 4.2.4 Feldbusmodelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.5 Gateway-Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.6 Werkzeugkette . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.7 Absicherung der Gültigkeit der Simulationsergebnisse 4.3 Referenzarchitektur (Serienfahrzeug) . . . . . . . . . . . . . . . . . 4.3.1 Hintergrund zur Fragestellung . . . . . . . . . . . . . . . . . 4.3.2 Untersuchungsszenario . . . . . . . . . . . . . . . . . . . . . . 4.3.3 Ergebnisse der Simulation . . . . . . . . . . . . . . . . . . . . 4.3.4 Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

59 59 59 60 62 63 63 67 71 72 73 74 76 77

. . . . . .

77 81 90 94 95 99

. . . . . . . . . . . . . .

103 105 107 107 110 111 114 116 117 135 137 137 137 138 141

Inhaltsverzeichnis

IX

4.4 Time-triggered und event-triggered Echtzeit-Ethernet . . . . 4.4.1 Hintergrund zur Fragestellung . . . . . . . . . . . . . . . . 4.4.2 Untersuchungsszenario . . . . . . . . . . . . . . . . . . . . . 4.4.3 Ergebnisse der Simulation . . . . . . . . . . . . . . . . . . . 4.4.4 Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . 4.5 Time-Aware-Shaper-Konzept . . . . . . . . . . . . . . . . . . . . . 4.5.1 Hintergrund zur Fragestellung . . . . . . . . . . . . . . . . 4.5.2 Untersuchungsszenario . . . . . . . . . . . . . . . . . . . . . 4.5.3 Ergebnisse der Simulation . . . . . . . . . . . . . . . . . . . 4.5.4 Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . 4.6 Hintergrunddatenverkehr im Echtzeit-Ethernet. . . . . . . . . 4.6.1 Hintergrund der Fragestellung . . . . . . . . . . . . . . . . 4.6.2 Untersuchungsszenario . . . . . . . . . . . . . . . . . . . . . 4.6.3 Ergebnisse der Simulation . . . . . . . . . . . . . . . . . . . 4.6.4 Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . 4.7 Frame Preemption im Fahrzeugnetzwerk . . . . . . . . . . . . . 4.7.1 Hintergrund der Fragestellung . . . . . . . . . . . . . . . . 4.7.2 Untersuchungsszenario . . . . . . . . . . . . . . . . . . . . . 4.7.3 Ergebnisse der Simulation . . . . . . . . . . . . . . . . . . . 4.7.4 Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . 4.8 Transportprotokolle und Echtzeit-Ethernet Traffic Shaping 4.8.1 Hintergrund der Fragestellung . . . . . . . . . . . . . . . . 4.8.2 Untersuchungsszenario . . . . . . . . . . . . . . . . . . . . . 4.8.3 Ergebnisse der Simulation . . . . . . . . . . . . . . . . . . . 4.8.4 Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . 4.9 Netzwerkarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9.1 Hintergrund der Fragestellung . . . . . . . . . . . . . . . . 4.9.2 Untersuchungsszenario . . . . . . . . . . . . . . . . . . . . . 4.9.3 Ergebnisse der Simulation . . . . . . . . . . . . . . . . . . . 4.9.4 Diskussion der Ergebnisse . . . . . . . . . . . . . . . . . . . 5 Evaluierung im Versuchsfahrzeug . . . . 5.1 Zielsetzung und Projektphasen . . . 5.2 Ausgangsfahrzeug . . . . . . . . . . . . 5.3 Komponenten . . . . . . . . . . . . . . . 5.3.1 Kameras und Bildkodierung 5.3.2 Laser-Scanner. . . . . . . . . . . 5.3.3 Switche und Physical Layer . 5.3.4 ECUs und Software . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

143 143 144 146 150 152 153 159 161 170 171 172 172 174 179 181 181 183 184 188 189 189 191 193 197 198 199 199 203 215

. . . . . . . .

. . . . . . . .

. . . . . . .

221 222 222 224 224 225 227 228

X

Inhaltsverzeichnis

5.3.5 Weitere Komponenten. . . . . . . . . . . . 5.4 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Architektur und Topologie. . . . . . . . . 5.4.2 Datenströme und Netzwerkprotokolle . 5.5 Ergebnisse. . . . . . . . . . . . . . . . . . . . . . . . . 5.5.1 Funktionale Ergebnisse . . . . . . . . . . . 5.5.2 Leistungsmessung . . . . . . . . . . . . . . . 5.5.3 Diskussion der Ergebnisse . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

233 233 234 236 239 239 240 252 255 255 259 259 264 266 267 268 269 270

6 Schlussfolgerungen und Designempfehlungen . 6.1 Diskussion der Untersuchungsergebnisse. . . 6.2 Designempfehlungen und Best Practices . . 6.2.1 Kommunikationsdesign . . . . . . . . . . 6.2.2 Topologiedesign . . . . . . . . . . . . . . . 6.2.3 Linkgeschwindigkeit . . . . . . . . . . . . 6.2.4 Preemption . . . . . . . . . . . . . . . . . . 6.2.5 Zeitsynchronisierung . . . . . . . . . . . . 6.2.6 Implementierung. . . . . . . . . . . . . . . 6.2.7 Werkzeuge und Fehlersuche . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . .

7 Zusammenfassung, Bewertung und Ausblick 7.1 Zusammenfassung . . . . . . . . . . . . . . . . . 7.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . 7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

271 . 271 . 283 . 284

. . . .

A Überblick über Forschungsfragen . . . . . . . . . . . . . . . . . . . . . . . 287 B Datenverkehrsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 B.1 Allgemeines Seriendatenverkehrsmodell . . . . . . . . . . . . . . . . . 291 B.2 Komprimiertes domänenbasiertes Datenverkehrsmodell . . . . . . 300 C Abstract Network Description Language . . . . . . . . . . . . . . . . . 303 Ausgewählte Veröffentlichungen des Autors . . . . . . . . . . . . . . . . . 307 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Mitbetreute Abschlussarbeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . 331 Sachregister . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Abbildungsverzeichnis 1.1 1.2

Schaltplan Ford Model T, 1919 . . . . . . . . . . . . . . . . . . . . . . . . . 1 Beispielhafte Netzwerkarchitektur, Technologien und Gateway . . . 4

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13

CAN-Frame-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FlexRay-Zyklus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FlexRay Frame-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . MOST 25 Frame-Format . . . . . . . . . . . . . . . . . . . . . . . . . . . Kollisionsdomänen im Vergleich: Bus, Hub und Switch . . . . . . Standard Ethernet Frame-Format. . . . . . . . . . . . . . . . . . . . . Traffic Shaping und Warteschlangen in IEEE 802.1Qav . . . . . Credit Based Shaping im IEEE 802.1Qav-Standard . . . . . . . . TTEthernet Frame-Format . . . . . . . . . . . . . . . . . . . . . . . . . Systembeispiel TTEthernet – Shaping mit drei Traffic-Klassen Zweistufiges TTEthernet-Synchronisierungsprotokoll . . . . . . . Verkürzung des Guard Band durch Preemption . . . . . . . . . . . Verkürzung der Ende-zu-Ende-Latenz und des Jitters durch Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14 Format von Ethernet Frames mit Preemption . . . . . . . . . . . . 2.15 Referenzimplementierung Frame Preemption . . . . . . . . . . . . .

. . . . . . . . . . . .

3.1 3.2 3.3

. . 64 . . 64

3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11

Nachrichtengrößen im allgemeinen Seriendatenverkehrsmodell. Zykluszeiten im allgemeinen Seriendatenverkehrsmodell . . . . . Heatmap der Kommunikation im allgemeinen Seriendatenverkehrsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . Nachrichtengrößen im domänenbasierten Datenverkehrsmodell Zykluszeiten im domänenbasierten Datenverkehrsmodell. . . . . Heatmap der Kommunikation im domänenbasierten Datenverkehrsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Steuergeräte im Serienfahrzeug. . . . . . . . . . . . . . . . . . . . . . . Heutige Topologie in Serienfahrzeugen . . . . . . . . . . . . . . . . . Domänen-Gateway-Topologie . . . . . . . . . . . . . . . . . . . . . . . . Domänen-Zonen-Topologie. . . . . . . . . . . . . . . . . . . . . . . . . . Flache Topologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . .

14 17 18 20 23 24 32 33 36 37 38 40

. . 41 . . 42 . . 43

. . 66 . . 68 . . 69 . . . . . .

. . . . . .

70 71 73 74 75 76

XII

Abbildungsverzeichnis

3.12 Topologie mit optionalen Steuergeräten . . . . . . . . . . . . . . . . . 3.13 Latenz in Abhängigkeit zu Nutzdatengröße – FlexRay und TTEthernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 Echtzeitslots in Abhängigkeit zur Nutzdatengröße – FlexRay und TTEthernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15 Nettobandbreite in Abhängigkeit zur Nutzdatengröße – FlexRay und TTEthernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16 Einfluss von Jumbo-Frames auf das Guard Band . . . . . . . . . . . 3.17 Gateway Tunnelnachrichtenformat . . . . . . . . . . . . . . . . . . . . . 3.18 Overhead des Gateway-Tunnelprotokolls . . . . . . . . . . . . . . . . . 3.19 Zusätzliche Verwaltungsaufgaben im übersetzenden Gateway . .

. 77

4.1 Zustände in kontinuierlichen und diskreten Systemen . . . . . . . . 4.2 Typischer Ablauf einer diskreten ereignisbasierten Simulation . . 4.3 Aufbau eines OMNeT++-Simulationsmoduls . . . . . . . . . . . . . . 4.4 Abweichung der Periode bei der Restbussimulation mit OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Aufbau der Fahrzeugnetzwerksimulation . . . . . . . . . . . . . . . . . 4.6 Überblick über das Simulationsmodell eines Echtzeit-Ethernet-Endgeräts . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Links und Botschaften in der automatisierten Schedule-Erzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Taskgraph in der automatisierten Schedule-Erzeugung . . . . . . . 4.9 Topologie für das Scheduling-Beispiel . . . . . . . . . . . . . . . . . . . 4.10 Ende-zu-Ende-Latenz mit verschiedenen Scheduling-Algorithmen 4.11 Maximale Lateness mit verschiedenen Scheduling-Algorithmen . 4.12 Verteilter Simulations-Cluster mit zentralem Datenbank-Server. 4.13 Erzeugung von Gantt-Diagrammen aus OMNeT++-Eventlog-Sequenzen . . . . . . . . . . . . . . . . . . . . . . . 4.14 Auslastung der Busse in der Referenzarchitektur . . . . . . . . . . . 4.15 Latenz in der Referenzarchitektur. . . . . . . . . . . . . . . . . . . . . . 4.16 Ende-zu-Ende-Latenz über Backbone in Fahrwerksdomäne . . . . 4.17 Anzahl an Nachrichten, die auf das Versenden innerhalb ihrer Domäne warten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.18 Baumbasierte Topologie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19 Multimedia-Streamingdaten und Kamera über TTEthernet und AVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.20 Steuerdaten über TTEthernet und AVB . . . . . . . . . . . . . . . . . 4.21 Steuerung des Medienzugriffs im Time Aware Shaper . . . . . . . .

. 105 . 106 . 109

. 84 . 87 . . . . .

87 91 97 100 101

. 110 . 111 . 112 . . . . . .

123 124 126 129 130 133

. . . .

136 138 139 140

. 142 . 145 . 148 . 150 . 155

Abbildungsverzeichnis

XIII

4.22 Standard IEEE 802.1Qav — Credit-Based-Shaping-Verhalten . . 4.23 CBS mit time-triggered Nachrichten im Time Aware Shaper . . . 4.24 CBS mit time-triggered Nachrichten, AVB Worstcase im Time Aware Shaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.25 Netzwerktopologie und Datenströme für die Analyse des Time Aware Shapers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.26 Kumulative Verteilung der Latenz im Time Aware Shaper . . . . 4.27 Time-Aware-Shaper-Konfiguration mit kompaktem Schedule. . . 4.28 Latenz im Time Aware Shaper bei kompaktem Schedule. . . . . . 4.29 Warteschlangenlänge im Time Aware Shaper . . . . . . . . . . . . . . 4.30 Time-Aware-Shaper-Konfiguration mit optimiertem Schedule . . 4.31 Latenz im Time Aware Shaper bei angepasstem Schedule . . . . . 4.32 AVB-Latenz in Abhängigkeit zur MTU im Time Aware Shaper. 4.33 Maximale Latenz von Steuerbotschaften mit Hintergrunddatenverkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.34 Maximale Latenz von kamerabasiertem Fahrerassistenzsystem mit Hintergrunddatenverkehr . . . . . . . . . . . . . . . . . . . . . . . . . 4.35 Maximale Latenz von Steuerbotschaften mit Preemption . . . . . 4.36 Vergleich der maximalen Latenz mit und ohne Preemption . . . . 4.37 Ende-zu-Ende-Latenz bei Preemption mit unterschiedlichen Fragmentgrößen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.38 Netzwerktopologie und Datenströme für die Analyse der Transportprotokolle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.39 Time-triggered Schedule mit gleichmäßigem Zyklus und Bursts. 4.40 Flache Topologie mit hochauflösender Sensorik . . . . . . . . . . . . 4.41 Latenz in der Domänen-Gateway-Topologie. . . . . . . . . . . . . . . 4.42 Latenz in der Domänen-Gateway-Topologie mit Aggregierung. . 4.43 Auslastung der Busse mit zerteilten Domänen . . . . . . . . . . . . . 4.44 Latenz in der Domänen-Zonen-Topologie . . . . . . . . . . . . . . . . 4.45 Maximale Latenz in der flachen Topologie . . . . . . . . . . . . . . . . 4.46 Latenz in der flachen Topologie mit RC-Datenverkehr . . . . . . . 4.47 Maximale Latenz in der flachen Topologie mit paralleler ADAS-Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.48 Vergleich der Latenz in verschiedenen Architekturen . . . . . . . .

. 156 . 157

5.1 Versuchsfahrzeug Golf VII Variant . . . . . . . . . . . . . . . . . . 5.2 Kameragehäuse mit Sichtkuppel und Halterung am Kühler. 5.3 Position der LIDAR-Sensoren im Versuchsfahrzeug . . . . . . 5.4 Netzwerkarchitektur des Versuchsfahrzeugs . . . . . . . . . . . .

. . . .

. . . .

. . . .

. 158 . . . . . . . .

160 162 163 164 166 167 168 169

. 176 . 178 . 185 . 186 . 187 . . . . . . . . .

192 198 203 204 207 208 210 212 215

. 216 . 217 . . . .

221 225 227 234

XIV

5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12

Abbildungsverzeichnis

Trennung des zentralen Serien-Gateways mit selektiver CAN-Diode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Messaufbau für Latenzuntersuchungen im Versuchsfahrzeug . . . Latenzverteilung der CAN-Übertragung über zentrales Gateway Latenzverteilung der CAN-Übertragung über Echtzeit-Ethernet Latenzzusammensetzung CAN-Übertragung über Echtzeit-Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Latenzzusammensetzung CAN-Übertragung über Echtzeit-Ethernet (Zoom) . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeitmessung LIDAR-Sensorfusion über Ethernet Backbone. . . . Abweichung der Synchronisationssignale über die Zeit . . . . . . .

. . . .

236 241 243 245

. 246 . 247 . 249 . 252

6.1

Abschirmung des Fahrzeug-Backbone gegen Hintergrunddatenverkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 6.2 Einfluss der MTU auf die Worstcase-Latenz . . . . . . . . . . . . . . . 262 6.3 Optimierung der Ende-zu-Ende-Latenz durch Bandbreitenerhöhung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 B.1 Bandbreitennutzung im allgemeinen Seriendatenverkehrsmodell . 299

Tabellenverzeichnis 2.1 2.2

SAE-Klassifikation von Kommunikationslösungen . . . . . . . . . . . 12 100BASE-T1, 100BASE-TX und 1000BASE-T im Vergleich . . . . 27

3.1 Latenz und Jitter für FlexRay- und TTEthernet-Beispielkonfigurationen . . . . . . . . . . . . . . . . . . . . . 89 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Automatisiertes Scheduling mit verschiedenen Algorithmen . . . Queue-Längen und Speicherbedarf im Gateway der Referenzarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verkehrsströme für die Untersuchung von Echtzeit-Ethernet-Protokollen . . . . . . . . . . . . . . . . . . . . . . . . Traffic-Klassen und Prioritäten für die Untersuchung von Echtzeit-Ethernet-Protokollen . . . . . . . . . . . . . . . . . . . . . . . . Latenz- und Jitter-Ergebnisse der Multimedia- und Kameradatenströme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Latenz- und Jitter-Ergebnisse der Steuerdaten. . . . . . . . . . . . . Latenzvergleich mit und ohne AVB-Datenverkehr im Time Aware Shaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Latenzvergleich kompakter und optimierter Schedule im Time Aware Shaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Netzwerkmetriken mit kompaktem und optimiertem Schedule im Time Aware Shaper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Charakteristiken der Verkehrsströme für die Untersuchung von Hintergrunddatenverkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . Traffic-Klassen und Prioritäten für die Untersuchung von Hintergrunddatenverkehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fahrzeugsteuerdaten mit Hintergrunddaten bei verschiedenen Frame-Größen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fahrerassistenzkameradatenströme mit Hintergrunddaten bei verschiedenen Frame-Größen . . . . . . . . . . . . . . . . . . . . . . . . . Multimedia- und Entertainment-Datenverkehr mit Hintergrunddaten bei verschiedenen Frame-Größen . . . . . . . . . Fahrzeugsteuerdaten mit Hintergrunddaten und Preemption. . .

. 128 . 141 . 145 . 146 . 147 . 149 . 162 . 169 . 171 . 173 . 173 . 174 . 177 . 178 . 185

XVI

Tabellenverzeichnis

4.16 Vergleich der Fahrzeugsteuerdaten mit Hintergrunddaten mit und ohne Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.17 Steuerdaten über verschiedene Transportprotokolle und Verkehrsklassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.18 Kameradaten über verschiedene Transportprotokolle und Verkehrsklassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.19 Zuweisung von CAN (Controller Area Network) zu rate-constrained Prioritäten . . . . . . . . . . . . . . . . . . . . . . . . . . 4.20 Auslastung der Ethernet-Links in der Domänen-Gateway-Topologie . . . . . . . . . . . . . . . . . . . . . . . . . 4.21 Auslastung in der Domänen-Gateway-Topologie mit Pooling. . . 4.22 Auslastung der Ethernet-Links in der Domänen-Zonen-Topologie 4.23 Netzwerkmetriken verschiedener Nachrichtenklassen mit flacher Topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.24 Netzwerkmetriken verschiedener Nachrichtenklassen mit flacher Topologie und Aggregierung. . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Datenströme und verwendete Protokolle im Versuchsfahrzeug . . 5.2 Gemessene Verzögerung zentrales CAN Gateway . . . . . . . . . . . 5.3 Gemessene Verzögerung CAN über Echtzeit-Ethernet . . . . . . . 5.4 Zusammensetzung der Verzögerung CAN über Echtzeit-Ethernet 5.5 Genauigkeit des Synchronisationssignals der LIDAR-Sensoren. .

. 187 . 195 . 196 . 200 . 203 . 206 . 209 . 211 . 213 . . . . .

237 242 244 247 251

A.1 Überblick über Forschungsfragen, Methoden und Schlüsselergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

Listings 4.1 Beispiel der rtIpConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.2 Beispiel der ANDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.3 Beispiel der XML-Konfiguration für den Check-Result-Manager. . 135 B.1 Allgemeines Seriendatenverkehrsmodell . . . . . . . . . . . . . . . . . . . 291 B.2 Komprimiertes domänenbasiertes Datenverkehrsmodell . . . . . . . . 300 C.1 Grammatik der ANDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

Verzeichnis der Farbkodierung Wo anwendbar, werden in der vorliegenden Arbeit Farben in Abbildungen und Graphen konsistent wie folgt verwendet: Verkehrsklassen Time-triggered Rate-constrained IEEE 802.1Q IEEE 802.1Qav (AVB) SRKlasse A IEEE 802.1Qav (AVB) SRKlasse B Best-effort

Domänen Abgeleitet aus der öffentlichen Volkswagen Service-Dokumentation [163] Antrieb Fahrwerk Komfort Erweitert Infotainment Diagnose

Simulationskomponenten ANDL (Abstract Network Description Language) CoRE4INET FiCo4OMNeT SignalsAndGateways oppResultManagers

Abkürzungsverzeichnis μs

Mikrosekunde

ABE ABS ADAS AFDX ALU ANDL API APIX ARAMiS ARINC ARM ARP ASR AVB

Allgemeine Betriebserlaubnis Antiblockiersystem Advanced Driver Assistance System Avionics Full DupleX Switched Ethernet Arithmetisch-logische Einheit Abstract Network Description Language Application Programming Interface Automotive Pixel link Automotive Railway Avionics Multicore Systems Aeronautical Radio Incorporated Advanced RISC Machines Address Resolution Protocol Antriebsschlupfregelung Audio Video Bridging

B b BAG BE BIOS BMBF BMW BRS

Byte Bit Bandwidth Allocation Gap best-effort Basic Input/Output System Bundesministerium für Bildung und Forschung Bayerische Motoren Werke AG Bit Rate Switch

CAN CBS CD CDF CI

Controller Area Network Credit Based Shaper Compact Disc Cumulative Distribution Function Continuous Integration

XXII

CMOS CoRE CoRE4INET

Abkürzungsverzeichnis

COTS CPA CPU CRC CSMA/CA CSMA/CD CT CTC

Complementary Metal-Oxide-Semiconductor Communication over Real-time Ethernet Communication over Real-time Ethernet for INET Framework Components-of-the-shelf Compositional Performance Analysis Central Processing Unit Cyclic Redundancy Check Carrier Sense Multiple Access/Collision Avoidance Carrier Sense Multiple Access/Collision Detection Critical Traffic Critical Traffic Conformance

DC DCU DEI DES DESS DM DSL DSP DSR

Direct Current Domain Control Unit Drop Eligible Indicator Diskrete ereignisbasierte Simulation Differential Equation Specified System Domänen-Master Domain Specific Language Digitaler Signalprozessor Data Set Ready

EADS ECU ED EDF EEE EFM EMV EoF ESP EtherCAT

European Aeronautic Defence and Space Electronic Control Unit External Data Earliest Deadline First Energy Efficient Ethernet Ethernet in the First Mile Elektromagnetische Verträglichkeit End of Frame Elektronisches Stabilitätsprogramm Ethernet for Control Automation Technology

FCS FD FES FiCo4OMNeT FIFO

Frame Check Sequence Flexible Data rate Future Event Set Fieldbus Communication for OMNeT++ First In - First Out

Abkürzungsverzeichnis

XXIII

FPGA FTDMA

Field Programmable Gate Array Flexible Time Division Multiple Access

GB GCTA GPIO GPS GW

Guard Band Gantt Chart Timing Analyzer General Purpose Input/Output Global Positioning System Gateway

HAD HAW HiL

Highly Automated Driving Hochschule für Angewandte Wissenschaften Hardware-in-the-Loop

IAV ID IDE IDS IEEE IET IETF IFG IKT INRIA IoT IP IPv4 IPv6 ISO

Ingenieurgesellschaft Auto und Verkehr Identifikator Integrated Development Environment Imaging Development Systems GmbH Institute of Electrical and Electronics Engineers Interspersing Express Traffic Internet Engineering Task Force Inter Frame Gap Informations- und Kommunikationstechnologie Institut National de Recherche en Informatique et en Automatique Internet of Things Internetprotokoll Internetprotokoll Version 4 Internetprotokoll Version 6 International Organization for Standardization

JPEG

Joint Photographic Experts Group

KFZ

Kraftfahrzeug

LAN LIDAR LIN LVDS

Local Area Network LIght Detection And Ranging Local Interconnect Network Low Voltage Differential Signaling

XXIV

Abkürzungsverzeichnis

MAC MEP MII MJPEG MLB MLT MOST MQB ms MSB MTU

Media Access Control MOST Ethernet Packet Media Independent Interface Motion JPEG Modularer Längsbaukasten Multilevel Transmission Encoding Media Oriented System Transport Modularer Querbaukasten Millisekunde Modularer Standardbaukasten Maximum Transmission Unit

NED NIT NMEA NRZ

Network Description Network Idle Time National Marine Electronics Association Non Return to Zero

OABR OEM OMNeT++ OPEN OSI

OPEN Alliance BroadR-Reach Original Equipment Manufacturer Objective Modular Network Testbed in C++ One Pair EtherNet Open Systems Interconnection

P2P PAM PARC PCAP PCAPng PCF PCIe PCP PCU PDES PHY POF PSI PTP

Point-2-Point Pulsamplitudenmodulation Palo Alto Research Center Packet Capture PCAP next generation Protocol Control Frame PCI Express Priority Code Point Programming Control Unit Parallel Distributed Simulation Physical Layer Plastic Optical Fiber Peripheral Sensor Interface Precision Time Protocol

QoS

Quality-of-Service

Abkürzungsverzeichnis

RC RDBMS RECBAR RFC RISC ROI RSE RTaW RTPGE RTR RTS RX

rate-constrained Relational Database Management System Realtime Ethernet Backbones for Cars Request for Comments Reduced Instruction Set Computer Region of Interest Rear Seat Entertainment RealTime-at-Work Reduced Twisted Pair Gigabit Ethernet Remote Transmission Request Real-Time Systems Receiver

SAE SATA SchuKo SCTP SEIS SFD SIG SJF SoC SoF SOME/IP SPES 2020 SPS SQL SR SRP ST STP SUTP SysML

Society of Automotive Engineers Serial ATA Schutz-Kontakt Stream Control Transmission Protocol Sicherheit in Eingebetteten IP-basierten Systemen Start Frame Delimiter Special Interest Group Shortest Job First System-on-a-Chip Start of Frame Scalable service-Oriented MiddlewarE over IP Software Platform Embedded Systems 2020 Speicherprogrammierbare Steuerung Structured Query Language Stream Reservation Stream Reservation Protocol Scheduled Traffic Shielded Twisted Pair SCALA UDP based Transport Protocol Systems Modeling Language

TABS TAP TCI TCP

Time Aware Blocking Shaper Test Access Port Tag Control Information Transmission Control Protocol

XXV

XXVI

Abkürzungsverzeichnis

TDMA TPID TSN TT TTCAN TTE TX

Time Division Multiple Access Tag Protocol Identifier Time-Sensitive Networking time-triggered Time-triggered Controller Area Network TT Ethernet Transmitter

UDP USB UTSP

User Datagram Protocol Universal Serial Bus Unshielded Twisted Single Pair

VID VL VLAN VoIP VW

VLAN-Identifier Virtueller Link Virtuelles LAN Voice-over-IP Volkswagen

WAN WCTA

Wide Area Network Worstcase Timing Analyse

XML

Extensible Markup Language

Glossar automotive Automotive ist ein Oberbegriff für maschinenangetriebene Fahrzeuge. Autonegotiation Autonegotiation, auch Autosensing, ist ein Verfahren, um auf einem Link zwischen zwei Ethernet-Teilnehmern die mögliche Übertragungsgeschwindigkeit sowie das Duplex-Verfahren auszuhandeln. Backbone Backbone (deutsch: Rückgrat, Hauptstrang, Basisnetz) bezeichnet den zentralen Kernbereich eines Telekommunikationsnetzes. best-effort Best-effort (deutsch: größte Bemühung) bezeichnet die geringste Dienstgütezusicherung in Netzwerken. Übermittlungsanfragen werden im Rahmen der zur Verfügung stehenden Ressourcen bedient. Birds-View Birds-View (deutsch: Vogelperspektive) bezeichnet im Automobilbereich eine virtuelle Kameransicht mit einer Perspektive von oben auf ein Fahrzeug herab. Eine weitere gängige Bezeichnung ist Top-View. Birds-ViewAnsichten werden auf Basis von mehreren rund um das Fahrzeug angeordneten Kameras berechnet. Burst Ein Burst ist eine Datenübertragung mit hoher Bandbreite über eine kurze Zeit. Bursts sind Lastspitzen auf einem Übertragungsmedium. Cut-Through Beim Cut-Through-Verfahren wird in paketvermittelnden Netzwerken nicht zunächst das komplette Paket empfangen, bevor es weitergeleitet wird.

XXVIII

Glossar

Sobald ausreichend Informationen für die Vermittlung vorliegen, werden die Daten direkt am ausgehenden Link weitergeleitet. Daisy-Chain Eine Daisy-Chain (zu deutsch, wörtlich: Gänseblümchenkette) ist eine in Serie miteinander verbunde Kette von Hardware-Komponenten. Dabei muss das Signal eines Teilnehmers von seinen Nachbarn solange weitergeleitet werden, bis es den Empfänger erreicht. DC-DC-Wandler Ein DC-DC-Wandler oder auch Gleichspannungswandler bezeichnet eine Schaltung, die eine zugeführte, meist variable, Gleichspannung in eine Gleichspannung eines höheren oder niedrigeren Spannungsniveaus wandelt. Guard Band Das Guard Band ist in time-triggered Echtzeit-Ethernet-Varianten ein Mechanismus um zu verhindern, dass eine synchrone TT-Botschaft (timetriggered) durch eine asynchrone Botschaft verzögert wird. Innerhalb des Guard Band darf die Übertragung eines asynchronen Frames nicht gestartet werden, da dieser in das time-triggered Sendefenster hineinreichen könnte. Hamming-Abstand Der Hamming-Abstand ist ein Maß für die Unterscheidbarkeit von Symbolen. Der Abstand zweier Blöcke ist dabei die Anzahl unterschiedlicher Stellen. Auf Basis von Wahrscheinlichkeiten kann der Hamming-Abstand zur Fehlererkennung und -korrektur eingesetzt werden. Hardware-in-the-Loop Bei der Methode HiL (Hardware-in-the-Loop) wird ein eingebettetes System zusammen mit dem Modell seiner realen Umgebung im HiL-Simulator ausgeführt. Dabei wird das zu testende System über seine Eingänge stimuliert und die Ausgaben an den Ausgängen überprüft. Heartbeat Ein Heartbeat (deutsch wörtlich: Herzschlag) ist in der Informatik ein Signal zwischen zwei Elementen eines Systems, welches benachrichtigt, dass die Gegenseite betriebsbereit ist, um ihre Aufgaben erfüllen zu können.

Glossar

XXIX

Heatmap Eine Heatmap (deutsch wörtlich: Wärmekarte) ist eine Visualisierungsform von Werten einer zweidimensionalen Definitionsmenge. Die Werte werden als Farben repräsentiert und helfen, in einer großen Datenmenge markante Werte zu erfassen. Hodometer Das Hodometer (englisch: Odometer) ist ein Messgerät oder Sensor, welches die zurückgelegte Strecke eines Objektes aufzeichnet. NMEA 0183-Format Das NMEA 0183-Format ist ein Format, welches ursprünglich für die Kommunikation zwischen Navigationsgeräten auf Schiffen von der NMEA (National Marine Electronics Association) definiert wurde. Es wird heute insbesondere für die Kommunikation zwischen GPS-Empfängern (Global Positioning System) und angeschlossenen Endgeräten verwendet. Padding Mit Padding wird im Ethernet das Auffüllen eines Nutzdatenfelds mit zumeist zufälligen Daten bezeichnet. Padding wird verwendet, um die standardisierte minimale Paketgröße zu erreichen. Pareto-Optimum Das Pareto-Optimum ist eine mögliche Lösung eines Optimierungsproblems, bei der es unmöglich ist, eine ihrer Eigenschaften zu verbessern, ohne zugleich eine andere verschlechtern zu müssen. Die Pareto-Menge ist die Menge aller Pareto-Optima. Ein Pareto-Optimum kann, aber muss nicht das absolute Optimum eines Optimierungsproblems sein. Preemption Preemption bezeichnet in der Computertechnik das temporäre Unterbrechen einer Aufgabe auf einem System durch ein externes Ereignis, mit der Absicht, die Aufgabe später fortzusetzen. Prioritätsinversion Prioritätsinversion (englisch: priority inversion) bezeichnet in der Informatik ein Problem des Schedulings mit Prioritäten. Dabei benötigt ein hoch priorisierter Prozess eine Ressource, die durch einen niedrig priorisierten

XXX

Glossar

Prozess belegt ist. Ein mittel priorisierter Prozess kann dabei verhindern, dass der niedriger priorisierte Prozess weiterarbeiten und die Ressourcen freigeben kann. Der hoch priorisierte Prozess wird blockiert. Restbussimulation Bei der Restbussimulation wird die Kommunikation auf dem Bus durch einen Simulator emuliert. Auf diese Weise können Steuergeräte in einer frühen Phase, in der der Systemverbund noch nicht zur Verfügung steht, getestet werden. Round Trip Time Die Round Trip Time (deutsch: Paketumlaufzeit) bezeichnet die Reaktionszeit eines kompletten Netzwerks. Sie ist die Summe der Zeit, die benötigt wird, um ein Signal von einem Sender zu einem definierten Empfänger zu senden sowie die Zeit, die benötigt wird, um die Antwort des Empfängers zurück an den Sender zu vermitteln. Seed Seed (deutsch: Saat), auch Random-Seed, bezeichnet die Eingabe, die einen Zufallszahlengenerator initialisiert. Mit verschiedenen Seeds werden vom Zufallszahlengenerator unterschiedliche Folgen von Pseudozufallszahlen erzeugt. Topologie Mit Topologie wird in Datennetzen die Struktur der Verbindungen mehrerer Teilnehmer untereinander bezeichnet. Totzeit Die Totzeit (auch Laufzeit oder Transportzeit) bezeichnet die Zeitspanne zwischen Änderung am Systemeingang und Antwort am Systemausgang einer Regelstrecke. X-by-Wire X-by-Wire bezeichnet den Ersatz von mechanischen Verbindungen zur Steuerung durch die Leitung elektrischer, elektronischer, optoelektronischer oder optischer Steuersignale vom Bediener zum Aktuator.

Zusammenfassung Das Fahrzeugkommunikationsnetzwerk von Automobilen befindet sich derzeit in einem starken Wandel. Neue Anwendungen aus den Bereichen der Fahrerassistenzsysteme und des Infotainments sowie insbesondere das automatisierte und autonome Fahren haben einen weit höheren Bedarf an leistungsfähigen Kommunikationsverbindungen, als die bisher im Automobil eingesetzten Technologien garantieren können. Dies gilt insbesondere für neue Sensorik wie beispielsweise Kameras, Radar und Laser-Scanner, welche die Umwelt mit einem hohen Detailgrad aufzeichnen und dafür höhere Bandbreiten als bisherige Systeme übertragen müssen. Echtzeit-Ethernet ist die favorisierte Lösung für die Herausforderungen zukünftiger Fahrzeugnetzwerke; es wurden jedoch, trotz des Bekenntnisses großer Automobilhersteller zu Automotive-Ethernet, bisher keine umfassenden und auf realistischen Datenverkehrsmodellen basierenden Architekturanalysen durchgeführt. Die vorliegende Arbeit leistet einen Beitrag zum Design und zur Bewertung neuer Ethernet-basierter Fahrzeugnetzwerkarchitekturen. Sie liefert Werkzeuge für die simulationsbasierte Analyse und Beurteilung von Netzwerkarchitekturen und evaluiert anhand konkreter Anwendungen, beispielsweise aus dem Bereich der Sensorfusion, und realistischer auf realen Verkehrsdaten aufbauender Szenarien mögliche Netzwerkdesigns und Konfigurationen. Dabei wird auch der schrittweiser Übergang von Legacy-Technologien hin zu einem rein Echtzeit-Ethernet-basierten Fahrzeugnetzwerk berücksichtigt. Ein schrittweiser Migrationspfad ist eine wichtige Anforderung für einen erfolgreichen Einsatz im Automobil. Auf Basis der hierbei aus analytischen Modellen sowie Simulationsstudien und einem realen Fahrzeugprototyp gewonnenen Erkenntnisse werden Designempfehlungen für die Entwicklung zukünftiger Ethernet-basierter Fahrzeugnetzwerke ausgesprochen. Methodisch kommt in der vorliegenden Arbeit insbesondere die Netzwerksimulation zum Einsatz. Für die Bewertung neuer Fahrzeugnetzwerkarchitekturen werden Werkzeuge zur Simulation und Analyse zukünftiger heterogener Echtzeit-Ethernet-Backbones entwickelt. Damit stellt die Arbeit eine leistungsfähige Open-Source-Simulationsumgebung für die Analyse zukünftiger Fahrzeugnetzwerke bereit, welche in Forschung und Entwicklung frei ver-

XXXII

Zusammenfassung

wendet und weiterentwickelt werden kann. Mithilfe eines Prototypfahrzeugs werden die in der Simulation sowie in analytischen Modellen untersuchten Aspekte in einer realen Fahrzeugumgebung überprüft. Die Untersuchung im Prototyp weist die Realisierbarkeit der entwickelten Ansätze nach und zeigt auf, an welcher Stelle Herausforderungen und Handlungsbedarfe bei der Implementierung der entwickelten Konzepte bestehen. Die Ergebnisse der Untersuchung führen zu Designempfehlungen und Best Practices für zukünftige Backbone-Netzwerke im Automobil. Diese umfassen unter anderem das Kommunikationsdesign, den Einsatz von Echtzeitverkehrsklassen, die Optimierung von Hintergrunddatenverkehr und die Entwicklung geeigneter Netzwerktopologien. Es wird gezeigt, dass sich die im Backbone-Netzwerk erreichbaren Kennzahlen unter Einhaltung der Designempfehlungen um ein Vielfaches verbessern lassen.

Abstract Communication in car networks is currently undergoing a major change. New applications from the areas of advanced driver assistance, infotainment and in particular highly automated and autonomous driving foster the demand for high performance communication links that cannot be satisfied with legacy technologies such as CAN or FlexRay. New environmental sensors such as cameras, radar, or laser scanners raise bandwidth requirements in particular. Realtime Ethernet is the favoured solution to cope with these challenges of future in-car networks. Although large automobile companies confirm their interest in automotive Ethernet technologies, there are no comprehensive architectural analyses nor performance studies based on realistic in-car traffic models yet. This work contributes to the design and assessment of new Ethernet based in-car networks. It provides tools for the analysis and evaluation of architectures and assesses network configurations based on selected applications, such as sensor fusion, as well as communication patterns from realistic scenarios of real series cars. As a major result, design recommendations and best practices for the development of future in-car network architectures are given. Network simulation is particularly used throughout this work. A toolchain for simulating and analyzing new heterogeneous realtime Ethernet backbones is provided. This toolchain covers the gradual transition from today’s legacy technologies to a solely Ethernet based network. It provides an open source simulation environment capable of analyzing future in-car communication that can be used for research and development. By deploying a prototype car, the results from analytical models and simulation are examined in a real vehicular environment. It is shown that today’s fieldbus technologies can be transparently consolidated in a new communication architecture. The empirical study performed with the prototype proves that the developed approach is feasible and reveals the areas of further challenges and additional efforts in implementation. The results of the analytical model, the simulation and the study in the prototype result in design recommendations and best practices for a future backbone network in the automobile. The recommendations include, the

XXXIV

Abstract

communication design, the use of realtime traffic classes, the optimization of crosstraffic scenarios and the design of suitable network topologies. It is shown that a backbone network can significantly improve performance when complying to the recommended design rules.

1 Einführung Das Fahrzeugbordnetz hat sich in den vergangenen 100 Jahren stark gewandelt. Angefangen von einfachen Kabelbäumen für Zündung und Licht (siehe Abbildung 1.1) wie im Ford Model T [38], dem ersten fließbandgefertigten Personenkraftwagen, über die ersten Bussysteme wie dem CAN-Bus, der 1991 in der Mercedes S-Klasse als erstes Bussystem in ein seriengefertigtes Fahrzeug Einzug hielt [121], bis zu den heutigen Netzwerken, bestehend aus einer Vielzahl an Steuergeräten, verbunden über diverse Feldbus- und Kommunikationstechnologien.

Abbildung 1.1: Schaltplan Ford Model T, 1919 [38]

Heute ist das Kommunikationsbordnetz das Nervensystem des Fahrzeugs. Moderne Kraftfahrzeuge unterstützen die Fahrer mit einer Vielzahl von Fahrerassistenzsystemen. Etablierte Beispiele sind die ASR (Antriebsschlupfregelung) oder das ESP (Elektronisches Stabilitätsprogramm). Neue Ent© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 T. Steinbach, Ethernet-basierte Fahrzeugnetzwerkarchitekturen für zukünftige Echtzeitsysteme im Automobil, https://doi.org/10.1007/978-3-658-23500-0_1

2

1 Einführung

wicklungen gibt es im Bereich der X-by-Wire-Technologie1 . Viele tausend Sensorinformationen und Befehle an die Aktuatoren werden jede Sekunde übertragen. Eine Störung oder sogar ein vollständiger Defekt dieses Nervensystems führen vom Ausfall einzelner Funktionen bis zur kompletten Fahruntauglichkeit des Fahrzeugs. Insbesondere neue fortschrittliche Assistenzsysteme, sogenannte ADASs (Advanced Driver Assistance Systems), steigern den Bedarf an leistungsfähigen Kommunikationsverbindungen im Automobil. Diese neuen Assistenzsysteme verwenden Kamera-, Radar- oder LIDAR-Sensoren (LIght Detection And Ranging). Im Gegensatz zu den bisher im Fahrzeug genutzten Sensoren wie beispielsweise Ultraschall-, Drehraten- oder Beschleunigungssensoren arbeiten diese neuartigen Sensoren in mehreren Dimensionen und mit einer sehr hohen Auflösung. Dadurch erzeugen sie eine deutlich größere Datenmenge und benötigen für die Übertragung der Informationen vom Sensor zum verarbeitenden Steuergerät eine hohe Bandbreite. Bisher wurde aufgrund der niedrigen Bandbreite im Fahrzeugnetzwerk auf eine Übertragung von Sensorrohdaten verzichtet. Die Informationen wurden direkt im Sensor verarbeitet, sodass nur die erkannten Objekte über die vorhandenen Feldbusse übertragen werden mussten. Um bessere Ergebnisse in der Umfelderkennung zu erzielen, werden jedoch zukünftig Sensorfusionssysteme eingesetzt, welche die Daten verschiedener Sensoren kombinieren (fusionieren) [139]. Diese sind auf die effiziente Übertragung der Sensorrohdaten angewiesen. Auch durch die Zunahme von Funktionen steigen die Anforderungen an das Fahrzeugbordnetz. In Oberklassefahrzeugen werden heute bereits bis zu 100 elektronische Steuergeräte, sogenannte ECUs (Electronic Control Units), welche über mehrere hundert unterschiedliche Botschaften tausende Signale untereinander austauschen, eingesetzt [63]. Folglich sind heutige Fahrzeuge komplexe verteilte Echtzeitsysteme, deren Kommunikationsflüsse zwischen den verteilten Modulen einen signifikanten Einfluss auf ihre Zuverlässigkeit sowie die Sicherheit und den Komfort der Fahrzeuginsassen haben.

1 X-by-Wire

bezeichnet den Ersatz von mechanischen Verbindungen zur Steuerung durch die Leitung elektrischer, elektronischer, optoelektronischer oder optischer Steuersignale vom Bediener zum Aktuator.

1.1 Motivation

3

1.1 Motivation Die Steigerung des Bedarfs an leistungsfähigen Kommunikationsverbindungen wird sich auch in den kommenden Jahren, insbesondere mit neuen Anforderungen aus dem Bereich des hochautomatisierten (HAD (Highly Automated Driving)) und autonomen Fahrens, fortsetzen und sogar noch verstärken. Insbesondere das (teil-)autonome Fahren wird die Anzahl an Sensoren im Fahrzeug steigern und, verglichen mit dem heutigen Stand, umfangreichere Kommunikation erfordern. Zudem zeigt sich bereits heute, dass Systeme zur Realisierung neuer Funktionen im Fahrzeug immer enger miteinander vermascht werden, wodurch der Bedarf an leistungsfähigen und zuverlässigen Kommunikationstechnologien wächst. Daten, welche zuvor nur isoliert in ihrer speziellen Funktionsdomäne verwendet wurden, werden zukünftig auch in zunächst unverwandten Funktionsbereichen aggregiert und zur Realisierung neuer Funktionalität zusammengestellt. Es sind neue Entwürfe notwendig, welche diesen stetig wachsenden Anforderungen gerecht werden können. Bereits seit einigen Jahren beobachtet die Automobilindustrie die Entwicklungen rund um die Ethernet-Technologie, um einen Ausweg aus den Engpässen der bisher eingesetzten Feldbusarchitekturen zu finden. So suchte BMW (Bayerische Motoren Werke AG) bereits 2004 eine Lösung, um das Übertragen der Fahrzeugsoftware zu beschleunigen. Das Übertragen der gesamten, zu der Zeit bereits über 1 GB umfassenden Systemsoftware, dauerte über ein CAN-Bus-Interface etwa 16 Stunden. Daher kam bereits im Jahr 2008 das erste Serienfahrzeug mit einer 100BASE-TX Ethernet-Verbindung auf den Markt [103]. Die fehlende Unterstützung von harten Echtzeitanforderungen sowie die teure Verkabelung, mit Leitungen aus verdrillten und geschirmten Aderpaaren, verhinderte zunächst jedoch eine schnelle Adaption der Ethernet-Technologie für Anwendungen im bewegten Fahrzeug. Bedeutung bekam das Thema Ethernet für das Automobil mit der Präsentation der BroadR-Reach-Technologie (jetzt IEEE-Standard (Institute of Electrical and Electronics Engineers) 802.3bw [67]) durch die Firma Broadcom. BroadR-Reach versprach die bidirektionale Übertragung von 100 Mbit/s über ein einziges verdrilltes und ungeschirmtes Aderpaar und damit über vergleichbare Leitungen, wie sie bis dahin für die Verkabelung von Feldbussen eingesetzt wurden. Schon in der aktuellen Fahrzeuggeneration hat Ethernet, als neue zusätzliche Kommunikationstechnologie, Einzug in das Fahrzeugnetz gehalten. Aktuelle Oberklassefahrzeuge nutzen Ethernet zur Übertragung der Bild-

4

1 Einführung

Instrumente

Instrumenten CAN

Diagnose CAN

Diagnose

Zentrales Gateway

Infotainment MOST

Fahrwerk FlexRay LIN

LIN

Komfort CAN

Abbildung 1.2: Beispielhafte Netzwerkarchitektur mit verschiedenen Kommunikationstechnologien und zentralem Gateway (eigene Darstellung nach [121])

ströme von Videokameras [103], da es preisgünstiger ist als eine proprietäre Lösung auf Basis von LVDS (Low Voltage Differential Signaling). Durch die Erweiterung des Technologiespektrums um Ethernet als weitere Kommunikationslösung im Fahrzeugnetz steigt jedoch gleichzeitig die Heterogenität und damit ebenfalls die Komplexität der Bordnetzarchitektur weiter an. Bereits vor der Einführung von Ethernet bestand das Fahrzeugbordnetzwerk aus diversen domänenspezifischen Bussystemen, wie beispielsweise CAN, FlexRay oder MOST (Media Oriented System Transport), welche über sogenannte Gateways miteinander gekoppelt sind (siehe Abbildung 1.2). Diese heterogene Struktur steht schon seit einigen Jahren in der Kritik: „Eigentlich ist das

1.1 Motivation

5

Bordnetz im Gesamtfahrzeug bereits heute nicht mehr vernünftig zu beherrschen“ (Richard Bogenberger, BMW Group Forschung und Technik [26]). Um die derzeitige Komplexität signifikant zu reduzieren, bedarf es neuer Architekturansätze für ein zukünftiges homogenes Kommunikationsbordnetz im Automobil. Ein solcher Ansatz ist der Echtzeit-Ethernet-Backbone2 , eine leistungsfähige zentrale Kommunikationsinfrastruktur mit hoher Bandbreite, welche sich flexibel auf die Anforderungen der Anwendungen im Fahrzeug anpassen lässt. Die Bemühungen um den Einsatz von Ethernet in Automobilen werden üblicherweise unter der Bezeichnung Automotive3 Ethernet zusammengefasst. Dieser durch die Automobilindustrie geprägte Begriff ist irreführend, da er nicht zwischen den verschiedenen OSI-Layern (Open Systems Interconnection) unterscheidet, sondern alle Ansätze, welche für die Nutzung von Ethernet im Fahrzeug notwendig sind — wie beispielsweise ein automobilgeeignetes physikalisches Layer, aber gleichzeitig auch Ansätze des QoS (Quality-of-Service) und Traffic Shapings — umfasst. Damit steht der Begriff Automotive Ethernet in der Tradition der heutigen Feldbustechnologien, welche ebenfalls über mehrere OSI-Layer spezifiziert sind. Während sich insbesondere die großen deutschen OEMs (Original Equipment Manufacturers) zum zukünftigen Einsatz von Automotive Ethernet bekennen und zum Teil in Projekten bereits erste Evaluierungen verschiedener Technologien und Aspekte durchgeführt haben, liegt die konkrete Ausgestaltung zukünftiger Fahrzeugnetzwerkarchitekturen noch im Dunkeln. Mit der vorliegenden Arbeit wird ein Beitrag zum Design und zur Bewertung dieser neuen Architekturen geleistet. Sie stellt die Werkzeuge für die Analyse und Beurteilung von Netzwerkarchitekturen bereit und evaluiert anhand realistischer, auf realen Fahrzeugdaten aufbauender Szenarien mögliche Netzwerkdesigns und Konfigurationen. Auf Basis der hierbei aus analytischen sowie Simulationsmodellen und einem realen Fahrzeugprototyp gewonnenen Erkenntnisse werden Best Practices entwickelt und Designempfehlungen ausgesprochen, welche bei der Entwicklung zukünftiger Ethernet-basierter Fahrzeugnetzwerke berücksichtigt werden sollten, um die volle Leistungsfähigkeit des Echtzeit-Ethernet-Backbones auszunutzen.

2 Backbone

(deutsch: Rückgrat, Hauptstrang, Basisnetz) bezeichnet den zentralen Kernbereich eines Telekommunikationsnetzes. 3 Automotive ist ein Oberbegriff für maschinenangetriebene Fahrzeuge.

6

1 Einführung

1.2 Problemstellung Der Begriff Netzwerkarchitektur wird oft fälschlich als Synonym für die Topologie4 — der (physikalischen) Struktur eines Netzwerks — verwendet. Der Begriff ist jedoch viel weiter gefasst und schließt jegliche Struktur ein, die aus funktionaler, logischer und technischer Sicht eine Auswirkung auf (insbesondere) Soft- und Hardware, aber auch andere Aspekte wie beispielsweise Deployment und Scheduling, besitzt [111]. Eine Fahrzeugnetzwerkarchitektur umfasst somit unter anderem: • Kommunikationstechnologien • QoS-Strategien • Netzwerkkonfigurationen • Scheduling-Strategien • Protokolle und Anwendungen • Einbindung von Legacy-Technologien Derzeit umfasst der Begriff Automotive Ethernet eine Sammlung von Technologiezweigen und Ansätzen. Einige davon, wie beispielsweise Frame Preemption5 , also das Unterbrechen von niedrig priorisierten Ethernet Frames, sind so neu, dass bisher keine Erfahrungen im Automobilkontext bestehen. Andere Aspekte wurden bereits in verwandten Forschungsarbeiten untersucht (siehe Abschnitt 2.2 auf Seite 43). Wie diese Technologien allerdings für den Einsatz im Automobil zusammen komponiert werden müssen, ist bisher noch unbetrachtet. Insbesondere das Zusammenspiel verschiedener Aspekte einer Fahrzeugnetzwerkarchitektur wurde bisher nicht evaluiert. Ein Konzept für eine komplette Architektur besteht somit bisher nicht. Im Gegensatz zu den heute eingesetzten Feldbussen, welche diverse Aspekte einer Netzwerkarchitektur in einer Technologie bündeln und dadurch den Freiheitsgrad bei der Entwicklung beschränken, werden zukünftige Ethernet-basierte Architekturen eine Komposition aus diversen Bausteinen ermöglichen. Dies wird das Fahrzeugnetzwerk flexibel und für verschiedene 4 Mit

Topologie wird in Datennetzen die Struktur der Verbindungen mehrerer Teilnehmer untereinander bezeichnet. 5 Preemption bezeichnet in der Computertechnik das temporäre Unterbrechen einer Aufgabe auf einem System durch ein externes Ereignis, mit der Absicht, die Aufgabe später fortzusetzen.

1.3 Zielsetzung, Forschungsansatz und methodisches Vorgehen

7

Anwendungen adaptierbar machen, jedoch gleichzeitig der Entwicklung und Evaluierung eine große Verantwortung zuweisen. Während heute nur wenige Parameter und Regeln bei der Entwicklung und Auslegung eines Netzwerks zu beachten sind, werden zukünftige Netzwerkkonfigurationen mit einer sehr hohen Anzahl an Dimensionen behaftet sein. Fahrzeugnetzwerkentwickler benötigen daher leistungsfähige Werkzeuge, welche in einem sehr frühen Stadium der Entwicklung eingesetzt werden können, um Netzwerkarchitekturen zu bewerten.

1.3 Zielsetzung, Forschungsansatz und methodisches Vorgehen Entsprechend der dargestellten Problemstellung ist das Ziel der vorliegenden Arbeit die Entwicklung und Bewertung neuer Echtzeit-Ethernet-basierter Backbone-Architekturen. Dabei wird untersucht, welche neuen Architekturvarianten durch einen Fahrzeug-Backbone möglich werden, und wie die dargestellten Probleme heute eingesetzter Fahrzeugnetzwerke gelöst werden können. Darüber hinaus steht die Frage, wie die heute genutzten Feldbustechnologien transparent in eine neue Kommunikationsarchitektur integrierbar sind, im Fokus der Untersuchungen. Anhand konkreter Anwendungen, beispielsweise aus dem Bereich der Sensorfusion und auf Basis realer Fahrzeugdaten, wird die Eignung von EchtzeitEthernet in Fahrzeugnetzen überprüft. Dafür werden zunächst die für die Fahrzeugkommunikation relevanten Netzwerkmetriken sowie die aus den Anwendungen abgeleiteten Anforderungen definiert oder aus bestehenden Spezifikationen ermittelt. Um eine realistische Bewertungsgrundlage zu erhalten, werden zwei aus Serienfahrzeugen abgeleitete Datenverkehrsmodelle entwickelt. Diese beschreiben die in einem Automobil auftretenden Nachrichtenströme und erlauben die Generierung von realistischen Verkehrsmustern in der Simulation. Die Datenverkehrsmodelle sind eine Voraussetzung für die realitätsnahe Evaluierung und sind notwendig, um sicherzustellen, dass die Ergebnisse aus der Bewertung in der Praxis anwendbar sind. In der vorliegenden Arbeit werden die verschiedenen Aspekte und Komponenten Ethernet-basierter Fahrzeugnetzwerkarchitekturen definiert und konkurrierende Technologien einander gegenübergestellt. Methodisch kommt in den durchgeführten Untersuchungen insbesondere die Netzwerksimulation zum Einsatz. Für die Bewertung neuer Fahrzeugnetzwerkarchitekturen werden Werkzeuge zur Simulation von Echtzeit-Ethernet-

8

1 Einführung

Backbones und Feldbus-Ethernet-Gateways benötigt. Ziel der vorliegenden Arbeit ist daher auch, eine leistungsfähige Simulationsumgebung für die Analyse zukünftiger Fahrzeugnetzwerke in Forschung und Entwicklung bereitzustellen. Es wird eine Umgebung entwickelt, welche die Simulation von Echtzeit-Ethernet-basierten, aber auch heterogenen, aus Feldbussen und Ethernet kombinierten Fahrzeugarchitekturen erlaubt. Auf Basis dieser Simulationsumgebung werden verschiedene Echtzeit-Ethernet-Protokolle, wie beispielsweise Ethernet AVB (Audio Video Bridging), TTEthernet (timetriggered Ethernet) oder TSN (Time-Sensitive Networking), auf ihre Eignung für den Einsatz im Automobil untersucht und miteinander verglichen. Darüber hinaus werden Strategien für die Anbindung heutiger Fahrzeugbusse wie dem CAN-Bus oder FlexRay mithilfe von Feldbus-Ethernet-Gateways entwickelt und überprüft. Anschließend werden die zuvor evaluierten Protokolle und Komponenten in verschiedenen Netzwerktopologien vereint und in ihrer Gesamtheit als Fahrzeugnetzwerkarchitekturen bewertet. Ausgewählte Ergebnisse der Simulation werden anhand eines realen Prototypfahrzeugs auf Basis des Volkswagen Golf 7 in einer empirischen Untersuchung überprüft. Dabei dient das Versuchsfahrzeug nicht nur als Nachweis für die zuvor in der Simulation ermittelten Ergebnisse, sondern ergänzt diese um Aspekte, welche in der Simulation nicht oder nur mit großem Aufwand zu ermitteln sind. So lassen sich im Prototyp neben den in realen Fahrsituationen auftretenden Kenngrößen auch weiche Metriken wie beispielsweise Aufwand oder Komplexität der Implementierung untersuchen und überprüfen. Die Untersuchung im realen Prototyp weist die Realisierbarkeit der entwickelten Ansätze nach und zeigt auf, an welcher Stelle Herausforderungen und Handlungsbedarfe bei der Implementierung der präsentierten Konzepte bestehen. Aufgrund der Vielzahl an möglichen Parametern kann keine allgemein gültige und optimale Architektur für jedes zukünftige Fahrzeugnetzwerk entwickelt werden. Die vorliegende Arbeit untersucht den Einfluss verschiedener Technologien und Parameter und spannt damit den Lösungsraum, innerhalb dessen eine optimale Architektur liegt, auf. Aus den Ergebnissen der Bewertung in der Simulation und des Prototyps werden Designempfehlungen und Best Practices entwickelt, welche Entwickler bei der Gestaltung zukünftiger Architekturen unterstützen. Da eine Fahrzeugarchitektur stets auf den konkreten Anwendungsfall angepasst werden muss, können dabei jedoch keine generellen Richtlinien für eine optimale Architektur gegeben werden. Vielmehr werden verschiedene Ansätze und Richtwerte aufgezeigt, welche geeignet sind, in der Designphase Probleme im Fahrzeugnetzwerk zu verhindern oder die zu erreichenden Netzwerkmetriken zu verbessern.

1.3 Zielsetzung, Forschungsansatz und methodisches Vorgehen

9

Im Rahmen der vorliegenden Arbeit werden eine Vielzahl individueller Forschungsfragen beantwortet. Diese sind stets eingebettet in die Gesamtfragestellung zum Design und der Bewertung zukünftiger Echtzeit-Ethernetbasierter Fahrzeugnetzwerke. Es wird untersucht, wie Echtzeitkommunikation im Fahrzeugnetzwerk auf Basis der Ethernet-Technologie realisiert werden kann und welche neuartigen Topologien dadurch möglich werden. Dabei wird auch der schrittweise Übergang von Legacy-Technologien hin zu einem Ethernet Backbone berücksichtigt. In der Simulation werden die Netzwerkmetriken und Grenzen heutiger feldbusbasierter Architekturen ermittelt. Auf Basis realer Verkehrsdaten werden time-triggered und event-triggered Echtzeit-Ethernet-Protokolle für den Einsatz in verschiedenen Domänen der Fahrzeugkommunikation untersucht und verglichen. Dabei wird auch die gegenseitige Beeinflussung von Datenverkehrsströmen unterschiedlicher Verkehrsklassen innerhalb einer geteilten Infrastruktur sowie der Einfluss von niedrig priorisiertem Hintergrunddatenverkehr auf die zu erreichenden Netzwerkmetriken ermittelt. Es wird untersucht, wie die Echtzeiteigenschaften event-basierter Verkehrsklassen durch Frame Preemption verbessert werden können und welche Änderungen am Preemption-Standard geeignet sind, um die Netzwerkmetriken der Kommunikation im Fahrzeug zu optimieren. Zudem wird ermittelt, wie sich Echtzeit-Ethernet-Traffic-Shaper und Transportprotokolle gegenseitig beeinflussen und welche Protokollkombinationen sich für den Einsatz im Fahrzeug eignen. Tabelle A.1 im Anhang A (Seite 287) gibt einen Überblick über die individuellen Forschungsfragen mit einem Verweis auf das jeweilige Kapitel. Die vorliegende Arbeit war eingebettet in das RECBAR-Forschungsprojekt (Realtime Ethernet Backbones for Cars). Das Projekt war ein über die Dauer von drei Jahren vom BMBF (Bundesministerium für Bildung und Forschung) gefördertes Forschungsprojekt (Förderkennzeichen 03FH023PX2). Projektpartner im RECBAR-Projekt waren: HAW Hamburg (Hochschule für Angewandte Wissenschaften), IAV (Ingenieurgesellschaft Auto und Verkehr), OFFIS e.V. Oldenburg, Heinz Nixdorf Institut der Universität Paderborn und Ibeo Automotive Systems GmbH. Die Projektlaufzeit war von September 2012 bis November 2015. Das Ziel von RECBAR war, den Technologiewechsel von aufgabenspezifischen heterogenen Bussystemen zu intelligenten domänenübergreifenden Vermittlungsinfrastrukturen im Automobil zu untersuchen. Zur Erreichung dieses Zieles sollten Techniken und Methoden zum Entwurf von skalierbaren, strukturierbaren und auf Standardkomponenten aufbauenden Vermittlungsinfrastrukturen konzipiert und entwickelt werden.

10

1 Einführung

1.4 Aufbau der Arbeit Im Kapitel 2 wird der Hintergrund zu den für die vorliegende Arbeit relevanten Technologien sowie der Stand der Technik und Wissenschaft zusammengefasst. Nachdem die heute im Fahrzeugnetzwerk verwendeten Technologien sowie Ethernet und insbesondere die für den Einsatz im Automobil infrage kommenden Echtzeiterweiterungen vorgestellt und erläutert werden, gibt der Stand der Wissenschaft Einblick in die bisher auf diesem Gebiet durchgeführten Forschungsprojekte und Veröffentlichungen. In Kapitel 3 werden die verschiedenen zur Bewertung stehenden Elemente der Fahrzeugnetzwerkarchitektur gegenübergestellt. Dafür werden zunächst die Anforderungen an Fahrzeugnetzwerke und Netzwerkmetriken zur Bewertung definiert. Anschließend werden die im Rahmen dieser Arbeit verwendeten Datenverkehrsmodelle definiert. Es wird ein Überblick über mögliche Topologievarianten sowie Kommunikationstechnologien und -strategien gegeben, als auch Architekturen für die transparente Anbindung von Legacy-Technologien entwickelt. Kapitel 4 beschreibt die Bewertung von Fahrzeugnetzwerkarchitekturen in der Simulation. Zunächst wird die DES (Diskrete ereignisbasierte Simulation) sowie die für die Simulation verwendete Plattform OMNeT++ (Objective Modular Network Testbed in C++) vorgestellt. Im Anschluss daran werden die für die zur Evaluierung von Fahrzeugnetzwerken entwickelten Simulationskomponenten und Werkzeuge beschrieben. Das Kapitel umfasst verschiedene Abschnitte mit Simulationsstudien zu Echtzeit-Ethernet-Protokollen, Traffic Shaping, dem Einfluss von Hintergrunddatenverkehr in Fahrzeugnetzwerken, Preemption-Lösungen sowie Transportprotokollen, und schließt mit der Untersuchung mehrerer Gesamtfahrzeugarchitekturen, welche die Ergebnisse der vorherigen Teiluntersuchungen in einem Gesamtsystem zusammenfassen. In Kapitel 5 wird die Evaluierung der Echtzeit-Ethernet-Backbone-Architektur im Versuchsfahrzeug gezeigt. Zunächst wird der Ablauf der Evaluierung im Versuchsfahrzeug sowie das als Basis dienende Serienfahrzeug beschrieben. Anschließend folgt ein Überblick über die für das Versuchsfahrzeug entwickelten Komponenten und deren Implementierung. Das Kapitel schließt mit den Ergebnissen aus der Evaluierung des Echtzeit-EthernetBackbones im Versuchsfahrzeug. Die aus den Evaluierungen gewonnenen Erkenntnisse werden in Kapitel 6 zusammengefasst und in Designempfehlungen und Best Practices für zukünftige switchbasierte Fahrzeugnetzwerke überführt. Abschließend fasst Kapitel 7 die Ergebnisse der vorliegenden Arbeit zusammen und gibt Ausblick auf zukünftige Forschungsfragen.

2 Stand der Wissenschaft und Technik Im Folgenden wird der zum Verständnis von Fahrzeugnetzwerkarchitekturen notwendige Hintergrund zum Stand der Technik (Abschnitt 2.1) sowie die relevanten Ergebnisse aus der Wissenschaft und der industriellen Forschung (Abschnitt 2.2 auf Seite 43) dargestellt.

2.1 Stand der Technik Nachdem in diesem Abschnitt die heute eingesetzten Kommunikationstechnologien im Fahrzeug als Grundlage für eine zukünftige Echtzeit-Ethernetbasierte Lösung vorgestellt wurden (Abschnitt 2.1.1), werden die Grundlagen zur Ethernet-Technologie (Abschnitt 2.1.2 auf Seite 22) sowie den verfügbaren Echtzeit-Ethernet-Protokollen (Abschnitt 2.1.3 auf Seite 27) dargestellt.

2.1.1 Heutige Fahrzeugnetzwerktechnologien Heute realisieren Feldbusse die Kommunikation der Systeme im Fahrzeug. Dabei kann sich die Kommunikation auf eine bestimmte Anwendungsdomäne, beispielsweise auf das Fahrwerk oder das Entertainment-System, beschränken oder über die Domänengrenzen hinweggehen. Ein solches domänenübergreifendes Kommunikationsbeispiel ist das Signal des Hodometers1 , welches in der Fahrwerkdomäne aufgezeichnet, aber beispielsweise für die Navigation in der Infotainment-Domäne genutzt wird. Momentan werden eine Vielzahl verschiedener Technologien verwendet, um Anwendungen im Fahrzeug miteinander zu vernetzen. Die SAE (Society of Automotive Engineers) teilt diese Kommunikationslösungen anhand ihrer Bitrate in vier Klassen ein. Tabelle 2.1 auf der nächsten Seite gibt einen Überblick über die Zuordnung der Technologien zu den SAE-Klassen und einige typische Anwendungsgebiete [121, 167, 120]. 1 Das

Hodometer (englisch: Odometer) ist ein Messgerät oder Sensor, welches die zurückgelegte Strecke eines Objektes aufzeichnet.

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 T. Steinbach, Ethernet-basierte Fahrzeugnetzwerkarchitekturen für zukünftige Echtzeitsysteme im Automobil, https://doi.org/10.1007/978-3-658-23500-0_2

12

2 Stand der Wissenschaft und Technik

Tabelle 2.1: SAE-Klassifikation von Kommunikationslösungen [121, 167, 120] SAE Klasse

Bitrate [kbit/s]

Typische Technologie

Typische Anwendung

A B C C+ D

< 25 25 bis 125 125 bis 1000 ≥ 1000 ≥ 10 000

LIN CAN (Low Speed) CAN (High Speed) FlexRay MOST, Ethernet

Vernetzung Sensoren/Aktuatoren Steuergeräte z.B. Komfortbereich Steuergeräte z.B. Antriebsstrang X-by-Wire, erweiterte Echtzeit Multimedia (Audio, Video)

Im Folgenden werden die für die Vernetzung von Steuergeräten genutzten Technologien CAN (Seite 12), FlexRay (Seite 15), MOST (Seite 19) und LVDS (Seite 21) vorgestellt, ihre Eigenschaften erläutert und Anwendungsgebiete aufgezeigt. Busse für die Vernetzung von Sensorik und Aktorik, wie beispielsweise PSI 5 (Peripheral Sensor Interface) oder der LIN-Bus (Local Interconnect Network), liegen nicht im Fokus der vorliegenden Arbeit und werden daher nicht vorgestellt. CAN-Bus (Controller Area Network) Der CAN-Bus (Controller Area Network), ab Mitte der achtziger Jahre bei der Firma Bosch entwickelt, war im Jahr 1991 das erste Bussystem, welches in einem Serienfahrzeug eingesetzt wurde [167]. CAN ist ISO- (International Organization for Standardization) (ISO 11898 [85]) und SAE-standardisiert (J2284 [130]). Es gibt CAN-Konfigurationen mit unterschiedlichen Geschwindigkeiten. Der High-Speed-CAN arbeitet mit Bitraten von 125 kbit/s bis 1 Mbit/s. LowSpeed-CAN bietet Bitraten von 5 kbit/s bis 125 kbit/s. Ursprünglich wurde der High-Speed-CAN für Motorsteuerung und Fahrwerkanwendungen, also für Bereiche, in denen Daten mit einer hohen Frequenz übertragen werden müssen, verwendet. Der Low-Speed-CAN wurde in den übrigen Domänen genutzt [121]. Mittlerweile sind jedoch alle Domänen so weit ausgelastet, dass in der Praxis fast ausschließlich der High-Speed-CAN bei einer Bitrate von 500 kbit/s eingesetzt wird [163]. CAN arbeitet nachrichtenorientiert mit durch eindeutige ID (Identifikator) adressierten Botschaften. Damit werden in CAN nicht Teilnehmer adressiert, sondern der Nachrichteninhalt. Es findet sogenanntes Content-based addressing statt. Da CAN als Bus organisiert ist, können grundsätzlich alle Teilnehmer eine Botschaft empfangen. Anhand der ID entscheidet jeder Teil-

2.1 Stand der Technik

13

nehmer selbständig, ob eine Botschaft für seine jeweilige Anwendung benötigt wird [120]. Standard-CAN ist ein Multi-Master-System. Alle Teilnehmer sind grundsätzlich gleichberechtigt; es gibt keine besonders ausgewiesenen Knoten, welche die Kommunikation steuern. CAN verwendet das CSMA/CA-Verfahren (Carrier Sense Multiple Access/Collision Avoidance). Die sogenannte Arbitrierungsphase löst Kollisionen durch gleichzeitig versendete Nachrichten auf. Dazu beobachten die sendenden Teilnehmer während der bitweisen Übertragung der NachrichtenID den Bus. Die Botschaft mit der niedrigeren ID ist in CAN höher priorisiert und darf als erstes gesendet werden. Dies wird durch die definierten Buspegel, Low (dominant/überstimmend) und High (rezessiv/nachgebend), ermöglicht. Wird durch einen Sender ein High-Bit und durch einen weiteren Sender ein Low-Bit versendet, setzt sich auf dem Bus stets das Low-Bit durch [120]. Das Arbitrierungsverfahren von CAN ermöglicht eine sehr feine Abstufung der Prioritäten von Nachrichten. Jeder Botschaft ist ihre eigene Priorität zugeordnet. In der Praxis ist der Nachteil dieser Eigenschaft, dass die Prioritäten fest an die Botschafts-ID gebunden sind. Es ist schwierig, in einem stark ausgelasteten ID-Bereich neue Botschaften unterzubringen, ohne bereits festgelegte IDs nachträglich zu verändern. Somit ist die vorausschauende Vergabe von Nachrichten-IDs und das Einplanen von Reserven wichtig. Grundsätzlich gibt es im CAN drei Nachrichtentypen: • Datentelegramm (Data Frame) • Anforderungstelegramm (Remote Frame) • Fehlertelegramm (Error Frame) Der wichtigste Typ in Automobilnetzwerken ist das Datentelegramm zur Übertragung von Daten an einen oder mehrere Empfänger. Das seltener genutzte Anforderungstelegramm wird durch den Empfänger einer Botschaft ausgesendet und löst das Versenden zugehöriger Daten beim Sender aus. Mit Fehlertelegrammen können auf dem Bus erkannte Fehler signalisiert werden [120]. Abbildung 2.1 auf der nächsten Seite zeigt das Format von CAN Frames. CAN-Botschaften werden mit einem dominanten Bit, dem SoF (Start of Frame) eingeleitet. Anschließend folgt das Arbitrierungsfeld, bestehend aus der Nachrichten-ID und dem RTR-Bit (Remote Transmission Request), welches anzeigt, ob es sich um ein Daten- oder Anforderungstelegramm handelt. Es folgt ein Bit, welches angibt, ob der Frame nach 2.0A oder 2.0B kodiert ist. Im CAN 2.0B-Standard folgt der Rest der ID und der Ersatz für

14

2 Stand der Wissenschaft und Technik

Layer 1

CAN Paket: 44 bit bzw. 64 bit bis 108 bit bzw. 128 bit (und zusätzliches Bitstuffing) Layer 2

CAN Frame: 34 bit bzw. 54 bit bis 98 bit bzw. 118 bit CAN Header: 18 bit bzw. 36 bit

Start of Frame

ID

Remote

1 bit

11 bit

1 bit

ID Reser- ReserLänge ID (B) Remote Ext. viert viert

Nutzdaten

1 bit 18 bit

0 B bis 8 B 15 bit

1 bit

1 bit

1 bit

4 bit

CRC

Inter CRC ACK End of Frame ACK Delim. Delim. Frame Space 1 bit

1 bit

1 bit

7 bit

3 bit

Abbildung 2.1: CAN (2.0A bzw. 2.0B) Frame-Format (eigene Darstellung)

das RTR-Bit (das erste RTR-Bit wird in 2.0B nicht genutzt). Sowohl in der A-, als auch in der B-Spezifikation folgen reservierte Bits. Anschließend kommt das vier Bit große Längenfeld, welches die Bytelänge im Payload angibt. Damit ist der CAN Header abgeschlossen. Es folgt der Botschaftsinhalt (Payload — 0 B bis 8 B) und Prüfinformationen (CRC (Cyclic Redundancy Check)). Der Eingang einer Botschaft wird durch die Empfänger mit einem dominanten Pegel im ACK-Feld quittiert. Den Abschluss bilden sieben rezessive Bits im EoF (End of Frame) und eine Ruhephase des Busses von mindestens drei weiteren rezessiven Bits [120]. Auf dem physikalischen Layer wird die NRZ-Kodierung (Non Return to Zero) verwendet. Dabei besteht die Gefahr, dass lange Folgen von gleichen Bits (rezessiv oder dominant) zum Verlust der Synchronisation der Abtastung führen. CAN verhindert dies durch ein Bitstuffing-Verfahren mit der Stuffweite fünf. Dabei wird nach fünf gleichen Bitwerten ein komplementäres Bit eingefügt. Dadurch werden künstliche Flanken im Signal erzeugt, die zur Nachsynchronisierung verwendet werden können [120]. Der Nachteil dieses Verfahrens ist, dass die Übertragungsdauer einer Nachricht nicht nur von der Payload-Größe, sondern ebenfalls vom Inhalt abhängt. So schwankt auf einem CAN-Bus mit 500 kbit/s die Übertragungszeit eines 2.0B Frames mit 8 B Nutzdaten zwischen 262 μs und 320 μs [167]. TTCAN (Time-triggered Controller Area Network): Mit TTCAN (Timetriggered Controller Area Network) (ISO 11898-4 [82]) existiert eine zeitgesteuerte TDMA-Variante (Time Division Multiple Access) des CAN-Bus. Dabei sendet ein spezieller Teilnehmer im Netzwerk, der sogenannte Time Master, periodisch eine Nachricht aus. Anhand des Empfangszeitpunkts dieser Botschaft synchronisieren sich alle Teilnehmer im Netzwerk. Die Zeit zwischen diesen periodischen Synchronisierungsbotschaften wird in Zeitschlitze unterteilt, die den Netzwerkteilnehmern zugewiesen werden. Jeder Teilnehmer darf ausschließlich in den ihm zugeordneten Zeitschlitzen sen-

2.1 Stand der Technik

15

den. Damit kann eine vollständig deterministische Kommunikation erreicht werden [87]. Die CSMA/CA-Fähigkeit des CAN bleibt auch beim TTCAN bestehen, wird aber durch das TDMA-Verfahren nicht mehr genutzt. Es können jedoch auch freie Zeitfenster mit Zugriff auf Basis von CSMA/CA geplant werden [120]. TTCAN konnte sich im Automobil nicht durchsetzen. Für zeitgesteuerte Kommunikation wird heute insbesondere der FlexRay-Bus eingesetzt (siehe Seite 15). CAN FD (Flexible Data rate): Da der CAN-Bus zunehmend die Bandbreitenanforderungen, insbesondere der Domänen Fahrwerk und Antrieb, nicht mehr erfüllen kann, wurde der CAN-Bus mit flexibler Datenrate (CAN FD (Flexible Data rate)) entwickelt. CAN FD ist eine Weiterentwicklung des CAN-Bus von Bosch. Eine erste Spezifikation steht seit 2012 zur Verfügung. Die zur Verfügung stehende Bandbreite wird in CAN FD gesteigert, indem größere Botschaften erlaubt werden (bis zu 64 B Nutzdaten) und die Bitrate erhöht wird. Allerdings begrenzen die bitweise Arbitrierung und die Bestätigung (Acknowledge) weiterhin die maximal mögliche Bitrate. Innerhalb dieser Felder muss unter Berücksichtigung der Buslänge und Signallaufzeit jedes Bit zuverlässig erkannt werden. Daher wird zunächst weiterhin mit den Standard-CAN-Bitraten übertragen. Erst das eigentliche Nutzdatenfeld und die CRC-Prüfsumme werden mit einer höheren Bitrate versendet. Das Ändern der Bitrate wird im CAN Header durch ein neues BRS-Kontrollfeld (Bit Rate Switch) angekündigt. Es werden Bitraten bis 4 Mbit/s angestrebt [167]. Damit kann CAN FD nur als vorübergehende Lösung zur Verhinderung von Bandbreitenengpässen angesehen werden. FlexRay-Bus Das FlexRay-Konsortium wurde 1999 durch BMW und DaimlerChrysler gegründet, mit dem Ziel, eine neue Feldbustechnologie zu entwickeln, welche den steigenden Anforderungen an Bandbreite und Übertragungssicherheit [120], auch vor dem Hintergrund neuer X-by-Wire-Anwendungen [103], gerecht wird. Die Spezifikation durch das FlexRay-Konsortium und die ISOStandardisierung [83] nahm eine lange Zeit in Anspruch. Die Einführung von FlexRay verzögerte sich daher stark und die Resonanz war zunächst zurückhaltend [103]. Heute wird es als Ergänzung zu CAN von einigen Fahrzeugherstellern eingesetzt. Es konnte den CAN-Bus jedoch nicht verdrängen. Um im Vergleich zum CAN-Bus die maximal mögliche Bandbreite zu erhöhen — durch die bitweise Arbitrierung ist CAN auf maximal 1 Mbit/s

16

2 Stand der Wissenschaft und Technik

beschränkt — führt FlexRay ein TDMA-Verfahren für den wechselseitigen Buszugriff ein. Dies ermöglicht im Gegensatz zu CAN eine deterministische Übertragung und einfach zu berechnende maximale Latenzzeiten. Zudem bietet FlexRay für sicherheitskritische Anwendungen die Möglichkeit, zwei separate Kanäle miteinander zu synchronisieren und damit eine redundante Verbindung aufzubauen. Diese Möglichkeit ist im CAN nur auf Anwendungsebene möglich. Die Implementierung von Mechanismen zur Synchronisation und Plausibilitätsüberprüfung wären in CAN daher aufwendig [167]. FlexRay erlaubt sowohl Bus-, als auch Stern-Topologien sowie Kombinationen aus beiden Elementen. Die Stern-Topologie wird über sogenannte Sternkoppler realisiert, welche als passive Netzwerkkomponente oder als aktive (verstärkende) Komponente ausgelegt sein können. Die Bitrate auf dem physikalischen Layer liegt bei 10 Mbit/s. Zwei Kanäle können redundant arbeiten oder zu einem Verbund mit 20 Mbit/s zusammengeschaltet werden [121]. Nach Schwierigkeiten, insbesondere in Linien-Topologien, wurden in Version 3 der Spezifikation auch 2,5 Mbit/s und 5 Mbit/s hinzugefügt [167]. Wie CAN ist FlexRay ein Multimaster-System. FlexRay verwendet wie CAN eine NRZ-Kodierung. Im Gegensatz zum Bitstuffing in CAN werden in FlexRay jedoch jedem Byte ein High- und ein Low-Bit vorangestellt. Damit benötigt FlexRay 10 bit für die Übertragung eines Bytes [46]; der Overhead ist damit im Gegensatz zu CAN konstant. Wegen der Kodierung und des großen Overheads an Steuerinformationen lassen sich in der Praxis mit FlexRay Nettodatenraten, also Nutzdaten abzüglich aller Steuerinformationen, von etwa 500 kbit/s bis 1000 kbit/s je 10 Mbit/s Kanal erreichen [167]. Das FlexRay-Protokoll vereint sowohl deterministische Kommunikation mit vordefinierten statischen Zeitscheiben als auch event-gesteuerte dynamische Kommunikation (ähnlich dem CAN-Bus [46]). Dafür ist ein fester, sich stetig wiederholender Kommunikationszyklus, der in Intervalle (Segmente) für die verschiedenen Zugriffsverfahren unterteilt ist, definiert. Der FlexRay-Zyklus (siehe Abbildung 2.2 auf der nächsten Seite) besteht aus [118]: • Statisches Segment • Dynamisches Segment • Symbolfenster (optional) • NIT (Network Idle Time) Die Größe der verschiedenen Segmente ist flexibel konfigurierbar. Die Zeiteinheit, in der die Segmente definiert werden können, sind Vielfache des

Statischer Slot n

...

Network Idle Time (optional)

Statischer Slot 3

Symbolfenster

Statischer Slot 2

Statisches Segment

Statischer Slot 1

Dynamisches Segment Dynamischer Slot n

Zyklus i + 1

Dynamischer Slot 2 ...

Zyklus i

Dynamischer Slot 1

Statischer Slot n

...

Statischer Slot 3

Statischer Slot 2

Statischer Slot 1

Statisches Segment

17

Dynamischer Slot 1

2.1 Stand der Technik

Abbildung 2.2: FlexRay-Zyklus (eigene Darstellung)

Macroticks, welcher das Zeitraster im FlexRay-Zyklus vorgibt. Der Macrotick soll zwischen 1 und 6 μs betragen. Das statische Segment definiert die TDMA-gesteuerte Zeitphase im FlexRay-Zyklus. Jeder TDMA-Botschaft wird ein Zeitfenster innerhalb des statischen Segments, ein sogenannter Slot zugewiesen. Die Slots sind so groß, dass sie genau eine FlexRay-Botschaft aufnehmen können. Alle Slots des statischen Segments sind gleich groß [120]. Nachrichten können in jedem Zyklus, aber auch in einer Periode, die einem Vielfachen der Zykluszeit entspricht, versendet werden. Wann welche Botschaft versendet wird, muss global in der Kommunikationsmatrix festgelegt werden. Diese Matrix wird auf allen Steuergeräten des FlexRay-Netzwerks konfiguriert [46]. Das dynamische Segment arbeitet nach dem sogenannten FTDMA-Prinzip (Flexible Time Division Multiple Access). Dabei wird das Segment in kleine Minislots unterteilt. Auch hier wird jeder Nachricht eine eindeutige ID zugewiesen. Jeder Sender zählt mit einem Slotzähler die abgelaufenen Minislots. Ist der Slot mit der ID der zu versendenden Botschaft erreicht, wird diese versendet. Da die Minislots zu klein sind, um eine Nachricht aufzunehmen, werden genutzte Slots vergrößert. Ähnlich zum Arbitrierungsverfahren des CAN bekommen Botschaften mit einer hohen ID dadurch später eine Sendegelegenheit. Dies kann sogar dazu führen, dass eine Botschaft erst nach einigen Zyklen versendet werden kann [167]. Im optionalen Symbolfenster können weitere Signale versendet werden, beispielsweise zum Aktivieren von Teilnehmern, welche sich im Ruhezustand befinden. Die NIT (Network Idle Time) ist eine Ruhephase des Busses, bevor der nächste Zyklus beginnt. In der NIT können notwendige Berechnungen

18

2 Stand der Wissenschaft und Technik

Layer 1

FlexRay Paket: 86 bit bis 2638 bit (10 bit Kodierung des FlexRay Frames) Layer 2

Transmission Start 3 bis 15 bit

FlexRay Frame: 8 B bis 262 B FlexRay Header: 5 B

Frame Start Control 1 bit

5 bit

ID 11 bit

Trailer

Länge CRC Zyklus 7 bit 11 bit

6 bit

CRC

Frame End

24 bit

2 bit

Nutzdaten

0 B bis 254 B (0 bis 127 Worte je 16 bit)

Abbildung 2.3: FlexRay Frame-Format (eigene Darstellung)

erfolgen, die nicht während der anderen Segmente durchgeführt werden können [167]. Der FlexRay Frame (siehe Abbildung 2.3) besteht aus einem 5 B Header, den Nutzdaten und dem 24 bit Trailer, welcher den CRC beinhaltet. Der Header beginnt mit dem 5 bit Control-Feld. Es folgt das 11 bit ID-Feld. Somit können 2074 verschiedene Botschaften, beziehungsweise Slots, im statischen und dynamischen Segment adressiert werden. Da das Feld für die PayloadLänge nur 7 bit umfasst, können nur gerade Bytelängen als Nutzdaten (maximal 254 B) verwendet werden. Die Länge beschreibt somit die Anzahl der 16 bit-Wörter im Payload. Der Header endet mit einem 11 bit Header CRC und dem 6 bit Zykluszähler. Der Zykluszähler wird beim Netzwerkstart mit null initialisiert und dann in jedem Zyklus inkrementiert [167]. Da FlexRay ein TDMA-Verfahren nutzt, müssen die Zyklen aller Teilnehmer präzise synchronisiert ablaufen. Dazu werden mit dem Sync Frame Indicator Bit des Control-Feldes (siehe Abbildung 2.3) Frames markiert, die zur Zeitsynchronisation herangezogen werden sollen. Diese Frames müssen in jedem Fall gesendet werden, auch wenn gerade keine Nutzdaten vorliegen. Fehlende Nutzdaten lassen sich in diesem Fall im Control-Feld mit dem Null-Frame-Indicator-Bit markieren. Anhand der Sync Frames wird bei der Zeitsynchronisation sowohl eine Offset-Korrektur als auch eine Korrektur der Zykluslänge (Rate Correction) vorgenommen. Als Zeiteinheit dient der sogenannte Microtick. Der Microtick basiert auf der Geschwindigkeit des Quarzes eines Teilnehmers. Seine Länge ist nicht veränderbar. Zur Offset-Korrektur, welche zu Beginn der NIT berechnet wird, wird die Länge der NIT entsprechend verlängert oder verkürzt, indem Microticks eingefügt oder weggelassen werden. Für die Frequenzkorrektur (Rate Correction) wird die Anzahl der Microticks, die einen Macrotick definiert, verringert oder erhöht. Das Verfahren kann Frequenzabweichungen bis etwa 1500 ppm korrigieren [167].

2.1 Stand der Technik

19

MOST (Media Oriented System Transport) Der Bedarf an digitalen Kommunikationsleitungen für komplexe Audioanwendungen führte Ende der neunziger Jahre zur Gründung der MOST Cooperation. Gründungsmitglieder waren im Jahre 1998 die Firmen BMW, DaimlerChrysler, Harman/Becker und Oasis SiliconSystems. Die Anforderung für eine neu zu entwickelnde Technologie war ein Hochgeschwindigkeitsbus für die Übertragung von Audio- und Videodaten bei gleichzeitiger Synchronisierung von Datenquelle und -senke sowie zwischen mehreren Senken [121]. Heute gibt es MOST-Systeme mit drei Datenraten: MOST 25 mit 24,8 Mbit/s, MOST 50 mit 50 Mbit/s und MOST 150 mit 150 Mbit/s. MOST wurde zunächst für den Einsatz mit Kunststoff-Lichtwellenleitern, sogenannten POF (Plastic Optical Fiber), spezifiziert. Durch die eingesetzte Manchesterkodierung ist dabei eine kontinuierliche Bittaktsynchronisation möglich. Seit MOST 50 gibt es auch eine Variante basierend auf einer verdrillten Zwei-Draht-Kupferleitung sowie seit MOST 150 ein physikalisches Layer auf Basis von Koaxialkabeln [52]. MOST-Topologien können in Form von Punkt-zu-Punkt-Verbindungen zwischen zwei Teilnehmern, sternförmig oder als Ring realisiert werden. In der Praxis ist der MOST-Ring die verbreitete Topologie. Ein System besteht dabei aus maximal 64 Teilnehmern [120]. MOST arbeitet nach dem Master-Slave-Verfahren. Es gibt einen besonders ausgewiesenen Knoten, den sogenannten Timing Master, welcher die synchrone Zeitbasis zur Verfügung stellt. Der Master erzeugt die Botschaften, aus denen die übrigen Teilnehmer während der Weiterleitung für sie bestimmte Daten entnehmen und in die zu versendende Daten eingefügt werden. Die beim Weiterleiten entstehende Latenz liegt bei MOST 25 bei etwa 25 μs, bei MOST 50 und 150 wird ein Cut-Through-Verfahren2 angewendet, was die Verzögerung auf unter 1 μs je weiterleitendem Teilnehmer reduziert [167]. Die Kommunikation in MOST ist bitstromorientiert und in Blöcken zu je 16 Frames organisiert. Ein Frame hat dabei die Länge von 22,67 μs. Die Wiederholrate der Frames entspricht damit der ursprünglichen Abtastfrequenz einer Audio-CD (Compact Disc) von 44,1 kHz. Hier lässt sich das ursprüngliche Anwendungsfeld von MOST, beispielsweise für die Anbindung abgesetzter CD-Wechsler, erkennen. Jeder Frame durchläuft einmal den gesamten Ring. In MOST ist der Begriff Frame kein Synonym für eine Botschaft 2 Beim

Cut-Through-Verfahren wird in paketvermittelnden Netzwerken nicht zunächst das komplette Paket empfangen, bevor es weitergeleitet wird. Sobald ausreichend Informationen für die Vermittlung vorliegen, werden die Daten direkt am ausgehenden Link weitergeleitet.

20

2 Stand der Wissenschaft und Technik

Layer 1

MOST 25 Paket: 64 B

MOST Header: 1 B

MOST Data: 60 B

Boundary Präambel Descriptor 4 bit

4 bit

Layer 1

Trailer

Synchron

Asynchron

Control Data

24 B bis 60 B

0 B bis 36 B (Rest)

2B

CRC 1B

MOST 25 Asynchrones Datenfeld: 10 B bis 1024 B (ggf. geteilt) Layer 2

MOST 25 Datenframe: 9 B bis 1023 B

MOST Header: 5 B Arbitration

1B

Zieladresse Länge Quelladresse 2B

1B

2B

Nutzdaten

CRC

0 B bis 1014 B

4B

Abbildung 2.4: MOST 25 Frame-Format (eigene Darstellung)

(wie in CAN oder FlexRay). Ein Frame kann selbst mehrere Botschaften und Steuerinformationen enthalten. Abbildung 2.4 zeigt das ursprüngliche MOST-Frame-Format (MOST 25). Jeder Frame beginnt mit einem 1 B Header, welcher in zwei Nibble geteilt ist. Das erste Halbbyte umfasst die Präambel und erlaubt die Neusynchronisation der Teilnehmer, das zweite Halbbyte definiert, wie das Datenfeld in einen synchronen und einen asynchronen Teil aufgeteilt ist. Der Wert ist angegeben in Quadlets (4 B). Es folgt das Datenfeld mit dem mindestens 24 B langen synchronen Teil, gefolgt vom asynchronen Teil, welcher den Rest der 60 B des Datenfelds umfasst. Wenn der synchrone Teil die kompletten 60 B umfasst, entfällt der asynchrone Teil. Der Frame endet mit dem 2 B ControlFeld für Steuerdaten und dem 1 B langen Trailer, welcher neben weiteren Steuer- und Statusinformationen auch Informationen zur Erkennung von Übertragungsfehlern bietet. Mit MOST 50 und 150 wurde bei höherer Bitrate die Übertragungsdauer des MOST Frames beibehalten. Damit steigt die Bytelänge des Frames auf 128 B (MOST 50), beziehungsweise 384 B (MOST 150). Der Header wurde auf 7 B (MOST 50) beziehungsweise 8 B (MOST 150), das Control-Feld auf 4 B vergrößert. Dafür entfällt der Trailer [167]. Der synchrone Teil des Datenfeldes ist selbst in Zeitschlitze zu jeweils 1 B, auch als physikalischer Kanal bezeichnet, aufgeteilt. Physikalische Kanäle können zu logischen Kanälen zusammengelegt werden, welche von 1 B bis zur Gesamtgröße des synchronen Datenfeldes variieren dürfen. Diese logischen Kanäle sind nach dem TDMA-Prinzip genau einem Endsystem zugewiesen, wel-

2.1 Stand der Technik

21

ches den Kanal füllen darf. Logische Kanäle haben keine Adressierung; die Zuweisung wird über Steuerdaten organisiert. Anhand der Zuweisung ist jedem Teilnehmer im MOST-Netz der Sender und Inhalt des Kanals bekannt [167]. Im asynchronen Teil des Datenfeldes können variable Datenpakete eventgetrieben übermittelt werden. Pakete, die größer als das asynchrone Feld sind, werden dabei auf mehrere Frames aufgeteilt. Die Übertragung eines Datenpakets wird durch das Arbitration-Feld geregelt, welches auch eine faire Verteilung der Bandbreite überwacht [121]. Dabei wird ein Token im Ring von Teilnehmer zu Teilnehmer weitergeleitet. Der Teilnehmer, der das Token hält, darf sein zugehöriges Datenpaket senden. Eine Priorisierung ist im asynchronen Datenfeld nicht vorgesehen. Der Header besteht aus der 16 bit Zieladresse, der Länge der Nutzdaten (Quadlets) und der Quelladresse. Es folgen die Nutzdaten sowie ein 4 B CRC-Feld [167]. In MOST 150 kam ein weiteres an Ethernet angelehntes Datenformat für das asynchrone Datenfeld, das MEP (MOST Ethernet Packet), hinzu. Es verwendet als Adressformat 48 bit MAC-Adressen (Media Access Control) und den Ethernet CRC. Damit die Übertragung eines vollen Ethernet Frames möglich wird, ist beim MEPFormat das Nutzdatenfeld auf 1506 B vergrößert [167]. Damit ist MOST 150 in der Lage, als physikalisches Layer für Ethernet im Automobil zu fungieren. LVDS (Low Voltage Differential Signaling) LVDS ist keine Bezeichnung für eine Kommunikationstechnologie oder ein Produkt, sondern ein Prinzip, das beschreibt, wie digitale Informationen auf Basis differentieller Signale über einen seriellen Link übertragen werden. LVDS wurde bereits im Jahr 1994 für den Consumer-Markt entwickelt [103] und ist als Schnittstelle für die Übertragung mit hohen Bandbreiten standardisiert als ANSI/TIA/EIA-644-1995 [146]. Der Anwendungsbereich von LVDS liegt in der seriellen Übertragung mit mehreren Gbit/s. Im Computerbereich wird es beispielsweise für SATA (Serial ATA), PCIe (PCI Express) oder FireWire eingesetzt [123]. Im Automobilbereich wird LVDS eingesetzt für die Videoübertragung. Ein verbreitetes Produkt ist APIX (Automotive Pixel link) [103]. Aufgrund der signifikant höheren Kabelkosten für die notwendigen geschirmten Leitungen wird LVDS heute nur wenn notwendig eingesetzt [103]. Ein weiterer Nachteil von LVDS ist die unidirektionale Funktionsweise. Für einen Steuerkanal müssen in der Regel zusätzliche Kabel verlegt werden. Insbesondere für Kameraanwendungen, die auf einen Steuerkanal angewiesen sind, ist dies ein bedeutender Nachteil gegenüber bidirektional operierenden Technologien wie beispielsweise Ethernet.

22

2 Stand der Wissenschaft und Technik

2.1.2 Ethernet Im Mai 1973 wurde Ethernet erstmals durch Robert Metcalfe am Xerox PARC (Palo Alto Research Center) in einem Memo als eine neue Technologie, um Workstations mit schnellen Laser-Druckern zu verbinden, beschrieben. Das von Metcalfe beschriebene Netzwerk war inspiriert durch frühe Experimente mit ALOHAnet. Das ALOHAnet-Protokoll, entwickelt von der University of Hawaii, um Standorte auf verschiedenen hawaiianischen Inseln zu verbinden, nutzte das ALOHA random access Zugriffsverfahren und war die Vorlage für die nachfolgenden CSMA/CD-Verfahren (Carrier Sense Multiple Access/Collision Detection) [131]. Seiner Abstammung entsprechend nannte Metcalfe seine Netzwerktechnologie zunächst Alto Aloha Network, änderte dies später jedoch zu Ethernet, um zu verdeutlichen, dass nicht nur die durch Xerox entwickelten Alto-Rechner mit dieser neuartigen Technologie verbunden werden könnten, sondern jedes verteilte System. Der Name Ethernet stammt von Lichtäther — luminiferous ether — eine Bezeichnung, die im 17. Jahrhundert für ein Medium, auf dem sich das Licht ausbreitet, verwendet wurde. Trotz der Widerlegung der Existenz von Lichtäther im Jahr 1887 durch Michelson und Morley empfand Metcalfe die Vorstellung eines allgegenwärtigen Übertragungsmediums als passende Analogie für seine Erfindung [131]. Der später veröffentlichte offene IEEE-Standard nutzte jedoch die Bezeichnung Ethernet zunächst nicht. Hier wurde Ethernet als IEEE 802.3 — Carrier Sense Multiple Access With Collision Detection (CSMA/CD) bezeichnet, um nicht den Eindruck zu erwecken, eine private Firma zu bevorzugen [103]. Erst 30 Jahre nach der Verabschiedung des 802.3-Standards und 40 Jahre nach der Erfindung wurde die Bezeichnung Ethernet offiziell in den IEEE 802.3-2012-Standard [66] aufgenommen. Metcalfe konzipierte Ethernet, entsprechend seiner Vorstellung einer allgegenwärtigen Übertragungsschicht, als reine Übertragungstechnologie. Jegliche Arten von Daten sollten über Ethernet übertragen werden können. Ethernet definiert dabei nicht die Darstellung dieser Daten, sondern ausschließlich die Übertragung der Bytes. Dadurch wurde Ethernet universell einsetzbar und ist heute die weltweit am weitesten verbreitete Netzwerktechnologie. Der Ethernet-Standard beschreibt das physikalische Layer sowie verschiedene Medienzugriffsverfahren und das Frame-Format im Data Link Layer. Heute gibt es diverse Spezifikationen für die physikalische Übertragungsschicht über Kupferkabel und Lichtwellenleiter mit Geschwindigkeiten bis zu 25 Gbit/s, an Standards mit noch größerer Bandbreite (derzeit bis zu 400 Gbit/s), auch als Terabit-Ethernet bezeichnet, wird bereits gearbeitet.

2.1 Stand der Technik

23

Bus

S

Hub

S

(a)

(b)

Switch

S

(c)

Abbildung 2.5: Kollisionsdomänen (rot) beim Senden (Sender: S) im Vergleich: Bus (a), Hub (b) und Switch (c) (eigene Darstellung)

Das ursprünglich revolutionäre CSMA/CD-Verfahren wird heute praktisch nicht mehr genutzt. Ethernet-Installationen sind heute als geswitchte Netzwerke realisiert. Diese verwenden eine Topologie aus P2P-Verbindungen (Point-2-Point). Während in ungeswitchten Netzwerken alle Teilnehmer am selben Medium angeschlossen sind — das gesamte Netzwerk hat eine einzige geteilte Kollisionsdomäne — werden geswitchte Netzwerke über Vermittlungsknoten, die Switche, und Punkt-zu-Punkt-Verbindungen verbunden. Dadurch kann es keine Kollisionen im Netzwerk geben, man spricht von einer Vollduplex-Kommunikation. Das parallele Empfangen von Botschaften wird in den Switchen durch Puffer aufgelöst [131]. Abbildung 2.5 zeigt die Kollisionsdomäne in verschiedenen Netzwerken. Beim Bus (2.5a) liegt die Botschaft stets bei allen verbundenen Teilnehmern an. In einem Netzwerk mit Hub3 (2.5b) wird eine sternförmige Topologie ermöglicht, indem das Signal an allen Anschlüssen, den sogenannten Ports, verstärkt wird. Die Charakteristik des Busses bleibt dabei jedoch erhalten. Im Gegensatz dazu beschränkt der Switch (2.5c) die Kollisionsdomäne auf den Link zwischen zwei Teilnehmern. Botschaften werden durch den Switch anhand der Zieladresse des Frames nur auf den Links weitergeleitet, welche einen Empfänger erreichen können. Dadurch sind geswitchte Netzwerke deutlich effizienter. Beim Format des Ethernet-Pakets unterscheidet man zwischen der Darstellung auf dem physikalischen Layer und dem Ethernet Frame auf Layer 2 (siehe Abbildung 2.6 auf der nächsten Seite). Das Ethernet-Paket beginnt mit einer 7 B Präambel und dem 1 B großen SFD (Start Frame Delimiter). Anschließend beginnt der eigentliche Ethernet Frame. Zunächst werden die ZielMAC-Adresse und die Quell-MAC-Adresse übertragen (jeweils 6 B). MACAdressen oder auch Hardware-Adressen sind eindeutige 48 bit lange IDs, 3 Hub

(englisch): Nabe

24

2 Stand der Wissenschaft und Technik

Ethernet Paket: 72 B bis 1526 B bzw. 1530 B

Layer 1 Layer 2

Ethernet Frame: 64 B bis 1518 B bzw. 1522 B

Ethernet Header: 14 B bzw. 18 B

Präambel

7B

Start of 802.1Q Ethertype/ MAC MAC Frame Ziel Quelle (optional) Länge 1B

6B

6B

4B

2B

Nutzdaten

42 B bzw. 46 B bis 1500 B

Frame Inter Check Frame Sequence Gap 4B

12 B

Abbildung 2.6: Standard Ethernet Frame-Format (eigene Darstellung)

welche genau ein Hardware Interface bezeichnen. In der 802.1Q-EthernetErweiterung [72] folgen anschließend 4 B mit Informationen zur Priorisierung und Segmentierung. Das letzte Feld des Ethernet Headers ist das Typenoder Längenfeld (2 B). Sofern das Feld einen Wert kleiner 1500 beinhaltet, ist damit die Länge der Nutzdaten (Payload) bezeichnet. Für Werte größer 1500 ist in diesem Feld die Art der Nutzdaten angegeben [131]. Damit wird Ethernet seinem Anspruch gerecht, jegliche Nutzdaten zu übertragen. Das IEEE unterhält eine Liste mit vergebenen Protokolltypen [78]. Bekannte Beispiele sind IEEE 802.1Q (0x8100), IPv4 (Internetprotokoll Version 4) (0x0800) oder IPv6 (Internetprotokoll Version 6) (0x86DD). Der Payload des Ethernet Frames muss mindestens so groß sein, dass der gesamte Frame eine Größe von 64 B erreicht. Dies entspricht beispielsweise 46 B für einen Standard-Frame und 42 B für einen Frame nach IEEE 802.1Q [72]. Sofern die zu versendenden Daten kleiner sind, wird der Frame aufgefüllt (Padding4 , siehe auch Abschnitt 3.4.3 auf Seite 92). Im Standard ist eine maximale Nutzdatenlänge von 1500 B vorgesehen; proprietäre Erweiterungen und Vereinbarungen zwischen Netzwerkkomponenten-Herstellern sehen jedoch auch größere Frames, sogenannte Jumbo-Frames vor (siehe auch Abschnitt 3.4.3 auf Seite 90) [131]. Der Ethernet Frame schließt ab mit einer Checksumme (FCS (Frame Check Sequence)), mit der die Integrität des übertragenen Frames überprüft werden kann. Nach jedem Ethernet-Paket folgt auf der Leitung eine Ruhephase von 12 B, der sogenannte IFG (Inter Frame Gap) [131].

4 Mit

Padding wird im Ethernet das Auffüllen eines Nutzdatenfelds mit zumeist zufälligen Daten bezeichnet. Padding wird verwendet, um die standardisierte minimale Paketgröße zu erreichen.

2.1 Stand der Technik

25

IEEE 802.3bw 100BASE-T1 – BroadR-Reach IEEE 802.3bw [67] wurde ursprünglich von der Firma Broadcom unter der Bezeichnung BroadR-Reach entwickelt. Dabei wurden Techniken aus der Entwicklung des 1000BASE-T-Standards genutzt, um eine robuste Übertragung mit 100 Mbit/s über ein einziges Adernpaar — 1000BASE-T verwendet vier Paare — zu realisieren. BroadR-Reach wurde ursprünglich als Technologie für den Netzwerkzugang „auf der ersten Meile“ (EFM (Ethernet in the First Mile)) entwickelt, also für Bereiche, in denen bereits eine Zweidraht-Verkabelung, nicht jedoch für beispielsweise 100BASE-TX spezifizierte Leitungen, zur Verfügung steht. BMW evaluierte BroadR-Reach als Lösung für Ethernet über ein UTSP (Unshielded Twisted Single Pair). Nachdem erste EMVMessungen (Elektromagnetische Verträglichkeit) erfolgreich waren, trieb die Automobilindustrie die offene Standardisierung von BroadR-Reach voran. Bisher war BroadR-Reach ein proprietäres, geschlossenes Produkt von Broadcom. Ein solches Monopol bei einer Schlüsseltechnologie, womöglich sogar eine Single-Source-Situation — also ein einziger Hersteller für Netzwerkkomponenten — war jedoch für die Automobilindustrie inakzeptabel [103]. In 2011 wurde durch die Firmen Broadcom, BMW und NXP Semiconductors die OPEN Alliance (One Pair EtherNet), eine SIG (Special Interest Group), gegründet. Broadcom willigte ein, für Mitglieder der Gruppe BroadR-Reach Lizenzen zu vergeben. Die Bezeichnung von BroadR-Reach wurde auf OABR (OPEN Alliance BroadR-Reach) erweitert. Im Jahr 2016 wurde zudem der IEEE 802.3bw-Standard verabschiedet. IEEE 802.3bw ist kompatibel zu OABR und der erste einer Reihe von IEEE-Standards für Ethernet über UTSP. Der neueste Standard aus dieser Reihe realisiert 1 Gbit/s über UTSP (1000BASE-T1) in IEEE 802.3bp [64], auch als RTPGE (Reduced Twisted Pair Gigabit Ethernet) bezeichnet. Die Entwicklung der T1-Übertragungsverfahren (100BASE-T1 und 1000 BASE-T1) ist von herausragender Bedeutung für den Erfolg von Automotive Ethernet. Sie ermöglichen den Einsatz von Ethernet mit kostengünstigen und gut zu verarbeitenden Kabeln, mit denen bereits beim Einsatz mit Feldbussen im Automobil Erfahrungen gesammelt wurden. Ohne die OABR-Technologie und den Einsatz von Ethernet mit STP-Kabeln (Shielded Twisted Pair) hätte gegenüber der MOST-Technologie kein Kostenvorteil bestanden. In diesem Fall hätte die Automobilindustrie für Anwendungen mit hoher Bandbreite den MOST150-Standard eingesetzt [103]. 100BASE-T1 wendet Techniken aus IEEE 802.3 1000BASE-T an, um eine robuste Ethernet-Verbindung über ein einziges verdrilltes Aderpaar zu realisieren. Während der 100BASE-TX-Standard noch jeweils ein Aderpaar für

26

2 Stand der Wissenschaft und Technik

die Sende- und Empfangsrichtung verwendet, müssen für Gigabit-Ethernet alle vier Paare einer Leitung nach CAT 5e Standard genutzt werden. Um die benötigte Bandbreite geringer zu halten, wurde auf ein echtes VollduplexVerfahren gesetzt, bei dem dasselbe Aderpaar zum gleichzeitigen Senden und Empfangen verwendet wird. Dabei werden von den beiden Transmittern an beiden Enden der Leitung die Signale übereinander modelliert. Dadurch, dass jeder Sender sein eigenes Signal kennt, kann aus dem resultierenden Summensignal das Signal der Gegenseite errechnet werden. Dies erfordert jedoch das Herausfiltern von Echos des eigenen Signals. Für das Trennen der Signale beider Sender wird eine Hybridschaltung eingesetzt. Eine Hybridschaltung ist eine Brückenschaltung aus in der Regel vier Widerständen. Da es in der Praxis durch Toleranzen im Fertigungsprozess nahezu unmöglich ist, die Hybridschaltung perfekt abzustimmen, werden in der Regel DSPs (Digitale Signalprozessoren) eingesetzt, um Restechos zu eliminieren [119]. Durch die Vollduplex-Nutzung aller vier Aderpaare liegt die Bandbreite je Paar bei 1000BASE-T bei nur 250 Mbit/s. Um in OABR eine 100 Mbit/s-Verbindung über ein Aderpaar zu realisieren, wäre es ausreichend gewesen, die ursprüngliche Kodierung von 100BASE-TX um die Hybridschaltung zu erweitern. Das Problem für den Einsatz im Automobil ist jedoch die Störempfindlichkeit, die aus der relativ hohen Baudrate von 125 MHz resultiert. Es war daher notwendig, eine möglichst robuste und effiziente Kodierung zu finden. Gigabit-Ethernet verwendet PAM (Pulsamplitudenmodulation), genauer das 4D-PAM5-Modulationsverfahren, bei dem über vier Doppeladern und fünf Zustände (−1 V, −0,5 V, 0 V, 0,5 V, 1 V) mit einer Symbolrate von 125 MSymbole/s eine Nutzbitrate von 1 Gbit/s erreicht wird. OABR verwendet das PAM3-Verfahren (mit den Zuständen −1 V, 0 V, 1 V). Damit kann im Vergleich zu 100BASE-TX die Symbolrate auf 66,66 MSymbole/s reduziert werden. Die niedrigere Frequenz erlaubt besseres Filtern und damit eine deutlich höhere Robustheit gegenüber Störungen. Wie in 1000BASE-T muss in OABR festgelegt werden, welcher Sender als Master für den Takt verantwortlich ist. Während in 1000BASE-T das Master-Slave-Verhältnis durch die Autonegotiation5 während des Aufbaus eines Links ausgehandelt wird, kann durch den Einsatz in einer definierten und statischen Umgebung bei OABR auf dieses Verfahren verzichtet werden. OABR verwendet eine feste offline konfigurierte Master-Slave-Beziehung [103].

5 Autonegotiation,

auch Autosensing, ist ein Verfahren, um auf einem Link zwischen zwei Ethernet-Teilnehmern die mögliche Übertragungsgeschwindigkeit sowie das DuplexVerfahren auszuhandeln.

2.1 Stand der Technik

27

Tabelle 2.2: 100BASE-T1, 100BASE-TX und 1000BASE-T im Vergleich (eigene Tabelle nach Matheus und Königseder [103]) Technologie

100BASE-T1

100BASE-TX

1000BASE-T

Aderpaare Übertragung Modulation Baudrate Bandbreite Master-Slave

100 Mbit/s 1 Vollduplex PAM3 66,66 MSymbole/s etwa 27 MHz fest konfiguriert

100 Mbit/s 2 Dual-Simplex MLT-3 125 MSymbole/s 65 MHz bis 80 MHz -

1 Gbit/s 4 Vollduplex 4D-PAM5 125 MSymbole/s 65 MHz bis 80 MHz Autonegotiation

Tabelle 2.2 zeigt die Eigenschaften von 100BASE-T1 im Vergleich zu den Technologievorlagen 100BASE-TX und 1000BASE-T.

2.1.3 Echtzeit-Ethernet-Protokolle Ein Grund für den großen kommerziellen Erfolg von Ethernet ist, dass keine Annahmen über die zu übertragenden Daten gemacht werden. Dieser Umstand ermöglicht eine hohe Flexibilität und den Einsatz in diversen Bereichen wie beispielsweise der Anbindung von Arbeitsplatzrechnern, Rechenzentren, der globalen Internet-Infrastruktur oder von Telefonieanwendungen. So kennt Ethernet auch keine Übertragungsgarantien mit Bestätigung (Acknowledge) und erneutem Versenden (Retransmit) [131]. Solche Dienste müssen auf den höheren Schichten des OSI-Modells implementiert werden. Standard Ethernet arbeitet nach dem Best-effort-Prinzip6 . Darüber hinaus wurde Ethernet nicht für den Einsatz in Systemen mit harten Echtzeitbedingungen entwickelt. Die Vorteile von Ethernet wie Flexibilität, Skalierbarkeit und Kosteneffizienz führten jedoch dazu, dass sich auch Domänen mit Anforderungen an Echtzeitkommunikation für Ethernet interessierten. Für die Steuerung von Industrieprozessen wurden diverse Industrial-Ethernet-Protokolle definiert, um Ethernet für die hohen Anforderungen an Übertragungszeit, Robustheit, Verfügbarkeit und Sicherheit zu erweitern [103]. Etablierte Produkte des Industrial Ethernet sind EtherCAT (Ethernet for Control Automation Technology), Ethernet POWERLINK, PROFINET oder SERCOS-III. 6 Best-effort

(deutsch: größte Bemühung) bezeichnet die geringste Dienstgütezusicherung in Netzwerken. Übermittlungsanfragen werden im Rahmen der zur Verfügung stehenden Ressourcen bedient.

28

2 Stand der Wissenschaft und Technik

Die Vielzahl von angebotenen Industrial-Ethernet-Lösungen ist gleichzeitig auch eine Schwäche. Standard Ethernet wurde als offene Technologie angelegt. Das Ziel war eine hohe Verbreitung und gute Interoperabilität zu erreichen, indem ein offener Standard mit breiter Akzeptanz geschaffen wurde. Diese Interoperabilität ist mit den verschiedenen am Mark befindlichen Protokollen heute nicht zu erreichen. Dies erklärt auch das Engagement der Industrie einen starken Echtzeit-Ethernet-Standard durch die IEEE zu spezifizieren. Diese Arbeit wird in der IEEE 802.1 TSN-Gruppe gebündelt. Auch die Flugzeugindustrie setzte früh auf die Ethernet-Technologie. Airbus entwickelte das AFDX-Protokoll (Avionics Full DupleX Switched Ethernet), welches mit dem Jungfernflug des A380 in 2005 erstmals abhob. AFDX wurde standarisiert als ARINC Report 664P7-1 [21]. Der AFDX-Standard hat eine breite Akzeptanz in seiner Domäne und wird von den großen Flugzeugherstellern eingesetzt. Dennoch ist die Flugzeugindustrie in der IEEE TSN-Gruppe aktiv und erweitert die Anforderungen und Anwendungsfälle der dort in Entwicklung befindlichen Standards für den Einsatz im Flugzeug. Automotive Ethernet ist der Begriff mit dem die Aktivitäten rund um Ethernet für das Automobil gebündelt werden. Die Automobilindustrie drängte beim Thema Ethernet schon früh auf starke und weit akzeptierte IEEE-Standards. Wie beim physikalischen Layer (IEEE 802.3bw, siehe auch Abschnitt 2.1.2 auf Seite 25) soll durch offene Standards auch bei den Echtzeit-Ethernet-Protokollen eine industrieweite Einigung und damit eine gute Verbreitung erreicht werden. Die Automobilindustrie ist derzeit die treibende Kraft in der IEEE TSN-Gruppe. Der Kern der Herausforderungen rund um Echtzeit-Ethernet-Lösungen ist das Traffic Shaping und der konkurrierende Medienzugriff. Diese Problemstellungen und mögliche Lösungsansätze werden im folgenden Abschnitt beschrieben. Medienzugriff und Traffic Shaping Um Echtzeitfähigkeit auf Basis von Ethernet zu erreichen, muss das Aufstauen von Nachrichten verhindert werden. Darum definieren Echtzeit-EthernetErweiterungen Strategien, um den gleichzeitigen Medienzugriff sowie durch sogenanntes Traffic Shaping die Übertragung von Bursts7 zu vermeiden. Es gibt Token-basierte, bandbreitenbasierte und time-triggered Verfahren. Im Folgenden werden grundsätzliche Eigenschaften der Verfahren dargestellt. 7 Ein

Burst ist eine Datenübertragung mit hoher Bandbreite über eine kurze Zeit. Bursts sind Lastspitzen auf einem Übertragungsmedium.

2.1 Stand der Technik

29

Token-basierte Verfahren: In Token-basierten Verfahren wird der gleichzeitige Medienzugriff mehrerer Teilnehmer durch eine exklusive Ressource, dem Token, ausgeschlossen. Der Teilnehmer, der das Token besitzt, darf eine Botschaft aussenden. Danach wird das Token in einem virtuellen Ring an den nächsten Teilnehmer weitergereicht. Bei den im Fahrzeug eingesetzten Bussystemen ist der MOST-Bus (siehe auch Abschnitt 2.1.1 auf Seite 19) ein Vertreter Token-basierter Kommunikation. In MOST wird eine Botschaft, die das Token repräsentiert, in einem physikalischen Ring von Teilnehmer zu Teilnehmer weitergeleitet und dabei mit Informationen angereichert. Historisch wurden Token-basierte Systeme im Token-Ring-Protokoll (IEEE 802.5) [75], einem Computernetz mit einer physikalischen Ringtopologie, oder IEEE 802.4 [68], einem Token-basierten System mit einem logischen Ring (aufgebaut aus den Teilnehmeradressen), eingesetzt. In der Prozessautomatisierung wird das nach dem Token-Prinzip arbeitende EtherCAT-Protokoll eingesetzt. Es gibt derzeit keine Token-basierten Echtzeiterweiterungen für Ethernet, die für den Einsatz im Automobil evaluiert werden. Time-triggered Verfahren: Zeitgesteuerte (time-triggered) Verfahren verwenden eine global synchronisierte Zeit, um eine deterministische Kommunikation zu realisieren. Dabei wird die lokale Uhr jedes Teilnehmers auf Basis eines Synchronisierungsprotokolls mit den Uhren der anderen Teilnehmer im Netzwerk synchronisiert. In einem vordefinierten Zeitplan sind jedem Teilnehmer Zeitschlitze zugewiesen, in denen Botschaften versendet werden dürfen. Dadurch können niemals zwei Teilnehmer zur selben Zeit auf denselben Link zugreifen. Diese Art des wechselseitigen Ausschlusses wird auch als koordiniertes TDMA bezeichnet. Time-triggered Verfahren arbeiten durch TDMA vollständig deterministisch. Die Dauer der Übertragung ist im Zeitplan festgelegt. Damit haben time-triggered Protokolle eine besonders niedrige maximale Ende-zu-Ende-Latenz sowie einen geringen Jitter. In der Prozessautomatisierung gibt es eine große Anzahl an time-triggered Echtzeit-Ethernet-Varianten, wie beispielsweise Profinet, SynqNet oder POWERLINK. Für den Einsatz in Fahrzeugen wurde die time-triggered Verkehrsklasse aus TTEthernet (siehe auch Abschnitt 2.1.3 auf Seite 35) evaluiert. Die IEEE TSN-Gruppe standardisiert derzeit ebenfalls time-triggered Ethernet-Erweiterungen in IEEE 802.1Qbv [71] (siehe auch Abschnitt 2.1.3 auf Seite 38). Bandbreitenbasierte Verfahren: Die bandbreitenbasierten Verfahren verhindern nicht den konkurrierenden Medienzugriff, sondern begrenzen das

30

2 Stand der Wissenschaft und Technik

Aufstauen von Botschaften, indem Bursts durch sogenanntes Traffic Shaping reduziert oder verhindert werden. Dabei werden Bandbreitenkontingente fest konfiguriert oder mithilfe eines dynamischen Prozesses zur Laufzeit reserviert. Die Teilnehmer des Netzwerks dürfen nur im Rahmen ihres reservierten Kontingents Bandbreite nutzen. Verfahren für die Bandbreitenverteilung sind beispielsweise Token-Bucket-Verfahren, bei denen sich ein Kredit kontinuierlich erhöht. Dieser Kredit muss zum Senden eingesetzt werden. Andere Verteilungsverfahren arbeiten beispielsweise mit minimalen Distanzen zwischen den Botschaften, die nicht unterschritten werden dürfen. Durch die Limitierung der Bandbreite kann nachgewiesen werden, dass trotz konkurrierenden Zugriffs auf das Medium nach endlicher Zeit alle Botschaften zugestellt werden können. Damit ist eine maximale Ende-zu-Ende-Latenz nachweisbar. Bekannte bandbreitenbasierte Echtzeit-Ethernet-Technologien sind beispielsweise das AFDX-Protokoll (siehe auch Abschnitt 2.1.3 auf Seite 33) und der CBS (Credit Based Shaper) aus IEEE 802.1Qav [74] (siehe auch Abschnitt 2.1.3 auf der nächsten Seite). Event-triggered Echtzeit-Ethernet Event-basierte Echtzeit-Ethernet-Protokolle verwenden asynchrone Medienzugriffsverfahren und das sogenannte Traffic Shaping, dem Belegen von ausgehendem Datenverkehr mit Regeln, um Echtzeitfähigkeit herzustellen. Im Bereich der Fahrzeugvernetzung wird insbesondere der CBS (Credit Based Shaper) aus dem Ethernet AVB Standard diskutiert. Aus dem Bereich der Vernetzung in Flugzeugen stammt das AFDX-Protokoll. IEEE 802.1Q ist kein primär für Echtzeitanwendungen entwickeltes Ethernet-Protokoll. Da es im Automobilbereich jedoch für den Einsatz als solches diskutiert wird und die Grundlage für die Ethernet AVB und TSN-Protokolle bildet, wird es ebenfalls im folgenden Abschnitt vorgestellt. IEEE 802.1Q IEEE 802.1Q [72] erweitert den Ethernet Frame um ein weiteres Feld (siehe auch Abbildung 2.6 auf Seite 24), das 4 B große QTag. Dieses Feld ist wiederum geteilt in 2 B TPID (Tag Protocol Identifier) sowie 2 B TCI (Tag Control Information). Das TPID-Feld steht im Frame an der Stelle des ursprünglichen EtherType-Feldes, welches im Q-Frame um 4 B verschoben ist. Um anzuzeigen, dass es sich um einen Q-Frame handelt, wird das TPID-Feld konstant mit 0x8100 belegt. Die eigentlichen Protokollinformationen von IEEE 802.1Q liegen im 16 bit großen TCI-Feld.

2.1 Stand der Technik

31

Dieses ist unterteilt in 3 bit PCP (Priority Code Point), einer Einteilung in acht mögliche Prioritätsklassen, dem DEI (Drop Eligible Indicator) (1 bit), einer Information, ob ein Frame bei Aufstauungen gelöscht werden darf, und dem VID (VLAN-Identifier) (12 bit), einer Zuweisung des Frames zu einem von 4094 möglichen virtuellen Netzwerken (die Werte 0 und 4095 sind reserviert). Durch die beschriebenen Erweiterungen ermöglicht IEEE 802.1Q sowohl die Priorisierung von Nachrichten als auch die Segmentierung eines Netzwerks mithilfe von VLANs (Virtuelle LANs) in aus Sicht der Erreichbarkeit strikt getrennte Teilnetzwerke. Ethernet AVB (IEEE 802.1Qav): Der Ursprung des IEEE 802.1QavStandards [74] liegt im Bedarf der verlustfreien Übertragung von Audio und Video mit niedriger Latenz. Er sieht vor, die Servicequalität konkurrierender Verkehrsströme zu verbessern, indem Bursts aufgelöst werden. Wenn ein Datenstrom beispielsweise 10 % der verfügbaren Bandbreite nutzt, macht es für gleichzeitig übertragene Ströme einen deutlichen Unterschied, ob alle 100 s für eine Dauer von 10 s gesendet wird, oder alle 100 μs für 10 μs. In beiden Fällen wird (annähernd) dieselbe Bandbreite genutzt, jedoch verzögern sich andere niedriger priorisierte Pakete im ersten Fall um 10 s, im zweiten Fall dagegen nur um 10 μs. Daher werden die Pakete eines Datenstroms unter Kontrolle von IEEE 802.1Qav möglichst gleichmäßig über die Zeit verteilt. Der Standard definiert dafür den sogenannten CBS. IEEE 802.1Qav ist eine Erweiterung des 802.1Q-Standards und nutzt aus diesem insbesondere die Zuweisung von Paketen zu Prioritäten. Der CBS kennt drei unterschiedliche Verkehrsklassen: SR-Klasse A (Stream Reservation), SR-Klasse B und BE-Datenverkehr (best-effort). Die BEVerkehrsklasse wiederum unterteilt sich in mehrere Prioritäten. Die SR- und BE-Klassen werden auf die Prioritäten des Q-Tags abgebildet; dabei hat die SR-Klasse A die höchste und die Klasse B die zweithöchste Priorität. Abbildung 2.7 auf der nächsten Seite zeigt die Warteschlangen- und ShaperArchitektur. Während die BE-Klasse unverändert bleibt, wird für die Klassen A und B das sogenannte Observation Window eingeführt. Vereinfacht definiert das Observation Window eine Frequenz mit der der Sender seine Pakete in das Netzwerk sendet. Für die Klasse A ist das Observation Window 125 μs groß, für die Klasse B 250 μs. Durch das Observation Window ist implizit auch definiert, wie groß die Botschaften eines Senders maximal werden dürfen. Für einen Stream mit 50 % eines 100 Mbit/s Links darf die Übertragung maximal

32

2 Stand der Wissenschaft und Technik

AVB SR 5 Klasse A AVB SR 4 Klasse B

Prio. Prio. Prio.

Credit Based Shaper (CBS)

3 2 Besteffort

1

Prioritätenbasierte Auswahl

5

4

3

Prio.

...

0

CBS Ausgang

Best-effort Ausgang

0

Abbildung 2.7: Traffic Shaping und Warteschlangen in IEEE 802.1Qav (eigene Darstellung)

50 % von 125 μs einnehmen. Dies entspricht ungefähr 780 B. Um eine höhere Frequenz zu ermöglichen, darf innerhalb des Observation Windows auch mehrfach gesendet werden. Entsprechend ist die Paketgröße auf mehrere Frames aufzuteilen. Um die Sendefrequenz einzuhalten, wird ein kreditbasiertes Verfahren eingesetzt, der CBS. Aus der Bandbreite des Datenstroms werden die sogenannten Idle und Send Slopes berechnet. Es handelt sich dabei um Raten, mit denen der Kredit ansteigt, solange kein Frame des Datenstroms gesendet wird (Idle Slope) und absinkt, während gesendet wird (Send Slopes). Abbildung 2.8 auf der nächsten Seite zeigt beispielhaft das Verhalten des CBS. Eine AVB-Nachricht kann gesendet werden, solange der Kredit größer oder gleich null ist. Wenn keine Nachricht gesendet wird oder gesendet werden kann, steigt der Kredit mit dem Idle Slope, bis er null erreicht. Wenn die Übertragung durch eine andere Botschaft blockiert wird, kann der Kredit auch über null ansteigen (siehe t0 in Abbildung 2.8 auf der nächsten Seite). Da der SR-Datenverkehr die höchste Priorität besitzt, wird der Frame gesendet, sobald der Ausgang (Linecard) wieder frei ist (siehe t1 in Abbildung 2.8). Der Send Slope reduziert dann den Kredit bis zum Ende der Übertragung. Nach Abschluss der Übertragung (siehe t2 ) dürfen weitere Frames nur gesendet werden, wenn der Kredit größer oder gleich null ist. Andernfalls muss gewartet werden, dass durch den Idle Slope der Kredit wieder ausreichend angestiegen ist (siehe t3 ). Wenn kein AVB Frame zum Senden zur Verfügung steht, bleibt der Kredit bis zum nächsten Frame bei null.

2.1 Stand der Technik

33 t1

t2 t3

AVBKredit

t0

2 1 0

AVB Frame gesendet

AVB Frame BE Frame gesendet

0

BE Frame AVB Frame bereit

AVBLine- Queuecard Länge

0

Zeit

Abbildung 2.8: Credit Based Shaping im IEEE 802.1Qav-Standard (eigene Darstellung)

Durch den CBS-Ansatz ist sichergestellt, dass sich Echtzeit-Frames nicht unbegrenzt aufstauen. Damit kann erreicht werden, dass ein Frame der SR-Klasse A in Ethernet AVB grundsätzlich nicht länger verzögert wird als ein Observation Window zuzüglich der Übertragung eines Frames maximaler Größe. In sorgfältig designten Netzwerken entspricht dies 250 μs pro Hop, was zu einer Ende-zu-Ende-Latenzgarantie von 2 ms führt. Es wurde in analytischen Worstcase-Betrachtungen jedoch bereits gezeigt, dass es Netzwerkkonfigurationen gibt, in denen diese Garantie verletzt werden kann [115]. Um sicherzustellen, dass für den Echtzeitdatenverkehr ausreichend Bandbreite auf dem Pfad zwischen Sender und Empfängern zur Verfügung steht, verwendet IEEE 802.1Qav das IEEE 802.1Qat SRP (Stream Reservation Protocol). Dieses ermöglicht, dynamisch zur Laufzeit neue Datenströme zu registrieren und damit Bandbreite auf den Links zu reservieren. Für den Einsatz im Automobil, in dem die notwendigen Verkehrsflüsse zur Designzeit feststehen, ist jedoch zunächst ein Ansatz mit statisch konfigurierten Strömen ohne das SRP möglich. AFDX (Avionics Full DupleX Switched Ethernet): AFDX ist die Bezeichnung für den ARINC-Standard 664 (Aeronautical Radio Incorporated) [21],

34

2 Stand der Wissenschaft und Technik

welcher ein Ethernet-basiertes Kommunikationsnetzwerk für den Einsatz im Flugzeug definiert. AFDX beschränkt die maximale Transferrate je Sender und ist damit ein klassisches bandbreitenbasiertes Echtzeitverfahren. Zudem verwendet es feste Kommunikationswege in der Netzwerktopologie und besitzt damit ein deterministisches Routing. AFDX ist durch Airbus patentiert und eine eingetragene Marke. AFDX erweitert Ethernet um das Konzept der BAG (Bandwidth Allocation Gap). Die BAG definiert die Bandbreite eines Senders, indem die Anzahl möglicher Botschaften in einem definierten Zeitintervall begrenzt wird. Dafür wird jeder Botschaft im Netzwerk ein sogenannter VL (Virtueller Link) — ein virtueller Pfad, der genau einen Datenstrom bezeichnet — zugewiesen. Jeder VL enthält anschließend eine definierte BAG. Es liegt in der Verantwortung des Netzwerkdesigners das Netzwerk nicht zu überlasten. Dafür muss die Summe aller Bandbreiten der VLs, die über einen physikalischen Link transportiert werden, stets unter dessen Kapazität liegen. Die Übertragung in AFDX ist nicht deterministisch. Durch den Einsatz von full-duplex Switched Ethernet kann zwar keine Kollision auftreten, es können aber Warteschlangen an den ausgehenden Ports entstehen. Über die BAG aller VL lässt sich jedoch eine obere Grenze für die maximal zu erwartende Latenz und den Jitter beweisen [36]. Dadurch ist AFDX für Echtzeitanwendungen geeignet. AFDX erlaubt die Definition von redundanten Links. Über eine Sequenznummer können dabei beim Empfänger redundante Pakete gefiltert werden. AFDX ist kein reines Layer 2-Protokoll. Das Protokoll verwendet neben Ethernet für die Strukturierung der VLs zusätzlich die Protokolle IP (Internetprotokoll) und UDP (User Datagram Protocol). Für die Überwachung zur Einhaltung der Bandbreitenkontingente setzt AFDX spezielle Switche ein. Auf Seite des Endsystems kann der AFDX Stack grundsätzlich in Hard- oder Software implementiert werden. Time-triggered Echtzeit-Ethernet Die time-triggered Echtzeit-Ethernet-Protokolle arbeiten synchron zeitgesteuert auf Basis einer globalen Zeit. Eine für den Einsatz in Fahrzeugen verschiedener Art entwickelte time-triggered Ethernet-Lösung ist TTEthernet. Die IEEE-TSN-Gruppe standardisiert mit IEEE 802.1Qbv mittlerweile ein eigenes zeitgesteuertes Echtzeit-Ethernet-Protokoll, welches unter anderem in Fahrzeugen eingesetzt werden soll. Im Folgenden werden die beiden Ansätze vorgestellt und verglichen.

2.1 Stand der Technik

35

TTEthernet (AS6802): Die Grundlagen für TTEthernet stammen aus der Entwicklung der RTS Group (Real-Time Systems) der TU Wien im Jahr 2004. Das Spin-off TTTech Computertechnik AG übernahm die Konzepte, entwickelte diese weiter und vermarktet TTEthernet kommerziell. Seit Ende 2011 ist TTEthernet durch die SAE als AS6802 [124] standardisiert. TTEthernet ist keine reine time-triggered Technologie. Es definiert neben der time-triggered Nachrichtenklasse den sogenannten rate-constrained Datenverkehr, eine asynchrone Nachrichtenklasse mit Echtzeitgarantien, und erlaubt zudem konkurrierende best-effort Kommunikation über dieselbe physikalische Infrastruktur. TTEthernet benötigt für die Einhaltung der Echtzeitanforderungen spezielle Switche sowie einen TTEthernet Stack auf dem Endsystem. Dieser kann in Hard- oder Software realisiert sein. Die drei Verkehrsklassen von TTEthernet ergänzen sich in ihren Eigenschaften: TT-Datenverkehr: Die synchrone zeitgesteuerte TT-Übertragung arbeitet vergleichbar wie FlexRay (siehe Abschnitt 2.1.1 auf Seite 15) mit einer zwischen allen Teilnehmern im Netzwerk synchronisierten Zeit und zyklischen Sendeslots für die Echtzeitnachrichten. Jeder Teilnehmer im Netzwerk besitzt einen lokalen, auf die Kommunikation im gesamten Netzwerk abgestimmten Zeitplan (Schedule). Dieses Medienzugriffsverfahren wird wegen des Zeitplans auch als koordiniertes TDMA bezeichnet. Aufgrund der vordefinierten Slots kann das physikalische Medium zum Sendezeitpunkt freigehalten werden. Somit ermöglicht die time-triggered Verkehrsklasse eine Kommunikation mit niedriger Latenz und minimalem Jitter. RC-Datenverkehr: RC-Botschaften (rate-constrained) arbeiten nicht nach dem time-triggered Prinzip, sondern werden asynchron versendet. Die RCVerkehrsklasse leitet sich aus dem AFDX-Standard ab und verwendet dessen Medienzugriffssteuerung auf dem Layer 2. Die Echtzeitgarantien werden durch die Limitierung der Bandbreite jedes Senders erreicht. Dabei wird für jede Nachrichtenquelle eine sogenannte BAG festgelegt. Diese definiert den minimalen Abstand zweier Botschaften derselben Quelle. Die Einhaltung der BAG wird dabei von jedem Switch auf dem Pfad von Sender zu Empfänger überprüft. Durch die limitierte Bandbreite ist sichergestellt, dass eine definierte Anzahl an Echtzeitbotschaften im Netzwerk nicht überschritten werden kann. Es lässt sich die obere Grenze für die Verzögerung und damit die maximale Netzwerklatenz berechnen und über die Konfiguration beweisen [36]. BE-Datenverkehr: Der BE-Datenverkehr (best-effort) entspricht den Standard-Ethernet-Botschaften nach IEEE 802.3, welche mit der niedrigsten

36

2 Stand der Wissenschaft und Technik

TTEthernet Paket: 72 B bis 1526 B

Layer 1 Layer 2

Präambel

Start of Frame

7B

1B

TTEthernet Frame: 64 B bis 1518 B

TTEthernet Header: 14 B CT-Adresse: 6 B

MAC Ethertype CT-Marker CT-ID Quelle 4B

2B

6B

2B

Nutzdaten

42 B bzw. 46 B bis 1500 B

Frame Inter Check Frame Sequence Gap 4B

12 B

Abbildung 2.9: TTEthernet Frame-Format (eigene Darstellung)

Priorität im Netzwerk transportiert werden. Er erlaubt die Integration von Geräten, welche keine Echtzeitkommunikation benötigen und diese auch nicht beherrschen. BE-Botschaften unterliegen keinen Garantien und können jederzeit verzögert oder sogar verworfen werden, sofern die Übertragung einer Echtzeitnachricht gefährdet wird. Es kann nicht pauschal festgelegt werden, welche der beiden Echtzeitverkehrsklassen (TT oder RC) die besseren Übertragungseigenschaften für eine Anwendung bereitstellt. Die Zuordnung muss stets im Hinblick auf die Anwendung erfolgen. Für die Nutzung von TT-Datenverkehr eignen sich zyklische Informationen mit einer möglichst konstanten Datengröße. Dies sind insbesondere zyklisch organisierte Regelkreise. Wegen der Variabilität ihrer Periode oder Datengröße eignen sich RC-Datenströme eher für Anwendungen wie komprimierte Videodaten (Kamera) oder die Übertragung asynchroner Botschaften, wie sie in CAN Gateways entstehen (siehe auch Abschnitt 3.5 auf Seite 94). Die Adressierung der Echtzeitdatenströme in TTEthernet verwendet das Prinzip der VLs. Ein VL ist ein virtueller Pfad zwischen einem Sender und einem oder mehreren Empfängern. Echtzeitnachrichten werden nicht an einen Teilnehmer, sondern an einen solchen VL adressiert. Dafür unterteilt TTEthernet die ursprüngliche Empfängeradresse in zwei Teile (siehe Abbildung 2.9); die ersten vier Byte werden zum CT-Marker (Critical Traffic). Anhand dieser konstanten ID kann der Empfang einer Echtzeitbotschaft erkannt werden. Die letzten zwei Byte definieren die CT ID, eine für jeden VL eindeutige Kennzahl. VLs sind immer statisch konfiguriert und besitzen eine offline festgelegte Route. Eine redundante Topologie ist möglich. Abbildung 2.10 auf der nächsten Seite zeigt den konkurrierenden Zugriff im Netzwerk. Im Beispiel sind drei Steuergeräte mit unterschiedlichen Anwendungen an einem Echtzeit-Switch angebunden. Alle Nachrichten sollen über einen einzigen Link an einen weiteren Switch weitergeleitet werden.

2.1 Stand der Technik

37

zeitkritisch synchron z.B. Fahrwerk TT

TT

t

Zyklus

TTE Switch

zeitkritisch asynchron z.B. Kamera

TT

TTE Switch

RC

BE

BE

TT

BE

Zyklus

t

RC

t

best-effort Hintergrund z.B. Diagnose

BE

BE

TT

Time-triggered Nachricht

RC

Rate-constrained Nachricht

BE

Best-effort Nachricht

BE

t

Abbildung 2.10: Systembeispiel TTEthernet – Shaping mit drei TrafficKlassen, gemäß dem Medienzugriffsverfahren im TTEthernet (eigene Darstellung)

Vorrang haben dabei die streng zyklisch gesendeten TT Frames. Sie werden auf Basis des offline definierten Schedules weitergeleitet. Die Lücken im Schedule werden mit den event-basierten Botschaften aufgefüllt. Die RC Frames transportieren ebenfalls Echtzeitdatenverkehr und haben Vorrang vor der best-effort-Kommunikation. Die verbleibende Bandbreite wird anschließend mit BE Frames aufgefüllt. Für die Zeitsynchronisierung definiert TTEthernet ein eigenes zweistufiges Synchronisierungsprotokoll. Es basiert auf so genanten PCF (Protocol Control Frame) und einem drei-Rollen-Prinzip: Synchronization Master senden ihre lokale Zeit in das Netzwerk Compression Master berechnen aus den empfangenen Zeiten eine neue globale Zeit für alle Teilnehmer Synchronization Clients empfangen die globale Zeit und justieren damit ihre lokale Uhr

38

2 Stand der Wissenschaft und Technik

Sync Master Endsystem

Sync Client Endsystem 1. PCF (lokale Zeit)

2. PCF (globale Zeit)

2. PCF (globale Zeit) Compression Master Switch

2. PCF (globale Zeit)

2. PCF (globale Zeit) 1. PCF (lokale Zeit)

Sync Client Endsystem

Sync Master Endsystem

Abbildung 2.11: Zweistufiges TTEthernet-Synchronisierungsprotokoll mit drei Rollen — schematisches Beispiel mit einem Compression Master als Switch und jeweils zwei Endsystemen als Synchronization Master und Client (eigene Darstellung)

Abbildung 2.11 zeigt ein schematisches Netzwerk mit den verschiedenen Rollen im Synchronisierungsprozess. Im ersten Schritt senden alle Synchronization Master ihre lokale Zeit an einen oder mehrere Compression Master. Dieser berechnet aus allen empfangenen Werten eine gemeinsame Zeitbasis. Je nach Anzahl empfangener Zeiten kommen dabei unterschiedliche Algorithmen für die Berechnung zum Einsatz. Die ermittelte neue globale Zeit wird anschließend an alle Master und Clients weitergeleitet und dort zum Nachjustieren der lokalen Uhren verwendet. Durch den Einsatz mehrerer Synchronization und Compression Master kann eine höhere Ausfallsicherheit durch Redundanz erreicht werden. Die Zuteilung der Rollen an Switche und Endsysteme ist grundsätzlich frei. Da die PCF je nach Topologie mehrere Switche durchlaufen, an denen sie potentiell verzögert werden können, enthalten sie das sogenannte Transparent Clock-Feld. In diesem Feld wird in jedem weiterleitenden Gerät die Latenz aufaddiert, die durch das jeweilige Gerät verursacht wurde. Damit kann beim Empfänger der genaue Absendezeitpunkt der Nachricht rekonstruiert werden. TSN Scheduled Traffic (IEEE 802.1Qbv): Der IEEE 802.1Qbv-Standard [71] implementiert time-triggered Kommunikation auf Basis der Nachrichtenklasse. Dies unterscheidet den Standard beispielsweise von AS6802,

2.1 Stand der Technik

39

welcher time-triggered Nachrichten auf Nachrichtenstromebene (auf Ebene der VL) bietet und damit eine genauere Konfiguration erlaubt. Wie IEEE 802.1Qav ist auch IEEE 802.1Qbv eine Erweiterung des 802.1Q-Standards. Er sieht vor, dass acht Warteschlangen — definiert durch die acht Prioritäten im Q-Tag — synchronisiert und zeitgesteuert aktiviert beziehungsweise deaktiviert werden. Zur Synchronisierung aller Teilnehmer im Netzwerk kommt der IEEE 802.1AS-Standard [73], eine Erweiterung des IEEE 1588 PTP (Precision Time Protocol) [77], zum Einsatz. IEEE 802.1Qbv löst das Problem von Ethernet AVB mit CBS, dass Frames mit hoher Priorität durch einen Frame niedriger Priorität blockiert werden können. Der Schedule erlaubt die Definition von Zeitschlitzen, in denen nur bestimmte Verkehrsklassen eine Sendeerlaubnis erhalten. Damit ist es weniger flexibel als beispielsweise das AS6802-Protokoll, reduziert jedoch die Komplexität der benötigten Schedules. Da der IEEE 802.1Qbv-Standard gegenüber AS6802 eine vereinfachte timetriggered Kommunikation realisiert, lassen sich die zu erwartenden Netzwerkmetriken durch geeignete Parametrisierung von AS6802-Simulationsmodellen und mit AS6802-Hardware nachstellen. Eine gesonderte Betrachtung ist daher im Rahmen der vorliegenden Arbeit nicht notwendig. Als IEEE-Standard ist für IEEE 802.1Qbv im Vergleich zu AS6802 mit einer insgesamt höheren Akzeptanz in der Automobilindustrie zu rechnen. Frame Preemption In unsynchronisierten Echtzeit-Ethernet-Protokollen kann die Übertragung eines hoch priorisierten Ethernet Frames durch einen niedrig priorisierten Frame, der den ausgehenden Link belegt, verzögert werden. Für Ethernet mit 100 Mbit/s ergibt sich durch die maximale Frame-Größe lmax = 1518 B und die Bit-Übertragungszeit von tb = 0,01 μs/bit sowie dem IFG tIF G = 0,96 μs eine maximale Verzögerung von tLmax = 122,4 μs: tLmax = lmax · tb + tIF G μs = 1518 B · 8 bit B · 0,01 bit + 0,96 μs = 122,4 μs

(2.1)

Frame Preemption ist ein neuer Ansatz, um Echtzeitfähigkeit in Ethernet zu unterstützen. Dabei wird die Übertragung von niedrig priorisierten Botschaften bei Bedarf unterbrochen, um eine hoch priorisierte Botschaft passieren zu lassen. Anschließend wird die Übertragung fortgesetzt. Frame Preemption wurde in IEEE 802.3br [65] für das MAC Layer definiert. IEEE

Queues

2 Stand der Wissenschaft und Technik Time-triggered

Ausgang

40

ohne Preemption

Guard Band (GB)

mit Preemption

BE

TT BE

Best-effort

GB

TT TT

BE BE t

Abbildung 2.12: Verkürzung des Guard Band durch Preemption — Bessere Ausnutzung der Bandbreite (eigene Darstellung)

802.1Qbu [76] standardisiert dazu die notwendigen Dienste für das Unterbrechen von Frames sowie neue unterbrechbare Verkehrsklassen. Da Frame Preemption das notwendige Guard Band8 reduziert (siehe Abbildung 2.12), kann es in zeitgesteuerten Netzwerken die nutzbare Kapazität verbessern. Das Guard Band muss nun nicht mehr so groß sein wie die größte mögliche Nachricht, sondern kann auf die Zeit reduziert werden, die benötigt wird, um einen Frame zu unterbrechen. Darüber hinaus reduziert Frame Preemption die maximale Latenz für hoch priorisierte asynchrone (event-triggered) Botschaften. Best-effort Hintergrunddatenverkehr wird dafür so früh wie möglich, jedoch nach den Regeln von Frame Preemption, unterbrochen und nach dem hoch priorisierten Echtzeit-Frame fortgesetzt (siehe Abbildung 2.13 auf der nächsten Seite). Abbildung 2.14 auf Seite 42 zeigt das Frame-Format für Ethernet mit Preemption. Express-Frames und Frames, welche unterbrochen werden können, werden anhand unterschiedlicher Werte im Start-Delimiter-Byte unterschieden (siehe Abbildung 2.14a). Davon abgesehen bleibt das Standard Ethernet Frame-Format unverändert. Das Fragment eines Frames (siehe Abbildung 2.14b) hat einen dem Standard-Frame vergleichbaren Aufbau. Die FCS wird ersetzt durch eine Fragment Check Sequence, welche geeignet ist, einen Bitfehler im Fragment zu erkennen. Auch nach dem Fragment muss ein IFG eingefügt werden, bevor ein Expresspaket gesendet werden kann. Nachfolgende Fragmente (siehe Abbildung 2.14c) besitzen eine verkürzte 8 Das

Guard Band ist in time-triggered Echtzeit-Ethernet-Varianten ein Mechanismus um zu verhindern, dass eine synchrone TT-Botschaft durch eine asynchrone Botschaft verzögert wird. Innerhalb des Guard Band darf die Übertragung eines asynchronen Frames nicht gestartet werden, da dieser in das time-triggered Sendefenster hineinreichen könnte.

Queues

2.1 Stand der Technik Event-triggered (Echtzeit)

41

RT BE

Best-effort

Ausgang

Verzögerung ohne Preemption mit Preemption

BE BE

RT

Verzögerung

RT BE (Rest) t

Abbildung 2.13: Verkürzung der Ende-zu-Ende-Latenz und des Jitters durch Preemption (eigene Darstellung)

Präambel, gefolgt von einem Fragment-Delimiter. Ein 1 B großer Fragmentzähler definiert die Reihenfolge der Fragmente für das Zusammensetzen des Frames beim Empfänger. Das Feld ist kodiert; die Werte haben einen Hamming-Abstand9 von vier. Anschließend wird der Payload des unterbrochenen Frames fortgesetzt. Das letzte Fragment eines Frames enthält die original FCS für den gesamten Frame. Um die Kompatibilität mit Standard-PHY-Chips (Physical Layer) zu erhalten, definiert der Standard entsprechend IEEE 802.3 [66] eine minimale Fragmentgröße von 64 B. Dadurch ist der kleinste fragmentierbare Frame 124 B groß (60 B erstes Fragment zuzüglich 64 B zweites Fragment). Um die Effizienz des Speicherns und Zusammensetzens der Fragmente zu verbessern, ist — abgesehen vom letzten Fragment — ein Alignment in Schritten von 8 B vorgesehen. Dies bedeutet, dass nur in Schritten von 64 bit eine Unterbrechung des Frames vorgesehen ist. Dies kann zu weiteren Verzögerungen des Express-Frames führen. In Abschnitt 3.4.3 (Seite 92) wird gezeigt, dass das Aufheben der minimalen Fragmentgröße die Echtzeiteigenschaften von Frame Preemption signifikant verbessern kann. Die Referenzimplementierung sieht vor, das MAC-Modul in zwei Pfade (Express MAC und Preemptable MAC) zu teilen (siehe Abbildung 2.15 auf Seite 43). Dabei entscheidet der Traffic Shaper basierend auf der TrafficKlasse, in welchem MAC-Modul der jeweilige Frame zu verarbeiten ist. Das MAC-Merge-Zwischenlayer fordert Frames zunächst vom Express MAC und 9 Der

Hamming-Abstand ist ein Maß für die Unterscheidbarkeit von Symbolen. Der Abstand zweier Blöcke ist dabei die Anzahl unterschiedlicher Stellen. Auf Basis von Wahrscheinlichkeiten kann der Hamming-Abstand zur Fehlererkennung und -korrektur eingesetzt werden.

42

2 Stand der Wissenschaft und Technik

Express Paket: 72 B bis 1526 B

Layer 1 Layer 2

Ethernet Frame: 64 B bis 1518 B

Ethernet Header: 14 B

Präambel

7B

Express / Start MAC MAC Ethertype/ Fragment Ziel Quelle Länge 1B

6B

Nutzdaten

2B

6B

46 B bis 1500 B

Frame Inter Check Frame Sequence Gap 4B

12 B

(a) Express- oder unfragmentierter Frame Erstes Fragment: 72 B bis 1466 B (8 B Alignment)

Layer 1

Layer 2

Ethernet Frame (Teil): 60 B bis 1454 B

Ethernet Header: 14 B Start Präambel Fragment MAC MAC Ethertype/ Delimiter Ziel Quelle Länge 7B

1B

6B

6B

2B

Nutzdaten

46 B bis 1440 B

Fragment Inter Check Frame Sequence Gap 4B

12 B

(b) Erstes Fragment Letztes Fragment: 72 B bis 1466 B

Layer 1

Layer 2

Präambel

6B

Fragment Fragment Delimiter Zähler 1B

1B

Ethernet Frame (Teil): 64 B bis 1458 B

Nutzdaten

60 B bis 1454 B

Frame Inter Check Frame Sequence Gap 4B

12 B

(c) Letztes Fragment

Abbildung 2.14: Format von Ethernet Frames mit Preemption, Express Traffic (a), erstes Fragment (b) und letztes Fragment (c) (eigene Darstellung)

wenn dort nicht vorhanden vom Preemptable MAC an. Sobald der Traffic Shaper einen Frame in das Express MAC übergibt, wird ein PreemptionSignal ausgelöst, welches die Übertragung eines für Preemption geeigneten Frames zum nächstmöglichen Zeitpunkt unterbricht.

2.2 Stand der Wissenschaft

43 Traffic Shaper

Express MAC

Preemptable MAC

Preemption Signal

Guard Band Signal

MAC-Merge-Zwischenlayer Standard PHY

Abbildung 2.15: Referenzimplementierung Frame Preemption — Express und Standard MAC mit MAC-Merge-Zwischenlayer (eigene Darstellung)

2.2 Stand der Wissenschaft Im Folgenden wird ein Überblick über den Stand der Wissenschaft im Bereich der Fahrzeugvernetzung und Simulation von verteilten Echtzeitsystemen gegeben. Zunächst werden die Ergebnisse des SEIS-Projekts (Sicherheit in Eingebetteten IP-basierten Systemen), dem in den vergangenen Jahren größten Forschungsprojekt zur Einführung neuer Kommunikationstechnologien im Fahrzeug, vorgestellt. Anschließend werden die Ergebnisse der wichtigsten Forschungsbeiträge aus den Bereichen Protokollvergleich und Evaluierung, time-triggered Kommunikation, formale Zeitanalyse, Simulation, Fahrzeugtopologien, Gateway-Technologien, Fahrzeuganwendungen und modellbasierte Entwicklung beschrieben. Die Bedeutung der jeweiligen Forschungsbereiche für die vorliegende Arbeit wird jeweils eingangs kurz dargestellt.

2.2.1 SEIS — Sicherheit in eingebetteten IP-basierten Systemen Das SEIS-Forschungsprojekt wurde von der Innovationsallianz Automobilelektronik E|ENOVA, die im Jahr 2007 von sieben Unternehmen der Automobilindustrie gegründet wurde, initiiert. Wie bereits dargestellt, handelte es sich um das größte Forschungsprojekt der vergangenen Jahre zur Einführung von neuen IP-basierten Kommunikationslösungen im Automobil. Damit gibt es einen guten Überblick über viele Forschungsbereiche, die im Verlauf dieses Kapitels detailliert vorgestellt werden. Das Projekt mit der Laufzeit von Juli 2009 bis Juni 2012 wurde durch das BMBF im Rahmen der IKT2020 (Informations- und Kommunikationstechnologie) und der Hightech-Strategie der Bundesregierung gefördert. Das

44

2 Stand der Wissenschaft und Technik

Projektkonsortium bestand aus den Firmen: Alcatel-Lucent Deutschland AG, Audi AG, Audi Electronics Venture GmbH, BMW AG, BMW Forschung und Technik GmbH, Continental Automotive GmbH, Daimler AG, EADS Deutschland GmbH, Elektrobit Automotive GmbH, Infineon Technologies AG, Robert Bosch GmbH, Volkswagen AG, Friedrich-Alexander-Universität Erlangen-Nürnberg, Lehrstuhl für Hardware-Software-Co-Design, Universität Karlsruhe, Institut für Telematik, TU Chemnitz, Lehrstuhl für Schaltkreisund Systementwurf, Technische Universität München, Lehrstuhl für Kommunikationsnetze und Lehrstuhl für Medientechnik, Fraunhofer-Einrichtung für Systeme der Kommunikationstechnik ESK, Fraunhofer-Einrichtung für Angewandte und Integrierte Sicherheit AISEC. Die Projektkoordination wurde durch BMW Forschung und Technik GmbH abgewickelt. Es stand ein Gesamtbudget von 18 Millionen Euro zur Verfügung. Das SEIS-Projekt war das erste große Forschungsprojekt zur Einführung von IP-basierter Kommunikation in Fahrzeugnetzwerken und untersuchte im Arbeitspaket „Geeignete Technologien für IP-Kommunikation im Fahrzeug“ unter anderem ebenfalls erstmals auch die Eignung der Ethernet-Technologie für den Einsatz im Automobil. Der Fokus lag jedoch im Bereich der IPKommunikation sowie auf dem Thema Sicherheit [50]. Die Vision des Projekts war die durchgängige Verwendung von IP in allen Anwendungsbereichen des Fahrzeugs [144]. Es wurde festgestellt, dass sich Ethernet grundsätzlich für den Einsatz in einem eingebetteten IP-basierten Bordnetzwerk eignet [39, 56]. Ethernet wurde als gut skalierbar beschrieben, und die Unterstützung für die Bereiche Security und QoS wurde hervorgehoben [39]. Es wurden Echtzeit-EthernetErweiterungen aus diversen Anwendungsdomänen auf Basis ihrer Spezifikationen verglichen [144]. Ein analytischer oder simulationsbasierter Vergleich anhand realer Fahrzeugarchitekturen fand im Rahmen von SEIS jedoch nicht statt. Die Fahrzeugnetzwerktopologie wurde als wichtiges Element für den Erfolg einer IP-basierten Bordnetzlösung identifiziert [39, 56]. Es wurde betont, dass die konkrete Auslegung des Netzwerks und seiner Komponenten entsprechend den Anforderungen von zentraler Bedeutung ist [55]. Im Bereich der Gateway-Technologien, die Botschaften von KFZ-Bussystemen wie beispielsweise CAN, FlexRay oder MOST auf geswitchte Ethernetbeziehungsweise IP-basierte Netze abbilden, wurde deutlich, dass der Aufwand für eine Migration nicht pauschal zu berechnen ist. Insbesondere die große Anzahl der zu optimierenden Dimensionen erschweren ein analytisches Vorgehen [56].

2.2 Stand der Wissenschaft

45

Es wurden Echtzeiteigenschaften von Protokollen, die auf der IP-Ebene aufsetzen — insbesondere zur Übertragung von Kamera- und MultimediaDaten — untersucht [133, 170]. In diesem Zusammenhang wurde auch das QoS-Verhalten von Echtzeit-Ethernet-Erweiterungen wie Ethernet AVB betrachtet. Hierbei wurden jedoch nur einfache Szenarien mit einer Kamera und einer Datensenke und der direkten Verbindung über einen Switch betrachtet. Für die Untersuchung wurde eine Simulation in OMNeT++ erstellt. Es wurden mehrere Traffic-Shaping-Varianten überprüft. Als Worstcase für die Dauer der Netzwerkübertragung eines Kamerabilds wurden 55 ms festgelegt. Die Ergebnisse zeigen, dass in dieser Konfiguration maximal zwei Kameras in H.264-Enkodierung mit einer Auflösung von 720p bei 30 Bildern pro Sekunde über einen Link mit 100 Mbit/s Bandbreite zu übertragen sind. Bei der Übertragung von Bilddaten wurde gezeigt, dass sich die hohe Variabilität in der Bandbreitennutzung des H.264-Codecs schlecht auf die Pufferbelegung in den Netzwerkkomponenten und damit negativ auf die Ende-zu-Ende-Latenz und den Jitter auswirkt. Es wurde daher der Einsatz des MJPEG-Codecs (Motion JPEG) empfohlen [133]. In der vorliegenden Arbeit wird ebenfalls die Videoübertragung auf Basis von MJPEG verwendet und untersucht. Bei der Analyse von Ethernet AVB wurde festgestellt, dass die Beschränkung auf maximal acht Prioritäts- beziehungsweise Verkehrsklassen — eine Limitierung des IEEE 802.1Q-Standard [72] — nicht immer zu optimalen Ergebnissen führt und somit eine größere Anzahl an Verkehrsklassen wünschenswert ist [55]. Bei der Untersuchung der Synchronisierungsgenauigkeit des AVB-Protokolls [73] wurde in empirischen Untersuchungen eine sehr hohe Präzision der synchronisierten Uhren und ein geringer Jitter von weniger als 160 ns gemessen. Dazu wurden Testboards in der Klimakammer unterschiedlich konditioniert (−10 ◦C bis 70 ◦C), um eine hohe Abweichung der Taktrate der verbauten Quarze zu erzeugen [90, 137]. Es wurde festgestellt, dass die Migration zu einer IP-basierten Architektur nur schrittweise erfolgen kann, da ein kompletter Umstieg von einer Fahrzeuggeneration zur nächsten einen zu großen Umbruch bedeuten würde [55]. Als Lösung wurden sogenannte DM (Domänen-Master) vorgeschlagen, welche ihre jeweilige — beispielsweise über CAN oder FlexRay — angebundene Domäne im IP-Netzwerk repräsentieren. In diesem Zusammenhang wurde auch die Möglichkeit einer Datenaggregation im DM genannt [137]. Der Vorteil der Aggregation liegt dabei in der besseren Auslastung des Ethernet-Netzwerks. Als Nachteile werden der erhöhte Konfigurationsaufwand sowie zusätzliche

46

2 Stand der Wissenschaft und Technik

Latenz genannt [137]. Zudem sollte sich ein DM später transparent entfernen lassen, wenn seine Domäne direkt über das IP angebunden wird [170]. Im Rahmen von SEIS wurden Werkzeuge zur Design Space Exploration und Architekturbewertung entwickelt. Dabei wurde für die Systemmodellierung PREEvision [162] von Vector Informatik verwendet. Ein PREEvision-Plugin erzeugt dabei eine Spezifikation für den SystemCoDesigner [49]. Hier wird der Designraum ausgefaltet und mögliche Architekturvarianten als virtueller Prototyp [51] evaluiert. Die Ergebnisse werden unter Einhaltung von Latenzen anhand verschiedener überwiegend nicht-funktionaler Metriken wie monetäre Kosten, Energieverbrauch oder Zuverlässigkeit bewertet. Das Ziel war dabei eine Pareto-optimale Architektur [144].

2.2.2 Protokollvergleiche Die Entwicklung und Parametrisierung der zur Verwendung im FahrzeugBackbone verwendeten Echtzeitübertragungstechnologie ist ein zentrales Ziel der vorliegenden Arbeit. Im Folgenden werden Studien vorgestellt, die als Grundlage oder Ergänzung für die durchgeführten Untersuchungen dienen. Zeng, Khalid und Chowdhury untersuchen in einer qualitativen Vergleichsstudie FlexRay und Standard Ethernet [166]. Dabei werden insbesondere die Kosten, Bandbreite und Fehlertoleranz sowie der Grad des zu erreichenden Determinismus verglichen. Die Ergebnisse entsprechen den Erwartungen: Ethernet als COTS-Technologie (Components-of-the-shelf), wird als günstiger bewertet; dabei werden die Kosten für ein angepasstes physikalisches Layer wie IEEE 802.3bw [67] jedoch nicht berücksichtigt. Ebenfalls wie erwartet liegt die Bandbreite von Ethernet mit 100 Mbit/s über der von FlexRay (bis zu 10 Mbit/s). Überraschend werden sowohl FlexRay als auch Ethernet als Payload-effizient — also als Technologien mit wenig Protokoll-Overhead — bezeichnet. Insbesondere für FlexRay ist aus Sicht des Autors der vorliegenden Arbeit, gerade bei den in Automobilnetzwerken üblichen kleinen Botschaften (bei FlexRay typischerweise bis 18 B Nutzdaten), ein hoher Overhead (mindestens 10 B, zuzüglich Sicherheiten für die Synchronisierung) einzuplanen (siehe auch Abschnitte 2.1.1 auf Seite 15 und 3.4.2 auf Seite 81). Da der Vergleich nur Standard Ethernet verwendet, fällt auch der Vergleich der Fehlertoleranz eindeutig aus, da Standard Ethernet keine Fehlerkorrektur und keine Redundanzmechanismen anbietet. Zeng, Khalid und Chowdhury erwähnen zwar Echtzeiterweiterungen wie Ethernet AVB (siehe auch Abschnitt 2.1.3 auf Seite 31) und TTEthernet (Abschnitt 2.1.3 auf Seite 35), beziehen deren Eigenschaften jedoch nicht in die Bewertung ein.

2.2 Stand der Wissenschaft

47

Salzwedel vergleicht CAN-, FlexRay- und Ethernet-basierte Architekturen für den Einsatz in ABS (Antiblockiersystemen) [125]. Hierbei werden Erfahrungen aus der Einführung von Ethernet im Flugzeug (AFDX, siehe auch Abschnitt 2.1.3 auf Seite 33) auf den Einsatz im Automobil übertragen. Salzwedel vergleicht ABS-Architekturen auf Basis von CAN, FlexRay und AFDX. Dabei kann gezeigt werden, dass das Ethernet-basierte System die Anforderungen der ABS-Anwendung erfüllt. Balbierer et al. vergleichen den Energiebedarf von Feldbus- und Ethernetbasierten Fahrzeugnetzwerken [28]. Ein analytisches Modell approximiert den Energieverbrauch unter Berücksichtigung der Topologie und Auslastung des Netzwerks. Die Ergebnisse zeigen, dass Ethernet zwar einen höheren Energiebedarf als die Feldbustechnologien CAN und FlexRay aufweist, gegenüber der Konkurrenztechnologie MOST jedoch einen geringeren Verbrauch hat. Verbesserungen wie EEE (Energy Efficient Ethernet) [69], bei denen der Ethernet Transceiver im Leerlauf abgeschaltet wird, erlauben sogar die Reduzierung des Energiebedarfs auf das Niveau von FlexRay. Die Autoren betonen den hohen Einfluss von Ethernet-Switchen auf den Energiebedarf. Dieser resultiert aus der Switch-Logik die, unabhängig von der Anzahl an Ports, immer vorhanden sein muss. Daher ist im Vergleich die Daisy-Chain10 Topologie aufgrund ihrer hohen Anzahl an Switchen am ineffizientesten. Die besten Ergebnisse liefert folglich eine Sterntopologie (30 % bis 40 % geringerer Energiebedarf). Die Untersuchung wurde auf Standard Ethernet nach IEEE 802.3 [66] beschränkt. Das für Automotive Ethernet entwickelte BroadRReach (IEEE 802.3bw [67], siehe auch Abschnitt 2.1.2 auf Seite 25) wurde nicht untersucht. Daher lassen sich die Ergebnisse nicht direkt auf die in dieser Arbeit untersuchten Netzwerkarchitekturen anwenden. Dennoch lassen sich die Ergebnisse zur Energieeffizienz verschiedener Topologien bei der Bewertung von Architekturvarianten nutzen. In mehreren Literaturstudien wird ein Überblick über Forschungsfragen rund um Automotive Ethernet-Technologien gegeben. Lo Bello motiviert die Einführung von Automotive Ethernet und den damit verbundenen Technologien [101]. Ethernet AVB und TTEthernet werden hier als aussichtsreiche Kandidaten für die Einführung im Fahrzeug aufgeführt. In einem Update ihres Surveys von 2014 [100] fokussiert sich die Autorin auf den Einsatz der time-triggered Erweiterung von Ethernet AVB. Tuohy et al. [157, 156] folgern, 10 Eine

Daisy-Chain (zu deutsch, wörtlich: Gänseblümchenkette) ist eine in Serie miteinander verbunde Kette von Hardware-Komponenten. Dabei muss das Signal eines Teilnehmers von seinen Nachbarn solange weitergeleitet werden, bis es den Empfänger erreicht.

48

2 Stand der Wissenschaft und Technik

dass Ethernet die größten Aussichten für den Einsatz als zukünftige Fahrzeugnetzwerktechnologie besitzt. Es wird insbesondere der Wert der IEEEStandardisierung betont. Die Autoren heben jedoch hervor, dass für den Einsatz in zeitkritischen Anwendungen weitere Queueing- und SchedulingErweiterungen evaluiert werden müssen, um den Anforderungen gerecht werden zu können. Entsprechende Ansätze werden derzeit in der IEEE-TSNGruppe erarbeitet. Schneele und Geyer [128] vergleichen Ethernet AVB und das AFDX-Protokoll aus der Perspektive der Flugzeugindustrie. Die Autoren stellen fest, dass die Echtzeitattribute von AFDX nicht direkt mit Ethernet AVB abbildbar sind. Für spezifische Anwendungen im Flugzeug, insbesondere im Bereich von Video- und Sprachübertragung [58] mit dem CBS, wird jedoch das Potenzial des IEEE-Standards für Anwendungen mit niedrigen Sicherheitsanforderungen hervorgehoben. Mit den Erweiterungen für Time Aware Shaping und Preemption könnte der mögliche Anwendungsbereich von AVB im Flugzeug darüber hinaus auch auf Anwendungen mit höheren Anforderungen ausgedehnt werden.

2.2.3 Time-triggered Kommunikation TDMA-Kommunikation ist eine geeignete Technik, um deterministische Kommunikation mit sehr niedriger Latenz und geringem Jitter zu erreichen. Daher werden time-triggered Konzepte in der vorliegenden Arbeit intensiv evaluiert, um ihre Vor- und Nachteile bewerten zu können. Mit dem TABS (Time Aware Blocking Shaper) [22] präsentieren Alderisi, Patti und Lo Bello ein Konzept mit vergleichbaren Attributen zu dem in der vorliegenden Arbeit vorgestellten Time-Aware-Shaper-Prinzip (siehe Abschnitt 4.5 auf Seite 152). Auch in ihrem Konzept wird eine TDMA-basierte Traffic-Klasse zusätzlich zum AVB-Datenverkehr eingeführt. Für eine synthetische Topologie vergleichen die Autoren in einer Simulation die Ergebnisse von time-triggered Traffic mit dem TABS-Konzept, Standard-AVB und timetriggered Traffic aus TTEthernet. Aus Sicht des Autors der vorliegenden Arbeit erscheinen die erzielten Ergebnisse in Hinblick auf den erzielten Jitter auffällig. Hier wurden für AVB Traffic, der mit einem CBS verarbeitet wird, bessere Werte erreicht als mit time-triggered Traffic im TTEthernet. Es ist unklar, mit welcher Simulationsumgebung die Ergebnisse erzielt wurden, jedoch lassen die angegebenen Werte auf eine ungenaue oder fehlerhafte Konfiguration der Simulation schließen. Weiterhin ist unklar, warum der angegebene Jitter höher ist als die Differenz aus maximaler und minimaler

2.2 Stand der Wissenschaft

49

Latenz. Die Schlussfolgerung der Autoren bestätigt die Erwartungen: Es wird festgestellt, dass time-triggered Traffic bessere Ende-zu-Ende-Latenzen als Standard-AVB-Datenverkehr erzielt. Der Einfluss von TDMA-Nachrichten auf das Verhalten des CBS wurde nicht analysiert. Die Untersuchung dieser gegenseitigen Beeinflussung von time-triggered und event-triggered Echtzeitbotschaften im Rahmen der in der vorliegenden Arbeit gezeigten Analyse des Time Aware Shapers (siehe Abschnitt 4.5 auf Seite 152) zeigt jedoch, dass sich das Verhalten der asynchronen Verkehrsströme durch zusätzliche TDMA-Kommunikation stark verändern kann und unbedingt betrachtet werden sollte.

2.2.4 Simulation Die Simulation wird in der vorliegenden Arbeit als ein zentrales Werkzeug für die Architekturbewertung verwendet. Eine Vielzahl von Studien zeigt die generelle Eignung von Netzwerksimulationen für die Untersuchung von Fahrzeugnetzwerken: Lauer, German und Pollmer zeigen die Eignung von event-basierten Simulationen für die frühe Auslegung von Systemen im Automobilkontext. Dabei wurden insbesondere Average-Case-Analysen betrachtet [92]. Die Autoren entwickelten ein Simulationsmodell für ECUs, Sensoren und Aktuatoren, welche über Legacy-Bussysteme wie FlexRay verbunden sind. Systeme auf Basis von Ethernet wurden jedoch nicht betrachtet. BMW Forschung und Technik führte Simulationen in OMNeT++ (siehe Abschnitt 4.2.1 auf Seite 107) zur Leistungsüberprüfung von Standard Ethernet, IEEE 802.1Q und Ethernet AVB durch. Lim, Weckemann und Herrscher [99] zeigen anhand einer Surround-View-Anwendung (auch als Birds View bezeichnet), dass Standard Ethernet ohne Priorisierung ungeeignet ist, um die Anforderungen im Automobil zu erfüllen. Für Steuerdaten ist die ermittelte Latenz um Faktor fünf über den Anforderungen. Infolgedessen untersuchten Lim et al. die Leistungsfähigkeit von IEEE 802.1Q und Ethernet AVB für Anwendungen im Automobil [95, 96]. Der Vergleich zeigt, dass Ethernet AVB für Multimedia-Daten deutlich bessere Ende-zu-EndeLatenzen erreicht als IEEE 802.1Q. Dies gilt insbesondere für Strecken mit einer hohen Anzahl an Switching-Hops. Für Steuerdaten zeigen die Autoren, dass die Konfiguration von Ethernet AVB anspruchsvoll ist. Da die SRKlasse A die höchste Priorität im Netzwerk haben muss, können Steuerdaten nur niedriger priorisiert oder als CBS Traffic übertragen werden. Bei einer Konfiguration in einer der SR-Klassen muss jedoch das Observation Window

50

2 Stand der Wissenschaft und Technik

beachtet werden, welches zu weiteren Einschränkungen in der Konfiguration führt (siehe auch Abschnitt 2.1.3 auf Seite 31). Hier sind in IEEE 802.1Q die Konfigurationsmöglichkeiten weniger eingeschränkt und resultieren in einem besseren Echtzeitverhalten der Steuerdaten. Insgesamt können mit beiden Protokollen Ende-zu-Ende-Latenzanforderungen von 10 ms je Paket sicher erfüllt werden. Für Anwendungen mit Latenzanforderungen von maximal 100 μs sind die Protokolle jedoch ungeeignet. In der vorliegenden Arbeit werden zur Erfüllung dieser harten Echtzeitanforderungen Architekturen unter Verwendung von TDMA und Frame Preemption entwickelt und untersucht. Da bei BMW Forschung und Technik vergleichbare Fragestellungen in Bezug auf die Leistung von Echtzeit-Ethernet-Erweiterungen für den Einsatz im Automobil bearbeitet wurden, erfolgte ab 2011 eine Zusammenarbeit zwischen dem Doktoranden Hyung-Taek Lim bei BMW und dem Autor der vorliegenden Arbeit an der HAW Hamburg. Ergebnisse aus dieser Zusammenarbeit sind in Abschnitt 4.4 (Seite 143) und 4.6 (Seite 171) dargestellt. Die Simulation von Funktionen ist in der Automobilindustrie bereits etabliert. Üblicherweise wird dies heute in MATLAB Simulink durchgeführt. Auch die Modellierung von Systemen in SysML (Systems Modeling Language) findet zunehmend Verbreitung [108]. Die Firma MLDesign Technologies entwickelt gemeinsam mit der TU Ilmenau und der University of Florida ein System-level-Simulationswerkzeug für die Analyse von Systemen auf Funktionsebene. Der MLDesigner vereint eine Modellierungs- und eine Simulationsplattform. Die Systeme werden grafisch in hierarchischen Blockdiagrammen beschrieben. Blöcke verfügen über definierte Ein- und Ausgänge, die über Links miteinander verbunden werden können. Auf niedrigster Ebene kann das Verhalten von Blöcken in C++ beschrieben werden [129]. Der MLDesigner ist ein Werkzeug zur Systemoptimierung, insbesondere auch von Echtzeitsystemen. Die Funktionalität des MLDesigner fokussiert sich auf ausführbare Modelle von Systemen. Obgleich Bibliotheken für Netzwerktechnologien — beispielsweise für AFDX, CAN oder FlexRay — zur Verfügung stehen, ist der MLDesigner kein Netzwerksimulator für detaillierte Untersuchungen des Kommunikationsverhaltens zukünftiger Echtzeit-Ethernet-Technologien, wie sie in der vorliegenden Arbeit durchgeführt werden.

2.2.5 Formale Zeitanalyse Neben der Netzwerksimulation ist die formale Zeitanalyse ein verbreitetes Werkzeug, um Netzwerkmetriken zu ermitteln. Formale Zeitanalysetechniken können dabei insbesondere verwendet werden, um Worstcase-Grenzen zu

2.2 Stand der Wissenschaft

51

ermitteln und zuverlässig zu beweisen. Die Herausforderungen liegen dabei in der Genauigkeit der Analysemodelle. Insbesondere die häufig zu pessimistischen Ergebnisse — mit Worstcase-Abschätzungen, die in der Realität nicht auftreten können — sind problematisch. Imtiaz, Jasperneite und Han [79] vergleichen auf Basis eines analytischen Modells die Leistungsfähigkeit von Ethernet AVBs CBS mit Standard Ethernet. Die Autoren entwickeln ein Systemmodell, um Ende-zu-Ende-Latenz sowie Round Trip Time11 in Ethernet AVB zu ermitteln. In ihrer Analyse stellen die Autoren fest, dass Ethernet AVB für die höchste Prioritätsklasse keine bessere Worstcase-Latenz bietet als Standard Ethernet mit Prioritäten nach IEEE 802.1Q, da ein niedrig priorisierter Frame maximaler Größe in beiden Fällen die maximale Verzögerung auslöst. Imtiaz, Jasperneite und Weber benennen drei Ansätze, um diese Worstcase-Latenz zu reduzieren [80]: Preemption (siehe auch Abschnitt 2.1.3 auf Seite 39), Fragmentierung von niedrig priorisierten Botschaften auf dem Layer 2 sowie die Einführung von TDMA. Die Autoren analysieren in einer Fallstudie den Einsatz von Fragmentierung. Dabei kann mit Fragmentierung ein Performance-Gewinn um den Faktor fünf bis neun erreicht werden. Allerdings geht dies bei sehr kleinen Fragmenten deutlich zulasten der zur Verfügung stehenden Bandbreite. Daher muss bei diesem Ansatz ein Kompromiss für die Fragmentgröße gefunden werden. In der vorliegenden Arbeit werden, neben dem beschriebenen fragmentbasierten Ansatz, auch der Einfluss von Preemption und TDMA-Datenverkehr auf das Echtzeitverhalten in Backbone-Netzwerken untersucht. Das Institut für Datentechnik und Kommunikationsnetze der TU Braunschweig und sein Spin-Off Symtavision entwickeln Lösungen für die Zeitanalyse von Echtzeitsystemen (System-Level Performance Analysis). Das dort entwickelte Zeitanalysewerkzeug SymTA/S [141] unterstützt seit kurzem auch Automotive Ethernet. Das Werkzeug basiert auf dem Ansatz der kompositorischen Leistungsanalyse (CPA (Compositional Performance Analysis)). Dabei werden analytische Zeitmodelle einzelner Komponenten mit einer den Datenverkehr beschreibenden Eingabefunktion ausgeführt. Daraus ergibt sich eine Ausgabefunktion, die an die nächste Komponente als Eingabefunktion weitergereicht wird [53, 60]. Der Fokus von SymTA/S liegt auf der systemweiten Zeitanalyse, insbesondere auch auf der Analyse 11 Die

Round Trip Time (deutsch: Paketumlaufzeit) bezeichnet die Reaktionszeit eines kompletten Netzwerks. Sie ist die Summe der Zeit, die benötigt wird, um ein Signal von einem Sender zu einem definierten Empfänger zu senden sowie die Zeit, die benötigt wird, um die Antwort des Empfängers zurück an den Sender zu vermitteln.

52

2 Stand der Wissenschaft und Technik

von Prozessen auf ECUs, SoCs (System-on-a-Chips) und Mehrkernsystemen. Rox, Ernst und Giusto benennen die Herausforderungen und Probleme der kompositorischen analytischen Zeitanalyse in Ethernet-basierten Netzwerkarchitekturen [122]. In einem Vergleich der Worstcase-Ergebnisse mit einer synthetischen Referenzsimulation zeigt sich der starke Pessimismus dieses Ansatzes. Da für jede Komponente im System die größtmögliche Verzögerung berechnet und anschließend für den Pfad zwischen Sender und Empfänger addiert wird, entstehen Worstcase-Zeiten aus Signalkonstellationen, die sehr unwahrscheinlich oder sogar in der Realität unmöglich sind. Damit sind die Ergebnisse im Sinne einer oberen Grenze nicht falsch, da die berechneten Werte im realen System nie überschritten werden, und können somit für den Nachweis einer maximalen Ende-zu-Ende-Latenz herangezogen werden; allerdings liegt diese konservative Grenze über den in der Realität zu erwartenden Werten. Thiele et al. zeigen, dass die pessimistischen Ergebnisse für die CPA verbessert werden können, indem bei der komponentenorientierten Analyse die möglichen Wechselwirkungen der Verkehrsströme [149] sowie die Eigenschaften von FIFO-Queues (First In - First Out) [148] und Traffic Shaping [25] auf Verkehrsströme einbezogen werden. Die an der TU Braunschweig entwickelten formalen Modelle umfassen Ethernet AVBs CBS [41, 42, 43] sowie die neuen Burst Limiting [150], Time Aware und Peristaltic Shaper [151] aus IEEE TSN. Farzaneh, Shafaei und Knoll schlagen ein formales Modell für die Analyse von TSN auf Basis der prädikativen Programmierung (Logic Programming) vor. An den Modellen wird derzeit noch gearbeitet. Die Autoren implementieren Erweiterungen, um Details der Fahrzeugkommunikation mit TSN abbilden zu können [47]. Die französische Firma RTaW (RealTime-at-Work), ein Spin-off des INRIA (Institut National de Recherche en Informatique et en Automatique), entwickelt Werkzeuge für die Zeitanalyse von Echtzeitnetzwerken. Für die WCTA (Worstcase Timing Analyse) kommen Verfahren wie Network Calculus zum Einsatz. Navet, Seyler und Migge definieren jedoch drei Schwächen von analytischen Verfahren [107]: Die berechneten Worstcase-Grenzen sind zu pessimistisch, große Netzwerkarchitekturen sind meist zu komplex, was zu Fehlern führt, und die vereinfachten analytischen Modelle können häufig die komplexen Software- und Hardwarearchitekturen nicht genau genug abbilden. Die Autoren führen aus, dass diese Schwächen im schlimmsten Fall dazu führen können, dass aus den Ergebnissen falsche Schlüsse gezogen werden. Aus diesem Grund empfehlen die Autoren analytische Verfahren durch Simulationsergebnisse zu ergänzen.

2.2 Stand der Wissenschaft

53

2.2.6 Topologien An der TU München wurden, gemeinsam mit BMW Forschung und Technik, bereits in 2008 erste Analysen für mögliche Netzwerktopologien von Infotainmentsystemen im Fahrzeug durchgeführt. Rahmani et al. vergleichen eine von MOST abgeleitete Ringtopologie sowie eine Topologie aus zwei verbundenen Sternen (Double Star) [116]. Die Ergebnisse zeigen einen klaren Vorteil bei sternförmigen Topologien gegenüber der Ring-Topologie, da hier mehr Daten parallel versendet werden können. Dagegen kann es im Ring bei starker Auslastung leichter zu Aufstauungen durch ausgelastete Links kommen. Die Analyse zeigt zudem, dass beide Topologien bei Datenverkehr mit Bursts Paketverluste aufweisen, da in den Switchen die Queues überlaufen können. Die Autoren plädieren für den Einsatz von Traffic Shapern, wie sie in der vorliegenden Arbeit betrachtet werden, um solche Bursts aufzulösen. Ein Traffic Shaper für den speziellen Einsatz von Audio-Video-Anwendungen im Automobil wurde in einer späteren Arbeit vorgestellt [117]. Lim et al. untersuchen verschiedene Topologien für eine Backbone-Architektur mit Domänen-Gateways [97]. Verglichen werden hier ebenfalls die Double-Star-Topologie sowie mehrere Varianten von Daisy-Chains. Die Autoren können die durch die Anwendungen vorgegebenen Ende-zu-EndeLatenzanforderungen von 10 ms in allen Topologien erreichen. Die besten Zeitgarantien werden in der sternbasierten Topologie realisiert. Die DaisyChain-Topologie hat, insbesondere in Konfigurationen ohne Priorisierung, eine sehr hohe Ende-zu-Ende-Latenz.

2.2.7 Gateways Die Anforderung, CAN-Botschaften über Ethernet zu transportieren, ist nicht neu. In Industrieanlagen, die mit Industrial Ethernet arbeiten, gibt es bereits länger den Bedarf, bestehende CAN-Segmente über Gateways an Echtzeit-Ethernet anzubinden [127]. Mit dem Aufkommen von Automotive Ethernet ist dieser Bedarf auch in der Automobilindustrie angekommen. Kern et al. untersuchen drei Varianten der Übersetzung von CAN zu Ethernet [89]. In der ungepufferten Variante wird für jeden CAN Frame ein Ethernet-Paket erzeugt. Im gepufferten Ansatz wird der Warteschlange eine maximale Größe und ein Timeout zugewiesen. Sobald die Warteschlange voll oder der Timeout abgelaufen ist, wird ein Ethernet-Paket mit den gesammelten CAN Frames erzeugt. Im zeitgesteuerten Ansatz wird die Wartezeit der Warteschlange für verschiedene CAN-Prioritäten unterschiedlich gewählt. Diese Wartezeit kann für ausgewählte Nachrichten auch auf null gesetzt werden, um das Senden

54

2 Stand der Wissenschaft und Technik

sofort auszulösen. Die Autoren sprechen hierbei vom Urgency-Ansatz. Die experimentellen Ergebnisse zeigen, dass mit diesem Ansatz für hoch priorisierte CAN-Botschaften vergleichbare Ergebnisse wie mit dem ungepufferten Ansatz erzielt werden können. Dennoch ist die Bandbreitennutzung auf dem Ethernet-Segment deutlich besser. Grundsätzlich haben alle gezeigten Varianten individuelle Vor- und Nachteile. Daher ist eine anwendungsbezogene Konfiguration erforderlich. Dies bestätigen auch die Ergebnisse von Matsumura et al., welche die vorgeschlagenen Ansätze in einer Simulationsumgebung mit synthetischen Verkehrsströmen evaluieren [88, 104]. Thiele et al. präsentieren ein formales Modell, mit dem der Kompromiss zwischen Ende-zu-Ende-Latenz und Bandbreiteneffizienz quantifiziert werden kann [152]. Auf Basis dieses CPA-basierten Modells (siehe auch Abschnitt 2.2.5 auf Seite 50) lassen sich mögliche Konfigurationen effizient überprüfen und optimieren. Herber et al. zeigen ein CAN-zu-Ethernet-AVB-Gateway mit FrameAggregation [61]. Eine Herausforderung bei der Abbildung von CAN auf das Traffic Shaping in Ethernet AVB ist die notwendige Bandbreitenreservierung. Die Autoren schlagen vor, mehr Bandbreite zu reservieren als vom CAN-Bus benötigt, um die Latenz zu reduzieren die im Gateway entsteht, wenn ein eingehender CAN Frame, der über Ethernet AVB weitergeleitet werden soll, warten muss, bis der Kredit ausreichend hoch ist. Dabei wird jedoch nicht auf die Besonderheiten des CBS (IEEE 802.1Qav [74]) eingegangen, bei dem als Minimum ein 64 B Frame je Class Measurement Interval (125 μs für SR-Klasse A, 250 μs für SR-Klasse B) reserviert werden muss. Dies entspricht ohnehin bereits ungefähr 3 Mbit/s netto Nutzdatenrate und damit einem Vielfachen der auf dem CAN-Bus anfallenden Datenrate. Ein Fall, in dem der Kredit negativ ist, wäre demnach nur zu erreichen, wenn weitere Verkehrsströme den Kredit beeinflussen. Der Autor der vorliegenden Arbeit stellt daher infrage, ob die gezeigten Scheduling-Strategien im Netzwerk in der Realität notwendig sind, da bereits in anderen Ansätzen [89, 104, 152] gezeigt wurde, dass Frames für die Aggregation ohnehin im Gateway aufgestaut werden müssten. Zinner et al. zeigen Konzepte für FlexRay- und MOST-zu-EthernetGateways [168]. In ihrem Ansatz wird das AVB-Netzwerk mit der Taktrate von MOST gespeist, um eine synchrone Kommunikation zu erreichen. Ein ähnliches Problem identifizieren die Autoren auch für ein mögliches FlexRay Gateway. Mehrere entfernte FlexRay-Busse, sogenannte Cluster, müssten miteinander synchronisiert werden, um ihre Zeitpläne isochron auszuführen. Die Autoren schlagen vor, die über AVB synchronisierte Zeit als Basis für die Timing Master der FlexRay-Busse zu verwenden.

2.2 Stand der Wissenschaft

55

2.2.8 Anwendungen Hank, Suermann und Müller zeigen eine mögliche Einführung von Ethernet im Automobil anhand eines dreistufigen Prozesses [54]. Nach der ersten Generation — Diagnose und Programmierung über 100BASE-TX Standard Ethernet (siehe auch 2.1.2 auf Seite 22) — wird in der zweiten Generation durch OABR (siehe auch 2.1.2 auf Seite 25) als physikalisches Layer der Einsatz von Ethernet für Infotainment- und ADAS-Anwendungen möglich. Im letzten Schritt, der dritten Generation, wird Ethernet als Backbone eingesetzt. Als physikalisches Layer planen die Autoren 1000BASE-T1 (IEEE 802.3bp [64]). Neben Ethernet AVB sind hier auch time-triggered Protokolle vorgesehen. In der Backbone-Architektur sind neben den ADAS und Infotainment-Systemen die Fahrzeugbusse über ein jeweiliges Domänensteuergerät angebunden. Die vorliegende Arbeit untersucht insbesondere die durch die Autoren beschriebene dritte Generation. Dabei werden jedoch auch erweiterte Topologien mit einem flachen Ethernet betrachtet; dies kann in Anlehnung an Hank, Suermann und Müller als vierte Generation bezeichnet werden. Lee et al. zeigen, wie die Dauer für das Übertragen von Software auf Steuergeräte im Automobil auf Basis eines Ethernet Backbones optimiert werden kann [93]. Da in Ethernet-Netzwerken die zur Verfügung stehende Bandbreite deutlich höher ist als die erreichbare Programmiergeschwindigkeit der Steuergeräte, wird ein paralleler Programmierprozess vorgeschlagen, in dem mehrere Geräte vor dem eigentlichen Flash-Vorgang parallel mit Firmware Images versorgt werden. Die Autoren gehen von einem EthernetBackbone-Design mit einem zentralen Switch und Gateways für die jeweiligen feldbusbasierten Domänen aus. Ein Steuergerät, PCU (Programming Control Unit), welches den Programmierprozess steuert, überträgt über den Ethernet Backbone die Software parallel an die jeweiligen Domänen-Gateways, DCU (Domain Control Unit) genannt. Die DCUs übertragen über die angebundene Feldbustechnologie — beispielsweise CAN oder FlexRay — die Software an die angebundenen ECUs. In einem Prototyp wurde experimentell für verschiedene Topologien der Geschwindigkeitsgewinn für das Programmieren aller ECUs ermittelt. Es konnte bereits in sehr kleinen Netzwerken mit bis zu sechs Teilnehmern eine Reduzierung der Programmierzeit um bis zu 73 % erreicht werden. Untersuchungen mit realistischen Fahrzeugnetzwerktopologie wurden jedoch nicht durchgeführt. Ob die Lösung auch in größeren Netzwerken skaliert, ist daher zu untersuchen. Herber, Saeed und Herkersdorf zeigen den Bedarf von Automotive Ethernet Controllern welche den Ressourcenbedarf auf Endsystemen reduzieren [62]. In

56

2 Stand der Wissenschaft und Technik

früheren Veröffentlichungen des Autors der vorliegenden Arbeit [5, 16] wurde bereits gezeigt, dass reine Softwareimplementierungen von Echtzeit-EthernetProtokollen hohe Anforderungen an die Performance der ausführenden ECU stellen. Daher wurde ein Konzept eines Realtime-Ethernet-Koprozessors für (insbesondere time-triggered) Echtzeitprotokolle vorgeschlagen und experimentell in einem Hardware-/Software-Codesign Ansatz auf einem FPGA (Field Programmable Gate Array) implementiert. Das im Rahmen des BMBF geförderten ARAMiS-Projekts (Automotive Railway Avionics Multicore Systems) entstandene Konzept von Herber, Saeed und Herkersdorf implementiert einen solchen Ansatz ebenfalls für die Zeitsynchronisierung und den CBS. Die Ergebnisse unterstreichen die Notwendigkeit von SoC-basierten HardwareErweiterungen für Echtzeit-Ethernet-Protokolle. Jungnickel und Korf zeigen, wie auf Basis der Sensorfusion von LIDAR und Grid Maps effizient Objekte im Fahrzeugumfeld erkannt und verfolgt werden können [86]. Für diese Art der Anwendung und das Fusionieren von Rohdaten wird ein sehr schnelles und zuverlässiges Fahrzeugnetzwerk benötigt. Neben einer hohen Bandbreite aufgrund der umfangreichen Daten beim Einsatz von rohen Sensorwerten muss das Netzwerk eine niedrige Ende-zu-Ende-Latenz aufweisen, um die Totzeit von Sensor zu Aktuator möglichst gering zu halten. Ein niedriger Jitter vereinfacht zudem die Fusion und reduziert den Bedarf von Puffern im Sensorfusionssteuergerät. In der vorliegenden Arbeit wird der Einfluss von Architekturentscheidungen auf die Sensorfusion untersucht.

2.2.9 Modellbasierte Entwicklung Der Fokus der vorliegenden Arbeit liegt nicht im Zentrum der ganzheitlichen modellbasierten Entwicklung. Dennoch muss insbesondere das Thema der Netzwerksimulation im Zusammenhang mit modellbasierten Entwicklungsprozessen betrachtet werden, bei denen Modelle die wesentlichen Artefakte der Entwicklung in allen Entwicklungsphasen darstellen [35]. Das SPES 2020-Forschungsprojekt (Software Platform Embedded Systems 2020) [111] entwickelte einen domänenübergreifenden (Industrieautomatisierung, Automobilbau, Flugzeugbau, Energiesektor und Gesundheit) modellbasierten Entwicklungsprozess basierend auf dem SPES 2020 Framework. Das Framework umfasst den Entwicklungsprozess von den initialen Anforderungen, der Spezifikation von Architekturen, bis hin zu Implementierung und Verifikation. Es erlaubt die Modellierung eines Systems mit einem hohen Grad der Automatisierung, insbesondere auch für die Überprüfung von Anforderungen [33]. Die in der vorliegenden Arbeit dargestellten Simulationswerkzeuge

2.3 Zusammenfassung und resultierender Handlungsbedarf

57

(siehe auch Abschnitt 4.2.2 auf Seite 110) können mit System- und Kommunikationsmodellen gespeist werden und erlauben damit die Überprüfung von funktionalen und nicht-funktionalen Eigenschaften der Kommunikationsinfrastruktur. Damit sind sie geeignet, in einen wie in SPES 2020 entwickelten Modellierungsprozess integriert zu werden. Das SPES 2020 Framework definiert verschiedene Abstraktionsebenen und Perspektiven auf ein System, sogenannte Viewpoints. Neben Viewpoints für Anforderungen, Funktionen und logische Strukturen wie Verteilung und Verantwortlichkeiten von Systemkomponenten gibt es einen Technical Viewpoint, welcher unter anderem Hardware-Topologien von Komponenten, aber auch Kommunikationsstrukturen beschreibt. Er ist eine Beschreibung der Abbildung von plattformunabhängigen logischen Komponenten auf plattformabhängige technische Modelle [164]. Die Simulation der Kommunikation des Modells auf dieser technischen Ebene (Technical Viewpoint) entspricht der in der vorliegenden Arbeit vorgestellten System-Level-Simulation und ließe sich daher als Komponente in modellbasierte Entwicklungsprozesse wie dem im Rahmen von SPES 2020 entwickelten Framework integrieren.

2.3 Zusammenfassung und resultierender Handlungsbedarf Der Stand der Technik bei heutigen feldbusbasierten Kommunikationsnetzwerken zeigt den Bedarf nach einer neuen vereinheitlichten Bordnetzarchitektur. Echtzeit-Ethernet ist eine geeignete Technologie, um eine solche Netzwerkarchitektur zu realisieren; allerdings gibt es eine hohe Zahl an möglichen QoS- und Traffic-Shaping-Varianten, die in unterschiedlichen Protokollen realisiert und standardisiert wurden. Bisherige Forschungsprojekte untersuchten stets nur eine Teilmenge der für eine ganzheitliche Architektur relevanten Aspekte. So lag beispielsweise der Fokus des SEIS-Projekts insbesondere auf der Einführung von IP-Kommunikation. Auch die gegenseitige Beeinflussung von Datenströmen unterschiedlicher Verkehrsklassen in Echtzeit-Ethernet und der Einfluss von niedrig priorisiertem Hintergrunddatenverkehr wurde bisher nicht ausreichend untersucht, um Empfehlungen für zukünftige Bordnetzarchitekturen geben zu können. Es wurden zwar Protokolle der höheren OSI-Ebenen für den Einsatz in Automobilanwendungen evaluiert, jedoch wurden dabei nicht die Auswirkungen von Traffic Shapern und der TDMA-Kommunikation auf dem OSI-Layer 2 auf das Verhalten in

58

2 Stand der Wissenschaft und Technik

Transportprotokollen wie UDP, TCP (Transmission Control Protocol) oder SCTP (Stream Control Transmission Protocol) untersucht. Die bisherigen Forschungsergebnisse aus analytischen, simulativen und empirischen Studien zeigen Lösungen für verschiedene Teilprobleme der Automotive-Kommunikation. Eine ganzheitliche Untersuchung möglicher Kommunikationsarchitekturen unter Berücksichtigung realistischer Netzwerktopologien und auf Basis von realen Datenverkehrsmodellen wurde bisher nicht durchgeführt. Es gibt bereits verschiedene Simulationswerkzeuge für die Architekturbewertung, beispielsweise den SystemCoDesigner oder den MLDesigner. Diese Werkzeuge abstrahieren jedoch die Netzwerkeigenschaften und liefern vordergründig Aussagen auf funktionaler Ebene. Eine Plattform für die dedizierte Netzwerksimulation von komplexen heterogenen Fahrzeugnetzwerken mit Feldbusprotokollen, adaptierbaren Echtzeit-Ethernet-Protokollen und Feldbus-Ethernet-Gateways steht bisher nicht zur Verfügung. Auch die Möglichkeit, verschiedene Shaping-Ansätze zu kombinieren sowie Echtzeitprotokolle und Medienzugriffsverfahren weiterzuentwickeln, ist in den vorhandenen Plattformen nicht vorgesehen. Insbesondere das Potenzial der preemptiven Zugriffsverfahren wurde für den Einsatz im Fahrzeug bisher nicht untersucht. In der vorliegenden Arbeit wird eine durchgehende Simulationsplattform für die Evaluierung von Echtzeit-Ethernet-basierten Bordnetzarchitekturen entwickelt. Mit dieser Plattform werden auf Basis von realistischen Topologien und realen Verkehrsströmen Architekturvarianten für zukünftige Echtzeit-Ethernet-Backbone-Architekturen entwickelt und überprüft. Damit steht ein Simulationsprozess zur Verfügung, welcher analytische WCTAUntersuchungen, die zumeist überpessimistisch oder stark abstrahiert sind, ergänzen und absichern kann. Es wurden in verschiedenen Forschungsarbeiten empirische Untersuchungen, beispielsweise im Bereich der Zeitsynchronisierungsprotokolle und Gateways, durchgeführt. Bisher wurde jedoch kein Backbone-Netzwerk auf Basis von Echtzeit-Ethernet und Feldbus-zu-Ethernet-Gateways in einem realistischen Prototypfahrzeug eingesetzt und untersucht. Mit der vorliegenden Arbeit wird der Nachweis für eine generelle Umsetzbarkeit von EchtzeitEthernet-basierten Bordnetzarchitekuren erbracht. Die Erfahrungen aus der Implementierung im Prototyp sowie den Ergebnissen der Testfahrten fließen dabei in die in der Simulation gewonnenen Erkenntnisse ein und bilden die Grundlage für Designempfehlungen und Best Practices, die aus technischer Sicht für eine erfolgreiche Einführung von Ethernet im Automobil berücksichtigt werden sollten.

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen Im Folgenden werden die für die Bewertung von Fahrzeugnetzwerkarchitekturen wichtigen Metriken und die typischen Anforderungen aus dem Automotive-Bereich definiert. Anschließend werden die zentralen Elemente der Fahrzeugnetzwerkarchitektur erläutert und gegenübergestellt. Dies umfasst die zur Bewertung verwendeten realistischen Datenverkehrsmodelle, mögliche Topologien, Kommunikationstechnologien und -strategien sowie Fahrzeug-Gateway-Architekturen.

3.1 Anforderungen und Netzwerkmetriken Es ist anspruchsvoll, genaue Anforderungen an eine zukünftige Kommunikationstechnologie im Fahrzeug zu definieren. Während für die heute eingesetzten Anwendungen Richtwerte für die einzuhaltenden Grenzen bekannt sind, ist bisher noch undefiniert, welche Anforderungen in zukünftigen Systemen, beispielsweise für das automatisierte und autonome Fahren, entstehen werden. Im Folgenden werden die wichtigsten technischen Metriken, welche in der nachfolgenden Bewertung berücksichtigt werden, definiert. Dies sind insbesondere Bandbreite, Latenz und Jitter. Weitere Metriken wie Energieverbrauch, Start-up-Geschwindigkeiten oder EMV werden in der vorliegenden Arbeit nur am Rande betrachtet und berücksichtigt.

3.1.1 Bandbreite Der steigende Bedarf an Bandbreite ist ein Antrieb für die Einführung von Ethernet als zukünftige Kommunikationstechnologie im Fahrzeug. Neue hochauflösende Sensoren benötigen eine deutlich höhere Bandbreite, insbesondere, wenn ihre Daten nicht am Sensor verarbeitet werden, sondern in einem zentralen Steuergerät fusioniert werden sollen. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018 T. Steinbach, Ethernet-basierte Fahrzeugnetzwerkarchitekturen für zukünftige Echtzeitsysteme im Automobil, https://doi.org/10.1007/978-3-658-23500-0_3

60

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

Bandbreite, auch als Durchsatz oder Kapazität eines Kommunikationsmediums bezeichnet, definiert die je Zeiteinheit zu übertragende maximale Datenmenge. Dabei ist insbesondere bei Kommunikationstechnologien zwischen der Netto- und Bruttobandbreite zu unterscheiden. Die Nettobandbreite bezeichnet dabei die Datenmenge ohne die für die Übertragung notwendigen Protokoll-Overheads. Für Ethernet-Links hängt die Nettobandbreite maßgeblich von der genutzten Paketgröße ab. Werden nur Nachrichten minimaler Frame-Größe lF rame = 64 B genutzt, sinkt die Nettobandbreite Vnet eines V = 100 Mbit/s Links auf etwa 55 Mbit/s, bei maximaler Frame-Größe lF rame = 1518 B bleiben etwa 98 Mbit/s: (lF rame − lHeader − lCRC ) (lF rame + lP reamble + lIF G ) (64 B − 14 B − 4 B) Mbit Vnet (64 B) = 100 Mbit s · (64 B + 8 B + 96 bit) ≈ 54,76 s (1518 B − 14 B − 4 B) Mbit Vnet (1518 B) = 100 Mbit s · (1518 B + 8 B + 96 bit) ≈ 97,52 s

Vnet (lF rame ) = V ·

(3.1)

Der Bandbreitenbedarf für Steuerdaten in Serienfahrzeugen ist heute im Vergleich zu den Datenraten zukünftiger hochauflösender Sensoren gering. Je Domäne liegt er unter 500 kbit/s. Im Gesamtfahrzeug liegt die Datenrate für Steuerdaten deutlich unter 3 Mbit/s (siehe auch Abschnitt 3.2 auf Seite 63). Die Datenrate für die Rohdaten der Radar- und LIDAR-Sensoren liegen für aktuelle Geräte heute je nach Messfrequenz zwischen etwa 3 Mbit/s und 8 Mbit/s. Kameras haben einen noch deutlich höheren Bandbreitenbedarf. Für eine Kamera mit einer Auflösung von 1280 x 1028 Pixel und einer Farbtiefe von 24 bit ist ein Rohbild bereits über 30 MB groß. Damit würde ein unkomprimierter Kamerastrom bei 30 Frames/s bereits einen Gigabit-Link auslasten. Daher kommen für die Übertragung von Kamerabildern Komprimierungsverfahren zum Einsatz, welche die Datenrate deutlich reduzieren (siehe auch Abschnitt 5.3.4 auf Seite 230). Realistische Datenraten für den komprimierten Datenstrom liegen bei 25 Mbit/s bis 60 Mbit/s [14].

3.1.2 Latenz Die Nachrichtenlatenz, auch als Verzögerung oder Laufzeit bezeichnet, definiert die Zeit zwischen dem Absenden einer Information durch den Sender und dem Empfang derselben Information beim Empfänger. Hervorgerufen

3.1 Anforderungen und Netzwerkmetriken

61

wird die Latenz von einer Vielzahl von Elementen wie beispielsweise der Verzögerung durch Warteschlangen, Sendeverzögerungen, Signallaufzeiten oder der Verarbeitungsdauer. In zeitkritischen Systemen ist die Latenz die wichtigste Netzwerkmetrik. Sie definiert in einer verteilten Regelung die Totzeit1 und hat damit entscheidenden Einfluss auf die zu erreichende Regelgüte. Die Latenz kann Ende-zu-Ende, also von Sender zu Empfänger, oder bidirektional als Roundtrip-Latenz ermittelt werden. Während sich beispielsweise für Client-Server-Anwendungen die Roundtrip-Zeit als relevante Größe etabliert hat, da in der Regel ein Anfrage-/Antwort-Verhalten implementiert ist, ist in der Kommunikation im Fahrzeug die Ende-zu-Ende-Latenz die wichtigere Größe. Dies liegt daran, dass viele Verbindungen im Automobil unidirektional oder asymmetrisch sind, also beispielsweise nur in eine Richtung vom Sensor zum Aktuator verlaufen. Daher wird nachfolgend der Begriff Latenz als Synonym für die Ende-zu-Ende-Latenz verwendet. Die Latenz kann auf Paketebene, also separat für jedes Paket eines Stromes, beschrieben werden oder als Latenz für die Übertragung einer Information. Wenn beispielsweise das Bild eines Videostroms in mehreren Fragmenten über ein Netzwerk übertragen wird, ist vordergründig nicht die Verzögerung der einzelnen Pakete von Interesse, sondern die gesamte Verzögerung der Übertragung des kompletten Bilds. Die Anforderungen zyklischer Regelprozesse im Automobil an die Endezu-Ende-Latenz liegen üblicherweise bei etwa 10 % der Zyklusdauer. Die kürzesten Perioden für Steuerdaten liegen meist bei 5 ms (siehe auch Abschnitt 3.2 auf Seite 63). Damit bleiben die Anforderungen für die Latenz von Steuerdaten im Automobil bei etwa 500 μs bis 10 ms [99]. Die WorstcaseLatenz für die Übertragung einer 8 B CAN-Botschaft (128 bit Gesamtlänge in CAN 2.0B zuzüglich Bitstuffing) mit der höchsten Priorität auf einem 500 kbit/s Bus liegt unter Berücksichtigung der maximalen Stuffbits bei 304 μs. Durch das Blockieren des Busses mit einer niedrig priorisierten Botschaft kommen noch einmal 304 μs zur Worstcase-Ende-zu-Ende-Latenz hinzu. Damit liegt die heute mit CAN zu erreichende Latenz bei etwa 600 μs und ist als Richtwert für zukünftige Architekturen anzustreben. Dadurch ist sichergestellt, dass jede heute mögliche Anwendung auf eine BackboneArchitektur zu übertragen ist. Neue Anwendungen aus dem Bereich der Fahrerassistenz und des autonomen Fahrens werden zukünftig härtere Anforderungen an die Ende-zu1 Die

Totzeit (auch Laufzeit oder Transportzeit) bezeichnet die Zeitspanne zwischen Änderung am Systemeingang und Antwort am Systemausgang einer Regelstrecke.

62

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

Ende-Latenz stellen. Als Zielsetzung sind in der Automobilindustrie heute maximale Ende-zu-Ende-Latenzen bis hinunter zu 100 μs im Gespräch [147]. Welche konkreten Anwendungen eine solch niedrige Latenz benötigen werden ist jedoch noch nicht abschließend geklärt. Eine zukunftssichere Netzwerkarchitektur sollte diese Anforderungen dennoch möglichst berücksichtigen. Für LIDAR-, Radar- und Kamera entspricht die maximale Latenz für die Übertragung eines Samples der Periode des Sensors. Bei einer Frequenz von 30 Hz entspricht dies zirka 33 ms. Dieser Wert gilt jedoch für die gesamte Übertragung eines Datensatzes oder Bilds. Da diese in mehreren Fragmenten übertragen werden müssen, muss die Übertragung aller Fragmente innerhalb der Latenzgrenze von 33 ms abgeschlossen sein.

3.1.3 Jitter Der Jitter ist eine Netzwerkmetrik, welche die Varianz der Latenz beschreibt. In klassischen Vermittlungsnetzen wird der Jitter über eine definierte Anzahl Pakete erhoben [142]; wenn die Differenz der Latenz über zwei Pakete erhoben wird, spricht man vom relativen Jitter [138]. In Echtzeitsystemen ist jedoch der maximale Jitter zwischen allen Paketen, also die Differenz zwischen maximaler und minimaler Paketlaufzeit, relevant. Dieser Jitter wird auch als absoluter Jitter bezeichnet. Nachfolgend wird der Begriff Jitter stets für den absoluten Jitter verwendet. In einer zyklischen Kommunikation führt der Übertragungsjitter dazu, dass die vom Sender vorgegebene Frequenz, die durch das periodische Versenden einer Botschaft vorgegeben ist, beim Empfänger gestört und ungenau ankommt. In miteinander synchronisierten Systemen kann durch zusätzliche künstliche Verzögerung der Verarbeitung eingehender Botschaften der Jitter zulasten der Ende-zu-Ende-Latenz ausgeglichen werden. In einer verteilten Regelung kann ein unberücksichtigter starker Jitter zu instabilen Regelprozessen führen. Eine obere Grenze des Jitters ist von Anwendung zu Anwendung unterschiedlich und muss daher individuell festgelegt werden. Eine in der Automobilindustrie gängige Faustformel für die obere Jittergrenze ist 10 % der Ende-zu-Ende-Latenz. Es ist wichtig, dass in einem Netzwerk der zu erwartende maximale Jitter ermittelt wird. Aus ihm lassen sich anwendungsspezifische Parameter wie beispielsweise maximal benötigte Puffergrößen oder Sicherheitsreserven für Slots in Schedules ableiten.

3.2 Fahrzeugdatenverkehrsmodelle

63

3.2 Fahrzeugdatenverkehrsmodelle Für die Untersuchung von Fahrzeugnetzwerkarchitekturen werden zwei unterschiedliche, aus Daten von Serienfahrzeugen erzeugte Verkehrsmodelle entwickelt. Die Datenverkehrsmodelle beschreiben die Kommunikation zwischen Steuergeräten im Fahrzeug auf einer abstrakten Ebene. Neben der Sender-/Empfängerbeziehung definiert das Datenverkehrsmodell das Priorisierungsverhältnis zwischen Botschaften, die Botschaftsgröße und ihre Wiederholfrequenz. Die Modelle enthalten keine Informationen über die Topologie. Es können verschiedene Topologien und Architekturen auf die Datenverkehrsmodelle angewendet werden. Die Modelle ermöglichen es, realistische Verkehrsflüsse zu simulieren und damit genaue und auf reale Systeme übertragbare Ergebnisse in der Analyse zu erzielen.

3.2.1 Allgemeines Seriendatenverkehrsmodell Das allgemeine Seriendatenverkehrsmodell basiert auf der Spezifikation der Kommunikationsdaten eines aktuellen Serienfahrzeugs eines großen Automobilherstellers. Es wurde abstrahiert und auf die Kommunikationsflüsse zwischen den Steuergeräten reduziert. Da die Inhalte der Botschaften für die Untersuchung der Netzwerkarchitekturen nicht relevant sind, enthält das Modell keine Informationen zu den in den Botschaften transportierten Signalen. Im Originalfahrzeug werden Feldbusse eingesetzt. Das Datenverkehrsmodell unterteilt sich in die Domänen: Diagnose, Antrieb und Fahrwerk, Komfort und Info-/Entertainment. Als Nachweis und zur Reproduzierbarkeit der Ergebnisse ist das Datenverkehrsmodell in der ANDL-Syntax im Anhang B.1 (Seite 291) offengelegt und kann für Untersuchungen von Fahrzeugnetzwerkarchitekturen herangezogen werden. Eine Beschreibung der ANDL ist in Abschnitt 4.2.6 (Seite 118) gegeben. Aufbau Das Datenverkehrsmodell besitzt 41 unterschiedliche Teilnehmer aus fünf verschiedenen Domänen. Dabei können mehrere Teilnehmer derselben physikalischen Komponente zugewiesen sein. Zwischen den Teilnehmern werden 421 unterschiedliche Botschaften ausgetauscht. Die größten Botschaften besitzen eine Nutzlast von 8 B, die kleinsten Botschaften liegen bei 2 B. Die Verteilung der Nachrichtengrößen ist in Abbildung 3.1 auf der nächsten Seite dargestellt. Zirka 90 % der Nachrichten haben die in CAN maximal mögliche

Botschaften [%]

64

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

80 60 40 20 0 0

2

4

8

16

24

32

Nutzdatenlänge [B]

Botschaften [%]

Abbildung 3.1: Verteilung der Nachrichtengrößen im allgemeinen Seriendatenverkehrsmodell

20

10

0 0

50

100

150

200

250

300

350

400

450

500

Periode [ms] Abbildung 3.2: Verteilung der Zykluszeiten bis 500 ms im allgemeinen Seriendatenverkehrsmodell

Nutzdatengröße von 8 B. Da im Originalfahrzeug ausschließlich CAN-Busse und keine Technologien, die größere Nutzdaten erlauben (beispielsweise FlexRay), eingesetzt werden, bestehen in diesem Datenverkehrsmodell keine größeren Nachrichten. Die verwendeten Perioden (siehe Abbildung 3.2) liegen zwischen 10 ms und 2 s. Jeweils etwa 25 % der Botschaften werden mit 100 ms beziehungsweise 500 ms Perioden übertragen. Knapp 40 % der Botschaften haben eine geringere Zykluszeit unter 100 ms.

3.2 Fahrzeugdatenverkehrsmodelle

65

Eigenschaften der Kommunikationsbeziehungen Ein wichtiges Merkmal eines Datenverkehrsmodells sind die Kommunikationsbeziehungen zwischen den Teilnehmern. Abbildung 3.3 auf der nächsten Seite zeigt eine Heatmap2 der Anzahl an Botschaften, die zwischen den Sender-/Empfänger-Paaren ausgetauscht werden. Die Heatmap ist ein Fingerabdruck der Kommunikationsbeziehungen im Datenverkehrsmodell. Die Zeilen der Matrix definieren die Sender, die Spalten die Empfänger. So definiert beispielsweise das zehnte Feld der fünften Zeile die Anzahl der Botschaften, die von ECU 4 an ECU 9 versendet werden. Das Datenverkehrsmodell umfasst ECUs mit unterschiedlichen Sende- und Empfangseigenschaften. Die meisten Steuergeräte haben ein überwiegend symmetrisches Kommunikationsverhalten, bei dem sich eingehende und ausgehende Botschaften die Waage halten. Auffällig ist die quadratische Fläche zwischen ECU 4 und ECU 15. Sie ist ein Beispiel für Steuergeräte, die aus Kommunikationssicht eng miteinander vermascht sind. Jede ECU tauscht mindestens eine Nachricht mit jeder anderen ECU der Gruppe aus. Da die ECUs nach den Domänen sortiert sind, zeigt sich hier die enge Vermaschung besonders stark. Es gibt jedoch auch weitere weniger offensichtliche Gruppen, welche daran identifiziert werden können, dass sie sich die Menge der Empfänger überwiegend teilen. Weiterhin gibt es ECUs welche mit nahezu allen anderen Teilnehmern kommunizieren (ECUs 0, 3, 4, 6, 10, 38). Dies zeigt, dass viele Steuergeräte nicht nur lokal innerhalb ihrer Domäne, sondern auch über die Domänengrenzen hinweg kommunizieren. Zudem enthält das Modell eine Reihe von Steuergeräten (ECU 23-26), welche ausschließlich Botschaften empfangen. Findet an der diagonalen Achse der Heatmap (schwarz) eine Spiegelung statt, sind sich demnach gegenüberliegende Felder ähnlich, ist die Kommunikation zwischen den Teilnehmern nicht nur bidirektional, sondern auch symmetrisch. Es gibt also in beide Richtungen gleich viele Botschaften. Abbildung B.1 im Anhang B.1 (Seite 299) zeigt die Heatmap für die Bandbreite. Die beiden Heatmaps sind sich ähnlich; dies zeigt, dass die genutzte Bandbreite gleichmäßig auf die Botschaften aufgeteilt ist. Dies entspricht auch den Erwartungen, da die überwiegende Zahl der Botschaften 8 B Nutzdaten transportiert. Die maximale Bandbreite zwischen einem Sender und einem Empfänger liegt bei nur rund 30 kbit/s. 2 Eine

Heatmap (deutsch wörtlich: Wärmekarte) ist eine Visualisierungsform von Werten einer zweidimensionalen Definitionsmenge. Die Werte werden als Farben repräsentiert und helfen, in einer großen Datenmenge markante Werte zu erfassen.

66

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

Steuergerät Empfänger 0 2 2 8 9 7 8 5 5 6 9 7 8 5 7 7 5 7 5 6 6 5 6 3 1 1 7 1 7

2 1 1

4 6 5 9 5 5 6 5 5

2

2 1 1

4 5 5 5 4 5 6 5 5

2

7 2 7

14 2 2 3 4 5 5 5 5 6 6 5 6 5 5 5 5 5 5 6 6 5 5 2 1 1 5

4 2 3 1 6 7 4 4 3 4 8 9 3 1 1

4 6 11 7 6 11 13 6 6 5 6 6 3 8 3 6 5 3 16 5 1 1 3 5 2 1 1 1 2 2 1 1 1 1

5

1

18 8 6 4 8 12 18 13 12 4 14 14

3

1 3

11 2 1 1

2 1

2 1 2 4 3 2 1 4 2

2

2 1 2 7 2 1 3 2 1 1 1 1 3 2 3 2 8 1 2 1 1 1 1 1 11 1 5 1 1 9 3 4 2 2 1 1 1

4

1

10 1 9 3 6 6 10 6 10 1 3 3 2 5 1 2 3 2 20 5 3 1 2 1 1 1 2 11 1 1 2 2

1

1

1 4

3

5 2 3 3 5 1

1

1

2 1 3 1 1 1 4 1 12 1 1 1 3 1 2 2 1 2 2 3 1 13 1 1

1

1 1

Steuergerät Sender

4 1 3 1 3 3 1 3 3 1 14 3 5 2 3 2 3 3 3 3 3 1 5 15 2

1

9

1

2

1

1

6

1

4

2

3 1

1 7 4 4

7 17 5 9 9 7 6 1

15

4 8 2 4 5 7 8 9 1

1 4 1 19 4 1 1

1 20

1 6

4

1 18 1

2 5

1

16 1

3

4 13 1 5

1 2

2 1 1 1 1

4

1

21

2

1

22

2 2 5 8 1 1

4

6

23 24 25 26 1 5

5

1

27 4

1 28

5 6

4

1

1 1 1

29 1

1

30

2

1

5 16

3 1

1

1

9 3

2

6

3

1

31

3 1 1

2 3 1 1 2 3 2 2

7 2

3

32 33

1 1

1 1

2 2

2

1 1

1

3 3

3

2 1

26

1

1 2

1

1

1 1 1 1

1

1 1 36 1 3

1

18 2 5 3 2 5 12 2 4 1 1 1 5 9 2 5 5 5 6 5 2

34 1 1 35

2 1

1

2 1 1 1

1

37 7 1 2

6 1 2

3 16 38 5 1

1

39

1

2 1

40

7

0

2

4

6

8

10

12

14

41

16

18

20

22

24

26

Botschaften [#]

Abbildung 3.3: Heatmap der Kommunikation zwischen Teilnehmern im allgemeinen Seriendatenverkehrsmodell — Die Zahl gibt die Anzahl der Botschaften an (eigene Darstellung)

3.2 Fahrzeugdatenverkehrsmodelle

67

3.2.2 Komprimiertes domänenbasiertes Datenverkehrsmodell Das komprimierte domänenbasierte Datenverkehrsmodell wurde gemeinsam mit dem Doktoranden Hyung-Taek Lim (BMW Forschung und Technik) für gemeinsame Veröffentlichungen entwickelt (siehe auch Abschnitt 4.4 auf Seite 143). Es basiert auf realistischen Verkehrsflüssen, welche in BMWSerienfahrzeugen ermittelt wurden. In den Fahrzeugen, aus denen die Verkehrsflüsse extrahiert wurden, werden CAN- und FlexRay-Busse eingesetzt. Zudem enthält das Datenverkehrsmodell Multimedia-Datenströme für das Entertainment (Video, TV, Audio) sowie ein kamerabasiertes Assistenzsystem. Das domänenbasierte Datenverkehrsmodell ist zur Nachvollziehbarkeit der Ergebnisse der vorliegenden Arbeit ebenfalls in der ANDL-Syntax im Anhang B.2 auf Seite 300 offengelegt. Aufbau Das domänenbasierte Datenverkehrsmodell besitzt 15 unterschiedliche Teilnehmer. Zwischen diesen werden 82 verschiedene Botschaften ausgetauscht. Die Anzahl an Steuergeräten und Botschaften ist im Vergleich zum allgemeinen Seriendatenverkehrsmodell (siehe Abschnitt 3.2.1 auf Seite 63) deutlich geringer, da in diesem Modell Kommunikationsteilnehmer hinter Domänen-Gateways versteckt sind. Diese Steuergeräte und ihre Botschaften sind im Gateway zusammengefasst und werden somit als nur ein Teilnehmer im Netzwerk sichtbar. Daher wird das Modell nachfolgend auch als komprimiertes domänenbasiertes Datenverkehrsmodell bezeichnet. Die größte Botschaft des Datenverkehrsmodells besitzt eine Nutzlast von 1428 B, die kleinste Botschaft liegt bei 2 B. Die Wiederholrate liegt zwischen 125 μs und 5 s. Die im Vergleich zum allgemeinen Seriendatenverkehrsmodell große Nutzlast und geringe Wiederholrate stammt von den zu den Steuerdaten hinzukommenden Kamera- und Multimedia-Datenströmen. Es gibt sechs verschiedene Funktionsgruppen im Datenverkehrsmodell. Im Bereich der Steuerdaten werden einzelne Domänen durch Stellvertreter (Domänen-Master) angebunden. Das entwickelte Modell besteht aus fünf Domänen mit entsprechenden Stellvertretern. Darüber hinaus gibt es ein Gateway-Steuergerät und eine ECU für eine zentrale Anzeigeeinheit. Im Bereich kamerabasierter Fahrerassistenz gibt es ein Steuergerät für die Fahrerassistenzfunktion sowie ein Steuergerät für die Berechnung einer Birds-View-

68

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

Botschaften [%]

40 30 20 10 0 0

2

4

8

16

24

32

Nutzdatenlänge [B] Abbildung 3.4: Verteilung der Nachrichtengrößen im domänenbasierten Datenverkehrsmodell — ohne Multimedia

Anwendung3 . Im Bereich Infotainment verfügt das modellierte Fahrzeug über Steuergeräte für Multimedia-Anwendungen, Fernsehempfang und den Audioverstärker sowie mehrere Displays (Mittelkonsole sowie RSE (Rear Seat Entertainment)). Steuerdaten: Die Steuerdaten auf dem Fahrzeug-Backbone umfassen 75 unterschiedliche Botschaften. Die Botschaften zur Fahrzeugsteuerung sind kurz (bis maximal 32 B Nutzdaten), da sie auf angebundenen Feldbussen (CAN und FlexRay) übertragen werden müssen. 40 % der Botschaften haben 8 B Nutzdaten, 20 % besitzen einen Payload von 16 B und 10 % liegen bei 32 B Nutzdaten. Die übrigen etwa 30 % verteilen sich über eine Nutzdatengröße von 2 B bis 15 B. Die genaue Verteilung ist in Abbildung 3.4 angegeben. Die Zyklen der Botschaften im Bereich der Fahrzeugsteuerung liegen zwischen 5 ms und 5 s. Etwa 80 % der Botschaften haben eine Wiederholfrequenz von bis zu 100 ms. Eine große Anzahl an Botschaften wird mit einer hohen Frequenz von 10 ms (≈22,5 %) und 20 ms (≈27 %) versendet (siehe Abbildung 3.5 auf der nächsten Seite). Steuerdaten sind für das Fahrzeug sicherheitsrelevant und haben daher harte Echtzeitanforderungen. Sie werden sowohl synchron als auch asynchron übertragen. Es gibt Nachrichten mit nur einem Empfänger (unicast); die 3 Birds-View

(deutsch: Vogelperspektive) bezeichnet im Automobilbereich eine virtuelle Kameransicht mit einer Perspektive von oben auf ein Fahrzeug herab. Eine weitere gängige Bezeichnung ist Top-View. Birds-View-Ansichten werden auf Basis von mehreren rund um das Fahrzeug angeordneten Kameras berechnet.

Botschaften [%]

3.2 Fahrzeugdatenverkehrsmodelle

69

20

10

0 0

50

100

150

200

250

300

350

400

450

500

Periode [ms] Abbildung 3.5: Verteilung der Zykluszeiten im domänenbasierten Datenverkehrsmodell — ohne Multimedia bis 500 ms

überwiegende Zahl der Botschaften hat jedoch mehr als einen Empfänger und eignet sich daher für Gruppenkommunikation (multicast). Kamerabasierte Fahrerassistenz: Die Kameras werden direkt Punkt-zuPunkt an das Birds-View-Steuergerät angebunden und die zusammengesetzten Bildströme von dort im Unicast-Verfahren direkt an das Steuergerät für die zentrale Anzeige gesendet. Damit verursachen die Datenströme zwischen der Kamera und dem Birds-View-Steuergerät zunächst keine zusätzliche Last auf dem Backbone. Dadurch können Architekturen für das komprimierte domänenbasierte Datenverkehrsmodell durchgehend Links mit einer Bandbreite von 100 Mbit/s einsetzen. Der im komprimierten domänenbasierten Datenverkehrsmodell zusammengesetzte Kamerastrom verfügt über eine Bandbreite von 25 Mbit/s und wird über den Backbone übertragen. Da die Kameradaten für das Fahrerassistenzsystem notwendig sind, müssen harte Echtzeitanforderungen erfüllt werden. Multimedia: Für Multimedia-Anwendungen werden im Datenverkehrsmodell drei weitere Verkehrsströme modelliert. Das Steuergerät für Multimedia sendet einen Videostrom von 40 Mbit/s an das RSE-System sowie einen Audiostrom von 8 Mbit/s an den Audioverstärker. Dies entspricht den aktuellen Bandbreiten von hochaufgelösten Videos mit modernen Kodierverfahren, beispielsweise in Blue-ray-Systemen. Zusätzlich ist ein TV-Signal mit 10 Mbit/s bis 20 Mbit/s modelliert. Die Multimedia-Anwendungen sind nicht sicherheitsrelevant und haben daher nur weiche Echtzeitanforderungen.

70

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen Steuergerät Empfänger

Steuergerät Empfänger 0

1 1 1 3 1 1 1 1

1 1

2 2

1 1

2 1

1 1 3 2 1 10 11 15 4 11

1

1

7 7

6 14

3 2 5 12 5 7 2 2

2 4

4 6 2

2

7

1

1

8 1

9 10 11

1

1

12

1 2

Steuergerät Sender

Steuergerät Sender

0

3 4 5 6 7 8 9 10 11 12

13 2

0

7

6

5

13 5

13 14

10

Botschaften [#]

15

14

0

10

20

30

40

Bandbreite Nutzdaten [Mbit/s]

(a) Botschaften, Sender zu Empfänger (b) Bandbreite, Sender zu Empfänger Abbildung 3.6: Heatmap der Kommunikation zwischen Teilnehmern im domänenbasierten Datenverkehrsmodell — Anzahl der Nachrichten (a) und Bandbreite (b) (eigene Darstellung)

Eigenschaften der Kommunikationsbeziehungen Abbildung 3.6 zeigt die Heatmaps der Kommunikationsbeziehungen. Die obere Hälfte definiert die Domäne der Steuerdaten. Diese zeichnen sich durch eine hohe Anzahl an Botschaften bei insgesamt niedriger Bandbreite aus. Hervorzuheben ist hier die ECU 4, welche insgesamt 81 Kommunikationsbeziehungen zu anderen Steuergeräten hat. Dennoch liegt die ausgehende Bandbreite bei unter 0,5 Mbit/s. Die ECUs 7 bis 13 liegen im Entertainment- und Infotainment-Bereich und haben umgekehrt nur wenige Verkehrsströme mit jedoch sehr hoher Bandbreite von bis zu 40 Mbit/s. Dieses Datenverkehrsmodell zeigt einen deutlichen Unterschied zwischen der Anzahl an Botschaften (Abbildung 3.6a) und der verwendeten Bandbreite (Abbildung 3.6b). Dies zeigt, dass die Größen und Perioden der Botschaften dieses Modelles sehr heterogen sind.

3.3 Topologien für Ethernet-basierte Fahrzeugnetze

71

Abbildung 3.7: Steuergeräte im Serienfahrzeug und Kommunikationsbeziehungen innerhalb der Domänen — Farben repräsentieren die Anwendungsdomänen (eigene Darstellung)

3.3 Topologien für Ethernet-basierte Fahrzeugnetze Die Einführung einer switchbasierten Kommunikationstechnologie gibt dem Entwickler neue Freiheiten, aber auch Einschränkungen in der Gestaltung der Netzwerktopologie, also der Anordnung von Verbindungen zwischen den Netzwerkteilnehmern. Als Grundlage für die Entwicklung von Topologieoptionen dient zunächst die physikalische Verteilung der Steuergeräte über das Fahrzeug. Abbildung 3.7 zeigt eine typische Anordnung der Steuergeräte in einem Serienfahrzeug. Die Steuergeräte der verschiedenen Domänen sind über das Gesamtfahrzeug verteilt. Dabei bilden sich drei Bereiche, in denen besonders viele Steuergeräte untergebracht sind. Dies sind der Motorraum (insbesondere Steuergeräte der Antriebs- und Fahrwerksdomäne), der Bereich um das Armaturenbrett (Steuergeräte der Fahrwerks- und Komfortdomäne) und

72

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

um das Entertainment-System. Abbildung 3.7 zeigt ebenfalls die Zuordnung zu Domänen sowie die Kommunikationsbeziehungen zwischen den Steuergeräten der verschiedenen Domänen (die Abbildung entspricht nicht dem Kabelbaum). Im Folgenden wird die heute eingesetzte feldbusbasierter Topologie vorgestellt. Anschließend werden verschiedene Schritte des Konsolidierungsprozesses von einer busbasierten zu einer switchbasierten Topologie vorgestellt. In Abschnitt 4.9 auf Seite 198 werden die verschiedenen Topologien innerhalb von Gesamtarchitekturen in der Simulation evaluiert.

3.3.1 Heutige Topologie in Serienfahrzeugen In heutigen Serienfahrzeugen werden für die verschiedenen Anwendungsdomänen getrennte Feldbusse eingesetzt. Für die domänenübergreifende Kommunikation sind diese Busse an ein zentrales Gateway angeschlossen. Dieses Gateway ist dafür verantwortlich, die Nachrichten entsprechend einer fest konfigurierten Kommunikationsmatrix vom Quell- zum Zielbus weiterzuleiten. Da sich die Steuergeräte der verschiedenen Anwendungsdomänen in der Regel über das gesamte Fahrzeug erstrecken, müssen auch die Busse durch das gesamte Fahrzeug gezogen werden. Dies kann dazu führen, dass beispielsweise für drei Steuergeräte unterschiedlicher Domänen auch drei unterschiedliche Busse in das Heck des Fahrzeugs gelegt werden müssen. Abbildung 3.8 auf der nächsten Seite zeigt die logische Topologie in heutigen Serienfahrzeugen. In verschiedenen Fahrzeugbereichen gibt es Häufungen von Steuergeräten (beispielsweise Front, Motorraum und Instrumente). An das zentrale Gateway (schwarz) sind alle Domänenbusse angebunden. Neben den das Fahrzeug durchziehenden Bussen gibt es zusätzlich sogenannte private Busse wie beispielsweise den privaten Bus für das adaptive Kurvenlicht (gelb), welche nicht über das zentrale Gateway angebunden sind und nur einige wenige Steuergeräte verbinden. Diese werden insbesondere zwischen Steuergeräten mit einem hohen Bandbreitenbedarf eingesetzt, um die Busse der Anwendungsdomäne zu entlasten. Aus Sicht der Entwicklung ist die heutige Topologie unflexibel. Soll ein neues Steuergerät in das Fahrzeug integriert werden, muss zunächst geprüft werden, ob der zur Domäne zugehörige Bus an der Einbauposition bereits vorhanden ist. Ist dies nicht der Fall, muss der Bus bis zu dieser Stelle neu verlegt werden. Zudem bildet das zentrale Gateway einen Flaschenhals. Mit steigender Anzahl an vernetzten Funktionen nimmt auch die über das Gateway abzuwickelnde domänenübergreifende Kommunikation zu.

3.3 Topologien für Ethernet-basierte Fahrzeugnetze

73

Infotainment Front

Dach

Heck

G

Motorraum

Instrumente

Abbildung 3.8: Heutige logische Topologie in Serienfahrzeugen — Farben repräsentieren Anwendungsdomänen: zentrales Gateway (G) in schwarz; mehrfarbige Steuergeräte sind ohne GatewayFunktionalität an mehreren Bussen angebunden (eigene Darstellung)

3.3.2 Domänen-Gateway-Topologie Die Domänen-Gateway-Topologie ist ein erster Evolutionsschritt hin zu einem Ethernet-basierten Bordnetz. Hierbei wird das zentrale Gateway aufgeteilt in mehrere Domänen-Gateways. Diese sind über einen Ethernet-Switch miteinander verbunden. Die domänenübergreifende Kommunikation wird direkt zwischen den Domänen-Gateways abgewickelt. Abbildung 3.9 auf der nächsten Seite zeigt die Domänen-Gateway-Topologie. Dabei sind die Gateways als eigenständige Entitäten gezeigt. In einer realen Implementierung dieser Topologie würde die Gateway-Funktionalität von einem der bestehenden Steuergeräte der jeweiligen Domäne übernommen. Für sich genommen bietet die Domänen-Gateway-Topologie nur wenige Vorteile gegenüber der heutigen auf einem zentralen Gateway basierenden Topologie. Zwar wird der Flaschenhals des zentralen Gateways aufgelöst; es bleiben jedoch die durch das gesamte Fahrzeug verlaufenden Busse bestehen. Dennoch hat dieser Evolutionsschritt hin zu einem Ethernet-basierten Netzwerk seine Berechtigung. So wird in dieser Architektur erstmals ein zentraler Ethernet-Switch eingesetzt, um die Anwendungsdomänen zu verbinden. Dieser erste Ethernet Backbone kann eingesetzt werden, um Sensoren mit einem hohen Bandbreitenbedarf — beispielsweise Kameras — in das Fahrzeugnetz-

74

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

Infotainment Front G

Dach G

Heck

G G

G

Motorraum

Instrumente

Abbildung 3.9: Domänen-Gateway-Topologie — Vormals zentrales Gateway (schwarz) wird ersetzt durch mehrere Domänen-Gateways (G) und Ethernet Backbone, mehrfarbige Steuergeräte sind ohne Gateway-Funktionalität an mehreren Bussen angebunden (eigene Darstellung)

werk einzubinden. Zudem bietet die Topologie eine Anbindung der Domänen mit hoher Bandbreite. So kann beispielsweise beim Programmieren von Steuergeräten die Dauer der Übertragung der Software deutlich reduziert werden, indem die Daten verschiedener Domänen parallel an die DomänenGateways des Fahrzeugs gesendet werden. Damit verteilt sich die Last für das Bereitstellen der Steuergerätesoftware über mehrere Gateways. Darüber hinaus ist es in dieser Topologie erstmals möglich, Steuergeräte direkt in das Ethernet einzubinden. Damit lassen sich Steuergeräte herkömmlicher und zukünftiger Technologien in einer Architektur verbinden.

3.3.3 Domänen-Zonen-Topologie Die Domänen-Zonen-Topologie (siehe Abbildung 3.10 auf der nächsten Seite) ist der letzte Schritt im Übergang von Feldbussen zu einem reinen Ethernet Backbone, welcher noch Busse verwendet. Der Begriff Domänen-ZonenTopologie wurde gewählt, da die Kommunikation innerhalb der Domäne erstmals über den Ethernet Backbone abgewickelt wird, indem die Domänenbusse in Zonen aufgeteilt werden. Damit teilen sich in dieser Topologie erstmals die verschiedenen Domänen dieselbe physikalische Infrastruktur des Backbones. In der Domänen-Zonen-Topologie werden erstmals die das

3.3 Topologien für Ethernet-basierte Fahrzeugnetze

75

Infotainment Front G

Dach G

G

G

Heck

G

G

G

G

G

Motorraum

G

G

G

G

G

G

Instrumente

Abbildung 3.10: Domänen-Zonen-Topologie — Ursprüngliche Feldbusse werden zerteilt und lokal über Gateways (G) an den Ethernet Backbone angebunden; mehrfarbige Steuergeräte und Gateways besitzen Funktionalität verschiedener Domänen (eigene Darstellung)

Fahrzeug durchspannenden Busse aufgelöst. Dazu werden die Busse zerteilt und erhalten für jedes Teilstück jeweils ein separates Gateway. Es wird nicht nur die domänenübergreifende Kommunikation von einem Bus einer Domäne zu einem Bus einer anderen Domäne sondern auch die Kommunikation innerhalb der Domäne über den Ethernet Backbone abgewickelt, sofern sich die Kommunikationspartner nicht auf demselben Teilbus (in derselben Zone) befinden. Die Busse der Domänen durchlaufen in dieser Topologie nur noch die einzelnen Steuergerätezonen — beispielsweise Front, Motorraum, Instrumente — nicht jedoch das Gesamtfahrzeug. Für die physikalische Ausdehnung wird ausschließlich der Ethernet Backbone verwendet. Auch in dieser Topologie gibt es verschiedene Implementierungsansätze. Es können Gateways verschiedener Domänen innerhalb einer Zone zusammengefasst werden, sodass je Zone ein Gateway mit mehreren Bussen entsteht. Dies reduziert die Anzahl benötigter Switche, da nun je Zone nur noch ein Ethernet-Link erforderlich ist. Eine weitere Möglichkeit ist, die Gateway-Funktionalität je Domäne und Zone einem Steuergerät zuzuschreiben, welches neben seiner eigentlichen Aufgabe zusätzlich die Anbindung des Teilbusses an den Backbone realisiert.

76

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen Infotainment

Front Dach Heck

Motorraum

Instrumente

Abbildung 3.11: Flache Topologie — Feldbus ist vollständig durch switchbasiertes Netzwerk ersetzt; mehrfarbige Steuergeräte besitzen Funktionalität verschiedener Domänen (eigene Darstellung)

3.3.4 Flache Topologie Die flache Topologie (siehe Abbildung 3.11) ist die theoretische Endstufe eines Ethernet-Fahrzeug-Backbones. Alle Steuergeräte, welche heute über Busse angebunden sind, nutzen Ethernet-Links für die Kommunikation. Dabei wird ausnahmslos eine geteilte physikalische Infrastruktur für die Kommunikation aller Domänen eingesetzt. Eine Separierung der Domänen kann innerhalb des Netzwerks beispielsweise über VLANs erreicht werden. Die flache Topologie benötigt eine hohe Anzahl an Switch-Ports. Daher würden in einer realen Implementierung mehrere Switche in den Steuergerätezonen eingesetzt. Dies vereinfacht die Verkabelung, da durch die Aufteilung in mehrere Switche und die damit verbundene bessere Positionierung die Links zwischen den Steuergeräten und den Switchen kürzer ausfallen. Eine Herausforderung bei einer reinen Ethernet-basierten Topologie liegt in der Auslegung der Switche. Einige Steuergeräte werden nur als optionale Sonderausstattung verbaut. Jedoch muss in einer switchbasierten Topologie stets die Maximalausstattung für die Dimensionierung der Switche herangezogen werden. Dies kann dazu führen, dass in einer Basisausstattung unnötig große Switche verwendet werden müssen. Da die Switche üblicherweise nicht eigenständig, sondern in bestehende Steuergeräte integriert sind, ist auch die Verwendung unterschiedlich großer Switche für verschiedene Ausstattungslinien unwirtschaftlich. Eine Lösung für dieses Problem ist die Verwendung

3.4 Kommunikationstechnologien und -strategien

1

2

3

4

(a) Optional freie ungenutzte Ports (rot)

1

77

2

3

4

(b) Optional Daisy-Chain (3-PortSwitche)

Abbildung 3.12: Topologie mit optionalen Steuergeräten (unterbrochene Linie) — Lösung mit freien Ports (a) und Daisy-Chains (b) (eigene Darstellung)

von Daisy-Chains. In diesen Ketten von Steuergeräten liefern optionale Steuergeräte die für sie benötigten Switch-Ports mit, indem sie selbst einen kleinen Switch enthalten. Abbildung 3.12 vergleicht die beiden Ansätze. Die Verwendung von Daisy-Chains ist jedoch aus anderer Perspektive problematisch: Durch das Hinzufügen von Switch-Hops verschlechtert sich die Netzwerkperformance. Die Latenz wird durch die Switchverzögerungen erhöht und durch konkurrierenden Datenverkehr steigt der Jitter an. Innerhalb der Kette müssen sich zudem alle Steuergeräte die zur Verfügung stehende Bandbreite teilen. Daher muss vor dem Einsatz einer Daisy-Chain das Netzwerk für alle möglichen Ausstattungsvarianten evaluiert werden. Der Umfang dieser Evaluierung kann reduziert werden, indem Kombinationen von optionalen Steuergeräten ausgeschlossen werden.

3.4 Kommunikationstechnologien und -strategien Im Folgenden werden Ansätze zur Echtzeitkommunikation im Fahrzeug vorgestellt, entwickelt und verglichen.

3.4.1 Global geplante Kommunikation und Überprovisionierung Für das Erreichen der Echtzeitanforderungen im Ethernet-basierten Bordnetzwerk stehen sich grundsätzlich zwei Ansätze gegenüber, welche den Zugriff auf die Netzwerkressource steuern. Es lässt sich unterscheiden zwi-

78

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

schen den zeitgesteuerten synchronen (time-triggered) Verfahren, auch als koordiniertes TDMA bezeichnet, und den event-getriebenen asynchronen (event-triggered) Ansätzen. Obwohl die überwiegende Anzahl an Signalen im Fahrzeug zyklisch übertragen wird, basieren heutige Fahrzeugnetze nahezu ausnahmslos auf asynchroner Übertragung unter Verwendung von CANBussen. Zwar bieten neuere Feldbusse wie FlexRay auch ein time-triggered Übertragungs-Pattern im statischen Segment an (siehe auch Abschnitt 2.1.1 auf Seite 15), in der Praxis werden diese synchronen Elemente jedoch nur selten genutzt. Dies liegt insbesondere am größten Nachteil der time-triggered Kommunikation, dem Aufwand der notwendigen Zeitsynchronisierung aller Teilnehmer und der Planung des Kommunikationsablaufs in einem Zeitplan (Schedule). Diese Planung muss vorab durchgeführt werden und legt damit bereits in einem frühen Stadium der Entwicklung die möglichen Botschaften im Netzwerk fest. Insbesondere in großen Netzwerken mit mehreren tausend Signalen ist es anspruchsvoll, das Gesamtverhalten zu planen. Eine spätere Anpassung und Erweiterung ist dann nur noch mit großem Aufwand möglich. Zudem ist es sehr aufwändig diese Zeitpläne manuell zu erstellen. Dennoch bietet die time-triggered Datenübertragung große Vorteile gegenüber asynchronen Verfahren. Die Nachrichtenübertragung ist durch den definierten Schedule vollständig deterministisch und unterliegt damit nur einem sehr geringen Empfangs-Jitter. Das Übertragungsverhalten kann einfach aus dem Schedule abgelesen werden und verändert sich durch steigende Belastung des Kommunikationsmediums nicht. Darüber hinaus lässt sich das Medium gleichmäßig über die Zeit auslasten, wohingegen beispielsweise der asynchrone CAN-Bus durch seine Arbitrierungsalgorithmen zur Bildung von Bursts und somit zu stark schwankender Übertragungsperformanz neigt. Dies führt dazu, dass heute asynchron operierende Feldbusse im Auto nur bis zu etwa 70 % ihrer Gesamtkapazität ausgelastet werden sollten. Im Gegensatz zu ungeswitchten Transporttechnologien wie beispielsweise FlexRay, welches auf einem global geteilten Medium operiert, also eine geteilte Kollisionsdomäne besitzt, ist das geswitchte Netzwerk in eine Vielzahl von sogenannten Congestion-Domänen, unterteilt. Die Congestion-Domäne beschreibt die geteilte Ressource, in deren Bereich gleichzeitig zu übertragende Pakete durch Warteschlangen auf der Zeitachse verteilt werden. Geswitchte Netzwerke, welche das time-triggered Verfahren zur Realisierung der Echtzeiteigenschaften verwenden, können daher nicht wie im FlexRay-Bus einen globalen Zeitplan nutzen, sondern benötigen einen dedizierten Zeitplan für jede Congestion-Domäne. Diese lokal definierten Zeitpläne regeln den

3.4 Kommunikationstechnologien und -strategien

79

Medienzugriff auf die geteilte Ressource, den Ausgangslink. Alle lokalen Schedules müssen so aufeinander abgestimmt werden, dass alle time-triggered Botschaften im Netzwerk auf dem Pfad von Sender zu Empfänger eine Endezu-Ende-Latenz erreichen, die den Anforderungen der Anwendung genügt. Die Vielzahl lokaler Zeitpläne macht das Gesamtproblem besonders komplex und führt zu einer NP-vollständigen Problemklasse. Ein automatisiertes Scheduling, welches nachgewiesen ein global optimales Ergebnis erzielt, ist daher nicht möglich. Eine Optimierung auf Ebene lokaler Schedules kann nicht ausreichen, da eine Nachricht auf ihrem Weg von Sender zu Empfänger bei jedem Hop in einem anderen Schedule organisiert ist. Dadurch ist das lokale Optimum für einen Port nicht zwangsläufig auch das absolute Optimum für eine Nachricht auf dem Gesamtpfad durch das Netzwerk. Neben dem globalen Schedule benötigt die time-triggered Kommunikation eine im gesamten Netzwerk möglichst genau synchronisierte Zeit. Dafür muss für alle Teilnehmer im Netzwerk ein Zeitsynchronisierungsprotokoll implementiert werden (siehe auch Abschnitt 2.1.3 auf Seite 37); darüber hinaus werden für eine möglichst genaue Synchronisierung zusätzliche Ressourcen wie beispielsweise genaue Quarze und Zeitstempel-Einheiten, aber auch Rechenzeit für die Ausführung der Synchronisierungsalgorithmen benötigt. Insgesamt steigert dies die Komplexität im Netzwerk und führt eine weitere mögliche Fehlerquelle ein. Fällt die Zeitsynchronisierung aus, kann nicht mehr synchron kommuniziert werden. Daher können Synchronisierungsprotokolle teilweise redundant ausgelegt werden (siehe auch Abschnitt 2.1.3 auf Seite 37). Alternativ zu koordiniertem TDMA bestehen in event-basierten Technologien verschiedene Strategien, um Echtzeiteigenschaften zu erzielen; insbesondere sind dies die Priorisierung und das Traffic Shaping. Die Priorisierung führt dazu, dass Nachrichten entsprechend ihrer Echtzeitanforderungen beim Zugriff auf das Medium bevorzugt werden. Dies können entweder strikte Prioritäten sein, wobei solange Botschaften der höchsten Priorität versendet werden, bis die entsprechende Warteschlange leer ist, oder aber andere Varianten, welche ein faires Verfahren implementieren, das die zur Verfügung stehende Bandbreite entsprechend der Priorität aufteilt. Oft wird dabei von sogenannten Traffic Shapern gesprochen. Es gibt verschiedene Ansätze des Traffic Shapings. Ein einfacher Ansatz ist die BAG der rate-constrained Verkehrsklasse in AS6802 (siehe Abschnitt 2.1.3 auf Seite 35). Hier werden feste Zeitabstände zwischen den Paketen definiert, welche durch den Sender eingehalten werden müssen. Dadurch können Warteschlangen eine definierte Länge nicht überschreiten. Über diese Eigenschaft lassen sich obere Grenzen

80

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

für die Ende-zu-Ende-Latenz und den maximalen Jitter beweisen. Komplexer ist der CBS in Ethernet AVB. Im CBS werden Bandbreitenkontingente durch den sogenannten Kredit überwacht, indem das Senden einer Botschaft den Kredit reduziert, während das Warten auf den freien Link den Kredit erhöht (siehe Abschnitt 2.1.3 auf Seite 31). Allen event-basierten Ansätzen ist jedoch gemein, dass sie die Echtzeiteigenschaften durch Überprovisionierung, der Einplanung von ungenutzter Kapazität, erreichen. So wird der CANBus in der Praxis nur zu 70 % ausgelastet; auch Ethernet AVB empfiehlt, weniger als 70 % der verfügbaren Bandbreite den Echtzeitverkehrsklassen zuzuweisen. Diese Strategie der Überprovisionierung stellt sicher, dass in der Praxis Bursts sowie die Aufstauung von statistisch möglichen ÜbertragungsPeaks in angemessener Zeit durch die vorgehaltene zusätzliche Bandbreite abgearbeitet werden können. Neben der Kommunikationstechnologie selbst ist auch deren Integration in die Basissysteme der Steuergeräte entscheidend für die zu erzielenden Echtzeiteigenschaften. Auch wenn bereits heute mit der FlexRay-Technologie ein Repräsentant der global geplanten Kommunikation zur Verfügung steht, sind die Softwarearchitekturen heutiger Automobilelektronik nicht auf ein global synchronisiertes Kommunikationsparadigma optimiert. Heute eingesetzte Basissoftware unterstützt das zeitgesteuerte Ausführen von Tasks synchron zur time-triggered Kommunikation kaum, wodurch der Nutzen einer synchronen Kommunikation bisher gering ist. Solange die Kommunikationszyklen der Applikationen auf den Steuergeräten des Fahrzeugs nicht mit denen des Kommunikationsmediums synchron ausgeführt werden, müssen Anwendung und Netzwerk über Puffer synchronisiert werden. Dies verursacht ein undeterministisches asynchrones Element im Gesamtpfad zwischen sendender und empfangender Applikation, welches den Vorteil der time-triggered Übertragungsstrecke, zumindest teilweise, aufhebt. Arbeitsgruppen wie die TSN Task-Force für Scheduled Traffic und Gremien in der Standardisierung für Basissoftware wie AUTOSAR versuchen derzeit, diesen Bereich zu standardisieren. Im Hinblick auf zukünftige Fahrzeugnetzwerkarchitekturen ist der Einsatz von time-triggered Echtzeit-Ethernet-Varianten zweigeteilt zu bewerten. Ein zunehmend wichtiges Thema in der Fahrzeugentwicklung ist die funktionale Sicherheit. Für Straßenfahrzeuge ist diese insbesondere in der ISO-Norm 26262 [84] definiert. Die Norm definiert, wie sicherheitsrelevante Elektroniksysteme zu entwickeln sind, um das Risiko von Fehlfunktionen, welche eine Gefahr für Fahrer, Insassen und Umgebung eines Fahrzeugs bedeuten, zu vermeiden oder zu minimieren. Ein umfangreicher Teil der Norm befasst sich

3.4 Kommunikationstechnologien und -strategien

81

mit dem Nachweis der Zuverlässigkeit einer sicherheitsrelevanten Funktion. Während die Konfiguration von time-triggered Systemen deutlich komplexer ist als die äquivalenter event-basierter Architekturen, ist durch den vollständigen Determinismus der Nachweis der in der Praxis zu erwartenden Eigenschaften einfacher. Während in event-basierten Systemen der Zufall die bestimmende Größe für die in der Praxis auftretenden Netzwerkmetriken ist, führt der Determinismus in zeitgesteuerten Systemen zu einem zu jeder Zeit definierten Verhalten. Demgegenüber steht die höhere Komplexität der time-triggered Kommunikation, welche beispielsweise eine globale Zeitsynchronisierung benötigt. Ein möglicher Kompromiss zwischen der Komplexität und dem erstrebenswerten Determinismus der synchronen Kommunikation ist die Definition einer kleinen Teilmenge von Signalen im Fahrzeugnetzwerk, welche hohe Anforderungen an den Determinismus der Übertragung haben. Ausschließlich diese Signale werden auf time-triggered Botschaften abgebildet. Durch die Begrenzung der synchronen Botschaften im Netzwerk verkleinert sich die Problemgröße des Schedulings und vereinfacht damit das Finden eines gültigen Zeitplans. Dennoch bleibt, zumindest in den Bereichen des Netzwerks, in denen synchrone Kommunikation genutzt wird, die Komplexität der Uhrensynchronisation erhalten.

3.4.2 Deterministische Übertragung — FlexRay und time-triggered Ethernet FlexRay (siehe Abschnitt 2.1.1 auf Seite 15) ist bisher der Standard für deterministische Übertragung von Daten im Fahrzeugnetzwerk. Lösungen für die deterministische Übertragung von Steuerdaten auf Basis von Ethernet müssen sich an den Echtzeitmetriken von FlexRay messen. Im Folgenden werden auf Basis eines analytischen Modells und anhand einer Beispieltopologie Ende-zu-Ende-Latenz und Jitter von FlexRays statischem Segment und der time-triggered Traffic-Klasse von TTEthernet (siehe Abschnitt 2.1.3 auf Seite 35) verglichen. Es wird gezeigt, dass sich ein System basierend auf FlexRay in ein TTEthernet-basiertes System überführen lässt. Das verwendete analytische Modell ist veröffentlicht [20]. Als Topologie wurden bei FlexRay zwei aktive Sternkoppler sowie für Ethernet das vergleichbare Netzwerk aus zwei Switchen zwischen Sender und Empfänger gewählt.

82

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

Ende-zu-Ende-Latenz Die Ende-zu-Ende-Latenz setzt sich zusammen aus der Signallaufzeit sowie der Nachrichtenübertragungszeit der Botschaft. Für FlexRay lässt sich die Signallaufzeit tS aus der Laufzeitverzögerung des Kabels tW D — hier mit der maximal möglichen Kabellänge von lW = 72 m — zuzüglich der Verzögerungen durch die Bustreiber tDD und der Verzögerung der aktiven Sternkoppler tSD auf Basis der Anzahl aktiver Sterne nS berechnen [118]: tS = tW D · lW + 2 · tDD + tSD · nS = 10 ns m · 72 m + 2 · 100 ns + 250 ns · 2 = 1420 ns

(3.2)

Die Übertragungszeit hängt von der Frame-Größe lF und der Geschwindigkeit des Busses ab. Die Frame-Größe kann aus der Übertragungsstartsequenz lT S — hier 15 bit — und der Frame-Startsequenz lF S sowie dem ProtokollOverhead lP O , der Frame-Endesequenz lF E und den in 10 bit/B verpackten Nutzdaten berechnet werden: lF = lT S + lF S + lP O + lP · 10 bit + lF E = 15 bit + 1 bit + 80 bit + lP · 10 bit + 2 bit = 98 bit + lP · 10 bit

(3.3)

lFmin = 98 bit + 2 · 10 bit = 118 bit lFmax = 98 bit + 254 · 10 bit = 2638 bit Ein Frame ist damit minimal lFmin = 118 bit und maximal lFmax = 2638 bit lang. Beim minimalen Frame wurde ein Payload von 2 B definiert. Dies ist der kleinstmögliche nicht leere Frame in FlexRay. Aus einer Busgeschwindigkeit VB von 10 Mbit/s ergibt sich eine Bitübertragungszeit tb von: tb =

1 μs = 0,1 bit VB

(3.4)

Daraus errechnet sich die Nachrichtenübertragungszeit tT : tT = lF · tb μs tTmin = 118 bit · 0,1 bit = 11,8 μs μs tT max = 2638 bit · 0,1 bit = 263,8 μs

(3.5)

3.4 Kommunikationstechnologien und -strategien

83

Die Nachrichtenübertragungszeit liegt somit zwischen 11,8 μs und 263,8 μs. Zusammen mit der Signallaufzeit tS = 1420 ns ergibt sich für FlexRay somit je nach Frame-Größe eine Ende-zu-Ende-Latenz zwischen 13,22 μs und 265,22 μs. Die Latenz für time-triggered Ethernet tL besteht aus den Verzögerungen in den Switchen tSD und den Signallaufzeiten tW D und Übertragungszeiten lF · tb auf den Links. Bei 100 Mbit/s beträgt die Bit-Übertragungszeit tb = 0,01 μs/bit. Die Switchverzögerungen sind implementierungsspezifisch und hängen zusätzlich vom Schedule ab. Auf Basis von Hardwarespezifikationen kann sie mit 1 μs bis 2,4 μs angenommen werden. Auf Basis von Formel 3.6 kann damit vereinfacht eine Ende-zu-Ende-Latenz zwischen 20,96 μs und 365,60 μs approximiert werden: tL = tW D · lW + (ns + 1) · lF · tb +

ns 

tSDi

i=1

μs  tL = 11,12 ns · 72 m + 3 · lF · 0,01 bit + 2,4 μs ns

i=1

tLmin tL254 tLmax

(3.6)

μs = 800,64 ns + 3 · 512 bit · 0,01 bit + 2 · 2,4 μs ≈ 20,96 μs μs = 800,64 ns + 3 · 2176 bit · 0,01 bit + 2 · 2,4 μs ≈ 70,88 μs μs = 800,64 ns + 3 · 12 000 bit · 0,01 bit + 2 · 2,4 μs ≈ 365,60 μs

Aufgrund der minimalen Paketgröße von 64 B liegt die Übertragungszeit für den minimalen Frame in time-triggered Ethernet bei 100 Mbit/s (tLmin ≈ 20,67 μs) leicht über FlexRay (tLmax = 13,22 μs). Die Ende-zuEnde-Latenz im time-triggered Ethernet für einen Frame mit 254 B Payload (FlexRay-Maximum) ist dagegen mit tL254 ≈ 70,59 μs gegenüber 265,22 μs bereits deutlich kürzer (siehe Abbildung 3.13 auf der nächsten Seite). Die Rentabilitätsschwelle für TTEthernet liegt bei zirka 11 B Nutzdaten. Für ein Netzwerk mit 1 Gbit/s reduziert sich auch die Ende-zu-Ende-Latenz für den minimalen Frame auf 6,82 μs und ist damit geringer als FlexRays minimale Latenz. Jitter Der maximale Jitter, definiert als maximale Varianz der Nachrichtenlatenz (siehe Abschnitt 3.1.3 auf Seite 62), wird für FlexRay aus der maximalen Uhrenabweichung nach einem Zyklus berechnet, da in jedem Zyklus eine

84

3 Bewertungsgrundlage und Elemente zukünftiger Architekturen

350

TTEthernet FlexRay

Latenz [μs]

300 250 200

Vergrößerter Ausschnitt

150

40

100

20

50

(11,16|20,96)

0 0

0 0

200

400

600

800

20

40

60

1.000 1.200 1.400

Nutzdatenlänge [B] Abbildung 3.13: Ende-zu-Ende-Latenz in Abhängigkeit zu Nutzdatengröße – FlexRay und TTEthernet (eigene Darstellung)

Uhrensynchronisation stattfindet. Für eine Quarzungenauigkeit ΔQ von 200 ppm und eine Zyklusdauer tC von 16 ms ergibt sich eine maximale Uhrenabweichung tJmax von 6,4 μs: 2 · t C · ΔQ (1 − ΔQ ) 2 · 16 ms · 0.0002 = = 6,4 μs 1 − 0.0002

tJmax =

(3.7)

Dieser Wert ergibt sich, wenn die Uhren zweier Teilnehmer maximal voneinander abweichen (auseinanderdriften). FlexRay erlaubt auch eine höhere Abweichung der Uhren. Zinner et al. berechnen für einen 5 ms-Zyklus eine Abweichung von bis zu 15 μs [169]. In der Praxis werden jedoch Quarze empfohlen, die bei Raumtemperatur eine Abweichung von ±50 ppm und im Worstcase eine Abweichung von ±100 ppm (entspricht den hier verwendeten 200 ppm) nicht überschreiten [90]. Für time-triggered Ethernet-Protokolle muss der maximalen Uhrenabweichung noch die Ungenauigkeit des Synchronisierungsprotokolls hinzugefügt werden. Diese liegt je nach Implementierung bei