汽车电气和电子

  从一位汽车大佬那边copy过来的,加了个目录方便自己看的,请联系阿宝1990本人,本文仅供自己查看,谢谢大佬了。

  欢迎关注我的微信公众号:阿宝1990,每天给你汽车干货,我们始于车,但不止于车。

  人生没有最优解,我们大家可以有多种活法,拒绝自我设限。加入本知识星球可以拓展您的圈层,打破您的认知边界,链接到4W+的汽车赛道“局内人”,交换职场信息,打破职场信息差,遇见同行伙伴,共同探索技术交流和职业发展。添加微信qiuq129获取加入方式

  【摘要】从汽车电动化、智能化对于电子电气架构都需要非常大的变化,本文从电子电气架构的起源,从分布式迈向集中式的架构为什么是软件定义汽车的前提,伴随着硬件、软件、通讯架构的升级,在超级计算机还没有到来之前,第三代EE架构是最佳的选择,介绍了主流的第三代EE区域控制器的方案,主流的OEM厂家的架构趋势。

  在2007年由德尔福(DELPHI)首先提出E/E架构的概念,具体就是在功能需求、法规和设计的基本要求等特定约束下,把汽车里的传感器、中央处理器、电子电气分配系统、软件硬件通过技术方法整合在一起;通过这种结构,将动力总成、传动系统、信息娱乐系统等信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、电源管理等电子电气解决方案。

  汽车电子电气架构(EEA,Electrical/Electronic Architecture ),指对汽车的传感器、执行器、ECU、线束、操作系统等整车软硬件进行设计,进而实现车内高效的信号传输、线束布臵等效果。EEA 设计需要考虑客户功能需求,安装、配臵、维护等方面的易程度和成本,并且需要具备适度的超前性。

  通俗来说,汽车是一个软硬件结合的产物,如果把它比作是一个人,「四个轮子+一个沙发」是身体,电子电气架构就等于神经系统,负责完成各个部位的连接,统领整个身体的运作,实现特定功能。

  功能车时代,汽车一旦出厂,使用者真实的体验就基本固化;智能车时代,汽车常用常新,千人千面, 电子电气架构向集中化演进是这一转变的前提。从分布式到域控制再到集中式,随着芯片和通信技术的发展,电子电气架构正在发生巨大的变化。

  电动化智能化浪潮来袭,汽车分布式电子电气架构不堪重负已不能适应汽车智能化的进一步进化。智能驾驶、智能座舱是消费的人能感知到的体验,背后需要强大的传感器、芯片,更需要先进的电子电气架构的支持,电子电气架构决定了智能化功能发挥的上限。假如没有先进的电子电气架构做支撑,再多表面智能功能的搭载也无法支持车辆的持续更新和持续领先,更无法带来车辆成本降低和生产研发的高效。

  最初,燃油车电子元器件数量有限,电子电气架构并不复杂, OEM 根据不同 Tier1 的技术和价格上的优势分别采购 ECM,只有必要进行集成、测试和验证,并不是特别需要掌握技术细节和代码。很长一段时间内, OEM 的工作只是依据市场需求持续不断的增加 ECM 和调整线束布臵,整车 EEA都是由 Tier1 配合 OEM 进行开发,强势的 OEM 可以向 Tier1 提出功能导向的要求,其他 OEM在 ECU 设计制造上不具备话语权。

  虽然 ECU 的数量和汽车配件的复杂程度只增不减,电动化引入三电系统更是加剧了这种态势,但整个行业的惯性始终在强化。一方面, Tier1 缺乏进行自我革命的动力,更高性能的总线技术和 ECU 是主要战场, 另一方面, OEM 考虑到对整车电子电气架构进行重塑式改造的庞大投入也会有所犹豫。

  打破行业僵局,特斯拉提供“拉力”,智能化浪潮提供“推力”。2017 年特斯拉用 Model 3 吹响改革的号角,新一代集中式电子电气架构被推上舞台,智能化的浪潮来临。在Model 3 席卷全球的倒逼下,OEM 和 Tier1 都是必须有所行动。

  分布式架构的极限是 L2 级别的无人驾驶,L3 级别已经超出承受范围。以大众分布式 MQB平台为例,CAN 总线上已经挂了很多 ECU,如果再挂雷达,通信协议总量将不支持,把全部的 CAN 换成 2M 相当于做了半个架构的改造。

  智能座舱和无人驾驶需要更加多的 ECU 和传感器,但分布式 EEA 已经到达瓶颈,算力和总线信号传输速度还远远不能够满足,因此必须引入搭载更高性能车规级芯片的域控制器、车辆以太网和集中式 EEA。根据 NXP 官网预测,2015-2025 年汽车中代码量有望呈指数级增长,其年均复合增速约为 21%。

  实现 OTA 和“软件定义汽车”,智能车必须解耦软硬件。分布式架构的 ECU 来自不同供应商,有不一样的嵌入式软件和底层代码,软件生态复杂,OEM 无法自主进行整车维护,更没办法实现 OTA。而 Tier1 更新 ECM 的周期和新车型的研发周期相匹配,一般为 2-3 年,率先实现 OTA 的特斯拉更新频率则为几个月一次,使用者真实的体验差异明显。在特斯拉已经掌握 OTA 技术的情况下,如果不尽早开始布局,传统车企或将重蹈诺基亚和摩托罗拉的覆辙。

  由分布式 ECU 向域控制/中央集中架构方向发展。从博世对 E/E 架构定义来看, 汽车 E/E 架构的升级路径表现为分布式(模块化→集成化)、 域集中(域控制集中→跨域融合)、 中央集中式(车载电脑→车-云计算)。

  即为分布式 ECU(每个功能对应一个 ECU)逐渐模块化、集成向域控制器(一般按照动力域、底盘域、车身域、信息娱乐域和 ADAS 域等),然后部分域开始跨域融合发展(如底盘和动力域功能安全、信息安全相似),并发展整合为中央计算平台(即一个电脑),最后向云计算和车端计算(中央计算平台)发展。其中车端计算大多数都用在车内部的实时处理,而云计算作为车端计算的补充,为智能汽车提供非实时性(如座舱部分场景可允许微秒级别的延迟)的数据交互和运算处理。

  目前我们正处于从过去的分布式EE架构迈向域集中式EE架构的转变过程中,预计到2025年左右就会完成这一转变。从2025年以后,将开启跨域的融合时代,也就是转变为“中央+区域”(Central & Zonal)计算的EE架构时代。

  一个 ECU 负责特定的功能,比如车上的灯光对应有一个控制器,门对应有一个控制器,无钥匙系统 对应有一个控制器。随着汽车功能增多这种架构日益复杂无法持续。

  单个 ECU 负责多个功能,ECU 数量较上一阶段减少。在这两个阶段,汽车电子电气架构仍处于分布式阶段,ECU 功能集成度较低。

  功能域即根据功能划分的域控制器,最常见的是如博世划分的五个功能域(动力域、底盘域、车身域、座舱域、无人驾驶域)。域控制器间通过以太网和 CANFD(CAN with Flexible Data-Rate)相连,其中座舱域和自动驾 驶域由于要处理大量数据,算力需求逐步增长。动力总成域、底盘域、车身域主要涉及控制指令计算及通讯资源,算力要求较低。

  在功能域基础上,为进一步降低成本和增强协同,出现了跨域融合,即将多个域融合到一起,由跨域控制单元进行控制。比如将动力域、底盘域、车身域合并为整车控制域,从而将五个功能域(无人驾驶域、动力域、底盘域、座舱域、车身域)过渡到三个功能域(自动驾驶域、智能座舱域、车控域)。

  随着功能域的深度融合,功能域逐步升级为更加通用的计算平台,从功能域跨入位置域(如中域、左域、右域)。区域控制器平台(Zonal Control Unit,ZCU)是整车计算系统中某个局部的感知、数据处理、控制与执行单元。它负责连接车上某一个区域内的传感器、执行器以及 ECU等,并负责该位置域内的传感器数据的初步计算和处理,还负责本区域内的网络协议转换。位置域实现就近布置线束,减少相关成本,减少通信接口,更易于实现线束 的自动化组装从而提高效率。传感器、执行器等就近接入到附近的区域控制器中,能更好实现硬件扩展,区域控制器的结构管理更容易。区域接入+中央计算保证了整车架构的稳定性和功能的扩展性,新增的外部部件可以基于区域网关接入,硬件的可插拔设计支持算力不断提升,充足的算力支持应用软件在中央计算平台迭代升级。

  在一项针对某家整车制造商的研究中,安波福发现,使用区域控制器可以整合 9个 ECU,并少用数百根单独电线,从而使车辆的重量减少了 8.5千克。减重有助于节能,并延长电动汽车的续驶里程。此外,由于区域控制器将车辆的基本电气结构划分为更易于管理的组成部分,更容易实现自动化线束组装。

  将汽车部分功能转移至云端,车内架构进一步简化。车的各种传感器和执行器可被软件定义和控制,汽车的零部件逐步变成标准件,彻底实现软件定义汽车功能。

  随着整车电子电气产品应用的增加,单车ECU数量激增,分布式电子电气架构由于算力分散、布线复杂、软硬件耦合深、通信带宽瓶颈等缺点而无法适应汽车智能化的进一步发展,正向中央计算迈进。

  一般芯片在参数设计时按照需求值设计并留有余量,以保证算力冗余,主要因为汽车在实际运行过程中,大部分时间仅部分芯片执行运算工作,而且并未满负荷运算,导致对于整车大部分运算处理能力处于闲置中,算力有效利用率较低。例如泊车使用的倒车影像等仅泊车等部分时段才执行运算操作。采用域控制器方式,可以在综合情况下,设计较低的总算力,仍能保证整车在工作时总算力满足设计要求。

  硬件架构对算力的需求,可类比保险。若个人想要抵御风险, 需要大量资金储备,因此大家都购买保险, 将汇集在一起的保险资金资源池来抵御个人风险,总资金量需求大大降低。分布式架构的芯片即为个人抵御风险储备,而域控制/中央计算平台即为总资金量,域控制/中央集中式显然算力设计需求会更少。另一方面现阶段传统车的智能功能并不丰富,智能车在未来功能扩展等方面预留较多升级空间,若实现同功能应用、驾驶安全条件下进行对比,域控制/中央集中显然更经济;若仅为传统车和智能车对比,智能车单车价值短期内显然为上升的。

  传统主机厂方案采用一个功能对应一套感知-决策-执行硬件,感知数据难以交互,也无法协同执行。而实现真正意义上的高级无人驾驶,不仅需要多传感器共同感知外部环境,还需要对车内部各运行数据进行实时监控,统一综合判断,并且执行机构协同操作。域控制器/中央计算平台可对采集的数据信息统一处理,综合决策, 协同执行

  分布式架构的感知数据无法统一决策处理,无异于盲人摸象。例如,因单一传感器 仅可识别到局部环境, 前方车上有一只宠物狗,各局部识别能力的传感器可获取到狗、 前车、路肩等,但因为无法实时交互,从而反馈到决策-执行层后易产生误操作。而采用域控制/中央计算平台方案可实现多种信息的融合处理,综合判断结果为一辆行驶在路上的车内有一只狗,从而执行合理的操作,提高行车安全性。

  采用分布式架构, ECU增多后线束会更长,错综复杂的线束布置会导致互相电磁干扰,故障率提升,此外也意味着更重。集中式的控制器/中央计算平台的方式可减少线束长度,减轻整车质量。

  Classic AutoSAR 基础软件分为四层,分别为服务层、 ECU 抽象层、微控制器抽象层和运行时环境,运行时环境使应用软件从底层软件和硬件平台相互独立。除此之外还包括复杂驱动程序,由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题,这部分暂时未被标准化。

  Adaptive AutoSAR 相较于 Classic AutoSAR 具有软实时、可在线升级、操作系统可移植等优势。Classic AutoSAR 是基于强实时性(微秒级) 的嵌入式操作系统上开发出来的软件架构, 可满足传统汽车定制化的功能需求,但受网络的延迟、干扰影响较大,无法满足强实时性。随着无人驾驶、车联网等应用的复杂化, 软实时性的软件架构系统 Adaptive AutoSAR 诞生,其主要用于域控制器/中央计算平台,相对于 Classic AutoSAR的优点:

  传统汽车嵌入式软件与硬件高度耦合,为应对越来越复杂的自动驾驶应用和功能安全需要,以AutoSAR 为代表的软件架构提供接口标准化定义,模块化设计,促使软件通用性, 实现软件架构的软实时、在线升级、操作系统可移植等。

  若未实现软硬件解耦,一般情况下增加一个应用功能则需要单独增加一套硬件装置,采集的数据信息仅一个应用功能可以利用。现阶段,自动泊车雷达和自适应巡航的摄像头、雷达采集数据不可交互,若打通整个汽车软件架构,各数据特征有效利用,实现多个应用共用一套采集信息,有效减少硬件需求数量。

  大带宽通信架构以适应车辆日益激增的数据量和低时延要求。自动驾驶需要以更快速度采集并处理更多数据,传统汽车总线无法满足低延时、高吞吐量要求。随着汽车电子电气架构日益复杂化, 其中传感器、控制器和接口越来越多,自动驾驶也需要海量的数据用于实时分析决策,因此要求车内外通信具有高吞吐速率、低延时和多通信链路。在高吞吐速率方面, LIDAR 模块产生约 70 Mbps 的数据流量,一个摄像头产生约 40 Mbps 的数据流量, RADAR 模块产生约 0.1Mbps 的数据流量。若L2 级自动驾驶需要使用 8 个 RADAR 和 3 个摄像头,需要最大吞吐速率超过 120Mbps,而全自动驾驶对吞吐速率要求更高,传统汽车总线不能满足高速传输需求。

  传统汽车总线 LIN/CAN 总线向以太网方向发展, 满足高速传输、低延迟等性能需求。

  在2022年9月20日晚,英伟达发布了全新的智能汽车芯片Thor。相比于公司去年发布的芯片Altan,Thor的AI算力提升了一倍,达到了2000TFLOPS,可同时满足自动泊车、自动驾驶、车机、仪表盘以及驾驶员监测等六重汽车算力需求。Thor芯片是为汽车中央计算架构而生的产品。英伟达对Thor芯片的愿景是用它取代目前汽车内的单独芯片,帮助车企降低生产的成本。但这种超级计算机真的适合现在的车企么?

  由于过去汽车上控制器相互独立,软件为嵌入式,整车做最终硬件集成即可。未来随着 ECU 的减负,原先高度分散的功能集成至域控制器,主机厂必须自己掌握中央控制系统,否则就会失去对汽车产品的控制权。而把原本高度分散的控制功能逐步整合统一起来是传统车企的全新必修课,

  特斯拉 Model3 开启了电子电气架构大变革,出现中央计算雏形+位置域,缩短 50%整车线束,未来目标是将整车线 米,在电子架构方面,特斯拉领先传统车企 6年以上。除特斯拉以外,目前大部分的车企的电子电气架构仍处于早期的功能域控制器阶段,即部分功能集中到了功能域控制器,但还有保留较多分布式模块,即“分布式 ECU+域控制器”的过渡方案,避免因为变革程度太大导致额外的风险及成本。

  大部分企业规划的下一代跨域融合电子电气架构将于 2022年量产,以实现软件高度集中于域控制器,逐步减少分布式 ECU。到 2025 年部分车企落地中央计算+区域控制器的电子电气架构,从而实现软硬件的进一步集成,软件所有权逐步收归主机厂。朝着“中央计算+区域控制”的架构演进的过程可能长达 5-10 年。

  区域内,区控制器与低阶的ECU通信时,有可能会用10BaseT1s(无屏蔽双绞线)代替其他的通信方式,比如CAN、FlexRay等;因此,也会充当IP-based设备(以太网通信设备)与骨干网(车载中央计算机与区控制器级之间的以太网通信)之间的交换机角色;当然,如果区域内的通信不完全被10BaseT1s以太网替代时(有CAN、LIN等通信存在),还会充当传统设备的网关;

  关于TSN主干网(以太网),要具备高带宽和实时通信,同时保证可靠性和fail-operational特性;

  二级配电网络,区控制器负责将电力继续向下输送到底层控制器,因此区控制器需要具备eFuse/高边power distribution功能;

  区控制器会配置ASIL等级高的MCU来实现车辆区域的各种基本功能。同时保证系统功能安全。

  ZCU除了以上基本特性外,可能也会涉及到一些变迁,比如逐步“吸收”区内其他ECU的功能。第一阶段,可能是相对通用化的ZCU,采用标准化软件模块,兼容现有ECU网络(CAN/LIN/FlaxRay);作为数据转发设备,将区内的功能在服务层面就行抽象;第二个阶段,会以降低区内ECU数量为目的,整合其他ECU功能,并将控制I/O虚拟化。可能带来的影响:ZCU的对于计算需求增大,MCU难以满足算力需求,可能还需要增加MPU(增加纯DMIPS算力的SOC,比如Denverton甚至Xeon)来满足算力需求。

  区域控制器是汽车中的节点,在汽车的一个物理区域内,为各传感器、执行器等设备提供电源分配,数据连接和I/O采集与驱动需求。MCU是区域控制器的大脑,区域控制器中的MCU一般需要具备强大的解决能力,有很丰富的通讯接口,同时具备一定功能安全和信息安全等级。下面介绍区域控制器的一些关键技术和MCU解决方案。

  TC3xx微控制器是第2代AURIX™产品,搭载了多达六个TriCore™ 1.62嵌入式内核,每个内核的时钟频率最高可达300MHz。下图是TC3xx家族中的TC39x系列MCU模块图,TC39x的算力达到了4000 DMIPS。

  TC4xx微控制器是第3代AURIX™产品,搭载了多达六个TriCore™ 1.8嵌入式内核,每个内核的时钟频率最高可达500MHz,并且集成一个PPU协处理器,可实现快速向量运算,基础神经网络算法以及其它一些复杂数学算法。PPU在未来的区域控制器中可以被应用于建模,模型预测控制以及防入侵检测等一些信息安全算法中。下图是TC4xx家族中的TC4Dx MCU的模块图,TC4Dx的算力达到了8000DMIPS+72GFlops*1。72GFlops是由PPU贡献的。

  在区域控制器体系中,每个传感器和执行器都根据其位置连接到本地区域控制器,然后区域控制器执行一些数据帧格式转换,汇总数据并通过高速以太网将数据传送至中央处理单元。区域控制器一般通过控制器CAN或LIN总线和挂载在它上面的传感器和执行器通信,或者通过低速以太网或LVDS与摄像头或其他ADAS传感器进行通信。这就要求区域控制器的主控MCU有丰富的CAN和LIN的通讯接口以及高速以太网接口。在区域控制器进行数据转发的过程中,还需要考虑通信延迟的问题,在中央集中式架构中,大部分的控制和执行命令是由中央处理单元发出,有些命令(例如底盘和动力)对于延时有严格的要求,因此对于区域控制器中从高速以太网转发到CAN/LIN/低速以太网接口的延时时间也有了要求。TC3xx/TC4xx家族产品都有丰富的CAN/LIN/Ethernet通讯接口。

  TC4xx产品中更是集成专用的硬件通讯路由模块CRE (CAN Routine Engine)/DRE (Data Routine Engine)。TC4xx中的一个CAN模块中集成了4个CAN 节点,当相同模块中的CAN节点进行数据通信时,可以通过CRE直接实现CAN数据转发,无需CPU和软件介入。当不同模块中CAN节点进行数据转发或者CAN节点和以太网之间进行数据转发,则可以通过CRE+DRE的方式直接实现数据转发,也无需CPU和软件介入。

  这种硬件路由引擎直接实现数据转发的方式大大减少了数据延迟,CAN到Ethernet的转发延时最少可以到15us,CAN到CAN的转发延时最少可以到5us。

  在未来的中央集成EE架构中,通讯数据量不断增加,高速以太网逐渐成为EE架构中的主干网。而为了考虑数据通信安全和冗余,以太网环网架构逐渐成为主流,区域控制器和中央控制单元则都是以太网环网架中的节点。TC4Dx中有2路5Gbps的高速以太网接口和4路10/100Mbps接口,2路高速以太网接入以太网环网(1进1出),4路低速以太网则可以接雷达或者摄像头传感器。2路高速以太网可以通过内部集成的高速以太网桥(G-Ethernet Bridge)直接进行以太网帧转发。4路低速以太网接口之间也可以通过低速以太网桥(L-Ethernet Bridge)直接进行以太网帧转发。低速以太网接口和高速以太网接口之间也可以通过低速以太网桥+DRE+高速以太网桥直接进行以太网帧转发。这种方式大大减少以太网接口之间数据转发的延时时间。

  瑞萨RH850/U2x高性能微控制器产品线用于下一代区域/内建ECU,支持丰富的嵌入式HW关键功能,这些功能是区域应用所特有的,如Hypervisor HW支持、QoS(仅U2B支持)、功能安全和信息安全,以实现无干扰。最重要的是,高性能的NoC(片上网络)结构可以确保每个单独内建的应用程序在外设和内存连接方面的实时行为。

  瑞萨的RH850/U2A微控制器(MCU)被设计为高端车身和底盘应用的跨域平台,以满足日益增长的将多种应用内建到单个芯片的需求。基于28奈米制程技术,32位RH850/U2A MCU建立在瑞萨用于底盘控制的RH850/Px系列和用于车身控制的RH850/Fx系列的关键功能之上,以提供更好的性能。

  瑞萨RH850/U2B系列以RH850/U2A的优势为基础,为解决未来几代汽车的创新E/E架构的挑战而定制。凭借其新的性能水平和高达32MB的内存整合度,RH850/U2B的定位高于RH850/U2A系列,以满足未来汽车整合平台概念的更多要求,同时与系统单芯片(SoC)相比,仍然提供具有成本优势的MCU解决方案。

  4.3.3 欧治半导体龙泉565 + 龙泉560 区域处理器芯片解决方案

  针对智能汽车需求,欧冶半导体可以提供完整领先的第三代E/E架构芯片解决方案,为电动汽车和燃油汽车的智能车灯及基本型端侧智能部件、CMS电子后视镜及增强型端侧智能部件,以及L2/L2+行泊一体ADAS和ZCU区域处理器应用提供高性能、低成本车规级SOC芯片解决方案。

  其中,欧冶通过龙泉560+龙泉565芯片组合完整覆盖了ZCU的全场景业务需求,可以为智能汽车提供高性能、低成本的智能ZCU区域处理器解决方案,满足智能化区域所需的高性能边缘计算、实时通信、智能供电需求。

  欧冶ZCU芯片方案集成高性能R核和M核处理器,集成低延迟CAN/LIN通信处理器和高性能车载以太网交换处理器,内置大容量的片内SRAM和NVM,内置丰富的外围接口,可以满足智能汽车ZCU区域控制器对实时性处理、车载以太网处理、功能安全和网络安全的需求。同时,欧冶ZCU芯片方案支持多路视频AI处理能力,为智能汽车ZCU区域应用预留了充足的能力。另外欧冶芯片配套提供成熟、稳定、易用的SDK和平台化解决方案,可以满足客户产品快速量产需求。

  特斯拉是汽车电子电气架构的全面变革者, 2012年 Model S 有较为明显的功能域划分,包括动力域、底盘域、车身域, ADAS模块横跨了动力和底盘域,由于传统域架构无法满足无人驾驶技术的发展和软件定义汽车的需求,为解耦软硬件,搭载算力更强大的主控芯片,必须先进行电子电气架构的变革,因此 2017 年特斯拉推出的 Model3 突破了功能域的框架,实现了中央计算+区域控制器框架, 通过搭建异域融合架构+自主软件平台,不仅实现软件定义汽车,还有效降低整车成本,提高效率:

  特斯拉 Model3基本实现了中央集中式架构的雏形,不过 Model3距离真正的中央集中式架构还有相当距离:通讯架构以 CAN总线为主,中央计算模块只是形式上将影音娱乐 MCU、无人驾驶 FSD以及车内外联网模块集成在一块板子上,且各模块独立运行各自的操作系统。但无论如何, Model3 已经践行了中央计算+区域控制的电子电气架构理念框架,领先传统车企 6 年左右。

  通过三款车型的演进,特斯拉的新型电子电气架构不仅实现了 ECU数量的大幅减少、线束大幅缩短( MODEL S 线 减少一半以上),更打破了汽车产业旧有的零部件供应体系(即软硬件深度耦合打包出售给主机厂,主机厂议价能力差,后续功能调整困难),真正实现了软件定义汽车, 特斯拉的 OTA 可以改变制动距离、开通座椅加热,提供个性化的用户体验, 由于突破了功能域,特斯拉的域控制器横跨车身、 座舱、底盘及动力域,这使得车辆的功能迭代更为灵活, 用户可以体验到车是常用常新的,与之形成鲜明对比的是,大部分传统车厂的 OTA 仅限于车载信息娱乐等功能。

  左车身控制模块负责左车身便利性控制以及转向、制动、助力等。右车身控制模块负责右车身便利性控制、 底盘安全系统、动力系统、热管理等。中央计算模块包括自动驾驶模块、信息娱乐模块、车内外通信连接,共用一套液冷系统。自动驾驶及娱乐控制模块接管与辅助驾驶有关的传感器——摄像头、毫米波雷达, 将对算力需求较高的智能驾驶、信息娱乐放在一起,便于智能硬件持续升级, 2019年特斯拉推出自研 FSD芯片替换了基于英伟达 Drive PX2 芯片组, AI计算性能提升达 21倍,随着特斯拉将自动驾驶最核心的计算硬件实现自研,特斯拉大幅提升了相对于竞争对手的领先优势。操作系统基于开源 Linux进行定制化裁剪,并自研中间件,软硬件均实现了自主可控,车型功能迭代更新速度加快,整车开发成本降低。

  新势力三强中小鹏汽车在电子电气架构方面走得比较领先,随着车型从 G3、P7和P5,迭代到 G9 的这套X-EEA3.0电子电气架构,已经进入到中央集中式电子电气架构。凭借领先一代的架构,搭载更高算力SOC芯片及更高算力利用率,小鹏G9或成首款支持 XPILOT 4.0 智能辅助驾驶系统的量产车。

  分层域控——功能域控制器( 智驾域控制器、车身域控制器、动力域控制器等模块)与中央域控制器并存;

  因此 CAN 总线和以太网总线并存,大数据/实时互均得以保证;以太网节点少,对网关要求低。

  因此CAN总线和以太网总线并存,大数据/实时互均得以保证;以太网节点少,对网关要求低。小鹏第二代电子电气架构实现传统ECU数量减少约60%,硬件资源实现高度集成,大部分的车身功能迁移至域控制器,中央处理器可实现支持仪表、信息娱乐系统以及智能车身相关控制的大部分功能,同时集成中央网关,兼容 V2X 的协议,支持车与车的局域网的通信,支持车与云端的互联,车与远程数字终端的连接功能。小鹏汽车的智能驾驶域控制器,集成了高速NGP、城市GNP及泊车功能。小鹏辅助驾驶采用激光雷达视觉融合方案,与特斯拉的纯视觉方案不同,这就导致两者硬件架构不同,对于通讯带宽、计算能力的要求也不一样。

  得益于小鹏汽车的全栈自研能力,新架构做到了硬件和软件的深度集成,不仅实现软硬件解耦,也实现软件分层解耦,可使得系统软件平台、基础软件平台、智能应用平台分层迭代,把车辆的底层软件和基础软件与智能、科技、性能相关的应用软件脱离开,在开发新功能时,只需要对最上层的应用软件进行研究和迭代就可以,缩短了研发周期和技术壁垒, 用户也能够享受到车的快速迭代。

  系统软件平台:基于外购代码做部分定制开发,随整车基础软件平台冻结而冻结, 可复用于不同车型;

  基础软件平台:多个整车基础功能软件均形成标准服务接口且在车辆量产前冻结, 可复用于不同车型;

  智能应用平台:如自动驾驶、智能语音控制、智能场景等功能,可实现快速开发和迭代。

  X-EEA 3.0 数据架构方面,域控制器设置内存分区,升级运行互不干涉,便用车边升级,30分钟可升级完成。

  通信架构方面, X-EEA3.0 在国内首次实现了以千兆以太网为主干的通信架构,同时支持多通讯协议,让车辆在数据传输方面更快速。从G9 搭载的新一代电子电气架构可以看出,小鹏在骨干网络的建设和面向 SOA 的方向起步较早。

  上图各控制节点的含义如下图所示,例如ACSM表示高级碰撞安全模块,AHM表示拖车模块,DSC为动态稳定控制模块,BDC表示车身控制模块,EGS表示电子变速箱控制模块,HU-H表示娱乐控制模块,PCU表示动力控制模块,RAM表示音频接收模块,KAFAS表示基于摄像头的驾驶员辅助系统,IHKA为集成集成自动暖气/空调模块,SAS表示选装模块,即为ADAS模块,SMBF表示驾驶员座椅控制模块。

  各节点之间的通信方式包括以太网、FlexRay、CAN总线所示中灰色表示以太网总线,包括两线的OABR以太网和五线以太网,无线以太网大多数都用在BDC与OBD2之间的交互,单独的以太网通信节点如下图所示,深红色表示FlexRay总线,黄色表示CAN总线。CAN总线中又分K-CAN、PT-CAN、Local CAN,K-CAN表示通信CAN,K-CAN1用于BDC与音频接收模块RAM、FZD通信,K-CAN5用于BDC与NFC、远程接收器FBD,K-CAN6用于BDC与右灯光控制模块FLER、左灯光控制模块FLEL通信;PT-CAN为BDC与动力相关模块,包括DME、DHC等模块,Local-CAN为SAS,即ADAS控制器与传感器单元通信。

  其中最值得一提的是SAS、BDC、HU-H分别为ADAS、车身、座舱域控制器,三者之中都集成了以太网交换机和网关。

  在ADAS方面,BMW的无人驾驶硬件架构采用的是增量式发展,比如L2的硬件架构可以作为L3/4/5级的备份,如下图所示。分别包含mPAD,hPAD,uPAD。

  而在电子电器架构方面,宝马也在探讨在中央计算平台架构下的动态可配置系统(Dynamic Reconfigurable System,简称DRS),在满足功能安全的前提下,在Zonal控制器层面进行动态配置,使得其可以快速和之前的设计的ECU进行兼容。

  宝马的动态可配置系统如图14所示,其中分为三层,最底层为依赖硬件的电子电气架构,主要是执行器和传统的ECU,中间层为面向服务的系统,主要是是区域控制器ZCU组成,最上层为中央计算平台。其中最底层与中间层通过CAN总线进行通信,ZCU之间或者是ZCU与上层计算平台之间通过以太网进行通信。DRS的目的是实现基于处理器的Fail-Operational,目标是检测HDS和和ZCU本身的故障,然后采取对应的措施,保证功能正常运行。

  人生没有最优解,我们大家可以有多种活法,拒绝自我设限。加入本知识星球可以拓展您的圈层,打破您的认知边界,链接到4W+的汽车赛道“局内人”,交换职场信息,打破职场信息差,遇见同行伙伴,共同探索技术交流和职业发展。添加微信qiuq129获取加入方式