- 功能说明
目前车辆上ECU的数目越来越多，不同功能的ECU对电源有不同的要求，在点火钥匙打到OFF档（KL15停止供电）之后，有的ECU（如座椅模块）允许直接断电，有的ECU（如空调模块）需要延时断电，有的ECU（如防盗模块）需要一直带电。
需要延时断电或一直断电的节点为KL30供电的节点。KL30供电的节点在OFF档之后能进入低功耗状态，关闭大部分不需要的功能（如禁止CAN通信功能），尽可能减少电量消耗, 避免蓄电池电量消耗过多导致汽车无法启动。同时这些节点在低功耗状态下需要监控唤醒条件，如KL15信号，或CAN总线的状态等。一旦KL15开始供电，或总线上有报文（或者需要的报文，需要使用特殊的带滤波功能的收发器）等，节点应能被唤醒，进入正常工作模式。
由此可见，要实现车辆中各ECU的低功耗管理，需要实现ECU上各CAN 网络的网络管理，即对于某个CAN网络，连接到该总线上的各节点需要协同工作，遵循同样的协议以实现同步睡眠(否则进入睡眠模式的节点会被暂未睡眠节点发出的报文唤醒)。
AUTOSAR CAN Network Management（以下简称AUTOSAR CAN NM）是目前被广泛使用的一种基于协同睡眠的网络管理协议。其主要功能点如下：
- CAN NM报文的发送（包括发送请求的方式，发送确认和发送错误处理）及接收。
- 协同睡眠。各节点自身均满足休眠条件（Network Released），且总线上无任何网络管理报文，在等待一定时间后，所有节点协同进入睡眠状态。
- Bus Load Reduction Mechanism。采用普通的NM报文发送方式，总线上的负载会随着网络上节点总数的增加而增加。为了降低总线上的负载，设计了一套Bus Load Reduction Mechanism。
- 策略方案详细介绍
本方案基于AUTOSAR Specification of CAN Network Management(V3.3.0, R4.0 Rev 3)。更多细节及参数说明请参考上述文档。
-
- 状态简介及状态转换说明
AUTOSAR CanNM包含3个operational mode：
- Network Mode
其中Network Mode中包含3个子状态，如下：
- Repeat Message State
- Normal Operation State
- Ready Sleep State
- Prepare Bus-Sleep Mode
- Bus-Sleep Mode
-
- 相关（子）状态的目的如下：
-
| （子）状态 | 主要目的 |
| Repeat Message State | 节点上线监测。 |
| Normal Operation State | 保证只要任何节点对网络有需求（network is requested），就可以保持整个网络处于awake状态。 |
| Ready Sleep State | 当某个节点X想要转化到Prepare Bus-Sleep Mode时，只要网络中的任一其他节点想要保持网络awake， 节点X只能继续在Ready Sleep State下等待。也就是说，只有网络中的所有节点对网络都没有需求时，节点X才可以从Ready Sleep State转化到Prepare Bus-Sleep Mode。 |
| Prepare Bus-Sleep Mode | 保障网络上的所有节点有足够的时间停止网络的活性，在Prepare Bus-Sleep Mode下，网络的活性在逐步下降（例如存在队列发送的情况下逐步清空所有的Tx-buffer），最终完全停止网络活性。 |
| Bus-Sleep Mode | 当某个节点没有消息需要交互时，进入Bus-Sleep Mode，以减少电源消耗，通信控制器转换到sleep模式，相应的wakeup机制被激活，最终电源消耗会减少到一个适当的水平。 |
-
-
- 状态转换的说明如下：
-
上图中，状态改变相关的转化用绿色标注，错误处理相关的转化用红色标注，节点监测（可选功能）相关的转化用蓝色标注，在此状态转换图中，假设已使能bus load reduction 功能。
下图是一个拥有3个节点的网络中，各节点从power-on 到bus sleep 的示例说明。
正在上传…重新上传取消
其中TRMT代表配置参数CanNmRepeatMessageTime {CANNM_REPEAT_MESSAGE_TIME}
TTO代表配置参数CanNmTimeoutTime {CANNM_TIMEOUT_TIME}
TWBS代表配置参数CanNmWaitBusSleepTime {CANNM_WAIT_BUS_SLEEP_TIME}
-
- 通信机制
- 发送机制
- 发送请求的方式
- 发送机制
- 通信机制
各种配置和状态下发送请求方式的说明如下：
正在上传…重新上传取消
-
-
-
- 发送确认
-
-
正在上传…重新上传取消
-
-
-
- 发送错误处理
-
-
CANNM_PASSIVE_MODE_ENABLED=TRUE或CANNM_IMMEDIATE_TXCONF_ENABLED= TRUE时CanNm 模块不使能发送错误处理。
当请求发送一个NM 报文时，NM Message Tx Timeout Timer会开始计时，超时值设置为CANNM_MSG_TIMEOUT_TIME。
当CanNm_TxConfirmation被CanIf调用时，NM Message Tx Timeout Timer会被停止清零。
当NM Message Tx Timeout Timer发生超时时，CanNm可以调用Nm_TxTimeoutException函数（可选）。
-
-
- 接收机制
-
当一个NM报文被成功接收，CanIf模块会调用回调函数CanNm_RxIndication。在该回调函数中，CAN NM会拷贝CanNm PDU相关的数据到内部buffer。
-
- Bus Load Reduction Mechanism
NM PDU的发送周期通常由时间参数CANNM_MSG_CYCLE_TIME来决定。对于属于一个网络的所有节点，该参数均相等。这样会导致总线上的负载会随着网络上节点总数的增加而增加。为了降低总线上的负载，可以采用Bus Load Reduction Mechanism。该机制如下：
如果成功发送NM PDU，发送周期定时器重新设置为CANNM_MSG_CYCLE_TIME。
如果成功接收NM PDU，发送周期定时器重新设置为节点特定的参数CANNM_MSG_REDUCED_TIME，此参数须在CANNM_MSG_CYCLE_TIME的0.5至1倍之间。
这会导致如下的结果：
整个网络上只有时间参数CANNM_MSG_REDUCED_TIME值最小的两个节点在轮流发送NM PDU,如果这两个节点A,B中有一个节点停止发送，则其余（且请求网络的）节点中CANNM_MSG_REDUCED_TIME值最小的那个节点C开始发送NM PDU,如果网络上只剩一个节点请求网络，则其NM PDU的发送周期为CANNM_MSG_CYCLE_TIME。
此机制保证了总线负载限制在每CANNM_MSG_CYCLE_TIME里最多两个NM报文。
正在上传…重新上传取消
-
- Network Management PDU 结构
正在上传…重新上传取消
