Automotive-Ethernet-Schnittstelle: Für den nötigen Durchblick

Automotive-Ethernet-Schnittstelle: Für den nötigen Durchblick

ENTWICKLUNGSWERKZEUGE
(all
Automotive-Ethernet-Schnittstelle:
Für den nötigen Durchblick
Das Testen und Simulieren von Automotive-Ethernet-Netzwerken
­erfordert eine andere Vorgehensweise, als Entwickler es von CAN, ­LIN
und FlexRay her gewohnt sind. Der Beitrag zeigt, wie entsprechende
Hard- und Software idealerweise aufgebaut sind und zusammenspielen, um optimale Entwicklungs-, Simulations- und Testergebnisse ­zu
­erzielen.
Von Peter Fellmeth und Matthias Schwedt
A
utomotive Ethernet ist im Gegensatz zu CAN, LIN und FlexRay
nicht einfach ein weiterer Bus,
der mit sehr hohen Übertragungsraten
glänzt. Vielmehr konfrontiert das System Entwicklungs- und Testabteilungen
mit einer vollständig anderen NetzwerkTopologie, die in vielen Punkten eine
andere Denk- und Herangehensweise
erfordert.
Am Beispiel einer neuen, flexiblen
Automotive-Ethernet-Schnittstelle wird
gezeigt, mit welchen Herausforderungen es Entwickler im Detail zu tun haben.
16
Zentrum des Interesses an Ethernet
ist für die Automobilindustrie der enorme Bandbreitengewinn, der für aktuelle und künftige Anwendungen eine
immer wichtigere Rolle spielt. Systeme
zum autonomen Fahren und Advanced
Driver Assistance Systems (ADAS) sind
stets auf hochaktuelle Umgebungsdaten von Kameras und Radarsystemen
angewiesen. Dort und in anderen Bereichen braucht man hohe Übertragungsraten, um zum Beispiel VideoStreams und Sensordaten schnell zu
übertragen. Aber auch beim Flashen
der vielen Steuergeräte sind Zeit- und
Elektronik automotive Sonderausgabe Ethernet 2016
Kostenvorteile durch eine hohe Bandbreite willkommen. Mit dem IEEE-Standard für Automotive Ethernet 100BASET1 (OABR, OPEN Alliance BroadR-Reach)
sind auf Basis eines einzigen ungeschirmten Adernpaares einfach und
kostengünstig Hochgeschwindigkeitsnetze realisierbar. Das System ist in der
Lage, in jede Richtung gleichzeitig eine
Bruttodatenrate von 100 Mbit/s zu
übertragen, und liefert nach dem Vollduplex-Verfahren somit maximal
200 Mbit/s.
Netzwerk aus 1:1-Verbindungen
Den Vorteil der großen Bandbreite erkauft sich die Automobilbranche jedoch
mit einem Paradigmenwechsel. Denn
Automotive Ethernet unterscheidet sich
von der Topologie her deutlich von
Bus-Systemen wie CAN, LIN oder FlexRay. So stehen bei Ethernet keine Busstränge zur Verfügung, an denen zahlreiche Steuergeräte, Sensoren und Aktoren gemeinsam angeschlossen sind.
Vielmehr hat man es mit einem Netzwerk aus Switches und vielen elektri-
eB
ilde
r: V
ec t
or)
ENTWICKLUNGSWERKZEUGE
schen Punkt-zu-Punkt-Verbindungen
zu tun. Bei solchen vollständig geswitchten Netzwerken spielt die Topologie, das heißt die Anordnung der
einzelnen Knoten, eine wichtige Rolle
– insbesondere wenn es um Echtzeitfähigkeit geht. Technologien wie AVB
(Audio Video Bridging) und TSN (Time
Sensitive Networking) haben Auswirkungen auf Switches und Steuergeräte
und werden in Zukunft AutomotiveEthernet-Netzwerke mit Funktionen wie
beispielsweise Priorisierung von Datenpaketen und Zeitsynchronität bereichern.
All dies erhöht die Komplexität spürbar und hat Auswirkungen auf das
Entwickeln, Testen und Simulieren entsprechender Netze. Von jeher große
Bedeutung im Entwicklungsprozess hat
ein komfortabler Netzzugriff der Testund Simulationswerkzeuge – so auch
bei Automotive Ethernet. Allerdings
steht in geswitchten Netzwerken „der
eine Bus“ nicht mehr zur Verfügung, an
dem man sämtliche Signale und Botschaften abgreift oder an den man
seine Test-Botschaften absetzt. Hier
stellt sich die Frage, welche Fähigkeiten
und Eigenschaften eine für aktuelle und
zukünftige Anforderungen gerüstete
Schnittstellen-Hardware mitbringen
muss.
Möglichst rückwirkungsfreies
­Messen
Die Basisanforderungen an eine Schnittstelle für Automotive Ethernet unterscheiden sich zunächst nicht von denen
anderer Kommunikationssysteme: Damit eine entsprechende Hardware gleichermaßen für das Labor wie für Außeneinsätze im Fahrzeug geeignet ist,
sollte sie über ein robustes Gehäuse
sowie über zuverlässige und für viele
Steckzyklen ausgelegte Steckverbinder
verfügen und für einen erweiterten
Temperaturbereich geeignet sein. Die
Software-Werkzeuge benötigen umfangreichen Netzwerkzugriff, das heißt
dass die Schnittstelle sowohl passive
Lesezugriffe als auch aktive Schreibzugriffe beherrschen muss. Wichtig für
sämtliche Aktivitäten sind natürlich
hochgenaue Zeitstempel sowie Synchronisierungsmöglichkeiten mit weiteren Schnittstellen und mit anderen
Bussystemen in Multibus-Umgebungen.
Zudem ist für die Kommunikation der
Hardware mit dem Simulations- oder
Analyse-Werkzeug eine stabile und
Funktionsentwicklung
performante Host-Anbindung erfordervs. Netzwerksicht
lich.
Bei der reinen Funktionsentwicklung
Wie erwähnt, besteht ein geswitchtes Ethernet-Netzwerk aus etlichen
reicht häufig ein TAP aus, da hier der
1:1-Verbindungen (Bild 1), deren VollFokus in der Regel auf einer einzelnen
duplex-Übertragung einen rückwirVerbindung zwischen zwei Netzknoten
kungsfreien Netzzugriff nahezu unmögliegt, zum Beispiel von Steuergerät zu
lich macht. Selbst ein passives Abgreifen
Steuergerät oder Steuergerät zu Switch.
des Datensignals zwischen zwei SwitNeben dem reinen Mithören einzelner
ches oder Steuergeräten mit einem
Verbindungen übernimmt das Softwareidealen, hochohmigen Messsystem am
Werkzeug auch Aufgaben wie die RestNetzwerkkabel nutzt wenig, da sich die
bussimulation und das Hinzufügen von
abgegriffenen Signale so nicht dekozusätzlichen Datenpaketen und Störundieren lassen. Zum Dekodieren ist jegen. Schwieriger gestaltet sich das Anaweils der gegenüberliegende Netzknolysieren von Automotive Ethernet bei
ten der Übertragungsstrecke in der
aufwändigeren Szenarien, wenn EntLage, der die empfangenen Informatiwickler eine Sicht auf das Gesamtsystem
benötigen (Bild 3). Das Augenmerk liegt
onen durch Differenzbildung mit dem
dann auf kompletten Datenpfaden.
eigenen Signal vom Signalgemisch seNeben Gesamtübertragungs- und Durchparieren kann.
Praktisch führt somit kein Weg daran
leitungszeiten in den Switches interesvorbei, eine im Fokus stehende 1:1-Versieren den Anwender Detailinformatiobindung aufzutrennen und zusätzliche
nen, wie zum Beispiel verworfene BotHardware beispielsweise als sogenannschaften und MAC-Adresstabellen. Beten TAP (Test Access Point) einzufügen
nötigt der Anwender gleichzeitig meh(Bild 2). Ein TAP stellt zwei Ethernet Ports
rere Zugänge zum Netz, so fügt er an
und eine Verbindung zum Rechner mit
mehreren Stellen seine Schnittstellen
dem Analyse-Werkzeug bereit, wobei
ein. Handelt es sich bei Letzteren um
verschiedene Betriebsarten eines TAP
diskrete Geräte, ist spätestens jetzt ein
unterscheidbar sind: Für reines MonitoSynchronisationsmechanismus erforderring sind passive TAPs
ausreichend, die die
Daten auf ISO-OSILayer 1, also der physikalischen Ebene durchschleifen. Dadurch ist
der TAP weitestgehend
transparent in Bezug
auf die wesentlichen
Kommunikationseigenschaften. Fehler
beim Übertragen von
Bild 1. Beispiel für ein geswitchtes Ethernet-Netzwerk aus mehreEthernet-Paketen werren 1:1-Verbindungen.
den weitergeleitet und
nicht verworfen. Für
die Zeitsynchronisation im Netzwerk ist
wichtig, dass die
zwangsweise auftretende Durchlaufverzögerung konstant und
minimal ist. Sobald
man aber in das Geschehen eingreifen
und Daten verändern
will, sind aktive TAPs
gefragt. Sie arbeiten –
vergleichbar mit einem
Switch – auf der SicheBild 2. Ein typischer Messaufbau mit Signalabgriff durch Auftrennen der 1:1-Verrungsebene (Layer 2).
bindungen und Durchschleifen durch zeitlich synchronisierte Schnittstellen.
Elektronik automotive Sonderausgabe Ethernet 201617
ENTWICKLUNGSWERKZEUGE
lich, damit alle Schnittstellen auf derselben Zeitbasis arbeiten und die Tests
brauchbare Ergebnisse liefern.
Neben dem Netzwerkzugang stellt
auch die Topologie bei geswitchten
Netzwerken eine Herausforderung dar.
Ein Beispiel aus der Praxis verdeutlicht
die grundlegende Problematik beim
Testen eines einzelnen Steuergeräts:
Der reale Prüfling ist über eine Automotive-Ethernet-Schnittstelle mit dem
Testrechner verbunden, auf dem zur
Restbussimulation zwei virtuelle Steuergeräte laufen. Üblicherweise verfügt
der PC mit dem Simulationswerkzeug
über genau einen TCP/IP-Stack, sodass
beide virtuellen Steuergeräte über den
gemeinsamen Stack nach außen zur
Schnittstelle hin kommunizieren. Der
vom PC erzeugte Datenverkehr entspricht somit keinesfalls einer realen
Situation. Denn das zu testende Steuergerät kann die Botschaften der beiden
simulierten Steuergeräte nicht unterscheiden, da sie unter derselben IP- und
MAC-Adresse agieren. Umgekehrt ist es
nicht in der Lage, die virtuellen Steuergeräte separat zu adressieren. Man
Bild 3. Datenübertragung vom Steuergerät 1 über drei Verbindungen und zwei Switches zum Steuergerät 5.
müsste das Steuergerät eigens modifizieren, nur um testen zu können – eine
höchst ineffiziente Arbeitsweise.
Abhilfe schafft ein spezialisiertes
Werkzeug, das es erlaubt, hinter jedes
simulierte Steuergerät eine eigene TCP/
IP-Stack-Instanz zu legen (Bild 4). Zusammen mit der Schnittstelle kann der
Anwender dann das reale Steuergerät
so stimulieren, dass die simulierte Kommunikation der realen entspricht. Im
weiteren Testverlauf könnte etwa ein
Anwender auf die Idee kommen – wie
er es von CAN gewohnt ist – „mal eben“
eines der simulierten Steuergeräte aus
der Simulation herauszulösen und durch
ein reales Pendant zu ersetzen. Wenn
er das an einem noch freien Ethernet
Port der Schnittstelle anschließt, müsste das doch funktionieren? Mit diesem
Ansatz ignoriert er jedoch die Tatsache,
dass Ethernet-Netze nur 1:1-Verbindungen erlauben. Eine 1:1-Verbindung
existiert in der Testanordnung aber
bereits zwischen dem realen Steuergerät und der Software mit dem verbleibenden simulierten Steuergerät. Weitere Geräte lassen sich in der Praxis nur
durch das Etablieren neuer zusätzlicher
1:1-Verbindungen hinzufügen, wobei
die neuen Netzfragmente mit Hilfe von
Switches an das bestehende Netzwerk
zu koppeln sind. Wenn die Schnittstelle
intern eine Switch-Funktion bereitstellen oder sich dahingehend umkonfigurieren lassen würde, könnte der Anwender seinen Plan umsetzen und das
zweite externe Steuergerät an einen
freien Port anschließen.
Die Summe der Ports ist nicht alles
Bild 4. Restbussimulation mit mehreren TCP/IP Stacks. Im Rahmen der Integration wird das simulierte Steuergerät ECU 2 durch ein reales Steuergerät unter Berücksichtigung der Topologie ersetzt.
18
Elektronik automotive Sonderausgabe Ethernet 2016
Eine leistungsfähige Automotive-Ethernet-Schnittstelle sollte mit zahlreichen
Ports ausgestattet sein. Zwölf
­100BASE-T1-Anschlüsse reichen aus, um
auch vergleichsweise komplexe TestSzenarien umzusetzen. Doch die Anzahl
der Ports allein ist nicht ausschlaggebend, wie oben schon gezeigt wurde. Es
ist wichtig zu verstehen, dass der Wechsel eines Gerätes zwischen Simulation
und realer Welt einer Topologieänderung gleichkommt. Nur mit herkömmlichen Standardkomponenten und -werkzeugen ausgestattet, können solche
eigentlich einfachen Arbeitsschritte mit
erheblichen Herausforderungen verbunden sein. Wie sollte vor diesem Hintergrund nun eine leistungs- und zukunftsfähige Automotive-Ethernet-Schnittstel-
ENTWICKLUNGSWERKZEUGE
le aussehen? Idealerweise entkoppelt
eine solche Schnittstelle die Simulation
von den direkten Ethernet Ports, indem
es PC-seitig einen sogenannten Applikationskanal dazwischen schaltet. Des
Weiteren füllt es die Lücke zwischen
Applikationskanal und 100BASE-T1-Ports
mit einer frei konfigurierbaren Transferfunktion (Bild 4). Eine typische und häufig benötigte Transferfunktion ist etwa
die Funktion eines Switch.
Durch den Einsatz eines FPGA lassen
sich solche Transferfunktionen einfach
auswählen und konfigurieren. Auch
eine zukünftige Erweiterung für neue
Transferfunktionen lässt sich hierüber
realisieren. Die Schnittstelle ist somit
flexibel an die praktischen Herausforderungen der verschiedenen Entwicklungs- und Testphasen anpassbar. Weiterhin ist nahezu jede Netzwerk-Kon­
stellation und -Topologie auf eine funktional identische Testanordnung abbildbar. Bei Bedarf konfiguriert der Anwender mehrere parallele Applikationskanäle sowie Transferfunktionen und
verknüpft diese mit den Ethernet Ports.
Neben Switches kommen als Transferfunktionen unter anderem der „PHY
Bypass“ (Mapping auf Layer 1) oder der
„MAC Bypass“ (Store-and-ForwardPrinzip auf Layer 2) in Frage. Die Schnittstelle erlaubt dem Werkzeug jederzeit
auch vollen Zugriff auf die Ethernet
Ports, entweder direkt oder relativ über
den Applikationskanal. Der native Zugriff auf Ethernet Frames am Bus-Trans­
ceiver zeigt beim Monitoring Probleme
am Bus wie beispielsweise beschädigte
Frames an, die bei herkömmlichen
Switches von der MAC-Schicht herausgefiltert werden. Dies erlaubt aufschlussreiche Analysen über Fragestellungen, was direkt am Bus passiert und
was am Steuergerät ankommt.
Skalierbare Schnittstellen-Familie
Die zuvor beschriebenen Funktionen
und Anforderungen hat Vector in sein
neues Automotive Ethernet Interface
VN5640 integriert (Bild 5). Das Gerät ist
speziell für den Anwendungsfall ausgelegt, auf Netzwerksicht zu simulieren
oder zu messen, und verfügt über insgesamt 16 Ethernet Ports, zwölf für IEEE
100BASE-T1 und vier für Standard-Ethernet-Anbindungen wie 100BASE-TX oder
1000BASE-T. Eine besonders schnelle
Host-Anbindung sorgt für das Weiterleiten der gewaltigen Datenmengen, die
Bild 5. Das Automotive Ethernet Interface VN5640 bietet vielfältige Transferfunktionen, umfangreiche Filtermechanismen und ausreichend Ethernet Ports.
an den Ethernet Ports anfallen können.
Da für die üblichen Test- und Simulationsaufgaben in der Regel nur eine Teilmenge der Ethernet Frames relevant ist,
sind in der VN5640-Hardware vielfältige
Filtermechanismen aktivierbar. Auf Basis
von diversen Protokollen leiten die Filter
nur die wirklich benötigten Ethernet
Frames an den PC weiter und tragen so
zu einer signifikanten Entlastung der
Simulations- und Test-Software bei.
Neben dem üblichen Interface Mode
kann das VN5640 auch ohne PC im
Stand-alone-Modus verwendet werden.
Darüber hinaus ist geplant, dass der
Anwender zukünftig einen Ethernetfähigen Standard-Automotive-Datenlogger anschließen kann. Zusammen
mit dem schon seit geraumer Zeit verfügbaren 2-Port Interface VN5610 bildet
das VN5640 eine skalierbare Automo­
tive-Ethernet-Interface-Familie, die
untereinander und mit dem Test- und
Simulationswerkzeug CANoe von Vector
zusammenarbeitet. Viele neue Funktionen des VN5640 werden zukünftig
auch vom VN5610 unterstützt und nach
einem Treiber-Update verfügbar sein.
Alle Interfaces der Familie sind über
eine gemeinsame Programmierschnittstelle (API) ansprechbar. In Kombination
mit CANoe lassen sich die umfangreichen Konfigurationsmöglichkeiten bequem mit Hilfe von Beschreibungsdateien vornehmen. Dies bietet außerdem
den Vorteil der Austauschbarkeit mit
anderen Abteilungen, Zulieferern und
Kunden. Ferner bietet CANoe Zugriff
auf die erweiterten Statistik- und
Switch-Informationen, wie zum Beispiel
Qualitätsinformationen von Übertragungsstrecken, Inhalte von MAC-Adress­
tabellen oder Queue-Stände von Switches, die Aufschluss über die Auslastung
einzelner Link-Strecken geben.
Um dem weiter steigenden Bedarf
an Bandbreite gerecht zu werden, ar-
beitet die IEEE bereits an einer GigabitVariante von BroadR-Reach (1000BASET1). Durch den flexiblen Aufbau der
Hardware ist das VN5640-Interface für
weitere Physical Layers vorbereitet und
schnell verfügbar. Technologien wie
AVB (Audio Video Bridging) und TSN
(Time Sensitive Networking) werden in
absehbarer Zeit für garantierte WorstCase-Latenzen, priorisierte Datenübertragungen und Zeitsynchronität sorgen.
Diese und sonstige Weiterentwicklungen werden zu gegebener Zeit in Firmware- und Software Updates Berücksichtigung finden. ku
Dipl.-Ing. (FH)
Peter Fellmeth
studierte Technische Informatik mit Schwerpunkt Automatisierungstechnik an der FH
Esslingen. Bei der Vector Informatik GmbH ist er als Gruppenleiter und Produktmanager verantwortlich für die Entwicklung von Produkten im Umfeld von Automotive Ethernet,
J1939 und ISOBUS.
Dipl.-Ing. (FH)
Matthias Schwedt
studierte Nachrichten- und
Kommunikationstechnik mit
dem Schwerpunkt Digitale Signalverarbeitung und Telekommunikation an der Hochschule Offenburg. Bei Vector ist er als Produktmanager im
Bereich Network Interfaces für die Automotive-EthernetInterface-Familie VN5600 verantwortlich.
_0ENOP_Spirig_EK_03.pdf;S: 1;Format:(45.94 x 31.85 mm);25. Jan 2016 14:42:20
Elektronik automotive Sonderausgabe Ethernet 201619