Figure 5.1: Parallel processing consumer-provider layered view example

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Abstraktes Architektur-Schichtenmodell (Layered Architectural Pattern) mit vertikalem Konsumenten-Produzenten-Beziehungsvektor (Consumer-Provider Hierarchy).
• Technischer Zweck & funktionale Einordnung:
  • Exemplarische Darstellung der Entkopplung von High-Level-Fahrassistenzfunktionen (ADAS) gegenüber heterogenen Hardware-Beschleunigern innerhalb der AUTOSAR Adaptive Platform (AP).
  • Systematisierung der Integration hochgradig paralleler Rechenoperationen (z. B. Deep Learning, Computer Vision) in eine serviceorientierte Architektur (SOA) gemäß AUTOSAR_AP_EXP_ParallelProcessingGuidelines.
  • Etablierung einer horizontalen Kapselung: Applikationen greifen nicht direkt auf proprietäre Beschleuniger zu, sondern konsumieren standardisierte funktionale Services, welche wiederum hardwareabstrahierende Bibliotheks- und Laufzeit-APIs ansteuern.

2. Komponenten, Entitäten & Schnittstellen

• Architektur-Ebenen & Entitäten (von Consumer zu Provider):
  1. AA layer (Adaptive Application Layer):
     • Entitäten: ADAS AA1, ADAS AA2, ... (Instanzen von AdaptiveApplication im User Space / POSIX-Prozesse).
     • Rolle: Reiner Service-Konsument (Consumer). Enthält fahrfunktionale Logik (z. B. Pfadplanung, Trajektorienberechnung).
  2. Service layer:
     • Entitäten: Object Detection service, Lane Detection service, Other Detection service, ... (Adaptive Service Instances).
     • Rolle: Hybride Entität (Provider gegenüber der AA-Ebene via ara::com; Consumer gegenüber der darunterliegenden Bibliotheksebene).
     • Schnittstelle zur AA-Ebene: Typisierte Service-Interfaces (ara::com Skeleton/Proxy via IPC oder Netzwerk/SOME/IP).
  3. Parallel processing library/language layer:
     • Entitäten: Standardisierte und herstellerspezifische Beschleunigungs- und Parallelisierungs-APIs:
       • OpenCL (Open Computing Language – heterogene Datenparallelität).
       • OpenVX (Standard für hardwarebeschleunigte Computer-Vision-Graphen).
       • Multi-threading (C++ std::thread, POSIX Pthreads, Task-Scheduling).
       • ... (z. B. SYCL, Vulkan Compute, proprietäre Inferenz-Engines/BLAS).
     • Rolle: Abstraktion hardwarenaher Ausführungsparadigmen und Bereitstellung von Compute-Kernel-Laufzeitumgebungen.
  4. Hardware / Execution Platform Layer (Hardware-Basis):
     • Entitäten: Heterogene Recheneinheiten:
       • GPGPU (General-Purpose Graphics Processing Unit)
       • FPGA (Field-Programmable Gate Array)
       • Manycore (Massiv-parallele Prozessoren mit Mesh-Topologie)
       • DFP (Data Flow Processor)
       • Multicore (Klassische symmetrische/asymmetrische CPU-Kerne)
       • Others (z. B. dedizierte NPU, DSP)
     • Rolle: Primärer Rechenressourcen-Provider.
• Beziehungen & Kardinalitäten:
  • Vertikaler Beziehungsvektor (Consumer ↔ Provider): Jede Schicht fungiert als Service-/Ressourcen-Provider für die darüberliegende Ebene und als Konsument für die darunterliegende.
  • N:M-Beziehungen: Eine ADAS AA kann mehrere Detection Services bündeln; ein Detection Service kann dynamisch oder statisch auf mehrere Parallelisierungs-Frameworks zugreifen (z. B. Vision-Vorbereitung via OpenVX auf DSP/GPU, Inferenz via DFP/GPGPU).

3. Dynamisches Verhalten & Sequenzablauf

Da es sich um ein statisches Schichtenmodell handelt, wird der dynamische Kontroll- und Datenfluss vertikal durch die Schichten abgebildet:

1. Service Discovery & Bindung:
   • ADAS AA instanziiert einen ara::com-Proxy und führt FindService für die benötigten Schnittstellen (Object Detection, Lane Detection) aus.
2. Synchroner / Asynchroner Request-Pfad:
   • ADAS AA triggert Bildverarbeitungs- bzw. Erkennungsanfragen via Methodenaufruf (ara::core::Future) oder konsumiert zyklische Event-Streams (z. B. Sensor-Rohdaten/Feature-Maps via Shared-Memory-IPC / Zero-Copy Mechanismen).
3. Execution Offloading:
   • Der Service delegiert die rechenintensive Last an die Parallel processing library/language layer.
   • Graphenaufbau bzw. Kernel-Dispatch (OpenCL clEnqueueNDRangeKernel, OpenVX vxProcessGraph oder Worker-Thread-Pool).
4. Hardware-Verarbeitung & Synchronisation:
   • Asynchrone Abarbeitung auf GPGPU, FPGA oder Manycore.
   • Benachrichtigung per Hardware-Interrupt / DMA-Completion an den POSIX-Host-Treiber.
   • Rückmeldung der Ergebnisse über die Bibliotheks-API an den Detection Service.
5. Ergebnisbereitstellung:
   • Der Service publiziert die segmentierten Objekte/Spurinformationen als ara::com-Event oder via Future-Auflösung zurück an die ADAS AA.

4. Normative Relevanz & Entwickler-Hinweise

• Architektur- & Entwurfsvorgaben:
  • Strikte Entkopplung: Applikationen (ADAS AA) dürfen keine direkten Treiber-/Bibliotheksaufrufe (z. B. clCreateContext, direkte CUDA/OpenCL-Includes) enthalten. Jeglicher Hardware-Beschleuniger-Zugriff muss in dedizierten Services (Service Layer) gekapselt sein, um Portabilität und Austauschbarkeit von Beschleuniger-Hardware (GPU vs. FPGA/DFP) zu gewährleisten.
  • Zero-Copy & Latenzoptimierung: Große Datenmengen (z. B. 4K-Kamerabilder, LiDAR-Punktwolken) verbieten Serialisierung über Standard-IPC. Für die Interaktion zwischen AA, Service und Beschleuniger-Bibliotheken sind Null-Kopier-Verfahren (ara::com Shared Memory / POSIX shm_open, herstellerspezifische UVM/Unified Virtual Memory-Mechanismen) zwingend erforderlich.
• Safety & Determinismus (ASIL):
  • Viele parallele Schnittstellen (OpenCL, dynamic Multi-threading) sind per se nicht echtzeitfähig oder ISO-26262-konform zertifiziert.
  • Entwickler müssen sicherstellen, dass die verwendeten Bibliotheken safe Subsets implementieren (z. B. MISRA-konforme C++-Wrapper, statisch alloziierte Memory-Pools, bounded execution time für Kernels).
  • Im Fehlerfall (z. B. GPU-Watchdog-Timeout, Kernel-Crash) muss der Service Layer die Fehlerbehandlung kapseln und via ara::phm (Platform Health Management) meldefähig machen, anstatt die konsumierende ADAS AA undefiniert blockieren zu lassen.