Figure 7.2: Typical usage of Safe Hardware Acceleration within an Adaptive Application

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Komponentendiagramm / Composite-Structure-Diagramm zur statischen und strukturellen Laufzeit-Gliederung.
• Architektur-Kontext: AUTOSAR Adaptive Platform (Release R25-11), Funktionscluster Safe Hardware Acceleration (AUTOSAR_AP_SWS_SafeHardwareAcceleration).
• Technischer Zweck: Das Diagramm spezifiziert das Kapselungs- und Instanziierungsmodell für hardwarebeschleunigte Berechnungen (z. B. GPU, NPU, DSP, FPGA) innerhalb des OS-Prozesskontexts einer Adaptive Application. Es visualisiert die Koexistenz und Entkopplung mehrerer unabhängiger Beschleunigungs-Pipelines (Instanz-Cluster A und B), bestehend aus Ausführungswarteschlangen, Speicherpuffern und logischen Hardware-Geräten.

2. Komponenten, Entitäten & Schnittstellen

• Adaptive Application (<<process>>):
  • Kapselnde POSIX-Prozessgrenze mit eigenem virtuellem Adressraum und Sicherheitskontext (Freedom from Interference auf OS-Ebene).
• Safe Hardware Acceleration (<<subsystem, entity>>):
  • Laufzeit-Subsystem innerhalb des Applikationsprozesses; fungiert als Abstraktions- und Sicherheitslayer zwischen Applikationslogik und Beschleuniger-Treibern/Hardware.
• Entitäten-Cluster A (Beschleuniger-Kontext A):
  • Queue A (<<entity>>): FIFO-/Abhängigkeits-Warteschlange für Rechenoperationen. Kapselt die konkreten Arbeitspakete:
    • + Task_A1
    • + Task_A2
    • + Task_A3
  • Buffer A1, Buffer A2 (<<entity>>): Speicherentitäten für Input-, Output- oder Zwischenergebnisse (z. B. DMA-fähiger Shared Memory, Host-Mapped Memory oder Device-Local Memory). Zeigt eine 1:n-Kardinalität zwischen Queue/Device und Puffern.
  • Device A (<<entity>>): Logische Repräsentation der ausführenden Hardware-Ressource (z. B. dedizierter Beschleunigerkern oder Compute-Unit).
• Entitäten-Cluster B (Beschleuniger-Kontext B):
  • Queue B (<<entity>>): Unabhängige zweite Warteschlange mit:
    • + Task_B1
    • + Task_B2
  • Buffer B (<<entity>>): Zugeordnete Speicherentität für Cluster B.
  • Device B (<<entity>>): Zweite logische Hardware-Einheit (kann ein physikalisch separates Gerät oder ein isolierter Hardware-Kanal/Virtual Function desselben Beschleunigers sein).
• Beziehungen:
  • Komposition: Das Subsystem aggregiert Queues, Buffer und Devices.
  • Orthogonalität: Die Instanzgruppen A und B sind logisch vollständig voneinander isoliert, existieren jedoch im selben Prozessadressraum.

3. Dynamisches Verhalten & Sequenzablauf

1. Kontext-Initialisierung:
   • Die Applikation instanziiert über das Subsystem die Hardware-Abstraktionen (Device A, Device B).
   • Zuweisung bzw. Allokation von Sicherheits- und I/O-Puffern (Buffer A1, Buffer A2, Buffer B).
   • Erzeugung der zugehörigen Queues (Queue A, Queue B).
2. Workload-Enqueuing (Host → Subsystem):
   • Applikations-Threads stellen Rechenaufgaben (Task_A1 bis Task_A3 bzw. Task_B1, Task_B2) asynchron in die jeweilige Queue ein.
   • Tasks binden die benötigten Datenreferenzen aus den zugeordneten Buffern.
3. Dispatch & Ausführung (Subsystem → Device):
   • Das Subsystem serialisiert bzw. disponiert Tasks aus Queue A zur Ausführung auf Device A und parallel Tasks aus Queue B auf Device B.
   • Die Abarbeitung auf den Beschleunigern erfolgt asynchron zur CPU-Ausführung der Host-Applikation.
4. Synchronisation & Completion:
   • Synchronisation erfolgt ereignisbasiert (z. B. Callbacks, Futures, Synchronization Primitives/Fences), sobald ein Task die Verarbeitung im Buffer abgeschlossen hat.

4. Normative Relevanz & Entwickler-Hinweise

• Speichersicherheit & Buffer-Management:
  • Pufferzugriffe müssen deterministisch gegen Race Conditions abgesichert sein. Puffer dürfen während der Task-Abarbeitung auf dem Device nicht unkontrolliert durch den Host-Prozess modifiziert werden.
  • Zur Erfüllung von ISO 26262 müssen Puffer-Allokationen vorzugsweise statisch während der Initialisierungsphase erfolgen, um dynamische Out-of-Memory-Zustände zur Laufzeit auszuschließen.
• Freedom from Interference (FFI):
  • Die Koexistenz von Queue A und Queue B innerhalb desselben Prozesses erlaubt die Partitionierung unterschiedlicher Compute-Pipelines (z. B. verschiedene ASIL-Einstufungen oder Latenzanforderungen).
  • Hardware-seitig erfordert dies Unterstützung für deterministisches Time-Slicing, Memory Protection (IOMMU/SMMU) und Hardware-Isolation zwischen Device A und Device B.
• Fehlerkapselung (Fault Isolation):
  • Fehler bei der Ausführung eines Tasks (z. B. Timeout, ECC-Fehler oder illegaler Speicherzugriff in Task_A2 auf Device A) dürfen nicht zur Blockade von Queue B oder zum unkontrollierten Absturz des Gesamtprozesses führen, sondern müssen als Fehlerrückmeldung durch das Subsystem isoliert abgefangen und gemeldet werden.