Figure 4.1: General approach

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Konzeptionelles Architektur- und Komponentendiagramm / Schichtenmodell zur Schnittstellenabstraktion (angelehnt an UML-Komponenten- und Schnittstellen-Notation).
• Technischer Zweck & Einordnung: Das Diagramm aus dem Konzeptdokument AUTOSAR_AP_EXP_SafeAPIHardwareAccelerators (Kapitel 4, General approach) spezifiziert die Abstraktions- und Kapselungsstrategie für Hardware-Beschleuniger (Hardware Accelerators – HWA, z. B. GPUs, NPUs, FPGAs) innerhalb der AUTOSAR Adaptive Platform (AP).
• Zielarchitektur: Kapselung proprietärer Beschleuniger-Hardware und heterogener Rechenlaufzeiten hinter einer standardisierten, funktional sicheren Programmierschnittstelle (Safe HWA API), basierend auf dem Industriestandard Khronos SYCL 2020 und gekoppelt an hardwarenahe Überwachungsbibliotheken.

2. Komponenten, Entitäten & Schnittstellen

Normative Ebene & Applikation

• AUTOSAR Specification: Normative Vorgabeebene; definiert die Semantik und Signatur der Safe HWA API.
• AUTOSAR Adaptive application: POSIX-basierter Anwendungsprozess im Userspace. Besitzt eine unidirektionale Konsumenten-Beziehung (uses) zur Safe HWA API. Besitzt keinen direkten Zugriff auf Low-Level-Treiber oder SYCL-Runtimes.

AUTOSAR Adaptive Platform Vendor Implementation (Kapselungsbereich)

• Safe HWA API (Stereotyp/Rolle: Interface): Formale AUTOSAR-Schnittstelle zur Bereitstellung deterministischer, sicherheitsgerichteter Beschleuniger-Dienste für Applikationen.
• AUTOSAR Adaptive Vendor implementation (Stereotyp/Rolle: Subsystem / Execution Runtime): Hersteller- und plattformspezifischer Stack.
  • Realisiert (implements) die Safe HWA API.
  • Konsumiert (uses) die darunterliegende SYCL 2020 Standard API.
  • Konsumiert (uses) dedizierte Hardware monitoring tools and libraries.

Fremd-, Standard- und Treiberbibliotheken (Libraries)

• Khronos Group SYCL 2020 Standard API (Interface): Offener Standard für heterogene C++-Parallelprogrammierung (Single-Source C++ für Host und Accelerator).
• SYCL-Implementierungen (implements SYCL 2020 Standard API):
  • oneAPI DPC++ (Intel-Implementierung)
  • ComputeCPP (Codeplay-Implementierung)
  • hipSYCL (AdaptiveCpp / Universität Heidelberg)
• Hardware monitoring tools and libraries (Entitätenpool / Multiplizität: stacked): Hardwarenahe Bibliotheken zur Laufzeitüberwachung (z. B. Sensorabfragen, Hardware-Watchdogs, ECC-Fehlerregister, Temperatur- und Spannungsmonitore).

3. Dynamisches Verhalten & Sequenzablauf

Das Diagramm bildet primär die statische Abhängigkeitsstruktur ab. Aus der Architektur leitet sich folgender Laufzeitablauf ab:

1. Initialisierung & Device-Discovery:
   • Die AUTOSAR Adaptive application instanziiert Beschleuniger-Kontexte über die Safe HWA API.
   • Die AUTOSAR Adaptive Vendor implementation initialisiert den SYCL-Kontext (Queues, Devices) über das konfigurierte SYCL-Backend und bindet die Hardware monitoring tools and libraries an.
2. Workload Dispatch (Asynchron / Event-basiert):
   • Applikation reicht Compute-Tasks/Graphen über die Safe HWA API ein.
   • Die Vendor Implementation überführt diese in SYCL-Befehlsgruppen (Command Groups, Buffers/Accessors, Kernels) und dispatchet sie an die Beschleuniger-Queue.
3. Parallele Überwachung (Supervision Loop):
   • Synchron oder asynchron erfassen die Hardware monitoring tools and libraries Diagnosedaten der physischen Hardware (Ausführungszeiten, Hardware-Faults, thermische Limits).
4. Fehlerbehandlung & Safety-Reaktion:
   • Hardware-Fehler oder Überschreitungen von Zeitschranken (Execution Timeouts) werden durch die Vendor Implementation abgefangen, isoliert und an die Sicherheitsinfrastruktur der Adaptive Platform gemeldet (z. B. Platform Health Management – PHM).

4. Normative Relevanz & Entwickler-Hinweise

• Applikationsentwickler (ARA-Ebene):
  • Striktes Abstraktionsgebot: Kein direkter Aufruf nativer Frameworks (CUDA, OpenCL, Vulkan Compute, natives SYCL).
  • Portabilität: Code gegen die Safe HWA API bleibt portabel über verschiedene Tier-1-Stacks und Hardwareplattformen (x86_64, ARM64) hinweg.
• Stack- & Plattform-Integratoren (Vendor Implementation):
  • Safety-Hülle (Safety Wrapper): Standard-SYCL ist von Haus aus nicht nach ISO 26262 (ASIL) zertifiziert. Die Vendor Implementation muss das Fault-Handling (Memory Separation, deterministische Queue-Allokation, Exception-Handling bei asynchronen SYCL-Fehlern) kapseln und qualifizieren.
  • Monitoring-Kopplung: Hardware-Monitore müssen deterministisch in die Fehlererkennungskette (Safety Loop) eingebunden werden, um Common-Cause- und Random-Hardware-Failures im Beschleuniger rechtzeitig zu detektieren.
• Backend-Auswahl:
  • Die Austauschbarkeit der Backends (DPC++, ComputeCPP, hipSYCL) erfolgt zur Build-/Integrationszeit; der API-Vertrag der Safe HWA API bleibt davon unberührt.