DEENESPTFRRUARHIKOZHNL
AUTOSAR_SWS_ExecutionManagement FIG-5bf6a4ae3c951ca0 831 × 886 px 1 Release(s)

Figure 7.10: Interaction between states

SHA-256 Inhalts-Fingerabdruck: 5bf6a4ae3c951ca0daad84161bf4f10ac1bd56aad29889113fda99f5c5b988ac

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 Application Process. Es visualisiert horizontal über die Zeitachse die Korrelation von Funktionsgruppenzuständen (FG1 State), prozessbezogenen Lebenszykluszuständen im EM (Process State) sowie internen Anwendungszuständen (Application 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 synchronen 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”).
  • Application Process: Beinhaltet die internen Zustände Initializing, Running und Terminating. Meldet Zustandsfortschritt an EM über ReportApplicationState(Running) sowie ReportApplicationState(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 Application 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 Application Process wechselt von Initializing nach Running und setzt den Aufruf ReportApplicationState(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 nur für FG1:State2 konfiguriert ist, wechselt der Process State nach Terminating (Terminate), und EM ruft Terminate() am Application Process auf.
  7. Der Application Process wechselt nach Terminating (store data, free resources, exit) und sendet ReportApplicationState(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 Quittierung der Zustandsänderungsanforderung an SM erfolgt über return (success) nach Erhalt der Prozessmeldung.
  • Applikationen müssen nach der Initialisierung zwingend ReportApplicationState(Running) aufrufen, um die Fertigstellung der Funktionsgruppen-Transition zu ermöglichen.
  • Bei Zustandsabwahl muss die Applikation auf Terminate() reagieren, ReportApplicationState(Terminating) melden und terminieren, woraufhin EM das Beenden per “waitpid” registriert.

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

R17-10_R1.2.0 → R18-03_R1.4.0 normative Änderung Vorgänger: FIG-f17883cc175583a4
  • State Management: Rückmeldung an State Management von ConfirmState: FG1, State2 bzw. ConfirmState: FG1, State3 geändert auf return (success).
  • State Management: Aufruf an Execution Management syntaktisch von SetState(...) auf *SetState*(FG1, State2) bzw. *SetState*(FG1, State3) typografisch angepasst.
R18-03_R1.4.0 → R18-10-1 normative Änderung Nachfolger: FIG-4f38eb7fbed6624a
  • 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.

Zugeordnete Anforderungen

Diese Angaben zeigt der Versions-Explorer.

Aus dem Dokument extrahierter Text & Kontext

Beschriftungen im Schaubild:

Application Process | Execution Management | Application State | Process State | Execute | FG1 State | Idle (Application | 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() ReportApplicationState | (Running) | ReportApplicationState (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)

Begleitender Spezifikationstext:

Specification of Execution Management AUTOSAR AP Release 18-03 7.4.5.2 State Interaction Figure 7.10 shows a simplified example for the interaction between different types of states. One can see the state transitions of a Function Group and the Process and Application States of one Process which references one state of this Function Group, ignoring possible delays and dependencies if several Processes were involved. The interaction is identical if the Process references a Machine State instead of a Function Group State. Application Process Execution Management Application State Process State Execute FG1 State Idle (Application 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() ReportApplicationState (Running) ReportApplicationState (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 pro

Vorkommen in AUTOSAR-Releases (1)

Release Dokument Seite Nr. Bildunterschrift im Dokument
R18-03_R1.4.0 AUTOSAR_SWS_ExecutionManagement S. 40 7.10 Figure 7.10: Interaction between states