Figure 7.5: Execution dependencies on Non-reporting Process

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Timing-Diagramm / Zustands-Zeitablauf-Diagramm (State Timeline) kombiniert mit Funktionsgruppen-Zustandsphasen (Function Group State Transition).
• Architektur-Kontext & Zweck:
  • AUTOSAR Adaptive Platform (ARA), Spezifikation AUTOSAR_SWS_ExecutionManagement (Kapitel Execution Management Architecture & Functionality).
  • Modellierung von Prozesszuständen (Idle, Running, Terminated) und deren Steuerung während eines Funktionsgruppen-Zustandswechsels (FunctionGroupState Transition von FG1:Off nach FG1:Running).
  • Visualisierung des Lösungsansatzes für Ausführungsabhängigkeiten (ExecutionDependency) auf nicht-meldende Prozesse (Non-reporting Processes) und selbst-beendende Prozesse (Self-terminating Processes) über das Companion-Process-Muster, um Startup-Race-Conditions zu verhindern.

2. Komponenten, Entitäten & Schnittstellen

• Entitäten & Metamodell-Elemente:
  • FunctionGroup / FunctionGroupState (FG1:Off, FG1:Running): Betriebszustände der Machine, verwaltet durch das Execution Management (EM) und getriggert durch den State Management Cluster (ara::sm).
  • Process / ProcessExecution (A, B, C, D): Instanzen von Executable, zugeordnet zu FG1:Running via Metamodell-Referenz (ProcessToMachineMappingExec / State Dependent Startup Config).
    • **Prozess A (Non-reporting Process / Self-terminating Process):** Implementiert keinen ara::exec::ExecutionClient. Geht gemäß [SWS_EM_01402] unmittelbar nach dem Fork/Exec-Start durch das EM synthetisch in den Zustand Running über. Führt eine Initialisierungs- oder Einmalaufgabe aus und beendet sich selbstständig (Terminated).
    • **Prozess B (Companion Process):** Regulärer AUTOSAR-Adaptive-Prozess (reportingBehavior = reportsExecutionState). Besitzt eine ExecutionDependency auf Process A == Running. Dient als Prüfinstanz für die funktionale Betriebsbereitschaft von Prozess A.
    • **Prozess C (Dependent Process):** Regulärer Reporting-Prozess mit ExecutionDependency auf Process B == Running.
    • **Prozess D (Post-Termination Process):** Regulärer Prozess mit ExecutionDependency auf Process A == Terminated.
• Schnittstellen & Interaktion:
  • ExecutionDependency (Kardinalität 0..* im Metamodell ProcessExecutionStateDependency): Richtungsgebundene Startvorbedingung gekoppelt an Zielzustände (kRunning, kTerminated).
  • ara::exec::ExecutionClient::ReportExecutionState(): IPC-Schnittstelle zwischen Prozess und EM-Daemon. Wird von B, C und D genutzt, entfällt zwingend bei A.
  • OS-Kernel-Schnittstelle: Signalierung via SIGCHLD / waitpid() zur zuverlässigen Detektion des Zustands Terminated von Prozess A durch EM.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger des Funktionsgruppenwechsels:
   • Anforderung zur Transition von FG1:Off nach FG1:Running. Eintritt in die Übergangsphase (state transition, schraffierter Bereich).
2. Start von Prozess A (Non-reporting):
   • Prozess A besitzt keine eingehenden ExecutionDependency-Bedingungen und wird vom EM unmittelbar aus Idle gestartet.
   • Wirkung von SWS_EM_01402: Unmittelbar mit dem Start setzt EM den internen Zustand von A automatisch auf Running, da kein kRunning-Report über den ExecutionClient erwartet wird.
3. Trigger und Synchronisation des Companion-Prozesses B:
   • Das Erreichen von A == Running triggert die ExecutionDependency von Prozess B. EM startet Prozess B aus Idle.
   • Prozess B nutzt projektspezifische Mechanismen (z. B. IPC-Handshake, Socket-Verbindung, Prüfen von Lockfiles/Pipes), um zu verifizieren, ob Prozess A tatsächlich initialisiert und arbeitsfähig ist.
   • Erst nach erfolgreicher Verifikation meldet B aktiv ExecutionState::kRunning an das EM. B geht in Running über.
4. Kaskadierter Start von Prozess C:
   • Die ExecutionDependency von Prozess C auf B == Running wird erfüllt. EM startet Prozess C; C meldet Running.
5. Terminierung von Prozess A & Start von Prozess D:
   • Prozess A schließt seine Aufgabe ab und terminiert. Das OS signalisiert das Prozessende an EM; A wechselt in Terminated.
   • Die ExecutionDependency von D auf A == Terminated wird erfüllt. EM startet Prozess D (Wechsel Idle → Running).
6. Abschluss der Transition:
   • Nach Erreichen aller geforderten Zustände wird die Transition beendet und der Zielzustand FG1:Running erreicht.

4. Normative Relevanz & Entwickler-Hinweise

• Spezifikationsanforderung [SWS_EM_01402]:
  • Normativer Wortlaut/Inhalt: Wird ein Prozess als Non-reporting Process konfiguriert, betrachtet das Execution Management diesen unmittelbar nach dem Startaufruf als im Zustand Running befindlich.
• **Architektur-Pattern (Companion Process):**
  • Eine direkte ExecutionDependency eines Drittprozesses (C) auf einen Non-reporting-Prozess (A) mit Zielzustand kRunning ist ein kritisches Fehlmuster (Race Condition): C würde gestartet, bevor A initialisiert ist.
  • Das Companion-Muster kapselt die fehlende EM-Reporting-Fähigkeit von Drittanbieter-/Legacy-Binaries durch einen zwischengeschalteten Überwacherprozess B.
• Zuverlässigkeit von Terminated:
  • Im Gegensatz zum Zustand Running erfordert der Zustand Terminated keinen ExecutionClient-Aufruf, da der Exit-Status direkt vom OS-Kernel an EM gemeldet wird. Abhängigkeiten auf kTerminated eines Non-reporting Prozesses sind daher ohne Companion-Prozess deterministisch und sicher einsetzbar.
• Manifest-Konfiguration:
  • Im Execution-Manifest muss für Prozess A reportingBehavior = false / doesNotReportExecutionState gesetzt sein.
  • Startup-Timeouts zur Überwachung des kRunning-Eingangs greifen für A nicht. Bleibt A hängen, ohne zu terminieren, muss die Fehlerbehandlung über den Companion-Prozess B oder den Platform Health Management Cluster (ara::phm) erfolgen.