1、AUTOSAR方法论

2、AUTOSAR的BSW

2.1、MCAL

2.2、ECU抽象层

2.3、服务层

2.4、复杂驱动

3、AUTOSAR的RTE

4、AUTOSAR的应用层

4.1、SWC

4.2、AUTOSAR的通信

4.3、AUTOSAR软件接口

1、AUTOSAR方法论

AUTOSAR为汽车电子软件系统开发过程定义了一套通用的技术方法,即AUTOSAR方法论。该方法描述了从系统底层配置到 ECU可执行代码产生过程的设计步骤。AUTOSAR设计和开发流程分为系统配置阶段、ECU设计与配置阶段以及代码生成阶段。

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

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

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

具体开发流程如下：

1、编写系统配置输入描述文件

在AUTOSAR中,所有的描述文件都是XML类型的文件。系统配置输入文件包括以下三部分内容：

软件组件描述：定义了每个涉及的软件组件的接口内容，如数据类型、端口、接口等；

ECU资源描述：定义了每个ECU的资源需求，如处理器、存储器、外围设备、传感器和执行器等；

系统约束描述：定义了总线信号、软件组件间的拓扑结构和映射关系。

2、系统配置

系统配置的功能主要是在资源和时序关系的前提下，把软件组件映射到各个ECU上，然后借助系统配置生成器生成系统配置描述文件。这个描述文件包括总线映射之类的所有系统信息以及软件组件与某个 ECU 的映射关系。

3、提取特定ECU描述

从系统配置描述文件中提取出与各个 ECU 相关的系统配置描述信息，提取的信息包括ECU 通信矩阵、拓扑结构、映射到该 ECU上的所有软件组件，并将这些信息放在各个ECU的提取文件中。

4、ECU配置

ECU配置主要是为该ECU添加必要的信息和数据，如任务调度，必要的基础软件模块及其配置，运行实体及任务分配等，并将结果保存在ECU配置描述文件中,该文件包含了属于特定ECU的所有信息。换言之，ECU上运行的软件可根据这些信息构造出来。

5、生成可执行文件

根据ECU配置描述文件中的配置信息,生成RTE和基础软件配置代码,完成基础软件和软件组件的集成,最终生成ECU的可执行代码。

2、AUTOSAR的BSW

AUTOSAR基础软件层的结构主要由四部分组成，即微控制器抽象层(MicrocontrollerAbstraction Layer,MCAL)、ECU 抽象层(ECU Abstraction Layer)、服务层(Services Layer)以及复杂驱动(Complex Drivers)。各部分在AUTOSAR基础软件层的位置如下图所示。

其中，MCAL包含了与硬件相关的驱动程序，可以用来访问内存、通信和 I/O 等；ECU抽象层负责提供统一的访问接口实现对通信、内存或者I/O的访问，从而无须考虑这些资源由微处理器提供还是由外部设备提供；服务层提供各种类型的后台服务，例如网络服务、内存管理和总线通信服务等,操作系统就位于这一层。

2.1、MCAL

微控制器抽象层(MCAL),位于AUTOSAR分层模型中BSW的最底层。MCAL包含内部驱动,可以直接访问微控制器和片内外设。更进一步地,MCAL又可分为微控制器驱动(Microcontroller Drivers)、存储器驱动(Memory Drivers)、通信驱动(CommunicationDrivers)和 I/O驱动(I/O Drivers)四个部分，如下图所示，各部分又由具体的与微控制器硬件相对应的驱动模块组成。

1、微控制器驱动

微控制器驱动由通用定时器驱动(General Purpose Driver, GPT Driver)、看门狗驱动(Watchdog Driver, WDG Driver)、微控制器单元驱动(Microcontroller Unit Driver, MCUDriver)和内核测试(Core Test)四个部分组成。

(1) GPT Driver

在AUTOSAR中有两类定时器:操作系统定时器和硬件定时器。该模块使用通用定时器单元的硬件定时器通道，为操作系统或者其他基础软件模块提供计时功能，一个典型的时间周期范围是 50 μs~5 ms。

GPT Driver 的作用是：

启动和停止硬件定时器；

得到定时器数值;

控制时间触发的中断；

控制时间触发的中断唤醒。

GPT Driver通过调用Gpt_StartTimer和Gpt_StopTimer函数来启动和停止定时器通道。目标时间视作Gpt_StartTimer的一个参数，可以为每个定时器通道单独设置。

定时器通道可以设为单次模式或连续模式。在单次模式下，定时器到达目标时间(即定时器数值)时会自动停止,保持定时器数值不变并且通道状态从“运行”变为“超时”;在连续模式下，定时器到达目标时间会清零并继续运行。

(2) WDG Driver

WDG Driver 的功能主要是初始化和触发看门狗。

WDG Driver 有内部 WDG Driver 和外部 WDG Driver。内部 WDG Driver 控制 MCU的内部看门狗定时器,提供触发功能和模式选择服务;外部WDG Driver控制外部硬件看门狗，与内部 WDG Driver一样，提供触发功能和模式选择服务。

(3) MCU Driver

MCU Driver 位于MCAL 层，可以直接访问微控制器硬件，它的主要功能是初始化、休眠、复位微控制器以及提供其他MCAL软件模块所需的与微控制器相关的特殊功能。MCU Driver 能为硬件复位提供软件触发服务，但是只有被授权的用户才可以调用这个复位服务函数。在ECU中有很多不同的原因可以造成复位，如果硬件允许，MCU模块可以获取复位的原因。此外,MCU Driver还能够使能并设置MCU时钟,例如CPU时钟、外围器件时钟、预分频器等参数。

注意:所有的外设时钟必须通过McuClockReferencePoint 与其他BSW模块联系起来。

(4) Core Test

Core Test模块包含周期性测试和启动测试。

Core Test可以对CPU的所有寄存器进行测试,提供中断控制和异常检测。该模块还对算术逻辑单元、存储保护单元和缓存控制器等进行检测。Core Test可以运行在后台模式或前台模式。在后台模式中，Core Test会被调度机（Scheduler）周期性调用，在当前的原子型序列(Atomic Sequence)中是可中断的，一个完整的测试由很多原子型序列组成，以测试内核功能。而在前台模式中,Core Test会被用来测试整个内核或者所选模块的功能。取消后台模式并启动前台模式是允许的，但是两种模式不能被同时执行。如果在某个后台任务运行中有前台任务被请求，那么，在调用前台任务前，后台任务应当被取消。

2. 存储器驱动

存储器驱动由内部EEPROM驱动、内部 Flash驱动、RAM 测试和Flash测试四部分组成。

（1）内部 EEPROM 驱动

内部 EEPROM 驱动提供初始化服务，以及对内部 EEPROM 的读、写、擦除等操作。该驱动模块一次只能接受一个任务。

（2）内部 Flash 驱动

内部Flash驱动提供内部Flash初始化服务,以及对内部Flash的读、写、擦除等操作。该驱动还可以将Flash访问代码下载到RAM中；如果需要的话，也可以执行写、擦除操作。

(3) RAM测试

RAM 测试模块通过软件对 RAM 存储进行测试。该模块包含后台测试和前台测试。其中，后台测试(Background RAM Test)是异步服务，前台测试(Foreground RAM Test)是同步服务。

(4)Flash 测试

Flash 测试模块提供算法来测试诸如数据/程序闪存、程序 SRAM 等非易失性存储器，这些存储器可以是集成在微控制器内部的，也可以是外部映射到微控制器的。测试服务可以在MCU初始化完成后的任意时间被执行，用户可以选择合适的测试算法。同样,Flash测试可以在前台模式和后台模式下运行,被测试的模块在前台和后台都可单独配置。

2.2、ECU抽象层

ECU 抽象层负责提供统一的访问接口，实现对通信、内存或者 I/O 的访问，从而无须考虑这些资源是由微处理器提供的还是由外部设备提供的。外部设备的驱动就位于这一层。ECU抽象层主要包括板载设备抽象(Onboard Device Abstraction)、存储器硬件抽象(Memory Hardware Abstraction)、通信硬件抽象(Communication Hardware Abstraction)和 I/O 硬件抽象（I/O Hardware Abstraction）四个部分。

2.3、服务层

服务层是基础软件层的最高层，它可以实现与应用层软件的关联。I/0信号可以通过ECU抽象层进行获取,此外，服务层还提供操作系统功能、汽车网络通信以及管理服务、内存服务、诊断服务[包含统一诊断服务(Unified Diagnostic Services, UDS)、错误记忆和故障处理]、ECU 状态和模式管理、逻辑与暂时程序流程监管(Watchdog 管理)、加密服务等。服务层的主要任务是为应用程序、RTE 以及基础软件模块提供最基本的服务。服务层的上层接口保证了微控制器和 ECU 硬件层的独立。按照服务对象的不同,服务层又可以分成三部分,即通信服务(CommunicationServices)、存储器服务(Memory Services)和系统服务(System Servieces)。

2.4、复杂驱动

复杂驱动(CDD)层跨于微控制器硬件和 RTE 之间，其主要任务是整合具有特殊目的且不能用 MCAL 进行配置的非标准功能模块，将该部分功能嵌入 AUTOSAR 基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。比如 AUTOSAR 中未指定的功能部分、有较高执行时间要求限制的或是需要移植的部分等。因此，复杂驱动程序跟单片机和 ECU 硬件紧密相关。其上层程序接口是根据 AUTOSAR 指定并且实施的；其下层程序接口受标准接口程序的限制。

(1)从分层软件架构下的其他模块到复杂驱动的访问

只有当复杂驱动提供一个接口并且该接口可以通过访问 AUTOSAR 模块进行配置时，才允许分层软件架构下其他模块访问复杂驱动。一个典型的例子就是PDU路由器，一个复杂驱动可能执行一个新的总线系统的接口模块,因此,这种情况在PDU路由器的配置选项中已经有所考虑。

(2)从复杂驱动到分层软件架构下其他模块的访问

同样的,只有当分层软件架构的各个模块提供接口并且准备好被复杂驱动访问时,复杂驱动才能访问分层软件架构下其他模块。通常，这就意味着这些各自的接口被定义为可以再次进入的(re-entrant)，如果使用了回调例程(Call Back routines)，那么，其名称也是可配置的。需要说明的是,不存在对模块状态进行管理的上层模块(并行访问将会改变状态,同时不会被上层模块注意到)。一

3、AUTOSAR的RTE

虚拟功能总线(Virtual Function Bus, VFB)是 AUTOSAR中的另一个重要概念。虚拟功能总线是对 AUTOSAR 提供的所有通信机制的一种抽象，是所有软件组件进行交互的桥梁，如下图所示。通过虚拟功能总线，软件组件之间的通信细节被抽象出来，软件组件通过AUTOSAR定义的接口对通信进行描述，即可最大限度地独立于具体的通信机制，实现与其他软件组件和硬件的交互。

通过虚拟功能总线，无论软件组件使用的是单 ECU 的内部通信还是 ECU 间的外部通信,对于应用软件的设计者来说,没有本质区别。内部通信与外部通信的区别只有等到系统配置阶段将软件组件分配到不同的 ECU 之后，才能体现出来。而在这种情况下，虚拟功能总线的真实通信实现可以由运行时环境和基础软件来保证。因此，在虚拟功能总线的帮助下,应用软件的各个软件组件不需要关注通信的区别,从而可以在独立的情况下设计开发软件组件，使得应用软件的开发可以独立于具体的 ECU，开发人员可以将精力集中在应用软件及其软件组件的开发上。

作为AUTOSAR虚拟功能总线(VFB)的具体实现，RTE位于AUTOSAR软件架构的中间层，介于应用层和基础软件层之间，如下图所示，它实现了特定 ECU 上的虚拟功能总线，支持 AUTOSAR 的软件组件间、基础软件间、软件组件与基础软件之间的通信。RTE封装了基础软件层的通信和服务，为应用层的软件组件提供标准化的基础软件和通信接口，使得应用层可以通过 API函数调用基础软件的服务，如操作系统的任务激活、等待等功能，基础软件模块管理、ECU 状态管理等服务，实现了对软件生命周期的控制。除此之外，RTE还抽象了 ECU之间的通信，使用标准化的接口将其统一为软件组件间的通信，使得 ECU 间的通信如同 ECU 内部的通信。但在实现上，它需要调用基础软件中的通信部分的功能以实现各种不同总线的通信。

RTE 软件设计的主要对象是软件组件和基础软件。为满足实时性、可靠性以及数据的一致性等要求,RTE向软件组件和基础软件组件提供通信机制和并发机制,如下图所示。

RTE 是 AUTOSAR 的核心，它衔接了应用层和基础软件层，为应用层提供标准接口来调用底层的资源,使得ECU软件的开发与具体的硬件相脱离,上层应用策略开发的人员可以更加专注于软件功能的开发,而不用纠缠于软件底层的细节。

4、AUTOSAR的应用层

4.1、SWC

在AUTOSAR中,应用软件包含许多独立的单元,即AUTOSAR软件组件(SoftwareComponent, SWC)。

一个AUTOSAR软件组件通过定义好的端口与其他AUTOSAR软件组件进行访问。如下图所示，五个SWC通过相应的端口进行连接。

软件组件的行为通过一个或多个可运行体(Runnable)实现。在Simulink里面,通过一个模型表示AUTOSAR软件组件。下下图表示一个AUTOSAR软件组件,三个函数调用子系统(Function-Call)代表三个可运行体,分别标识为Runnablel_subsystem, Runnable2lsubsystem和Runnable3_subsystem。信号irvl, irv2, irv3, irv4代表AUTOSAR 内部可运行体间变量(Inter-Runnable Variable，IRV)。

4.2、AUTOSAR的通信

AUTOSAR软件组件提供了定义明确的连接点,即端口。有以下三种类型的AUTOSAR 端口.

需求端口

供给端口

组合的供给需求端口

AUTOSAR端口可引用下列类型的接口

发送—接收接口（Sender-Receiver）；

客户—服务器接口（Client-Server);

模式—切换接口(Mode-Switch)；

非易失数据接口(Nonvolatile Data);

参数接口(Parameter)；

触发接口（Trigger）。

Client-Server接口，AUTOSAR 客户一服务器接口定义了提供这个接口的软件组件以及需求这个接口的软件组件之间的交互。提供这个接口的软件组件是服务器,需要这个接口的软件组件是客户端。

4.3、AUTOSAR软件接口

AUTOSAR对软件的接口(Interface)进行了合理的分类和定义,在标准化的前提下实现了最大限度的可扩展性和可移植性，从而为AUTOSAR 应用于汽车系统提供了基础。AUTOSAR定义了三种接口,即AUTOSAR接口(AUTOSAR Interface)、标准化的AUTOSAR 接口(Standardized AUTOSAR Interface）和标准化接口 (StandardizedInterface)。AUTOSAR 各组件之间的接口如下图所示。

由下图可知,在AUTOSAR软件架构中,基础软件模块之间的接口为标准接口,应用软件组件与RTE层之间的接口为AUTOSAR接口，OS 与 RTE、通信服务与RTE之间的交互接口为标准接口,服务层其他服务与RTE之间的交互接口为标准化AUTOSAR接口,IO抽象层与RTE、复杂驱动与RTE的交互接口为AUTOSAR接口。三种接口的特性如下。

1、AUTOSAR接口

AUTOSAR 接口定义了软件模块和 BSW 模块(仅仅是 IO 抽象和复杂驱动)之间交互的方式,AUTOSAR接口是以port的形式出现的,包括信息的发送与接收和服务的调用(send or receive information or invoke services), AUTOSAR将ECU 内部的通信和网络通信使用的接口进行了统一。AUTOSAR接口的C语言的表现形式为:

Rte_Write_(p)_<d>(),

Rte_Read_<p>_<d>(),

Rte_Call_<p>_<d>()。

2、标准化的AUTOSAR接口

标准化的 AUTOSAR 接口是语义和语法均使用 AUTOSAR 接口技术标准化的接口,该类接口通常使用在AUTOSAR基础件模块通过RTE提供给应用层软件组件的标准化服务中。如服务端口(Service Port),格式为Rte_Call_(PortPrototype)_(operation)_(operation)();服务层的一些API接口,如SetEventStatus(In Dem_EventStatusType)。

3、标准化接口

标准化接口是AUTOSAR中一种标准化的应用编程接口(Application ProgrammingInterface, API),但是并没有使用AUTOSAR接口技术,标准化接口通常被用在某个ECU内部的软件模块之间的通信,不能用于网络通信。形如OS中Schedule(), WaitEvent()均为标准化接口。