Der EthSwt-Überblicksartikel hat schon gezeigt, was ein AUTOSAR Ethernet Switch Driver grundsätzlich tut und wann man ihn statt eines einfachen EthTrcv braucht. Diese Tutorial-Serie geht jetzt einen Schritt tiefer: Bevor in den nächsten Teilen API-Aufrufe, ARXML-Container und VLAN-Konfiguration drankommen, klärt dieser erste Teil, was die offizielle Specification of Ethernet Switch Driver (Dokument-ID 656, AUTOSAR CP R25-11) tatsächlich vorschreibt — Zustandsautomat, Konfigurationsklassen und die Einordnung im Stack.

Alle Aussagen in diesem Post sind gegen den Originaltext der SWS geprüft (docs/references/autosar-sws/AUTOSAR_CP_SWS_EthernetSwitchDriver_R25-11.txt im Quellrepo dieses Blogs).

Die SWS EthSwt im Überblick

Die SWS EthSwt ist mit rund 330 Seiten deutlich umfangreicher als die SWS EthTrcv — nicht weil der Switch komplizierter wäre, sondern weil er zusätzliche Funktionsbereiche mitbringt, die ein reiner Transceiver nicht kennt: Port-Mirroring, MAC-Learning, VLANs, Time-Sensitive Networking (TSN), MACsec auf Switch-Ebene und die Interaktion mit dem Firewall-Modul. Diese Serie behandelt die Grundlagen in den Teilen 1–4 und vertieft die Spezialthemen danach in eigenen Posts.

SWS EthSwt (Dokument-ID 656) — Kapitelübersicht
──────────────────────────────────────────────────────────────
1  Introduction and functional overview
5  Dependencies to other modules
7  Functional specification          ← Grundlage dieses Posts
   7.1.1  Indexing scheme
   7.1.2  Port Mirroring
   7.1.3  State Handling             ← Zustandsautomat
   7.1.7  Functional Description     (Learning, VLAN, TSN, MACsec, ...)
8  API specification                 ← Teil 2 dieser Serie
10 Configuration specification       ← Teil 3 dieser Serie

Zustandsautomat des Moduls

Anders als man vielleicht erwartet, ist der EthSwt-Zustandsautomat kein einfaches Uninit/Init-Paar, sondern vierstufig — er unterscheidet explizit zwischen "der Treiber ist initialisiert" und "die Ports sind initialisiert":

EthSwt_StateType (SWS_EthSwt_00123)
──────────────────────────────────────────────────────────────
ETHSWT_STATE_UNINIT              0x00   Switch ist noch nicht konfiguriert
        │
        │  EthSwt_Init()
        ▼
ETHSWT_STATE_INIT                0x01   Switch-Treiber ist initialisiert
        │
        │  (Port-Initialisierung abgeschlossen)
        ▼
ETHSWT_STATE_PORTINIT_COMPLETED  0x02   Port-Initialisierung abgeschlossen
        │
        │  EthSwt_SetSwitchPortMode(ACTIVE)
        ▼
ETHSWT_STATE_ACTIVE              0x03   Switch ist aktiv

Die SWS bezeichnet diesen Zustand ausdrücklich als "Status supervision used for Development Error Detection" — er dient also primär der Fehlerdiagnose (DET), nicht der Ablaufsteuerung durch den Anwender. Trotzdem lohnt es sich, ihn beim Debuggen eines Bring-up-Problems als Erstes abzufragen: Steckt der Treiber noch in UNINIT, ist meist EthSwt_Init gar nicht (erfolgreich) aufgerufen worden.

Konfigurationsklassen

Wie jedes AUTOSAR-BSW-Modul unterscheidet auch EthSwt zwischen Pre-Compile-, Link-Time- und Post-Build-Parametern. Für einen Switch-Treiber ergibt sich daraus eine praktisch wichtige Faustregel:

KonfigurationsklasseTypisch für EthSwt

Pre-Compile

Grundlegende Modul-Fähigkeiten, die Compile-Zeit-Codegenerierung beeinflussen — z. B. ob EthSwt_GetSwitchRegApi überhaupt vorhanden ist, Anzahl unterstützter Switches

Link-Time

Seltener genutzt bei EthSwt, meist projektspezifische Bibliotheksbindung

Post-Build

Der Großteil der praktischen Parametrisierung: Portanzahl, VLAN-Zuordnung, MAC-Learning-Modus, Mirroring-Konfiguration — Werte, die sich zwischen Fahrzeugvarianten unterscheiden, ohne dass der Treiber neu compiliert werden muss

Laut SWS ist EthSwt_ConfigType (Kapitel 8.2.2) ausdrücklich als "implementation specific structure of the post build configuration" definiert — die tatsächliche Struktur bleibt Sache des MCAL-Lieferanten, nur die Post-Build-Natur ist normativ vorgeschrieben.

Das Indexing-Schema: SwitchIdx und SwitchPortIdx

Ein Detail, das in der Praxis häufiger übersehen wird, als man denkt: EthSwt kennt zwei getrennte, jeweils nullbasierte Indizes (Kapitel 7.1.1):

  • SwitchIdx — identifiziert welcher Switch gemeint ist, wenn ein Steuergerät mehrere physische Switch-Chips verbaut hat

  • SwitchPortIdx — identifiziert einen Port an diesem Switch

Praktisch jede EthSwt-API (siehe Teil 2) nimmt daher entweder beide Indizes entgegen oder mindestens SwitchIdx. Wer versehentlich einen SwitchPortIdx eines anderen Switches an die falsche SwitchIdx übergibt, bekommt keinen Compile-Fehler — sondern schlicht falsches Verhalten am falschen Port.

Werden in einem Steuergerät mehrere Switch-Chips unterschiedlicher Hersteller verbaut, schreibt die SWS vor (SWS_EthSwt_00131), dass sich die Funktionsnamen der jeweiligen Treiberinstanzen unterscheiden müssen — z. B. durch einen angehängten Vendor- oder Typ-Bezeichner. Zwei EthSwt_Init mit identischem Symbolnamen für zwei verschiedene Chips sind nicht zulässig.

Architektur im AUTOSAR Ethernet-Stack

EthSwt reiht sich zwischen EthIf und den EthTrcv-Instanzen der einzelnen Switch-Ports ein:

EthSwt im AUTOSAR Ethernet-Stack

Der wichtigste Unterschied zu einem einfachen EthTrcv-Setup: EthSwt hat in der Regel mehrere EthTrcv-Instanzen unter sich — eine pro externem Port — während der Host selbst nur über einen einzigen Eth/EthIf-Pfad mit dem Switch spricht. Der Switch selbst übernimmt die Weiterleitung zwischen den externen Ports, ohne dass jedes Frame den Host passieren muss.

Eine nützliche Eselsbrücke: Bei einem einfachen EthTrcv "sieht" der Host jedes Bit, das über die Leitung geht. Bei einem Switch mit EthSwt sieht der Host nur noch die Frames, die für ihn selbst bestimmt sind oder die er explizit über Mirroring oder Management-APIs anfordert — der Switch trifft die Forwarding-Entscheidung eigenständig in Hardware.

Multi-Switch-Topologien

In Zonal-Architekturen sind kaskadierte Switches der Normalfall: ein Backbone-Switch im zentralen Gateway, verbunden über Uplink-Ports mit kleineren Switches in den Zonal-Controllern. Die SWS berücksichtigt das explizit über die Portrolle ETHSWT_UP_LINK_PORT und eigene Mechanismen zur Uhrensynchronisation zwischen kaskadierten Switches (dazu mehr in Issue #142 dieser Serie).

Zusammenspiel mit EthIf

EthIf abstrahiert jeden Switch-Port als eigenen virtuellen Controller nach oben — für TcpIp/SoAd sieht ein Switch-Port genauso aus wie ein eigenständiger EthTrcv-Controller. Das ist der entscheidende Kniff, der die höheren Kommunikationsschichten davon befreit, zwischen "einfachem Transceiver" und "Switch-Port" zu unterscheiden.

Überblick über die Serie

TeilThema

1 (dieser Post)

Grundlagen, SWS & Architektur — Zustandsautomat, Konfigurationsklassen, Indexing-Schema, Einordnung im Stack

2 — API & Initialisierungssequenz

Die konkreten EthSwt-Funktionsaufrufe und deren Reihenfolge

3 — ARXML-Konfiguration

Container-Struktur, Pflichtparameter, vollständiges Beispiel

4 — VLAN-Management, Mirroring & Diagnose

VLAN-Laufzeitänderungen, Mirroring, MAC-Learning, MIB-Zähler

Darüber hinaus vertiefen mehrere Einzelposts Spezialthemen: Hardware- Architektur (inklusive interner Switch-Fabric und Switch-Stacking), TSN (Stream Identification, Time-Aware Shaping, Frame Preemption), MACsec im Switch, Firewall-Interaktion, Global-Time-Support, ARL-Tabelle/ MAC-Learning sowie Diagnose- und Registerzugriff (SPI/SMI).

Zusammenfassung

AspektKernaussage

Zustandsautomat

Vierstufig: UNINIT → INIT → PORTINIT_COMPLETED → ACTIVE, primär für Development Error Detection gedacht

Konfigurationsklassen

Praktische Parametrisierung (Ports, VLANs, Mirroring) läuft fast ausschließlich über Post-Build-Konfiguration

Indexing-Schema

Zwei getrennte, nullbasierte Indizes: SwitchIdx (welcher Switch) und SwitchPortIdx (welcher Port an diesem Switch)

Architektur im Stack

EthSwt sitzt unter EthIf, hat aber typischerweise mehrere EthTrcv- Instanzen unter sich — eine pro externem Port

Nächster Schritt

Teil 2 zeigt die konkrete API und Initialisierungsreihenfolge von EthSwt

Weiter in der EthSwt-Serie: EthSwt Teil 2 — API & Initialisierungssequenz