首页软件开发正文

AUTOSAR规范与车用控制器软件开发（autosar规范与车用控制器软件开发pdf 百度网盘）

软件开发 2023-01-21T15:46:10 2185

今天给各位分享AUTOSAR规范与车用控制器软件开发的知识，其中也会对autosar规范与车用控制器软件开发pdf 百度网盘进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！本文目录一览： 1、新能源汽车电驱动技术发展和产业化趋势

今天给各位分享AUTOSAR规范与车用控制器软件开发的知识，其中也会对autosar规范与车用控制器软件开发pdf 百度网盘进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

新能源汽车电驱动技术发展和产业化趋势

新能源汽车的动力系统包括电驱动系统与电源系统两大类

电驱动系统包含电机、电控制器、减速箱，是驱动电动汽车行驶的核心部件；电源系统包含车载充电机（OBC）、DC-DC 转换器和高压配电盒，是动力电池组进行充电、电能转换及分配的核心部件。

电驱动产业链涉及环节较多，可以概括为零件—总成—系统—整车厂四大层级。

上游零部件包括永磁体、硅钢体、功率模块、电容、传感器等，这一级的玩家对在整车产业链中属于“三级供应商”。在零部件基础上进一步设计组装得到电机总成、电控总成与传动总成，这一级的玩家可以称为车企的“二级供应商”；各个单独总成进一步集成为电驱动系统供货于车企，这一级玩家为行业“一级供应商”。

1.1. 大三电：电机、电控、减速器

1.1.1. 电机：扁线电机、高压电机带来新机遇

电驱动系统在新能源汽车成本中占比仅次于电池。电驱动系统（电机、电控、减速器）是新能源汽车动力总成的关键部件，相当于传统燃油车发动机的作用，直接决定整车的动力性能。其成本占比仅次电池，占比绝对值因新能源汽车品牌、车型而异。

驱动电机主要技术路径聚焦在永磁同步电机交流异步电机上。永磁同步电机与交流异步电机的主要区别点在于转子结构，永磁同步电机会在转子上放置永磁体，由磁体产生磁场；而交流异步电机则是由定子绕组通电产生旋转磁场。功率密度、效率（高效率区间）是衡量电机性能的关键指标：

1）功率密度越大代表着相同功率下的电机体积更小，有利于节省空间制造成本；

2）效率越高，说明电机端损耗越小，相同电池容量下，新能源车续航里程更长。

永磁同步电机为目前应用最多的电机类型，异步电机在高端车型双电机配置下会有部分使用。相比交流异步电机，永磁同步电机功率密度更高、高效区间更宽、质量更轻。

根据第一电动汽车网统计信息，2022 年 3 月，我国新能源汽车共配套驱动电机 50.97 万台，其中永磁同步电机为 48.60 万台，占比 95%，适用于大部分主流车型；交流异步电机配套 2.09 万台，占比为 4%，主要配套包括特斯拉 Model Y、岚图 FREE、蔚来 ES8、奥迪 e-tron、大众 ID.4 CROZZ 等车型。交流异步电机在高速中应用性能更优，同时具有成本优势（稀土永磁材料成本较高，同功率的永磁同步电机价格更高），目前配套多以高端车型、双电机方案为主 (蔚来 ES8 是前永磁同步+后交流异步，特斯拉 Model Y 2021款采用前感应异步+后永磁同步)。

多电机在高端车型中应用有所增加，故单车配套电机数也随高端市场占比而变化。

相比单电机，双电机可以显著提高汽车的加速性能与续航能力。同时，双电机多意味着四驱系统，可以提供更好的附着力，从而提高安全性能。近年来，在高端车型中双电机的应用不断增加，特斯拉、蔚来、奥迪、大众、奔驰都陆续推出搭载双电机的车型。而在法拉第 FF91 和荣威 MarvelX 中更是使用了三个电机。

扁线：可有效提高电机功率密度，减少铜损耗以提升效率。

1）功率密度高：相较于传统的圆线绕组电机，扁线电机将圆形导线换成矩形导线，因此相同面积的定子线槽可以塞进更多面积的导线，进而提高功率密度。

2）效率高、损耗小：铜损耗在电机损耗里占比达 65%，因此为提高电机效率，需采用更合理的定子绕组，从而降低铜耗。此外，扁线截面更粗使得电阻相对更小，铜导线发热损失的能量也越小。而且扁线电机的端部尺寸短 5-10mm，从而降低端部绕组铜损耗。

3）重量、NVH 等方面也存在优势。

发卡电机为应用最广泛的扁线技术，产线投资高，产业化仍处于前期阶段。根据线圈绕组方式差异，扁线电机可分为集中绕组扁线电机、波绕组扁线电机与 Hairpin（发卡）扁线电机，其中发卡电机应用最为广泛。相对圆线电机，扁线电机无法进行手工制造、自动化要求较高——绕组制造过程非常复杂，需要先将导线，制作成发卡的形状，然后通过自动化插入到定子铁芯槽内，然后进行端部扭头和焊接。高自动化及定制化使得扁线电机产线投入较高，根据方正电机，2021 年来公司已先后投资 17.42 亿元用于产线建设，对企业资金实力有较大挑战。

雪佛兰和丰田开启扁线电机应用先河，近年来渗透率不断提升。2007 年，雪佛兰VLOT 采用的电动汽车中就有发卡式扁线电机，其供应商为雷米。2015 年，丰田发行了装载扁线电机的第四代普锐斯，其电机供应商为 Denso。在扁线电机更高的效率加成下及内外资电机厂商批量化工艺的成熟，近年来其应用不断增加，2020 年来，保时捷、比亚迪、特斯拉等车企纷纷推出装载发卡式电机的新车型，渗透率不断增长。根据方正电机公司年报，2020 年全球新能源汽车行业扁线电机渗透率为 15%，我国扁线电机渗透率约为 10%。2021 年随着各主流车企大规模换装扁线电机，特斯拉换装国产扁线电机，我国扁线电机渗透率已与全球扁线电机渗透率同步增长至 25%。

此外，在高端车型中，搭载扁线电机数量也开始从原来的单电机增加到双电机。例如，保时捷首款纯电动跑车 Taycan 便采用了三电机。

高压：缩短充电时间、提高电机效率以延长里程的重要措施。纯电乘用车电压通常在 200-400V 之间，在同等功率下，当电压从 400V 提升到 800V 后，线路中通过的电流减少一半，产生的功率损耗更小，从而可以提高充电效率、缩短充电时长，进而改善新能源汽车使用体验。同时，工作电流的减少将降低功率损耗，继而可以进一步降低同样行驶里程中的电量消耗，从而延长汽车里程数。2021 年为我国 800V 高压快充元年，行业发展有望加速。

2021 年来，比亚迪（e 平台）、理想、小鹏、广汽（埃安）、吉利（极氪 001）、北汽(极狐)等车企纷纷布局 800V 快充技术，我国 800V 高压快充行业进入发展加速期。

高压化下对汽车电子各环节都将带来新挑战，目前应用仅停留在高端车型。新能源汽车要实现 800V 及以上高压平台兼容，除了需要提高电机、电池性能外，PTC、空调、OBC、高压线束等部件都需要重新适配，此外还面临更高电压带来的安全、热管理、成本等多方面挑战。受以上因素影响，目前 800V 高压平台应用还仅停留在部分高端车型。

油冷：采取合理的电机热管理设计可以进一步提升功率密度。电机的功率极限能力往往受限于电机温升极限，因此提高电机冷却散热能力可以快速提高功率密度，同时防止永磁体在高温时发生不可逆的“退磁”。目前常用的冷却方式为水冷，但其无法直接冷却热源，热量传递路径长、散热效率低；相较于水冷，油冷的优势在于油品具有不导电、不导磁、绝缘等性能，因此可以直接接触热源，形成更安全的热交换，提高散热效率。

故相同的绕组绝缘等级下，油冷电机可以承受更高的绕组电流，长期工作功率更高。

1.1.2. 电机控制器：IGBT 掣肘，单管并联纾困

电控系统通过电机控制算法发出信号驱动电机转动，进而控制整个车辆的动力输出。电控系统可分为主控制器和辅助控制器：

1）主控制器控制汽车的驱动电机；

2）辅助控制器控制汽车的转向电机、制动器、空调等。

我们本文重点讨论的电控系统主要指主控制器，主要由控制板（接受整车控制器的信号指令，运行电机控制算法，发出控制指令给功率板）、功率板（接受控制板指令，频繁通断 IGBT/MOSFET，控制电机转动）、壳体等组成，在控制器中，控制电路板、功率电路板成本主要在于 IGBT（绝缘栅双极型晶体管）、MOSFET（功率场效应晶体管）、MCU（微控制器）、电源芯片等半导体器件。

电控开发需要从硬件、软件两方面协同进步。类似电机，电机控制器的核心指标同样为功率密度、效率，软硬件的优化也是围绕这两大核心主题展开。

1）硬件角度，功率半导体单管并联方案将具备高性价比优势，或成 A 级以下车型主流硬件配置；而模组方案凭借更高可靠性，在中高端车型占据核心地位。器件方面，碳化硅有望逐步渗透。

2）软件角度，需要在可拓展性、易维护性、功能安全性等方面的不断提高。

功率半导体 IGBT 占电控成本比重较高，主要参与者为国外功率半导体巨头。根据盖世汽车数据，2017 年功率板的核心器件 IGBT 模块，占到电控总成本高达 37%。根据Yole，2020 年全球 IGBT 行业销售额 TOP15 公司中共 14 家为国外企业，而英飞凌（Infineon）更是凭借 14.33 亿美元的收入连续多年稳居全球第一。

功率半导体在新能源汽车中的应用可分为模组单管并联这两种路线，两者有各自适用的场景。模组为高度集成的功率半导体产品，保证了电控成品的可靠性良率高，同时降低了系统设计的复杂度。以 IGBT 为例，由于车规级功率半导体主要被英飞凌等外资占据，其往往提供特定参数规格的标准 IGBT 模组，然而模组参数往往不能很好适配具体需求，因此标准模组在不同功率的驱动电机控制系统中容易出现容量受限、结构安装等问题。若采用多个 IGBT 单管并联（通过复合母排、冷却装置等部件一同封装），则可以根据不同车型灵活设计冗余量，并且单管成本显著低于模块，在成本要求较高的A 级以下车型使用得更为普遍。但多个 IGBT 单管并联时，由于各单管参数的分散性、输出电流的不一致性，可能使系统可靠性较差，整个 IGBT 模组寿命也会缩短，对企业技术、制造能力考验大，故中高端 B 级以上车型通常使用可靠性更强的模组路线。

碳化硅功率器件可显著提高电控效率、功率密度等性能。碳化硅材料具有禁带宽度大、热导率高、电子饱和迁移速率高等性质，相比硅基 IGBT，碳化硅元器件体积更小、频率更高、开关损耗更小，可以使电驱动系统在高压、高温下保持高速稳定运行（硅基IGBT 只能在 200 以下的环境中工作）。根据意法半导体，在 400V 电压平台下，相较于硅基 IGBT，碳化硅功率件有 2-4%的效率提升；在 750V 电压平台下，碳化硅器件有3.5-8%的效率提升。

越来越多的高端车型已采用碳化硅电控。

1）车企角度，2021 年奥迪 e-tron GT 与福特 Mach E、特斯拉 Model S 等新车型也纷纷采用了碳化硅器件。2021 年 10 月，通用汽车与 Wolfspeed 签订了碳化硅供应协议，在原材料上抢先布局。国内车企也不断布局碳化硅，比亚迪发布了碳化硅车系平台 e-Platform 3.0，小鹏 G9、蔚来 ET7 等采用碳化硅电控的车型也有望在 2022 年交付。

2）供应商角度，根据精进电动招股说明书，公司采用全 SiC 模块，可以使控制器的功率提高 20kW 同时使其重量减少 6kg，逆变器尺寸缩小 43%。根据英搏尔，碳化硅电机控制器的损耗下降了 5%，电驱动系统整体 NEDC 平均效率提升 3.6%，整车 NEDC 续航提升 30km、增幅达 5.8%。

除了电机控制器外，碳化硅器件在 OBC、DC/DC、无线充电等“小三电”中也有应用。例如，欣锐科技早于 2013 年正式将 Wolfspeed 的碳化硅方案应用于 OBC 产品，2021 年为比亚迪 DMi 车型提供碳化硅电源类产品。目前制约碳化硅器件应用的主要因素为成本，伴随着未来碳化硅产业链的发展完善，相关器件应用渗透率将稳步提升。

软件：电控的进步体现在可拓展性、易维护性、功能安全性等方面的不断提高。

1）可拓展性：电控软件开发通常会使用 AUTOSAR 工具链（B 级及以上车把 AUTOSAR 作为“标配”）。AUTOSAR（AUTOmotive Open System Architecture，汽车开放系统架构）是由全球各大汽车整车厂、汽零供应商、汽车电子软件系统公司联合建立的一套标准协议，旨在有效地管理日趋复杂的汽车电子软件系统。AUTOSAR 规范的运用使得不同结构的电子控制单元的接口特征标准化、模块化，应用软件具备更好的可扩展性、可移植性，缩短开发周期。

2）易维护性：是指在软件后续使用过程中，及时实现远程更新升级与性能优化。OTA（Over-the-Air）技术可以降低维护成本，创造新的收入来源，目前已经在汽车行业包括其控制器总成上持续推广。3）安全性，电驱动系统的控制器总成对新能源汽车的动力输出进行直接的调节控制，是保证安全性的重要一环。在汽车行业逐步引入 ISO26262 标准之后，基于功能安全的车用软件开发对电控软件提出了新的要求。

1.1.3. 减速器：单档路线为主，两档减速可以期待

电机高速化趋势明显，带动减速器向两档减速方向发展。减速器是影响电驱动系统整体 NVH 性能的关键。按照传动等级分类，减速器可以分为单级减速器、两档减速器以及两档以上减速器。在电机高速化的趋势下，减速器正在经历从单级到多档的产品演变过程。目前，丰田普锐斯和特斯拉 Model 3 电机转速均已达到了 17900rpm，国内车企转速略低，但基本也都达到了 16000rpm，下一步规划便是 18000-20000rpm，电机高速化性能的提升需要相应的高性能减速器来配套。

单级减速器结构简单、成本较低、体积小，因此目前仍为主流应用。但在高转速区间，单档减速器由于传动比单一，在最高或最低车速以及低负荷条件下，电驱动效率会下降，浪费电能而减少行驶里程，此外减速器高转速时会带来 NVH 等问题。

两档减速器在混动车中率先应用，纯电动车应用可以期待。相较于单档减速器，两档减速器一方面使驱动电机在更高效的区域运行，从而提升驱动系统效率。另一方面，采用两档减速器后，传动比可以做到更高，汽车动力性随之增加、减少百公里加速时间。

此外，采用两个档位后，驱动电机可以更加小型化、低速化，从而降低电机及电控的成本。目前，采埃孚、GKN、麦格纳、Taycan 等企业均已推出两档减速器产品。

1.2. 小三电：OBC、DC/DC、PDU

“小三电”是 OBC、DC/DC、PDU 三大类电源产品，三者一同搭建了汽车内部的“能源网络”。OBC（充电机）负责将来自电网的交流电转换成直流电给电池充电；汽车电气电子系统中，不同部件需要的电压等级不尽相同，故需要 DC/DC（直流-直流变换器）转换电压；PDU（高压配电盒）负责内部“电气能源网架”的互联互通。

半导体器件成本占比较高，部分仍依赖进口。根据威迈斯招股说明书，在电源产品中，半导体器件、电容电阻为主要成本构成，占比分别为 23%和 16%。而由于半导体器件与部分电容产品国产化水平较低，多数公司仍采用外资供应商为主。例如，威迈斯主要供应商为 TI、英飞凌、意法半导体、贵弥功等，2016-2018 年公司进口原材料金额占比分别为 22.30%、19.96%、28.71%，其中 IGBT、MOSFET 海外主要供货商英飞凌占比最高，2016-2018 年采购金额占比分别为 3.18%、6.61%、7.28%。

技术持续演进，集成化趋势同样显著，软硬件能力都将迎来考验。早期车载电源产品主要采用模拟控制技术，产品功能较为单一，配套的软件只具备检测功能，不能实现精准控制。之后车载电源产品向数字化技术转变，能够实现复杂的控制算法，实现输出参数的灵活调整和精准控制，提高了软件系统的操控性，包括车载电源的诊断、升级和参数调整等应用需求。下一代车载电源产品将向集成化转变，在硬件、软件、体积、重量四个维度实现创新突破。硬件上有望将进一步采用更高性能的碳化硅器件；软件上将开发过程转换为模型化编程及满足 AUTOSAR 的接口方式，提升软件稳定性和灵活性；在体积和重量上实现小型化、轻量化。

1.3. 集成化：1+1+1 3，深度集成方兴未艾

1+1+13，电驱动由最初“结构集成”向“深度系统集成”演进，集成化“多合一”总成产品成为主流趋势。以往动力系统的电机、电控、电源多单独采购，根据其电气、机械结构进行集成组装；随着新能源汽车零部件要求不断提高，“多合一”总成产品通过巧妙设计将电机、电控、减速器、电源“深度集成”，减少彼此间的连接器、冷却组件、高压线束等部件。“多合一”集成式系统相比分体式产品的优势主要体现在以下方面：

1）性能更优：降低了各部件之间连接部位的效率损耗，提高整车的 NVH 性能，从而提高了集成系统的可靠性；

2）成本更低：集成式电驱动系统可以减少车内部的高压线束、连接器数量，节约线束与连接器成本，从而使集成式系统更具有经济性。

3）更省空间：集成式产品体积更小、重量更轻，有利于节省车内空间。

集成化电驱动系统渗透率不断提升。根据 NE 时代新能源，2020 年/2022 年 1-4 月我国新能源乘用车“三合一”电驱动系统搭载量为 50.27/79.26 万台，渗透率为44.91%/61.63%，目前基本涵盖大部分 A 级车、B 级以上车型。

现有集成产品以“三合一”为主，集成度更高的“多合一”新产品也在不断问世。

根据 NE 时代新能源，2022 年 1-4 月新能源乘用车搭载的电驱动系统中，分体式、电机/电控“二合一”合计占比为 44%，“三合一”占比为 52%，“多合一”占比为 4%。同时，OBC、DC-DC、PDU 等充配电系统集成产品应用也不断增加，结合电驱系统集成产品将形成集成度更高的多合一平台。

华为 DriveOne“七合一”电驱动系统打造多合一集成新标杆，比亚迪和上汽变速器也陆续推出多合一产品。

1）华为七合一系统集成了 MCU、电机。减速器、DC-DC、 OBC、PDU、BCU 七大部件，具有开发简单、适配简单、布置简单、演进简单等优势。

相较于“三合一”，该产品体积减少 20%、重量减轻 15%。此外，华为 DriveOne 系统可实现 7dB 的超静音，并具有 80%NEDC 效率，提升整车驾驶体验。根据 NE 时代新能源，华为“三合一”电驱动总成已在长安 CS-GXNEV 和赛力斯 SF5 两款车型中得到应用，但目前其七合一产品还没有在整车中的应用案例。

2）比亚迪“海豚”八合一系统即成立VCU、BCU、PDU、DC-DC、OBC、MCU、电机、减速器八大部件；

3）上汽变速器威迈斯的七合一系统集成电机、电控、减速器、OBC、DC-DC、PDU、BCU 七大部件。

1.4. 总结：千亿空间市场广阔，技术变革推动天花板不断打开

据前文所述，新能源汽车电驱动、电源系统围绕“高效率区间、高功率密度”等核心性能，其技术迭代仍在演进，而且针对不同车企、不同车型大多需要“量身定制”。

截至 2022 年 4 月，国内电动车销量结构成“纺锤形”——B 级和 A00 级车型销量占比较高。分车型来看电驱动技术，1）A/B 级及以上中高端车型通常因价格较高、可降本空间大，性能要求高，故对“三合一”乃至“六合一/七合一”等更青睐，扁线、碳化硅有望率先在中高端车型进行渗透。2）A00/A0 级的低端车型对成本要求更高，故倾向于采购分体式产品，部分也会采用成本低的“三合一”。即使对同一级别车型，不同车企及电动化平台均有各自技术架构，需要电驱动企业去配合设计，故当前定制化水平仍较高。

1）技术变革带动需求结构变化：在电机技术方向上，扁线电机渗透率有望在未来5 年快速提升，我们假设 2025 年在电驱三合一市场的综合渗透率将达到 87%；在单车配套电机数量上，双电机目前仍主要应用于高端车型，我们假设 2025 年双电机在电驱三合一市场综合渗透率将达到 5%。在电控方向，由于碳化硅性能优势较强，近年应用增长较快，考虑其降本速度，我们假设碳化硅电控渗透率稳步提升、2025 年在电驱三合一市场综合渗透率达到 26%。

2）规模化带动价格下降：电机方面，扁线电机厂家近年产能扩展迅猛，我们预计规模化将带动价格快速下降，同时随着扁线电机渗透率提升，与圆线电机价格差异持续缩小，经济性更为突出；电控方面，碳化硅同样持续降本。

3）集成化占比提高：我们将电驱动电源市场分为分布式、二合一、三合一（含少量“多合一”），我们假设“三合一”渗透率不断提升、2025 年达到 59%（基本覆盖 A 级及以上的车型）

行业参与者可分为“三大阵营”：整车厂自供体系、动力系统集成商、第三方电驱动供应商。

1）整车厂自供体系（in-house）：出于供应链安全、成本控制等考虑，整车厂多设立子公司或合资公司自供电驱动、电源产品，代表公司有特斯拉、比亚迪旗下的弗迪动力、蔚来旗下的蔚然动力、长城旗下的蜂巢能源等。

2）动力系统集成商（Tier1）：通常为海外汽车零部件巨头，如联合电子、日电产、博世、大陆、博格华纳等，凭借深厚的技术、工艺等积淀拓展至新能源汽车领域，本身产品力强、产能规模大，且具备全球主流车企客户资源。

3）第三方电驱动供应商：近年来快速崛起，独立第三方根据业务侧重点可以分为电控为主、电机为主的厂商，但是在集成化的趋势下，企业通常会同时布局电机、电控、电源与“多合一”系统。根据公司业务结构差异，又可分为以下几类：

1）整车厂自制 VS 向第三方外采：

我们认为，未来 5-10 年仍将是自主品牌与新势力车企崛起的机遇期。一方面由于新能源汽车更新换代速度要高于传统燃油车，相比外资品牌，自主品牌的“包袱”更小，能够更加快速地进行变革。另一方面，新能源汽车扎根本土，对消费者需求有更深刻的认知，可以敏锐捕捉到消费者需求变化并快速响应。

上述核心车企采购逻辑（自制 or 开放供应链）影响了第三方可触及的市场空间。

对于前述的“中高端、中端、中低端”市场，车企通常有各自的采购偏好：

2021 年/2025 年第三方供应商总体销量份额为 40%/60%。整车厂前期因新能车出货量相对不大，部分车企选择自制电驱动/电源系统，但后期随新能源车年销量过百万辆、车型品类丰富等，对自制体系的成本控制能力、快速研发能力、产能等都提出较大挑战。届时，我们预计第三方凭借技术平台完备，以标准化促定制化开发，叠加定点车型销量较大，规模效应强劲，在成本、开发速度、产能方面均具备更强竞争优势。不同于燃油车，电池、电驱作为新能源汽车中最重要的板块，如果全部外包给第三方供应商，那么留给车企的参与环节将大幅减少，这将不断降低产业壁垒，缩小盈利空间，因此从整车厂的经营战略来考虑，部分车企未来仍会坚持“部分自供”。综上，我们预计多数整车厂在性能要求苛刻的中高端平台（B 级及以上）部分采用自供体系、部分外供，中端、中低端市场的车型开放供应链给第三方。结合上一节不同品牌车的销量占比数据，我们测算 2021 年第三方供应商总体销量份额约 39.96%，至 2025 年份额有望提升至 60.38%。

2）第三方供应商竞争焦点（第三方 VS 第三方）：

国内主流厂家在技术上和海外 Tier1 的差异在逐步缩小。海外 Tier1 在传统车零部件研发生产上走在世界前列，但是近年来我国电驱动供应商在技术上不断实现突破，与国外先进水平差距逐步缩小，核心性能基本与海外 Tier1 相差不大，在新技术路线的布局方面也处于同一起跑线甚至领先一步。

高压化（基于碳化硅的电驱动产品）：在电机方面，方正电机基于 800V 碳化硅平台的驱动电机目前已完成客户项目定点，有望于 2022Q3 量产。在电控方面，日立为保时捷 Taycna 提供了基于 Si-IGBT 技术的 800V 的逆变器。在电驱动总成方面，汇川技术、臻驱科技、中车时代等都已推出了应用碳化硅的驱动集成产品，其中汇川的第四代动力总成已在小鹏 800V 高压平台车型中实现量产。

扁线电机：方正电机、大洋电机、华域电动等生产的扁线电机均已得到应用，例如方正电机产品已量产配套蔚来 ET7，大洋电机已量产配套北汽 48V BSG。

AUTOSAR规范与车用控制器软件开发（autosar规范与车用控制器软件开发pdf 百度网盘）

汽车开放系统架构AUTOSAR

AUTOSAR简介：

AUTOSAR(汽车开放系统架构)，汽车开放系统架构联盟是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立，各成员保持开发合作伙伴关系。自2003年起，各伙伴公司携手合作，致力于为汽车工业开发一个开放的、标准化的软件架构。AUTOSAR这个架构有利于车辆电子系统软件的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。此外，AUTOSAR在确保产品及服务质量的同时，提高了成本效率。

AUTOSAR应用：

宝马集团自2001年即开始在称为BMW Standard Core的架构下，在ECU电子控制单元中运用标准化基础软件。该软件覆盖车辆管理系统各个层面的功能，包括执行(如车辆能量流管理系统、停车准备功能)，系统管理(如系统的编码与诊断)，到系统定制(如个性化定制功能，可设定特殊条件的服务定制功能)。

现在，应用于全新7系的BMW Standard Core软件系统通过AUTOSAR架构实现对车载网络、系统内存管理以及大部分的系统诊断功能。此外，全新BMW 7系所采用的多个ECU的运行系统与AUTOSAR架构相匹配，允许各应用程序独立运行。例如中央网关，该ECU确保了外部I/O系统(以太网和CAN总线)与内部I/O系统总线(CAN，MOST，FlexRay)间高速宽带连接。同时它还可以调节一些内核功能，如车况监测、系统编码和能量消耗检测等。

关于ECU电子控制单元未来的发展，宝马集团坚定地支持应用、推广AUTOSAR架构。一个精心制定的计划已经开始实施，相关的供应商也被纳入相关规划。针对驱动系统、底盘、安全系统、内部和车身的研发应用已经全面展开。

在Elmar Frickenstein看来，AUTOSAR架构的优势显而易见：“未来的车型将普遍受益于全行业统一的标准化程序，以及通用性、互换性更强的软件。AUTOSAR界面的标准化以及供应商通用工具软件的应用将促进该领域的进一步发展。

AUTOSAR在中国：

国内的各大汽车厂商、科研院校也越来越关注AUTOSAR带来的标准化的设计、开发、验证，从而大幅提高汽车电子的研发效率和研发质量。

一汽、长安等整车厂技术研究院也于2009年开始利用AUTOSAR标准的工具进行ECU的设计、开发、验证。

值得注意的是，普华基础软件股份有限公司（iSOFT），作为Autosar的成员，已经在中国联合上汽、一汽、长安、奇瑞等主要OEM和部分院校成立了CASA联盟，旨在中国推广和发展Autosar架构。普华已具备一些列基于Autosar的工具链，如OrientaisStudio，BSW配置工具。

汽车开放系统架构AUTOSAR @2019

奔驰聊聊执行器哪些事

操作系统，中间件，应用软件-各司其职分工不同

操作系统-我负责对硬件，提供线程创建等服务，其他我不管

中间件-我负责和不同操作系统对接，并给上面应用提供通讯，资源管理等服务，其他我不管

应用软件-嗯，剩下都我的事，我管功能，不同系统，不同硬件的事我不管。

中间件(middleware)是基础软件的一大类，在操作系统、网络和数据库之上，应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。在不同的技术之间共享资源并管理计算资源和网络通信。

另外中间件的定位不是操作系统，而是一套软件框架，虽然包括了RTOS，MCAL，服务通信层等协议和服务。两者看着很接近，但没有多少竞争关系。

什么是汽车软件中间件？

随着汽车应用要求的不断提高，软件总量也随之迅速增长，这导致了系统的复杂性和成本的剧增，为了提高软件的管理性、移植性、裁剪性和质量，需要定义一套架构( Architecture )；方法学( Methodology )和应用接口( Application Interface )。从而实现标准的接口、高质量的无缝集成、高效的开发以及通过新的模型来管理复杂的系统。

目前在汽车控制领域有多种总线标准，各侧重点有所不同。尽管总线通信速度越来越高，但是还没有通信网络可以完全满足未来汽车的所有成本和性能要求，因此需要兼容多种总线和底层协议的通信协议和规范。

中间件的核心思想在于“统一标准、分散实现、集中配置”。统一标准才能给各个厂商提供一个通用的开放的平台；分散实现则要求软件系统层次化、模块化，并且降低应用与平台之间的耦合度；不同模块来自不同的厂商，它们之间存在复杂的相互联系，要想将其整合成一个完善的系统，必须要求将所有模块的配置信息以统一的格式集中管理起来，集中配置生成系统。

这个架构还需要具备如下功能：解决汽车功能的可用性和安全性需求；保持汽车电子系统一定的冗余；可以移植到不同汽车的不同平台上；实现标准的基本系统功能作为汽车供应商的标准软件模块；通过网络共享软件功能；集成多个开发商提供的软件模块；在产品生命期内更好地进行软件维护；更充分地利用硬件平台的处理能力；可实现汽车电子软件的更新和升级等。

汽车软件中间件有什么好处？

所有把标准统一后的服务的优势都大同小异，总结主要几点

跨配置，跨车型，跨平台，跨硬件适应

提高了效率，软件开发聚焦差异化

软件认证有标准可依

方便行业软件互换，降低进入门槛

更简单的集成已有工具链，支持从设计到代码全流程

对于Autosar，说实话，最有利的是OEM和基础软件公司，OEM可以标准化接口，自己做应用层或找软件公司开发应用，基础软件公司可以多卖软件。最不愿意的是tier1，因为增加了成本，还逐步可能沦为硬件生产商。但这个也不能说是autosar的锅，软件定义汽车下这个趋势的发展是必然的。

汽车软件中间件有什么缺点？

老实讲，这块大家讲的很少，都说这个很美好，但实际操作过程中，我觉得是软硬件一体设计上的阻碍。

值得注意的像Tesla这样的新兴企业并没有使用autosar这是为什么？所有平台性的软件，都有一个弊病，就是为了兼容一致性，会对软硬件协作的效率带来影响，autosar也不例外。

我感觉“Autosar就是汽车行业的塞班系统，看似很好，很标准，但是最终会被淘汰。就像当年的诺基亚一样，原因是最后会被一个软硬件集成度更好的iphone取代，iphone可不纠结能够给其他公司用自己的系统。

从商业和成本角度看

Autosar设计上已经有些落后，代码臃肿，对成本影响很大。打个比方，北美一个程序员一年的cost也就是15万美金，自己完成底层的开发就这个价，使用Autosar的工具链和代码臃肿带来的升级MCU开销远大于节省的这部分开发成本。细分Autosar的成本：

1.开发成本:首先需要购买autosar，本身就是成本，autosar包含的模块多，肯定要贵，但不一定所有的都会被用上。其次是人力投入，对于一个原来就有其他平台的新的第一个项目转换到autosar是增加人力的，对于新公司，购买autosar是降低人力的，很多模块不用自己开发了。对于建立平台以后的项目，实际差不多。

2.生产成本:首先是硬件成本，现在MCU越来越便宜，用不用autosar基本没区别，如果说存储空间特别小的MCU，比如防夹模块，本来也没要求autosar。其次是软件成本，这个才是问题，跟以前基础软件不同autosar现在收量产license费。

从技术角度看

关于autosar的应用，autosar之前定义的主要就是BCM、TCU、EMS、ESP等要求实时控制的ECU。不是针对娱乐系统，自动驾驶MPU的，当然这些控制器里也有MCU，可以用运行autosar的MCU。autosar现在最擅长的是16bit MCU以及不太复杂的32bitMCU。32bit以上的MCU，需要RTOS支持，比如自动驾驶软件。车的中控也不可能基于autosar,也是因为没有一个强有力的RTOS，在越来越强调security的软件开发中，AUTOSAR也没有进程隔离的概念。前景难料.

中间件的明星方案-AUTOSAR

所有中间件方案中，最著名的是AUTOSAR, 其是由各大整车厂商和零部件厂商开始着手联合制定软件的标准化接口。AUTOSAR(AUTomotive Open System ARchitecture)是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业(如BMW、BOSCH、Continental、DAIMLER、Ford、OPEL、PSA、TOYOTA、VW等)共同制定的汽车开放式系统架构标准。

2003年7月，由宝马、博世、大陆、戴姆勒-克莱斯勒、西门子VDO和大众联合成立AUTOSAR发展联盟，为汽车E/E架构建立了一种开放式的行业标准。

2003年11月，福特公司作为核心伙伴加入，12月标致雪铁龙和丰田汽车加入。接下来的11月通用汽车也作为核心伙伴加入。自从西门子VDO被大陆在2008年2月收购后，它就不再作为AUTOSAR的独立核心伙伴。

第一阶段（2004-2006）：标准基本开发时期（版本1.0.2.0和2.1）

第二阶段（2007-2009）：体系和方法相关方面扩展（版本3.0，3.1和4.0）

第三阶段（2010-2013）：可维护性和可选择性的改进（版本3.2，4.1和4.2）

在2013年，AUTOSAR联盟进入一种持续改进模式，主要用来维持标准和提供所选择的改进,往后实际上，autosar更新就很少了，开始转向AUTOSAR-Adaptive。

AUTOSAR-Adaptive拯救AUTOSAR

对于用于实现典型动力总成和底盘功能的深度嵌入式系统，AUTOSAR经典平台仍将是首选。在低成本硬件上运行时，对安全性、实时性和确定性要求较高。同时，AUTOSAR为这些应用程序提供了一个经过良好验证的成熟软件平台，包括一个广泛使用的方法，它支持当今所有的协作模型。而为了支持客户应用程序的动态部署，并为需要高端计算能力的应用程序提供环境，AUTOSAR在2017年推出了第二个软件平台，即AUTOSAR Adaptive platform。这个想法是尽可能从其他领域(如消费电子产品)的发展中获益，同时仍然考虑汽车的特定要求，如功能安全。

Adaptive需要支持，未来E/E架构的两个关键特征是：

1) 异构软件平台的集成，当今汽车的网络架构可以聚集成不同的领域，用于信息娱乐和连接、底盘、动力系统等。虽然infotainment ECUs通常使用Linux、QNX或其他通用操作系统，但AUTOSAR Classic平台是深度嵌入式控制单元的标准。随着新的用例和对计算能力的深入嵌入式应用程序不断增长的需求，第三种ecu将出现，它具有不同的特性，必须集成到现有的E/E体系结构中。

2) 面向服务和基于信号的通信，传统的汽车通信仍然是基于ecu向其他ecu提供信号广播的思想。这种范式非常适合于有限大小的控制数据，这些数据必须循环地进行通信。先进的应用程序，如高自动化驾驶与更高的负载要求，例如交换对象列表检测到的一组传感器和以太网作为一个通信系统需要更复杂的协议。面向服务通信的概念是基于在通信系统上提供服务的应用程序和订阅此服务的其他应用程序。然后数据只发送给订阅服务器。

面向服务的通信与现有的基于信号的范式的结合是未来E/E体系结构的第二个关键方面，从这个角度来看，这是一个艰巨的挑战。

为了解决AUTOSAR僵化的问题，Adaptive希望可以找到一种中间过程平台

ADAPTIVE为承载这些功能的软件基础设施增加了新的需求。除了现有的需求(如功能安全和安全性)，软件架构还必须支持硬件(如具有高端计算能力的硬件)、空中更新、与后端系统的通信或应用程序的动态部署。

AUTOSAR Adaptive扩展了AUTOSAR平台，以满足当前汽车自动驾驶、电气化和互联互通等趋势的需求。因此，它在许多方面改变了已建立的E/E开发过程。最重要的变化是，基于信号的通信被面向服务的设计所取代。c++取代了C语言作为自适应应用程序的编程语言，以及基于posix的操作系统(如Linux用于自适应电子控制单元)是进一步的突破性转变。

AUTOSAR Adaptive 组件封装了SOA软件底层的通讯细节(包括SOME/IP协议，IPC等)，同时提供代理(Proxy)-骨架(Skeleton)模型，该模型以C 面向对象语言描述，方便上层应用开发人员调用标准服务接口(API)进行开发。Application Design Model是该模型另一种可配置的呈现，开发人员通过使用相应的配置工具对Application Design Model进行描述和配置，即可实现基于SOA服务架构的软件落地和部署。联合电子使用AUTOSAR Adaptive组件完成SOA服务架构软件的开发

可以看到，自适应Autosar又找到了延续自己生命的另外一个理由，提供了一种由现在信号导向的架构往SOA架构的标准。未来由于控制器数量大幅度降低, 类似特斯拉这样的车企多半是不理会自适应AutosarAdaptive

与此同时，更多的相关配套供应商也在加快与AUTOSAR自适应平台的对接。去年11月，Real-Time Innovations（RTI）宣布，AUTOSAR最新版本的自适应平台（版本18-10），已经具有数据分发服务(DDS)标准的完整网络绑定。这意味着汽车制造商现在可以使用DDS实现AUTOSAR自适应框架，并开发高度自动驾驶系统，如4级和5级。DDS允许AUTOSAR完全支持高度自动驾驶系统，并提供“量产级通信框架”，保证这些复杂系统所需的可靠性、可伸缩性和性能。比如，在AUTOSAR中完全指定了DDS之后，汽车行业现在可以使用RTI Connext和DDS开发高性能应用程序，比如传感器融合应用程序。

AUTOSAR版本18-10有助于解决OEM软件开发团队在支持不同价格区间车型时所面临的各种安全和连接性挑战。此外，允许开发人员“动态配置平台”，以支持每个车型平台的各种操作模式和硬件功能。

技术细节-AUTOSAR的分层设计

架构层面

AUTOSAR定义一个软件分层架构以支持汽车电子系统的集成。其体系架构从上至下依次为应用层、运行环境层(RTE)、以及基础软件层（BSW)

接着再复杂一些，BSW再分为复杂驱动模块，微控制器抽象层、ECU抽象层、系统服务层

(1)应用层。包括应用软件组件、传感器和执行器软件组件，都位于应用层。该层的软件组件通过RTE进行内部通讯和访问ECU资源。应用层的软件实现独立于微控制器、ECU。

(2)RTE层。RTE层为应用层提供通讯服务。RTE层的实现与ECU和具体应用相关，必须为每个ECU分别实现，AUTOSAR软件组件之间通信需要通过RTE。

(3)服务层。包含RTOS、通信与网络管理、内存管理、诊断服务、状态管理、程序监控等服务。它为应用和基础软件模块提供基本服务，包括：操作系统服务、汽车网络通讯和管理服务、存储服务、诊断服务和ECU状态管理。服务层的实现部分与微控制器、ECU和具体应用相关。

(4)ECU抽象层。ECU抽象层抽象出ECU结构，如外设与ECU的联接方式等．虽然该层与ECU平台相关，但是与微控制器是无关的。这种无关性是由微控制器抽象层来实现的。其中封装了微控制器层及外围设备的驱动，并对微控制器内外设的访问进行了统一，实现了软件应用层与硬件系统的分离

(5)微控制器的抽象层(microcontroller abstraction layer，MCAL)。位于基础软件的最底层，包含了访问微控制器的驱动（如I/O驱动、ADC驱动等），做到了上层软件与微控制器的分离，以便应用的后续的移植复用。微控制器的抽象层是实现不同硬件接口统一化的特殊层，通过微控制器的抽象层可将硬件封装起来，避免了高层软件直接与微控制器的寄存器打交道。MCAL提供消息机制，并以此将指令、响应和信息分离成不同的过程。微控制器抽象层包括微控制器相关的驱动，它负责管理微控制器的外部设备，并将微控制器的信号提供给基础软件的元件。

(6)复杂驱动层，由于其严格的时序为应用层通过RTE访问硬件提供支持。

再复杂一些

再再复杂一些

接着我们从RTE层往上看

运行时环境( RTE )是应用软件和基础软件通信的桥梁，无论通信发生在 ECU之间( 如通过CAN、LIN、FlexRay、MOST等网络) ，还是在ECU内部，RTE均通过提供一致的接口和服务来实现SWC之间的通信抽象，其最终实现会因ECU的不同而有所差异。一般情况下，每一层只能使用下一层的接口，并向上一层提供服务接口。

应用层中的功能由各软件组件（SWC）实现，组件中封装了部分或者全部汽车电子功能，包括对其具体功能的实现以及对应描述，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。

在设计开发阶段中，软件组件通信层面引入了一个新的概念，虚拟功能总线VFB（Virtual Functional Bus），它是对AUTOSAR所有通信机制的抽象，利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，甚至ECU内部或者是与其他ECU之间的数据传输。

因此软件组件只需向VFB发送输出信号，VFB将信息传输给目标组建的输入端口，这样的方式使得在硬件定义之前，即可完成功能软件的验证，而不需要依赖于传统的硬件系统。

中间件RTE与面向对象OO（object oriented）的编程思想非常接近，所有ECU所对应的RTE都是特定的，它负责着软件构件间以及软件构件与基础软件之间的通信。对于软件构件来说，基础软件不能够直接访问，必须通过RTE进入。因而RTE也被理解成是VFB的接口实现。

而构件之间及构件与基础软件的通信关系如图所示：

AUTOSAR软件构件无法直接访问基础软件中的操作系统OS，因而在应用程序中就不存在「task」的概念，且不能动态创建线程，因此并行的任务由RTE直接管理调入的「构件运行实体」来实现。每个软件构件也许会有一个或者多个运行实体，但是一个运行实体只对应一个入口。

方法学层面

「AUTOSAR方法论」是指在汽车电子系统开发的某些步骤中所需要的通用技术方法。

1、但AUTOSAR方法既非完整的过程描述也不是商业模式，也没有定义「角色」和「责任」。

2、方法论仅是一个work-product flow，并定义了其中的依赖关系。

根据AUTOSAR方法论，完整的基于AUTOSAR规范的配置生成过程分为以上图示两部分，即系统配置过程及ECU配置过程。两者之间并无先后关系，系统配置过程中的输入包内含有ECU配置的相关模块，ECU配置也会反馈于系统配置。

系统配置过程：

系统配置输入（System Configuration Input）必须被定义好，AUTOSAR倾向于通过信息交换格式（软件构件、ECU资源、系统限制）以及模版来减少这些厨师系统设计决定的正式描述。模板包含三部分：

软件构件的描述：定义每个需要的软件构件的接口内容，如数据类型、端口、接口等

系统约束描述：如总线信号的定义、拓扑结构与软件构件之间的映射关系

ECU资源描述：定义每个ECU的资源需求，如处理器、外部设备、存储器、传感器以及执行器

配置步骤如下

输入的系统配置文件借助配置系统（configure-system）将软件构件映射到资源与计时要求相关的ECU上，所得到的文件就是系统配置描述文件（system configuration description）。其中包含了软件构件与ECU映射时所需注意的限制条件，以及通信矩阵（Communication-Matrix），矩阵中描述了整车网络结构中的数据包内容及其时序关系。

ECU配置过程

系统配置完成后，生成了系统配置描述文件，作为ECU配置过程的输入。

Extract ECU-Specific Information会负责从系统配置文件中剥离出各ECU相关的系统配置信息，如通信矩阵、拓扑结构、顶级功能组合，生成到ECU Extract of System Configuration中。

Configure ECU的是生成包含了特定ECU局部信息的ECU Configuration Description，而这些信息可以构件该特定ECU的可执行软件。

Generate Executable根据从ECU Configuration Description中得到的信息生成可执行程序。

AUTOSAR 的特性使得当ECU底层硬件配置升级时，也并不一定要牵动其他软件系统，正因其统一的标准规范，越来越多的企业将会加入到其中，这也为未来汽车电子行业内高效管理以及复用愈加复杂的汽车软件系统奠定了基础。

AUTOSAR 中SWC(Software Component Description)包含下列信息: 该SWC用到或被用到的Operation和Data，SWC对基础构架(网络)和对硬件(延迟时间，定时等)的要求，SWC使用的资源 (存储器, CPU时间等)，运行机制(重复率)，SWC软件接口。

AUTOSAR中ECU Resource Description包含下列信息:描述使用到的硬件:传感器，执行器，存储器，处理器，通信外部设备（如收发器），引脚分配。

AUTOSAR中System Constraint Description中包含下列信息:网络拓扑，限制，协议，通信矩阵，波特率，定时，ECU映射。

系统配置主要是将端口数据映射到通信矩阵，将SWC映射到ECU。ECU配置主要是将runnable(可运行实体)映射到task(任务)中。对以上各项内容角色分工

接口层面

AUTOSAR各层软件的交互通过三类接口实现，分别是标准接口、AUTOSAR接口和AUTOSAR标准接口。其中，标准接口用于BSW各个模块之间的交互，已用C语言定义，如void Adc_Init (const Adc_ConfigType* ConfigPtr)。AUTOSAR接口用于软件构件（Software Component, SW-C）之间的交互或者软件构件和ECU硬件（IO硬件抽象、复杂设备驱动）之间的交互，这类接口命名以“Rte_”为前缀。AUTOSAR标准接口用于软件构件访问AUTOSAR服务。

依赖这种分层架构和接口定义，AUTOSR显著提高了汽车电子嵌入式软件的复用性——层级越高者，复用性越强。值得注意的是：

微控制器抽象层层级最低，随微控制器的更换而更换；

RTE虽然层级仅低于应用层，但由于它承担着应用层和BSW之间的桥梁作用，和硬件的耦合性最高，不具有复用性；

应用层(除传感器、执行器相关的软件构件外)完全独立于硬件，具有绝对的复用性。

AUTOSAR在定义软件架构和接口的同时。也定义了易于交换的硬件平台标准。AUTOSAR标准不仅提供了基础软件模块的规范。还提供了用于开发分布式系统应用软件的方法。这种方法以基于模型的软件和分布式系统描述开始。以自动代码生成和可重复的测试结束。

Autosar也定义了与网络总线接口相关的模块，CAN,LIN等网络总线接口驱动、诊断等。AUTOSAR的出现使得ECU中的软件包括网络总线通信软件第三方供货成为可能。未来的网络总线标准是否仍然各自独立、互不兼容，目前还无法断定，但AUTOSAR却实实在在地将部分标准公开化、标准化，兼容化，而且实际的产品也已经被应用，AUTOSAR已对现在相互之间封闭的网络总线标准形成挑战。

此外，AUTOSAR还定义了一套标准的软件开发流程，从系统建模到生成可执行的代码，包括软件组件设计、系统配置、ECU配置和代码生成三大流程，如图

技术细节-AUTOSAR ADAPTIVE架构介绍

活动推荐：

ICVS中国智能汽车及自动驾驶博览会，暨同期：中国智能汽车产业链展

2022年9月26-29日

江苏·苏州国际博览中心

30,000m²展览面积

100场会议演讲

500家参展企业

30,000专业观众

点击进入ICVS智能汽车产业联盟主页—进入菜单栏展会报名页面，即可免费领取参观门票，现阶段报名还将获取更多报告福利。

如何在c++定义一个学生类以实现平均成绩的计算和查询功能？

一．中间件的定义与作用

1.什么是中间件？

图片摘自公众号“筋斗云与自动驾驶”

笔者在交流中发现，不同的人对中间件的理解并不一样，甚至可以说，到现在，这个概念还是模糊不清的。比如：

（1）有的人认为中间件仅指位于OS内核之上、功能软件之下的那部分组件，为上层提供进程管理、升级管理等服务；而有的人则认为中间件还应包括功能软件和应用软件中间的那部分（参见上图）。按茅海燕的说法，前者是“通用中间件”，而后者是“专用中间件”。本文中提到的“中间件”，若不做专门说明，便特指“通用中间件”。

（2）有一些人提到的自动驾驶中间件，包括了AUTOSAR（又分为AUTOSAR CP和AUTOSAR AP），还有一些人口中的中间件，特指ROS2、Cyber RT、DDS等。

（3）未动科技VP萧猛认为，“中间”一词是相对的，当有多层堆叠的时候，每一层都是其上下两层的中间层，因此，在用“中间件”这个词的时候，我们需要特别指明它究竟位于“哪两层之间”。按萧猛的说法，当我们称“ROS/ROS2 为中间件”时，其含义与 “AUTOSAR AP为中间件”并不是对等的关系。

(4)Vector产品专家蔡守群说，他理解的中间件，“是给App开发提供功能支撑的，对外是没有功能表征的；但是站在操作系统内核的角度，中间件跟App并没有本质的区别”。

2.中间件的作用

汪浩伟说：“专用中间件原本是应用程序的一部分，只是很多公司做自动驾驶都需要用到，就被抽象出来了。”

那么，它究竟有什么用？

毕晓鹏认为，自动驾驶中间件最主要的作用是：对下，它能够去适配不同的OS内核和架构；对上，它能够提供一个统一的标准接口，负责各类应用软件模块之间的通信以及对底层系统资源的调度。

据毕晓鹏解释，前者，使开发者们无需考虑底层的OS内核是什么，也无需考虑硬件环境是什么，即不仅实现了应用软件与OS的解耦，也实现了应用软件与硬件的解耦；而后者则确保了数据能够安全实时地传输、资源进行合理的调度。

为什么要通过中间件来支持软硬件解耦？毕晓鹏解释道：

我开发一个应用软件，其中很多内容都是与具体应用逻辑无关的，包括数据通信、通信安全、系统资源调度等，比如，有十个进程需要数据交互，完全没有必要在十个程序的软件代码里各自进行实现和配置。针对这种情况，我们就可以把重复的部分抽象成一种服务，单独封成一层东西（这就是中间件），并提供统一的库、接口和配置方法，供上层去调用。这样的话，有一部分人专门去做中间件的，而做上层应用的人也不需要考虑跟底层交互的事情。

举例说，如果要做一个自动泊车系统，它有各个模块或业务逻辑独立的不同软件，在进行通信、数据交互，或者调用底层资源时，只需要中间件的一个接口就可以实现，其他事情不需要考虑，这样开发人员就可以专注于自己的业务逻辑。

又比如，一个摄像头需要感知前面的车道线、红绿灯等，开发人员就专门做红绿灯和车道线检测算法，与外界的数据交互只需要使用中间件的通信服务（例如订阅摄像头信息，发布检测结果），而不必关心数据从哪里来、发给谁。

Nullmax纽劢科技系统平台总监苗乾坤博士在此前的一篇文章中写道：

“芯片算力大幅增长，摄像头像素呈翻倍之势，激光雷达出现在更多新车规划上……没有谁能够断言车上的传感器应该有多少，又或者是将来的汽车还会增加哪些硬件，但所有人都知道硬件的变化将会来得更加猛烈。

“所以我们也可以看到，汽车对软硬件架构的要求也越来越高，既要能满足当下的需求，还要具备相当的前瞻性、兼容性和扩展性，能够支持接下来软硬件升级换代、增减模块的需求。而自动驾驶的中间件，就正是这样一个可以按需调整、满足各样需求的现代温室。

“在早期开发中，中间件可以化整为零，将巨大的软件工程分解成若干小任务，分散解决。在后期应用时，它又可以化零为整，像拼积木一样，根据需求将一个个模块组合成一个整体，严丝合缝。”

在春节前的一场直播中，东软睿驰产品销售总监安志鹏说，在软硬件解耦、模块化管理后，再遇到问题，就不用整个系统都改，只改相对应的部分就行了。这样，软件的可复用程度就极大地提升了，同时，验证的工作量也会减少许多，整体开发效率也会因此提升。

相反，没有中间件的话，应用层就得直接调用操作系统的接口，后期要是换了操作系统，应用层的代码和算法可能就要推倒重来。

简言之，中间件通过对计算平台、传感器等资源进行抽象，对算法、子系统、功能采取模块化的管理，并提供统一接口，让开发人员能够专注于各自业务层面的开发，无需了解无关细节。

按东软睿驰产品销售总监安志鹏的说法，搞AUTSOAR这样的中间件，并不是只对OEM有利，“零部件供应商的选择面也大了——应用做好了，下面的软件、芯片可以选好几家供应商的，要比传统的开发模式快很多，因而，零部件供应商也是受益者”。

用萧猛的话说，中间件最直接的好处就是“为上层屏蔽底层的复杂性”，软件开发人员可以忽略芯片、传感器等硬件的差异，从而高效、灵活地将上层应用及功能算法在不同平台上实现、迭代、移植。萧猛认为，中间件可以看做是自动驾驶应用背景下的一项“新基建”。

（图片摘自冯占军博士的《AUTOSAR对基础软件开发是喜还是忧？》一文。AUTOSAR只是中间件的一种，但这里写的“AUTOSAR开发优势”基本也适用于其他中间件。）

不过，站在开发者的角度看，中间件的意义也未必全部是正面的。如冯占军博士在《AUTOSAR对基础软件开发是喜还是忧？》一文中就提到了如下两点：

底层软件工程师变成了工具人，“只要你去点点鼠标，用工具配合就可以了”，很多原本由自己做的测试也改由供应商来做，进而导致工程师的成就感严重降低；时间久了，工程师从0到1开发的能力也会降低。

（图片摘自冯占军博士的文章。尽管文章说的是Autosar,但实际上这些问题在ROS等其他中间件的使用过程中也会存在。）

对软件工程师来说，中间件造成的“能力退化”这一问题几乎是无解的。但冯占军博士认为，“如果这个中间件在开发过程中，有使用公司的工程师深度参与，提出需求并一起实施，会好一些”。

此外，殷玮在一篇文章提到，使用AUTOSAR这样的中间件，Tier 1们应该是很不情愿的，“因为不到增加了成本，还有可能逐步沦为硬件生产商”。但这个也不能说是中间件的锅，在软件定义汽车大大趋势下，这几乎是必然的。

二．常见的基本概念

1. AUTOSAR CP 与 AUTOSAR AP

在所有的中间件方案中，最著名的非AUTOSAR莫属了。

严格地说，AUTOSAR并非特指由某一家软件公司开发出来的某款操作系统或中间件产品，而是由全球的主要汽车生产厂商、零部件供应商、软硬件和电子工业等企业共同制定的汽车开放式系统架构标准。不过，在实践中，各公司基于AUTOSAR标准开发出来的中间件也被被称为“AUTOSAR”。

当前，AUTOSAR可分为Classic Platform和Adaptive Platform两个平台，两者分别被简称为AUTOSAR CP与AUTOSAR AP。

简单地说，AUTOSAR CP主要跑在8bit、16bit、32bit的MCU上，对应传统的车身控制、底盘控制、动力系统等功能，如果涉及到自动驾驶的话，AUTOSAR CP可能无法实现；而AUTOSAR AP主要跑在64bit以上的高性能MPU/SOC上，对应自动驾驶的高性能电子系统。

严格地说，AUTOSAR CP并不只是个“中间件”，它是相当于“OS内核+中间件”的一套完整的“操作系统”。 AUTOSAR CP定义了基本的上层任务调度、优先级调度等。

在基于分布式架构的ADAS功能中，AUOTSAR CP便是最常见的“操作系统”。在AUTOSAR的生态形成后，很多芯片厂商的MCU上标配的就是AUTOSAR CP，主机厂没有什么选择权。

由于分布式架构下的芯片主要是MCU，因此，便有了“AUTOSAR CP主要跑在MCU上”的说法。

在分布式架构下，不同的功能对应着不同的MCU，而每一个MCU上都需要跑一套AUTOSAR CP，若传感器的类型比较多，则仅ADAS相关功能就需要很多套AUTOSAR CP，那怎么收费呢？

常规的做法是：根据MCU的类型来收费——如果MCU是两个异构的MCU，那AUTOSAR CP就按两套来收费；如果MCU是同构的，那AUTOSAR CP就按一套来收费。

随着EE架构从分布式向集中式演进、芯片由MCU向SOC演进，计算量及通信量成数量级地上升，另外，多核处理器、GPU、FPGA以及专用加速器的需求，还有OTA等，都超出了AUTOSAR CP的支持范围。

（图片摘自安志鹏的直播课）

2017年，为更好地满足集中式架构+SOC时代的高等级自动驾驶对中间件的需求，AUTOSAR联盟推出了通信能力更强、软件可配置性更灵活、安全机制要求更高的AUTOSAR AP平台。

需要强调的是，不同于AUTOSAR CP自身已经包含了基于OSEK标准的OS，AUTOSAR AP只是一个跑在Lunix、QNX等基于POSIX标准的OS上面的中间件——它自身并不包含OS。

结合aFakeProgramer于2020年发表在CSDN上的《为什么要用AP？Adaptive AutoSAR到底给企业提供了一些什么？》一文及东软睿驰安志鹏在2022年春节前的一场直播中讲的内容，AUTOSAR CP与AUTOSAR AP最主要的区别有如下几点：

1）.编程语言不同——AUTOSAR CP基于C语言，而AUTOSAR AP基于C++语言；

2）.架构不同——AUTOSAR CP 采用的是FOA架构（function-oriented architecture），而AUTOSAR AP采用的则是SOA架构（service-oriented architecture）；

3）.通信方式不同——AUTOAR CP采用的是基于信号的静态配置通信方式（LIN\CAN...通信矩阵），而AUTOSAR AP采用的是基于服务的SOA动态通信方式（SOME/IP）；

4）.连接关系不同——在AUTOSAR CP中，硬件资源的连接关系受限于线束的连接，而在AUTOSAR AP中，硬件资源间的连接关系虚拟化，不局限于通信线束的连接关系；

5）.调度方式不同——AUTOSAR CP采用固定的任务调度配置，模块和配置在发布前进行静态编译、链接，按既定规则顺序执行，而AUTOSAR CP则支持多种动态调度策略，服务可根据应用需求动态加载，并可进行单独更新。

6）.代码执行和地址空间不同——AUTOSAR CP中，大部分代码静态运行在ROM，所有application共用一个地址空间，而在AUTOSAR AP中，应用加载到RAM运行，每个application独享（虚拟）一个地址空间。

这些区别，带给AUTOSAR AP的优势有如下几点——

1）.ECU更加智能：基于SOA通信使得AP中ECU可以动态的同其他ECU同其他ECU进行连接，提供或获取服务；

2）.更强大的计算能力：基于SOA架构使得AP能够更好地支持多核、多ECU、多SoCs并行处理，从而提供更强大的计算能力；

3).更加安全：基于SOA架构使得AP中各个服务模块独立，可独立加载，IAM管理访问权限；

4).敏捷开发：Adaptive AUTOSAR服务不局限于部署在ECU本地可分布于车载网络中，使得系统模块可灵活部署，后期也能灵活独立更新（FOTA）；

5).高通信带宽：可实现基于Ethernet等高通信带宽的总线通信；

6).更易物联：基于以太网的SOA通信，更易实现无线、远程、云连接，方便部署V-2-X应用。

（图片摘自东软睿驰）

当然了，在某些方面，AUTOSAR AP与AUTOSAR CP相比是有一些“劣势”的。比如，AUTOSAR CP的时延可低至微秒级、功能安全等级达到了ASIL-D，硬实时；而AUTOSAR AP的时延则在毫秒级，功能安全等级则为ASIL-B，软实时。

上述区别也导致了两者应用领域的不同：AUTOSAR CP一般应用在对实时性和功能安全要求较高、对算力要求较低的场景中，如引擎控制、制动等传统ECU；而AUTOSAR则应用在对实时性和功能安全有一定要求，但对算力要求更高的场景中，如ADAS、自动驾驶，以及在动态部署方面追求较高自由度的信息娱乐场景。

尽管AUTOSAR AP有种种优点，但总的来说，它目前还不够成熟——主要是信息安全及UCM等模块不成熟。量产车上装AUTOSAR AP的不少，但主要用在娱乐场景，真正用在自动驾驶场景的还很少。

此外，由于SOC+MCU组合的现象会长期存在，因而，在今后相当长一段时间内，AUTOSAR AP都不可能彻底取代AUTOSAR CP——最常见的分工会是，需要高算力的工作交给AUTOSAR AP,而需要高实时性的工作则交给AUTOSAR CP。

（图片摘自超星未来）

2.ROS 2

ROS是机器人操作系统（Robot Operating System）的英文缩写，原生的ROS本是机器人OS，并不能直接满足无人驾驶的所有需求，用作自动驾驶中间件的是ROS 2。

ROS 2与ROS 1的主要区别如下：

（1）.ROS 1主要构建于Linux系统之上，主要支持Ubuntu；ROS 2采用全新的架构，底层基于DDS(Data Distribution Service)通信机制，支持实时性、嵌入式、分布式、多操作系统，ROS 2支持的系统包括Linux、windows、Mac、RTOS，甚至是单片机等没有操作系统的裸机。

（2）.ROS 1的通讯系统基于TCPROS/UDPROS，强依赖于master节点的处理；ROS 2的通讯系统是基于DDS，取消了master，同时在内部提供了DDS的抽象层实现，有了这个抽象层，用户就可以不去关注底层的DDS使用了哪个商家的API。

（3）.ROS运行时要依赖roscore，一旦roscore出现问题就会造成较大的系统灾难，同时由于安装与运行体积较大，对很多低资源系统会造成负担；ROS2基于DDS进行数据传输，而DDS基于RTPS的去中心化的通信框架，这就去除了对roscore的依赖，系统的稳定性强，对资源的消耗也得到了降低。

(4).由于ROS 缺少Qos机制，topic的稳定性与质量难以保证；ROS2则提供了Qos机制，对通信的实时性、完整性、历史追溯等功能有了支持，这便大幅加强了框架功能，避免了高速系统难以适用等问题。

不过，ROS2的QoQ配置较为复杂，目前主要是国外一些专业的大学或实验室在使用,国内仅有极少数公司在尝试;此外，ROS 2的生态成熟度远不如ROS,这也给推广应用带来了不便。

跟AUTOSAR AP一样，ROS 2也是跑在soc芯片上、用于满足高等级自动驾驶的需求的。不过，萧猛在去年的一批文章中却特别强调：当我们称 “ROS/ROS2 为中间件”时，其含义与 “AUTOSAR AP为中间件”并不是对等的关系。

萧猛的文章称：

当我们说 AutoSar是中间件时，这个中间件是很明确的 L.BSW层语义，即处于计算机OS与车载ECU特定功能实现之间，为 ECU功能实现层屏蔽掉特定处理器和计算机OS相关的细节，并提供与车辆网络、电源等系统交互所需的基础服务；

ROS/ROS2 是作为机器人开发的应用框架，在机器人应用和计算机OS之间提供了通用的中间层框架和常用软件模块(ROS Package)，而且， ROS团队认为这个框架做得足够好，可以称作操作系统（OS）了。

ROS 2尽管在功能上跟AUTOSAR AP有不少重叠之处，但两者的思路是不一样的：

（1）.从表现形式上看，AUTOSAR AP首先是一套标准，这个标准定义了一系列基础平台组件，每个平台组件定义了对应用的标准接口，但没有定义实现细节，和平台组件之间的交互接口（这些部分留给AUTOSAR AP供应商实现）；ROS2则从一开始就是代码优先，每个版本都有完整的代码实现，也定义有面向应用标准API接口。

（2）AUTOSAR AP从一开始就面向ASIL-B应用；ROS 2不是根据ASIL的标准设计的，ROS 2实现功能安全的解决方案是，把底层换为满足ASIL要求的RTOS和商用工具链(编译器）。

ROS 2“过不了车规”似乎已成为一个很广泛的行业共识。但在萧猛看来，ROS2本来就不是为实时域设计的，如果一定要把实时性要求高的车辆控制算法运行在 ROS2中，“那是软件设计的错误，而不是ROS2的问题”。

萧猛认为，只要能补齐 L.BSW层所需要完成的所有功能、补齐 A 轴所有切面要求的特性，ROS 2就能用于自动驾驶量产车。如前段时间刚拿到采埃孚等多家巨头投资的Apex.AI公司基于ROS 2定制开发的Apex.OS就已经通过了最高等级的ASIL D认证。

萧猛说：“这实际上是基于 ROS 2的架构去实现一套 AUTOSAR AP 规范。这可以成为一个单独的产品，投入时间+人+钱可以开发出来，只是看有没有必要，值不值得”。

在具体的实践中，ROS 2跟AUTOSAR AP存在直接竞争关系——尽管对用户来说，并不存在严格意义上的“二选一”问题，但通常来说，若选了ROS 2，就不会选AUTOSAR AP了；若选了AUTOSAR AP，就不会选ROS 2了。

3. CyberRT

Cyber RT是百度Apollo开发出来的中间件，在Apollo 3.5中正式发布。Cyber RT和ROS2是比较像的，其底层也是使用了一个开源版本的DDS。

百度最早用的是ROS 1,但在使用的过程中逐渐发现了ROS 1存在“若ROS Master出故障了，则任何两个节点之间的通信便受到影响”的问题，所以就希望使用一个“没有中间节点”的通信中间件来代替ROS 1，那时还没有ROS2，所以自己去做了一个Cyber RT。

为了解决 ROS 遇到的问题，Cyber RT删除了master机制，用自动发现机制代替，这个通信组网机制和汽车网络CAN完全一致。此外，Cyber RT的核心设计将调度、任务从内核空间搬到了用户空间。

（图片出处：）

其相对于其他系统，Cyber RT的一大优势是，专为无人架驶设计。百度已将Cyber RT开源，某互联网巨头的自动驾驶团队使用的中间件便是百度开源出来的Cyber RT。

Cyber RT跟ROS 2之间也存在竞争关系。

在谈到AUTOSAR AP、ROS 2与Cyber RT这些中间件的关系时，Vector产品专家蔡守群的解释是：

“不需要很机械地去分类，你可以把AUTOSAR AP, ROS和Cyber RT都想象成一个提供一组中间件的超市，用户可以按需从不同的超市购买，并不是说从一个超市买过一个中间件，就不能从其他超市买了。

蔡守群说：AUTOSAR AP中也包含了对ROS接口的支持。说不准哪天ROS和Cyber RT就会加入AUTOSAR AP的组件，或者 AUTOSAR AP会引入Cyber RT的组件。

4.DDS（通信中间件）

（1）什么是DDS？

在自动驾驶领域，中间件的功能涉及到通信、模块升级、任务调度、执行管理，但其最主要的功能就是通信。当前市场上，无论是Cyber RT还是 ROS，基本上90%的功能就是通信，狭义上说就是通信中间件。

通信中间可以分成开源和闭源的两种。开源的为OPEN DDS、FAST DDS、Cyclone等，闭源的就RTI的DDS和Vector的SOME/IP。DDS的全称为Data Distribution Service ，指一种数据分发服务标准，由对象管理组织(OMG)制定。

DDS能够实现低延迟、高可靠、高实时性的数据融合服务，能够从根本上降低软件的耦合性、复杂性，提高软件的模块化特性。高等级自动驾驶现在基本上都在探索依靠DDS来解决异构通信、低时延等CP解决不了的挑战。

融合了DDS的汽车软件能够更好地运行在下一代汽车的体系架构中，更能降低开发的成本、缩短研发的时间，更快地将产品推向市场。

（2）DDS与ROS 2、AUTOSAR AP之间的关系

ROS 2和Cyber RT的底层都使用了开源的DDS，将DDS作为最重要的通信机制。但也有自动驾驶公司的工程师认为，DDS可以起到替代ROS 2的作用，站在用户的角度看，两者之间其实存在“二选一”的关系。

AUTOSAR CP里一直没有包含跟DDS有关的东西，但AUTOSAR AP在 2018年3月的最新版（版本18-10）里开始支持DDS标准。将DDS与AUTOSAR AP结合使用，不仅可以保证和扩展AUTOSAR AP系统内部互操作性的功能，而且还可以将其开放给来自不同的生态系统（即ROS 2）。

从工程角度来看，将AUTOSAR和DDS结合起来的最大优势是，功能域和网络拓扑不再是对手，而是车辆中的盟友。网络拓扑结构能够更好地适应车辆的物理约束，功能域在物理车辆的顶部提供了一个灵活的覆盖层，这就是所谓的分区体系结构。

当然，DDS仅是通信中间件的一种。关于各类通信中间件之间的异同，我们将在本系列的第二篇做更详细的阐释。

三．AUTOSAR AP的地位正在弱化？

尽管AUTOSAR是当下最有名的自动驾驶中间件，但《九章智驾》在对诸多中间件厂商们的调研中得出一个结论：AUTOSAR在产业链中的地位可能正在弱化。当然了，那些专注于AUTOSAR系统的厂商们并不认同这一观点。

我们在上文已经提到，随着EE架构从分布式向集中式演进、MCU被SOC取代，CP AUTSAR被AUTOSAR AP、ROS 2和Cyber RT等取代已是大势所趋，在下文，我们主要谈的是“AUTOSAR AP的地位会不会弱化”。

2021年12月中旬，两家AUTOSAR发起公司大陆集团、丰田联合采埃孚、捷豹路虎、沃尔沃、海拉等多家汽车行业龙头企业宣布投资车载操作系统初创公司Apex.AI，而Apex.AI的主力产品Apex.OS则是基于ROS 2发展起来的。

拿到了Apex.AI公司15%股权的采埃孚方面在接受媒体采访时说：“这意味着，我们可以为客户提供AUTOSAR AP的替代方案。”

尽管AUTOSAR AP已经有了标准，但还没有落地。安波福、采埃孚、大陆这些公司提供的方案，仍然是基于AUTOSAR CP标准的接口。事实上，越来越多的OEM不太想完全用AUTOSAR去解决智能驾驶操作系统的问题。

不仅特斯拉没有用AUTOSAR AP,国内的几大造车新势力也没有用(他们用的是AUTOSAR CP+DDS)。甚至，连一些正在转型的传统车企也没打算用AUTOSAR AP。

从产业链中各方的反应来看，AUTOSAR AP“地位不稳”的原因主要有以下几个：

1．使用成本太高

冯占军博士在《AUTOSAR对基础软件开发是喜还是忧？》一文中透露，AUTOSAR的费用通常是“几百万起”，并且，针对不同的域控制器、不同的芯片需要“重复收费”，一般小厂根本吃不消。“可能还没有什么产出，几百万就花出去了”。

除购买成本高外，毕晓鹏和萧猛都提到，AUTOSAR前期的学习难度很大、学习成本也非常高。为了学会如何使用AUTOSAR,企业甚至不得不专门培训一批人,如果受培训的人临时离职了，那培训费用就打了水漂。

2.效率不高

毕晓鹏认为，AUTOSAR AP的配置非常多，它是通过配置加上一部分代码去实现自己的功能，但配置多了之后，效率不高，而且代码臃肿。

3.静态部署与动态部署的理念冲突

毕晓鹏博士提到，AUTOSAR AP其实是从AUTOSAR CP发展而来的，AUTOSAR CP是静态部署，只适用于相对简单的业务逻辑和功能，其代码是固化的，有点像以前的功能手机——功能无法改变，不可能往里面再加一个APP；但AUTOSAR AP有点像现在的智能手机，软件开发人员开发一个APP，跨平台就可以用不同手机上了，这种动态部署的理念和之前的静态部署概念不甚相同，而其方法论却是基于静态部署衍生而来的，因此在实践层面会遇到不少问题。

4.无法满足智能网联的需求

由于云端跟车端所使用的操作系统不一样，AUTOSAR只能负责车内的通信，不能支持车端到云端的通信，因而无法支持车路协同场景（车端跟云端的通信，是通过MQTT、kafka等中间件来实现的）。除此之外，AUTOSAR能否兼容车辆网联化中需要用到的数据平台、通信平台和地图平台，也存在很大的疑问。

毕晓鹏说，在发现了这些问题后，有一些OEM开始逐渐放弃AUTOSAR架构，“转而自己去研发一套更适合动态部署、成本较低的新型软件架构”。

传统车厂是从使用CP过来的，所以在惯性上，他们可能还会考虑AP是否适合智能驾驶，但慢慢地也在尝试转型。如奥迪和TTTech合作做的通信中间件——zFAS，也没有采用AP。

不同于AUTOSAR CP已经是非常标准化的东西，大家用起来没什么问题，AUTOSAR AP现在的标准也不是很完善，每年也在更新，具体AP能发展成什么样，这个谁也不知道，大家更多也是观望的态度。

毕晓鹏认为，AUTOSAR标准并不能很好地支撑自动驾驶应用和创新的发展，因此，我们有必要建立一套更适合中国智能驾驶发展、且自主可控的技术架构和生态体系。

萧猛认为，由于从AUTOSAR CP到AUTOSAR AP一脉相承，一些已经对AUTOSAR形成路径依赖的公司会坚持使用AUTOSAR AP,但在经历过招人难、开发周期长等教训之后，他们有可能转向ROS 2。

当然，以AUTOSAR为主业的公司，显然不会认可上述“涉嫌唱衰”AUTOSAR AP的观点的。

比如，Vector蔡守群就认为，AUTOSAR AP只会越来越重要，因为它是顺应车载技术不断发展的一套规范，覆盖面会越来越广。

东软睿驰茅海燕也认为，要将整车域控制器和智驾域控制器合并到统一的中央计算平台上，没有AUTOSAR AP的支持很难搞定。“不是每家公司都能像特斯拉一样自己从头搭建系统的，目前,最好的工具还是AUTOSAR AP”。

请问autosar和osek的关系是什么？

都是汽车电子软件的标准。

AUTOSAR与OSEK二者都是汽车电子软件的标准。

OSEK基于ECU开发，AUTOSAR基于整体汽车电子开发。

1.AUTOSAR

AUTOSAR一般就是指AUTOSAR构架/标准，AUTOSAR的全称是AUTomotive Open System ARchitecture），随着多年的发展，越来越多的行业内的公司加入到了AUTOSAR联盟中，这其中有OEM（汽车整车厂），Tier1（汽车零部件供应商），芯片制造商以及工具制造商，AUTOSAR构架/标准也成为了汽车E/E设计的发展方向。

2.OSEK

在1995年召开的研讨会上众多的厂商对OSEK和VDX的认识达成了共识，产生了OSEK/VDX规范(1997年发布)，本文简称OSEK规范。

它主要由四部分组成:操作系统规范(OSEK Operating System,OSEK OS)、通信规范(OSEK Communication , OSEK COM )、网络管理规范( OSEK Net Management, OSEK NM)和OSEK实现语言(OSEK Implementation Language,OIL)。

扩展资料：

OSEK OS的特点

OSEK规范为实现其制定的初衷并满足汽车控制领域对系统安全性和节省有限资源的特殊要求，制定了系统而全面的操作系统规范。其特点主要有以下几个方面。

1. 实时性

由于越来越多的微处理器被应用到汽车控制领域，如汽车刹车的防抱死系统、动力设备的安全控制等这些系统直接关系着人的生命安全，即使出现丝毫的差错也会导致危及生命安全的严重后果，因此要求操作系统具有严格的实时性。

2.可移植性

OSEK规范详细规定了操作系统运行的各种机制，并在这些机制基础上制定了标准的应用程序编程接口，使那些独立编写的代码能够很容易地整合起来，增强了应用程序的可移植性。

3.可扩展性

为了适用于广泛的目标处理器，支持运行在广泛硬件基础上的实时程序，OSEK操作系统具备高度模块化和可灵活配置的特性。

AUTOSAR特点

1、模块化和可配置性

定义了一套汽车ECU软件构架，将不依赖硬件的软件模块和依赖硬件的软件模块分别优雅的封装起来，从而可以让ECU可以集成由不同供应商提供的软件模块，增加了功能的重用性，提高了软件质量。软件可以根据不同的ECU功能需求和资源情况进行灵活配置。