一文详解整车网络管理指南

01

网络管理初识

为了更加通俗易懂地介绍网络管理，先来构建一个例子来进行说明，如下所示：

对该图稍作说明：

对于一个控制器而言，它可能存在多种唤醒源，包括本地唤醒和网络唤醒等方式，图中这两种方式都存在；    

对于一个控制器参与CAN通讯，其他硬件组成有CAN收发器，CAN控制器和微控制器；

不同CAN总线网络通过网关才能进行通讯。

当整车处于休眠状态，即所有的控制器都睡觉了，在整车某个休眠唤醒场景下，制动踏板行程传感器BPS感知到变化了，从而唤醒的硬线信号有了变化，被IEB检测到了，那么处于休眠的IEB将被唤醒，对应着图中1区域，这里IEB称为主动唤醒节点。

此时，为了实现这个唤醒场景的功能，需要参与其他一些控制器，比如EPS和VCU，称为它俩为被动唤醒节点，这就意味着IEB需要去唤醒他俩。如果采用CAN总线的唤醒方式，则IEB可以通过网管报文去唤醒EPS和VCU，大致过程是：IEB被传感器BPS唤醒后，它的网络管理状态会产生变化，由睡觉模式转为网络模式。

然后IEB会发出网管报文，EPS和VCU的CAN收发器会收到该网管报文，识别到需要唤醒，最后它们也会发网管报文，告诉IEB醒来了，可以一起搞事情，对应到上图的234部分。

在这个过程中，实现其实很复杂，有几个层面的问题值得深入探究：

一是功能层面，整车哪些功能有休眠唤醒场景？谁是主动唤醒节点，谁是被动唤醒节点？

二是控制器层面：对于每个休眠唤醒场景，主动唤醒节点是怎么被唤醒，被动唤醒节点又是怎么被总线唤醒的？关于网络管理状态机，这些控制器之间是如何管理网络状态？关于网络管理报文，IEB发送网管报文应该是怎样的？而EPS和VCU的又是怎样的？

02

为什么需要网络管理？

在回答上面的这些问题之前，先弄清楚下整车为什么需要进行网络管理，我们知道随着汽车行业的快速发展，从燃油车到混动车和纯电动车，从传统的机械钥匙到遥控钥匙再到无钥匙进入PEPS，汽车部署控制器越来越多。下面列举上世纪和当今汽车的整车网络拓扑：

Source: Global B 电子电气架构，预示了通用的下一个十年。

Source: Global B 电子电气架构，预示了通用的下一个十年。

不难理解，越来越多的控制器部署到汽车电子电器架构，意味着可以实现更多的功能，同时也意味着更多的能量消耗。另外，日益复杂的网络拓扑对控制器间如何协同工作提出巨大的挑战。为了节能减小耗电，某些时刻不需要工作的控制器应该休眠；但某些时刻，又需要休眠的控制器立马醒来参与工作。因此，需要一种控制机制或策略，即网络管理策略，使得通讯拓扑网络中的ECU节点能有序地休眠和唤醒，这样就可以保证汽车功能的同时尽可能节省电量。

03

结合硬件来了解唤醒

当车辆处于长时间停止使用或待机状态时，控制器会进入休眠模式以降低功耗。在需要时，控制器又能被唤醒以响应特定事件或指令，如车门开关、遥控钥匙信号等。这里，首先涉及到唤醒源，然后唤醒源作用在控制器硬件，最后一个控制器通过CAN总线网络作用到另外的控制器，下面来详细了解这些内容。

3.1 唤醒源

先聊下唤醒源，常见的唤醒源有：本地唤醒，网络唤醒和RTC唤醒等。本地唤醒是指某些控制器可以通过特定的触发信号被唤醒，比如KL15硬线，某些传感器唤醒引脚信号。当这些触发信号被检测到时，控制器可以被唤醒以执行相应的操作。

1）KL15硬线唤醒

KL15是汽车电子中的一个标准电源信号，常用于控制器的供电。KL15硬线信号在车辆点火时处于高电平状态，表示电源已连接。KL15硬线唤醒是指通过监测KL15信号的状态变化来唤醒控制器或其他电子模块，并开始执行相应的操作，例如初始化或执行特定任务等。下图所示是一种最常见的KL15硬线唤醒方式。

Source: KL15和KL30 - Smah - 博客园 (cnblogs.com)

2）传感器唤醒

做底盘域控开发时，就碰到制动踏板传感器有唤醒引脚。某些工况下，驾驶员踩制动踏板，制动踏板传感器感知到后，通过其唤醒引脚以硬线形式去唤醒某些控制器，比如IEB，从而及时触发这些车辆稳定性控制系统或防抱死制动系统等安全系统的操作。

3）CAN网络唤醒

CAN网络唤醒源是指能够通过CAN总线发送网络报文，以唤醒处于休眠状态的设备或模块。这些网络报文可以是预定义的标准报文，也可以是自定义的扩展报文。接收到特定的唤醒报文后，设备或模块会解析该报文并进行相应的唤醒操作。比如，当CAN收发器监控到总线电平变化或者特定报文时，就可以通过INH引脚使能电源芯片供电，从而唤醒ECU。

Source: 你知道BMS有哪些内外部的唤醒信号吗 (zhihu.com)

CAN网络唤醒从唤醒方式来进一步划分的话，可以分为：

唤醒帧（Wake-up Frame）：CAN网络中的节点可以通过发送唤醒帧来唤醒其他节点或整个系统。唤醒帧是一种特殊的CAN数据帧，它包含唤醒标识符和相关的控制信息，用于告知接收节点进行唤醒操作。

连续监听（Continuous Listening）：某些CAN网络实现中，节点可以设置为持续监听CAN总线，以侦听特定的唤醒帧或其他相关报文。当接收到指定的报文时，节点将执行唤醒操作。

4）RTC唤醒

RTC唤醒（Real-Time Clock Wakeup）是一种可以在预定的时间点或间隔后唤醒控制器的唤醒方式。在汽车中，RTC唤醒通常用于控制器的定时操作，通过配置RTC唤醒功能，可以在设定的时间点唤醒相关控制器，以执行特定的任务或操作。例如，BMS可以利用RTC唤醒来进行电池状态监测、数据记录等操作，以确保电池在休眠期间得到适当的管理和保护。

Source: 大普通信高精度高可靠性RTC，为新能源汽车BMS安全管理助力 (laoyaoba.com)

3.2 控制器相关硬件 

唤醒源作用到控制器硬件后，有可能直接唤醒微控制器，也有可能经电源芯片间接唤醒微控制器，可以先了解下汽车控制器硬件的组成，其通常由微处理器和相关的传感器和执行器组成。汽车控制器实物如下图所示，上面有很多芯片和电子元器件，它们能够实现怎么的功能呢？

简化一下大概像下图这样： 

控制器的功能有电源管理，传感器信号采集，执行器驱动和通讯等功能，对于CAN通讯功能的硬件部分，通常由CAN总线，终端电阻，CAN收发器，CAN控制器和微控制器组成，如下示意：

在控制器上，CAN总线就不是双绞线形式，而是CAN-H和CAN-L两个PIN脚接入；终端电阻可能没有而在其他控制器上，CAN收发器一定有。CAN收发器最主要作用是提供物理层的接口功能和进行信号转换。当接收报文时，将输入的差分电压转化成逻辑电平（显性/隐性）；当发送报文时，将逻辑电平转换成差分电压输出。而涉及到网络唤醒的话，那么它能够接收、解析和处理唤醒信号，实现对休眠节点的唤醒操作，通常操作是使能电源芯片给微控制器上电的作用。

在硬件层面，CAN收发器常见于2种形式，一种是作为一块独立的芯片，如下图示意；另一种是被集成到某些芯片，比如集成到SBC中。

Source：TLE9252手册

CAN控制器的作用是管理CAN总线上的通信活动。它负责处理消息的发送和接收，确保消息的正确性、完整性和时序性。CAN控制器通常集成在微控制器或通信芯片中，用于与其他CAN节点进行通信，通常一个微控制器中包括多个CAN控制器，如下示意的英飞凌TC系列芯片就有几个。

由这些器件构成的CAN通讯硬件，常见的一种C网络唤醒方式是这样：通过CAN收发器的唤醒引脚或中断功能来触发唤醒信号，然后使用唤醒信号来激活电源芯片，再由电源芯片提供电源给微控制器。这种方式中，当CAN收发器接收到特定的唤醒帧或触发条件时，会通过唤醒引脚发送唤醒信号给电源芯片，激活电源芯片以为微控制器提供电源。

结合之前的本地唤醒源和当下的整车通讯网络架构，唤醒机制通常是：本地唤醒某个控制器，然后这个控制器再通过CAN网络唤醒其所在总线的相关其他控制器，这样唤醒的这些控制器共同来实现某一个功能。比如锁车休眠之后插枪交流充电工况，CP硬线信号唤醒OBC，OBC再发送网络管理报文唤醒BMS等控制器，最终实现交流充电功能。

04

休眠唤醒表

接着从整车休眠唤醒功能层面来进行介绍，上面的IEB例子仅是众多休眠唤醒场景中的一个，再多看两个例子：

一台纯电动汽车关门锁车下电后进入休眠，在它处于休眠这期间，实际上存在很多种唤醒场景。比如用户有用车需求了，可能通过手机端APP提前远程开启空调或座椅加热等功能，那么这时就需要唤醒汽车上的很多控制器。首先TBOX需要被唤醒，然后TBOX醒来后会唤醒上高压相关的控制器，再唤醒空调，加热器的控制器等。    

Source：远程启动功能可以开空调吗？夏天远程启动车开空调伤车吗

用户发现汽车电量不充足了，那么会有充电需求，插枪充电，这时如果插上慢充枪，那么OBC会先被唤醒，识别出插枪行为及其慢充枪的连接状态，然后OBC唤醒BMS和其他相关的控制器进行充电。

Source: 【图】热门电动汽车新闻_新能源汽车行业资讯_电动邦 (diandong.com)

也就是说，通过对一个又一个整车功能和应用场景的详细分析，最终能够汇总出整车所有的休眠唤醒场景需求，通常会用一个表格来管理，俗称休眠唤醒表。休眠唤醒表一般有哪些内容？根据上述所讲的逻辑：

首先休眠唤醒需求，定义有哪些休眠场景或唤醒场景。针对每个唤醒场景，唤醒的条件是什么，针对每个休眠场景，休眠的条件又是什么。

其次是对于每个唤醒场景，哪些控制器需要参与？谁是主动唤醒节点，谁又是被动唤醒节点，每个控制器需要做什么事情。

然后呢，对于每个唤醒或休眠场景，有无唤醒或休眠的时间要求。如下图示意（绿色代表主动唤醒节点）：

注意休眠唤醒表是网络管理最核心的内容，正是有了这样的需求，才有采用何种网络管理方法，来实现预期的休眠唤醒行为。

05

网络管理策略

5.1 AutoSAR NM 状态机

当整车处于休眠状态，如果出现了唤醒场景，那么一定有来自控制器内部的本地唤醒请求，然后才有唤醒网络请求，体现在AutoSAR NM状态机就是本地唤醒源使得IEB进入总线睡眠模式（BusSleep Mode），成为主动唤醒源，然后IEB就会从总线睡眠模式跳转到网络模式（Network Mode）的重复报文状态（Repeat Message State）。    

在重复报文状态，主动唤醒节点IEB会开始以快发形式发送网管报文，而且会连续发送一定的数量网管报文，比如以20ms的发送周期连续快发5帧网管报文。

而被动唤醒节点EPS和VCU接收到IEB的网管报文，同样它们的状态会跳转到重复报文状态，也会周期性发送不同ID的网管报文，但不是快发形式，通常是500ms的发送周期，具体发多少帧取决具体需求。另外，对于被动唤醒节点EPS和VCU需要连续接收到IEB几帧网管报文，可能是一帧，也可能是两帧等，取决于具体需求。

另外在这个状态，对于主动唤醒节点IEB除了需要发送网管报文，还需要发送应用报文，但第一帧是需要先发网管报文，再发应用报文。

当IEB处于重复报文状态一段时间后，就会跳转到正常运行状态（Normal Operation State）,主动唤醒节点IEB将继续周期性发送网管报文，比如500ms的发送周期，以此告诉其他节点自己在正常通信。

而EPS和VCU可能继续周期性发送报文，也可能会停发，取决于节点是否需要与与总线上其他节点进行信息交换。

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

当节点不需要主动与总线上的其他节点进行交互时，就将网络状态设置为“网络释放”，节点在“网络释放”状态下依然需要响应总线上其他节点的网络请求。

5.2 AutoSAR NM 网络管理报文

网络管理报文定义如下表：

Byte0 用于发送源节点ID，每一个 ECU 都会被分配一个唯一的ID，来告知接收节点该网管报文是由哪个节点发送的。比如定义IEB的网管报文ID为0x410, 则节点ID为0x10；同样地，EPS的网管报文ID为0x412, 则节点ID为0x12；VCU亦是如此逻辑。  

Byte1控制位向量，非常重要，这里着重介绍Bit0, 4, 6。

Bit 0 : 重复报文状态请求位，用来表示有无请求重发报文状态，1则有，0则无；

Bit 4 : 主动唤醒位，用来表示是否为主动唤醒网络，1为主动唤醒，0为被动唤醒；

Bit 6 : 局部网络信息位，用来表示网管报文包含PNC信息，如果网络管理有使用到PN功能，那么该位会被置为1，否则为0；

其他位暂时预留。

06

休眠唤醒表与网络管理

网络管理是指车辆（下电，Power off）休眠之后，唤醒需要工作的控制器一起去实现相应的整车功能。说到底就是需要结合好休眠唤醒表和网络管理策略才有更完善的整车功能和行为，那他俩是如何相互结合的呢？

首先是休眠唤醒表与网络管理报文相联系，首先是网络管理报文的Byte1（CBV），对应上表中的某个场景满足，绿框打勾的那个ECU就是主动唤醒节点，那么该ECU的网络管理报文Byte1的Bit4就应该置1；其次，与网络管理报文Byte 2-7相关，即User data。就结合本文IEB例子，某个唤醒场景需要实现底盘域控相关功能，需要唤醒IEB, EPS, EPB和VCU，其中IEB是主动唤醒节点，那么对于IEB的网络管理报文的User data可以如下图这样的定义：

这样通过休眠唤醒需求分析各个场景，最终可以提炼出每一个控制器作为主动唤醒节点，它需要去唤醒哪些控制器或网络。因此可以确定每个控制器的网络管理报文，不难理解，byte0和byte1。同时针对不同休眠或唤醒场景，网管报文的user data有所区别，如何做到场景与网管报文内容一一映射，通常会定义另一帧报文，用来表明当前是哪个或哪几个请求条件或释放条件满足。另外，采取何种网络管理策略其实会影响休眠唤醒表的定义，比如采用PN，那么在休眠唤醒表中，是需要定义清楚PN cluster的。对于PN，有需要的话，可关注开心果 Need Car。

07

代码的角度

/***************************************************************************************************
 Function name    : CanNm_InternalMainProcess
 Syntax           : void CanNm_InternalMainProcess( const NetworkHandleType CanNm_NetworkHandle )
 Description      : This is an internal main function of CANNM which does state machine processing
                    for all channels.
 Parameter        : CanNm_NetworkHandle - Identification of the CANNM-channel
 Return value     : None
 ***************************************************************************************************/

/***************************************************************************************************
 Function name    : CanNm_NetworkRequest
 Description      : This is the AUTOSAR interface to request the network, since ECU needs to
                    communicate on the bus. This API shall be called by Nm.
 Parameter        : nmChannelHandle - Identification of the NM-channel
 Return value     : E_OK - No error
                  : E_NOT_OK - Requesting of network has failed
 ***************************************************************************************************/

‍

/***************************************************************************************************
 Function name    : CanNm_NetworkRelease
 Description      : This is the AUTOSAR interface to release the network, since ECU doesn't have to
                    communicate on the bus. This API shall be called by Nm.
 Parameter        : nmChannelHandle - Identification of the NM-channel
 Return value     : E_OK - No error
                  : E_NOT_OK - Releasing of network has failed
 ***************************************************************************************************/

审核编辑：黄飞