Generic Network Management Interface
Translate in your language
We already covered the generic blocks of Communication services in brief in my other article, now I will be explaining each block of it in detail, this article will focus on Generic Network management interface block. The Generic Network Management Interface(NM) is a part of generic blocks of Communication Services block of AUTOSAR Layered Architecture. It is a adaptation layer between the AUTOSAR Communication Manager(ComM) and bus specific or network dependent network management(NM) block of Bus (for e.g.: CanNm for CAN bus). It handles the task of changing network states from awake to sleep to save power.
Note: Please don’t confuse the Generic Network management module with Bus specific network management module while reading further. 🙂
Above figure is the Com Stack with only Generic Network Management block highlighted. This is a network independent block hence it is instantiated only once and reused again for all buses i.e. there won’t be different blocks for CAN Bus and FlexRay Bus, instead same NM block will be used for both buses. Generic NM provides a interface for Communication manager(ComM) and uses services offered by bus specific NM modules like CanNm. ComM communicates with bus specific NM module via Generic NM module thereby achieving complete abstraction and hardware(bus) independence.
Some features of Generic Network Management module:
- Generic NM allows adhoc addition of new nodes seamlessly, just that node should have “NmSelectiveNmChannel” property set to False during configuration. Such newly added nodes can be of types like: nodes which connected late, nodes which recovered from fault state, or nodes added dynamically in live network.
- Generic NM allows SWCs communicate even if Generic NM fails to initialize or is yet to initialize.
- Generic NM being a network independent module, works for any communication bus simultaneously as long as it is supported by AUTOSAR.
- If no node needs the bus, then Generic NM puts the bus in sleep mode.
Generic NM module mainly performs two operations as follows:
- Convert generic function calls to bus specific calls and vice versa: Function calls from Communication manager are bus independent in nature, Generic NM module converts these calls and “directs” them to bus specific calls which will be in CanNm for CAN or FrNm for FlexRay. It also converts the bus specific call backs to bus independent calls which are directed towards ComM.
- Performs the role of NM coordinator: Generic NM module can be used to implement NM coordinator functionality in a separate ECU called Gateway ECU which is connected to multiple buses (like CAN bus, FlexRay,etc). Such functionality is required for performing synchronous shutdown of NM of bus (this means bus specific NM in ECU on the other end of the bus) in multiple buses scenario, such bus is called coordinated bus. Here synchronous means, all the nodes in the bus will shutdown (or move to power down state) by NM coordinator in sync because each node in the bus will be aware if any node is using bus or ready to sleep and if no node is using the bus, then all nodes will mutually go in power down state with help of NM coordinator. Generic NM module uses a special algorithm for implementing this functionality referred as coordinator algorithm. The NM coordinator keeps the bus awake if at least one of node in the network needs the bus, that means it won’t let others to sleep even if they want to! 😀 Every coordinated bus (ECU which should listen to NM coordinator) has configurable property which can be configured in Configurator software like Vector DaVinci Configurator “NmSelectiveNmChannel” if it is set to True, then NM coordinator will ignore such node and its shutdown is not under NM coordinator’s control or it will be asynchronous shutdown. If only NM coordinator is using the bus and all other coordinated buses are not using, then NM Coordinator puts whole bus to shutdown by sending NM messages to other nodes in the network and if there is no NM messages from other nodes in network, then NM Coordinator considers this as “no one needs the bus” and then shuts down the bus. Generic NM won’t help in “synchronous wakeup” as it is not required because Communication manager will wakeup the respective node when bus needs to be used by that nodes.
- NM interface functionality without NM coordinator functionality
- NM interface functionality limited to support NM coordinator functionality only with ECUs using AUTOSAR based Network Management module.
- NM interface functionality to support NM coordinator functionality with both, ECUs using AUTOSAR based NM as well as OSEK based NM. AUTOSAR is based on OSEK implementation, but it has more extensions compared to OSEK. So AUTOSAR uses different NM implementation than OSEK’s NM, there is thin line of difference. NM interface can support both type of NM implementations simultaneously, as AUTOSAR is backward compatible with OSEK.
Files generated for Generic NM
Only a single C file is generated for NM named as Nm.c. It have all the implementation of NM functionality as discussed above and as per the configuration. Some tools also implement macros instead of separate C file for realising NM functionality.
Four header files are generated namely:
- Nm.h: This file contains function prototypes of functions in Nm.c file.
- Nm_Cbk.h: This file contains the function prototypes call back functions in Nm.c file
- Nm_Cfg.h: This file contains pre-compile time configurable parameters.
- Nm_StackTypes.h: This file contains typedef and structures used in Nm.c file.
I hope I explained Generic NM interface well, if you have any doubts please comment below.
If you find any incorrect information in this article, then please help me improving it by contacting me.
Thanks for reading 🙂