18 Automobil ElEktronik 07-08 / 2016 www.automobil-elektronik.de

Bussysteme/Protokolle Tools

Zeitsynchronisation in automotive-Ethernet-netzenVernetzung im Automobil realisieren

Damit sich Ethernet im Automobil auch für zeitkritische Anwendungen nutzen lässt, sind einige Herausforderungen in Sachen Zeitsynchronisation zu meistern. Derzeitige Mög-lichkeiten und Grenzen der Ethernet-Vernetzung im Fahrzeug sowie künftige Lösungen und Verbesserungen beschreibt der folgende Beitrag. Autor: Dipl. Ing. (FH) Bernd Jesse

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-ZeitkonzeptDas 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 Netz-werk verteilt. Davon abgeleitete Sub-Zeit-domänen können sich über verschiedene physikalische Medien hinweg erstrecken. Zum Verteilen der Zeit dienen Time Gate-ways, die die Zeit, ausgehend von jeweils einem Slave Port, über einen oder mehre-re Master Ports zu den Endpunkten (Time Slaves) oder zu weiteren Time Gateways weitergeben (Bild 2). Dabei ist die synchro-

Ethernet hat sich in vielen Anwen-dungen der Automobilelektronik als Netzwerk zur Verbindung von

Steuergeräten fest etabliert. Anwendun-gen wie Fahrerassistenzsysteme (ADAS), die mit Kameras und Radar beziehungs-weise Sensoren zusammenarbeiten, der Bereich Audio- und Video-Streaming, Backbones zum Synchronisieren ver-schiedener physikalischer Domänen sowie das Thema Onboard Data Logging (Bild 1) stellen an das in ihnen eingesetz-te Ethernet-Netzwerk jedoch hohe Echt-zeitanforderungen. Außerdem sind die via Ethernet vernetzten Geräte auch mit anderen physikalischen Systemen, wie CAN und Flexray, zu synchronisieren.

Dem Kommunikationsstandard Ether-net, ursprünglich für die Computerver-netzung und das Büroumfeld entwickelt, fehlt historisch bedingt die für viele tech-nische Anwendungen notwendige Echt-

zeitfähigkeit. Auf Switches basierende Ethernet-Topologien reduzieren zwar Kol-lisionen beim Netzzugriff, ein vollkom-men deterministisches Verhalten lässt sich alleine dadurch jedoch nicht realisieren. Insbesondere die sensible Aufgabe der Zeitsynchronisation erfordert entlang des

Übertragungswegs lückenlose Informati-onen über Laufzeiten und Latenzen, die in Switches und Gateways unvermeidlich entstehen.

Die wesentlichen Methoden zur Zeit-synchronisation im Automobilbereich

Autosar unterstützt Zeitsynchronisation über CAN, Flexray

und Ethernet.Bernd Jesse, Vector Informatik

Automobil ElEktronik 07-08/2016 19www.automobil-elektronik.de

nisierte Zeit um die Verweilzeit (Residence Time) in den Gateways zu korrigieren.

Ethernet-Steuergeräte nach IEEE 802.1AS synchronisierenSeit Autosar 4.2.1 gibt es den „Synchro-nized Time Base Manager“ (StbM), der jeweils busspezifische Zeitbasisgeber (Bus Provider Module) für Flexray, CAN und Ethernet zur Laufzeitumgebung hin abs-trahiert 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-Pro-vidern implementiert, wobei der Ethernet-Bus-Provider das aus der IEEE 802.1 stam-mende „generalized Precision Time Pro-tocol“ (gPTP) verwendet (Bild 3). Um dies in Einklang mit den im Automobil übli-chen Anwendungsfällen zu bringen, waren allerdings diverse Modifikationen, Erweiterungen oder teilweise auch Ein-schränkungen im Rahmen von Autosar erforderlich.

Um die Unterschiede von Ethernet gegenüber CAN und Flexray zu verdeut-lichen, ist es hilfreich, zunächst die wesentlichen Eigenschaften der CAN- und Flexray-Synchronisation zusammenzu-fassen. 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 bein-haltet die zweite Botschaft zusätzlich eine Überlauferkennung, um im Nanosekun-denbereich mögliche Überläufe abzufan-gen. Über einen „Time-Gateway-Synchronization“-Status erkennt die Anwendung, ob sie synchron zur Subdo-main oder synchron zum globalen Zeit-master arbeitet. Daneben gibt es einen Sequence Counter Check und eine CRC-Prüfung.

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 Syn-chronisation der Zeitbasen in den Steuergeräten erfordern. Als wertvolle Hilfe in diesem Szenario gelten Entwicklungstools wie beispielsweise das Test-Tool CANoe sowie die Autosar-Basissoft-ware Microsar von Vector Informatik.

Eck-DatEn

Im Automobil weicht die Implementie-rung jedoch in etlichen Punkten von den Vorgaben gemäß IEEE ab. Während die IEEE-Spezifikation mancherlei dynami-sche Konfigurationen erlaubt, beispiels-weise hinsichtlich der Netztopologie oder des BMCA (Grand Master Auswahl), ist im Automobil vieles statisch vordefiniert. Nur so sind eindeutige Systembeschrei-bungen und optimierte Kommunikations-matrizen erreichbar. Weitere Abweichun-gen finden sich bei der Zeitstempelunter-stützung in Soft- oder Hardware, den (fehlenden) Nutzerdaten oder der Not-wendigkeit, die Fahrzeuge aus Security-Gründen mit VLANs auszustatten.

Erweiterte Switch-Treiber liefern Port-InformationenEine 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 emp-fangenen Botschaft nicht an die darüber liegende Schicht weitergeben. Dies beein-trä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 (Pde-lay_Resp/Pdelay_Resp_Follow_Up) führt, lassen sich diese den einzelnen Kommu-nikationsports nicht mehr zuordnen. Das

Automobilspezifische gPTP-ImplementierungDie Standardmethode zur Zeitsynchroni-sation in einem auf Switches basierenden Ethernet-Netzwerk ist im Standard IEEE 802.1AS beschrieben und umfasst folgen-de drei Kernverfahren:

• Verteilung der synchronisierten Zeit(Sync/Follow_Up),

•Messung der Botschaftslaufzeit (Pdelay) und

• Best Master Clock Algorithmus (BMCA).Verantwortlich für die eigentliche Syn-chronisation ist ein zweistufiges Verfah-ren, bestehend aus einer Sync- sowie einer Follow_Up-Botschaft. Beim Pdelay, han-delt es sich um ein spezielles Protokoll zum Messen der Botschaftslaufzeit zwischenzwei Ports. Außerdem können Steuerge-räte mithilfe des Pdelay detektieren, ob sie Teil eines Netzwerks mit Zeitsynchroni-sation (Time-Aware-System) sind. Überden Best-Master-Clock-Algorithmusermitteln Netzknoten, vorzugsweise indynamisch aufgebauten Netzen, das Gerät mit der besten Systemzeit und erheben es zum Grand Master.

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

TG: Time gatewayTM: Time masterTS: Time slave

Time subdomain

Bussysteme/Protokolle Tools

Bilde

r: Vec

tor In

form

atik

20 Automobil ElEktronik 07-08/2016

Bussysteme/Protokolle Tools

www.automobil-elektronik.de

autorDipl. Ing. (FH) Bernd JesseSenior Produktmanager im Bereich Embedded Software bei Vector In-formatik für die Ethernet-AVB/TSN-Lösung. Er betreut aktiv das Global Time Konzept in Autosar.

infoDIREKt 950ael0816

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. Auto-sar 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 SuppeBeim Anwenden der IEEE 802.1AS im Automobil gibt es noch an einigen weite-ren Stellen Handlungsbedarf. Dazu zäh-len Themen wie (OEM-spezifische) „Nut-zerdaten“, die Unterstützung mehrerer Zeitdomänen oder Redundanz- und Back-up-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 erweiter-te 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 Konfi-guration, dieses Feld auswerten oder nicht.

Mangelware ZeitdomänenDie IEEE 802.1AS stellt derzeit nur eine Zeitdomäne bereit. Automotive-Anwen-dungen benötigen jedoch deutlich mehr

FazitDer Standard IEEE 802.1AS liefert für Ethernet eine gute Referenz zur Zeitsyn-chronisation und eröffnet – bei entspre-chender Implementierung – auch im Info-tainment-Bereich die Nutzung des gPTP-Protokolls nach IEEE-Standard. Beim kommenden TSN-Standard werden spür-bar mehr Automotive-Anforderungen berücksichtigt. Derzeit ist noch nicht ersichtlich, wie umfassend die Neuerun-gen 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, Entwick-ler und Zulieferer ist, ihre Ethernet-Pro-jekte zügig vorantreiben zu können. Dabei sind Entwicklungstools eine wertvolle Hil-fe, beispielsweise das Test-Tool CANoe sowie die Autosar-Basissoftware Microsar von Vector Informatik, die unter anderem auch für spezielle Ethernet-Hardware ver-fü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 synchro-nisierte Zeit zum Beispiel für Audio/Video-Streaming verwenden. (hb)� n

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

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

Zeitdomänen, etwa für die UTC-Zeit, die GPS-Zeit, zur Auswertung sensorspezi-fischer 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 ledig-lich die „0“ als Domain Number erlaubt, alles andere wird von den Knoten igno-riert. 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 defi-nieren.

Backup Master für ausfallsichere SynchronisationBei 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 mindes-tens 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 Synchro-nisations-Timeout stattfindet. Diese und zahlreiche weitere Fragen werden weiter-hin für reichlich Diskussionsstoff in den Standardisierungsgremien sorgen.