精⼼整理吐⾎推荐的AUTOSAR科普介绍材

料
⼀、AUTOSAR的背景介绍
AUTOSAR是AUTOmotive Open System Architecture（汽⻋开放系统架构）的⾸字⺟缩
写，是由全球各⼤汽⻋整⻋⼚、汽⻋零部件供应商、汽⻋电⼦软件系统公司联合建⽴
的⼀套标准协议，是对汽⻋技术开发⼀百多年来的经验总结。从2003年起，拟定了⼀
个符合汽⻋电⼦软件开发的、开放的以及标准化的软件架构。该架构旨在改善汽⻋电
⼦系统软件的更新与交换，同时更⽅便有效地管理⽇趋复杂的汽⻋电⼦软件系统。
AUTOSAR规范的运⽤使得不同结构的电⼦控制单元的接⼝特征标椎化，应⽤软件具备
更好的可扩展性以及可移植性，能够实现对现有软件的重⽤，⼤⼤降低了重复性⼯
作，缩短开发周期。

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

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

1）建⽴分层的体系架构
2）为应⽤程序的开发提供⽅法论
3）制定各种应⽤接⼝规范

⼆、AUTOSAR的分层模型
为了实现应⽤程序和硬件模块之间的分离，AUTOSAR架构被抽象成四层，由上⾄下依
次 为 ： 应 ⽤ 层 （ Application Layer） 、 运 ⾏ 时 环 境 层 （ Run Time Environment， 即
RTE ） 、 基 础 软 件 层 （ Basic Software ， 即 BSW ） ， 以 及 微 控 制 器 层
（Microcontroller）。如下图所示。

AUTOSAR软件体系结构包含了完全独⽴于硬件的应⽤层（APP）和与硬件相关的基础
软件层（BSW），并在两者中间设⽴了⼀个运⾏时环境（RTE），从⽽使两者分离，
形 成 了 ⼀ 个 分 层 体 系 架 构 。 RTE 是 专 ⻔ 为 应 ⽤ 软 件 （ AUTOSAR 软 件 组 件 和 / 或
AUTOSAR传感器/执⾏器组件）提供通信服务的层。在RTE之上，软件架构⻛格从“分
层”转变为“组件⻛格”。AUTOSAR软件组件通过RTE与其他组件（内部和/或内部ECU）
或服务进⾏通信。所以，这样的分层结构带来两个最⼤的好处，⼀⽅⾯，OEM可以专
注于开发特定的、有竞争⼒的应⽤层软件（位于RTE之上），另⼀⽅⾯，它使OEM所不
关⼼的基础软件层（位于RTE之下）得到标准化。

三、AUTOSAR的⽅法论
AUTOSAR为汽⻋电⼦软件系统开发过程定义了⼀套通⽤的技术⽅法，即AUTOSAR⽅
法论。该⽅法描述了从系统底层配置到ECU可执⾏代码产⽣过程的设计步骤，如下图
所示。

AUTOSAR设计和开发流程分为三个阶段：系统配置、ECU设计与配置阶段、代码⽣成
阶段。

第⼀阶段：定义系统配置⽂件，这是系统设计者或架构师的任务。包括选择硬件
和软件组件，定义整个系统的约束条件。AUTOSAR通过使⽤信息交换格式和模板
描述⽂件来减少初始系统设计时的⼯作量。系统配置的输⼊是XML类型的⽂件，
输出是系统配置描述⽂件，系统配置的主要作⽤是把软件组件的需求映射到ECU
上。
第⼆阶段：根据系统配置描述⽂件提取单个ECU资源相关的信息，提取出来的信
息⽣成ECU提取⽂件。根据这个提取⽂件对ECU进⾏配置，例如操作系统任务调
度，必要的BSW模块及其配置，运⾏实体到任务的分配等，从⽽⽣成ECU配置描
述⽂件。该描述⽂件包含了特定ECU的所有信息。
第三阶段：⽣成代码，是基于ECU配置描述⽂件指定的配置来产⽣代码、编译代
码，并把相关代码链接起来形成可执⾏⽂件。

具体的开发流程如下：

1. 编写系统配置输⼊描述⽂件
在AUTOSAR中，所有的描述⽂件都是XML类型的⽂件。系统配置输⼊⽂件包含三
部分内容：
1）软件组件描述，定义了每个涉及的软件组件的接⼝内容，如数据类型，端⼝，
接⼝等。
2）ECU资源描述，定义了每个ECU的资源需求，如处理器、存储器、外围设备、
传感器和执⾏器等。
3）系统约束描述，定义了总线信号，软件组件间的拓扑结构和映射关系。
2. 系统配置
系统配置的功能主要是在资源和时序关系的前提下，把软件组件映射到各个ECU
上，然后借助系统配置⽣成器⽣成系统配置描述⽂件。这个描述⽂件包括总线映
射之类的所有系统信息以及软件组件与某个ECU的映射关系。
3. 提取特定ECU的描述
从系统配置描述⽂件中提取出与各个ECU相关的系统配置描述信息，提取的信息
包括ECU通信矩阵、拓扑结构、映射到该ECU上的所有软件组件，并将这些信息
放在各个ECU的提取⽂件中。
4. ECU配置
ECU配置主要是为该ECU添加必要的信息和数据，如任务调度、必要的基础软件
模块及其配置、运⾏实体及任务分配等，并将结果保存在ECU配置描述⽂件中，
该⽂件包含了属于特定ECU的所有信息，换⾔之，ECU上运⾏的软件可根据这些
信息构造出来。
5. ⽣成可执⾏⽂件
根据ECU配置描述⽂件中的配置信息，⽣成RTE和基础软件配置代码，完成基础软
件和软件组件的集成，最终⽣成ECU的可执⾏代码。

四、AUTOSAR的接⼝类型
通过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抽象层传递给服务层使⽤。

五、AUTOSAR的基础软件层
在上述AUTOSAR的分层模型中，最重要也是最复杂的，莫过于基础软件层BSW了。所
以，接下去会花⼤篇幅重点介绍⼀下这个BSW。

⾸先，对基础软件层BSW进⾏进⼀步的细分，划分为4层：微控制器抽象层，ECU抽象
层，服务层以及复杂驱动层。其中：

微控制器抽象层（MicroController Abstraction Layer，即MCAL），它位于BSW的

最底层，包含了跟硬件相关的驱动程序、软件模块与直接访问微控制器内部和外
围的设备，可以⽤来访问内存、通信和I/O等；
ECU抽象层（ECU Abstraction Layer），位于微控制器抽象层之上，对接微控制器
抽象层所提供的驱动程序，并同时包含对外部设备的驱动程序，然后负责向上提
供统⼀的访问接⼝实现对通信、内存或者I/O的访问，从⽽使得上层模块⽆须考虑
这些资源由微处理器提供还是由外部设备提供；
服务层（Service Layer），提供各种类型的后台服务，例如⽹络服务、内存管理
和总线通信服务等，操作系统就位于这⼀层。服务层是基础软件的最⾼层，同时
与应⽤程序也有关联。虽然对I/O信号的访问由ECU抽象层覆盖，但服务层负责提
供以下接⼝：操作系统的功能、⻋辆⽹络通信管理服务、存储器服务（NVRAM管
理）、诊断服务（包括UDS通信、错误存储和故障处理）、ECU状态管理，模式
管理、逻辑和时间程序流监控（Wdg管理器）、密码服务（密码服务管理）；
复杂驱动层（Complex Drivers Layer，即CCD），跨越于微控制器硬件层和RTE之
间，其主要任务是整合具有特殊⽬的且不能⽤MCAL进⾏配置的⾮标准功能模块，
将该部分功能嵌⼊到AUTOSAR基础软件层中，从⽽实现处理复杂传感器以及执⾏
器的特定功能和时间要求，提供集成特殊⽤途的功能，例如设备驱动程序，在
AUTOSAR中未规定的、具有⾮常⾼的时间限制或⽤于迁移等⽬的；

如下图所示：

所以，总结⼀下，基础软件层BSW的组件及其功能对应如下：

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

同时，对BSW中的各个⼦层，还可以从功能上将其中的各个模块划分为4种类型，分别
为驱动模块Driver、接⼝模块Interface、处理模块Handler以及管理器Manager。

1. 驱动模块Driver
驱动模块包含了控制和使⽤内部或者外部器件的功能，分为内部驱动和外部驱
动。
1）内部驱动
内部器件位于微控制器（单⽚机）的内部，例如内部EEPROM、内部CAN控制
器、内部ADC模块等。
内部驱动程序就是针对单⽚机内部器件资源的驱动程序，这部分驱动程序属于微
控制器抽象层（MCAL）。
2）外部驱动
外部器件是指单⽚机外部的ECU硬件，⽐如外部EEPROM、外部看⻔狗、外部
Flash等。外部驱动程序就是针对单⽚机外部硬件资源的驱动程序，属于ECU抽象
层。外部驱动程序需要通过微控制器抽象层（MCAL）驱动程序来实现对外部器件
的驱动。这种⽅法下AUTOSAR也⽀持嵌⼊在系统基础芯⽚（SBCs）中的组件，
像收发器以及看⻔狗等。例如，使⽤SPI通信接⼝的外部EEPROM驱动程序是通过
SPI总线处理程序来驱动外部EEPROM的。但是有⼀种例外，对于和内存映射相关
的外部器件（如外部Flash存储器），其驱动程序是可以直接对微控制器进⾏存取
访问的，所以这部分驱动程序属于微控制器抽象层（MCAL）。
2. 接⼝模块Interface
接⼝模块包含了对其次级模块进⾏抽象的功能，⽐如对⼀个特定功能的硬件进⾏
抽象。它提供⼀个通⽤的接⼝函数（API）来访问⼀种特定的器件类型，且与该类
型器件的数⽬⽆关，同时也与器件的具体硬件实现⽆关。
接⼝模块不会改变数据的内容。⼀般来说，接⼝属于ECU抽象层。例如，CAN通
信系统的接⼝模块提供⼀个通⽤的接⼝函数来访问CAN通信⽹络，并且与ECU上
CAN控制器的数⽬以及硬件实现⽆关。
3. 处理模块Handler
处理模块是⼀个专⽤的接⼝，它控制⼀个或多个客户端对⼀个或多个驱动程序进
⾏并⾏、多重以及异步地访问。也就是说，它起着缓冲、队列、仲裁以及多路复
⽤的功能。同时，处理程序也不会改变数据本身的内容。处理模块通常会并⼊驱
动程序或是接⼝模块中（如SPIHandlerDriver、ADC Driver等）。
4. 管理器Manager
管理器为多重的客户端提供特定的服务。当单纯的处理程序不能满⾜对多重的客
户端进⾏抽象时，就需要⽤到管理器来进⾏处理。除了处理功能外，管理器还可
以对数据内容进⾏评估、改变或是适应数据内容。
⼀般⽽⾔，管理器属于服务层。例如，⾮易失性随机存储器（NVRAM）的管理器
负责对内部或是外部存储设备进⾏并⾏的访问，如Flash、EEPROM存储器等。同
时，它也可以完成分布式并且可靠的数据存储、数据校验以及默认值的规定等。

从上⾯的划分⻆度出发，同时考虑到基础软件层主要⽤于向上提供基础软件服务，包
括标准化的系统功能以及功能接⼝。所以，也可以从服务类型的⻆度，将上述4个⼦层
更进⼀步的细分成⼀系列的基础服务软件组件，包括系统服务（System Services）、
存储服务（Memory Services）、通信服务（Communication Services）、以及IO服务
（I/O Services）等，如下图：

下⾯进⾏展开解释：

1、微控制器抽象层
微控制器器抽象层位于AUTOSAR分层模型中的BSW的最底层，它包含内部驱动，可以
直 接 访 问 微 控 制 器 和 ⽚ 内 外 设 。 进 ⼀ 步 的 ， MCAL⼜ 可 分 为 微 控 制 器 驱 动 模 块 组
（Microcontroller Drivers）、存储器驱动模块组（Memory Drivers）、通信驱动模块组
（Communication Drivers）、以及I/O 驱动模块组（I/O Drivers）。各个部分⼜由具体
的与微控制器硬件相对应的驱动模块组成，如下图：

1.1、微控制器驱动

微控制器驱动由通⽤定时器驱动（General Purpose Driver，GPT Driver）、看⻔狗驱动

（ Watchdog Driver ， WDG Driver ） 、 微 控 制 器 单 元 驱 动 （ Microcontroller Unit
Driver，MCU Driver）和内核测试（Core Test）四个部分组成。

1.1.1、GPT Driver

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

GPT驱动的作⽤是：

启动和停⽌硬件定时器；
得到定时器数值；
控制时间触发的中断；
控制时间触发的中断唤醒。

1.1.2、WDG Driver

WDG Driver的功能主要是初始化和触发看⻔狗。WDG Driver有内部WDG Driver和外部

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

1.1.3、MCU Driver

MCU Driver位于MCAL层，可以直接访问微控制器硬件，它的主要功能是初始化、休
眠、复位微控制器以及提供其他MCAL软件模块所需的与微控制器相关的特殊功能。
MCU Driver还能够使能并设置MCU时钟，例如CPU时钟、外围器件时钟、预分频器等
参数。

1.1.4、Core Test

Core Test（内核测试）模块包含周期性测试和启动测试。内核测试模块可以对CPU所
有寄存器进⾏测试，提供中断控制和异常检测。该模块还对算术逻辑单元、存储保护
单元和缓存控制器等进⾏检测。

1.2、存储器驱动

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

1.2.1、内部EEPROM驱动

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

1.2.2、内部Flash驱动

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

1.2.3、RAM测试

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

1.2.4、Flash测试

flash测试模块提供算法来测试诸如数据/程序闪存、程序SRAM等⾮易失性存储器，这
些存储器可以是集成在微控制器内部的，也可以是外部映射到微控制器的存储器。

1.3、通信驱动

通信驱动由以太⽹（Ethernet）驱动、FlexRay驱动、CAN驱动、LIN驱动和SPI驱动五
部分组成。

1.3.1、Ethernet驱动

Ethernet驱动模块使⽤以太⽹驱动层访问某些控制器，对所使⽤的以太⽹控制器的硬件
特性进⾏抽象，为上层的以太⽹使⽤提供统⼀的接⼝。可由由若⼲个以太⽹驱动模块
复合起来组成。

1.3.2、FlexRay驱动

FlexRay驱动⽤来抽象不同的FlexRay通信控制器及其硬件相关的特性。通信控制器的
FlexRay协议强制特性经过封装后只能通过统⼀的API进⾏访问。API提供了映射到基于
实际通信控制器的硬件访问序列的抽象功能操作。因此，使⽤FlexRay驱动可以保证
FlexRay接⼝独⽴于硬件。

对内部或外部FlexRay通信控制器的驱动来说，需要进⾏下列处理：

FlexRay控制器的初始化；
配置数据处理单元；
控制指令向通信控制器的传递；
从协议引擎到控制器主接⼝状态数据的规定；
通信控制器和主处理机之间信息数据的传输。

1.3.3、CAN驱动

CAN驱动针对的是微控制器内部的CAN控制器，它可以实现以下功能：

对CAN控制器进⾏初始化；
发送和接收报⽂；
对报⽂的数据和功能进⾏通知（对接收报⽂的指示、对发送报⽂的确认）；
溢出和错误处理；
唤醒检测；

此外，CAN驱动还具有以下特性：

单个或多个CAN通道；
CAN驱动的多重实例化；
对接收报⽂的中断/轮询模式；

CAN驱动是MCAL的⼀部分，可以执⾏硬件访问、向上层提供独⽴于硬件的API，⽽仅
有的能够访问CAN驱动的上层是CAN接⼝（CAN Interface）。CAN驱动也可以为数据
传输的初始化和通知接收事件的回调函数提供服务，该服务也是独⽴于硬件的。除此
之外，CAN驱动也可以控制从属于同⼀个CAN硬件单元的CAN控制器的⾏为和状态。

1.3.4、LIN驱动

LIN驱动使⽤标准的通⽤异步收发器（Universal Asynchronous Receiver Transmitter，

UART）或者串⾏通信接⼝（Serial Communication Interface，SCI）进⾏通信。

该模块可以完成下列任务：

LIN硬件的初始化；
调度表的处理；
LIN报⽂的发送（通过标志位和函数接⼝确认）；
LIN报⽂的接收（通过标志位和函数接⼝指示）；
睡眠和唤醒；
协议差错的处理；
报⽂的超时监测；

LIN驱动也是MCAL的⼀部分，可以执⾏硬件访问、向上层提供独⽴于硬件的API。仅有
的能够访问LIN驱动的上层是LIN接⼝（LIN Interface）。⼀个LIN驱动可以⽀持多个通
道，但是这些通道要属于同⼀个LIN硬件单元。

1.3.5SPI驱动

SPI驱动模块是微控制器内部同步通信串⾏接⼝的驱动。SPI驱动为SPI总线上不同的设
备（如EEPROM/Watchdog等）提供读写访问服务。⼀个SPI设备可以被所使⽤的SPI硬
件和相关的⽚选信号识别。该模块可以在主、从或者主-从模式下运⾏。

配置SPI驱动应遵循以下步骤：

选择SPI驱动的功能级别，配置可选择的功能特性；
根据数据⽤途来定义SPI通道，它们可以是SPI驱动的内部缓冲器，或者是由⽤户
提供的外部缓冲器；
根据硬件属性来定义SPI任务，它们会包含⼀系列使⽤这些属性的通道；
最后定义任务序列，以优先级排序的⽅式来传递数据；

1.4、I/O驱动

I/O驱动由PORT驱动、DIO驱动、ADC驱动、PWM驱动、ICU驱动、OCU驱动六部分组
成。

1.4.1、PORT驱动

PORT驱动初始化就是对微控制器的整个PORT模块进⾏初始化配置。

很多端⼝和管脚被分配有多种不同的功能，即可以进⾏引脚功能复⽤，⽐如通⽤I/O、
模数转换、脉宽调制等功能。因此，对PORT必须有⼀个整体的配置和初始化，对各管
脚的具体配置和使⽤取决于微控制器和ECU的引脚功能分配。PORT初始化数据应当尽
可能⾼效地写到每个端⼝。DIO驱动中所⽤到的端⼝的配置和初始化都是在PORT驱动
模块中完成的。因此，在使⽤DIO功能之前，应先进⾏PORT的初始化。

1.4.2、DIO驱动

DIO驱动对微控制器硬件管脚的访问进⾏了抽象，除此之外，还可以对管脚进⾏分组。
该模块通过DIO通道、DIO端⼝以及DIO通道组来读写数据，⽽且这类操作是同步的。

1.4.3、ADC驱动

ADC驱动对微控制器内部模数转换单元进⾏初始化和控制。它可以提供启动和停⽌模
数转换的服务，分别⽤来开启和禁⽤模数转换的触发源。

1.4.4、PWM驱动

PWM驱动为微控制器PWM模块提供初始化和控制服务，可⽣成周期和占空⽐都可变的
脉冲。

1.4.5、ICU驱动

ICU驱动控制的是微控制器的输⼊捕获单元（Input Capture Unit），有两种模式：正常

模式和休眠模式。

ICU驱动可以提供以下服务：

信号边沿检测及通知；
中断唤醒；
周期性信号时间的测量；
边沿时间戳捕获；
边沿/脉冲计数；

1.4.6OCU驱动

OCU驱动的作⽤是对微控制器内部的输出⽐较单元（Output Compare Unit）进⾏初始

化和控制。当计数器的值到达某个阈值时，OCU模块会⾃动开始⽐较并执⾏相应的操
作。