módulo ara::com — Communication Management

O Functional Cluster Communication Management (ara::com) permite a interação orientada a serviços entre aplicações Adaptive através de interfaces padronizadas de proxy e skeleton (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). Regula a descoberta dinâmica de serviços através de OfferService() e FindService() ([SWS_CM_00101], [SWS_CM_00122]) e disponibiliza métodos síncronos e assíncronos, events e fields com proteção integrada de E2E e SecOC ([SWS_CM_00141], [SWS_CM_90420]). Em caso de perda temporária de um serviço, o middleware interceta interrupções de ligação e atualiza automaticamente os objetos proxy existentes após a sua nova disponibilização (ARAComAPI p. 32).

mais ›

O Functional Cluster Communication Management (ara::com) constitui a espinha dorsal da arquitetura orientada a serviços (SOA) na AUTOSAR Adaptive Platform e desacopla a lógica aplicacional de protocolos de transmissão concretos através do padrão proxy-skeleton (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). Classes de proxy geradas no lado do consumidor e classes de skeleton no lado do fornecedor, a partir de descrições formais de interfaces, disponibilizam métodos, events e fields através de APIs C++ com segurança de tipos ([SWS_CM_00130], [SWS_CM_00131]).

A disponibilização e pesquisa dinâmica de serviços são processadas através de Service Discovery (SWS_CommunicationManagement p. 67). Um fornecedor oferece o seu serviço através de OfferService() ([SWS_CM_00101]), enquanto os consumidores determinam instâncias compatíveis de forma síncrona via FindService() ou de forma assíncrona através de StartFindService() ([SWS_CM_00122], [SWS_CM_00123]). Neste processo, as instâncias podem ser endereçadas com base em modelos através de ara::core::InstanceSpecifier e resolvidas em ara::com::InstanceIdentifier concretos em tempo de execução ([SWS_CM_00118], [SWS_CM_00622]).

Diagrama de sequência: sequência de Service Offering, pesquisa assíncrona e criação de proxy. Fontes: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

Para a transmissão de dados, ara::com suporta métodos de pedido-resposta através de ara::core::Future ([SWS_CM_00191], [SWS_CM_00196]), bem como padrões publish-subscribe para events e fields (AUTOSAR_EXP_ARAComAPI p. 68). Os subscritores registam-se através de Subscribe() ([SWS_CM_00141]) e leem dados recebidos através de GetNewSamples() ([SWS_CM_00701]). Para aumento de desempenho, o fornecedor disponibiliza dados através de Allocate() e transfere a titularidade por zero-copy via Send() ([SWS_CM_90437], [SWS_CM_90438]).

Para proteger a transmissão, a plataforma integra proteção ponta a ponta (E2E), autenticação criptográfica (SecOC) através de Freshness Value Management (FVM), bem como Signal-to-Service-Translation para redes clássicas ([SWS_CM_90420], [SWS_CM_11288], [SWS_CM_10174], SWS_CommunicationManagement p. 222). Estados de erro são sinalizados de forma padronizada através de domínios de erro com segurança de tipos, tais como ComErrorDomain e ComE2EErrorDomain ([SWS_CM_10432], [SWS_CM_10474]). Caso a conexão a um serviço seja interrompida, o estado do proxy muda para kSubscriptionPending; após nova disponibilização, o middleware atualiza o endereçamento interno de forma transparente, de modo que a comunicação seja prosseguida sem reinstanciação do proxy (ARAComAPI p. 32).

mais ›

Papel e arquitetura de sistema da comunicação orientada a serviços

O Functional Cluster Communication Management (ara::com) forma a espinha dorsal de tecnologia da informação da AUTOSAR Adaptive Platform e realiza a comunicação orientada a serviços (Service-Oriented Architecture, SOA) entre processos de aplicação isolados, bem como através de limites de ECUs (SWS_CommunicationManagement p. 55). O princípio central é o padrão de projeto estrito proxy-skeleton (ARAComAPI p. 1): a partir de descrições formais de interfaces de software (Service Interfaces), um gerador de código baseado em modelos gera classes de proxy tipadas para consumidores de serviço e classes de skeleton para provedores de serviço ([SWS_CM_00130], [SWS_CM_00131]). A lógica da aplicação interage exclusivamente com essas abstrações, enquanto bindings específicos de protocolo, como SOME/IP, IPC ou DDS, bem como a sua serialização, só são vinculados no momento de integração e deployment (AUTOSAR_AP_EXP_ARAComAPI p. 124).

Para satisfazer os requisitos da plataforma, o ara::com coopera estreitamente com outros clusters funcionais (SWS_CommunicationManagement p. 34). Em tempo de execução, o Execution Management monitora o ciclo de vida dos processos, enquanto o Identity and Access Management (IAM) bloqueia interações não autorizadas nos níveis de Method, Event e Field através de verificações de acesso baseadas em diretivas (Policy Decision Point) (SWS_CommunicationManagement p. 215). Além disso, eventos de segurança são reportados diretamente ao EventReporter do Intrusion Detection System Manager (IdSM) (SWS_CommunicationManagement p. 34).

Diagrama de contexto: incorporação de ara::com e desacoplamento das camadas de aplicação através de bindings. Fontes: SWS_CommunicationManagement p. 55, ARAComAPI p. 1

Descoberta de serviços e instanciação através de proxies e skeletons

A mediação dinâmica de serviços (Service Discovery) regula o estabelecimento de relações de comunicação locais e distribuídas (SWS_CommunicationManagement p. 67). Um provedor de serviço sinaliza a sua disponibilidade através da chamada de OfferService() no skeleton ([SWS_CM_00101]). Se o serviço for finalizado ou o fornecimento for revogado, StopOfferService() retira a oferta ([SWS_CM_00111]). Os consumidores determinam instâncias de serviço compatíveis de forma síncrona através de FindService() ou de forma assíncrona através de StartFindService() ([SWS_CM_00122], [SWS_CM_00123], ARAComAPI p. 103). Este último registra um FindServiceHandler, que é notificado a cada alteração no panorama de instâncias até que a busca seja terminada explicitamente através de StopFindService() ([SWS_CM_00125], [SWS_CM_00383]).

Para desacoplar o código-fonte de IDs de rede e de instância fixas, a interface permite o endereçamento através de caminhos abstratos de modelo por meio de ara::core::InstanceSpecifier ([SWS_CM_00622], [SWS_CM_00623], AUTOSAR_AP_EXP_ARAComAPI p. 124). O middleware resolve esses especificadores em ara::com::InstanceIdentifier concretos através do Service Instance Manifest armazenado ([SWS_CM_00118], [SWS_CM_11520], ARAComAPI p. 1). Um serviço encontrado é disponibilizado como descritor tipado (HandleType) em um ServiceHandleContainer ([SWS_CM_10383], AUTOSAR_EXP_SensorInterfaces p. 16). Através do método de fábrica estático Proxy::Create() ou do construtor, o consumidor cria uma instância de proxy vinculada para uso posterior de funções ([SWS_CM_10438], [SWS_CM_00131]).

Diagrama de sequência: sequência de Service Offering, pesquisa assíncrona e criação de proxy. Fontes: [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

Padrões de interação: chamadas de método e processamento assíncrono

As chamadas de método mapeiam o paradigma de solicitação-resposta síncrono e assíncrono. O cliente dispara métodos através do operador de chamada de função operator() no proxy ([SWS_CM_00196]). Como tipo de retorno, é utilizado por padrão um ara::core::Future, que encapsula o resultado ou um estado de erro ([SWS_CM_00191], ARAComAPI p. 1). O consumidor decide de forma flexível sobre a sincronização: através de consulta bloqueante via get(), espera com controle de tempo via wait_for() ou wait_until(), ou mediante o registro de rotinas de callback baseadas em eventos por meio de then() (ARAComAPI p. 1). Para notificações meramente unidirecionais sem resposta, existem métodos fire-and-forget com retorno void ([SWS_CM_90434], [SWS_CM_90435]).

No lado do provedor, o MethodCallProcessingMode define a estratégia de execução para chamadas recebidas ([SWS_CM_00301], [SWS_CM_00130]). No modo guiado por eventos (kEvent ou kEventSingleThread), a chamada de método ocorre imediatamente dentro de uma worker thread gerenciada pelo middleware (AUTOSAR_SWS_CommunicationManagement p. 60). No modo de polling (kPoll), a própria aplicação controla os momentos de processamento de forma determinística, chamando ProcessNextMethodCall() periodicamente ([SWS_CM_00199], EXP_SWArchitecture p. 68). A implementação do método gera o resultado internamente através de um ara::core::Promise e retorna o future associado (ARAComAPI p. 1).

Diagrama de sequência: chamada de método entre proxy e skeleton sob despacho kPoll e kEvent. Fontes: [SWS_CM_00196], [SWS_CM_00199], AUTOSAR_SWS_CommunicationManagement p. 60

Comunicação de eventos e campos no padrão publish-subscribe

A distribuição de fluxos contínuos de dados e de alterações de estado ocorre através de eventos e campos no padrão publish-subscribe (SWS_CommunicationManagement p. 67). Um assinante ativo registra o seu interesse de recepção através de Subscribe(), informando a quantidade máxima de amostras a serem mantidas (maxSampleCount) ([SWS_CM_00141], [SWS_CM_12002]). O estado da assinatura é consultado através de GetSubscriptionState() ou monitorado de forma assíncrona por meio de callbacks via SetSubscriptionStateChangeHandler() ([SWS_CM_00310], [SWS_CM_00316], [SWS_CM_01110]). O cancelamento da assinatura é feito através de Unsubscribe() ([SWS_CM_00151]).

A recepção de dados pode ocorrer guiada por eventos através de SetReceiveHandler() ou pela leitura periódica do buffer de recepção ([SWS_CM_00181], [SWS_CM_11356]). Com GetNewSamples(), o consumidor passa um objeto de função (lambda), que é chamado para cada amostra recebida com um SamplePtr tipado ([SWS_CM_00701], [SWS_CM_11610]). Para evitar custos de cópia (zero-copy), o skeleton disponibiliza memória através de Allocate() e envia o ponteiro tipado SampleAllocateePtr, com transferência total de propriedade, via Send() para a camada de transmissão ([SWS_CM_90438], [SWS_CM_90437], [SWS_CM_00308], AUTOSAR_EXP_ARAComAPI p. 63, ARAComAPI p. 1).

Um Field estende o conceito de evento com semântica de getters e setters (AUTOSAR_EXP_ARAComAPI p. 68). Os consumidores leem o Field através de Get() ou o escrevem através de Set() ([SWS_CM_00112], [SWS_CM_00113]). No lado do servidor, essas solicitações são atendidas com RegisterGetHandler() ou RegisterSetHandler() ([SWS_CM_00114], [SWS_CM_00116]). Se o servidor atualizar o estado através de Update(), o Field atua automaticamente como notificador e distribui a alteração a todos os assinantes registrados ([SWS_CM_00119], ARAComAPI p. 1).

Diagrama de sequência: alocação zero-copy, publicação de eventos, assinatura e consumo com GetNewSamples. Fontes: [SWS_CM_00141], [SWS_CM_00701], [SWS_CM_90437], AUTOSAR_EXP_ARAComAPI p. 63

Proteção, tradução de serviços e integração à plataforma

Para fluxos de dados determinísticos e relevantes para a segurança, o ara::com integra proteção ponta a ponta (E2E) e autenticação de acordo com os padrões AUTOSAR (AUTOSAR_AP_TR_SystemTests p. 132). Através de GetProfileCheckStatus() e GetE2EStateMachineState(), os consumidores podem verificar o estado de integridade e validação dos dados recebidos ([SWS_CM_90420], [SWS_CM_90421], [SWS_CM_11554]). No lado do servidor, a aplicação registra rotinas de tratamento de erros através de SetTransportFaultConditionHandler() para reagir de forma padronizada a defeitos de transporte e de E2E no nível de método ([SWS_CM_00093], [SWS_CM_00094], [SWS_CM_00100], EXP_SWArchitecture p. 68).

A integridade criptográfica e a autenticidade de mensagens externas são asseguradas pela Secure Onboard Communication (SecOC) (SWS_CommunicationManagement p. 222). Para isso, o middleware integra uma biblioteca intercambiável de Freshness Value Management (FVM), que gerencia valores de freshness através de GetRxFreshness(), GetTxFreshness() e Initialize() ([SWS_CM_11288], [SWS_CM_11289], [SWS_CM_11290], SWS_CommunicationManagement p. 226). Funções de diagnóstico e de segurança monitoram ou controlam a verificação através de interfaces específicas como SetVerificationStatus() ([SWS_CM_19999], AUTOSAR_AP_EXP_SWArchitecture p. 70).

Para interoperabilidade com a AUTOSAR Classic Platform, o ara::com suporta a comunicação baseada em sinais (Signal-to-Service Translation) (SWS_CommunicationManagement p. 146, TPS_ManifestSpecification p. 476). De acordo com [SWS_CM_10174] e [SWS_CM_80001], I-PDUs de sinal clássicas e mensagens SOME/IP podem ser transportadas através do mesmo socket. Caso exista uma configuração de SecOC baseada em sinais, o middleware lê os parâmetros de proteção diretamente a partir do acionamento de PDU do manifesto ([SWS_CM_11346], SWS_CommunicationManagement p. 228).

Diagrama de atividades: pipeline de proteção E2E e SecOC para mensagens recebidas. Fontes: [SWS_CM_90420], [SWS_CM_11288], SWS_CommunicationManagement p. 222

Comportamento em caso de erro

O gerenciamento de erros do ara::com baseia-se em domínios de erro com segurança de tipos e códigos de retorno do AUTOSAR Core Framework ([SWS_CM_11334], [SWS_CM_11335]). Os erros da camada geral de comunicação são agrupados no ComErrorDomain e codificados através do enumerador ComErrc ([SWS_CM_10432]). No caso de erros de verificação E2E, o ComE2EErrorDomain sinaliza erros de verificação específicos, como divergências de checksum ou contadores inválidos, através do valor de enumeração ComE2EErrc ([SWS_CM_10474], [SWS_CM_12510], [SWS_CM_12511]). Para erros de freshness do SecOC, existe analogamente o ComSecOcFvmErrorDomain com ComSecOcFvmErrc ([SWS_CM_12521], [SWS_CM_12522]).

Se ocorrer uma queda de conexão durante o tempo de execução, o estado de assinatura do proxy muda de kSubscribed para kSubscriptionPending ([SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32). As chamadas de método falham com um erro durante essa fase. Se o provedor de serviço retornar subsequentemente via Service Discovery, o middleware atualiza o endereçamento interno do proxy de forma transparente, sem que o consumidor precise reinstanciar o objeto proxy; após uma ressincronização bem-sucedida, o estado retorna automaticamente para kSubscribed (ARAComAPI p. 32). De acordo com a especificação do sistema, o próprio software aplicativo é responsável pelos prazos e pelo monitoramento de prazos (Deadline Monitoring) (TPS_ManifestSpecification p. 504).

Diagrama de estados: ciclo de vida e estados de conexão de uma instância de proxy mediante alterações de disponibilidade do provedor. Fontes: [SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32

Evidências mais detalhadas

Os principais requisitos e interfaces de sistema enquadram-se nas especificações AUTOSAR da seguinte forma:

• Ciclo de vida de serviço e Discovery: a disponibilização de serviços e os mecanismos de busca baseiam-se em [SWS_CM_00101], [SWS_CM_00111], [SWS_CM_00122] e [SWS_CM_00123], detalhados no guia de arquitetura de software (ARAComAPI p. 103).
• Paradigmas de interação: métodos e valores futuros assíncronos são padronizados em [SWS_CM_00191] e [SWS_CM_00196]; assinaturas de eventos e transmissões de amostras seguem [SWS_CM_00141], [SWS_CM_00701] e [SWS_CM_90437] (SWS_CommunicationManagement p. 67).
• Segurança e serialização: conceitos de proteção para E2E ([SWS_CM_90420]), SecOC ([SWS_CM_90108], [SWS_CM_11288]) e Signal-to-Service-Translation ([SWS_CM_10174]) regulam o intercâmbio de dados em todo o sistema (SWS_CommunicationManagement p. 146, SWS_CommunicationManagement p. 222).
• Definições de manifestos e de tipos: o mapeamento de tipos de dados estruturados, campos opcionais e especificadores de instância está consolidado na especificação de manifesto (TPS_ManifestSpecification p. 161, TPS_ManifestSpecification p. 458).