依稀记得是2019年国庆假期后回来上班的第二天，收到售后的一封邮件，大意是：客户刚提车1个月，已发生2次车辆馈电导致无法启动，客户现在正闹着要退车，请相关工程师全力协助排查。
过程不去赘述，最终结论就是车辆的TBOX被云端异常周期唤醒，TBOX随后又唤醒整车，如此周期往复，最终导致整车小电池电量耗尽发生馈电，馈电是整车网络管理中最不愿意见到的一幕，伤敌一千自损八百。
而随着桀骜不驯的智驾域的加入，整车网络管理难度也随之加大，已经开始挑战各主机厂的企业标准。如何对包含智驾域的整车进行网络管理，如何将有限的能量转换为无限长的放置时间，成为主机厂会议室中一个重要的议题，本文就对担负着减少整车能量消耗的网络管理进行介绍。
01 唤醒休眠
整车上的部分控制器会一直由小电瓶供电，这样才能支持你随心所欲地远程控车、遥控寻车等功能，但是车辆在长时间静置的时候，如果一直保持着功能就绪状态的电量消耗，那么车辆上小电池的电量将会急剧减少，虽然现在电动车都设计有大电池给小电池的补电策略，但这种消耗带来的续航里程减少也是不可容忍的，为了规避这个问题，就需要对常电供电的控制器进行网络管理。
在整车网络管理的眼中，控制器没有了算力高低之分，没有了高矮胖瘦之分，有的只是唤醒和休眠之分。车辆在需要控制器出苦力的时候（整车上电）将其唤醒，而在准备吃香喝辣的时候（整车下电）又将其休眠，地主老爷不过如此。
对于控制器来说，唤醒的时候究竟是醒了什么，怎么醒的？休眠的时候究竟是眠了什么，怎么眠的？这是正式介绍网络管理前必须要理清的概念。
对于控制器来说，常用的唤醒方式有硬线唤醒和网络唤醒，与之相对应的休眠方式也就有硬线休眠和网络休眠。
（1）硬线唤醒休眠
硬线唤醒休眠是指通过电压或电流方式唤醒休眠控制器，整车控制器常用的硬线唤醒休眠方式为KL15点火信号，在发动机启动（燃油车）或整车上高压（电动车）时，KL15点火信号会由0V上升到12V。
不同控制器基于实现的功能不同，硬线唤醒休眠的内部逻辑也会有所区别，本节为了解释硬线唤醒休眠的逻辑，以一个简单系统为例，给出了一种使用KL15点火信号唤醒控制器的可能硬件架构，如图1所示。
图1 一种支持硬线唤醒休眠的硬件架构
该系统由CPU，承担电源管理功能的系统基础芯片（System Basis Chip，SBC），CAN收发器、外部存储器、温度传感器、蓄电池等组成。图1中红色实线和虚线代表电源线、黑色实线代表信号线。
在该系统中SBC直接接蓄电池，也就是由KL30供电，除非蓄电池发生故障或馈电，否则无论整车点火还是熄火，SBC都会有电。SBC的唤醒接口接KL15点火信号，在整车没有点火或上高压时，KL15端电压为0，SBC判断整车没有唤醒需求，从而进入到Sleep模式，且不对片内其他模块供电，其他模块进入到OFF或Shutdown模式，此时控制器整体对外表现出一种低功耗休眠模式，控制器的静态电流也就是这种模式下的电流，传统控制器的静态电流常要求20mA以内。
当整车点火或上高压，KL15端电压升高到12V，SBC检测到整车有唤醒需求，由Sleep模式一步步跳转到Normal模式，并打开对CPU、CAN收发器、外部存储器、温度传感器等模块的供电，整车控制器随之开始正常工作。
当整车熄火或下高压，SBC和CPU同时检测到KL15端电压下降，CPU进行下电前的准备工作，包括缓存写入外部存储器，并将是否准备好下电的状态通过SPI告知SBC，SBC收到CPU准备就绪的状态后，按照设定好的顺序依次切断其他模块的供电，自身随后一步步跳转到Sleep模式。
（2）网络唤醒休眠
网络唤醒休眠是指通过网络管理报文唤醒休眠控制器，CAN网络下一种网络唤醒硬件架构如图2所示。
图2一种支持网络唤醒休眠的硬件架构
CAN收发器通过一个DCDC和KL30直连，在没有网络唤醒需求的时候，CAN收发器进入Sleep模式，一旦检测到CAN总线上有网络唤醒报文，CAN从Sleep模式恢复，INH引脚产生一个10ms的高电平信号， SBC的WAK引脚检测到一个10ms的高电平信号， SBC被唤醒。
SBC收到唤醒信号后，由Sleep模式一步步跳转到Normal模式，并打开对CPU、外部存储器、温度传感器等模块的供电，整车控制器随之开始正常工作，休眠过程与之类似。
知道了唤醒休眠的本质，接下来就能介绍网络管理了，目前整车上常用的网络管理方式包括OSEK网络管理和AUTOSAR网络管理，下文将逐一介绍。
02 OSEK网络管理
为了解决汽车控制技术通信和网络发展多元化带来的软件移植和不同应用程序的接口协调问题，德国汽车工业界在1993年推出了OSEK（open systems and the corresponding interfaces for automotive electronics）体系，定义汽车开放式系统及接口。1994年法国标致雷诺将汽车分布式运行系统VDX（vehicle distributed executive）纳入OSEK。
在1995年召开的OSEK研讨会上，众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)。它主要由四部分组成：操作系统规范(OSEK Operating System，OSEK OS)、通信规范(OSEK Communication , OSEK COM)、网络管理规范(OSEK Net Management，OSEK NM)和OSEK实现语言(OSEK Implementation Language，OIL)。
OSEK网络管理是一个三层的状态机，最顶层有三个状态：NMOff，NMOn和NMShutDown，如图3所示。
图3 OSEK网络管理顶层状态机
（1）NMOff
网络管理关闭状态，控制器上电后首先进入的状态，通过调用StartNM接口，控制器将离开此状态并开始运行网络管理，运行中的网络管理通过调用StopNM接口，控制器将跳转到NMShutDown状态，进而回到此状态并关闭网络管理。
（2）NMOn
进入到NMOn状态后，又会按照图4进行网络管理，图4左右两边是两组并行的状态，互不影响。对于左边来说，首先进入NMinit状态并进行硬件初始化，初始化完成后，如果有通信需求会跳转到NMAwake状态，如果没有通信需求会跳转到NMBusSleep。对于右边来说默认进入NMActive子状态，表示参与逻辑环循环过程，若应用层通过参数设置为不参与，则将跳转到NMPassive状态，控制器停止发送Ring消息及参与逻辑环的循环过程。
图4 NMOn下子状态机
NMAwake状态是控制器正常进行网络管理时长期保持的状态，还可以继续细分为三个子状态NMReset、NMNormal和NMLimpHome，如图5所示。
（a）NMReset
控制器唤醒后会一步步跳转到NMReset状态，并以广播形式发出一帧特殊网络管理报文（第一字节是控制器自身ID，第二字节Bit0为1），用来唤醒其他控制器及建立逻辑环。当网络中所有控制器都发完Alive报文之后，网络中所有控制器根据收到的Alive报文ID由小到大的循序确认自己的逻辑后继节点，ID最大控制器的后继节点为ID最小控制器（如21->22->23->24->25>26->21），由此组成一个逻辑环，并进入NMNormal状态。
（b）NMNormal
最初发送Alive报文的控制器（或者Alive报文标识符优先级高的控制器）成为逻辑环中的第一个Ring报文发送控制器，Ring报文的第一个字节是下一个控制器的ID，第二字节的Bit1为1。网络中其他控制器收到指向自身ID的网络管理报文后，也被称为“令牌”，才能发出自身Ring报文，因此网络中同一时间只有一个控制器能发出网络管理报文，每个控制器按照顺序发送网络管理报文，这个顺序就叫做逻辑环，一个简单的逻辑环原理如图6所示。
图6 逻辑环原理
逻辑环建立完成之后，无论是有新控制器加入还是某个控制器掉线，都需要重新进行建环以维持正常的网络管理，因此对网络的稳定性要求比较高，整体策略比较复杂。
当控制器自身休眠条件满足，就会发出睡眠指示位 (Sleep.Ind，第二字节Bit4) 为 1 的 Ring 报文，表示自身不再主动请求网络管理，当所有控制器都满足休眠条件，最后一个休眠控制器的下一个节点，就会依次发出睡眠应答位 (Sleep.Ack，，第二字节Bit5) 为 1 的 Ring 报文，当网络上所有控制器都接收到其他所有控制器的睡眠应答位为1的Ring报文后，等待一定时间后同步进入睡眠状态。这个时候，控制器会停止发送任何报文到总线，等待控制器的内部任务完成后，就会进入低功耗模式，静态电流会变得很小。
（3）NMLimpHome
如果控制器或总线有故障导致逻辑环建立失败，控制器将进入NMLimpHome状态，并按一定周期发送LimpHome网络管理报文（第一字节是自己的ID，第二字节Bit2为1）。
03 AUTOSAR网络管理
2003年汽车行业内的几大巨头（BMW, Bosch, Continental, DaimlerChrysler, Volkswagen, Siemens VDO）联合建立了AUTOSAR（AUTomotive Open System ARchitecture）联盟，一起开发并建立一套真正的开放的汽车电子电器架构，也就是我们现在所说的AUTOSAR标准或者架构。
AUTOSAR网络管理的状态机有三个模式：Bus-Sleep Mode、Network Mode和Prepare Bus-Sleep Mode，如图7所示。
（1）Bus-Sleep Mode
控制器上电状态，如果没有本地唤醒或远程唤醒请求时，控制器将进入的一种休眠模式，此模式下控制器电流消耗将降低至最低水平。
该模式下，网络管理报文及应用报文都被禁止发送，但可以接收网络管理报文和应用报文。当收发器支持特定帧唤醒时，那么控制器只有在接收到事先定义好的网络管理报文才会唤醒；当收发器不支持特定帧唤醒时，那么网络上的任意报文都可以将控制器唤醒，唤醒之后再去判断是否为有效网络管理报文，如果不是，又会再次按照休眠流程进入到休眠模式。
（2）Network Mode
Network Mode模式又可细分为三个子状态：Repeat Message State、Normal Operation State和Ready Sleep State，如图2所示。
图8 Network Mode下子状态机
（a）Repeat Message State
Repeat Message State是一个短时间的重复消息状态，当控制器从Bus-Sleep Mode或者Prepare Bus-Sleep Mode进入到Network Mode后，控制器会发出自身的网络管理报文通知其他控制器自己上线，就好比你早上到了办公室之后，和身边的同事打个招呼，告诉他们今日话搭子已上线，请做好唠嗑准备。
Repeat Message State下还有两个子状态：NM Immediate Transmit State和NM Normal Transmit State，两个状态的主要区别就是网络管理报文发送周期的不同，前面子状态下网络管理报文可以按照配置参数高频发送一定周期，目的是快速唤醒整个网络，后面子状态下网络管理报文恢复到正常周期。
进入到Network Mode后，应用报文需要在第一帧网络管理报文发送之后再发送，同时开启一个计时器，在计时器超时之前会一直保持该状态，否则会离开该状态，
（b）Normal Operation State
当控制器自身存在网络通信的需求，且整车网络和控制器均正常，那么控制器将跳转并一直保持在Normal Operation State状态，进入该状态后，控制器将周期性发送网络管理报文，同时正常收发应用报文。
（c）Ready Sleep State
当控制器不再需要网络通信时处于的就绪休眠状态，该状态下控制器将停止发送网络管理报文，但可以正常发送自身的应用报文，同时正常收发应用层报文。进入该状态后将同时启动一个计数器，每次成功接收到其他控制器发送的网络管理报文，计时器将重置，一旦计时器超时，控制器将跳转到Prepare Bus-Sleep状态。
整车网络和控制器均正常，控制器将维持在Normal Operation State和Ready Sleep State状态，差别就是自身是否有网络通信需求。
（3）Prepare Bus-Sleep Mode
此模式为控制器准备进入睡眠模式的一个过渡，不会长期处于此模式。该模式下网络管理报文停止发送，可以接收网络管理报文，已经存在缓存器的应用报文可以继续发送，同时不再接收应用层报文。进入该模式后，同样启动一个计时器，一旦计时时间到，就将跳转到Bus-Sleep Mode。
04 比较
（1）相同点
（a）均属于直接网络管理。
（b）均需要特定的网络管理报文，且每个控制器的网络管理报文ID均不同。
（c）唤醒方式相同，网络中第一个唤醒的控制器发送网络管理报文唤醒其他控制器。
（d）目的相同，都是协调多个控制器同步唤醒及休眠，并最终达到低功耗的目的。
（2）不同点：
（a）唤醒帧类型不同，OSEK网络管理要求控制器唤醒后的第一帧网络管理报文必须为Alive类型，而AUTOSAR网络管理要求只要是网络管理报文即可。
（b）休眠逻辑不同，OSEK网络管理的休眠是一个请求和确认的过程，所有控制器都发送Ring请求休眠帧，且收到其它控制器的Ring确认休眠帧之后才可以准备进入休眠，而AUTOSA网络管理直接停止发送网络管理的报文且一定时间内检测不到网络上其他的网络管理帧就可以准备进入休眠。
（c）网络保持方式不同，OSEK网络管理下控制器唤醒后想参与网络的节点会先发Alive报文申请加入逻辑环，逻辑环建成后，各节点按顺序发Ring报文向后续节点传递“令牌”。而AUTOSAR网络管理下，唤醒的控制器直接发送网络管理报文就可以，所有的控制器想参与到通信中的只要各自发送网络管理报文就可以。
（d）网络管理帧PDU格式不一样，OSEK由于唤醒过程要知道下一个唤醒的控制器，因此在PDU中包含了自己地址、令牌环中下一个控制器的目的地址、命令状态、用户数据等，而AUTOSAR网络管理报文只包含自己的地址、少量控制信息及用户选择数据，相比之下要简单不少。
来源：十一号组织
