行泊一体域控技术解析：本土Tier1的软硬兼修与三路围攻

这两年我一直在一线研究本土Tier 1的智能驾驶布局，一个明显的感受是：行泊一体已经从“可选项”变成了“必答题”。跟几家主机厂的电子电气架构负责人聊天，几乎每个人都在筛选行泊一体域控供应商。行泊一体的核心就是把行车和泊车两套功能收拢到同一颗域控芯片上，通过软硬件的深度协同把成本打下来、把体验提上去。这篇文章算是我这段时间的一份研究笔记，重点拆解本土Tier 1“软硬兼修、分三路围攻”背后的技术逻辑和工程经验。如果你正在做智驾方案选型，或者跟我一样关注Tier 1的竞争格局，这篇内容应该能帮你省不少时间。

1. 行泊一体为什么突然成了主战场

过去一辆车要实现基础的ADAS和泊车辅助，需要多个分散的ECU，行车一个、泊车一个，甚至APA还要单独挂一块板子。现在把这些功能全部收拢到一个域控里面，硬件成本、线束成本、装配成本几乎同时缩水了一大截，这个账主机厂算得很清楚。

1.1 从分到合：行泊一体到底解决了什么问题

传统方案里，行车功能（ACC、LKA、NOA）和泊车功能（APA、RPA、AVP）由独立控制器承载，各用各的传感器、各走各的网络拓扑。这带来的问题很直接：

• 算力孤岛：两套芯片各有闲置资源，却没有一套机制能互相借用，整体利用率很低。
• 传感器无法复用：前视摄像头看到的信息，泊车时完全帮不上忙；环视摄像头在行车中也基本不参与感知。
• 功能割裂：从高速NOA退出到进入停车场，驾驶员能明显感觉到“系统切换了一下”，体验不连贯。
• 维护成本高：两套软件、两套OTA体系，研发和售后都要各养一支团队。

行泊一体的做法是把行车和泊车放到同一个“行泊一体域控”上，所有摄像头、雷达、超声波的原始数据都汇入同一个SoC，在统一的感知空间里完成环境建模和路径规划。用户端最直观的变化是，从高速路到停车场，整个智驾过程不会“掉线”，系统始终保持连贯状态。

这个事用生活里的类比很好理解：以前出差要带好几个充电器，现在一个多口氮化镓充电头全搞定。功能和体验都更简单，成本也更低。从整车架构演进的角度看，行泊一体还承担着“算力收敛”的使命——域控取代分布式ECU，是电子电气架构从分布式走向集中式的必经一步。

1.2 为什么这次是本土Tier 1的主场

过去底盘和ADAS基本被博世、大陆、采埃孚这些国际巨头统治，因为传统Tier 1的优势在精密制造和模块化集成，属于典型的“硬件驱动”模式。但行泊一体改变了游戏规则：它的核心不再是“把盒子做得可靠”，而是“把算法和硬件焊在一起做深度优化”。本土Tier 1的软件开发效率高、工程响应快，再加上国内主机厂对定制化服务和快速迭代的要求极其苛刻，国外Tier 1“标准产品+长周期”的打法很难跟上节奏。

中国停车场景的特殊性也是一个关键变量。国外泊车大多是规整的地下或露天停车场，国内则是窄车位、斜位、无划线位甚至机械车位，停车场光线忽明忽暗，还经常有行人、推车、锥桶混行。这些场景数据只有在国内市场持续获取、持续训练，系统才能真正好用。本土Tier 1在数据积累和场景适配方面，天生就比海外厂商快一步。产品迭代周期上的差距更直观：国际巨头普遍需要18到24个月完成一轮功能迭代，本土厂商能压缩到6到12个月。在智能驾驶这种“软件定义”的赛道上，速度几乎决定了市场份额的归属。

2. “软硬兼修”到底修在哪：核心能力拆解

“软硬兼修”这个提法，听着像软件和硬件两条线各自发展，但行泊一体真正考验的，是把软硬件之间的缝隙填平。硬件是壳，软件是魂，两者耦合在一起才是完整的方案。

2.1 硬件底座的博弈：算力、接口与选型逻辑

先说硬件。行泊一体不是纯算法工程，SoC的算力、接口数量、散热设计、功能安全等级，全都直接决定方案的上限。目前主流的SoC平台我整理了一个表：

选型逻辑不是越贵越好，而是看目标车型和功能定义的匹配度。比如只做高速NOA加记忆泊车这个最低配功能集，用TDA4或者征程3就足够了；想做城市NOA和代客泊车，就得往Orin X或征程6上走。

这里有一个容易被忽视的指标：每TOPS的实际可用效率。有些芯片算力标得很高，实测利用率不到50%，表现反而不如算力低但充分优化的方案。所以我评估一个硬件平台，从来不看规格书上的峰值，必须拿真实的数据流跑一遍，看端到端时延、帧率、CPU占用率的曲线。硬件选型的另一个重点是外围接口设计——摄像头接入数量、毫米波雷达的接口、超声波阵列的布线方式，都会影响整机成本和装配复杂程度。

2.2 软件栈的护城河：中间件、算法与数据闭环

硬件只是底座，软件栈才是真正的护城河。行泊一体的软件栈可以分四层来看：

• 底层中间件：AUTOSAR Adaptive、DDS、SOME/IP通信框架，负责模块调度和跨核通信。
• 核心算法模块：感知、定位、预测、规划、控制，每个模块都有大量工程细节。
• 功能应用层：面向用户的NOA、AVP、APA等各种功能包。
• 工具链和数据闭环：仿真、标注、数据回灌、OTA升级，以及整个数据回流体系。

感知算法这几年的变化最大，从2D检测走向BEV鸟瞰图感知，又升级到Occupancy网络。行泊一体在感知架构上强调全场景同一套网，行车时用BEV模式处理前视和周视信息，泊车时把环视相机的图像也放进同一个感知空间，统一输出障碍物和可行驶区域。规划控制层面，行车和泊车的规控逻辑差异很大，但可以共享一个“意图决策层”，由上层统一判断当前应该由哪套策略来接管。

数据闭环是软件栈里最容易被低估的部分。一个量产项目要跑几百万公里真实数据，才能把边界情况收敛到可接受的水平。如果Tier 1没有把“路采—挖掘—标注—训练—评测—OTA”这条飞轮转起来，算法迭代能力就跟不上，光有再漂亮的演示视频也没用。这也是很多Tier 1不断招算法团队、自建数据平台的原因——因为这套能力短时间补不齐。

2.3 软硬协同设计才是“兼修”的真相

我见过不少项目死在软硬件脱节上：软件团队拿着“标准版”算法往新的硬件上移植，结果跑不动、发热高、时延不稳定，最后只能砍功能。真正落地的行泊一体域控，软硬件必须从设计第一天就协同：

• 算子级优化：算法部署到NPU时，要做算子融合、内存复用、模型量化，不然算力再高也吃不饱。
• 资源调度：行车和泊车模型同时跑，CPU、NPU、内存带宽的分配要很精细，否则就是灾难。
• 功耗与热设计：算力提升带来的散热压力，直接影响系统稳定性和性能释放。

举一个实际案例：某个泊车模型在GPU开发环境里跑得挺好，部署到目标SoC后，因为没有做内存访问优化，端到端时延多出40毫秒，最后重新编排了流水线才把指标救回来。这类问题只能靠软硬件团队从第一天就坐在一起定义需求、压测验证来避免。

用一个类比来理解软硬协同：软件和硬件的关系像厨师和灶台，光有顶级厨师没有合适的火力，炒出来的菜照样不对味。一台行泊一体域控，本质上是把“菜谱”（算法）和“灶台”（硬件）一起研发，才能做到性能与成本的平衡点。

3. 分三路“围攻”：三条技术路线的选择与推演

所谓分三路围攻，是指本土Tier 1同时从三条线路打进不同的价位段和客户群体，形成合围之势。这样即便某一两条路线暂时没有上量，整个盘子也不会太被动。三条路分别是：大算力自研路线、单芯片走量路线、软硬解耦生态路线。

3.1 第一路：大算力自研，死磕高阶行泊一体

第一路的画像最鲜明：多为有自研芯片背景，或长期绑定大算力SoC的头部Tier 1。他们一出手就是11V5R12U的满配，算力拉到200 TOPS以上，功能覆盖高速NOA、城市NOA、记忆泊车、代客泊车全场景。

这条路的商业逻辑是“硬件预埋、软件付费”：前期用高规格硬件把体验上限拉满，后续通过OTA不断释放新功能，靠订阅和选装包回收成本。技术护城河确实深，算法迭代和底盘调校都是长期积累，友商想短时间追上来很难。

代价也大。11V的传感器配置加上高算力域控，BOM成本对小车型来说很难接受，所以这类方案只能先投放到20万元以上的车型。等算法稳定、成本摊薄之后，再向中端市场下沉，形成降维打击。这条路更适合那些“手里有钱、团队有兵”的头部玩家。

3.2 第二路：单芯片走量，打穿15万级主流市场

第二路走的是性价比量产逻辑。核心思路很朴素：不用所有功能都贪多，把高速公路跟车、车道居中、自动变道、记忆泊车这几个最高频实用的功能打磨到极致，传感器简化为5V5R6U或5V6R12U，用一颗中低算力SoC把全部负载扛下来。

实际操作中有几个关键手段。软件上做“极简模式”，行车时停掉冗余的泊车模型，泊车时再加载，降低并发负载；硬件上通过标准化接口减少外围芯片数量；生产端把产线标定和装配工艺做深做透，提升装机良率。从落地价格看，早期一套行泊一体方案报价能到4000元以上，现在部分本土Tier 1已经能把方案包压到2000元上下，直接打开了15万级车型的大门。

这条路的本质是田忌赛马：不给客户全部能力，但给客户最常用、最稳定的核心能力。没有花哨功能，客户口碑反而好——大家最常用的就是那几项功能，用得稳定比什么噱头都重要。

3.3 第三路：软硬解耦，做智能驾驶的“安卓”

第三路更像一场生态赌局。核心做法是中间件加算法平台与硬件解耦，不绑死在一颗芯片上，通过标准化的平台层适配不同SoC，让客户可以选芯片、选硬件，软件以License或订阅的方式交付。

这种模式有点类似安卓和手机厂商的关系：Tier 1提供“操作系统加应用商店”，芯片厂和硬件伙伴提供“手机壳”。对主机厂来说，选择自由度大了，不会被单一供应商绑死；对Tier 1来说，软件资产可以跨平台复用，一套代码卖给多个客户，边际成本递减。

这路最难的是优化深度。同一个软件栈在不同芯片上，跑出来的性能和体验差异很大。没有针对性的深度优化，很容易出现“适配了但不好用”的尴尬。所以真正做软硬解耦的Tier 1，实际上还是会选一两颗主力芯片做深度适配和性能压测，其他芯片只作兼容选项。生态路线的成败，取决于能否把标准产品卖到足够多的客户手里，形成规模效应之后反哺软件研发。

对比一下三条路线的特点，可以看得更清楚：

三条路也不是非此即彼。很多头部Tier 1实际上是三路并进：大算力平台立品牌，单芯片方案保销量，解耦平台做战略纵深。

4. 实地推进中踩过的坑与排查实录

这一章聊点更接地气的，都是我在实际项目里见过、排查过的问题。行泊一体看起来热闹，真正跑起来全是细节。

4.1 行泊切换的“割裂感”问题

行泊一体跟单独的行车或泊车最大的区别，在于状态切换。实测中最常见的用户投诉是：从高速NOA退出到泊车辅助时，系统会有一秒多的迟滞，甚至误报“功能不可用”。

排查这个问题，我的思路是分三步走：

• 先看状态机迁移条件：行车状态到泊车状态需要满足哪些前置条件，是否因为某个条件不满足导致切换卡住。
• 再看传感器数据流的切换逻辑：环视摄像头与行车摄像头的曝光参数差异很大，切换瞬间可能导致感知短暂空白。
• 最后检查定位模块的切换时机：从道路坐标系切换到停车场局部地图坐标系，如果时序不对，也会造成系统“茫然”。

最有效的解决技巧是增加“预切换”机制。在自车进入停车场前500米，就提前加载停车场局部地图，同时把环视摄像头切换为低曝光模式，让系统做好状态准备。用户完全感觉不到断点，才算把行泊一体的“一体”做到位。

4.2 算力分配的隐性坑

行泊一体域控最头疼的不是峰值算力不够，而是资源分配不当导致“局部过载”。行车和泊车的感知模型同时加载到NPU上，一旦遇到拥挤停车场和高速工况叠加的边界场景，CPU占用率很容易飙到90%以上。典型表现是控制周期抖动——平均算力占用看着还行，但每隔一段时间出现一次超长时延，车内体验就是卡顿和顿挫。

排查和解决的思路是这样：

• 先用性能分析工具画出每个模型的算力占用曲线，找到占用的波峰和波谷。
• 建立任务优先级调度，行车侧的安全目标检测永远优先，泊车模型在非必要时降级运行。
• 把NPU算子排布错峰，避免行车和泊车模型在同一个时间片内竞争硬件资源。
• 对关键控制任务做锁核和带宽预留，防止调度抖动影响控制指令。

这些底层细节在演示阶段完全看不出来，但在量产项目里，往往决定了功能能不能稳定交付。我每次跟团队复盘，都会强调一句话：多花一周做资源画像，能省下后面三个月填坑的时间。

4.3 传感器标定与产线工艺的连锁问题

行泊一体的感知链路覆盖了前视、环视、雷达和超声波。传感器数量上来了，标定就成了生产环节的大坑。

我实际遇到过一次批量投诉：新车交付后，用户的AEB在高速上偶发误触发。排查到最后，根源是个别车辆的前摄像头安装角度有0.3度的偏差，导致某些工况下检测到“虚拟障碍物”。这类问题在产线上很难被传统终检发现，因为静态检测根本覆盖不了动态场景。

解决方向有三个：

• 把标定流程前移到线体更上游，确保安装夹具的重复精度。
• 在下线检测中加入动态标定校验环节，让车辆跑一段指定路线，自动校验摄像头外参是否漂移。
• 建立数据回传机制，把量产车上传的异常感知事件与产线标定批次关联起来，方便倒查溯源。

这条我认为是本土Tier 1从“能做出来”到“做得稳”最关键的一道门槛。

5. 后面还会怎么卷：趋势观察与个人心得

5.1 从行泊一体到舱驾一体

行泊一体的下一站，正在被扩展为舱驾一体。座舱芯片与智驾芯片集成到同一个域控甚至同一颗SoC里，行泊一体只是其中的一部分功能模块。舱驾一体更吸引人的地方在于：座舱和智驾可以共享算力池、共享摄像头信号、共享存储和外设，成本还能再降一截；体验层面，“上车—行车—泊车—离车”的全流程都可以通过同一个系统完成交互闭环。

工程挑战也跟着变大。座舱和智驾对功能安全等级的要求完全不同，热设计压力更大，软件隔离要求更高，还得深度融合虚拟化技术。我看到的头部Tier 1已经在做舱驾一体的技术预研，但真正的规模量产可能还需要两三年。对大多数主机厂来说，未来两年的主旋律仍然是以行泊一体域控为核心的中阶智驾量产战。

5.2 本土Tier 1如何不被卷死：几点经验心得

在行泊一体这个战场上，纯硬件的溢价空间已经很窄。主机厂反复比价的结果，就是方案商利润越来越薄。能撑起利润的只有两样东西：一是长期可迭代的软件能力，二是围绕量产项目积累的工程交付能力。前者的变现方式是订阅、选装和持续的OTA；后者的变现方式是稳定的良率、低返修率和快速的问题响应速度。

跟Tier 1的朋友聊天，大家基本认同一个判断：拿单靠的是技术和商务关系，活下来靠的是工程交付和数据闭环。未来两到三年，行泊一体赛道一定会筛掉一批玩家，剩下的要么在特定价位段做到极致规模，要么在某个细分功能上做到极致体验。

我个人在实际调研中最大的感受是，越是看起来不起眼的工程细节，比如一次标定流程的优化、一个算力调度的策略、一套数据回传的机制，越能拉大方案之间的体验差距。行泊一体到现在已经不是一个“能不能做”的问题，而是“能不能稳、能不能省、能不能快速迭代”的问题。谁先把这个答案写清楚，谁就能在下一轮价格战和技术战中站稳脚跟。