舱驾一体(2)_智驾衍生功能csdn-CSDN博客

本文链接：https://blog.csdn.net/weixin_50518899/article/details/135484390

1. 前言

舱驾融合可以从硬件和软件两个不同的层面去考虑，从不同层面进行融合的概念是完全不同的，目的和作用也完全不一样。

硬件上的融合更多地是基于产品的视角，从成本和设计的维度进行考虑。在一颗SoC芯片里面做融合，才是真正意义上的硬件融合。这个时候，底层软件和通讯方式都会有本质上的改变，成本上的优势也会凸显出来。

软件上的融合更多地是基于技术的视角，从功能的维度进行考虑。软件上的融合需要考虑怎么去改变整体软件架构设计，从而使得新的软件架构能够更加适用于舱驾融合系统。

2. 融合层级的划分

2.1 应用层面的融合

在物理形式上，驾驶域控制器和座舱域控制器采用完全相互独立的两个盒子，但在应用层面，很多功能之间的信息交互通过跨域进行打通，并实现数据融合创新 —— 将智能座舱中的人机交互、沉浸式体验等内容，与智能驾驶的各项功能深度结合、联动，从而提升用户的安全感与舒适感，增强用户对智能化汽车的使用体验。

比如通过以太网或CAN协议把座舱域和智驾域中的信号能够发送出来共享，这样一来，在功能层面就可以做更多的融合创新。如果按以前的策略，两个域的信号基本都是固定写死的，虽然可以通过私有CAN转发到整车CAN总线上，但是，系统需要获取相关信号的时候，还得再去整车CAN总线上查询，非常不方便。

2.2 物理形式上合二为一

座舱域控制器和智驾域控制器合并成一个盒子，内部由多个SoC或者MCU芯片构成。这些芯片用于支持不同的功能，每个芯片以及芯片内的不同核上运行不同的操作系统。这种形式又可再细分成两种方案：A. 座舱和智驾功能分别部署在不同的板子上。B.座舱和智驾功能部署在同一个板子上。

如果座舱和智驾功能分别部署在不同的板子上，用于支持座舱和智驾功能的SoC芯片肯定都会有自己专属的外围电路设计；如果两者的功能部署在同一个板子上，设计方案可以从整体上去考量，包括器件的选型，电路、供电、存储等方面的设计，比如，考虑DDR是否可以共享、EMMC模块是否可以共享等等。整体来讲，B方案比A方案在电子器件、接口、线束等部件的使用量上有一定程度的减少，使得BOM成本相对较低。

2.3 SOC芯片的功能融合

智舱和智驾的功能由一颗单SoC芯片来完成 —— 在芯片上运行虚拟机，通过虚拟机分割出不同的功能模块，来实现不同安全级别需求的舱驾功能。

有一些芯片公司和主机厂在探讨这样的方案，未来也很有可能会有这样的一些芯片产品出现。但是，理想很丰满，现实很骨感，短期内应该是很难看到这样的理想方案落地。

大部分车型无论是对于成本，还是可靠性都比较敏感。同样，开发一个新车型，车型的上市周期也会有一定的要求，所以主机厂一般会首选技术成熟度较高，并且成本已经在行业内能够被分摊下来的成熟方案。另外，不管是主机厂的组织架构，还是对应用层的梳理，都需要很长时间去调整和消化。

3. 厂家的融合方案

3.1 特斯拉

特斯拉是中央计算+区域控制理念的最早实践者，其在2019年量产的Model3车型中率先采用了此架构。其中，中央计算单元CCM融合了影音娱乐模块（座舱）、驾驶辅助系统模块（智驾）以及车内外通信信通模块，只不过三个模块分别部署在不同的板子上，运行着各自独立的操作系统，这算是舱驾融合形式在早期的一个初步尝试。

A.信息娱乐控制单元采用自研的车机操作系统，它基于开源的 Linux 操作系统进行定制开发。

B.驾驶辅助系统控制单元上的MCU运行FreeRTOS，SoC上采用基于Linux进行深度定制开发的Version操作系统。