Modul ara::shwa — Safe Hardware Acceleration

Das adaptive Cluster shwa stellt eine prozesslokale Bibliothek zur funktional sicheren Ansteuerung heterogener Rechenbeschleuniger wie GPUs und NPUs bereit (AUTOSAR_AP_EXP_SWArchitecture S. 127). Es ermöglicht die geräteagnostische Selektion von Ausführungseinheiten, die Verwaltung n-dimensionaler Speicherpuffer sowie das asynchrone Einreihen paralleler Rechenaufgaben über Ausführungswarteschlangen ([AP_SWS_SHWA_00309], [AP_SWS_SHWA_00912]). Bei Task-Ausführungsfehlern existiert keine Rollback-Semantik, weshalb die betroffenen Pufferdaten als unbestimmt verändert gelten ([AP_SWS_SHWA_00604]).

mehr ›

Das funktionale Cluster Safe Hardware Acceleration (shwa) stellt für die AUTOSAR Adaptive Platform ein standardisiertes, funktional sicheres Ausführungsmodell für heterogene Recheneinheiten wie GPUs, NPUs, DSPs und FPGAs bereit (AUTOSAR_AP_EXP_SWArchitecture S. 132). Als In-Process-Bibliothek ausgeführt, ermöglicht shwa Adaptive Applications sowie anderen funktionalen Clustern die direkte und latenzfreie Steuerung von Hochleistungsrechenressourcen (AUTOSAR_AP_EXP_SWArchitecture S. 127, SWS_SafeHardwareAcceleration S. 23).

Hardware-Plattformen und Zielgeräte werden über Platform und Device abstrahiert ([AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308]). Mittels Strategieklassen wie GpuSelector oder AcceleratorSelector können Applikationen passende Rechenziele flexibel auswählen ([AP_SWS_SHWA_00407], [AP_SWS_SHWA_00413]). Datenpuffer werden über Buffer in N-dimensionalen Indexräumen (Range) allokiert, während strukturierte Lese- und Schreibzugriffe typensicher über Accessor und Id erfolgen ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_00707]).

Sequenzdiagramm: End-to-End-Ablauf von Pufferallokation, Kernel-Einreichung (Submit) und asynchroner Synchronisation. Quellen: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Berechnungsaufträge werden über TaskHandler als Einzelaufgabe oder parallele Schleife definiert und über Warteschlangen (Queue) an das Gerät übermittelt ([AP_SWS_SHWA_01203], [AP_SWS_SHWA_00912]). Die Rückgabe liefert ein Event-Objekt für blockierende oder zeitbegrenzte Synchronisationen ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00606]). Zur Laufzeitüberwachung dient DeviceMonitor, welcher den aktuellen Hardwarezustand (kReady, kNotAccesible, kFailure, kUnknown) abbildet ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103]).

Fehler werden deterministisch über ara::core::Result und ShwaErrorCode gemeldet ([AP_SWS_SHWA_01301]). Schlägt eine Task-Ausführung fehl, besitzen die Operationen keine Rollback-Semantik, sodass verknüpfte Puffer als unbestimmt modifiziert eingestuft werden müssen ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]).

mehr ›

Architektonische Rolle und Systemgrenzen von Safe Hardware Acceleration

Das funktionale Cluster Safe Hardware Acceleration (shwa) stellt innerhalb der AUTOSAR Adaptive Platform ein standardisiertes, funktional sicheres Ausführungs- und Abstraktionsmodell für heterogene Recheneinheiten wie GPUs, DSPs, NPUs und FPGAs bereit (AUTOSAR_AP_EXP_SWArchitecture S. 132). Im Gegensatz zu daemon-basierten Plattformclustern wie dem Platform Health Management ist shwa als nicht-daemon-basierte, prozesslokale Bibliothek (In-Process-Bibliothek) konzipiert (AUTOSAR_AP_EXP_SWArchitecture S. 127). Dadurch agiert die Laufzeitumgebung direkt im POSIX-Adressraum des konsumierenden Anwenderprozesses und entkoppelt Berechnungsaufträge ohne IPC-Latenzen von den darunterliegenden Beschleunigertreibern (AUTOSAR_AP_SWS_SafeHardwareAcceleration S. 23).

Das architektonische Schnittstellendesign orientiert sich an modernen Standards für heterogenes Rechnen wie SYCL und OpenCL, adaptiert diese Paradigmen jedoch strikt an die deterministischen und sicherheitsgerichteten Vorgaben der AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI S. 15). Konstruktoren aller primären Schnittstellenklassen sind privat deklariert; Instanzen lassen sich ausschließlich über benannte statische Factory-Methoden vom Typ Create() erzeugen (EXP_SafeHardwareAccelerationAPI S. 15). Nahezu alle Operationen signalisieren ihren Erfolg oder systemspezifische Fehlerzustände über den Rückgabetyp ara::core::Result ([AP_SWS_SHWA_00308], EXP_SafeHardwareAccelerationAPI S. 15). Neben regulären Adaptive Applications können auch andere funktionale Cluster (beispielsweise Bildverarbeitungs- oder Perzeptionscluster) die C++-Schnittstellen von shwa direkt für hochparallele HPC-Workloads einbinden (SWS_SafeHardwareAcceleration S. 23).

Kontextdiagramm: Einbettung von ara::shwa als In-Process-Bibliothek im POSIX-Prozessraum zur Ansteuerung heterogener Beschleuniger. Quellen: AUTOSAR_AP_EXP_SWArchitecture S. 127, SWS_SafeHardwareAcceleration S. 22.

Hardware-Topologie, Plattform-Ermittlung und Device-Selektion

Die Topologie der im Gesamtsystem integrierten Rechenbeschleuniger wird über die Schnittstelle Platform abstrahiert ([AP_SWS_SHWA_01107]). Über die statische Operation Platform::GetPlatforms() ermittelt die Anwendung zunächst alle registrierten Ausführungsplattformen und fragt anschließend mittels Platform::GetDevices() die jeweils zugeordneten Recheneinheiten ab ([AP_SWS_SHWA_01108], AUTOSAR_AP_EXP_SWArchitecture S. 132). Jedes physische oder logische Ausführungsziel wird im System durch ein Device-Objekt repräsentiert ([AP_SWS_SHWA_00302]). Ein Device bietet Inspektionsmethoden zur Klassifizierung der Hardwareart an, darunter IsCpu() ([AP_SWS_SHWA_00310]), IsGpu() ([AP_SWS_SHWA_00311]) und IsAccelerator() ([AP_SWS_SHWA_00312]), sowie generische Detailabfragen über das Funktionstemplate GetInfo() ([AP_SWS_SHWA_00313]).

Zur gezielten Auswahl geeigneter Recheneinheiten stellt shwa das polymorphe Selektionsmuster DeviceSelector bereit ([AP_SWS_SHWA_00402], [AP_SWS_SHWA_00403]). Über die Standard-Implementierungen GpuSelector ([AP_SWS_SHWA_00406], [AP_SWS_SHWA_00407]), CpuSelector ([AP_SWS_SHWA_00409], [AP_SWS_SHWA_00410]) und AcceleratorSelector ([AP_SWS_SHWA_00412], [AP_SWS_SHWA_00413]) können Systeme Rechenziele nach vordefinierten Prioritäten oder heuristischen Eignungsbewertungen filtern. Die Fabrikmethode Device::Create(deviceSelector) bindet diesen Selektionsmechanismus unmittelbar an die Geräteinstanziierung an ([AP_SWS_SHWA_00309]).

Sequenzdiagramm: Topologieermittlung, Selektion eines Rechenziels und Instanziierung eines logischen Device. Quellen: AP_SWS_SHWA_01107, AP_SWS_SHWA_01108, AP_SWS_SHWA_00407, AP_SWS_SHWA_00309.

Speicherverwaltung und multidimensionaler Datenzugriff mit Buffer und Accessor

Für parallele Rechenoperationen auf heterogenen Architekturen trennt shwa die physische Datenhaltung strikt vom logischen Zugriff (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI S. 15). Speicherbereiche werden über das Template Buffer<DataT, Dimensions, AllocatorT> gekapselt ([AP_SWS_SHWA_00202]). Die Ausdehnung eines Speichers im ein-, zwei- oder dreidimensionalen Raum wird durch die Struktur Range<Dimensions> vorgegeben ([AP_SWS_SHWA_01007], [AP_SWS_SHWA_01008], [AP_SWS_SHWA_01009]), deren Dimensionen über GetDimension0(), GetDimension1() und GetDimension2() abgefragt werden können ([AP_SWS_SHWA_01010], [AP_SWS_SHWA_01011], [AP_SWS_SHWA_01012]). Ein Puffer kann entweder neu mit eigenem Speicher bzw. Allokator erzeugt werden ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00210]) oder vorhandene Host-Speicherzeiger (hostData) als Eingangs- oder Ausgangsdaten einbinden ([AP_SWS_SHWA_00211], [AP_SWS_SHWA_00213], [AP_SWS_SHWA_00214]). Besitzende Puffer werden von Buffer::Create() typischerweise als std::unique_ptr zurückgegeben (EXP_SafeHardwareAccelerationAPI S. 15).

Der eigentliche Lese- und Schreibzugriff auf Pufferdaten erfolgt nicht direkt über Zeiger, sondern über typisierte Accessor-Objekte ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00008]). Der Zugriffsmodus wird über das Enum AccessMode bestimmt, welches die Ausprägungen kRead, kWrite und kReadWrite umfasst ([AP_SWS_SHWA_00101]). Die Adressierung diskreter Indexpunkte im N-dimensionalen Raum erfolgt mittels des Typs Id<Dimensions> ([AP_SWS_SHWA_00707], [AP_SWS_SHWA_00708], [AP_SWS_SHWA_00709]) mit den entsprechenden Koordinaten-Gettern und -Settern ([AP_SWS_SHWA_00710], [AP_SWS_SHWA_00711]). Zur Manipulation einzelner Feldelemente stellt Accessor den Indexoperator operator[] ([AP_SWS_SHWA_00009], [AP_SWS_SHWA_00010]) sowie die synchronisierenden Methoden Get() ([AP_SWS_SHWA_00012]) und Set() ([AP_SWS_SHWA_00011]) bereit. Durch die Übergabe von PropertyList-Instanzen lassen sich spezifische Speichereigenschaften und Zugriffsattribute deklarativ anfügen ([AP_SWS_SHWA_00802], [AP_SWS_SHWA_00015], [AP_SWS_SHWA_00215]).

Task-Definition, Auftragsplanung und Ausführung über Queues

Die Ausführung von Berechnungen auf Beschleunigergeräten wird über Befehlswarteschlangen vom Typ Queue koordiniert ([AP_SWS_SHWA_00902]). Eine Queue wird über ihre Factory-Methode Create() an ein bestimmtes Device oder einen DeviceSelector gebunden und optional mit einem ErrorHandler sowie einer PropertyList konfiguriert ([AP_SWS_SHWA_00908], [AP_SWS_SHWA_00909]). Die Methode GetDevice() liefert das an die Queue gekoppelte Rechengerät zurück ([AP_SWS_SHWA_00910]). Das Ausführungsverhalten der Warteschlange kann über IsInOrder() überprüft werden ([AP_SWS_SHWA_00911]): Bei einer In-Order-Warteschlange werden eingereihte Berechnungsaufgaben streng sequenziell abgearbeitet (AUTOSAR_AP_EXP_SWArchitecture S. 133).

Die Definition konkreter Arbeitslasten erfolgt mithilfe von TaskHandler ([AP_SWS_SHWA_01202]). Der Task-Handler unterscheidet zwischen atomaren Einzelaufgaben (SingleTask(), [AP_SWS_SHWA_01203]) und datenparallelen Berechnungsrastern (ParallelFor(), [AP_SWS_SHWA_01204]). Das Ziel der Ausführung kann dabei über die Enumeration Target entweder als Beschleuniger (kDevice) oder als CPU-Host-Aufgabe (kHostTask) festgelegt werden ([AP_SWS_SHWA_00102]). Die Einreichung an die Warteschlange geschieht über die Methode Queue::Submit() ([AP_SWS_SHWA_00912]). Bei komplexeren Pipelines unterstützt Submit() auch die Angabe einer sekundären Queue, um Abhängigkeiten zwischen verschiedenen Hardware-Pipelines abzubilden ([AP_SWS_SHWA_00913], AUTOSAR_AP_SWS_SafeHardwareAcceleration S. 23).

Sequenzdiagramm: End-to-End-Ablauf von Pufferallokation, Kernel-Einreichung (Submit) und asynchroner Synchronisation. Quellen: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Ereignisbasierte Synchronisation und Hardware-Zustandsüberwachung

Jede Einreichung über Queue::Submit() liefert ein Event-Objekt zurück, das als asynchroner Synchronisationsanker dient ([AP_SWS_SHWA_00912], [AP_SWS_SHWA_00602]). Ein Aufrufer kann die Fertigstellung der Hardwareberechnung entweder blockierend mittels Event::Wait() abwarten ([AP_SWS_SHWA_00604]) oder eine zeitlich begrenzte Synchronisation über WaitFor(ms) durchführen ([AP_SWS_SHWA_00606]). Mehrere Ereignisse können über Event::Wait(const Vector<Event>&) aggregiert überwacht werden ([AP_SWS_SHWA_00605]). Alternativ bietet die Queue selbst kollektive Synchronisationsmethoden an: Queue::Wait() blockiert, bis alle bisher eingereihten Aufgaben abgearbeitet sind ([AP_SWS_SHWA_00914]), während Queue::WaitFor(ms) das Warten auf ein vorgegebenes Timeout limitiert ([AP_SWS_SHWA_00917]).

Um die Zuverlässigkeit und funktionale Sicherheit der Hardwarebeschleuniger zur Laufzeit zu gewährleisten, definiert shwa die Überwachungskomponente DeviceMonitor ([AP_SWS_SHWA_01402]). Instanzen werden über statische Create()-Methoden bezogen auf ein Device oder einen DeviceSelector erzeugt ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_01408]). Über die Methode DeviceMonitor::Status() wird der aktuelle Hardwarezustand abgefragt ([AP_SWS_SHWA_01409]). Die Enumeration DeviceStatus umfasst vier standardisierte Zustände: kReady (0, betriebsbereit), kNotAccesible (1, nicht zugänglich), kFailure (2, Fehlerzustand) und kUnknown (255, Status nicht ermittelbar) ([AP_SWS_SHWA_00103]). Dieser Überwachungsmechanismus bildet das Fundament für Sicherheitsanalysen und Health-Monitoring gemäß ISO 26262 (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI S. 15).

Zustandsdiagramm: Lebenszyklus und Statusübergänge des DeviceStatus nach ara::shwa::DeviceMonitor. Quellen: AP_SWS_SHWA_00103, AP_SWS_SHWA_01409.

Verhalten im Fehlerfall und Diagnose

Das Fehlerbehandlungskonzept von shwa basiert auf der AUTOSAR-spezifischen Fehlerdomäne ShwaErrorDomain ([AP_SWS_SHWA_01307]), die über GetShwaDomain() bezogen werden kann ([AP_SWS_SHWA_01311]). Spezifische Fehlercodes werden durch die standardisierte Enumeration ShwaErrorCode abgebildet ([AP_SWS_SHWA_01301]). Hierzu zählen fundamentale Laufzeitfehler wie kRuntime, Berechnungsabbrüche auf dem Beschleuniger wie kTaskExecutionFailure, Speicherallokationsfehler wie kMemoryNotAllocated, Verletzungen der Speicherintegrität wie kIntegrityCorrupted, temporäre Betriebsmittelkonflikte wie kResourceBusy sowie ungültige Zugriffsmodi wie kInvalidAccessMode ([AP_SWS_SHWA_01301]). Fehlercodes werden typsicher mit MakeErrorCode() konstruiert ([AP_SWS_SHWA_01312]) und liefern über Name() und Message() textuelle Beschreibungen ([AP_SWS_SHWA_01308], [AP_SWS_SHWA_01309]).

Fehler bei der asynchronen Ausführung oder beim Warten auf Ereignisse (Event::Wait() oder Queue::Wait()) haben gravierende Auswirkungen auf die Datenkonsistenz: Tritt während der Berechnung ein kTaskExecutionFailure oder kRuntime auf, besitzen die betroffenen Operationen keine Rollback-Semantik und die Daten in den verknüpften Puffern gelten als unbestimmt modifiziert ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]). Für asynchrone Benachrichtigungen wird die Klasse ErrorHandler genutzt, deren Callback mittels HandleError() ausgelöst wird ([AP_SWS_SHWA_00507], [AP_SWS_SHWA_00508]). Sollte die Anwendung Ausnahmebehandlung erfordern, können Fehler über ThrowAsException() in eine ShwaException konvertiert werden ([AP_SWS_SHWA_01303], [AP_SWS_SHWA_01310]).

Weiterführende Detailbelege und Spezifikationsverweise

Die Architektur und Anforderungen des Clusters shwa sind durch normative Requirements und zugehörige Erläuterungsdokumente vollständig belegt. Tabelle 1 fasst die Kernkonzepte und ihre maßgeblichen Fundstellen zusammen.

Themenbereich	Wichtige Spezifikationselemente	Belegstellen
Architektur & Bereitstellung	In-Process-Bibliothek, funktionale Einordnung in Kategorie Safety	AUTOSAR_AP_EXP_SWArchitecture S. 127, AUTOSAR_AP_EXP_SWArchitecture S. 132
Topologie & Selektion	Platform, Device, DeviceSelector, GpuSelector, CpuSelector	[AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308], [AP_SWS_SHWA_00403]
Speicher & Datenzugriff	Buffer, Accessor, Range, Id, AccessMode	[AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_01007], [AP_SWS_SHWA_00101]
Auftragsplanung & Synchronisation	Queue, TaskHandler, Event	[AP_SWS_SHWA_00908], [AP_SWS_SHWA_01202], [AP_SWS_SHWA_00604]
Hardwareüberwachung & Fehler	DeviceMonitor, DeviceStatus, ShwaErrorCode, ErrorHandler	[AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103], [AP_SWS_SHWA_01301], [AP_SWS_SHWA_00507]

Die typische Pipeline-Instanziierung und Entkopplung mehrerer Warteschlangen innerhalb einer Anwendung wird ausführlich in der Spezifikation veranschaulicht (SWS_SafeHardwareAcceleration S. 22, AUTOSAR_AP_SWS_SafeHardwareAcceleration S. 23). Die strenge Trennung von Speicher- und Berechnungsressourcen garantiert dabei deterministisches Verhalten in sicherheitskritischen automobilen Anwendungsfeldern (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI S. 15).