Figure 5.3: CPU/co-processor-model example

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schichten- und Allokationsdiagramm / Software-Architektur- und Ausführungsmodell (konzeptionelles Komponentenmodell für parallele Datenverarbeitung gemäß AUTOSAR AP Legendendefinition).
• Technischer Zweck: Darstellung des CPU/Co-Processor-Architekturmusters (Offloading-Modell) gemäß AUTOSAR_AP_EXP_ParallelProcessingGuidelines (Kapitel 5).
• Funktionale Einordnung: Entkopplung rechenintensiver ADAS/AD-Algorithmen (z. B. Deep Learning, Objekterkennung) von konsumierenden Applikationen. Heterogene Beschleuniger-Hardware (GPU, NPU, DSP, FPGA) wird über gekapselte Server-Prozesse und standardisierte AUTOSAR-Dienstschnittstellen (ara::com) abstrahiert, anstatt anwendungsspezifischen Treibercode direkt in die Funktions-Applikation einzubetten.

2. Komponenten, Entitäten & Schnittstellen

• Akteure & Ausführungseinheiten (OS- & Thread-Ebene):
  • ADAS AA1: Adaptive Application (Client-Prozess im POSIX-Adressraum), ausgeführt in einem dedizierten Thread.
  • Object Detection server (Stereotyp/Rolle: Service): Server-Prozess (POSIX-Adressraum), agiert als Service Provider und kapselt einen Thread-Pool (dargestellt als vier überlappende Thread-Instanzen) zur parallelen Auftragsabarbeitung.
  • CPUs/co-processors: Heterogene Ausführungseinheiten auf Hardwareebene (Host-CPUs sowie Beschleuniger wie GPUs, NPUs, FPGAs oder Vision-DSPs).
• Bibliotheken & Frameworks:
  • Threading framework/library: Laufzeitumgebung/Engine zur Thread- und Beschleuniger-Steuerung (z. B. OpenMP, Intel TBB, SYCL, OpenCL, CUDA Runtime oder proprietäre Hardware-Abstraktions-Frameworks).
• Schnittstellen (Schichtengrenzen):
  • C++ generated service I/F: Typsichere AUTOSAR-Adaptive-Dienstschnittstelle (ara::com Proxy/Skeleton), generiert aus dem ARXML-Servicemodell (Methoden, Events, Fields via IPC/Shared Memory).
  • Threading library I/F: Standardisierte oder proprietäre Programmierschnittstelle zwischen Anwendungslogik des Servers und Threading-Framework (z. B. C++ Standard Threading, Task-Scheduler-APIs).
  • HW specific hardware-software I/F: Hardwarenahe Schnittstelle (Kernel-Treiber, MMIO, DMA-Controller, PCIe-Bus, Register-Ebene).
• Beziehungen & Kardinalitäten:
  • Client-zu-Server: 1:1 oder N:1 lose Kopplung über prozessübergreifende ara::com-Service-Kommunikation.
  • Server-zu-Worker-Threads: 1:N Allokation (Task-Parallelismus bzw. Thread-Pool).
  • Framework-zu-Hardware: Abstraktion der M:N-Abbildung von Software-Tasks auf physische Co-Prozessor-Rechenkerne/-Pipelines.

3. Dynamisches Verhalten & Sequenzablauf

1. Trigger & Request: ADAS AA1 initiiert eine Berechnungsanforderung (z. B. Inferenzauftrag für Kamerabild) über das C++ generated service I/F. Typischerweise erfolgt dies asynchron via ara::core::Future / ara::core::Promise oder über Event-Streaming.
2. Dispatching & Queueing: Der Object Detection server nimmt den Request entgegen. Ein interner Dispatcher-Thread übergibt die Eingangsdaten an freie Worker-Threads aus dem Thread-Pool.
3. Offloading & Execution:
   • Die Worker-Threads rufen über das Threading library I/F das Framework auf.
   • Das Framework konfiguriert Kernel/Pipelines und stößt DMA-Transfers des Payloads über das HW specific hardware-software I/F in den Speicher des Co-Prozessors an.
   • Der Co-Prozessor führt Matrix- oder Bildverarbeitungsoperationen parallel zur CPU aus.
4. Synchronisation & Notification:
   • HW-Interrupts (z. B. DMA-Completion) signalisieren die Beendigung an den Treiber/das Framework.
   • Der zugeordnete Worker-Thread holt die Ergebnisse (z. B. Bounding Boxes, Objektvektoren) ab und formatiert die Servicerückgabe.
5. Response & Fehlerpfade:
   • Ergebnisbereitstellung an ADAS AA1 über ara::com (Auflösung des Future oder Event-Notification).
   • Bei Timeouts, Hardware-Faults oder Ressourcenerschöpfung Rückmeldung via ara::core::ErrorCode; Überwachung ggf. angebunden an das Platform Health Management (PHM).

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler (ADAS AA1):
  • Vollständige Entkopplung von herstellerspezifischen Co-Prozessor-APIs und SDKs. Applikationscode bleibt portabel, da ausschließlich gegen das generierte ara::com-Interface programmiert wird.
  • Asynchrone Aufrufmuster sind zwingend erforderlich, um Blockaden des Haupt-Threads während rechenintensiver Beschleunigeroperationen zu vermeiden.
• Server-Entwickler (Object Detection server):
  • Verantwortlich für das Lifecycle- und Thread-Management (Vermeidung von Race Conditions, Deadlocks und Priority Inversion).
  • Optimierung des Datentransfers: Bei großen Datenmengen (z. B. unkomprimierte Sensordaten/Point Clouds) ist zero-copy-fähiger Shared-Memory-Datenaustausch auf ara::com-Ebene sowie synchronisierter UVM- (Unified Virtual Memory) oder DMA-Transfer zum Co-Prozessor erforderlich.
• Plattform- & Integrations-Entwickler:
  • OS-Konfiguration: Exakte Definition von CPU-Affinitäten (Core Pinning) und Echtzeit-Scheduling-Klassen (z. B. SCHED_FIFO/SCHED_RR) für Server-Threads zur Einhaltung von WCET-Schranken.
  • Status des Dokuments: Als EXP (Explanation) enthält die Leitlinie keine normativen [SWS_...]-Anforderungen, definiert jedoch das maßgebliche Best-Practice-Muster für Beschleuniger-Integration in der AUTOSAR Adaptive Platform.