module ara::nm — Network Management

Le cluster fonctionnel Network Management met à la disposition du State Management des interfaces pour demander de manière coordonnée des handles de réseau logiques, des réseaux partiels et des canaux de communication physiques, ainsi que pour interroger leur état ([SWS_ANM_01000], EXP_SWArchitecture p. 77). La classe NetworkHandle permet de piloter les états cibles et effectifs entre kNoCom et kFullCom et d'enregistrer des notificateurs asynchrones ([SWS_ANM_01009], [SWS_ANM_01010], [SWS_ANM_01358]). L'utilisation de l'interface est exclusivement réservée au State Management, tandis que les erreurs sont signalées de manière uniforme via NmErrorDomain ([SWS_ANM_01101], [SWS_ANM_01111]).

plus ›

Le cluster fonctionnel Network Management (NM) fournit à l'AUTOSAR Adaptive Platform des mécanismes pour la demande et la surveillance d'état de réseaux de communication et de réseaux partiels. L'interface de programmation s'adresse exclusivement au cluster fonctionnel State Management, qui contrôle les ressources réseau via des instances logiques de la classe NetworkHandle et est découplé des structures de bus physiques telles qu'Ethernet ou CAN ([SWS_ANM_01000], EXP_SWArchitecture p. 77, EXP_PlatformDesign p. 60).

Diagramme de contexte : intégration systémique du cluster fonctionnel Network Management entre le State Management et le niveau de réseau physique. Sources : SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

Un NetworkHandle est initialisé via un ara::core::InstanceSpecifier et prend en charge les opérations de déplacement, tandis que le constructeur de copie et l'affectation par copie sont supprimés ([SWS_ANM_01001], [SWS_ANM_01003], [SWS_ANM_01005]). Le module fait la distinction entre l'état de requête défini (SetNetworkRequestedState, GetNetworkRequestedState) et l'état de réseau réellement actif (GetNetworkState), chacun étant représenté par NetworkStateType avec les états kNoCom et kFullCom ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01358]).

Diagramme de séquence : flux d'interaction lors de l'enregistrement de notificateur, de la demande d'état et de l'interrogation d'état. Sources : [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

Pour la signalisation asynchrone des changements d'état, des callbacks peuvent être enregistrés via RegisterNetworkStateChangeNotifier ou RegisterNetworkRequestedStateChangeNotifier – en option avec leur propre exécuteur – ([SWS_ANM_01010], [SWS_ANM_01014], [SWS_ANM_01020]). Les erreurs sont indiquées via NmErrorDomain et NmErrc ; des codes standardisés tels que kServiceNotAvailable et kInvalidHandler garantissent un traitement déterministe des pannes et des configurations erronées ([SWS_ANM_01101], [SWS_ANM_01111]).

plus ›

Rôle systémique et délimitation de l'architecture fonctionnelle

Le cluster fonctionnel Network Management (NM) assure, au sein de l'AUTOSAR Adaptive Platform, la gestion coordonnée des réseaux de communication et des réseaux partiels (Partial Networks, PN). L'interface de programmation du module n'est pas destinée à des Adaptive Applications quelconques, mais sert spécifiquement au cluster fonctionnel State Management (SM) afin de demander ou de libérer des capacités de communication en fonction des besoins ([SWS_ANM_01000], EXP_SWArchitecture p. 77). Le State Management agit en tant qu'orchestrateur système central de la machine et contrôle les groupes de fonctions ainsi que les états de plateforme, tandis que le Network Management encapsule la surveillance effective du bus, la logique de réseau partiel et les états de maintien d'activité (keep-alive) du bus (SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60).

Sur le plan architectural, le Network Management découple les contrôles d'état de niveau supérieur de la topologie de réseau physique telle que les réseaux Ethernet ou CAN via des handles de réseau logiques (NetworkHandle) (EXP_PlatformDesign p. 60). Une requête de réseau émise par le State Management est mappée en interne sur des machines à états spécifiques au canal et sur des Partial Network State Machines (PNSM), ce qui synchronise la communication sur les canaux physiques et l'active ou l'arrête en fonction des besoins (SWS_NetworkManagement p. 18, SWS_StateManagement p. 17).

Diagramme de contexte : intégration systémique du cluster fonctionnel Network Management entre le State Management et le niveau de réseau physique. Sources : SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

Instanciation et gestion des ressources via NetworkHandle

L'accès fonctionnel à un réseau partiel concret ou à un canal de communication physique s'effectue via des instances de la classe NetworkHandle ([SWS_ANM_01000]). Un NetworkHandle est explicitement construit par la transmission d'un ara::core::InstanceSpecifier, qui référence de manière univoque le prototype de port associé d'un NetworkManagementPortInterface ([SWS_ANM_01001]). L'initialisation via ce constructeur est spécifiée comme étant thread-safe ([SWS_ANM_01001]).

La conception de l'interface de NetworkHandle suit des règles strictes de cycle de vie et de propriété : le constructeur de copie et l'opérateur d'affectation par copie sont explicitement supprimés (= delete), empêchant ainsi toute duplication non coordonnée d'instances de handle ([SWS_ANM_01005], [SWS_ANM_01006]). En revanche, le constructeur de déplacement et l'affectation par déplacement sont fournis afin de pouvoir transférer les ressources de manière contrôlée ([SWS_ANM_01003], [SWS_ANM_01004]). Interprétation : la copie étant interdite et seules les opérations de déplacement étant autorisées, l'architecture devrait imposer une sémantique de propriété exclusive par instance de handle afin d'exclure des enregistrements concurrents de notificateurs sur le même objet. Question Q-912cb5d1ddff2896 (ouverte) Le destructeur et l'affectation par déplacement sont explicitement définis comme non thread-safe, raison pour laquelle la gestion du cycle de vie d'un handle doit s'effectuer de manière synchronisée dans le State Management ([SWS_ANM_01002], [SWS_ANM_01004]).

Contrôle et interrogation des états de communication

Le module fait une distinction stricte entre l'état cible demandé (Requested State) et l'état effectif réellement actif (Network State) d'un handle de réseau ([SWS_ANM_01007], [SWS_ANM_01008]). Les deux états sont représentés via l'énumération NetworkStateType avec les valeurs kNoCom (valeur 0) et kFullCom (valeur 1) ([SWS_ANM_01358]). Par définition, l'état global n'est kFullCom que si la totalité, sans exception, des réseaux partiels ou complets associés au handle se trouvent dans l'état de communication FULL_COM ; dans le cas contraire, le statut est kNoCom ([SWS_ANM_01358]).

Via la méthode SetNetworkRequestedState, le State Management demande l'activation (kFullCom) ou la libération (kNoCom) du PNC, du VLAN ou du réseau physique correspondant ([SWS_ANM_01009], EXP_SWArchitecture p. 77). GetNetworkRequestedState permet d'interroger de manière synchrone la dernière valeur de requête définie ([SWS_ANM_01008]). L'état de fonctionnement réel pertinent pour le bus est quant à lui lu à l'aide de GetNetworkState, les deux méthodes d'interrogation étant déclarées thread-safe et encapsulant leur résultat dans un ara::core::Result ([SWS_ANM_01007], [SWS_ANM_01008]).

Diagramme d'état : transitions d'état du statut de réseau élémentaire NetworkStateType. Sources : [SWS_ANM_01358], [SWS_ANM_01007], [SWS_ANM_01009]

Surveillance d'état basée sur les événements et mécanismes de notification

Étant donné que les changements d'état au niveau du réseau parviennent avec retard en raison de participants au bus externes, de délais d'attente de messages ou de temps de démarrage asynchrones, NetworkHandle fournit des mécanismes de notification asynchrone via des fonctions de rappel de type NetworkStateChangeNotifier (std::function<void(const NetworkStateType&)>) ([SWS_ANM_01020]). RegisterNetworkStateChangeNotifier sert pour les modifications de l'état de réseau effectif ([SWS_ANM_01010]), tandis que les modifications de l'état demandé sont surveillées via RegisterNetworkRequestedStateChangeNotifier ([SWS_ANM_01012]).

Au maximum un seul notificateur peut être enregistré par handle et par type de surveillance ; chaque appel d'enregistrement ultérieur écrase le callback précédemment enregistré (EXP_SWArchitecture p. 77). UnregisterNetworkStateChangeNotifier ainsi que UnregisterNetworkRequestedStateChangeNotifier permettent d'annuler explicitement les enregistrements existants ([SWS_ANM_01011], [SWS_ANM_01013]). Pour un contrôle d'exécution étendu, des méthodes d'enregistrement basées sur des templates sont disponibles ; elles acceptent un exécuteur personnalisé (ExecutorT&& executor) afin de traiter la notification dans un contexte d'exécution ou un thread spécifique ([SWS_ANM_01014], [SWS_ANM_01015]).

Diagramme de séquence : flux d'interaction lors de l'enregistrement de notificateur, de la demande d'état et de l'interrogation d'état. Sources : [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

Modélisation de manifeste et configuration d'association

L'intégration du Network Management dans l'Adaptive Application s'effectue via des éléments de métamodèle standardisés dans le manifeste. L'interface NetworkManagementPortInterface spécialise la métaclasse fondamentale PortInterface et définit ainsi des prototypes de port formels (PPortPrototype, RPortPrototype) pour l'interaction avec le cluster (TPS_ManifestSpecification p. 263).

Dans le manifeste de déploiement, la liaison entre les instances d'application et la gestion de réseau logique est déclarée via l'élément de mappage NetworkHandlePortMapping (TPS_ManifestSpecification p. 620). Celui-ci associe un prototype de port au sein d'un processus (Process) à un NmNetworkHandle logique (TPS_ManifestSpecification p. 620). De plus, le couplage de coordination entre le cluster State Management (via NmInteractsWithSmMapping) et le handle de réseau (StateManagementStateRequest) est configuré de manière contraignante via l'élément de métamodèle NmNetworkHandle (TPS_ManifestSpecification p. 875).

Diagramme de métamodèle : relations de configuration et de mappage ARXML entre ports, processus, handles et State Management. Sources : TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620, TPS_ManifestSpecification p. 875

Comportement en cas d'erreur

Pour un traitement uniforme des erreurs, le module implémente son propre domaine d'erreur conformément à l'architecture d'erreur d'AUTOSAR Adaptive. La classe NmErrorDomain hérite de ara::core::ErrorDomain et identifie les erreurs de la gestion de réseau via l'interrogation de domaine statique GetNmDomain ainsi que les méthodes d'identification Name et Message ([SWS_ANM_01101], [SWS_ANM_01105], [SWS_ANM_01106], [SWS_ANM_01107], [SWS_ANM_01109]).

Les causes d'erreur spécifiques sont définies dans l'énumération NmErrc ([SWS_ANM_01111]). Le code d'erreur NmErrc::kServiceNotAvailable (code 1) signale que le service de plateforme ou démon sous-jacent n'est pas joignable ; il peut survenir lors des méthodes GetNetworkState, GetNetworkRequestedState et SetNetworkRequestedState ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01111]). Le code d'erreur NmErrc::kInvalidHandler (code 2) est signalé lorsqu'un gestionnaire de notificateur non valide a été transmis à l'une des méthodes d'enregistrement ([SWS_ANM_01010], [SWS_ANM_01012], [SWS_ANM_01014], [SWS_ANM_01015], [SWS_ANM_01111]).

Les codes d'erreur sont convertis en objets ara::core::ErrorCode réguliers via MakeErrorCode ([SWS_ANM_01110]). Si les exceptions C++ sont autorisées et configurées dans les environnements d'exécution, ces erreurs peuvent être levées via ThrowAsException sous la forme d'une exception de type NmException ([SWS_ANM_01100], [SWS_ANM_01102], [SWS_ANM_01108]). Pour simplifier, les alias de type Errc et Exception sont mis à disposition ([SWS_ANM_01103], [SWS_ANM_01104]).

Preuves détaillées supplémentaires

Les prescriptions essentielles du module s'appuient sur des dispositions normatives de la spécification et des modèles d'architecture d'accompagnement :

• Spécification des classes et interfaces : NetworkHandle en tant que classe centrale pour les requêtes de réseau et les interrogations d'état ([SWS_ANM_01000] à [SWS_ANM_01015]).
• Définition des états : NetworkStateType avec kNoCom et kFullCom pour la représentation de l'état du réseau ([SWS_ANM_01358]).
• Domaine d'erreur et codes d'erreur : NmErrorDomain, NmException et NmErrc ([SWS_ANM_01100] à [SWS_ANM_01111]).
• Justificatifs d'architecture et de manifeste : définitions d'interfaces et de ports dans EXP_SWArchitecture p. 77, SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60 ainsi que mappages de métamodèle dans TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620 et TPS_ManifestSpecification p. 875.