Figure 7.44: Different types of S2R support in Adaptive Applications

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptuelles Architektur- und Interaktionsdiagramm / Klassifikations-Übersicht.
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R25-11), Spezifikation AUTOSAR_AP_SWS_StateManagement.
• Funktionaler Zweck: Kategorisierung von Adaptive Applications (Prozessen) hinsichtlich ihres Verhaltens und ihrer Integrationsstrategie beim Übergang des Systems in den Energiesparzustand Suspend-to-RAM (S2R). Es definiert das Zusammenspiel zwischen State Management (SM), Execution Management (EM) und den Betriebssystem-Prozessen (Proc) zur Gewährleistung von Datenkonsistenz, deterministischem Lifecycle und hardwarekonformem Power-Down/Resume.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten:
  • SM (State Management): Zentrale funktionale Einheit zur Orchestrierung von Maschinen-, Funktionsgruppen- und Power-Zuständen.
  • EM (Execution Management): Plattform-Modul zur Überwachung und Steuerung des Prozess-Lebenszyklus (Start, Termination, Health Monitoring) über Funktionsgruppen.
  • Proc (Adaptive Process): Instanziiertes Betriebssystem-Executable einer Adaptive Application.
• Schnittstellen & Interaktionspfade:
  • S2R req. (Input): Trigger-Schnittstelle an SM (z. B. via Vehicle State Client, Power State Request oder Machine State Transition).
  • Terminate via EM: Interne Plattform-Steuerschnittstelle von SM zu EM, um Prozesse über den Funktionsgruppen-Zustand kontrolliert zu terminieren (SIGTERM/SIGKILL-Sequenz).
  • Notify via interconnect: Bidirektionaler Kommunikationskanal zwischen SM und Prozess (realisiert über IPC, z. B. ara::com Service-Interface oder dediziertes Event-Handling).
• Klassifikationskategorien:
  1. S2R-Tolerant: Prozess verharrt im Speicher; keine Interaktionsschnittstelle zu SM bei S2R erforderlich.
  2. S2R-Unsupported: Unidirektionale Lebenszyklus-Steuerung durch SM über EM.
  3. S2R-Aware: Bidirektionale Interaktion; aktiver Handshake vor Eintritt in S2R.

3. Dynamisches Verhalten & Sequenzablauf

• Trigger: Eintreffen eines S2R req. am State Management.
• Szenario 1: S2R-Tolerant (Transparenter Betrieb)
  1. SM registriert den S2R-Request.
  2. Keine Aktion bezüglich des Prozesses erforderlich.
  3. Plattform/OS friert den Task/Thread im RAM ein (Freeze/Suspend); nach Resume läuft der Prozess ohne State-Management-Eingriff transparent weiter (Voraussetzung: Verwendung S2R-fester Ressourcen wie monotoner Zeitgeber).
• Szenario 2: S2R-Unsupported (Destruktiver Lifecycle-Pfad)
  1. SM initiiert Zustandswechsel der zugehörigen Function Group über EM.
  2. EM sendet Terminationssignal (SIGTERM, nach Ablauf von enterTimeoutDuration ggf. SIGKILL) an Proc.
  3. Proc terminiert vollständig vor HW-Suspend.
  4. Bei System-Resume initiiert EM einen Kaltstart des Prozesses gemäß Manifest-Konfiguration (StartupConfig).
• Szenario 3: S2R-Aware (Geführter Handshake-Pfad)
  1. SM sendet Pre-Suspend-Notifikation via Interconnect an Proc.
  2. Proc führt applikative Quieszenz-Routinen aus:
     • Einstellen externer Netzwerkdienste (StopOfferService).
     • Persistierung von flüchtigen Caches / NVRAM-Zuständen (ara::per).
     • Schließen/Freigabe von Hardware-Handles (Sockets, Device Drivers).
  3. Asynchroner/Synchroner Acknowledge (Proc meldet Bereitschaft via Interconnect an SM zurück).
  4. SM leitet nach Rückmeldung aller S2R-Aware-Prozesse den finalen Hardware-Suspend ein.
  5. Beim Aufwachen erfolgt analog eine Wakeup-/Resume-Notifikation zur Re-Initialisierung.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest- & Deployment-Konfiguration:
  • Die Einstufung steuert das Execution-Manifest: Prozesse dürfen für S2R nur dann aktiv bleiben, wenn sie als S2R-Tolerant oder S2R-Aware ausgelegt sind.
  • S2R-Unsupported erfordert zwingend eine Zuordnung zu Function Groups, die bei Übergang in den S2R-Machine-State in den Zustand Off überführt werden.
• API-Verträge & Ressourcen-Restriktionen:
  • S2R-Tolerant: Streng limitiert. Keine offenen Netzwerk-Sockets mit Keepalive-Erwartungen; Zeitmessungen dürfen nicht auf System-Wall-Clock (std::chrono::system_clock) basieren, sondern müssen hardwaregestützte monotone Timer (CLOCK_BOOTTIME / std::chrono::steady_clock) nutzen.
  • S2R-Aware: Entwickler müssen den State-Management-Interconnect bedienen. Timeouts für die Bestätigung (Acknowledge) sind strikt begrenzt; Verzögerungen beim Speichern blockieren das Erreichen des Fahrzeug-Ruhestromziels (Quiescent Current) und führen zu Watchdog- bzw. Platform-Recovery-Eingriffen.
  • S2R-Unsupported: Geeignet bei zwingenden Hardware-Resets (z. B. PCIe/GPU-Initialisierung nach Power-Gating) oder Legacy-Code ohne S2R-Interface; Nachteil ist die verlängerte Latenzzeit beim Wake-up durch Prozess-Neustart.