module ara::shwa — Safe Hardware Acceleration

Le cluster adaptatif shwa fournit une bibliothèque locale au processus pour le pilotage fonctionnellement sûr d'accélérateurs de calcul hétérogènes tels que les GPU et les NPU (AUTOSAR_AP_EXP_SWArchitecture p. 127). Il permet la sélection indépendante du périphérique des unités d'exécution, la gestion de tampons de mémoire n-dimensionnels ainsi que la mise en file d'attente asynchrone de tâches de calcul parallèles via des files d'attente d'exécution ([AP_SWS_SHWA_00309], [AP_SWS_SHWA_00912]). En cas d'erreurs d'exécution de tâches, aucune sémantique de rollback n'existe, raison pour laquelle les données de tampon concernées sont considérées comme modifiées de manière indéterminée ([AP_SWS_SHWA_00604]).

plus ›

Le cluster fonctionnel Safe Hardware Acceleration (shwa) fournit pour l'AUTOSAR Adaptive Platform un modèle d'exécution standardisé et fonctionnellement sûr pour les unités de calcul hétérogènes telles que les GPU, les NPU, les DSP et les FPGA (AUTOSAR_AP_EXP_SWArchitecture p. 132). Implémenté sous forme de bibliothèque intégrée au processus (In-Process), shwa permet aux Adaptive Applications ainsi qu'à d'autres clusters fonctionnels de contrôler directement et sans latence les ressources de calcul haute performance (AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 23).

Les plateformes matérielles et les périphériques cibles sont abstraits via Platform et Device ([AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308]). Au moyen de classes de stratégie telles que GpuSelector ou AcceleratorSelector, les applications peuvent sélectionner de manière flexible les cibles de calcul adaptées ([AP_SWS_SHWA_00407], [AP_SWS_SHWA_00413]). Les tampons de données sont alloués via Buffer dans des espaces d'indices à N dimensions (Range), tandis que les accès structurés en lecture et en écriture s'effectuent avec une sécurité de type via Accessor et Id ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_00707]).

Diagramme de séquence : déroulement de bout en bout de l'allocation de tampon, de la soumission de kernel (Submit) et de la synchronisation asynchrone. Sources : AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Les ordres de calcul sont définis via TaskHandler sous la forme d'une tâche unique ou d'une boucle parallèle et transmis au périphérique via des files d'attente (Queue) ([AP_SWS_SHWA_01203], [AP_SWS_SHWA_00912]). Le retour fournit un objet Event pour des synchronisations bloquantes ou limitées dans le temps ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00606]). DeviceMonitor sert à la surveillance au moment de l'exécution et reflète l'état matériel actuel (kReady, kNotAccesible, kFailure, kUnknown) ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103]).

Les erreurs sont signalées de manière déterministe via ara::core::Result et ShwaErrorCode ([AP_SWS_SHWA_01301]). Si l'exécution d'une tâche échoue, les opérations ne possèdent aucune sémantique de rollback, de sorte que les tampons associés doivent être classés comme modifiés de manière indéterminée ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]).

plus ›

Rôle architectural et limites système de Safe Hardware Acceleration

Au sein de l'AUTOSAR Adaptive Platform, le cluster fonctionnel Safe Hardware Acceleration (shwa) fournit un modèle d'exécution et d'abstraction standardisé et fonctionnellement sûr pour les unités de calcul hétérogènes telles que les GPU, DSP, NPU et FPGA (AUTOSAR_AP_EXP_SWArchitecture p. 132). Contrairement aux clusters de plateforme basés sur des démons comme Platform Health Management, shwa est conçu comme une bibliothèque locale au processus, non basée sur des démons (bibliothèque In-Process) (AUTOSAR_AP_EXP_SWArchitecture p. 127). De ce fait, l'environnement d'exécution opère directement dans l'espace d'adressage POSIX du processus utilisateur consommateur et découple les ordres de calcul des pilotes d'accélérateurs sous-jacents sans latence IPC (AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

La conception architecturale de l'interface s'inspire des standards modernes de calcul hétérogène tels que SYCL et OpenCL, tout en adaptant strictement ces paradigmes aux exigences déterministes et axées sur la sécurité de l'AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Les constructeurs de toutes les classes d'interface primaires sont déclarés privés ; les instances ne peuvent être créées que via des méthodes de fabrique statiques nommées du type Create() (EXP_SafeHardwareAccelerationAPI p. 15). La quasi-totalité des opérations signale son succès ou des états d'erreur spécifiques au système via le type de retour ara::core::Result ([AP_SWS_SHWA_00308], EXP_SafeHardwareAccelerationAPI p. 15). Outre les Adaptive Applications régulières, d'autres clusters fonctionnels (par exemple des clusters de traitement d'images ou de perception) peuvent également intégrer directement les interfaces C++ de shwa pour des charges de travail HPC hautement parallèles (SWS_SafeHardwareAcceleration p. 23).

Diagramme de contexte : intégration de ara::shwa en tant que bibliothèque In-Process dans l'espace de processus POSIX pour le pilotage d'accélérateurs hétérogènes. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 22.

Topologie matérielle, découverte de plateforme et sélection de périphérique

La topologie des accélérateurs de calcul intégrés dans l'ensemble du système est abstraite via l'interface Platform ([AP_SWS_SHWA_01107]). Via l'opération statique Platform::GetPlatforms(), l'application détermine d'abord toutes les plateformes d'exécution enregistrées, puis interroge au moyen de Platform::GetDevices() les unités de calcul associées respectives ([AP_SWS_SHWA_01108], AUTOSAR_AP_EXP_SWArchitecture p. 132). Chaque cible d'exécution physique ou logique est représentée dans le système par un objet Device ([AP_SWS_SHWA_00302]). Un Device propose des méthodes d'inspection pour classifier le type de matériel, notamment IsCpu() ([AP_SWS_SHWA_00310]), IsGpu() ([AP_SWS_SHWA_00311]) et IsAccelerator() ([AP_SWS_SHWA_00312]), ainsi que des requêtes détaillées génériques via le modèle de fonction GetInfo() ([AP_SWS_SHWA_00313]).

Pour le choix ciblé d'unités de calcul appropriées, shwa met à disposition le modèle de sélection polymorphe DeviceSelector ([AP_SWS_SHWA_00402], [AP_SWS_SHWA_00403]). Grâce aux implémentations standard GpuSelector ([AP_SWS_SHWA_00406], [AP_SWS_SHWA_00407]), CpuSelector ([AP_SWS_SHWA_00409], [AP_SWS_SHWA_00410]) et AcceleratorSelector ([AP_SWS_SHWA_00412], [AP_SWS_SHWA_00413]), les systèmes peuvent filtrer les cibles de calcul selon des priorités prédéfinies ou des évaluations d'adéquation heuristiques. La méthode de fabrique Device::Create(deviceSelector) relie directement ce mécanisme de sélection à l'instanciation de périphérique ([AP_SWS_SHWA_00309]).

Diagramme de séquence : détermination de la topologie, sélection d'une cible de calcul et instanciation d'un périphérique logique. Sources : AP_SWS_SHWA_01107, AP_SWS_SHWA_01108, AP_SWS_SHWA_00407, AP_SWS_SHWA_00309.

Gestion de la mémoire et accès multidimensionnel aux données avec Buffer et Accessor

Pour les opérations de calcul parallèles sur des architectures hétérogènes, shwa sépare strictement la conservation physique des données de l'accès logique (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Les zones de mémoire sont encapsulées via le modèle Buffer<DataT, Dimensions, AllocatorT> ([AP_SWS_SHWA_00202]). L'étendue d'une mémoire dans l'espace uni-, bi- ou tridimensionnel est définie par la structure Range<Dimensions> ([AP_SWS_SHWA_01007], [AP_SWS_SHWA_01008], [AP_SWS_SHWA_01009]), dont les dimensions peuvent être interrogées via GetDimension0(), GetDimension1() et GetDimension2() ([AP_SWS_SHWA_01010], [AP_SWS_SHWA_01011], [AP_SWS_SHWA_01012]). Un tampon peut soit être créé à neuf avec sa propre mémoire ou son propre allocateur ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00210]), soit intégrer des pointeurs de mémoire hôte existants (hostData) comme données d'entrée ou de sortie ([AP_SWS_SHWA_00211], [AP_SWS_SHWA_00213], [AP_SWS_SHWA_00214]). Les tampons propriétaires sont généralement renvoyés par Buffer::Create() sous forme de std::unique_ptr (EXP_SafeHardwareAccelerationAPI p. 15).

L'accès proprement dit en lecture et en écriture aux données de tampon ne s'effectue pas directement via des pointeurs, mais via des objets typés Accessor ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00008]). Le mode d'accès est déterminé par l'énumération AccessMode, qui comprend les valeurs kRead, kWrite et kReadWrite ([AP_SWS_SHWA_00101]). L'adressage de points d'indice discrets dans l'espace à N dimensions s'effectue au moyen du type Id<Dimensions> ([AP_SWS_SHWA_00707], [AP_SWS_SHWA_00708], [AP_SWS_SHWA_00709]) avec les accesseurs et mutateurs de coordonnées correspondants ([AP_SWS_SHWA_00710], [AP_SWS_SHWA_00711]). Pour manipuler des éléments de tableau individuels, Accessor met à disposition l'opérateur d'indexation operator[] ([AP_SWS_SHWA_00009], [AP_SWS_SHWA_00010]) ainsi que les méthodes de synchronisation Get() ([AP_SWS_SHWA_00012]) et Set() ([AP_SWS_SHWA_00011]). La transmission d'instances de PropertyList permet d'adjoindre de manière déclarative des propriétés de mémoire et des attributs d'accès spécifiques ([AP_SWS_SHWA_00802], [AP_SWS_SHWA_00015], [AP_SWS_SHWA_00215]).

Définition des tâches, ordonnancement des commandes et exécution via des files d'attente

L'exécution de calculs sur des périphériques accélérateurs est coordonnée par le biais de files d'attente de commandes de type Queue ([AP_SWS_SHWA_00902]). Une Queue est liée à un Device ou à un DeviceSelector déterminé via sa méthode factory Create(), et configurée de manière facultative avec un ErrorHandler ainsi qu'une PropertyList ([AP_SWS_SHWA_00908], [AP_SWS_SHWA_00909]). La méthode GetDevice() renvoie le périphérique de calcul couplé à la file d'attente ([AP_SWS_SHWA_00910]). Le comportement d'exécution de la file d'attente peut être vérifié via IsInOrder() ([AP_SWS_SHWA_00911]) : dans le cas d'une file d'attente in-order, les tâches de calcul enfilées sont traitées de manière strictement séquentielle (AUTOSAR_AP_EXP_SWArchitecture p. 133).

La définition de charges de travail concrètes s'effectue à l'aide de TaskHandler ([AP_SWS_SHWA_01202]). Le gestionnaire de tâches distingue les tâches unitaires atomiques (SingleTask(), [AP_SWS_SHWA_01203]) des grilles de calcul parallèles aux données (ParallelFor(), [AP_SWS_SHWA_01204]). La cible de l'exécution peut être définie via l'énumération Target soit comme un accélérateur (kDevice), soit comme une tâche hôte CPU (kHostTask) ([AP_SWS_SHWA_00102]). La soumission à la file d'attente s'effectue via la méthode Queue::Submit() ([AP_SWS_SHWA_00912]). Pour les pipelines plus complexes, Submit() prend également en charge la spécification d'une file d'attente secondaire afin de représenter les dépendances entre différents pipelines matériels ([AP_SWS_SHWA_00913], AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

Diagramme de séquence : déroulement de bout en bout de l'allocation de tampon, de la soumission de kernel (Submit) et de la synchronisation asynchrone. Sources : AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Synchronisation basée sur les événements et surveillance de l'état du matériel

Chaque soumission via Queue::Submit() renvoie un objet Event qui sert de point d'ancrage de synchronisation asynchrone ([AP_SWS_SHWA_00912], [AP_SWS_SHWA_00602]). Un appelant peut soit attendre la fin du calcul matériel de manière bloquante au moyen de Event::Wait() ([AP_SWS_SHWA_00604]), soit effectuer une synchronisation limitée dans le temps via WaitFor(ms) ([AP_SWS_SHWA_00606]). Plusieurs événements peuvent être surveillés de manière agrégée via Event::Wait(const Vector<Event>&) ([AP_SWS_SHWA_00605]). En alternative, la file d'attente elle-même propose des méthodes de synchronisation collective : Queue::Wait() bloque jusqu'à ce que toutes les tâches précédemment enfilées soient traitées ([AP_SWS_SHWA_00914]), tandis que Queue::WaitFor(ms) limite l'attente à un délai d'expiration prédéfini ([AP_SWS_SHWA_00917]).

Afin de garantir la fiabilité et la sécurité fonctionnelle des accélérateurs matériels au moment de l'exécution, shwa définit le composant de surveillance DeviceMonitor ([AP_SWS_SHWA_01402]). Les instances sont créées via des méthodes Create() statiques associées à un Device ou à un DeviceSelector ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_01408]). L'état matériel actuel est interrogé via la méthode DeviceMonitor::Status() ([AP_SWS_SHWA_01409]). L'énumération DeviceStatus comprend quatre états standardisés : kReady (0, opérationnel), kNotAccesible (1, non accessible), kFailure (2, état d'erreur) et kUnknown (255, état non déterminable) ([AP_SWS_SHWA_00103]). Ce mécanisme de surveillance constitue le fondement des analyses de sécurité et du health-monitoring conformément à l'ISO 26262 (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).

Diagramme d'état : cycle de vie et transitions d'état de DeviceStatus selon ara::shwa::DeviceMonitor. Sources : AP_SWS_SHWA_00103, AP_SWS_SHWA_01409.

Comportement en cas d'erreur et diagnostic

Le concept de traitement des erreurs de shwa repose sur le domaine d'erreur ShwaErrorDomain spécifique à AUTOSAR ([AP_SWS_SHWA_01307]), qui peut être obtenu via GetShwaDomain() ([AP_SWS_SHWA_01311]). Les codes d'erreur spécifiques sont représentés par l'énumération standardisée ShwaErrorCode ([AP_SWS_SHWA_01301]). Parmi ceux-ci figurent des erreurs d'exécution fondamentales telles que kRuntime, des interruptions de calcul sur l'accélérateur telles que kTaskExecutionFailure, des erreurs d'allocation de mémoire telles que kMemoryNotAllocated, des violations de l'intégrité de la mémoire telles que kIntegrityCorrupted, des conflits de ressources temporaires tels que kResourceBusy ainsi que des modes d'accès non valides tels que kInvalidAccessMode ([AP_SWS_SHWA_01301]). Les codes d'erreur sont construits de manière sécurisée du point de vue des types avec MakeErrorCode() ([AP_SWS_SHWA_01312]) et fournissent des descriptions textuelles via Name() et Message() ([AP_SWS_SHWA_01308], [AP_SWS_SHWA_01309]).

Les erreurs lors de l'exécution asynchrone ou lors de l'attente d'événements (Event::Wait() ou Queue::Wait()) ont de graves répercussions sur la cohérence des données : si un kTaskExecutionFailure ou un kRuntime survient pendant le calcul, les opérations concernées ne possèdent aucune sémantique de rollback et les données dans les tampons associés sont considérées comme modifiées de manière indéterminée ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]). Pour les notifications asynchrones, la classe ErrorHandler est utilisée, dont le callback est déclenché au moyen de HandleError() ([AP_SWS_SHWA_00507], [AP_SWS_SHWA_00508]). Si l'application requiert un traitement des exceptions, les erreurs peuvent être converties en une ShwaException via ThrowAsException() ([AP_SWS_SHWA_01303], [AP_SWS_SHWA_01310]).

Justifications détaillées complémentaires et références aux spécifications

L'architecture et les exigences du cluster shwa sont entièrement justifiées par des exigences normatives et les documents explicatifs associés. Le tableau 1 résume les concepts clés ainsi que leurs références déterminantes.

Domaine thématique	Éléments de spécification importants	Références justificatives
Architecture & mise à disposition	Bibliothèque in-process, classification fonctionnelle dans la catégorie Safety	AUTOSAR_AP_EXP_SWArchitecture S. 127, AUTOSAR_AP_EXP_SWArchitecture S. 132
Topologie & sélection	Platform, Device, DeviceSelector, GpuSelector, CpuSelector	[AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308], [AP_SWS_SHWA_00403]
Mémoire & accès aux données	Buffer, Accessor, Range, Id, AccessMode	[AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_01007], [AP_SWS_SHWA_00101]
Planification des tâches & synchronisation	Queue, TaskHandler, Event	[AP_SWS_SHWA_00908], [AP_SWS_SHWA_01202], [AP_SWS_SHWA_00604]
Surveillance du matériel & erreurs	DeviceMonitor, DeviceStatus, ShwaErrorCode, ErrorHandler	[AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103], [AP_SWS_SHWA_01301], [AP_SWS_SHWA_00507]

L'instanciation typique d'un pipeline et le découplage de plusieurs files d'attente au sein d'une application sont illustrés en détail dans la spécification (SWS_SafeHardwareAcceleration p. 22, AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23). La stricte séparation des ressources de mémoire et de calcul garantit ainsi un comportement déterministe dans les domaines d'application automobiles critiques pour la sécurité (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).

Le module Safe Hardware Acceleration fournit une interface C++ standardisée et conforme aux exigences de sûreté fonctionnelle pour déporter des calculs intensifs vers des accélérateurs hétérogènes tels que les GPU, FPGA, DSP et NPU (SWArchitecture p. 132). Déployé sous la forme d'une bibliothèque intégrée sans démon, il gère la découverte matérielle, l'allocation sécurisée de tampons multidimensionnels, la soumission asynchrone de tâches parallèles via des files de commandes et leur synchronisation par événements ([AP_SWS_SHWA_00908], [AP_SWS_SHWA_01204]). Il intègre une surveillance continue de l'état des dispositifs matériels ainsi qu'un domaine d'erreur dédié conforme à l'architecture AUTOSAR Adaptive ([AP_SWS_SHWA_01301]).

plus ›

Le cluster fonctionnel Safe Hardware Acceleration (shwa) de l'AUTOSAR Adaptive Platform (Release R25-11) fournit un modèle d'exécution standardisé et sécurisé pour déporter des calculs intensifs vers des accélérateurs matériels hétérogènes tels que des GPU, NPU, DSP ou FPGA (SWArchitecture p. 132). Rattaché à la catégorie Safety, shwa est implémenté sous forme d'une bibliothèque directement liée dans l'espace d'adressage de l'application cliente (in-process library), garantissant des performances maximales sans surcoût de communication inter-processus (SWArchitecture p. 127).

Diagramme de composants : Architecture en bibliothèque in-process et interfaçage matériel hétérogène de Safe Hardware Acceleration. Sources : SWArchitecture p. 127, SWArchitecture p. 132.

L'architecture de programmation sépare l'abstraction géométrique des données et l'ordonnancement des calculs (SafeHardwareAccelerationAPI p. 15). Les plages multidimensionnelles Range et les index Id structurent la mémoire allouée dans les tampons Buffer, tandis que les objets Accessor régissent les droits de lecture et écriture en garantissant la cohérence ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00209], [AP_SWS_SHWA_01007]). L'attribution du travail est prise en charge par les sélecteurs spécialisés DeviceSelector (notamment pour GPU ou CPU), permettant d'instancier des files de commandes Queue adaptées à la topologie ([AP_SWS_SHWA_00407], [AP_SWS_SHWA_00908]).

Diagramme de séquence : Pipeline de sélection, soumission asynchrone et synchronisation par événement. Sources : [AP_SWS_SHWA_00908], [AP_SWS_SHWA_00912], [AP_SWS_SHWA_00604].

La soumission de tâches de traitement individuel (SingleTask) ou massivement parallèle (ParallelFor) s'opère via Submit() et produit un objet de synchronisation Event autorisant des attentes bloquantes ou temporisées ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_01204]). La sûreté est complétée par la surveillance continue de l'état matériel via DeviceMonitor et par une gestion formelle des erreurs asynchrones reposant sur ErrorHandler et le domaine normalisé ShwaErrorDomain ([AP_SWS_SHWA_00507], [AP_SWS_SHWA_01301], [AP_SWS_SHWA_01407]).

plus ›

Rôle architectural et intégration en bibliothèque de Safe Hardware Acceleration

Au sein de l'AUTOSAR Adaptive Platform (AP) dans le release R25-11, le cluster fonctionnel Safe Hardware Acceleration (shwa) appartient à la catégorie fonctionnelle Safety, conjointement avec Platform Health Management (SWArchitecture p. 127). Contrairement aux services basés sur des démons POSIX système, shwa est architecturé sous la forme d'une bibliothèque intégrée directement dans l'espace d'adressage du processus utilisateur (in-process library), évitant ainsi le coût de communication inter-processus (IPC) pour le calcul intensif (SWArchitecture p. 132). Ce composant standardise l'abstraction de coprocesseurs hétérogènes tels que les unités de calcul graphique (GPU), les processeurs neuronaux (NPU), les processeurs de signaux numériques (DSP) et les matrices prédiffusées programmables (FPGA) (SafeHardwareAccelerationAPI p. 15). Il peut être exploité directement par une Adaptive Application ou par d'autres clusters fonctionnels comme la vision ou la perception ([AP_SWS_SHWA_01103], SafeHardwareAcceleration p. 23).

Diagramme de composants : Architecture en bibliothèque in-process et interfaçage matériel hétérogène de Safe Hardware Acceleration. Sources : SWArchitecture p. 127, SWArchitecture p. 132, SafeHardwareAcceleration p. 22.

Le paradigme de programmation adopté par shwa s'inspire directement des modèles de calcul parallèle modernes tels que SYCL et OpenCL, tout en les contraignant aux exigences strictes de sûreté de fonctionnement (ISO 26262) et de déterminisme de la plateforme adaptative (SafeHardwareAcceleration p. 17). Les constructeurs de toutes les classes principales sont privés et les instanciations s'opèrent exclusivement via des méthodes de fabrique statiques nommées Create() (SafeHardwareAccelerationAPI p. 15). Les classes propriétaires de données encapsulent leurs instances dans des pointeurs uniques std::unique_ptr, tandis que la gestion des retours et anomalies repose systématiquement sur le conteneur ara::core::Result ([AP_SWS_SHWA_00507], SafeHardwareAccelerationAPI p. 15).

Découverte, sélection dynamique et surveillance des accélérateurs

L'exploration de la topologie matérielle s'amorce par l'intermédiaire de la classe ara::shwa::Platform, qui expose la méthode statique GetPlatforms() ainsi que la découverte des dispositifs associés via GetDevices() ([AP_SWS_SHWA_01107], [AP_SWS_SHWA_01108]). Chaque entité physique ou logique est représentée par un objet ara::shwa::Device ([AP_SWS_SHWA_00308]). L'application cliente peut interroger la nature du composant à l'aide des prédicats IsCpu(), IsGpu() et IsAccelerator() ([AP_SWS_SHWA_00310], [AP_SWS_SHWA_00311], [AP_SWS_SHWA_00312]), ou obtenir des métriques et capacités spécialisées via le modèle typé GetInfo<InfoType>() ([AP_SWS_SHWA_00313]).

Pour découpler l'algorithme des cibles matérielles spécifiques, shwa propose un mécanisme de sélection polymorphique fondé sur la classe abstraite ara::shwa::DeviceSelector ([AP_SWS_SHWA_00402]). Cette classe impose l'implémentation de la fonction d'évaluation operator() ainsi que de SelectDevice() ([AP_SWS_SHWA_00403], [AP_SWS_SHWA_00404]). Le standard fournit des sélecteurs spécialisés prêts à l'emploi : GpuSelector ([AP_SWS_SHWA_00406], [AP_SWS_SHWA_00407]), CpuSelector ([AP_SWS_SHWA_00409], [AP_SWS_SHWA_00410]), et AcceleratorSelector ([AP_SWS_SHWA_00412], [AP_SWS_SHWA_00413]). Un sélecteur peut être transmis directement à la fabrique Device::Create(deviceSelector) ([AP_SWS_SHWA_00309]).

La surveillance de l'état opérationnel et de la disponibilité des accélérateurs est déléguée à la classe ara::shwa::DeviceMonitor ([AP_SWS_SHWA_01402]). Instanciée à partir d'un Device ou d'un DeviceSelector ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_01408]), elle permet d'interroger à tout instant le statut du composant via Status() ([AP_SWS_SHWA_01409]). Ce statut est modélisé par l'énumération ara::shwa::DeviceStatus qui distingue l'état prêt (kReady), inaccessible (kNotAccesible), défaillant (kFailure) ou indéterminé (kUnknown) ([AP_SWS_SHWA_00103]).

Diagramme d'états : Machine à états de disponibilité matérielle DeviceStatus supervisée par DeviceMonitor. Sources : [AP_SWS_SHWA_00103], [AP_SWS_SHWA_01409].

Modèle de données : espaces discrets, tampons et accesseurs

La gestion mémoire dans shwa sépare strictement l'allocation physique, la définition des espaces d'indexation géométriques et les droits d'accès en lecture/écriture (SafeHardwareAccelerationAPI p. 15). L'espace géométrique d'itération et d'adressage est formalisé par la classe modèle ara::shwa::Range<Dimensions>, disponible pour 1, 2 ou 3 dimensions ([AP_SWS_SHWA_01007], [AP_SWS_SHWA_01008], [AP_SWS_SHWA_01009]). Les dimensions sous-jacentes sont accessibles via les méthodes d'inspection GetDimension0(), GetDimension1() et GetDimension2() ([AP_SWS_SHWA_01010], [AP_SWS_SHWA_01011], [AP_SWS_SHWA_01012]). Corrélativement, les coordonnées discrètes au sein de ces plages sont modélisées par la classe modèle ara::shwa::Id<Dimensions> ([AP_SWS_SHWA_00707], [AP_SWS_SHWA_00708], [AP_SWS_SHWA_00709]), manipulable au moyen de ses fonctions Get() et Set() ([AP_SWS_SHWA_00710], [AP_SWS_SHWA_00711]).

Le stockage effectif est encapsulé dans ara::shwa::Buffer<DataT, Dimensions, AllocatorT> ([AP_SWS_SHWA_00202]). Ce tampon peut être créé en allouant directement de la mémoire gérée à partir d'un Range et d'un allocateur optionnel ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00210], [AP_SWS_SHWA_00212]), ou en enveloppant un bloc contigu de données préexistantes sur l'hôte (hostData) sous forme constante ou mutable ([AP_SWS_SHWA_00211], [AP_SWS_SHWA_00213], [AP_SWS_SHWA_00214]). Les propriétés spécifiques d'alignement ou de cohérence de bus sont configurées via PropertyList et vérifiables par HasProperty() et GetProperty() ([AP_SWS_SHWA_00215], [AP_SWS_SHWA_00216], [AP_SWS_SHWA_00802]).

Pour sécuriser et contrôler les accès concurrents aux données stockées dans un tampon, le composant requiert l'utilisation d'un ara::shwa::Accessor ([AP_SWS_SHWA_00002]). Un accesseur est instancié pour un contexte hôte ou lié à l'exécution d'un TaskHandler ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00008]). Le mode d'accès est dicté par l'énumération AccessMode qui restreint les opérations à kRead, kWrite ou kReadWrite ([AP_SWS_SHWA_00101]). L'accès aux éléments est garanti par les opérateurs d'indexation operator[] prenant un scalaire ou un Id<Dimensions> ([AP_SWS_SHWA_00009], [AP_SWS_SHWA_00010]), ou par les primitives thread-safe Get() et Set() ([AP_SWS_SHWA_00011], [AP_SWS_SHWA_00012]), le type de référence ReferenceT s'adaptant automatiquement selon la mutabilité accordée ([AP_SWS_SHWA_00014]).

Diagramme de structure de classes : Relations entre Buffer, Accessor, Range et Id pour la gestion sécurisée de données. Sources : SWArchitecture p. 135, SafeHardwareAccelerationAPI p. 15.

Ordonnancement, soumission asynchrone et synchronisation par événements

L'exécution de noyaux de calcul est orchestrée par la file d'attente de commandes ara::shwa::Queue ([AP_SWS_SHWA_00902]). Une Queue est créée en association directe avec un Device ou un DeviceSelector, accompagnée d'un gestionnaire d'erreur obligatoire ErrorHandler et d'une liste de propriétés de configuration PropertyList ([AP_SWS_SHWA_00908], [AP_SWS_SHWA_00909]). Elle permet de retrouver son dispositif cible via GetDevice() ([AP_SWS_SHWA_00910]). La méthode IsInOrder() indique si les tâches soumises doivent s'exécuter strictement selon leur ordre d'arrivée (FIFO) ou si un réordonnancement piloté par graphe de dépendances est toléré ([AP_SWS_SHWA_00911]).

La soumission de travail vers l'accélérateur s'effectue via les méthodes surchargées Submit() ([AP_SWS_SHWA_00912], [AP_SWS_SHWA_00913]). Au sein du foncteur ou de la configuration transmise à Submit(), l'application manipule une instance de ara::shwa::TaskHandler ([AP_SWS_SHWA_01202]) pour qualifier le profil d'exécution : soit une tâche unique séquentielle via SingleTask() ([AP_SWS_SHWA_01203]), soit un traitement massivement parallèle distribué sur un espace d'itération via ParallelFor() ([AP_SWS_SHWA_01204]). La cible d'exécution peut être contrainte sur l'accélérateur (Target::kDevice) ou rapatriée sur le processeur hôte (Target::kHostTask) ([AP_SWS_SHWA_00102]).

Toute soumission renvoie un objet de synchronisation asynchrone ara::shwa::Event ([AP_SWS_SHWA_00602]). Un Event matérialise l'avancement de la tâche sous-jacente et permet de constituer des graphes de dépendances au moyen de GetWaitList() ([AP_SWS_SHWA_00603]). L'application cliente peut bloquer son exécution jusqu'à l'achèvement d'une tâche individuelle via Event::Wait() ([AP_SWS_SHWA_00604]), attendre un ensemble synchronisé de tâches avec la surcharge vectorielle Wait(eventList) ([AP_SWS_SHWA_00605]), ou contraindre la durée maximale d'attente à l'aide de WaitFor(ms) ([AP_SWS_SHWA_00606]). Des fonctions équivalentes de barrière globale sont offertes au niveau de la file avec Queue::Wait() et Queue::WaitFor(ms) ([AP_SWS_SHWA_00914], [AP_SWS_SHWA_00917]).

Diagramme de séquence : Pipeline complet de création, soumission parallèle et synchronisation par événement. Sources : [AP_SWS_SHWA_00908], [AP_SWS_SHWA_00912], [AP_SWS_SHWA_01204], [AP_SWS_SHWA_00604].

Comportement en cas d'erreur et robustesse d'exécution

La gestion des défaillances au sein de shwa concilie le modèle asynchrone des accélérateurs et la politique d'erreurs déterministe d'AUTOSAR Adaptive Platform ([AP_SWS_SHWA_01301]). L'énumération ara::shwa::ShwaErrorCode recense l'ensemble des conditions d'anomalie standardisées : défaillance d'exécution de noyau (kTaskExecutionFailure), saturation ou conflit de ressources (kResourceBusy), échec d'allocation mémoire (kMemoryNotAllocated), corruption de l'intégrité mémoire (kIntegrityCorrupted), mode d'accès invalide (kInvalidAccessMode), manipulation illégale d'accesseur (kAccessorFailure), opération erronée sur les événements (kEventInvalidOperation), ou fonctionnalité non supportée par le pilote matériel (kFeatureNotSupported) ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00016], [AP_SWS_SHWA_00603], [AP_SWS_SHWA_01301]).

Le traitement des erreurs asynchrones survenant sur le matériel déporté est confié à la classe ara::shwa::ErrorHandler ([AP_SWS_SHWA_00502]). Instanciée via Create() en lui fournissant un rappel fonctionnel (std::function<void(ara::core::ErrorCode)>) ([AP_SWS_SHWA_00507]), elle intercepte les signaux de rupture et déclenche la méthode HandleError() ([AP_SWS_SHWA_00508]). Selon les exigences de sûreté applicables, toute interruption ou faute durant l'exécution d'une tâche invalide immédiatement les données associées, qui doivent être considérées comme corrompues de manière non maîtrisée sans garantie de retour en arrière (no rollback semantics) ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00912]).

L'intégration formelle au mécanisme global des domaines d'erreur AUTOSAR est concrétisée par ara::shwa::ShwaErrorDomain ([AP_SWS_SHWA_01307]). Ce domaine fournit l'identifiant textuel via Name() ([AP_SWS_SHWA_01308]), la conversion des codes en messages descriptifs via Message() ([AP_SWS_SHWA_01309]), et la levée d'exceptions C++ typées au travers de ThrowAsException() ([AP_SWS_SHWA_01310]) qui instancie un objet ara::shwa::ShwaException ([AP_SWS_SHWA_01303]). Deux fonctions d'assistance statiques, GetShwaDomain() et MakeErrorCode(), complètent l'interface pour permettre la composition directe d'erreurs au standard ara::core ([AP_SWS_SHWA_01311], [AP_SWS_SHWA_01312]).

Références détaillées et traçabilité

L'implémentation du cluster shwa s'appuie sur un corpus normatif précis articulé entre les spécifications formelles d'architecture et les exigences d'interface applicative :

• Découverte matérielle et sélection : Les exigences fondamentales définissent le modèle d'exploration des plateformes ([AP_SWS_SHWA_01107], [AP_SWS_SHWA_01108]) ainsi que les règles de sélection algorithmique sur GPU, CPU ou accélérateur dédié ([AP_SWS_SHWA_00403], [AP_SWS_SHWA_00407], [AP_SWS_SHWA_00413]).
• Gestion de la mémoire et accesseurs : L'allocation dimensionnelle étanche et les garanties de protection d'accès reposent sur les contrats formels des classes Buffer, Range, Id et Accessor ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00209], [AP_SWS_SHWA_00707], [AP_SWS_SHWA_01007]).
• Exécution asynchrone et files de commandes : Le dispatching des tâches et la synchronisation déterministe via des événements non bloquants ou temporisés sont cadrés par les spécifications de Queue, TaskHandler et Event ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00908], [AP_SWS_SHWA_00912], [AP_SWS_SHWA_01204]).
• Intégrité et sécurité de fonctionnement : La surveillance continue du matériel via DeviceMonitor ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_01409]) et le domaine d'erreur standardisé ShwaErrorDomain ([AP_SWS_SHWA_01301], [AP_SWS_SHWA_01307]) garantissent l'adéquation aux exigences de sûreté ASIL requises par la plateforme adaptative (SWArchitecture p. 127).