módulo ara::shwa — Safe Hardware Acceleration

O cluster adaptativo shwa disponibiliza uma biblioteca local ao processo para o controle funcionalmente seguro de aceleradores computacionais heterogêneos, como GPUs e NPUs (AUTOSAR_AP_EXP_SWArchitecture p. 127). Ele permite a seleção agnóstica de dispositivos das unidades de execução, o gerenciamento de buffers de memória n-dimensionais, bem como o enfileiramento assíncrono de tarefas computacionais paralelas por meio de filas de execução ([AP_SWS_SHWA_00309], [AP_SWS_SHWA_00912]). Em caso de erros de execução de tarefas, não existe semântica de rollback, razão pela qual os dados do buffer afetados são considerados modificados de forma indeterminada ([AP_SWS_SHWA_00604]).

mais ›

O cluster funcional Safe Hardware Acceleration (shwa) disponibiliza para a AUTOSAR Adaptive Platform um modelo de execução padronizado e funcionalmente seguro para unidades computacionais heterogêneas, como GPUs, NPUs, DSPs e FPGAs (AUTOSAR_AP_EXP_SWArchitecture p. 132). Executado como uma biblioteca in-process, o shwa permite que Adaptive Applications, bem como outros clusters funcionais, controlem recursos computacionais de alto desempenho diretamente e sem latência (AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 23).

Plataformas de hardware e dispositivos-alvo são abstraídos via Platform e Device ([AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308]). Por meio de classes de estratégia como GpuSelector ou AcceleratorSelector, as aplicações podem selecionar alvos computacionais adequados de forma flexível ([AP_SWS_SHWA_00407], [AP_SWS_SHWA_00413]). Buffers de dados são alocados via Buffer em espaços de índices N-dimensionais (Range), enquanto acessos estruturados de leitura e gravação ocorrem de forma type-safe através de Accessor e Id ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_00707]).

Diagrama de sequência: Fluxo de ponta a ponta de alocação de buffer, submissão de kernel (Submit) e sincronização assíncrona. Fontes: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Ordens de cálculo são definidas via TaskHandler como tarefa individual ou laço paralelo e transmitidas ao dispositivo através de filas (Queue) ([AP_SWS_SHWA_01203], [AP_SWS_SHWA_00912]). O retorno fornece um objeto Event para sincronizações bloqueantes ou com limite de tempo ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00606]). Para o monitoramento em tempo de execução, utiliza-se DeviceMonitor, que mapeia o estado atual do hardware (kReady, kNotAccesible, kFailure, kUnknown) ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103]).

Erros são reportados de forma determinística via ara::core::Result e ShwaErrorCode ([AP_SWS_SHWA_01301]). Se a execução de uma tarefa falhar, as operações não possuem semântica de rollback, de modo que os buffers vinculados devem ser classificados como indeterminadamente modificados ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]).

mais ›

Papel arquitetural e limites de sistema de Safe Hardware Acceleration

O cluster funcional Safe Hardware Acceleration (shwa) fornece, dentro da AUTOSAR Adaptive Platform, um modelo padronizado e funcionalmente seguro de execução e abstração para unidades computacionais heterogêneas, como GPUs, DSPs, NPUs e FPGAs (AUTOSAR_AP_EXP_SWArchitecture p. 132). Ao contrário de clusters de plataforma baseados em daemon, como o Platform Health Management, o shwa é concebido como uma biblioteca local ao processo (biblioteca in-process), não baseada em daemon (AUTOSAR_AP_EXP_SWArchitecture p. 127). Com isso, o ambiente de tempo de execução atua diretamente no espaço de endereçamento POSIX do processo de usuário consumidor e desacopla tarefas de computação dos drivers de aceleradores subjacentes sem latências de IPC (AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

O design arquitetural de interface orienta-se por padrões modernos de computação heterogênea, como SYCL e OpenCL, mas adapta estritamente esses paradigmas aos requisitos determinísticos e voltados à segurança da AUTOSAR Adaptive Platform (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Os construtores de todas as classes de interface primárias são declarados privados; instâncias podem ser criadas exclusivamente por meio de métodos factory estáticos nomeados do tipo Create() (EXP_SafeHardwareAccelerationAPI p. 15). Quase todas as operações sinalizam seu sucesso ou estados de erro específicos do sistema através do tipo de retorno ara::core::Result ([AP_SWS_SHWA_00308], EXP_SafeHardwareAccelerationAPI p. 15). Além de Adaptive Applications regulares, outros clusters funcionais (como clusters de processamento de imagem ou percepção) também podem integrar diretamente as interfaces C++ de shwa para workloads de HPC altamente paralelas (SWS_SafeHardwareAcceleration p. 23).

Diagrama de contexto: Incorporação de ara::shwa como biblioteca in-process no espaço de processo POSIX para controle de aceleradores heterogêneos. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 127, SWS_SafeHardwareAcceleration p. 22.

Topologia de hardware, detecção de plataforma e seleção de dispositivos

A topologia dos aceleradores computacionais integrados em todo o sistema é abstraída através da interface Platform ([AP_SWS_SHWA_01107]). Por meio da operação estática Platform::GetPlatforms(), a aplicação identifica inicialmente todas as plataformas de execução registradas e, em seguida, consulta as unidades computacionais atribuídas a cada uma por meio de Platform::GetDevices() ([AP_SWS_SHWA_01108], AUTOSAR_AP_EXP_SWArchitecture p. 132). Cada destino de execução físico ou lógico é representado no sistema por um objeto Device ([AP_SWS_SHWA_00302]). Um Device oferece métodos de inspeção para classificar o tipo de hardware, incluindo IsCpu() ([AP_SWS_SHWA_00310]), IsGpu() ([AP_SWS_SHWA_00311]) e IsAccelerator() ([AP_SWS_SHWA_00312]), bem como consultas genéricas detalhadas através do template de função GetInfo() ([AP_SWS_SHWA_00313]).

Para a seleção direcionada de unidades computacionais adequadas, shwa disponibiliza o padrão de seleção polimórfico DeviceSelector ([AP_SWS_SHWA_00402], [AP_SWS_SHWA_00403]). Através das implementações padrão GpuSelector ([AP_SWS_SHWA_00406], [AP_SWS_SHWA_00407]), CpuSelector ([AP_SWS_SHWA_00409], [AP_SWS_SHWA_00410]) e AcceleratorSelector ([AP_SWS_SHWA_00412], [AP_SWS_SHWA_00413]), os sistemas podem filtrar alvos computacionais de acordo com prioridades predefinidas ou avaliações heurísticas de adequação. O método factory Device::Create(deviceSelector) vincula esse mecanismo de seleção diretamente à instanciação do dispositivo ([AP_SWS_SHWA_00309]).

Diagrama de sequência: Determinação de topologia, seleção de um alvo computacional e instanciação de um dispositivo lógico. Fontes: AP_SWS_SHWA_01107, AP_SWS_SHWA_01108, AP_SWS_SHWA_00407, AP_SWS_SHWA_00309.

Gerenciamento de memória e acesso multidimensional a dados com Buffer e Accessor

Para operações de computação paralela em arquiteturas heterogêneas, shwa separa rigorosamente o armazenamento físico de dados do acesso lógico (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15). Áreas de memória são encapsuladas através do template Buffer<DataT, Dimensions, AllocatorT> ([AP_SWS_SHWA_00202]). A extensão de uma memória no espaço unidimensional, bidimensional ou tridimensional é especificada pela estrutura Range<Dimensions> ([AP_SWS_SHWA_01007], [AP_SWS_SHWA_01008], [AP_SWS_SHWA_01009]), cujas dimensões podem ser consultadas via GetDimension0(), GetDimension1() e GetDimension2() ([AP_SWS_SHWA_01010], [AP_SWS_SHWA_01011], [AP_SWS_SHWA_01012]). Um buffer pode ser recém-criado com memória própria ou alocador ([AP_SWS_SHWA_00209], [AP_SWS_SHWA_00210]), ou vincular ponteiros de memória do host existentes (hostData) como dados de entrada ou saída ([AP_SWS_SHWA_00211], [AP_SWS_SHWA_00213], [AP_SWS_SHWA_00214]). Buffers proprietários são tipicamente retornados por Buffer::Create() como std::unique_ptr (EXP_SafeHardwareAccelerationAPI p. 15).

O acesso real de leitura e gravação a dados do buffer não é realizado diretamente por ponteiros, mas sim por meio de objetos tipados Accessor ([AP_SWS_SHWA_00007], [AP_SWS_SHWA_00008]). O modo de acesso é determinado pelo enum AccessMode, que compreende as variantes kRead, kWrite e kReadWrite ([AP_SWS_SHWA_00101]). O endereçamento de pontos de índice discretos no espaço N-dimensional ocorre por meio do tipo Id<Dimensions> ([AP_SWS_SHWA_00707], [AP_SWS_SHWA_00708], [AP_SWS_SHWA_00709]) com os respectivos getters e setters de coordenadas ([AP_SWS_SHWA_00710], [AP_SWS_SHWA_00711]). Para manipular elementos individuais de matrizes, Accessor fornece o operador de índice operator[] ([AP_SWS_SHWA_00009], [AP_SWS_SHWA_00010]), bem como os métodos sincronizantes Get() ([AP_SWS_SHWA_00012]) e Set() ([AP_SWS_SHWA_00011]). Ao fornecer instâncias de PropertyList, propriedades de memória e atributos de acesso específicos podem ser anexados declarativamente ([AP_SWS_SHWA_00802], [AP_SWS_SHWA_00015], [AP_SWS_SHWA_00215]).

Definição de tarefas, agendamento de ordens e execução através de filas

A execução de cálculos em dispositivos aceleradores é coordenada por meio de filas de comandos do tipo Queue ([AP_SWS_SHWA_00902]). Uma Queue é vinculada através de seu método factory Create() a um Device específico ou a um DeviceSelector e configurada opcionalmente com um ErrorHandler, bem como uma PropertyList ([AP_SWS_SHWA_00908], [AP_SWS_SHWA_00909]). O método GetDevice() retorna o dispositivo computacional acoplado à fila ([AP_SWS_SHWA_00910]). O comportamento de execução da fila pode ser verificado através de IsInOrder() ([AP_SWS_SHWA_00911]): em uma fila in-order, as tarefas computacionais enfileiradas são processadas estritamente de forma sequencial (AUTOSAR_AP_EXP_SWArchitecture p. 133).

A definição de cargas de trabalho concretas é realizada com o auxílio de TaskHandler ([AP_SWS_SHWA_01202]). O manipulador de tarefas distingue entre tarefas atômicas individuais (SingleTask(), [AP_SWS_SHWA_01203]) e grades computacionais paralelas de dados (ParallelFor(), [AP_SWS_SHWA_01204]). O destino da execução pode ser definido através da enumeração Target como um acelerador (kDevice) ou como uma tarefa de host de CPU (kHostTask) ([AP_SWS_SHWA_00102]). A submissão à fila ocorre por meio do método Queue::Submit() ([AP_SWS_SHWA_00912]). Em pipelines mais complexos, Submit() também suporta a especificação de uma fila secundária para mapear dependências entre diferentes pipelines de hardware ([AP_SWS_SHWA_00913], AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23).

Diagrama de sequência: Fluxo de ponta a ponta de alocação de buffer, submissão de kernel (Submit) e sincronização assíncrona. Fontes: AP_SWS_SHWA_00209, AP_SWS_SHWA_00909, AP_SWS_SHWA_00912, AP_SWS_SHWA_00604.

Sincronização baseada em eventos e monitoramento de estado de hardware

Cada submissão via Queue::Submit() retorna um objeto Event, que serve como uma âncora de sincronização assíncrona ([AP_SWS_SHWA_00912], [AP_SWS_SHWA_00602]). Um chamador pode aguardar a conclusão do cálculo de hardware de forma bloqueante por meio de Event::Wait() ([AP_SWS_SHWA_00604]) ou realizar uma sincronização com tempo limitado via WaitFor(ms) ([AP_SWS_SHWA_00606]). Vários eventos podem ser monitorados de forma agregada via Event::Wait(const Vector<Event>&) ([AP_SWS_SHWA_00605]). Alternativamente, a própria fila oferece métodos de sincronização coletiva: Queue::Wait() bloqueia até que todas as tarefas anteriormente enfileiradas tenham sido processadas ([AP_SWS_SHWA_00914]), enquanto Queue::WaitFor(ms) limita a espera a um timeout predefinido ([AP_SWS_SHWA_00917]).

Para garantir a confiabilidade e a segurança funcional dos aceleradores de hardware em tempo de execução, shwa define o componente de monitoramento DeviceMonitor ([AP_SWS_SHWA_01402]). As instâncias são criadas por meio de métodos Create() estáticos referenciando um Device ou um DeviceSelector ([AP_SWS_SHWA_01407], [AP_SWS_SHWA_01408]). Por meio do método DeviceMonitor::Status(), consulta-se o estado atual do hardware ([AP_SWS_SHWA_01409]). A enumeração DeviceStatus abrange quatro estados padronizados: kReady (0, operacional), kNotAccesible (1, inacessível), kFailure (2, estado de erro) e kUnknown (255, status não determinável) ([AP_SWS_SHWA_00103]). Esse mecanismo de monitoramento forma a base para análises de segurança e health-monitoring de acordo com a ISO 26262 (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).

Diagrama de estados: ciclo de vida e transições de estado do DeviceStatus conforme ara::shwa::DeviceMonitor. Fontes: AP_SWS_SHWA_00103, AP_SWS_SHWA_01409.

Comportamento em caso de falha e diagnóstico

O conceito de tratamento de erros de shwa baseia-se no domínio de erro específico do AUTOSAR ShwaErrorDomain ([AP_SWS_SHWA_01307]), que pode ser obtido por meio de GetShwaDomain() ([AP_SWS_SHWA_01311]). Códigos de erro específicos são mapeados pela enumeração padronizada ShwaErrorCode ([AP_SWS_SHWA_01301]). Entre eles estão erros fundamentais de tempo de execução como kRuntime, interrupções de cálculo no acelerador como kTaskExecutionFailure, erros de alocação de memória como kMemoryNotAllocated, violações da integridade de memória como kIntegrityCorrupted, conflitos temporários de recursos como kResourceBusy e modos de acesso inválidos como kInvalidAccessMode ([AP_SWS_SHWA_01301]). Os códigos de erro são construídos com segurança de tipos através de MakeErrorCode() ([AP_SWS_SHWA_01312]) e fornecem descrições textuais por meio de Name() e Message() ([AP_SWS_SHWA_01308], [AP_SWS_SHWA_01309]).

Erros na execução assíncrona ou na espera por eventos (Event::Wait() ou Queue::Wait()) têm impactos graves na consistência dos dados: se ocorrer um kTaskExecutionFailure ou kRuntime durante o cálculo, as operações afetadas não possuem semântica de rollback e os dados nos buffers vinculados são considerados modificados de forma indeterminada ([AP_SWS_SHWA_00604], [AP_SWS_SHWA_00914]). Para notificações assíncronas, utiliza-se a classe ErrorHandler, cujo callback é disparado por meio de HandleError() ([AP_SWS_SHWA_00507], [AP_SWS_SHWA_00508]). Caso a aplicação exija tratamento de exceções, os erros podem ser convertidos em uma ShwaException via ThrowAsException() ([AP_SWS_SHWA_01303], [AP_SWS_SHWA_01310]).

Evidências detalhadas complementares e referências de especificação

A arquitetura e os requisitos do cluster shwa são totalmente respaldados por requisitos normativos e pelos documentos explicativos correspondentes. A Tabela 1 resume os conceitos centrais e suas principais fontes de referência.

Área temática	Elementos importantes da especificação	Fontes de referência
Arquitetura & disponibilização	Biblioteca in-process, classificação funcional na categoria Safety	AUTOSAR_AP_EXP_SWArchitecture S. 127, AUTOSAR_AP_EXP_SWArchitecture S. 132
Topologia & seleção	Platform, Device, DeviceSelector, GpuSelector, CpuSelector	[AP_SWS_SHWA_01107], [AP_SWS_SHWA_00308], [AP_SWS_SHWA_00403]
Memória & acesso a dados	Buffer, Accessor, Range, Id, AccessMode	[AP_SWS_SHWA_00209], [AP_SWS_SHWA_00007], [AP_SWS_SHWA_01007], [AP_SWS_SHWA_00101]
Planejamento de tarefas & sincronização	Queue, TaskHandler, Event	[AP_SWS_SHWA_00908], [AP_SWS_SHWA_01202], [AP_SWS_SHWA_00604]
Monitoramento de hardware & erros	DeviceMonitor, DeviceStatus, ShwaErrorCode, ErrorHandler	[AP_SWS_SHWA_01407], [AP_SWS_SHWA_00103], [AP_SWS_SHWA_01301], [AP_SWS_SHWA_00507]

A instanciação típica do pipeline e o desacoplamento de múltiplas filas dentro de uma aplicação são ilustrados detalhadamente na especificação (SWS_SafeHardwareAcceleration p. 22, AUTOSAR_AP_SWS_SafeHardwareAcceleration p. 23). A separação rigorosa de recursos de memória e computação garante, com isso, um comportamento determinístico em áreas de aplicação automotiva críticas para a segurança (AUTOSAR_AP_EXP_SafeHardwareAccelerationAPI p. 15).