Figure 9.2: Asynchronous power state setting

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm).
• Technischer Zweck: Spezifikation des zweiphasigen, asynchronen Energie-Zustandswechsels (Asynchronous Power State Setting) von Peripheriemodulen über die I/O Hardware Abstraction (IoHwAb).
• Funktionale Einordnung: AUTOSAR Classic Platform (R24-11), AUTOSAR_CP_SWS_IOHardwareAbstraction. Das Diagramm bildet das Zusammenspiel zwischen Modus-Management (BswM), Laufzeitumgebung/Scheduler (Rte/SchM), Hardware-Abstraktionsschicht (IoHwAb) und den MCAL-Treibern (Adc, Pwm) ab, um Peripheriegeräte ohne Blockierung des BSW-Schedulers in stromsparende Zustände zu überführen.

2. Komponenten, Entitäten & Schnittstellen

• Module & Akteure (Stereotyp «module»):
  • BswM: Basic Software Mode Manager (Master für Moduswechsel-Entscheidungen).
  • Rte: Runtime Environment / Basic Software Scheduler (SchM) als Entkopplungs- und Event-Dispatcher.
  • IoHwAb: I/O Hardware Abstraction Module (Aggregator und Koordinator der MCAL-Power-States; dargestellt als aktive Komponente mit internem Kontrollfluss).
  • Adc, Pwm: Exemplarische MCAL-Treiber mit Power-State-Unterstützung gem. AUTOSAR-Hardwaretreiber-Spezifikation.
• Schnittstellen & Operationen:
  • Modus-Umschaltung:
    • RTE/SchMSwitch(char): Asynchrone/synchrone Modus-Anforderung durch den BswM.
    • RTE/SchMSwitch(LowPowerModeA_Transition_End): Vollzugsmeldung der IoHwAb an die RTE/SchM.
    • UpdateModePorts(): Aktualisierung der Mode-Ports in Richtung BswM.
  • Task- & Runnable-Aktivierung:
    • OnEntryRunnable_LowPowerModeA(): Modus-Eintritts-Runnable der IoHwAb.
    • PeriodicTask(): Zyklischer OS-Task zur periodischen Abarbeitung der IoHwAb-Zustandsüberwachung.
  • MCAL Power-State-APIs (gemäß SWS der jeweiligen Treiber):
    • <MSN>_GetCurrentPowerState() (Adc_GetCurrentPowerState, Pwm_GetCurrentPowerState): Synchrones Auslesen des aktiven Leistungszustands.
    • <MSN>_PreparePowerState(PwrSts_x) (Adc_PreparePowerState(PwrSts_1), Pwm_PreparePowerState(PwrSts_3)): Start der asynchronen Vorbereitungsphase im MCAL-Treiber.
    • <MSN>_SetPowerState() (Adc_SetPowerState, Pwm_SetPowerState): Synchrones Wirksamschalten des vorbereiteten Leistungszustands.
    • <MSN>_Main_PowerStateTransitionManager(): Treiberinterne zyklische Funktion zur Abwicklung der Vorbereitung.
  • Treiber-Callbacks zu IoHwAb:
    • IoHwAb_Pwm_NotifyReadyForPowerStateLowPowerModeA()
    • IoHwAb_Adc_NotifyReadyForPowerStateLowPowerModeA()
  • Interne IoHwAb-Routinen:
    • IoHwAb_PreparePowerState_LowPowerModeA(): Initiiert MCAL-Vorbereitungen.
    • IoHwAb_PollForResults(): Prüfroutine zur Verifikation aller eingetroffenen Callbacks.
    • IoHwAb_EnterPowerStateLP1(): Leitet Phase 2 (Umschaltung) ein.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Phase 1 (Prepare-Phase):
   • BswM schaltet via RTE/SchMSwitch in den Zielmodus.
   • Rte aktiviert die Mode-Entry-Runnable OnEntryRunnable_LowPowerModeA() der IoHwAb.
   • IoHwAb führt IoHwAb_PreparePowerState_LowPowerModeA() aus:
     • Fragt initial via Adc_GetCurrentPowerState() und Pwm_GetCurrentPowerState() synchron den Status ab.
     • Ruft Adc_PreparePowerState(PwrSts_1) und Pwm_PreparePowerState(PwrSts_3) auf.
   • Nach Return der PreparePowerState-Aufrufe läuft die Vorbereitung hardwarenah im Hintergrund, getrieben durch <MSN>_Main_PowerStateTransitionManager().
   • OnEntryRunnable_LowPowerModeA() terminiert; der BSW-Task blockiert nicht.
2. Synchronisation & Callback-Polling:
   • Ein zyklischer Scheduler-Aufruf (PeriodicTask()) ruft IoHwAb_PollForResults() auf. Da Notifikationen noch ausstehen, erfolgt kein Zustandswechsel.
   • Treiber melden die Bereitschaft asynchron über konfigurierte Callbacks an die IoHwAb:
     • Pwm -> IoHwAb_Pwm_NotifyReadyForPowerStateLowPowerModeA()
     • Adc -> IoHwAb_Adc_NotifyReadyForPowerStateLowPowerModeA()
3. Phase 2 (Set-Phase & Transition-Abschluss):
   • Beim nachfolgenden PeriodicTask()-Aufruf erkennt IoHwAb_PollForResults(), dass alle Notifikationen vorliegen.
   • IoHwAb verzweigt in IoHwAb_EnterPowerStateLP1():
     • Ruft Adc_SetPowerState() auf (Hardware schaltet endgültig um).
     • Ruft Pwm_SetPowerState() auf.
   • IoHwAb meldet den Abschluss via RTE/SchMSwitch(LowPowerModeA_Transition_End) an die RTE.
   • Die RTE aktualisiert die Mode-Ports (UpdateModePorts()) des BswM. Der Moduswechsel ist abgeschlossen.

4. Normative Relevanz & Entwickler-Hinweise

• Zweistufiger API-Vertrag (Prepare vor Set): Hardware mit Einschwingzeiten (z. B. PLL-Deaktivierung, Entladung von ADC-Referenzen, PWM-Shutdown) darf im Stack keine blockierenden Warteroutinen erzeugen. Treiber müssen *PreparePowerState sofort verlassen (E_OK) und die asynchrone Hardwareanpassung in <MSN>_Main_PowerStateTransitionManager betreiben.
• Konfigurationsabhängigkeiten (ARXML/BSW-Konfiguration):
  • In den MCAL-Modulen (Adc, Pwm) muss der Parameter <MSN>LowPowerStatesSupport aktiviert sein.
  • Die Callback-Funktionsnamen (IoHwAb_<MSN>_NotifyReadyForPowerState<Mode>) müssen in der Treiber-Konfiguration als Notifikationsfunktionen exakt den C-Symbolen der IoHwAb entsprechen.
• Implementierungsanforderung an IoHwAb:
  • IoHwAb muss eine Zustandsmaschine mit Bitmaske/Zähler vorhalten, die im Concurrency-Kontext (Aufruf aus Interrupt oder Scheduler-Task) thread-sicher registriert, welche Treiber ihre Bereitschaft gemeldet haben.
  • Die IoHwAb_PollForResults()-Logik muss in einer periodischen MainFunction (IoHwAb_MainFunction) laufen, um Deadlocks bei ausbleibenden Treiber-Meldungen (Timeout-Handling) abzufangen.
• BswM-Interaktion: Der BswM darf abhängige Aktionen (z. B. EcuM_GoHalt / EcuM_GoPoll) erst nach Empfang des SchM-Switches LowPowerModeA_Transition_End triggern, um Peripherieabschaltungen während laufender Zugriffe auszuschließen.