汽车开放系统架构(AUTOSAR)是什么

1.AUTOSAR的概念

AUTOSAR，全称为Automotive Open System Architecture，即汽车开放系统架构。

• 它是由全球各家汽车制造商、零部件供应商以及各种研究、服务机构共同参与的一种汽车电子系统的合作开发框架，并建立了一个开放的汽车控制器(ECU)标准软件架构。
• ECU（Electronic Control Unit）电子控制单元，又称“行车电脑”、“车载电脑”等，它和普通的电脑一样,由微控制器（MCU）、存储器（ROM、RAM）、输入/输出接口（I/O）、模数转换器（A/D）以及整形、驱动等大规模集成电路组成。用一句简单的话来形容就是“ECU就是车的大脑”。

2.背景和目的

从上个世纪80年代汽车控制器出现开始，汽车的电子控制系统一直在高速发展，面临的挑战也越来越多，主要体现在以下几个方面：

• 汽车的电气化电子化程度提高，控制器数量增加，网络复杂度增加。
• 软件功能数量急剧增加
• 硬件平台多样化，软件可复用性差
• 软件开发周期缩短
• 软件成本占比增加

汽车行业里整车厂(OEM整车厂，Original Equipment Manufacturer)和供应商的关系

• 汽车行业里有众多的整车厂（OEM）和供应商。

• 一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。

• 减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。

• OEM希望可以让同一套系统和部件用在不同的车型上；
  同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；
  而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。

• 另一方面，各个供应商的开发进度往往是不同步的。
  人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。

这便是AUTOSAR的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。

所以，UTOSAR做了以下3件事情：

• 对应用软件与底层软件之间以及应用软件之间的接口进行标准化
• 给出一个控制器软件参考架构
• 规范分布式开发流程中的交换格式

通过这些手段，AUTOSAR希望可以做到：

• 提高软件的可扩展性和灵活性，方便应用功能的集成和转换，以及控制器网络的优化
• 提升软件的可复用性
• 降低产品和流程的复杂度和风险
• 提升软件的开发和更新速度
• 降低软件开发和维护成本

AUTOSAR提出了一个口号，叫做“Cooperate on standards, compete on implementation”。

• 意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。
• 打个简单的比方。
  整车和零部件就好比是电脑和外设的关系，它们之间通过标准的USB接口来连接。无论是联想的电脑，还是戴尔的电脑，无论是100块的鼠标，还是1000块的鼠标，它们都互相可以即插即用。
  电脑厂家可以专注做自己的电脑，而无需考虑会外接什么样的鼠标键盘；
  相应的，外设厂可以专注做自己的鼠标键盘，而无需考虑会用在什么样的电脑上。它们之间的接口和交换格式，已经由USB标准规定了。这就是标准化带来的便利。

3.AUTOSAR的基本思想

在一个汽车控制器中，除了实现具体功能及算法的应用软件，还有许多底层软件来保证控制器的正常运行，比如CAN总线信号的收发、任务进程的调度、Flash数据的读写等等。

• 一方面，不同控制器中这部分底层软件的功能重复度很高；
• 而另一方面这部分底层软件又跟硬件紧密相连，在一个处理器平台上写好的软件，换一个处理器平台就不能用了。
• 去为每一个控制器项目专门写一套底层软件显然是非常低效的，而且也容易出错。

于是人们就想通过标准化应用软件和底层软件之间的接口，来让应用软件开发者可以专注于具体应用功能的开发，而无需考虑控制器底层的运行过程。

• 这样即使更换了处理器硬件，应用软件也无需做太多修改就可以被移植过去。而底层软件的开发则交给专门的公司，他们为每一个处理器硬件写好驱动，并封装成标准化接口提供给上层。
• 这样底层软件就可以被高效地集成到不同项目中。而由于同一套底层软件被大量重复使用，发现bug的概率大大提高，从而可以很快得到修补，并且通过更新对其它项目进行同步修补。

AUTOSAR的基本思想：软硬件分离

• eg：autosar的基本思想
  把上图中左边寄件人+邮筒+邮局看成一个ECU(汽车电子控制单元 (ECU))，其中写信人是应用软件，邮局是底层软件，邮筒是连接应用软件和底层软件的标准接口，把右半部分看成另一个ECU，把连接两个邮局之间的运输工具看成是汽车上的物理总线。

4.AUTOSAR的基本架构

Classic AUTOSAR平台的软件架构。

• 它可以分为以下几部分：
  

• 微控制器（Microcontroller）：即控制器硬件。

• 基础软件层（Basic Software Layer，BSW）:基础软件层，它包含了以下4个部分：
  （1）微控制器抽象层（Microcontroller Abstraction Layer，MCAL）：是与硬件直接相关的驱动软件，例如对存储器、通信寄存器、IO口的操作等等。
  （2）ECU抽象层（ECU Abstraction Layer，ECUAL）：是对控制器的基础功能和接口进行统一，比如CAN报文内容的解析、网关报文的转发、存储器读写流程的控制等等。
  （3）服务层（Services Layer）：为应用层提供各种后台服务，比如网络管理、存储器管理、总线通信管理服务以及操作系统等。
  （4）复杂设备驱动（Complex Device Drivers，CDD）：为用户提供了一个可以自行编写特殊设备驱动软件的可能性。

• 运行环境（Runtime Environment，RTE）：是AUTOSAR的核心，它将应用软件层与基础软件层剥离开来，为应用层软件提供运行环境，如进程时间片调度、应用层模块之间以及应用层与基础软件层之间的数据交换等。

• 应用软件层（Application Software Layer，ASW）：即实现具体应用功能的软件。
  它可以包含多个软件组件（Software Component，SWC）。

• eg：Vector公司AUTOSAR软件模块图
  中基础软件层可以再细分成很多个小模块。
  下面是Vector公司给出的基础软件层的模块图，其中绝大部分的模块都由AUTOSAR作了详细描述，从具体的功能、工作流程到接口。
  一级供应商在开发的时候只需要根据实际需求，购买相应的基础软件模块，再进行配置和集成即可。这就有点像乐高积木一样。
  这使得供应商对控制器基础软件的开发由实现（implement）变成了配置（configurate），大大增加了开发效率，也减少了错误几率。
  

5.AUTOSAR的开发方法

AUTOSAR遵循的是一种自上而下的开发方式。

• 即先进行系统设计，再分别进行开发实现，最终进行系统集成。

下图是AUTOSAR的E/E系统(汽车电子电气架构，Electrical/Electronic Architecture)开发流程的一个简要概括。

• 这里首先要提一下虚拟功能总线（Virtual Functional Bus，VFB），它是为SWC之间的通信和对BSW服务的调用提供一个虚拟的中间层。

• 第一步，整车厂在初期进行系统设计（1）时，就可以专注于软件功能模块的设计，而无需考虑硬件的限制。
  SWC因而也可以重复利用，并在不同项目里自由组合。
  

• 完成系统功能架构设计后，第2步便是将SWC分割到不同的ECU上。
  （1）同一个ECU内不同SWC之间的信息交换可以在ECU内部完成，而如果不同ECU的SWC之间需要信息交换的话，那就需要通过物理总线了，比如CAN。
  （2）通常来说，功能相近的SWC要放在一个ECU上，这样可以减少总线上传递的信号数量，减少总线负载，也减少传输延迟。
  （3）这一步会把整个网络细节定义好，包括信号的长度、处在哪个CAN报文的哪个位置、CAN总线的比特率等等。
  （4）最终生成一个AUTOSAR XML格式的系统描述文档（System Description）。

• 完成系统设计之后，就可以为每个控制器单独生成一个控制器描述文档（ECU Extract of System Description），同样是AUTOSAR XML格式。
  它包含了系统里跟这个ECU有关的所有信息，例如拥有哪些总线，每个总线的参数（如CAN的比特率、LIN的Schedule Table等等），在每条总线上都收发哪些信号，是否带E2E校验，包含哪些SWC，分别都收发哪些信号，等等。

• 接下来便是把这些控制器描述文档分发给各个控制器相应的供应商。
  （1）供应商会从AUTOSAR基础软件提供商（如Vector、Elektrobit）购买相应的基础软件模块，并使用AUTOSAR开发工具导入控制器描述文档，就可以生成该控制器的大体框架。
  （2）之后只需要完成对各个基础软件模块的具体参数配置，就可以自动生成基础软件的C代码，包括RTE。
  RTE会把基础软件层与应用层的接口封装好。
  而应用层软件的开发可以同步进行。
  前面已经定义好了各个SWC使用的接口，做应用层开发的时候只需要使用这些接口即可。
  应用层的开发即可以是由同一个控制器的供应商来做，也可以是整车厂自己做，甚至可以将同一个控制器的不同SWC交给不同的供应商来做。
  开发过程可以是基于模型的，也可以手动编写C代码。
  等到应用层和基础软件层都开发完毕之后，由于它们使用了预设好的统一的接口，最后可以很方便地集成到一起。

• 之后供应商便可以对控制器及相应的部件进行测试。
  前面说过，一辆车上各个部件往往是交给不同的供应商来做的。供应商之间的开发进度往往不同步，而且一般也不会互相往来。那么供应商如何在没有其他部件的情况下，测试自己的部件是否能在系统中正确工作呢？
  由于我们是在一个设计好的完整系统中切割出一个个ECU Extract的，所以它已经包含了跟系统中其它部件的接口信息。于是各个供应商可以通过仿真工具建立起一个虚拟的系统环境，来测试他们的部件是否与系统兼容。
  这也就是硬件在环测试（Hardware in the loop，HIL）。

• 各个部件开发完成后，就可以集成到一起进行测试了。
  由于各个部件是基于同一个系统设计开发出来的，它们集成到一起后便可以互相配合了。
  当然，实际当中会很多问题在单独开发测试阶段没有被发现，集成到一起之后才会被发现。
  之后还需要不停地进行修改、测试。
  但在AUTOSAR框架下，这个过程也是非常清晰的。当需要修改两个控制器之间的信号时，只要先在系统描述文档里进行修改，再生成更新后的控制器描述文档，相应地供应商再将它们导入AUTOSAR开发工具中，更新相应的信号路径、参数等，就可以很快地生成新的C代码。

6.局限

首先，目前提供AUTOSAR开发工具链及基础层软件的基本上就Vector、Elektrobit（Continental）和Bosch三家，而由于各家对AUTOSAR标准的理解和具体实现方式不同，导致它们的基础层软件在某些方面是不兼容的。这使得应用时的灵活性受到了限制。

其次，AUTOSAR的整套工具链价格还是相当昂贵的。AUTOSAR的优势是提高软件的可复用性来降低成本，但对于一些小供应商来说，如果做的量太小的话，这一优势相对于购置整套开发环境的成本便不那么明显了。

另外，传统AUTOSAR的灵活性也是相对而言的。

• 传统AUTOSAR用的是OSEK OS，是一个静态操作系统。
  其进程的数量、优先级、内存分配等等都是固定的。
  一旦需要做一个改动，比如添加一个通信信号，都需要重新生成一遍整个ECU的代码并刷写，于是人们又开发出了Adaptive AUTOSAR，来满足汽车越来越高的智能化，越来越快的功能和软件更新频率要求。

• 参考：链接，汽车开放系统架构（AUTOSAR）是什么