DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_ExecutionManagement FIG-cd16e25e5b41a02b 887 × 603 px 4 Release(s)

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

SHA-256 Inhalts-Fingerabdruck: cd16e25e5b41a02be19c854065fc0d7770dc19ef71f55f4346e7c105fcf6795a

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

UML-Sequenzdiagramm zur Spezifikation des dynamischen Verhaltens im AUTOSAR-Adaptive-Platform-Modul Execution Management (EM). Das Diagramm stellt die maschinelle Zustandsänderung (Transition to Machine State <<StateXYZ>>) dar, die durch den State Management (SM) initiiert wird und das geordnete Herunterfahren nicht mehr benötigter Anwendungen sowie das Starten neuer Prozesse umfasst.

2. Komponenten, Entitäten & Schnittstellen

Das Diagramm definiert vier Instanzen im Sequenzrahmen sd Transition to Machine State <<StateXYZ>>:

  • EM: Execution Management.
  • SM: State Management.
  • App1: Zu beendende Anwendung.
  • App2: Neu zu startende Anwendung.

Schnittstellen und Interaktionen:

  • SetState("MachineState", StateXYZ): Anforderung des Maschinenzustandswechsels von SM an EM.
  • SIGTERM(allApps): Signal von EM an die Lebenslinie von App1 bzw. alle betroffenen Anwendungen.
  • ExecutionClient::ReportExecutionState(kTerminating): Zustandsmeldung von App1 an EM.
  • WaitForTermination(App1): Interner Warteaufruf von EM.
  • CreateProcess(allApps): Prozessinitiierung durch EM für App2 bzw. alle zu startenden Anwendungen.
  • ExecutionClient::ReportExecutionState(kRunning): Betriebsbereitschaftsmeldung von App2 an EM.
  • :kSuccess: Gestrichelte Erfolgsrückmeldung von EM an SM.

3. Dynamisches Verhalten & Sequenzablauf

  1. SM sendet SetState("MachineState", StateXYZ) an EM.
  2. Interaktionsschleife loop [Shutdown]:
    • EM sendet SIGTERM(allApps) an die betroffenen Anwendungen (dargestellt an App1).
    • App1 quittiert mit ExecutionClient::ReportExecutionState(kTerminating).
    • EM wartet lokal über WaitForTermination(App1) auf das Beenden.
  3. Interaktionsschleife loop [Startup]:
    • EM initiiert CreateProcess(allApps) (dargestellt an App2).
    • App2 meldet nach Initialisierung ExecutionClient::ReportExecutionState(kRunning) an EM.
  4. EM meldet den erfolgreichen Zustandswechsel via :kSuccess an SM zurück.

4. Normative Relevanz & Entwickler-Hinweise

Normative Festlegung für AUTOSAR Adaptive Execution Management unter Verwendung von ExecutionClient statt des früheren ApplicationClient. Applikationen müssen über ExecutionClient::ReportExecutionState ihren Ausführungszustand (kTerminating bzw. kRunning) an EM melden. Prozess-Shutdown und -Startup erfolgen in Schleifen über Mengen von Applikationen (allApps).

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

R18-03_R1.4.0 → R18-10-1 normative Änderung Vorgänger: FIG-a91d8ac429c095d9
  • Diagramm-Header: Standard-UML-Kopfzeile sd Transition to Machine State <<StateXYZ>> ersetzt den proprietären Rahmen.
  • Nachricht SIGTERM: Parameter (allApps) ergänzt (SIGTERM(allApps)).
  • Statusmeldung: Schnittstelle ApplicationClient::ReportApplicationState(...) durch ExecutionClient::ReportExecutionState(...) ersetzt (in beiden Schleifen).
  • Nachricht CreateProcess: Parameter (allApps) ergänzt (CreateProcess(allApps)).
  • Rückmeldung: Frühere kSuccess-Rückgabe an App2 entfallen; Abschlussantwort an SM als :kSuccess formatiert.
R19-11 → R20-11 normative Änderung Nachfolger: FIG-eb1c2bc8b85deb97
  • Initialer Aufruf: Parameter von SetState("MachineState", StateXYZ) zu SetState("MachineFG", StateXYZ) geändert; unmittelbare asynchrone Rückkehr der Aufruf-Aktivierung an SM.
  • Terminierung: Signalaufruf von SIGTERM(allApps) zu SIGTERM(allProcesses) umbenannt.
  • Terminierung: Selbstaufruf WaitForTermination(App1) und Meldung ExecutionClient::ReportExecutionState(kTerminating) ersetzt durch asynchrone Prozessbeendigung :EXIT_SUCCESS mit Zerstörung der Lebenslinie von App1 (X).
  • Prozessstart: App2 wird erst zur Laufzeit dynamisch erzeugt (Erhalt der CreateProcess(allApps)-Nachricht direkt am Kopf-Kasten) statt statisch ab Beginn vorhanden zu sein; Zerstörungssymbol (X) am Ende der Lebenslinie von App2.
  • Statusübergang: Abschlussmeldung an SM von gestricheltem :kSuccess in synchrone/feste Benachrichtigung :Transition completed geändert.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Begleitender Spezifikationstext:

Specification of State Management AUTOSAR AP R19-11 An arbitrary state change sequence to machine state StateXYZ is illustrated in Figure 7.2. Here, on receipt of the state change request, Execution Management terminates running Processes and then starts Processes active in the new state before confirming the state change to State Management. Figure 7.2: State Change Sequence – Transition to machine state StateXYZ 7.1.1.1 Startup Execution Management will be controlled by State Management and therefore it should not execute any Function Group State changes on its own. This creates some expectations towards system configuration. The configuration shall be done in this way that State Management will run in every Machine State (this includes Startup, Shutdown and Restart). Above expectation is needed in order to ensure that there is always a software entity that can introduce changes in the current state of the Machine. If (for example) system integrator doesn’t configure State Management to be started in Startup Machine State, then Machine will never be able transit to any other state and will be stuck forever in it. This also applies to any other Machine State state that doesn’t have State Management configured. 17 of 41 — AUTOSAR CONFIDENTIAL — Document ID 908: AUTOSAR_SWS_StateManagement

Vorkommen in AUTOSAR-Releases (13)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_ExecutionManagement S. 39 7.7 Figure 7.7: State Change Sequence – Transition to machine state StateXYZ
R18-10-1 AUTOSAR_SWS_ExecutionManagement S. 39 7.7 Figure 7.7: State Change Sequence – Transition to machine state StateXYZ
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_StateManagement S. 18 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_StateManagement S. 18 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ
R18-10-1 AUTOSAR_SWS_StateManagement S. 18 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ
R19-03 AUTOSAR_SWS_ExecutionManagement S. 38 7.7 Figure 7.7: State Change Sequence – Transition to machine state StateXYZ
R19-03 AUTOSAR_SWS_ExecutionManagement S. 38 7.7 Figure 7.7: State Change Sequence – Transition to machine state StateXYZ
R19-03 AUTOSAR_SWS_StateManagement S. 17 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ
R19-03 AUTOSAR_SWS_StateManagement S. 17 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ
R19-11 AUTOSAR_SWS_ExecutionManagement S. 42 7.7 Figure 7.7: State Change Sequence – Transition to machine state StateXYZ
R19-11 AUTOSAR_SWS_ExecutionManagement S. 42 7.7 Figure 7.7: State Change Sequence – Transition to machine state StateXYZ
R19-11 AUTOSAR_SWS_StateManagement S. 17 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ
R19-11 AUTOSAR_SWS_StateManagement S. 17 7.2 Figure 7.2: State Change Sequence – Transition to machine state StateXYZ