|
引言： 前段时间，集度发布了其首款汽车机器人ROBO-01，并在发布会上提到了一个令笔者比较感兴趣的词：“舱驾融合”。其实早在集度之前，上汽零束也提出过舱驾融合的概念。而有些车企，虽然没有明确提出舱驾融合，但其智能驾驶和智能座舱产品，也或多或少地有着舱驾融合的形态。 那么，什么是舱驾融合？目前企业在舱驾融合上在做怎样的探索？舱驾融合方案的优势和面临的挑战是什么？舱驾融合对开发模式和产业链格局又会带来什么样的影响？带着这些问题，笔者访谈了相关领域的技术专家，希望能够对“舱驾融合”有更深层次的理解。
1. 厘清“舱驾融合”概念 众所周知，汽车的智能化程度取决于底层的EE架构。在汽车智能化的进程中，EE架构的发展路线从功能独立的分布式架构，到功能集成的域集中式架构，最后再到高度集成的中央计算＋区域控制的中央集中式架构。
均联智行首席架构师汪浩伟认为：“舱驾融合可以从硬件和软件两个不同的层面去考虑，从不同层面进行融合的概念是完全不同的，目的和作用也完全不一样。 “硬件上的融合更多地是基于产品的视角，从成本和设计的维度进行考虑。在一颗SoC芯片里面做融合，才是真正意义上的硬件融合。这个时候，底层软件和通讯方式都会有本质上的改变，成本上的优势也会凸显出来。 “软件上的融合更多地是基于技术的视角，从功能的维度进行考虑。软件上的融合需要考虑怎么去改变整体软件架构设计，从而使得新的软件架构能够更加适用于舱驾融合系统。与此同时，引入SOA面向服务的设计理念和工具，可以帮助主机厂更好地做好舱驾融合。 “软件上的融合不会随着硬件上的融合而变化。不管硬件是做成一个单SoC芯片，还是做成一个单板，亦或是做成两个单板，从软件融合的角度来讲，区别并不大，只是底层的通讯和运行方式会有所不同。从功能层面来讲，只有软件上的融合才会改变应用程序和上层逻辑本身，舱驾融合意义才会更大。” 1.1 舱驾融合层级的划分 1）应用层面的融合 由于技术发展和工程化的问题，现阶段比较容易实现的方案是：在物理形式上，智能驾驶域控制器和座舱域控制器采用完全相互独立的两个盒子，但在应用层面，很多功能之间的信息交互通过跨域进行打通，并实现数据融合创新 —— 将智能座舱中的人机交互、沉浸式体验等内容，与智能驾驶的各项功能深度结合、联动，从而提升用户的安全感与舒适感，增强用户对智能化汽车的使用体验。 环宇智行COO曹晶提到，他们有一个项目，主机厂要求统一采用SOA架构，通过以太网或CAN协议把座舱域和智驾域中的信号能够发送出来共享，这样一来，在功能层面就可以做更多的融合创新。如果按以前的策略，两个域的信号基本都是固定写死的，虽然可以通过私有CAN转发到整车CAN总线上，但是，系统需要获取相关信号的时候，还得再去整车CAN总线上查询，非常不方便。 2）座舱域控制器和智驾域控制器在物理形式上合二为一 座舱域控制器和智驾域控制器合并成一个盒子，内部由多个SoC或者MCU芯片构成。这些芯片用于支持不同的功能，每个芯片以及芯片内的不同核上运行不同的操作系统。这种形式又可再细分成两种方案：A. 座舱和智驾功能分别部署在不同的板子上。B.座舱和智驾功能部署在同一个板子上。 “如果座舱和智驾功能分别部署在不同的板子上，用于支持座舱和智驾功能的SoC芯片肯定都会有自己专属的外围电路设计；如果两者的功能部署在同一个板子上，设计方案可以从整体上去考量，包括器件的选型，电路、供电、存储等方面的设计，比如，考虑DDR是否可以共享、EMMC模块是否可以共享等等。整体来讲，B方案比A方案在电子器件、接口、线束等部件的使用量上有一定程度的减少，使得BOM成本相对较低。”曹晶表示。 3）基于单SOC芯片的舱驾功能融合 智舱和智驾的功能由一颗单SoC芯片来完成 —— 在芯片上运行虚拟机，通过虚拟机分割出不同的功能模块，来实现不同安全级别需求的舱驾功能。 目前，有一些芯片公司和主机厂在探讨这样的方案，未来也很有可能会有这样的一些芯片产品出现。但是，理想很丰满，现实很骨感，短期内应该是很难看到这样的理想方案落地。 据业内专家透露，大部分车型无论是对于成本，还是可靠性都比较敏感。同样，开发一个新车型，车型的上市周期也会有一定的要求，所以主机厂一般会首选技术成熟度较高，并且成本已经在行业内能够被分摊下来的成熟方案。另外，不管是主机厂的组织架构，还是对应用层的梳理，都需要很长时间去调整和消化。因此，这样的产品需求不会一下子就爆发出来。 1.2 什么是真正的舱驾融合？ 芯片作为汽车智能化的核心硬件，在很大程度上影响着智能座舱和智能驾驶的能力上限。因此真正的舱驾融合需要智舱与智驾芯片一体化，即智舱与智驾的软件和算法完全部署在同一颗SoC芯片上，这是最理想的方案。但受限于软硬件技术水平、架构方案、供应链等方面的原因，目前还难以实现基于单SOC芯片的舱驾融合方案。 映驰科技产品副总裁赵建洪讲到：“我们首推的是舱泊融合方案，并且，主机厂对舱泊融合也有一定的需求。因为泊车方案现在比较成熟，同时，座舱域控制器上的算力也有了一定的富余，把泊车功能融合到座舱域控制器具有一定的成本优势。不过，舱泊融合相当于是舱驾融合的第一步，由于行车方案目前还不是很成熟，需要两者都发展成熟的时候，再去考虑融合的问题。” 汪浩伟也提到了类似的观点：“座舱和智驾集成在一个单SoC芯片里面，肯定是大势所趋的。在成本的驱动下，这种方案大概率会从中低端的车型开始出现（舱泊一体）。待EE架构进化到中央集成 区域控制架构阶段，并且业内逐渐地把底层软件铺设好，最后才能看到两者融合所带来的真正价值。” 为什么依然有企业有动力去做两者的融合？因为在应用层面上，两者之间可以互相借力。之所以现在舱驾融合的应用价值还没有被完全挖掘出来，是因为底层的软件设计还没达到相应的程度，需要将底层的逻辑进行封装，比如，做成一个个微服务的形式。在这样的情况下，座舱和智驾之间就可以更容易地去相互调用对方的服务或者资源，进而就能够比较容易地去开发新的融合应用。” 1.3 在什么阶段，舱驾才有必要融合？ 智能座舱和智能驾驶，作为汽车智能化的代表，直接影响车主对汽车智能化的体验。智能座舱是汽车直接与用户沟通、交流的部分，体现的是人与车的交互；智能驾驶则发挥汽车最基本的功能，即行驶，体现的是车与环境的交互。而在交通环境中，驾驶行为是人-车-环境三方交互的过程，因此，汽车作为重要的载体，如何打通三方的交互，让驾驶员和乘客获得好的驾乘体验，就显得尤为重要。 那么，舱驾融合在什么阶段才更有意义，是L3级以上，还是L3级及以下？在访谈的过程中，笔者发现大家的理解目前也存在差异 —— 有的人认为，在L3级及以下才有必要融合；也有的人认为，在不同的自动驾驶阶段都有必要融合，只不过融合的形式和意义不同而已。 1）观点1 ：只有在L3级及以下融合才有意义 在L3及以下的时候，系统只是辅助驾驶，驾驶员还是要对车辆的安全负责。人坐在舱内，对舱外的行车环境并不一定能够充分了解，因而，只有座舱和智驾进行信息打通和融合，座舱才能更清楚地了解自动驾驶系统在干什么，舱外的环境是怎样的。座舱结合智驾的一些传感器数据信息，才能更好地把车外的环境信息反馈给驾驶员，帮助或指导驾驶员更好地开车。 当自动驾驶等级达到L4的时候，人就脱离了驾驶任务，座舱里面的人就不再需要关心车外的情况，整个座舱会变成一个以娱乐和工作为中心的“第三生活空间”。这个时候，自动驾驶系统就基本没有必要介入到座舱 —— 如果驾驶任务都已经完全交给系统去完成了，自动驾驶系统还时不时地去“烦”座舱里的人，那这还算是真正的“自动驾驶”么? 2）观点2 ： 都有必要融合，只不过两者融合的形式和深度不一样 A. L3及以下 - 硬件独立，上层应用融合 对于L3及以下 ，硬件层面可能并不需要融合，只是在上层应用层面基于一些信息的交互，做一些融合类的功能。 目前，应用在座舱和智驾的一些芯片，比如应用在座舱上的高通8155、智驾上的TI TDA4，经过这两年的产业化路径已经变得非常成熟，在硬件相互独立的前提下，底层就不需要再做太多的工作，因此就不需要过多的工程化的投入或者是成本上的增加，通过虚拟现实或一些其它的方式，就可以在应用层打造出一些更加沉浸式的体验。例如，人工智能语音公司Cerence Inc发布的Cerence Look，结合了在线数据库和视线跟踪摄像头数据，将汽车的语音助手变成实时导游。驾驶员不需要使用特定的唤醒词，而是使用环境重建和传感器数据来确定车辆的位置，并确定驾驶员提出问题时正在看什么。 B. L4级 - 软硬件均开始融合 在EE架构集中化、芯片算力的大幅提高以及软件开发能力提升的不断推动下，智驾和智舱从底层硬件层面开始进行融合。而应用层级的融合是车辆功能和性能的外在表现形式，又会受到底层硬件和软件的制约。只有底层硬件和软件融合得足够深，上层应用才有可能发挥出最大的融合效果。 当自动驾驶发展到L4级，即无人驾驶阶段，人从驾驶任务中解放出来，汽车本身成为服务的载体，座舱的设计思路将从以驾驶员为核心转向以乘客为核心。那么，座舱和智驾之间的融合应用也将从提供辅助驾驶相关的信息为主，转变为以提供生活服务相关的信息为主。在这个阶段，仪表或者HUD上便不再需要显示一些驾驶员接管的提醒或其它一些用于辅助驾驶的图像信息（比如用于泊车的360全景信息显示），更多地会展示一些娱乐和工作相关信息（比如，基于车外的摄像头数据在舱内展示一些车外的风景信息等）。 2. 舱驾融合的初步尝试 - 特斯拉 特斯拉是中央计算 区域控制理念的最早实践者，其在2019年量产的Model3车型中率先采用了此架构。其中，中央计算单元CCM融合了影音娱乐模块（座舱）、驾驶辅助系统模块（智驾）以及车内外通信信通模块，只不过三个模块分别部署在不同的板子上，运行着各自独立的操作系统，这算是舱驾融合形式在早期的一个初步尝试。 2.1 特斯拉舱驾融合方案简介 中央计算平台（CCM）的硬件构成（参考2021款ModelS）： A.信息娱乐控制单元的主控芯片（更换至第三代）：AMD Ryzen YE180FC3T4MFG B. 驾驶辅助系统控制单元的主控芯片：2个自研FSD  在软件层面： A.信息娱乐控制单元采用自研的车机操作系统，它基于开源的 Linux 操作系统进行定制开发。 B.驾驶辅助系统控制单元上的MCU运行FreeRTOS，SoC上采用基于Linux进行深度定制开发的Version操作系统。 2.2 特斯拉舱驾融合方案的优势 1）更高效的通讯 座舱和智驾分属于两个不同控制器的时候，两者之间需要通过CAN或者以太网总线进行通讯；而现在，两者虽然还是部署在不同的PCB板子上，但是可以部署在一个盒子里面，两个板子之间通过Switch就可以实现通讯，通讯速率更高。 2）共用一套散热系统，节省成本 现在座舱和智驾需要实现的功能越来越多，所需的算力越来越大，功耗也越来越高，因此座舱域控制器和智能驾驶域控制器都需要做散热设计。尤其是对于大算力的智驾域控制器，还需要做专门的水冷散热设计。如果两者放在一个盒子里面，散热系统就无需再做两套，可直接共用一套冷却系统。 3）节省空间，易于布置 集成到一个盒子里，比较容易布置，并且整车空间利用率也会更高。 单单上面的几点好处，大家肯定也会觉得有点单薄——不足以驱动特斯拉去采用这样的方式，那么特斯拉采用这种方案背后真正的驱动力是什么呢？ 据业内专家透露，特斯拉并不只是为了实现舱驾融合，才要做个CCM模块把座舱和智驾的两个板子放在一起， 其真正的目的是为了实现中央计算 区域控制器的架构。而中央计算平台则需要整合其它功能域的功能，但受当时软硬件水平、架构方案等限制，即便是特斯拉也没办法将主要的域控融合到一颗SoC芯片上，但至少把他们都集成到了一个盒子里面去，这也算是比较有意义的一次初步探索。 虽然特斯拉的这代架构并不是真正意义上的中央计算 区域控制器架构，但当时也是业内公认的最先进的EE架构，被认为是领先同行至少5~6年。特斯拉采用这样的EE架构，背后的驱动力就是为了实现软硬分离、软件定义汽车——通过采用区域控制器，把硬件剥离掉，并把硬件的变化隐藏在区域控制这层，使得中央大脑能够做到与硬件相对“无关”，真正的地用软件去控制车辆的各个方面。 2.3 为什么很少有其它主机厂去效仿特斯拉的舱驾融合方案？ 特斯拉这种把座舱和智驾模块放在一个盒子里面，从表面上看，感觉技术难度也不大，为什么到现在依然很少有其它主机厂去效仿特斯拉，是否存在一些技术壁垒和局限性，导致没有实力的主机厂想模仿却模仿不了，而有实力的主机厂因为其中的局限性而选择了去规划其它方案？ 2.3.1 特斯拉舱驾融合方案的技术壁垒 1）电磁干扰设计有难度 特斯拉的CCM模块内，因为不同板子之间都是高速信号在传输，板子之间会存在电磁互相干扰的潜在问题，怎样消除不同板子之间的电磁干扰会存在一定的难度。 2）需要对整个系统架构有很深的理解 某主机厂智能驾驶系统架构专家讲道：“特斯拉的整个系统架构都是自研的，包括它的子系统和关联系统。怎么去设计硬件架构和软件架构、需要预留哪些接口、在前期都需要考虑得非常清楚。然而，在国内能够把座舱、智能驾驶和整车控制这三大部分都能想明白的OEM几乎没有。” 2.3.2 特斯拉舱驾融合方案的局限性 1）不适合平台化应用 传统的主机厂面向的用户更多，价格区间更广，从十几万到二十几万，再到三十几万及以上的车型都有；并且，一种车型还要做高中低不同配置。所以，特斯拉当前的这种舱驾融合方案，对于大多数需要考虑平台化的传统车企并不一定适用。 汪浩伟解释道：“特斯拉的车型比较少，在考虑EE架构应用的时候，首先是要从车型本身的竞争力的角度去考虑，不会考虑太多平台化，所以软件设计上基本也没有什么平台化的概念。如果换成是大众，有这么多品牌，各个品牌旗下又有那么多车型，那么他在做EE架构的时候，一定会去考虑平台化的问题，正所谓'大象难转身’，它在推进这样一个新EE架构的时候，面临的困难必然更多。” 2）不具备较强的扩展性 特斯拉的CCM模块在当初量产时的确算是比较先进的产品，但智驾和智舱都是处在快速地发展迭代中，对算力的需求也越来越大；因而，站在现在这个时间点上来看，特斯拉CCM模块的算力资源就有点捉襟见肘，同时，受其硬件结构形式的限制，它又很难在原来的基础上进一步扩充算力资源。 创时智驾首席产品专家杨曾提到：“如果考虑扩展性，软件还可以通过OTA更新来实现，但是舱驾融合域控制器硬件的可扩展性如何实现？如果前期能够为座舱和智驾预留足够多的接口和算力资源，那么后期也许还可以逐渐增加新的功能。但现实是，座舱和智能驾驶技术都还处于不断地发展中，尤其是智能驾驶，迭代速度更快，前期很难把规划做得完美无缺，若后期再改动，其设计和平台验证都需要很多的时间和资源投入。” 3. 国内企业舱驾融合方案的探索 3.1 Tier1 1）德赛西威 基于多SoC芯片的舱驾融合方案 2022年4月，发布车载智能计算平台“Aurora”—— 实现从了从域控制器向中央计算平台的跨越。  2）创时智驾 基于多SoC芯片的舱驾融合方案（据推测）  3）中科创达 A.基于高通SA8295的舱泊融合方案（座舱和泊车功能融合） 2022年初，发布基于高通SA8295芯片的硬件平台，实现一芯多屏座舱域控方案，并在高算力（CPU算力200K DMIPS、GPU算力3000G FLOPS、 NPU算力30 TOPS）和多摄像头支持能力下，实现座舱和低速泊车功能的融合，支持360°环视和智能泊车功能。 B. 基于高通SA8795芯片的舱驾融合方案（座舱和智驾功能融合） 基于高通SA8795芯片（预计，CPU算力240K DMIPS、 NPU算力60 TOPS）布局座舱和智能驾驶的跨域融合方案，并计划于2024年实现量产。 3.2 主机厂 1）小鹏 A . 应用层级的融合 —— SR智能辅助驾驶环境模拟 该技术是基于高德第三代车载导航实现的。在技术方案上，将导航与高精地图深度融合，并将智驾系统的感知、决策信息与车道级导航更加精准地匹配。 在NGP功能激活的状态下，小鹏可以实现“SR智能辅助驾驶环境模拟”，将环境感知、定位、高精地图和高清渲染的画面融合，模拟真实的路况。SR（Surround Reality）系统能够展现驾驶员和智驾系统的责任边界，并提供准确的风险场景识别和清晰的分级接管提醒，告知驾驶员接管车辆的时机，增强人机共驾的安全性与可靠性。   小鹏G9舱驾融合方案：上一代的中控系统CDU、仪表系统ICM和智驾系统XPU，在此方案中会整合到一个舱驾一体域控制器中。 2）上汽零束 基于多SoC芯片的舱驾融合（据推测）  银河全栈3.0软件平台 （图片来源: 上汽零束宣讲资料） 3）集度汽车 应用层级的融合 —— 集度发布的舱驾融合，主要体现在两个方面的应用：一是智能驾驶“真冗余”的方案，二是3D人机共驾地图。 A. 智能驾驶“真冗余”方案 集度的智驾“真冗余”是指当智驾域控失效时，智舱域控可以顺利接管车辆，起到冗余备份的作用。具体来说，就是将12个摄像头中的1个前视摄像头接入到智舱域，从而在紧急情况下，智舱的域控制器可以基于该摄像头的路况感知信息，实现紧急制动或者靠边停车功能。 B. 3D人机共驾地图 集度在座舱内基于现实环境通过仿真建模为驾驶员构建了一个虚拟的驾驶世界，实现静态地图导航和动态感知数据融合，打通虚拟场景与现实交通环境的障碍。从集度发布的视频来看，通过智能座舱和智能驾驶系统之间的跨域资源调度，智能驾驶系统感知到的障碍物模型支持直接可视化融合显示在 3D 地图上，提供了还原现实的虚拟化驾驶体验。 4 . 单SoC芯片的舱驾融合方案 特斯拉目前采用的方案属于舱驾融合的一个初期探索，只是把座舱和智驾的域控制器合二为一集成在一个盒子里面。以后，如果能够实现真正的舱驾融合——把座舱和智驾的功能完全集成在一颗SoC里面来实现。这样的方案又会带来哪些好处？同时，实现这样的方案又将面临怎样的挑战？ 4.1 单SoC芯片方案带来的好处 1） 成本可以做得更低
2）通讯时延更短 相比于之前通过网络总线传输的方式或两个板子件通过Switch通讯，现在可以使用内存共享的方式，通讯时延会更短。 3）OTA升级空间更大 某主机厂自动驾驶系统架构专家认为：“舱驾融合后，数据信息可以共享，两者之间的交互可以做得更多，软件迭代的想象空间会更大。如果两个域还是完全独立，接口基本上是固定的，接口变，双方软件就要跟着变，比如在后期，一些主机厂会要求增加一个新功能，就需要订阅一些服务，会发现订阅不了，因为之前的接口是定义“死”的，除非在开始的时候就能够把接口定义得特别丰富，否则，一旦后期需要做变更，就需要跨部门提变更需求，再次跨部门进行协作，沟通成本很高。如果两者融合了，再增加新的功能，一般只需要对软件模块做一些变更，不再需要变更硬件接口，便于在后期做一些系统上的OTA升级。” “座舱域控制器和智能驾驶域控制器相互独立的时候，他们之间可互通的信息比较少，也很难及时获取对方的数据信息，但舱驾融合以后，两者的传感器数据便可以更充分、更及时地被复用。相当于在功能层面留下更多的想象空间 —— 基于座舱和智驾的这些传感器数据，可以融合出一些比较新的、有想象力的应用。” 杨曾说道。 4.2 单SoC芯片方案面临的挑战 4.2.1 硬件层面的挑战 1）芯片本身的设计 实现真正的舱驾一体融合方案，SoC芯片设计本身就是个很大的难题 —— 要把很多的系统和功能融合在一起，芯片的设计方案会很复杂。同时，单SoC芯片不仅要实现上千TOPS的算力，还要把功耗控制在可接受的程度内，这对芯片的制程要求非常高。现在的车载AI芯片已经下探到5nm了，不仅成本高，而且掌握这种先进工艺的企业也寥寥无几。 有业内人士提到了使用Chiplet来设计这样的SoC芯片，它的优势在于各家芯片厂商可以专注自己的芯粒和IP，不用为多余的IP买单，并且小芯粒的流片良率更高，有坏点的部分扔掉，剩下的还能用。因此，采用小芯粒技术进行SoC芯片的迭代设计会更加方便。但是，目前也存在一些问题 —— Chiplet技术，又被称为小芯粒技术，即把不同制程的芯粒经过选型直接封装在一个SOC里面。目前业内已有一些成功的应用案例，并且整个行业也在推动。曹晶告诉九章智驾：“基于Chiplet技术实现舱驾融合的SoC芯片不难被设计出来，只要产业链端能够提供足够多满足智驾和智舱的芯粒就可以。 我觉得使用芯粒技术最大的挑战不在单个芯粒内部的这些设计和实现，反倒是高速带宽部分，毕竟芯粒之间也是需要进行大通道数据的输入输出。 “同样，Chiplet技术不仅面整个产业链成熟的问题，而且在SoC芯片上面实现智舱和智驾这些复杂功能也会涉及到很多工程化的问题，这些问题可能会比把芯片设计出来所花的时间还要长。整个行业讨论这种技术方案比较多，在实践上也有企业在向这个方向发展，但是我觉得离真正在车上量产应用尚且需要一段时间，不过至少这个方向的国产自主化趋势是窥见一斑了。” 2）硬件资源分配 智舱和智驾功能融合在一个单SoC芯片里面，芯片内部的GPU和CPU等资源可以共享，但是资源该如何分配？哪一块GPU/CPU资源供智能驾驶使用，哪一块GPU/CPU资源供座舱使用，怎样实现资源的动态调节？并且，智舱和智驾都处于不断地迭代发展中，如果智能驾驶发展两年，技术迭代升级了，对硬件的需求变了，之前硬件资源分配方案可能就不行了，还需要重新做资源分配。 同时，对于单SoC芯片的舱驾融合方案，很有可能要做内存共享，这样数据才会读得更快，信息传输延迟会更小。但是，DDR分配也会面临很多问题 —— 比如，智驾的内存需求发生变更，另外一个也要跟着变更；在座舱开发的时候，内存损坏，也会影响到自动驾驶的开发。 某主机厂自动驾驶系统架构专家告诉九章智驾：“当前，座舱和智驾尚未达到一个终极形态，硬件资源也没有足够强。两者在硬件资源需求上的变动很可能会影响到整个软件架构，以及后续硬件资源的分配。比如，对于CPU资源，有些ARM核用于支持座舱相关应用，有些ARM核用于支持智能驾驶相关应用；对于GPU资源，可能会通过制定一个优先级进行资源使用或者直接把GPU隔离成不同部分，座舱用一部分、智驾用另外一部分；但问题的关键是 - 对于这种架构设计，大家都没有太多经验可以借鉴，比如，硬件资源怎么去分配，分配是否合理？后期面临需求变更的时候，会不会没办法实现？这些问题都会存在很大的不确定性。” “智能座舱和智能驾驶功能集成在单颗SoC芯片上的时候，因为两个域的需求完全不同，在做硬件资源分配的时候，既要定义这些应用的优先级，又要确保这些应用有足够资源可以用 —— 能够保证互相不打架，也不能出现一个应用锁死另外一个应用的现象。”汪浩伟表示。 4.2.2 软件层面的挑战 1）OTA升级策略 智能座舱和智能驾驶两者的OTA软件模块、升级模块的数据量、数据包的大小可能都不太一样，在这样的情况下，做好OTA的升级策略也存在一定的挑战。 赵建洪认为，舱驾融合后，座舱发布的数据包和智驾发布的数据包需要要整合在一起才能升级。因为涉及很多的功能，如何更好地整合在一起会有一定的难度。同时，两者有各自的功能升级策略，有的升级频率是三个月，有的升级频率为半年。并且，座舱升级频率比较高，并且座舱还经常容易出问题，出问题就要升级，临时更新内容也需要马上升级。 2）软件上的安全隔离 SoC上面需要隔离出不同区域，并且适配好不同的操作系统。A核上面一般会跑 Linux或QNX系统；内置MCU、M核或R核上会跑AUTOSAR CP。 汪浩伟讲到：“对于舱驾融合方案，在软件上进行整合，并做好安全隔离，确保不同应用的功能安全和信息安全。如此一来，座舱便不会影响自动驾驶，自动驾驶也不会影响到座舱。隔离是系统设计的问题，要从系统设计出发去考虑怎么去做隔离方案。随着芯片的集成化程度越来越高，方案会越来越统一，直到有一天大家都用一种或少数几种芯片、一种操作系统，并且应用程序也非常固定的时候，功能安全方案才会固定下来。不然，功能安全方案永远是跟着项目走，一个项目可能就需要采用一种功能安全方案。 “安全级别不一样的软件放在一起如何共存？既要保证安全件的绝对安全性，又要保证非安全件的“人权”，—— 他们不是“奴隶”，也需要获取一部分资源。可以在操作系统上面再嵌套操作系统，虚拟机是一种，也可以采用Container的方式去做。通过这些方式都可以在软件层面上把不同的应用隔离出来，但更大的问题在于隔离完以后该怎么办？—— 通讯怎么解决、调度怎么解决、资源怎么保证，这些问题才是更主要的。” 目前座舱和智驾中相关模块对功能安全的要求：座舱的中控娱乐模块需要达到ASIL A等级，仪表模块需要达到ASILB等级；智驾的泊车模块至少需要达到ASILB等级，行车模块需要达到ASILD等级。那么芯片底层的加速器资源针对这些不同功能安全等级的应用如何进行有效隔离也是一个比较大的挑战。 杨曾举例说：“以GPU为例，既可以用于做深度学习，又可以用于图像渲染，但是在系统设计的时候，到底留多少给座舱做图形渲染，又留多少给智驾做AI计算？GPU资源的划分既要满足不同功能域的需求，又要支持不同域功能安全的隔离，同时还要保证不同域的数据流能够互相访问复用，这不仅对芯片底层设计，甚至对整个系统软件的设计，都提出了比较高的要求。” 3）虚拟机技术带来额外的硬件开销 舱驾融合需要在操作系统层面做虚拟化技术，但虚拟化技术并非解决问题的完美方案。因为采用虚拟机将会占用一定的硬件资源。据业内相关人士透露，采用虚拟机将会导致额外增加10%以上的CPU开销，同时在商业层面，虚拟化也会带来更多的授权许可成本。 “虽然虚拟化对整体资源会有一定的消耗，但是它也带来了额外的好处 —— 实现了对客户机资源静态的划分及分配。客户机应用之间不互相干扰、信息不会互相串访，保证了功能与信息安全性，简化了上层软件的开发，所以这些资源的耗费也是值得的。”杨曾解释道。 4.2.3 工程化层面的挑战 1）测试验证层面 某主机厂自动驾驶系统架构专家认为：智能驾驶本身在进行底层软件以及应用软件集成的时候就面临很多问题，现在还要和座舱的相关功能一起去进行集成测试和回归测试，不仅工作量很大，并且也很难保证整个产品的可靠性。 2）开发体系不同 “智驾系统和座舱系统本来是两套独立的体系，都有自己的开发节点和发展路线。特别是智驾系统，现在发展还不是特别成熟，比如Orin芯片，虽然现在蔚小理等很多家都在用，但是它的功能尚未被完全开发出来，至少需要2~3年后才能够发挥出来。如果把两者放在一个时间节点上去开发，问题会很多，不仅达不到1 1大于2的效果，甚至可能还会相互拖后腿，没有必要过早的就交叉融合在一起。当两者的技术达到一定成熟度的时候，自然会有一些整车厂愿意去尝试。”赵建洪表示。 4.2.4 跨部门协作难 舱驾融合还面临另外一个难题，就是“部门墙”的问题。业内相关专家大都认为，如果要把座舱和智驾的功能集成到一个SOC芯片上来，确实对主机厂的组织架构存在挑战，根本原因在于谁来做、谁承担责任的问题。最终整合的话，相当于把这些研发资源都打通了，一起来管理。如果还是现在这种跨部门协作，肯定多少会存在扯皮、懈怠的问题，难以保证开发效率和质量。 4.2.5 缺乏统一的行业标准 汪浩伟谈到：“实现真正的舱驾融合，首先要让座舱和智驾把自己的整个架构打开，打开以后把各自的服务做好。SOA实现路径中间必经的一步就是要把原来单体的软硬件架构打碎，变成一个个微服务。这一步做完之后，再谈如何去做融合，不仅智舱和智驾两个部门协作的难度会降低不少，而且后期在资源和时间上的投入也会少很多。 “但是这个事情，需要行业标准的推动，甚至需要强迫一些厂商逐渐把它的软件架构打开。制定行业标准的目的就是把大家的利益统一起来，谁不跟着行业标准走，谁就会吃亏、掉队，甚至面临淘汰，这样才能逐渐推动整个行业的发展和进步。” 5. 舱驾融合对开发模式和产业链格局的影响 5.1 对开发模式的影响 从开发模式上来说，在舱驾融合之前，造车新势力也好、传统主机厂也罢，他们的智能座舱和智能驾驶，是分别开发、再拉通的模式，基本上是智舱部门承接智驾部门的需求，把智驾相关的显示、操控需求，简单地加入到座舱开发中，可以想象得到，其融合程度一定是很低的。 而秉承舱驾融合的理念，智舱与智驾的开发需要同步进行，从一开始两者就紧密相连，智驾部门会将座舱、人机交互等内容，也作为智能驾驶的一部分来考虑；智舱部门也会将智驾功能在车内的表现，作为重中之重来考虑。 那么未来会主机厂的智舱和智驾部门的组织架构又将会是怎样的一种形态，谁又会去融合谁？ 当前，在主机厂的研发部门，智驾和座舱是两个独立的部门。智驾内部又分行车和泊车两个不同的团队，再往下可能会分多个不同专业——感知、规控、定位等专业小组；座舱部门会分为HUD、仪表和中控等不同团队。另外，还有专门负责车型的部门，车型部门会围绕车型的EE架构以及系统的一些技术，包括需求定义等开展工作。当车型的功能定义好之后，车型部门相关负责人会找具体的部门来协作。整体来说，一般是由车型部门的项目经理或项目总监来整合这两部分的需求，这是目前智舱和智驾两个部门比较常见的一种开发合作模式。 智舱和智驾进行融合，到底哪个部门或者团队主导牵头去做这件事情，应该也是分阶段的。在现阶段，座舱和泊车进行融合，泊车功能比较成熟，座舱功能要比泊车功能复杂，并且座舱团队也比较庞大，这个时候适合座舱团队做主导。到后期，随着智驾技术发展成熟，以及智驾团队不断地发展壮大，多半是以智驾部门为主导去融合座舱，毕竟智驾的复杂度和对安全的重视程度要高于座舱。 未来舱驾融合之后，主机厂的组织架构会受到哪些影响？赵建洪认为：不管最终两个部门是否合并成一个部门，智舱和智驾始终都会是两个独立的团队，毕竟他们专业分工不同，两个部门都非常重要，把哪个部门做降级处理都不太现实。但是很有可能会出现一些主机厂把智驾和智舱合并成一个智能化部门 —— 我中有你，你中有我，从一开始就奠定了舱驾深度融合的基础。 5.2 对产业链格局的影响 整车EE架构从分布式向集中式域控架构转变的过程中，产业链从Tier2→Tier1→OEM这种线性关系，逐渐演变成以主机厂为中心的网状关系。那么到跨域融合的阶段，是否会对现在的产业链格局有更进一步的影响？ 从集中式域控到跨域融合，产业链格局其实还是网状的。只不过这种格局需要主机厂的掌控力更强，对主机厂的要求更高。 杨曾谈到：“通常情况下，主机厂智驾域控的硬件和底层软件基本上会定一个供应商，功能模块可能会再找另外一家供应商，然后主机厂参与去做基础软件和整个域控系统的集成，这是一种在智驾场景下的合作方式，这种合作方式也会拓展到舱驾融合的控制器。 “如果主机厂做舱驾融合方案，首先会找一家做底层硬件和基础软件的Tier1供应商，它需要至少对一家主流芯片公司的芯片及其Roadmap比较熟悉。其次，再由主机厂牵头，去找一些中间件的模块，比如说智驾相关安全集成的中间件模块。再次，主机厂一般会找一些之前合作比较好或者能力比较强的智驾或座舱方面的公司，提供一些应用算法模块。最后，主机厂把所有功能进行集成，并统一牵头做系统验证和测试。” 对于域控供应商而言，之前所谓的Tier1和Tier2之间的分工和定位越来越模糊。 曹晶认为：“Tier1和Tier2的界限逐渐模糊，并且出现了Tier 0.5和Tier1.5。我们做域控设计的公司，对于轻量级的智驾域控，客户需要把所有功能都做一个整合，由于此类域控软件的代码量不高，我们自己就可以把这些功能全部完成。但是，对于比较复杂的的大算力域控，所有的软硬件模块都有一家Tier1来做也不太现实，如果市面上有一些已经量产的、比较好用的模块，比如感知模块，我们会直接去做集成，以提高研发周期降低自研成本。在这些情况下，我们基本就是在扮演一个Tier1的角色。 “在舱驾融合的阶段，主机厂大多会采用SOA的架构，要求软硬件做更好的解耦，因为软件是需要不断地OTA升级，从原来的买一个功能到后面就变成买一个服务，那个时候就会跟供应商绑定得比较深，需要供应商去维护这套软件框架，在未来几年的生命周期内也要不断地去迭代，这种情况下域控制器供应商就更像是一个Tier0.5的角色。” 智能汽车的产业链格局会随着整车架构的变化而变化，原先的产业格局属于垂直整合和横向分割，随着EE架构由分布式走向域集中式，产业链格局逐渐变成水平整合和垂直分割。 水平整合 —— 现在车上控制器越来越少，座舱和智驾甚至也要合并成一个舱驾一体域控制器，最后甚至还要把网关、BCM、VCM统统整合进来，集成为一个中央计算平台。 垂直分割 —— 硬件（包括芯片）、底层软件和应用层软件会由不同的公司分工去完成。每个公司专精于被垂直分割的一个垂直技术领域。 “舱驾一体作为中央计算平台发展的一个过渡形态，会推动整个汽车产业彻底走向软硬分离的方式。然后大家在垂直方向去寻找自己擅长的领域—— 有人专门设计芯片，有人专门设计底层软件，也有人专门设计应用层软件，甚至还有人专门做硬件代工。”汪浩伟解释道。 1.智能座舱的“质变”，域控 软件 多功能融合集成加速落地 https://mp.weixin.qq.com/s/-nkomCaEK-OJYUTpzLiQsg 2.智能座舱平台研究：智能座舱加速进入跨域融合，软件分层设计新时代 https://mp.weixin.qq.com/s/LW0THSTDR9NJegLbsJldgA 3.创时智驾：解码智能驾驶域控制器行业发展态势及软硬件内核 https://www.sohu.com/a/551498073_560178 4.特斯拉最新中央计算模块(CCM)解析 https://mp.weixin.qq.com/s/IWmXxoFYPtMu-dJFfswh9A 5.地平线再度合作上汽集团，全力打造搭载征程5芯片的智驾计算平台 https://www.d1ev.com/kol/180760 6.一台车里，集齐了机器人、人工智能和元宇宙 https://mp.weixin.qq.com/s/gtHfTzq_tc3PVfUlDXHbsA 7.体验驱动vs功能驱动 软硬件解耦下的域控设计思维转变 https://app./apps/ShareArticleContent/2/70308358.html 8.自动驾驶与智能座舱，走向融合or独立发展？ https://mp.weixin.qq.com/s/P0PuphWLlu1Mi6qAy4ennw |
|
|
来自： 新用户82165308 > 《底盘架构》
