Figure 9.11: Interfaces for Suspend-to-RAM

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Komponenten- und Schnittstellendiagramm mit AUTOSAR-Adaptive-Plattform-Stereotypen («aapFunctionalCluster», «aapAPI,aapPortInterface», «aapCallbackMethod»).
• Funktionale Einordnung: Spezifikation des Hub-Satellite-Musters für Suspend-to-RAM (S2R) innerhalb des Functional Clusters State Management (SM) der AUTOSAR Adaptive Platform (R25-11, AUTOSAR_AP_EXP_SWArchitecture).
• Technischer Zweck: Entkopplung der zentralen Energiestatus-Orchestrierung (Control-Plane) von der dezentralen Vorbereitung und Quieszenz der einzelnen Nutzer-Applikationen (Execution-Plane) vor dem Einfrieren des Systems in den RAM-Retention-Modus.

2. Komponenten, Entitäten & Schnittstellen

Komponenten

• «aapFunctionalCluster» State Management (daemon-based): Zentraler Plattform-Daemon, der den globalen Lebenszyklus und die S2R-Zustände der Machine verwaltet. Realisiert sowohl die Hub- als auch die Satelliten-Gegenstelle.
• SMControlApplication: Applikative Kontrollinstanz (OEM-/System-spezifische Zustandslogik), welche über Richtlinien (Policies) und externe Trigger (z. B. Klemme 15, CAN-Netzwerkmanagement) den S2R-Ablauf anfordert und steuert.
• Adaptive Application: Regulärer AP-Prozess, der auf S2R-Ereignisse reagieren muss, um flüchtige Zustände zu sichern, Netzwerkverbindungen sauber einzufrieren und Hardware-Ressourcen freizugeben.

Schnittstellen & Methoden

• «aapAPI,aapPortInterface» S2RHub (bereitgestellt von State Management, genutzt von SMControlApplication via «use»):
  • + RequestToEnterSuspendMode(): Fordert die Einleitung der S2R-Vorbereitungsphase im Gesamtsystem an.
  • + RequestToLeaveSuspendMode(): Leitet den geordneten Aufwachprozess nach dem OS-Resume ein.
  • + EnterSuspendToRamOs(): Weist das Host-OS an, die CPU-Cores anzuhalten und den SoC final in den Suspend-to-RAM-Modus (z. B. ACPI S3, POSIX-spezifische PM-Treiber) zu versetzen.
• «aapAPI,aapPortInterface» S2RSatellite (bereitgestellt von State Management, genutzt von Adaptive Application via «use»):
  • Lifecycle- & Registrierungsmethoden:
    • + Create() (statisch): Instanziiert das lokale Satelliten-Objekt innerhalb der Applikation.
    • + Offer(): Registriert den Prozess beim State Management als aktiv am S2R-Mechanismus teilnehmend.
    • + StopOffer(): Meldet den Prozess vor dessen Terminierung vom S2R-Mechanismus ab.
  • «aapCallbackMethod» (Von der Applikation zu implementieren):
    • + EnterSuspendMode(): Notifikation an die Applikation, unverzüglich alle I/O-Aktivitäten einzustellen, Puffer zu flashen und Quieszenz zu melden.
    • + LeaveSuspendMode(): Notifikation nach dem Aufwachen zur Re-Initialisierung von Peripherie, Timer-Resynchronisation und IPC-Reaktivierung.

Beziehungen & Kardinalitäten

• Realisierung: State Management realisiert S2RHub (1:1) und S2RSatellite (1:n über IPC-Abstraktion).
• Nutzung: Exakt eine SMControlApplication bedient S2RHub per Service-Port («use»); n Adaptive Applications binden je eine Instanz von S2RSatellite an («use»).

3. Dynamisches Verhalten & Sequenzablauf

A. Initialisierung & Registrierung

1. Adaptive Application instanziiert den Satelliten über S2RSatellite::Create().
2. Aufruf von S2RSatellite::Offer() registriert die Callback-Handler beim lokalen SM-Daemon.

B. Suspend-to-RAM Sequenz (Einfrieren)

1. Trigger: SMControlApplication empfängt ein Shutdown-/Suspend-Signal und ruft synchron/asynchron S2RHub::RequestToEnterSuspendMode() auf.
2. Broadcasting: Das State Management iteriert über alle registrierten Satelliten und triggert S2RSatellite::EnterSuspendMode().
3. Applikations-Quieszenz:
   • Applikationen schließen File-Descriptors, stoppen Worker-Threads, terminieren SOME/IP- und IPC-Transaktionen und sichern kritische Daten.
   • Rückmeldung der Applikation an den Satelliten (Bestätigung der Suspend-Bereitschaft).
4. Finaler Suspend: Nach Quittierung aller aktiven Satelliten (oder Erreichen eines Timeouts) meldet S2RHub Vollzug an SMControlApplication.
5. OS-Trigger: SMControlApplication ruft S2RHub::EnterSuspendToRamOs() auf → SM delegiert an OS-Kernel/BSP (CPU-Context-Save, RAM im Self-Refresh, Übergabe an PMIC/Firmware).

C. Resume Sequenz (Aufwachen)

1. Wake-up Trigger: Externes Ereignis (CAN-Transceiver, Wake-up-Pin, RTC-Alarm) weckt den OS-Kernel.
2. Re-Start SM: OS-Kernel stellt Kontext wieder her; State Management und SMControlApplication nehmen den Betrieb auf.
3. Resume-Anforderung: SMControlApplication führt S2RHub::RequestToLeaveSuspendMode() aus.
4. Applikations-Aufweckung: State Management dispatcht S2RSatellite::LeaveSuspendMode() an alle Satelliten.
5. Dienstwiederaufnahme: Applikationen reconnecten Treiber, re-synchronisieren Kommunikations-Endpunkte und setzen die zyklische Ausführung fort.

4. Normative Relevanz & Entwickler-Hinweise

• Trennung von Privilegien: Gewöhnliche Adaptive Applications erhalten keinen Zugriff auf S2RHub oder Low-Level OS-Energieverwaltung. Der finale OS-Aufruf EnterSuspendToRamOs() ist strikt auf die Plattformsteuerung beschränkt.
• Echtzeit- und Timeout-Restriktionen:
  • Der Callback EnterSuspendMode() muss deterministisch und zeitlich begrenzt abgearbeitet werden.
  • Bleibt eine Applikation im Callback hängen, erzwingt das State Management je nach Konfiguration entweder einen Timeout-Abbruch, das harte Terminieren des Prozesses (SIGKILL) oder einen Fallback auf einen Hard-Reset/Graceful Shutdown.
• Keine dynamischen Speicher- und Kommunikationsallokationen: Während EnterSuspendMode() dürfen keine neuen IPC-, Shared-Memory- oder Netzwerkverbindungen aufgebaut werden; alle Puffer müssen deterministisch geleert werden.
• OS-/BSP-Integration: EnterSuspendToRamOs() erfordert native BSP-Unterstützung (z. B. Linux Suspend-to-RAM via /sys/power/state oder QNX Power Management Framework). Ein unvollständig quiesziertes Subsystem führt zu Race Conditions oder Kernel-Panics beim Einfrieren der Speichercontroller.