DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_EthernetDriver FIG-b09c718e2392699c 923 × 583 px 6 Release(s)

Figure 7.1: Basic Structure of the Ethernet BSW stack

SHA-256 Inhalts-Fingerabdruck: b09c718e2392699c937e0c24f23b5c80ae81f04caf27a2dc38561f29496c589d

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

  • Klassifikation: Schichtenmodell / Architektur-Blockdiagramm (AUTOSAR BSW Layered Architecture).
  • Technischer Zweck: Darstellung der Abstraktion und Entkopplung zwischen der hardwareunabhängigen Kommunikationsschnittstelle (EthIf) und hardwarespezifischen Ethernet-Treibern (Eth) im AUTOSAR Classic BSW Communication Stack (R4.0.3).
  • Systemeinordnung: Zeigt die Multi-Vendor- und Multi-Controller-Topologie des Ethernet-Subsystems. Das EthIf konsolidiert heterogene Ethernet-Controller-Hardware (integrierte MACs, externe SPI-Ethernet-Controller) für darüberliegende Schichten (z. B. TcpIp, EthSM, SoAd).

2. Komponenten, Entitäten & Schnittstellen

  • Software-Ebene (Software):
    • Ethernet Interface (EthIf): Zentrales Abstraktionsmodul der MCAL-Abstraktionsschicht. Bietet standardisierte APIs nach oben (TcpIp, EthSM) und aggregiert 1 bis n darunterliegende Treiber.
    • Ethernet Driver (Eth) [Vendor A, Vendor B, Vendor C]: MCAL-Treibermodule. Unterstützung herstellerspezifischer Implementierungen nebeneinander im selben Steuergerät (Multi-Vendor-Support via Vendor-ID-Prefixing).
  • Hardware-Ebene (Hardware):
    • EC Type A, EC Type B, EC Type C (Ethernet Controller): Physische MAC-/Controller-Instanzen.
    • Ethernet physical medium: Das physikalische Übertragungsmedium (z. B. 100BASE-T1, 100BASE-TX).
  • Kardinalitäten & Zuordnungen:
    • EthIf : Eth Driver = 1 : n (Ein EthIf kann parallel Module von Vendor A, B und C ansteuern).
    • Eth Driver : Ethernet Controller = 1 : m (m ≥ 1):
      • Vendor A: 1 Treiber instanziiert/verwaltet 2 Controller desselben Typs (EC Type A).
      • Vendor B: 1 Treiber verwaltet genau 1 Controller (EC Type B).
      • Vendor C: 1 Treiber verwaltet 2 Controller desselben Typs (EC Type C).
    • Ethernet Controller : Physical Medium = n : 1 bzw. separate Ports auf demselben Busmedium.

3. Dynamisches Verhalten & Sequenzablauf

  • Statisches Strukturdiagramm: Kein zeitlicher Ablauf dargestellt.
  • Laufzeit-Interaktionsmuster (abgeleitet):
    • Downlink (TX / Control): Synchrone Funktionsaufrufe von EthIf an den treiberspezifischen Funktionszeiger/API-Entry (z. B. Eth_ProvideTxBuffer, Eth_Transmit, Eth_SetControllerMode). Das Routing erfolgt über den im Index kodierten Controller/Vendor-Deskriptor (CtrlIdx).
    • Uplink (RX / Confirmation): Asynchrone Benachrichtigung über Polling (Eth_MainFunctionRead / Eth_MainFunctionWrite) oder ISRs des jeweiligen Controllers; Weiterleitung an EthIf über Callbacks (EthIf_RxIndication, EthIf_TxConfirmation).

4. Normative Relevanz & Entwickler-Hinweise

  • Multi-Vendor-API-Name-Mangling: Bei Co-Existenz mehrerer Treiber (Vendor A, Vendor B, etc.) fordert AUTOSAR das Vendor-/Driver-Prefixing (z. B. <VendorId>_<ModuleId>_Eth_...), um Symbolkollisionen beim Linken zu verhindern. EthIf dispatcht via Konfigurationstabelle oder Funktionszeiger-Array auf den jeweiligen Treiberschnittstellensatz.
  • Controller-Indizierung (CtrlIdx):
    • Auf Treiberebene ist CtrlIdx treiberlokal (0-basiert je Treibermodul).
    • EthIf verwaltet einen globalen virtuellen CtrlIdx und übersetzt diesen zur Laufzeit auf das Paar (EthDriverInstance, DriverLocalCtrlIdx).
  • Puffer- und Queue-Trennung: Jeder Controller-Typ bzw. Treiber besitzt dedizierte Descriptor-Ringe und DMA-Puffer im RAM. Es gibt keinen controllerübergreifenden Zero-Copy-Speicherpool ohne explizites Software-Routing in oberen Schichten (EthIf/TcpIp).
  • Konfigurationsaspekt: Im BSW-Konfigurator muss für jede Treiberinstanz ein separater Eth-Container gepflegt und im EthIf über EthIfController auf die konkrete Hardware-Instanz referenziert werden (EthIfPhysControllerRef).

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R4.0.3 → R4.1.3 keine inhaltliche Änderung Vorgänger: FIG-a0206718599b65d7

Keine inhaltlichen Änderungen erkennbar.

R20-11 → R21-11 keine inhaltliche Änderung Nachfolger: FIG-877e55efe2991733

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

7 Functional specification 7.1 Ethernet BSW stack As part of the AUTOSAR Layered Software Architecture according to Figure 7.1, the Ethernet BSW modules also form a layered software stack. Figure 7.1 depicts the basic structure of this Ethernet BSW stack. The Ethernet Interface module accesses several controllers using the Ethernet Driver layer, which can be made up of several Ethernet Drivers modules.

Vorkommen in AUTOSAR-Releases (6)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R4.1.3 AUTOSAR_SWS_EthernetDriver S. 14 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack
R4.2.2 AUTOSAR_SWS_EthernetDriver S. 20 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack
R4.3.1 AUTOSAR_SWS_EthernetDriver S. 17 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_EthernetDriver S. 16 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack
R19-11 AUTOSAR_SWS_EthernetDriver S. 15 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack
R20-11 AUTOSAR_SWS_EthernetDriver S. 15 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack