Figure 9.1: Initialization

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Architektur-Kontext: Start-/Initialisierungsphase des FlexRay-Kommunikationsstacks innerhalb der AUTOSAR Classic Platform (System Service Layer & Communication Stack).
• Funktionaler Zweck: Festlegung der synchronen Aufruf- und Abhängigkeitsreihenfolge bei der Basiskomponenten-Initialisierung (BSW Initialization Phase) durch den ECU State Manager (EcuM) für die FlexRay-Komponenten Interface (FrIf) und State Manager (FrSM).

2. Komponenten, Entitäten & Schnittstellen

• Teilnehmer (Lifelines mit Stereotyp «module»):
  • EcuM (Paket: EcuM_fix): Initialisierungs-Master / Orchestrator der BSW-Treiber und Schnittstellen vor dem Anlauf des Schedulers / OS.
  • ComM (Paket: ComM): Communication Manager; im Diagramm als passiver Architektur-Akteur des Kommunikationsclusters aufgeführt (nimmt zu diesem Zeitpunkt noch keine aktiven Steuerungsaufrufe entgegen).
  • FrSM (Paket: FrSm): FlexRay State Manager; verwaltet die clusterbezogenen FlexRay-Zustandsübergänge.
  • FrIf (Paket: FrIf): FlexRay Interface; abstrahiert die FlexRay-Treiber-Hardware (Fr), Transceiver (FrTrcv) und Controller für die oberen Schichten.
• Schnittstellen & Signaturen:
  • FrIf_Init(const FrIf_ConfigType* ConfigPtr): Synchroner Aufruf zur Initialisierung des FlexRay Interface.
  • FrSm_Init(const FrSM_ConfigType* FrSM_ConfigPtr): Synchroner Aufruf zur Initialisierung des FlexRay State Managers.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Vorbedingung:
   • Das System befindet sich in der Startphase des EcuM (z. B. Phase EcuM_AL_DriverInitTwo bzw. BSW-Init-Block gemäß BSW-Scheduler-/EcuM-Konfiguration).
   • Alle unteren Treiberschichten (Fr, FrTrcv) sind bereits initialisiert.
2. Schritt 1 – Initialisierung FrIf:
   • Synchroner Aufruf FrIf_Init(ConfigPtr) durch EcuM.
   • FrIf schließt die interne Konfiguration ab und kehrt synchron zum EcuM zurück.
3. Schritt 2 – Initialisierung FrSM:
   • Zwingend sequentiell nachgelagerter synchroner Aufruf FrSm_Init(FrSM_ConfigPtr) durch EcuM.
   • FrSM wechselt intern vom Zustand FRSM_UNINIT in den Grundzustand (z. B. FRSM_READY mit Clusterzustand FRSM_CLUSTER_OFF bzw. Startup-Bereitschaft).
   • Synchroner Return zum EcuM.
4. Rolle von ComM:
   • ComM wird erst nach Abschluss der BSW-Init-Phase aktiviert und triggert nachfolgend im operativen Betrieb Kommunikationsanfragen (ComM_RequestComMode) an den FrSM.

4. Normative Relevanz & Entwickler-Hinweise

• Strikte Init-Reihenfolge (SWS-Regel): FrIf_Init() muss zwingend vor FrSm_Init() ausgeführt werden. Ein vorzeitiger Aufruf von FrSm_Init() führt zu undefiniertem Verhalten oder DET-Fehlern (FRSM_E_UNINIT / Aufruf nicht initialisierter FrIf-APIs).
• Konfigurationszeiger: Beide Funktionen erwarten Zeiger auf die Post-Build- bzw. Link-Time-Konfigurationsstrukturen (FrSM_ConfigPtr, ConfigPtr). Ist FrSM als VARIANT-PRE-COMPILE konfiguriert, ist NULL_PTR normativ zulässig, sofern in der Konfiguration definiert.
• API-Restriktionen vor Init: Vor Rückkehr aus FrSm_Init() dürfen keine Request- oder MainFunction-Aufrufe (FrSm_MainFunction_<ClusterId>(), FrSm_RequestComMode()) abgesetzt werden; Aufrufe vor Initialisierung müssen durch das Modul mit dem Development Error FRSM_E_UNINIT verworfen werden.
• BswM/EcuM-Konfiguration: In moderneren AUTOSAR-Architekturen (Release 4.x / R20-11+) wird diese Sequenz typischerweise über BSW-Management-Action-Lists (BswM) im Rahmen der Startup-Regeln modelliert; die funktionale Sequenzierung FrIf → FrSM bleibt strikt verbindlich.