E T H E R N E T

HANSER automotive networks / Special 201330 © Carl Hanser Verlag, München

B is vor einigen Jahren waren CAN und LIN die einzigen Bussysteme, die im Fahrzeug eingesetzt wur-

den. Der Wunsch nach mehr Bandbrei-te und gestiegene Anforderungen im Safety-Umfeld, vor allem im Hinblick auf X-by-Wire-Systeme, führten zur Entwicklung und Einführung von Flex-

Ray. Im Multimediabereich hat sich für High-End-Anwendungen zusätzlich der MOST-Standard etabliert. FlexRay und MOST sind im Vergleich zu CAN kom-plexe und teure Bussysteme. Daher und aufgrund der fehlenden Werkstatt-Infrastruktur wurde bei der Fahrzeug-diagnose weiterhin CAN für den exter-

nen Zugang verwendet. Durch die ein-geschränkte Bandbreite von CAN und die immer umfangreichere Software stieg die benötigte Zeit für die Steuer-geräteprogrammierung schnell drama-tisch an. Um dieses Problem zu behe-ben, wurde vor einigen Jahren mit der Entwicklung von Diagnostics over Inter- A

lle B

ilder

: Vec

tor

Info

rmat

ik G

mbH

Mit Ethernet hält eine neue und doch altbekannte Netzwerktechnologie Einzug ins

Fahrzeug. Zuerst nur für Diagnoseanwendungen und intelligentes Laden von Elek­

trofahrzeugen verwendet, sind inzwischen fahrzeuginterne Ethernet­Netzwerke im

Einsatz. Dieser Artikel beschreibt Eigenschaften und Vorteile sowie die Besonder­

heiten bei der Integration der Technologie in AUTOSAR. Zum Schluss werden nütz­

liche Erweiterungen für einen AUTOSAR­Ethernet­Stack vorgestellt, mit denen sich

neue Anwendungen realisieren lassen.

AUTOSAR lernt Ethernet

E T H E R N E T

31HANSER automotive networks / Special 2013www.hanser-automotive.de

net Protocol (DoIP) begonnen. Das Pro-tokoll setzt erstmals auf Ethernet als Netzwerktechnologie im Fahrzeugum-feld und ist in der ISO 13400 standardi-siert. Ethernet bietet den Vorteil der gro-ßen Bandbreite und hat sich vor allem in der Büro- und Internet-Welt etabliert. Daher lässt sich ein DoIP-basierter Diag-nosetester beispielsweise einfach in ein Werkstattnetz einbinden. Mit DoIP war der Grundstein für das Verwenden von Ethernet im Fahrzeug gelegt. Als kurze Zeit später das Thema Elektromobilität aufkam, verschob sich der Fokus in Rich-tung Ethernet-basierter Vehicle-to-Grid-Anwendungen. Beim Ladevorgang kom-muniziert das Elektro- oder Hybridfahr-zeug auf Basis von TCP/IPv6 und über ein eigenes Smart Charge Communica-tion (SCC)-Protokoll mit der Ladesäule eines Energieanbieters, um zum Beispiel Ladeart (AC/DC), Ladezeitpunkt, Lade-dauer sowie Tarif- und Zahlungsinforma-tionen auszutauschen.

Die geschirmten Standard-Ethernet-Kabel und die damit verbundenen hohen Verkabelungskosten verhinderten den breiten Einsatz der Technologie für fahr-zeuginterne Netzwerke. Mit der Einfüh-rung der neuen physikalischen Schicht

BroadR-Reach ist Ethernet nun auch für die fahrzeuginterne Kommunikation inte-ressant. BroadR-Reach bietet eine Band-breite von 100 Mbit/s über verdrillte Zweidraht-Leitungen, also eine im Ver-gleich zu CAN hundertfach höhere Ge-schwindigkeit bei gleichbleibenden Ver-kabelungskosten. Ebenso bietet es zu-sätzlich noch die Vorteile eines geswitch-ten Netzwerks. Damit ist beispielsweise die Realisierung einer Backbone-Archi-tektur möglich (Bild 1). Aber auch The-men wie Audio Video Bridging (AVB), Netzwerkmanagement und neue Kon-zepte für Gateway-Steuergeräte stehen inzwischen im Fokus der Fahrzeugher-steller und deren Zulieferer.

Ethernet in Kombination mit dem In-ternet Protocol (IP), Transmission Con-

trol Protocol (TCP) und User Datagram Protocol (UDP) ermöglicht auch den Übergang von einem daten- zu einem serviceorientierten Kommunikations-schema. BMW entwickelte das Seriali-sierungsprotokoll Service Oriented Middleware over Internet Protocol (SOME/IP), das unter anderem Remo-te-Procedure-Calls ausführen kann.

Dazu passend wurde das Service Dis-covery (SD)-Protokoll spezifiziert. Über Service Discovery teilen Steuergeräte anderen Kommunikationspartnern die Verfügbarkeit ihrer Services mit. Zu-sätzlich können Steuergeräte nach Ser-vices suchen und sich für deren Events registrieren.

Ethernet und AUTOSAR

Seit der Version 4.0 ist Ethernet im AU-TOSAR-Standard enthalten. Der Ether-net-Kommunikations-Stack ist in der AU-TOSAR-Architektur parallel zum CAN-, LIN- und FlexRay-Stack angeordnet. Im Vergleich mit diesen weist er allerdings einige Besonderheiten auf – vor allem aufgrund der höheren Protokollschichten

IP, UDP und TCP. Die Module Ethernet Transceiver Driver (EthTrcv und Ethernet Driver (Eth) sind vergleichbar mit denen der anderen Netzwerktechnologien. Das Modul Ethernet Interface (EthIf) ist hin-gegen unterschiedlich. Während die In-terfaces für CAN, LIN und FlexRay direkt die AUTOSAR Protocol Data Unit (PDU)- Schnittstelle umsetzen, gibt das Ether-net Interface Rohdaten an den TCP/IP-Stack weiter beziehungsweise nimmt diese entgegen. Das Verarbeiten der IP-, UDP- und TCP-Protokolle findet im TCP/IP-Stack statt, der allerdings in AUTO-SAR 4.0 nicht vollständig spezifiziert ist. Hier ist die Verwendung eines Common-Off-The-Shelf TCP/IP-Stacks vorgese-hen.

Ein Paradigma der TCP/IP-Proto-kollfamilie ist das Verwenden von So-ckets. Ein Socket ist durch die Kombi-nation von IP-Adresse und Port des entfernten sowie des lokalen Endkno-tens eindeutig identifizierbar. Über ei-nen Socket werden paketorientierte UDP- und verbindungsorientierte TCP-Nutzdaten vom TCP/IP-Stack an die Applikation beziehungsweise von der Applikation an den TCP/IP-Stack über-geben. Dieses Paradigma passt nicht zum PDU-Konzept von AUTOSAR. Die Transformation der Socket-basierten in eine PDU-basierte Kommunikation und umgekehrt ist Aufgabe des Socket Ad-aptor Moduls (SoAd). Dieses stellt den darüber liegenden Modulen die be-kannte PDU-Schnittstelle zur Verfü-

Bild 1: Mögliche Domänenarchitektur zukünftiger Kraftfahrzeuge mit Ethernet-

Netzwerken.

»

Aufgrund der Architektur von MICROSAR IP

können kundenspezifische Erweiterungen ohne

Probleme integriert werden.

MARC WEBER, Vector Informatik

»

E T H E R N E T

HANSER automotive networks / Special 201332 © Carl Hanser Verlag, München

W Der Socket Adaptor bietet in der neuen Version eine generische Schnittstelle zu den darüber liegen-den Modulen.

W Die Umsetzung des DoIP-Protokolls wurde aus dem Socket Adaptor entfernt und in ein separates DoIP-Modul ausgelagert.

W Das Service Discovery-Protokoll ist ebenfalls als neues AUTOSAR-Mo-dul spezifiziert.

Weiterhin nicht Bestandteil von AUTO-SAR ist das Protokoll SOME/IP sowie die Anwendungsfälle SCC und AVB. Die Beschreibung einer beispielhaften Um-setzung von SOME/IP ist als Ergän-zungsdokument zum aktuellen Stan-dard verfügbar.Als Beschreibungsformat für fahrzeug-interne Ethernet-Netzwerke wurde in der Praxis bisher nur FIBEX 4.1 einge-setzt. Dieses ist mittlerweile mit AUTO-SAR 4.1.1 harmonisiert. Das heißt, die beiden Beschreibungsformate sind zwar nicht identisch, die Inhalte können aber ohne Informationsverlust von ei-nem ins andere Format transformiert werden. Damit lässt sich der Ethernet-Stack nach AUTOSAR 4.1.1 zu großen Teilen automatisiert bedaten (Bild 2).

Nützliche Ergänzungen aus der Praxis

Wie bereits erwähnt, sind einige An-wendungsfälle des Ethernet-Stacks nicht durch die AUTOSAR-Spezifikatio-nen abgedeckt. Dazu zählt beispiels-weise Smart Charge Communication. Hierfür gibt es ISO- und DIN-Standards, an deren Erstellung Vector mitgearbei-

tet hat. Die darin verwendeten Pro-tokolle für das intelligente Laden benötigen die Hersteller und Zulie-ferer von Elektro- und Hybridfahr-zeugen. Idealerweise sind diese Protokolle nahtlos in einen AUTO-SAR-Ethernet-Stack eingebunden.Laut Spezifikation ist das Universal Measurement and Calibration Proto-col (XCP) nicht routingfähig. Wird Ethernet für den Fahrzeugzugang

verwendet, ist es wünschenswert, auch alle Steuergeräte, die nicht direkt mit dem Ethernet-Netzwerk verbunden sind, über XCP zu kalibrieren. In Zusammenarbeit mit einem deutschen Fahrzeughersteller aus dem Premium-Segment hat Vector einen Mechanismus entwickelt, der dies ermöglicht.

Das Routen von DoIP über ein Gate-way auf ein Sub-Ethernet-Netzwerk ist in der ISO 13400-Spezifikation nicht stan-dardisiert. Allerdings gibt es bereits Lö-sungskonzepte, die mit verschiedenen Fahrzeugherstellern erarbeitet wurden.

Der in AUTOSAR definierte Ether-net-Stack ist unter dem Produktnamen MICROSAR IP als Steuergerätesoft-ware von Vector verfügbar (Bild 3). Er enthält die in AUTOSAR 4.0.3 und 4.1.1 spezifizierte Funktionalität und ist darü-ber hinaus auch für AUTOSAR 3.x-Pro-jekte lieferbar. Die oben erwähnten Er-weiterungen sind ebenso enthalten wie eine ressourcensparende Implementie-rung von SOME/IP. Aufgrund der Archi-tektur von MICROSAR IP können kun-denspezifische Erweiterungen ohne Probleme integriert werden.

Ausblick

Mittels AVB werden unter anderem Au-dio- und Video-Streams zeitsynchron über Ethernet übertragen. Das dafür be-nötigte Transportprotokoll nach IEEE 1722 ist bereits von Vector verfüg-bar. Momentan wird die AVB-Unterstüt-zung weiter ausgebaut, wie zum Bei-spiel das Einbinden der Zeitsynchroni-sation durch das Generic Precision Time Protocol.

gung. Damit ist der Ethernet-Stack vollständig in die AUTO-SAR-Architektur integriert.

Ethernet­Stack in AUTOSAR 4.0

Mit dem in AUTOSAR 4.0 spezifi-zierten Ethernet-Stack wurde die Grundlage geschaffen, um PDUs über Ethernet zu empfangen und zu versenden. Zusätzlich ist der Anwendungsfall DoIP berücksich-tigt. Die Umsetzung des DoIP-Pro-tokolls ist als Socket Adaptor Plug-In vorgesehen. Des Weiteren un-terstützt diese AUTOSAR-Version das Kalibrieren von Steuergeräten mit-tels XCP über Ethernet, das Netzwerk-management über UDP und bietet eine Schnittstelle zum Anbinden von AUTO-SAR Complex Drivers (Cdd). Das auto-matisierte Bedaten des Ethernet-Stacks ist in AUTOSAR 4.0 nur teilweise mög-lich. Der Anwender kann Ethernet-Netz-werke, -Frames und -PDUs in der AU-TOSAR System Description oder im ECU Extract of System Description ab-bilden. Eine Vorab-Bedatung der höhe-ren Protokollschichten wie beispiels-weise das Festlegen von IP-Adressen und Ports ist nicht spezifiziert.

Erweiterte Ethernet­Unterstützung in AUTOSAR 4.1

Mit der Einführung von fahrzeuginter-nen Ethernet-Netzwerken entstanden neue Anforderungen, die ein Ethernet-Stack nach AUTOSAR 4.0 nicht erfüllt. Das effiziente Übertragen von mehre-ren PDUs ist zum Beispiel nur sehr schwer umsetzbar. Daher wurde mit AUTOSAR 4.1.1 der Ethernet-Stack massiv überarbeitet:

W Der TCP/IP-Stack ist nun ein AUTO-SAR-Modul.

W Neben der Internet Protokoll Version 4 wird auch Version 6 unterstützt. Beide IP-Versionen können sowohl einzeln als auch parallel in einem Steuergerät betrieben werden.

W Die Verwendung von virtuellen Netz-werken (VLANs) ist nun möglich.

W Die Datenübertragung auf PDU-Ba-sis über den Socket Adaptor erfolgt deutlich effizienter.

Bild 2: Die Konfiguration eines

Ethernet-Stacks erfolgt mit einer

AUTOSAR 4.1-Beschreibungs-

datei.

E T H E R N E T

33HANSER automotive networks / Special 2013www.hanser-automotive.de

ist dies nur für Client-Server-Verbindun-gen möglich. Ein weiteres Dokument be-schreibt die Einführung eines zweiten Kommunikationsmoduls, das speziell für das effiziente Versenden und Empfan-gen von serialisierten Daten ausgelegt ist. Weitere Konzepte, die aktuell in der Diskussion sind, befassen sich mit der Vergabe von IP-Adressen und der globa-

len Zeitsynchronisation über verschiede-ne Netzwerke hinweg. W (oe) » www.vector.com

Marc Weber, M.Eng. ist bei Vector Informatik in der Produktlinie Em-bedded Software für das Produkt-management des Ethernet-Stacks verantwortlich.

Mit der AUTOSAR-Version 4.2.1 gibt es voraussichtlich noch einige Erweite-rungen, die den Ethernet-Stack betref-fen. Ein aktuelles Konzept sieht vor, die Datenserialisierung mittels SOME/IP in den Standard mit aufzunehmen. Im Zuge dessen ist auch geplant, die Datenseria-lisierung für die Sender-Receiver-Kom-munikation zu unterstützen. Momentan

Bild 3: Der AUTOSAR-Ethernet-Stack MICROSAR IP von Vector enthält die AUTOSAR-Module und nützliche Ergänzungen.

Import für AUTOSAR XML 4.x mit Ethernet-Support Mit SymTA/S 3.4 unterstützt Symta-vision nun auch das Timing-Design und die Timing-Analyse für LIN sowie ver-besserte Analysemöglichkeiten für FlexRay, Import für AUTOSAR XML 4.x mit Ethernet-Support und schnelleres Laden von Gantt-Charts. Gleichzeitig kündigte Symtavision auch die neue Version von TraceAnalyzer 3.4 an, einer Lösung für die Visualisierung und Analy-se von Timing-Daten aus Messungen und Simulationen.Die neue LIN-Bibliothek zu SymTA/S 3.4 unterstützt System Distribution und Worst-Case-Analyse mit mehreren Scheduling-Tabellen und Frame-Map-pings und ermöglicht, Standardparame-ter wie beispielsweise Busgeschwin-digkeiten, Zeitbasen und Jitter zu defi-nieren. So können Ingenieure viele ver-schiedene LIN-Netzwerke parametri-sieren und die jeweiligen Antwortzeiten der Frames analysieren. Zusätzlich er-möglicht ein LDF-Interface (LIN De-

scription File) den Import von LIN-Kom-munikationsmatrizen. Eine Integration mit den etablierten SymTA/S-Analysen für CAN, Ethernet, FlexRay und auf OSEK oder AUTOSAR basierenden ECUs vereinfacht die Ende-zu-Ende-Ti-minganalyse für verteilte Funktionen über LIN sowie die Verbindung von LIN zu CAN, Ethernet- und FlexRay-Netz-werke über Gateways. Das SymTA/S-FlexRay-Modell unter-stützt nun den FlexRay-2.x-Standard mit Cycle-Multiplexing im dynamischen Segment für System-Distribution und Worst-Case-Analysen und ermöglicht es, für vollsynchronisierte und für ge-triggerte Kommunikation das Echtzeit-verhalten Ende-zu-Ende zu analysieren. Der automatisierte Import für Ethernet-Netzwerkbeschreibungen aus AUTO-SAR XML 4.x verbessert die Effizienz der Ethernet-Analyse, da das Modell nun nicht mehr manuell definiert wer-den muss.

Sowohl SymTA/S 3.4 als auch der Tra-ceAnalyzer 3.4 bieten Verbesserungen beim Laden großer Gantt-Charts. Au-ßerdem ist es nun auch möglich,

Library-Lizenzen einzeln auszuchecken und zu definieren, welche Lizenzen oder welche Funktionalität während der Laufzeit benötigt werden.

» www.symtavision.com

Der automatisierte Import für Ether-

net-Netzwerkbeschreibungen aus

AUTOSAR XML 4.x vereinfacht die

Ethernet-Analyse.