DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_ExecutionManagement FIG-4f38eb7fbed6624a 831 × 885 px 3 Release(s)

Figure 7.9: Interaction between states

SHA-256 Inhalts-Fingerabdruck: 4f38eb7fbed6624ac832398bab9b730cdead2870431252469c3a1a84fd93df28

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

Architektur- und Zustandsinteraktionsdiagramm der AUTOSAR Adaptive Platform zur Darstellung des Zusammenspiels zwischen State Management (SM), Execution Management (EM) und einem Prozess (Process). Es visualisiert horizontal über die Zeitachse die Korrelation von Funktionsgruppenzuständen (FG1 State), prozessbezogenen Lebenszykluszuständen im EM (Process State) sowie internen Ausführungszuständen (Execution State).

2. Komponenten, Entitäten & Schnittstellen

  • State Management (SM): Übergeordnete Instanz zur Arbitrierung von Eingangsdaten (via ara::com aus Fahrzeugmanagement, Diagnose, Fehlermanagement etc.) mit dem Aufruf *SetState*(FG1, State) an EM und dem Rückgabewert return (success).
  • Execution Management (EM): Verwaltet Funktionsgruppenübergänge (FG1 State: FG1:State1 -> FG1:State2 -> FG1:State3) und den Prozesslebenszyklus (Process State: Idle, Starting, Running, Terminating, Terminated). Steuert Prozessanlage (Start(), create process, allocate resources), Einplanung (schedule) und Beendigung (Terminate(), “waitpid”).
  • Process: Beinhaltet die internen Zustände des Execution State (Initializing, Running und Terminating). Meldet den Ausführungsstatus an EM über ReportExecutionState(Running) sowie ReportExecutionState(Terminating).
  • Schnittstellen & Pfeilarten: Durchgezogene Pfeile stellen Trigger dar (trigger), gestrichelte Pfeile Bestätigungen bzw. synchrone/asynchrone Rückmeldungen (confirm).

3. Dynamisches Verhalten & Sequenzablauf

  1. State Management arbitriert Anforderungen und ruft synchron *SetState*(FG1, State2) auf EM auf.
  2. Der FG1-Übergang von FG1:State1 nach FG1:State2 veranlasst im Process State den Übergang von Idle (Referenz im Execution Manifest) nach Starting (Execute); EM erzeugt den Prozess (Start(), create process, allocate resources).
  3. Nach Bereitstellung der Prozessressourcen wechselt der Process State nach Running (Schedule), und EM plant den Prozess ein (schedule).
  4. Der Process wechselt von Initializing nach Running und setzt den Aufruf ReportExecutionState(Running) an EM ab.
  5. EM quittiert daraufhin den Zustandsaufruf an SM mit return (success).
  6. SM ruft anschließend *SetState*(FG1, State3) auf. Da der Prozess laut Execution Manifest nur für FG1:State2 konfiguriert ist, wechselt der Process State nach Terminating (Terminate), und EM ruft Terminate() am Process auf.
  7. Der Process wechselt nach Terminating (store data, free resources, exit) und sendet ReportExecutionState(Terminating) an EM.
  8. Sobald der Prozess beendet ist (“waitpid”, process terminated), geht der Process State in Terminated über (process resources freed), und EM schließt den Aufruf an SM mit return (success) ab.

4. Normative Relevanz & Entwickler-Hinweise

Das Diagramm legt die Interaktionskette und Schnittstellenanforderungen für Adaptive Applications fest:

  • Die Konfiguration der Prozessaktivierung erfolgt über das Execution Manifest.
  • Applikationen müssen nach der Initialisierung zwingend die Schnittstelle ReportExecutionState(Running) aufrufen, um die Fertigstellung der Funktionsgruppen-Transition zu ermöglichen.
  • Bei Zustandsabwahl muss die Applikation auf Terminate() reagieren, ReportExecutionState(Terminating) melden und terminieren, woraufhin EM das Beenden per “waitpid” registriert.

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

R18-03_R1.4.0 → R18-10-1 normative Änderung Vorgänger: FIG-5bf6a4ae3c951ca0
  • Begrifflichkeit und API: Umbenennung von Application Process zu Process.
  • Begrifflichkeit und API: Umbenennung der Zustandsgruppe von Application State zu Execution State.
  • Schnittstelle: Umbenennung des Meldeaufrufs von ReportApplicationState(Running) zu ReportExecutionState(Running).
  • Schnittstelle: Umbenennung des Meldeaufrufs von ReportApplicationState(Terminating) zu ReportExecutionState(Terminating).
  • Manifest-Referenz: In Zustand Idle Verweis von (Application Manifest references FG1:State2) auf (Execution Manifest references FG1:State2) geändert.
R19-03 → R19-11 redaktionell Nachfolger: FIG-0714b8f0a5ed8dbd
  • Beschriftung: Kursivierung/Sternchen bei *SetState*(...) entfernt zu regulärem SetState(FG1, State2) und SetState(FG1, State3).
  • Beschriftung: Kastenbezeichnung Process unten links in Kleinbuchstaben process geändert.
  • Layout: Zeilenumbrüche in Zustandsfeldern (Idle, Initializing, Running, FG1:State1) typografisch umformatiert.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Erkannte Spezifikationsbelege & Anforderungen auf dieser Seite

RS_AP_00131 Wortlaut noch nicht übernommen RS_EM_00101 SWS_EM_01026 Wortlaut noch nicht übernommen

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Process | Execution Management | Execution State | Process State | Execute | FG1 State | Idle (Execution | Manifest references FG1:State2) | Starting | process created, resources | allocated | Terminated | process resources | freed | Initializing application | data initialization | Running perform main | functionality | Terminating | store data, free resources, | exit | Start() | Terminate() ReportExecutionState | (Running) | ReportExecutionState (Terminating) | Terminating Terminate | “waitpid” | process terminated | FG1:State1 initial state of | Function Group “FG1“ | (example) | FG1:State2 FG1:State3 | State Management | Arbitration of input data (e.g. state requests, events) to determine current target states | State Transition State Transition | *SetState*(FG1, State2) *SetState*(FG1, State3) return (success) | vehicle management, error management, diagnostics, authorized applications, etc. | Running | Process Lifecycle | managed by EM | State Transitions | managed by EM | confirm | trigger | optional | Terminate create process | allocate resources | schedule | Schedule | ara::com | return (success)

Vorkommen in AUTOSAR-Releases (4)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-10_R4.4.0_R1.5.0 AUTOSAR_SWS_ExecutionManagement S. 45 7.9 Figure 7.9: Interaction between states
R18-10-1 AUTOSAR_SWS_ExecutionManagement S. 45 7.9 Figure 7.9: Interaction between states
R19-03 AUTOSAR_SWS_ExecutionManagement S. 44 7.9 Figure 7.9: Interaction between states
R19-03 AUTOSAR_SWS_ExecutionManagement S. 44 7.9 Figure 7.9: Interaction between states