一、AUTOSAR的背景介绍

AUTOSAR，英文全称为AUTomotive Open System Architecture，翻译过来就是汽车开放系统架构。它是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司于2003年联合拟制的一套符合汽车电子软件开发的、开放的以及标准化的软件架构，是对汽车技术开发一百多年来的经验总结。该架构旨在改善汽车电子系统软件的更新与交换，同时更方便有效地管理日趋复杂的汽车电子软件系统。使得不同结构的电子控制单元的接口特征标椎化，应用软件具备更好的可扩展性以及可移植性，能够实现对现有软件的重用，大大降低了重复性工作，缩短开发周期。

AUTOSAR成员之间开展合作的主要目标是：使基本系统功能以及接口标椎化，使软件开发合作伙伴之间能交换、转换和集成各自的车载网络功能，最大限度地提高车辆售后的软件更新和系统升级效率。有了这个标准，AUTOSAR可以把范例从一个基于ECU的系统转移到基于功能的系统进行设计开发，统筹技术和经济方面对不断增长的E/E复杂性的汽车软件开发的管理。由于AUTOSAR提倡“在标准上合作，在实现上竞争”的原则，其核心思想是“统一标准、分散实施、集中配置”，所以采用AUTOSAR将为OEM带来很多好处，使得他们对于软件采购和控制拥有更大和更灵活的权利。软件系统的开放化和标准化将使更多的软件供应商进入汽车电子软件行业，OEM将有更多的选择，这将有利于提高软件产品的质量。

AUTOSAR的计划目标主要有三个：

1）建立分层的体系架构
2）为应用程序的开发提供方法论
3）制定各种应用接口规范

二、ATUOSAR的分层模型

为了实现应用程序和硬件模块之间的分离，AUTOSAR被抽象成四层：由上至下依次为：应用层（Application Layer）、运行时环境（Run Time Environment，RTE）、基础软件层（Basic Software，BSW）以及微控制器（Microcontroller），如下图所示。
在这里插入图片描述
而对于基础软件层BSW而言，它主要包括四部分：微控制器抽象层，ECU抽象层，服务层以及复杂驱动。其中：

微控制器抽象层（MCAL）包含了跟硬件相关的驱动程序，可以用来访问内存、通信和I/O等；
ECU抽象层负责提供统一的访问接口实现对通信、内存或者I/O的访问，从而无须考虑这些资源由微处理器提供还是由外部设备提供；
服务层提供各种类型的后台服务，例如网络服务、内存管理和总线通信服务等，操作系统就位于这一层；
复杂驱动（CCD）层跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求；

如下图所示：
在这里插入图片描述
基础软件层的组件及其功能对应如下：

1）系统：提供标准化的规定（针对操作系统、定时器以及错误存储器）、ECU特定的服务（ECU状态管理、看门狗管理）和库函数；
2）内存：对内部和外部的内存（非易失性存储器）的访问入口进行标准化；
3）通信：对汽车网络系统、ECU通信系统以及ECU内部软件的访问入口进行标准化；
4）输入/输出：对传感器、执行器以及ECU外设的访问入口进行标准化；

同时，基础软件层模块按照类型可以分为驱动模块、接口模块、处理模块以及管理器。

1、驱动模块

驱动模块包含了控制和使用内部或者外部器件的功能，分为内部驱动和外部驱动。

1）内部驱动

内部器件位于微控制器（单片机）的内部，比如内部EEPROM、内部CAN控制器、内部ADC模块等。它主要是针对单片机内部器件资源的驱动程序，这部分驱动程序属于微控制器抽象层（MCAL）。
2）外部驱动

外部器件是指单片机外部的ECU硬件，比如外部EEPROM、外部看门狗、外部Flash等。外部驱动程序就是针对单片机外部硬件资源的驱动程序，属于ECU抽象层。外部驱动程序需要通过微控制器抽象层（MCAL）驱动程序来实现对外部器件的驱动。这种方法下AUTOSAR也支持嵌入在系统基础芯片（SBCs）中的组件，像收发器以及看门狗等。例如，使用SPI通信接口的外部EEPROM驱动程序是通过SPI总线处理程序来驱动外部EEPROM的。但是有一种例外，对于和内存映射相关的外部器件（如外部Flash存储器），其驱动程序是可以直接对微控制器进行存取访问的，所以这部分驱动程序属于微控制器抽象层（MCAL）。

2、接口模块

接口模块包含了对其次级模块进行抽象的功能，比如对一个特定功能的硬件进行抽象。它提供一个通用的接口函数（API）来访问一种特定的器件类型，且与该类型器件的数目无关，同时也与器件的具体硬件实现无关。

接口模块不会改变数据的内容。一般来说，接口属于ECU抽象层。例如，CAN通信系统的接口模块提供一个通用的接口函数来访问CAN通信网络，并且与ECU上CAN控制器的数目以及硬件实现无关。

3、处理模块

处理模块是一个专用的接口，它控制一个或多个客户端对一个或多个驱动程序进行并行、多重以及异步地访问。也就是说，它起着缓冲、队列、仲裁以及多路复用的功能。同时，处理程序也不会改变数据本身的内容。处理模块通常会并入驱动程序或是接口模块中（如SPIHandlerDriver、ADC Driver等）。

4、管理器

管理器为多重的客户端提供特定的服务。当单纯的处理程序不能满足对多重的客户端进行抽象时，就需要用到管理器来进行处理。除了处理功能外，管理器还可以对数据内容进行评估、改变或是适应数据内容。

一般而言，管理器属于服务层。例如，非易失性随机存储器（NVRAM）的管理器负责对内部或是外部存储设备进行并行的访问，如Flash、EEPROM存储器等。同时，它也可以完成分布式并且可靠的数据存储、数据校验以及默认值的规定等。

三、ATUOSAR的接口标准

通过RTE实现AUTOSAR软件组件之间以及应用层与基础软件之间的通信前提是：软件组件之间必须有标准的AUTOSAR接口。AUTOSAR规范把汽车电子领域内的一些典型的应用划分为若干个由一个或多个软件组件组成的模块，并详细定义了这些软件组件相关的参数，例如名称、范围、类型等。

AUTOSAR定义了三种接口：标椎化接口（Standardized Interface）、AUTOSAR接口（AUTOSAR Interface）和标准化的AUTOSAR接口（Standardized AUTOSAR Interface）。

AUTOSAR接口是一种与应用相关的接口，与RTE一并生成。基于AUTOSAR接口的端口可以用于软件组件（Software Component,SWC）之间或者软件组件与ECU固件之间（例如复杂驱动）的通信。

标准化AUTOSAR接口是一种特殊的AUTOSAR接口。这些在AUTOSAR规范中定义过的接口被SWC用于访问AUTOSAR BSW模块提供的服务，比如ECU管理模块或者诊断事件管理模块。

标椎化接口是AUTOSAR规范中用C语言定义的API。这些接口用于ECU内部BSW模块之间，RTE和操作系统之间或者RTE和COM模块之间。
在这里插入图片描述
如图所示，基础软件之间通过标椎化接口进行数据通信和操作调用的。故基础软件之间可以相互调用各自的API函数，但是微控制器抽象层只能被ECU抽象层所调用，底层驱动信息通过ECU抽象层传递给服务层使用。

四、ATUOSAR的开发方法

AUTOSAR为汽车电子软件系统开发过程定义了一套通用的技术方法，即AUTOSAR方法论。该方法描述了从系统底层配置到ECU可执行代码产生过程的设计步骤，如下图所示。
在这里插入图片描述
AUTOSAR设计和开发流程分为三个阶段：系统配置、ECU设计与配置阶段、代码生成阶段。

第一阶段：定义系统配置文件，这是系统设计者或架构师的任务。包括选择硬件和软件组件，定义整个系统的约束条件。AUTOSAR通过使用信息交换格式和模板描述文件来减少初始系统设计时的工作量。系统配置的输入是XML类型的文件，输出是系统配置描述文件，系统配置的主要作用是把软件组件的需求映射到ECU上。

第二阶段：根据系统配置描述文件提取单个ECU资源相关的信息，提取出来的信息生成ECU提取文件。根据这个提取文件对ECU进行配置，例如操作系统任务调度，必要的BSW模块及其配置，运行实体到任务的分配等，从而生成ECU配置描述文件。该描述文件包含了特定ECU的所有信息。

第三阶段：生成代码，是基于ECU配置描述文件指定的配置来产生代码、编译代码，并把相关代码链接起来形成可执行文件。

具体的开发流程如下：