###### tags: `專題`
# ara::nm
Documents:
[SWS_NetworkManagement](https://www.autosar.org/fileadmin/user_upload/standards/adaptive/21-11/AUTOSAR_SWS_NetworkManagement.pdf)
[PRS_NetworkManagementProtocol](https://www.autosar.org/fileadmin/user_upload/standards/foundation/21-11/AUTOSAR_PRS_NetworkManagementProtocol.pdf)
## Overview

`ara::nm` can be broken down to several parts:
1. Network Handle Instance(Chapter 7.3?)
2. PN State Machines(Chapter 7.8)
3. NM instance with Network State Machine inside(Chapter 7.4)
## Network Management Algorithm
NM is working as decentralized, which means every node is independant and there is no `main(master) node` that controls every node. They're all exists equally, and they can send packets to any of the nodes directly, waking the node up or make the node work.
So every node needs to have timer(s) that can turn the mode into sleep mode when the timeout is occurred. Also if any node needs another specific node not falling to sleep state, it needs to send packets to the target periodically.
> Every network node transmits periodic NM messages as long as it requires bus communication; otherwise it does not transmit NM messages.
## Network Control
### Logical Network and Partial Network

Basically the 'layers' of network is drawn in the graph. The outer circles of network handles inner circles of network. So `Logical Network` can handle both `Partial and Physical Networks`, and `Partial Network` can only handle `Physical Network`. As the result, by controlling `Logical Network`, we can control all the `Partial and Physical Networks` assigned to it.
### State Management controls NetworkState
State Management can get/set the state by accessing `NetworkState`. It can change the status of the node by setting `NetworkRequestedState`, and it can reading the current state by getting `NetworkCurrentState`. Note that only State Management can connunicate with NM.
Here are the states of `NetworkState`:

From now on, we say that "Network requested" means `NetworkRequestedState = kFullCom`, and "Network released" means `NetworkRequestedState = kNoCom`.
## Operational Modes
[CSDN explains Operational Modes](https://blog.csdn.net/weixin_42555246/article/details/90344383)
### State Chart Diagram

經過反覆閱讀後認為這張圖跟Requirements差不多符合,除了有些箭頭方向畫錯之外基本上蠻直覺的。
另一個小問題是在這個圖的上方提到切換模式會用綠色表示,Error Handling會用紅色表示,但在圖中完全看不到這兩個顏色。
錯的地方:
> (Bus Sleep Mode <-- Prepare Bus Sleep Mode) **[SWS_ANM_00024]**
There are three modes in operational modes:
* Bus Sleep Mode
* Prepare Bus Sleep Mode
* Network Mode
### Network Mode
There are three states in Network Mode:
1. Repeat Message State
2. Normal Operation State
3. Ready Sleep State
#### 1. Repeat Message State
At this state, ***the node informs every node that this node is online***(so every node is awaken at this point), so it sends NM Message to **every** node periodically, when it reached `nmRepeatMessageTime`, the next state is depended by if the network is requested or not.
#### 2. Normal Operation State
If the network is requested, either **Repeat Message State** or **Ready Sleep State** will set the next state to this state. This state basically keeps the NM Nodes(those are needed to operate) awake, ***so it sends NM Message periodically to every one of them***. When the `Repeat Message Request Bit` is set in Nm Message, it should go back to **Repeat Message State**, if the network is released, it should go to **Ready Sleep State**.
#### 3. Ready Sleep State
If the network is released, either **Repeat Message State** or **Normal Operation State** will turn to this state. In this state, ***NM Message will not be transmitted***, and when `nmTimeoutTimer` is expired, it will enter Prepared Bus Sleep Mode. But if the network is requested, it will enter **Normal Operation State**. When the `Repeat Message Request Bit` is set in Nm Message, it should go back to **Repeat Message State**.
### Prepare Bus Sleep Mode
This mode is waiting for all the network activity to finish. In this mode, it is not going to do anything new, when the `nmWaitBusSleepTime` is finished, it will go to Bus Sleep Mode. But if the network is requested, it will go to Repeat Message Mode instead.
### Bus Sleep Mode
In this mode, the network transmission and reception(Tx/Rx) can be switched off(if supported) to reduce the power comsuption. By reading the modes and states above, we can know the whole NM Cluster is going to sleep at the same time
>(if any node are in Repeat Message or Normal Operation State, it will inform all the nodes to stay awake. so the whole cluster will only sleep together if there are no signals at all)
at `nmNetworkTimeout(to prepare bus sleep) + nmWaitBusSleepTime(to bus sleep)` if every node is set identically the same time. If the network is requested in this mode, the mode will switch to **Network Mode(Repeat Message State)**.
## Question
### 1. What is the relationship between NMNode & NMCluster & NMInstance?
From [PRS_NetworkManagementProtocol](https://www.autosar.org/fileadmin/user_upload/standards/foundation/21-11/AUTOSAR_PRS_NetworkManagementProtocol.pdf), We can get this

By reading descriptions about `NM cluster` and `NM Node`, we can easily find out that many nodes can form a cluster. But the instance says that an instance is NM status of a **cluster** inside a **node**. Is this typo or there's something that I miss understood?
And by the following limitations from the same file, we can see

So if one ECU is a node and only one instance can exist in a node, only one network is allowed in an ECU?
---
### 2. Where does the service should be placed?

Looking at the **Overview** graph in [APNM_Spec](https://www.autosar.org/fileadmin/user_upload/standards/adaptive/21-11/AUTOSAR_SWS_NetworkManagement.pdf) again, there are multiple **Handle Instances**, one **PN State Machine**, and inequal amounts(compare to handles) of **NM Instances**, each connecting to a **Network** that is assigned to different **PNs**.
So I assume a Node is an ECU, and a Node only can have one instance(according to the last question). Where's the service that is possible to include **multiple** Instances(in this case Nodes) be at?
There's no `main node` since the nodes are decentralized(Chapter 7.2). But there seems like there's a Service lives as a controller that can communicate to `State Management` using `ara::com`, one `PN State Machine` that **seems** like it can handle every individual PNs(more on that later).
My best assumption is to put it in `NM Cluster`. But does NM Cluster actually exist physically? Or it is just a virtual group that is assigned to each nodes? If this is just a virtual group how do I put an acutal Service inside it?
TLDR;
>Where should the NM Service layer(the layer including Handle Instances, PN State Machine, and NM Instances) be placed? Or how to implement this Service virtually?
---
### 3. Can Partial Network be removed(or not implemented)?
Accroding to the Spec of the protocol, we can see

But at the Requirement Document

Does this mean we can put PN aside?
Also, in the Spec of NM, it says

What does **implementation specific** means? What are we going to implement?
---
### 4. Where are the packages?
In appendix A, we can see several template classes in packages, for example:

As the table can tell, there is a package starting with `M2::AUTOSARTemplates`. After a long time of searches, I can't find anything about this package, nor can I find a single SDK. Does this package exist?