AUTOSAR网络管理

1. 功能说明

目前车辆上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）是目前被广泛使用的一种基于协同睡眠的网络管理协议。其主要功能点如下：

1. CAN NM报文的发送（包括发送请求的方式，发送确认和发送错误处理）及接收。
2. 协同睡眠。各节点自身均满足休眠条件（Network Released），且总线上无任何网络管理报文，在等待一定时间后，所有节点协同进入睡眠状态。
3. Bus Load Reduction Mechanism。采用普通的NM报文发送方式，总线上的负载会随着网络上节点总数的增加而增加。为了降低总线上的负载，设计了一套Bus Load Reduction Mechanism。

1. 策略方案详细介绍

本方案基于AUTOSAR Specification of CAN Network Management(V3.3.0, R4.0 Rev 3)。更多细节及参数说明请参考上述文档。

1. 1. 状态简介及状态转换说明

AUTOSAR CanNM包含3个operational mode：

1. Network Mode

其中Network Mode中包含3个子状态，如下：

1. Repeat Message State
2. Normal Operation State
3. Ready Sleep State

1. Prepare Bus-Sleep Mode
2. Bus-Sleep Mode
   1. 1. 相关（子）状态的目的如下：

（子）状态	主要目的
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机制被激活，最终电源消耗会减少到一个适当的水平。

1. 1. 1. 状态转换的说明如下：

上图中，状态改变相关的转化用绿色标注，错误处理相关的转化用红色标注，节点监测（可选功能）相关的转化用蓝色标注，在此状态转换图中，假设已使能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}

1. 1. 通信机制
      1. 发送机制
         1. 发送请求的方式

各种配置和状态下发送请求方式的说明如下：

正在上传…重新上传取消

1. 1. 1. 1. 发送确认

正在上传…重新上传取消

1. 1. 1. 1. 发送错误处理

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函数（可选）。

1. 1. 1. 接收机制

当一个NM报文被成功接收，CanIf模块会调用回调函数CanNm_RxIndication。在该回调函数中，CAN NM会拷贝CanNm PDU相关的数据到内部buffer。

1. 1. 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报文。

正在上传…重新上传取消

1. 1. Network Management PDU 结构

正在上传…重新上传取消