行泊一体的历史、现状和发展趋势-上｜盖世大学堂舱驾、行泊一体系列知识讲解

在智能汽车领域，行泊一体技术成为近年来的热门话题，其对于提升汽车智能化水平具有关键意义。本篇文章围绕行泊一体技术展开，涵盖汽车电子架构演变历程、自动驾驶传感器的发展与功能适配，以及自动驾驶域控制器的发展趋势，探讨技术背后的原理、优势及面临的挑战。

一、汽车电子架构的演变历程

在汽车发展的历程中，电子架构经历了从模块化到集成化、集中化再到域融合的过程，最终朝着车云融合的方向发展。

早期，即20世纪90年代，ECU数量较少，仅为个位数或十位数。当时汽车功能有限，一辆车所能提供的完整功能大约只有十几个。在这种情况下，一个ECU通常只负责一个独立功能，例如一个ECU专门用于播放收音机，另一个负责点亮前大灯。这种模块化的设计与当时的产业生态相契合，许多供应商专注于单一功能部件的软硬件设计，如车灯、车身控制模块、方向盘、仪表、蓝牙钥匙等相关ECU。

随着市场竞争加剧，汽车厂商为满足消费者多元化需求，尤其是面向年轻群体增加信息化功能，汽车功能变得日益复杂。如今，仅座舱功能就多达近百个，行车和泊车功能加起来也有40个左右。功能的增加促使汽车电子架构向集成化发展，即将多个功能集成到一个域控制器中。这就好比管理学生，管理10个学生相对轻松，而管理1000个学生时，将他们划分成不同班级，由班主任负责管理更为高效，域控制器就如同班主任。

随着软件定义汽车理念的兴起，汽车更加注重服务。不同功能域之间的交互变得频繁，例如在NA highway时，需要在屏幕上显示路线和探测目标；TSR功能需要在仪表上显示限速信息。集成化架构因物理隔离难以满足这种跨域交互需求，于是集中化架构应运而生。集中化强调跨域融合，通过软件服务实现不同域之间的功能订阅，提升了架构的灵活性。此外，开发成本、人工成本和开发周期等因素也是推动架构发展的重要考量。车云融合则是未来的发展趋势，虽然目前相关技术仍在探索中，但已有部分企业开展相关研究。当下，跨域融合是行业讨论的热点话题。

二、自动驾驶传感器的演变与功能适配传感器在泊车与行车功能中的应用

自动驾驶功能的实现离不开各类传感器的支持，其发展演变与汽车功能的日益复杂密切相关。

在泊车功能方面，超声波雷达与后置摄像头配合，实现倒车影像功能。前置毫米波雷达在一些主机厂的方案中，为追求冗余和更可靠的效果，会与前摄像头组合使用。毫米波雷达因其探测范围广、距离远、输出信息多的特性，被应用于AEB和ACC功能。在AEB功能中，它能够检测目标物的存在，并测量与目标物之间的碰撞时间和距离，从而实现紧急刹车；ACC功能同理。

车道保持辅助功能主要依赖摄像头。与AEB、ACC不同，车道保持需要识别车道线，而雷达更擅长识别动态目标，对于车道线这种颜色差异的识别能力有限。摄像头能够通过图像识别车道线，确保车辆在车道中间行驶。随着技术发展，摄像头传感器从单后视摄像头逐渐演变为360环视摄像头。对于具有自动泊车辅助(APA)功能的车辆，360环视摄像头能为其提供更全面的环境信息，帮助识别地上的锥桶、停车位上的停车锁、倒车时的柱子等物体，同时增加的超声波雷达起到辅助作用，与摄像头信号相互补偿，实现半自动泊车辅助功能。

功能升级带动传感器的新增与优化

在行车功能方面，为实现更高级的驾驶辅助功能，车辆增加了多种传感器。例如，在车辆后保险杠两端加装两个毫米波雷达，可实现交通拥堵辅助和高速公路驾驶辅助(HWA)功能。在高速公路或城区拥堵路段行驶时，当车辆需要变道，这些毫米波雷达能够识别后侧来车，避免发生车祸。

前角雷达的加入进一步拓展了车辆的功能。拨杆变道和自动变道辅助(ALC)功能的实现依赖于前角雷达对周围环境的感知。ALC功能更为智能，它能够识别左侧车道线是否空闲，自动判断是否可以变道，并在必要时提醒驾驶员。此外，前角雷达对于泊车功能中的后车穿行报警(RCTA)、后车穿行刹车(RCTB)、前车穿行报警(FCTA)、前车穿行刹车(FCTB)等功能也起到重要作用。当车辆从停车场出来时，无论是倒车还是前进，前角雷达都能检测到横向穿行的目标物，并及时触发相应的报警或刹车动作。

NOA功能对传感器的要求更高。该功能旨在实现车辆从起点到终点的自动驾驶，需要车辆能够规划路线并感知周围环境。为此，车辆配备了四个测试摄像头，与鱼眼摄像头不同，测试摄像头更适合行车功能，其探测距离和处理速度能够满足高速行驶时对感知的需求。此外，长距前置摄像头也被应用于NOA功能，它能够探测更远的距离，为车辆的行驶决策提供更充足的信息。

在城区复杂路况下，激光雷达的作用日益凸显。城区道路存在行人、电瓶车、交通灯、路口等多种复杂元素，激光雷达能够通过发射几十万级的点云，构建一公里范围内的高清地图，帮助车辆识别建筑、树木、马路牙、路口等环境信息，从而支持城区领航服务。不同主机厂对于激光雷达的应用策略有所差异，例如特斯拉在这方面的需求相对不那么强烈。

三、自动驾驶域控制器的发展趋势从独立到融合的发展路径

随着汽车传感器数量和功能的增加，电子电器架构也在不断演变。早期，当车辆功能相对简单，仅涉及倒车雷达、360环视、基于前视的安全和舒适功能时，电子电器架构采用分布式设计。以毫米波雷达和摄像头为例，供应商分别提供带有AEB、ACC等功能的产品，各部件之间相对独立，通过简单的请求制动等方式实现协同。这种架构在当时的技术和成本条件下具有合理性。

随着泊车功能的不断丰富，如增加APA、RPA等功能，需要处理更多的传感器数据，如12个超声波雷达和4个环视摄像头的数据。泊车控制器应运而生，它成为第一个采用域控制器形式的部件。与传统的单一功能ECU不同，泊车控制器需要收集并融合环视摄像头的图像数据和超声波雷达的感知结果，进行二次感知和控制。尽管在车灯等部件中此前已存在域控制器概念，但泊车控制器属于更高级的智能域控制器。

行车功能的发展也促使行车控制器的出现。由于行车和泊车功能在感知、操作系统部署、规控、环境建模等方面存在诸多共性，为降低成本、提高算力复用率，行泊一体的趋势逐渐形成。将行车和泊车功能集成到一个域控制器中，不仅减少了硬件成本，还提升了系统集成度，使系统间通讯更加高效，为后续的OTA升级提供了更大的空间。

舱驾融合的技术支撑与优势

在行泊一体的基础上，舱驾融合成为新的发展方向。以英伟达的芯片为例，从小鹏汽车对orin系列芯片的应用可以看出，算力的提升为舱驾融合提供了可能。早期受算力限制，难以实现舱驾融合，而如今随着英伟达、高通、地平线等公司推出高性能芯片，这一设想得以逐步实现。

舱驾融合具有多方面优势。在成本方面，减少了硬件控制器的数量，降低了成本；算力可在不同系统间复用，提高了资源利用率。集成度的提升使得系统可控可管，迭代速度加快。例如，在车机系统中添加新功能时，若采用传统分布式架构，可能会因涉及多个ECU部门的协调而困难重重，而舱驾融合后，通过OTA软件推送即可轻松实现。

实现舱驾融合需要技术支撑。首先是Hypervisor技术，它如同“会下蛋的老母鸡”，对底层物理资源进行抽象，实现分时复用。在一台电脑中，Hypervisor可以让座舱系统和智能驾驶系统共享物理资源，如CPU、GPU、DPU、VPU、NPU等。根据不同需求，可采用固定分配或动态分配资源的方式，目前常见的是固定分配，如将8个CPU核中的4个分配给座舱，4个分配给智能驾驶。Hypervisor有Type 1和Type 2两种类型，Type 1类似于在Windows系统上通过VMware运行Linux系统，Windows系统既可以运行自身进程，也可以支持虚拟机运行；Type 2则更为纯净，其宿主操作系统仅负责维护基础服务，应用程序全部在虚拟机中运行。不同公司根据自身情况选择不同类型，如高通采用黑莓的QNX操作系统时选择Type 1。

中间件技术也是舱驾融合的重要支撑。传统的ECU开发耦合度高，而中间件通过对计算平台、传感器等资源进行抽象，对算法、子系统、功能采取模块化管理，并提供统一接口。以AUTOSAR CP的RTE为例，它作为中间件，使得开发者无需关注底层细节，如摄像头驱动型号等。在开发过程中，开发者只需向中间件请求所需资源，中间件会负责适配和提供，实现了软硬件解耦。这不仅缩短了开发周期，还提高了软件应用开发的成功率和质量，降低了前期开发成本和维护费用。

在中间件中，Some/IP和DDS是两种比较主流的协议。Some/IP采用请求/响应 + 订阅/发布的通信模式，是车规级协议；DDS以Topic为单元进行订阅/发布，属于工业级协议，应用范围更广。DDS支持丰富的服务质量策略，安全性更高，在工业、航空、汽车等领域应用广泛；Some/IP则具有占用资源少的特点。这些协议通过优化通信模式，降低了系统通讯的复杂程度，为舱驾融合提供了有力支持。