Figure 7.40: Example for leaving Suspend-To-RAM

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Sequenzdiagramm mit kombinierten Fragmenten (loop, alt) und Zustands-Invarianten.
• Technischer Zweck & Einordnung: Spezifikation des standardisierten Ablaufs zum Verlassen des Energiesparzustands Suspend-to-RAM (S2R) in der AUTOSAR Adaptive Platform (AP State Management, SWS_StateManagement). Das Diagramm illustriert das Zusammenspiel zwischen einer projektspezifischen Steuerapplikation (SmControlApplication), dem State-Management-Kern (Zustandsautomat und Service-Interface) und den verteilten Adaptive Applications über das Hub-and-Satellite-Muster (S2RHub / S2RSatellite).

2. Komponenten, Entitäten & Schnittstellen

• «Adaptive application» SmControlApplication:
  • Projektspezifische Steuerlogik/Funktionsapplikation. Initiiert den Aufwach-/Transitionspfad basierend auf System-Triggern (z. B. Wake-up-Events, Busaktivität).
• State Management (ARA-Kernkomponente):
  • «Service» StateMachineService: ARA-Service-Schnittstelle zur Entgegennahme von Zustandsänderungsanfragen (RequestTransition).
  • «StateMachine» Controller: Zentraler Zustandsautomat des State Managements; evaluiert Trigger, führt Zustandsübergänge aus und verarbeitet zugehörige ActionLists.
  • «C++ API» ara/sm/s2r/S2RHub: Zentraler Vermittler (Hub) innerhalb des State Managements zur Koordination des S2R-Zustands für alle registrierten Applikationen.
• Adaptive Applications:
  • «C++ API - Skeleton» ara::sm::s2r::S2RSatellite: Lokale Satelliten-Instanz pro registrierter Applikation (basiert auf generierten Service-Skeletons/APIs), welche Rückmeldungen über das Aufwachen aus dem RAM an den Hub liefert.
• Schnittstellen & Interaktionen:
  • Synchroner/asynchroner Methodenaufruf: RequestTransition(trigger Y).
  • Interne Trigger-Weiterleitung: trigger Y.
  • Hub-Kommunikation: LeaveSuspendToRam / RequestToLeaveSuspendMode.
  • Satelliten-Broadcast/Loop-Aufruf: LeaveSuspendMode() via IPC/ara::com an die einzelnen Satelliten.

3. Dynamisches Verhalten & Sequenzablauf

1. Ausgangszustand:
   • Controller == Suspend.
2. Transitions-Trigger:
   • SmControlApplication entscheidet anhand projektspezifischer Logik über den Zielzustand (z. B. Normal Mode oder LowPowerMode) und sendet RequestTransition(trigger Y) an den StateMachineService.
   • StateMachineService leitet trigger Y an den Controller weiter.
3. Validierung & Zustandswechsel:
   • Controller prüft Gültigkeit (valid trigger?).
   • Zustandswechsel erfolgt nach LowPowerMode state (Controller == LowPowerMode).
   • Abarbeitung der konfigurierten ActionList startet.
4. Koordination des S2R-Ausscheidens:
   • Controller ruft LeaveSuspendToRam am S2RHub auf.
   • S2RHub stößt intern RequestToLeaveSuspendMode an.
   • loop [For each registered application]: Iterativer Aufruf von LeaveSuspendMode() am jeweiligen S2RSatellite. Applikationen reinitialisieren ihren Kontext (Leaving S2R) und quittieren synchron/asynchron mit OK.
5. Alternative Verzweigung (alt):
   • Erfolgspfad ([All Applications respond successfully]):
     • S2RHub meldet LeaveSuspendToRam::OK an den Controller.
     • System geht über in Machine in Normal mode.
     • Controller meldet trigger Y:OK an StateMachineService.
     • StateMachineService antwortet RequestTransition(trigger Y):OK an die SmControlApplication.
   • Fehlerpfad (Else / Timeout / NOK):
     • Mindestens ein Satellit schlägt fehl oder antwortet nicht rechtzeitig: S2RHub meldet LeaveSuspendToRam::NOK.
     • Controller meldet trigger Y:NOK an StateMachineService.
     • StateMachineService meldet RequestTransition(trigger Y):kOperationFailed an die SmControlApplication.
     • Ausführung einer definierten Fehlerbehandlung (Recovery action will be started, z. B. Restart, Reset oder Safe State).

4. Normative Relevanz & Entwickler-Hinweise

• Satelliten-Implementierung (ara::sm::s2r::S2RSatellite):
  • Applikationen, die bei Suspend-To-RAM persistiert wurden, müssen zwingend die S2RSatellite-Schnittstelle implementieren und bedienen.
  • Der Callback LeaveSuspendMode() muss deterministisch und innerhalb definierter Timeouts antworten, um den Gesamtsystem-Aufwachprozess nicht in den kOperationFailed-Zweig zu treiben.
• State Management Konfiguration (ARXML):
  • Der Übergang aus Suspend erfordert die Modellierung valider Transitionsregeln und Guard-Conditions für trigger Y.
  • In der zugehörigen ActionList muss der Aufruf des S2RHub korrekt deklariert sein.
• Fehlerbehandlung (Recovery Actions):
  • Entwickler der SmControlApplication müssen den Rückgabewert kOperationFailed abfangen. Das State Management muss deterministische Recovery-Aktionen (z. B. Eskalation an das Platform Health Management / PHM oder Maschinen-Reset) bereitstellen, falls einzelne Applikationen das Verlassen von S2R verweigern.