General catalog link ==>> AutoSAR entry and actual combat series general catalog
Article directory
Common Network Management Interface Module
This article will focus on the Common Network Management Interface module. Generic Network Management Interface (NM) "is part of the generic block of the AUTOSAR Layered Architecture Communication Services block." It is an adaptation layer between the AUTOSAR Communication Manager (ComM) and the bus-specific or network-dependent Network Management (NM) block (Example: CanNm for CAN bus). It handles the task of changing the network state from awake to sleep to save power.
"Note:" When reading further, please do not confuse the generic network management module with the bus-specific network management module.
Figure: Generic NM interface in Com Stack
The image above is the Com stack highlighting only the common network management blocks. NM is a network independent block, so it is instantiated only once and used again for all buses, i.e. there will not be different blocks for CAN bus and FlexRay bus, but the same NM block will be used for both buses. A generic NM provides an interface to the Communication Manager (ComM) and uses the services provided by a bus-specific NM module such as CanNm. ComMs communicate with bus-specific NM blocks via generic NM blocks, allowing complete abstraction and hardware (bus) independence.
Some features of the general network management module
Generic NM allows seamless ad-hoc addition of a new node, except that the node should have the "NmSelectiveNmChannel" property set to False during configuration. This newly added node can be of the following types: a delayed connection node, a node recovered from a fault state, or a dynamically added node in the live network.
The Generic NM allows SWCs to communicate even if the Generic NM cannot or has not been initialized.
Universal NM is a network-independent module, which can be applied to any communication bus at the same time as long as AUTOSAR supports it.
If no nodes require the bus, the generic NM puts the bus into sleep mode.
The Generic NM module mainly performs the following two operations:
"Translate generic function calls to bus-specific calls and vice versa:" function calls from the Communication Manager are bus-independent in nature, and the generic NM module translates and "directs" these calls to bus-specific calls that will be used in CanNm for CAN or in FrNm for FlexRay. It also converts bus-specific callbacks into bus-independent calls to ComM.
"Perform the role of NM coordinator:" Generic NM modules can be used to implement NM coordinator functions in a separate ECU called a gateway ECU, which is connected to multiple buses (such as CAN bus, FlexRay, etc.). In a multi-bus scenario, such functionality is required for synchronously shutting down the NMs of the bus (the bus-specific NM in the ECU at the other end of the bus), such a bus is called a coordinating "bus". Synchronization here means that all nodes in the bus will be controlled by The NM coordinator shuts down synchronously (or enters a power down state), because every node in the bus will know if any nodes are using the bus or going to sleep, and if no nodes are using the bus, then all nodes will down each other into the power-down state. The generic NM module uses a special algorithm to achieve this, called the "Coordinator Algorithm". If at least one node in the network needs the bus, the NM coordinator keeps the bus awake, which means it won't put other nodes to sleep, even if they wanted to! Each coordination bus (ECU that should listen to the NM Coordinator) has a configurable property that can be configured in configurator software such as Vector DaVinci Configurator "NmSelectiveNmChannel", if NmSelectiveNmChannel is set to True, the NM Coordinator will ignore the node and Its shutdown is not under the control of the NM coordinator or will be shutdown asynchronously. If only the NM coordinator is using the bus and all other coordinating buses are unused, the NM coordinator shuts down the entire bus by sending NM messages to other nodes in the network, and if there are no NM messages from other nodes in the network, NM coordinating The controller thinks this is "no one needs the bus" and turns off the bus. Generic NM won't help with "synchronous wakeup" because it's not necessary, because when a node needs to use the bus, the communication manager will wake up the corresponding node.
The NM coordinator function is optional, the generic NM supports the following combination of functions
Without the NM coordinator function, with the NM interface function
The NM interface function is limited to the ECU using the AUTOSAR-based network management module to support the NM coordinator function.
The NM interface function supports the NM coordinator function, and the ECU uses the NM based on AUTOSAR and the NM based on OSEK. AUTOSAR is implemented based on OSEK, but has more extensions than OSEK. So AUTOSAR uses a different NM implementation than OSEK's NM, and there are subtle differences between the two. The NM interface can support both types of NM implementations at the same time because AUTOSAR is backward compatible with OSEK.
Makefile for generic NM
The "Nm.c" static code implements all the NM functions discussed above and according to the configuration.
Generate four header files are:
"Nm.h": This file contains the function prototypes of the functions in the Nm.c file.
"Nm_Cbk.h": This file contains the function prototype callback function in Nm.c file
"Nm_Cfg.h:" This file contains precompile time configurable parameters.
"Nm_StackTypes.h:" This file contains the type definitions and structures used in the Nm.c file.
The generated c file is:
「Nm_LCfg.c：」