Figure 5.1: Interfaces Provided by Safe Hardware Acceleration to Other Functional Clusters

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm (C++ API-Strukturentwurf mit Template-Spezifikationen), gegliedert in vier funktionale Schichten / Domänen (Data management, Task execution, Device management and monitoring, Error Handling).
• Technischer Zweck: Spezifikation der standardisierten C++-Schnittstellen des Functional Clusters Safe Hardware Acceleration (SHWA, Doc ID 1088, Release R25-11) der AUTOSAR Adaptive Platform.
• Funktionale Einordnung: Hardware-unabhängige, funktionale Sicherheitsabstraktion (ISO 26262) für heterogene Compute-Beschleuniger (GPU, DSP, NPU, FPGA, Multicore-CPU). Das Programmiermodell adaptiert moderne SPMD-/Data-Parallel-Paradigmen (analog SYCL/OpenCL) über typsichere Puffer-, Accessor- und Command-Queue-Abstraktionen zur kontrollierten Interaktion mit anderen Functional Clusters (z. B. Vision, Perception, ML) und Adaptive Applications.

2. Komponenten, Entitäten & Schnittstellen

A. Data Management (Speicher- und Datenraum-Abstraktion)

• Range<Dimensions: int> (Klassentemplate):
  • Definiert diskrete n-dimensionale Iterations- und Puffergrößen (1D, 2D, 3D).
  • Factory: Create(size_t dim0 [, size_t dim1 [, size_t dim2]]) : Result<Range>
  • Inspektoren: GetDimension0(), GetDimension1(), GetDimension2() : size_t
• Id<Dimensions: int> (Klassentemplate):
  • Repräsentiert diskrete n-dimensionale Koordinaten/Indizes innerhalb eines Range.
  • Factory: Create(...) : Result<Id>
  • Operationen: Get(size_t dimension) : size_t, Set(size_t dimension, size_t index) : void
• Buffer<T: DataType, Dimensions: int> (Klassentemplate):
  • Verwaltet zusammenhängenden Host-/Device-Speicherraum ohne direkte Rohzeiger-Exposition.
  • Factory: Create(Range<Dimensions>) : Result<Buffer>
  • Beziehungen: Nutzt Range («use»); deklariert Accessor als «friend».
• Accessor<T: DataType, Dimensions: int> (Klassentemplate):
  • Kapselt kontrollierte Lese-/Schreibzugriffe auf Puffer zur Synchronisations- und Cache-Kohärenz-Steuerung.
  • Factory: Create(Buffer<T, Dimensions> [, TaskHandler]) : Result<Buffer> (Hinweis: Rückgabetyp im Standard-UML als Handle/Accessor typographiert).
  • Operationen: Set(Id<Dimensions>, T) : void, Get(Id<Dimensions>) : T.
  • Beziehungen: Nutzt Id («use»), greift als Friend auf Buffer zu, bindet an TaskHandler («use»).

B. Task Execution (Befehlswarteschlangen & Kernel-Scheduling)

• Queue:
  • Asynchrone Command-Queue zur Aufgabenübermittlung an ein spezifisches Device.
  • Methoden: Create(DeviceSelector) : Result<Queue>, Submit(TaskHandler) : Result<Event>, Wait() : void.
  • Beziehungen: 1:1-Komposition/Bindung an Device; 1-zu-1..*-Assoziation zu TaskHandler; nutzt Event; referenziert ErrorHandler (1).
• TaskHandler:
  • Kapselt die auszuführende Workload (Kernel/Funktor).
  • Methoden: Create() : Result<TaskHandler>, SingleTask(lambda_task) : void, ParallelFor(Range<Dimensions>, lambda_task) : void.
  • Beziehungen: Nutzt Range für Iterationsräume; nutzt Device («use»).
• Event:
  • Asynchrones Synchronisationsprimitiv für Abhängigkeitsketten und Completion-Tracking.
  • Methoden: Create() : Result<Event>, GetWaitList() : Vector<Event>, Wait() : void, Wait(Vector<Event>) : void.

C. Device Management and Monitoring (Hardware-Lifecycle & Health)

• Platform:
  • Einstiegspunkt zur Enumeration der Hardware-Plattform.
  • Methoden: static GetPlatforms() : Vector<Platform>, GetDevices() : Vector<Device>.
  • Beziehungen: Komposition 1 → 1..* Device.
• Device:
  • Repräsentiert physische/logische Recheneinheit.
  • Methoden: Create(DeviceSelector) : Result<Device>, GetInfo() : Result<DeviceInfo>, IsCpu(), IsGpu(), IsAccelerator() : Result<bool>.
  • Beziehungen: Komposition 1 → 1 DeviceMonitor.
• DeviceMonitor:
  • Schnittstelle für Functional Safety & Hardware-Health-Monitoring.
  • Methoden: Create(Device) : Result<DeviceMonitor>, Create(DeviceSelector) : Result<DeviceMonitor>, Status() : DeviceStatus.

D. Error Handling (ara::core-konformes Fehler-Subsystem)

• ara::core::ErrorCode:
  • Standard-Fehlerobjekt (AUTOSAR Core Type) mit Value() : CodeType, ErrorDomain() : const ErrorDomain&, Message() : StringView.
• ErrorHandler:
  • Registriert asynchrone Fehler-Callbacks für Hardware- und Ausführungsfehler: Create(lambda_handler) : Result<ErrorHandler>, HandleError(ErrorCode) : void.
• ShwaErrorDomain:
  • Spezifische Fehlerdomäne für Hardware Acceleration (Name(), Message()).
• ShwaException:
  • Exception-Wrapper für POSIX/Non-Realtime-Kontexte (ShwaException(ErrorCode)).
• ShwaErrorCode (Enumeration):
  • kRuntime, kTaskExecutionFailure, kMemoryNotAllocated, kIntegrityCorrupted, kResourceBusy, kInvalidAccessMode, kAccessorFailure, kEventInvalidOperation, kFeatureNotSupported, kInvalidIndex, kInvalidParameter, kInvalidObject.

3. Dynamisches Verhalten & Sequenzablauf

1. Hardware-Discovery & Monitoring-Initialisierung:
   • Abfrage verfügbarer Plattformen via Platform::GetPlatforms().
   • Selektion und Instanziierung des Zielgeräts via Device::Create(DeviceSelector).
   • Aktivierung der Sicherheitsüberwachung über DeviceMonitor::Create(Device) zur zyklischen Zustandsprüfung (Status()).
2. Setup der Ausführungsumgebung & Exception-Strategie:
   • Asynchroner Callback-Handler via ErrorHandler::Create(lambda) instanziieren.
   • Instanziierung der Queue für das selektierte Device unter Anbindung des ErrorHandler.
3. Puffer- und Datenvorbereitung:
   • Definition des Datenraums via Range<Dimensions>::Create(...).
   • Allokation des Device-/Host-Speichers via Buffer<T, Dimensions>::Create(range).
   • Host-seitige Vorbelegung über Accessor via Set(Id, value).
4. Kernel-Definition & Submission (Asynchroner Pfad):
   • Erzeugung eines TaskHandler.
   • Zuweisung des Datenpuffers über Accessor(buffer, taskHandler).
   • Definition des Rechenkerns (SingleTask oder datenparalleles ParallelFor).
   • Einreihen in die Ausführungswarteschlange via Queue::Submit(taskHandler) → liefert synchron ein Result<Event> zurück.
5. Synchronisation & Datenabholung:
   • Synchronisation auf Kernel-Abschluss via Event::Wait() oder Queue::Wait().
   • Validierung des Ausführungsergebnisses; Zugriff auf Ergebnisdaten über Host-Accessor::Get(Id).
6. Fehlerpfad (Asynchron vs. Synchron):
   • Synchrone Fehler (z. B. ungültige Dimensionen, Parameter) werden unmittelbar über den Rückgabetyp ara::core::Result<T> zurückgegeben.
   • Asynchrone Hardware-/Kernel-Fehler (z. B. Memory Corruptions, Execution Failures) triggern den im Queue-Kontext hinterlegten Callback ErrorHandler::HandleError(ErrorCode).

4. Normative Relevanz & Entwickler-Hinweise

• Deterministisches Speichermodell (Zero Data Races): Direkte Zeigerarithmetik auf Beschleunigerspeicher ist strikt untersagt. Der Zugriff erfolgt normativ ausschließlich über das Gespann Buffer ↔ Accessor. Das Binding von Accessor an TaskHandler erlaubt dem SHWA-Laufzeittreiber, Abhängigkeitsgraphen (Read-/Write-Hazards) vorab zu analysieren und implizite Cache-Invaliderungs- bzw. Flush-Operationen zwischen Host und Beschleuniger deterministisch einzuplanen.
• Safety-First Error Policy (ara::core::Result): Alle Factory- und Lifecycle-Methoden kapseln Rückgabewerte deterministisch in ara::core::Result<T>. Exceptions (ShwaException) sind in harten ASIL-Ausführungspfaden gemäß AUTOSAR C++14-Leitlinien typischerweise deaktiviert. Fehlerzustände müssen über Result::HasValue() bzw. Result::Error() abgefragt werden.
• ASIL-relevante Hardware-Integrität: Der Fehlercode kIntegrityCorrupted signalisiert den Ausfall hardwareseitiger Sicherheitsmechanismen (z. B. ECC-Multibit-Fehler auf Beschleuniger-SRAM, Memory Protection Violations, Watchdog-Timeouts der NPU/GPU). Dieser Fehler ist nicht lokal behebbar und erfordert über den ErrorHandler eine unmittelbare Eskalation an das Platform Health Management (PHM) zur Initiierung von Safe States.
• ParallelFor-Restriktionen: Beim Einsatz von ParallelFor(Range, lambda_task) müssen übergebene Lambdas seiteneffektfrei bezüglich nicht-lokaler Host-Ressourcen sein (Trivially Copyable Captures, keine dynamische Heap-Allokation innerhalb des Kernels), um die Portabilität auf Bare-Metal-Beschleuniger und DSPs sicherzustellen.