module ara::nm — Network Management

The functional cluster Network Management provides interfaces for State Management to request logical network handles, partial networks, and physical communication channels in a coordinated manner and to query their status ([SWS_ANM_01000], EXP_SWArchitecture p. 77). Via class NetworkHandle, target and actual states between kNoCom and kFullCom are controlled and asynchronous notifiers are registered ([SWS_ANM_01009], [SWS_ANM_01010], [SWS_ANM_01358]). Use of the interface is exclusively reserved for State Management, while errors are reported uniformly via NmErrorDomain ([SWS_ANM_01101], [SWS_ANM_01111]).

more ›

The functional cluster Network Management (NM) provides the AUTOSAR Adaptive Platform with mechanisms for requesting and status monitoring of communication networks and partial networks. The programming interface is addressed exclusively to the functional cluster State Management, which controls network resources via logical instances of class NetworkHandle and is decoupled from physical bus structures such as Ethernet or CAN ([SWS_ANM_01000], EXP_SWArchitecture p. 77, EXP_PlatformDesign p. 60).

Context diagram: Systemic integration of the functional cluster Network Management between State Management and the physical network layer. Sources: SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

An NetworkHandle is initialized via a ara::core::InstanceSpecifier and supports move operations, while copy constructor and copy assignment are deleted ([SWS_ANM_01001], [SWS_ANM_01003], [SWS_ANM_01005]). The module distinguishes between the requested state set (SetNetworkRequestedState, GetNetworkRequestedState) and the actually active network state (GetNetworkState), each represented by NetworkStateType with states kNoCom and kFullCom ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01358]).

Sequence diagram: Interaction flow during notifier registration, state request, and state query. Sources: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

For the asynchronous signaling of status changes, callbacks can be registered via RegisterNetworkStateChangeNotifier or RegisterNetworkRequestedStateChangeNotifier—optionally with a dedicated executor ([SWS_ANM_01010], [SWS_ANM_01014], [SWS_ANM_01020]). Errors are reported via NmErrorDomain and NmErrc; standardized codes such as kServiceNotAvailable and kInvalidHandler ensure deterministic handling of failures and erroneous configurations ([SWS_ANM_01101], [SWS_ANM_01111]).

more ›

Systemic role and functional architectural demarcation

The Network Management (NM) functional cluster provides the coordinated management of communication networks and partial networks (PN) within the AUTOSAR Adaptive Platform. The module's programming interface is not intended for arbitrary Adaptive Applications, but specifically serves the State Management (SM) functional cluster to request or release communication capabilities on demand ([SWS_ANM_01000], EXP_SWArchitecture p. 77). State Management acts as the central system orchestrator of the machine and controls function groups as well as platform states, whereas Network Management encapsulates the actual bus monitoring, partial network logic, and bus keep-alive states (SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60).

Architecturally, Network Management uses logical network handles (NetworkHandle) to decouple higher-level state controls from the physical network topology such as Ethernet or CAN networks (EXP_PlatformDesign p. 60). A network request by State Management is mapped internally to channel-specific state machines and Partial Network State Machines (PNSM), whereby communication on the physical channels is synchronized and activated or shut down on demand (SWS_NetworkManagement p. 18, SWS_StateManagement p. 17).

Context diagram: Systemic integration of the functional cluster Network Management between State Management and the physical network layer. Sources: SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60, [SWS_ANM_01000]

Instantiation and resource management via NetworkHandle

Functional access to a specific partial network or physical communication channel is performed via instances of class NetworkHandle ([SWS_ANM_01000]). A NetworkHandle is constructed explicitly by passing a ara::core::InstanceSpecifier, which uniquely references the assigned port prototype of a NetworkManagementPortInterface ([SWS_ANM_01001]). Initialization via this constructor is specified as thread-safe ([SWS_ANM_01001]).

The interface design of NetworkHandle follows strict lifecycle and ownership rules: the copy constructor and copy assignment operator are explicitly deleted (= delete), which prevents uncoordinated duplication of handle instances ([SWS_ANM_01005], [SWS_ANM_01006]). In contrast, a move constructor and move assignment are provided to allow controlled transfer of resources ([SWS_ANM_01003], [SWS_ANM_01004]). Interpretation: Since copying is prohibited and only move operations are permitted, the architecture likely enforces exclusive ownership semantics per handle instance in order to exclude conflicting notifier registrations on the same object. Question Q-912cb5d1ddff2896 (open) The destructor and move assignment are explicitly defined as not thread-safe, which is why lifecycle management of a handle in State Management must be synchronized ([SWS_ANM_01002], [SWS_ANM_01004]).

Control and query of communication states

The module strictly distinguishes between the requested target state (Requested State) and the actually active actual state (Network State) of a network handle ([SWS_ANM_01007], [SWS_ANM_01008]). Both states are represented via the enumeration NetworkStateType with the values kNoCom (value 0) and kFullCom (value 1) ([SWS_ANM_01358]). By definition, the overall state is kFullCom only if all partial or full networks assigned to the handle are in communication state FULL_COM without exception; otherwise, the status is kNoCom ([SWS_ANM_01358]).

Via method SetNetworkRequestedState, State Management requests the activation (kFullCom) or release (kNoCom) of the associated PNC, VLAN, or physical network ([SWS_ANM_01009], EXP_SWArchitecture p. 77). With GetNetworkRequestedState, the request value set last can be queried synchronously ([SWS_ANM_01008]). In contrast, the actual, bus-relevant operating state is read with GetNetworkState, whereby both query methods are declared as thread-safe and encapsulate their result in a ara::core::Result ([SWS_ANM_01007], [SWS_ANM_01008]).

State diagram: State transitions of the elementary network status NetworkStateType. Sources: [SWS_ANM_01358], [SWS_ANM_01007], [SWS_ANM_01009]

Event-based state monitoring and notification mechanisms

Because state changes at network level arrive with a delay due to external bus participants, message timeouts, or asynchronous ramp-up times, NetworkHandle provides asynchronous notification mechanisms via callback functions of type NetworkStateChangeNotifier (std::function<void(const NetworkStateType&)>) ([SWS_ANM_01020]). RegisterNetworkStateChangeNotifier is used for changes in the effective network state ([SWS_ANM_01010]), whereas changes in the requested state are monitored via RegisterNetworkRequestedStateChangeNotifier ([SWS_ANM_01012]).

A maximum of one notifier can be registered per handle and monitoring type; each subsequent registration call overwrites the previously registered callback (EXP_SWArchitecture p. 77). Existing registrations can be canceled explicitly using UnregisterNetworkStateChangeNotifier as well as UnregisterNetworkRequestedStateChangeNotifier ([SWS_ANM_01011], [SWS_ANM_01013]). For advanced flow control, template-based registration methods are available that accept a user-defined executor (ExecutorT&& executor) to process the notification in a specific execution context or thread ([SWS_ANM_01014], [SWS_ANM_01015]).

Sequence diagram: Interaction flow during notifier registration, state request, and state query. Sources: [SWS_ANM_01007], [SWS_ANM_01009], [SWS_ANM_01010], SWS_StateManagement p. 38

Manifest modeling and mapping configuration

The integration of Network Management into the Adaptive Application is performed via standardized metamodel elements in the manifest. Interface NetworkManagementPortInterface specializes the fundamental metaclass PortInterface and thus defines formal port prototypes (PPortPrototype, RPortPrototype) for interaction with the cluster (TPS_ManifestSpecification p. 263).

In the deployment manifest, the binding between application instances and logical network management is declared via the mapping element NetworkHandlePortMapping (TPS_ManifestSpecification p. 620). This links a port prototype within a process (Process) to a logical NmNetworkHandle (TPS_ManifestSpecification p. 620). In addition, the coordinating coupling between the State Management cluster (via StateManagementStateRequest) and the network handle (NmNetworkHandle) is bindingly configured via the metamodel element NmInteractsWithSmMapping (TPS_ManifestSpecification p. 875).

Metamodel diagram: ARXML configuration and mapping relationships between ports, processes, handles, and State Management. Sources: TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620, TPS_ManifestSpecification p. 875

Behavior in the event of an error

For uniform error handling, the module implements its own error domain according to the AUTOSAR Adaptive error architecture. Class NmErrorDomain inherits from ara::core::ErrorDomain and identifies network management errors via the static domain query GetNmDomain and the identification methods Name and Message ([SWS_ANM_01101], [SWS_ANM_01105], [SWS_ANM_01106], [SWS_ANM_01107], [SWS_ANM_01109]).

The specific error causes are defined in enumeration NmErrc ([SWS_ANM_01111]). Error code NmErrc::kServiceNotAvailable (code 1) signals that the underlying platform service or daemon is unreachable; it can occur with methods GetNetworkState, GetNetworkRequestedState, and SetNetworkRequestedState ([SWS_ANM_01007], [SWS_ANM_01008], [SWS_ANM_01009], [SWS_ANM_01111]). Error code NmErrc::kInvalidHandler (code 2) is reported if an invalid notifier handler was passed to one of the registration methods ([SWS_ANM_01010], [SWS_ANM_01012], [SWS_ANM_01014], [SWS_ANM_01015], [SWS_ANM_01111]).

Error codes are converted into regular ara::core::ErrorCode objects via MakeErrorCode ([SWS_ANM_01110]). If C++ exceptions are permitted and configured in execution environments, these errors can be thrown via ThrowAsException as an exception of type NmException ([SWS_ANM_01100], [SWS_ANM_01102], [SWS_ANM_01108]). To simplify usage, the type aliases Errc and Exception are available ([SWS_ANM_01103], [SWS_ANM_01104]).

Further detailed evidence

The essential requirements of the module are based on normative specifications and accompanying architectural models:

• Class and interface specification: NetworkHandle as core class for network requests and state queries ([SWS_ANM_01000] to [SWS_ANM_01015]).
• State definition: NetworkStateType with kNoCom and kFullCom for mapping the network status ([SWS_ANM_01358]).
• Error domain and error codes: NmErrorDomain, NmException, and NmErrc ([SWS_ANM_01100] to [SWS_ANM_01111]).
• Architecture and manifest references: Interface and port definitions in EXP_SWArchitecture p. 77, SWS_NetworkManagement p. 13, EXP_PlatformDesign p. 60 as well as metamodel mappings in TPS_ManifestSpecification p. 263, TPS_ManifestSpecification p. 620, and TPS_ManifestSpecification p. 875.