AUTOSAR lernt Ethernet

ETHERNET
AUTOSAR lernt Ethernet
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
B
is vor einigen Jahren waren CAN
und LIN die einzigen Bussysteme,
die im Fahrzeug eingesetzt wurden. Der Wunsch nach mehr Bandbreite und gestiegene Anforderungen im
Safety-Umfeld, vor allem im Hinblick
auf X-by-Wire-Systeme, führten zur
Entwicklung und Einführung von Flex-
30
Ray. Im Multimediabereich hat sich für
High-End-Anwendungen zusätzlich der
MOST-Standard etabliert. FlexRay und
MOST sind im Vergleich zu CAN komplexe und teure Bussysteme. Daher
und aufgrund der fehlenden WerkstattInfrastruktur wurde bei der Fahrzeug­
diagnose weiterhin CAN für den exter-
HANSER automotive networks / Special 2013
nen Zugang verwendet. Durch die eingeschränkte Bandbreite von CAN und
die immer umfangreichere Software
stieg die benötigte Zeit für die Steuergeräteprogrammierung schnell dramatisch an. Um dieses Problem zu beheben, wurde vor einigen Jahren mit der
Entwicklung von Diagnostics over Inter© Carl Hanser Verlag, München
Alle Bilder: Vector Informatik GmbH
neue Anwendungen realisieren lassen.
ETHERNET
net Protocol (DoIP) begonnen. Das Protokoll setzt erstmals auf Ethernet als
Netzwerktechnologie im Fahrzeugumfeld und ist in der ISO 13400 standardisiert. 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 Diagnosetester 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 Richtung Ethernet-basierter Vehicle-to-GridAnwendungen. Beim Ladevorgang kommuniziert das Elektro- oder Hybridfahrzeug auf Basis von TCP/IPv6 und über
ein eigenes Smart Charge Communication (SCC)-Protokoll mit der Ladesäule
eines Energieanbieters, um zum Beispiel
Ladeart (AC/DC), Ladezeitpunkt, Ladedauer sowie Tarif- und Zahlungsinformationen auszutauschen.
Die geschirmten Standard-EthernetKabel und die damit verbundenen hohen
Verkabelungskosten verhinderten den
breiten Einsatz der Technologie für fahrzeuginterne Netzwerke. Mit der Einführung der neuen physikalischen Schicht
»
Bild 1: Mögliche Domänenarchitektur zukünftiger Kraftfahrzeuge mit EthernetNetzwerken.
trol Protocol (TCP) und User Datagram
Protocol (UDP) ermöglicht auch den
Übergang von einem daten- zu einem
serviceorientierten Kommunikationsschema. BMW entwickelte das Serialisierungsprotokoll Service Oriented
Middleware over Internet Protocol
(SOME/IP), das unter anderem Remote-Procedure-Calls ausführen kann.
Aufgrund der Architektur von MICROSAR IP
können kundenspezifische Erweiterungen ohne
Probleme integriert werden.
MARC WEBER, Vector
Informatik
BroadR-Reach ist Ethernet nun auch für
die fahrzeuginterne Kommunikation interessant. BroadR-Reach bietet eine Bandbreite von 100 Mbit/s über verdrillte
Zweidraht-Leitungen, also eine im Vergleich zu CAN hundertfach höhere Geschwindigkeit bei gleichbleibenden Verkabelungskosten. Ebenso bietet es zusätzlich noch die Vorteile eines geswitchten Netzwerks. Damit ist beispielsweise
die Realisierung einer Backbone-Architektur möglich (Bild 1). Aber auch Themen wie Audio Video Bridging (AVB),
Netzwerkmanagement und neue Konzepte für Gateway-Steuergeräte stehen
inzwischen im Fokus der Fahrzeughersteller und deren Zulieferer.
Ethernet in Kombination mit dem Internet Protocol (IP), Transmission Conwww.hanser-automotive.de
Dazu passend wurde das Service Discovery (SD)-Protokoll spezifiziert. Über
Service Discovery teilen Steuergeräte
anderen Kommunikationspartnern die
Verfügbarkeit ihrer Services mit. Zusätzlich können Steuergeräte nach Services suchen und sich für deren Events
registrieren.
Ethernet und AUTOSAR
Seit der Version 4.0 ist Ethernet im AUTOSAR-Standard enthalten. Der Ethernet-Kommunikations-Stack ist in der AUTOSAR-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 hingegen unterschiedlich. Während die Interfaces für CAN, LIN und FlexRay direkt
die AUTOSAR Protocol Data Unit (PDU)Schnittstelle umsetzen, gibt das Ethernet Interface Rohdaten an den TCP/IPStack weiter beziehungsweise nimmt
diese entgegen. Das Verarbeiten der IP-,
UDP- und TCP-Protokolle findet im TCP/
IP-Stack statt, der allerdings in AUTOSAR 4.0 nicht vollständig spezifiziert ist.
Hier ist die Verwendung eines CommonOff-The-Shelf TCP/IP-Stacks vorgesehen.
Ein Paradigma der TCP/IP-Protokollfamilie ist das Verwenden von Sockets. Ein Socket ist durch die Kombination von IP-Adresse und Port des
entfernten sowie des lokalen Endknotens eindeutig identifizierbar. Über einen Socket werden paketorientierte
UDP- und verbindungsorientierte TCPNutzdaten vom TCP/IP-Stack an die
Applikation beziehungsweise von der
Applikation an den TCP/IP-Stack übergeben. 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 Adaptor Moduls (SoAd). Dieses stellt den
darüber liegenden Modulen die bekannte PDU-Schnittstelle zur Verfü-
HANSER automotive networks / Special 2013
31
»
ETHERNET
gung. Damit ist der EthernetStack vollständig in die AUTOSAR-Architektur integriert.
Bild 2: Die Konfiguration eines
Ethernet-Stacks erfolgt mit einer
AUTOSAR 4.1-Beschreibungs­
datei.
Ethernet-Stack in
AUTOSAR 4.0
Mit dem in AUTOSAR 4.0 spezifizierten Ethernet-Stack wurde die
Grundlage geschaffen, um PDUs
über Ethernet zu empfangen und
zu versenden. Zusätzlich ist der
Anwendungsfall DoIP berücksichtigt. Die Umsetzung des DoIP-Protokolls ist als Socket Adaptor PlugIn vorgesehen. Des Weiteren unterstützt diese AUTOSAR-Version
das Kalibrieren von Steuergeräten mittels XCP über Ethernet, das Netzwerkmanagement über UDP und bietet eine
Schnittstelle zum Anbinden von AUTOSAR Complex Drivers (Cdd). Das automatisierte Bedaten des Ethernet-Stacks
ist in AUTOSAR 4.0 nur teilweise möglich. Der Anwender kann Ethernet-Netzwerke, -Frames und -PDUs in der AUTOSAR System Description oder im
ECU Extract of System Description abbilden. Eine Vorab-Bedatung der höheren Protokollschichten wie beispielsweise das Festlegen von IP-Adressen
und Ports ist nicht spezifiziert.
Erweiterte EthernetUnterstützung in
AUTOSAR 4.1
Mit der Einführung von fahrzeuginternen Ethernet-Netzwerken entstanden
neue Anforderungen, die ein EthernetStack nach AUTOSAR 4.0 nicht erfüllt.
Das effiziente Übertragen von mehreren PDUs ist zum Beispiel nur sehr
schwer umsetzbar. Daher wurde mit
AUTOSAR 4.1.1 der Ethernet-Stack
massiv überarbeitet:
WW Der TCP/IP-Stack ist nun ein AUTOSAR-Modul.
WW 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.
WW Die Verwendung von virtuellen Netzwerken (VLANs) ist nun möglich.
WW Die Datenübertragung auf PDU-Basis über den Socket Adaptor erfolgt
deutlich effizienter.
32
WW Der Socket Adaptor bietet in der
neuen Version eine generische
Schnittstelle zu den darüber liegenden Modulen.
WW Die Umsetzung des DoIP-Protokolls
wurde aus dem Socket Adaptor
entfernt und in ein separates DoIPModul ausgelagert.
WW Das Service Discovery-Protokoll ist
ebenfalls als neues AUTOSAR-Modul spezifiziert.
Weiterhin nicht Bestandteil von AUTOSAR ist das Protokoll SOME/IP sowie
die Anwendungsfälle SCC und AVB. Die
Beschreibung einer beispielhaften Umsetzung von SOME/IP ist als Ergänzungsdokument zum aktuellen Standard verfügbar.
Als Beschreibungsformat für fahrzeug­
interne Ethernet-Netzwerke wurde in
der Praxis bisher nur FIBEX 4.1 eingesetzt. Dieses ist mittlerweile mit AUTOSAR 4.1.1 harmonisiert. Das heißt, die
beiden Beschreibungsformate sind
zwar nicht identisch, die Inhalte können
aber ohne Informationsverlust von einem ins andere Format transformiert
werden. Damit lässt sich der EthernetStack 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 Anwendungsfälle des Ethernet-Stacks
nicht durch die AUTOSAR-Spezifikationen abgedeckt. Dazu zählt beispielsweise Smart Charge Communication.
Hierfür gibt es ISO- und DIN-Standards,
an deren Erstellung Vector mitgearbei-
HANSER automotive networks / Special 2013
tet hat. Die darin verwendeten Protokolle für das intelligente Laden
benötigen die Hersteller und Zulieferer von Elektro- und Hybridfahrzeugen. Idealerweise sind diese
Protokolle nahtlos in einen AUTOSAR-Ethernet-Stack eingebunden.
Laut Spezifikation ist das Universal
Measurement and Calibration Protocol (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 Gateway auf ein Sub-Ethernet-Netzwerk ist in
der ISO 13400-Spezifikation nicht standardisiert. Allerdings gibt es bereits Lösungskonzepte, die mit verschiedenen
Fahrzeugherstellern erarbeitet wurden.
Der in AUTOSAR definierte Ethernet-Stack ist unter dem Produktnamen
MICROSAR IP als Steuergerätesoftware 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-Projekte lieferbar. Die oben erwähnten Erweiterungen sind ebenso enthalten wie
eine ressourcensparende Implementierung von SOME/IP. Aufgrund der Architektur von MICROSAR IP können kundenspezifische Erweiterungen ohne
Probleme integriert werden.
Ausblick
Mittels AVB werden unter anderem Audio- und Video-Streams zeitsynchron
über Ethernet übertragen. Das dafür benötigte
Transportprotokoll
nach
IEEE 1722 ist bereits von Vector verfügbar. Momentan wird die AVB-Unterstützung weiter ausgebaut, wie zum Beispiel das Einbinden der Zeitsynchronisation durch das Generic Precision
Time Protocol.
© Carl Hanser Verlag, München
ETHERNET
Bild 3: Der AUTOSAR-Ethernet-Stack MICROSAR IP von Vector enthält die AUTOSAR-Module und nützliche Ergänzungen.
Mit der AUTOSAR-Version 4.2.1 gibt
es voraussichtlich noch einige Erweiterungen, die den Ethernet-Stack betreffen. Ein aktuelles Konzept sieht vor, die
Datenserialisierung mittels SOME/IP in
den Standard mit aufzunehmen. Im Zuge
dessen ist auch geplant, die Datenserialisierung für die Sender-Receiver-Kommunikation zu unterstützen. Momentan
ist dies nur für Client-Server-Verbindungen möglich. Ein weiteres Dokument beschreibt die Einführung eines zweiten
Kommunikationsmoduls, das speziell für
das effiziente Versenden und Empfangen 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 verschiedene Netzwerke hinweg. W (oe)
» www.vector.com
Marc Weber, M.Eng. ist bei Vector
Informatik in der Produktlinie Embedded Software für das Produktmanagement des Ethernet-Stacks
verantwortlich.
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 verbesserte 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 Analyse 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-Mappings und ermöglicht, Standardparameter wie beispielsweise Busgeschwindigkeiten, Zeitbasen und Jitter zu definieren. So können Ingenieure viele verschiedene LIN-Netzwerke parametrisieren und die jeweiligen Antwortzeiten
der Frames analysieren. Zusätzlich ermöglicht ein LDF-Interface (LIN De-
www.hanser-automotive.de
scription File) den Import von LIN-Kommunikationsmatrizen. 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-Timinganalyse für verteilte Funktionen
über LIN sowie die Verbindung von LIN
zu CAN, Ethernet- und FlexRay-Netzwerke über Gateways.
Das SymTA/S-FlexRay-Modell unterstü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 getriggerte Kommunikation das Echtzeitverhalten Ende-zu-Ende zu analysieren.
Der automatisierte Import für EthernetNetzwerkbeschreibungen aus AUTOSAR XML 4.x verbessert die Effizienz
der Ethernet-Analyse, da das Modell
nun nicht mehr manuell definiert werden muss.
Sowohl SymTA/S 3.4 als auch der TraceAnalyzer 3.4 bieten Verbesserungen
beim Laden großer Gantt-Charts. Außerdem ist es nun auch möglich,
Der automatisierte Import für Ethernet-Netzwerkbeschreibungen aus
AUTOSAR XML 4.x vereinfacht die
Ethernet-Analyse.
­ ibrary-Lizenzen einzeln auszuchecken
L
und zu definieren, welche Lizenzen
oder welche Funktionalität während der
Laufzeit benötigt werden.
»» www.symtavision.com
HANSER automotive networks / Special 2013
33