Das bringt Time Sensitive In-Vehicle Networking mit Ethernet AVB

Ethernet Frames oder IP-Pakete lassen sich transparent über unterschiedliche physikalische Medien übertragen, denn Ethernet ist vom Physical Layer abgekoppelt. Somit können Geräte, welche über unterschiedliche Netzwerktypen verbunden sind, problemlos miteinander kommunizieren, wie z.B. ein Handy mit Mobilfunkanbindung und ein Steuergerät mit INICnet-Vernetzung (ISO21806) in einem Auto (über Telematik-Unit bzw. Gateway des Fahrzeuges). IP-Pakete werden vom Sender bis zum Empfänger durchgeroutet.

Aber was ist mit Übertragungszeiten, Latenz, Jitter und verlorenen Paketen? Leider ist das originale Ethernet nicht deterministisch, d.h. es gibt weder Kontrolle wann und wie viele Daten die Geräte senden dürfen noch über welche Route die Pakete übertragen werden. Übertragungszeiten zwischen zwei Geräten variieren ständig und bei Überlastung des Netzwerks können Pakete verloren gehen. Das Verhalten ist inkompatibel mit kritischen Anwendungen, in der geringe Latenz und Zustellung zu gewährleisten sind.

Proprietäre Bus- und Netzwerk-Technologien, welche geringe Latenz und Determinismus anbieten, sind nur bedingt eine Lösung. Der Trend geht in allen Märkten zu standardisierten und offenen Technologien, welche keine Herstellerbindung tragen. Darüber hinaus benötigen Standardtechnologien weder spezielles Know-how noch komplexe und teure Gateways.

Lösung Audio Video Bridging

Die Community hat deshalb die Schwächen von Ethernet seit vielen Jahren untersucht. Über der Zeit sind verschiedene Lösungen zur Verbesserung des Echtzeit-Verhaltens von Ethernet entstanden, eine davon ist AVB/TSN.

Das Thema Audio Video Bridging (AVB) wurde im Jahr 2008 in einer IEEE-Arbeitsgruppe gestartet. Das Ziel war damals, die Übertragung von zeitkritischen Audio- und Video-Daten über Ethernet zu verbessern. Zu dem Begriff AVB gehört nicht nur den Standard IEEE 802.1BA, sondern auch noch die folgenden Standards (Bild 1):

• IEEE 802.1AS für die Zeitsynchronisation
• IEEE 802.1Qav für die Regelung der Übertragung und Zwischenpuffern von Frames in Switches
• IEEE 802.1Qat für die dynamische Bandbreiteallokation für die Audio- und Video-Ströme
• IEEE 1722 Transport-Protokoll
• IEEE 1722.1 für die dynamische Konfiguration AVB-fähiger Netzwerke und Geräte

2011 wurde der Standard fertiggestellt und veröffentlicht. Er kam zunächst zum Einsatz in verschiedensten Multimedia-Anwendungen, und später auch im industriellen Bereich, speziell für die Übertragung von zeitkritischen Kommandos oder Sensordaten. Da das Interesse an AVB für nicht Multimedia-Anwendungen immer grösser war, wurde bei der IEEE die Arbeitsgruppe Time Sensitive Networking (TSN) gestartet. Die Gruppe TSN hat die Standards aus der Gruppe AVB übernommen und adressiert dazu ein deutlich breiteres Spektrum an Anwendungen, in den Bereichen Professional Audio-Video, Industrie, Automobil und Luftfahrt.

Im Bereich Automobil kommen heutzutage immer noch die ursprünglichen AVB-Standards zum Einsatz, teilweise aber schon die in der TSN-Gruppe überarbeiteten Versionen davon. Dieser Artikel behandelt primär die AVB-Standards, welche gleichwertig zu TSN sind.

Zeitsynchronisierung mit gPTP

Generalized Precision Time Protocol (gPTP – IEEE 802.1AS) ist die gemeinsame Basis von allen AVB-fähigen Systemen. Der Zweck ähnelt dem des Network Time Protocol (NTP) aus der Computer-Branche. NTP sorgt dafür, dass die Rechner-Uhren zu einer Referenzzeit synchronisiert werden, und zwar mit einer Genauigkeit von wenigen Millisekunden innerhalb eines lokalen Netzwerks. Solch eine Genauigkeit ist für Rechner und Server absolut ausreichend, für synchrone oder zeitkritische Anwendungen ist es allerdings zu ungenau.

gPTP sorgt für eine viel genauere Zeitbasis in Ethernet-Geräten, in der Regel im Bereich von Mikrosekunden, bestenfalls sogar Nanosekunden. gPTP besteht prinzipiell aus zwei Mechanismen: der Verteilung einer Referenzzeit und der Berechnung der Übertragungszeit (Bild 2).

Die Verteilung der Zeit erfolgt von einem oder mehreren Zeitreferenzknoten (gPTP Master gemäß IEEE Standard) zu einem oder mehreren Clients (gPTP Slaves gemäß IEEE Standard). Ähnlich zum IEEE-1588-2-Step-Verfahren, werden bei gPTP immer zwei Frames nacheinander gesendet: „Sync“ und „Sync Follow-Up“. Anhand der enthaltenen Zeitstempel stellen die Clients ihre lokalen Uhren auf die Referenzzeit zurück, so dass alle Geräte im Netzwerk mit exakt der gleichen Zeitbasis arbeiten.

Eine sehr genaue Zeitbasis ist aber nur dann erreichbar, wenn dazu noch die benötigte Übertragungszeit über das Netzwerk berücksichtigt wird. Dazu erfolgen sogenannte Peer-Delay-Messungen immer paarweise zwischen direkten Nachbarknoten. Die Summe der gemessenen Übertragungszeiten pro Knoten ergibt dann den Peer-Delay-Wert um welchen die gPTP-Zeit korrigiert wird.

IEEE 1722-AVTP: Audio Video Transport Protocol ist das Standard-Transportprotokoll, um Audio/Video-Daten als auch zeitkritische Daten über Ethernet AVB zu übertragen. Es handelt sich dabei um ein schlankes ISO/OSI-Layer2-Protokoll, mit welchem die Geräte über MAC-Adressen adressiert werden. Es besteht somit keinerlei Notwendigkeit, einen vollständigen IP-Stack zu integrieren. Dies trägt dazu bei, die Größe, Kosten und Komplexität von Projekten und Designs zu minimieren.

IEEE 1733-RTP/RTCP: RTP und RTCP (IETF RFC 3550) sind IP-basierende Netzwerkprotokolle für die Übertragung von Audio- und Video-Daten über Ethernet. Sie kommen seit vielen Jahren in sämtlichen industriellen und Consumer-Geräten zum Einsatz, wie zum Beispiel in Videoüberwachungskameras oder InterCom-Geräten. IEEE 1733 ist eine Adaptation von RTP/RTCP für die synchrone Übertragung mit AVB und somit eine IP-basierende Alternative zum IEEE 1722.

Traffic-Shaping

Ein Ethernet-Netzwerk besteht typischerweise aus einer Vielzahl an Endpunkten (Rechner, elektronische Geräte) und Bridges (Switches, Gateways, etc.). Unabhängig vom ausgewählten Transportprotokoll sind die Daten in Ethernet Frames gekapselt, welche vom Sender über mehrere Bridges (Hops) bis zum Empfänger geroutet werden. Die Art und Weise wann die Übertragung der Frames erfolgt, ist nicht deterministisch. Die Bridges innerhalb der Route leiten die Frames schneller oder langsamer weiter (store-forward, cut-through). Bei Netzwerküberlastung erfolgt manchmal eine Zwischenspeicherung der Frames für eine gewisse Zeit. Im schlimmsten Fall können sie sogar verloren gehen.

Industrielle sowie Automobil-Systeme benötigen eine geringe, deterministische Latenz und vor allem eine zuverlässige Übertragung, ohne Gefahr zu laufen, dass Frames verloren gehen. Dafür wird Traffic Shaping (Teil von IEEE 802.1Q - Quality of Service) verwendet. Traffic Shaping definiert Strategien, wie Bridges die Frames je nach Priorität behandeln sollen. Es gibt mehrere Standards für Traffic Shaping, zum Beispiel:

• IEEE 802.1Qav, Forwarding and Queuing Enhancements for Time-Sensitive Streams (FQTSS), auch öfters Credit Base Shaper (CBS) genannt
• IEEE 802.1Qbv, Enhancements for Scheduled Traffic, oft auch Time Aware Shaper (TAS) genannt
• IEEE 802.1Qch, Cyclic Queuing and Forwarding
• IEEE 802.1Qcr, Asynchronous Traffic Shaping

Im Automotive-Bereich kommen überwiegend CBS und TAS zum Einsatz.

Mit dem Credit Based Shaper bekommt jedes Ethernet-Gerät ein Guthaben (Credit), das zum Versenden von Frames verwendet wird. Solange das Guthaben noch positiv ist, darf das Gerät weitersenden. Danach muss es warten, bis das Guthaben sich wieder auffüllt. Diese Strategie ermöglicht eine effiziente Nutzung der Bandbreite. Es gibt keine vordefinierten Slots. Endpunkte, welche Daten unregelmäßig senden müssen, können ihr Guthaben sammeln und auf einmal aufbrauchen. Die Konfiguration eines AVB-Netzwerks mit CBS ist relativ einfach.

Im Vergleich basiert die Strategie des Time Aware Shaper auf einem Timeslot-Modell. Es richtet sich nicht mehr nach der Menge der zu versendenden Daten, sondern an der Häufigkeit der Sendungen. Knoten dürfen nicht mehr beliebig lang senden, aber sie bekommen die Garantie, dass sie sehr regelmäßig senden dürfen. Somit lässt sich eine deutlich geringere und deterministischere Latenz erreichen. Qbv hat allerdings den Nachteil, dass die Netzwerkbandbreite nicht immer effizient verwendet wird. Sollten Endpunkte ihre Slots nicht verwenden, gehen diese Slots und damit Bandbreite verloren.

Interoperabilität mit AVNU

Für die Implementierung von AVB kann sich der System-Architekt verschiedenster, verfügbarer Komponenten bedienen. Je nach Systemanforderungen lassen sich unterschiedliche Untermengen von AVB implementieren. Das ist einerseits hilfreich, um Hardwarekomponenten, aber andererseits verursacht es eventuell Interoperabilitätsprobleme, da Geräte von verschiedenen Lieferanten nicht exakt die gleichen AVB-Features unterstützen. Es kommt erschwerend hinzu, dass IEEE-Standards manchmal von den Ingenieuren unterschiedlich interpretiert werden können.

Die sogenannte Ethernet AVB Functional and Interoperability Specification der AVNU Alliance Autosar definiert im Automobilbereich eine Referenz für die AVB Untermengen und die dazu gehörigen Parameter, welche in jedem Gerät implementiert sein sollen, um Interoperabilität zwischen Lieferanten zu gewährleisten. AVB-fähige Geräte lassen sich extern durch Testhäuser oder intern mit speziellem Testequipment auf AVNU-Kompatibilität testen.

In der Praxis bestehen AVB-fähige Netzwerke aus mehreren Komponenten: Switches, PHYs und Endpunkte. Um die gewünschte Leistung zu erreichen, müssen alle Switches und Endstationen AVB unterstützen. Durch die IEEE-Standards, die AVNU- und OpenAlliance-Spezifikationen sind heute Komponenten wie PHYs und Switches von unterschiedlichen Herstellern sehr gut interoperabel.

Die Implementierung von AVB in den Endpunkten bleibt allerdings noch eine komplexe und langwierige Aufgabe. Die Entwicklung von Systemen erfolgt oft auf Basis von SoCs oder High-End-Mikrocontrollern, in die viel Software zu integrieren ist: ein Echtzeit-Betriebssystem, Autosar und ein AVB-Stack, der oft noch eine Lizensierung benötigt. Eine interessante Alternative dazu sind die AVB-Endpoints, wie z.B. der LAN9360 von Microchip (Bild 3). Dieser ist eine Art intelligenter Ethernet-Controller mit integrierten AVB-Protokollen. AVB wird damit als eine Hardware-basierte Lösung sofort einsetzbar, bei der keine Software-Entwicklung mehr notwendig ist.