Figure 7.6: PowerModes for Adaptive (Platform) Applications

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hierarchisches Zustandsdiagramm (UML State Machine) mit Kapselung orthogonaler Unterzustände (Substates/Modes).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Spezifikation AUTOSAR_SWS_StateManagement (Releases R20-11, R21-11, R22-11), Kapitel 7 (Functional Specification).
• Architektur-Zweck: Darstellung der semantischen Entkopplung zwischen dem standardisierten Prozess-Lebenszyklus (Execution States des Execution Management, ara::exec) und den applikativen Energiemodi (PowerModes des State Management, ara::sm).
• Kernbotschaft: PowerModes (On, Suspend, Off) stellen keine Betriebssystem-Prozesszustände dar, sondern applikative Betriebsmodi, die streng an die übergeordnete Lebenszyklusphase Running gebunden sind.

2. Komponenten, Entitäten & Schnittstellen

Übergeordnete Entitäten: Execution States (ara::exec)

Die horizontalen Zustandsblöcke spiegeln den POSIX-Lebenszyklus eines Prozesses wider, welcher über das Execution Manifest konfiguriert und von Execution Management kontrolliert wird:

• Idle: Ruhezustand. Der Prozess ist im Manifest deklariert, aber noch nicht durch das Betriebssystem via fork()/exec() instanziiert.
• Starting: Initialisierungsphase. Der POSIX-Prozess existiert bereits, initialisiert Middleware-Stacks und Hardware-Abstraktionen und bindet Kommunikations-Schnittstellen.
• Running: Stationärer Ausführungszustand. Der Prozess hat ara::exec::ApplicationClient::ReportApplicationState(kRunning) abgesetzt. Er ist voll schedulbar und Träger der applikativen Geschäftslogik.
• Terminating: Geordnete Shutdown-Phase. Eingeleitet durch das Execution Management (typischerweise via POSIX-Signal SIGTERM) zwecks Ressourcen- und Zustandssicherung.
• Terminated: Endzustand. Der Prozess wurde beendet, Exit-Code ist registriert, Systemressourcen sind freigegeben.

Verschachtelte Entitäten: PowerModes (ara::sm)

Die grün gestrichelten Sub-Zustände innerhalb des Running-Containers definieren das Power-Management auf Funktionsebene:

• On: Normalbetrieb. Sämtliche Threads, Sensor-/Aktor-Schnittstellen und ara::com-Dienste sind uneingeschränkt aktiv.
• Suspend: Quiescent-/Energiesparmodus. Nicht-essenzielle Worker-Threads und zyklische Sendeoperationen sind angehalten; flüchtige Datenstrukturen sind für schnelles Wake-up im RAM eingefroren. Der OS-Prozess verbleibt im Zustand Running.
• Off: Applikativer Vor-Abschaltzustand. Vorbereitung auf vollständigen Spannungsverlust oder Funktionsgruppen-Deaktivierung (Schließen von Netzwerk-Sockets, Flashen nicht-flüchtiger Speicher über ara::per).

Schnittstellen & Kommunikationsprotokolle

• CommunicationGroup: State Management agiert als CommunicationGroupServer, Adaptive Applications fungieren als CommunicationGroupClient.
• Broadcast-/Request-Mechanismus: Übertragung von PowerMode-Anforderungen (PowerMode::message()) an registrierte Applikationen und Rückmeldung des aktuellen Status (PowerMode::event()).
• Zustandsberichterstattung: Schnittstelle ara::exec::ApplicationClient zur Synchronisation des Prozessstatus mit dem Execution Manager.

3. Dynamisches Verhalten & Sequenzablauf

[Idle] ---> [Starting] ---> [Running: On | Suspend | Off] ---> [Terminating] ---> [Terminated]
                                  │           ▲
                                  ▼           │
                               (PowerMode-Events via SM)

1. Allokation & Start:
   • State Management fordert bei Execution Management den Übergang einer Funktionsgruppe (Function Group, z. B. MachineFG) in einen Zielzustand an.
   • Execution Management überführt den Prozess von Idle nach Starting.
2. Eintritt in den Power-Scope:
   • Die Applikation initialisiert sich und meldet kRunning an Execution Management.
   • Erst mit dem Übergang in Running abonniert die Applikation die PowerMode-Schnittstelle von State Management. Der Default-Zustand ist typischerweise On.
3. PowerMode-Zustandsübergänge (innerhalb Running):
   • On → Suspend: SM empfängt ein Suspend-Ereignis (z. B. Diagnose, Klemme-15-Signal) und sendet die Anforderung via CommunicationGroup an alle Clients. Die Applikation pausiert zyklische Workloads, geht in Bereitschaft und quittiert den Vollzug.
   • Suspend → On: SM signalisiert Wake-up. Die Applikation nimmt den vollen Betrieb ohne Kaltstart-Latenz wieder auf.
   • On/Suspend → Off: SM initiiert das Herunterfahren. Die Applikation sichert persistente Daten transaktionssicher via ara::per und meldet Quittierung an SM.
4. Prozessterminierung:
   • Nach Quittierung von Off (oder bei direktem Function Group State Transition in den System-Shutdown) leitet Execution Management die Beendigung ein.
   • EM versendet SIGTERM → Transition nach Terminating.
   • Nach Abschluss der Bereinigung bzw. nach Ablauf des im Manifest konfigurierten enterTimeoutValue erfolgt der Übergang nach Terminated (bei Timeout-Überschreitung erzwungen via SIGKILL).

4. Normative Relevanz & Entwickler-Hinweise

• Strikte Ebenentrennung: Entwickler dürfen den PowerMode Off keinesfalls mit dem Prozessende verwechseln. Im Modus Off läuft der Prozess im Betriebssystem weiter und muss nach wie vor auf IPC-/SM-Nachrichten reagieren können.
• API-Sequenzierung: Vor dem Aufruf von ReportApplicationState(ApplicationState::kRunning) dürfen keine PowerMode-Events verarbeitet oder quittiert werden, da State Management die Applikation erst nach bestätigtem kRunning als steuerungsfähig einstuft.
• Persistierungs-Strategie: Das Schreiben kritischer Daten via ara::per muss beim Übergang in den PowerMode Off (oder Suspend) erfolgen. Das Verlassen auf den SIGTERM-Handler im Zustand Terminating birgt erhebliche Risiken, da dieser durch den harten Watchdog/Timeout (enterTimeoutValue) des Execution Managers hart abgebrochen werden kann.
• Nicht-blockierende Signalverarbeitung: Callback-Handler für PowerMode-Nachrichten müssen asynchron bzw. streng deterministisch ausgelegt sein. Verzögerungen bei der Quittierung führen zu Timeout-Eskalationen im State Management Cluster.