ethernet-canfd-automobilelektronik-201508-graphic-0-cmyk-300dpi.jpg

Eine klassische CAN-Nachricht überträgt bis zu acht Nutzdaten-Bytes. Aus Effizienzgründen ist es vorteilhaft, alle acht Byte zu verwenden, um ein möglichst gutes Verhältnis zwischen Nutzdaten und Protokoll-Overhead zu erhalten. Einzelne zu übertragende Datenelemente (Signale) wie beispielsweise eine Raddrehzahl sind aber oftmals kleiner als acht Byte. Daher werden mehrere Signale gemeinsam versendet. Jedes Bit ist kostbar und so wird das Definieren der CAN-Nachrichten mit den jeweils enthaltenen Signalen sehr komplex.

ethernet-canfd-automobilelektronik-201508-graphic-0-cmyk-300dpi.jpg

Vector Informatik

Eine Datenbasis definiert dabei die Kommunikationsmatrix. Für CAN geschieht dies wahlweise in einem der Formate DBC, Fibex oder Autosar System Description. Die Datenbasis (Bild 1) enthält neben den Nachrichten und deren Zusammensetzung auch die dazugehörigen Sende- und Empfangsbeziehungen. Ebenso sind darin die PDUs (Protocol Data Units) definiert – eine Abstraktionsschicht zwischen Signalen und Nachrichten.

CAN FD, der verbesserte CAN-Bus

Für die heutigen Kommunikationsanforderungen reicht die Übertragungsrate von maximal 1 MBit/s auf dem CAN-Bus teilweise nicht mehr aus. Eine Lösung des Bandbreitenproblems ist das Verwenden von CAN mit flexibler Datenrate (CAN FD). Diese verbesserte Version des CAN-Protokolls bietet Übertragungsraten bis zu 8 MBit/s. Zwei Erweiterungen zum klassischen CAN ermöglichen dies.

Bild 1: Eine Datenbasis enthält sowohl System- als auch Datenbeschreibungen.

Bild 1: Eine Datenbasis enthält sowohl System- als auch Datenbeschreibungen.Vector Informatik

Zum einen überträgt das System die Nutzdaten-Byte mit einer höheren Bitrate. Damit die sonstigen Eigenschaften von CAN, beispielsweise die maximale Leitungslänge, möglichst gleich bleiben, erfolgt das Senden der Header und der Trailer einer CAN-Nachricht allerdings mit der normalen Bitrate. Eine CAN-FD-Nachricht enthält bis zu 64 Byte Nutzdaten. Wenn das System diese Nutzdaten mit der achtfachen Bitrate verschickt und 64 Nutzdaten-Bytes sendet, dann ist die Übertragungszeit mit einer klassischen CAN-Nachricht vergleichbar, die acht Nutzdaten-Bytes enthält.

Durch CAN FD erhöht sich die bereits erwähnte Komplexität beim Definieren der Kommunikationsmatrix nochmals deutlich. Um auch in diesem Fall eine effiziente Kommunikation zu erreichen, müssen Netzwerkdesigner die Signale in bis zu achtmal größeren Nachrichten logisch sinnvoll gruppieren. Bei einigen Szenarien besteht außerdem die Anforderung, bereits für CAN definierte PDUs auf CAN FD zu übernehmen. Damit wäre der Vorteil der größeren Nutzdatenlänge verloren. Abhilfe schafft hier der Mechanismus n-PDU-to-Frame-Mapping, der es erlaubt, mehrere PDUs in einer Nachricht zu versenden.

N-PDU-to-Frame-Mapping anhand eines Gateways

Bild 2: Mögliches Einführungsszenario von CAN FD.

Bild 2: Mögliches Einführungsszenario von CAN FD.Vector Informatik

In einem Gateway-Szenario (Bild 2) kann die Bandbreite eines klassischen CAN-Busses nicht mehr ausreichen. Ein gutes Beispiel hierfür ist ein Gateway, bei dem drei CAN-Busse angeschlossen sind, die bereits an der Buslastgrenze arbeiten. An CAN-Bus 3 hängt ein Steuergerät, das viele Daten der anderen beiden Busse benötigt. Das Gateway ist für das Routen dieser Daten zuständig. Wenn das Steuergerät an CAN-Bus 3 auf Grund eines Generationswechsels zusätzlichen Kommunikationsbedarf hat, reicht die Bandbreite von CAN-Bus 3 nicht mehr aus. Daher soll stattdessen CAN FD zum Einsatz kommen. Zusätzlich gibt es noch drei weitere Anforderungen: So gilt es, zur effizienten Busnutzung die kompletten 64 Nutzdaten-Bytes zu nutzen. Außerdem dürfen die bisher definierten PDUs nicht verändert werden, und auch die Komplexität des Gateways darf nicht wesentlich ansteigen. Alle diese Aspekte lassen sich realisieren, indem das Gateway mehrere bereits definierte CAN-PDUs in einer CAN-FD-Nachricht versendet.

Bild 3: Vergleich der Netzwerktopologien von CAN (FD), Flexray und Ethernet.

Bild 3: Vergleich der Netzwerktopologien von CAN (FD), Flexray und Ethernet.Vector Informatik

Bisher ermöglichte der jeweilige CAN-Identifier (CAN ID) die Identifizierung des Inhalts einer Nachricht. Diese Möglichkeit hat der Empfänger der Daten nicht mehr, da eine CAN-FD-Nachricht mehrere PDUs enthält. Eine Lösung wäre, den Inhalt der CAN-FD-Nachricht statisch in einer Datenbasis zu definieren. Im Gegensatz dazu wird beim n-PDU-to-Frame-Mapping in der Datenbasis nur noch festgelegt, welche PDUs potenziell in der CAN-FD-Nachricht enthalten sein können. Welche PDUs das Steuergerät tatsächlich versendet, entscheidet sich zur Laufzeit. Das beschriebene Szenario ist in Bild 2 schematisch dargestellt: Jedes Steuergerät an CAN-Bus 1 und 2 sowie das Gateway selbst sendet eine PDU, die auf dem CAN-FD-Bus übertragen werden soll. Das Gateway füllt die CAN-FD-Nachricht bis zum Versendezeitpunkt mit den PDUs nach und nach auf. Jeder PDU wird ein Header vorangestellt, damit ein Empfänger die einzelnen PDUs aus der Nachricht extrahieren kann. Das Gateway muss also nicht mehr auf die Reihenfolge der PDUs achten und kann sich ein aufwendiges Einhalten des Nachrichtenlayouts sparen. Somit bleiben die Ressourcen-Anforderungen an das Gateway so gering wie möglich.

Das Versenden einer CAN-FD-Nachricht wird durch verschiedene Ereignisse angestoßen, zu denen unter anderem ein voller Sendepuffer der Nachricht oder der Ablauf des für die Nachricht definierten Timeouts gehören. Zudem wird nach Ablauf des für eine PDU definierten Timeouts die Nachricht versendet, in der diese PDU enthalten ist. Außerdem besitzt eine PDU ein zusätzliches Attribut, das nach dem Kopieren der PDU in den Sendepuffer ein sofortiges Senden der Nachricht auslöst.

Bild 4: Funktionsprinzipien von Service-orientierter Kommunikation mittels Service Discovery.

Bild 4: Funktionsprinzipien von Service-orientierter Kommunikation mittels Service Discovery.Vector Informatik

Die Möglichkeit, mehrere PDUs in einer Nachricht zu versenden, ist in Autosar seit Release 4.2.1 definiert. Der Mechanismus ist netzwerkunabhängig im I-PDU-Multiplexer-Modul spezifiziert, damit er neben CAN FD zum Beispiel auch für Flexray oder Ethernet zum Einsatz kommen kann. Neben dem reinen Aufsammeln von PDUs unterstützt das Modul auch die unterschiedlichen Versendebedingungen und zwei unterschiedliche PDU-Header-Formate. Für CAN FD und Flexray kommt hauptsächlich ein 4-Byte-Header zum Einsatz. Auf Ethernet wird meistens ein 8-Byte-Header verwendet.

Ethernet bietet eine wesentlich größere Nutzdatenlänge

Im Vergleich zu CAN bietet Ethernet eine mehr als 185-fache Nutzdatenlänge. Eine klassische Definition von hunderten oder sogar tausenden Signalen innerhalb einer 1500 Bytes langen PDU ist kaum realisierbar. Für Gateway-Anwendungen kann es allerdings vorteilhaft sein, bestehende CAN- oder Flexray-PDUs 1:1 auf Ethernet weiterzuleiten. Das für CAN FD vorgestellte Versenden von mehreren PDUs innerhalb einer Nachricht kann unverändert für Ethernet angewendet werden. Im Gegensatz zu CAN FD und Flexray spezifiziert Autosar für Ethernet zwei gleichwertige Ansätze. Der erste bereits bei CAN FD beschriebene Ansatz ist das n-PDU-to-Frame-Mapping im I-PDU-Multiplexer. Der gleiche PDU-Sammelalgorithmus ist im Socket-Adaptor-Modul spezifiziert, welches für das Anbinden des TCP/IP-Stacks an die restliche Autosar-Architektur zuständig ist. Der Anwender kann beide Ansätze verwenden, wobei der Socket-Adaptor noch zusätzliche Steuerungsmöglichkeiten für Ethernet-basierte Kommunikation anbietet.

Mit Ethernet ändert sich die Vernetzungstopologie

Neben der Nutzdatenlänge unterscheidet sich Ethernet auch bei der Vernetzungstopologie und Adressierung maßgeblich von anderen Netzwerktechnologien (Bild 3). CAN setzt auf eine klassische Bustopologie. Flexray lässt sich physikalisch zwar mit einer Sterntopologie realisieren, verhält sich logisch gesehen aber stets wie ein Bus. Bei beiden Netzwerktechnologien wird eine Nachricht an alle Teilnehmer gesendet. Alle Netzwerkknoten entscheiden selbstständig, ob eine Nachricht für sie relevant ist und weiter verarbeitet wird. Bei CAN geschieht dies anhand der CAN ID, bei Flexray anhand der Slot-ID, wobei in beiden Fällen die ID bereits den Inhalt der Nachricht klassifiziert. Es gibt keine Möglichkeit, eine Nachricht gezielt an nur einen Empfänger zu versenden. Daher sind CAN und Flexray Broadcast-Medien. Ethernet war zu Beginn seiner Erfolgsgeschichte ebenfalls ein Bussystem. Die Verkabelung wurde damals mit Koaxialkabeln und T-Elementen realisiert. Heute ist Ethernet in den allermeisten Fällen ein aktiv geswitchtes Netzwerk mit Baum-Topologie, in dem es auf Grund der Punkt-zu-Punkt-Verbindungen keine Kollisionen gibt.

Eckdaten

CAN FD und Ethernet bieten mit der höheren Nutzdatenlänge neue Möglichkeiten in der Datenübertragung. Sie stellen die Fahrzeughersteller und ihre Zulieferer aber auch vor neue Herausforderungen – unter anderem beim Erstellen der Systembeschreibung. Abhilfe schafft hier das n-PDU-to-Frame-Mapping, das mehrere PDUs in eine CAN-FD- oder Ethernet-Nachricht verpackt. Im Falle von Ethernet erhöhen sich aber nicht nur die Nutzdatenlänge und die zur Verfügung stehende Bandbreite. Eine kleine Revolution im Automotive-Umfeld stellt das geswitchte Netzwerk und die damit verbundene neue Adressierungsart dar. Neue Mechanismen zur Datenverteilung sind notwendig. Darauf aufbauend wird mittels Service-orientierter Kommunikation der Datenaustausch dynamischer. Autosar 4.2.1 unterstützt bereits alle vorgestellten Mechanismen und erleichtert somit das Umsetzen der neuen Kommunikationsparadigmen. Am Markt sind bereits Basissoftware-Implementierungen dieser Autosar-Version verfügbar. Ein Beispiel hierfür ist Microsar von Vector. Ebenso ermöglichen Werkzeuge wie CANoe das komfortable Analysieren und Testen von CAN-FD- und Ethernet-Netzwerken.

Jeder Ethernet-Knoten hat eine MAC-Adresse, die zum eindeutigen Adressieren im Netzwerk dient. Ein Knoten verarbeitet eine Nachricht, wenn seine MAC-Adresse als Ziel angegeben ist. Daher muss der Sender den Empfänger kennen und die Zieladresse in der Nachricht entsprechend eintragen. Diese 1:1 Kommunikationsbeziehung verwendet eine sogenannte Unicast-Adressierung. Wird eine Unicast-adressierte Nachricht an alle Netzwerkknoten versendet, verarbeitet dennoch nur ein Empfänger das Paket; alle anderen verwerfen es. Um ein unnötiges Fluten des Netzwerks zu verhindern, kommt ein aktives Netzwerk-Koppelelement zum Einsatz: der Switch. Ein Switch leitet Nachrichten nach einer kurzen Einlernphase nur an die Verbindung weiter, an der das adressierte Ziel zu erreichen ist. Dies ermöglicht eine effiziente Nutzung der zur Verfügung stehenden Bandbreite. Außerdem ermöglicht ein Switch, dass zur selben Zeit mehrere Unicast-adressierte Nachrichten parallel im Netzwerk versendet werden können. Bild 3 zeigt als Beispiel ein Ethernet-Netzwerk mit zwei Switches – einer im Steuergerät ganz oben im Bild, der zweite im unbeschrifteten Steuergerät. Farblich markiert sind parallele Kommunikationspfade durch das Netzwerk, die sich gegenseitig nicht beeinflussen. Auf allen drei Verbindungen können maximal 100 Mbit/s full-duplex übertragen werden. Dadurch multipliziert sich die Bandbreite von 100 Mbit/s mit der Anzahl der parallelen Kommunikationspfade. Ethernet bietet auch 1:n-Kommunikation per Multicast und 1:alle-Kommunikation per Broadcast. Wenn man diese Adressierungsarten ungeschickt einsetzt, gehen die beschriebenen Vorteile von Ethernet verloren.

Im Falle von Unicast-Adressierung wandert die Intelligenz im Netzwerk vom Empfänger in den Sender. Der Sender muss wissen, welche Empfänger im Netzwerk an welchen Daten beziehungsweise PDUs interessiert sind, und er muss die Nachrichten mittels n-PDU-to-Frame-Mapping entsprechend zusammensetzen. Dabei können PDUs oder Nachrichten durchaus mehrfach versendet werden, wenn es mehrere Empfänger für die gleichen PDUs gibt. Dieser Empfänger-spezifische Daten Fan-Out ist in Autosar am einfachsten mit dem Socket-Adaptor realisierbar.

Neues Kommunikationsparadigma: service-orientierte Kommunikation

Die Eigenschaften von Ethernet sowie der Wunsch der Fahrzeughersteller nach mehr Flexibilität und Beherrschbarkeit der Komplexität bei der Vernetzung führten zur Einführung von service-orientierter Kommunikation im Automotive-Umfeld. Dieses aus der Internet-Welt bekannte Kommunikationsparadigma wurde auf die Fahrzeugvernetzung übertragen. Allerdings kommen spezifische, für den Automotive-Anwendungsfall optimierte Protokolle zum Einsatz: Service Discovery (SD) und Scalable Service-oriented Middleware over Internet Protocol (SOME/IP). Bisher wurde in der Fahrzeugvernetzung von Sender und Empfänger gesprochen. Bei Service-orientierter Kommunikation gibt es ein Steuergerät, das einen Dienst (Service) anbietet – den Server – und Steuergeräte, die diesen Dienst verwenden – die Clients.

Über das Service-Discovery-Protokoll geben die Server zur Laufzeit bekannt, welche Services sie anbieten und wie diese angesprochen werden. Clients rufen Methoden des Servers auf (Remote Procedure Calls) oder registrieren sich beim Server, um nachfolgend automatisch Datenaktualisierungen zu erhalten. Im letzteren Fall stellt der Server bestimmte Datenelemente – sogenannte Events – bereit und verschickt deren Wert an alle registrierten Clients. Zu welchem Zeitpunkt die Datenaktualisierungen versendet werden entscheidet die Applikation des Servers. Durch das n-PDU-to-Frame-Mapping ist ein Versenden mehrerer Events innerhalb einer Nachricht möglich. Bild 4 stellt die beiden Prinzipien der service-orientierten Kommunikation grafisch dar.

Bei Methodenaufrufen und Datenaktualisierungen kann die Länge der zu übertragenden Daten stark variieren. Das Unterstützen dieser variablen Datenlänge ist ein Hauptmerkmal von SOME/IP. Es serialisiert strukturierte und komplexe Anwendungsdaten, so dass die restliche Basissoftware eines Steuergeräts sich nur noch um das Versenden beziehungsweise Empfangen eines Bytestroms kümmern muss. Daher wird das exakte Nachrichtenlayout nicht mehr in einer Datenbasis definiert.

Autosar unterstützt SD und SOME/IP vollständig. Auf Grund der Plattformunabhängigkeit von SD und SOME/IP kommen die Protokolle auch beim Datenaustausch zwischen Autosar-Steuergeräten und anderen Plattformen zum Einsatz.

M.Eng. Marc Weber

ist bei Vector Informatik in der Produktlinie Embedded Software für das Produktmanagement des Ethernet-Stacks verantwortlich.

(av)

Sie möchten gerne weiterlesen?

Unternehmen

Vector Informatik GmbH

Ingersheimer Str. 24
70499 Stuttgart
Germany