38 Elektronik automotive 4.2012

IP-Kommunikation llll Bussysteme Bussysteme llll IP-Kommunikation

Nach dem Debüt des CAN-Bus-ses in der Mercedes-S-Klasse im Jahr 1991 haben sich die

Bussysteme LIN, MOST und FlexRay im Kraftfahrzeug etabliert. CAN kommt in aktuellen Pkw-Netzwerkarchitektu-ren nach wie vor in allen Domänen (von Powertrain bis Body) zum Einsatz. Der LIN-Bus ist prädestiniert für den einfa-chen und kostengünstigen Datenaus-tausch 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.

Ethernet und IP im Kraftfahrzeug

Motivation für Ethernet �

In der Bürokommunikation, der Auto-matisierungstechnik 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 Diagno-sezugang bewährt. Weitere Einsatzbe-reiche wurden in den letzten Jahren in den automobilen Forschungs- und Ent-wicklungsabteilungen verstärkt disku-tiert, denn die verfügbare, skalierbare Bandbreite und die Flexibilität spra-chen stark dafür. Allerdings fehlte eine für das Kraftfahrzeug geeignete wirtschaftliche Verkabelungstechno-logie.

Haupttreiber für den Ethernet-Ein-satz im Fahrzeug sind aktuell kamera-basierte Fahrerassistenzsysteme. Bei Kameraanwendungen im Fahrzeug kam bisher die Low-Voltage-Differen-tial-Signaling-Technologie (LVDS) zum Einsatz. Die dort in der Regel verwendeten geschirmten Kabel sor-gen zwar für die elektromagnetische Verträglichkeit, sind aber für Bran-chenverhältnisse teuer und in der Ver-legung im Kraftfahrzeug wenig prak-tikabel. 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öf-fentlichungen für den Einsatz im Kraftfahrzeug geeignet ist [1, 2, 3].

Anforderungen an ein IP-Ent- �wicklungswerkzeug

Für das Entwicklungswerkzeug erge-ben sich zunächst die aus bisherigen Bussystemen bekannten Anforderun-gen. Erforderlich ist zunächst eine detaillierte Protokollanalyse mit Sti-mulationsmöglichkeit bis hin zu skriptbasiertem Testen mit automati-scher Erstellung von Testprotokollen. Auch erwartet der Anwender, dass die auf dem Markt bewährte Multi-Bus-Fähigkeit auf Ethernet und IP ausge-weitet wird, um Abhängigkeiten zwi-

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

IP-Kommunikation llll Bussysteme

Elektronik automotive 4.2012 39

schen Ereignissen auf verschiedenen Bussystemen optimal untersuchen zu können. Gegenwärtig interessieren solche Zusammenhänge beispielswei-se zwischen LIN und CAN, zukünftig zwischen CAN und IP.

Der Anwender benötigt bei der Pro-tokollanalyse wie bisher einen einfa-chen, 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 Protokollviel-falt von IP ergeben. Anhand des aktu-ellen Kamerabeispiels und vier weite-ren Einsatzbereichen von IP und Ethernet im Kfz wird nachfolgend dar-gestellt, wie sich diese Messaufgaben aus Sicht der Systemverantwortlichen in der Serienentwicklung stellen und welche besonderen Anforderungen sich daraus für das Entwicklungs-werkzeug ergeben.

Ethernet als Systemnetzwerk �für die Kamera nutzen

Ein kamerabasiertes Fahrerassistenz-system wird bei BMW die erste Seri-enanwendung im Kraftfahrzeug sein, die IP und Ethernet als Systemnetz-werk im Fahrzeug einsetzt [1]. OEMs und Zulieferer nutzen hierfür den Phy-sical Layer BroadR-Reach, um gegen-über der bisher gängigen LVDS-Tech-nologie Gewicht und Kosten einzuspa-ren [1, 4, 5]. BroadR-Reach wird von weiteren Anbietern lizensiert [6].

Ein Kamerasystemnetzwerk ist ex-emplarisch mit möglichen Messpunk-ten in Bild 1 dargestellt. Alternativ

lassen sich alle Ka-meras direkt mit ei-nem Switch verbin-den. Wie bei den bis-her im Kraftfahrzeug verwendeten Bussys-temen muss der Da-tenverkehr an ver-schiedenen Punkten im Netzwerk beob-achtet, analysiert und zeitsynchron vergli-chen 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 mehrka-naliger Abgriff über T-Stücke, der das Systemnetzwerk beim Monitoring möglichst wenig beeinflusst. Zur Va-lidierung der Systemfunktion sollte das T-Stück auch Fehler einfügen kön-nen. Ü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 Zeitsynchronisati-on und Quality of Service (QoS) [4]. Diese sollen durch Protokollerweite-rungen des Audio-Video-Bridging-Standards (AVB) gelöst werden [7]. Nachdem sich die Hersteller hinsicht-lich der Bit-Übertragungsschicht (OSI-Layer 1) praktisch einig sind, wird aus Kosten- und Testgründen auch eine Vereinheitlichung der höheren Schich-ten angestrebt.

Allein aufgrund der bei der Kamera-applikation verwen-deten Protokolle gibt es neue Anforderun-gen an die Mess-Soft-ware, damit beliebige Signale aus der Pay-load der verschiede-nen und durchaus komplexen Protokolle applikationsgerecht präsentiert und mani-puliert werden kön-nen. Bild 2 (nach [7] und Vector) zeigt die für AVB zum Einsatz kommenden Proto-

kolle in den Spalten Audio/Video und Control-Kommunikation. Hinzu kom-men Protokolle zur Bandbreitenreser-vierung und weitere Netzwerk-Ma-nagement-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 Anwendungs-fälle hinzu.

Diagnosezugang im Blickpunkt

Über die Technologie Diagnostics over IP (DoIP) ist es möglich, alle ange-schlossenen Steuergeräte verschiede-ner Bussysteme zentral über einen leistungsfähigen Ethernet-Zugang zu flashen (Bild 3). Die Systementwick-lung 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 ana-lysieren, sondern auch auf IP-Seite. Relevant sind die Protokolle ISO 13400 und IPv4, gegebenenfalls auch IPv6.

Intelligentes Laden

Das intelligente Laden, auch Smart-Charging genannt, geht weit über das einfache Anstecken an die Haushalts-steckdose hinaus. Das zu ladende Elektrofahrzeug ist über eine Ladesta-tion an das Stromnetz (Grid) ange-schlossen. Ladevorgänge starten nicht einfach, sondern melden den Bedarf erst einmal an. Durch die Verzögerung einzelner Ladevorgänge um Bruchtei-le von Minuten lassen sich Überlas-tungen des Grids vermeiden. Weiter

Netzwerktester

ImageProcessor

Node1

Switch1T TNode2 Node3

Node4

Node5

Switch2

Embedded Ethernet System

Ethernet

Bild 1. Zuverlässige Analyse von kamerabasierten Fahrerassis- ltenzsystemen erfordert das Abgreifen des Datenverkehrs an meh-reren 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 Übertragung100-

Base-Tx

IPv4/IPv6

TCP/IPUDP

TCP/IPUDP UDP

IPv4/IPv6

IEEE Ethernet MAC + VLAN (802.1Q)

Automotive Ethernet Physical Layer(z.B. BroadR-Reach)

DoIP

BroadR-Reach

IEEE Ethernet MAC +VLAN (802.1Q)

ISO15118

Part 1 (2) SOME/IP Bonjour DHCPv6DHCP

ICMPv6ICMP

NDPARP

ISO15118Part 3

AVBIEEE1722

802.1ASISO

15118Part 2

Audio/VideoZeitsync.

Diagnose-zugang

ControlKommuni-

kation

Dienst-erkennung

Kon�gurationder

Adressen

Au�ösung der Adresse,Signallisierung etc.

SmartGrid

Bild 2. IP-Protokolle automobiler Anwendungen im OSI-Referenz- lmodell aufgetragen (Spalten links) inklusive Verwaltungsfunktio-nen (Spalten rechts): Sowohl neue Protokolle (rot) als auch aus der Bürokommunikation bekannte (blau) werden verwendet.

Bussysteme llll IP-Kommunikation

40 Elektronik automotive 4.2012

IP-Kommunikation llll Bussysteme

lassen sich angeschlossene Fahrzeuge als Speicher nutzen; die Abrechnung mit dem Stromversorger kann automa-tisiert erfolgen.

Das ermöglicht die Kommunikation zwischen Fahrzeug und Ladestation über Ethernet auf IP-basierten Proto-kollen, deren Standardisierung in der Norm ISO 15118 festgelegt ist. Die La-destation kommuniziert dabei mit dem Grid und dem Fahrzeug. Für den Sys-temverantwortlichen beim Fahrzeug-hersteller ist die Kommunikation des Pkw mit der Ladestation wichtig. Um den Ladeprozess sicherzustellen, ist eine detaillierte Analyse und Validie-rung der Protokolle unumgänglich. Das Entwicklungswerkzeug muss auch die-

se Protokolle unter-stützen (Spalte Smart Grid in Bild 2).

Kalibrieren, Debug-gen und Flashen

Ethernet mit dem Mess- und Kalibrier-protokoll XCP wird in der Entwicklung für das Kalibrieren, Debuggen und Fla-shen der Steuergeräte schon mehrere Jahre genutzt. In der Serie steht aus Kostengrün-den der Ethernet-Zu-gang gar nicht mehr zur Verfügung. Des-

halb wird derzeit über das vorliegende Arbeitsprotokoll, beispielsweise CCP oder XCP on CAN, kalibriert und re-programmiert. Wenn aber in naher Zukunft Ethernet ins Fahrzeug ein-zieht, wäre das Messen und Kalibrie-ren über XCP on Ethernet aufgrund der deutlich höheren Messdatenrate auch in der Serie attraktiv.

WLAN und Car-2-X �

Car-2-X bezeichnet die externe Kom-munikation zwischen Fahrzeugen und Infrastruktur. Die Anwendungen rei-chen von Komfortfunktionen über Verkehrsfluss-Optimierung bis hin zur Erhöhung der Verkehrssicherheit

durch Fahrerassis-tenzsysteme. Die Technologie befin-det sich bereits in der Vorserienent-wicklung und die Standardisierung ist weit fortgeschritten. Sie ist IP-basiert; als Physical Layer wird der Standard IEEE 802.11p ge-nutzt.

Das messtechni-sche Interesse bei Car-2-X-Anwen-dungen dehnt sich aus Sicht der Sys-temverantwortli-chen über die Gren-ze des eigenen Fahrzeugs hinweg auf eine Anzahl von

Fahrzeugen und Roadside-Units (RSUs) im Nahbereich aus. Das zu evaluierende Steuergerät kommuni-ziert nicht nur mit den an Bord befind-lichen Bussystemen, sondern auch über die Luftschnittstelle mit anderen Verkehrsteilnehmern. Das Entwick-lungswerkzeug muss daher auch diese IP-basierten Standards unterstützen. Daneben ergeben sich weitere Anfor-derungen im Hochfrequenzbereich, zum Beispiel WLAN im 5-GHz-Band.

Protokollvielfalt für Anwen- �dungen und Messwerkzeug

In Bild 2 sind exemplarisch die ver-schiedenen, von der Anwendung ab-hängigen Übertragungsschichten und Protokolle zusammengefasst, die das Entwicklungswerkzeug allein auf-grund der bisher behandelten Fälle unterstützen muss. Einige der im Be-reich der Bürokommunikation ver-wendeten Protokolle finden sich hier wieder. Viele davon sind verzichtbar, andere kommen hinzu. Die blau ge-kennzeichneten Protokolle können aus der Bürokommunikation übernommen werden. Jene, die aufgrund der neuen, automobilen Anwendung hinzukom-men, 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ünschens-wert, alle Busdomänen auf einer ge-meinsamen Zeitbasis mit ausreichen-der Genauigkeit darstellen zu kön-nen.

Absicherung �von IP-Serienprojekten

Wie die Betrachtung der obigen An-wendungsfälle zeigt, machen es Kau-salitäts- oder gar Zeitbetrachtungen über mehrere Bussysteme hinweg schwierig bis unmöglich, Standard-Ethernet-Tools aus der Bürokommuni-kation 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 Internet-protokolle. Diese unterscheiden sich je nach Anwendung in Art und Komple-xität genauso deutlich wie die Anfor-derungen an den Physical Layer.

Netzwerktester

Diagnosetester

DiagnoseGateway

CAN ECU

FlexRay ECU

LIN ECU

MOST ECU

Switch/„T”DoIP/Ethernet

EthernetCANLIN

MOSTFlexRay

Bild 3. Bei der Validierung von DoIP an einem Gateway ist die Darstellung des Daten- lverkehrs sowohl auf der DoIP-Seite (links des Gateways) als auch auf allen ange-schlossenen Bussystemen (rechts des Gateways) wichtig. Idealerweise werden alle Botschaften aller Netzwerke auf einer gemeinsamen Zeitbasis abgetragen.

Bild 4. CANoe.IP unterstützt die Entwicklung, Simulation und Test von Embedded-Syste- lmen, die über IP oder Ethernet kommunizieren.

Bussysteme llll IP-Kommunikation IP-Kommunikation llll Bussysteme

Elektronik automotive 4.2012 41

Um die Signalstruktur der Proto-kolle im Entwicklungswerkzeug dar-zustellen und den Embedded Code zu generieren, ist ein geeignetes Enginee-ring-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-For-mat als Datenbankformat nicht mehr aus. Es wäre aus Sicht der Werkzeug-zulieferer hilfreich, wenn sich die OEMs auf ein gemeinsames Enginee-ring-Format einigen könnten. Geeig-nete Kandidaten wären FIBEX 4.0 und die AUTOSAR System Description. Erfahrungen aus anderen Industriebe-reichen zeigen, dass danach von Werk-zeugherstellern zeitnah geeignete Ent-wicklungswerkzeuge für Analyse und Code-Generierung zur Verfügung ge-stellt werden.

Zukünftige �Fahrzeugnetzwerke

CAN wird noch deutlich länger als zehn Jahre im Pkw zu finden sein, al-le anderen hier besprochenen Bussys-teme mindestens zehn Jahre. Dennoch legen die Anwendungen durch steigen-de Anforderungen in Hinsicht auf Bandbreite, Flexibilität und Wirt-schaftlichkeit den Einsatz von IP und Ethernet immer stärker nahe. In den nächsten Jahren werden wie bisher mehrere über Gateways vernetzte Bus-systeme vorzufinden sein – Ethernet und IP kommen einfach noch dazu. Wie bei der Kameraapplikation wird es auch bei zukünftigen IP-Anwen-dungen neue Herausforderungen auf allen Protokollebenen geben, die aber mit geeigneten Entwicklungswerkzeu-gen zu lösen sind.

Ausblick auf IP-Entwicklungs- �werkzeuge

Für den Automotive-Bereich empfeh-len sich nach wie vor dafür konzipier-te Entwicklungswerkzeuge. Diese müssen einerseits alle Protokollebenen unterstützen, sich aber andererseits auch in die branchentypische Werk-zeuglandschaft einpassen. Für die Ab-sicherung 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 der Einführung durch den Werkzeugherstel-ler mit ein.

Basierend auf dem bewährten Simulati-ons- und Testwerk-zeug CANoe von Vector Informatik deckt die Option IP die genannten Anfor-derungen an ein Ethernet-Entwick-lungswerkzeug bereits ab. Durch die vielfältigen Ethernet-spezifischen Funktionen und die Multi-Bus-Fähig-keit kann CANoe.IP helfen, die Ent-wicklungszeit zu reduzieren, wodurch sich wertvolle Ressourcen zielführend applikationsseitig einsetzen lassen (Bild 4). CANoe.IP für die automobi-le Netzwerkentwicklung weist densel-ben 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ög-lichkeiten (Bild 5). Im einfachsten Fall 1 arbeitet es mit beliebigen auf einem Windows-Rechner vorhandenen Netz-werkkarten zusammen. Kommt BroadR-Reach zum Einsatz oder sol-len auch Fehler eingefügt werden, kann als Hardware-Interface zukünf-tig die VN56xx-Familie genutzt wer-den (Fall 2). Dadurch erhöht sich die Zeitsynchronität zwischen den IP-Kanälen und zu anderen Bussystemen erheblich. Ist Echtzeitverhalten gefor-dert, dann kann in Zukunft CANoe.IP in Verbindung mit der Echtzeit-Hard-ware 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

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-deve-lops-automotive-ethernet-transceivers-for-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.

Windows PC

100/1.000 BT

100/1.000 BT

BroadR-Reach

100/1.000 BTBroadR-Reach

Fall 3USB

Fall 2USB

Fall 1GBE

VN89xx

VN56xx

VN56xx

CANoe.IP

Bild 5. CANoe.IP mit skalierbaren Hardware-Interfaces und optio- lnaler Echtzeitunterstützung (Bilder: Vector Informatik)

Dipl.-Ing. Hans-Werner Schaal

studierte Nachrichtentechnik an der Universi-tät Stuttgart und Electrical & Computer Engi-neering an der Oregon State University in Ore-gon, USA. Er ist Business Development Mana-ger bei der Vector Informatik GmbH im Be-reich der Produktlinie Open Networking. Zuvor war er Entwicklungsingenieur, Projektleiter und Produktmanager in verschiedenen Bran-chen im Bereich Testwerkzeuge für mehrere Netzwerk-Technologien.hans-werner.schaal@vector.com