关于汽车电子架构，对于计算机来讲还是相对比较简单的，行业内也早进行了预判，所以三年前写了四篇文章：XXX
基本涵盖了其发展的技术点。
汽车电子框架演进为三步：分布式（ECU）-》集中式（域控制器）-》中央式（硬件虚拟化+SOA），对应的就是EEA1.0-3.0，如果有人说EEA2.5那就是域融合了一半，还没到中央式。其实中央式是一种理想状态，整车只有一个电路板中枢，当前处于各种安全因素还不能完全使用。例如生物进化中，章鱼有9个大脑，人类有1个大脑，但是都在地球上可以生存，只是章鱼没有人聪明。
汽车电子框架演进说的比较简单，但是在实际操作的时候，面对海量的功能和代码，系统集成的难度直线上升，目前的技术实现又难以跟上了，这里要说一个难度对比PC<手机<汽车<机器人<飞行器，目前也就处在汽车的阶段。
另外随着AI的兴起，特别是LLVM大模型的出现，对于汽车软硬件提出了新的挑战。传统三域融合，到底谁是老大，三国鼎立，谁最后吃掉对方，成为赢家，还难说。本文从域融合角度来分析下，各位在做软硬件域融合的时候也可以参考。
1. 前情回顾
先铺垫点基础知识，回顾下之前的几篇文章的内容。
1.1 分布式架构
ECU（Electronic Control Unit）电子控制器单元：1968 年电子设备首次出现在汽车中，当时大众汽车在大众1600轿车的发动机中安装了电子控制单元 (ECU)，以帮助控制燃油喷射。其是一块独立的电路板，但是随着汽车的发展，汽车里面ECU逐渐增多，达到了100+ 。这么多ECU，汽车软件这时候的构架是分布式的，汽车里的各个ECU都是通过CAN和LIN总线连接在一起，如下图：
1.2 集中式架构
当出现了这么多ECU，首先从成本上来说，这么多电路板，每个电路板上都有芯片，成本非常的高，并且这么多ECU要连线，线束的总长度很大，成本很高。这些电路板很多功能都是一样的，完全可以一个电路板把活干完，但是由于汽车不同零部件的供应商不一样，很难协调。另外这些ECU如果需要交互，在一起协调工作就变的很困难，满足不了智能控制的需求。
为了解决分布式EEA（Electrical ElectronicArchitecture电子电气架构）的这些问题，人们开始逐渐把很多功能相似、分离的ECU功能集成整合到一个比ECU性能更强的处理器硬件平台上，这就是汽车“域控制器 （Domain Control Unit，DCU） ”。域控制器的出现是汽车EE架构从ECU分布式EE架构演进到域集中式EE架构（如下图）的一个重要标志。
对于功能域的具体划分，各汽车主机厂家会根据自身的设计理念差异而划分成几个不同的域。比如BOSCH划分为5个域：
动力域 （PowerTrain）、
底盘域 （Chassis）、
车身域 （Body/Comfort）、
座舱域 （Cockpit/Infotainment）、
自动驾驶域 （ADAS） 。
这也就是最经典的五域集中式EEA，如上图所示。也有的厂家则在五域集中式架构基础上进一步融合，把原本的动力域、底盘域和车身域融合为整车控制域，从而形成了三域集中式EEA，也即：
车控域控制器 （VDC，Vehicle Domain Controller）、
智能驾驶域控制器 （ADC，ADAS\AD Domain Controller）、
智能座舱域控制器 （CDC，Cockpit Domain Controller） 。
1.3 中央式架构
在中央式构架中，只需要一块电路板，汽车的软件都运行在上面，除了需要进行边缘计算的硬件，这样就是一个中央集权的国家，所有的资源怎么分配，各个模块干什么活都是中央说了算，就是官员是中央任职的，中央的政策也会得到贯彻。可以达到动态的协调资源，节省资源，而且为自动驾驶提供极大的便利。就好像可以集中力量办大事，不内耗。
车云计算：这个是更未来的发展，一堆汽车，只需要一个大脑，汽车只是一个接收执行命令的终端。这个估计在飞行器的时代会应用上。在科幻片里面的外星人一般都是有母舰，指挥一堆机器人，基本就是这个思路。
1.4 三域介绍
- 2.1 车控控制域
这个好理解，就是控制汽车上所有的设备，开车的人都熟悉。比如发动机、变速箱、灯具、雨刮、洗涤、门锁、电动窗、天窗、电动后视镜、车钥匙、刹车、车身稳定系统、电池、座椅、空调、方向盘、仪表、各种监测系统等。
软件技术分析：主要是AUTOSAR中间件对这些设备进行抽象，给控制系统提供服务。
硬件技术分析：一个典型就是英飞凌的TC397，或者ARM芯片包含A核和R核。R核就是传统的单片机运行AUTOSAR CP，A核是CPU运行AUTOSAR AP。
- 2.2 智能驾驶域
这个也好理解，就是摄像头、雷达探测达到不撞车，无人自动驾驶。
软件技术分析：主要就是AI算法、图像，雷达信号处理，建立模型，然后学习后做出判断，给重要控制域发信号，控制汽车做出反应。这里的软件严重依赖硬件的计算能力。
硬件技术分析：英伟达的Orin或者地平线的J5等
- 2.3 智能座舱域
这个更好理解，就是看电影，听歌那个大屏，可以有电话、上网、地图、麦克风、音箱、蓝牙，各种app应用等功能。可以理解为一个大个的手机，或者一个平板电脑。
软件技术分析：就是一个安卓手机类型的系统，本身技术很复杂，但是有手机公司很多，都是开源代码，难度不大。
硬件技术分析：这个就是手机CPU最常见的就是高通，基于ARM的，当然华为也有基于ARM CPU的芯片海思但是被卡脖子了。其他瑞芯微、全志什么的也可以用。
2. 域融合的技术基础
2.1 多核SoC
下面列举一些使用多核的优势：
- 性能：计算机芯片的发展早已经进入瓶颈，提高性能的方法不再是提高主频，而是就是把芯片做大，一个芯片上集成更多的核心来进行并行计算。视频编码、3D渲染等场景中，多核可同时处理不同帧或像素块，加速任务完成。AI任务中处理矩阵也是需要并行计算的。
- 异构多核：结合CPU、GPU、NPU（神经网络处理器）等，实现任务分流。如手机SoC中，CPU负责通用计算，GPU处理图形渲染，NPU加速AI推理，整体性能远超单核方案。多核SoC可根据任务需求动态分配核心，低负载场景：仅启用少量核心（如手机待机时使用低功耗小核），降低功耗。高负载场景：激活全部核心（如游戏时启用大核+GPU），平衡性能与能耗。
- 功耗：散热的挑战，主频做不高，只能多核并行。
- 通信：对于复杂系统，板级通信比较慢，消耗也高，而NoC片上通信则又快又好。
- 可靠性：多核，特别是异构核配合工作，相互直接隔离，安全性提高
多核SoC可根据任务需求动态分配核心： 低负载场景：仅启用少量核心（如手机待机时使用低功耗小核），降低功耗。 高负载场景：激活全部核心（如游戏时启用大核+GPU），平衡性能与能耗。 实时任务场景：在自动驾驶、工业控制等场景中，多核可确保关键任务实时处理：
另外根据用户的需求对芯片进行定制，特别是AI芯片中，基本就是软件定义硬件，软硬协同的模式去工作的： 小核（如ARM Cortex-A55）：低功耗设计，适合后台任务。 大核（如ARM Cortex-A78）：高性能设计，适合前台应用。 专用核心（如NPU、ISP）：针对AI、图像处理等任务优化，能效比通用核心更高。
以特斯拉FSD芯片为例，其有3个A72核心簇，一个簇4个核，共有12核，NPU也用了两个，每个NPU中又有无数的计算核心。
参考Orin中也是无数的核心。
2.2 Hypervisor
基于虚拟机Hypervisor技术，可以将不同的ＯＳ跑在一个主控芯片上。运行不同的ＯＳ来满足不同的需求，比如上图中Classic AUTOSAR可以用做汽车控制、Android用于影音娱乐、Linux AP QNX综合性的系统也可以运行在上面。然后硬件资源在各个OS中进行动态分配，共用就可以节省硬件资源，充分的发挥芯片的性能，降低硬件成本。
多OS运行在一个电路板上，也可以减少OS间交互成本，减少汽车的布线，降低这方面的成本。目前最新的智能汽车上的布线有３－５公里，首先成本巨大，其次线束之间或者受外界的电磁干扰，如果信号出现一个位反转，或者那条线坏了将的致命的，复制的硬件系统同时也是极其脆弱的，已经限制了其发展。
虚拟化技术是一种将计算机物理资源进行抽象、转换为虚拟的计算机资源提供给程序使用的技术。这里所指的计算机资源，就包括了 CPU 提供的运算控制资源，硬盘提供的数据存储资源，网卡提供的网络传输资源等。
对硬件虚拟化技术的需要注意两方面：
（1）硬件资源的分区与隔离
原本需要多个ECU实现的多个功能都整合到域控制器上后，势必会导致域控制器的软件更为复杂，这势必会导致整个软件系统的出错概率增加、可靠性下降。而且多个应用混合运行在同一个操作系统上，经常会出现故障传播（Failure Propagation），也就是一个应用出现问题后，会使得整个系统底层软件和硬件都处于紊乱状态，从而导致其它原本正常的应用也会开始出现故障。因此通过硬件虚拟化技术对硬件资源进行分区（Partition），使得各个功能对应的软硬件之间互相隔离（Isolation），以此保证整个系统的可靠性。
（2）支持混合安全等级
另一方面，在汽车电子系统中，通常不同的应用其对实时性要求和功能安全等级要求都不同。例如，根据ISO 26262标准，汽车仪表系统与娱乐信息系统属于不同的安全等级，具有不同的处理优先级。汽车仪表系统与动力系统密切相关，要求具有高实时性、高可靠性和强安全性，要求运行在底层实时操作系统上（比如QNX）。而信息娱乐系统主要为车内人机交互提供控制平台，追求多样化的应用与服务，以Linux和Android为主。为了实现混合安全等级的应用，实现不同的操作系统运行在同一个系统上，这就需要虚拟化技术的支持。
车载硬件虚拟化技术的核心是Hypervisor，它是一种运行在物理服务器和操作系统之间的中间层软件，可以允许多个不同虚机上的操作系统和应用共享一套基础物理硬件。当系统启动时，首先运行Hypervisor，由它来负责给每一台虚拟机分配适量的内存、CPU、网络、存储以及其它硬件资源等等（也就是对硬件资源进行分区），最后加载并启动所有虚拟机的客户操作系统。
一句话总结一下基于Hypervisor的优点：它提供了在同一硬件平台上承载异构操作系统的灵活性，同时实现了良好的高可靠性和故障控制机制, 以保证关键任务、硬实时应用程序和一般用途、不受信任的应用程序之间的安全隔离，实现了车载计算单元整合与算力共享。
承载计算和控制的底层硬件从分散的多个ECU集中到多核、异构的高性能域主控处理器后，相应的软件也会从分散向集中、从简单向复杂、从静态向动态进化。下图显示了以后汽车域控制器上的典型软件架构：
1)操作系统层：
最底层利用Hypervisor虚拟化技术对硬件资源进行分区(partition)，从而可以在每个虚机运行不同的操作系统。比如在上图中，虚机VM1中运行兼容POSIX实时操作系统标准（比如PSE 52）的RTOS，RTOS上通常要承载功能安全相关的应用和服务；虚机VM2中运行Linux这种完全POSIX标准的分时操作系统，上面通常运行管理相关的功能和服务；虚机VM3中运行的可能是原来在ECU上运行的Legacy应用。
2)中间件层：
操作系统是不做任何与“车”特定相关工作的。为了让域主控处理器在汽车场景下使用，需要有很多软件或者中间件用于让域控制器满足汽车的电源管理标准、网络管理标准以及诊断标准等；车载域控制器需要比一般工业嵌入式系统有更高的可靠性要求，这样就需要在计算机OS基础上再附加对存储和通讯等各方面的安全保护和容错机制；同时，位了让车载域控制器能够在整车EE架构下运行，还需要提供时钟同步、日志跟踪以及服务管理和发现等功能。AdaptiveAutoSAR规范定义了运行在Linux或者完全兼容POSIX1003.1标准RTOS上的这一层与“车”相关的中间件标准；而传统运行在POSIX子集的RTOS或者BareMetal模式的中间件规范则由Classic AutoSAR标准定义。
3) 应用层：
上层应用基于AutoSAR标准的中间件来进行开发。随着汽车智能化和网联化相关的功能越来多，上层应用软件也越来越复杂。为了降低单个应用的整体复杂性，我们可以借鉴互联网的面向服务架构（SOA）的软件设计思想，将一个复杂应用拆分多个服务。每个服务实现得尽可能小，尽量实现成无状态方式的服务，以利于整个系统的开发、测试和软件重用。服务与服务之间通过事件或者消息总线（发布/订阅工作模式）来进行通信，并降低互相之间的耦合度。通过服务配置来管理服务之间的依赖性、服务的部署和启动，以及服务的健康状态检测等。
3. 三域融合之三国杀
3.1 三域护城河
-
座舱域：基本是延续手机而来，高通的天下，护城河就是：量大价格便宜，手机芯片同价。
-
车控域：延续传统汽车而来，英飞凌等闭源软硬件的天下，护城河就是：安全，经过时间和装机量的验证，商业软件可靠性强，有功能安全认证，被国外掌控，溢价比较高。
-
智驾域：延续PC上的GPU显卡，基本英伟达的天下，护城河就是：AI core，一个芯片上集成大量的AI运算核心，芯片面积巨大，为了完成AI任务需要的异构核心众多，成本高。
3.2 降成本角度
首先三域短期内由于护城河的作用，谁也干不掉谁。但是从降成本的角度（最有动力）可以先行：
- 座舱域芯片比较便宜，肯定要保留
- 车控域溢价高，必须要干掉
- 智驾域成本高，再加几个核也增加不了多少钱
-
首先从低端车的路线出发，那成本高的AI芯片肯定上不了了，已经有了高通的座舱芯片，那成本有限可以稍微再加一个AI的功能，顺带把溢价高的车控给干掉就好了
-
从高端车的路线出发，AI肯定是最重要的，成本贵就贵没办法，多加几个核顺带就把车控给解决了，为了AI稳定性，座舱便宜的芯片也没必要替换，暂时用着。
这时候车控域就要发言了，都想干掉我，别忘了我的护城河：安全。这一套国外的软硬件离开了，就不行。座舱和智驾一看，我干不掉你的芯片，我把你的电路板先干掉，让你的车控芯片在我的主板上运行，这样在一块电路板上，也缩短了距离，减少布线，外设可以共用省下一些成本。然后把你的业务不紧要的，不需要那么安全的慢慢往我的上面移，逐步蚕食，慢慢融合。
例如单独的车控芯片还是TC397+Vector的AUTOSAR，座舱或者智驾芯片里面，搞出来几个异构R核或者RISCV核运行开源或者自研的AUTOSAR软件，这个不费钱啊，先用起来，稳定后逐步替换。
3.3 座舱的逆袭之路
从手机而来的芯片量大便宜，以高通为代表，但是高通也想抬高身价去挣钱啊，那必须得上AI，通往高端的逆袭之路。
目前的算力100 TOPS只能做到智能泊车，只能算舱泊一体。概念不能搞错了。目前智能驾驶都需要1000 TOPS以上的算力了，都是一颗不够，多颗来凑的。
燕雀安知鸿鹄之志哉，看看高通的规划（640 TOPS）：
3.4 智驾的顺手牵羊
以地平线J6为例，其集成了MCU用于替换TC397，客户用不用不知道，但是已经有这个能力了。
3.5 车控的坐吃山空
这点可以说是有个老顽固，不过它有它的道理，那就是追求理想主义的安全，认为自己不可替代，新兴的技术那那都是缺点，根本不能用在车上，迟早要出问题。其实这就是偏执、老套，像一个年龄大的人也拼不动了，就守着已有的底盘，过一天赚一天。
4. 舱驾一体
三域，这里直接忽略了车控，变两域了，车控真是被无视了啊。主要还是目前AI太火了，用户都关注座舱和智驾里面的AI，而这两部分AI也需要进行融合，共享资源。
4.2 舱驾一体介绍
当前，在域控制器集中式架构阶段，智能驾驶和智能座舱是车载AI芯片的两个重要应用领域。充分挖掘在这两个场景下的应用需求是车载AI芯片厂商的核心驱动力。新算法模型的引入，以及整车EE架构的发展，都会对车载AI芯片的迭代产生较大的影响。
1）不管是智能座舱，还是智能驾驶，所应用的算法模型都在不断地变化和演进，尤其是在智能驾驶领域，更为明显，从先前的CNN网络演进到现在的BEV+ Transformer+OCC网络，促使车载AI芯片向适应更新的算法模型的架构方向进化。在智能座舱领域，生成式AI大模型被逐渐引入，用来强化舱内的AI视觉和语音等人机交互体验。基于“软件定义芯片”的理念去设计AI芯片。
2）车载AI芯片的迭代与整车EE架构的演进相互协同发展。在域控制器集中式架构阶段，车载AI芯片基本都是针对特定功能域下的应用场景去设计和开发，比如，智能座舱或智能驾驶。随着整车EE架构进入跨域融合阶段，“舱驾融合”成为重点的关注方向，芯片厂商需要兼顾智能座舱和智能驾驶的应用需求，设计出一款高度适配“舱驾一体”的车载AI芯片。
4.2 舱驾一体面临的挑战
- 硬件层面：
- 需要将多个系统和功能融合在一起 ，并且还要能兼顾不同应用场景的需求 —— 有的重视响应，需要及时反馈；有的侧重安全，需要高稳定可靠性；有的既要性能强，还要兼容软件丰富，通用性好。
- 理想型的舱驾一体SoC需要在支持智能驾驶全功能高负荷运行的时候，还要支持座舱内的用户交互和娱乐系统，这需要舱驾一体SoC单芯片的总性能大于等于单独的座舱SoC和智驾SoC这两颗芯片性能之和，两边的DRAM系统最好是分开的，互相不影响内存带宽和访问延迟；另外，在GPU资源的使用上，座舱的娱乐系统和智驾系统最好也完全分开使用；如果AI计算使用专门的NPU，也要考虑是否被两套系统共享。
- 这样的芯片，成本和功耗自然都不会低，而且复杂度很高，出问题的概率也会增加。而且，座舱和智驾的功能安全需求等级不一致，如果两边都做成满足智驾水平的功能安全等级，必然会抬高成本。如果两边按座舱的标准去做功能安全，智驾系统则存在安全性风险。
- 软件层面：
- 座舱和智驾如何进行安全有效的隔离？智驾域的特点是高可靠性和低时延性；而座舱域更注重娱乐和用户体验，需要更丰富的功能和较高的OTA频率。如何把两个系统能进行很好的整合，保证不同任务的优先级情况和不同功能安全等级的实现，这都存在很大的挑战。
- 目前座舱和智驾中相关模块对功能安全的要求：智能座舱中控娱乐模块需要达到ASILA等级，仪表模块需要达到ASILB等级；智能驾驶泊车模块至少需要达到ASILB等级，行车模块需要达到ASILD等级。那么芯片底层的加速器资源针对这些不同功能安全等级的应用如何进行有效隔离是很棘手的问题。
- 行业技术标准
- 高阶自动驾驶尚处于演进过程中，业界没有统一的标准：传感器方案没有统一，感知的数据格式不一致，那么，它对芯片处理架构的需求不一样
- 舱驾一体落地需要行业标准的推动，甚至需要强迫一些厂商逐渐把他们的软件架构打开。制定行业标准的目的就是把大家的利益统一起来，谁不跟着行业标准走，谁就会吃亏、掉队，甚至面临淘汰，这样才能逐渐推动整个行业的发展和进步
- 组织架构方面
- 针对舱泊行一体方案，研发部门的分工问题目前虽然已经被大家普遍意识到了，解决问题需要芯片厂家、主机厂以及一级供应商的通力协作。目前，在实施层面，主机厂的座舱和智驾项目大部分还依然是由两个独立的部门去完成，怎么能够跨部门把这个项目去落地， 需要有更符合方案需求、更具竞争力的产品以及全方位的技术支持来一起推动方案落地量产。
- 目前大部分座舱和智驾系统分别还需要选择多个不同的供应商来完成，如何提供有竞争力的产品，在单一芯片上实现座舱、泊车以及行车辅助驾驶功能，帮助整车厂优化成本，降低研发投入，提升盈利；给终端消费者带来更优的用户体验，是芯片厂家和整车厂商所共同面对的机遇与挑战。
4.3 舱驾一体的演进
舱驾一体的发展路径应该是从One Box 到One Board，再到One Chip，循序渐进式的发展，不太可能一下子就跨越到单SoC芯片舱驾一体的‘完美’解决方案。比如，先通过One Box或One Board的方案，先试着去解决组织上的问题，把开发过程中碰到的问题以及各方的职责先梳理清楚，把该踩的坑先踩一遍。
有一个问题：车上有几个borad？
如果是三域那就是三个？其实不对，还有一些零散是ECU是漏网之鱼，每个ECU都是一个独立的board。这些ECU主要负责座椅、门、窗、灯、方向盘、安全气囊、空调、充放电、动力、悬挂、刹车等。这些需要及时相应的部件，目前实车上还无法进入集中式域里面，而是作为区域控制器。
重要的区域有专人（藩王）镇守，那后续为了降本，那中央就需要削藩，在功能层面，中央控制器会先集成已经成熟稳定的功能，慢慢再集成更高阶、更复杂的功能。
目前，L2及以下的辅助驾驶功能，倾向于直接集成到座舱的SoC芯片去完成。L3以上的高阶智能驾驶方案，倾向于用更大算力的智驾SoC芯片去实现
目前，辅助驾驶在市场的渗透率也才30%左右，NOA功能的渗透率更低。如果有企业率先在市场上把舱驾一体方案推出来，并且切实降低了成本或在不增加用户成本的基础上，将原本中高端车型的智驾功能扩大到中低端车型，辅助驾驶的渗透率将会更快的提升，整个行业都会受益。新的事物进入到市场上，肯定要有一定的导入期。只要方案有价值，并且是可靠的，方案的全行业落地实现无非就是时间上的问题。
举一个高通的轻量级单SoC舱驾一体方案例子：
高通Snapdragon Flex SoC 参考方案示意图（图片来源-高通）
- 创新的硬件架构：满足跨域多场景需求，能够基于虚拟化技术将异构资源进行合理和安全地隔离分配 —— 把不同类型的算力，根据不同场景，以不同规格和安全要求进行灵活的搭配和组合。
- 高算力需求：实现城区NOA等高阶智能驾驶功能，对于芯片的AI算力需求也在逐渐增加，有效AI算力可能至少需要在200TOPS，同时还需要满足座舱内影音娱乐所需要的强大的渲染能力和通用算力需求，因此对于GPU和CPU的算力资源也必然会有较大的需求。
- 具备较为丰富的外设接口：之前座舱和智驾SoC芯片分别对应有各自独立的外设接口，现在两者进行整合后，相当于要在这一颗芯片上预留好之前所有的接口。比如，CES 2024 上，畅行智驾正式推出了面向中央计算的单SOC 舱驾融合域控制解决方案“RazorDCX Tarkine”。面向自动驾驶，其支持11V5R12USS接入，预留12路CAN/CANFD 接口，并提供8路车规级以太网接口；面向座舱，支持多屏互动、音频放大器、车载音频总线（A2B）以及面向媒体的系统传输总线（MOST）接口与连接。
总之，实现高阶的单SoC舱驾一体方案，对SoC芯片的要求会更高：需要在设计芯片时，就能规划好座舱和智驾对CPU、GPU及NPU等各种算力的类型的需求，并在可行的工艺制程下，全面灵活地实现性能、功耗和成本之间的最佳平衡。
4.4 车载AI芯片的特点
驾舱一体，需要一个强有力的AI芯片去实现中央式的域融合，下面是一些研发过程中的指导：
- 芯片的软件生态要好
- AI开发套件是软件生态里比较重要的一部分，通常包括算子库、AI工具链等。什么样的芯片才算是“好用”的芯片？一般来讲， 首先，算子库丰富；其次，工具链好用。“工具链好用表现在两个方面：第一，编译部署的时候，要能够把客户需要的算子都能署下去，不但能支持，并且性能还要好。第二，不但基础设施要好，而且在基础设施之上的那些管理调度系统也需要做好，这是软硬结合的过程。
- AI计算架构把RISC-V和DSA结合起来，解决了在传统AI加速器上所面临的通用性和专用性的矛盾问题。基于软硬结合的前瞻理念，我们看到AI编译技术对大模型在端侧落地的支持要好。
- 软件生态好用，能支撑好合作伙伴和客户的开发所需，应用文档要充分完善，参考设计和代码丰富准确，有相应的社区或者足够详细的指导文档能帮助用户自行快速上手。最大限度的降低用户的学习成本和业务的迁徙代价。
- 软件生态兼容，需要一个长期稳定的软件框架和接口，能够尽可能的做到向下兼容，帮助用户的存量代码的价值在后续芯片的升级时也能得到继承。 2.芯片的适配性
- 硬件层面，芯片的适配性包括传感器的适配，配套外围电路的适配，例如存储芯片（如LPDDR、NOR Flash）、通信芯片（如以太网交换芯片）、音视频数据接口以及相关处理芯片（如解串行芯片）等等
- 软件层面，芯片的适配性包括与底软、中间件以及上层算法层面的适配；
- 通讯层面，主要是芯片与总线的适配，涉及到CAN、以太网等总线，即芯片和其它组件的之间的通信和数据交换是否适配。
“面向从低到高的全阶智能驾驶场景，征程6基于统一芯片设计理念进行平台化设计，秉持同代一致、代际兼容、高度集成、系统最优（DTCO，STCO）等理念，使其具备统一的软硬件技术特性，包括统一硬件架构、统一工具链和统一软件栈，进而提供平台化的系列计算方案，助力客户降本增效，缩短智驾系统开发周期，打造系统成本更优的智能驾驶方案。
后记：
面对这么复杂的情况，需要整合软件、硬件、汽车需求等因素，可能只有整车厂有能力去做到，华为、小米，还有新势力里面可能有一半能成功，以及软件定义硬件的芯片公司有些优势，其他在这条路上应该都会比较难。
