DEENESPTFRRUARHIKOZHNL
AUTOSAR_AP_SWS_StateManagement FIG-3b9d3ffb76b95f80 887 × 532 px 2 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: 3b9d3ffb76b95f8010ec8c4d64dfe7376d6c2e5f58fb9eab32ec2eb8e1cd5d07

Im Versions-Explorer öffnen

Kanonischer Bildausschnitt (144 DPI WebP, gerendert aus Original-Vektorgrafik) · nicht öffentlich, nur mit Anmeldung und Freigabe
✦ 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

Sequenzdiagramm (Titel: FunctionGroup State transition to StateXYZ) zur Spezifikation des Zustandswechsels einer Function Group in der AUTOSAR Adaptive Platform. Das Diagramm modelliert die Interaktion zwischen State Management, Execution Management und Applikationsprozessen unter Verwendung typsicherer C++-Schnittstellensignaturen (ara::core::Future, ara::core::Result).

2. Komponenten, Entitäten & Schnittstellen

  • Execution Management: Plattforminstanz zur Prozessüberwachung, Signalübermittlung und Prozessinitiierung.
  • State Management: Plattforminstanz zur Festlegung und Beauftragung des Zielzustands.
  • App1: Prozess, der durch das Signal SIGTERM beendet wird und terminiert.
  • App2: Neu instanziierter Prozess, der seinen Ausführungsstatus an das Execution Management meldet.
  • Schnittstellen & Methoden:
    • SetState(FunctionGroupState &stateXYZ): ara::core::Future<void>: Asynchroner Methodenaufruf von State Management an Execution Management.
    • SIGTERM: Signal von Execution Management an App1.
    • exit: Prozessinterne Terminierung von App1.
    • WaitingForTermination(App1): Interner Wartezustand im Execution Management.
    • CreateProcess(App2): Aufruf zum Starten des Prozesses App2.
    • ReportExecutionState(kRunning): ara::core::Result<void>: Ausführungsstatusmeldung von App2 an Execution Management.
    • Success <<future invocation from SetState>>: Asynchrone Einlösung des Promises/Futures zur Erfolgsbestätigung an State Management.

3. Dynamisches Verhalten & Sequenzablauf

  1. State Management ruft SetState(FunctionGroupState &stateXYZ) auf Execution Management auf und erhält ein ara::core::Future<void> zurück.
  2. Kombiniertes Fragment loop [Shutdown]:
    • Execution Management sendet das Signal SIGTERM an App1.
    • App1 führt die interne Beendigung exit durch und terminiert (gekennzeichnet durch das Termination-Kreuz auf der Lebenslinie).
    • Execution Management führt WaitingForTermination(App1) aus, um das Ende des Prozesses zu registrieren.
  3. Kombiniertes Fragment loop [Startup]:
    • Execution Management instanziiert den Prozess über CreateProcess(App2).
    • App2 meldet seinen Status über ReportExecutionState(kRunning) an Execution Management und empfängt ein ara::core::Result<void>.
  4. Nach erfolgreichem Hochfahren aller Prozesse wird das zuvor übergebene Future aufgelöst (Success <<future invocation from SetState>>).

4. Normative Relevanz & Entwickler-Hinweise

Normativ verbindliche Spezifikation der C++-Plattform-Schnittstellen für State Management und Execution Management:

  • Das Setzen des Zustands erfolgt asynchron über ara::core::Future<void>.
  • Applikationen melden ihren Zustand direkt über ReportExecutionState mit dem Rückgabetyp ara::core::Result<void> zurück.
  • Die Terminierung der Prozesse im Shutdown erfolgt nach SIGTERM direkt durch Prozessende (exit) ohne separaten Statusreport via ExecutionClient.
  • Die Auflösung des Futures signalisiert dem State Management die vollständige Vollendung aller Shutdown- und Startup-Loops.

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

R23-11 → R24-11 normative Änderung Vorgänger: FIG-d64bc31733cce54a
  • 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.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R25-11 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ 7.1.2 Function Group State If more than one group of functionally coherent Adaptive Applications is installed on the same machine, the Machine State mechanism is not flexible enough to control these functional clusters individually, in particular if they have to be started and terminated with interleaving lifecycles. Many different Machine States would be required in this case to cover all possible combinations of active functional clusters. To support this use case, additional Function Groups and Function Group States can be configured. Other use cases where starting and terminating individual groups of Modelled Processes might be necessary including error recovery. In general, Machine States are used to control Machine lifecycle (startup/shutdown/restart) and Modelled Processes of platform level Applications while other Function Group States individually control Modelled Processes which belong to groups of functionally coherent user level Adaptive Applications. Modelled Processes reference in their Execution Manifest the states in which they want to be executed. A state can be any Function Group State, including a Machine State. For details see [13], especially "Mode-dependent Startup Configuration" chapter and "Function Groups" chapter. The arbitrary state change sequence as shown in Figure 7.2 applies to state changes of any Function Group - just re

Vorkommen in AUTOSAR-Releases (2)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R24-11 AUTOSAR_AP_SWS_StateManagement S. 23 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ
R25-11 AUTOSAR_AP_SWS_StateManagement S. 26 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ