DEENESPTFRRUARHIKOZHNL
AUTOSAR_CP_SWS_EthernetDriver FIG-efcf339260c31927 1034 × 648 px 3 Release(s)

Figure 7.1: Basic Structure of the Ethernet BSW stack

SHA-256 Inhalts-Fingerabdruck: efcf339260c319273c3428fab1e88f5426bc9a81084525ec1d1c6b99dd927402

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)

R21-11 → R22-11 keine inhaltliche Änderung Vorgänger: FIG-877e55efe2991733

Keine inhaltlichen Änderungen erkennbar.

R24-11 → R25-11 keine inhaltliche Änderung Nachfolger: FIG-38c8032d2de76d8f

Keine inhaltlichen Änderungen erkennbar.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of Ethernet Driver AUTOSAR CP R24-11 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. Figure 7.1: Basic Structure of the Ethernet BSW stack 7.1.1 Switch Furthermore a Switch device might be connected to a dedicated controller index of an Ethernet Driver. This scenario leads to additional interaction between the Switch Driver and the Ethernet Driver (Figure 7.2). The Ethernet Driver ask the Switch Driver for a special treatment to ensure that the current Ethernet frame could be managed in the Switch later on. 21 of 213 Document ID 430: AUTOSAR_CP_SWS_EthernetDriver

Vorkommen in AUTOSAR-Releases (3)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R22-11 AUTOSAR_SWS_EthernetDriver S. 18 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack
R23-11 AUTOSAR_CP_SWS_EthernetDriver S. 21 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack
R24-11 AUTOSAR_CP_SWS_EthernetDriver S. 21 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack