Figure 9.85: Interfaces for hardware accelerated execution

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm / Schnittstellen-Realisierungsdiagramm mit Komponentenbezug.
• Architektur-Kontext:
  • Plattform: AUTOSAR Adaptive Platform (AP), Release R25-11.
  • Funktionaler Cluster: Safe Hardware Acceleration (Kurzname: shwa), Kategorie: Safety, Ausprägung: Non-daemon-based (In-Process-Bibliothek).
  • Funktionale Einordnung: Bereitstellung eines standardisierten, funktional sicheren Ausführungsmodells für heterogene Recheneinheiten (z. B. GPUs, DSPs, NPUs, FPGAs). Das API-Design orientiert sich an modernen Standards für heterogenes Rechnen (SYCL/OpenCL) und trennt Host-Steuerung, Befehlswarteschlangen, Kernel-Dispatching und asynchrone Synchronisation.

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Stereotypen

• Adaptive Application: Konsumierende Anwendungskomponente (Client-Prozess im AP-User-Space).
• «aapFunctionalCluster» Safe Hardware Acceleration: Realisierender funktionaler Cluster, der die Hardwarebeschleunigungs-Laufzeitumgebung implementiert.
• Schnittstellen (jeweils mit Stereotyp «aapAPI, aapNativeInterface»):
  • Platform: Verwaltung und Abfrage der verfügbaren Hardware-Plattformen und Beschleuniger-Backends.
    • + GetPlatforms() (statisch): Enumeriert verfügbare Beschleuniger-Plattformen auf der Machine.
    • + GetDevices(): Liefert die physischen Ausführungseinheiten (Devices) einer Plattform-Instanz.
  • Queue: Asynchrone Befehlswarteschlange (Command Queue) für ein spezifisches Beschleunigergerät.
    • + Create() (statisch): Factory-Methode zur Instanziierung einer Queue für ein Zielgerät.
    • + GetDevice(): Referenz auf das zugewiesene Rechengerät.
    • + IsInOrder(): Gibt an, ob Tasks strikt sequenziell (In-Order) oder nebenläufig/abhängigkeitsbasiert (Out-of-Order) abgearbeitet werden.
    • + Submit(): Reiht Ausführungsobjekte bzw. Task-Handler in die Warteschlange ein.
    • + Wait(): Synchronisationsbarriere; blockiert, bis alle Aufgaben der Queue abgearbeitet sind.
  • TaskHandler: Kapselt die Ausführungskonfiguration von Rechen-Workloads (Kernels) auf dem Beschleuniger.
    • + Create() (statisch): Erstellt eine neue Instanz zur Task-Definition.
    • + ParallelFor(): Startet datenparallele Workloads über einen Indexraum (SIMD-/Grid-Ausführung, ein Work-Item pro Index).
    • + SingleTask(): Führt eine einzelne Kernel-Instanz exklusiv auf dem Zielgerät aus.
  • Event: Asynchroner Synchronisations- und Tracking-Primitiv für eingereichte Operationen.
    • + Create() (statisch): Erzeugt ein Event-Objekt.
    • + GetWaitList(): Ruft Abhängigkeitslisten ab, die vor der Ausführung erfüllt sein müssen.
    • + Wait() (überladen): Blockiert den aufrufenden Host-Thread bis zum Abschluss der mit dem Event verknüpften Operation (optional mit Timeout oder Listener-Bindung).

Beziehungen

• Realisierung («realize» / gestrichelte Linie mit geschlossener Dreiecksspitze): Safe Hardware Acceleration realisiert vollständig die vier Schnittstellen TaskHandler, Queue, Platform und Event.
• Nutzung («use» / gestrichelte Pfeillinie): Adaptive Application bindet alle vier C++ Native Interfaces direkt ein und interagiert über diese mit dem Cluster.

3. Dynamisches Verhalten & Sequenzablauf

Typischer Host-Device-Ausführungszyklus:

1. Discovery & Selektion:
   • Abfrage der Plattformen via Platform::GetPlatforms().
   • Selektion der Zielhardware (GPU/NPU/DSP) über platform.GetDevices().
2. Queue-Initialisierung:
   • Erzeugen einer Instanz via Queue::Create(device, ...).
   • Konfiguration/Prüfung der Ausführungssemantik über IsInOrder().
3. Task-Definition & Enqueueing:
   • Erzeugen eines Ausführungskontexts über TaskHandler::Create().
   • Definition des Ausführungsmodus (SingleTask für Einzelberechnungen oder ParallelFor für Vektor-/Matrix-Workloads).
   • Asynchrones Einreichen des Tasks in die Queue via Queue::Submit(). Dies liefert ein Event-Objekt zurück bzw. bindet ein solches ein.
4. Synchronisation & Completion:
   • Steuerung von Task-Abhängigkeiten via Event::GetWaitList().
   • Warten auf Teilschritte über Event::Wait() oder bündiges Warten auf die gesamte Befehlswarteschlange mittels Queue::Wait().

4. Normative Relevanz & Entwickler-Hinweise

• Non-Daemon-Architektur: Da shwa nicht daemon-basiert ist, läuft die Middleware als In-Process-C++-Bibliothek im Adressraum der Adaptive Application. IPC-Roundtrips zum Dispatching entfallen, wodurch minimaler Overhead und deterministische Latenzen erreicht werden.
• Ausführungs-Restriktionen:
  • Operationen wie ParallelFor() und SingleTask() dürfen ausschließlich innerhalb des Kontexts eines an die Queue übergebenen Tasks (Submit()) aufgerufen werden; ein direkter, isolierter Aufruf auf dem Host schlägt fehl.
• Safety- & Concurrency-Vorgaben (ASIL):
  • Bei Out-of-Order-Queues (IsInOrder() == false) liegt die Verantwortung für Race-Condition-freie Synchronisation über Event-Waitlists beim Anwendungsentwickler.
  • Speicherbarrieren und Cache-Kohärenz zwischen Host-CPU und Beschleuniger müssen über die zugehörigen Device-Memory-APIs (in Folge-Diagrammen spezifiziert) synchronisiert werden, bevor Wait()-Barrieren verlassen werden.
  • Event::Wait() muss deterministische Timeouts unterstützen, um Deadlocks durch hängende Beschleuniger-Hardware abfangen zu können (Safe State Transition).