Figure 4.2: High-level SW Architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Informelles Software-/Hardware-Architektur- und Schichtenmodell (High-Level Blockdiagramm / Deployment- & Abstraktionsmodell) gemäß AUTOSAR Adaptive Platform (Release R25-11).
• Technischer Zweck: Spezifikatorische Einordnung des Functional Clusters ara::hpc (Safe Hardware Acceleration API / Safe HWA API). Das Diagramm visualisiert die Trennung zwischen Applikationscode (AP application), der standardisierten Laufzeit- und Abstraktionsschicht (ara::hpc) und der physischen heterogenen Plattform (Host ECU).
• Funktionale Einordnung: Bereitstellung einer einheitlichen, sicherheitsgerichteten Abstraktion (ISO 26262) für rechenintensive Workloads (z. B. ADAS/AD, Computer Vision, Neuronale Netze). Ziel ist die Entkopplung der Applikation von herstellerspezifischen Beschleuniger-Schnittstellen (wie CUDA, OpenCL, Vulkan oder proprietären NPU-Treibern) durch ein einheitliches Ausführungs- und Speichermodell, das sowohl Standard-Host-CPUs als auch spezialisierte Hardware-Beschleuniger transparent adressiert.

2. Komponenten, Entitäten & Schnittstellen

Schichten und Akteure

1. AP application (Adaptive Application):
   • Nutzer der API im User-Space der Adaptive Platform.
   • Interagiert direkt über zwei Hauptpfade mit der Safe HWA API: Speicherverwaltung (allocate memory) und Ablaufsteuerung (submit tasks).
2. ara::hpc / Safe HWA API (Standardisierte Abstraktionsschicht):
   • Buffer:
     • Kapselt Allokation, Lebenszyklus und Zugriffsrechte von Speicherbereichen für Beschleunigungsoperationen.
     • Existiert in zwei Ausprägungen: Host-gebundener Puffer (Mapping auf Hauptspeicher) und Accelerator-gebundener Puffer (Mapping auf dedizierten Beschleunigerspeicher bzw. Shared/Unified Memory).
   • Queue:
     • Asynchrone Auftragswarteschlange zur Aufnahme, Serialisierung und Koordinierung von Rechenaufgaben.
     • Enthält jeweils eine Sequenz von n TaskHandler-Elementen.
   • TaskHandler:
     • Repräsentiert eine konkrete ausführbare Berechnungseinheit (Kernel/Compute Job).
     • Bindet die benötigten Ein-/Ausgabedaten (use Buffer) und definiert die Zielressource (executed on Device).
   • Device:
     • Logische Abstraktion einer konkreten Rechenressource.
     • Kapselt gerätespezifische Treiberaufrufe und leitet Befehle an die physische Ausführungseinheit weiter (CPU oder Accelerator).
3. Host ECU (Hardware-Ebene):
   • Host-Pfad: Bestehend aus Standard-CPU und System-Memory (DRAM/Host-RAM).
   • Hardware Accelerator (Dedizierte Beschleuniger-Domäne): Bestehend aus Accelerator (Rechenwerk wie GPU, DSP, NPU, FPGA) und lokalem Memory (VRAM, lokales SRAM oder dedizierte SPM-Bereiche).

Beziehungen & Kardinalitäten

• AP application → Buffer: 1 : n (allocate memory), Applikation erzeugt und verwaltet Pufferinstanzen.
• AP application → Queue: 1 : n (submit tasks), Applikation reiht Aufgaben in Queues ein.
• Queue ◇- TaskHandler: Komposition/Aggregation (1 : n), eine Queue verwaltet eine geordnete Menge an Tasks.
• TaskHandler → Buffer: n : m (use), ein Task konsumiert bzw. modifiziert einen oder mehrere Puffer.
• TaskHandler → Device: n : 1 (executed on), ein Task wird genau einem logischen Device zur Ausführung zugewiesen.
• Buffer → Memory: 1 : 1 (use), logische Puffer binden physische Allokationen (Host-Memory oder Accelerator-Memory).
• Device → CPU / Accelerator: 1 : 1 (use), das logische Device steuert die physische Recheneinheit an.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Speicherallokation (Synchron):
   • Die Applikation initialisiert Zielgeräte (Device) und Warteschlangen (Queue).
   • Pufferanforderung via allocate memory: Buffer fordert physischen Speicher an – entweder direkt im Host-RAM (Host ECU -> Memory) oder im dedizierten Beschleunigerspeicher (Hardware Accelerator -> Memory).
2. Task-Submission & Enqueuing (Asynchron):
   • Die Applikation definiert Rechenoperationen (Kernel-Parameter, Datenabhängigkeiten).
   • Aufruf von submit tasks: Erzeugt TaskHandler-Instanzen und reiht diese nicht-blockierend in die jeweilige Queue ein.
3. Ressourcenbindung & Dispatching:
   • Vor Ausführung bindet der TaskHandler die referenzierten Datenpuffer (use Buffer). Gegebenenfalls triggert die Laufzeitschicht implizite DMAs/Kopiervorgänge zwischen Host- und Device-Memory.
   • Die Queue delegiert den Task an das zugeordnete Device (executed on).
4. Hardware-Ausführung & Synchronisation:
   • Pfad A (Host-Fallback / CPU): Das Device stößt die Berechnung auf der nativen Host-CPU unter Zugriff auf das Host-Memory an.
   • Pfad B (Offloading / Accelerator): Das Device instruiert den Accelerator, der autonom auf seinem lokalen Memory operiert.
   • Statusüberwachung, Barrieren und Completion-Events werden über den TaskHandler an die Queue bzw. an die Applikation signalisiert (z. B. via Futures, Events oder Callback-Mechanismen).

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler:
  • Portabilität & Symmetrie: Das identische Abstraktionsmuster (Buffer + Queue + TaskHandler + Device) gilt für CPU- und Beschleuniger-Targets. Code kann prinzipiell ohne Neuarchitektur zwischen Host-CPU und Beschleuniger migriert werden (z. B. für Fallback-Strategien bei Hardwarefehlern).
  • Speichermodell & Latenzen: Zuweisung des Puffers (Buffer) entscheidet über Kopiervorgänge. Ist kein Unified Memory / Shared Virtual Memory (SVM) vorhanden, entstehen implizite Latenzen durch PCIe/Systembus-Transfers zwischen Host- und Accelerator-Memory.
  • Asynchronizität: Submissions sind standardmäßig asynchron; Synchronisationspunkte müssen explizit über Handhabung der TaskHandler gesetzt werden, um Pipeline-Stalls zu vermeiden.
• Treiber- und Stack-Entwickler (ara::hpc-Implementierer):
  • Safety & Isolation (ISO 26262): ara::hpc muss deterministisches Verhalten garantieren. Dies erfordert Watchdogs/Timeouts für blockierte Accelerator-Tasks, Speicherschutz (IOMMU/SMMU-Konfiguration für Puffer) und saubere Fehlerkapselung (z. B. Weiterleitung von Hardware-Exceptions an den Platform Health Management / PHM Cluster).
  • Queue-Scheduling: Die Queue-Implementierung muss Priorisierung, faire Zuteilung und ggf. deterministische Echtzeitgarantien für sicherheitskritische Tasks gegenüber Hintergrund-Workloads umsetzen.
  • Zero-Copy-Optimierung: Treiber sollten Shared-Memory-Architekturen optimal ausnutzen, um redundante Datenbewegungen zwischen Host- und Accelerator-Speicherbereichen zu eliminieren.