módulo ara::shwa — Safe Hardware Acceleration

El clúster adaptativo shwa proporciona una biblioteca local al proceso para el control funcionalmente seguro de aceleradores de cómputo heterogéneos como GPU y NPU (AUTOSAR_AP_EXP_SWArchitecture p. 127). Permite la selección agnóstica del dispositivo para las unidades de ejecución, la gestión de búferes de memoria n-dimensionales, así como el encolado asíncrono de tareas de cómputo paralelas mediante colas de ejecución ([AP_SWS_SHWA_00309], [AP_SWS_SHWA_00912]). En caso de errores de ejecución de tareas no existe semántica de reversión (rollback), por lo que los datos del búfer afectados se consideran modificados de forma indeterminada ([AP_SWS_SHWA_00604]).

más ›

El clúster funcional Safe Hardware Acceleration (shwa) proporciona para la AUTOSAR Adaptive Platform un modelo de ejecución estandarizado y funcionalmente seguro para unidades de cómputo heterogéneas como GPU, NPU, DSP y FPGA (AUTOSAR_AP_EXP_SWArchitecture p. 132). Implementado como biblioteca dentro del proceso (in-process), shwa permite a las Adaptive Applications y a otros clústeres funcionales el control directo y sin latencia de recursos de cómputo de alto rendimiento (AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 23).

Las plataformas de hardware y los dispositivos de destino se abstraen mediante Platform y Device ([AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308]). Mediante clases de estrategia como GpuSelector o AcceleratorSelector, las aplicaciones pueden seleccionar de forma flexible destinos de cómputo adecuados ([AP_SWS_SHWA_00407], [AP_SWS_SHWA_00413]). Los búferes de datos se asignan mediante Buffer en espacios de índices N-dimensionales (Range), mientras que los accesos estructurados de lectura y escritura se realizan con seguridad de tipos mediante Accessor y Id ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_00707]).

Diagrama de secuencia: flujo de extremo a extremo de asignación de búfer, envío de kernel (submit) y sincronización asíncrona. Fuentes: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Las órdenes de cálculo se definen mediante TaskHandler como tarea única o bucle paralelo y se transmiten al dispositivo mediante colas (Queue) ([AP_SWS_SHWA_01203], [AP_SWS_SHWA_00912]). El retorno proporciona un objeto Event para sincronizaciones bloqueantes o con límite de tiempo ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00606]). Para la supervisión en tiempo de ejecución se utiliza DeviceMonitor, que refleja el estado actual del hardware (kReady, kNotAccesible, kFailure, kUnknown) ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103]).

Los errores se notifican de forma determinista mediante ara::core::Result y ShwaErrorCode ([AP_SWS_SHWA_01301]). Si falla la ejecución de una tarea, las operaciones no poseen semántica de reversión (rollback), por lo que los búferes vinculados deben clasificarse como modificados de forma indeterminada ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]).

más ›

Rol arquitectónico y límites del sistema de Safe Hardware Acceleration

El clúster funcional Safe Hardware Acceleration (shwa) proporciona dentro de la AUTOSAR Adaptive Platform un modelo de ejecución y abstracción estandarizado y funcionalmente seguro para unidades de cómputo heterogéneas como GPU, DSP, NPU y FPGA (AUTOSAR_AP_EXP_SWArchitecture p. 132). A diferencia de los clústeres de plataforma basados en demonios como Platform Health Management, shwa está concebido como una biblioteca local al proceso no basada en demonios (biblioteca in-process) (AUTOSAR_AP_EXP_SWArchitecture p. 127). De este modo, el entorno de tiempo de ejecución actúa directamente en el espacio de direcciones POSIX del proceso de usuario consumidor y desacopla las órdenes de cálculo de los controladores de acelerador subyacentes sin latencias de IPC (AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

El diseño arquitectónico de la interfaz se orienta a los estándares modernos de computación heterogénea como SYCL y OpenCL, pero adapta estrictamente estos paradigmas a los requisitos deterministas y orientados a la seguridad de la AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Los constructores de todas las clases de interfaz primarias están declarados como privados; las instancias solo pueden crearse mediante métodos de fábrica estáticos con nombre del tipo Create() (EXP_SafeHardwareAccelerationAPI p. 15). Prácticamente todas las operaciones señalizan su éxito o estados de error específicos del sistema mediante el tipo de retorno ara::core::Result ([AP_SWS_SHWA_00308], EXP_SafeHardwareAccelerationAPI p. 15). Además de las Adaptive Applications ordinarias, otros clústeres funcionales (por ejemplo, clústeres de procesamiento de imágenes o de percepción) también pueden integrar directamente las interfaces C++ de shwa para cargas de trabajo HPC altamente paralelas (SWS_SafeHardwareAcceleration p. 23).

Diagrama de contexto: integración de ara::shwa como biblioteca in-process en el espacio de proceso POSIX para el control de aceleradores heterogéneos. Fuentes: AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 22.

Topología de hardware, determinación de plataformas y selección de dispositivos

La topología de los aceleradores de cómputo integrados en el sistema global se abstrae mediante la interfaz Platform ([AP_SWS_SHWA_01107]). A través de la operación estática Platform::GetPlatforms(), la aplicación determina primero todas las plataformas de ejecución registradas y, a continuación, consulta mediante Platform::GetDevices() las unidades de cómputo asignadas en cada caso ([AP_SWS_SHWA_01108], AUTOSAR_AP_EXP_SWArchitecture p. 132). Cada destino de ejecución físico o lógico se representa en el sistema mediante un objeto Device ([AP_SWS_SHWA_00302]). Un Device ofrece métodos de inspección para clasificar el tipo de hardware, entre ellos IsCpu() ([AP_SWS_SHWA_00310]), IsGpu() ([AP_SWS_SHWA_00311]) y IsAccelerator() ([AP_SWS_SHWA_00312]), así como consultas genéricas de detalles a través de la plantilla de función GetInfo() ([AP_SWS_SHWA_00313]).

Para la selección selectiva de unidades de cómputo adecuadas, shwa proporciona el patrón de selección polimórfico DeviceSelector ([AP_SWS_SHWA_00402], [AP_SWS_SHWA_00403]). A través de las implementaciones estándar GpuSelector ([AP_SWS_SHWA_00406], [AP_SWS_SHWA_00407]), CpuSelector ([AP_SWS_SHWA_00409], [AP_SWS_SHWA_00410]) y AcceleratorSelector ([AP_SWS_SHWA_00412], [AP_SWS_SHWA_00413]), los sistemas pueden filtrar destinos de cálculo según prioridades predefinidas o evaluaciones heurísticas de idoneidad. El método de fábrica Device::Create(deviceSelector) vincula este mecanismo de selección directamente a la instanciación de dispositivos ([AP_SWS_SHWA_00309]).

Diagrama de secuencia: determinación de la topología, selección de un destino de cálculo e instanciación de un Device lógico. Fuentes: AP_SWS_SHWA_01107, AP_SWS_SHWA_01108, AP_SWS_SHWA_00407, AP_SWS_SHWA_00309.

Gestión de memoria y acceso a datos multidimensional con Buffer y Accessor

Para operaciones de cálculo paralelas en arquitecturas heterogéneas, shwa separa estrictamente el almacenamiento físico de datos del acceso lógico (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Las áreas de memoria se encapsulan mediante la plantilla Buffer<DataT, Dimensions, AllocatorT> ([AP_SWS_SHWA_00202]). La extensión de una memoria en el espacio unidimensional, bidimensional o tridimensional viene especificada por la estructura Range<Dimensions> ([AP_SWS_SHWA_01007], [AP_SWS_SHWA_01008], [AP_SWS_SHWA_01009]), cuyas dimensiones pueden consultarse mediante GetDimension0(), GetDimension1() y GetDimension2() ([AP_SWS_SHWA_01010], [AP_SWS_SHWA_01011], [AP_SWS_SHWA_01012]). Un búfer puede crearse de nuevo con memoria propia o asignador propio ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00210]), o bien integrar punteros de memoria de host existentes (hostData) como datos de entrada o salida ([AP_SWS_SHWA_00211], [AP_SWS_SHWA_00213], [AP_SWS_SHWA_00214]). Buffer::Create() suele devolver los búferes con posesión en forma de std::unique_ptr (EXP_SafeHardwareAccelerationAPI p. 15).

El acceso real de lectura y escritura a los datos del búfer no se realiza directamente mediante punteros, sino a través de objetos Accessor tipados ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00008]). El modo de acceso se determina mediante el enum AccessMode, que incluye las variantes kRead, kWrite y kReadWrite ([AP_SWS_SHWA_00101]). El direccionamiento de puntos de índice discretos en el espacio N-dimensional se realiza mediante el tipo Id<Dimensions> ([AP_SWS_SHWA_00707], [AP_SWS_SHWA_00708], [AP_SWS_SHWA_00709]) con los correspondientes métodos getter y setter de coordenadas ([AP_SWS_SHWA_00710], [AP_SWS_SHWA_00711]). Para la manipulación de elementos individuales del arreglo, Accessor proporciona el operador de indexación operator[] ([AP_SWS_SHWA_00009], [AP_SWS_SHWA_00010]), así como los métodos sincronizadores Get() ([AP_SWS_SHWA_00012]) y Set() ([AP_SWS_SHWA_00011]). Al transferir instancias de PropertyList, se pueden adjuntar de forma declarativa propiedades de almacenamiento y atributos de acceso específicos ([AP_SWS_SHWA_00802], [AP_SWS_SHWA_00015], [AP_SWS_SHWA_00215]).

Definición de tareas, planificación de órdenes y ejecución mediante colas

La ejecución de cálculos en dispositivos aceleradores se coordina mediante colas de comandos del tipo Queue ([AP_SWS_SHWA_00902]). Una Queue se vincula a un Device o un DeviceSelector específico mediante su método de fábrica Create() y se configura opcionalmente con un ErrorHandler, así como una PropertyList ([AP_SWS_SHWA_00908], [AP_SWS_SHWA_00909]). El método GetDevice() devuelve el dispositivo de cómputo acoplado a la cola ([AP_SWS_SHWA_00910]). El comportamiento de ejecución de la cola puede comprobarse mediante IsInOrder() ([AP_SWS_SHWA_00911]): en una cola in-order, las tareas de cálculo encoladas se procesan de forma estrictamente secuencial (AUTOSAR_AP_EXP_SWArchitecture p. 133).

La definición de cargas de trabajo concretas se realiza con ayuda de TaskHandler ([AP_SWS_SHWA_01202]). El gestor de tareas distingue entre tareas individuales atómicas (SingleTask(), [AP_SWS_SHWA_01203]) y mallas de cálculo con paralelismo de datos (ParallelFor(), [AP_SWS_SHWA_01204]). El destino de la ejecución puede definirse a través de la enumeración Target como un acelerador (kDevice) o como una tarea de host de CPU (kHostTask) ([AP_SWS_SHWA_00102]). El envío a la cola se realiza mediante el método Queue::Submit() ([AP_SWS_SHWA_00912]). En tuberías más complejas, Submit() también admite la especificación de una cola secundaria para modelar dependencias entre diferentes tuberías de hardware ([AP_SWS_SHWA_00913], AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

Diagrama de secuencia: flujo de extremo a extremo de asignación de búfer, envío de kernel (submit) y sincronización asíncrona. Fuentes: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Sincronización basada en eventos y supervisión del estado del hardware

Cada envío a través de Queue::Submit() devuelve un objeto Event que actúa como ancla de sincronización asíncrona ([AP_SWS_SHWA_00912], [AP_SWS_SHWA_00602]). El invocador puede esperar a que finalice el cálculo del hardware de forma bloqueante mediante Event::Wait() ([AP_SWS_SHWA_00604]) o bien realizar una sincronización con límite de tiempo a través de WaitFor(ms) ([AP_SWS_SHWA_00606]). Múltiples eventos pueden supervisarse de forma agregada mediante Event::Wait(const Vector<Event>&) ([AP_SWS_SHWA_00605]). Alternativamente, la propia cola ofrece métodos de sincronización colectiva: Queue::Wait() se bloquea hasta que se hayan procesado todas las tareas encoladas hasta el momento ([AP_SWS_SHWA_00914]), mientras que Queue::WaitFor(ms) limita la espera a un tiempo de espera especificado ([AP_SWS_SHWA_00917]).

Para garantizar la fiabilidad y la seguridad funcional de los aceleradores de hardware en tiempo de ejecución, shwa define el componente de monitorización DeviceMonitor ([AP_SWS_SHWA_01402]). Las instancias se generan mediante métodos estáticos de Create() referidos a un Device o un DeviceSelector ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_01408]). Mediante el método DeviceMonitor::Status() se consulta el estado actual del hardware ([AP_SWS_SHWA_01409]). La enumeración DeviceStatus abarca cuatro estados estandarizados: kReady (0, listo para el funcionamiento), kNotAccesible (1, no accesible), kFailure (2, estado de error) y kUnknown (255, estado no determinable) ([AP_SWS_SHWA_00103]). Este mecanismo de monitorización constituye la base para análisis de seguridad y Health-Monitoring conforme a ISO 26262 (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).

Diagrama de estados: ciclo de vida y transiciones de estado del DeviceStatus según ara::shwa::DeviceMonitor. Fuentes: AP_SWS_SHWA_00103, AP_SWS_SHWA_01409.

Comportamiento en caso de error y diagnóstico

El concepto de tratamiento de errores de shwa se basa en el dominio de errores específico de AUTOSAR ShwaErrorDomain ([AP_SWS_SHWA_01307]), que puede obtenerse a través de GetShwaDomain() ([AP_SWS_SHWA_01311]). Los códigos de error específicos se representan mediante la enumeración estandarizada ShwaErrorCode ([AP_SWS_SHWA_01301]). Entre ellos se incluyen errores fundamentales en tiempo de ejecución como kRuntime, cancelaciones de cómputo en el acelerador como kTaskExecutionFailure, errores de asignación de memoria como kMemoryNotAllocated, violaciones de la integridad de la memoria como kIntegrityCorrupted, conflictos temporales de recursos como kResourceBusy y modos de acceso no válidos como kInvalidAccessMode ([AP_SWS_SHWA_01301]). Los códigos de error se construyen con seguridad de tipos mediante MakeErrorCode() ([AP_SWS_SHWA_01312]) y proporcionan descripciones textuales a través de Name() y Message() ([AP_SWS_SHWA_01308], [AP_SWS_SHWA_01309]).

Los errores durante la ejecución asíncrona o al esperar eventos (Event::Wait() o Queue::Wait()) tienen graves consecuencias en la consistencia de los datos: si durante el cómputo se produce un kTaskExecutionFailure o kRuntime, las operaciones afectadas no disponen de semántica de rollback y los datos en los búferes vinculados se consideran modificados de forma indeterminada ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]). Para notificaciones asíncronas se utiliza la clase ErrorHandler, cuya callback se dispara mediante HandleError() ([AP_SWS_SHWA_00507], [AP_SWS_SHWA_00508]). En caso de que la aplicación requiera tratamiento de excepciones, los errores pueden convertirse mediante ThrowAsException() en una ShwaException ([AP_SWS_SHWA_01303], [AP_SWS_SHWA_01310]).

Justificaciones detalladas adicionales y referencias a especificaciones

La arquitectura y los requisitos del clúster shwa están totalmente respaldados por requisitos normativos y documentos explicativos asociados. La tabla 1 resume los conceptos clave y sus fuentes determinantes.

Área temática	Elementos importantes de la especificación	Fuentes de referencia
Arquitectura y suministro	Biblioteca in-process, clasificación funcional en categoría Safety	AUTOSAR_AP_EXP_SWArchitecture S. 127, AUTOSAR_AP_EXP_SWArchitecture S. 132
Topología y selección	Platform, Device, DeviceSelector, GpuSelector, CpuSelector	[AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308], [AP_SWS_SHWA_00403]
Memoria y acceso a datos	Buffer, Accessor, Range, Id, AccessMode	[AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_01007], [AP_SWS_SHWA_00101]
Planificación de tareas y sincronización	Queue, TaskHandler, Event	[AP_SWS_SHWA_00908], [AP_SWS_SHWA_01202], [AP_SWS_SHWA_00604]
Monitorización de hardware y errores	DeviceMonitor, DeviceStatus, ShwaErrorCode, ErrorHandler	[AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103], [AP_SWS_SHWA_01301], [AP_SWS_SHWA_00507]

La instanciación típica de canalizaciones y el desacoplamiento de múltiples colas dentro de una aplicación se ilustran en detalle en la especificación (SWS_SafeHardwareAcceleration p. 22, AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23). La estricta separación de los recursos de memoria y de cómputo garantiza al mismo tiempo un comportamiento determinista en campos de aplicación del sector del automóvil críticos para la seguridad (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).