在换电站及充电桩等补能基础设施尚未大规模普及的情况下,普通用户购买电动车最关心的还是车辆的续航能力。从这个需求场景处出发,有利于降低整车能量消耗、提高整车续航能力的技术都值得主机厂工程师研究一番。
车辆在使用过程中的能量消耗一般包括以下三大类:
(1)车辆行驶时克服各种阻力消耗的能量;
(2)车辆热管理消耗的能量;
(3)车辆各个控制器和执行器工作时消耗的能量。
其中前两类在车辆行驶中占据能量消耗的大头,如果说一辆车的百公里能耗低,那势必在这两方面做到了很好的平衡。
第三类能量消耗与我们日常生活息息相关,既会发生在车辆行使过程中,也会发生在车辆静止的时候。开车时开个空调、停车时开个尾门都会产生不同程度的能量消耗。
这类能量消耗虽然总体占比不大,对整车续航能力影响有限,但蚂蚁腿也是肉,如何节省这部分的能量成为主机厂架构工程师日日忙碌的事情。
本文就来介绍一种可以降低此类能量消耗的技术方案;PNC+E-FUSE。
01PNC
在传统整车网络管理中,整车控制器要么同时被唤醒要么同时休眠。但在一些功能场景中,比如车辆充电场景、比如哨兵模式,我们只需要部分网段中部分控制器参与工作,而不是全部网段的全部控制器。
基于以上需求痛点,AUTOSAR在其网络管理中定义了局部网络(Partial Network,PN)的特性,允许通过采用些规则将整车网络进一步划分为不同的局部网络。在特定功能场景下,与功能场景相关的局部网络内的控制器处于工作状态,而无关的局部网络内的控制器仍处于低功耗状态,以达到进一步减少能量消耗的目的。
局部网络根据功能将整车控制器划分为不同的网络簇(Partial Network Cluster,PNC),每一个PNC就是一个虚拟的局部网络,PNC中的控制器可以在同一个网段,也可以跨不同的网段,且每一个PNC支持单独的唤醒和休眠。
NM PDU是AUTOSAR中定义的CAN网络上的网络报文,包括8个字节,每个字节定义如图1所示。
图1 NM PDU定义
Byte1对应的控制位向量(Control Bit Vector,CBV)中每个Bit定义如图2所示。
图2 CBV中各Bit定义
CBV中Bit 6表示局部网络管理支持位(Partial Network Information Bit,PNI),等于0时表示不支持局部网络管理,等于1时表示支持局部网络管理。 如果整车要使用PN功能,发送NW PDU时,需要将该位置1。
图1中的Byte2到Byte7通常用来存储PNC信息,一共有6个Byte,每一组PNC使用其中的某一个bit位来表示,所以原则上整车最多可以有48个PNC。
02E-FUSE
E-FUSE本质上是一种集成电路,通过在单芯片上集成MOSFET、驱动、检测电路、逻辑电路、诊断等模块,提供一种供电电路保护的半导体解决方案。
当E-FUSE串联进主供电电路时,其工作方式类似于传统保险丝,能够检测过电流和过电压情况并对其做出快速反应。 发生过载情况时,设备会将输出电流限制为用户定义的安全值。 如果异常过载情况持续存在,则设备将进入打开状态,从而断开负载与电源的连接。 过载电流限制可以通过一个外部电阻器进行编程。
E-FUSE具有的优点如下:
(1)节省空间。 E-FUSE通过集成在PCB板上,相比于现在至少需要单独两个配电盒(前舱和乘员舱各一个),可以节省不少空间,对本就捉襟见肘的车内布置空间来说是一大福音;
(2)相比传统保险丝通过不可逆的自毁方式保护整车的用电线路,E-FUSE具备自恢复的能力。 这也就意味着E-FUSE因过压、过流、低压等电路异常损坏的概率极小,不考虑芯片本身的故障,E-FUSE几乎可以用到车辆报废。 所以从这个维度来看,E-FUSE还能侧面减少整车生命周期的维修成本,提供更好的用户体验;
(3)提高功能安全。 高等级自动驾驶对关键供电线路的功能安全等级要求一般为最高的ASIL D。 采用传统“黄金搭档”方案很难达到此要求或者需要付出极大的代价,而让一颗半导体芯片达到ASIL D,这是芯片巨头的强项;
(4)诊断功能。 通过对每一条供电线路进行检测和诊断,可以提早发现故障,减少重大故障发生的几率;
(5)在线升级。 通过在线升级可以灵活调整功能逻辑、及时修复BUG。
E-FUSE具有的缺点如下:
(1)单个E-FUS的成本高。 十几块钱的E-FUS相比几毛钱的保险丝,谁用谁败家。 但是莱特定律告诉我们:产量每累计增加一倍,成本价格就会下降15%。 现在是缺点,产量达到一定规模就是优点;
(2)更换成本高。 一旦坏掉(虽然硬件失效的概率极小,但不排除百万分之一坏的可能),需要连着整个控制器都一起换,更换一个控制器的成本是一个保险丝的几百上千倍。
03PNC与E-FUSE的结合
下文以一个具体的使用场景来说明对PNC进行详细设计的过程。
比如说有一个远程座舱舒适功能的场景,需要把车内温度和座椅温度达到用户设定的值,这个场景定义为PNC1(NM PDU Byte2Bit0)。
如图3所示,假定空调和座椅分别由ECU1和ECU2进行控制,并且分布在不同的CAN网段上。 根据该场景需求,需要对ECU1和ECU4分别进行网络配置,并在收到NM PDU Byte2Bit0 == 1时,ECU1和ECU4 可以被唤醒。
图3 远程舒适功能架构
当用户激活该功能时,对应区域控制器收到该请求信号,把对应的NM PDU Byte2Bit0置为1,同时发送到相应的网段(CAN1和CAN2),当ECU1和ECU4收到该NM PDU时会自行唤醒,此时控制器可正常工作。 其余的控制器因为没有配置PNC1对应的内容,所以即使在同一网段上收到该网络管理帧也不会唤醒。
在没有引入PNC的特性时,AUTOSAR的网络管理一般是同一网段上只要有网络管理帧,那么该网段上的所有控制器都会唤醒。 更有甚者是只要整车有任一唤醒源唤醒了网络,中央网关就会把整车所有节点都唤醒。
对于那些并不需要参与这个功能的控制器来说,尤其是功率比较大的控制器,比如主机屏幕、激光雷达等,醒着就是浪费车辆的能耗。
所以在不增加硬件成本的情况下针对特殊的使用场景设计不同的PNC,能有效地降低整车的功耗,特别是该特殊使用场景持续使用的时间还比较长,比如哨兵模式、露营模式等,就可以运用PNC进行管理,以达到节能的目的。
随着最近几年E-FUSE也引入了车辆的设计中,E-FUSE与PNC的组合设计成为主机厂架构设计中的一种潮流。
在没有用到E-FUSE之前,整车的电源管理一般只分为三种状态,分别为OFF、ACC、ON,这里我做一个简化,把ACC和ON状态合并叫做KL15供电,OFF状态叫做KL30供电。 KL15供电一般是由BCM控制继电器吸合后供电,KL30为接入蓄电池的常电。
一般只有需要在整车OFF下工作的用电器才挂在KL30下,像BCM、PLG、T-BOX、SCM等控制器。 而不需要在整车OFF下工作的用电器通常会挂在KL15供电下面,像空调、娱乐大屏等控制器,KL30和KL15供电示意图如图4所示。
图4 KL30和KL15供电示意图
很显然这样的电源管理方式是比较粗犷的,在当前流行的区域控制器中,区域控制器会统一对下辖的子节点进行电源管理,也就是通过E-FUSE来实现电源的供给与切断。 不同的ECU以及执行器按照就近原则被放在不同的区域控制器下面来进行控制,通过区域控制器对下一级的ECU的电源进行管理,这就是E-FUSE当前的使用场景,如图5所示。
图5 区域架构下E-FUSE应用案例
既然已经用了E-FUSE这么高端且智能的控制芯片,那么如果仅仅只是为了电源的管理岂不是太浪费了。 可以把不同的控制器放在不同的E-FUSE上,一个车上的E-FUSE越多,那么就可以更精准的控制每个用电器的电源。
回想一下前面提到的PNC1的管理,也就是远程座舱舒适功能场景的网络管理。 在没有引入E-FUSE之前,需要区域控制器通过网络的方式唤醒座椅和空调控制器,并且控制KL15继电器吸合,因为KL15供电下的控制器不止空调控制器,在该供电下的其他控制器也会同时工作,这样就会导致整车的能耗增加。
如果有E-FUSE的精细化管理控制,区域控制器可以精准的控制空调和座椅控制器所在的E-FUSE。 虽然也有可能有其他的控制器挂在空调或者座椅所在的这一路E-FUSE上,但是通过对使用场景的分析,可以尽可能的把功耗小的控制器挂在该E-FUSE上,甚至如果分析完所有场景需求,在满足场景需求的情况下可以把空调和座椅控制器放在同一个E-FUSE下进行控制。
04写在最后
车辆刚诞生的时候,其实并不需要网络管理,因为车上就没有几个控制器。 随着汽车的发展,车上的控制器越来越多,需要在整车OFF模式下工作的用电器也越来越多,如果没有网络管理,那当某个功能需要不同的控制器协同工作时,只能通过硬线的方式对需要的控制器进行唤醒。 随着控制器的增多,采用这样的方式效率会很低,所以网络管理孕育而生。
正所谓天下合久必分,分久必合。 汽车的发展也由之前的控制器极少变成控制器超多,到现在慢慢的控制器在减少。 所以在控制器变少的情况下,网络管理是不是也会有相应的变化。 前文提到的远程座舱舒适功能的单一场景,如果仅仅只是满足这个场景需求,其实可以把座椅控制器和空调控制器放在同一路E-FUSE下,直接由区域控制器来控制这两个控制器。 当用户触发该功能时,E-FUSE工作,而不需要用到PNC的管理。
AUTOSAR的网络管理协议栈并不便宜,通过梳理整车的功能场景,如果在满足所有场景的情况下部分的用电器可以直接由E-FUSE控制,其余的通过PNC进行管理,这两者相结合,这样可以省掉一笔不菲的开发费以及带来整车能耗的下降,这也是给消费者带来更实惠产品进行的尝试。
审核编辑:汤梓红
全部0条评论
快来发表一下你的评论吧 !