Figure 5.2: Accelerator-model example

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Kombiniertes Prozess-, Schichten- und Hardware-Architekturdiagramm (Combined Process and Physical Architectural View) nach AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: AUTOSAR AP (AUTOSAR_AP_EXP_ParallelProcessingGuidelines, Kap. 5.2.2 Accelerator-model).
• Technischer Zweck: Spezifikation des Beschleunigermodells (Offloading-Architektur via OpenCL, CUDA oder OpenVX) zur Entkopplung von rechenintensiver Datenverarbeitung (z. B. Objekterkennung) von der Standard-CPU. Es kapselt hardwarenahe Parallelisierungs-Frameworks hinter standardisierten Service-Schnittstellen (ara::com) und definiert die vertikale Schichtung vom Applikationsprozess bis zu den heterogenen Recheneinheiten (CPUs vs. GPGPU).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & Klassifikation (gemäß Diagrammlegende)

• ADAS AA1 (OS process): Adaptive Application (Client-Prozess im POSIX-User-Space), die funktionale Assistenzfunktionen ausführt und Erkennungsergebnisse konsumiert.
• Object Detection server (OS process): Spezifischer Adaptive Service-Provider-Prozess (Server-Kapselung).
  • Thread (Thread): Ausführungskontext innerhalb des Server-Prozesses zur Verwaltung von Anfragen, Datentransfers und Synchronisation.
  • OpenCL kernels (Framework specific module): GPU-Programmcodes/Rechenkerne; werden vom Server-Prozess gehalten und in die Recheneinheit geladen (loaded).
• OpenCL (Framework/engine): Laufzeitumgebung/User-Space-Bibliothek (OpenCL Runtime Framework) zur Verwaltung von Compute-Contexts, Command Queues und Memory Buffers.
• Accelerator device driver (OS specific module): Betriebssystemspezifischer Treiber; je nach OS-Architektur (Monolithisch vs. Microkernel) als Kernel-Modul oder eigenständiger Treiber-Prozess realisiert.
• GPGPU / CPUs (Hardware): Heterogene Zielhardware: Multi-Core Host-CPUs für Steuerungs- und OS-Aufgaben sowie GPGPU (General-Purpose Graphics Processing Unit) als Beschleuniger.

Schnittstellen (Interfaces) & Beziehungen

• C++ generated service I/F: Service-orientierte Schnittstelle (ara::com Proxy/Skeleton bzw. C++Bindings) zwischen Client ADAS AA1 und Object Detection server. Entkoppelt Applikationslogik vollständig vom Beschleuniger.
• OpenCL library I/F: Standardisierte API (Host-API) zwischen dem Server-Thread und der OpenCL-Framework-Bibliothek.
• OS specific device driver I/F: Systemschnittstelle (z. B. POSIX ioctl, System Calls oder IPC) zwischen OpenCL-User-Space-Runtime und dem Beschleuniger-Treiber.
• HW specific hardware-software I/F: Physische Anbindung (PCIe, Shared Memory, DMA-Controller, MMIO-Register) zwischen Treiber und GPGPU bzw. Host-CPUs.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierungs- & Ladephase:
   • Der Object Detection server initialisiert den OpenCL-Kontext und die Command Queues über die OpenCL library I/F.
   • Die vorkompilierten OpenCL kernels werden geladen (loaded) und über den Treiber auf die GPGPU geflasht/alloziert.
2. Service Request (asynchron/synchron):
   • ADAS AA1 triggert eine Verarbeitungsanforderung über das C++ generated service I/F (ara::com-Methodenaufruf oder Event-Bereitstellung mit Bild-/Sensordaten).
3. Offloading & Execution:
   • Der Server-Thread serialisiert/mapped die Eingangsdaten in Beschleuniger-kompatible Puffer (Device Memory / Shared Virtual Memory).
   • Übergabe der Ausführungsbefehle über die OpenCL library I/F an den Beschleunigertreiber (OS specific device driver I/F).
   • Der Treiber stößt per DMA/Registerzugriff die parallele Kernel-Abarbeitung auf der GPGPU an. Die Host-CPUs werden während der GPU-Kernel-Ausführung entlastet.
4. Synchronisation & Response:
   • Nach Kernel-Beendigung signalisiert die GPGPU (typischerweise via Interrupt) die Fertigstellung an den Accelerator device driver.
   • Die OpenCL-Engine benachrichtigt den Server-Thread (Event-Completion).
   • Der Object Detection server extrahiert die Ergebnisse und liefert sie über das C++ generated service I/F zurück an ADAS AA1.

4. Normative Relevanz & Entwickler-Hinweise

• Kapselung & Safety-Zonierung:
  • Adaptive Applications (ADAS AA1) dürfen keine direkten Abhängigkeiten auf herstellerspezifische Beschleuniger-APIs (OpenCL, CUDA, ROCm) besitzen. Sämtliche Hardware-Beschleunigung ist in dedizierten Server-Prozessen hinter AUTOSAR-Services zu kapseln.
  • Dies ermöglicht unabhängiges Lifecycle-Management (Execution Management) und erleichtert die ASIL-Dekomposition (z. B. QM-Beschleuniger hinter ASIL-B/D-Service-Wrapper).
• Treiber- & OS-Konfiguration:
  • Der Accelerator device driver muss zur Plattform-Strategie passen: Bei Microkernel-Systemen (z. B. QNX Neutrino) läuft der Treiber oft als User-Space Resource Manager, bei Linux (RT-Preempt) als Kernel-Modul. Echtzeit-Prioritäten müssen zwischen Server-Thread und Treiber-Interrupts strikt abgestimmt sein.
• Determinismus & Kernel-Kompilierung:
  • Just-In-Time (JIT) Kompilierung von OpenCL-Kernels zur Laufzeit im Fahrzeug ist unzulässig. Kernels müssen als vorkompilierte Binaries (Offline-Compilation, z. B. SPIR-V oder vendorspezifische Binärformate) vorliegen, um Startzeit- und Laufzeit-Jitter zu eliminieren.
• Speichereffizienz (Zero-Copy):
  • Datentransfers zwischen Server-Prozess, Host-Memory und GPGPU-Memory stellen den Haupt-Flaschenhals dar. Entwickler müssen Shared Memory (IPC) auf ara::com-Ebene und Zero-Copy-Mechanismen (Unified Memory / Shared Virtual Memory SVM) auf OpenCL-Ebene einsetzen, um redundante memcpy-Zyklen zu verhindern.