Figure 7.38: Example for the Controller StateMachineStates supporting Suspend-To-RAM.

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Zustandsdiagramm (State Machine Diagram) mit internen Aktionslisten (<<ActionList>>) und Synchronisationsschranken (SYNC).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (Release R25-11), Spezifikation State Management (AUTOSAR_AP_SWS_StateManagement).
• Technischer Zweck: Referenzmodell für die Steuerung der Controller-Zustände (Power Modes) mit nativer Unterstützung von Suspend-to-RAM (S2R). Das Diagramm demonstriert das Zusammenspiel zwischen der globalen Maschinen-Funktionsgruppe (MachineFG), untergeordneten Funktionsgruppen/Prozess-Controllern (Agent1, Agent2), applikationsweiten S2R-Signalnachrichten und OS-Level-Sleep-Calls.

2. Komponenten, Entitäten & Schnittstellen

• Zustände des Controllers:
  • Initial State: System-Bootstrapping.
  • Normal Mode: Regulärer Vollbetrieb der Adaptive Application Plattform.
  • Suspend: Partieller Standby-Zustand (S2R für alle S2R-fähigen Prozesse beider Agenten).
  • FullSuspend: Restriktiver Standby-Zustand (vollständiger Shutdown von Agent2, S2R nur für Agent1).
  • LowPowerMode: Zwischenzustand nach dem Aufwachen aus Suspend mit reduziertem Funktionsumfang.
  • RecoveryMode: Fallback- und Fehlerbehandlungszustand bei Plattform- oder Prozessanomalien.
• Akteure & Funktionsgruppen (Entities):
  • MachineFG: Standard-Maschinenfunktionsgruppe (FunctionGroup), gesteuert durch Execution Management (ara::exec). Sichtbare Zustände: Startup, Running, Recovery.
  • Agent1, Agent2: Abstraktionen von logischen Prozessgruppen, Funktionsgruppen oder Subsystemen. Unterstützen die Lebenszyklus-Zustände start, stop, start(S2R) und start(LowPowerMode).
• State Management Aktionen & Primitiven (<<ActionList>>):
  • EnterSuspendToRam: Plattformweites Request-Kommando (Broadcast/Event über SM-Schnittstelle) an alle registrierten, aktiven Prozesse, sich auf den S2R-Modus vorzubereiten (z. B. State-Serialisierung, Deaktivierung von Kommunikationsendpunkten).
  • EnterSuspendToRamOS: Privilegierter Maschinen- bzw. OS-Call zum Übergang in den Hardware-Schlafmodus (CPU-Suspend, DRAM Self-Refresh).
  • LeaveSuspendToRam: Plattformweite Benachrichtigung nach Wakeup, um den S2R-Zustand aufzuheben und Ressourcen zu reinitialisieren.
  • SYNC: Deterministische Synchronisationsbarriere; State Management blockiert den Phasenübergang, bis alle zuvor getriggerten Prozesswechsel bzw. Zustandsbestätigungen (Execution State Notifications) vollständig quittiert sind.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung:
   • Eintritt via Initial-Pseudostate in Initial State.
   • Anforderung MachineFG::Startup → Warten an SYNC → Start von Agent1, Stopp von Agent2 → Unkonditionierter Übergang zu Normal Mode.
2. Normalbetrieb (Normal Mode):
   • Aktivierung von MachineFG::Running.
   • Ausführung von LeaveSuspendToRam (Bereinigung eventueller Rest-Zustände).
   • Paralleler Start von Agent1 und Agent2.
3. Pfade in den Suspend-to-RAM (S2R):
   • Pfad A – Vollständiger/Selektiver Standby (Suspend):
     • Verbleib in MachineFG::Running.
     • Agent1.start(S2R) und Agent2.start(S2R) versetzen beide Prozessgruppen in S2R-Zustände.
     • EnterSuspendToRam fordert alle registrierten Prozesse zur Suspend-Vorbereitung auf.
     • SYNC-Barriere erzwingt das Warten auf alle Bestätigungen.
     • EnterSuspendToRamOS versetzt die Plattform über das OS in den Sleep-Modus.
   • Pfad B – Tiefer Standby (FullSuspend):
     • MachineFG::Running.
     • Agent1.start(S2R) während Agent2.stop ausgeführt wird (Teilabschaltung).
     • EnterSuspendToRam → SYNC → EnterSuspendToRamOS.
4. Aufwach- und Rückkehrsequenzen:
   • Wakeup aus FullSuspend: Direkter Übergang zurück in Normal Mode (inkl. Reaktivierung von Agent2).
   • Wakeup aus Suspend via LowPowerMode:
     • Gestaffeltes Aufwachen: Zunächst Übergang nach LowPowerMode.
     • Agent1.start(LowPowerMode) aktiviert ausschließlich priorisierte Sub-Applikationen; Agent2 verbleibt in stop.
     • SYNC → LeaveSuspendToRam informiert alle Prozesse über die Beendigung des S2R.
     • Nachfolgender Übergang in den Normal Mode zur Wiederherstellung der Vollfunktionalität.
5. Fehlerpfad (RecoveryMode):
   • Triggerbar aus Normal Mode (z. B. durch Health-Monitoring-Verletzungen oder SM-Fehlerregeln).
   • Umschaltung auf MachineFG::Recovery → SYNC → LeaveSuspendToRam (garantiert deterministisches Verlassen schlafender Kontexte) → Stopp aller Agenten (Agent1.stop, Agent2.stop).

4. Normative Relevanz & Entwickler-Hinweise

• Idempotenz & S2R-Hygiene: Sowohl Normal Mode als auch RecoveryMode führen zwingend LeaveSuspendToRam aus. Entwickler von Adaptive Applications müssen sicherstellen, dass Handler für LeaveSuspendToRam idempotent implementiert sind und auch nach unvollständigen Boot- oder Abbruchzyklen ohne vorherigen Suspend fehlerfrei reagieren.
• Prozess-Lifecycle & Timeouts: Anwendungen, die an EnterSuspendToRam teilnehmen, müssen ihre Suspend-Vorbereitung innerhalb des im Execution Management konfigurierten Timeouts abschließen. Ein Verpassen der Quittierung vor Erreichen der SYNC-Schranke führt zum Timeout-Fehler im SM und blockiert den OS-Sleep-Call (EnterSuspendToRamOS).
• Ressourcenfreigabe bei Teilabschaltung: Bei Umschaltung nach FullSuspend oder LowPowerMode wird Agent2 gestoppt (Agent2.stop). Prozesse unter Agent2 müssen einen regulären SIGTERM-/Shutdown-Zyklus durchlaufen, während Prozesse unter Agent1 flüchtige Zustände im RAM halten dürfen.
• OS-Treiber-Integration: EnterSuspendToRamOS ist die exklusive Schnittstelle zwischen State Management und BSP/OS (z. B. Linux System Suspend /sys/power/state oder QNX Power Management). Plattform-Integratoren müssen sicherstellen, dass zu diesem Zeitpunkt keine blockierenden IPC- oder ara::com-Transaktionen mehr ausstehen.