AUTOSAR基础篇之CanNM

前言

首先，问大家几个问题，你清楚：

• 为什么要引入网络管理呢？上电同时启动，下电同时关闭，它不香吗？
• 你知道车上的ECU节点可以分为哪几种类型吗？
• 汽车启动时，ECU之间怎么保持同步唤醒的呢？
• 下电时，ECU又是怎样协同罢工的呢？
• 汽车熄火后，什么样的ECU会继续工作呢？

这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：

---

正文

网络节点类型

汽车上ECU节点千千万万，不可能ignition On时所有ECU都正常工作，而是当用户需要请求相关功能时，参与该功能的相关ECU节点才需要启动起来，否则带来的只是过多对电池的无用消耗。

为了更好的去利用整车的能源，防止出现不必要的电池浪费，网络管理（Network Management，以下简称NM）便可以很好的解决此类问题，最大可能的高效利用整车电池能源，节约用车成本，延长电池使用寿命。

虽然汽车上网络总线类型多种多样，有CAN，FlexyRay、Lin、Ethernet等，但基本原理相似，本文将以最为常见的CAN总线的NM来讲述，举一反三，对于其他总线的NM，AUTOSAR也有相关规范，大家可以自行去阅读学习。

一般而言，按照唤醒方式，我们可以将ECU网络节点类型划分为两大类：本地唤醒与远程唤醒。

本地唤醒：唤醒源来源于自身模块，比如常说的KL15硬线唤醒或者hardware sensor感知唤醒等；

远程唤醒：唤醒源来源于自身ECU节点所在的网络报文，该节点可以处于完全休眠状态，一般无静电消耗；

根据这两大类唤醒方式，可以组合出下列四种子唤醒方式，每种方式的供电方式如下图所示：

仅本地唤醒

​ 图1 本地唤醒节点
​

特点：ECU始终保持after-running状态，当检测到本地唤醒源之后，就会开启网络通信；

仅网络唤醒

​ 图2 仅网络管理唤醒节点
​

特点： 只有当Transceiver监控到总线电平变化或者特定报文时，就会接通Vreg给到芯片供电，从而唤醒ECU；

本地+网络唤醒

​ 图3 本地+网络唤醒节点
​

特点： ECU始终保持After-Running模式，当接收到本地唤醒源或者网络唤醒源时，就会启动ECU；

类KL15电唤醒

​ 图4 KL15电唤醒节点
​

特点： 仅当Power supply 连接至ECU时，ECU才会正常工作，比如常说的KL15唤醒。

NM状态机

本文对于本地唤醒方式不作过多讨论，因为本地唤醒本身就是一种供应商自定义的一种唤醒方式，比较直接，不需要其他ECU节点参与，同时也不会对其他ECU节点造成影响。

但是网络唤醒是以网络管理报文为基础来协同整个网络“同睡同醒”，采用分布式的直接网络管理方式来发送自身节点所需的网络管理请求及自身网络管理状态，并接受来自网络上其他ECU节点的网络管理请求与状态。

因此，对于这些NM状态的变化我们有必要进一步研究NM状态机的状态及它们之间状态转换关系。该状态机的状态类型可分为“三大三小”。其中“三大”指的是Bus Sleep Mode、Network Mode、Prepare Bus-Sleep Mode；而“三小”则值得是Network Mode下的三个子状态：Repeat Message State、Normal Operation Mode、Ready Sleep Mode。

Bus Sleep Mode

当没有远程唤醒或者本地唤醒请求时，ECU的Controller应当切换至Sleep模式，电流消耗将降低至最低水平，该Mode是ECU启动时的起始状态或者是ECU睡眠时的最终状态。

在该模式下，NM报文以及应用报文都应该被禁止发送，但是可以被网络上的报文唤醒。

在此特意说明一点，当Transiver支持并使能了特定帧唤醒时，该ECU只会接受到特定的NM报文才会正常唤醒，否则就会一直处于休眠状态，能够不受网络上应用报文的干扰。

如果Transiver不支持特定帧唤醒，那么网络的任意报文都可以唤醒该ECU，如果唤醒条件不满足，又会走休眠流程继续睡下去，这样“睡醒交替”的方式就是不支持特定帧唤醒的Transiver的典型特征。当然，如果整车上的NM都可以正常运作，那么就不会频繁出现这种“睡醒交替”的方式，这种方式一般都是在做测试时才会较多的体现出来。

Network Mode

一旦进入Network Mode，计时器T_NM_Timeout就会启动，只要成功接收到来自总线上的NM报文或者成功发送至总线NM报文，都会将该计时器T_NM_Timeout重置。

该模式又进一步细分为以下三种子状态，RMS、NOS、RSS。

• Repeat Message State（RMS）
  
• • 该状态能够确保当ECU的状态机从Bus-Sleep Mode或者Prepare Bus-Sleep mode切换至Network Mode时能够及时的被网络上其他ECU节点发现，也就是告诉其他ECU，“大家注意了，我成功上线了，请多多指教！”
  • 当成功进入到RMS状态时，该节点就会重新发送NM报文并开启计时器T_REPEAT_MESSAGE，应用报文则需要等待第一帧网络管理报文发送之后再发送。
  • 当然，第一帧NM报文可以通过配置参数MSG_CYCLE_ OFFSET来延迟发送，降低在同一时间内的总线负载，这个配置参数默认是0 ，一般根据测试结果来做适当的调整。
  • 在计时器T_REPEAT_MESSAGE超时之前，该节点就会一直保持在该状态，否则将会离开该状态。
  • 在该状态下也存在着两个子状态：
    
  • • NM Immediate Transmit State
      在该模式下，ECU的目的是快速唤醒整个网络，同时该节点将会以配置参数T_NM_ImmediateCycleTime的周期发送NM报文，而发送次数则是由配置参数N_ImmediateNM_TIMES来决定，每一次成功发送，该参数就会减1，直至为0，退出该子状态；
    • NM Normal Transmit State
      在该模式下，ECU节点将会以正常报文周期T_NM_MessageCycle的方式来发送NM报文。

• Normal Operation State（NOS）
  只要ECU节点自身存在网络通信的需要，那么ECU就会一直工作在NOS的状态下。该状态下NM报文的发送将会以T_NM_MessageCycle的周期来发送报文，每次报文的成功发送或接收或者计时器NM-Timeout超时都会重置该计时器NM-Timeout；
  在该状态下的NM报文以及应用报文都应该正常收发通信。
• Ready Sleep State（RSS）
  在该模式下，ECU节点应当停止发送NM报文。每次成功接受到来自网络上的NM报文，计时器T_NM_TIMEROUT 就会重置，一旦T_NM_TIMEROUT 超时，那么就会离开该状态转而进入Prepare Bus-Sleep状态。
  

Prepare Bus-Sleep Mode

一旦进入该模式，计时器T_WAIT_BUS_SLEEP就会启动。在该模式下禁止网络管理报文的发送，允许接受NM报文。应用报文已经在buffer中的一般允许继续发送，但最终应该是silent bus，该ECU的Controller的状态应当处于operational mode。一旦T_WAIT_BUS_SLEEP超时，就会进入到Bus-Sleep阶段。

Passive Mode

在该模式下只接受NM报文，但不发送任何的NM报文。该模式可以通过配置得到，同时该模式应只存在于开发或者调试过程中，在正式SOP的软件中禁止出现此种模式。

报文发送与接受状态

在测试的过程中，需要针对网络管理每一个状态下的NM报文与APP报文接收与发送进行测试。如下图所示，体现了在不同NM子状态下的报文发送与接受状态。

• Bus-Sleep阶段，只接收NM报文唤醒，不发送任何报文；
• Pre-Bus-Sleep阶段，同样仅允许接收NM报文，对于早已在发送Buffer中的APP报文应发送完毕后立刻停止APP报文；
• 在Network Mode模式下，除了在Ready Sleep阶段不允许发送NM报文之外，其余阶段APP报文与NM报文正常收发；

图5 NM过程中报文收发状态
​

状态机时间参数总结

鉴于在网络管理各子状态的切换过程中都依赖于各种计时器，为了便于后续状态机切换的讲述以及后续查表方便，将相关参数总结如下，以供参考。

图6 NM计时器参数表
​

NM状态机切换

NM状态机是整个网络管理的核心。从上述内容可知NM管理状态机总共分为3种模式：Bus-Sleep、Pre-Bus-Sleep以及Network Mode。

其中Network Mode 又可分为3个子状态：Repeat Message State、Normal Operation State以及Ready Sleep State。

其中Repeat Message State又可分为Immediate Transmit State与Normal Transmit State。

如图7所示，根据以下状态切换路径来一一讲解各个状态的切换。

图7 NM状态机切换
​

唤醒源一般可分为本地唤醒源与远程唤醒源。

• 本地唤醒源：主要指的是基于内部计时器、传感器、按钮或者硬线连接或者基于内部状态的自身请求等。
• 远程唤醒源： 主要指的是来自网络上的NM报文或者其他相关信号，比如点火开关信号等。

在ECU被唤醒前，软件内部状态机应当充分实现唤醒源的可靠性检查，如果检查失败，应当禁止进入Network Mode。

绝大部分情况下，需要支持NM的ECU都始终连接着KL30电。在这种情况下，ECU是否被启动（存在静态电流消耗），则取决于网络上是否存在任意报文或者存在特定的NM报文。需要注意的是特定的NM报文唤醒方式则取决于是否采用支持特定帧唤醒的Transiver。

• NM_01(系统初始化):
  当系统KL30启动或者接收到来自网络的唤醒源时，则会执行系统初始化，在初始化的过程中，则会执行CanNM_Init来实现NM的初始化。如果唤醒条件不满足，ECU就会一直停留在Bus-Sleep 阶段，直至满足条件休眠或者被正常唤醒。
  
• NM_02(Bus-Sleep to RMS):
  当ECU处于Bus-Sleep阶段时，如果接收到有效的NM报文，则会进入到Normal Transmit State。当进入到该阶段后，在T_REPEAT_MESSAGE 超时前，ECU将按照T_NM_MessageCycle周期来传输报文，同时T_MESSAGE_TIMEOUT也会启动。
  
• NM_03(Bus-Sleep to RMS):
  当ECU在Bus-Sleep阶段，存在本地唤醒请求时，ECU应当主动激活网络，并进入Immediate Transmit State阶段，同时将发送的NM报文中的Active Wake up bit置为1。
  在该状态下，应当按照N_ImmediateNM_TIMES的次数发送报文周期为T_NM_ImmediateCycleTime的网络管理报文。
  
• NM_04:
  当N_ImmediateNM_TIMES 等于0之后，NM状态就会从Immediate Transmit State进入到Normal Transmit State。
  
• NM_05(RMS to RMS):
  在RMS阶段，如果T_NM_TIMEROUT超时，当前NM状态不会被改变，但是T_NM_TIMEROUT会被重置。当T_MESSAGE_TIMEOUT超时后，则会调用相应的exception函数通知上层进行处理。
  
• NM_06(RMS to NOS):
  当处于RMS阶段时，T_REPEAT_MESSAGE超时后，ECU需要继续保持网络通信的需要，即通过调用CanNM_NetworkRequest函数进入到NOS阶段，而ECU则会继续按照T_NM_MessageCycle来发送NM报文。
  
• NM_07(NOS to RMS):
  在NOS阶段，有两个RMS子状态可以到达：Immediate Transmit State 与 Normal Transmit State。如果自身节点有repeat message的需要，那么则会进入到Immediate Transmit State。如果接收到的NM中repeat message bit置1，则进入到Normal Transmit State。
  
• NM_08(NOS to NOS):
  在NOS阶段，如果T_NM_TIMEROUT超时，当前NM状态不会被改变，但是T_NM_TIMEROUT会被重置。当T_MESSAGE_TIMEOUT超时后，则会调用相应的exception函数通知上层进行处理。
  
• NM_09(NOS to RSS):
  当休眠条件满足时，ECU就会通过CanNm_NetworkRelease函数来实现从NOS至RSS状态。在RSS状态下应当停发NM报文。
  
• NM_10(RSS to NOS):
  在RSS状态下，如果存在本地唤醒请求，则可以通过CanNm_NetworkRequest函数来切换至NOS状态。
  
• NM_11(RSS to RMS):
  在RSS状态下，RMS存在两种子状态可供进入：Immediate Transmit State与 Normal Transmit State。当自身节点存在repeat message请求时，则会进入前者；当接受到外部的NM报文中repeat message bit为1时，则进入后者。
  
• NM_12(RMS to RSS):
  当ECU处在RMS状态中的Normal Transmit State状态下，如果T_REPEAT_MESSAGE超时且满足休眠条件时，则会进入RSS状态。
  
• NM_13(RSS to Pre-Bus-Sleep):
  在RSS状态下，如果没有本地唤醒请求或者远程唤醒请求，在计时器T_NM_TIMEROUT 超时之后就会进入Pre-Bus-Sleep 阶段，同时T_MESSAGE_TIMEOUT置为0，启动T_WaitBusSleep计时器。
  
• NM_14(Network Mode to Network Mode):
  在Network Mode下，当成功接受或者发送NM报文时T_NM_TIMEROUT 就会被重置，重置该定时器的行为就发生在调用函数CanNM_RxIndication或者CanNM_Txconfirmation接口中。
  
• NM_15(Pre-Bus-Sleep to RMS):
  在Pre-Bus-Sleep模式下，如果存在远程唤醒请求，则会进入到RMS阶段中的Normal Transimit State。同时启动T_REPEAT_MESSAGE。
  
• NM_16(Pre-Bus-Sleep to RMS):
  在Pre-Bus-Sleep模式下，如果存在本地唤醒请求，即调用函数接口CanNm_NetworkRequest来进入到RMS中的Immediate Transmit阶段，应当按照N_ImmediateNM_TIMES的次数发送报文周期为T_NM_ImmediateCycleTime的网络管理报文。
  
• NM_17(Pre-Bus-Sleep to Bus-Sleep):
  在Pre-Bus-Sleep模式下，如果不存在本地唤醒或者远程唤醒请求，则进入到Bus-Sleep状态。至于何时关闭电源控制，则可以根据自身节点类型来shutdown。
  

网络管理报文结构

NM报文作为传递自身节点的NM状态的重要载体，有必要仔细研究报文中每一位Bit的含义。

接下来就以CAN NM报文为例，来一同解析其报文总体结构以及各个Bit的相应含义，以便了解个ECU节点的协同唤醒与休眠方式。

NM报文总体结构解析

如下图8所示，根据最新的AutoSAR官方文档的介绍：

​图8 NM报文结构
​

由图可知，Byte 0表示当前节点的Source ID，比如如何当前节点发送的NM报文ID为0x514，那么该Source ID就为0x14；Byte1则为CBV，该字节中传递着当前节点的网络状态，是非常重要的字节；其余字节作为User Data给到客户自行定义，如定义当前唤醒源有哪些？网络管理状态机切换过程等。

当然上述报文内容定义只是AutoSAR举例说明，Source ID可以被分配至Byte0，Byte1或者没有，而CBV也是可被分配至Byte0，Byte1或者没有。这些字节内容的分配与定义一般均可以在BSW工具链中进行配置。

CBV详解

鉴于CBV的重要性，如下图9所示，讲解每一个Bit在使用中的具体含义：

​ 图9 CBV Byte定义
​

Bit 0: Repeat Message Request Bit

• 0: 代表存在Repeat Message Request ；
• 1：代表不存在Repeat Message Request ；

Bit 1：PN ShutDown Request Bit（PNSR）

• 0：NM报文中不包含同步局部网络管理休眠请求；
• 1：NM报文中包含同步局部网络管理休眠请求；

Bit 3：NM Coordinator Sleep Bit

• 0：未被主协调NM节点请求开始同步休眠；
• 1：已被主协调NM节点请求开始同步休眠；

Bit 4： Active Wakeup Bit

• 0：节点没有唤醒过网络，属于被动唤醒；
• 1：节点唤醒过网络，属于主动唤醒；

Bit 5: PN Learning Bit(PNL)

• 0: PNC learning被请求
• 1: PNC learining未被请求

Bit 6 PN Information Bit(PNI)

• 0: NM报文中包含PN 信息；
• 1:NM报文中未包含PN 信息；

上述几个Bit中，经常使用到的也就Bit0，Bit3，Bit4, Bit6这4位，需要重点掌握。

常用函数接口

为了更好的使用该模块函数以及遇到问题时方便调试该模块，特将CanNM模块中较为重要的常用函数列举如下图10所示。