Figure 4.2: High-level SW Architecture

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: High-Level Software-/Hardware-Architektur- und Schichtenmodell (Struktur- und Mapping-Diagramm) zur Abbildung logischer AUTOSAR Adaptive Platform (AP) Entitäten auf physische Host- und Accelerator-Ressourcen.
• Technischer Zweck: Spezifikationskontext des Functional Clusters bzw. Namespace ara::hpc (AUTOSAR_AP_EXP_SafeAPIHardwareAccelerators, R23-11/R24-11). Kapselung und Abstraktion heterogener Compute-Einheiten (Host-CPU vs. Hardware-Beschleuniger wie GPU, NPU, DSP, FPGA) unter einer standardisierten, funktional sicheren Programmierschnittstelle (Safe HWA API) für deterministische, parallele HPC-Workloads.

2. Komponenten, Entitäten & Schnittstellen

• AP application: Adaptive Application im POSIX-/User-Space-Kontext. Fungiert als Client für Speicherallokation und asynchrone Task-Submission.
• ara::hpc / Safe HWA API (Abstraktionsschicht):
  • Buffer: Kapselung linearer Speicherbereiche. Bietet Abstraktionen für Allokation (allocate memory), Adressübersetzung und kohärente Speicherzugriffe über heterogene Busdomänen hinweg.
  • Queue: Zustandsbehaftete FIFO-/Scheduling-Warteschlange für Berechnungsaufträge; jeweils einem logischen Device zugeordnet.
  • TaskHandler: Atomares Ausführungselement innerhalb einer Queue. Kapselt Kernel-/Graph-Instruktionen, Ausführungskontexte und Pufferreferenzen (use).
  • Device: Logischer Repräsentant einer physischen Ausführungseinheit. Vermittelt zwischen Queue/TaskHandler und der zugrunde liegenden Recheneinheit (executed on).
• Host ECU (Physische Zielhardware):
  • Host-Domäne: Standard-Mehrkern-CPU und primärer Systemspeicher (Memory).
  • Hardware Accelerator: Dedizierte Beschleuniger-Hardwarekomponente, gegliedert in spezialisierte Compute-Engines (Accelerator) und separaten bzw. schnellen On-Chip-/Device-Speicher (Memory, z. B. HBM, LPDDR, SRAM).
• Beziehungen und Mapping:
  • Symmetrische Schnittstellenarchitektur: CPU-basierte Pfade und dedizierte Hardware-Beschleuniger-Pfade verwenden identische Schnittstellentypen (Buffer, Queue, TaskHandler, Device).
  • Buffer (links) mappt physisch auf Host ECU -> Memory; Device (links) mappt auf Host ECU -> CPU.
  • Buffer (rechts) mappt physisch auf Hardware Accelerator -> Memory; Device (rechts) mappt auf Hardware Accelerator -> Accelerator.
  • Kardinalitäten: Eine Queue verwaltet 1..n TaskHandler; ein TaskHandler bindet an 1..n Buffer und wird genau einem Device zugeordnet.

3. Dynamisches Verhalten & Sequenzablauf

1. Speicherallokation (allocate memory): Die AP application initiiert die Pufferallokation über die API. Die Speicherplatzierung erfolgt zielgerichtet entweder im Host-RAM oder im Accelerator-Speicher (bzw. Unified Memory).
2. Task-Konfiguration & Submission (submit tasks): Die Anwendung serialisiert Rechenoperationen in TaskHandler-Instanzen, bindet Ein-/Ausgabe-Buffer (use) und reicht diese asynchron in die zuständige Queue ein.
3. Dispatching & Ausführung (executed on): Die Runtime entnimmt TaskHandler aus der Queue und disponiert sie zur Ausführung auf dem zugeordneten Device.
4. Datenzugriff & Kernel-Execution: Das Device führt den Kernel auf der Hardware (CPU bzw. Accelerator) aus und greift direkt oder via DMA/Memory Controller auf den entsprechenden physischen Memory zu.
5. Synchronisation & Completion: Nach Abarbeitung des TaskHandler erfolgt die Benachrichtigung der Applikation über nicht-blockierende Benachrichtigungsprimitive (z. B. ara::core::Future, Completion-Callbacks oder Event-Synchronisation).

4. Normative Relevanz & Entwickler-Hinweise

• Einheitliches Programmiermodell (Hardware-Agnostik): Identische API-Verträge ermöglichen es Applikationsentwicklern, Algorithmen transparent zwischen Host-CPU (z. B. Referenz-/Fallback-Implementierung) und spezialisierten Hardware-Beschleunigern zu portieren, ohne die Anwendungslogik zu refaktorisieren.
• Zero-Copy & Memory-Placement-Strategien: Entwickler müssen die physikalische Speicherallokation (Buffer) explizit passend zum Ziel-Device wählen. Fehlallokationen führen zu impliziten, latenzintensiven Host-to-Device/Device-to-Host-Kopiervorgängen über PCIe/System-Busse.
• Safety-Isolation & ASIL-Dekomposition: Das API-Design trennt den ungesicherten hardwarenahen Vendor-Treiberstack (z. B. GPU-Compute-Runtimes) von der Adaptive Core Platform. Fehlfunktionen eines Beschleuniger-Tasks (z. B. Timeouts, Memory Overflows) müssen auf API-Ebene durch IOMMU-Kapselung, Watchdogs und deterministische Task-Abbruch-Mechanismen isoliert werden, um Rückwirkungsfreiheit (Freedom from Interference) auf die Host-CPU zu gewährleisten.