Figure 7.8: 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 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 externer Anforderungen (via ara::com aus Fahrzeugmanagement, Diagnose, Fehlermanagement etc.) mit der Schnittstelle SetState(FG1, State) an EM und Empfang von ConfirmState: FG1, StateX.
• Execution Management (EM): Zentrale Plattformkomponente, 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 Terminierung (Terminate(), “waitpid”).
• Application Process: Enthält die internen Zustände Initializing, Running und Terminating. Kommuniziert Zustandswechsel an das EM über ReportApplicationState(Running) und ReportApplicationState(Terminating).
• Schnittstellen & Pfeilarten: Durchgezogene Pfeile kennzeichnen Auslöser/Trigger (trigger), gestrichelte Pfeile Quittierungen/Bestätigungen (confirm).

3. Dynamisches Verhalten & Sequenzablauf

1. State Management empfängt Anforderungen über ara::com und initiiert per SetState(FG1, State2) einen Zustandswechsel im EM.
2. Der FG1-Übergang von FG1:State1 nach FG1:State2 triggert im Process State den Wechsel von Idle nach Starting (Execute), worauf EM den Prozess erzeugt (Start(), create process, allocate resources).
3. Nach erfolgreicher Ressourcenallokation wechselt der Process State zu Running (Schedule), und EM plant den Prozess zur Ausführung ein (schedule).
4. Der Application Process durchläuft Initializing und meldet nach Erreichen von Running per ReportApplicationState(Running) an EM.
5. EM bestätigt den Abschluss des Funktionsgruppenwechsels an SM mittels ConfirmState: FG1, State2.
6. Nachfolgend initiiert SM per SetState(FG1, State3) den nächsten Zustandswechsel. Da die Manifest-Konfiguration nur FG1:State2 referenziert, triggert dies die Terminierung: Process State wechselt nach Terminating (Terminate), und EM sendet Terminate() an den Application Process.
7. Der Application Process wechselt (optional direkt aus Running) nach Terminating, sichert Daten, gibt Ressourcen frei und meldet ReportApplicationState(Terminating) an EM.
8. Nach Beendigung des Prozesses synchronisiert EM via “waitpid” (process terminated), der Process State wechselt nach Terminated (process resources freed), und EM bestätigt mit ConfirmState: FG1, State3 den Zustandswechsel an SM.

4. Normative Relevanz & Entwickler-Hinweise

Das Diagramm definiert das normative Interaktionsprotokoll zwischen State Management, Execution Management und Applikationsprozessen. Entwickler von Adaptive Applications müssen beachten:

• Die Benachrichtigung ReportApplicationState(Running) ist zwingend erforderlich, da EM erst nach deren Erhalt den FG-Zustandswechsel erfolgreich bestätigt.
• Auf den Empfang des Terminationssignals (Terminate()) muss die Anwendung in den Zustand Terminating übergehen, Daten sichern, Ressourcen bereinigen, ReportApplicationState(Terminating) aufrufen und sich beenden.
• Das Prozess-Manifest bindet Prozesse deklarativ an bestimmte Funktionsgruppenzustände. Die Ausführung identischer Interaktionen gilt auch für Bindungen an Machine States.