一文了解整车网络管理的来龙去脉

之前写过一篇易懂的整车网络管理指南介绍了如何实现休眠管理，最近从供应商角度来做网络管理功能的软件实现，有了一些新的体会，在此基础上再次汇总分享下。

首先了解网络管理产生的背景，其次介绍网络唤醒的机理，再介绍网络唤醒的实现方式，最后介绍网络唤醒的具体实现。

1 为什么需要进行网络管理？

网络管理的根据动机就是减小电耗，控制器不需要工作时休眠，需要工作时被唤醒起来。为什么以前不需要而现在需要？因为以前的汽车一方面控制器数量少，另一方面汽车功能也少，所以整车下电后，可能除了无钥匙进入系统的控制器，其他控制器基本都处于断电状态。

source: Tutorial for Wake Up Schemes and Requirements for Automotive Communication Networks，Automotive Electronic

但是现代的汽车不一样了，一个控制器数量快速增长，另一个汽车的电动化、网联化和智能化浪潮下，车辆功能的不断增多，比如PEPS、远程APP控车、迎宾模式和哨兵模式等功能，这些功能使用的场景都是人不在车上，即整车处于下电锁车，且人离车有一段距离。

为了保证这些功能的实现，那么相应的控制器需要连接蓄电池常电，不过并不说这些控制器就一直不下电。实际的状态是在车辆下电锁车后，这些控制器会停止工作，进入休眠这种低功耗状态，但是其中一些外设芯片（比如SBC或CAN收发器）会一直监控车辆的唤醒行为，一旦有唤醒需求，它们就会为给控制器的MCU(微控制器)供电，以此MCU就被唤醒而正常工作。

关于唤醒的源头，简单地可以分为两种，一种硬线唤醒，另一种网络唤醒，当前主要是CAN报文唤醒。对于这种硬线唤醒通常主动唤醒，而网络唤醒称为被动唤醒。

硬件唤醒很好理解，自身需要而醒来，如果自己单独可以实现，那么自己醒着干自己的活就行，但是如果单靠自己还干不完这个活，那就需要叫醒其他控制器共同参与来实现，此时就需要网络唤醒。

现代的汽车越来越多的功能都需要多个控制器来参与，这意味着需要一套机制或规则来管理，否则很容易乱套，因此网络管理的概念就产生了，其存在的价值也越来越强。

2 网络唤醒的机理是怎样的？

对于整车网络管理的机理，这里构建一个例子来理解，如下所示：

IEB包括硬件唤醒和网络唤醒等方式，对于网络唤醒，其他硬件组成有CAN收发器，CAN控制器和微控制器；不同CAN总线网络通过网关才能进行通讯。

当所有的控制器都睡了，突然制动踏板行程传感器BPS感知到有情况，连接的IEB的硬线信号有了变化，那么IEB将被唤醒，对应着图中1区域。此时，为了实现这个唤醒场景下的功能，需要其他控制器参与，比如EPS和VCU，这就意味着IEB需要去唤醒他俩，通过CAN网络以报文形式唤醒，即IEB发送网管报文，然后EPS和VCU的CAN收发器会收到该网管报文，识别到需要唤醒，最后它们也会发网管报文，告诉IEB醒来了，可以一起搞事情，对应到上图的234部分。

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

在整车功能层面，有哪些功能需要有休眠唤醒场景？对于每个功能的唤醒，谁是主动唤醒的控制器，谁又是被动唤醒的控制器？这些控制器之间怎么进行唤醒信息的交互？
在控制器层面，在硬件设计上，怎么实现主动唤醒，又怎么实现网络唤醒？在软件实现上，怎样实现网络管理的状态机？收发怎样的网管报文？

3 整车功能层面的几个问题

3.1休眠唤醒表

现在的纯电动车下电锁车后，会存在很多的唤醒场景。比如用户可能通过手机APP提前远程开启空调，这时TBOX先被唤醒，然后TBOX醒来后会唤醒上高压相关的控制器，再唤醒空调的控制器。又或者用户给车下电后发现要充电，当插上枪，OBC先被唤醒，识别出插枪行为及其枪的连接状态，然后OBC唤醒BMS和其他相关的控制器进行充电控制。

Source: 热门电动汽车新闻_新能源汽车行业资讯

这样通过对这些整车功能和应用场景的详尽分析，就获取到了哪些功能有休眠唤醒场景的需求，都需要哪些控制器参与，谁是主动唤醒的控制器，谁又是被动唤醒的控制器。通常主机厂用表格文件来管理，俗称休眠唤醒表。

这就不难理解休眠唤醒表应该有哪些内容，包括：

定义有哪些休眠场景或唤醒场景。针对每个唤醒场景，唤醒的条件是什么，针对每个休眠场景，休眠的条件又是什么。
对于每个唤醒场景，哪些控制器需要参与？谁是主动唤醒节点，谁又是被动唤醒节点，每个控制器需要做什么事情。
对于每个唤醒或休眠场景，有无唤醒或休眠的时间要求。如下图示意（绿色代表主动唤醒的控制器）：

或者下图这种形式，依据功能逻辑架构及功能分配方案进行功能到ECU的打点：

source: 从整车层级到零部件层级的网络管理开发

休眠唤醒表是网络管理的根本需求，由它催生更详细网络管理策略，包括网络管理状态机和网络管理报文等内容。

3.2 网络管理状态机

最常见的网络管理状态机是AUTOSAR NM状态, 这里不对其定义进行详细介绍，直接根据之前的IEB例子来进行说明：如果出现了唤醒场景，一定得有来自控制器内部的主动唤醒请求，然后才产生唤醒网络请求，体现在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可能继续周期性发送报文，也可能会停发，取决于控制器是否需要与与总线上其他控制器进行信息交换。

当节点需要主动与总线上其他控制器进行信息交换时，就通过发送网管报文来请求网络，并将其网络状态设置为“网络请求”。
当节点不需要主动与总线上的其他控制器进行交互时，就将网络状态设置为“网络释放”，节点在“网络释放”状态下依然需要响应总线上其他控制器的网络请求。

以上就是对于AUTOSAR NM状态的介绍，当然对于网络管理状态机不止这么一种形式，比如有些主机厂的网络管理状态机长下图这样：

但是不管是哪种形式，其内核还是一样的，就是在唤醒场景下，以怎样的规则在控制器之间进行唤醒信息和应用信息的交互。当然这里面网络管理报文起着非常大的作用。

3.3 网管报文

以AUTOSAR NM的网管报文来说明，其定义如下表：

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

Byte1控制位向量，这里着重介绍它的Bit0, Bit4 和 Bit6。

Bit 0 : 重复报文状态请求位，用来表示有无请求重发报文状态，1有0无。
Bit 4 : 主动唤醒位，用来表示是否为主动唤醒网络，1主动0被动。
Bit 6 : 局部网络信息位，用来表示网管报文包含PNC信息，1包含0不包含。

3.4 总结

将休眠唤醒表和网络管理策略才能构建起整车功能的完整休眠唤醒场景，也就是说如何将以上三节内容相结合？

先结合休眠唤醒表与网管报文，将网管报文的Byte1对应休眠唤醒中的某个场景满足，下图绿框打勾的那个ECU就是主动唤醒的控制器，那么该ECU的网管报文Byte1的Bit4就应该置1；然后针对某个唤醒场景，比如需要唤醒IEB, EPS, EPB和VCU，其中IEB是主动唤醒的控制器，那么对于IEB的网管报文Byte 2-7的User data可以入下图这样定义：

这样逐个分析各功能的休眠唤醒场景，最终可以确定每个控制器的网管报文内容，针对不同休眠或唤醒场景，网管报文的user data有所区别，如何做到场景与网管报文内容一一映射，通常会定义另一帧报文，用来表明当前是哪个或哪几个请求条件或释放条件满足。这些就是在整车功能层面网络管理需要重点考虑和解决的几个问题。

4 控制器层面的几个问题

4.1 唤醒的硬件机理

针对唤醒功能，对于控制器来说，有硬线唤醒和网路唤醒。硬线唤醒作用到控制器硬件后，通常是作用到电源芯片后再唤醒微控制器，如下图所示：

从上图不难理解，只要电源管理芯片被唤醒，整个控制器的供电就正常了，就可以正常运行了。而对于网络唤醒，主要涉及CAN通讯功能的硬件部分，涉及到CAN总线，终端电阻，CAN收发器，CAN控制器和微控制器，其中关键器件是CAN收发器，一方面CAN收发器提供物理层的接口功能和进行信号转换。当接收报文时，将输入的差分电压转化成逻辑电平（显性/隐性）；当发送报文时，将逻辑电平转换成差分电压输出。另一方面CAN收发器能够接收、解析和处理唤醒信号，实现对休眠控制器的唤醒操作，通常操作是使能电源芯片给微控制器上电的作用，如下所示：

以上就是控制器硬件如何支持硬线唤醒和网络唤醒的机制，对于主动唤醒的控制器，一个唤醒场景下，先是本地的硬线唤醒控制器，然后这个控制器通里过CAN网络唤醒其他控制器，因此这些控制器共同实现某一个功能。比如锁车休眠之后插枪慢充，硬线CP信号唤醒OBC，OBC发送网管报文唤醒BMS等控制器，最终实现慢充功能。

4.2 唤醒的软件实现

在软件层面，休眠唤醒功能需要底层软件和应用层软件结合起来实现。底层软件基本可以按照AUTOSAR NM模块来做，控制上下电和控制网管报文和应用报文的收发，而这里主要介绍应用层软件可以做什么。

第一，确认唤醒信号。通常控制器被唤醒初期，需要由应用层软件再次确认是否存在真的唤醒源，比如硬线唤醒，IEB再次确认确实有BPS信号，且信号数值确实在有效范围。当确认是有效唤醒，此时应用层软件可以通过调用ComM接口ComM_RequestComMode（）请求FULL_COM以使能通信；当确认是无效唤醒，应用层软件可以通过调用ComM接口ComM_RequestComMode（）请求NO_COM以释放网络而休眠。
第二，唤醒请求逻辑。当检测有效唤醒需要请求网络，可能还需要请求网管报文和应用报文的发送，当唤醒结束则需要释放网络，以及停止报文的发送等，这里与上条用户通过调用ComM接口ComM_RequestComMode请求FULL_COM和NO_COM一样。

在上面的过程中，当ComM在接收到用户FULL_COM请求后，调用 CanSM_RequestComMode()请求CanSM将相应的Can通道状态切换为FULL_COM，CanSM再通过CanIf切换控制器和收发器状态。ComM进入FULL_COM后，可通过BSWM或手动方式，启动相应通道的Com IPdu Groups，通信开始。

第三，唤醒相关信号的计算。比如唤醒请求由谁发起，唤醒产生的原因是什么，释放网络的原因是什么和唤醒次数的统计等。

总体来说，在应用层软件差不多是这几个内容，关键点在于与底层软件的配合来实现网络管理的时间性能要求。

5 总结

以上就是网络管理从整车功能到控制器的软硬件实现的介绍，更多细节需要从实际工作中去挖掘。最后补充一个知识点：唤醒源，常见的唤醒源有：本地唤醒，网络唤醒和RTC唤醒等。

1）本地唤醒指某些控制器可以通过特定的触发信号被唤醒，比如KL15硬线和传感器唤醒引脚信号。当这些触发信号被检测到时，控制器可以被唤醒以执行相应的操作。

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