德国人卡尔·本茨(1844-1929年)于1885年10月成功研制世界上第一辆汽车,采用一台两冲程单缸0.9马力的汽油机。此车具备了现代汽车的一些特点,如火花点火、水冷循环、钢管车架钢板弹簧悬架、后轮驱动、前轮转向和制动把等机械部件。在后续的很长时期内,汽车的发展和革新主要集中在发动机、底盘车身等机械和电气领域。
汽车的起源来自于机械工业的发展，早期的车型是一个纯机械产物。汽车脱胎于马车，真正开始大规模的普及起源于1908年福特采用流水线生产T型车，将汽车从作坊产品带代入流水线工业化时代。
随着对于汽车功能要求的提升，机械部件逐步被功能更为完善的电气部件取代。在这个过程中，由于电气化是渐进式替代原有机械部件，因此引入的电气化产品都相互独立。随着汽车开始普及，出于高速安全角度，汽车上原本使用的乙炔灯逐步开始被电子照明系统所取代。
1954年，斯图加特车队中博世研究用车搭载不同的大灯和喇叭
1913年，梅赛德斯10/25HP搭载的博世照明系统，配备发电机、大灯和电压调整器
1927年，博世研发柴油喷射系统
1932年博世首款量产车载收音机
CAN通讯是一个伟大创新
我们先来看看最原始的发动机和变速箱的交互。
吃瓜群众：这两个ECU之间也就5根线不多啊，不就比CANBUS多了3根线么？
机哥：不着急，我给你看看4个ECU之间的通讯是怎么样的。
1、首先空调和柴油发动机这块相对简单一些，空调请求发动的命名，然后柴油机发动机会许可给到空调控制器，同时把冷却液温度传递给空调这边。
2、柴油发动机和变速箱的控制就有许多通讯的内容，比如变速箱需要把负载情况档位传递给发动机，发动机需要把驾驶人的控制逻辑传递给变速箱。
3、汽车ABS这块要动作，需要把行驶速度给到发动机，发动机需要把转速界限值给到ABS这块，同时ABS这块也要同变速箱纠缠不清，需要变速箱把档位信息给到ABS，ABS把速度信息给到变速箱，最终综合各方面的因素限定调节，在决策是否输出ABS动作。
总线功能有较高的可靠性和功能安全性，能大大减少因插头连接和导线所引起的故障。因敷设导线减少而降低装配成本，并减轻线束重量。因采用较小的控制单元和插头而使空间节约下来，并使安装和修改更加容易。控制器之间的数据传输较快。系统诊断能力更强。
越来越多的电子电气系统出现后，相互间的通信冗杂、线束的难度快速提升，新的架构呼之欲出。比如，如何完成这些系统内ECU之间的通信成为挑战。为解决这个问题，博世在1986年开发出了CAN总线，用来对ECU的数据进行传输，1991年世界上首款基于CAN总线系统的量产车型奔驰500E正式亮相。
而真正影响电气架构本质的东西，也就是冰山以下的东西，首先是功能架构。也就是这个电气架构要承载多少功能，比如所谓的L3/L4，不仅仅是等级的区别，更是它的功能和安全角度上不一样。还如一个普通的机械式的汽车仪表和一个12.3寸的全液晶的仪表，它们也不仅是表面上的不一样，更是本质上的功能不一样，12.3寸可以显示各种各样的信息，这是普通仪表不具备的。把这些功能搞清楚了，你想要做什么样子的功能，然后这些功能在整个架构下如何分配，他们之间如何关联，这些才是架构设计要优先考虑和解决的问题。随着功能的不断增加，电气架构也需要与之匹配地不断演进。
出现背景
为了统筹考虑汽车的电子电气系统原理设计、中央电器盒的设计、连接器的设计、电子电气分配系统等设计，德尔福公司首先提出了整车电子电气架构（EEA）的概念。传统的电子电气架构是一种分布式方案，根据汽车功能划分成不同的模块，如动力总成、信息娱乐、底盘和车身等。这种分布式方案最大的特点是功能划分明确，可以通过预先的设计来严格明确界限，所有历史工作的继承性也很强。
1)传统EE架构中，当增加一个新功能，只是简单地添加一个ECU，增加电线和线束布线，加大系统复杂性，OEM集成验证更困难。如果需要实现较为复杂的功能，需要许多个控制器同时开发完成才能进行验证，如果其中任意一个控制器出现问题，可能导致整个功能全部失效。
2)在传统分布式EE架构之下，ECU由不同的供应商开发，框架无法复用，无法统一，同时OTA外部开发者无法对ECU进行编程，无法由软件定义新的功能，无法进行硬件升级；
正式提出
当前，车企正在应用的第一类E/E架构，采用分布式设计，分为模块化和集成化两个阶段：
a、模块化阶段，汽车的每个功能拥有独立ECU，现在大多数汽车处于该阶段；
b、集成化阶段，车辆的设计开始进行功能集成，进而带来ECU的被集成。
今后，车企将采用第二类E/E架构，采用（跨）域集中式设计，分为集中化和域融合两个阶段，如大众由搭载来自200个不同供应商的70个ECU“减少到三台中央车载电脑”来减少整车软件的复杂性：
a、集中化阶段，指开始出现了域中心控制器；
b、域融合阶段，对应地开始出现跨域中心控制器。特斯拉Model3正是域融合阶段的代表车型。
未来，E/E架构将发展为第三类架构，即车辆集中E/E架构，分为车载电脑和车-云计算：
a、车载电脑阶段，采用的是车载电脑和区域导向架构；
b、车-云计算阶段，车辆功能在云端。
如果我们按照整车三大架构来进行分析：
根据安全性排序：车身底盘动力域>自动驾驶域>座舱域，
而车身动力域由于安全性要求最高，并且和底层控制深度耦合，因此无论是产品形态还是产业链的格局，相对变化都较小。而自动驾驶域因为对算力要求远超从前，因此产业链逐步增加了新的供应商。
计算集中化后的优势：
1）硬件架构升级：
a.减少内部算力的冗余，避免ECU数量膨胀，减少设计算力总需求；
b.传统分布式架构难以实现实时交互，集中式架构可以统一交互，并实现整车功能协同；
c.集中式架构后，线束缩短，整车质量减轻。
2）软件架构升级：
a.分布式架构软硬一体，整车企业并没有权限去维护和更新ECU，因此无法通过后续OTA更新解决问题。变成集中式架构后，软硬解耦，可以通过系统升级(OTA)持续地改进车辆功能，软件一定程度上实现了传统4S店的功能，可以持续地为提供车辆交付后的运营和服务；
b.整体形成感知层后，采集的数据信息可共用。软硬解耦后，可实现多个应用共用一套硬件装置，有效减少硬件数量。
一句话总结就是既降低了成本，又提升了效果。电子架构变迁的核心驱动力是降本，毕竟都是商人，无利不起早。
CAN网络无法满足目前车载智能化的一个信息传递的需求，举一个最简单常见的例子，现在的车载普通导航地图一般都需要1-2个月更新一下数据，因为地图厂家会根据目前的数据进行更新，比如某个地段新修了一条道路等等，那么整个全国高清地图包的数据基本上是8G，因为地图不像其他数据可以差分包更新，也就是这个道路更新了这一条，我就把这条道路的信息传递过来，是整个地图包是一体的数据，所以数据量不少。
但随着汽车“新四化”的发展，ECU数量，ECU的运算能力需求都呈现爆发式增长，尤其是ECU与ECU之间对全双工通讯有了强烈需求，继续使用CAN总线连接不仅将造成汽车电子系统成本大增，更无法满足高性能处理器实时高速双向数据交互的需求。
下图就是目前最新使用车载以太网的架构，是不是有疑问，为什么还有can网络，不是所有的地方都是以太网呢？
比如车窗控制，这些非常简单的控制单元，也没有音视频大量数据传输，就是简单信号控制类的，当然车载以太网也可以实现，就有点大材小用了，用can或者lin网络非常低成本，高性价比就可以解决的方案，就没有必要为了高大上去上以太网，毕竟成本才是王道。
3）多子网络阶段，将多个子网络进行整合，车载以太网作为车载骨干网，集成动力、底盘、车身、娱乐等整车各个域的功能，形成整车级车载以太网络架构，实现车载以太网在车载局域网络上的全面应用。
域控制器可以完成各自域内协调工作，便于软件管理和车辆变形。域集中和中央计算平台架构使原来分散的算力集中化，在降低架构复杂度同时提高了系统算力，软硬件解耦让汽车软件实现即插即用，具备可持续迭代升级的能力。
我们就来看看特斯拉的电子电气架构的变化。
我们先看下基本面
1、大量使用CAN/LIN用作主干网、支干网，速率包括125kbps、500kbps；Ethernet也有使用，但仅用于IC与CenterDisplay之间以及诊断接口；
2、较为明显的域划分，包括动力域PowerTrain、底盘域Chassis、车身域Body以及一路低速容错BodyFT；
3、72个控制器ECU节点，其中44个CAN节点、28个LIN节点与中大型豪华电动轿车相符。
...如果只有上面这些是不是有点平平无奇？我们继续。
4、ADAS模块横跨PT与CH，因为高级辅助功能对动力和制动转向的实时性需求；
6、量产车型仍留下诊断接口？？？调试接口在试制、下线以及售后都可以发挥不小的作用，特斯拉为了追求极致的效率可以说是...很棒了；
说到以太网，我们有注意到特斯拉使用的是传统以太网，可能是CenterDisplay投射到IC地图的需求，而较短的走线则抵消了EMC干扰及价格重量的劣势。
7、CenterDisplay横跨多个网段，充分接入更多节点，集成了GW、HU、T-BOX...等诸多功能，俨然汽车大脑级的存在；这种设计理念搁现在可能没啥，但是别忘了，这是6年前横空出世的ModelS！加上2~3年的车型开发周期也就是说至少8年前特斯拉的设计！而自行开发的决定则和创始灵魂艾伯哈德、施特劳贝尔的背景一脉相承。
按照博世的EEA（ElectricElectronicArchitecture，电子电气架构）进化，针对CenterDisplay来说ModelS可是一步跨到了VehicleComputer的层级！
当然特斯拉愿不愿意往上靠是另外一回事了。
...不知道大家看到ModelX的拓扑与ModelS对比什么感觉？
在我看来就一个感觉：这就是一个模子里面出来的呀！
我们来看下，
1、4个网段、主要通信类型CAN/LIN都没变吧；
2、主要节点都没变化吧（这个是废话了...）；
4、ThermalCAN单独接入一路到CenterDisplay&Gateway;
5、其他的诸如座椅控制器、车门控制器的增多主要用于二排联动、主驾电吸门等控制逻辑；
6、诊断接口继续发扬...增加了ThermalCAN与FalconCAN；
7、注意跨网段的趋势，比如中央车身控制器CentralBodyControlModule横跨底盘Chassis、车身低速容错BodyFT以及车身Body，这一点在Model3上面会大爆发。
总体来说虽然ModelX相比ModelS车型有跨越，但是针对电子电气架构来说没有太大的变动，可以说是平台的变种。
Model3的拓扑...我是谁？我在哪儿？？？
1、动力域？车身域？娱乐域？不存在的，映入眼帘...emmm夺人眼球的是3大块：一个是自动驾驶及娱乐控制模块Autopilot&InfotainmentControlModule，二个是右车身控制器BCMRH，三个是左车身控制器BCMLH；
2、...你们猜的没错，这三个控制器都是特斯拉自行开发；
4、右车身控制器BCMRH，初步判断集成了自动驶入驶出AP（AutomaticParking/AutonomousPullOut）、热管理、扭矩控制等；事实上，这里正是特斯拉厉害的地方：硬件抽象（硬件和软件的分离）。我们回头看下S和X：热管理几乎都是独立的控制器模块，扭矩控制几乎都运行在CenterDisplay中，也就是说之前的code完美地移植到了3的右车身控制器BCMRH中！
有没有似曾相识的感觉？
上图是在电子电气架构方面一向激进、开放的宝马规划的下一代EE架构。殊途同归。
5、左车身控制器BCMLH，与右模块相同的是横跨多个网段，不同的是左模块负责了内部灯光、进入部分；事实上这里面有个特斯拉的思考那就是分区域的控制模块，举个典型的例子：驻车卡钳（没错EPB的功能...由左右车身控制器瓜分了）；
7、右车身控制器BCMRH横跨DriveInverter与底盘Chassis，为刚升级的赛道模式「TrackMode」提供了架构支撑；
8、关于冗余设计，可以先看下特斯拉自动驾驶技术路线，基于视觉的渐进式路线，传感器方面没有选择LiDAR、更多的毫米波雷达，而在底盘域的关键传感器除了扭矩（疑似）有双路采集，其他的都没有；事实上其电子转向助力模块PowerSteeringECU像极了博世华域的PP3.2平台；再加上iBooster、ABS的通信备份...往大了可以说特斯拉Model3做好了制动、转向的冗余设计；
9、关于星型网络，我的看法是单从架构拓扑无法评判，得看具体的功能分配；事实上，自动驾驶及娱乐控制模块Autopilot&InfotainmentControlModule、右车身控制器BCMRH以及左车身控制器BCMLH亦可以看做网状网络，而在接口都具备的情况下功能的分配（互为备份）则仅仅是软件的问题，而软件正好是特斯拉的强项；
前面说了特斯拉的电气电子架构，我们再来看看model3的特点：
①继电器体积大，不容易提升集成度；
③继电器是机械件，相对于MOSFET故障率更高；
⑤继电器在接通和断开时会有声响，对整车的NVH会造成一定影响；
⑥继电器在触点老化后容易出现拉弧，致使其EMC性能也不如MOSFET。
而model3的设计思路与此并不相同，其采用了大集成的概念，即把一个区域范围内可见到的控制器都集成在一起，也就是主控制器把小控制器统统吃掉，融合成一个超大控制器。这样做的好处也很明显，就是大大降低了单车成本。传统车中虽然子控制器被标准化了，子控制器确实也在新车型上省掉了开发成本，但单车的成本并没有被压缩；而特斯拉的思路是把子控制器融合掉了，因此可以把子控制器在MCU、SBC、Housing等方面的单车成本节约下来。所以传统车思路省下来的是新车型的开发费用，而Model3省下来的是单车成本，各有优劣势。
而Model3的思路并不是这样的，从其控制器的形状及布置位置可以看出，特斯拉采用的是布置优先的策略，即控制器的工程师确定控制器所需要的面积和高度，由总布置工程师进行分配，因地制宜，只要面积够用，方便布置，不管其形状被分配成什么样子，因此可以看到Model3很多控制器都是不规则形状的，这样做大大提升了整车集成度，虽然控制器的形状个性，但却与车辆结构整齐划一。
简而言之，就是不同区域的线束通过控制器不同的PIN针连接或耦合在一起，比如座椅线束中的某根线要和仪表台的某根线连接在一起，二者属于不同的线束模块，但却都和左车身控制器相连，因此左车身控制器就会做一对Passthrough，将这两个线束模块中需要连在一起的线束最终连在一起。
特斯拉电子电气架构变化总结：
汽车电子电气E/E架构加速向域控制、中央计算平台架构迁移。博世认为汽车电子电气架构演变路径为分布式、域集中、中央集中式。传统汽车分布式架构缺点越来越明显，高档车使用100~200种不同ECU，汽车的EEA中搭载了各种功能不同的ECU进行协同运作为驾驶员提供各种功能，打造中央集中式EEA架构的车载计算平台，面临“功能安全、实时性、带宽瓶颈、算力黑洞”等多种挑战。目前车厂逐步将一些ECU功能合并到一个ECU中，减少控制节点，控制器向“域”集成方向发展，目前车辆上主要有动力域、车身域、自动驾驶域、底盘域和信息娱乐域。
域控制器可以完成各自域内协调工作，便于软件管理和车辆变形。域集中和中央计算平台架构使原来分散的算力集中化，在降低架构复杂度同时提高了系统算力，软硬件解耦让汽车软件实现即插即用，具备可持续迭代升级的能力。在电子电气架构方面，目前特斯拉发展最为领先，其新一代集中式E/E架构达到车载中央电脑和区域控制器阶段，配合自研的操作系统，可实现整车OTA。
在新能源车的发展过程中你会看到很多同传统车不一样的先进技术在这方面使用，由于新能源车本身的架构和传统燃油就有很大的不同，对比于燃油车，新能源汽车的结构更简单。目前的燃油车结构比新能源汽车更复杂，特别是动力总成系统部分，要比新能源汽车复杂得多。新能源汽车的车辆结构较为简单，主要部件为动力电池组、电机和EMS组成的三电系统，因此在新能源汽车上开发或者使用自动驾驶技术，那么出现概率的情况要比燃油车低得多。
与此同时，从操控上来说，新能源汽车也要比燃油车更好操控——控制电压电流的大小以及输出，远比控制传统内燃机来得容易得多。所以比如一些ADAS的设备、TBOX、以太网、还有一些域控制器都是在优先在新能源车上出现，然后逐步使用到燃油车上。
智能座舱域控制器行业发展历程及里程碑事件
智能座舱发展经历了整体基础智能座舱发展经历了整体基础-细分产品细分产品-融合方案的格局变化。先是整体电子器架构和操作系统出现，随后各细分产品逐渐装载到车上，如今的趋势是各产品的协同整合。
可以看到2018年伟世通才出现基于座舱产品的域控制器，主要是整合了车载中控和仪表，还没有整合更多的ADAS功能的产品，比如360环视、LDWS等功能进去，说明这个域控制器有一定的难度。
域控制融合功能越多，功能安全越复杂
上图是中央控制器会遇到的问题，这个和域控制面临的问题是一样的，主要还是很多功能性安全，实时性安全的技术要求还不成熟。不是像我们想的这么简单，把能融合的就融合在一起，从功能安全的角度出发，反而并不一定好，我们以视频感知系统为例讲解。
这个系统通常很难做到ASIL-B或者更高的功能安全等级，这是因为这些模块有着复杂的数据处理过程，并包含多种失效模式。CMOSsensor首先要保证选用ASIL-B或者以上级别的。视觉SoC的内部多个单元模块也要实现各种错误检测和汇报机制，以实现ASIL级别的需要。如果其CPU使用ARMA系列的处理器，除非进行锁步执行，很难达到ASIL-B功能安全等级。
那么如何提升视觉感知系统的功能安全呢？行业里的较为普遍的做法，是使用ASIL-B级别以上的安全岛，或者独立的ASIL-B以上级别的SafetyMCU，来实现系统级功能安全。
通过增加一个具有ASIL-B或更高安全等级的MCU，并且软件实现视觉感知SoC向SafetyMCU输出结果，并且接收SafetyMCU的监控和控制，这样这个系统就有可能实现“系统级功能安全”，最终视觉感知结果，具备功能安全ASIL-B或更高等级。这个系统也相当于:
系统级ASIL-B=QM(VisionSoC)+ASIL-B(SafetyMCU)
其次因为VisionSoC的失效如果不被SafetyMCU检查出来，则会被传导到最终输出，这种将会导致ASIL分解不成立。如果VisionSoC的失效是可以被SafetyMCU检查出来的，那么SafetyMCU可以在最终信息输出标识系统进入安全状态,并且可以控制包括重置VisionSoC子系统进行错误修复，这时VisionSoC的失效不会导致系统失效，ASIL分解成立。所以关键点在于VisionSoC的失效是否可以被检查出。
经过上述的努力，我们有希望把视觉感知系统提到接近于ASIL-B的安全目标。但这样的系统通常也被认为不能达到ASIL-B，其主要原因是其采用的视觉感知算法目前尚不能被ISO26262认可。也有观点认为单独使用ASIL-BSafetyMCU不能做到充分的冗余，但通过增加一条数据通路，使得SafetyMCU也可以监控CMOSsensor的输出状态和信息，可以实现更为充分的冗余而达到系统级ASIL-B。这种设计在Veoneer的TrafficJamPilot系统里已经实现量产(视觉SoCQM级别+SafetyMCUASIL-B级别)。
那么，如果要达到更为严格意义上的ASIL-B，是否可以做到呢？市场现行的解决方案是增加可替代视觉感知的冗余，特别是增加毫米波雷达感知系统。增加了雷达以后，以上的系统框图变为：
这个系统需要摄像头的覆盖角度的关键部分如当前车道，和毫米波雷达的覆盖角度相重叠，这样来自两个不同传感器的异构冗余可以改善系统的功能安全。毫米波雷达系统可以做到符合ASIL-B，随后在ASIL-B或更高级别的SafetyMCU进行视觉+雷达做数据融合，并根据融合数据做出算法判断，最终的输出结果可达到ASIL-B或更高级别。
这里我们可能面临一个问题，如果有一颗SoC能够把VisionSoC和SafetyMCU合并进去，是不是等价方案？既可以实现高性能的算法，同时又可以做到功能安全需求。
这样系统的框图类似下面。Performancecore是性能核，也就是原来VisionSoC的部分，SafetyCore就是原来的SafetyMCU的部分。现在放到一起以后，两部分可以通过共享内存和相互发送中断进行通信。
SafetyCore部分的CPU运算性能，功能安全等级不一定好于分离式里的单独的SafetyMCU。同样，PerformanceCore部分的视觉感知性能，也不一定好于分离式里单独的VisionSoC。
所以在实际系统设计的时候，需要根据需求进行分析，并不能得出分离式系统的功能安全不如集成式系统这一结论。
下图是能够支持L3级别自动驾驶的奥迪A8的智能驾驶域控制器的设计：
这个例子很好的说明了如果设计合理的话，分离式功能安全设计是可行的，同时也说明了单颗甚至两颗芯片实现这样复杂的系统功能是非常困难的。再反过来看看前面提到的特斯拉FSD的完全双重冗余，也许特斯拉的设计更清晰明朗，虽然其并不是典型的ISO26262设计理念。
大家都知道汽车开发一个车型涉及大量的技术集成、零部件设计、试验验证等，所以汽车开发具有耗资大、周期长，开发风险高等特点。以往的汽车厂家推出一款新车至少需要5-10年，周期很长、工作量很大。但此一时彼一时，如今的车企，车型更迭的速度非常快，这个都是得益于底盘平台化。
如宝马的UKL前驱平台、CLAR后驱平台，丰田的TNGA架构、吉利的CMA平台，奔驰的MFA、MRA、MHA、MSA平台等，以丰田的TNGA平台架构为例，初期使零部件通用比例达到20%-30%，最终将达到70%-80%，这对于企业节约成本，降低研发周期起到关键作用。
而现在一个平台车型的迭代周期是3-4年，车型小改款是1年左右，越来越多的车厂选择把显示屏部分进行标准化，这样IP造型、显示屏的成本都能固定下来，而每次升级改款只需要修改主机，因为现在域控制或者单芯片的算力越来越强，主机升级换代的需求是必然，显示屏是显示内容部分，这部分相对简单一些，只要规划好对应的造型、尺寸、分辨率是可以做到平台化共用的，节省成本。
原来的座舱里面的控制器基本上是分开的，导航主机是一家，液晶仪表是一家，同时还有一个AVM全景一家，还有TBOX等，这里线束连接就非常复杂，而且不同供应商直接的协调调试也非常复杂。
上图是域控制产品形态，这样无论是走线，还是调试都非常方便，最关键就是OTA非常好做，而且降低成本。
以智能座舱为切入点提升用户体验成为企业制胜的关键点：
一方面，“一芯多屏”成为趋势热点。车载显示屏从单一、小型的平面矩形屏幕逐步向多个、大型曲面屏转变。因为传统分离式的座舱集成，多个座舱系统之间如“孤岛”一般相互独立导致通信成本高，而“一芯多屏”的智能座舱解决方案以通信成本低、时延短，可以更好地支持多屏联动、多屏驾驶等复杂电子座舱功能；
另一方面，汽车企业在追求炫酷科技带来的震撼感、科幻感的同时，开始围绕改善用户体验密集发力，更加强调用户的便捷度、舒适感、娱乐性，从消费者观感体验以及心理体验出发进行产品开发和服务设计，更加增进用户黏性。
半导体、能源革命驱动的此轮汽车智能化、电动化浪潮，半导体格局反应产业链格局
自动驾驶芯片
封闭生态战胜开放生态
L3以下：Mobileye市占率最高，但黑盒子交付模式越来越不受车厂喜欢，未来开放模式将更受大家欢迎；地平线、黑芝麻等国产厂商有机会
CPU作为控制器、运算器、存储器的结合体，提供通用算力，能处理不同的数据类型，成为了计算机的刚需。
CPU内部组成和工作原理：
运算器负责算术运算和逻辑运算。控制器负责应对所有的信息情况，调度运算器把计算做好。寄存器既要承接控制器的命令，传达命令给运算器；还要帮运算器记录已处理或者将要处理的数据。
CPU指令集（InstructionSet）是CPU中计算和控制计算机系统所有指令的集合。
指令集包含了基本数据类型，指令集，寄存器，寻址模式，存储体系，中断，异常处理以及外部I/O，一系列的opcode即操作码（机器语言），以及由特定处理器执行的基本命令。
指令集一般被整合在操作系统内核最底层的硬件抽象层中。指令集属于计算机中硬件与软件的接它向操作系统定义了CPU的基本功能。
现阶段的指令集可以被划分为复杂指令集（CISC）与精简指令集（RISC）两类。
CCISC与RISC无论哪一方都没有绝对的优势或劣势。
从硬件角度分析：CISC采用的是不等长指令集，因此在执行单条指令时需要较多的处理工作，但是它的优势往往在于部份特定专业领域的应用。而RISC执行的是等长精简指令集，CPU在执行指令的时候速度较快且性能稳定，因此RISC适合采用流水线方式运作，且在并行处理方面明显优于CISC。
CCISC与RISC从上世纪后期已经在逐步走向融合，并且该趋势持续至今。例如2005年苹果通过引入Rosetta将原先IBM的PowerPC指令集转译为英特尔处理器接受的X86指令集。2020年苹果发布基于ARM指令集的M1处理器后，将Rosetta更新为Rosetta2以便将原英特尔的X86指令集快速转译为M1的ARM指令集。
软件生态方面，X86运行的主要为DOS，非ARM版Windows，旧版MacOS等操作系统，起步早，基于Wintel联盟，生态完善。全世界有65%以上的软件开发商都为X86提供生态服务。
ARM方面运行的主要有安卓，iOS，iPadOS，Windows10移动版，MacOSBigSur等。原先适应X86指令集的软件需要经过翻译后才可运行，如苹果的Rosetta2可以将X86指令转换为ARM指令，所以运行速度会减慢。
ARM成本低，迭代快，其软件生态正在加速追赶X86的软件生态。苹果应用商店软件数量从2008年7月的5万个发展到2020年的342万个。同年GooglePlay商店有270万款可供下载的软件。
微架构是（MicroArchitecture）一种给定的指令集架构在处理器中执行的方法。相同的指令集可以在不同的微架构中执行，但实施的目的和效果可能不同。优秀的微架构对CPU性能和效能提升发挥着至关重要的作用。计算机体系是微架构和指令集的结合。
众多的算数单元、逻辑单元和寄存器文件在三态总线和单向总线，以及各个控制线的连接下组成了CPU的微架构。计算机的总线组织由CPU的复杂程度决定，二者常同向变化。
CPU微架构中常见的单元有执行端口、缓冲单元、整数运算单元、矢量运算单元等。
2)内存的特点是存取速率快
内存的作用
1)暂时存放cpu的运算数据
2)硬盘等外部存储器交换的数据
3)保障cpu计算的稳定性和高性能
上图非常清楚的看到不用的存储的大小不同，而且速度不同，越上面的存储器容量越小，比如L1和L2cache这部分容量非常小，但是速度非常快，而且价格比较贵。
芯片内部高速缓存介绍：
上图是全志T7的芯片内部手册图，可以从很多芯片手册上面看到有Icache和Dcache和L2cache。这个就是上图中的L1和L2cache芯片内部高速缓存。
Cache，是存储器子系统的组成部分，存放着程序经常使用的指令和数据，这就是Cache的传统定义。从广义的角度上看，Cache是快设备为了缓解访问慢设备延时的预留的Buffer，从而可以在掩盖访问延时的同时，尽可能地提高数据传输率。
CPU的每个核心有独占的L1指令缓存、L1数据缓存和L2缓存，多数核心共享L3缓存。所有缓存中L1缓存通过虚拟地址空间寻址，L2/L3通过线性地址空间寻址。
微架构工作流程概述：以英特尔的SandyBridge（下图）为例，CPU先使用取指令单元（下图紫色部份），将代码段从内存中取出;通过解码单元（下图橘色部份），将机器码按序转化为定长的uop（微操作），发射到uopDecoderQueue（微操作解密等候区）；乱序单元（下图黄色部份）从微操作解密等候区中取出微操作，根据执行条件，依赖关系，重新排序后，发送到Scheduler（调度器）；调度器将计算指令发送到计算单元（下图蓝色部份），得到计算结果；将内存读写指令发送给访存单元（下图绿色部份），完成内存读写。
微架构通过执行指令“exec（）“，执行某个二进制数时，该二进制数首先被kernel（核心）从硬盘加载到内存。
nInstructionFetchUnit（执行获取单元）会按照执行顺序将bin的代码段，从内存中读入到CPU。当遇到分支代码时,需要查询BranchPredictors（分支预测）。执行获取单元增加访问电路，可以并发地访问内存、寄存器，解决流水线气泡问题。
在Precoded（预解码）中解码的X86指令集，会被保存到InstructionQueue（指令等候区），等待解码。
现在的CPU均使用超标量的结构。例如SandyBridge是16条。每个CPUcycle有16个操作在并行执行，需要一系列设计来保证流水线不被中断。
InstructionQueue（执行等候区）中取指单元获得的x86CISC指令，会通过译指单元翻译，以提高CPU流水的整体能力。
一个周期有4条指令进入译指单元不同的模块，ComplexDecode（复杂解码器）翻译单指令多数据流指令，一个周期最大可以产生4个uops（微操作），SimpleDecode（简单解码器）翻译普通指令，一个周期产生1个微操作，得到的微操作会保存到uopDecoderQueue（微操作解码等候区）中。
微架构的乱序执行会选择当前可执行的指令优先执行，减少处理器闲置。
Scheduler（调度器）会将整数操作数和浮点操作数分别保存，把映射表存入ReorderBuffer（重新编序缓存）。最后统一调度器选择有执行条件的微操作发送给执行单元，没有执行能力的微操作先缓存，待条件具备后发送。
乱序执行单元每个周期发送4个微操作到计算单元。port0、port5可以执行整数、浮点数、整数SIMD（单指令多数据流）所有指令，port1只能执行整数、整数SIMD乘法、移位指令，每个周期最多执行3条指令。port2，port3，port4每个周期可以执行2个load（读取），1个store（存储）指令。
SandyBridge在运算单元上，通过AVX指令，大幅提升了浮点数以及SIMD的效率。
AddressGenerationUnit（地址产生单元）产生读写内存的虚拟地址；LoadStoreUnit（存取单元）通过地址，实现读取、存储。
存取单元包含Loadbuffer（读取缓冲）、Storebuffer（存储缓冲）、prefetch（预读逻辑）、一致性的逻辑。存取单元读内存时，先要查询缓冲中的是否有缓存，如果命中，直接返回。当不命中时，需要发起对内存的读取，由于读取内存大概需要200周期，代价很高，存取单元实现了预读逻辑。
CPU发展史简单来说就是Intel、IBM、ARM的发展历史，CPU已经有四十多年的发展历史。
随着2005年以Prescott为内核的奔腾4处理器在性能和效能上被AMD的K8速龙超越，英特尔采取了“Tick-Tock”的钟摆模式，“Tick”年升级处理器的制程，“Tock”年升级处理器的微架构。以两年为周期的钟摆模式，从“Nehalem”开始让CPU交替发展，一方面避免了同时革新可能带来的失败风险，同时持续的发展也可以降低研发的周期，并可以对市场造成持续的刺激，并最终提升产品的竞争力。
2008-2015年的钟摆模式使英特尔CPU年均有15%左右的提升，维护了英特尔X86领域的霸主地位，并诞生了诸如Skylake这样经典的架构，沿用至今。
1、内核角度
下图即为ARM的单核心CPU和多核心CPU。图中红色虚线框标出的部分为CPU核心，分别为基于ARMv7微架构的单核心CPU芯片以及ARMCortex-A9MPCore用2个和4个Cortex-A9构成的2核心和4核心CPU芯片。
目前我们能见到的4核心CPU大多都是属于Cortex-A9系列。ARMCortex-A9的应用案例有联发科MT6577、三星Exynos4210、华为K3V2等，另外高通APQ8064、MSM8960、苹果A6、A6X等都可以看作是在A9架构基础上的改良版本。
从ARM内核的发展架构来看，从单SOC多核变化到单SOC多核异构
ARM-V7单SOC多核
ARM-V8单SOC多核异构（大小核）
一体化程度更高
单SOC多系统共存技术趋于成熟
智能驾驶舱的集成了DIC、HUD、IVI和RSE等等多屏融合
2、市场成熟度角度
智能座舱域控制器芯片市场主要玩家：
2.手机领域的厂商，主打高端市场：联发科、三星、高通等。
由于域控制器芯片市场仍处于行业萌芽期，目前国内搭载座舱域控制器芯片的车型绝大部分仍然采用的是德州仪器的Jacinto6和NXP的i.mx6等上一代产品。国内竞争者主要有杰发、芯驰等。
2015年前：以瑞萨、NXP、TI等传统汽车芯片主导市场，这三家占据市场60%的份额。
2015年开始：越来越多的消费级芯片巨头参与汽车片芯片生产商重组并购。
验收条件更苛刻，且周期长：车规级芯片在温度、湿度、碰撞等多个维度范围更宽，需要承受的极限条件更苛刻
趋势变化，这两年车机芯片的运行速度已经和消费级芯片的运行速度差距大幅度减小。
参照手机，汽车座舱领域迭代速度加快，车机芯片的运行速度已经和消费级芯片大幅缩小，产品的生命周期越来越短。
智能座舱（中控屏）芯片发展情况
智能座舱域控制器芯片未来3-5年的玩家
智能座舱芯片：高端以高通、英特尔、瑞萨为主（还要看其第四代产品竞争力），高通领先
CPU性能对比：高通820ACPU性能与英特尔、瑞萨基本一致。但8155具备全方面的性能优势，8.5万DMIPS同代产品领先。
待进入玩家：华为、三星、联发科。
3、芯片算力角度
CPU性能评估采用综合测试程序，较流行的有Whetstone和Dhrystone两种。Dhrystone主要用于测整数计算能力，计算单位就是DMIPS。Whetstone主要用于测浮点计算能力，计算单位就是MFLOPS。一个表示整数运算能力，一个表示浮点数运算能力，二者不能完全等同。
DMIPS：DhrystoneMillionInstructionsexecutedPerSecond，主要用于测整数计算能力；
MFLOPS：MillionFloating-pointOperationsPerSecond，主要用于测浮点计算能力；
D是Dhrystone的缩写，表示的是基于Dhrystone这样一种测试方法下的MIPS。Dhrystone是于1984年由ReinholdP.Weicker设计的一套综合的基准程序，该程序用来测试CPU（整数）计算性能。Dhrystone所代表的处理器分数比MIPS（MillionInstructionsexecutedPerSecond，每秒钟执行的指令数）更有意义。
一般芯片都有DMIPS/MHz信息（参见下面的图片）
比如ARMCortex-A53架构为2.3DMIPS/MHz，那么可以计算出：
双核A53架构，主频为1.6GHz的CPU，DMIPS为：2*1600MHz*2.3DMIPS/MHz=7360DMIPS；
四核A53架构，主频为1.6GHz的CPU，DMIPS为：4*1600MHz*2.3DMIPS/MHz=14720DMIPS；
我们来算下NXPi.mx8QuadMax，ARM(2*A72+4*A53)，4核A53架构，主频为1.2GHz的CPU，DMIPS为：4*1200MHz*2.3DMIPS/MHz=11040DMIPS；
2核A72架构，主频为1.6GHz的CPU，DMIPS为：2*1600MHz*4.7DMIPS/MHz=15040DMIPS；最终IMX8Q的CPU计算性能15040+11040=26080，所以是26KDMIPS；
4、芯片SOC的GPU算力能力
那么要快速执行一次YOLO-V3，就必须执行完一万亿次的加法乘法次数。
这个时候就来看了，比如IBM的POWER8，最先进的服务器用超标量CPU之一，4GHz，SIMD，128bit，假设是处理16bit的数据，那就是8个数，那么一个周期，最多执行8个乘加计算。一次最多执行16个操作。这还是理论上，其实是不大可能的。
那么CPU一秒钟的巅峰计算次数=16*4Gops=64Gops，当然，以上的数据都是完全最理想的理论值。因为，芯片上的存储不够大，所以数据会存储在DRAM中，从DRAM取数据很慢的，所以，乘法逻辑往往要等待。另外，AI算法有许多层网络组成，必须一层一层的算，所以，在切换层的时候，乘法逻辑又是休息的，所以，诸多因素造成了实际的芯片并不能达到利润的计算峰值，而且差距还极大，实际情况，能够达到5%吧，也就3.2Gops，按照这个图像算法，如果需要执行YOLO-V3的计算，1W除以3.2=3125秒，也就是那么需要等待52分钟才能计算出来。
此时我们在回过头来看看高通820A芯片的算力，CPU的算力才42K，刚刚那个是基于最先进的服务器IBM的POWER8CPU计算力是是3.2GPOS，车载算的上最先进的域控制器才42K的CPU计算力，所以不能用于AI的计算。此时需要使用GPU来计算，看看GPU的算力是320Gops，此时算这个YOLO-V3图像识别的算法需要32秒，这个成绩还是非常不错的。
此时可以看到高通820A芯片的CPU算力是不能够用于AI的计算，GPU的算力是可以满足一些不需要那么实时性比较高的一些AI处理。
这样你就不会问为什么GPU这么厉害，AI识别为什么不全部使用GPU得了，那就需要继续看CPU和GPU的区别了。
从芯片设计思路看，CPU是以低延迟为导向的计算单元，通常由专为串行处理而优化的几个核心组成，而GPU是以吞吐量为导向的计算单元，由数以千计的更小、更高效的核心组成，专为并行多任务设计。
CPU的核心运算ALU数量只有几个（不超过两位数），每个核都有足够大的缓存和足够多的数字和逻辑运算单元，并辅助很多复杂的计算分支。而GPU的运算核心数量则可以多达上百个（流处理器），每个核拥有的缓存大小相对小，数字逻辑运算单元也少而简单。
CPU和GPU设计思路的不同导致微架构的不同。CPU的缓存大于GPU，但在线程数，寄存器数和SIMD（单指令多数据流）方面GPU远强于CPU。
CPU和GPU的不同的通俗解释：
GPU就是这样，用很多简单的计算单元去完成大量的计算任务，纯粹的人海战术。这种策略基于一个前提，就是小学生A和小学生B的工作没有什么依赖性，是互相独立的。很多涉及到大量计算的问题基本都有这种特性，比如你说的破解密码，挖矿和很多图形学的计算。这些计算可以分解为多个相同的简单小任务，每个任务就可以分给一个小学生去做。但还有一些任务涉及到“流”的问题。比如你去相亲，双方看着顺眼才能继续发展。总不能你这边还没见面呢，那边找人把证都给领了。这种比较复杂的问题都是CPU来做的。
总而言之，CPU和GPU因为最初用来处理的任务就不同，所以设计上有不小的区别。而某些任务和GPU最初用来解决的问题比较相似，所以用GPU来算了。GPU的运算速度取决于雇了多少小学生，CPU的运算速度取决于请了多么厉害的教授。教授处理复杂任务的能力是碾压小学生的，但是对于没那么复杂的任务，还是顶不住人多。当然现在的GPU也能做一些稍微复杂的工作了，相当于升级成初中生高中生的水平。但还需要CPU来把数据喂到嘴边才能开始干活，究竟还是靠CPU来管的。
在GPU+CPU的异构运算中，GPU和CPU之间可以无缝地共享数据，而无需内存拷贝和缓存刷新，因为任务以极低的开销被调度到合适的处理器上。CPU凭借多个专为串行处理而优化的核心运行程序的串行部份，而GPU使用数以千计的小核心运行程序的并行部分，充分发挥协同效应和比较优势。
什么类型的程序适合在GPU上运行？
座舱的域控制器GPU算力的需求：
前面聊了GPU对于3D图像处理。一些简单的图像算法都需要涉及GPU，而智能座舱域控制器主要是输出给液晶仪表和中控导航，所以首先图像处理部分肯定是必不可少的，这个就跟图像显示需要做到的效果有关了，如果仅仅是普通的2.5D的效果，这个时候对于GPU的算力就不高，如果是3D的高级的图像效果，这个时候就需要GPU的算力比较大，基本上200GFLOPS以上就能满足3个屏以上的图像效果了。
智能座舱的域控制综合考虑因素
想想如果处理不压缩的图像数据，我们来看看4K的图像数据有多少，3840*2160*24bit*60fps=11943936000bits=1.39GB/s，处理一个4K的图像数据就需要这多大的数据量，而且允许占的内存带宽还会更大。
在选择芯片平台的时候，还需要考虑以下因素
1、车载市场占有率这个占有率越高，整体后面的成本才具有优势，同时采购周期或者调货的时候也比较方便，当然大家都用，就需要考虑到后面的技术支持的力度，从目前来看高通芯片的占有率非常高，其次是NXP和瑞萨。
3、产品路标和技术支持也是需要考虑的一个维度，比如瑞萨在国内的技术支持力度就不大，中国区没有足够的技术支持能力、需要通过联络日本本社提供技术支持面对国内车厂和T1、在项目中的问题反馈和对应速度偏慢。而且需要看该产品路线后续的芯片规划，有的可能规划了这两代后，后面基本上就放弃了智能座舱的芯片了，比如TI芯片。
高通芯片的市占率
根据StrategyAnalytics数据，2015年瑞萨、恩智浦合计占据整个车机芯片市场份额的六成以上，其中瑞萨在驾驶舱、仪表份额达到47%、44%；
车用MCU/SOC市场规模约为60-70亿美元，2016年之前高通市占率为1%以下；2019、2020财年高通来自汽车业务收入（包含通信、座舱芯片）收入分别为6.4、6.44亿美金。
公司预期汽车芯片在2022年的TAM为180亿美元，对应三年CAGR为12%。
推算2020年TAM约为140亿美元，公司收入6.44亿美元，市占率约4.6%。
高通座舱芯片渗透率不断走高。其中2020年是高通座舱出货大年，核心出货量比较大的车型包括奥迪改款A4L、本田雅阁十代等，并且大部分新能源车型都选择高通820A作为座舱芯片。
高通芯片roadmap
从性能参数可以看到最强的8195P，现在最前沿马上量产的是8155，吉利的极克01就是这个芯片，当然小鹏的P5也是这个芯片，都还没有量产，比8155低一个档位的是820A芯片，前面有可以看到有接近20款车型使用这个座舱芯片，当然也有低端的座舱芯片，比如带动一个中控导航和副驾驶娱乐屏的需求，这个时候就可以使用6155P的芯片。
自主平台在座舱里面发力比较多的是芯驰，地平线和黑芝麻主要是做自动驾驶的芯片，比如地平线的征程5已经在很多车上做自动驾驶平台方案了。
全志的T7也有在东南汽车、北京现代、长安汽车上使用，但是做座舱芯片还是很吃力，基本上只能做中控导航的驱动。目前看到的自主座舱芯片平台比较有潜力的是芯驰。
可以看到越来越多的芯片公司选择来做智能座舱的芯片，NXPTI瑞萨传统三杰，高通，intel、芯驰、全志等厂家也进入来做座舱芯片，单芯片多系统为代表的“域控制器”，已经成为智能汽车的必选项目之一。
上图是IMX6的多芯片方案，液晶仪表、中控导航、后排娱乐都使用了IMX6最小系统，这样上图黄色框里面的内容就资源重复了，但是如果只用一颗IMX6又不能带动三个显示屏，所以利用率不高。
单SOC智能座舱系统框架
上图是RCAR-H3的单SOC智能座舱的方案，可以看到这部分最小核心系统的器件只需要一份，就可以驱动中控导航、液晶仪表、后排娱乐显示屏、还有副驾驶娱乐屏，多个显示屏的不同内容。
单SOC的方案的优点非常多
车身:设备单一，布线方便，成本低，可靠性好。
系统硬件资源：
产品开发：
独家设备供应商，独立设备开发，独立样件制作，无须定制复杂协议，多个设备无须联调，开发进度容易把控，开发成本可控。
信息安全：
独家供应商，设备间通讯在芯片内部完成，信息安全得到有效保护。
整套成本：
硬件资源利用率高，独家供应商，生产，包装，运输可控整套成本可控。
体验：
设备单一，整套设备方案受限因素小，多屏娱乐互动性好，体验佳
1、方案概述
新推出的R-CarH3具备比前一代R-CarH2更强大的汽车计算性能，可充分满足系统制造商对汽车处理平台的要求。为了提供准确、实时的信息处理能力，R-CarH3基于ARM?Cortex?-A57/A53核构建，采用ARM的最新64位CPU核架构，实现了40000DMIPS（Dhrystone百万指令/每秒（注1））的处理性能。
此外，R-CarH3采用PowerVR?GX6650作为3D图形引擎，可为驾驶员提供及时可靠的信息显示。基于ImaginaTIonTechnologies提供的最新架构，R-CarH3的着色计算（注2）性能约是R-CarH2的三倍。
除了CPU和GPU以外，片上并行可编程引擎IMP-X5也提供了先进的图像识别技术。IMP-X5是瑞萨电子独有的识别引擎，专门为与CPU配合处理而进行了优化。它的识别性能是第二代R-Car系列内置的IMP-X4的四倍。
R-CarH3R8A77951（SoC）关键参数：
CPUcore：Cortex-A57Quad@1.5Ghz+Cortex-A53Quad@1.2Ghz+Cortex-R7@800Mhz
GPU：IMGPowerVRSeries6XTGX6650Max600Mhz
Videooutput：4displaycontrollable(HDMI2ch+LVDS1ch+RGB8881ch
VideoCodec：H.262/H.263/H.264/H.265/RealVideo8/9/10/VP8/VC-1SP/MP/AP/MPEG-4ASP
Storage：USB3.0Host1ports/USB2.0Host/OTG4ports/SDx2ch/SATA1ch/
芯片制程16nm
R-CARH3系统框图
基于1颗SOC，搭载QNXHypervisor2.0运行QNXSDP7.0+RTOS+AndroidPAutomotive
CPU及外部硬件资源通过QNXHypervisor虚拟化共享。
AndroidP实现IVI+HMI+RSE三屏，QNXSDP7.0+Kanzi实现仪表。
RCAR-H3QNX共享CPU
半虚拟化是通过事先经过修改的用户操作系统内核共享底层物理硬件来实现的。
缺点：是用户操作系统内核需要事先进行修改，部署的便利性和灵活性不够好。
优点：是用户的操作系统内核不需要做特殊配置，部署便利，灵活，兼容性好。
缺点：是用户操作系统的内核不能够直接管理底层物理硬件，内核通过hypervisor系统管理模块管理底层物理硬件需要有转换，性能比半虚拟化弱。实时性不好。
RCAR-H3是使用全虚拟化的设计，共享内存，零拷贝，速度非常快。
方案概述
系统框图概要：
系统主要器件List：
系统主SOC选型说明：
系统软件架构：
座舱系统包含三部分，具体如下：
SoC运行QNXHypervisor，包含两个操作系统，其中QNX运行对实时性和安全性要求高的功能，比如仪表/HUD
QNX虚拟化方案支持：
运行GuestOS系统，可以在虚拟机上运行Android系统
QNX系统达到ASIL-D等级，同时具备高实时性，可以运行仪表/HUD等功能
GPU以及CPU的资源可以共享，可以通过配置优先级确保QNX系统的资源
QNX和Android之间的进程间通讯包含两部分
系统间的控制命令/数据通讯（不包含音频视频）可以通过SomeIP协议来实现
系统间的大数据量数据通讯（比如图像/音频）可以通过共享内存的方式实现数据通讯
安卓端框架介绍
应用层：运行自研应用及第三方应用
安卓服务层：支持应用运行的功能，以android服务的形式运行
硬件抽象层：对上提供统一的接口，屏蔽底层驱动的不同，对下适配底层驱动
QNX软件主要分为如下几层：
架构层：主要运行图形处理/音频处理/网络管理/进程间通讯框架
服务层：主要运行进程间通讯，虚拟IO口的访问/音频服务/屏幕管理的逻辑
驱动层：负责屏幕串行解串/USB/摄像头等驱动调试
支持A/B分区升级，在升级主机过程中不影响用户使用
支持集成车厂的FOTA方案，目前FOTA方案的集成一般包含两部分
升级客户端：与升级服务器交互，下载升级包，与后台的升级服务器同步主机版本信息。
升级代理：负责升级主机和MCU软件；可以通过DOIP协议发起刷新其他模块
支持对屏幕的升级
升级模块支持车厂的PKI策略集成，可以支持证书的生成和校验
Camera框架使用AIS框架，图像数据的采集在QNX端完成
Android端可以通过AIS框架获取到Camera图像数据，界面的处理需要靠图层叠加来完成
Camera的接口是CSI接口，每个CSI接口可以支持4个摄像头接入。不同高通平台的CSI接口数目不同
屏幕的输出使用WFD框架
屏幕的输出接口控制在QNX端。Android端使用代理与QNX端通讯
屏幕的输出接口有DP和DSI两种，具体的接口数目不同的项目不一样
NXP座舱芯片的roadmap
在新一代的iMX8QM和iMX8QXPBSP中，它实现了硬件分区以划分资源和内存区域。默认的AndroidAutoBSP给出了M4和A内核之间共享内存的示例，这被用于RPMSG。
QNX基于A35运行；
QNX本身自有的图形监视子系统用于保证正常图形绘制的安全性以及可靠性；
同时界面工具QT（或者KANZI）有完整的安全渲染机制（QtSafeRendererversion1.1.），通过工具所提供的安全渲染引擎（SafeRendererEngin），能够对安全要求最高图层进行渲染（警告图标等等）；
上述A35核本身借助符合ISO26262-ASIL-B的QNX+QT的工具集来保证系统和功能的安全性和稳定性
M核基于RTOS，M核端运行Watchdog；
实现由M核对A核的服务与消息机制的监管；
建议：
QNX符合ASIL-B的显示子系统安全机制；
HMI图形工具QT的安全渲染机制，保证失效机制下的最高等级图层显示（FB0）。M4核是冗余设计出来的。
TheQNXCARplatformbootsinseveralstages,asillustratedinthefollowingdiagram:
QNX的安全启动流程参考如下：引用QNXBoot_Optimization_Guide
NXP的imx8芯片是基于硬件虚拟化设计实现，具有以下功能：
双系统独立启动，双系统为LINUX+ANDROID
崩溃检测
硬件资源划分
共享内存
使用NXP硬隔离方案，在两个Domain之间通过MU和ShareMemory的方式进行信息通讯和数据共享
—END—
公众号：阿宝1990；本公众号专注于自动驾驶和智能座舱，每天给你一篇汽车干货，我们始于车，但不止于车！