Figure 7.42: Example for autonomous wake-up due to OS system call

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm (Interaktionsdiagramm) mit Interaktionsbereichen (Interaction Frames/Dividers) und Zustandsannotationen.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster State Management (ara::sm), Release R25-11.
• Technischer Zweck: Spezifikation des Zusammenspiels beim Übergang in den stromsparenden Ruhezustand Suspend-To-RAM (S2R) und des anschließenden, durch das Betriebssystem (OS) initiierten autonomen Aufwachprozesses (Autonomous Wake-up).

2. Komponenten, Entitäten & Schnittstellen

• OS: Basisbetriebssystem (POSIX/RTOS) inkl. Hardware-/Power-Management-Treiberschicht.
• apext::sm::PowerStateInterface («C++ API»): Adaptive Platform Extension Interface (herstellerspezifische Plattform-Erweiterung) zur Kapselung hardwarenaher OS-/BSP-Power-State-Systemaufrufe.
• ara::sm::s2r::S2RHub («C++ API»): Standardisierte interne C++-Schnittstelle innerhalb des State Managements zur Orchestrierung von Suspend-to-RAM-Abläufen.
• State Management («process»): Zentraler System-Dämon/Prozess des Functional Clusters ara::sm, verantwortlich für Regelverarbeitung (ActionLists), Moduswechsel und Zustandsverwaltung des Controllers/der Machine.
• StateMachineService («Service»): Serviceorientierte Schnittstelle (ara::com), über welche Steuerungsapplikationen (z. B. SmControlApplication) Transitionsanforderungen an das State Management übermitteln.

3. Dynamisches Verhalten & Sequenzablauf

Phase 1: Transition to Suspend-To-RAM mode

1. Ausgangszustand: Controller befindet sich im regulären Betrieb (Controller == Normal Mode).
2. Transitionsanforderung: Die Steuerungslogik (SmControlApplication) fordert via StateMachineService synchron/asynchron den Zustandswechsel an: $RequestTransition(trigger Y)$
3. Aktionslistenverarbeitung: State Management evaluiert den Trigger und führt die konfigurierte ActionList im Frame Controller transition to Suspend state aus.
4. OS-Suspend-Kaskade:
   • Aufruf von EnterSuspendToRamOs an ara::sm::s2r::S2RHub.
   • Weiterleitung via Suspend-To-RAM an apext::sm::PowerStateInterface.
   • Niedrigster Treiber-/Systemaufruf an das OS: $SetPowerState(kPmSuspendToRam)$
5. Ruhezustand: Das OS friert den Kontext ein; der Controller verharrt im Zustand Controller == Suspend (roter Balken kennzeichnet inaktive CPU-/OS-Ausführung).

Phase 2: OS notifies wake-up

1. Hardware-Trigger: Ein externes Wake-up-Event (z. B. CAN-Transceiver, Wake-up-Timer, GPIO-Interrupt) weckt das Betriebssystem auf.
2. Benachrichtigungskette:
   • OS signalisiert wake-up an apext::sm::PowerStateInterface.
   • PowerStateInterface leitet dieses Ereignis implementierungsspezifisch weiter (forward notification [implementation specific], gestrichelte Nachricht) an den Prozess State Management.
3. Autonome Transition:
   • State Management führt ohne externe Service-Interaktion einen internen Zustandswechsel durch: $$\text{autonomous transition for Controller to LeaveSuspend state}$$
4. Folgezustand: Controller == LeaveSuspend (Vorbereitung zur Reinitialisierung der Funktionsgruppen und Peripherie).

4. Normative Relevanz & Entwickler-Hinweise

• Architektonische Trennung (ara vs. apext): Die Transition nutzt standardisierte APIs (ara::sm::s2r::S2RHub), delegiert die eigentliche Hardware-/OS-Interaktion jedoch zwingend an den Extension-Namespace apext::sm. BSP-/Plattform-Integratoren müssen apext::sm::PowerStateInterface OS-spezifisch implementieren (z. B. via Linux /sys/power/state, QNX Power Manager oder Hypervisor-Calls).
• Asymmetrie Einschlafen vs. Aufwachen: Während das Versetzen in den Suspend-Zustand durch eine Applikationsanforderung (RequestTransition) ausgelöst wird, erfolgt das Verlassen des Suspend-Zustands strikt autonom über OS-Interrupts. Applikationen können keinen Wake-up-Request stellen, da deren Threads während Controller == Suspend angehalten sind.
• Konfiguration der State-Management-Regeln: Integratoren müssen in den ARXML-Modellen des State Managements sicherstellen, dass:
  • Trigger Y exakt auf die ActionList mit EnterSuspendToRamOs gemappt ist.
  • Ein autonomer Übergang für den Eingang der OS-Wake-up-Notification definiert ist, der den Controller kontrolliert von Suspend nach LeaveSuspend überführt, bevor Applikationsprozesse durch das Execution Management wieder freigegeben werden.