智能座舱域控制器技术发展趋势分析

交流群 | 进“传感器群/滑板底盘群”请加微信号：xsh041388

交流群 | 进“汽车基础软件群”请加微信号：ckc1087

备注信息：群名称 + 真实姓名、公司、岗位

引言

提到座舱域控制器用的主控SoC芯片，大家第一个会想到应该就是高通的SA8155P 。目前，在主机厂新上市的中高端车型中，其座舱的主控SoC芯片多是采用高通的SA8155P， SA8155P为什么会得到众多主机厂的青睐呢？不妨先看一看高通座舱SoC芯片的迭代历程。

高通座舱芯片的迭代历程

高通四代座舱SoC芯片的算力

通过对比高通的四代座舱芯片，能够从侧面反映出：智能座舱的算力需求在不断增长，不管是CPU算力（DMIPS）、GPU算力（FLOPS）或者是NPU算力（TOPS）。

CPU算力和NPU算力需求预测（数据来源 - IHS Markit）

那么，智能座舱算力需求不断增长的驱动力又是什么呢？

1）EE架构的不断升级推动座舱功能集成化

智能座舱系统架构图（图片来源：大陆集团，中金公司研究部）

座舱集成的功能越来越多，需要处理的数据越来越多、也越来越复杂，因此座舱对算力的需求将持续增长。当前座舱域控制器功能集成的外在表现主要有：一芯多屏、舱内感知技术融合、舱泊一体等。

2）舱内应用场景的拓展

传统意义上的座舱一般只服务于驾驶员，现在座舱的概念从“驾舱”扩展到整个“座舱”，服务的对象就不再只是重点针对驾驶员，还包括了副驾和后排乘客。

芯驰科技资深产品市场总监金辉说：“传统的车机系统基本上只和驾驶员发生交互，而现在的智能座舱系统还需要同时和多个乘客发生交互，即多人交互。”

随着自动驾驶能力由人机共驾过渡到无人驾驶阶段，座舱的应用场景不断拓展，除了用于导航、安全预警等传统驾驶/安全相关的需求外，各种各样的人机交互以及娱乐体验变得越来越突出，座舱的应用场景开始逐渐延伸到办公、生活以及娱乐等。

应用场景不断地拓展，自然会衍生出一些新的功能需求，从而间接推动座舱算力需求的增长。

3）数据安全的重视

座舱内的应用生态越来越丰富，它对安全性的要求也变得越来越高。“每个人都希望保护好自己的隐私，国家也推出了数据保护和个人隐私保护相关的法律和法规。数据安全的处理，在一定程度上也会推高座舱对算力的需求。”均联智行中国区CTO陈远介绍说。

本文先从智能座舱域控制器的硬件架构特点入手，再从功能集成表现、产品形态、数据安全三个维度讲智能座舱域控制器的技术发展趋势。

1. 座舱域控制器硬件架构特点‍

1.1 座舱域控制器硬件架构方案：SoC + MCU

当前，座舱域控制器和智驾域控制器的硬件架构非常相似，都是SoC+MCU的方案。

座舱域控控制器的主控SoC芯片用于跑复杂的操作系统，做大数据的处理，比如图像、视频、音频等非结构化数据的处理。

但是，现在的智能座舱主控SoC芯片架构多是从手机端迁移过来的，本身不带车载网络访问的接口，比如CAN、MOST、LIN等。因此，需要搭配MCU去访问车身网络。因此，复杂的座舱域控制器一般都是采用两类芯片：SoC+MCU。

一般情况下：

1）SoC运行Hypervisor，在Hypervisor之上运行两类操作系统，其中对实时性和安全性要求比较高的安全域模块跑在QNX或者Linux系统上；对实时性要求不太高、但对生态要求比较高的娱乐域模块跑在Android系统上；

2）MCU运行AUTOSAR系统，用于CAN/LIN总线的唤醒、通讯以及电源管理等。

座舱域控系统软件架构（图片来源：公众号-阿宝1990）

为什么MCU是座舱域控硬件架构中不可或缺的一部分呢？诺博汽车副总经理陈礼顺解释道：“MCU的实时性和可靠性要求非常高，启动唤醒都是毫秒级别，需要支持CAN、LIN各类车载通讯总线。座舱域控制器与车身、动力等控制器的信息交互需要通过MCU来完成。另外，MCU还需要对SoC进行电源管理和状态监控。

“也有厂商打算通过在SoC里面集成一个MCU模块，来替代外挂的MCU，但是目前内置MCU的方案的可靠性有待验证，并且集成后的MCU和SoC电源需要考虑独立供电以降低静态功耗，实现起来也相对复杂些。

“相比于MCU，SoC的功耗很大（静态电流很大），所以在整机睡眠状态下，SoC一般处于断电状态，MCU处于供电状态。当MCU监控到有唤醒源时，会把SoC唤醒，然后SoC开始启动工作；如果SoC需要进入睡眠模式，MCU会把SoC电源给断掉。

“此外，整个产品级控制器的电源管理都是通过MCU去实现的，MCU是不可缺少的。”

1.2 座舱主控SoC芯片与智驾主控SoC芯片的区别

跟智驾主控soc芯片一样，座舱主控SoC芯片也是采用异构多核架构，并且，两者的内部架构也大体相似——都包括了CPU、GPU、NPU等多种异构资源，但座舱和智驾毕竟是两种不同的应用场景，这就决定了座舱SoC芯片和智驾SoC芯片在设计的时候会各有侧重点。

1）异构架构的侧重点不同

座舱域控器主控SoC芯片的侧重点是CPU和GPU，智驾域控器主控SoC芯片的侧重点是CPU和NPU。

CPU用于通用逻辑运算，比如说系统调度、外部资源访问等，不管是座舱系统，还是智驾系统，CPU资源都是不可或缺的。
GPU浮点运算能力强，但是在智驾SoC芯片上，基本上不会集成非常强的GPU，因为其内部NPU的张量单元本身就很强，不需要GPU去做张量运算和加速运算；座舱SoC芯片需要进行图像的3D渲染、图像拼接以及运行大型的3D 游戏等应用，因此座舱SoC芯片对GPU的能力要求会比智驾SoC芯片高。

“在早期，座舱中的GPU主要是用于支持基本的2D界面交互功能。而现在，客户的要求变得更高，除了要求我们在安卓上使用原生 SDK做图形开发以外，还想达到更炫的效果，比如 Normal贴图；甚至，有一些客户直接要求使用 Unity游戏引擎来做界面交互的内容；并且，在车机APP应用里面，客户还需要系统能够运行一些大型的3D游戏。这些需求对 GPU的算力需求都非常大。”北斗星通智联科技产品技术中心常务副总经理董红荣说。
NPU作为神经网络算法的加速器，负责处理AI方面的计算需求。智能驾驶对NPU的算力需求比较大，这点毋容置疑；一些座舱SoC芯片虽然也带有NPU模块，可以做DMS或者LDW等一些基础的驾驶辅助功能，但整体而言，座舱主控SoC芯片中的NPU性能要弱于智驾主控SoC芯片中的NPU。

总之，座舱主控SoC芯片是通用核强于专用核，智驾主控SoC芯片则是专用核强于通用核。

2）接口定义的区别

座舱域控器主控SoC芯片和智驾域控制器SoC芯片的接口定义也有很大的区别。均联智行中国区CTO陈远认为，座舱面向的应用场景更侧重于舱内的人机交互能力。人机交互则需要提供大量的数据输出，比如，视频、声音，还有其它投影图像等数据输出；同时，还需要获取车里的数据输入，主要是车内人员的数据输入—— 有视频（DMS/OMS）、也有声音（麦克风）等。因此，座舱SoC芯片会面临一些多样化的传感器数据的输入和输出要求。

诺博汽车副总经理陈礼顺也基本认同这一观点，他说：“座舱外设的侧重点在于音视频等大数据的输入输出等。比如，支持多少DP或DSI 接口—— 决定了能接多少路显示屏；支持多少路TDM - 决定了是否可以实现更复杂的多场景音频通路；还要支持GNSS、WIFI、Bluetooth等模块接口。总之，座舱SoC芯片对外围接口的要求非常高。

“在自动驾驶系统解决方案中，毫米波雷达信号一般通过CAN总线传输，激光雷达信号一般通过以太网传输，这些都是标准通讯接口，因此，智驾主控SoC芯片的外设接口就相对简单，外设方面需要重点考虑摄像头的接入。”

3）功能安全设计的差别

“功能安全不是针对芯片，而是针对产品本身。功能安全设计是一个系统工程，既可以在芯片层面设计一些冗余或者增加一些状态检测，也可以针对控制器产品本身进行系统级的监控以及功能分解。

“芯片厂商在做SoC芯片设计开发的时候，如果考虑功能安全，必然要考虑它具体的应用场景，是应用于座舱，还是应用于驾驶，甚至是具体的某些工况，然后再针对相应的场景、工况做针对性的基于芯片层面的功能安全设计。”诺博汽车副总经理陈礼顺告诉九章智驾。

座舱SoC芯片和智驾SoC芯片在做功能安全认证方面没有太大的差异，但是在功能安全设计上有一定的差别。

据北斗星通智联科技产品技术中心常务副总经理董红荣透露，除芯片本身的功能安全设计之外，还需要有其它的设计来联合保证智能驾驶的功能安全要求达标。芯片只是一部分，系统方案是另外一部分，如果要做系统方案备份，芯片设计本身就需有一些接口能够做冗余通讯方式。

相对而言，座舱系统对功能安全设计的要求就要低很多，即便是对安全性和实时性要求比较高的仪表或者HUD模块，主控SoC芯片功能安全等级达到ASIL B即可满足要求。

2. 座舱功能集成化的表现

整车EE架构由分布式架构向域集中式架构升级，驱动座舱内一个个独立的ECU集成到一个座舱域控制器的DCU上。座舱需要整合的功能越来越多，那么座舱进行功能整合的原则是什么？哪些功能适合被整合进去？

2.1 功能整合的原则

1）在座舱主控SoC芯片的能力边界之内

集成什么样的功能取决于座舱主控SoC，主机厂或Tier1会评估座舱主控SoC能够支持接入多少路、多大分辨率的摄像头和显示屏；同时，也要看被整合功能的安全等级是否能够被座舱芯片覆盖到（不超过ASIL B），如果主控SoC的处理能力或性能能够覆盖到此功能，那么便可以初步判断，此功能适合作为座舱功能的一个延伸，被集成进去。

2）无需额外新增硬件

如果增加一项或几项功能，可以不用增加硬件，只需要把算法和软件移植到座舱域控制器里面，同时，在成本上还具有一定的竞争力，此功能便适合被集成进去。

北斗星通智联科技产品技术中心常务副总经理董红荣举例说：“如果座舱域控SoC芯片本身不带5G模组，但非要融合V2X功能，那么，开发者就需要单独找个5G模组装到域控的板子上。这样可能既增加了系统成本，又增加了设计难度，甚至还导致要实现的功能与其他域的联系变弱的负面影响。在这样的情况下，就没必要去整合V2X功能。”

2.2 座舱功能集成化的三种表现

随着智能座舱主控SoC芯片性能的不断提升，以及5G车联网、OTA等功能的加速渗透，无论是主机厂还是Tier1，都开始注重智能座舱域控制器在功能上的融合。座舱域控制器的功能集成主要表现在如下几个方面：

2.2.1 一芯多屏

在传统的座舱解决方案中，中控、仪表等系统相互独立，一般由单一芯片驱动单个功能/系统。随着座舱智能化发展，座舱域控制器进一步集成仪表、HUD、流媒体后视镜等其它系统 —— 从单个SoC驱动单个系统单一屏幕到单一SoC支持多系统多屏显示。

一芯多屏（图片来源：大众对外公开宣讲材料）

要在一个SoC芯片上支持多个屏的显示，从安全性角度考虑，虚拟仪表、HUD需要采用QNX或者Linux系统；从软件生态角度考虑，中控导航、副驾娱乐和后排娱乐则需要采用Android系统。

目前主流的方案是采用虚拟机-Hypervisor来实现在一个硬件上运行多个操作系统，那么现阶段，Hypervisor技术在座舱上的应用还存在哪些不足或需要提升的地方？是否有其它技术可以作为Hypervisor技术的替代方案呢？

Hypervisor技术存在的不足或需要提升的地方：

1）会造成一定的硬件性能损失

芯驰科技资深产品市场总监金辉介绍说：“使用软件虚拟化需要付出代价，不管是CPU、GPU，还是NPU，它们的算力在软件虚拟化的过程中会流失掉一部分，并没有被完全用起来，也就是说性能打了折扣。同时，外设访问的性能也会受到软件虚拟化的影响—— 多个系统要通过软件虚拟化去访问同一个接口，这个接口需要在虚拟机软件里去做一些软件层面的处理，访问外设的效率和性能会降低。”

“ 使用Hypervisor一定会导致系统开销增大，像GPU、CPU以及NPU等系统资源进行虚拟化处理的时候，硬件资源在不同的应用之间进行切换，不可避免地会造成系统总负载的升高。”均联智行中国区CTO陈远也基本认同这一观点。

2）QNX Hypervisor授权费用高，且对芯片厂商支持力度不够

在座舱域控制器上，如果Hypervisor是采用QNX hypervisor，上面再跑 QNX和Linux系统，其实相当于要给黑莓付2份的授权费，授权费用非常高。

北斗星通智联科技产品技术中心常务副总经理董红荣还提到了一点，就是QNX 对芯片厂商的支持力度不够。QNX Hypervisor虽然满足功能安全的需求，但是很难在所有芯片上得到应用，支持Hypervisor的国产芯片目前多是采用基于Linux内核的Hypervisor。

3）系统没有实现有效的隔离

“Hypervisor技术是通过软件来实现系统的划分，并没有实现硬件层面的有效隔离 —— 各系统都是放在同一个软件的上层去运行，相比于硬隔离方案，功能安全和信息安全得不到有效的硬件保障。”芯驰科技资深产品市场总监金辉表示。

那么，是否有Hypervisor的替代方案呢？

均联智行中国区CTO陈远告诉九章智驾：“QNX的行业地位，短期内很难被撼动。所有的选择都是在成本和效率之间去寻找平衡。目前有一些企业采用硬隔离的方案，硬隔离方案是一种选择；不用硬隔离方案，在芯片上进行软件隔离也是一种选择。”

采用Hypervisor技术的优势在于所有的IP核（ CPU、GPU、DSP等）以及周围的外设都可以共享，而硬隔离的问题在于资源不能很好地去共享。比如，安全域中用于仪表模块的资源闲置了，也没办法分配给娱乐域去使用。

但是，硬隔离也有自身优势，芯驰科技资深产品市场总监金辉表示：“相比于Hypervisor技术，采用硬隔离方案便无需支付虚拟化软件上的License费用，并且算力也不打折扣，功能安全和信息安全也能够得到保障。”

2.2.2 舱内感知技术融合

目前DMS的主流实现方案是基于人脸识别的视觉技术，对芯片的要求很高 —— 首先是车规级的要求，需要经过环境试验和寿命试验等可靠性认证；其次是对AI算力的需求也较高，比如，为了准确识别人脸3D 的球状形象，不仅需要较高分辨率的摄像头，在图像数据采集后还需要将模型进行优化。

随着技术的发展，DMS延伸发展到了OMS，即将检测范围从驾驶员扩展到车内乘客，比如，检测乘客是否系安全带，下车的时候是否把儿童遗忘在车内等应用场景。当前不少主机厂已经将DMS和OMS组合起来进行应用。

DMS及OMS功能主要是通过对舱内摄像头数据的实时分析来实现的。现在座舱主控SoC芯片的算力和性能越来越强，不仅能够支持多通道的视频输入能力，还集成有单独的DSP单元。

将DMS/OMS功能融合到座舱，不仅是因为座舱SoC芯片的性能能够覆盖到DMS/OMS ,也是因为把它们融合到座舱，它们便可以和座舱内的其它关联模块更好地进行信息交互。

比如，伟世通的 HMEye 是基于视线测量的 DMS，除了可以监测驾驶员的双手和视线是否在驾驶状态，它还可以让驾驶员通过眼球的转动实现开关广播、调整温度、开启导航等功能，这样，在驾驶过程中，驾驶员便可以更安全地去进行人机互动。

2.2.3 舱泊一体

泊车融入到座舱也有功能集成化的因素：早期的360环视都有单独的控制器；后来360环视和自动泊车辅助APA进行融合，再升级到融合泊车功能，控制器的性能再次升级；再往后发展，座舱主控SoC芯片具了更强的CPU算力和AI算力，具备了整合泊车功能的条件，于是，也便有了把泊车功能融合到座舱的需求出现。

座舱整合基本的泊车功能：一是可以降本，至少可以把原来泊车的控制器省掉，能够节省一定的物料成本；二是整合到座舱，能够更好地做泊车场景下的人机交互设计，把泊车功能融入到座舱，座舱域控制器会得到更多的泊车信号；最后，座舱上的算力也能得到最大程度的利用。

均联智行中国区CTO陈远解释道：“泊车功能是在停车的场景下才会用到，刚好跟座舱上的一些应用形成时间上的错位，比如导航信息显示、行车信息显示都是在行车的时候使用，泊车的时候这些应用基本都处于停用状态，因此，泊车时便可以将座舱上剩余的大部分算力全部用于做泊车的相关应用。”

3. 座舱域控制器产品形态的变化

在不同的自动驾驶阶段，座舱域控设计理念上的不同，甚至会导致产品的形态产生较大的差异。

从技术发展趋势上来看，当前属于人机共驾阶段，即所谓的驾驶辅助阶段。在此阶段，智驾域控和智舱域控还是两个独立的控制器。等过渡到真正的无人驾驶阶段，业内人士普遍认为，随着整车电子电气架构的进一步升级，达到所谓的中央计算平台+区域控制器的架构阶段，座舱和智驾的功能会高度融合，即舱驾一体。

中央计算+区域控制架构（图片来源：均联智行对外宣传材料）

根据不同阶段的EE架构和主控SoC芯片的融合能力，舱驾一体高性能计算平台又会出现不同的形态：

采用多颗SoC芯片，座舱和智驾功能分别部署在不同板子上，板间通过以太网或PCIE连接
采用多颗SoC芯片，座舱和智驾功能部署在同一个板子上
座舱和智驾功能部署到单SoC芯片上

现在有人提到舱架一体HPC，但它也不是单SoC芯片方案，基本上是由两块板子组成，一块板子跑智能座舱系统，另外一块板子跑智能驾驶系统，但是，这样的结构形式对散热设计和供电设计提出了很高的要求。

某主机厂EE架构专家告诉九章智驾：“在域控制器阶段，智舱和智驾还是分别采用单独的盒子控制，这在目前来看还是比较好的方案。如果现在要把两个独立盒子的方案改为一个盒子内两块板子的方案，成本应该是可以降低，但在工程上会比较麻烦：比如一盒子里有多块板子，不同的板子用不同的供应商，中途发现不好用，换起来会很麻烦；如果是改为一个盒子一块板子的方案，意味着要把太多的功能绑在一块板子上，必然要受多方的牵扯，前期的协调沟通以及后期的更换维护都会比较复杂。”

某主机厂资深工程师也同意现阶段座舱系统和智驾系统应该相互独立的观点，他说：“单纯从整车EE架构的演进来看，舱驾融合肯定是大势所趋，但从短期来看，把智驾和智舱结合在一起，纯粹是一种形式上的结合，不是从产品需求的角度分解出来的结果。

“两者面向的应用场景、功能定义、性能边界都不一样，至少从目前来看，我觉得两者没必要去融合，如果硬要把他们捏在一起，不管是芯片的选型，还是外围电路的设计，面临的要求都不一样。那么，在成本和性能的考虑上，我们到底应该倾向于谁？总之，两者融合的方式会给开发者带来一系列设计方面的难题。”

虽然单SoC芯片的舱驾一体架构方案才能实现真正的座舱和智驾融合，但是座舱和智驾在功能需求、功能安全要求、信息安全要求以及对不同类型算力需求的侧重点等多个方面的要求是不一样的，如果两者放在一个芯片内去做，系统将会异常复杂，短期内很难有一款单SoC芯片能够同时满足这样的需求。

现阶段，单SoC芯片的舱驾一体方案仍面临一些硬件和软件上的问题。具体面临什么样的问题，这里便不多做介绍，感兴趣的读者可查看笔者之前的文章：“舱驾融合”技术发展趋势分析，里有比较详细的介绍。

4. 智能座舱的数据安全防护

现在座舱内的摄像头越来越多，舱内的功能也日渐丰富。座舱系统将会在本地使用大量的用户数据，同时也需要和云端保持实时的数据共享和同步，座舱域控制器是车企后续进行用户数据收集、OTA的重要端口，因此座舱系统的数据安全将变得非常重要。

那么应如何保护用户的私有敏感数据信息不被泄露和非法使用呢？

4.1 确保操作系统本身的信息安全

首先，要确保操作系统本身的信息安全，比如，Andriod、QNX等系统在启动的时候，需要做安全启动校验，防止系统遭到病毒感染。另外，对操作系统进行权限控制，做一些最小化的授权事项，避免所有的应用都可以访问一些很私密的区域。

其次，控制器之间的通信需要做一些安全通信处理，比如做C2C加密，一个报文过来，需要校验是谁发的。

4.2 数据加密和脱敏处理

数据采集和数据存储不仅需要得到用户的授权，同时还需要进行加密和脱敏处理。

数据加密 —— 座舱SoC芯片里有一个信息安全的模块HSM，它内置了信息安全的加密引擎。用户有了这些引擎和配套的处理器之后，可以在上层构建一些加密算法，比如国密的SM2/SM3/SM4/SM9，或者是商用的一些加密算法等。

北斗星通智联科技产品技术中心常务副总经理董红荣介绍说：“座舱信息安全的基本框架主要就是私钥加密+公钥解密。传输的隐私数据，第一，需要签授权；第二，需要加密。也就是说，用私钥加密，加密完了之后把数据发给对方。对方用公钥解密后才能看到数据。在传输过程中，其他任何人如果没有公钥，即便拿到数据也解密不出来。”

数据脱敏 —— 识别人的时候不能识别人的身份，也不能识别人的个性特征，比如，是男还是女。采集数据自然就可能会涉及到对他人隐私的侵犯，所以数据必须要经过脱敏处理。并且，很多数据必须在终端上处理，不能送到云端处理，以避免在往云端传输的过程中出现数据泄露的风险。

总之，数据安全的防护是非常复杂的工程，需要从各个方面去考虑。在保护数据的同时，还要防止被黑客侵入。“在全球，有很多黑客去攻击特斯拉的车辆，去寻找漏洞，然后再上报给特斯拉去获取一些奖励。现在很多车辆都要求做渗透测试，也就是说去找一家第三方公司去破解这辆车，看它有没有漏洞。”均联智行中国区CTO陈远举例说。

5. 座舱主控SoC芯片市场格局

当前，座舱域控制器的主控SoC芯片的市场格局已经逐渐明朗：中低端市场 —— 传统汽车芯片厂商是主力，比如瑞萨、TI、恩智浦等；高端市场 —— 消费电子芯片厂商是主力，比如高通、三星、英特尔、AMD等。

为什么消费电子芯片厂商能够杀入到座舱芯片市场领域？

有业内专家指出，消费电子芯片厂商之所以能够进入座舱领域，是因为从消费电子芯片转向座舱芯片的壁垒并不高 —— 两者在技术层面的要求高度相似，车规级的特殊要求主要体现在寿命、适应车载环境等安全层面，然而，消费电子芯片厂商通过这些车规级认证的难度并不是特别大。

同时，消费电子芯片厂商在消费端已经具备了足够强的设计能力，从而能够帮助他们在相对小众的汽车领域里，也能提供类似工艺和设计的车规级座舱芯片。

消费电子芯片厂商不但杀入了座舱领域，为什么还能牢牢霸占座舱领域的高端市场？

1）成本优势

消费级芯片厂商能够最大化利用其在消费端的生产能力，去摊销整个芯片设计的成本。因此当其把消费端的芯片转移到座舱领域来应用，在成本上对传统芯片厂商是一个降维打击。

诺博汽车副总经理陈礼顺说：“ 座舱的SoC芯片一般都会包含CPU、GPU、NPU、DSP等等，这些IP设计与授权一般都是来自第三方公司，比如ARM, Imagination等，对于传统汽车芯片厂商，这些IP的授权费都是非常高的，但对于高通来讲，一是很多IP都是进行自研设计，二是ARM的架构授权费也是要比一些传统汽车芯片厂商低很多。”

2）芯片的性能和迭代速度优势

首先，消费电子芯片厂商的座舱芯片在先进制程和大算力上具有明显的优势。

其次，消费电子芯片厂商的座舱芯片迭代速度快。消费电子芯片厂商可以在智能消费电子芯片迭代的基础上再去迭代座舱芯片，他们的芯片迭代的速度自然要远远快于传统汽车芯片厂商。

高通四代座舱平台的基础信息（数据来源：公开资料整理）

备注：截止目前为止，高通总共对外发布了四代座舱芯片，而这四代芯片都是遵循着“消费级芯片先发，智能座舱芯片后改”的底层逻辑。

参考资料：

1. 智能座舱域控制器（四）

https://mp.weixin.qq.com/s/IfCPucJ1zjV0bkvvUw0tVg

2. 自动驾驶“解放双手”？从标配DMS开始

https://mp.weixin.qq.com/s/p0heq74SRQmeqLRHZq64jw

3. 行泊一体：打通智能驾驶的“任督二脉”

PINnopqMj2KDV9tGEUY83Q