Figure 7.13: Interaction between states

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 via SIGTERM. Registriert die Prozessbeendigung via EXIT_SUCCESS.
• process: Beinhaltet die internen Zustände des Execution State (Initializing, Running und Terminating). Meldet den Ausführungsstatus an EM ausschließlich über ReportExecutionState(Running).
• 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 sendet das Signal SIGTERM an den Process.
7. Der Process wechselt nach Terminating (store data, free resources, exit) und beendet sich eigenständig ohne Meldung eines Terminating-Zustands an EM.
8. Das Beenden des Prozesses wird mit dem Exit-Code EXIT_SUCCESS (process terminated) an EM gemeldet; der Process State wechselt nach Terminated (process resources freed), und EM schließt den Funktionsgruppenwechsel an SM mit return (success) ab.

4. Normative Relevanz & Entwickler-Hinweise

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

• Applikationen müssen nach der Initialisierungsphase aktiv ReportExecutionState(Running) melden, damit EM den Funktionsgruppenübergang an SM erfolgreich quittiert.
• Bei Aufforderung zur Beendigung über SIGTERM erfolgt keine Rückmeldung ReportExecutionState(Terminating) mehr; die Applikation bereinigt ihre Ressourcen, terminiert und liefert EXIT_SUCCESS an die Plattform zurück.
• EM wertet den Exit-Status EXIT_SUCCESS zur Bestätigung der ordnungsgemäßen Prozessbeendigung aus.