Automotive Ethernet: Trends und Herausforderungen

Was tut sich im Bereich Automotive Ethernet? Serviceorientierte Architekturen () dienen in der IT-Industrie bereits seit Jahren dazu, verteilte Systeme zu beschreiben und zu strukturieren. Serviceorientiertes Design gewinnt aber auch in der Automobilindustrie massiv an Bedeutung. Mit einer SOA entsteht eine durch klar definierte Schnittstellen (Interfaces) charakterisierte Servicelandschaft (Bild 1). Diese Schnittstellen sind idealerweise sowohl syntaktisch als auch semantisch korrekt beschrieben.

Bild 1: Serviceorientierte Architektur und Serviceverteilung Vector Informatik

Außerdem sind in einer SOA die Softwarekomponenten über einen „Service-Bus“ als Middleware miteinander verbunden. Die Middleware dient als Vermittler zwischen den zwei Rollen eines Services: Dem Anbieter (Service-Provider) und den Konsumenten des Services (Service-Consumer). Die SOA bietet eine lose Kopplung zwischen den Service-Rollen innerhalb eines Systems. Gegenüber monolithischen Softwarearchitekturen hat sie dadurch eine höhere Flexibilität. Zwei weitere positive Aspekte sind eine größere Wiederverwendbarkeit sowie eine bessere Integrationsfähigkeit neuer Servicekomponenten. Die Middleware regelt die Kommunikation zwischen Service-Provider und Service-Consumer sowie den Kommunikationsaufbau. Ebenso definiert die Middleware in der Regel auch das Serialisieren von Daten im Ethernet-Frame. Der Serialisierer legt fest, wie die Daten in einen seriellen Bitstrom umgewandelt und auf der Empfangsseite wieder de-serialisiert werden.

Heute existieren verschiedene Beschreibungssprachen für Schnittstellen, sogenannte Interface-Description-Languages (). Diese weisen typischerweise technologieunabhängige Anteile als formale Beschreibung eines Services auf. Zusätzlich können sie auch protokollspezifische Anteile tragen. Technologieunabhängige Eigenschaften sind beispielsweise verfügbare Methoden, Felder und Events, inklusive der verwendeten Datentypen. Als technologieabhängige Eigenschaft hingegen kann das middleware-spezifische Startup-Verhalten angesehen werden. Dazu zählen die „Service-Discovery“ () sowie das Verwenden von Datenserialisierung und protokollspezifischen Bezeichnern (Englisch: Identifier, ID). IDLs eignen sich besonders gut für das formale Beschreiben einzelner Schnittstellen und die automatische Codegenerierung. Sie liegen meist in einer hierarchisch strukturierten Textdatei vor.

Für das Design einer vollständigen SOA sind Textdateien aber eher ungeeignet. Daher setzen sich verstärkt modellbasierte Designwerkzeuge durch. Eine Stärke der Modellierung ist die zentrale Datenverwaltung und dadurch ein drastisch reduzierter Pflegeaufwand. Modellbasiertes Design garantiert darüber hinaus, dass die Daten zum Designzeitpunkt formal korrekt sind. Die klare Definition erlaubt es außerdem, die Services zu strukturieren. Dazu kommen bei größeren Systemen in der Regel Schichtenarchitekturen zum Einsatz, welche die Abhängigkeiten von Services verständlich machen und klare Designregeln darstellen. Bauen Services aufeinander auf, wird das notwendige Design hierfür „Service-Choreografie“ genannt. In einem modellgetriebenen Designentwurf lässt sich auf Basis einer Servicemodellierung die Datenkommunikation teilweise ableiten. Ebenso wird die Komplexität durch modellbasiertes Design deutlich besser beherrscht, als im IDL-basierten Ansatz.

Der Einsatz einer SOA erlaubt grundsätzlich den dynamischen Aufbau von Kommunikationsbeziehungen zur Laufzeit. Allerdings ist in aktuellen Automotive-Systemen, welche bereits eine SOA einsetzen, die Service-Kommunikation häufig aufgrund der limitierten Ressourcen noch statisch ausgelegt. Grundsätzlich entsteht durch den Einsatz einer Middleware die Verbindung zwischen Service-Provider und Service-Consumer zur Laufzeit – und nicht wie bisher zur Design-Zeit des Systems. In Zukunft ist insbesondere bei Systemen mit leistungsfähiger Hardware davon auszugehen, dass vorrangig eine volldynamische Servicekommunikation stattfindet. Vor allem Infotainment- und Fahrerassistenzsysteme treiben diesen Trend voran. Auch die Außenkommunikation mit Online-Kartendiensten oder OTA-Updates (über die Luftschnittstelle) unterstützt diesen Trend. Servicekommunikation erfordert auf Netzwerkebene einen wesentlich größeren Anteil an Protokollinformationen als ein signalbasierter Ansatz. Durch die benötigte Bandbreite kommt daher hauptsächlich Ethernet als Netzwerktechnologie im Fahrzeug in Frage.

Automotive Ethernet in POSIX-basierten Steuergeräten

Serviceorientierte Kommunikation sowie sicherheitsrelevanter und deterministischer Ethernet-Verkehr verschmelzen in zukünftigen Fahrzeugplattformen zu komplexen Systemen. Vector Informatik

Das im vorherigen Abschnitt beschriebene Modellieren von serviceorientierten E/E-Architekturen und den darunter liegenden Ethernet-Netzwerken betrifft heute bereits viele Steuergeräte in unterschiedlichen Leistungsklassen. Das Spektrum reicht von intelligenten Sensoren, wie beispielsweise Kamera-, Radar- und Lidar-Systemen bis hin zu zentralen Hochleistungsrechnern, welche die Sensorfusion und die übergeordneten Fahrerassistenzapplikationen realisieren. Steuergeräte in den unteren und mittleren Leistungsklassen basieren häufig auf einer klassischen Autosar-Softwarearchitektur. Für Hochleistungssteuergeräte sind allerdings andere Betriebssysteme notwendig. Gefordert ist einerseits eine Unterstützung der entsprechenden Hardwarebeschleuniger, beispielsweise von Grafikeinheiten. Andererseits ist eine erhöhte Flexibilität bezüglich Applikationshandling und Datenaktualisierung gefragt. Daher kommt in diesem Bereich meistens ein POSIX-basiertes Betriebssystem zum Einsatz. Zu den im Automotive-Umfeld bekanntesten Softwarelösungen zählen Linux – für sicherheitskritische Anwendungen ist bei Linux auch ein Hypervisor wie beispielsweise Pike-OS von Sysgo erforderlich – sowie Integrity von Green Hills Software und QNX.. Diese Betriebssysteme bieten jedoch keine integrierte Unterstützung von Automotive Ethernet.

Um den Automotive-Anforderungen gerecht zu werden, wurden für den Einsatz im Fahrzeug einige spezifische Protokolle auf Basis von Ethernet und TCP/IP definiert. Dazu zählen Scalable Service-Oriented Middleware over IP (SOME/IP) für eine effiziente und serviceorientierte Kommunikation, Diagnostic Communication over IP () für die Fahrzeugdiagnose, User Datagram Protocol basiertes Netzwerkmanagement (UDPNM), Universal Measurement and Calibration Protocol () für Mess- und Kalibieraufgaben sowie eine Zeitsynchronisation nach IEEE 802.1AS. [visbs1] Im Gegensatz zu Classic unterstützen heutige POSIX-Systeme diese Protokolle nicht nativ, erlauben aber eine nachträgliche Integration.

Bild 2: Einsatz von Autosar-Classic-Modulen in Steuergeräten mit POSIX-Betriebssystem Vector Informatik

Eine Möglichkeit ist das Ausführen von bewährten Autosar-Classic-Modulen in einem POSIX-Prozess (Bild 2). In Classic greifen SOME/IP-SD, DoIP, UDPNM, XCP sowie die klassische Signal- und PDU-basierte Kommunikation (: Protocol Data Unit) nicht direkt auf die Autosar TCP/IP-Sockets zu, da diese vom Socket Adaptor Module gekapselt werden. Verwendet der Socket Adaptor jedoch Berkeley-Sockets (BSDs) anstelle von Autosar-Sockets, kann dieses Modul – und damit auch die erwähnten automotive-spezifischen Protokolle – innerhalb eines POSIX-Prozesses ausgeführt werden.

Geht man noch einen Schritt weiter und emuliert zudem das Autosar-Betriebssystem, ist sogar der Einsatz der Laufzeitumgebung () und des damit verbundenen SOME/IP-Transformers innerhalb eines Prozesses möglich. Schicht-2-Protokolle wie beispielsweise die erwähnte Zeitsynchronisation und das Audio/Video-Transportprotokoll () nach IEEE 1722, müssen separat betrachtet werden. Da diese nicht auf TCP/IP-Kommunikation basieren, sind die dafür verwendeten BSD-Sockets in einem speziellen Modus zu öffnen, der den Zugriff auf den gesamten Ethernet-Frame erlaubt. Ein angepasster Ethernet-Treiber und die entsprechenden Autosar-Classic-Module erlauben damit das Realisieren und Verwenden der automotive-spezifischen Schicht-2-Protokolle in einem POSIX-Prozess.

Eine zweite Möglichkeit ist das Verwenden von Autosar Adaptive – eine für POSIX-Betriebssysteme standardisierte Laufzeitumgebung, die zukünftig für viele innovative Automotive-Anwendungen zum Einsatz kommt. Autosar Adaptive stellt volldynamischen POSIX-Applikationen automotive-spezifische Erweiterungen zur Verfügung. Im Bereich der Ethernet-Kommunikation sind dies momentan SOME/IP und DoIP. Aktuell wird bereits an der Unterstützung weiterer Protokolle gearbeitet. Für TCP/IP-basierte Kommunikation kommen dabei ebenfalls die BSD-Sockets des POSIX-Betriebssystems zum Einsatz, was eine einfache Integration ermöglicht. Für die Unterstützung der Schicht-2-Protokolle im Rahmen von Time-Sensitive Networking () sind gegebenenfalls Betriebssystem-spezifische Anpassungen in Autosar Adaptive notwendig, da einige benötigte Zusatzinformationen über die Standard-POSIX-Schnittstellen nicht zur Verfügung stehen.

Welche der vorgestellten Varianten für ein Steuergeräteprojekt am besten geeignet ist, hängt von verschiedenen Faktoren ab. Kann beispielsweise auf bestehende Autosar-Softwarekomponenten (SWCs) oder Diagnose-Implementierungen zurückgegriffen werden, bietet sich der Einsatz von klassischen Autosar-Modulen unter POSIX an. Wird dagegen die volle Flexibilität von nativen POSIX-Anwendungen benötigt, ist Autosar Adaptive empfehlenswert.

Zuverlässige Kommunikation mittels Time-Sensitive Networking (TSN)

Bild 3: TSN erweitert Automotive-Ethernet für zeitkritische Daten um die Themen Skalierbarkeit, Zuverlässigkeit sowie um Timing-Garantien. Vector Informatik

Im Fahrzeug ist Echtzeitfähigkeit für bestimmte Anwendungen essenziell. Um diese sicherzustellen, werden Mechanismen benötigt, die direkt auf Hardware-Ressourcen im Ethernet-Controller zugreifen. TSN bietet die Möglichkeit, ein skalierbares Ethernet-Netzwerk aufzubauen. Dazu werden verschiedene Nachrichtenklassen hinsichtlich ihrer Verfügbarkeit skaliert und gemäß ihrer Latenz und Priorität kategorisiert. Jede Nachrichtenklasse erhält dabei eine entsprechend zugesicherte Bandbreite. Ebenso werden redundante Ethernet-Systeme unterstützt und Sicherheitskriterien für einen stabilen Datenaustausch festgelegt.

Im Rahmen der IEEE „Audio/Video Bridging Task Group“ erfolgte die Definition diesbezüglicher Mechanismen und Protokolle, um einen Datenaustausch mit niedrigen Latenzen sicherzustellen, sowie Anwendungen zeitlich miteinander zu synchronisieren. Audio/Video Bridging () zielt im Wesentlichen auf Infotainment-Anwendungen ab. Die breite Einführung von Fahrerassistenzsystemen hingegen fordert noch striktere Regeln in Bezug auf das Sende- und Empfangsverhalten. Deshalb führt die IEEE „Time-Sensitive Networking Task Group“ die Arbeit der „Audio/Video Bridging Task Group“ fort. Der Fokus dieser Arbeitsgruppe liegt auf deterministischer Datenübertragung, einer weiteren Latenzreduzierung und auf der robusten und sicheren Übertragung in Ethernet-Netzwerken (Bild 3).

Grundvoraussetzung für die Stabilität eines Ethernet-Netzwerks mit zeitlicher Bewertung von Daten ist die Zeitsynchronisation durch gemäß IEEE 802.1AS („Timing and Synchronization for Time-Sensitive Applications“). Dabei sendet ein Grand-Master eine globale Zeit an alle zeitsensitiven Steuergeräte. Zudem wird die mittlere Laufzeit eines definierten Ethernet-Frames gemessen und beim Berechnen der synchronisierten Zeit berücksichtigt. Dadurch können sich alle zeitsensitiven Steuergeräte mit einer Abweichung von maximal einer Mikrosekunde synchronisieren.

Bild 4: Die TSN-Bridge leitet nur die bei ihr registrierten Datenströme weiter. Vector Informatik

Diese synchronisierte Zeit wird nun beim Sender und Empfänger den einzelnen Datenpaketen zugeordnet. Mittels eines bestimmten Sendeverfahrens (Shaper) werden die Daten an die Endpunkte verteilt. Dabei gewährleistet der vom Audio/Video-Bridging bekannte Credit-Based-Shaper, dass die Daten innerhalb einer definierten Zeit (Presentation Time) beim Empfänger ankommen. Im Gegensatz dazu sorgt der durch TSN hinzugekommene Time-Aware-Shaper dafür, dass die Daten gemäß eines fest vorgegebenen zeitlichen Rasters deterministisch versendet werden. Dies ist insbesondere von jedem Switch sicherzustellen. Dadurch entsteht für einen gewissen Teil der Bandbreite ein zeitgesteuertes Netzwerk, ähnlich wie bei Flexray. Beide Shaping-Verfahren können problemlos parallel zum regulären Ethernet-Verkehr in einem Netzwerk koexistieren. Gegenüber Flexray ist dies ein Vorteil.

TSN unterstützt darüber hinaus Mechanismen, um Ethernet-Pakete mit hoher Priorität im Vergleich zu gerade gesendeten Ethernet-Paketen mit niedriger Priorität zu bevorzugen, ohne auf deren kompletten Versand zu warten. Dazu werden letztere zum nächstmöglichen Zeitpunkt zu Gunsten des Ethernet-Paketes mit höherer Priorität unterbrochen (preempted) und später fortgesetzt. Dieses Verfahren verringert die bisherige maximale Latenz noch weiter, ohne dabei das übrige Sendeverhalten zu beeinflussen.

Zur Bandbreitenüberwachung wird das Stream-Reservation-Protokoll (Bild 4) verwendet. Hier kontrolliert die TSN-Bridge, dass nur bei ihr registrierte Datenströme weitergeleitet werden. Dabei muss sich das aktuelle Nachrichtenaufkommen einer Nachrichtenklasse im Rahmen eines vorher definierten Bereichs befinden. Ist dieses Budget verbraucht, kann dieser Datenstrom zu diesem Zeitpunkt nicht versendet werden.

Für sicherheitskritische Systeme besteht überdies die Möglichkeit, die Pakete für eine redundante Übertragung über separate Netzwerkpfade zu verdoppeln. Filter- und Kontrollmechanismen stellen zudem sicher, dass nur die Weiterleitung tatsächlich erwarteter Nachrichtenklassen im Rahmen ihrer benötigten Häufigkeit erfolgt. Beides erhöht die Robustheit der Ethernet-Kommunikation im Fehlerfall – sei es durch unterbrochene Netzwerkstrukturen oder durch unerwünschten Ethernet-Verkehr.

Bild 5: TSN-Mechanismen in einem Automotive-Ethernet-Netzwerk. Vector Informatik

Ein Großteil der TSN-Mechanismen erfordert Hardware-Unterstützung (Bild 5). Die jetzt schon stabile TSN-Spezifikation IEEE 802.1Qbv („Enhancements for Scheduled Traffic“) nimmt eine Führungsrolle ein und wird bereits von einer breiten Hardware-Auswahl unterstützt. Für IEEE 802.1Qbu („Frame Preemption“) hingegen bleibt abzuwarten, wie sich die Unterbrechungsmechanismen auf Ethernet etablieren. Die verkürzte Wartezeit bis zum Senden eines Frame mit höherer Priorität wird beim Gigabit-Ethernet kaum ins Gewicht fallen sondern eher einen signifikanten Einfluss auf 10/100-Megabit-Systeme haben.

Ausblick

In zukünftigen Fahrzeugplattformen verschmelzen aus der IT bekannte dynamische Protokolle und Methoden mit klassischen Automotive-Anforderungen bezüglich Zeitverhalten, Verfügbarkeit und Robustheit. Serviceorientierte Kommunikation sowie sicherheitsrelevanter und deterministischer Ethernet-Verkehr verschmelzen zu komplexen Systemen. Einerseits steht zum Designzeitpunkt noch nicht zwingend fest, auf welchem Steuergerät und unter welcher Laufzeitumgebung eine Funktion implementiert wird. Andererseits muss die Netzwerkarchitektur eine anwendungsgerechte und zuverlässige Kommunikation gewährleisten.

Mit seiner Embedded-Software ist Vector bereits heute in der Lage, diese Anforderungen zu erfüllen. Darüber hinaus bieten die Ethernet-Design- und Test-Werkzeuge von Vector Möglichkeiten, um dynamische, serviceorientierte und zeitsensitive Kommunikationsbeziehungen darzustellen und zu testen. Durch die aktive Gremienmitarbeit von Vector profitiert der Markt außerdem von frühzeitig verfügbaren Lösungen für zukünftige Trends in der Automobilindustrie.

(av)