Figure 7.17: 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.
• ExecutionClient («ara::exec»):
  • Standard-Schnittstelle zur Lebenszyklus-Rückmeldung an das Execution Management.
  • Methoden:
    • + ReportExecutionState(): Meldet interne Prozesszustände (z. B. kRunning, kTerminating).

Beziehungen & Pfade

• Provided / Required Ports:
  • Application nutzt (Required Interface / Socket) die Schnittstellen DeterministicClient und ExecutionClient.
  • 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 ExecutionClient::ReportExecutionState(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 Ausführungszyklus (Aktivierungszeitpunkt).
   • Abfrage von deterministischer Zeit (GetActivationTime(), GetNextActivationTime()) und deterministischer Pseudozufallszahlen (GetRandom()).
   • Ggf. Abarbeitung paralleler Berechnungsaufgaben über RunWorkerPool().
3. Prozessterminierung:
   • Execution Management signalisiert der Application das Beenden (Terminate).
   • Die Applikation fährt kontrolliert herunter und meldet ihren Status über den ExecutionClient.

4. Normative Relevanz & Entwickler-Hinweise

• Normative Vorgaben:
  • Deterministische Anwendungen müssen für das Lifecycle-Management zwingend ara::exec::ExecutionClient nutzen und ihren Zustand via ReportExecutionState() melden.
  • Für deterministisches Verhalten dürfen keine nicht-deterministischen OS-Dienste (wie Standard-Systemuhren, unkoordinierte POSIX-Threads oder systemweite Entropiequellen) genutzt werden; stattdessen ist strikt ara::exec::DeterministicClient zu verwenden.
  • Das Execution Management steuert den Prozessstart und die Terminierung (Start / Terminate) normativ über Plattform-Mechanismen.
• Entwickler-Hinweise:
  • WaitForNextActivation() blockiert den aufrufenden Thread bis zur Freigabe des nächsten Ausführungszyklus durch das Execution Management.
  • Bei Nutzung von RunWorkerPool() ist sicherzustellen, dass die Worker-Tasks frei von Daten-Races und unkontrollierten Synchronisationsprimitiven sind, um Replay-Fähigkeit zu gewährleisten.