When it comes to the main control SoC chip used by the cockpit domain controller
, the first thing that everyone will think of is Qualcomm's SA8155P. Currently, among the mid-to-high-end models newly launched by OEMs, most of the main control SoC chips in their cockpits use Qualcomm's SA8155P. Why is SA8155P favored by many OEMs? Let’s first take a look at the iteration process of Qualcomm’s cockpit SoC chip.
The iteration process of Qualcomm cockpit chips
Computing power of Qualcomm’s fourth-generation cockpit
SoC chip
By comparing Qualcomm's fourth-generation cockpit chips, it can be reflected from the side: the computing power demand of smart cockpits is constantly growing, whether it is
CPU computing power (DMIPS), GPU computing power (FLOPS) or NPU computing power (TOPS).
CPU computing power and NPU computing power demand forecast (data source - IHS Markit)
So, what is the driving force
behind the
growing
demand for computing power in smart cockpits
?
1) The continuous upgrading of EE architecture promotes the integration of cockpit functions
Intelligent cockpit system architecture diagram (image source: Continental Group, CICC Research Department)
The cockpit integrates more and more functions, and the data that needs to be processed is increasing and becoming more and more complex. Therefore, the demand for computing power in the cockpit will continue to grow. The current external manifestations of cockpit domain controller function integration mainly include: one core and multiple screens, in-cabin sensing technology integration
, cabin and berth integration, etc.
2)
Expansion of in-cabin application scenarios
In the traditional sense, the cockpit generally only serves the driver. Now
the concept of cockpit
has expanded
from
the "cockpit"
to the entire
"
cockpit
"
, and the service
objects
are
no longer
just
focused on
the driver, but also include the co-pilot
and
rear
passengers
.
Jin Hui, senior product marketing director of Xinchi Technology, said
:
"
Traditional car-machine
systems
basically only interact with the driver, but now the smart cockpit system also needs to interact with multiple passengers at the same time, that is, multi-person interaction.
"
As
autonomous driving capabilities
transition from human-machine co-driving to driverless driving,
the application scenarios of the cockpit continue to expand.
In addition to traditional driving/safety-related needs
such as navigation and safety warnings
,
various human-computer interactions
and
The entertainment experience has become more and more prominent
, and
the application scenarios of cockpits have gradually extended to office, life, entertainment, etc.
The continuous expansion of application scenarios will naturally generate some new functional requirements, thereby indirectly promoting the growth of cockpit computing power requirements.
3) Pay attention to data security
The application ecology in the cockpit is becoming more and more abundant, and
its
safety
requirements are also becoming higher and higher.
"
Everyone wants to
protect their privacy
, and the country has also introduced
laws and regulations
related to
data protection
and
personal privacy protection
.
The processing of data security will also,
to
a certain extent, push up
the demand
for
computing power
in the cockpit
.
"
Junlian Chen Yuan, CTO of Chi Heng China
, said.
This article starts with the hardware architecture characteristics of smart cockpit domain controllers, and then discusses the technological development trends of smart cockpit domain controllers from the three dimensions of functional integration performance, product form, and data security.
1. Cockpit domain controller hardware architecture
characteristics
1.1 Cockpit domain controller hardware architecture solution: SoC + MCU
Currently, the hardware architectures of cockpit domain controllers and smart driving domain controllers are very similar, and both are
SoC+MCU solutions.
The main SoC chip of the cockpit domain control controller
is used to run complex operating systems and process big data, such as images, videos, audio and other unstructured data.
但是,现在的智能座舱主控
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即可满足要求。
整车
EE架构由分布式架构向域集中式架构升级,驱动座舱内一个个独立的ECU集成到一个座舱域控制器的DCU上。座舱需要整合的功能越来越多,那么座舱进行功能整合的原则是什么?哪些功能适合被整合进去?
1)在座舱主控SoC芯片的能力边界之内
集成什么样的功能取决于座舱主控
SoC,主机厂或Tier1会评估座舱主控SoC能够支持接入多少路、多大分辨率的摄像头和显示屏
;
同时,也要看被整合功能的安全等级是否能够被座舱芯片覆盖到(不超过
ASIL B),如果主控SoC的
处理能力
或性能
能够覆盖到
此功能
,
那么便可以初步判断,此功能适合作为座舱功能的一个延伸,被集成进去。
2)无需额外新增硬件
如果增加一项或几项功能,可以不用增加硬件,只需要把算法和软件移植到座舱域控制器里面,同时,在成本上还具有一定的竞争力,此功能便适合被集成进去。
北斗星通智联科技产品技术中心常务副总经理董红荣举例说:
“
如果座舱域控
SoC芯片本身不带5G模组,但非要融合V2X功能,那么,开发者就需要单独
找个
5G
模组
装到域控的板子上。这样
可能
既
增加了系统成本,又增加了
设计
难度
,
甚至还导致要
实现的功能与其他域的联系变弱
的
负面影响。在这样的情况下,就没必要去整合
V2X功能
。
”
随着智能座舱
主控
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延伸发展
到了
O
MS,
即
将检测范围从驾驶员扩展到
车内乘客
,
比如
,
检测乘客是否系安全带,下车的时候是否把儿童遗忘在车内等应用场景。当前不少主机厂已经将
DMS和OMS组合起来进行应用。
DMS及OMS功能主要是通过对舱内摄像头数据的实时分析来实现的。现在座舱主控SoC芯片的算力和性能越来越强,不仅能够支持多通道的视频输入能力,还集成有单独的DSP单元。
将DMS/OMS功能融合到座舱,不仅是因为座舱SoC芯片的性能能够覆盖到DMS/OMS ,也是因为把它们融合到座舱,它们便可以和座舱内的其它关联模块更好地进行信息交互。
比如,
伟世通的
HMEye 是基于视线测量的 DMS,除了可以监测
驾驶员的
双手和视线是否在驾驶状态,
它
还可以
让驾驶员
通过眼球的转动
实现
开关广播、调整温度、开启导航等功能,这样
,在驾驶过程中,驾驶员便可以更安全地去进行人机互动。
2.2.3 舱泊一体
泊车融入到座舱也有功能集成化的因素:早期的360环视都有单独的控制器;后来360环视和自动泊车辅助APA进行融合,再升级到融合泊车功能,控制器的性能再次升级;再往后发展,座舱主控SoC芯片具了更强的CPU算力和AI算力,具备了整合泊车功能的条件,于是,也便有了把泊车功能融合到座舱的需求出现。
座舱整合基本的泊车功能:一是可以降本,至少可以把原来泊车的控制器省掉,能够节省一定的物料成本;二是整合到座舱,能够更好地做泊车场景下的人机交互设计,把泊车功能融入到座舱,座舱域控制器会得到更多的泊车信号;最后,座舱上的算力也能得到最大程度的利用。
均联智行中国区CTO陈远解释道:“泊车功能是在停车的场景下才会用到,刚好跟座舱上的一些应用形成时间上的错位 ,比如导航信息显示、行车信息显示都是在行车的时候使用,泊车的时候这些应用基本都处于停用状态,因此,泊车时便可以将座舱上剩余的大部分算力全部用于做泊车的相关应用。”
在不同的自动驾驶阶段,座舱域控设计理念上的不同,甚至会导致产品的形态产生较大的差异。
从技术发展趋势上来看,当前属于人机共驾阶段,即所谓的驾驶辅助阶段。在此阶段,智驾域控和智舱域控还是两个独立的控制器。等过渡到真正的无人驾驶阶段,业内人士普遍认为,随着整车电子电气架构的进一步升级,达到所谓的中央计算平台
+区域控制器的架构阶段,座舱和智驾的功能会高度融合,即舱驾一体。
中央计算
+区域控制架构(图片来源:均联智行对外宣传材料)
根据不同阶段的
EE架构和
主控
SoC芯片的融合能力
,舱驾一体高性能计算平台又会出现不同的形态:
现在有人提到舱架一体
HPC,但它也不是单SoC芯片方案,基本上是由两块板子组成,一块板子跑智能座舱系统,另外一块板子跑智能驾驶系统,但是,这样的结构形式对散热设计和供电设计提出了很高的要求。
某主机厂
EE架构专家告诉九章智驾:“在域控制器阶段,智舱和智驾还是分别采用单独的盒子控制,这在目前来看还是比较好的方案。如果现在要把两个独立盒子的方案改为一个盒子内两块板子的方案,成本应该是可以降低,但在工程上会比较麻烦:比如一盒子里有多块板子,不同的板子用不同的供应商,
中途
发现不好用,换起来会很麻烦;如果是改为一个盒子一块板子的方案,意味着要把太多的功能绑在一块板子上,必然要受多方的牵扯,前期的协调沟通以及后期的更换维护都会比较复杂。
”
某主机厂资深工程师也同意现阶段座舱系统和智驾系统应该相互独立的观点,他说:
“单纯从整车EE架构的演进来看,舱驾融合肯定是大势所趋,但从短期来看,把智驾和智舱结合在一起,纯粹是一种形式上的结合,不是从产品需求的角度分解出来的结果。
“两者面向的应用场景、功能定义、性能边界都不一样,至少从目前来看,我觉得两者没必要去融合,如果硬要把他们捏在一起,不管是芯片的选型,还是外围电路的设计,面临的要求都不一样。那么,在成本和性能的考虑上,我们到底应该倾向于谁?总之,两者融合的方式会给开发者带来一系列设计方面的难题。”
虽然单
SoC芯片的舱驾一体架构方案才能实现真正的座舱和智驾融合,但是座舱和智驾在功能需求、功能安全要求、信息安全要求以及
对不同类型
算力需求
的侧重点
等多个方面的要求是不一样的,如果两者放在一个芯片内去做,系统将会异常复杂,短期内很难有一款单
SoC芯片能够同时满足这样的需求。
现阶段,单
SoC芯片的舱驾一体方案仍面临一些硬件和软件上的问题。具体面临什么样的问题,这里便不多做介绍,感兴趣的读者可查看笔者之前的文章:
“舱驾融合”技术发展趋势分析
,里有比较详细的介绍。
Nowadays, there are more and more cameras in the cockpit, and the functions in the cockpit are becoming increasingly rich. The cockpit system will use a large amount of user data locally, and also needs to maintain real-time data sharing and synchronization with the cloud. The cockpit domain controller is
an important port
for car companies to collect user data and
OTA
in the future
, so
the data security of the cockpit system will be become very important.
So how to protect users’ private and sensitive data from being leaked and illegally used?
4.1 Ensure the information security of the operating system itself
First of all, it is necessary to ensure the information security of the operating
system itself. For example,
when systems such as Android and QNX are started, safe startup verification is required to prevent the system from being infected by viruses. In addition, perform permission control on the operating system and minimize authorization matters to prevent all applications from accessing some very private areas.
Secondly, the communication between controllers requires some secure communication processing, such as
C2C encryption. When a message comes in, it needs to be verified who sent it.
4.2 Data encryption and desensitization
Data collection and data storage not only require user authorization, but also require encryption and desensitization.
Data encryption
-
There is an information security module HSM in the
cockpit
SoC chip, which has a built-in information security encryption engine. After users have these engines and supporting processors, they can build some encryption algorithms on the upper layer, such as the national secret SM2/SM3/SM4/SM9, or some commercial encryption algorithms.
Dong Hongrong, executive deputy general manager of Beidou Star Intelligent Technology Product Technology Center, said:
"The basic framework of cockpit information security is mainly private key encryption + public key decryption.
The transmitted private data, firstly
,
needs to be signed for authorization
;
secondly,
it needs to
be encrypted
.
That is to say,
use the private key to encrypt and
send the data to the other party. The
other
party
can only see the data
after
decrypting it with the public key
.
During the transmission process
,
if anyone else does not have the public key,
they will not be able to
decrypt it even
if
they get the data.
”
Data desensitization
-
When identifying a person, the person's identity cannot be identified, nor can the person's
personality characteristics, such as whether they are male or female
.
Collecting data
may naturally
involve infringement of
other
people's privacy
,
so the data
must be desensitized. Moreover,
a lot of data must
the
terminal
to avoid
the risk of data leakage during transmission
the cloud
In short, data security protection is a very complex project that needs to be considered from all aspects. While protecting your data, you also need to prevent hackers from intruding.
"Around the world, there are many hackers attacking Tesla vehicles to find vulnerabilities, and then report them to Tesla to obtain some rewards. Now many vehicles require penetration testing, which means finding a third-party company. Crack the car to see if it has any loopholes,"
said Chen Yuan, CTO
of Junlianzhixing China
.
5. Cockpit main control SoC chip market structure
At present, the market structure of the main control SoC chip of the cockpit domain controller
has gradually become clear: the middle and low-end market-traditional automotive chip manufacturers are the main players, such as Renesas, TI, NXP, etc.; the high-end market-consumer electronics
chip
manufacturers are Main players, such as Qualcomm, Samsung
, Intel,
AMD
, etc.
Why can consumer electronics chip manufacturers enter the cockpit chip market?
Some industry experts pointed out that the reason why consumer electronics chip manufacturers are able to enter the cockpit field is because the barriers to switching from consumer electronics chips to cockpit chips are not high
-
the technical
requirements
of
the two
are highly similar, and the special requirements of the car grade are mainly reflected. In terms of safety aspects such as lifespan and adaptability to the vehicle environment
, however, it is not particularly difficult for consumer electronics chip manufacturers to pass these vehicle-level certifications.
At the same time, consumer electronics chip manufacturers already have strong enough design capabilities on the consumer side, which can help them
provide car-grade cockpit chips with similar technology and design in the relatively niche automotive field.
Not only have consumer electronics chip manufacturers entered the cockpit field, why can they also firmly dominate the high-end market in the cockpit field?
1) Cost advantage
Consumer chip manufacturers
can maximize
their
production capabilities
on
the consumer side
to amortize the cost of the entire chip design
.
Therefore, when it transfers consumer-side chips to the cockpit field for application, it will be a dimensionality reduction blow to traditional chip manufacturers in terms of cost.
Chen Lishun, deputy general manager of Nobo Auto, said: "SoC chips in the cockpit generally include CPU, GPU, NPU, DSP, etc. These IP designs and authorizations are generally from third-party companies, such as ARM, Imagination, etc. For traditional automotive chips Manufacturers, the licensing fees for these IPs are very high, but for Qualcomm, firstly, many IPs are developed and designed in-house, and secondly, ARM’s architecture licensing fees are much lower than those of some traditional automotive chip manufacturers.”
2) Advantages of chip performance and iteration speed
First of all, the cockpit chips of consumer electronics chip manufacturers have obvious advantages in advanced processes and large computing power.
Secondly, consumer electronics chip manufacturers’ cockpit chips iterate quickly. Consumer electronics chip manufacturers can iterate cockpit chips on the basis of smart consumer electronics chip iterations. The speed of their chip iterations is naturally much faster than that of traditional automotive chip manufacturers.
Basic information of Qualcomm’s fourth-generation cockpit platform (data source: compiled from public information)
Note:
So far, Qualcomm has released a total of four generations of cockpit chips, and these four generations of chips follow the underlying logic of "consumer chips are released first, and smart cockpit chips are modified later."