Figure 7.1: High Level Design of Safe Hardware Acceleration in an Adaptive Platform

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Architekturelles Schichten- und Blockdiagramm (High-Level Design / Layered Component Model) gemäß AUTOSAR Adaptive Platform (AP).
• Technischer Zweck: Darstellung der Integration des Functional Clusters Safe Hardware Acceleration (ara::shwa) in die Schichtenarchitektur der AUTOSAR Adaptive Platform zur sicheren, parallelen Auslagerung von Rechenoperationen auf dedizierte Hardware-Beschleuniger (GPU, NPU, DSP, FPGA).
• Funktionale Einordnung: Entkopplung der Applikationslogik von plattform- und herstellerspezifischen Beschleunigertreibern über standardisierte ara::shwa-APIs bei gleichzeitiger Verknüpfung mit sicherheitsrelevanten Plattformdiensten zur Laufzeitüberwachung.

2. Komponenten, Entitäten & Schnittstellen

• Application Layer:
  • Adaptive application: Anwender- oder Middleware-Prozess, der hardwarebeschleunigte Berechnungen anfordert und parallel ausführt.
• Adaptive Platform (Middleware / Functional Clusters):
  • ara::shwa (Standardisiertes Interface): Formale C++-API des Functional Clusters für Queue-, Buffer- und Device-Management.
  • ara::shwa implementation (Cluster-Backend): Plattform- und architecturespezifische Implementierung des SHWA-Stacks; realisiert das ara::shwa-Interface (gekennzeichnet durch Generalisierungs-/Realisierungspfeil auf ara::shwa).
  • ara::phm (Platform Health Management): Überwachung von Lebendigkeit, Kontrollfluss und Ausführungsfristen (Alive/Deadline/Logical Supervision) der ausgelagerten Tasks.
  • ara::sm (State Management): Steuerung von System- und Funktionszuständen (z. B. Aktivierung/Deaktivierung bestimmter Beschleunigerpfade in Degradationsmodi).
  • ara::exec (Execution Management): Prozesslebenszyklus, Ressourcenzuordnung und Determinismus.
  • ...: Repräsentiert weitere funktionale Cluster (z. B. ara::core, ara::com, ara::log).
• Unterlagerte System- & Hardware-Ebene:
  • OS (POSIX) & Hardware: Standard-Host-Betriebssystem-Kernel (POSIX-Schnittstelle) und Host-CPU-Plattform.
  • Driver & Hardware Accelerator: Proprietäre Kernel-/Userspace-Treiber sowie die physische Beschleunigungshardware (z. B. PCIe/SoC-integrierte AI-Engines, Graphikeinheiten).
• Schnittstellen & Kopplungen:
  • Bidirektionaler Pfeil Adaptive application ↔ ara::shwa: API-Aufrufe (Enqueue, Synchronisation) und Event-/Status-Rückmeldungen.
  • Bidirektionaler Pfeil Adaptive application ↔ [ara::phm, ara::sm, ara::exec]: Melden von Checkpoints an PHM, Zustandsabfragen an SM, Lifecycle-Bindung an Execution Management.
  • Gerichteter Realisierungspfeil ara::shwa implementation → ara::shwa: Das herstellerspezifische Backend implementiert die Spezifikationsvorgaben der standardisierten Schnittstelle.
  • Bidirektionaler Pfeil ara::shwa implementation ↔ Driver: Interaktion der Laufzeitumgebung mit dem Gerätetreiber (Memory-Mapped I/O, DMA-Transfer-Setup, Interrupt-/Event-Handling, Queue-Submission).

3. Dynamisches Verhalten & Sequenzablauf

• Initialisierung & Device-Discovery:
  • Start der Applikation über ara::exec.
  • Initialisierung des ara::shwa-Kontexts; Enumeration verfügbarer Beschleuniger-Devices und Zuordnung der Treiber-Endpoints via ara::shwa implementation.
• Task-Submission & Puffer-Handling:
  • Allokation/Binding von Eingangs- und Ausgangs-Buffern über ara::shwa.
  • Asynchrones Einreihen (Enqueue) von Rechenbefehlen/Kerneln in Task-Queues.
  • Das Backend delegiert die Jobs an den herstellerspezifischen Driver, welcher den DMA-Transfer initiiert und die Beschleunigerkerne triggert.
• Sicherheitsüberwachung & Synchronisation (PHM-Interaktion):
  • Vor/während/nach der Beschleunigung meldet die Applikation (oder Middleware) Checkpoints an ara::phm.
  • Tritt ein Timeout, Deadlock oder Treiberfehler im Beschleuniger auf, detektiert ara::phm die Fristverletzung und initiiert via ara::sm Wiederherstellungs- oder Notlauf-Mechanismen (Fail-Safe/Fail-Operational).
• Rückführung & Completion:
  • Benachrichtigung der Applikation über Task-Beendigung (z. B. via asynchrone Callbacks, Futures oder Polling) und Validierung der Ergebnisdaten.

4. Normative Relevanz & Entwickler-Hinweise

• Für Applikations-Entwickler:
  • Direkte Zugriffe auf Hardwarebeschleuniger-Treiber (z. B. rohe ioctl-, CUDA- oder OpenCL-Syscalls) verletzen das Schichtenmodell. Interaktionen müssen strikt über die standardisierte ara::shwa-API abgewickelt werden, um Portabilität zwischen SoCs zu wahren.
  • Funktionale Sicherheit (ASIL): Die Nutzung von Beschleunigern ist erst in Kombination mit ara::phm normkonform. Deadlines und Execution-Budgets hardwarebeschleunigter Aufgaben müssen explizit überwacht werden.
• Für Plattform- & Treiber-Entwickler (BSP/Stack):
  • Das ara::shwa implementation-Modul muss Hardwarefehler, Memory-Protection-Verletzungen (IOMMU/SMMU) und Treiber-Timeouts abfangen und deterministisch als standardisierte ara::core::Result-Fehlercodes nach oben propagieren.
  • Zero-Copy-Memory-Sharing zwischen Host-POSIX-RAM und Beschleuniger-Speicherbereichen muss durch die Treiberanbindung des Backends sichergestellt werden, ohne die Speichertrennung anderer Applikationen zu kompromittieren.