AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器（ECU）标准软件架构。
AUTOSAR联盟是在2003年由9家汽车行业的巨头（宝马、博世、大陆、戴姆勒、福特、通用、PSA、丰田、大众）建立的。这9家公司后来也称为AUTOSAR联盟的核心成员。截至2020年3月， AUTOSAR已经拥有了57家高级成员、50家开发成员、142家普通成员以及20家观察员公司及机构，包括全球各大主流整车厂、一级供应商、标准软件供应商、开发工具和服务提供商、半导体供应商、高校和研究机构等。许多中国厂商也是AUTOSAR联盟成员，例如长城、东风、一汽、上汽、吉利、蔚来、拜腾、宁德时代等。比较特殊的是，目前炙手可热的特斯拉却没有加入AUTOSAR。这意味着他们很可能拥有自己的一套E/E开发流程和控制器软件架构。
2. 背景和目的
从上个世纪80年代汽车控制器出现开始，汽车的电子控制系统一直在高速发展，面临的挑战也越来越多，主要体现在以下几个方面：
汽车的电气化电子化程度提高，控制器数量增加，网络复杂度增加。
软件功能数量急剧增加
硬件平台多样化，软件可复用性差
软件开发周期缩短
软件成本占比增加
我们再来看看汽车行业里整车厂和供应商的关系。
汽车行业里整车厂和供应商的关系（图片来源：AUTOSAR官网）
汽车行业里有众多的整车厂（OEM）和供应商。一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上；同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。
另一方面，各个供应商的开发进度往往是不同步的。人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。
这便是AUTOSAR的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。
为此，AUTOSAR做了以下3件事情：
对应用软件与底层软件之间以及应用软件之间的接口进行标准化
给出一个控制器软件参考架构
规范分布式开发流程中的交换格式
通过这些手段，AUTOSAR希望可以做到：
提高软件的可扩展性和灵活性，方便应用功能的集成和转换，以及控制器网络的优化
提升软件的可复用性
降低产品和流程的复杂度和风险
提升软件的开发和更新速度
降低软件开发和维护成本
AUTOSAR提出了一个口号，叫做“Cooperate on standards, compete on implementation”。意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。
打个简单的比方。整车和零部件就好比是电脑和外设的关系，它们之间通过标准的USB接口来连接。无论是联想的电脑，还是戴尔的电脑，无论是100块的鼠标，还是1000块的鼠标，它们都互相可以即插即用。电脑厂家可以专注做自己的电脑，而无需考虑会外接什么样的鼠标键盘；相应的，外设厂可以专注做自己的鼠标键盘，而无需考虑会用在什么样的电脑上。它们之间的接口和交换格式，已经由USB标准规定了。这就是标准化带来的便利。
3. AUTOSAR的基本思想
在一个汽车控制器中，除了实现具体功能及算法的应用软件，还有许多底层软件来保证控制器的正常运行，比如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。一方面，不同控制器中这部分底层软件的功能重复度很高；而另一方面这部分底层软件又跟硬件紧密相连，在一个处理器平台上写好的软件，换一个处理器平台就不能用了。去为每一个控制器项目专门写一套底层软件显然是非常低效的，而且也容易出错。
于是人们就想通过标准化应用软件和底层软件之间的接口，来让应用软件开发者可以专注于具体应用功能的开发，而无需考虑控制器底层的运行过程。这样即使更换了处理器硬件，应用软件也无需做太多修改就可以被移植过去。而底层软件的开发则交给专门的公司，他们为每一个处理器硬件写好驱动，并封装成标准化接口提供给上层。这样底层软件就可以被高效地集成到不同项目中。而由于同一套底层软件被大量重复使用，发现bug的概率大大提高，从而可以很快得到修补，并且通过更新对其它项目进行同步修补。
AUTOSAR的基本思想：软硬件分离（图片来源：AUTOSAR官网）
为了让大家更直观地理解这套思想，我再打个比方。
简单的寄信流程
假如小明现在要给小红寄一封信，需要分几步？我想大致可以分成以下几个步骤：
小明把写好的信装进信封里，写上收信人和寄信人的姓名地址邮编，封好口，并贴上邮票。
小明把信投入家附近的邮筒里。
邮递员把信从邮筒收集到当地邮局，并按目的地进行分类。
信件通过长途交通运输工具运送到目的地邮局。
目的地邮局的邮递员按照信封上具体的收件人地址投递到小红的邮箱中。
小红从信箱中拿到信，打开信封，就读到了小明信的内容。
现在我们再回过头想想。作为使用邮政服务的寄信人和收信人，是否需要考虑底下整个邮政系统的运行方式呢？一般是不需要的。寄信人只需要按照邮政的要求在信封上写好收寄件人信息、贴好邮票，再放进邮政系统提供的标准接口——邮筒里就可以了，并且相信，若干天之后信就可以到达收信人的邮箱。而收件人只要每天查看邮政给他提供的接口——邮箱，到时就可以收到信了。而至于邮递员是几点来把信从邮筒收走的，又是乘坐何种交通工具到达目标城市，邮递员是走路还是骑小绵羊来送信，等等等等，都与他们无关。而反过来，对于邮政系统来说，信的内容是情书、休书、还是勒索信，都与他们无关。邮政要做的就只是高效、准确地投送信件。
如果我们把上图中左边寄件人+邮筒+邮局看成一个ECU，其中写信人是应用软件，邮局是底层软件，邮筒是连接应用软件和底层软件的标准接口，把右半部分看成另一个ECU，把连接两个邮局之间的运输工具看成是汽车上的物理总线，那么整个AUTOSAR的基本思想是不是就变得直观了？
4. AUTOSAR的基本架构
下面我们看看Classic AUTOSAR平台的软件架构。它可以分为以下几部分：
Classic AUTOSAR架构（图片来源：AUTOSAR官网）
微控制器（Microcontroller）：即控制器硬件。
基础软件层（Basic Software Layer，BSW）:基础软件层，它包含了以下4个部分：
微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：是与硬件直接相关的驱动软件，例如对存储器、通信寄存器、IO口的操作等等。
ECU抽象层（ECU Abstraction Layer，ECUAL）：是对控制器的基础功能和接口进行统一，比如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等等。
服务层（Services Layer）：为应用层提供各种后台服务，比如网络管理、存储器管理、总线通信管理服务以及操作系统等。
复杂设备驱动（Complex Device Drivers，CDD）：为用户提供了一个可以自行编写特殊设备驱动软件的可能性。
运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。
应用软件层（Application Software Layer，ASW）：即实现具体应用功能的软件。它可以包含多个软件组件（Software Component，SWC）。
其中基础软件层可以再细分成很多个小模块。下面是Vector公司给出的基础软件层的模块图。其中绝大部分的模块都由AUTOSAR作了详细描述，从具体的功能、工作流程到接口。一级供应商在开发的时候只需要根据实际需求，购买相应的基础软件模块，再进行配置和集成即可。这就有点像乐高积木一样。这使得供应商对控制器基础软件的开发由实现（implement）变成了配置（configurate），大大增加了开发效率，也减少了错误几率。
Vector公司AUTOSAR软件模块图（图片来源：Vector公司官网）
AUTOSAR遵循的是一种自上而下的开发方式。即先进行系统设计，再分别进行开发实现，最终进行系统集成。
下图便是AUTOSAR开发流程的一个简要概括。这里首先要提一下虚拟功能总线（Virtual Functional Bus，VFB）。它是为SWC之间的通信和对BSW服务的调用提供一个虚拟的中间层。这样整车厂在初期进行系统设计（1）时，就可以专注于软件功能模块的设计，而无需考虑硬件的限制。SWC因而也可以重复利用，并在不同项目里自由组合。
AUTOSAR的E/E系统开发流程
完成系统功能架构设计后，第2步便是将SWC分割到不同的ECU上。同一个ECU内不同SWC之间的信息交换可以在ECU内部完成，而如果不同ECU的SWC之间需要信息交换的话，那就需要通过物理总线了，比如CAN。通常来说，功能相近的SWC要放在一个ECU上，这样可以减少总线上传递的信号数量，减少总线负载，也减少传输延迟。这一步会把整个网络细节定义好，包括信号的长度、处在哪个CAN报文的哪个位置、CAN总线的比特率等等。最终生成一个AUTOSAR XML格式的系统描述文档（System Description）。
完成系统设计之后，就可以为每个控制器单独生成一个控制器描述文档（ECU Extract of System Description），同样是AUTOSAR XML格式。它包含了系统里跟这个ECU有关的所有信息，例如拥有哪些总线，每个总线的参数（如CAN的比特率、LIN的Schedule Table等等），在每条总线上都收发哪些信号，是否带E2E校验，包含哪些SWC，分别都收发哪些信号，等等。
接下来便是把这些控制器描述文档分发给各个控制器相应的供应商。供应商会从AUTOSAR基础软件提供商（如Vector、Elektrobit）购买相应的基础软件模块，并使用AUTOSAR开发工具导入控制器描述文档，就可以生成该控制器的大体框架。之后只需要完成对各个基础软件模块的具体参数配置，就可以自动生成基础软件的C代码，包括RTE。RTE会把基础软件层与应用层的接口封装好。而应用层软件的开发可以同步进行。前面已经定义好了各个SWC使用的接口，做应用层开发的时候只需要使用这些接口即可。应用层的开发即可以是由同一个控制器的供应商来做，也可以是整车厂自己做，甚至可以将同一个控制器的不同SWC交给不同的供应商来做。开发过程可以是基于模型的，也可以手动编写C代码。等到应用层和基础软件层都开发完毕之后，由于它们使用了预设好的统一的接口，最后可以很方便地集成到一起。
之后供应商便可以对控制器及相应的部件进行测试。前面说过，一辆车上各个部件往往是交给不同的供应商来做的。供应商之间的开发进度往往不同步，而且一般也不会互相往来。那么供应商如何在没有其他部件的情况下，测试自己的部件是否能在系统中正确工作呢？由于我们是在一个设计好的完整系统中切割出一个个ECU Extract的，所以它已经包含了跟系统中其它部件的接口信息。于是各个供应商可以通过仿真工具建立起一个虚拟的系统环境，来测试他们的部件是否与系统兼容。这也就是硬件在环测试（Hardware in the loop，HIL）。
各个部件开发完成后，就可以集成到一起进行测试了。由于各个部件是基于同一个系统设计开发出来的，它们集成到一起后便可以互相配合了。当然，实际当中会很多问题在单独开发测试阶段没有被发现，集成到一起之后才会被发现。之后还需要不停地进行修改、测试。但在AUTOSAR框架下，这个过程也是非常清晰的。当需要修改两个控制器之间的信号时，只要先在系统描述文档里进行修改，再生成更新后的控制器描述文档，相应地供应商再将它们导入AUTOSAR开发工具中，更新相应的信号路径、参数等，就可以很快地生成新的C代码。
AUTOSAR的设想很美好，不过在实际应用当中还是有各种限制。首先，目前提供AUTOSAR开发工具链及基础层软件的基本上就Vector、Elektrobit（Continental）和Bosch三家，而由于各家对AUTOSAR标准的理解和具体实现方式不同，导致它们的基础层软件在某些方面是不兼容的。这使得应用时的灵活性受到了限制。其次，AUTOSAR的整套工具链价格还是相当昂贵的。AUTOSAR的优势是提高软件的可复用性来降低成本，但对于一些小供应商来说，如果做的量太小的话，这一优势相对于购置整套开发环境的成本便不那么明显了。另外，传统AUTOSAR的灵活性也是相对而言的。传统AUTOSAR用的是OSEK OS，是一个静态操作系统。其进程的数量、优先级、内存分配等等都是固定的。一旦需要做一个改动，比如添加一个通信信号，都需要重新生成一遍整个ECU的代码并刷写。于是人们又开发出了Adaptive AUTOSAR，来满足汽车越来越高的智能化，越来越快的功能和软件更新频率要求。
个人觉得，AUTOSAR的出发点是好的。如果各个整车厂和供应商都遵循同一套软件开发标准，是可以大大提高开发效率和产品的灵活度的。而且要让整个汽车行业这么多企业坐在一起开发一套共同的标准，本来就不是一件简单的事。虽然现实应用中有各种不足，但随着AUTOSAR应用越来越广泛，标准逐步完善，AUTOSAR在汽车软件的开发中还是会扮演举足轻重的角色的。
此文转自知乎汽车电子
