AUTOSAR 是什么意思？如何学习？

最新推荐文章于 2025-06-04 14:00:27 发布

蓝天居士

最新推荐文章于 2025-06-04 14:00:27 发布

阅读量1k

点赞数 4

CC 4.0 BY-SA版权

分类专栏： AUTOSAR 文章标签： AUTOSAR

原文链接：https://www.zhihu.com/question/566550343/answer/3278488901

AUTOSAR 专栏收录该内容

1 篇文章

订阅专栏

本文介绍了AUTOSAR的起源、组织结构及其在汽车行业中解决软件不标准问题的架构标准，重点讲解了经典平台和自适应平台，以及应用接口和验收测试。AUTOSAR通过分层架构和标准化接口，促进了汽车软件开发的高效和一致性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一、AUTOSAR定义

1. AUTOSAR联盟

AUTOSAR，全称Automotive Open System Architecture，中文是“汽车开放系统架构”。但它首先是一个组织，下图是该组织的标志：

注意AUTOSAR不能写作AutoSAR，否则Open的含义就没有了，标志也用红色圆圈强调了开放的理念。这个组织是怎么来的呢？

2003年，9家公司成立了AUTOSAR。截至2023年11月，已有350多家公司、机构加入，包括汽车制造商、部件供应商、电子和软件公司等。

那么为什么要成立这个组织呢？因为各大厂商发现了一个问题：

随着汽车功能越来越多，导致ECU的数量越来越多。1993年的时候，奥迪A8才只有5个ECU，现在典型的现代汽车上有超过50个ECU，有的车甚至有150个ECU。

但是ECU可能是不同的供应商提供的，各厂家的标准、软件架构可能不同，OEM车厂要让这些ECU之间正常通信，是一件复杂和困难的事。供应商软件开发的工作量也很大，版本众多，维护起来非常困难。

在ECU中添加新功能，或者把ECU-A的功能移植到ECU-B中也不是一件简单的事。

因此，就成立了这样一家致力于制定汽车电子软件标准的联盟。那么，该组织做了什么呢？

2. AUTOSAR架构

AUTOSAR联盟为了解决大量ECU软件不标准的问题，制定了AUTOSAR软件架构标准。

如上图所示，ECU的软硬件一般是耦合在一起的，每一个ECU都要专门开发软件，并且这些软件较难复用在别的车型上。AUTOSAR架构的原理是将耦合在一起的软件和硬件进行解耦，让硬件层和应用软件层分离，让应用程序开发不用再关注硬件的具体形式和参数。就好比现在的手机App开发，只要知道是Android还是iOS，不用太关注手机具体的品牌和型号。

现在，所有公司和机构都用同样的框架、接口来开发，大大减少了嵌入式软件的开发难度，方便了软件版本的更新。架构相当于是将ECU的底层软件做了标准的封装，只用修改几个参数，就可以匹配不同的硬件。AUTOSAR为管理愈来愈复杂的汽车软件系统提供了基础。

综上，AUTOSAR有两个定义，一个是组织名称，一个是架构和标准。除此以外，AUTOSAR也可以指过程、工具或使用的文件格式，如AUTOSAR XML或ARXML，我们后面详细再聊。

最后再分享一下AUTOSAR的组织架构、会员类型、加入好处等。

AUTOSAR的组织架构

AUTOSAR组织架构如下图所示：

会员类型

会员类型分为Core Partner、Premium Partner、Development Partner、Associate Partner、Attendees。各类型成员的职责、权限、会费等如下图所示：

加入AUTOSAR的好处

二、AUTOSAR架构标准

如果你在汽车行业工作，如何评估开发的软件是否符合AUTOSAR标准规范呢？接下来我们就看一下AUTOSAR的架构标准，看看AUTOSAR是怎么把软硬件分离的。

我们先来聊个别的，小时候父母有没有跟你说过：学习的时候别想着玩，玩的时候别想着学习。其实，这是一种思想的体现，这个思想叫做“关注点分离”。同样地，我们希望软件开发者不要太关注硬件，硬件开发者也不要太关注软件，专注一个领域，工作效率会更高。AUTOSAR就是帮开发者软硬件解耦的标准。

AUTOSAR架构标准有5大部分，分别是：经典平台（Classic Platform）、自适应平台（Adaptive Platform）、基础（Foundation）、应用界面（Application Interface）、验收测试（Acceptance Test）。

AUTOSAR将应用软件和硬件平台进行解耦，在应用软件和基础软件与硬件之间嵌入虚拟功能总线（VFB，Virtual Function Bus），应用之间的通信或者访问硬件资源等都是通过虚拟功能总线进行资源交换。如下图所示：

对于不同平台，VFB的具体实现是不同的，我们下面来看。

1. CP - AUTOSAR Classic Platform（since 2003）

为什么叫Classic，因为它早在2003年AUTOSAR成立的时候就颁布了，所以我们先来聊它。

上图是AUTOSAR Classic原理，在软硬件之间插入Runtime Environment运行环境层，即RTE层。

举个不太恰当的例子来帮助理解：传统ECU开发就相当于一个人，既要吃饭（软件）又要做饭（硬件），可能还要洗碗（硬件，释放内存），效率就比较低。而AUTOSAR像是一个食堂，硬件层就是食堂做菜师傅、锅碗瓢盆和食材，应用层相当于要吃饭的学生，中间的RTE层就相当于打菜的阿姨。学生（软件开发者）不需要关注食材（硬件，数据）是怎么洗净切好，怎么放到锅碗瓢盆（硬件，存储）中做熟，只需要和打菜阿姨（RTE上接口）说一下（通信）要什么菜（数据包），阿姨就会打给你（提供数据），如果没有菜了，阿姨就会喊（通过RTE下接口）做菜的师傅（硬件），判断还有没有菜（提供相关数据），如果没有就要赶紧做菜（执行某个操作），或者告诉学生没有菜了（硬件报错，硬件损坏，兼容性问题等）。

当然，以上只是原理的介绍。其实Classic Platform的架构是这样的：

在RTE层（红色）和微控制器硬件层（黑色）之间还有一块Basic Software基础软件层，即BSW层。我们来聊聊各层的作用：

应用层

AppL或ASWL - Application Software Layer。实现具体应用功能，一个App包含多个软件组件（SWC，Software Component）。

基础软件层

BSW。4层如上图所示（非上下层关系）：

Service服务层：给应用层提供后台服务，如存储管理、网络管理等。

ECU抽象层：ECUAL - ECU Abstraction Layer，标准化硬件的基础功能和接口，控制网关报文转发、存储器读写等。

硬件抽象层：MCAL - Microcontroller Abstraction Layer，硬件相关的驱动软件。

复杂驱动：CDD - Complex Device Driver。

硬件层

也称微控制器层，即控制器的硬件部分。

AUTOSAR给出了公认的标准，而如何实现上面的功能，各个厂家或机构如Vector、Denso等都给出了自己的解决方案。这也符合AUTOSAR理念“Cooperate on standards, Compete on implementation”，即“标准上合作，实现上竞争”。

当然，AUTOSAR的标准还可以更细化，像这样：

或者这样：

甚至这样：

毕竟AUTOSAR Classic Platform文档有100多个不同的模块，超过2万页的内容。Classic通过科学的软件分层、分区、分模块，将嵌入式ECU软件标准化，让每个模块的功能都得到了具体的定义。

2. AP - AUTOSAR Adaptive Platform（since 2017）

为什么有了Classic，还要搞个Adaptive呢？因为ECU数量做减法的时代来临了。

人们发现，车辆每新增一个功能，都要增加ECU的数量。这会带来什么问题呢？

（1）芯片数量越多，成本越贵。

（2）芯片之间连接的线缆会变长（如奥迪A8的线束长度8km，这也就是100多个ECU）。线缆成本增加，装配线缆的人工成本增加。装配线缆耗费时间使流水线效率降低，单车成本增加。线缆还会让车变重，在车身轻量化上还会被竞争对手嘲笑。

（3）ECU软件开发和管理的复杂度指数级攀升。软件开发人员也都是要工资的，海量版本更容易出错，给公司造成不可控风险。

所以，从分布式Distributed向集中式Centralized的E/E电子电气架构发展，已经成为汽车行业的共识：

集中化不仅能减少线束成本，减少车重，还能减少人工组装成本。特斯拉ModelS的线束长度3km，Model3的线束长度1.5km，未来特斯拉的线束长度可能只有100m。

集中式电子电气架构必然需要集中式计算，特斯拉Model3上目前只有3个DCU（域控制器，Domain Control Unit。左车身域，右车身域，前车身域），实现了要50多个ECU才能实现的功能。

所以在2017年，为适应汽车的发展趋势（如辅助驾驶、V2X、OTA、远程诊断、动态部署等），应对汽车E/E系统开发面临的新的挑战（高性能处理器的应用，实现ADAS，高带宽通信，E/E架构演变等），AUTOSAR组织推出了AUTOSAR Adaptive Platform（AP）。简单说，AP就是为高性能计算提出的解决方案，架构如下：

在Classic中虚拟功能总线VFB为RTE层，在Adaptive中VFB为ARA层，AUTOSAR Runtime for Adaptive applications。

ARA层提供通讯管理、执行管理和日志跟踪等功能组件，并给App层提供API接口。

AP构建在POSIX OS上，由不同功能模块组成，这些模块属于服务模块Service和基础模块Foundation。模块的通信是面向服务（SOA）的，并使用以太网与其它ECU通信。

AP的灵活性让软件在运行时也支持软件的更改，更多AP和CP的区别见下图所示：

综上，AP解决了高性能计算的需求，解决了CP嵌入式软件架构的局限性。但AP和CP并不是相互独立的，AP为高端计算提供了环境，平滑连接了嵌入式和非AUTOSAR系统，保留了嵌入式的特点，如安全性、确定性和实时性等。Adaptive Platform并不是用来取代Classic Platform或者非AUTOSAR平台，而是为了相互兼容，协作并满足未来的需求。