DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_StateManagement FIG-d64bc31733cce54a 887 × 603 px 1 Release(s)

Figure 7.2: State Change Sequence – Transition to machine state StateXYZ

SHA-256 Inhalts-Fingerabdruck: d64bc31733cce54a6d083396547aba4c3963ea4eb79141186b207e4b72db8d9b
✦ KI-generierte Bildanalyse & technische Beschreibung Modell: gemini-3.8-flash (via agy) · Rezept figure-series@1 · erstellt am 2026-10-08

1. Diagrammtyp & Architektur-Kontext

UML-Sequenzdiagramm (sd Transition to Machine State <<StateXYZ>>) zur Darstellung der Interaktion zwischen State Management (SM), Execution Management (EM) und Anwendungsinstanzen in AUTOSAR Adaptive Platform während eines Maschinenstatuswechsels. Es zeigt die Koordination des Herunterfahrens nicht mehr benötigter Prozesse sowie das Starten neuer Prozesse im Rahmen einer Zustandsänderung der Function Group MachineState.

2. Komponenten, Entitäten & Schnittstellen

  • EM (Execution Management): Verwaltet den Lebenszyklus von Prozessen, führt Zustandswechsel für Function Groups aus und terminiert bzw. startet Prozesse.
  • SM (State Management): Initiiert den Zustandsübergang der Maschine über die Schnittstelle zu EM.
  • App1: Prozess, der im Ausgangszustand aktiv ist und für den Zielzustand heruntergefahren wird.
  • App2: Prozess, der für den Zielzustand gestartet wird.
  • Schnittstellen & Methoden:
    • SetState("MachineState", StateXYZ): Anforderung des Zustandswechsels durch SM an EM.
    • SIGTERM(allApps): Signal von EM an zu beendende Prozesse.
    • WaitForTermination(App1): Interne Synchronisation/Wartefunktion im EM auf das Prozessende.
    • CreateProcess(allApps): Erzeugung und Start der Prozesse durch EM.
    • ExecutionClient::ReportExecutionState(kRunning): Statusmeldung des neu gestarteten Prozesses an EM.
    • :kSuccess: Erfolgsrückmeldung von EM an SM.

3. Dynamisches Verhalten & Sequenzablauf

  1. SM sendet den synchronen Aufruf SetState("MachineState", StateXYZ) an EM, um den Übergang der Function Group MachineState in den Zustand StateXYZ auszulösen.
  2. Kombiniertes Fragment loop [Shutdown]:
    • EM sendet SIGTERM(allApps) an die zu beendende App1.
    • EM wartet intern über WaitForTermination(App1) direkt auf die Beendigung des Prozesses (ohne expliziten Termination-Report der App).
  3. Kombiniertes Fragment loop [Startup]:
    • EM startet neue Prozesse mittels CreateProcess(allApps) (hier App2).
    • App2 meldet nach Initialisierung ExecutionClient::ReportExecutionState(kRunning) an EM.
  4. Nach Abschluss aller Shutdown- und Startup-Schleifen sendet EM die Erfolgsantwort :kSuccess an SM zurück.

4. Normative Relevanz & Entwickler-Hinweise

Das Diagramm beschreibt das normativ vorgegebene Zusammenspiel zwischen State Management und Execution Management gemäß AUTOSAR Adaptive Platform. Für Integratoren und Entwickler von Plattformdiensten ist relevant:

  • Der Übergang erfolgt zweiphasig (erst geordneter Shutdown aller obsoleten Prozesse, danach kontrollierter Startup neuer Prozesse).
  • Prozesse melden ihren Lebenszyklusstatus über den ExecutionClient explizit zurück (kTerminating und kRunning).
  • EM quittiert SetState erst, nachdem alle definierten Prozesse erfolgreich beendet bzw. hochgefahren wurden.

Versionsvergleich KI-generiert · gemini-3.8-flash (via agy)

R22-11 → R23-11 normative Änderung Vorgänger: FIG-b091e536f51ae152
  • Methodenaufruf zur Zustandsänderung: Parameter für die Function Group von SetState("MachineFG",StateXYZ) auf SetState("MachineState",StateXYZ) geändert.
  • Prozess-Terminierung: Nachricht ExecutionClient::ReportExecutionState(kTerminating) von App1 an EM sowie zugehöriger Execution-Fokus entfallen vollständig; EM wartet nach dem Versenden von SIGTERM(allProcesses) direkt via WaitForTermination(App1).
R23-11 → R24-11 normative Änderung Nachfolger: FIG-3b9d3ffb76b95f80
  • Diagramm-Header und Titel: UML-Rahmen sd Transition to Machine State <<StateXYZ>> ersetzt durch die Überschrift FunctionGroup State transition to StateXYZ.
  • Lebenslinien: Rollenbezeichnungen EM und SM umbenannt in Execution Management und State Management (jeweils mit Kopf- und Fußkästen; State Management farblich hervorgehoben).
  • Zustandsanforderung: Signatur von SetState("MachineState",StateXYZ) auf C++-API-Signatur SetState(FunctionGroupState &stateXYZ): ara::core::Future<void> umgestellt.
  • Shutdown-Schleife: Zielnachricht SIGTERM(allProcesses) vereinfacht zu SIGTERM an App1; interne EM-Warteoperation von WaitForTermination(App1) in WaitingForTermination(App1) umbenannt; explizite Beendigungssequenz exit mit Zerstörungssymbol (rotes Andreaskreuz / Termination) an der Lebenslinie von App1 ergänzt.
  • Startup-Schleife: Prozessstart von CreateProcess(allApps) auf CreateProcess(App2) konkretisiert; Rückmeldung von ExecutionClient::ReportExecutionState(kRunning) auf ReportExecutionState(kRunning): ara::core::Result<void> mit typisiertem Rückgabewert geändert.
  • Asynchroner Abschluss: Rückmeldung :kSuccess ersetzt durch asynchrone Future-Auflösung Success <<future invocation from SetState>>.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R23-11 AUTOSAR_AP_SWS_StateManagement S. 25 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ