Figure 9.86: Device and related interfaces of Safe Hardware Acceleration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides UML-Diagramm (Kombination aus Tabellen-Spezifikation für Native Interfaces und UML-Klassendiagramm/Komponentendiagramm) zur Schnittstellen- und Klassenhierarchie.
• Funktionale Einordnung: AUTOSAR Adaptive Platform (AP), Functional Cluster Safe Hardware Acceleration (Release R25-11, AUTOSAR_AP_EXP_SWArchitecture).
• Technischer Zweck: Bereitstellung einer sicheren, standardisierten Abstraktionsschicht (konzeptionell angelehnt an heterogene Programmiermodelle wie SYCL/OpenCL) für heterogene Recheneinheiten (CPUs, GPUs, dedizierte Hardware-Beschleuniger/NPUs/DSPs). Ermöglicht Adaptive Applications die geräteagnostische Entdeckung, Selektion, Aufgabenübermittlung (Queueing/Scheduling) und Synchronisation (Events).

2. Komponenten, Entitäten & Schnittstellen

Entitäten & funktionale Cluster

• Adaptive Application: Konsument/Client der Schnittstellen («use»-Beziehung).
• Safe Hardware Acceleration («aapFunctionalCluster»): Implementierender AUTOSAR-AP-Kernbaustein, der die nativen Schnittstellen über standardisierte Treiber/Laufzeitumgebungen realisiert (Realization-Pfeile).

Native Schnittstellen & Klassen («aapAPI, aapNativeInterface»)

• Device:
  • Repräsentiert eine physische oder logische Recheneinheit.
  • Operationen: Create(), IsAccelerator(), IsCpu(), IsGpu().
• DeviceMonitor:
  • Bietet Überwachungs- und Diagnosefähigkeiten für die Beschleunigerhardware zur Laufzeit.
  • Operationen: Create(), Status().
• DeviceSelector:
  • Basis-Klassifikator/Funktor zur Filterung und Zuweisung geeigneter Ausführungsgeräte.
  • Operationen: operator()(): void, SelectDevice().
  • Spezialisierungen (Generalisierung/Vererbung):
    • CpuSelector: Selektion von Host-/Ziel-CPUs.
    • GpuSelector: Selektion von Grafikprozessoren (z. B. für parallele Shader/Compute-Pipelines).
    • AcceleratorSelector: Selektion generischer Beschleuniger (z. B. NPU, FPGA, DSP).

Tabellarisch spezifizierte Native Interfaces

• Platform:
  • Root-Einstiegspunkt zur Systemtopologie-Abfrage.
  • Operationen: GetPlatforms(), GetDevices().
• Queue:
  • Befehls- und Arbeitswarteschlange für die Offloading-Pipeline.
  • Operationen: Create(), GetDevice(), IsInOrder(), Submit(), Wait().
• Event:
  • Synchronisations- und Abhängigkeitsknoten innerhalb des Ausführungsgraphen (Task DAG).
  • Operationen: Create(), GetWaitList(), Wait() (Überladung: synchrones Warten auf Einzel-Event oder Event-Listen).

3. Dynamisches Verhalten & Sequenzablauf

1. Hardware-Discovery & Selektion:
   • Die Applikation fragt über Platform::GetPlatforms() / Platform::GetDevices() verfügbare Hardware ab oder instanziiert einen spezifischen Selektor (GpuSelector, CpuSelector, AcceleratorSelector).
   • Aufruf von DeviceSelector::SelectDevice() liefert eine kompatible Device-Instanz zurück.
2. Instanziierung & Assoziation:
   • Erzeugung einer Ausführungswarteschlange via Queue::Create(), gebunden an das ausgewählte Device (Queue::GetDevice()).
   • Prüfung der Ausführungssemantik mittels Queue::IsInOrder() (In-Order vs. Out-of-Order Execution).
3. Task-Dispatching (Asynchroner Pfad):
   • Kernel-/Compute-Payloads werden via Queue::Submit() zur asynchronen Ausführung auf dem Beschleuniger eingereiht.
   • Steuerung von Datenabhängigkeiten erfolgt über Event-Instanzen (Abhängigkeitsgraph via Event::GetWaitList()).
4. Synchronisation & Monitoring (Synchroner Pfad):
   • Blockierendes Warten auf Arbeitsabschluss wahlweise über Warteschlangen-Ebene (Queue::Wait()) oder feingranular auf Task-/Event-Ebene (Event::Wait()).
   • Parallele Überwachung des Hardwarezustands und möglicher Hardware-Fehler über DeviceMonitor::Status().

4. Normative Relevanz & Entwickler-Hinweise

• Entkopplung durch Selektoren: Applikationen dürfen Recheneinheiten nicht fest eincodieren. Über polymorphe Selektoren (DeviceSelector-Ableitungen) muss ein Fallback-Pfad (z. B. von GpuSelector auf CpuSelector) ermöglicht werden, falls Zielhardware nicht verfügbar ist oder Fehler meldet.
• Safety & ASIL-Dekomposition: Das Interface DeviceMonitor ist sicherheitskritisch: Beschleuniger-Hardware (oft Non-AUTOSAR oder ASIL-B QM-Mischbetrieb) erfordert periodische Statusabfragen via Status(), um Hardware-Hangs, Speicherüberläufe oder ECC-Fehler im Safety-Kontext der Adaptive Platform abzufangen.
• Synchronisationsaufwand: Queue::Wait() blockiert den aufrufenden Thread vollständig. In harten Echtzeitszenarien sind Event-basierte Abhängigkeiten (Event-Graph) dem blockierenden Polling vorzuziehen, um Scheduling-Jitter im Execution Management (EM) zu minimieren.
• In-Order vs. Out-of-Order: Entwickler müssen vor Submit() verifizieren (IsInOrder()), ob die Ziel-Queue implizite sequentielle Ausführung garantiert oder explizite Event-Barrieren erfordert, um Race Conditions im Device-Memory zu verhindern.