作者 | Jessie

出品 | 焉知汽车

座舱域和智驾域分开设计虽然在早期阶段可以降低开发难度和风险，但随着智能汽车功能的复杂化和用户需求的提升，这种分离设计逐渐暴露出诸多问题，影响整体性能和用户体验。首先，两者的软件版本可能由不同团队开发，导致版本迭代不同步，兼容性问题频发。分开设计导致开发、测试、生产等工序需要分别进行，增加了管理复杂度。座舱域和智驾域之间需要通过总线（如CAN、Ethernet）进行数据交互，增加了通讯延迟和带宽压力。分开设计导致硬件资源（如算力、内存、存储）无法共享，造成资源浪费或不足。座舱域和智驾域的功能交互需求日益增多，分开设计导致业务逻辑复杂化。分开设计限制了整体系统的优化空间，无法充分发挥硬件和软件的潜力。

随着电子电器架构架构从分布式走逐渐向集中，处理单元高度集中将逐步成为国内外各大Tier1/0EM公认的趋势。“舱驾一体域控制器”是指将智能驾驶（如自动驾驶、高级驾驶辅助系统）和智能座舱（如车载娱乐、人机交互）的功能集成到一个统一的域控制器中。舱驾一体域控制器通过硬件资源共享、软件架构简化和跨域协同，能够显著提升汽车电子电气架构的效率、性能和用户体验。

尽管面临实时性、安全性和软件复杂性等挑战，但随着技术的进步和行业标准的建立，舱驾一体域控制器有望成为支持“智能驾驶+智能座舱”的终局需求。由于这种架构具备线束少、集中易布置、成本低、数据融合处理实时高效等优势，被认为是未来汽车电子电气架构的重要发展方向。目前，各大主机厂已经在积极布局相关产品。预计2025年后开始逐步量产上车，逐步推动汽车智能化进入新阶段。

随着汽车行业竞争加剧和价格战的持续，驾舱一体域控制器（即智能驾驶与智能座舱功能集成到一个域控制器中）确实可以大幅缩减整车智能化部分的成本，并成为车企在成本控制和资源整合方面的重要解决方案。

对于各大汽车原始设备制造商（OEM）而言，自动驾驶域控制器的开发与应用已广泛开展，下一阶段它们将朝着中央控制单元（CCU）方向演进。本报告将自动驾驶域控制器的发展分为Two Box/Two Board(多盒 / 单盒、多板、多芯片)——>One Box/Two Board(单盒、单板、多芯片)——>One Box/One Chip(单盒、单芯片)三个阶段。其中One Box/One Chip这种舱驾一体域控中配置的一款域控制器系统级芯片（SoC）拥有多个通过芯片间通信相互连接的 IP 内核。未来许多高性能电动汽车将搭载高算力中央域控芯片，如基于 NVIDIA Blackwell 架构的下一代自动驾驶汽车（AV）处理器 DRIVE Thor，该架构专为 Transformer、大语言模型（LLM）和生成式人工智能工作负载而设计。并配备 NVLink 5 互连技术，芯片内存带宽可达 100 Gb/s 以上。

如下表，将对市面上主流的舱驾一体域控制器应用的芯片平台基本市场配置进行梳理，他们分别是NVIDIA Orin系列、Qualcomm Snapdragon系列、Mobileye系列及国内的Horizon Robotics Journey系列。

其中，NVIDIA Thor平台 具有1000 TOPS的AI计算能力，专为L4/L5自动驾驶和智能座舱交互设计，支持实时深度学习推理，能处理高复杂度的感知、决策和驾驶行为计算任务。像Tesla、Mercedes-Benz、Volvo等主机厂将会在其下一代自动驾驶平台中采用Thor，特别是自动驾驶和车载娱乐系统。

Qualcomm Snapdragon Ride Flex平台 提供约800 TOPS的计算能力，支持L3-L4级自动驾驶，并集成了针对智能座舱和车载娱乐的计算需求。与旧版Snapdragon Ride相比，Flex平台提升了计算能力和能效，满足未来智能汽车对车载AI的需求。BMW、Honda、GM等主机厂已采用Snapdragon Ride Flex平台，在自动驾驶、车载娱乐、智能座舱等场景中得到广泛应用。

Intel Mobileye EyeQ6 作为Mobileye的最新平台，提供1000 TOPS的计算能力，全面支持L4及以上级别的自动驾驶，特别注重视觉感知、精确定位和高精度地图的处理。Mobileye EyeQ6被BMW、Audi、Ford等车企应用于自动驾驶和高级驾驶辅助系统，支持从L3到L4级别的驾驶场景。

Horizon Robotics Journey 6/7 平台继续保持在500 TOPS以上，主打高效能和高集成度，适用于自动驾驶L4+、智能座舱、车载娱乐、车联网等多种智能功能。Journey 6和7在能效、计算能力方面进行了优化，特别适合中国电动车平台。国内OEM诸如BYD、Geely、长城汽车等中国车企已开始部署Journey 6/7，助力智能电动平台和自动驾驶系统的开发。

如上这些平台将在未来几年推动全球智能驾驶和汽车产业的发展。伴随跨域融合+中央计算式趋势，支持“智能驾驶+智能座舱”的驾舱一体多域计算控制架构或成为终局需求，随着今年汽车行业的大降价，各车企对于成本控制及资源整合越发重视，驾舱一体可以进一步大幅缩减整车智能化部分的成本。

舱驾一体融合目标及实现策略

舱驾一体化方案通过整合智能驾驶域与智能座舱域的硬件架构和软件系统，实现资源复用与协同管理。对于行业系统工程师实际关心的是如何在实际操作中实现这些整合，可能会遇到哪些技术难点，比如实时性保障、安全隔离、资源冲突解决等。对于设计而言，可能更希望了解具体的解决方案，比如使用哪些芯片架构，软件框架如何设计，测试验证的方法等。同时，可能还需要考虑成本控制、供应链管理以及符合行业标准的问题。

如下图是典型的舱驾一体中央计算平台架构设计图。

基于当前智驾系统的传感器架构布局，下一阶段的舱驾一体域控的布局将无疑会仍旧沿用当前的智驾系统感知布局I（5*Radar+12-13*Camera+12*USS+1-3*Lidar），唯一不同的是由于舱驾一体预计会采用更高算力的芯片平台，因此，对于如上传感器会采用更大分辨率、更高探测性能的感知硬件。比如，前视摄像头会从当前的8M升级为17M，侧视和环视会从当前的2M升级为5M甚至8M。激光雷达会从当前的128线升级为更多的线，毫米波雷达会从3D升级为4D，这样所有的毫米波原始点云数据将直接接入到域控中进行处理，这样就可以方便感知数据进行前融合处理。

此外，整个域控还会同步接入智能座舱的多模态感知源。包括智能语音输入、智能手势检测、智能人脸识别等。这些多模态信息以前是单独输入给座舱域控，再通过CAN信息传递给智驾域控的。当然，不得不说，这样的处理和传递过程存在一定的延迟。基于舱驾一体的域控，所有这些感知源只需要传递原始信息进行处理即可。当然，过程中，多模态之间的数据对齐也是需要算法进行专门设计的。

多计算域隔离能力，可支持时间关键型的进程不间断同时运行，也就是说，车辆在一台计算机上可以同时运行 Linux、QNX 和 Android。

以下从关键维度进行系统性解析：

1、软件架构设计

如上软件架构各层级细化说明如下：

硬件层

•CPU - Thor 芯片：作为整个系统的核心计算单元，提供强大的通用计算能力，支撑各类算法和应用的运行。

•GPU - Thor 芯片集成：用于加速深度学习等计算密集型任务，如目标检测、图像识别等。

•传感器组包括摄像头、毫米波雷达、激光雷达和惯性测量单元（IMU）等部分。

•执行器组包括制动、转向、油门及基础车身控制等。

驱动层

•CPU 驱动 - Thor 芯片：负责与 Thor 芯片的 CPU 进行通信，为上层软件提供对 CPU 资源的访问接口。

•GPU 驱动 - Thor 芯片：管理 Thor 芯片集成的 GPU，使上层应用能够利用 GPU 的计算能力进行加速计算。

•传感器驱动涉及摄像头驱动、毫米波雷达驱动、激光雷达驱动、IMU 驱动等多个模态的传感器接入。

•执行器驱动包括刹车执行器驱动、转向执行器驱动、油门执行器驱动。

操作系统层

操作系统层主要涉及三大操作系统，包括实时操作系统（RTOS） - 如 FreeRTOS。可以为对实时性要求较高的智能驾驶功能提供支持，确保系统能够在规定的时间内响应和处理事件。通用操作系统 - 如 Linux，可以用于智能座舱等对实时性要求相对较低的应用场景，提供丰富的系统服务和开发环境。虚拟机管理程序（Hypervisor），能够实现 RTOS 和通用操作系统的隔离和资源分配，确保两个操作系统能够安全、稳定地运行在同一硬件平台上。

中间件层

中间件在舱驾一体域控制器的设计中扮演着至关重要的角色，因为它作为连接硬件、操作系统和应用功能的桥梁，直接影响系统的性能、灵活性、可扩展性和安全性。这里的中间件主要包括通信中间件（CAN、以太网、FlexRay）、数据管理中间件（数据库、数据融合模块）、AI 中间件（推理引擎 - 如 TensorRT、模型管理模块）、安全中间件（故障诊断模块、冗余管理模块）等。

一般情况下，舱驾一体域控制器需要同时处理座舱域（如信息娱乐、人机交互）和智驾域（如感知、规划、控制）的功能。这些功能通常由不同的团队开发，运行在不同的操作系统（如RTOS和Linux/QNX）上。中间件通过提供统一的通信机制（如DDS、SOME/IP），实现多域之间的数据交换和功能协同，确保座舱域和智驾域的无缝集成。

同时，中间件通过资源管理模块来高效地管理有限的硬件资源（如CPU、GPU、NPU、内存）。包括动态分配算力、内存和带宽，确保关键任务（如自动驾驶）优先获得资源。实现负载均衡，避免资源浪费或瓶颈。支持多任务并行处理，提高系统整体效率。

智驾域功能（如感知、控制）对实时性和可靠性要求极高。中间件通过实时通信机制（如DDS）和任务调度策略确保关键数据的低延迟传输。提供高可靠性的通信保障，避免数据丢失或错误。支持故障检测和恢复，提高系统的鲁棒性。

舱驾一体域控制器通常采用异构计算架构（如CPU、GPU、NPU协同工作）。中间件通过抽象硬件差异实现异构计算资源的统一管理和调度，提供高效的跨硬件数据传输机制，支持多种计算框架（如TensorFlow、PyTorch）的集成。

应用层

该层涉及高级驾驶辅助系统（ADAS）应用：如自适应巡航控制（ACC）、车道保持辅助（LKA）、自动紧急制动（AEB）。智能座舱应用：信息娱乐系统、导航系统、人机交互系统（HMI）等。

2、电路复用融合

舱驾一体的电路复用应该是指硬件层面的资源共享，比如使用同一个处理器或者共享电源管理模块。需要考虑到不同系统的实时性和安全要求，比如智能驾驶可能需要更高的计算能力，而座舱集中式域控则注重多媒体处理。这时候可能需要异构计算架构，比如使用SOC结合MCU，确保关键功能的安全隔离。中央计算平台内部通过优化整合，提供统一的电源接口防护和一级电源模组。座舱模块复用智驾功能模块供电电源轨。

举例：以阶段性舱驾一体域控可能仍旧采用SoC+MCU异构架构（如英伟达Orinx+高通SA8295+Infineon TC3xx）为例说明舱驾一体域控在包括异构计算平台集成、传感器供电复用等。

1）异构计算平台集成：共享电源管理单元（PMIC）和时钟系统。智能驾驶ASIL-D级功能由Orinx+独立MCU保障，多媒体处理由SA8295 GPU承担，通过PCIe Switch实现计算资源动态分配。

2）传感器供电复用：比如，环视摄像头与DMS摄像头共用5V电源轨，采用Time Division Multiplexing技术分时供电。智驾毫米波雷达与座舱毫米波生命体征检测共享24V电源模块，设计瞬态响应<5μs的智能配电单元。

3）Switch复用：座舱和智驾内部通过单一Switch模块相连，节省座舱Switch，减少两者以太网链路及对外以太网通信接口数量。

4）导航定位模块复用：在之前座舱和智驾分开情况下，GNSS/IMU等定位模块是分开的，一般情况下两者在其特定的模块下承担相应的任务子项。通过，舱驾一体域控制器的设计结合，可以很好的融合IMU/GNSS模组，减少误差和通信成本。

3、影像处理策略

智能驾驶的摄像头和座舱的摄像头可能有不同的用途，比如环视摄像头和车内监控摄像头。如何复用这些摄像头的数据，同时处理不同的算法需求，比如同时进行驾驶员状态监测和道路识别。可能需要优化图像处理流程，使用多任务神经网络，或者动态调整分辨率，确保资源合理分配。

为了实现舱驾一体域控的影像交互处理过程，可以从多模态数据流管理和渲染的角度进行分析。

3.1、多模态数据流管理

构建Camera Service中间件层，支持YUV422（ADAS）与RGB888（DMS）双格式并行输出。采用H.265硬件编码器实现4路1080P@30fps视频流压缩传输，带宽占用降低40%。

这里的视频流涉及环视视频流和前视视频流两类。

3.2、动态渲染优先级调度

建立QoS分级机制：ADAS警示信息（L1）抢占AR导航（L2）和娱乐界面（L3）。采用GPU硬件虚拟化技术，划分20%算力保障ADAS图形渲染延迟<50ms。

4、系统状态机统一管理

对于舱驾一体域控系统而言，应该是要整合两个系统的状态，比如车辆启动、熄火、休眠等状态。需要考虑不同子系统之间的状态同步，比如当自动驾驶系统检测到故障时，座舱需要及时提示用户。因此，需要设计一个中央状态管理器，定义统一的状态转换规则，避免冲突。

4.1、分层状态建模

构建三层状态机架构：基础层主要呈现电源状态（OFF/ACC/ON），功能层用于驾驶模式（L2/L3/L4）与座舱场景（办公/休息/娱乐）场景功能定义，交互层主要是考虑整体舱驾一体方案的HMI呈现策略。

对于如上分层结构设计，可以很好的实现基层驱动与整车功能联动，基于同一个MCU对舱驾SOC的统一电源状态管理，能够做到极致节能和状态统一。如整车上电时，智驾或座舱功能的可用状态与仪表或PAD状态显示实现完全同步。又如，考虑一些常用的智车交互产品——哨兵模式。按照原始智驾和智舱分开设计的方案下，一般激活时，由于该功能既涉及：智驾域控进入低功耗（Particial Working）——>智驾SOC驱动环视视频流——>通过Eth/GMSL输出视频流给到座舱域控，整个过程存在多个控制器之间的信息交互和传递。后续车辆正式高压上电后，还存在从Particial Working到Full Working过程中的控制权切换。而切换为舱驾一体系统方案后，就不在存在如上的情况了。

4.2、事件驱动同步机制

整个设计可以基于DDS的分布式事件总线，关键状态变更（如AEB触发）通过RTPS协议50ms内同步至座舱系统，HMI响应延迟<100ms。

5、存储复用管理

存储复用方面，可能需要共享存储硬件，但隔离数据分区。智能驾驶的数据量大，实时性要求高，而座舱可能更多是多媒体存储。需要优化存储管理策略，比如使用高速缓存和固态硬盘组合，动态分配存储资源，同时确保关键数据的可靠性和安全性。

整个存储复用可参照如下模式进行划分：

5.1、混合存储架构

配置LPDDR5X 16GB统一内存池，划分安全隔离区（ADAS 8GB/座舱6GB/共享2GB）。NVMe SSD采用RAID1镜像存储关键参数，读写速度达3500MB/s。

5.2、数据生命周期管理

建立动态存储配额机制：ADAS传感器数据保留周期≤30天，座舱娱乐数据按LRU算法自动清理。紧急事件数据触发Write-Protect机制，防覆盖时间≥72h。

6、OTA复用

舱驾一体域控可以统一OTA升级，这涉及到同时更新两个系统的软件，需要协调升级流程，确保兼容性。可能需要分阶段升级，先升级基础模块，再更新应用层，同时有回滚机制，防止升级失败导致系统瘫痪。实现差分升级优化，采用算法（如VCDIFF）生成ADAS与座舱联合升级包，体积可以减少60%。建立依赖关系图谱，确保ECU固件与应用程序版本兼容性。通过安全验证机制，实施三级签名校验（供应商/OEM/云端），关键ECU升级采用HSM加密传输。设计A/B双分区回滚策略，异常状态恢复时间<3分钟。

7、通信诊断、电检

通信诊断和电检标定方面，需要统一的通信协议，比如CAN FD或以太网，确保两个系统之间的数据高效传输。诊断工具需要支持跨系统的故障诊断，可能需要开发统一的诊断接口，方便标定和测试。采用混合网络架构，主干网络采用10Gbps以太网，关键控制链路保留CAN FD。设计网关报文转换引擎，时戳对齐精度±10μs。统一诊断服务，集成UDS与DoIP协议栈，支持OTA诊断模式切换。电检标定工具集成XCP协议，ADAS参数标定效率提升5倍。

其次，生产流程和产品管控融合，这涉及到制造环节的整合，比如同一生产线组装舱驾一体硬件，测试流程需要同时验证两个系统的功能。质量管理体系可能需要整合，确保零部件和软件的一致性。

总 结

除开以上的信息说明外，整个舱驾一体域控的技术实施关键点还包括确保其功能安全设计达到性能要求。包括建立ASIL-B(D)混合安全架构，关键信号传输采用CRC32+ECC双校验，MTTF＞10000小时。实时性保障方面，设计基于时间敏感网络的调度器，ADAS任务抢占延迟＜5μs，座舱非实时任务容忍延迟提升至200ms。在热管理优化方面，一般设计采用3D均温板+石墨烯复合散热方案，计算平台结温控制在＜95℃@TOPS 200工况。最后，舱驾一体化方案需建立跨域协同开发流程，建议采用V模型开发体系，同步开展ASPICE L2级流程认证与ISO 26262功能安全认证。量产阶段建议设置＞20%的硬件资源冗余度，为后续功能升级预留扩展空间。