Ethernet und IP im Kraftfahrzeug - Vector

Bussysteme llll IP-Kommunikation
Nach dem Debüt des CAN-Busses
in der Mercedes-S-Klasse
im Jahr 1991 haben sich die
Bussysteme LIN, MOST und FlexRay
im Kraftfahrzeug etabliert. CAN kommt
in aktuellen Pkw-Netzwerkarchitekturen
nach wie vor in allen Domänen (von
Powertrain bis Body) zum Einsatz. Der
LIN-Bus ist prädestiniert für den einfachen
und kostengünstigen Datenaustausch
von unkritischen Signalen im
Komfortbereich. Dort wo Bandbreiten
und Echtzeitanforderungen an ihre
Grenzen stoßen, wird CAN – wenn
wirtschaftlich vertretbar – durch Flex-
Ray oder MOST ersetzt. In aktuellen
Fahrzeugen kommen oft alle genannten
Bussysteme zum Einsatz – segmentiert
und über Gateways vernetzt.
38 Elektronik automotive 4.2012
Ethernet und IP
im Kraftfahrzeug
Neue Anforderungen an das Entwicklungswerkzeug durch
den Ethernet- und IP-Einsatz
Bis vor einigen Jahren herrschte die Meinung, Ethernet komme mit Ausnah-
me des Diagnosezugangs nie ins Serienfahrzeug. In Kürze nutzen kamera-
basierte Fahrerassistenzsysteme als erste Anwendungen Ethernet als Sy-
stemnetzwerk. Fahrzeughersteller, Zulieferer und Hersteller von Entwick-
lungswerkzeugen werden mit neuen Herausforderungen konfrontiert, weil
das Internet-Protokoll und Ethernet für das Fahrzeug eine neue Netzwerk-
technologie darstellen. Dennoch lassen sich viele Aufgaben bereits lösen.
Von Hans-Werner Schaal
Motivation für Ethernet
In der Bürokommunikation, der Automatisierungstechnik
mit dem ODVA-
Standard Ethernet/IP und ProfiNet
sowie in der Luftfahrttechnik mit AF-
DX ist Ethernet schon seit langem
Standard. Im Automobilbereich hatte
sich Ethernet im Fahrzeug als Diagnosezugang
bewährt. Weitere Einsatzbereiche
wurden in den letzten Jahren in
den automobilen Forschungs- und Entwicklungsabteilungen
verstärkt diskutiert,
denn die verfügbare, skalierbare
Bandbreite und die Flexibilität sprachen
stark dafür. Allerdings fehlte
eine für das Kraftfahrzeug geeignete
wirtschaftliche Verkabelungstechnologie.
Haupttreiber für den Ethernet-Einsatz
im Fahrzeug sind aktuell kamerabasierte
Fahrerassistenzsysteme. Bei
Kameraanwendungen im Fahrzeug
kam bisher die Low-Voltage-Differential-Signaling-Technologie
(LVDS)
zum Einsatz. Die dort in der Regel
verwendeten geschirmten Kabel sorgen
zwar für die elektromagnetische
Verträglichkeit, sind aber für Branchenverhältnisse
teuer und in der Verlegung
im Kraftfahrzeug wenig praktikabel.
Mittlerweile steht ein Physical
Layer zur Verfügung, der 100 Mbit/s
auf einem CAN-ähnlichen, verdrillten
Zweidraht-Kabel (Unshielded Twisted
Pair) im Vollduplex überträgt und sich
nach Meinung verschiedener Veröffentlichungen
für den Einsatz im
Kraftfahrzeug geeignet ist [1, 2, 3].
Anforderungen an ein IP-Entwicklungswerkzeug
Für das Entwicklungswerkzeug ergeben
sich zunächst die aus bisherigen
Bussystemen bekannten Anforderungen.
Erforderlich ist zunächst eine
detaillierte Protokollanalyse mit Stimulationsmöglichkeit
bis hin zu
skriptbasiertem Testen mit automatischer
Erstellung von Testprotokollen.
Auch erwartet der Anwender, dass die
auf dem Markt bewährte Multi-Bus-
Fähigkeit auf Ethernet und IP ausgeweitet
wird, um Abhängigkeiten zwi-

schen Ereignissen auf verschiedenen
Bussystemen optimal untersuchen zu
können. Gegenwärtig interessieren
solche Zusammenhänge beispielsweise
zwischen LIN und CAN, zukünftig
zwischen CAN und IP.
Der Anwender benötigt bei der Protokollanalyse
wie bisher einen einfachen,
symbolischen Zugriff auf alle
relevanten Applikationssignale sowie
die Möglichkeit, diese beliebig logisch
und grafisch weiterzuverarbeiten.
Hinzu kommen neue Anforderungen,
die sich einerseits aus der Busphysik
und andererseits aus der Protokollvielfalt
von IP ergeben. Anhand des aktuellen
Kamerabeispiels und vier weiteren
Einsatzbereichen von IP und
Ethernet im Kfz wird nachfolgend dargestellt,
wie sich diese Messaufgaben
aus Sicht der Systemverantwortlichen
in der Serienentwicklung stellen und
welche besonderen Anforderungen
sich daraus für das Entwicklungswerkzeug
ergeben.
Ethernet als Systemnetzwerk
für die Kamera nutzen
Ein kamerabasiertes Fahrerassistenzsystem
wird bei BMW die erste Serienanwendung
im Kraftfahrzeug sein,
die IP und Ethernet als Systemnetzwerk
im Fahrzeug einsetzt [1]. OEMs
und Zulieferer nutzen hierfür den Physical
Layer BroadR-Reach, um gegenüber
der bisher gängigen LVDS-Technologie
Gewicht und Kosten einzusparen
[1, 4, 5]. BroadR-Reach wird von
weiteren Anbietern lizensiert [6].
Ein Kamerasystemnetzwerk ist exemplarisch
mit möglichen Messpunkten
in Bild 1 dargestellt. Alternativ
Netzwerktester
Image
Processor
Embedded Ethernet System
T
Switch1
Node1
Node2
Switch2
Ethernet
lassen sich alle Kameras
direkt mit einem
Switch verbinden.
Wie bei den bisher
im Kraftfahrzeug
verwendeten Bussystemen
muss der Datenverkehr
an verschiedenen
Punkten
im Netzwerk beobachtet,
analysiert und
zeitsynchron verglichen
werden. Die
Mess-Hardware muss
daher zunächst die
aktuelle Busphysik
unterstützen, bei-
spielsweise BroadR-Reach, aber auch
für zukünftige Physical Layer offen
sein. Wünschenswert ist ein mehrkanaliger
Abgriff über T-Stücke, der das
Systemnetzwerk beim Monitoring
möglichst wenig beeinflusst. Zur Validierung
der Systemfunktion sollte
das T-Stück auch Fehler einfügen können.
Über die Analyse hinausgehend
ist auch die Stimulation oder gar die
Simulation ganzer Teile des Netzwerks
erforderlich (Restbussimulation). Das
bringt einige Herausforderungen an
die Mess-Hardware mit sich.
Eine Kameraapplikation stellt hohe
Anforderungen an Zeitsynchronisation
und Quality of Service (QoS) [4].
Diese sollen durch Protokollerweiterungen
des Audio-Video-Bridging-
Standards (AVB) gelöst werden [7].
Nachdem sich die Hersteller hinsichtlich
der Bit-Übertragungsschicht (OSI-
Layer 1) praktisch einig sind, wird aus
Kosten- und Testgründen auch eine
Vereinheitlichung der höheren Schichten
angestrebt.
Allein aufgrund
der bei der Kameraapplikationverwendeten
Protokolle gibt
es neue Anforderungen
an die Mess-Software,
damit beliebige
Signale aus der Pay-
T
Node3
Node4
Node5
l Bild 1. Zuverlässige Analyse von kamerabasierten Fahrerassis-
tenzsystemen erfordert das Abgreifen des Datenverkehrs an mehreren
Stellen des Ethernet-Netzwerks, idealerweise über „T-Stücke“
mit geringstmöglichem Zeitversatz und mit Darstellung auf
gemeinsamer Zeitbasis.
7 Anwendung
6 Darstellung
5 Sitzung
4 Transport
3 Vermittlung
2 Sicherung
1 Übertragung
Diagnosezugang
DoIP
TCP/IP
UDP
IPv4/
IPv6
100-
Base-Tx
load der verschiedenen
und durchaus
komplexen Protokolle
applikationsgerecht
präsentiert und manipuliert
werden können.
Bild 2 (nach [7]
und Vector) zeigt die
für AVB zum Einsatz
kommenden Proto-
Audio/Video
Zeitsync.
AVB
IEEE
1722
802.1AS
IEEE Ethernet MAC +
VLAN (802.1Q)
BroadR-
Reach
IP-Kommunikation llll Bussysteme
Smart
Grid
ISO
15118
Part 1 (2) SOME/IP Bonjour DHCPv6
DHCP
ISO
15118
Part 2
ISO
15118
Part 3
Control
Kommunikation
TCP/IP
UDP
Dienst-
Konguration
erkennung
der
Adressen
kolle in den Spalten Audio/Video und
Control-Kommunikation. Hinzu kommen
Protokolle zur Bandbreitenreservierung
und weitere Netzwerk-Management-Protokolle,
siehe auch die
vier rechten Spalten in Bild 2. Diese
und weitere in der Grafik aufgeführte
Protokolle kommen aufgrund der im
Folgenden betrachteten Anwendungsfälle
hinzu.
Diagnosezugang im Blickpunkt
UDP
Über die Technologie Diagnostics over
IP (DoIP) ist es möglich, alle angeschlossenen
Steuergeräte verschiedener
Bussysteme zentral über einen
leistungsfähigen Ethernet-Zugang zu
flashen (Bild 3). Die Systementwicklung
des OEM muss diesen Dienst
valide absichern. Weil ein Steuergerät
als Gateway eingesetzt wird, besteht
großes Interesse, die Übertragung der
Diagnosedaten nicht nur auf Seite der
angeschlossenen Bussysteme zu analysieren,
sondern auch auf IP-Seite.
Relevant sind die Protokolle ISO
13400 und IPv4, gegebenenfalls auch
IPv6.
Intelligentes Laden
IPv4/IPv6
ICMPv6
ICMP
IEEE Ethernet MAC + VLAN (802.1Q)
Automotive Ethernet Physical Layer
(z.B. BroadR-Reach)
Auösung der Adresse,
Signallisierung etc.
l Bild 2. IP-Protokolle automobiler Anwendungen im OSI-Referenz-
modell aufgetragen (Spalten links) inklusive Verwaltungsfunktionen
(Spalten rechts): Sowohl neue Protokolle (rot) als auch aus
der Bürokommunikation bekannte (blau) werden verwendet.
NDP
ARP
Das intelligente Laden, auch Smart-
Charging genannt, geht weit über das
einfache Anstecken an die Haushaltssteckdose
hinaus. Das zu ladende
Elektrofahrzeug ist über eine Ladestation
an das Stromnetz (Grid) angeschlossen.
Ladevorgänge starten nicht
einfach, sondern melden den Bedarf
erst einmal an. Durch die Verzögerung
einzelner Ladevorgänge um Bruchteile
von Minuten lassen sich Überlastungen
des Grids vermeiden. Weiter
Elektronik automotive 4.2012 39

Bussysteme llll IP-Kommunikation
Diagnosetester
DoIP/Ethernet
Netzwerktester
Ethernet
Switch/„T”
Diagnose
Gateway
CAN
LIN
MOST
FlexRay
lassen sich angeschlossene Fahrzeuge
als Speicher nutzen; die Abrechnung
mit dem Stromversorger kann automatisiert
erfolgen.
Das ermöglicht die Kommunikation
zwischen Fahrzeug und Ladestation
über Ethernet auf IP-basierten Protokollen,
deren Standardisierung in der
Norm ISO 15118 festgelegt ist. Die Ladestation
kommuniziert dabei mit dem
Grid und dem Fahrzeug. Für den Systemverantwortlichen
beim Fahrzeughersteller
ist die Kommunikation des
Pkw mit der Ladestation wichtig. Um
den Ladeprozess sicherzustellen, ist
eine detaillierte Analyse und Validierung
der Protokolle unumgänglich. Das
Entwicklungswerkzeug muss auch die-
40 Elektronik automotive 4.2012
CAN ECU
LIN ECU
MOST ECU
FlexRay ECU
l Bild 3. Bei der Validierung von DoIP an einem Gateway ist die Darstellung des Daten-
verkehrs sowohl auf der DoIP-Seite (links des Gateways) als auch auf allen angeschlossenen
Bussystemen (rechts des Gateways) wichtig. Idealerweise werden alle
Botschaften aller Netzwerke auf einer gemeinsamen Zeitbasis abgetragen.
se Protokolle unterstützen
(Spalte Smart
Grid in Bild 2).
Kalibrieren, Debuggen
und Flashen
Ethernet mit dem
Mess- und Kalibrierprotokoll
XCP wird
in der Entwicklung
für das Kalibrieren,
Debuggen und Flashen
der Steuergeräte
schon mehrere Jahre
genutzt. In der Serie
steht aus Kostengründen
der Ethernet-Zugang
gar nicht mehr
zur Verfügung. Deshalb
wird derzeit über das vorliegende
Arbeitsprotokoll, beispielsweise CCP
oder XCP on CAN, kalibriert und reprogrammiert.
Wenn aber in naher
Zukunft Ethernet ins Fahrzeug einzieht,
wäre das Messen und Kalibrieren
über XCP on Ethernet aufgrund
der deutlich höheren Messdatenrate
auch in der Serie attraktiv.
WLAN und Car-2-X
l Bild 4. CANoe.IP unterstützt die Entwicklung, Simulation und Test von Embedded-Syste-
men, die über IP oder Ethernet kommunizieren.
Car-2-X bezeichnet die externe Kommunikation
zwischen Fahrzeugen und
Infrastruktur. Die Anwendungen reichen
von Komfortfunktionen über
Verkehrsfluss-Optimierung bis hin
zur Erhöhung der Verkehrssicherheit
durch Fahrerassistenzsysteme.
Die
Technologie befindet
sich bereits in
der Vorserienentwicklung
und die
Standardisierung ist
weit fortgeschritten.
Sie ist IP-basiert;
als Physical Layer
wird der Standard
IEEE 802.11p genutzt.
Das messtechnische
Interesse bei
Car-2-X-Anwendungen
dehnt sich
aus Sicht der Systemverantwortlichen
über die Grenze
des eigenen
Fahrzeugs hinweg
auf eine Anzahl von
Fahrzeugen und Roadside-Units
(RSUs) im Nahbereich aus. Das zu
evaluierende Steuergerät kommuniziert
nicht nur mit den an Bord befindlichen
Bussystemen, sondern auch
über die Luftschnittstelle mit anderen
Verkehrsteilnehmern. Das Entwicklungswerkzeug
muss daher auch diese
IP-basierten Standards unterstützen.
Daneben ergeben sich weitere Anforderungen
im Hochfrequenzbereich,
zum Beispiel WLAN im 5-GHz-
Band.
Protokollvielfalt für Anwendungen
und Messwerkzeug
In Bild 2 sind exemplarisch die verschiedenen,
von der Anwendung abhängigen
Übertragungsschichten und
Protokolle zusammengefasst, die das
Entwicklungswerkzeug allein aufgrund
der bisher behandelten Fälle
unterstützen muss. Einige der im Bereich
der Bürokommunikation verwendeten
Protokolle finden sich hier
wieder. Viele davon sind verzichtbar,
andere kommen hinzu. Die blau gekennzeichneten
Protokolle können aus
der Bürokommunikation übernommen
werden. Jene, die aufgrund der neuen,
automobilen Anwendung hinzukommen,
sind rot dargestellt.
Das Messsystem hat die Aufgabe,
alle relevanten Protokolle aufzulösen
und alle Netzwerkereignisse in einen
kausalen Bezug zu stellen (korrekte
Reihenfolge). Dabei ist es wünschenswert,
alle Busdomänen auf einer gemeinsamen
Zeitbasis mit ausreichender
Genauigkeit darstellen zu können.
Absicherung
von IP-Serienprojekten
Wie die Betrachtung der obigen Anwendungsfälle
zeigt, machen es Kausalitäts-
oder gar Zeitbetrachtungen
über mehrere Bussysteme hinweg
schwierig bis unmöglich, Standard-
Ethernet-Tools aus der Bürokommunikation
für Multi-Bus-Anwendungen
im Fahrzeug nutzen. Ethernet im Bürobereich
ist eben nicht gleich Ethernet
im Automotive-Bereich. Dasselbe gilt
für die jeweils eingesetzten Internetprotokolle.
Diese unterscheiden sich je
nach Anwendung in Art und Komplexität
genauso deutlich wie die Anforderungen
an den Physical Layer.

Um die Signalstruktur der Protokolle
im Entwicklungswerkzeug darzustellen
und den Embedded Code zu
generieren, ist ein geeignetes Engineering-Format
wichtig. Hierfür haben
sich bei CAN das DBC-Format und
bei FlexRay FIBEX durchgesetzt. Für
das neue Ethernet- und IP-basierte
Systemnetzwerk reicht das DBC-Format
als Datenbankformat nicht mehr
aus. Es wäre aus Sicht der Werkzeugzulieferer
hilfreich, wenn sich die
OEMs auf ein gemeinsames Engineering-Format
einigen könnten. Geeignete
Kandidaten wären FIBEX 4.0 und
die AUTOSAR System Description.
Erfahrungen aus anderen Industriebereichen
zeigen, dass danach von Werkzeugherstellern
zeitnah geeignete Entwicklungswerkzeuge
für Analyse und
Code-Generierung zur Verfügung gestellt
werden.
Zukünftige
Fahrzeugnetzwerke
CAN wird noch deutlich länger als
zehn Jahre im Pkw zu finden sein, alle
anderen hier besprochenen Bussysteme
mindestens zehn Jahre. Dennoch
legen die Anwendungen durch steigende
Anforderungen in Hinsicht auf
Bandbreite, Flexibilität und Wirtschaftlichkeit
den Einsatz von IP und
Ethernet immer stärker nahe. In den
nächsten Jahren werden wie bisher
mehrere über Gateways vernetzte Bussysteme
vorzufinden sein – Ethernet
und IP kommen einfach noch dazu.
Wie bei der Kameraapplikation wird
es auch bei zukünftigen IP-Anwendungen
neue Herausforderungen auf
allen Protokollebenen geben, die aber
mit geeigneten Entwicklungswerkzeugen
zu lösen sind.
Ausblick auf IP-Entwicklungswerkzeuge
Für den Automotive-Bereich empfehlen
sich nach wie vor dafür konzipierte
Entwicklungswerkzeuge. Diese
müssen einerseits alle Protokollebenen
unterstützen, sich aber andererseits
auch in die branchentypische Werkzeuglandschaft
einpassen. Für die Absicherung
von Serienprojekten beim
OEM sind insbesondere die Zulieferer
darauf angewiesen, dass geeignete
Entwicklungswerkzeuge zur Verfügung
stehen. Das schließt den Support
und idealerweise auch
die Unterstützung bei
CANoe.IP
der Einführung durch
den Werkzeughersteller
mit ein.
Basierend auf dem
Windows PC
bewährten Simulations-
und Testwerkzeug
CANoe von
Vector Informatik l
deckt die Option IP
die genannten Anforderungen
an ein Ethernet-Entwicklungswerkzeug
bereits ab. Durch die
vielfältigen Ethernet-spezifischen
Funktionen und die Multi-Bus-Fähigkeit
kann CANoe.IP helfen, die Entwicklungszeit
zu reduzieren, wodurch
sich wertvolle Ressourcen zielführend
applikationsseitig einsetzen lassen
(Bild 4). CANoe.IP für die automobile
Netzwerkentwicklung weist denselben
Entwicklungskomfort auf, wie es
für die etablierten Bussysteme CAN,
LIN, MOST und FlexRay Standard ist.
Dabei ist das Entwicklungswerkzeug
in hohem Maße skalierbar und verfügt
prinzipiell über drei Interface-Möglichkeiten
(Bild 5). Im einfachsten Fall
1 arbeitet es mit beliebigen auf einem
Windows-Rechner vorhandenen Netzwerkkarten
zusammen. Kommt
BroadR-Reach zum Einsatz oder sollen
auch Fehler eingefügt werden,
kann als Hardware-Interface zukünftig
die VN56xx-Familie genutzt werden
(Fall 2). Dadurch erhöht sich die
Zeitsynchronität zwischen den IP-
Kanälen und zu anderen Bussystemen
erheblich. Ist Echtzeitverhalten gefordert,
dann kann in Zukunft CANoe.IP
in Verbindung mit der Echtzeit-Hardware
VN8900 betrieben werden, die
mit der Interface-Hardware VN56xx
nahtlos zusammenarbeitet (Fall 3).
eck
Literatur + Links
[1] Bogenberger, R., BMW AG: IP & Ethernet
as potential mainstream automotive
technologies. Product Day Hanser
Automotive. Fellbach, 2011.
[2] Neff, A., Matheeus, K, et al.: Ethernet & IP
als applikativer Fahrzeugbus am
Einsatzszenario kamerabasierter
Fahrerassistenzsysteme. VDI-Berichte
2132, Elektronik im Kraftfahrzeug.
Baden-Baden, 2011. S. 491 – 495.
[3] Streichert, T., Daimler AG: Short and
Longterm Perspective of Ethernet for
Vehicle-internal Communications. 1st
Ethernet & IP @ Automotive Technology
Fall 1
GBE
Fall 2
USB
Fall 3
USB
IP-Kommunikation llll Bussysteme
VN89xx
VN56xx
VN56xx
100/1.000 BT
100/1.000 BT
BroadR-Reach
100/1.000 BT
BroadR-Reach
Bild 5. CANoe.IP mit skalierbaren Hardware-Interfaces und optio-
naler Echtzeitunterstützung (Bilder: Vector Informatik)
Day, BMW, München, 2011.
[4] Nöbauer, J., Continental AG: Migration
from MOST and FlexRay Based Networks
to Ethernet by Maintaining QoS. 1st
Ethernet & IP @ Automotive Technology
Day, BMW, München, 2011.
[5] Powell, S. R., Broadcom Corporation:
Ethernet Physical Layer Alternatives for
Automotive Applications. 1st Ethernet &
IP @ Automotive Technology Day, BMW,
München, 2011.
[6] NXP Develops Automotive Ethernet
Transceivers for In-Vehicle Networks.
November 09, 2011, www.nxp.com/
news/press-releases/2011/11/nxp-develops-automotive-ethernet-transceiversfor-in-vehicle-networks.html.
[7] Völker, L., BMW AG: One for all,
Interoperability from AUTOSAR to
Genivi. 1st Ethernet & IP @ Automotive
Technology Day, BMW, München, 2011.
Dipl.-Ing.
Hans-Werner Schaal
studierte Nachrichtentechnik an der Universität
Stuttgart und Electrical & Computer Engineering
an der Oregon State University in Oregon,
USA. Er ist Business Development Manager
bei der Vector Informatik GmbH im Bereich
der Produktlinie Open Networking. Zuvor
war er Entwicklungsingenieur, Projektleiter
und Produktmanager in verschiedenen Branchen
im Bereich Testwerkzeuge für mehrere
Netzwerk-Technologien.
hans-werner.schaal@vector.com
Elektronik automotive 4.2012 41