Figure 7.14: Deterministic Execution Interface

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm (cmp ArchitectureView-DeterministicClient) zur Darstellung der Schnittstellenarchitektur auf System- und Prozessebene.
• Technischer Zweck: Spezifiziert die Interaktion zwischen einer deterministischen Adaptive Application und dem funktionalen Cluster Execution Management (ara::exec) der AUTOSAR Adaptive Platform (Release R18-03 / R1.4.0).
• Funktionale Einordnung: Definiert die Abstraktion des Prozesslebenszyklus sowie die Entkopplung von nicht-deterministischen Plattform- und OS-Ressourcen (Systemuhr, Host-Threading, OS-Zufallsgeneratoren), um reproduzierbare Berechnungen (z. B. für automatisierte Fahrfunktionen, Replay-Simulationen und SIL/HIL-Validierung) zu garantieren.

2. Komponenten, Entitäten & Schnittstellen

Komponenten (UML Components)

• Application: POSIX-basierter Prozess der Adaptive Application, welcher Algorithmen mit deterministischer Ausführungscharakteristik kapselt. Fungiert als Client gegenüber beiden Schnittstellen.
• Execution Management: Zentraler Plattform-Daemon der Adaptive Platform (ara::exec), zuständig für Prozessüberwachung, deterministisches Scheduling und Lifecycle-Management. Stellt die korrespondierenden Ports bereit.

Schnittstellen & Klassen (Namespace «ara::exec»)

• DeterministicClient («ara::exec»):
  • Zugriffspunkt für deterministische Ausführungsmodelle.
  • Methoden:
    • + GetActivationTime(): Liefert den deterministischen Zeitstempel des aktuellen Ausführungszyklus (unabhängig von der realen Host-Laufzeit).
    • + GetNextActivationTime(): Liefert den geplanten deterministischen Startzeitpunkt des Folgezyklus.
    • + GetRandom(): Liefert pseudo-zufällige Werte aus einem reproduzierbaren, durch das Execution Management synchronisierten PRNG-Zustand.
    • + RunWorkerPool(): Triggert die parallele Abarbeitung deterministischer Teilaufgaben über einen verwalteten Worker-Pool unter Vermeidung von Race Conditions.
    • + WaitForNextActivation(): Blockierender Synchronisationspunkt, der den Prozess bis zur nächsten deterministischen Zyklus-Freigabe suspendiert.
• ApplicationClient («ara::exec»):
  • Standard-Schnittstelle zur Lebenszyklus-Rückmeldung an das Execution Management.
  • Methoden:
    • + ReportApplicationState(): Meldet interne Prozesszustände (z. B. kRunning, kTerminating).

Beziehungen & Pfade

• Provided / Required Ports:
  • Application nutzt (Required Interface / Socket) die Schnittstellen DeterministicClient und ApplicationClient.
  • Execution Management implementiert und exponiert (Provided Interface / Ball) beide Ports via IPC.
• Kontrollpfad Start / Terminate:
  • Gerichtete Kontrollbeziehung (gestrichelte Linie) vom Execution Management zur Application. Signalisiert die Erzeugung (POSIX fork/exec) und Terminierung (SIGTERM/SIGKILL) des Prozesses.

3. Dynamisches Verhalten & Sequenzablauf

1. Prozessinitialisierung:
   • Execution Management startet die Application (Start).
   • Die Applikation initialisiert ihre Ressourcen und meldet über ApplicationClient::ReportApplicationState(kRunning) ihre Betriebsbereitschaft.
2. Deterministische Regelschleife (Zyklische Abarbeitung):
   • Die Applikation ruft blockierend DeterministicClient::WaitForNextActivation() auf.
   • Nach Trigger durch das Execution Management erwacht die Applikation im definierten Zyklus.
   • Abfrage der logischen Zykluszeit über GetActivationTime() und optional GetNextActivationTime().
   • Bei Randomisierung Nutzung von GetRandom(); bei Datenparallelismus Ausführung über RunWorkerPool().
   • Abschluss der Zyklusberechnung; Rücksprung zu WaitForNextActivation().
3. Prozessterminierung:
   • Execution Management initiiert den Shutdown (Terminate).
   • Die Applikation verlässt die Regelschleife, meldet ReportApplicationState(kTerminating) und gibt Ressourcen frei.

4. Normative Relevanz & Entwickler-Hinweise

• Verbot direkter POSIX-Aufrufe: Entwickler deterministischer Applikationen dürfen keine nicht-deterministischen OS-Primitives verwenden (clock_gettime(), std::chrono::system_clock, std::thread, pthread_create, /dev/urandom, rand()). Zeit, Threading und Zufall müssen ausnahmslos über den DeterministicClient bezogen werden.
• Run-to-Completion & Barrieren: Berechnungen innerhalb eines Aktivierungszyklus müssen vor dem nächsten WaitForNextActivation() vollständig terminieren.
• Worker-Pool-Restriktionen: Parallelverarbeitung via RunWorkerPool() erfordert seiteneffektfreie Tasks, da das Framework die Reproduzierbarkeit der Abarbeitungsreihenfolge und Speicherzugriffe sicherstellt.
• Koexistenz: Die Implementierung von DeterministicClient entbindet nicht von der Pflicht, die Standard-Zustandsmeldungen über den ApplicationClient abzusetzen, um Watchdog-Timeouts und Alive-Supervision-Fehler durch das Execution Management zu verhindern.