Figure 7.14: Example configuration for state transition

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptuelles Architektur- und Modellierungs-Constraint-Diagramm (Instanzebene des AUTOSAR Adaptive Metamodells für Execution Management).
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Subsystem Execution Management (EM) im Zusammenspiel mit dem State Management (SM).
• Technischer Zweck: Visualisierung der normativen Randbedingungen für Prozessabhängigkeiten (ExecutionDependency, [constr_1689]) über Funktionsgruppen (FunctionGroup) und Funktionsgruppenzustände (FunctionGroupState) hinweg sowie Demonstration der Auswirkungen divergierender Startup-Konfigurationen bei Zustandswechseln ([SWS_EM_02251]).

2. Komponenten, Entitäten & Schnittstellen

• Metamodell-Entitäten (Klassen & Instanzen):
  • FunctionGroup (äußere Ovale):
    • FG_A, FG_B: Orthogonale Zustandssteuerungsdomänen auf Maschinenebene (Modellierung via ModeDeclarationGroupPrototype).
  • FunctionGroupState (innere, blaue Ovale):
    • FG_A: Zustand ON.
    • FG_B: Zustände ABC und XYZ.
  • Process (grüne Kreise):
    • Instanzen von Process (OS-Level-Prozesse): A (in FG_A:ON), B & C (in FG_B:ABC), B & D (in FG_B:XYZ).
  • StateDependentStartupConfig / StartupConfig:
    • Prozess B instanziiert je Zustand (ABC vs. XYZ) eine eigene StateDependentStartupConfig.
• Beziehungen & Abhängigkeitsregeln (ExecutionDependency):
  • Zulässige Abhängigkeiten (rote Pfeile ohne Kreuz):
    • FG_B:ABC: Prozess B → Prozess C (Prozess B erfordert, dass C gestartet wurde und betriebsbereit ist; strikt intra-state).
    • FG_B:XYZ: Prozess D → Prozess B (Prozess D erfordert, dass B betriebsbereit ist; strikt intra-state).
  • Unzulässige / Verbotene Abhängigkeiten (durchkreuzte rote Pfeile):
    • Inter-Function-Group-Abhängigkeit (B → A): Verboten gemäß [constr_1689]. Ein Prozess in FG_B darf keine direkte Ausführungsabhängigkeit zu einem Prozess in FG_A besitzen. Grund: Verdeckte, für das State Management unsichtbare Kopplungen zwischen unabhängigen Funktionsgruppen.
    • Inter-State-Abhängigkeit (D → C): Verboten gemäß [constr_1689]. Ein Prozess in FG_B:XYZ darf nicht von einem Prozess in FG_B:ABC abhängen, da C im Zustand XYZ nicht als laufend konfiguriert ist.

3. Dynamisches Verhalten & Sequenzablauf

• Zustandsinitiierung & Auswertung:
  • Trigger: Zustandsänderungsanforderung durch das State Management via ara::exec::StateClient::SetState("FG_B", "ABC") bzw. "XYZ".
  • DAG-Auflösung (Directed Acyclic Graph): EM parst die ExecutionDependency-Elemente der jeweiligen StateDependentStartupConfig ausschließlich innerhalb des angeforderten Zielzustands.
    • In FG_B:ABC: Startreihenfolge: 1. C → Warten auf State Reporting via ara::exec::ApplicationClient::ReportApplicationState(ApplicationState::kRunning) → 2. Start von B.
• Zustandsübergang FG_B: ABC → XYZ:
  1. Terminierung nicht mehr aktiver Prozesse: Prozess C existiert in XYZ nicht → EM sendet SIGTERM (bzw. konfigurierte De-Escalation/Grace-Period) an C.
  2. Erzwungener Neustart ([SWS_EM_02251]): Prozess B existiert zwar in beiden Zuständen, besitzt jedoch unterschiedliche StateDependentStartupConfigs (in ABC existiert eine Dependency auf C, in XYZ nicht; B fungiert nun als Target-Dependency für D). EM stoppt B (SIGTERM), wartet auf Beendigung und startet B unter der Konfiguration von XYZ neu.
  3. Sequenzierter Hochlauf in XYZ: Sobald der neu gestartete Prozess B den Zustand kRunning meldet, startet EM Prozess D.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Referenzen:
  • [SWS_EM_01001]: Definiert Semantik und Gültigkeitsbereich von Ausführungsabhängigkeiten.
  • [constr_1689]: Validierungsregel für Generatoren und Manifest-Checker: Eine ExecutionDependency darf niemals die Grenzen eines FunctionGroupState überschreiten (weder funktionsgruppenübergreifend noch zustandsübergreifend). Verletzungen führen zum Abbruch des Manifest-Deployments / ARXML-Validierungsfehlern.
  • [SWS_EM_02251]: Ändert sich beim Wechsel des FunctionGroupState die StateDependentStartupConfig eines Prozesses (z. B. Argumente, Umgebungsvariablen, Resource-Limits oder Dependencies), ist das EM verpflichtet, den Prozess neu zu starten.
• Architektur- & Integrationsvorgaben:
  • Entkopplung über State Management: Müssen Prozesse aus FG_B auf Services aus FG_A warten, darf dies nicht über Start-Dependencies modelliert werden. Die Synchronisation muss auf Applikationsebene (z. B. via ara::com Service-Discovery / FindService) oder über das State Management erfolgen (SM wechselt FG_B erst nach erfolgreicher Bestätigung von FG_A:ON).
  • Laufzeit- und Latenzoptimierung: Soll ein Prozess über mehrere Function-Group-States hinweg ohne Unterbrechung durchlaufen, müssen seine StateDependentStartupConfig-Definitionen in allen beteiligten Zuständen identisch gehalten werden. Divergierende Abhängigkeiten erzwingen unweigerlich Prozessabrisse und Neustart-Overhead.