Figure 3: Pwm initialization

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (UML 2.x Sequence Diagram) mit annotierter Spezifikationsnotiz (Note Box).
• Kontext: AUTOSAR Classic Platform (CP), Schicht: Microcontroller Abstraction Layer (MCAL), Modulfamilie: I/O Drivers.
• Technischer Zweck: Spezifikation der synchronen Initialisierungssequenz des PWM-Treibers (Pwm) durch eine übergeordnete BSW-Instanz vor dem Übergang in den operativen Kanalbetrieb.

2. Komponenten, Entitäten & Schnittstellen

• Lifelines / Rollen:
  • Pwm User: Übergeordneter Aufrufer; im AUTOSAR-Standard typischerweise der ECU State Manager (EcuM) im Rahmen der Startup-Phase (z. B. EcuM_AL_DriverInitList) oder ein komplexer Treiber (CDD) bzw. die IoHwAb.
  • Pwm («module»): MCAL-Treibermodul zur hardwarenahen Ansteuerung der PWM-Peripherie / Timer-Einheiten.
• Schnittstellen & Datenstrukturen:
  • Pwm_Init(const Pwm_ConfigType* ConfigPtr): Synchroner, nicht wiedereintrittsfähiger Service-Aufruf zur Hardware- und Modulinitialisierung.
  • Pwm_ConfigType: Modulspezifische Konfigurationsstruktur (abhängig von der Konfigurationsvariante Pre-Compile, Link-Time oder Post-Build Selectable/Loadable) zur Definition von Kanal-Prescalern, Perioden, Duty Cycles, Polaritäten und Default-Zuständen.
  • Return-Pfeil Pwm_Init(): Synchrone Rückkehr der Ausführungskontrolle an den Aufrufer (Rückgabetyp void).

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger: System-Startup / Modulstartsequenz durch den Pwm User.
2. Aufruf: Pwm User ruft Pwm_Init(...) auf und übergibt die Basisadresse der Konfigurationsdatenmenge (const Pwm_ConfigType*).
3. Treiber-interne Abarbeitung:
   • Konfiguration der zugewiesenen Hardware-Timer, Taktteiler und Ausgangspins.
   • Initialer Signalzustand: Die physikalischen Ausgangssignale werden entsprechend den konfigurierten Kanalparametern deterministisch auf LOW-Pegel, HIGH-Pegel oder direkt in den aktiven Modulationszustand (Modulation State) gesetzt.
   • Notification-Status: Sämtliche kanalbezogenen Interrupts und Callbacks verbleiben deaktiviert. Unabhängig von der statischen Konfiguration werden erst nach explizitem Aufruf von Pwm_EnableNotification() Ereignisse gemeldet.
4. Rückkehr: Nach erfolgreicher Registerkonfiguration wechselt der Treiberstatus auf initialisiert (PWM_INITIALIZED), und die Ausführung kehrt zum Pwm User zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Prä- und Postconditions:
  • Vor Ausführung von Pwm_Init() darf kein funktionaler API-Aufruf auf Kanalebene (z. B. Pwm_SetDutyCycle, Pwm_SetPeriodAndDuty) erfolgen. Bei aktivem DET wird der Fehler PWM_E_UNINIT ausgelöst.
  • Ein mehrfacher Aufruf ohne vorheriges Pwm_DeInit() führt bei aktiviertem Default Error Tracer zur Meldung von PWM_E_ALREADY_INITIALIZED.
• Konfigurationszeiger-Validierung:
  • Bei Post-Build-Konfigurationen (VARIANT-POST-BUILD) muss ein gültiger Zeiger auf die Pwm_ConfigType-Struktur übergeben werden; die Übergabe von NULL_PTR führt zu PWM_E_PARAM_POINTER.
  • Bei reiner Pre-Compile-Konfiguration (VARIANT-PRE-COMPILE) kann der Parameter laut SWS implementationsspezifisch mit NULL_PTR belegt werden.
• Hardware- & Safety-Relevanz (Aktuatorik):
  • Entwickler müssen sicherstellen, dass die in der Konfiguration hinterlegten Initialpegel (Polarität und Idle-Zustand) mit der nachgeschalteten Hardware (z. B. H-Brücken-Treiber, Leistungsendstufen) harmonieren, um unerwünschte Transienten oder Kurzschlüsse unmittelbar nach dem Controller-Reset zu vermeiden.
• Notification-Gating:
  • Benachrichtigungen für Regelkreise müssen im Anschluss an die Initialisierung für jeden Kanal separat über Pwm_EnableNotification(Channel) scharfgeschaltet werden. Ein automatisches Feuern von Interrupts direkt aus Pwm_Init() heraus ist normativ ausgeschlossen.