DEENESPTFRRUARHIKOZHNL
AUTOSAR_CP_SWS_EthernetDriver FIG-38c8032d2de76d8f 923 × 579 px 1 Release(s)

Figure 7.1: Basic Structure of the Ethernet BSW stack

SHA-256 Inhalts-Fingerabdruck: 38c8032d2de76d8f2e6c93aa779cb579bf133e280674859440b5cf85ac19d484

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)

R24-11 → R25-11 keine inhaltliche Änderung Vorgänger: FIG-efcf339260c31927

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 R25-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 using the driver API abstraction of the EthIf (Figure 7.2). The Ethernet Driver asks the Switch Driver for a special treatment to ensure that the current Ethernet frame could be managed in the Switch later on. 23 of 203 Document ID 430: AUTOSAR_CP_SWS_EthernetDriver

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R25-11 AUTOSAR_CP_SWS_EthernetDriver S. 23 7.1 Figure 7.1: Basic Structure of the Ethernet BSW stack