Figure 7.39: Example for entering Suspend-To-RAM mode.

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Sequenzdiagramm (Interaktionsdiagramm mit kombinierten Fragmenten loop und alt).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Spezifikation State Management (SWS_StateManagement, R25-11).
• Technischer Zweck: Spezifikation des standardisierten, zweiphasigen Ablaufs zum Versetzen der Machine in den Energiesparmodus Suspend-To-RAM (S2R). Es visualisiert das koordinierte Zusammenspiel zwischen externer Kontrolllogik, dem State Management (SM), den angemeldeten Adaptive Applications und dem zugrunde liegenden Betriebssystem (OS).

2. Komponenten, Entitäten & Schnittstellen

• «Adaptive application» SmControlApplication: Projekt-/fahrzeugspezifische Steuerapplikation, die als Träger der Zustandsentscheidung fungiert (z. B. Power-Manager/Fahrzeugzustandslogik).
• Boundary State Management:
  • «Service» StateMachineService: Service-Schnittstelle (ara::com / IPC), über die externe Applikationen Zustandsübergänge im SM anfordern (RequestTransition).
  • «StateMachine» Controller: Kern-Zustandsmaschine des State Managements zur Validierung von Triggern, Ausführung von Zustandsübergängen und Abarbeitung konfigurierter ActionLists.
  • «C++ API» ara/sm/s2r/S2RHub: Zentraler Mediator/Hub innerhalb des SM zur Verwaltung und Koordination aller für S2R registrierten Applikationen sowie der OS-Schnittstelle.
• Boundary Adaptive Applications:
  • «C++ API - Skeleton» ara::sm::s2r::S2RSatellite: Bibliotheks-/Skeleton-Instanz auf Seite der Nutzerapplikationen, die Callbacks für den S2R-Eintritt empfängt und den Quiescing-Status an den Hub quittiert.
• OS: Host-Betriebssystem / POSIX-Kernel / BSP, das den hardwarenahen Suspend-To-RAM-Syscall bzw. Power-Transition-Befehl ausführt.

3. Dynamisches Verhalten & Sequenzablauf

Initialzustand & Trigger

• Der Controller befindet sich im Zustand Normal Mode.
• SmControlApplication ermittelt anhand interner Logik den Zielzustand (Suspend oder FullSuspend) und ruft RequestTransition(trigger X) auf dem StateMachineService auf.
• StateMachineService leitet trigger X an den Controller weiter.
• Der Controller prüft den Trigger (valid trigger?), führt den Zustandsübergang aus (transit to Suspend state → Controller == Suspend) und startet die Abarbeitung der zugeordneten ActionList.

Phase 1: Applikations-Quiescing (Request Suspend-To-RAM to Adaptive Applications)

1. Hub-Ansteuerung: Der Controller ruft EnterSuspendToRam auf ara/sm/s2r/S2RHub auf, welcher intern RequestToEnterSuspendMode auslöst.
2. Loop über registrierte Applikationen ([For each registered application]):
   • Aufruf von EnterSuspendMode() an jedem S2RSatellite.
   • Die Zielapplikation führt lokale Vorbereitungen durch (Preparation for S2R: z. B. I/O stoppen, flüchtige Caches auf persistenten Speicher flashen, Thread-Aktivitäten anhalten).
   • Der Satellit quittiert mit OK.
3. Verzweigung (alt):
   • Erfolgsfall ([All Applications respond successfully]):
     • S2RHub meldet EnterSuspendToRam::OK an den Controller.
     • Sequenz fährt mit Phase 2 fort.
   • Fehlerfall (Alternativpfad):
     • Mindestens ein Satellit schlägt fehl oder antwortet nicht → S2RHub meldet EnterSuspendToRam::NOK.
     • Controller signalisiert trigger X:NOK an StateMachineService.
     • StateMachineService quittiert den Request an SmControlApplication mit dem Fehlercode RequestTransition(trigger X):kOperationFailed.
     • Es wird eine lokale/projektierte Fehlerbehandlung initiiert (Recovery action will be started); das System geht nicht in den OS-Suspend.

Phase 2: Hardware-Suspend (Request Suspend-To-RAM to OS)

1. Nach erfolgreichem Quiescing aller Applikationen ruft der Controller EnterSuspendToRamOS auf S2RHub auf.
2. S2RHub setzt den systemnahen Call RequestToEnterSuspendModeOS(void) an das OS ab.
3. Zustandserreichung: Die Plattform wechselt in den stromsparenden Schlafzustand (Machine in Suspend-To-RAM mode).
4. Aufwachen/Rückkehr: Nach dem Reaktivieren der Machine meldet der Controller trigger X:OK an den StateMachineService, welcher die ursprüngliche Anforderung mit RequestTransition(trigger X):OK an die SmControlApplication positiv abschließt.

4. Normative Relevanz & Entwickler-Hinweise

• S2R-API-Vertrag (Applikationsentwickler): Prozesse, die vor dem Abschalten des SoC konsistente Zustände sichern müssen, müssen zwingend den ara::sm::s2r::S2RSatellite instanziieren und die Callback-Methode EnterSuspendMode() implementieren.
• Deterministisches Quiescing: Die Vorbereitung (Preparation for S2R) muss nicht-blockierend und innerhalb konfigurierter Guard-Timeouts abgeschlossen werden. Ein Hängenbleiben oder Rückmelden von Fehlern bricht den gesamten Sleep-Vorgang der Machine ab (kOperationFailed).
• Fail-Safe statt unvollständigem Sleep: State Management garantiert atomare Sicherheit: Schlägt auch nur eine Applikation fehl, wird der OS-Suspend unterbunden und stattdessen eine konfigurierbare Recovery-Aktion eingeleitet.
• Architektur-Entkopplung: Die Geschäftslogik (SmControlApplication) steuert lediglich Trigger ein, interagiert jedoch niemals direkt mit dem OS oder einzelnen Applikationen; die Orchestrierung und Fan-Out-Kommunikation liegt vollständig gekapselt im SM (Controller ↔ S2RHub).