Figure 10.16: Use cases for Safe Hardware Acceleration

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: UML-Anwendungsfalldiagramm (Use Case Diagram) gemäß AUTOSAR-Modellierungsrichtlinien für funktionale Cluster der Adaptive Platform (AP).
• Technischer Zweck: Definition der primären Nutzungsszenarien für das funktionale Cluster Safe Hardware Acceleration innerhalb der AUTOSAR Adaptive Platform. Es kapselt den hardwarebeschleunigten Offloading-Bedarf von rechenintensiven Workloads (z. B. Computer Vision, Deep Learning/Inferenz, Signalverarbeitung) unter Erfüllung funktionaler Sicherheitsanforderungen (ISO 26262) gegenüber der Hardware (GPU, NPU, DSP, FPGA, Vector-Units).

2. Komponenten, Entitäten & Schnittstellen

• Akteur:
  • Adaptive Application: Repräsentiert den Nutzerprozess im POSIX-User-Space (Application Layer), welcher rechenintensive Operationen an spezialisierte Recheneinheiten delegiert.
• Systemgrenzen (Boundaries):
  • Adaptive Platform: Übergeordnete Systemgrenze der AUTOSAR Adaptive Runtime Environment.
  • Safe Hardware Acceleration: Untergeordnete funktionale Cluster-Grenze, welche die Schnittstellen und Mechanismen zur sicheren Ansteuerung heterogener Beschleunigerhardware kapselt.
• Anwendungsfälle (Stereotyp «aapUseCase»):
  • Process Multiple Instructions on Multiple Data (MIMD): Ausführung asynchroner, heterogener Instruktionsströme auf voneinander unabhängigen Datenmengen (z. B. Multi-Core-Beschleuniger, FPGA-Pipelines, parallele Kernel-Graphen).
  • Process Single Instructions on Multiple Data (SIMD): Parallele Ausführung identischer Berechnungsbefehle auf homogenen Vektoren/Matrizen (z. B. Vektorerweiterungen, Tensor-/Matrix-Units, GPU-Warp-/SIMT-Architekturen).
• Beziehungen (Stereotyp «aapTriggers»):
  • Gerichtete Assoziation von Adaptive Application zu beiden Use Cases. Definiert den Kontrollflussinitiator: Die Applikation triggert das Einreihen und die Ausführung von Rechenaufgaben im jeweiligen Beschleuniger-Modus.

3. Dynamisches Verhalten & Sequenzablauf

1. Initialisierung & Ressourcenzuweisung: Die Adaptive Application fordert über standardisierte Cluster-APIs Beschleunigerkontexte, Execution Streams oder Compute-Pipelines an (inklusive IOMMU/SMMU-Pufferallokation für Zero-Copy-Datenzugriff).
2. Task-Trigger («aapTriggers»):
   • SIMD-Pfad: Übergabe kompakter Vektordatenstrukturen und Bindung an SIMD-Rechenkerne. Typischerweise synchrone oder eng gekoppelte asynchrone Vektoroperationen mit deterministischer Ausführungszeit.
   • MIMD-Pfad: Übermittlung komplexer Task-Graphen / Command-Buffer mit separaten Kerneln auf unterschiedlichen Hardware-Engines.
3. Asynchrone Abarbeitung & Synchronisation:
   • Nicht-blockierender Dispatch der Berechnungen an die Hardware-Warteschlange.
   • Benachrichtigung der Applikation über Synchronisationsprimitive (Fences, Futures, Callbacks/Poll-Mechanismen).
4. Fehlerbehandlung & Safety-Überwachung:
   • Hardware-Watchdogs, ECC-Prüfungen, Paritätsfehler oder Timeout-Events führen zum Abbruch der Beschleuniger-Queue und lösen plattformseitige Diagnostics-/Recovery-Routinen aus.

4. Normative Relevanz & Entwickler-Hinweise

• Applikations-Entwickler:
  • Abstraktion der Zielhardware: Applikationen interagieren gegen funktionale Beschleunigerschnittstellen (z. B. standardisierte Compute-APIs oder High-Level-Frameworks wie OpenVX/SYCL/Vulkan-Abstraktionen), ohne direkte Registerzugriffe oder ungesicherte Direct-I/O-Treiber zu verwenden.
  • Puffer-Management: Zwingende Einhaltung von Cache-Kohärenz-Vorgaben und Speicheralignments (Contiguous Memory, DMA-taugliche Puffer).
• Treiber- & Stack-Entwickler (Platform Provider):
  • Safety Isolation: Implementierung zwingender Hardware-Schutzmechanismen (IOMMU/SMMU-Mapping, Memory Protection Units) zur Verhinderung von Freedom from Interference (FFI)-Verletzungen zwischen ASIL- und QM-Workloads.
  • Deterministisches Scheduling: Gewährleistung von Worst-Case Execution Time (WCET)-Garantien sowie Preemption- und Time-Slicing-Fähigkeiten auf geteilten Beschleunigern (insbesondere bei MIMD-Szenarien).
  • ASIL-Dekomposition: Absicherung der Beschleuniger-Treiber und Middleware gemäß gefordertem ASIL-Level, einschließlich redundanter Lockstep-Prüfung oder plausibilitätsbasierter Ergebniskontrolle.