行泊一体 - 打通智能驾驶的 「任督二脉」

作者：陈康成

遵循整车 EE 架构发展路径，智能驾驶相关功能的发展历程可分为如下几个阶段：

阶段 1：每个泊车或行车功能都有一个对应的 ECU 单元

阶段 2：泊车相关功能开始不断地集成到一个泊车控制单元，行车相关功能整合到一个行车控制单元；

阶段 3：泊车功能与行车功能融合，出现行泊一体技术方案即智能驾驶域控方案，同时在这个过程中还出现了另外一条技术路径 —— 泊车功能融合到座舱域即舱泊一体；

阶段 4：智能驾驶域的功能和座舱域的功能进行跨域融合，形成一个更高性能的舱驾一体 HPC

舱泊一体和行泊一体方案属于下图中第 3 个阶段的产物。在今年，国内将会有若干家的行泊一体技术方案量产落地。本文重点讨论关于第 3 个阶段发生的一些问题。

舱泊一体方案

泊车和行车同属于驾驶类功能，按说，泊车与行车融合在一起才更合理一些，为什么在业内会出现把低速泊车功能融合到座舱域的方案呢？

舱泊一体方案 「诞生」 的缘由

九章智驾经过向业内专家人士调研，大家的观点基本是一致的：

• 座舱域控制器上的算力有了富余，剩余的算力可满足一些基本泊车功能的应用需求，如 360 环视和自动泊车辅助 APA 等基础泊车功能；

• 泊车功能会涉及到一些人机交互的设计，把泊车功能融入到座舱，座舱域控制器会得到更多的泊车信号，进而能够更好地去做泊车场景下的人机交互设计；

• 把低速泊车功能融合到座舱，可以把原来泊车的控制器省掉，能够节省一定的成本。

某主机厂智能驾驶系统设计负责人认为，低速泊车融入到座舱也有功能集成化趋势的因素。早期的 360 环视都有单独的控制器，需要接入 4 个鱼眼摄像头；后来，360 环视和自动泊车辅助 APA 进行融合，升级到融合泊车功能，控制器的性能也需要再次升级，并且需要接入 4 个鱼眼摄像头 + 12 个超声波雷达；再往后发展，随着座舱的智能化升级，座舱 SOC 具备了更强的 CPU 算力和 AI 算力，也能够支持更多的传感器接口，比如三星已量产的座舱芯片 Exynos Auto V910 中嵌入了 AI 加速计算，算力达 1.9TOPS，最多可支持 12 个摄像头。座舱具备了集成泊车功能的内外条件，于是，便有了把泊车功能融合到座舱的技术需求出现。

舱泊一体方案的劣势和局限性

为什么业内普遍认为舱泊一体方案是一种非主流的技术方案呢？因为相比行泊一体方案，它自身存在一定的劣势和局限性。

劣势：

1）开发协调沟通成本高

不管是在主机厂内部，还是在 Tier1 内部，泊车功能和座舱功能基本都是由两个相互独立的团队负责，并且对于泊车功能和座舱功能，主机厂多半也是交由不同的供应商去做。如果把低速泊车功能融合到座舱域，在进行项目开发或者需求变更的时候需要主机厂的两个不同部门与多个供应商之间进行协调沟通，沟通成本太高。

某主机厂智能驾驶负责人告诉九章智驾：「把低速的泊车功能融合到座舱域，在很多主机厂内部都是需要跨部门开发，主机厂现在的组织架构也比较难推动。尤其是对于传统主机厂，这种方案多半会被拒绝，因为其涉及到的参与方太多，在量产落地的时候，一旦出了问题，谁负责去解决？解决不了，谁又愿意去背锅？」

2）座舱功能和泊车功能的开发模式不同，两者融合在一起开发，会出现开发周期和迭代速度不匹配的问题。

东软睿驰副总经理刘威提到，从开发角度考虑，智能驾驶功能的开发跟传感器、执行器、数据采集、数据上传都有关系，跟外界打交道的东西比较多、需要同步开发；座舱相对来说是一个比较封闭的系统，跟周边系统的关联并没有那么强，以离线开发为主。如果把离线开发为主的座舱和跟外界交互比较多、以同步开发为主的泊车功能放在一块开发，两者在开发周期和迭代速度上不能够完全相匹配。

局限性：

从感知传感器数据共用和功能安全两个维度来看，把泊车功能融入到座舱域方案的局限性在于：会限制泊车功能在以后的迭代升级，这种方案目前主要适用在一些追求性价比的中低配车型上。

1）对于基础泊车功能，现在车型上配置率比较高的是 360 环视和自动泊车辅助 APA，如果未来涉及到更高阶的泊车功能，比如代客泊车 AVP 或者家庭记忆泊车 HPA，则需要行车感知系统的参与，不管是前视摄像头，还是侧视摄像头，甚至激光雷达都要参与到整个系统的建图和感知定位里面。因此，从这个维度讲，高等级的泊车功能目前也是不适合融合到座舱域去实现。

2）现阶段座舱域控芯片和智能驾驶域控芯片的对功能安全的要求不太一样，座舱域控芯片对功能安全等级要求不高，只能支持一些低等级的泊车功能，比如 APA、AVM 等。

座舱域内部一般通过虚拟机管理器来运行两类操作系统：一种是具有较高实时性和安全性要求的 QNX 操作系统，用于仪表模块；一种是实时性和安全性不高，但是生态资源丰富的 Android 和 Linux 操作系统，用于娱乐模块。泊车功能需要在中控屏上进行图像显示，会涉及到类似于 3D 界面、全景界面、操作界面等人机交互相关的设计，所以它是放在娱乐模块去实现。娱乐模块当前的功能安全等级要求比较低，实际上是没办法去做更高等级的泊车功能，只能做一些基础的泊车功能 。

舱泊一体方案会存活下去么？

从泊车的发展路径来看，先是倒车影像，然后是 360 环视，再往后发展是记忆泊车 HPA 和代客泊车 AVP。360 环视是当前比较受用户欢迎、配置率比较高的一项 ADAS 功能，并且在未来配置率还有很大的上升空间。同时，把泊车功能融合到座舱，也可以省掉泊车控制器的硬件成本。因此，主机厂从用户体验和成本优化的角度去考虑，中低配车型可能会把比较实用的基础泊车功能融合到座舱；中高配车型要搭载更高等级的泊车功能，比如 HPA、AVP 等，它们对功能安全等级的要求更高，故无法融合到座舱里去做，因此中高配车型会选择采用行泊一体方案。

德赛西威副总裁李乐乐认为，舱泊一体和行泊一体两种技术方案会同时存在，如果把时间轴延长，跨越到 3 到 5 年后，在那个时间点，AVM 和 APA 差不多就变成低配车型上的标准配置，受限于成本，低配车型可能不会搭载中大算力域控制器平台，泊车和行车的功能就没办法集成到一起，故低配车型会选择把基础的泊车功能融合到座舱的技术方案。而中高配车型具备中大算力域控制器平台，肯定还是要采用行泊一体方案，即低速泊车向智能驾驶域集成。

行泊一体方案

行泊一体方案的优势

当前，大部分车型的智能驾驶模块依然是由泊车和行车两套系统组成。整车电子电气架构由分布式架构向域集中式架构升级，以及行车和泊车传感器和域控制器共用技术的成熟，将进一步加快行泊一体技术方案的量产落地进程。

1）传感器共用，性能提升

一旦泊车功能升级到 AVP 或 HPA，还需要使用行车系统上的传感器进行感知补充，以增强系统的安全性。比如 AVP 中重点要解决的紧急避障问题，仅依靠环视摄像头和超声波雷达的感知是不够的，需要使用行车中的摄像头、毫米波雷达甚至激光雷达来提前识别一些远距离或微小物体。

同样，行车下的某些场景也需要利用低速泊车的传感器数据进行辅助支持。比如 Cut in 场景，在没有侧视摄像头的情况下，需要利用环视摄像头提高对后车切入预判的准确性。

2）功能迭代

原来行车和泊车分离的方案，大多还是沿用之前的传统分布式架构，受存储、硬件接口以及算力的限制，基本上不太支持 OTA 功能。而行泊一体域控制器基本上都配备有百兆甚至千兆以太网接口，并且有更多的算力支持高级算法模型的部署，因此能够更好地支持功能的 OTA 升级。

3）提升开发效率

行泊一体域控制器通过部署分层式的软件架构，实现软硬件解耦。底层预置基础软件、标准中间件，做成通用化，可在不同平台之间移植；同时，基于标准中间件提供相对稳定的上层接口，主机厂能够方便快捷地进行个性化和差异化的上层应用软件开发和迭代升级，进而缩短开发周期，提升开发效率。

知行科技产品总监司正敏认为，原来行车和泊车相分离时相当于是要做两套系统，现在行泊一体方案相当于合二为一。拿软件架构来说，底层的基础软件和中间件的开发其实是非常复杂和耗工时的，原来需要搞两套，现在搞一套就可以了，上层直接做一些差异化的应用模块的软件开发，开发效率会有一定程度地提升。

4）降本增效

首先，低速泊车功能融合到行车控制器上，在复用了行车控制器上算力的同时，也节省去了原来泊车控制器的硬件成本；其次，还能够简化域控制器的 I/O 接口，减少布线长度，进而有效降低整车的复杂度。总之，可以帮助主机厂降低整个的生产成本。

国内主流的行泊一体方案

德赛西威 - IPU02/IPU03/IPU04

1）IPU02

A. 主控芯片：TDA4

B. 操作系统：支持 QNX、Linux 和 AUTOSAR CP

C. 接口：

• 6 路 GMSL
• 8 路 CAN
• 6 路 100M +1 路 1G 车载以太网

D. 功能支持：

• 行车功能：自适应巡航 ACC、自动紧急制动 AEB、车道保持辅助 LKA 、高速公路辅助驾驶 HWA、导航辅助驾驶 NOA（高速）等。
• 泊车功能：360 环视、自动泊车辅助 APA、遥控泊车 RPA、记忆泊车 HPA、代客泊车 AVP 等

2）IPU03

A. 主控芯片：Xavier（英伟达）+MCU（英飞凌 Aurix 系列的 Safety MCU）

B. 操作系统：Xavier 采用 QNX，MCU 采用 AUTOSAR CP

C. 接口：

• 12 路 GMSL
• 12 路 CAN
• 2 路 LVDS
• 8 路 1G +1 路 10G 车载以太网

D. 功能支持：相比 IPU02，IPU03 支持增强型的 AVP 和高速 NOA；并且支持城区 NOA 和 HWP 功能

3）IPU04

A. 主控芯片：Orin（英伟达）+MCU（英飞凌 Aurix 系列的 Safety MCU）

B. 操作系统：Orin 芯片采用 QNX 或 Linux，MCU 采用 AUTOSAR CP

C. 接口：

• 16 路 GMSL（最高达 28 路）
• 24 路 CAN
• 4 路 LVDS
• 12 路 100M+12 路 1G +1 路 10G 车载以太网
• 2 路 Flexray
• 2 路 PCIe

D. 功能支持：相比 IPU03，IPU04 支持增强型的城区 NOA 和 HWP 功能

福瑞泰克 - ADC20/ADC25/ADC30

1）ADC20

A. 主控芯片：TDA4 + 地平线 J3

B. 操作系统：支持 QNX、Linux 和 AUTOSAR CP

C. 接口：CAN/CAN-FD/ 以太网 / LVDS

D. 传感器配置：6V5R12U

E. 功能支持：导航辅助驾驶 NOA（高速）、自适应巡航 ACC、车道保持辅助 LKA、自动紧急制动 AEB、自动泊车辅助 APA、遥控泊车 RPA 等功能

知行科技 - IDC MID

1）IDC MID

A. 主控芯片：灵活适配主流芯片如 TDA4/EyeQ5H 及地平线 J3 等国产芯片

B. 操作系统：支持 Linux、AUTOSAR CP 等

C. 接口：

• 12 路摄像头接口

• 8 路 CAN-FD

• 2 路千兆以太网

D. 传感器配置：4R5V12U

E. 功能支持：导航辅助驾驶 NOA（高速）、自适应巡航 ACC、自动紧急制动 AEB、记忆泊车 HPA、360 环视等

东软睿驰 - 行泊一体域控制器升级款

1）行泊一体域控制器升级款

A. 主控芯片：TDA4 芯片

B. 操作系统：支持 Linux 和 QNX

C. 接口：支持 CAN-FD、LVDS、以太网 1000BASE-T 等

D. 传感器配置：10V5R12U

E. 功能支持：导航辅助驾驶 NOA、记忆泊车 HPA、代客泊车 AVP 等功能

轻量级行泊一体域控制器与大算力行泊一体域控制器

在上一篇文章关于智能驾驶域控制器的一些观察中，文中提到了中低算力（轻量级）行泊一体域控制器和大算力行泊一体域控制器的一些差别，主要是从市场定位以及主机厂对两者诉求不同的角度去展开。在本文中，笔者再从技术的维度去讲一下两者的差别。

1）硬件配置层面

轻量级行泊一体域控制器是一种追求性价比的方案，主要支持实现的是 L1~L2 级的驾驶辅助功能。受成本限制，轻量级域控制器一般会选用高性价比的中低算力 AI 芯片，比如 TDA4，地平线 J3 等。整个域控制器的 AI 算力一般在十几 TOPS 到几十 TOPS 左右，并且能够接入的传感器数量、类型和性能受限，目前支持的传感器配置主要为 4R5V12U 或者 5R5V12U 等。

大算力行泊一体域控制器主要是搭载在高端车型，作为技术高点和品牌宣传的亮点；并且，它还有功能拓展的需求，需要算力预埋，会选取中大算力 AI 芯片，例如英伟达的 Orin X、华为的昇腾 610 等。整个域控制器的算力普遍在 200TOPS 以上，有的甚至把 4 颗大算力芯片级联在一起，达到上千 TOPS。同时，支持的传感器数量多、类型丰富，传感器的精度也会更高。比如蔚来 ET7 的传感器配置为 1L11V5R12U，采用了 7 颗 800 万高清像素摄像头和 1 颗波长为 1550nm 的混合固态激光雷达。

总之，系统的功能需求不同，传感器和系统架构方案的选择就会不同，需要硬件平台的接口，算力资源的需求都会不一样。

2）功能体验层面

从表面看，轻量级域控制器与大算力域控制器能够支持实现的功能大同小异，主要差异点在一些功能体验上。这不仅跟车辆配置的传感器类型和数量相关，同时跟域控制器内部所能部署的算法模型也有较大关联。

大算力域控制器能够部署更大、更复杂的算法模型，能够覆盖的场景更多，因此，所支持实现的功能在安全性和舒适性上会更好一些。比如高速上的自动换道功能，大算力域控制器可支持运行更深层次的神经网络模型，感知性能会更好，换道时的精确性便会更高；相比之下，轻量级域控制器受算力的限制，可部署的算法模型要精简很多，系统对换道时机的把控可能会差一些，甚至还需要驾驶员介入给予确认的情况下才能换道。

均胜电子智能驾驶系统设计负责人李茂青认为：「轻量级域控制器和大算力域控制器之所以会有功能体验上的不同，是因为两者的产品定位不同， 客户对这两种产品要实现的场景功能及性能、产品拓展需求、安全等需求不一样。举个例子，同样都要求实现高速领航功能，但细化后的使用场景和安全要求可能相差很大，比如需要能在多少车速下对前方静止障碍物实现避障，这个场景需求直接影响了感知方案设计，进而影响域控制器的方案设计；再比如对于某一系统失效场景，是可以直接将动态驾驶任务交由驾驶员，还是要求系统能够实现靠边停车需求，这个也直接影响了智驾系统的硬件安全架构设计。」

3）OTA 升级层面

轻量级域控制器为了最大化的利用有限的算力，软件和硬件的耦合度会更高一些，并且需要根据特定具体场景不断地去打磨功能。虽然它也可以进行 OTA 升级，但更多的是为了优化性能和解决 bug，因为算力不富余，导致在后期去增加新的功能会比较困难。

大算力域控制器，算力比较充足，能够支持较大程度的模型优化以及多轮的 OTA 升级，具备较强的可拓展性。因为算力强大，模型经过优化后即使不做特别的压缩和简化也能部署。轻量级域控制器在这方面就显得对算力 「斤斤计较」 了，OTA 升级前就需要把新模型所需要的算力计算清楚，不然就会出现模型经过优化后无法部署的尴尬局面。

从另外一个角度来看，中低算力的轻量级域控制器主要是为了解决当下已有的需求，大算力域控制器是为了解决将来未知的需求。

行泊一体域控制器的发展趋势

不管是轻量级行泊一体域控制器，还是大算力行泊一体域控制器，从整个域控制器的发展角度来讲，外围的 I/O 接口，即匹配的传感器配置以及关联的器件会逐渐趋同，并最终标准化。但是控制器内部选用的芯片不太可能统一，在软件和功能实现上还是需要做出一些差异化的设计和开发。

主要原因如下：

1）不同主机厂之间要差异化竞争，即使同一个主机厂，不同的车型，也会选择不同的硬件方案；

2）为应对主机厂不同的需求，芯片厂商的 Roadmap 也会打造出一些差异化的卖点。

「首先，不同的主机厂，域控制器所选用的芯片不太可能统一到一款或者少数几款芯片上。其次，即使同一个主机厂，不同品牌定位的车型，所选用的域控制器也不可能一模一样。从过去一段时间来看，芯片厂商都有自己的 Roadmap，并且不同的芯片厂商之间，为了应对主机厂的不同需求，他们的 Roadmap 上也会做一些差异化的规划。」 刘威博士解释道。

李茂青认为：「行泊一体域控制器正朝着通用化、平台化的趋势发展。研发通用化、平台化的域控制器，对 Tier1 来说不仅可以充分复用研发资源，降低研发成本，这个过程也可提高对此类域控制器的技术积累及认知，建立技术品牌影响力。对车企客户来说，标准化的硬件平台不仅可以大大缩短整车的研发周期，提高拓展性，还能解决成本等问题。」

行泊一体方案对自动驾驶供应链的影响

行车和泊车系统相分离的方案属于分布式架构阶段的产物。在此阶段，Tier1 占据主导地位，软硬件以打包的方式直接供给 OEM。供应链形式相对比较简单，属于 「线」 性的供应关系：软件供应商 / 芯片供应商 Tier2 → 零部件集成商 Tier1 → 主机厂。

行泊一体方案属于域集中式架构阶段的产物，在这一阶段，传统的 「线」 性供应关系被打破，供应体系由 「线」 发展成 「面」，形成以主机厂为中心的网状结构，产业链上各方的合作模式变得更加开放和多元化。

主机厂

泊车和行车相分离的系统方案基本都是 「黑盒」 模式，车企很难对其进行分解招标。而行泊一体方案打破了这种模式，使得主机厂与供应商在合作模式上变得更加灵活多样。同时，越来越多车企不再满足仅作为一个 「系统集成」的角色，而希望具备对整个系统和供应链的自定义能力。比如主机厂会直接与芯片企业开展战略合作，以便能够对域控制器中的芯片进行定制化开发。

据极氪智能驾驶系统专家夏天介绍，原来泊车和行车可以说是两套不同的系统，一般是泊车选一个打包方案供应商，行车选另外一个打包方案供应商。现在行泊一体了，主机厂的参与度会更高，可选择性也会而更大，一套大系统可以拆成多个包：传感器、控制器、系统集成、应用软件开发等，对于有必要并且自己能做的部分会自己做，没有必要或者不能做的部分会交给不同的供应商去做。整体来看，主机厂与供应商之间的合作方式变得更加灵活多样。

「以往合作模式中，Tier1 提供整体的软硬件解决方案给到车企，车企对控制器芯片的选择没有很强的倾向性。而现在，由于车企客户对于方案的开发程度、拓展性等都提出了更多、更高的要求，他们对于域控制器芯片的选择上会更具倾向性。于是，出现了车企客户基于已经选择好的芯片再去找相应的 Tier1 进行合作的现象。」 李茂青表示，「现在车企对于域控制器芯片的了解程度其实比我们想象中的还要深入，一方面是芯片厂商和车企通过战略合作的方式提供技术支持，帮助车企客户了解相关的产品技术；另一方面是整个智驾行业的人才流动非常大，把对芯片及基础软件等原来不太关注的技术领域，车企通过人才团队建设也慢慢积累了起来 」

Tier1

行泊一体方案或者说域控制器架构的量产落地，对传统 Tier1 带来了比较大的冲击。在以前，核心技术和推动力来自于供应链上的零部件公司，他们有什么样的产品，直接让主机厂搭载了去卖就好。随着电子电气架构的升级变革，硬件逐渐的标准化，软件从硬件中剥离出来，软件和硬件实现解耦，使得由软件来定义汽车成为了现实。因此，主机厂对掌握软件定义汽车的能力变得更加的强烈，他们希望能够逐渐地从 Tier1 手中夺回期盼已久的 「主导权」。与此同时，Tier1 为了维护自己的主导权地位，也纷纷开始进行垂直整合，打造软硬件全栈的研发能力，由系统集成商向系统方案解决商转型。

司正敏提到，行泊一体域控方案的应用，确实在迫使一些 Tier1 去做转型，比如原来只做泊车方案的 Tier1，正在行车方案上积极尝试。传统 Tier1 擅长硬件开发，现在需要继续突破、做强硬件开发创新能力。高度集成化域控同时推动开发生态体系重构，过去垂直单一的线型产业链结构，将逐渐演变为分层解耦、分层共享、跨域共用的立体网状生态系统，推动新型生态体系融合发展，而新型生态体系将持续助力集成化域控的进化。

芯片企业

芯片企业在自动驾驶产业链中变得更加活跃，现在芯片企业会直接去面对主机厂，帮助 Tier1 拿项目，或者直接和主机厂展开合作。通过这种形式，芯片公司不仅可以直接向主机厂展示其芯片的一些能力，还能够直接获取主机厂的一些诉求，比如域控制器后续的可拓展性要求、芯片的接口、计算资源等需求，从而能够更及时地去调整他们的产品战略方向。

同时，为了充分挖掘芯片的 「能力」，芯片企业也纷纷开始在软件层面进行布局，致力于为其客户提供软硬件整体解决方案。例如：

1）英伟达推出的 NVIDIA DRIVE 开源软件堆栈；

2）高通的 Snapdragon Ride 平台还包括安全中间件、操作系统和驱动程序等；

3）地平线推出的 AI 开放平台 - 天工开物主要包括三大功能模块：模型仓库、AI 芯片工具链和 AI 应用开发中间件；

4）黑芝麻发布了瀚海 ADSP 自动驾驶中间件平台。