1、NM是用来做什么的；

不管是传统的燃油车还是新能源车，车上都有各种各样的ECU，而所有这些ECU都是需要用电的，而车上的供电单元一般是蓄电池，因此蓄电池的电量是有限的，对于新能源车来说太耗电无疑会给电池的续航里程带来巨大影响，因此为了尽可能的省电，所以就提出了网络管理，也就是说网络管理一个最重要的作用就是为了省电。

那么网络管理是如何来实现省电的呢？我们知道车上的所有ECU之间会通过CAN通信、Flexray或以太网等进行相互通信连接在一起，那么网络管理就是通过在各个ECU的网络上，发送一些命令制定一套规则，来实现各个ECU的协同睡眠和唤醒。

什么是ECU的睡眠和唤醒？为了支持睡眠和唤醒，ECU的芯片必须支持低功耗模式和正常工作模式的切换。低功耗模式（ECU睡眠）指一个ECU断电或者处于极少数的外围器件工作的模式；唤醒指的是ECU处于全工作模式。

总结下：其实网络管理就是用来节约能源，有效的实现车上的ECU的协同睡眠和唤醒。

android 车机休眠启动 startService 没反应_CAN

AUTOSAR中网络管理主要使用了CAN接口(CanIf)，并提供通用网络管理接口(NmIf)。CAN网络管理在CAN架构中所处的位置。

2. AutoSar中网络管理的原理；

  我用比较多的CAN网络管理为例来进行说明，我会主要围绕其中最重要的一个状态机来进行介绍。

  网络管理最终要实现的是车上的ECU能够协同睡眠以及唤醒，也就是说网络管理最重要的一点是要保证车上的ECU能够协同唤醒和休眠。那么假如车上的ECU都处于睡眠模式，网络上都没有报文，你咋实现唤醒呢，其实，一般不会让所有的ECU都处于睡眠模式，这个时候可能会有极少的ECU处于工作状态，比如车上的BCM。也就是说有一些ECU是通过KL15直接唤醒的，而有些是通过CAN报文唤醒。当然或许后面会升级到更加节能的模块，可以不需要钥匙信号，这些模块在睡眠状态时，耗能非常少，因此可以一直处于可唤醒状态。

唤醒请求(Wake Up Request)

唤醒请求可分为两种：

● 主动唤醒请求：来自模块内部对网络的请求。主动唤醒节点的网络管理报文必须先于应用报文发送。

● 被动唤醒请求：来自总线上其他模块对该模块的网络请求。被动唤醒的节点，发送网络管理报文和应用报文的先后顺序无特别要求。

网络状态（Network States）

节点的网络状态包括以下两种：

● 网络请求：模块需要主动与总线上其他节点进行信息交换时，它必须通过发送网络管理报文来请求网络，并将其网络状态设置为“网络请求”；

● 网络释放：模块不需要主动与总线上其他节点进行信息交换时，必须将其网络状态设置为“网络释放”；需要注意的是，在网络释放状态下模块仍可能因总线上的其他节点请求网络而与其进行信息交互。

总线唤醒(Bus wake up)

采用AUTOSAR CAN 网络管理方式的ECU必须选择符合 ISO 11898-5 标准的高速 CAN 收发器。若ECU处于低功耗模式，仅在总线上出现符合ISO 11898-5标准定义的唤醒序列，且该 ECU成功接收到该网段定义的唤醒报文时才能够被总线唤醒。这里这条唤醒报文必须是该网段中 ECU 的网络管理报文。

  为了满足这种协同唤醒和睡眠，我们下面来看看Autosar中的NM是如何实现协同的。

android 车机休眠启动 startService 没反应_Network_02

如图所示，状态机中有三个主状态，分别是BusSleep睡眠模式、PreSleep预睡眠模式、Network网络模式三个状态；其中Network状态又分为三个子状态，分别是RepeatMsg重复报文状态、NormalOperate常规操作状态、ReadySleep准备睡眠状态。下面我来讲一下每个状态它的作用。

  • BusSleep睡眠模式：这个状态就是我们所说的休眠状态，这个状态下是不发送网络管理报文也不收发应用报文，一般该状态时一个低功耗的状态，也就是我们上文提到的协同睡眠状态。当然我们上电初始化时，也会默认进入该状态。（当节点没有主动网络唤醒及被动唤醒请求时，ECU 通信控制器切换至睡眠模式，ECU功耗降低至适当水平。在睡眠模式下，节点的网络管理报文和应用报文禁止发送，并且不能对总线上的报文进行ACK应答。同时节点在该模式下，如果检测到有效的唤醒源，节点必须被唤醒）。
  • PreSleep预睡眠模式：这个状态是进入休眠状态的前一准备状态，这个状态一般不发送网络管理报文帧了，也不发送应用报文了，只是等待其他ECU一起睡眠，为啥要这个状态呢，其实就是实现‘’协同‘’两个字，也就是让等一段时间让车上所有ECU实现一起睡眠，其实这个一起睡眠还是比较重要的，比如车上某个ECU的工作与其他ECU的工作是关联的，比如VCU（整车控制器）和INV（电机控制器），有可能VCU不发报文了，会导致INV报故障，因此这种情况是要避免的。（在预睡眠模式下，总线活动静止下来，最终达到总线上没有活动，ECU通信控制器状态处于工作模式。在该模式下，节点的网络管理报文和应用报文禁止发送，但应该对总线上的报文进行 ACK应答。节点的网络管理状态必须保持预睡眠模式一段时间，一旦超时，网络管理状态应该离开预睡眠模式，进入睡眠模式。）
  • Network网络模式：这个状态是允许ECU进行正常通信的，一般这个状态下即可以收发网络管理报文帧也可以收发应用报文（包括诊断报文），意思就是唤醒状态。接下来我来解释一下这个状态下里面的三个子状态的含义： 1、RepeatMsg重复报文状态：表示重复发网络管理报文的状态。重复报文状态包含两个子状态：网络管理报文快速发送状态和网络管理报文正常发送状态。
    NM PDU 快速发送状态：节点在进入NM PDU快速发送状态时，必须开启或重置NM-Timeout Timer，为了快速唤醒网络，必须以快速周期发送网络管理报文，同时不得发送正常周期网络管理报文；所有的应用报文必须在第一帧快速NM PDU报文发送开始后延迟一定时间才能发送。在NM PDU快速发送状态下，节点一旦接收或发送一条网络管理报文，或者NM-Timeout Timer超时，NM-Timeout Timer会立即重置。
    NM PDU 正常发送状态：进入NM PDU 正常发送状态后，节点必须以正常周期发送网络管理报文。若节点因被动唤醒请求进入NM PDU正常发送状态，必须开启NM-Timeout Timer，同时所有的应用报文必须从节点检测到唤醒请求后延迟Tx_Enable_Time 才能发送。在NM PDU正常发送状态下，节点一旦接收或发送一条网络管理报文，或者 NM Timeout Timer超时，NM Timeout Timer会立即重置。
    节点的网络管理状态保持重复报文状态一段时间（这段时间一般可以配置），一旦超时，网络管理状态会离开重复报文状态。在该状态下，节点的网络管理报文和应用报文能够正常发送。
    一般我们进入网络（Network）状态时，首先会进入这个状态，这个状态下会快速的发送一些网络管理报文帧出来，为啥要快速发送一些网络管理报文呢？其实就是想尽快的告诉车上的其他ECU，我上线了！我要正常通信了，大家请注意啊，大家也和我一块进行整车通信啊。就是以上这个意思。
  • 2、NormalOperate常规操作状态：在进入RepeatMsg一段一时间后，如果需要通信，就会跳到正常工作状态，正常工作状态会按照正常的周期发送网络管理报文以及所有应用报文正常进行通信，可以说这个状态就是真正的唤醒状态。（在常规操作状态下，节点一旦接收或发送一条网络管理报文，或者NM-Timeout Timer超时，NM-Timeout Timer应该立即重置。在该状态下，节点的网络管理报文和应用报文必须正常发送。）
    3、ReadySleep准备睡眠状态：如果唤醒后，需要休眠，那么我们可能需要做一些准备工作才能允许我们的ECU进入休眠，比如这个时候有一些数据要存储、比如电机控制器检测到电机还没停下来等等情况，因此这个状态就是用来做一些休眠前的准备工作，我们可以看到，任何从唤醒到休眠的过程，都需要经过这个状态，也就是说睡眠前有些准备工作是必须要完成的。那么这个状态下，其实还是能够进行通信的，只有进入PreSleep状态，才会把相应的应用报文收发关闭以及发送NM报文关闭。还有一点要声明的是，一般网络管理报文帧的接收不会关闭。（节点进入准备睡眠状态后，必须停止发送网络管理报文，所有的应用报文在NM Timeout Timer超时后必须停止发送。在准备睡眠状态下，节点一旦接收到一条网络管理报文，NM Timeout Timer会立刻重置。NM Timeout Timer超时，节点的网络管理状态应该进入预睡眠模式。）

android 车机休眠启动 startService 没反应_初始化_03

3.网络管理报文(NM PDU)

AUTOSAR CAN 网络管理报文的数据场格式如下表所示:

android 车机休眠启动 startService 没反应_网络管理_04

源节点标识符(Source Node Identifier)

NM PDU的字节 0 用于发送源节点标识符，每一个 ECU 都会被分配一个唯一的标识符，来告知接收节点该 NM PDU 是由哪个节点发送的。

控制比特向量(Control Bit Vector)
NM PDU 的字节 1 被分配用于发送控制比特向量。其中：
bit 0 :重复报文状态请求位;
bit 3 :网络管理睡眠协调位；
bit 4 :激活唤醒位；
bit 6 :部分网络信息位；
其他bit位暂时预留。

android 车机休眠启动 startService 没反应_网络请求_05

用户数据域(User Data)

网络管理报文的字节 2 到字节 7 用于发送用户自定义的数据信息，这些字节目前各项目为扩展预留，都被填充为‘0x00’。

4、网络管理状态切换(Network Management State Transition)

android 车机休眠启动 startService 没反应_CAN_06

Condition_01
节点供电状态从电池off切换到电池on 后，节点必须进行网络管理模块CanNm初始化，初始化完成后节点必须进入睡眠模式，并且需要立即具备被主动唤醒请求或者被动唤醒请求唤醒的能力；

Condition_02
当节点处于睡眠模式时，如果收到有效的网络管理报文，那么节点将离开睡眠模式并进入重复报文状态中的NM PDU正常发送状态。进入NM PDU正常发送状态后，在计时器Repeat Message Timer超时以前，节点必须以正常周期发送网络管理报文。在节点收到网络管理报文时，它向总线发出的第一帧报文可以是网络管理报文也可以是应用报文。

Condition_03
如果节点在睡眠模式下检测到主动唤醒请求，那么节点必须发送网络管理报文来主动唤醒网络，在节点主动唤醒网络的过程中，必须首先进入NM PDU快速发送状态。当节点因主动唤醒请求需要唤醒网络时，必须快速发送连续NM PDU报文。

Condition_04
处于NM PDU快速发送状态的节点，在计数器为零时，节 点 将 进 入NM PDU正常发送状态，并开始等待一段时间后以正常周期发送网络管理报文。

Condition_05
处于重复报文状态下的主动请求网络节点，如果Repeat Message Timer 发生超时，但节点的主动网络请求仍持续存在，节点必须进入常规操作状态。节点继续保持以正常周期发送网络管理报文和应用报文PDU。

Condition_06
处于常规操作状态的节点，如果释放所有的网络请求，不再需要主动请求网络，那么它必须立即将网络管理状态切换到准备睡眠状态，同时该节点必须立即停止发送网络管理报文。

Condition_07
处于准备睡眠状态的节点，如果检测到主动网络请求，节点必须立刻进入常规操作状态，同时必须开始以正常周期发送网络管理报文和应用报文PDU。

Condition_08
处于重复报文状态的NM PDU正常发送状态的节点，如果没有检测到主动网络请求，一旦 Repeat Message Timer超时，节点将进入准备睡眠状态。

Condition_09
处于准备睡眠状态的节点如果没有检测到主动网络请求，一旦NM Timeout Timer超时，节点将进入预睡眠模式。

Condition_10
处于预睡眠模式的节点，如果收到被动唤醒请求，节点将进入重复报文状态的NM PDU正常发送状态。

Condition_11
处于预睡眠模式的节点，如果检测到主动唤醒请求，节点将进入重复报文状态的NM PDU快速发送状态。

Condition_12
处于预睡眠模式的节点如果不再收到主动或被动唤醒请求，一旦Wait Bus-Sleep Timer超时，节点将进入睡眠模式。

Condition_13
在任何状态下发生电池掉电，节点都将进入关闭模式，不再拥有任何通信和网络管理的功能。AUTOSAR网络管理的算法与处理器无关，即它不依赖于任何处理器特定的硬件支持，因此可以在AUTOSAR范围内的任何处理器架构上实现。

5.状态转换的时序图

当唤醒请求（主动唤醒请求、被动唤醒请求）将节点的网络管理状态激活时，该节点的所有应用报文必须延迟一定时间后才能够开始发送。网络中的被唤醒节点网络管理报文的发送不受 延迟时间的限制，可以在它结束前发送，但首帧网络管理报文必须在节点进入重复报文状态后再延迟一定时间发送，以避免被唤醒节点同时发网络管理报文而形成网络拥堵。

NM信号发送的时序图

android 车机休眠启动 startService 没反应_初始化_07

NM信号接收的时序图

android 车机休眠启动 startService 没反应_Network_08

NM协调过程

android 车机休眠启动 startService 没反应_网络管理_09

在睡眠的过程中，一旦NM Timeout Timer超时，节点所有的应用报文必须立刻停止发送。上图描述的案例是针对单一主动唤醒请求触发的唤醒与睡眠过程，当多个唤醒请求交错发生时，各唤醒请求必须遵守各自的定时参数，不会互相影响。

6.举例介绍

客户的需求是一个标准的AutoSar架构的网络管理。

在休眠状态，我们的ECU只有CAN收发器处于工作状态，也就是说能检测NM报文，当然这个是通过芯片来实现的。

我们的ECU连接上了KL15信号，那么我们的ECU支持KL15唤醒以及NM报文唤醒，也就是有效唤醒源是这两种。

下面我以NM报文唤醒为例，大概说一下唤醒的过程。

在睡眠状态，车上网络状态是没有报文的，一旦车上BCM检测到要使用网络时，就是第一时间发出网络管理报文出来，这个时候我们的ECU也会收到该网络管理报文，因此会唤醒我们的ECU，首先我们的ECU的收发器收到NM报文后，告诉芯片要唤醒了，这个时候就会给控制器供电，然后程序就会初始化，进入BusSleep状态，接着会进入RepeatMsg模式，这个时候会迅速发出第一帧NM报文，会快速发出5帧NM报文（如周期10ms），让其他节点知道我们的ECU醒来了，然后会切换到正常周期的NM报文（如50ms），当然这个时候，系统也在初始化，应用报文也会到一定周期能够正常收发。处于RepeatMsg状态一定时间后，会切换到NormalOpr模式，这个时候就会正常通信了。这个模式下NM报文是以一定周期发送的如500ms，告诉所有节点我在正常通信。其实NM报文里面是有一些信息的，比如唤醒原因，用户数据等等，这些都可以去定义。

下面讲一下NM休眠的过程：

处于NormalOpr状态下，如果ECU不需要网络了，比如KL15断开，ECU这个时候就会选择释放网络，释放网络就是从Normal状态切换到ReadySleep状态，这个时候会进行一些故障存储、下电前的装备工作，完成后，等待一定时间就会进入到PreSleep状态，这个状态将会把应用报文和TX网络管理报文也关闭，等待一定时间就会进入BusSleep状态，进入BusSleep后，会让控制器进入休眠。

模式转换具体步骤：

android 车机休眠启动 startService 没反应_初始化_10

01-蓄电池上电

02-ECU主动唤醒网络

03-ECU被动唤醒网络

04-快发状态发完规定的网络报文（周期和帧数可定义）后进入正常发送状态

05-有网络需求的ECU进入正常工作状态

06-网络管理数据的Repeat bit 被置1

07-ECU释放网络请求

08-ECU有网络请求

09-无网络需求的ECU直接进入准备睡眠状态

10-网络管理数据的Repeat bit 被置1

11-NM Timeout Timer 溢出

12-ECU有网络需求并主动唤醒网络

13-网络有需求，ECU被动唤醒

14-Bus Sleep timer溢出

15-断开蓄电池

以主动唤醒ECU举例，假定主动唤醒源为KL 15 ON。

整个流程：

01——KL 15 ON——02——04——05，如果KL 15 一直为ON，则ECU保持在常规操作状态。当KL 15 OFF后——07——其他ECU也无网络需求——11——14.

以被动唤醒ECU举例，流程如下：

01——03——09——其他ECU也无网络请求——11——14.

综上所述，ECU网络管理的实现的核心就是实现上述的状态机，在AUTOSAR中，这些状态之间的跳变就是由AUTOSAR定义的各种接口函数实现的。