Figure 7.14: Dependency resolution during state change

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Zeitverlaufs- / Timing-Diagramm 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) für zwei Szenarien von Ausführungsabhängigkeiten (ExecutionDependency gemäß SWS_EM_02245):
  1. Abhängigkeit auf den Zustand "Running" bei Neustart eines Prozesses aufgrund geänderter Startparameter (StartupOptions).
  2. Abhängigkeit auf den Zustand "Terminated" bei einem vorbedingenden MultiReferenceProcess, der sich im Altzustand selbst beendet hat (Self Termination), jedoch für den Zielzustand erneut konfiguriert ist.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Entitäten (AUTOSAR Adaptive Manifest-Modell, TPS_MANI_03149):
  • FunctionGroup (FG2): Funktionsgruppe mit den Zuständen FG2:Off, FG2:Running und FG2:Fallback.
  • Process A: MultiReferenceProcess, zugeordnet zu FG2:Running und FG2:Fallback mit divergierenden StartupOptions.
  • Process B: Zielzustandsspezifischer Prozess, zugeordnet zu FG2:Fallback.
  • Process C: MultiReferenceProcess, zugeordnet zu FG2:Running und FG2:Fallback, führt während FG2:Running eine Selbstterminierung (Self Termination) durch (ohne gesonderte different StartupOptions-Annotation).
  • Process D: Zielzustandsspezifischer Prozess, zugeordnet zu FG2:Fallback.
• Zustände des Lebenszyklus:
  • Diskrete Prozesszustände: Idle, Running, Terminated.
  • Transitionsphasen (schraffierte Blöcke): Synchronisationsfenster des EM bei Funktionsgruppenwechseln.
• Beziehungen & Abhängigkeiten:
  • ExecutionDependency (B auf A): Bedingung ProcessState == Running.
  • ExecutionDependency (D auf C): Bedingung ProcessState == Terminated.
  • Multi-State-Mapping: Process A und Process C referenzieren mehrere Zustände derselben Funktionsgruppe.

3. Dynamisches Verhalten & Sequenzablauf

1. Szenario 1: Abhängigkeit auf "Running" (Prozesse A und B):
   • Initialphase: EM startet Process A beim Wechsel von FG2:Off nach FG2:Running. Process B bleibt in Idle.
   • Zustandswechsel (FG2:Running → FG2:Fallback): Process A erfordert aufgrund abweichender StartupOptions einen Neustart.
   • Konfliktvermeidung (Roter Sperrpfad ×): Keine vorzeitige Auflösung gegen CurrentStates.
   • Normativer Ablauf (Schwarzer Pfad): EM terminiert Process A via SIGTERM und instanziiert ihn mit den neuen StartupOptions neu; erst nach Erreichen von Running startet EM Process B.
2. Szenario 2: Abhängigkeit auf "Terminated" (Prozesse C und D):
   • Initialphase & Selbstterminierung: EM startet Process C beim Wechsel nach FG2:Running. Während FG2:Running beendet sich Process C selbst (Self Termination) und wechselt in den Zustand Terminated. Process D bleibt in Idle.
   • Zustandswechsel (FG2:Running → FG2:Fallback): Als MultiReferenceProcess, der für FG2:Fallback konfiguriert ist und den Zustand Terminated aufweist, wird Process C im Zielzustand regulär neu gestartet.
   • Konfliktvermeidung (Roter Sperrpfad ×): Die vor dem Übergang erfolgte Selbstterminierung darf nicht zur vorzeitigen Starterlaubnis für Process D führen, da Process C für FG2:Fallback re-exekutiert werden muss.
   • Normativer Ablauf (Schwarzer Pfad): EM startet Process C im Kontext von FG2:Fallback. Erst nachdem Process C diesen erneuten Durchlauf beendet hat und wieder in den Zustand Terminated gewechselt ist, wird die ExecutionDependency positiv evaluiert und EM startet Process D.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Spezifikationsbezüge: SWS_EM_02245 (Dependency resolution against RequestedStates), SWS_EM_01060, SWS_EM_01066, RS_EM_00101, RS_AP_00131.
• Regeln für MultiReferenceProcesses:
  • Für jeden MultiReferenceProcess, der mindestens einen der RequestedStates referenziert und sich im Zustand Idle oder Terminated befindet, ist ein Neustart durch EM zwingend vorgeschrieben.
  • Dies gilt uneingeschränkt auch für Prozesse, die sich im vorherigen Funktionsgruppenzustand bereits selbst beendet haben (Self Termination).
• Auflösung von Abhängigkeiten auf "Terminated":
  • Eine ExecutionDependency auf den Zustand Terminated darf bei einem Zustandsübergang erst dann als erfüllt bewertet werden, wenn der vorbedingende Prozess innerhalb des Gültigkeitsbereichs der RequestedStates seinen Lebenszyklus beendet hat.
  • Ein vor dem Zustandswechsel eingetretener Terminated-Status eines für den Zielzustand erneut konfigurierten Prozesses erfüllt die Abhängigkeit nicht vorab.
• Integrationshinweise:
  • Entwickler von kurzlebigen Initialisierungs-, Migrations- oder Setup-Tasks (Self Termination) müssen sicherstellen, dass deren Multi-State-Konfiguration im Manifest bewusst gewählt wird. Eine versehentliche Referenzierung im Zielzustand erzwingt eine erneute Ausführung vor dem Start nachfolgender Prozesse.