An in-depth analysis of “cabin-driving fusion” technology

Some time ago, Jidu released its first automotive robot ROBO-01, and mentioned a word that interests me at the press conference : " cabin-driving fusion " . In fact, long before Jidu, SAIC Zero Beam also proposed the concept of cabin-driving integration. Although some car companies have not explicitly proposed cabin-driving integration, their smart driving and smart cockpit products more or less have the form of cabin-driving integration.

So, what is cabin-driving integration? What kind of exploration are companies currently making in cabin-driving integration? What are the advantages and challenges of cabin-driving integration solutions? What impact will the integration of cabin and driving have on the development model and industrial chain structure? With these questions in mind, the author interviewed technical experts in related fields, hoping to have a deeper understanding of "cabin-driving integration".

1. Clarify the concept of “cabin-driving integration”

As we all know, the degree of intelligence of a car depends on the underlying EE architecture. In the process of automobile intelligence, the development route of EE architecture has evolved from a distributed architecture with independent functions, to a domain-centralized architecture with integrated functions, and finally to a centralized architecture with highly integrated central computing + regional control.

Wang Haowei, Chief Architect of Junlianzhixing, believes: “ Cabin-driving integration can be considered from two different levels: hardware and software. The concepts of integration from different levels are completely different, and the purposes and functions are also completely different.

" Hardware integration is more based on the product perspective, and is considered from the dimensions of cost and design. Fusion in an SoC chip is the true hardware integration. At this time, the underlying software and communication methods There will be fundamental changes, and the cost advantages will also be highlighted.

" Software integration is more based on a technical perspective and is considered from a functional dimension. Software integration requires consideration of how to change the overall software architecture design, so that the new software architecture can be more suitable for cabin-driving integration systems. At the same time, the introduction of SOA service-oriented design concepts and tools can help OEMs better integrate cabin and driving.

" Software integration will not change with hardware integration. Whether the hardware is made into a single SoC chip , a single board, or two single boards, from the perspective of software integration In other words, the difference is not big, but the underlying communication and operation methods will be different. From a functional perspective, only the integration of software will change the application and upper-level logic itself, and the integration of cabin and driver will be more significant.”

1.1 Division of cabin-driving integration levels

1) Integration at the application level

Due to technological development and engineering issues, the solution that is easier to implement at this stage is: in physical form, the intelligent driving domain controller and the cockpit domain controller use two completely independent boxes, but at the application level, many functions The information interaction among smart cockpits is opened up through cross-domain, and data fusion innovation is realized - deeply integrating and linking human-computer interaction, immersive experience and other content in the smart cockpit with various functions of smart driving, thereby improving users' sense of security. and comfort, enhancing users’ experience in using smart cars.

Huanyu Zhixing COO Cao Jing mentioned that they have a project where the OEM requires a unified SOA architecture to send and share signals in the cockpit domain and smart driving domain through Ethernet or CAN protocols . In this way, at the functional level You can do more integrated innovation. If we follow the previous strategy, the signals in the two domains are basically hard-coded. Although they can be forwarded to the vehicle CAN bus through private CAN, when the system needs to obtain relevant signals, it has to go to the vehicle CAN bus again. It is very inconvenient .

2） 座舱域控制器 和智驾域 控制器 在物理形式上合二为一

座舱域控制器和智驾域控制器合并成一个盒子 ，内部由多个 So C 或者MCU芯片构成。这些芯片用于支持不同的功能，每个芯片 以及芯片内的不同核上运行不同的操作系统。这种形式又可再细分成两种方案： A. 座舱和智驾功能分别部署在不同的板子上。B.座舱和智驾功能部署在同一个板子上。

“如果 座舱和智驾功能分别部署在不同的板子上，用于支持座舱和智驾功能的 So C 芯片肯定都会有自己专属 的外围电路设计；如果两者的功能部署在同一个板子上，设计方案可以从整体上去考量，包括器件的选型，电路、供电、存储等方面的设计，比如，考虑 DDR是否可以共享 、 EMMC模块是否可以共享等等。整体来讲，B方案比A方案在电子器件、接口、线束等部件的使用量上有一定程度的减少， 使得 BOM成本 相对较低。 ”曹晶表示。

3） 基于单 SOC芯片的舱驾功能融合

智舱和智驾的功能由一颗单 So C 芯片来完成 —— 在芯片上运行虚拟机，通过虚拟机分割出不同的功能模块，来实现不同安全级别需求的舱驾功能。

目前，有一些芯片公司和主机厂在探讨这样的方案，未来也很有可能会有这样的一些芯片产品出现。但是，理想很丰满，现实很骨感，短期内应该是很难看到这样的理想方案落地。

据业内专家透露，大部分车型无论是对于成本，还是可靠性都比较敏感。同样，开发一个新车型，车型的上市周期也会有一定的要求，所以主机厂一般会首选技术成熟度较高，并且成本已经在行业内能够被分摊下来的成熟方案。另外，不管是主机厂的组织架构，还是对应用层的梳理，都需要很长时间去调整和消化。因此，这样的产品需求不会一下子就爆发出来。

1.2 什么是真正的舱驾融合？

芯片作为汽车智能化的核心硬件，在很大程度上影响着智能座舱和智能驾驶的能力上限。因此真正的舱驾融合需要智舱与智驾芯片一体化，即智舱与智驾的软件和算法完全部署在同一颗 So C 芯片上，这是最理想的方案。但受限于软硬件技术水平、架构方案、供应链等方面的原因，目前还难以实现基于单SOC芯片的舱驾融合方案。

映驰科技产品副总裁赵建洪讲到： “ 我们首推的是舱泊融合方案，并且， 主机厂对舱泊融合也有一定的需求。 因为泊车方案现在比较成熟，同时，座舱域控制器上的算力也有了一定的富余，把泊车功能融合到座舱域控制器具有一定的成本优势 。不过，舱泊融合相当于是舱驾融合的第一步，由于行车方案目前还不是很成熟，需要两者都发展成熟的时候，再去考虑融合的问题。 ”

汪浩伟也提到了类似的观点： “ 座舱和智驾集成在一个单 So C 芯片里面，肯定是大势所趋的。 在成本的驱动下，这种方案大概率会从中低端的车型开始出现（舱泊一体）。待 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， So C 上采用基于Linux进行深度定制开发的 Version 操作系统。

2.2 特斯拉舱驾融合方案的优势

1） 更高效的 通讯

座舱和智驾分属于两个不同控制器的时候，两者之间需要通过 CAN或者以太网总线进行通讯 ；而现在，两者虽然还是部署在不同的 PCB板子上，但是可以 部署在一个盒子里面，两个板子之间通过 Switch就可以实现通讯，通讯速率更高。

2）共用一套散热系统，节省成本

现在座舱和智驾需要实现的功能越来越多，所需的算力越来越大，功耗也越来越高，因此座舱域控制器和智能驾驶域控制器都需要做散热设计。尤其是对于大算力的智驾域控制器，还需要做专门的水冷散热设计。如果两者放在一个盒子里面，散热系统就无需再做两套，可直接共用一套冷却系统。

3）节省空间，易于布置

集成到一个盒子里，比较容易布置，并且整车空间利用率也会更高。

单单上面的几点好处，大家肯定也会觉得有点单薄 —— 不足以驱动特斯拉去采用这样的方式，那么 特斯拉采用这种方案 背后真正的驱动力是什么呢？

据业内专家透露，特斯拉并不只是为了实现舱驾融合，才要做个 CCM模块把座舱和智驾的两个板子放在一起， 其真正的目的是为了实现中央计算+区域控制器的架构。而中央计算平台则需要整合其它功能域的功能，但 受当时软硬件水平、架构方案等限制，即便是特斯拉也没办法将主要的域控融合到一颗 So C 芯片 上，但至少把他们都集成到了一个盒子里面去，这也算是比较有意义的一次初步探索。

虽然特斯拉的这代架构并不是真正意义上的中央计算 +区域控制器架构，但当时也是业内公认的最先进的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. 基于高通SA 8295 的舱泊融合方案（座舱和泊车功能融合）

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） 芯片本身的设计

实现真正的舱驾一体融合方案， So C 芯片设计本身就是 个很大的难题 —— 要把很多的系统和功能融合在一起，芯片的设计方案会很复杂。同时，单 So C 芯片 不仅要实现上千 TOPS的算力， 还要把功耗控制在可接受的程度内，这对芯片的制程要求非常高。现在的车载 AI芯片已经下探到5nm了，不仅成本高，而且掌握这种先进工艺的企业也寥寥无几。

有业内人士提到了使用Chiplet来设计这样的SoC芯片，它的优势在于 各家芯片厂商可以专 注自己的芯粒和IP，不用为多余的IP买单，并且 小芯粒的流片良率更高，有坏点的部分扔掉，剩下的还能用。因此，采用小芯粒技术进行 So C 芯片的 迭代设计会更加方便。 但是，目前也存在一些问题 ——

Chiplet技术，又被称为小芯粒技术， 即把不同制程的芯粒经过选型直接封装在一个 SOC里面。目前业内 已有一些成功的应用案例，并且整个行业也在推动。曹晶告诉九章智驾： “基于Chiplet技术实现舱驾融合的 So C 芯片不难被设计出来，只要产业链端能够提供足够多满足智驾和智舱的芯粒就可以。 我觉得使用芯粒技术最大的挑战不在单个芯粒内部的这些设计和实现，反倒是高速带宽部分，毕竟芯粒之间也是需要进行大通道数据的输入输出。

“同样，Chiplet技术 不仅面整个产业链成熟的问题，而且在 So C 芯片上面实现智舱和智驾这些复杂功能也会涉及到很多工程化的问题，这些问题可能会比把芯片设计出来所花的时间还要长。整个行业讨论这种技术方案比较多，在实践上也有企业在向这个方向发展，但是我觉得离真正在车上量产应用尚且需要一段时间，不过至少这个方向的国产自主化趋势是窥见一斑了。 ”

2） 硬件资源分配

智舱和智驾功能融合在一个单 So C 芯片里面，芯片内部的GPU和CPU等资源可以共享，但是资源该如何分配？哪一块GPU/CPU资源供智能驾驶使用，哪一块GPU/CPU资源供座舱使用，怎样实现资源的动态调节？并且，智舱和智驾都处于不断地迭代发展中，如果智能驾驶发展两年，技术迭代升级了，对硬件的需求变了，之前硬件资源分配方案可能就不行了，还需要重新做资源分配。

同时，对于单 So C 芯片的舱驾融合方案，很有可能要做内存共享，这样数据才会读 得更快，信息传输延迟会更小。但是， DDR分配也会面临很多问题 —— 比如，智驾的内存需求发生变更，另外一个也要跟着变更；在座舱开发的时候，内存损坏，也会影响到自动驾驶的开发。

某主机厂自动驾驶系统架构专家告诉九章智驾： “ 当前，座舱和智驾尚未达到一个终极形态，硬件资源也没有足够强。两者在硬件资源需求上的变动很可能会影响到整个软件架构，以及后续硬件资源的分配。比如，对于 CPU资源，有些ARM核 用于支持座舱相关应用，有些 ARM核用于支持 智能驾驶相关应用；对于 GPU资源，可能会通过制定一个优先级进行资源使用或者直接把GPU隔离成不同部分，座舱用一部分 、智驾用另外一部分；但问题的关键是 - 对于这种架构设计，大家都没有太多经验可以借鉴， 比如，硬件资源怎么去分配，分配是否合理？后期面临需求变更的时候，会不会没办法实现？这些问题都会存在很大的不确定性。 ”

“智能座舱和智能驾驶功能集成在单颗 So C 芯片上的时候，因为两个域的需求完全不同，在做硬件资源分配的时候，既要定义这些应用的优先级，又要确保这些应用有足够资源可以用 —— 能够保证互相不打架，也不能出现一个应用锁死另外一个应用的现象。 ”汪浩伟表示。

3） 行驶安全考虑

某芯片公司负责人告诉九章智驾：“一旦具备L3以上的自动驾驶功能，智能座舱与智能驾驶在底层芯片上，我个人观点一定会分离，原因有：智能驾驶外接大量各类传感器，要求大算力，要求芯片，OS，相应软件硬件都具备功能安全，根本不充许运行中出现死机停机等故障，同时相应的软件种类也少，不会让用户去随便下载什么智能驾驶功能软件。而智能座舵就是一个大手机，不考虑大屏的价格，成本低很多，但同时需要支持各种应用软件的下载及运行，但芯片os，软件硬件又不具备功能安全。一旦两者运行在同一个芯片及OS上，尽管软件的隔离比较容易做好（通过Hypervisor技术），但芯片底层硬件的相互隔离很难做好。一旦座舱软件卡死涉及底层硬件，一定会影响驾驶软件的运行。同时一旦出了问题，追责很难。座舱软件用户可以随意下载运行，一旦这些没有经过测试的运应用软件运行导致驾驶出了问题谁去负责？

智能座舱芯片，一个手机芯片就能搞定，不值得绑定在智能驾驶芯片上。高端L3以上的智能驾驶会牺牲功能安全性，去将就低成本的智能座舱？再说，一旦上了L3，实现部分自动驾驶，目前智能座舱上的大多数智能功能会失去意义，如语音手势智能控制等

智能驾驶芯片会有接口输出一些传感器信息或智能处理后的信息等给座舱芯片使用，但不会让座舵芯片来控制智能驾驶芯片，这是常识。除了功能安全外，另外信息安全也是导致两者分离的原因之一。

4.2.2 软件层面的挑战

1）OTA升级策略

智能座舱和智能驾驶两者的 OTA软件模块、升级模块的数据量、数据包的大小可能都不太一样 ，在这样的情况下，做好 OTA的升级策略也存在一定的挑战 。

赵建洪认为，舱驾融合后，座舱发布的数据包和智驾发布的数据包需要要整合在一起才能升级。因为涉及很多的功能，如何更好地整合在一起会有一定的难度。同时，两者有各自的功能升级策略，有的升级频率是三个月，有的升级频率为半年。并且，座舱升级频率比较高，并且座舱还经常容易出问题，出问题就要升级，临时更新内容也需要马上升级。

2）软件上的安全隔离

So C 上面需要隔离出不同区域，并且适配好不同的操作系统。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 对开发模式的影响

从开发模式上来说，在舱驾融合之前，造车新势力也好、传统主机厂也罢，他们的智能座舱和智能驾驶，是分别开发、再拉通的模式，基本上是智舱部门承接智驾部门的需求，把智驾相关的显示、操控需求，简单地加入到座舱开发中，可以想象得到，其融合程度一定是很低的。

而秉承舱驾融合的理念，智舱与智驾的开发需要同步进行，从一开始两者就紧密相连，智驾部门会将座舱、人机交互等内容，也作为智能驾驶的一部分来考虑；智舱部门也会将智驾功能在车内的表现，作为重中之重来考虑。

So what will the organizational structure of the smart cabin and smart driving departments of OEMs be like in the future, and who will integrate whom?

Currently, in the R&D department of the OEM, smart driving and cockpit are two independent departments. Intelligent driving is divided into two different teams: driving and parking. Further down, it may be divided into multiple different majors - perception, control, positioning and other professional teams; the cockpit department will be divided into different teams such as HUD, instrumentation and central control. . In addition , there is a department specifically responsible for vehicle models. The vehicle model department will work around the EE architecture of the vehicle model and some system technologies, including requirement definition. After the functions of the vehicle model are defined, the relevant person in charge of the vehicle model department will find specific departments to collaborate. Generally speaking, it is generally the project manager or project director of the vehicle model department who integrates the needs of these two parts. This is currently a common development cooperation model between the smart cabin and smart driving departments.

The integration of smart cabins and smart driving should also be done in stages. Which department or team will take the lead in doing this? At this stage, the cockpit and parking are integrated. The parking function is relatively mature, the cockpit function is more complex than the parking function, and the cockpit team is also relatively large. This time is suitable for the cockpit team to take the lead. In the later stage, as the smart driving technology matures and the smart driving team continues to grow, the smart driving department will probably take the lead in integrating the cockpit. After all, smart driving is more complex and pays more attention to safety than the cockpit.

After the integration of cabin and driving in the future, how will the organizational structure of the OEM be affected? Zhao Jianhong believes that no matter whether the two departments are eventually merged into one department, smart cabin and smart driving will always be two independent teams. After all, they have different professional divisions of labor. Both departments are very important, and it doesn’t matter which department is downgraded. Reality. But it is very likely that some OEMs will merge smart driving and smart cabins into an intelligent department - you are in me, and I am in you. This has laid the foundation for the deep integration of cabin and driving from the beginning.

5.2 Impact on the industrial chain structure

In the process of the transformation of the vehicle EE architecture from distributed to centralized domain control architecture, the industry chain has gradually evolved from a linear relationship of Tier2 → Tier1 → OEM to a networked relationship centered on the OEM. So at the stage of cross-domain integration, will it have further impact on the current industrial chain structure?

From centralized domain control to cross-domain integration, the industry chain pattern is actually still mesh-like. It's just that this pattern requires the OEMs to have stronger control and has higher requirements for the OEMs.

Yang Zeng said: "Normally, the OEM will basically choose one supplier for the hardware and underlying software of smart driving domain control , and the functional modules may find another supplier, and then the OEM will participate in making the basic software and the entire The integration of domain control systems is a method of cooperation in smart driving scenarios. This cooperation method will also be extended to controllers for cabin-driving integration.

"If the OEM is developing a cabin-driving integration solution, it will first find a Tier1 supplier that provides underlying hardware and basic software. It needs to be familiar with at least one mainstream chip company's chips and its Roadmap. Secondly, the OEM will take the lead to Find some middleware modules, such as smart driving-related safety integration middleware modules. Thirdly, OEMs will generally find some smart driving or cockpit companies with good cooperation or strong capabilities in the past to provide some application algorithm modules. Finally, the OEM integrates all functions and takes the lead in system verification and testing. ”

For domain control providers, the division of labor and positioning between the previously so-called Tier1 and Tier2 is becoming increasingly blurred.

Cao Jing believes: "The boundaries between Tier1 and Tier2 are gradually blurring, and Tier 0.5 and Tier1.5 have emerged. As a company that designs domain control, for lightweight smart driving domain control, customers need to integrate all functions Since the amount of code for this type of domain control software is not high, we can complete all these functions ourselves. However, for more complex domain controls with large computing power, it is not feasible to have a Tier1 company do all the software and hardware modules. In reality, if there are some easy-to-use modules that are already in mass production on the market, such as sensing modules, we will directly integrate them to improve the development cycle and reduce self-development costs . In these cases, we are basically acting as a Tier1. character of.

“In the stage of cabin-driving integration, most OEMs will adopt SOA architecture, requiring better decoupling of software and hardware, because software requires constant OTA upgrades, and buying a function will turn into buying a service. , at that time, it will be deeply bound to the supplier, and the supplier will be required to maintain this software framework and continue to iterate in the life cycle of the next few years. In this case, the domain controller supplier will be more Like a Tier 0.5 character.”

The industrial chain pattern of smart cars will change with the changes in the vehicle architecture. The original industrial pattern was vertical integration and horizontal segmentation. As the EE architecture changes from distributed to domain centralized, the industry chain pattern gradually becomes horizontal integration and vertical integration. segmentation.

Horizontal integration - There are fewer and fewer controllers in the car now. The cockpit and smart driving even have to be merged into a cabin-driving integrated domain controller. Finally, the gateway, BCM, and VCM have to be integrated into a central computing platform.

Vertical segmentation - hardware (including chips), underlying software and application layer software will be completed by different companies. Each company specializes in a vertical technology area that is vertically segmented.

"As a transitional form in the development of central computing platforms, cabin-driving integration will push the entire automotive industry towards a complete separation of software and hardware. Then everyone will look for areas of expertise in the vertical direction - some people specialize in designing chips, and some specialize in designing underlying software. "There are also people who specialize in designing application layer software, and there are even people who specialize in hardware foundry, " Wang Haowei explained.