“舱驾一体”，到底还有多长的路要走？

lichengwan

作者 | 巴哈姆特
出品 | 焉知汽车

知圈 |  进“AI大模型群”,加微13501975564,备注AI

最近，在自动驾驶领域中，为了进一步提升整车的智能化集成水平，已有多家车企（如理想汽车、小鹏、埃安、路特斯等）已经开始研发全新一代中央计算E/E架构核心技术与车型产品了。在传统分布式架构阶段，智驾和智舱两大系统分别有各自的传感器和控制器。如智舱着重与车内环境监控，智驾着重于车外环境监控。在这种架构下，两套系统是无法正增做到数据同步处理，也无法真正实现同样的安全性要求的。由此，可能造成了一定程度上数据采集无法满足安全性和完整性要求，也无法形成真正的数据闭环和控制融合。

而随着电子电气架构继续向跨域融合演进，智能座舱芯片算力同步提升，这些主机厂紧跟大算力芯片带来的舱驾融合热度，其研发重点正在从原来的行泊一体向舱驾一体进阶。实际上，舱驾融合可以说是真正的跨域融合，也是电子电气架构进一步向中央集成式迈进的关键一步，同时也符合降本增效的行业趋势。



所谓舱驾一体，就是将座舱域和智驾域集成到一个高性能计算单元中，同时支持智能驾驶和智能座舱功能，参照当前比较典型的设计用例就是将座舱域芯片+驾驶域芯片+高效的CPU进行集成的舱驾一体化域控。相较于行泊一体和舱泊一体，这种架构的集成度更高，当然对硬件的要求也随之升高。

舱驾一体系统架构的难度在哪里？

1、集中式控制难度

在集中式架构中，智能座舱域控制器和智能驾驶域控制器都被集成在一个中央控制单元中。从软件角度来看，由于“舱驾一体化”集成系统所驱动的整体软件架构迭代，可以获得更多的功能或者更好的功能体验。然而，这需要单独适配软件应用中心的中央控制单元负责整个车辆系统的控制和协调。基于此，这里就不得不提到控制软件的基石：操作系统了。作为无论是底层还是上层应用算法的基础，操作系统的重要性不言而喻。

然而，集中式智驾和智舱域控需要解决在智能系统控制中不同软件开发平台的兼容性问题。因为，对于智舱域来说，操作系统是基于QNX或Andriod语言编写的，而智驾域的操作系统大多基于Linux或C++语言。如果是在域控中不同的芯片上部署不同的操作系统，其运行策略就需要考虑如何设计相应的调度接口来满足其两种系统下的应用程序调度和通信。



可以说，上层生态的迁移以及软件适配的复杂度和难度将随着智能驾驶域和座舱域融合度的增加而显着增加，开发成本也会增加。

2、硬件设计难度

从硬件角度看，“座驾一体化”可以提高传感器、芯片等硬件的复用率，降低成本。无论是采用一盒、一板还是一芯片方案，相比目前智能驾驶领域和座舱领域的两盒两芯片方案，在硬件方面都可以很好的减少域控和芯片的投入，同时也可以减少域之间的线束数量。通过将智能座舱和智能驾驶的功能集成在一个中央控制单元中，减少了电气线束和接口的数量，简化了系统的架构。可以说集中式架构可以降低系统的复杂性和维护成本。

然而，舱驾一体芯片设计面临着较大的挑战，例如设计复杂度、功耗、散热等问题。以功耗为例，单就智驾域控而言，为了满足其功耗和散热的要求，其要求的芯片制程就已经开始向下探到接近于14nm甚至7nm了。而再加上智舱芯片，特别是在图形渲染上也会占用大量的运算资源。两者结合起来，对于合适的芯片选型要求就更高了。

3、数据传输及处理

舱驾一体芯片的优势在于集成度高，可以减少系统的复杂性和成本。通过一个芯片实现座舱控制和驾驶控制的整合，可以提供更高度的系统一致性、响应性和实时性。集中式架构通过内部网络传输各个子系统的数据。智能座舱域控制器和智能驾驶域控制器之间可以通过高速数据总线或以太网等方式进行数据交互和共享。

然而，数据传输介质和标准规格上，智驾和智舱的要求也略有不同。举个例子，对于视频处理这一常规的处理而言，智驾系统需要接入的视频格式要求通常是像RGB这类原始视频，且要求帧率一般较低。因此，在视频传输介质选型上，智驾系统通常会选择MIPI或者PCIe这类并行效率高，且较为稳定的介质。另一方面的，对智舱而言，则更加倾于传输方便于压缩传输的原始视频流（如YUV），或者是对原始视频流进行压缩处理后的HEVC/H.264视频。且智舱对于显示效果会更加倾向于还原实际场景，这样就必然要求其帧率也是足够高，比如流媒体视频就是个典型的例子。

那么问题就来了，如果是既用于智驾又用于智舱的视频将如何在同一个域控中被处理，比如部分视频抽帧，视频时间同步等问题就就会对舱驾一体域控的数据传输及处理能力提出新的要求。

4、系统一致性

由于智能座舱和智能驾驶都由同一个中央控制单元控制，因此系统的一致性和兼容性会得到更好的保证。比如，集中式架构通过集中处理和控制，可以更高效地处理各种输入数据并做出相应的决策和控制，实现较好的实时性和响应性控制。

需要注意的是，集中式架构虽然具有一些优点，但也有一些潜在的缺点。

由于智驾与智舱所处理的是不同的功能模块，一个偏驾驶性控制，另一个偏交互性控制，两者无论是在功能安全还是信息安全上都有着完全不同的层次需求。例如，就功能安全而言，智能驾驶领域与座舱领域功能安全要求也各有不同，导致满足车辆监管要求也随之增加。此外，集中式架构可能存在单点故障的风险，即如果中央控制单元发生故障，整个系统都会受到影响。此外，集中式架构可能面临处理大量数据安全的挑战，需要考虑处理能力限制、数据传输的带宽限制、以及数据入侵风险可能导致的全盘崩塌。

因此，在实际设计中，短期内舱驾一体域控难以实现平台化、标准化、规模化。为了可以更好地协同工作，需要实现更高级别的软硬件模块整合。同时，需要综合考虑系统的可靠性、性能和复杂性等因素来选择合适的架构。

“舱驾一体”实现推手——高算力芯片计算平台

众所周知，座舱芯片主要的计算任务是图形处理，包括渲染等，对GPU的算力要求高。提到这个就不得不提当前比较火热的通过智驾感知输出+地图的全场景渲染需求了。对于这样的场景重构需求而言，智舱处理能力的要求不仅仅是在传统的2D渲染上，更多的则是在其3D渲染上。想想需要勾勒和重现的那些3D模型，以及为了实现渲染效果的真实性，这样的处理过程要求是并行的、实时的，不难看出这将是一个十分庞大的工作量。

相较于智舱而言，智驾芯片主要的计算任务是深度学习，对NPU的算力要求高。那么如果要实现舱驾一体，那就必须同时解决GPU算力和NPU算力问题。舱驾一体化需要逐步打通智能驾驶域与座舱域之间的部门围墙，推动组织架构一体化以提高效率。同时还要充分考虑如下一些要素的配合才行。

基于此，用于座舱和智驾的SOC芯片一般包含GPU、CPU、NPU、ISP等不同的IP模块。在做舱驾一体的芯片选型时需要充分考虑综合算力、带宽、外设、内存、能效比、成本等多方面因素。同时，除开考虑芯片本身的性能外，还要综合考虑芯片外围生态，相关芯片的开发工具链，各芯片相互之间的适配性的要素，软件模块之间调用和通信关系等。

实际上，当前还没有一款真正能够由一家生态实现的完整的舱驾一体大集成式芯片。当然，当前国内外已有一些芯片厂商看到了舱驾一体的发展商机，开始花大力气开发这样一款既能满足智驾又能满足智舱的芯片，期望能在这一领域第一个抢占市场。比较典型的有智驾和智舱的龙头老大，“英伟达”和“高通”。

笔者看来，英伟达是一家充满野性的芯片公司，早在很久以前，应为已经牢牢占据了智驾领域的半壁江山，已被广泛应用的Orin系列早已经为业界所熟知，而该公司研发大算力芯片的脚步却从未停止。在去年9月，英伟达又重磅发布了大算力芯片命名为Drive Thor的芯片。该芯片最大的特点就是实现座舱域、驾驶域的融合，同时可支持多计算域间隔离，这样，就可以很好的满足将辅助驾驶、自动泊车、信息娱乐、DMS等多种功能整合在同一块芯片中运行。且公司已经在不少场合官宣，Thor芯片将在2025量产。



另一方面，坐稳智舱处理芯片厂商的龙头老大——高通公司也不甘示弱。其在2023年1月推出的全新骁龙Ride Flex系统级芯片和新的自动驾驶平台（Snapdragon Ride）可以完美的融合了高通的数字化驾驶舱和高级驾驶辅助平台上，有助于在相同的硬件（Ride Vision）上协同处理智驾和智舱的所有应用场景。

而以上提到的两家王者级别的芯片（NVIDIA的Drive Thor和高通Snapdragon Rideflex）其算力也是十分惊人的，据官方提前爆出的资料显示，GPU算力均超过2000TOPS。

当然，为了跟上时代洪流，国内的多家芯片供应商也开始跟着“卷”起来。黑芝麻作为其中一家典型的芯片公司，也早在2023年4月宣布开发一款覆盖座舱、智驾、网关等不同领域的跨域计算场景的芯片——“C1200”。虽然，目前距离舱驾一体芯片真正落地还有一段时间，但是，黑芝麻的此番官宣也是比较吸睛的。

舱驾一体系统架构的设计

我们知道，智能汽车的中央控制单元采用异构单元设计，一般由 SoC 和 MCU 构成。SoC、MCU 根据应用的功能和性能要求，可以增加多个同构/异构 SoC、MCU 形成分布式计算硬件架构。对于舱驾一体域控制器而言，各个芯片系统主要通过总线和网络进行连接，实现数据交互。为满足智驾域与座舱域在智能驾驶和智能交互中所需求的更高算力需求，通常需要采用多个型号的 SoC 分布式计算单元，来实现算力翻倍。

智能驾驶中的舱驾一体芯片是指集成了座舱控制和驾驶控制功能的芯片。它是一种高度集成的芯片解决方案，旨在实现智能座舱和智能驾驶系统的整合。舱驾一体芯片的设计目标是在一个芯片上集成座舱控制和驾驶控制相关的功能模块。实现的算力类型包括但不限于AI 算力、逻辑算力、GPU 算力、DSP 算力。这些算力资源需要实现的用途包括感知运算、融合运算、预测筛选运算、规划运算、定位运算、地图运算、拼接渲染运算、车控运算等。通过集成这些功能，舱驾一体芯片可以实现对车辆的全面控制，并提供更高级别的智能驾驶体验。

对于舱驾一体域控设计而言，根据 SoC 和 MCU 单元组合后的架构设计，可分为 4 种常见架构形态。

(1)形态 1：SoC 和 MCU 完全独立，一般通过 SPI 总线，实现通信互联；

(2)形态 2：双 SoC 通过高速总线 PCIe 级联，实现高带宽数据交互，GPIOs 实现低速信号通信，两 SoC 分别通过 SPI 接口和 MCU 通信；

(3)形态 3：三个或三个以上的 SoC，通过 PCIe 连接到同一个 PCIe Switch 网关芯片，实现SoC 间高带宽数据交互，同时各 SoC 分别通过 SPI 接口和 MCU 通信；



如上1、2、3这类型中央控制器的设计主要取决于新所选型的芯片能力能否完全适配上对于对应的算力需求。

从所要实现的智驾系统和座舱系统的分级标准上进行芯片选型是比较合理的一种方式。比如，针对L2级以下功能，通常智驾和智舱是可以选择低算力平台的一些芯片的。因为从智驾上讲，50Tops+50KDMIPS已经足足够已，而智舱而言，则基本就是一些常规的2D图像显示和声音报警，甚至连像DMS这样的处理单元都用不上的。因此，这样的智舱芯片可能连AI算力需求都是极低的。

然而，随着自动驾驶系统的升级，比如L2+以上的系统，在硬件选型上则更倾向于大算力、存储、通信接口更加丰富的芯片了。

(4)终极形态：MCU 集成在 SoC 内部，通过芯片内部的 IPC 接口，实现进程通信和数据交互；



以英伟达的DRIVE Thor为例，该芯片支持多域计算，隔离自动驾驶和智能座舱相关功能。DRIVE Thor 的性能高达 2,000 teraflops的 FP8 精度，允许在不牺牲精度的情况下过渡到 8 位。将智能功能（包括自动驾驶和辅助驾驶、智能泊车、驾驶员和乘员监控、数字仪表盘、车载信息娱乐 (IVI) 和后座娱乐）统一到单一架构中，这样可以提高效率并降低总体系统成本。通常，数十个电气控制单元分布在车辆各处，为各个功能提供动力。

DRIVE Thor 作为第一个 NVIDIA GPU 中 Tensor Core 的新组件中的推理变压器引擎 AV 平台。借助该引擎，DRIVE Thor 可以将 Transformer 深度神经网络的推理性能提高高达 9 倍，对于支持与自动驾驶相关的大量复杂的人工智能工作负载至关重要。

同时，DRIVE Thor 首次在 NVIDIA Hopper? 多实例 GPU 架构中引入的尖端 AI 功能，以及 NVIDIA Grace? CPU 和 NVIDIA Ada Lovelace GPU。这具有对图形和计算的 MIG 支持，独特地使 IVI 和高级驾驶员辅助系统能够运行域隔离，从而允许并发时间关键流程不间断地运行。

因此，借助 DRIVE Thor，域控开发端可以有效地将许多功能整合到单个片上系统 (SoC) 上，从而缓解供应限制并简化车辆设计开发，从而显着降低成本、减轻重量并减少电缆数量。

总结

未来随着智能驾驶技术的普及，智能座舱所能发挥的空间也就越大，舱驾一体化逐渐成为发展趋势，终极目标是将座舱域、智驾域、动力域、底盘域、车身域进行跨域大融合。而实现这一目标的前提是先做分布式融合后建立一定的局部跨域融合处理，即先将部分域的功能集成到一个高性能计算单元内，再逐渐聚合更多的功能域。随着大算力芯片的研发落地，后续的舱驾一体甚至是整车一体化控制都会逐步实现。