Figure 17.2: Safe Hardware Acceleration integration to AUTOSAR AP

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Schichtenbasiertes Block- und Architekturdiagramm mit UML-Realisierungs- und Abhängigkeitsbeziehungen.
• Technischer Zweck: Spezifikation des Integrationsmusters für Safe Hardware Acceleration (SHWA) in die AUTOSAR Adaptive Platform (AP) gemäß AUTOSAR_AP_EXP_PlatformDesign (R25-11, Kap. 17).
• Funktionale Einordnung: Standardisierung des Zugriffs von Adaptive Applications auf spezialisierte, sicherheitsrelevante Rechenbeschleuniger (GPUs, NPUs, FPGAs, DSPs) unter Kapselung herstellerspezifischer Treiber bei gleichzeitiger Einbindung in das funktionale Sicherheits- und Überwachungskonzept der Plattform (ISO 26262).

2. Komponenten, Entitäten & Schnittstellen

• Application Layer:
  • Adaptive application (AA): Nutzerprozess im POSIX-User-Space; interagiert parallel mit dem Beschleuniger-Subsystem und den Standard-Plattformdiensten.
• Adaptive Platform Layer:
  • Standard Functional Clusters (Foundation / Core Services):
    • ara::exec (Execution Management): Prozess-Lifecycle, Scheduling und Ressourcenlimitierung.
    • ara::sm (State Management): Zustands- und Funktionsgruppensteuerung.
    • ara::phm (Platform Health Management): Überwachung von Alive-, Deadline- und Logical-Supervision-Zyklen.
    • ...: Weitere Basisfunktionen (z. B. ara::core, ara::log).
  • Standardisierte Schnittstelle:
    • ara::shwa: Abstrakter Namensraum/API-Vertrag des Functional Clusters Safe Hardware Acceleration (C++-Schnittstelle zur Definition von Kontexten, Memory-Buffern und Execution-Queues).
  • Plattform-spezifische Realisierung:
    • ara::shwa implementation: Vendor-/Plattform-spezifische Implementierung des SHWA-Clusters.
• Betriebssystem- & Hardware-Layer:
  • Standard-Hostpfad:
    • OS (POSIX): Standardisiertes POSIX-Betriebssystem (PSE51/PSE52) für Host-CPU-Prozesse.
    • Hardware: Host-Rechenknoten (CPU).
  • Beschleunigerpfad:
    • Driver: Kernel-/User-Space-Treiber (z. B. PCIe/DMA/IOMMU-Treiber, Vendor-Compute-Runtime).
    • Hardware Accelerator: Physikalische Beschleuniger-Hardware (GPU, NPU, DSP, FPGA).
• Beziehungen & Semantik:
  • Adaptive application ↔ ara::shwa: Nutzungsbeziehung (Aufruf der standardisierten C++-APIs für Pipeline-Setup und Datenübergabe).
  • Adaptive application ↔ Basis-Cluster (ara::phm, ara::sm, ara::exec): Standard-AP-Interaktion (Health-Reporting, State-Handling, Prozessmanagement).
  • ara::shwa implementation $\triangle$\hspace{-5pt}--- ara::shwa: UML-Realisierung (Interface Implementation); die konkrete Implementierung implementiert den abstrakten Standardvertrag.
  • ara::shwa implementation ↔ Driver: Hardwarenahe Treiberanbindung (Ioctl, Shared-Memory-/DMA-Management, IRQ-Handling) unter Umgehung des generischen POSIX-OS-AP-Pfads für performanten Datendurchsatz.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Setup:
   • ara::exec startet die Adaptive application und instanziiert die ara::shwa implementation.
   • Die Applikation fordert über ara::shwa Beschleuniger-Kontexte und Speicherressourcen an.
   • ara::shwa implementation mappt über den Driver IOMMU-geschützte Zero-Copy- oder Shared-Memory-Bereiche für DMA-Operationen.
2. Job-Submission & Asynchrone Ausführung:
   • Applikation übergibt Compute-Pipelines (z. B. Inferenzgraphen, Bildverarbeitungs-Kernel) an ara::shwa.
   • ara::shwa implementation encodiert Kommandobuffer und übergibt sie an den Driver, welcher den Hardware Accelerator triggert.
   • Rückgabe erfolgt non-blocking über asynchrone Primitive (ara::core::Future/Promise).
3. Safety-Überwachung & Synchronization:
   • Die Applikation meldet regelmäßige Checkpoints an ara::phm.
   • Der Beschleunigertreiber überwacht Hardware-Timeouts, Paritäts-/ECC-Fehler und Hang-Zustände; Ausfälle werden an ara::shwa implementation gemeldet.
   • Bei Überschreiten von Ausführungs-Deadlines oder Hardware-Fehlern greift ara::phm/ara::sm, um den definierten sicheren Zustand (Safe State) anzufordern.

4. Normative Relevanz & Entwickler-Hinweise

• Für Applikations-Entwickler:
  • API-Konformität: Direkte Aufrufe proprietärer Treiber (z. B. /dev/nv*, direct OpenCL/CUDA/Vulkan-Bypass) verletzen die AUTOSAR-Portabilität und Safety-Zertifizierung; Zugriffe müssen zwingend über ara::shwa erfolgen.
  • Fehlerbehandlung: Rückgabetypen sind konsequent als ara::core::Result<T> ausgelegt; Fehlerdomänen des Beschleunigers müssen auf Applikationsebene deterministisch abgefangen werden.
  • Speicher-Management: Explizite Beachtung von Cache-Kohärenz, DMA-Alignments und Zero-Copy-Buffer-Lebenszyklen.
• Für Stack- & Plattform-Integratoren:
  • Realisierungsvertrag: ara::shwa implementation muss deterministisches Queueing bereitstellen und darf keine unkontrollierten POSIX-Blockaden auf dem Host auslösen.
  • Safety-Integration: Bindeglied zwischen Beschleuniger-Health-Events und ara::phm (Deadline- und Alive-Supervision für Offloaded-Workloads).
• Für Treiber- & BSP-Entwickler:
  • Isolation (Freedom from Interference): Hardwareseitige Trennung durch IOMMU/SMMU-Konfiguration sicherstellen, um unautorisierte Speicherzugriffe fehlerhafter Beschleuniger-Workloads auf den Host-Speicher auszuschließen.