Figure 9.87: Common interfaces of Safe Hardware Acceleration (1)

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponenten- und Schnittstellendiagramm (Klassendiagramm auf Architekturebene mit Schnittstellenrealisierung).
• Technischer Zweck: Spezifikation der Basisschnittstellen des Functional Clusters Safe Hardware Acceleration (SHA) innerhalb der AUTOSAR Adaptive Platform (AP).
• Architektur-Kontext: SHA abstrahiert heterogene Rechenbeschleuniger (GPUs, NPUs, DSPs, FPGAs) sicherheitsgerichtet (unter ASIL-Anforderungen, angelehnt an SYCL-/OpenCL-Paradigmen). Es stellt C++-Abstraktionen für Pufferverwaltung, Datenzugriff, Iterationsbereiche und Fehlermeldungen bereit, die von einer Adaptive Application direkt über native Schnittstellen (in-process C++ API) konsumiert werden.

2. Komponenten, Entitäten & Schnittstellen

Komponenten (Akteure):

• Adaptive Application (UML Component): Konsumierender Anwendungsprozess im User-Space der Adaptive Platform.
• «aapFunctionalCluster» Safe Hardware Acceleration (UML Component): Bereitstellender AUTOSAR Functional Cluster, der die Hardwareabstraktion und Laufzeitumgebung für Beschleunigerkerne implementiert.

Schnittstellen / Klassen (Stereotyp «aapAPI, aapNativeInterface»):

• Accessor:
  • Vermittelt den typisierten Lese- und Schreibzugriff auf Gerätespeicher oder geteilte Puffer (Device/Host Access).
  • Operationen: + Create() (statische Factory-Methode), + Get(), + operator[](), + Set().
• Buffer:
  • Kapselt 1D-, 2D- oder 3D-Speicherallokationen für Beschleuniger-Workloads unabhängig vom physischen Speicherort (Host-Memory, Device-VRAM, Shared-Memory).
  • Operationen: + Create() (statische Factory-Methode).
• Range:
  • Definiert den mehrdimensionalen Ausführungsraum bzw. Indexvektor für parallele Compute-Kernel (bis zu 3 Dimensionen).
  • Operationen: + Create() (statische Factory-Methode), + GetDimension0(), + GetDimension1(), + GetDimension2().
• ErrorHandler:
  • Zentraler Fehlerbehandlungsmechanismus zur Abfangung und Weiterleitung asynchroner Hardware-, Scheduling- oder Kernel-Laufzeitfehler.
  • Operationen: + Create() (statische Factory-Methode), + HandleError().

Beziehungen:

• Nutzungsbeziehung («use», Abhängigkeit gestrichelt mit offener Pfeilspitze): Adaptive Application instanziiert und nutzt Accessor, Buffer, Range und ErrorHandler.
• Schnittstellenrealisierung (Interface Realization, gestrichelt mit geschlossener, nicht ausgefüllter Dreiecksspitze): Safe Hardware Acceleration realisiert/implementiert alle vier Schnittstellen.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Setup:
   • Die Adaptive Application erzeugt über statische Create()-Methoden einen Buffer (Allokation von Gerätespeicher) und eine Range zur Festlegung des Iterationsraums (Dimensionen 0 bis 2).
   • Registrierung eines ErrorHandler via Create(), um asynchrone Hardwarefehler zu isolieren.
2. Datenbereitstellung:
   • Instanziierung eines Accessor auf den Buffer mittels Accessor::Create().
   • Synchrone Datenübertragung oder Pufferzuweisung über Set() bzw. operator[]().
3. Kernel-Ausführung & Fehlerbehandlung:
   • Nach Enqueue/Dispatch des Rechenkernels (im Diagramm Folgeinteraktion, Teil 2) greift der Beschleuniger im durch Range definierten Raster auf den Buffer zu.
   • Asynchroner Fehlerpfad: Tritt ein Speicherzugriffsfehler (z. B. Out-of-Bounds, Parity/ECC-Fehler) oder ein Timeout im Beschleuniger auf, invoked der Functional Cluster asynchron ErrorHandler::HandleError().
   • Synchroner Pfad: Bei erfolgreicher Ausführung liest die Applikation die Ergebnisse über Accessor::Get() oder Accessor::operator[]() zurück.

4. Normative Relevanz & Entwickler-Hinweise

• Kein C++-Exception-Modell: Alle Klassen exponieren unterstrichene (statische) Create()-Methoden. Gemäß AUTOSAR AP C++ Sprachprofil (ara::core) signalisiert die Objekterzeugung Erfolg oder Misserfolg typischerweise über ara::core::Result<T> anstelle von C++-Exceptions.
• Speicher- und Zeiger-Sicherheit (ASIL): Ein direkter Zugriff auf Raw-Pointers wird vermieden; der Zugriff auf Beschleunigerspeicher wird strikt über Accessor kanalisiert, um Bounds-Checking und Cache-Synchronisation (Flush/Invalidate) zwischen Host-CPU und Accelerator-Hardware zu garantieren.
• Dimensionierung: Range limitiert Kernel-Workspaces auf maximal 3 Dimensionen (GetDimension0 bis GetDimension2), passend zu Standard-Hardwarebeschleuniger-Topologien (Grid/Block/Work-Group-Modelle).
• Treiber- & Stack-Entwickler: Plattform-Vendors müssen unterhalb von Safe Hardware Acceleration Zero-Copy-fähige Shared-Memory-Treiber (z. B. über IOMMU/SMMU gesichert) bereitstellen, die die Pufferbindung für Accessor deterministisch ohne unkontrollierte Latenzen ausführen.