随着智能驾驶功能的持续演进，点对点自动驾驶、远程遥控泊车等高阶智驾场景已逐步落地。然而，在用户实际使用中，经常面临“功能启动慢”、“等待时间长”甚至“首次无法成功激活”等问题，严重影响用户体验，尤其是在城市驾驶等“短平快”使用场景中尤为明显。

引发启动缓慢的根本原因往往涉及底层软件、系统中间件、上层应用、感知模型加载等多个维度，需要从系统角度对功能启动链路进行解剖和优化。

一、智驾“开机秀”：功能启动全链路解码

以点对点自动驾驶、远程遥控泊车为例，这些功能通常具备以下共同启动流程结构。

可以看出整车在不同的启动方式下会存在较大的启动时长差别。

冷启动 Cold Boot模式下，系统完全掉电后重新启动。包括SoC、MCU、电源管理模块全部重启，内存丢失。一般应用场景为用户早晨启动车辆，ECU 完全休眠。热启动 Warm Boot / Fast Boot则要求部分模块维持低功耗状态或常驻内存，系统从休眠/待机中快速恢复，保留部分上下文信息。智驾功能短时间内重启，车辆未熄火或刚停车几分钟后再次上电。

具体的冷启动与热启动的系统路径差异如下：

二、卡在哪儿？域控启动的隐形堵点

从上表中可以看出，整个智驾域控启动流程包括底软初始化、中间件启动、应用层软件加载几个大模块。且这几个模块会在自身启动过程中从其对应的几个方面影响系统加载启动速度。

1、底层基础软件（BSW）初始化

包括电源管理模块、ECU 通信（CAN、Ethernet）、MCU/SOC 启动引导等；

TCU/VCU等车辆控制域需先完成唤醒与通信握手。

2、中间件层启动

通常包括ROS 2、DDS、CyberRT等服务框架初始化；

涉及服务发现、Topic 注册、IPC管理、共享内存映射等；

各类设备驱动、传感器接入SDK、CAN/MIPI传感器桥接同步初始化。

3、应用层软件加载

功能模块如感知、定位、规划、控制等分别启动子进程；

多数采用模块化加载模式（以Docker/Colcon/动态链接方式）；

网络模型（例如BEV感知、地图匹配模块）首次加载需要较长时间；

同步等待外部条件（GNSS就位、毫米波雷达数据可用、高清地图服务拉起等）。

影响域控系统启动慢的原因如下：

1、系统模块串行启动逻辑

大量模块按传统依赖链“顺序”加载，导致部分模块空等或延迟。

2、感知/模型加载时间长

多数感知模型为ONNX/Pytorch格式，首次加载需GPU资源且模型解包慢；

大模型体积大（>300MB），涉及Flash读取与内存解压过程。

3、中间件服务发现耗时

DDS等机制需完成节点注册、服务广播与Topic匹配；

若存在资源抢占或并发初始化，可能出现阻塞或初始化失败重试。

4、多芯片协同延迟

主控SoC与协处理芯片（如辅助MCU/XPU）间需通过以太网或SPI完成同步；

GNSS模块、APA摄像头等如直连至辅助芯片，增加启动路径复杂度。

5、软件架构未优化

缺乏启动依赖图谱与并行优化策略；

无模块级健康状态管理，无法区分关键路径与辅助模块。

三、智驾秒启：加速域控的全链路解法

基于如上启动流程，我们可以考虑从如下几个方面进行启动时间优化。

1、休眠保活机制

该模式需要对关键模块（如中间件/地图进程）使用“常驻进程+低功耗挂起”。实际上这是一种域控SOC 长休眠模式。该模式下支持SOC快速启动，快速响应智驾业务请求。比如目前华为这种主流智驾方案就采用了这种方式可以最高保证到起电12s后就可激活智驾功能。具体地，可以利用DRAM保留、SoC低功耗模式如SC7。在前面的文章中我们有详细介绍这种低功耗模式。实际上，我们实测来看，底软启动总时间约在10s内完成，启动耗时较大的部分在于算法侧功能Ready时间。

这种休眠唤醒模式中，可以节省从域控唤醒到SOC上电之前的所有MCU加载底软运行时间。期间，在SOC底软启动后，还需要通过场景状态缓存模块保留上一次定位、GNSS状态、障碍物状态，跳过重新感知。常用于点对点自动驾驶、远程遥控泊车场景的恢复。这样可以进一步减少SOC的应用软件耗时。

2、并行化的架构策略

针对本文提到的典型智能驾驶场景点对点自动驾驶：Camera Service与GNSS/IMU、地图、雷达、V2X并行加载，可显著缩短 ready 时间，尤其在城市环境地图加载慢时效果更明显。

远程遥控泊车：泊车雷达、超声波传感器、车控接口、定位模块均可与 Camera Service 并行；这类泊车对感知链路依赖较少，提升空间更大。

比如，在算法模块的启动中，一般情况下，摄像头启动耗时较长，会阻塞后面定位等模块启动，导致整个算法完全启动ready时间变长。传统串行启动流程如下：

Camera Service 初始化过程包含驱动加载、ISP 初始化、GMSL/MIPI 链路检测、畸变矫正参数加载等，耗时甚至可达 3~8 秒。后续定位、感知、规划模块会等待 Camera Service “数据 ready” 信号才启动，导致整个 Ready 时间被 Camera 启动拖慢。

因此，可以将camera Service与其他启动耗时较短的算法模块组并行启动，通过应用层服务启动顺序优化，将服务的串行启动改为部分并行启动。模型转换为TensorRT engine（Plan文件）后以 memory-mapped 形式加载，避免完整模型加载/初始化流程，加速整个算法完全启动ready时间。下表列出了可以并行启动的候选模块（假设它们与 Camera 数据不是“硬依赖”关系，或可使用延迟绑定/占位输入机制）：

具体的并行操作步骤如下:

下图示例中显示了应用这种并行启动时序优化后的对比结果如下：

3、快启预热策略

提前启动域控减少智驾功能链路等待时间。该方案在用户即将接近使用功能场景前，后台预拉起部分模块。如车速<5km/h且靠近车库，提前预热泊车模块。通过域控预启动方法，在用户上车前提前启动域控，当用户上车设置导航完成后域控基本完成启动，智驾领航功能立即可用，用户基本无感智驾功能进入的等待时间。如下图，整个快启预热可以节省掉解锁走到车门处的整个时间大概5-10s时间。

如上通过快启预热进入机制的整理逻辑如下：

1）通过车辆检测车钥匙或手机蓝牙信号（包括蓝牙是否连接、蓝牙具体位置或蓝牙解锁车门），智能进入控制器收到相关信号后通过CAN网络唤醒启动车辆；

2）智驾域控收到该快启预热信号后，通过域控启动控制状态机从下电状态跳转至正常上电工作态；

3）快启预热期间，智驾域控各芯片通过相关的启动控制程序控制MCU做BootLoader，并预启动SOC相关的APP进程；

4）考虑到如上过程和正式的域控系统工作态是一致的，因此，需要驱动相关的热管理单元进行配热降温；

5）在驾驶员真正通过按钮启动车辆前，域控需要持续维持CAN网络唤醒状态；

四、软件性能优化

优化应用层算法软件、地图服务、定位软件等启动时长。这里我们详细介绍一些关于城市NOA启动的关键环节地图加载，主要通过地图服务更新校验链路优化实现。

4.1、地图服务软件性能优化

4.1.1、优化前架构

在原有架构中，点对点自动驾驶启动依赖于两种地图资源：高快路网地图（高速、快速路段）和城区 SD NP 地图（城市道路导航泊车一体化）。

其中关键耗时点：

token 获取：需要网络请求，耗时约 0.5~1s，受网络延迟影响大

云端地图校验与更新：若本地版本落后，需要下载或增量更新，耗时 1~5s 不等（城市道路地图体积较大）

地图解析：地图数据加载、索引建立需要额外 CPU/IO 时间。

优化前，整体导致城市 NOA 激活需要等到地图服务完成所有校验与更新，启动耗时受网络质量和地图版本差异影响较大，波动性强。

4.1.2、优化后架构

优化后采用全域 SD NP 方案，并调整了地图依赖策略。优化后总体可节省 17-19秒，且启动时间波动大幅降低。

1）全域 SD NP 地图替代 Landtopo+城区双地图模式

高速、快速路、城市道路统一由 SD NP 覆盖

消除了两套地图调用、校验和更新流程的串联延迟

启动后由独立线程或服务检测地图版本并下载，完成后自动刷新地图服务，不中断 NOA 运行

2）省略地图服务启动前的云端依赖

移除了 map_provider 获取 token 步骤

启动时不再强制进行云端版本校验与地图数据更新

地图数据更新可放到后台异步执行，不阻塞 NOA 激活

3）地图数据本地缓存与快速加载

采用分块加载（tile-based loading），本地保存常用路段地图片区，启动时仅加载必要片区，降低 IO 延迟

4）弱地图模式（Lite Map Mode）

在地图服务未 ready 时，算法使用基础导航与感知定位信息运行，支持动态切换到完整地图模式。此时，智驾领航上线全域SD NP⽅案，省略了map_provider获取token、云端检验以及地图更新等时间，并且智驾领航的激活不依赖地图。整体节省了智驾激活确认时间。

5）地图与算法解耦

智驾领航不再硬依赖地图服务完成启动，采用“算法先行”策略：在算法模块 ready 后 2~3 秒即可激活 NOA

初期运行可使用本地缓存地图数据或弱地图模式，待地图服务 ready 后自动切换到全功能模式

算法模块通过中间件（如 ROS2/DDS）接收地图数据

启动顺序可并行化，避免阻塞

4.2 定位服务软件性能优化

对于智驾系统软件来说，上电初期往往需要较长时间进行绝对位置定位。其中，涉及较长时间的卫星搜星等操作。

1）卫星信息搜索过程较长

当前，部分定位系统采用了慢搜星+快搜星交替的搜星模式，每个星系全部搜索完成后才进行下个星系的搜索。且在慢搜星模式下冷启动时遍历每个星系的每个卫星，搜星耗时长。

特别是慢搜星模式在冷启动时遍历每个星系每颗卫星，耗时长（TTFF 高）。同时，缺少利用热缓存 / A-GNSS / 并行化 /优先级策略，导致冷启动性能差，且对天线/遮挡更敏感。

整个优化过程需要考虑在城市峡谷/遮挡场景下，增加首fix 成功率与稳定性，对硬件/功耗影响最小化。

这里的优化方案包括新版本采用星系交叉搜索方式，并行多星座同时搜索。优先级扫描，比如搜索Galileo一段时间没有搜到该星系卫星信号，不会等到Galileo星系所有的卫星信号全部搜索一遍，而会直接跳到下一个星系进行搜星。此外，也可以采用缓存与辅助数据（A-GNSS）策略。

2）全局时间同步过程较慢

一般情况下，如果定位盒子是从卫星获取UTC时间，接收器接收一帧来自卫星的UTC时间帧，时间较长。这里可以让上电启动时间内，直接让域控从车载总线（如 Ethernet、CAN FD、LIN、FlexRay 等）向座舱域控制器（ICU/IVI）获取当前 UTC 时间。其中，座舱域通常已经通过蜂窝网络（NTP）、车云协议或 RTC 与网络时间同步，精度可达毫秒级。

3）搜星结果解析较慢

当前卫星信号解析包含步骤：获取星历、计算卫星位姿、筛选可用卫星。期间，接收器必须收到至少 4 颗可用卫星的星历才能完成首次定位解算（TTFF — Time To First Fix）。理论最优时间：在信号良好、星历刚好开始广播的情况下 ≥12 秒，实际在冷启动或弱信号下可达 30 秒甚至更久。

这时可以在启动时不等待卫星广播星历，而是直接通过A-GNSS（Assisted GNSS）云服务从服务器获取最新星历。星历数据通过车载网络（蜂窝 / 以太网）传给定位盒子 或 GNSS 模块，立即可用。优化后时序中，星历获取时间大大减少（具体优化值取决于网络速度和星历文件大小，通常几十 KB）。后续计算和筛选在星历到达后立即执行。

五、总结

在智能驾驶系统日益复杂的今天，域控启动慢已经成为制约用户体验和功能落地的关键瓶颈。通过对全链路启动流程的深入剖析，我们发现问题主要集中在底层软件初始化、感知与算法模块串行加载、地图依赖冗余，以及定位服务中搜星、信号解析、UTC 时间同步等环节。针对这些痛点，本文提出了一系列优化思路：包括 Camera Service与其他模块的并行加载，通过 全域 SD NP 策略弱化地图依赖，利用 总线 UTC 时间源替代卫星时间同步，以及 A-GNSS 星历加速解析 等。实践表明，这些优化可以将智驾功能的可用时间从十余秒级缩短到秒级，显著提升了功能的响应速度与使用体验。未来，随着软硬件协同和云端辅助的进一步深入，智驾系统的启动将不再是瓶颈，而是成为打造“点火即智驾”体验的核心竞争力。