Figure 5.1: Class diagram

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: UML-Klassendiagramm mit Schichtenarchitektur (Drei-Ebenen-Gliederung).
• Technischer Zweck: Spezifikation des objektorientierten C++-API-Designs für heterogene Rechenbeschleuniger (GPU, FPGA, DSP, NPU) im Kontext der AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SafeAPIHardwareAccelerators). Das Konzept adaptiert moderne heterogene Programmiermodelle (analog zu Khronos SYCL/OpenCL), bindet diese jedoch an das sicherheitsgerichtete, deterministische AUTOSAR-Adaptive-Fundament an (ara::core::Result, Health Monitoring, deterministisches Queueing).
• Schichtenunterteilung:
  1. Data storage and management (Speicherabstraktion, N-dimensionale Adressierung, Zugriffsschutz).
  2. Task execution (Asynchrone Auftragsplanung, Kernel-Dispatch, Synchronisation via Events).
  3. Device management and monitoring (Hardware-Topologie-Erkennung, Beschleuniger-Klassifizierung und Laufzeitüberwachung gem. ISO 26262).

2. Komponenten, Entitäten & Schnittstellen

Ebene 1: Data Storage and Management

• Range<Dimensions: int> (Template-Klasse):
  • Definiert den N-dimensionalen Indexraum (1D bis 3D) für Pufferallokation und parallele Iterationsräume.
  • Fabrikmethoden / API: Create(size_t dim0), Create(size_t dim0, size_t dim1), Create(size_t dim0, size_t dim1, size_t dim2) (jeweils mit Rückgabe Result<Range>), Dimensions-Getter GetDimension0/1/2(): size_t.
• Id<Dimensions: int> (Template-Klasse):
  • Repräsentiert den diskreten N-dimensionalen Indexpunkt innerhalb eines Range.
  • Fabrikmethoden / API: Überladene Create(...)-Methoden (Result<Id>), Get(size_t dimension): size_t, Set(size_t dimension, size_t index): void.
• Buffer<T: DataType, Dimensions: int> (Template-Klasse):
  • Kapselt typsichere Nutzdaten im Host- und Device-Speicher unabhängig vom Adressraum.
  • Fabrikmethoden / API: Create(Range<Dimensions>): Result<Buffer>.
  • Abhängigkeiten: Nutzt (<<use>>) Range. Befreundet mit (<<friend>>) Accessor.
• Accessor<T: DataType, Dimensions: int> (Template-Klasse):
  • Realisiert kontrollierten Lese-/Schreibzugriff auf Buffer-Instanzen unter Vermeidung von Aliasing- und Concurrency-Konflikten.
  • Fabrikmethoden / API: Create(Buffer<T, Dimensions>): Result<Buffer>, Create(Buffer<T, Dimensions>, TaskHandler): Result<Buffer>, Set(Id<Dimensions>, T): void, Get(Id<Dimensions>): T.
  • Abhängigkeiten: Nutzt (<<use>>) Id und TaskHandler.

Ebene 2: Task Execution

• TaskHandler:
  • Kapselt die Kernel-Logik und bindet Pufferzugriffe an den Ausführungsbefehl.
  • API: Create(): Result<TaskHandler>, SingleTask(lambda_task): void (singuläre Kernel-Ausführung), ParrallelFor(Range<Dimensions>, lambda_task): void (vektorisierte/parallele Ausführung über einen Indexraum).
  • Beziehungen: Nutzt (<<use>>) Range zur Iterationsdefinition; aggregiert über Accessor.
• Queue:
  • Zentrale Command-Queue zur Serialisierung und Übertragung von Aufgaben an das Zielgerät.
  • API: Create(DeviceSelector): Result<Queue>, Submit(TaskHandler): Result<Event>, Wait(): void.
  • Beziehungen:
    • Komposition (1 zu 1..*) gegenüber TaskHandler: Eine Queue hält die zu dispatchenden Tasks.
    • Nutzt (<<use>>) Buffer (Speichersynchronisation Host/Device) und Device (Hardwarebindung).
    • Nutzt (<<use>>) Event zur Signalisierung der Fertigstellung.
• Event:
  • Asynchrones Synchronisationsprimitiv zur Abbildung des Execution-DAGs (Dependencies).
  • API: Create(): Result<Event>, GetWaitList(): Vector<Event>, blockierende Methoden Wait(): void und Wait(Vector<Event>): void.

Ebene 3: Device Management and Monitoring

• Platform:
  • Repräsentiert die Heterogenitätsplattform (Host-SoC plus Beschleunigerumgebung).
  • API: static GetPlatforms(): Vector<Platform>, GetDevices(): Vector<Device>, IsHost(): Result<bool>.
  • Beziehungen: Komposition (1 zu 1..*) gegenüber Device.
• Device:
  • Abstraktion des konkreten physikalischen oder logischen Compute-Cores.
  • API: Create(DeviceSelector): Result<Device>, GetInfo(): Result<DeviceInfo>, Klassifizierer IsCpu(): Result<bool>, IsGpu(): Result<bool>, IsAccelerator(): Result<bool>.
  • Beziehungen: Komposition (1 zu 1) mit DeviceMonitor.
• DeviceMonitor:
  • Diagnostische Schnittstelle für Safety- und Health-Management (PHM / Platform Health Management).
  • API: CurrentLoad(): Result<DeviceLoadStatus>, HealthStatus(): Result<DeviceHealthStatus>, DeviceFailure(): Result<bool>, RuntimeError(): Result<DeviceRuntimeError>.
  • Beziehungen: Nutzt (<<use>>) Queue zur Überwachung laufender Execution-Pipelines.

3. Dynamisches Verhalten & Sequenzablauf

1. Hardware-Discovery & Queue-Erzeugung:
   • Abfrage verfügbarer Plattformen via Platform::GetPlatforms().
   • Selektion des Zielgeräts (Device) über DeviceSelector und Instanziierung einer Queue mittels Queue::Create(DeviceSelector).
2. Speicher-Allokation:
   • Definition des Datenformats und der Dimensionen via Range::Create(...).
   • Instanziierung des Buffer<T, Dim>::Create(...) auf Host-Seite.
3. Task-Zusammenstellung:
   • Instanziierung eines TaskHandler::Create().
   • Definition der Berechtigung über Accessor<T, Dim>::Create(buffer, taskHandler).
   • Übergabe des Rechenkernels über TaskHandler::SingleTask(...) oder TaskHandler::ParrallelFor(...) unter Nutzung von Lambda-Expressions.
4. Dispatching & Asynchrone Ausführung:
   • Submit an die Hardware über Queue::Submit(taskHandler). Der Aufruf ist nicht-blockierend und liefert synchron ein Result<Event> zurück.
   • Der Accessor stellt sicher, dass Daten bei Bedarf transparent auf den Device-Speicher übertragen werden (DMA/Shared Memory).
5. Synchronisation & Fehlerbehandlung:
   • Synchronisation wahlweise über Event::Wait() / Queue::Wait() oder Verknüpfung im Execution-Graph (GetWaitList()).
   • Überwachung von Hardwarezustand, Überlast und Laufzeitfehlern im Hintergrund über DeviceMonitor.

4. Normative Relevanz & Entwickler-Hinweise

• Fehlerbehandlungsmodell (ara::core::Result):
  • Sämtliche Fabrik- und Abfragemethoden geben Result<T> zurück. Embedded-Entwickler müssen strikt monadic checking (HasValue(), InspectError()) anwenden; C++-Exceptions sind auf AUTOSAR Adaptive im sicherheitskritischen Umfeld typischerweise deaktiviert.
• ISO-26262-Konformität & Safety-Isolation:
  • DeviceMonitor schlägt die Brücke zum AUTOSAR Platform Health Management (PHM). Bei Rückgabe von DeviceFailure() == true oder determinierbaren RuntimeError()-Codes muss die Applikation in einen sicheren Zustand (Degradation / Fallback auf Host-CPU) übergehen.
• Speicherzugriff & Aliasing-Vermeidung:
  • Direkter Speicherzugriff auf Buffer ist unterbunden (gekapselt via <<friend>> Accessor). Entwickler dürfen Puffer ausschließlich über typisierte Accessor-Instanzen manipulieren, um Race Conditions zwischen Host-CPU und Accelerator-Kernen auszuschließen.
• DeviceSelector & Deterministisches Deployment:
  • Die Entkopplung von Queue und Device via DeviceSelector erlaubt es, Kernels zur Entwurfszeit portabel zu halten und hardwareabhängig (CPU-Fallback vs. GPU/NPU-Beschleunigung) erst zur Laufzeit bindend zuzuordnen.