Figure 5: Initialization

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation der normativen Initialisierungsreihenfolge des AUTOSAR Ethernet-Kommunikationsstacks während der ECU-Startup-Phase (EcuM Driver Initialization List).
• Funktionale Einordnung: Vertikale Schichtenarchitektur der AUTOSAR Classic Platform (R4.0.3) vom System Service (EcuM) über die Hardware-Abstraktionsschicht (EthIf, EthTrcv) bis zur Microcontroller Abstraction Layer (MCAL, Eth).

2. Komponenten, Entitäten & Schnittstellen

Beteiligte Module (Akteure / Lifelines)

• «module» :EcuM: ECU State Manager (System Services Layer) – Orchestrator der BSW-Initialisierungssequenz.
• «module» :EthIf: Ethernet Interface (Communication Hardware Abstraction Layer) – Abstrahiert mehrere Ethernet-Controller und Transceiver für obere Schichten (z. B. TcpIp, EthSM).
• «module» :Eth: Ethernet Driver (MCAL) – Direkte Hardware-Ansteuerung des MAC-Controllers (Media Access Control) und der MII/MDIO-Management-Schnittstelle.
• «module» :EthTrcv: Ethernet Transceiver Driver (Hardware Abstraction / Onboard Device Driver) – Logische Ansteuerung des externen oder integrierten PHY-Bausteins.

Schnittstellen & Datenstrukturen

• EthIf_Init(const EthIf_ConfigType* ConfigPtr): Initialisierung des Ethernet Interfaces anhand des statischen/Post-Build-Konfigurationssatzes.
• Eth_Init(const Eth_ConfigType* ConfigPtr): Hardware-nahe Initialisierung der MAC-Controller-Instanz(en), DMA-Ringe und Puffer-Deskriptoren.
• EthTrcv_Init(const EthTrcv_ConfigType* ConfigPtr): Grundinitialisierung des Transceivers/PHYs.
• Eth_WriteMii(uint8 CtrlIdx, uint8 TrcvIdx, uint8 RegIdx, uint16 RegVal) (im Diagrammtext als Eth_WriteMii(Eth_ReturnType, uint8, uint8, uint8, uint16) notiert): Synchroner MII/MDIO-Buszugriff über den MAC zur Konfiguration der internen PHY-Register.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: Aufruf der BSW-Initialisierungsphase durch den State Manager (EcuM) im Zuge des Hochlaufs (z. B. EcuM_AL_DriverInitTwo).
2. Phase 1 – Initialisierung EthIf: EcuM ruft synchron EthIf_Init(&EthIf_Config) auf. EthIf wechselt in den Zustand ETHIF_STATE_INIT, setzt interne Zustandsvariablen zurück und kehrt zum EcuM zurück.
3. Phase 2 – Initialisierung Eth (MAC): EcuM ruft synchron Eth_Init(&Eth_Config) auf. Der MAC-Treiber konfiguriert die Hardware-Register, Clocks, Interrupts sowie TX/RX-Deskriptoren und meldet Bereitschaft an EcuM zurück.
4. Phase 3 – Initialisierung EthTrcv (PHY): EcuM ruft synchron EthTrcv_Init(&EthTrcv_Config) auf.
5. Phase 3a – MII-Registerzugriff (Querbeziehung): Innerhalb der Ausführung von EthTrcv_Init ruft der EthTrcv-Treiber synchron Eth_WriteMii(...) auf, um grundlegende PHY-Register (z. B. Basic Control Register, Autonegotiation-Parameter, Power-Down-Bit) über das MII-Management-Interface (MDIO/MDC) des Ethernet-Controllers zu programmieren. Nach erfolgreichem Schreiben kehrt der Call zu EthTrcv und anschließend zu EcuM zurück.
6. Ausführungspfad: Rein synchrone C-Funktionsaufrufe (Blocking Calls); keine asynchronen Callbacks, Det-Aufrufe oder Fehlerpfade im Diagramm expliziert.

4. Normative Relevanz & Entwickler-Hinweise

• Strikte Abhängigkeitsreihenfolge: Eth_Init muss zwingend vor EthTrcv_Init ausgeführt werden. Da EthTrcv_Init über Eth_WriteMii auf das MII-Management-Interface des MACs zugreift, schlägt die Transceiver-Initialisierung fehl (oder führt zu einem Hardware-Hang/Timeout), wenn das MII-Interface im MAC-Controller noch nicht getaktet und betriebsbereit ist.
• Orchestrierung durch EcuM: Entgegen anderen Stacks (z. B. CAN/LIN in späteren Releases) kapselt EthIf in AUTOSAR R4.0.3 nicht die Initialisierung der unterlagerten Treiber: EthIf, Eth und EthTrcv müssen separat und explizit in der passenden EcuMDriverInitList konfiguriert werden.
• Schnittstellen-Vertrag Eth_WriteMii: Die Implementierung von Eth_WriteMii muss während der Initialisierungsphase synchron (polling-basiert auf MDIO-Busy-Flag) arbeiten, da das Betriebssystem (Os) und die Interrupt-Verarbeitung in frühen EcuM-Phasen typischerweise noch nicht aktiv sind.
• Konfigurationszeiger: Gültige Zeiger auf die jeweiligen typspezifischen Datenstrukturen (const *_ConfigType*) müssen vor dem Aufruf durch die EcuM-Post-Build-Auflösung (EcuM_GetConfig()) sichergestellt sein. Für reine Pre-Compile-Varianten wird typischerweise NULL_PTR übergeben.