módulo ara::nm — Network Management

El Functional Cluster Network Management pone a disposición de State Management interfaces para solicitar de manera coordinada handles de red lógicos, subredes y canales de comunicación físicos, así como para consultar su estado ([SWS_ANM_01000], EXP_SWArchitecture p. 77). A través de la clase NetworkHandle se controlan los estados objetivo y real entre kNoCom y kFullCom, y se registran notificadores asíncronos ([SWS_ANM_01009], [SWS_ANM_01010], [SWS_ANM_01358]). El uso de la interfaz está reservado exclusivamente a State Management, mientras que los errores se notifican de forma uniforme a través de NmErrorDomain ([SWS_ANM_01101], [SWS_ANM_01111]).

más ›

El Functional Cluster Network Management (NM) pone a disposición de AUTOSAR Adaptive Platform mecanismos para la solicitud y la supervisión del estado de redes de comunicación y subredes. La interfaz de programación está dirigida exclusivamente al Functional Cluster State Management, el cual controla los recursos de red a través de instancias lógicas de la clase NetworkHandle y queda desacoplado de estructuras de bus físicas como Ethernet o CAN ([SWS_ANM_01000], EXP_SWArchitecture p. 77, EXP_PlatformDesign p. 60).

Diagrama de contexto: Integración sistémica del Functional Cluster Network Management entre State Management y el nivel de red física. Fuentes: SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

Un NetworkHandle se inicializa a través de un ara::core::InstanceSpecifier y admite operaciones de movimiento, mientras que el constructor de copia y la asignación por copia están eliminados ([SWS_ANM_01001], [SWS_ANM_01003], [SWS_ANM_01005]). El módulo distingue entre el estado de solicitud establecido (SetNetworkRequestedState, GetNetworkRequestedState) y el estado de red realmente activo (GetNetworkState), representados en cada caso por NetworkStateType con los estados kNoCom y kFullCom ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01358]).

Diagrama de secuencia: Flujo de interacción durante el registro de notificadores, la solicitud de estado y la consulta de estado. Fuentes: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

Para la señalización asíncrona de cambios de estado pueden registrarse retrollamadas mediante RegisterNetworkStateChangeNotifier o RegisterNetworkRequestedStateChangeNotifier —opcionalmente con un ejecutor propio— ([SWS_ANM_01010], [SWS_ANM_01014], [SWS_ANM_01020]). Los errores se identifican mediante NmErrorDomain y NmErrc; códigos estandarizados como kServiceNotAvailable y kInvalidHandler salvaguardan el tratamiento determinista de fallos y configuraciones erróneas ([SWS_ANM_01101], [SWS_ANM_01111]).

más ›

Papel sistémico y delimitación funcional de la arquitectura

Dentro de AUTOSAR Adaptive Platform, el Functional Cluster Network Management (NM) proporciona la gestión coordinada de redes de comunicación y subredes (Partial Networks, PN). La interfaz de programación del módulo no está prevista para Adaptive Applications arbitrarias, sino que sirve específicamente al Functional Cluster State Management (SM) para solicitar o liberar capacidades de comunicación en función de la demanda ([SWS_ANM_01000], EXP_SWArchitecture p. 77). State Management actúa como orquestador central del sistema en la máquina y controla Function Groups así como estados de plataforma, mientras que Network Management encapsula la supervisión efectiva del bus, la lógica de subredes y los estados de mantenimiento de actividad del bus (SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60).

Desde el punto de vista arquitectónico, Network Management desacopla los controles de estado de nivel superior respecto de la topología de red física, como redes Ethernet o CAN, a través de handles de red lógicos (NetworkHandle) (EXP_PlatformDesign p. 60). Una solicitud de red realizada por State Management se traslada internamente a máquinas de estados específicas del canal y a Partial Network State Machines (PNSM), con lo que la comunicación en los canales físicos se sincroniza y se activa o desactiva en función de la demanda (SWS_NetworkManagement p. 18, SWS_StateManagement p. 17).

Diagrama de contexto: Integración sistémica del Functional Cluster Network Management entre State Management y el nivel de red física. Fuentes: SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

Instanciación y gestión de recursos mediante NetworkHandle

El acceso funcional a una subred concreta o a un canal de comunicación físico se efectúa a través de instancias de la clase NetworkHandle ([SWS_ANM_01000]). Un NetworkHandle se construye explícitamente pasando un ara::core::InstanceSpecifier, el cual referencia de manera unívoca el prototipo de puerto asignado de un NetworkManagementPortInterface ([SWS_ANM_01001]). La inicialización a través de este constructor está especificada como segura frente a subprocesos ([SWS_ANM_01001]).

El diseño de interfaz de NetworkHandle sigue estrictas reglas de ciclo de vida y de propiedad: el constructor de copia y el operador de asignación por copia están explícitamente eliminados (= delete), con lo que se impide una duplicación no coordinada de instancias de handles ([SWS_ANM_01005], [SWS_ANM_01006]). Por el contrario, se proporcionan un constructor de movimiento y una asignación por movimiento para poder transferir recursos de forma controlada ([SWS_ANM_01003], [SWS_ANM_01004]). Interpretación: Dado que la copia está prohibida y solo se permiten operaciones de movimiento, es de presumir que la arquitectura impone una semántica de propiedad exclusiva por cada instancia de handle con el fin de excluir registros de notificadores concurrentes sobre el mismo objeto. Pregunta Q-912cb5d1ddff2896 (abierta) El destructor y la asignación por movimiento se definen explícitamente como no seguros frente a subprocesos, razón por la cual la gestión del ciclo de vida de un handle en State Management debe realizarse de forma sincronizada ([SWS_ANM_01002], [SWS_ANM_01004]).

Control y consulta de estados de comunicación

El módulo distingue estrictamente entre el estado objetivo solicitado (Requested State) y el estado real efectivamente activo (Network State) de un handle de red ([SWS_ANM_01007], [SWS_ANM_01008]). Ambos estados se representan mediante la enumeración NetworkStateType con los valores kNoCom (valor 0) y kFullCom (valor 1) ([SWS_ANM_01358]). Por definición, el estado global solo es kFullCom si, sin excepción, todas las redes parciales o completas asignadas al handle se encuentran en el estado de comunicación FULL_COM; de lo contrario, el estado es kNoCom ([SWS_ANM_01358]).

A través del método SetNetworkRequestedState, State Management solicita la activación (kFullCom) o la liberación (kNoCom) de la red PNC, VLAN o física asociada ([SWS_ANM_01009], EXP_SWArchitecture p. 77). Con GetNetworkRequestedState se puede consultar de forma síncrona el valor de solicitud establecido por última vez ([SWS_ANM_01008]). El estado operativo real y relevante para el bus se lee, por su parte, mediante GetNetworkState, estando ambos métodos de consulta declarados como seguros frente a subprocesos y encapsulando su resultado en un ara::core::Result ([SWS_ANM_01007], [SWS_ANM_01008]).

Diagrama de estados: transiciones de estado del estado de red elemental NetworkStateType. Fuentes: [SWS_ANM_01358], [SWS_ANM_01007], [SWS_ANM_01009]

Monitorización de estados basada en eventos y mecanismos de notificación

Dado que los cambios de estado a nivel de red llegan con retraso debido a participantes externos del bus, tiempos de espera de mensajes o tiempos de arranque asíncronos, NetworkHandle proporciona mecanismos de notificación asíncronos mediante funciones de retrollamada del tipo NetworkStateChangeNotifier (std::function<void(const NetworkStateType&)>) ([SWS_ANM_01020]). Para modificaciones del estado de red efectivo se utiliza RegisterNetworkStateChangeNotifier ([SWS_ANM_01010]), mientras que los cambios del estado solicitado se monitorizan mediante RegisterNetworkRequestedStateChangeNotifier ([SWS_ANM_01012]).

Por cada manejador y tipo de monitorización se puede registrar como máximo un notificador; cada llamada de registro posterior sobrescribe la retrollamada registrada previamente (EXP_SWArchitecture p. 77). Con UnregisterNetworkStateChangeNotifier y UnregisterNetworkRequestedStateChangeNotifier se pueden revocar explícitamente los registros existentes ([SWS_ANM_01011], [SWS_ANM_01013]). Para un control de ejecución ampliado se dispone de métodos de registro basados en plantillas que aceptan un ejecutor definido por el usuario (ExecutorT&& executor) para procesar la notificación en un contexto de ejecución o hilo específico ([SWS_ANM_01014], [SWS_ANM_01015]).

Diagrama de secuencia: Flujo de interacción durante el registro de notificadores, la solicitud de estado y la consulta de estado. Fuentes: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

Modelado del manifiesto y configuración de asignación

La integración de Network Management en la Adaptive Application se realiza mediante elementos estandarizados del metamodelo en el manifiesto. La interfaz NetworkManagementPortInterface especializa la metaclase fundamental PortInterface y define así prototipos de puerto formales (PPortPrototype, RPortPrototype) para la interacción con el clúster (TPS_ManifestSpecification p. 263).

En el manifiesto de despliegue se declara la vinculación entre las instancias de aplicación y la gestión lógica de red a través del elemento de mapeo NetworkHandlePortMapping (TPS_ManifestSpecification p. 620). Este vincula un prototipo de puerto dentro de un proceso (Process) con un NmNetworkHandle lógico (TPS_ManifestSpecification p. 620). Además, a través del elemento del metamodelo NmInteractsWithSmMapping se configura de forma vinculante el acoplamiento de coordinación entre el clúster State Management (a través de StateManagementStateRequest) y el manejador de red (NmNetworkHandle) (TPS_ManifestSpecification p. 875).

Diagrama de metamodelo: relaciones de configuración ARXML y de mapeo entre puertos, procesos, manejadores y State Management. Fuentes: TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620, TPS_ManifestSpecification p. 875

Comportamiento en caso de error

Para un tratamiento de errores homogéneo, el módulo implementa un dominio de errores propio conforme a la arquitectura de errores de AUTOSAR Adaptive. La clase NmErrorDomain hereda de ara::core::ErrorDomain e identifica errores de la gestión de red mediante la consulta estática de dominio GetNmDomain, así como los métodos de identificación Name y Message ([SWS_ANM_01101], [SWS_ANM_01105], [SWS_ANM_01106], [SWS_ANM_01107], [SWS_ANM_01109]).

Las causas específicas de los errores están definidas en la enumeración NmErrc ([SWS_ANM_01111]). El código de error NmErrc::kServiceNotAvailable (código 1) señala que el servicio de plataforma o demonio subyacente no está disponible; puede ocurrir en los métodos GetNetworkState, GetNetworkRequestedState y SetNetworkRequestedState ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01111]). El código de error NmErrc::kInvalidHandler (código 2) se notifica cuando se ha pasado un manejador notificador no válido a uno de los métodos de registro ([SWS_ANM_01010], [SWS_ANM_01012], [SWS_ANM_01014], [SWS_ANM_01015], [SWS_ANM_01111]).

Los códigos de error se transforman en objetos regulares ara::core::ErrorCode mediante MakeErrorCode ([SWS_ANM_01110]). En caso de que en los entornos de ejecución las excepciones de C++ estén permitidas y configuradas, estos errores pueden lanzarse mediante ThrowAsException como excepción del tipo NmException ([SWS_ANM_01100], [SWS_ANM_01102], [SWS_ANM_01108]). Para mayor simplificación, se encuentran disponibles los alias de tipo Errc y Exception ([SWS_ANM_01103], [SWS_ANM_01104]).

Más evidencia detallada

Las prescripciones esenciales del módulo se basan en definiciones normativas de la especificación y modelos de arquitectura complementarios:

• Especificación de clases e interfaces: NetworkHandle como clase central para solicitudes de red y consultas de estado ([SWS_ANM_01000] a [SWS_ANM_01015]).
• Definición de estados: NetworkStateType con kNoCom y kFullCom para representar el estado de red ([SWS_ANM_01358]).
• Dominio de errores y códigos de error: NmErrorDomain, NmException y NmErrc ([SWS_ANM_01100] a [SWS_ANM_01111]).
• Evidencias de arquitectura y manifiesto: definiciones de interfaz y puerto en EXP_SWArchitecture p. 77, SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, así como mapeos de metamodelo en TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620 y TPS_ManifestSpecification p. 875.