Figure 9: 2.1: asynchronous power state setting.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des zweiphasigen asynchronen Power-State-Übergangs (Power State Transition) von MCAL-Peripherietreibern über die I/O Hardware Abstraction (IoHwAb).
• Architektur-Einordnung:
  • Eingebettet in das AUTOSAR Classic Platform (CP) Mode- und Power-Management (ab Release 4.1).
  • Die IoHwAb fungiert als Aggregator und Zustandsvermittler zwischen dem systemweiten Modus-Management (BswM via Rte/SchM) und den hardwarenahen MCAL-Treibern (z. B. Adc, Pwm), um komplexe Energiesparmodi ohne Blockierung des Steuergeräts deterministisch zu koordinieren.

2. Komponenten, Entitäten & Schnittstellen

• Beteiligte Module («module» Lifelines):
  • BswM (Basic Software Mode Manager): Übergeordneter Master für Zustandsübergänge, initiiert Mode-Switches und konsumiert Abschlussquittierungen.
  • Rte (Runtime Environment / SchM): Signal- und Ausführungsvermittler für Mode-Switch-Events und Task-Trigger.
  • IoHwAb (I/O Hardware Abstraction): Zentraler Orchestrator; kapselt Peripherie-spezifische Power-States in ECU-spezifische Modi (LowPowerModeA, LP1).
  • Adc / Pwm (Microcontroller Abstraction Layer Modules): Untergeordnete Hardwaretreiber mit standardisierten Power-State-APIs (<MSN>_...).
• Schnittstellen & Callbacks:
  • RTE/SchMSwitch(char) / RTE/SchMSwitch(LowPowerModeA_Transition_End): Modus-Umschaltanforderung bzw. -Rückmeldung via Mode Declaration Group Ports.
  • OnEntryRunnable_LowPowerModeA(): Entry-Runnable der IoHwAb, ausgelöst bei Eintritt in den Übergangsmodus.
  • IoHwAb_PollForResults(): Periodisches Runnable der IoHwAb zur Synchronisationsüberwachung.
  • MCAL Synchronous Query APIs: Adc_GetCurrentPowerState(), Pwm_GetCurrentPowerState().
  • MCAL Async Preparation APIs: Adc_PreparePowerState(PwrSts_1), Pwm_PreparePowerState(PwrSts_3).
  • MCAL Completion Callbacks: IoHwAb_Pwm_NotifyReadyForPowerStateLowPowerModeA(), IoHwAb_Adc_NotifyReadyForPowerStateLowPowerModeA().
  • MCAL Target State Setting APIs: Adc_SetPowerState(), Pwm_SetPowerState().

3. Dynamisches Verhalten & Sequenzablauf

1. Triggerung & Phase 1 (Preparation Request):
   • BswM triggert über RTE/SchMSwitch den Moduswechsel.
   • Die Rte aktiviert die Entry-Funktion OnEntryRunnable_LowPowerModeA() der IoHwAb.
   • IoHwAb führt intern IoHwAb_PreparePowerState_LowPowerModeA() aus.
   • IoHwAb liest den Ist-Zustand über <MSN>_GetCurrentPowerState() von Adc und Pwm aus.
   • IoHwAb ruft <MSN>_PreparePowerState(<TargetState>) synchron auf beiden Treibern auf. Die APIs kehren sofort zurück; die eigentliche Hardware-Vorbereitung startet asynchron im Hintergrund.
2. Hintergrundausführung & Synchronisation:
   • Die MCAL-Treiber wickeln die Vorbereitung (z. B. Beenden laufender ADC-Sequenzen, Auslaufen/Ramp-Down von PWM-Perioden) getrieben durch <MSN>_Main_PowerStateTransitionManager() im Hintergrund ab.
   • PeriodicTask() ruft wiederkehrend IoHwAb_PollForResults() auf; solange Quittierungen fehlen, verbleibt das System im Wartezustand.
   • Nach erfolgreicher Vorbereitung signalisieren die Treiber ihre Bereitschaft über konfiguierte Callbacks an die Abstraktionsschicht:
     • IoHwAb_Pwm_NotifyReadyForPowerStateLowPowerModeA()
     • IoHwAb_Adc_NotifyReadyForPowerStateLowPowerModeA()
3. Phase 2 (Set Power State & Quittierung):
   • Beim nächsten Zyklus von IoHwAb_PollForResults() erkennt die IoHwAb die Vollständigkeit aller Benachrichtigungen (Barriere-Synchronisation) und ruft IoHwAb_EnterPowerStateLP1() auf.
   • Ausführung der harten Umschaltung über die synchronen APIs Adc_SetPowerState() und Pwm_SetPowerState().
   • IoHwAb quittiert den Abschluss über RTE/SchMSwitch(LowPowerModeA_Transition_End) an die Rte.
   • Rte aktualisiert die BswM-Modusports via UpdateModePorts().

4. Normative Relevanz & Entwickler-Hinweise

• 2-Phasen-Commit-Pattern: MCAL-Treiber dürfen in Phase 1 (Prepare) keine harten Takt-/Registerabschaltungen vornehmen, sondern müssen flüchtige Operationen geordnet terminieren und neue Requests sperren. Erst in Phase 2 (Set) erfolgt die physikalische Modusumschaltung.
• BSW-Scheduling & Background-Tasks:
  • Das asynchrone Verhalten setzt zwingend voraus, dass <MSN>_Main_PowerStateTransitionManager() im OS-Taskplan für die betroffenen MCAL-Module konfiguriert ist.
  • IoHwAb_PollForResults muss auf einem periodischen Basic-Task gemappt sein, um Race Conditions zwischen Callbacks und State-Setting zu vermeiden.
• Konfigurationsabhängigkeiten (BSW Management & IoHwAb):
  • Zuordnung der generischen ECU-Power-Modes zu den modulspezifischen PowerState-Enums (z. B. PwrSts_1, PwrSts_3) erfolgt statisch in der IoHwAb-Konfiguration.
  • Die Callbacks (IoHwAb_<MSN>_NotifyReadyFor...) müssen im MCAL-Treiber als Benachrichtigungsschnittstellen für Power-State-Transitions projektiert werden.
• Fehlerbehandlung & Timeouts: Im realen Serieneinsatz muss die IoHwAb oder der BswM einen Timeout-Mechanismus vorhalten, falls ein MCAL-Treiber aufgrund von Hardwarefehlern den Vorbereitungszustand nicht erreicht und den Callback blockiert.