Ethernet hat sich in vielen Anwendungen der Automobilelektronik als Netzwerk zur Verbindung von Steuergeräten fest etabliert. Anwendungen wie Fahrerassistenzsysteme (ADAS), die mit Kameras und Radar beziehungsweise Sensoren zusammenarbeiten, der Bereich Audio- und Video-Streaming, Backbones zum Synchronisieren verschiedener physikalischer Domänen sowie das Thema Onboard Data Logging (Bild 1) stellen an das in ihnen eingesetzte Ethernet-Netzwerk jedoch hohe Echtzeitanforderungen. Außerdem sind die via Ethernet vernetzten Geräte auch mit anderen physikalischen Systemen, wie CAN und Flexray, zu synchronisieren.

Bild 1: In modernen Fahrzeugen lassen sich zahlreiche Elektroniksysteme über Ethernet verbinden.

Bild 1: In modernen Fahrzeugen lassen sich zahlreiche Elektroniksysteme über Ethernet verbinden. Vector Informatik

Eckdaten

Der Einzug von Ethernet in moderne Fahrzeuge mit echtzeitfähigen Anwendungen verlangt von Entwicklern und Systemarchitekten eine neue Herangehensweise, da sich bisherige Konzepte nicht einfach auf Ethernet übertragen lassen und viele Systemfunktionen eine hochgenaue Synchronisation der Zeitbasen in den Steuergeräten erfordern. Als wertvolle Hilfe in diesem Szenario gelten Entwicklungstools wie beispielsweise das Test-Tool CANoe sowie die Autosar-Basissoftware Microsar von Vector Informatik.

Dem Kommunikationsstandard Ethernet, ursprünglich für die Computervernetzung und das Büroumfeld entwickelt, fehlt historisch bedingt die für viele technische Anwendungen notwendige Echtzeitfähigkeit. Auf Switches basierende Ethernet-Topologien reduzieren zwar Kollisionen beim Netzzugriff, ein vollkommen deterministisches Verhalten lässt sich alleine dadurch jedoch nicht realisieren. Insbesondere die sensible Aufgabe der Zeitsynchronisation erfordert entlang des Übertragungswegs lückenlose Informationen über Laufzeiten und Latenzen, die in Switches und Gateways unvermeidlich entstehen.

Diesem Szenario stehen alle Entwickler gegenüber, die technische Prozesse mithilfe von Ethernet regeln und steuern möchten. Dies erklärt, warum verschiedene Standardisierungsgruppen parallel daran arbeiten, Mechanismen zur Zeitsynchronisation einzuführen sowie Ethernet mit Echtzeitfähigkeiten nachzurüsten. Die wesentlichen Methoden zur Zeitsynchronisation im Automobilbereich basieren auf den Standards Autosar 4.2.2, IEEE 802.1AS sowie IEEE 802.1AS-ref, die aus der IEEE Audio/Video Bridging Task Group hervorgegangen ist. Diese wurde inzwischen in Time Sensitive Networking Task Group umbenannt.

Das globale Autosar-Zeitkonzept

Das Konzept von Autosar 4.2.2 sieht einen statisch definierten Global Time Master (GTM) vor, der in der globalen Zeitdomäne als Steuergerät mit der höchsten Genauigkeit die Zeit für das gesamte Netzwerk verteilt. Davon abgeleitete Sub-Zeitdomänen können sich über verschiedene physikalische Medien hinweg erstrecken. Zum Verteilen der Zeit dienen Time Gateways, die die Zeit, ausgehend von jeweils einem Slave Port, über einen oder mehrere Master Ports zu den Endpunkten (Time Slaves) oder zu weiteren Time Gateways weitergeben (Bild 2). Dabei ist die synchronisierte Zeit um die Verweilzeit (Residence Time) in den Gateways zu korrigieren. Alternativ lassen sich auf Basis von Autosar auch eigene autarke Zeitbasen etablieren, die über das jeweilige Gateway mit der aktuellen Zeit „befüllt“ werden.

Bild 2: Das Global-Time-Konzept in Autosar ist für die Bussysteme CAN, FlexRay und Ethernet spezifiziert.

Bild 2: Das Global-Time-Konzept in Autosar ist für die Bussysteme CAN, FlexRay und Ethernet spezifiziert. Originalfassung „AUTOSAR-Spezifikation des Synchronized Time-Base Manager, Release 4.2.1“ (Kapitel 2.2.7 auf Seite 11), bearbeitete Fassung: Vector Informatik.

Wie die Synchronisation im Detail abläuft, hängt vom Typ des Netzwerks ab. So korrigiert der Time Slave bei CAN und Ethernet die empfangene globale Zeitbasis, indem er den Zeitstempel von der Transmitter-Seite mit dem eigenen Empfangs-Zeitstempel vergleicht. Beim Flexray-Bussystem ist der Abgleich einfacher, da es als deterministisches System mit festen Zykluszeiten und in einem streng vordefinierten Zeitraster agiert. Die Zeit ist somit implizit über die Flexray-Uhr gegeben. Während beim CAN-Bus der Zeitstempel immer per Software berechnet wird, erlaubt Ethernet die Berechnung wahlweise in Software oder Hardware. Weiterhin sind für CAN- und Flexray-Bussysteme bis zu 16 Zeitdomänen realisierbar. Für Ethernet hingegen ist eine einzige Zeitdomäne (Global Time Domain) spezifiziert.

Ethernet-Steuergeräte nach IEEE 802.1AS synchronisieren

Seit Autosar 4.2.1 gibt es den „Synchronized Time Base Manager“ (StbM), der jeweils busspezifische Zeitbasisgeber (Bus Provider Module) für Flexray, CAN und Ethernet zur Laufzeitumgebung hin abstrahiert und die „Presentation Time“ für die Applikation zur Verfügung stellt. Die einzelnen Protokolle für den jeweiligen physikalischen Bus sind in den Bus-Providern implementiert, wobei der Ethernet-Bus-Provider das aus der IEEE 802.1 stammende „generalized Precision Time Protocol“ (gPTP) verwendet (Bild 3). Um dies in Einklang mit den im Automobil üblichen Anwendungsfällen zu bringen, waren allerdings diverse Modifikationen, Erweiterungen oder teilweise auch Einschränkungen im Rahmen von Autosar erforderlich.

Bild 3: Vereinfachte Darstellung der Autosar-Softwarearchitektur für das Global-Time-Konzept.

Bild 3: Vereinfachte Darstellung der Autosar-Softwarearchitektur für das Global-Time-Konzept. Vector Informatik

Um die Unterschiede von Ethernet gegenüber CAN und Flexray zu verdeutlichen, ist es hilfreich, zunächst die wesentlichen Eigenschaften der CAN- und Flexray-Synchronisation zusammenzufassen. Beide Bussysteme verfügen über 16 synchronisierte Zeitbasen und optional über bis zu 16 statisch verbundene Offset-Zeitbasen. Beim CAN-Bus erfolgt die Übertragung der Zeitinformation über zwei Botschaften – der Sekundenanteil in der ersten und der Nanosekundenanteil in der zweiten Botschaft. Deshalb beinhaltet die zweite Botschaft zusätzlich eine Überlauferkennung, um im Nanosekundenbereich mögliche Überläufe abzufangen. Über einen „Time-Gateway-Synchronization“-Status erkennt die Anwendung, ob sie synchron zur Subdomain oder synchron zum globalen Zeitmaster arbeitet. Daneben gibt es einen Sequence Counter Check und eine CRC-Prüfung.

Automobilspezifische gPTP-Implementierung

Die Standardmethode zur Zeitsynchronisation in einem auf Switches basierenden Ethernet-Netzwerk ist im Standard IEEE 802.1AS beschrieben und umfasst folgende drei Kernverfahren:

  • Verteilung der synchronisierten Zeit (Sync/Follow_Up),
  • Messung der Botschaftslaufzeit (Pdelay) und
  • Best Master Clock Algorithmus (BMCA).

Verantwortlich für die eigentliche Synchronisation ist ein zweistufiges Verfahren, bestehend aus einer Sync- sowie einer Follow_Up-Botschaft. Beim Pdelay, handelt es sich um ein spezielles Protokoll zum Messen der Botschaftslaufzeit zwischen zwei Ports. Außerdem können Steuergeräte mithilfe des Pdelay detektieren, ob sie Teil eines Netzwerks mit Zeitsynchronisation (Time-Aware-System) sind. Über den Best-Master-Clock-Algorithmus ermitteln Netzknoten, vorzugsweise in dynamisch aufgebauten Netzen, das Gerät mit der besten Systemzeit und erheben es zum Grand Master.

Im Automobil weicht die Implementierung jedoch in etlichen Punkten von den Vorgaben gemäß IEEE ab. Während die IEEE-Spezifikation mancherlei dynamische Konfigurationen erlaubt, beispielsweise hinsichtlich der Netztopologie oder des BMCA (Grand Master Auswahl), ist im Automobil vieles statisch vordefiniert. Nur so sind eindeutige Systembeschreibungen und optimierte Kommunikationsmatrizen erreichbar. Weitere Abweichungen finden sich bei der Zeitstempelunterstützung in Soft- oder Hardware, den (fehlenden) Nutzerdaten oder der Notwendigkeit, die Fahrzeuge aus Security-Gründen mit VLANs auszustatten.

Bild 4: Erhöhung der Robustheit für Safety- und Security-Anwendungen durch Redundanz- und Backup-Konzepte für den Global Time Master.

Bild 4: Erhöhung der Robustheit für Safety- und Security-Anwendungen durch Redundanz- und Backup-Konzepte für den Global Time Master. Vector Informatik

Erweiterte Switch-Treiber liefern Port-Informationen

Eine entscheidende Hürde für eine präzise Zeitsynchronisation via Ethernet besteht derzeit – Stand Autosar 4.2.2 – noch in der beschränkten Switch-Funktionalität von Automotive-Ethernet. Die Switch-Treiber können die Port-Nummer der gerade empfangenen Botschaft nicht an die darüber liegende Schicht weitergeben. Dies beeinträchtigt zum einen das port-spezifische Versenden von Sync-, Follow_Up- und Pdelay-Botschaften, und zum anderen wird der Pdelay-Mechanismus praktisch außer Kraft gesetzt. Da ein ausgehender Pdelay-Request hier zu mehreren Antworten (Pdelay_Resp/Pdelay_Resp_Follow_Up) führt, lassen sich diese den einzelnen Kommunikationsports nicht mehr zuordnen. Das Pdelay liefert somit keine verwertbaren Informationen. Desweiteren erlauben die Switches in der aktuellen Spezifikation kein (separates) port-spezifisches Time Stamping. Da sich die Verzögerungen in den Switches nicht bestimmen lassen, ist keine präzise Zeitkorrektur gegeben. Autosar 4.3 wird die Situation entspannen und mehr Unterstützung für IEEE-802.1AS-Funktionen bringen. Vom Switch-Treiber über den Ethernet-Treiber bis zu den Basissoftwarekomponenten werden durchgehend port-spezifische Switch-Informationen unterstützt, so dass die benötigten Ein- und Ausgangsstempel dann verfügbar sind.

Nutzerdaten: Das Salz in der Suppe

Beim Anwenden der IEEE 802.1AS im Automobil gibt es noch an einigen weiteren Stellen Handlungsbedarf. Dazu zählen Themen wie (OEM-spezifische) „Nutzerdaten“, die Unterstützung mehrerer Zeitdomänen oder Redundanz- und Backup-Strategien. Als Nutzerdaten sind zusätzliche Informationen in den Follow_Up-Botschaften zu verstehen, die der Standard nicht abdeckt, die aber für eine spezielle Anwendung oder Funktionalität unverzichtbar sind – beispielsweise Debugging-Informationen und erweiterte Statusinformationen. Die Lösung besteht darin, in den gPTP-Botschaften weitere Informationen in einem Autosar-spezifischen TLV-Feld (Type Length Value) unterzubringen. Die Time Slaves würden dann, abhängig von ihrer Konfiguration, dieses Feld auswerten oder nicht.

Mangelware Zeitdomänen

Der Standard IEEE 802.1AS liefert für Ethernet eine gute Referenz zur Zeitsynchronisation und eröffnet – bei entsprechender Implementierung – auch im Infotainment-Bereich die Nutzung des gPTP-Protokolls nach IEEE-Standard.

Der Standard IEEE 802.1AS liefert für Ethernet eine gute Referenz zur Zeitsynchronisation und eröffnet – bei entsprechender Implementierung – auch im Infotainment-Bereich die Nutzung des gPTP-Protokolls nach IEEE-Standard. Vector Informatik

Die IEEE 802.1AS stellt derzeit nur eine Zeitdomäne bereit. Automotive-Anwendungen benötigen jedoch deutlich mehr Zeitdomänen, etwa für die UTC-Zeit, die GPS-Zeit, zur Auswertung sensorspezifischer Signale und dergleichen. Deswegen muss die bereits existierende Domain Number im gPTP Message Header für Werte größer Null freigegeben werden. Denn aktuell ist nach IEEE 802.1AS lediglich die „0“ als Domain Number erlaubt, alles andere wird von den Knoten ignoriert. Als Erweiterung der IEEE 802.1AS ist in der aktuellen TSN-Spezifikation (IEEE 802.1AS-ref) zwar mindestens noch eine weitere Zeitdomäne eingeplant, das reicht aber für den Bedarf im Automobil nicht aus. Als Lösung bietet Autosar die Möglichkeit, weitere Zeitdomänen zu definieren.

Backup Master für ausfallsichere Synchronisation

Bei künftigen Fahrzeugarchitekturen und Autosar-Versionen rücken Überlegungen hinsichtlich Safety und Security immer mehr in den Fokus. Dies führt schnell zu der Frage nach einem Backup Master oder allgemein nach Redundanzkonzepten, falls der statisch definierte und einzige Zeitgeber (Global Time Master) einmal ausfällt (Bild 4). Daher bedarf es mindestens eines zweiten Zeitgebers, der als Backup Master stets mitläuft. Der Best-Master-Clock-Algorithmus in der jetzigen Form scheint hierfür keine Lösung zu sein. Er ist relativ langsam und arbeitet auf der Basis der Timeout-Erkennung, so dass Steuergeräte möglicherweise schon in den Zustand des Synchronisations-Timeouts geraten, den es eigentlich zu vermeiden gilt. Vielmehr müssten sich die Master gegenseitig ersetzen, bevor ein Synchronisations-Timeout stattfindet. Diese und zahlreiche weitere Fragen werden weiterhin für reichlich Diskussionsstoff in den Standardisierungsgremien sorgen.

Fazit

Der Standard IEEE 802.1AS liefert für Ethernet eine gute Referenz zur Zeitsynchronisation und eröffnet – bei entsprechender Implementierung – auch im Infotainment-Bereich die Nutzung des gPTP-Protokolls nach IEEE-Standard. Beim kommenden TSN-Standard werden spürbar mehr Automotive-Anforderungen berücksichtigt. Derzeit ist noch nicht ersichtlich, wie umfassend die Neuerungen letztlich sein werden. In jedem Fall ergänzen sich IEEE und Autosar und bewegen sich aufeinander zu. Bedingt durch unterschiedliche Freigabezyklen wird dies jedoch noch geraume Zeit in Anspruch nehmen.

Wichtig für Systemarchitekten, Entwickler und Zulieferer ist, ihre Ethernet-Projekte zügig vorantreiben zu können. Dabei sind Entwicklungstools eine wertvolle Hilfe, beispielsweise das Test-Tool CANoe sowie die Autosar-Basissoftware Microsar von Vector Informatik, die unter anderem auch für spezielle Ethernet-Hardware verfügbar ist. Die Produkte unterstützen wahlweise eine Zeitsynchronisation mit gPTP nach Autosar oder gPTP nach IEEE. Darüber hinaus gibt es auch Funktionen und Software-Lösungen, die die synchronisierte Zeit zum Beispiel für Audio/Video-Streaming verwenden.