Dieser Post ist die Ergänzung zur EthTrcv Teil 1 — Grundlagen & Einordnung-Serie: Während EthTrcv den PHY-Chip an genau einem Port ansteuert, kümmert sich EthSwt um Steuergeräte mit mehreren Ports und einem Switch-Chip dazwischen. Grundlagenwissen zu AUTOSAR im Allgemeinen liefert der AUTOSAR Grundlagen-Post.

Wer bisher nur einfache Steuergeräte mit einem einzelnen Ethernet-Anschluss konfiguriert hat, kennt EthTrcv, EthTrcv_Init, EthTrcvMiiInterface — fertig. Sobald ein Steuergerät aber mehrere Ethernet-Teilnehmer bedienen muss (Zonal Gateway, Domain Controller mit mehreren Kamera-Zuleitungen), reicht dieses Modell nicht mehr aus. Dann kommt EthSwt ins Spiel.

Was ist EthSwt?

EthSwt ist der AUTOSAR Basic-Software-Treiber für Ethernet-Switch-ICs. Er kapselt die Konfiguration und Steuerung eines Switch-Chips, der mehrere physikalische Ports mit Layer-2-Forwarding zwischen ihnen verbindet.

Die Grundfrage, die über "brauche ich EthSwt?" entscheidet, ist einfach:

SituationTreiber

Ein Ethernet-Port, ein PHY, eine Punkt-zu-Punkt-Verbindung

EthTrcv reicht aus

Mehrere Ethernet-Ports, die Frames untereinander weiterleiten sollen (Switching)

EthSwt erforderlich, zusätzlich zu EthTrcv pro Port

Steuergerät mit VLANs, Port-Mirroring, Priorisierung über mehrere Teilnehmer

EthSwt zwingend

EthSwt ersetzt EthTrcv nicht — er ergänzt es. Jeder physikalische Port eines Switch-Chips hat in der Regel einen eigenen PHY (intern oder extern), der weiterhin über EthTrcv konfiguriert wird. EthSwt kommt zusätzlich dazu und kümmert sich um die switch-spezifische Logik: Forwarding-Tabellen, VLANs, Port-Zustände.

In der Praxis taucht EthSwt vor allem in zwei Szenarien auf:

  • Zonal-Gateway-Steuergeräte, die Ethernet-Verkehr aus mehreren Zonen bündeln und zum Backbone weiterleiten.

  • Domain Controller mit mehreren Kameras oder Sensoren, die jeweils über einen eigenen 100BASE-T1-Link angebunden sind und deren Frames auf einem gemeinsamen Uplink zusammenlaufen müssen.

Architektur im AUTOSAR Ethernet-Stack

EthSwt sitzt in der Basic Software zwischen EthIf und den EthTrcv-Instanzen der einzelnen Switch-Ports. Der grobe Aufbau sieht so aus:

                     ┌────────────────────────────────────────┐
                     │                  EthIf                 │
                     │   (Abstraktion: virtuelle Controller)   │
                     └───────────────┬────────────┬───────────┘
                                      │            │
                         ┌────────────┘            └────────────┐
                         ▼                                      ▼
                 ┌───────────────┐                      ┌───────────────┐
                 │      Eth      │                      │     EthSwt    │
                 │ (Controller-  │                      │  (Switch-     │
                 │  Treiber, MAC)│                      │   Treiber)    │
                 └───────┬───────┘                      └───┬───┬───┬───┘
                         │                                  │   │   │
                         ▼                                  ▼   ▼   ▼
                    ┌─────────┐                        ┌─────┐┌─────┐┌─────┐
                    │ EthTrcv │                        │EthTrcv││EthTrcv││EthTrcv│
                    │ (1 Port)│                        │Port 1 ││Port 2 ││Port 3 │
                    └────┬────┘                        └───┬───┘└───┬───┘└───┬───┘
                         ▼                                 ▼        ▼        ▼
                       PHY                                PHY      PHY      PHY
                         │                                 │        │        │
                       Kabel                             Kabel    Kabel    Kabel

Wichtige Punkte an diesem Bild:

  • Eth ist der klassische Controller-Treiber für die MAC-Anbindung des SoC (z. B. den internen Uplink-Port des SoCs zum Switch-Chip, oft via RGMII oder SGMII).

  • EthSwt verwaltet den Switch-Chip als Ganzes: Register-Konfiguration über SPI/I2C oder MDIO, Forwarding-Regeln, VLAN-Tabellen, Port-Zustände.

  • Jeder physikalische Port des Switch-Chips hat weiterhin einen eigenen EthTrcv, weil auf Leitungsebene weiterhin ein PHY (oft integriert im Switch-IC) das Signal auf dem Kabel erzeugt — siehe dazu den EthTrcv Hardware Deep Dive.

  • EthIf abstrahiert die Switch-Ports zusätzlich als eigene virtuelle Controller, sodass obere Softwareschichten (Socket-Adaptor, TCP/IP-Stack, DoIP) nicht wissen müssen, ob ein Frame über einen physikalischen MAC-Controller oder einen Switch-Port läuft.

Ein häufiges Missverständnis: EthSwt "spricht" nicht direkt mit EthIf-Nutzern wie DoIP oder dem TCP/IP-Stack. Diese kommunizieren immer über EthIf — EthSwt ist reine Konfigurations- und Verwaltungsschicht für den Switch-Chip selbst.

EthSwt API — die wichtigsten Funktionen

Die EthSwt-API ist im Vergleich zu EthTrcv deutlich management-lastiger: weniger "sende dieses Frame", mehr "konfiguriere diesen Port so". Drei Funktionen bilden das Grundgerüst.

EthSwt_Init

void EthSwt_Init(
    const EthSwt_ConfigType* CfgPtr
);

Initialisiert den Switch-Treiber anhand der generierten Konfigurationsstruktur. Dabei werden typischerweise:

  • die Kommunikationsschnittstelle zum Switch-Chip aufgebaut (SPI, I2C, oder MDIO-basiertes Register-Interface, je nach Chip),

  • die initialen Port-Zustände gesetzt (z. B. alle Ports zunächst im DISABLED- oder BLOCKING-Zustand, bis die höheren Schichten sie aktivieren),

  • VLAN-Grundkonfiguration, Forwarding-Datenbank und ggf. QoS-Priorisierung geladen.

EthSwt_Init liefert wie viele AUTOSAR-Init-Funktionen void zurück — Fehler werden über das Diagnostic Event Manager (DEM) oder Development Error Tracer (DET) gemeldet, nicht über einen Rückgabewert.

EthSwt_GetPortMacAddr

Std_ReturnType EthSwt_GetPortMacAddr(
    uint8    SwitchIdx,
    uint8    SwitchPortIdx,
    uint8*   MacAddrPtr
);

Liest die MAC-Adresse eines bestimmten Switch-Ports aus. Das ist notwendig, weil manche Switch-Chips pro Port eine eigene MAC-Adresse besitzen (z. B. für die Beantwortung von ARP/NDP-Anfragen an virtuellen Controllern), während andere Chips eine gemeinsame Basis-MAC-Adresse mit Offset pro Port verwenden.

SwitchIdx adressiert den Switch-Chip (bei Steuergeräten mit mehreren Switch-ICs), SwitchPortIdx den physikalischen Port innerhalb dieses Chips. Der Rückgabewert ist Std_ReturnType — E_OK bei Erfolg, E_NOT_OK wenn der Port ungültig ist oder die MAC-Adresse (noch) nicht gelesen werden kann.

EthSwt_SetPortMode

Std_ReturnType EthSwt_SetPortMode(
    uint8              SwitchIdx,
    uint8              SwitchPortIdx,
    Eth_ModeType       PortMode
);

Setzt den Betriebsmodus eines Ports — typischerweise ETH_MODE_DOWN oder ETH_MODE_ACTIVE. Damit lassen sich Ports gezielt deaktivieren, etwa um Energie zu sparen, wenn ein angeschlossener Teilnehmer nicht gebraucht wird, oder um einen Port aus Sicherheitsgründen zu isolieren.

EthSwt_SetPortMode steuert den logischen Betriebsmodus des Ports im Switch (Forwarding aktiv/inaktiv). Der physikalische Link-Zustand — ob überhaupt ein Kabel angeschlossen und ein PHY-Link etabliert ist — bleibt weiterhin Aufgabe des zugehörigen EthTrcv_SetTransceiverMode bzw. wird über EthTrcv_GetLinkState abgefragt. Beide Ebenen sind unabhängig voneinander zu betrachten.

Switch-Management-Konzepte in AUTOSAR

Neben den drei API-Funktionen definiert der AUTOSAR EthSwt-Standard eine Reihe von Management-Konzepten, die über ARXML-Konfiguration gesteuert werden.

Port-Konfiguration

Jeder Switch-Port wird im ARXML als EthSwtPortConfig (bzw. äquivalente Container, je nach AUTOSAR-Release) beschrieben, u. a. mit:

  • Port-Rolle: Uplink-Port (zum SoC) vs. Downlink-Port (zu Endgeräten/Sensoren),

  • Standard-VLAN-Zugehörigkeit,

  • Priorisierungs-Mapping (IEEE 802.1p → Switch-interne Queues),

  • Erlaubte Link-Geschwindigkeiten (Autonegotiation-Grenzen).

Forwarding

Der Switch-Chip pflegt intern eine Forwarding-Datenbank (FDB), die MAC-Adressen auf Ports abbildet. AUTOSAR EthSwt erlaubt es, statische FDB-Einträge über ARXML vorzukonfigurieren — etwa für sicherheitsrelevante Kommunikationspfade, die nicht vom dynamischen Lernverhalten des Switches abhängen sollen.

Dynamisches Lernen:  Switch beobachtet Quell-MAC eingehender Frames
                      → trägt (MAC, Port) automatisch in FDB ein
                      → Timeout löscht ungenutzte Einträge (Aging)

Statische Einträge:   Im ARXML vorkonfiguriert
                      → werden nie gealtert
                      → typisch für sicherheitskritische ECU-zu-ECU-Pfade

Mirroring

Für Diagnose und Entwicklung unterstützen die meisten automotive-tauglichen Switch-Chips Port-Mirroring: der komplette Datenverkehr eines oder mehrerer Quell-Ports wird zusätzlich auf einen Ziel-Port (Mirror-Port) kopiert, an dem ein Analysewerkzeug (z. B. ein Wireshark-fähiger Logging-Rechner) angeschlossen wird.

Mirroring ist in Serien-Steuergeräten meist per Default deaktiviert und wird nur über ein Diagnose-Kommando (UDS Routine Control) oder eine spezielle Debug-Variante der ARXML-Konfiguration aktiviert — dauerhaft aktives Mirroring kostet Bandbreite auf dem Mirror-Port und ist im Feldbetrieb unerwünscht.

VLAN-Konfiguration

VLANs (IEEE 802.1Q) sind der Kernmechanismus, mit dem ein einzelner physikalischer Switch mehrere logisch getrennte Netzwerke abbildet — etwa um sicherheitskritischen ADAS-Verkehr von Infotainment-Verkehr zu trennen, obwohl beide über denselben Switch-Chip laufen.

Tagged vs. Untagged Ports

Untagged Port (Access Port):
   Eingehendes Frame ohne VLAN-Tag
   → Switch weist es intern der Port-VLAN-ID (PVID) zu
   → Ausgehend wird der Tag wieder entfernt (transparent für den Endteilnehmer)

Tagged Port (Trunk Port):
   Eingehendes Frame trägt bereits einen 802.1Q-Tag (VLAN-ID im Header)
   → Switch leitet basierend auf dieser VLAN-ID weiter
   → Ausgehend bleibt der Tag erhalten
   → typisch zwischen zwei Switches oder zum Zonal-Gateway-Uplink

Ein 802.1Q-Tag fügt dem Ethernet-Header 4 zusätzliche Bytes hinzu:

 Ziel-MAC | Quell-MAC | 802.1Q-Tag (4 Byte) | EtherType | Payload
                        ├─ TPID  (0x8100)
                        ├─ PCP   (3 Bit, Priorität, 802.1p)
                        ├─ DEI   (1 Bit)
                        └─ VID   (12 Bit, VLAN-ID, 1–4094)

VLAN-Konfiguration im ARXML

Ein vereinfachtes, illustratives Beispiel, wie eine VLAN-Konfiguration in ARXML aussehen kann (Struktur an die realen EthSwt-Konfigurationscontainer angelehnt, im Detail herstellerabhängig):

<ETHERNET-SWITCH-VLAN>
  <SHORT-NAME>VLAN_ADAS</SHORT-NAME>
  <VLAN-IDENTIFIER>100</VLAN-IDENTIFIER>
  <ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIPS>
    <ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
      <ETHERNET-SWITCH-PORT-REF DEST="ETHERNET-SWITCH-PORT">
        /EthSwt/SwitchAsr/Port_Camera_Front
      </ETHERNET-SWITCH-PORT-REF>
      <TAGGING-MODE>UNTAGGED</TAGGING-MODE>
    </ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
    <ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
      <ETHERNET-SWITCH-PORT-REF DEST="ETHERNET-SWITCH-PORT">
        /EthSwt/SwitchAsr/Port_Uplink_Gateway
      </ETHERNET-SWITCH-PORT-REF>
      <TAGGING-MODE>TAGGED</TAGGING-MODE>
    </ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIP>
  </ETHERNET-SWITCH-PORT-VLAN-MEMBERSHIPS>
</ETHERNET-SWITCH-VLAN>

In diesem Beispiel gehört Port Port_Camera_Front untagged zu VLAN 100 (die Kamera selbst "weiß" nichts von VLANs), während der Uplink-Port zum Zonal-Gateway getaggt ist — dort laufen mehrere VLANs gebündelt über eine einzige physikalische Leitung.

ParameterBedeutungTypischer Wert

VLAN-IDENTIFIER

Eindeutige VLAN-ID im Switch

1–4094 (0 und 4095 reserviert)

TAGGING-MODE

Ob der Port das VLAN getaggt oder untagged sieht

TAGGED / UNTAGGED

PVID (Port-VLAN-ID)

Default-VLAN für untagged eingehende Frames

Meist identisch mit der VLAN-ID des primären Access-VLANs

Ein Port, der fälschlich als TAGGED statt UNTAGGED konfiguriert ist, lässt Frames mit VLAN-Tag beim Endgerät ankommen, das keine 802.1Q-Tags erwartet. Viele einfache Sensor-/Aktor-Steuergeräte verwerfen solche Frames stillschweigend — ein klassischer "Kommunikation geht nicht, aber kein Fehlercode"-Bug.

Zusammenspiel mit EthIf

Für die oberen Softwareschichten sollen Switch-Ports möglichst genauso aussehen wie gewöhnliche Ethernet-Controller. AUTOSAR löst das, indem EthIf jeden relevanten Switch-Port als eigenen virtuellen Controller (EthIfCtrlIdx) abbildet.

Physikalische Sicht:                  Logische Sicht (EthIf):

  Switch-Chip                           EthIf-Controller 0  → Switch-Port 1
    ├── Port 1 (Kamera vorne)           EthIf-Controller 1  → Switch-Port 2
    ├── Port 2 (Kamera hinten)          EthIf-Controller 2  → Switch-Port 3
    ├── Port 3 (Radar)                  EthIf-Controller 3  → Eth (SoC-Uplink)
    └── Port 4 (Uplink zum SoC)

Ein Socket-Adaptor oder die TCP/IP-Stack-Instanz, die z. B. Kamera-Daten von Port 1 empfangen soll, konfiguriert einfach EthIfCtrlIdx = 0 — ob dahinter ein "echter" MAC-Controller oder ein Switch-Port mit EthSwt-Anbindung steckt, ist für diese Schicht unsichtbar.

Diese Abstraktion ist ein zentraler Designvorteil von AUTOSAR: Ein Applikations- Softwaremodul, das über einen Socket kommuniziert, muss nicht wissen, ob es auf einem Steuergerät mit einfachem EthTrcv oder auf einem komplexen Zonal-Gateway mit mehrstufigem Switch läuft. Die Portierung zwischen Hardware-Varianten bleibt eine reine Konfigurationsänderung in EthIf/EthSwt.

Spanning Tree & Port-States

Sobald mehrere Switches in einem Fahrzeugnetz redundante Pfade bilden (z. B. für Ringtopologien in Zonal-Architekturen, die auch bei Kabelbruch funktionsfähig bleiben sollen), entsteht die Gefahr von Broadcast-Loops. Das Standard-Gegenmittel aus der IT-Welt ist das Spanning Tree Protocol (STP, IEEE 802.1D) bzw. dessen schnellere Nachfolger RSTP (802.1w) und MSTP (802.1s).

In automotive Steuergeräten wird STP/RSTP selten vollständig dynamisch betrieben — die Netztopologie ist meist zur Entwicklungszeit bekannt und fest verdrahtet. Trotzdem definiert AUTOSAR EthSwt die Port-Zustände, die STP-Implementierungen (oder statisch vorkonfigurierte Äquivalente) durchlaufen:

DISABLED    → Port physikalisch/logisch abgeschaltet, kein Verkehr
BLOCKING    → Port empfängt STP-BPDUs, leitet aber keine Nutzdaten weiter
              (verhindert Loop, während die Topologie ausgehandelt wird)
LISTENING   → Übergangszustand, Port beginnt aktiv am STP-Algorithmus teilzunehmen
LEARNING    → Port lernt MAC-Adressen (FDB-Aufbau), leitet aber noch nicht weiter
FORWARDING  → Normalbetrieb: Port leitet Nutzdaten in beide Richtungen weiter

Der Übergang von BLOCKING über LISTENING/LEARNING zu FORWARDING kostet bei klassischem STP mehrere Sekunden (Forward Delay). Für automotive Anwendungsfälle, wo Netzwerkverfügbarkeit innerhalb von Millisekunden nach Power-On gefordert ist, ist das oft inakzeptabel. Viele Automotive-Switch-Chips setzen deshalb auf RSTP mit Rapid-Transition-Mechanismen oder verzichten ganz auf dynamisches STP zugunsten statisch konfigurierter, loop-freier Topologien.

Die meisten in Fahrzeugen eingesetzten Switch-Topologien sind daher bewusst loop-frei als Baum oder Stern aufgebaut — STP dient dann eher als Absicherung gegen Fehlkonfiguration oder Verkabelungsfehler in der Werkstatt, nicht als aktiv genutzter Redundanzmechanismus im Normalbetrieb.

Typische Switch-Chips in der Praxis

Ein kurzer, keineswegs vollständiger Überblick über automotive-taugliche Switch-ICs, die in AUTOSAR-Projekten mit EthSwt-Anbindung vorkommen:

ChipHerstellerEckdaten

SJA1110

NXP

Automotive Ethernet-Switch mit integrierten 100BASE-T1/1000BASE-T1-PHYs, TSN-Unterstützung (IEEE 802.1Qbv Time-Aware Shaper), häufig in Zonal-Gateways

88Q5050

Marvell

Gigabit-Automotive-Switch, mehrere 1000BASE-T1-Ports, SGMII-Uplink, eingesetzt in Domain-/Zonal-Controllern mit hohem Kamera-/LiDAR-Durchsatz

RTL9068

Realtek

Automotive-Switch-Familie mit Fokus auf kosteneffiziente Multi-Port-Lösungen für kleinere Zonal-Steuergeräte

Viele dieser Chips bringen die PHYs für 100BASE-T1/1000BASE-T1 bereits integriert mit — aus AUTOSAR-Sicht ändert das nichts an der Notwendigkeit, für jeden Port weiterhin eine EthTrcv-Instanz zu konfigurieren. Der PHY ist nur physisch im selben Package wie der Switch, softwarearchitektonisch bleibt die Trennung zwischen EthSwt (Switch-Logik) und EthTrcv (PHY pro Port) bestehen.

Die Anbindung an den Mikrocontroller erfolgt bei diesen Chips meist über SPI (für Register-Konfiguration) kombiniert mit SGMII oder RGMII (für den Daten-Uplink) — MDIO wird teils zusätzlich für die PHY-Konfiguration der einzelnen Ports verwendet, auch wenn der Switch-Chip selbst über SPI gesteuert wird.

Diagnose und Monitoring

Switch-Chips sammeln pro Port umfangreiche Statistiken — CRC-Fehler, Kollisionen (bei Legacy-Half-Duplex, in modernen Automotive-Netzen selten relevant), verworfene Frames, Broadcast-/Multicast-Zähler. AUTOSAR bindet diese Daten über zwei etablierte Kanäle in die Diagnose ein:

DEM — Fehlerspeichereinträge

Überschreitet ein Fehlerzähler (z. B. CRC-Fehlerrate auf einem Port) einen konfigurierten Schwellwert, meldet EthSwt dies als Diagnostic Event an den DEM. Klassische Events sind z. B. "Port Link Lost" oder "Excessive Frame Errors", die dann über den regulären DTC-Mechanismus (Diagnostic Trouble Code) im Fehlerspeicher landen und per UDS auslesbar sind.

DCM — Auslesen von Switch-Statistiken

Über UDS-Services (typischerweise Read Data By Identifier, Service 0x22) lassen sich switch-spezifische Datensätze auslesen — etwa aktuelle Port-Zustände, FDB-Auslastung oder kumulierte Fehlerzähler. Diese Datensätze werden im DCM/DEM-Konfigurationslayer auf herstellerspezifische Data Identifier (DIDs) gemappt.

Werkstatt-Tester
   → UDS ReadDataByIdentifier (DID = Switch-Port-Statistik)
   → Dcm leitet Anfrage an EthSwt-Diagnose-Callback weiter
   → EthSwt liest Register aus dem Switch-Chip aus (SPI/I2C)
   → Statistik wird als UDS-Response zurückgegeben

Bei der Fehlersuche im Feld sind Port-Statistiken oft aussagekräftiger als ein einzelner DTC: eine kontinuierlich steigende CRC-Fehlerrate auf genau einem Port deutet meist auf ein PCB- oder Kabelproblem an diesem spezifischen Anschluss hin, während ein DTC nur "irgendetwas mit Ethernet" signalisiert.

Zusammenfassung

ThemaKernaussage

EthSwt vs. EthTrcv

EthSwt verwaltet den Switch-Chip als Ganzes, EthTrcv bleibt pro Port zuständig für den PHY

Architektur

EthIf abstrahiert Switch-Ports als virtuelle Controller — obere Schichten sehen keinen Unterschied

API

EthSwt_Init, EthSwt_GetPortMacAddr, EthSwt_SetPortMode bilden das Grundgerüst

VLANs

802.1Q-Tagging trennt logische Netze auf einem physikalischen Switch; Tagged/Untagged-Konfiguration pro Port ist fehleranfällig

Spanning Tree

In automotive Netzen meist statisch/loop-frei konfiguriert statt dynamisch betrieben — STP als Absicherung, nicht als aktiver Mechanismus

Switch-Chips

NXP SJA1110, Marvell 88Q5050 und ähnliche integrieren PHYs, ändern aber nichts an der EthSwt/EthTrcv-Trennung

Diagnose

Port-Statistiken über DEM/DCM sind oft aussagekräftiger als ein einzelner DTC

Mehr zum AUTOSAR Ethernet-Stack: EthTrcv-Serie