Eine hochgenau synchronisierte Zeit im gesamten TSN-Netzwerk stellt die Grundlage für viele weitere Mechanismen dar. In der AVB-Arbeitsgruppe wurde bereits 2011 der Standard IEEE 802.1AS „Generalized Precision Time Protocol“ (gPTP) zur Uhrensynchronisation finalisiert. Damit ist es möglich, über maximal sieben Hops eine Zeitgenauigkeit aller Knoten von ±500 ns zur sogenannten „Grandmaster Clock“ zu erreichen. Dieser zentrale Zeitgeber wird über den Best Master Clock Algorithm (BMCA) bestimmt oder in der Automotive-Industrie üblicherweise statisch vorkonfiguriert. Im Fehlerfall muss der BMCA erneut ausgeführt werden, was einige Sekunden dauern kann. Im statischen Fall wäre gar keine Zeitsynchronisation mehr möglich.
Um künftig gegen einen Ausfall der Grandmaster Clock gewappnet zu sein, führt die TSN-Arbeitsgruppe mit dem Standard IEEE 802.1AS-rev „Timing and Synchronization for Time-Sensitive Applications“ die Möglichkeit ein, gleichzeitig mehrere Domänen mit jeweils unterschiedlichen Zeitgebern zur Zeitsynchronisation zu betreiben. Teilnehmer, die Redundanz in der Zeitsynchronisation benötigen, können somit in mehreren Domänen zur selben Zeit aktiv sein und beim Ausbleiben von Synchronisationsnachrichten des primären Zeitgebers sofort auf die Zeit einer anderen Domäne zugreifen.
Schutz vor fehlerhaften Datenströmen
TSN- und AVB-Datenströme müssen reserviert sein, bevor sie gestartet werden können. Dabei wird auf jedem Knoten, den der Datenstrom passieren soll, geprüft, ob die angeforderte Bandbreite zugesichert werden kann. Der Datenpfad wird nur erfolgreich reserviert, wenn diese Zusage von allen beteiligten Knoten erfolgt ist.
Sowohl der Absender als auch die dazwischen liegenden Knoten stellen mit Hilfe von Traffic Shapers sicher, dass die Datenströme nicht mehr als die reservierte Bandbreite belegen, siehe Bild 2 (a). Sollte allerdings aufgrund eines Fehlerfalls oder einer mutwilligen Manipulation der Sender die vereinbarte Datenrate überschreiten, so könnte dies im Netzwerk zu schwerwiegenden Störungen anderer reservierter Datenströme führen, siehe Bild 2 (b). Aus diesem Grund ist es für Fahrzeuge, die fail-operational sein müssen – also auch bei einem Fehler noch wie vorgesehen funktionieren –, unbedingt notwendig, alle TSN-Datenströme durchgehend zu validieren.
Sollte ein Datenstrom seine vereinbarte Datenrate überschreiten, muss dieser, wie in Bild 2 (c) zu sehen, deaktiviert werden. So wird verhindert, dass der fehlerhafte Datenstrom Auswirkungen auf den Rest des Netzwerks hat. Hierzu wird in der IEEE am Standard 802.1Qci „Per-Stream Filtering and Policing“ gearbeitet, welcher es erlaubt, einzelne AVB- und TSN-Datenströme in ihrer reservierten Bandbreite zu beschränken und ggf. bereits am Dateneingang zu verwerfen. Die Überprüfung muss an dieser Stelle in Hardware stattfinden, da die üblicherweise eingesetzten Mikrocontroller eine so fehlerhaft hohe Datenlast nur schwer in Software abarbeiten können.
Dynamische Konfiguration von TSN-Netzwerken
Die meisten der TSN-Standards benötigen zumindest ein Mindestmaß an Konfiguration. Auch wenn die Automobilhersteller statische Konfigurationen in ihren Fahrzeugnetzen bevorzugen, so bietet TSN mit den Standards IEEE 802.1Qca „Path Control and Reservation“ und IEEE 802.1Qcc „Stream Reservation Protocol (SRP) Enhancements and Performance Improvements“ Möglichkeiten zur dynamischen Konfiguration.
So können mit IEEE 802.1Qca beispielsweise redundante Pfade im Netzwerk ausfindig gemacht und zur Verwendung von nahtloser Redundanz (IEEE 802.1CB) konfiguriert werden. IEEE 802.1Qcc wiederum kann genutzt werden, um zur Laufzeit TSN-Datenströme zu beenden oder neue Ströme aufzusetzen.
Mit diesen Mitteln können TSN-Netzwerke dynamisch an sich ändernde Anforderungen angepasst werden. Sollten zukünftige Fahrzeugarchitekturen exzessiv Service-orientierte Kommunikation nutzen und adaptiv ausgelegt werden, können diese Methoden mittel- bis langfristig auch für die Automobilindustrie interessant werden.
TSN-Support in Hardware
Da viele Mechanismen von TSN auf Echtzeitübertragung und nahtlose Fehlertoleranz abzielen, ist oftmals eine möglichst verzögerungsfreie Bearbeitung der Datenpakete notwendig. Würde man alle kritischen Teile von TSN in Software ausführen, wären die sich ergebenden Verzögerungen zu hoch. Allen voran seien als Beispiele die Filterung eingehender Datenströme und die Funktion des Time-Aware Shaper genannt.
Die Hersteller von Switching Hardware haben dies erkannt und integrieren in ihre Automotive-Produkte Hardware-Unterstützung für genau solche Punkte. Demgegenüber befinden sich die Hersteller von Mikrocontrollern und Systems on Chip (SoCs) in einem größeren Spannungsfeld. Da der MAC-Baustein bei ihnen nur einen kleinen Teil der gesamten Funktionalität ausmacht, wägen diese Hersteller oftmals genau ab, welche Funktion wie umfangreich von der Hardware unterstützt werden muss. Aus Sicht der Automobilindustrie ist Hardware-Unterstützung für das Filtern von Datenströmen und für die Uhrensynchronisation jedoch unerlässlich. Innerhalb der Industrievereinigung AVnu Alliance gibt es bereits eine Arbeitsgruppe, die ein TSN-Profil zugeschnitten auf den Einsatz im Automobil erarbeiten soll. Ebenso wurde innerhalb der OPEN Alliance kürzlich das TC11 ins Leben gerufen. Ziel dieses Komitees ist es, Switch-Konfigurationen für verschiedene Anwendungsfälle im Fahrzeug zu erstellen. Zwischen beiden Gruppen ist eine Abstimmung geplant, um redundante Arbeit oder gar widersprüchliche Empfehlungen zu verhindern.
TSN als flexibler Werkzeugkasten
Ethernet TSN bildet mit seinen bald zehn Teilstandards einen umfangreichen Werkzeugkasten, der für verschiedene Anwendungen spezialisierte Lösungen bereithält. Dabei ist es der TSN-Arbeitsgruppe gelungen, die Standards größtenteils unabhängig voneinander zu gestalten, sodass diese fast beliebig kombiniert werden können, um einfache wie auch fordernde Szenarien zu bedienen (Bild 3). Da immer wieder neue Projekte von der TSN-Arbeitsgruppe gestartet wurden und – wie am vorgeschlagenen Standard 802.1Qcr „Asynchronous Traffic Shaping“ zu sehen – auch noch werden, sind die Fortschritte bei den einzelnen Standards sehr unterschiedlich, wie die Tabelle zeigt. Dies erklärt auch, warum viele Hardware-Anbieter von pre-TSN sprechen, wenn sie beispielsweise bereits den Time-Aware Shaper nach Standard IEEE 802.1Qbv integrieren. Es lässt sich nicht von „dem“ finalen TSN-Standard sprechen. TSN ist der Werkzeugkasten, der weit über geringe Latenzen hinaus für verschiedene Aufgaben passendes Handwerkszeug bietet. Was man mit den Werkzeugen herstellt, bleibt dabei aber dem Anwender überlassen.
Der Autor
Daniel Hopf |
---|
beschäftigt sich bei Continental mit Anforderungen an zukünftige Kommunikationsnetze und untersucht diese speziell auf deren Eignung für echtzeit- und sicherheitskritische Anwendungen. Er studierte Informatik an der Ostbayerischen Technischen Hochschule in Regensburg und erlangte dort seinen Bachelor- und Masterabschluss. |