“天下苦AUTOSAR久矣，苦Vector久矣。”这是汽车电子工程师时常叹息的一句话。

AUTOSAR普及程度之高，使得许多企业近乎"盲目"采用该架构，甚至将其视为技术实力的象征——若某家企业的产品未采用AUTOSAR，似乎就等同于落后于时代。对工程师来说，掌握AUTOSAR又是一个“刚需”技能，甚至是入行的敲门砖。

这是一个矛盾的时代，苦于AUTOSAR，不得不使用AUTOSAR，寻找替代AUTOSAR。

那么问题来了，AUTOSAR究竟是什么，目前主流AUTOSAR巨头都有谁，现在AUTOSAR行业现状如何，接下来本文将详细解析。

为什么会有AUTOSAR

在汽车行业中，最忌讳的莫过于“重复造轮子”。AUTOSAR的出现就是为了这一目的，类似于USB Type-C标准的统一，使不同厂商的ECU能够无缝协作。

软件开发对汽车应用越来越重要。越发严苛的安全要求、环境要求和便利性要求，大大增加

了车辆电子系统的数量。90%的技术创新都是基于软件驱动的电子部件。这些部件占汽车开发成本的 40%。发展的步伐以及整合更多功能和控制单元的持续性需求，对汽车制造商构成了重大挑战。

AUTOSAR（AUTomotive Open System ARchitecture，汽车开放系统架构）因此诞生，它是一种标准化的汽车电子控制单元（ECU）软件架构，旨在通过统一底层软件封装，使不同厂商的ECU能够兼容，从而减少重复开发，提高效率。AUTOSAR联盟于2003年由9家汽车行业的巨头（宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众）建立，目前在全球已有接近400成员，包括我们熟知的NXP、ST、Infineon。此外，AUTOSAR中国中心（China Hub）成立于2022年，是AUTOSAR组织的官方分支机构。

AUTOSAR核心理念是“标准上合作，实现上竞争”，即行业共同制定底层标准，而各厂商专注于上层应用开发，如算法和控制逻辑优化。

在AUTOSAR出现之前，汽车电子开发效率低下，开发周期长，代码合作开发难，维护难可重用性差（例如更换硬件平台后，代码几乎是需要重新开写的），此外随着代码量的增加，代码质量也随之下降。例如，不同厂商的CAN收发器协议不兼容，导致工程师更换硬件平台时需重新开发底层代码，效率低下且成本高昂。AUTOSAR的提出解决了这一问题。目前，全球主流汽车厂商及供应商（如宝马、博世、大陆等）均采用该架构。

通过AUTOSAR，实现了三层目标：第一，软硬件解耦：通过标准化接口，使应用层开发独立于底层硬件，更换硬件时仅需调整配置，无需重写代码；第二，开发效率提升：减少底层开发工作量，使工程师更专注于算法和功能优化；第三，行业生态整合：推动汽车电子向模块化、标准化发展，降低开发成本。

看懂AUTOSAR的“里子”

AUTOSAR架构包含两大平台：经典平台（Classic或者CP）和自适应平台（Adaptive或者AP）。CP面向具有严格实时性要求的安全关键型车辆功能，采用C语言作为主要编程语言，适用于传统微控制器。AP则针对联网车辆和高度自动驾驶等计算密集型应用设计，基于POSIX操作系统构建，采用模块化设计，分为服务模块和基础模块两大类别。在通信机制上，AP平台采用面向服务架构（SOA），支持通过DDS或SOME/IP协议实现基于以太网的ECU间通信。两个平台通过基础标准实现互操作，在汽车电子系统中形成互补关系——经典平台适用于动力总成等传统控制领域，自适应平台则满足智能网联等新兴需求。

从名称看，AP比CP更高端一些，CP更老旧。实际也如此，CP平台适用于传统的嵌入式系统，特别是对实时性要求高的场景。CP采用静态分层架构，主要满足确定性实时控制需求；而AP基于动态服务化架构，专注于支持高性能计算和智能网联应用。这种演进反映了汽车软件从固定功能向智能服务的转型趋势。不过，这两个平台不是对手，而是队友。两者在汽车设计和开发生态系统中都有不同的用途。

图源丨CodeWisdom

AUTOSAR架构是一种分层的软件架构，宏观上由三层组成：

• 应用软件层（Application）：负责业务逻辑，如电机控制算法。
• 实时运行环境（RTE）：充当中间层，隔离应用与底层。
• 基础软件层（BSW）：封装硬件驱动，提供标准化接口。又分为4大部分：硬件抽象层（MCAL）、 ECU抽象层、服务层、复杂驱动（或CDD)。

AUTOSAR的核心思想是分层与封装，类似于日常生活中的“黑箱”操作。例如，用户使用空调时无需了解其内部原理，只需操作控制面板。同样，AUTOSAR将底层驱动封装，开发者只需调用标准接口，无需关注硬件细节。这种分层思维也可应用于其他领域，如代码模块化或任务管理，以提高效率。

目前，AUTOSAR已成为汽车电子的行业标准，但底层开发仍由少数专业公司（如Vector、西门子等）主导，大多数工程师主要承担应用层开发。对于从业者而言，掌握AUTOSAR配置与工具链是核心技能，但深入底层需较高门槛。实践中，需平衡标准化与灵活性，避免因过度依赖工具而限制创新。

车载网络在AUTOSAR如何实现

网络与通信在车载ECU开发中非常重要性。比如，在胎压监测系统中，就至少涉及三种通信方式：四个轮胎的压力传感器通过BLE蓝牙与TPMS（胎压管理系统）通信传输胎压数据；TPMS与网关通过CAN总线交互传递胎压数据及附加信息；IVI（含仪表盘）与网关交互；TBOX作为车载联网终端实现数据上传，使手机端可查看车辆状态。

AUTOSAR最基本的功能就是基于通信的数据交互。随着发展，许多数据相关组件都能遵循AUTOSAR架构实现，因为AUTOSAR本身就是一个开放的架构系统，支持组件扩展。

在通信中，PCI（Protocol Control Information）、PDU（Protocol Data Unit，协议数据单元）和SDU（Service Data Unit，服务数据单元）是三个基础概念。在AUTOSAR思想中，通信数据在不同层级组件间遵循PDU和SDU的转换规则：由上而下，当前层级的PDU是下一层级的SDU，当前层级的SDU是上一层级的PDU。这种分层设计类似于快递包装与拆包的过程，实现数据的封装与解封装。

而到车载的CAN通信，就是I-PDU（交互层PDU）、L-PDU（数据链路层PDU）和N-PDU（网络层PDU）的概念。这三者对应经典的三层网络模型：物理层、数据链路层和网络层。在AUTOSAR软件架构中，这些网络层级被映射到具体组件：CAN Driver（驱动层）、CAN Interface（ECU抽象层，连接驱动与PDU路由）、PDU Router（分发I-PDU）以及CAN TP和AUTOSAR COM组件，如下图：

盘点AUTOSAR领域国内外巨头

AUTOSAR是汽车软件领域最重要、最常见、最常用的中间件，但遵循“标准开源，成果独占”的思想，AUTOSAR仅是一个标准，需要完全实现AUTOSAR，需要购买第三方公司做好的AUTOSAR工具链并进行二次开发。所以，AUTOSAR也是利润最丰厚的领域。目前，形成了国际AUTOSAR三巨头和国内AUTOSAR三巨头的局面。

首先，国际上AUTOSAR三巨头分别是VECTOR、ETAS和EB。

VECTOR基本上可以配合所有主流MCU芯片，具有工具链完整、技术实力雄厚、软件质量优异等特点，其产品在行业内处于领先地位。然而其系统架构相对固化，灵活性不足，且产品定价显著高于同业，通常为其他厂商的2倍以上。值得注意的是，Vector的MCAL重构工作由国外技术团队完成，国内仅提供技术支持，这充分体现了其技术实力和软件质量。但需注意的是，若开发过程中需求发生重大变更，可能导致项目延期风险。

ETAS作为博世集团子公司，偏向意法半导体、英飞凌和瑞萨。ETAS同样提供完整的工具链解决方案，其产品易用性较好。据工程师称，ETAS目前正在推进的本土化进程，不过在本土有技术储备不足的挑战，在功能安全领域的技术实现亦有待提升。其优势在于采取灵活的合作模式和具有竞争力的价格策略。

EB（大陆集团子公司）偏向瑞萨和NXP的MCU。EB提供BSW和MCAL工具链，但工程师认为其缺乏ASW工具链支持。若需ASW解决方案，需引入第三方工具（如AutoSAR Builder），这些第三方工具可能会是美国公司，同时多供应商协作会增加项目管理复杂度。目前EB在中国区的技术团队规模有限，主要依赖国外团队完成系统集成，国内仅提供技术支持。工程师认为如果不是缺ASW工具，可能比ETAS好，当然他的价格贵于ETAS。

除了上述三家公司，西门子Mentor的工具链也很齐全，本土化有相关建设，软件质量很好，但知名度比较高。

其次，国内的AUTOSAR三巨头分别是普华基础软件、东软睿驰和经纬恒润。

普华基础软件是AUTOSAR重要企业，是中国电子科技集团有限公司整合集团优势资源共同投资设立的，作为中国电科发展基础软件的重要平台，肩负提升基础软件产业核心竞争力，引领网信产业转型升级的历史使命。普华基础软件致力于 AUTOSAR 车用基础软件的技术研发与产品应用，提供设计、开发、配置、集成、测试等全生命周期的工具链、本地化一站式增值服务及车用芯片的生态支持。最近，普华基础软件也正在开源自己的车载操作系统。

2021年11月，普华基础软件与芯驰科技达成战略合作，双方已经推出了基于芯驰科技G9X智能网关芯片提供全套Classic AUTOSAR解决方案。此前，芯驰采用EB旗下经典的EB tresos Studio工具用于符合AUTOSAR标准的微控制器抽象层（MCAL）开发平台进行车规芯片底层软件的开发，此次选择普华基础软件合作说明了国产厂商的技术实力正在逐渐获得市场认可。

东软睿驰国内较早成为AUTOSAR高级会员单位的企业之一，其面向新一代智能汽车的软件开发平台 NeuSAR 率先实现国内“AUTOSAR AP+CP+中间件”全栈软件平台产品量产落地，全球首家升级至 AUTOSAR AP R21-11 版本，并在不断完善，最高支持功能安全 ASIL D 等级，国内首家获得ISO/SAE 21434:2021汽车信息安全认证，已应用在包括一汽、岚图、长安、吉利等多家车厂的多个主力车型定点项目中。

经纬恒润自2007年起加入了AUTOSAR组织，于2022年正式升级为高级合作伙伴会员。期间，先后参与了多个重要组的有关工作，还将在后续的合作中加入WG-DDS工作组，提出技术建议并积极参与标准建设。

国内AUTOSAR第二梯队有华为、斑马智行、超星未来、映驰科技、未动科技、零念科技、上海赫千、国汽智控、成都道伟。

观望AUTOSAR，替代AUTOSAR

虽然AUTOSAR至关重要，但AUTOSAR也有一个致命问题，那就是“贵”。动辄数百万乃至上千万元的授权费用，且需针对不同域控制器和芯片重复支付。使得众多中小企业不得不对这一技术望而却步。

更重要的是，AUTOSAR目前也存在一些其他问题和挑战：由于规范制定时缺乏充分测试，问题修复往往需等待后续版本更新，导致整车开发过程成为工具链持续修复BUG的过程；尽管AUTOSAR标榜软件模块的复用性与独立性，但实际应用中难以实现了；出于商业利益考虑，各厂商间缺乏充分的兼容性设计与沟通，对规范的理解也存在差异，高学习成本和陡峭的学习曲线，使企业难以招募到合格的AUTOSAR技术人才；AUTOSAR目前也存在“标准先行”“依赖软件供应商”的种种不便之处。

面对这些挑战，部分车企开始探索替代方案。如大陆、丰田等投资了基于ROS 2的Apex.AI公司的Apex.OS，采埃孚将其视为AUTOSAR AP的有效替代品。百度Apollo推出的Cyber RT则专注于自动驾驶领域。同时，SOA架构理念正被引入汽车行业，东软睿驰、上汽零束等企业都在推进SOA平台建设，旨在实现整车级软件接口的标准化与开放。

2022年3月，Eclipse基金会在其官网宣布成立软件定义汽（SDV）车工作组。工作组的核心成员有在全世界开发软件最多的Microsoft、世界上最大开源基金会之一的Eclipse，以及全球汽车零部件Top5中的三家：博世（Bosch）、ZF和Conti。Eclipse SDV工作组专注于使用开源和开放式规范，加速车规级车载软件栈的创新。

Eclipse SDV开源了它们的代码、文档、工作组记录，并提供了可运行的初始版本供开发人员试验。这相较于AUTOSAR，会相对更容易被尝试、测试、接受并使用，并更容易形成事实标准。

由Arm公司主导的适用于嵌入式边缘的可扩展开放架构特别兴趣小组（Scalable Open Architecture for Embedded Edge special interest group, SOAFEE SIG）也正在通过标准化系统架构规范来应对车辆SOA挑战。SOAFEE打算通过采用云原生计算和边缘计算的标准来改变这种状况，使汽车原始设备制造商能够专注于其核心竞争力，并提高软件的可重用性。

一些车企，如理想，也选择开源了自己的汽车操作系统。此前，理想汽车此前也采用行业通用的AUTOSAR操作系统，而后选择自研操作系统。

一些工程师评价：“AUTOSAR干了多少年才干出来，不是一两年也不是三五年，是整整二十年啊；关键是要有一帮城下心来做架构的工程师专家，这些人在欧洲都是大学老师和Vector这样的公司核心专家一起完成的。车载操作系统的架构是一个系统的复杂的架构，国内根本没有这个土壤和氛围来做这个。很多车企老板不懂，被忽悠。”

一些业内人士则对AUTOSAR系统评价表示：“特斯拉就不是AUTOSAR体系的，人家面试就是林纳斯那一套show your code，很多企业用不起AUTOSAR。对于量少/平台少，或者自有平台已经建立的，AUTOSAR不是必须。甚至包括autosar core member如福特GM，这并不是所有module都用AUTOSAR。”

有工程师则认为：“仿AUTOSAR架构不是问题，工具链生成代码才是，工具链大大提高了开发效率，车场dbc都是vector的东西，个人觉得AUTOSAR这个亏只能认了，除非国内车企越来越牛，联合起来提出更牛的标准架构。”

也有工程师认为：“功能安全认证，AUTOSAR什么都是扯，不用这些，汽车一样做的很安全。说白了就是方便不同供应商厂家一致，先入为主的一个标准，技术上很落后。中国完全可以由大厂牵头自己搞一个，做个国标，连can都放弃，直接用ethercat之类的东西，这样中国汽车工业才能真正引领世界。反正中国主要造整车，国外汽车配件商也要看中国脸色，跟中国标准走，时代不同了。”

而在软件定义时代，SOA解决方案是否能够满足软件定义汽车时代，开源操作系统是否又能颠覆AUTOSAR，我们是否还有别的方法去做满足客户功能安全认证的工具链，或许这要看时代的进一步发展。