Figure 7.14: Cyclic Deterministic Execution

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Mischform aus architekturellem Kontrollfluss-, Prozess- und Interaktionsdiagramm (Daten-/Kontrollflussschema mit Fork-Join-Parallelitätsmodell).
• Architektonischer Zweck: Spezifikation des Ausführungsmodells für zyklisch-deterministische Prozesse (Deterministic Execution) innerhalb der AUTOSAR Adaptive Platform (ARA) gemäß AUTOSAR_SWS_ExecutionManagement.
• Funktionale Einordnung: Gewährleistet softwareseitige Reproduzierbarkeit (zeitlicher und datenbezogener Determinismus). Ein Benutzerprozess (user process) wird in feste Aktivierungszyklen segmentiert, isoliert Eingangs- und Ausgangsdaten von der Umwelt und steuert nebenläufige Berechnungsstränge deterministisch über einen synchronisierten Worker-Pool.

2. Komponenten, Entitäten & Schnittstellen

• user process (OS-Prozessgrenze): Kapselt den Anwendungs-Haupt-Thread sowie verwaltete Worker-Threads.
• DeterministicClient (Klasse / Laufzeit-Bibliothek):
  • Schnittstelle des Execution Management zur Anwendung.
  • Verantwortlichkeiten: Zyklussteuerung, Worker-Pool-Management, Bereitstellung deterministischer Pseudozufallszahlen und logischer Zeitstempel.
  • APIs:
    • WaitForNextActivation(): Blockiert bis zum Start des nächsten logischen Zyklus.
    • RunWorkerPool(): Triggert die parallele Ausführung vordefinierter Runnable-Tasks auf dem Worker-Pool.
    • GetRandom(): Liefert deterministische Pseudozufallszahlen (reproduzierbare Seed-Sequenz je Zyklus).
    • GetActivationTime(), GetNextActivationTime(): Liefert feste, an den Zyklus gebundene Zeitreferenzen (keine unkoordinierte Abfrage einer unsynchronisierten Systemzeit).
• Worker-Threads (worker):
  • Zustandslose oder strikt isolierte Ausführungseinheiten innerhalb des Worker-Pools.
  • Entkopplung: Explizit annotiert mit „no interaction“ (rote Sperrbalken). Keine Inter-Thread-Kommunikation, keine Mutexe/Shared-Memory-Races zwischen parallelen Workern.
• Lebenszyklus-Zustände / Phasen:
  • Register Services, Service Discovery, Init, Run, Terminate: Explizite Phasensteuerung, wobei Run den zyklischen Berechnungszweig darstellt.
• Communication Management (ara::com):
  • Serviceorientierte Kommunikationsschicht für I/O.
  • Interaktion: Synchronisation mit dem Aktivierungszyklus („synchronization with activation cycle – details not yet specified“ in R18-03).
  • Datentransfer: access input data (lesend zu Zyklusbeginn) und publish output data (schreibend zu Zyklusende).

3. Dynamisches Verhalten & Sequenzablauf

1. Zyklus-Initialisierung & Trigger:
   • Der Hauptkontrollknoten ruft synchron WaitForNextActivation() am DeterministicClient auf.
   • Der Thread blockiert, bis der nächste deterministische Rechenzyklus freigegeben wird.
2. Eingangsdaten-Snapshot:
   • Vor Beginn der eigentlichen Berechnungen holt der Prozess atomar konsistente Eingangsdaten über ara::com ab (access input data). Während des Berechnungszyklus bleiben diese Eingangsdaten unveränderlich (Double-Buffering / Snapshot-Semantik).
3. Phasen-/Zustandsauswahl:
   • Verzweigung in Steuerphasen (Register Services, Service Discovery, Init, Run, Terminate).
4. Parallele Rechenphase (Run via Fork-Join):
   • Fork 1: Haupt-Thread ruft RunWorkerPool() auf. Verteilung auf N parallele Worker-Instanzen.
   • Ausführung 1: Worker führen deterministische Berechnungen isoliert aus (optional Aufruf von GetRandom()).
   • Barrier/Join 1: Synchronisation im Join-Knoten; Haupt-Thread übernimmt wieder sequentiell.
   • Fork 2: Erneuter Aufruf von RunWorkerPool() für nachgelagerte Worker-Kaskade.
   • Barrier/Join 2: workers joining – Zusammenführen aller Rechenstränge an der finalen Barriere.
5. Zeitabfrage & Publikation:
   • Abfrage der logischen Aktivierungszeiten (GetActivationTime(), GetNextActivationTime()).
   • Konsistente Veröffentlichung aller Zyklus-Ergebnisse via ara::com (publish output data).
6. Rückkopplung:
   • Rücksprung zum Hauptkontrollknoten zur Vorbereitung des nächsten Zyklus (WaitForNextActivation()).

4. Normative Relevanz & Entwickler-Hinweise

• Restriktionen für Anwendungsentwickler:
  • Verbot asynchroner OS-Primitive: Kein freies Erzeugen von POSIX-Threads (pthread_create), keine freien Locks (std::mutex) und keine asynchronen Sleeps (sleep, usleep). Alle Nebenläufigkeiten müssen zwingend über DeterministicClient::RunWorkerPool() abgewickelt werden.
  • Verbot nicht-deterministischer Quellen: Direkte Zugriffe auf POSIX-Uhren (clock_gettime) oder hardwarebasierte Zufallsgeneratoren (/dev/random) führen zum Verlust des Determinismus. Es dürfen ausschließlich die Schnittstellen GetActivationTime() und GetRandom() verwendet werden.
  • Keine Worker-Interaktion: Worker dürfen keine gemeinsamen Variablen mutieren; Datenfluss zwischen Workern ist rein über Eingangs-/Ausgangspuffer sequentieller Stufen (über Barrier/Join) abzubilden.
• Integrations- & I/O-Vertrag (ara::com):
  • I/O-Aktivitäten sind strikt phasenbasiert: Samples dürfen nur am Anfang des Zyklus gelesen und am Ende veröffentlicht werden. Das Kommunikations-Subsystem muss sicherstellen, dass Datenkonsistenz über den gesamten Rechenzyklus hinweg garantiert ist.
• Plattform-Status (R18-03):
  • Die Kopplung zwischen Zyklus-Trigger und ara::com-Synchronisation ist im Standard R18-03 als konzeptionell offengelegt („details not yet specified“), was herstellerspezifische Adaptionen (z. B. synchrone Event-Queues oder deterministische Pufferung) im Stack-Design erfordert.