módulo ara::nm — Network Management

O cluster funcional Network Management disponibiliza interfaces para o State Management para requisitar, de forma coordenada, handles de rede lógicos, redes parciais e canais de comunicação físicos, bem como consultar o seu estado ([SWS_ANM_01000], EXP_SWArchitecture p. 77). Através da classe NetworkHandle, são controlados os estados alvo e real entre kNoCom e kFullCom, e são registrados notificadores assíncronos ([SWS_ANM_01009], [SWS_ANM_01010], [SWS_ANM_01358]). A utilização da interface é reservada exclusivamente ao State Management, enquanto os erros são reportados de forma padronizada através de NmErrorDomain ([SWS_ANM_01101], [SWS_ANM_01111]).

mais ›

O cluster funcional Network Management (NM) disponibiliza à AUTOSAR Adaptive Platform mecanismos para a requisição e monitoramento de estado de redes de comunicação e redes parciais. A interface de programação destina-se exclusivamente ao cluster funcional State Management, que controla recursos de rede através de instâncias lógicas da classe NetworkHandle e é desacoplado de estruturas de barramento físicas como Ethernet ou CAN ([SWS_ANM_01000], EXP_SWArchitecture p. 77, EXP_PlatformDesign p. 60).

Diagrama de contexto: Integração sistêmica do cluster funcional Network Management entre o State Management e o nível físico de rede. Fontes: SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

Um NetworkHandle é inicializado através de um ara::core::InstanceSpecifier e suporta operações de movimentação, enquanto o construtor de cópia e a atribuição por cópia estão excluídos ([SWS_ANM_01001], [SWS_ANM_01003], [SWS_ANM_01005]). O módulo distingue entre o estado de requisição definido (SetNetworkRequestedState, GetNetworkRequestedState) e o estado de rede efetivamente ativo (GetNetworkState), representados respectivamente por NetworkStateType com os estados kNoCom e kFullCom ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01358]).

Diagrama de sequência: Fluxo de interação no registro de notificadores, requisição de estado e consulta de estado. Fontes: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

Para a sinalização assíncrona de mudanças de estado, podem ser registrados callbacks através de RegisterNetworkStateChangeNotifier ou RegisterNetworkRequestedStateChangeNotifier – opcionalmente com executor próprio – ([SWS_ANM_01010], [SWS_ANM_01014], [SWS_ANM_01020]). Os erros são reportados através de NmErrorDomain e NmErrc; códigos padronizados como kServiceNotAvailable e kInvalidHandler garantem o tratamento determinístico de falhas e configurações incorretas ([SWS_ANM_01101], [SWS_ANM_01111]).

mais ›

Papel sistêmico e delimitação da arquitetura funcional

O cluster funcional Network Management (NM) fornece, dentro da AUTOSAR Adaptive Platform, o gerenciamento coordenado de redes de comunicação e redes parciais (Partial Networks, PN). A interface de programação do módulo não se destina a Adaptive Applications arbitrárias, mas serve especificamente ao cluster funcional State Management (SM) para requisitar ou liberar capacidades de comunicação sob demanda ([SWS_ANM_01000], EXP_SWArchitecture p. 77). O State Management atua como orquestrador central do sistema da máquina e controla grupos de funções e estados de plataforma, enquanto o Network Management encapsula o monitoramento efetivo do barramento, a lógica de rede parcial e os estados de bus-keep-alive (SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60).

Em termos arquiteturais, o Network Management desacopla os controles de estado de nível superior da topologia física de rede, como redes Ethernet ou CAN, através de handles de rede lógicos (NetworkHandle) (EXP_PlatformDesign p. 60). Uma requisição de rede feita pelo State Management é mapeada internamente para máquinas de estado específicas de canal e Partial Network State Machines (PNSM), sincronizando a comunicação nos canais físicos e ativando-a ou desativando-a sob demanda (SWS_NetworkManagement p. 18, SWS_StateManagement p. 17).

Diagrama de contexto: Integração sistêmica do cluster funcional Network Management entre o State Management e o nível físico de rede. Fontes: SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

Instanciação e gerenciamento de recursos via NetworkHandle

O acesso funcional a uma rede parcial concreta ou a um canal de comunicação físico ocorre através de instâncias da classe NetworkHandle ([SWS_ANM_01000]). Um NetworkHandle é explicitamente construído passando-se um ara::core::InstanceSpecifier, que referencia de forma unívoca o protótipo de porta associado de um NetworkManagementPortInterface ([SWS_ANM_01001]). A inicialização através deste construtor é especificada como thread-safe ([SWS_ANM_01001]).

O design de interface de NetworkHandle segue regras estritas de ciclo de vida e propriedade: o construtor de cópia e o operador de atribuição por cópia estão explicitamente excluídos (= delete), impedindo a duplicação não coordenada de instâncias de handle ([SWS_ANM_01005], [SWS_ANM_01006]). Em contrapartida, são disponibilizados o construtor de movimentação e a atribuição por movimentação para permitir a transferência controlada de recursos ([SWS_ANM_01003], [SWS_ANM_01004]). Interpretação: Como a cópia é proibida e apenas operações de movimentação são permitidas, a arquitetura provavelmente impõe uma semântica de propriedade exclusiva por instância de handle, a fim de evitar registros concorrentes de notificadores no mesmo objeto. Pergunta Q-912cb5d1ddff2896 (aberta) O destrutor e a atribuição por movimentação são explicitamente definidos como não thread-safe, razão pela qual o gerenciamento do ciclo de vida de um handle no State Management deve ocorrer de forma sincronizada ([SWS_ANM_01002], [SWS_ANM_01004]).

Controle e consulta de estados de comunicação

O módulo distingue estritamente entre o estado alvo requisitado (Requested State) e o estado real efetivamente ativo (Network State) de um handle de rede ([SWS_ANM_01007], [SWS_ANM_01008]). Ambos os estados são representados pela enumeração NetworkStateType com os valores kNoCom (valor 0) e kFullCom (valor 1) ([SWS_ANM_01358]). Por definição, o estado geral só é kFullCom se todas as redes parciais ou totais atribuídas ao handle estiverem, sem exceção, no estado de comunicação FULL_COM; caso contrário, o status é kNoCom ([SWS_ANM_01358]).

Através do método SetNetworkRequestedState, o State Management requisita a ativação (kFullCom) ou liberação (kNoCom) da respectiva rede PNC, VLAN ou física ([SWS_ANM_01009], EXP_SWArchitecture p. 77). Com GetNetworkRequestedState, o último valor de requisição definido pode ser consultado de forma síncrona ([SWS_ANM_01008]). Já o estado operacional real e relevante para o barramento é lido com GetNetworkState, sendo que ambos os métodos de consulta são declarados como thread-safe e encapsulam seu resultado em um ara::core::Result ([SWS_ANM_01007], [SWS_ANM_01008]).

Diagrama de estados: Transições de estado do status de rede elementar NetworkStateType. Fontes: [SWS_ANM_01358], [SWS_ANM_01007], [SWS_ANM_01009]

Monitoramento de estado baseado em eventos e mecanismos de notificação

Como as mudanças de estado no nível de rede chegam com atraso devido a nós externos do barramento, timeouts de mensagens ou tempos de inicialização assíncronos, NetworkHandle disponibiliza mecanismos de notificação assíncrona através de funções de callback do tipo NetworkStateChangeNotifier (std::function<void(const NetworkStateType&)>) ([SWS_ANM_01020]). Para alterações do estado de rede efetivo, utiliza-se RegisterNetworkStateChangeNotifier ([SWS_ANM_01010]), enquanto as alterações do estado requisitado são monitoradas através de RegisterNetworkRequestedStateChangeNotifier ([SWS_ANM_01012]).

Por handle e tipo de monitoramento, pode ser registrado no máximo um notificador; cada chamada subsequente de registro sobrescreve o callback registrado anteriormente (EXP_SWArchitecture p. 77). Com UnregisterNetworkStateChangeNotifier e UnregisterNetworkRequestedStateChangeNotifier, registros existentes podem ser explicitamente cancelados ([SWS_ANM_01011], [SWS_ANM_01013]). Para um controle de fluxo avançado, estão disponíveis métodos de registro baseados em templates que aceitam um executor definido pelo usuário (ExecutorT&& executor) para processar a notificação em um contexto de execução ou thread específico ([SWS_ANM_01014], [SWS_ANM_01015]).

Diagrama de sequência: Fluxo de interação no registro de notificadores, requisição de estado e consulta de estado. Fontes: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

Modelagem de manifesto e configuração de mapeamento

A integração do Network Management na Adaptive Application ocorre por meio de elementos de metamodelo padronizados no manifesto. A interface NetworkManagementPortInterface especializa a metaclasse fundamental PortInterface e define, assim, protótipos formais de porta (PPortPrototype, RPortPrototype) para a interação com o cluster (TPS_ManifestSpecification p. 263).

No manifesto de deployment, a vinculação entre instâncias de aplicação e o gerenciamento lógico de rede é declarada através do elemento de mapeamento NetworkHandlePortMapping (TPS_ManifestSpecification p. 620). Este vincula um protótipo de porta dentro de um processo (Process) a um NmNetworkHandle lógico (TPS_ManifestSpecification p. 620). Além disso, através do elemento de metamodelo NmInteractsWithSmMapping, o acoplamento coordenativo entre o cluster State Management (através de StateManagementStateRequest) e o handle de rede (NmNetworkHandle) é configurado de forma vinculativa (TPS_ManifestSpecification p. 875).

Diagrama de metamodelo: Relações de configuração e mapeamento ARXML entre portas, processos, handles e State Management. Fontes: TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620, TPS_ManifestSpecification p. 875

Comportamento em caso de erro

Para um tratamento de erros uniforme, o módulo implementa um domínio de erros próprio de acordo com a arquitetura de erros da AUTOSAR Adaptive. A classe NmErrorDomain herda de ara::core::ErrorDomain e identifica erros do gerenciamento de rede através da consulta estática de domínio GetNmDomain, bem como dos métodos de identificação Name e Message ([SWS_ANM_01101], [SWS_ANM_01105], [SWS_ANM_01106], [SWS_ANM_01107], [SWS_ANM_01109]).

As causas específicas de erro são definidas na enumeração NmErrc ([SWS_ANM_01111]). O código de erro NmErrc::kServiceNotAvailable (código 1) sinaliza que o serviço de plataforma ou daemon subjacente não está acessível; ele pode ocorrer nos métodos GetNetworkState, GetNetworkRequestedState e SetNetworkRequestedState ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01111]). O código de erro NmErrc::kInvalidHandler (código 2) é reportado quando um handler de notificador inválido é passado para um dos métodos de registro ([SWS_ANM_01010], [SWS_ANM_01012], [SWS_ANM_01014], [SWS_ANM_01015], [SWS_ANM_01111]).

Os códigos de erro são convertidos em objetos ara::core::ErrorCode regulares através de MakeErrorCode ([SWS_ANM_01110]). Se as exceções C++ forem permitidas e configuradas nos ambientes de execução, esses erros podem ser lançados através de ThrowAsException como uma exceção do tipo NmException ([SWS_ANM_01100], [SWS_ANM_01102], [SWS_ANM_01108]). Para simplificação, estão disponíveis os aliases de tipo Errc e Exception ([SWS_ANM_01103], [SWS_ANM_01104]).

Evidências mais detalhadas

Os requisitos essenciais do módulo baseiam-se em determinações normativas da especificação e modelos de arquitetura complementares:

• Especificação de classes e interfaces: NetworkHandle como classe central para requisições de rede e consultas de estado ([SWS_ANM_01000] a [SWS_ANM_01015]).
• Definição de estados: NetworkStateType com kNoCom e kFullCom para representação do status de rede ([SWS_ANM_01358]).
• Domínio de erros e códigos de erro: NmErrorDomain, NmException e NmErrc ([SWS_ANM_01100] a [SWS_ANM_01111]).
• Evidências de arquitetura e manifesto: Definições de interfaces e portas em EXP_SWArchitecture p. 77, SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, bem como mapeamentos de metamodelo em TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620 e TPS_ManifestSpecification p. 875.