Figure 7.11: Dependency resolution during state change

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Zeitverlaufs- / Timing-Diagramm (Zustand-über-Zeit-Darstellung) synchronisierter diskreter Zustände für Funktionsgruppen und Prozesse.
• Technischer Zweck & funktionale Einordnung: Spezifikation des deterministischen Verhaltens von Execution Management (EM) in der AUTOSAR Adaptive Platform (AP) während einer Funktionsgruppen-Zustandstransition (FunctionGroupState Wechsel). Das Diagramm visualisiert die normative Auflösungsreihenfolge von Ausführungsabhängigkeiten (ExecutionDependency) gemäß SWS_EM_02245, wenn ein vorbedingender Prozess aufgrund geänderter Startparameter (StartupOptions) innerhalb des Zustandsübergangs neu gestartet werden muss.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten (AUTOSAR Adaptive Manifest-Modell, TPS_MANI_03149):
  • FunctionGroup (FG2): Zustandsgesteuerte Gruppierung von Prozessen mit den modellierten Zuständen FG2:Off, FG2:Running und FG2:Fallback.
  • Process A: MultiReferenceProcess, zugeordnet zu FG2:Running und FG2:Fallback. Besitzt in beiden Zuständen divergierende StartupOptions (Kommandozeilenparameter, Umgebungsvariablen).
  • Process B: Single-State- bzw. zielzustandsspezifischer Process, zugeordnet zu FG2:Fallback.
• Zustände des Lebenszyklus:
  • Prozesszustände: Idle, Running, Terminated (gesteuert durch POSIX-Lifecycle-Mechanismen via EM).
  • Transitionsphase (schraffierte Blöcke): Zeitspanne, in der EM die Prozesse für den Zielzustand rekonfiguriert.
• Beziehungen & Abhängigkeiten:
  • ExecutionDependency: Gerichtet von Process B auf Process A mit der Bedingung ProcessState == Running.
  • Multi-State-Mapping: Process A referenziert mehrere Zustände derselben Funktionsgruppe mit unterschiedlichen StartupConfig-Instanzen.

3. Dynamisches Verhalten & Sequenzablauf

1. Ausgangsbasis (FG2:Off → FG2:Running):
   • EM startet Process A bei Aktivierung von FG2:Running. Process A wechselt von Idle nach Running. Process B verbleibt in Idle.
2. Trigger für Zustandswechsel (FG2:Running → FG2:Fallback):
   • State Management (SM) fordert den Wechsel auf FG2:Fallback an (RequestedStates).
   • EM identifiziert, dass Process A in FG2:Fallback weiterhin aktiv sein muss, jedoch abweichende StartupOptions erfordert.
3. Konfliktvermeidung (Roter Pfad mit Sperrkreuz ×):
   • Fehlinterpretation: Würde EM die Abhängigkeit von Process B gegen die Alt-Zustände (CurrentStates) auflösen, wäre Process A bereits im Zustand Running. Process B würde sofort gestartet. Da Process A aber rekonfiguriert werden muss, würde er kurz darauf terminiert – Process B verlöre zur Laufzeit seine zwingende Vorbedingung.
4. Normativer Ablauf nach SWS_EM_02245 (Schwarzer Pfad):
   • Schritt 1 (Terminierung Process A, SWS_EM_01060): EM sendet SIGTERM an Process A. Process A wechselt von Running nach Terminated.
   • Schritt 2 (Neustart Process A, SWS_EM_01066): EM instanziiert Process A mit den neuen StartupOptions für FG2:Fallback. Process A wechselt wieder in Running.
   • Schritt 3 (Start Process B, SWS_EM_01066): Erst nachdem Process A im Kontext der RequestedStates den Zustand Running stabil erreicht und gemeldet hat (via Execution State API), wird die ExecutionDependency von Process B positiv evaluiert.
   • EM startet Process B; dieser wechselt von Idle nach Running.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Anforderungsdurchsetzung:
  • SWS_EM_02245 führt keine neue Ablauflogik ein, sondern erzwingt die strikte Ausführungsreihenfolge: [SWS_EM_01060] (Terminierung) und [SWS_EM_01066] (Neustart) für vorbedingende Prozesse (Process A) müssen zwingend vor [SWS_EM_01066] für abhängige Prozesse (Process B) abgeschlossen sein.
  • Traceability: Befriedigt RS_EM_00101 (Zustandssteuerung von Applikationen) und RS_AP_00131.
• Manifest-Design & Parametrierung:
  • Wenn ein Prozess über mehrere FunctionGroupStates hinweg kontinuierlich laufen soll, müssen die StartupOptions identisch sein. Weichen Parameter ab, erzwingt EM immer einen Stop-Start-Zyklus.
• Timing & State-Transition Latency:
  • Entwickler müssen die akkumulierte Transitionszeit $t_{\text{trans}} \ge t_{\text{term}}(A) + t_{\text{start}}(A) + t_{\text{start}}(B)$ bei der Auslegung der Funktionsgruppen-Timeouts berücksichtigen.
• Applikations-Design (IPC & IPC-Clients):
  • Process B darf die Schnittstellenkommunikation zu Process A erst aufbauen, wenn EM ihn freigibt. Process A muss SIGTERM deterministisch und ohne Blockaden quittieren, um Timeouts und daraus resultierende Fehlereskalationen (SIGKILL / Transition Failure) zu verhindern.