Ressourcen effizient nutzen

Zukunftssichere Smart-Ethernet-Switches

1. Juli 2023, 11:30 Uhr | Irina Hübner
© Vector Informatik

Ethernet-Switches sind im Automotive-Umfeld zunehmend wichtig: Um den Host-Mikrocontroller zu entlasten, werden wesentliche Teile des AUTOSAR-Stack in den Switch verlagert. Wie sieht eine solche Softwarearchitektur aus und welche Anforderungen sind bei der Entwicklung zu beachten?

Diesen Artikel anhören

Die fahrzeuginterne Kommunikation mit Ethernet ist seit Jahren bei Fahrzeugherstellern und Zulieferern etabliert und entwickelt sich stetig weiter. In den Anfängen von Automotive Ethernet waren es meist Punkt-zu-Punkt-Netzwerke für dedizierte Insellösungen, etwa die Verbindung zu einem Diagnosetester oder einer Rückfahrkamera. Der Fokus lag dabei im Wesentlichen darauf, die erforderliche Bandbreite bereitzustellen.

Mit den Weiterentwicklungen in der jüngsten Vergangenheit sind immer mehr Ethernet-Knoten in den Fahrzeugnetzwerken hinzugekommen. Damit wurden Switches erforderlich, um die Verbindung der Knoten untereinander sicherzustellen. Mit dem Einzug der domänenbasierten Architektur in den Fahrzeugen wurden zudem neue Funktionen eingeführt wie etwa ein Ethernet-Backbone.

Automotive Switches: Software- und Hardwarearchitekturen

Zukünftig entwickelt sich die fahrzeuginterne Architektur von einem domänenbasierten Ansatz hin zu einer Zonenarchitektur. Der Hauptgrund hierfür ist das Reduzieren der Verdrahtungskomplexität bei Domänenarchitekturen. Mit diesem Evolutionsschritt, bei dem sich alle Domänen (Body, Powertrain, Chassis usw.) das gleiche Backbone-Medium teilen, ist eine völlig andere Herangehensweise und Zusammenarbeit in der Entwicklungsphase erforderlich. In der Zukunft spielt in Zonenarchitekturen auch Redundanz eine immer wichtigere Rolle (Bild 1).

Zukünftig spielt in Zonenarchitekturen mit Ethernet-Switches die Redundanz eine immer wichtigere Rolle. Dadurch steigt die Komplexität beim Konfigurieren solcher verteilten Systeme
Bild 1. Zukünftig spielt in Zonenarchitekturen mit Ethernet-Switches die Redundanz eine immer wichtigere Rolle. Dadurch steigt die Komplexität beim Konfigurieren solcher verteilten Systeme
© Vector Informatik

Damit nimmt die Komplexität der Konfiguration von verteilten Switches enorm zu. Die Anforderungen gehen über das reine Bereitstellen von Bandbreite weit hinaus. Die Fahrzeughersteller (OEMs) fordern ein zuverlässiges und sicheres Netzwerk mit einer flexiblen, dynamischen, Service-orientierten Kommunikation, die parallel mit Steuerungsfunktionen und Streaming-Traffic mit Time-Sensitive-Networking(TSN)-Anforderungen existiert.

Switches sind in einem solchen Kommunikationsnetzwerk essenziell wichtig. Sie ermöglichen eine Kommunikation zwischen den Ethernet-Knoten und steuern den Netzwerkzugriff, die Latenzzeiten und die Bandbreite. Ebenso spielen sie eine zentrale Rolle bei der Umsetzung von TSN-Funktionen wie beispielsweise Zeitsynchronisation sowie bei der Zuverlässigkeit und der Sicherheit des Netzwerks insgesamt. Schon heute ist klar, dass die Zahl der Switches im Netzwerk aufgrund der Zunahme der Funktionen im Fahrzeugnetzwerk deutlich steigen wird.

In diesem Zusammenhang stellen sich daher beim Einsatz von Switches einige Fragen:

  • Wie sieht die Hard- und Softwarearchitektur aus?
  • Welche Softwarefunktionen sind auf dem Switch notwendig?
  • Wie lässt sich die Konfigurationskonsistenz über alle Switches im Netzwerk sicherstellen?
  • Wie erfolgt das Software-Update der Switches?

Automotive Switches und AUTOSAR

Ein Mikrocontroller-basiertes Switch-Management ist in seiner Leistungsfähigkeit begrenzt. Der limitierende Faktor ist die Schnittstelle
Bild 2. Ein Mikrocontroller-basiertes Switch-Management ist in seiner Leistungsfähigkeit begrenzt. Der limitierende Faktor ist die Schnittstelle.
© Vector Informatik

Aus Hardwaresicht ist ein Switch-IC ein Subsystem des Steuergeräts, das zusammen mit dem Mikrocontroller auf einer Leiterplatte platziert ist. Beim klassischen AUTOSAR-Ansatz läuft auf dem Mikrocontroller ein AUTOSAR-Stack mit einem Echtzeitbetriebssystem. Dieser Mikrocontroller verwaltet den Switch und dessen PHYs mittels Treiber via Management-Interfaces wie beispielsweise MDIO (Management Data Input/Output) oder SPI (Serial Peripheral Interface) und steuert den Switch wie ein Peripheriegerät (Bild 2).

Ein solcher Ansatz stößt jedoch schnell an seine Grenzen. So ist zum Beispiel das PTP-Handling (Precision Time Protocol) von Switches mit mehr als sechs Ports nicht mehr sinnvoll, da die CPU-Last des Mikrocontrollers mit der Zahl der Ports enorm ansteigt. Auch für Anwendungsfälle wie Automotive-Firewall oder softwarebasierte Paketanalyse ist ein solcher Lösungsansatz aufgrund der Latenzzeiten zwischen Switch und Mikrocontroller sowie der Laufzeit des Mikrocontrollers nicht mehr praktikabel.

»Smart Switches« und AUTOSAR

Ein Switch-IC mit integrierter CPU fungiert als ein smarter Switch des Mikrocontrollers und übernimmt wichtige Netzwerkaufgaben vom Mikrocontroller
Bild 3. Ein Switch-IC mit integrierter CPU fungiert als ein smarter Switch des Mikrocontrollers und übernimmt wichtige Netzwerkaufgaben vom Mikrocontroller.
© Vector Informatik

Die meisten heute eingesetzten Switches enthalten bereits eine eigene CPU mit (externem) Flash-Speicher (Bild 3), von dem aus der Switch gebootet und somit unabhängig vom Mikrocontroller betrieben wird. Das bedeutet, dass ein Switch-IC mit einer eigenen CPU als »Smart Switch« des Mikrocontrollers arbeitet. Der Switch übernimmt relevante netzwerkspezifische Tasks und entlastet dadurch den Mikrocontroller von Netzwerkaufgaben wie zum Beispiel PTP-Handling.

Beim Einsatz solcher Smart-Switch-ICs in der Praxis gibt es meist zwei Herangehensweisen. Beide sind nicht optimal, da die Funktionen und Ressourcen des Switches nicht ausreichend genutzt werden. Beim ersten Ansatz wird der Switch oftmals als einfaches Peripheriegerät eingesetzt und die AUTOSAR-Switch-Treiber laufen weiterhin auf dem Mikrocontroller. Das führt dazu, dass die Switch-CPU deaktiviert ist und daher die eigentlich zusätzlichen Ressourcen des Smart Switch entfallen.

Der zweite Ansatz ist der Wegfall der Switch-Treiber auf dem Mikrocontroller. In diesem Fall führt der Switch seine eigene, proprietäre Software aus. Der Nachteil hierbei ist, dass der Switch vom AUTOSAR-Workflow (Konfiguration und Updates) komplett entkoppelt ist und der Mikrocontroller keinen Einfluss mehr auf den Switch hat. Dieser Ansatz wirft wiederum einige Fragen auf:

  • Wie wird die Konfigurationskonsistenz erreicht?
  • Wie sieht das Konzept des Software-Updates und der UDS-Diagnose aus?
  • Wie unterstützt der Switch Automotive-spezifische Protokolle und Erweiterungen?

Im Detail betrachtet ist ein solches Switch-Steuergerät (ECU) ein Multiprozessor-System mit einem verteilten Funktions-Set (Bild 4): Auf der einen Seite ist der Mikrocontroller mit dem AUTOSAR-Echtzeitbetriebssystem und der Basissoftware, auf der anderen Seite der Switch mit integrierter CPU und eigener Software.

Softwaremodule für das PTP-Handling, TSN, Firewall und Diagnose werden vom Mikrocontroller auf den Switch ausgelagert
Bild 4. Softwaremodule für das PTP-Handling, TSN, Firewall und Diagnose werden vom Mikrocontroller auf den Switch ausgelagert.
© Vector Informatik

Das Ziel ist, eine verteilte Softwarearchitektur zu erstellen, bei der Funktionen jeweils auf der dafür bestgeeigneten Systemkomponente ausgeführt werden. Damit wird zum einen ein Mikrocontroller-unabhängiges schnelles Starten und Aufwecken erreicht sowie eine Selbstkonfiguration des Switch. Zum anderen wird das PTP-Handling lokal über den Switch ausgeführt.

Ein weiterer Vorteil dieses Konzepts ist das Ausführen von unter anderem Partial Networking sowie AVB/TSN-Funktionen auf dem Switch. Bei ausreichenden Ressourcen sind sogar »Firewalling« oder OEM-spezifische Use-Cases wie zum Beispiel Variantenbereitstellung direkt auf dem Switch möglich. In naher Zukunft ist auch der Einsatz von MACsec auf dem Switch geplant.

Das Kürzel MACsec steht für Media Access Control Security. Dabei handelt es sich um einen in der IEEE-Norm 802.1AE spezifizierten Sicherheitsstandard. Er arbeitet auf der Schicht 2 des OSI-Referenzmodells, sorgt für Sicherheit der Punkt-zu-Punkt-Ethernet-Verbindungen und verhindert zahlreiche Bedrohungen und Angriffe wie beispielsweise Spoofing, Replay-Angriffe, Man-in-the-Middle-Angriffe oder Masquerading.

Erste AUTOSAR-fähige Ethernet-Switches

Vector hat den ersten AUTOSAR-fähigen Multi-Gig-Ethernet-Switch auf Basis der Brightlane-Lösung von Marvell entwickelt, der für Zulieferer und Automobilhersteller unter der Bezeichnung Ethernet-Switch Brightlane 88Q5072 von Marvell erhältlich ist. Die neue Embedded Software von Vector für Ethernet-Switches ist mit dem Namen MICROSAR Classic veSwitch verfügbar. Sie nutzt den AUTOSAR-Workflow für wesentliche Funktionen wie beispielsweise die Portkonfiguration, Partial Networking und PTP. Security-Funktionen wie Automotive-Firewalls und MACsec sind in die Software-Architektur einfach integrierbar. Die Software hat sich in der Praxis bewährt und der Aufwand für das Entwickeln von intelligenten Switch-ECUs ist deutlich reduziert.

Der modulare Ansatz des Workflow führt zu einer Hardware-optimierten und flexiblen Lösung – ideal für Automotive-konforme Switches einschließlich Firewall- und Safety-Anwendungen. Der Entwickler-Workflow wird durch die Vector DaVinci Tools optimal unterstützt.

In einer ersten Version erfüllt die Embedded-Software die Qualitätsanforderungen nach Automotive SPICE. Zukünftig wird veSwitch nach ISO 26262 verfügbar sein. Ein Evaluierungspaket ist ebenfalls verfügbar.


  1. Zukunftssichere Smart-Ethernet-Switches
  2. Softwaredistribution

Lesen Sie mehr zum Thema


Das könnte Sie auch interessieren

Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Vector Informatik GmbH

Weitere Artikel zu Bordnetz und Bussysteme

Weitere Artikel zu Verbindungstechnik sonstige

Weitere Artikel zu Fahrzeugkomponenten

Weitere Artikel zu Entwicklung und Test