[AutoSAR系列] 1.3 AutoSar 架构

依AutoSAR及经验辛苦整理，原创保护，禁止转载。

专栏 《深入浅出AutoSAR》

1. 整体架构

​

图片来源： AutoSar 官网

从官往图中可以看出autosar作为汽车ECU软件架构，是通过分层来实现软硬件隔离。就像大多数操作系统一样，通过分层实现软件架构的最通用化。

上面的框框有点零碎，我们试着来归纳下，抽象成下图。 可以更清晰看出它的层级关系。

​

为了实现应用程序和硬件模块之间的分离，AUTOSAR被抽象成四层：由上至下依次为：应用层（Application Layer）、运行时环境（Run Time Environment，RTE）、基础软件层（Basic Software，BSW）以及微控制器（Microcontroller）。

其中应用程序、实时运行环境(RTE)和基本软件(BSW) 是架构中三个软件层。作为汽车人， 因为有 AutoSar， 我们可以不受硬件改动影响，关注于软件层。

• 应用软件层：逻辑代码，基本上是与硬件无关的。
• 实时运行环境：应用程序的完整接口，软件组件之间的通信和通过RTE访问BSW。
• 基础软件层：分为三个主要层次和复杂的驱动因素: 服务、ECU(电子控制单元)抽象和微控制器抽象。服务进一步划分为代表系统、内存和通信服务的基础设施的功能组。

后续仔细讲解每一个小的组件模块。

2. App应用层

​

ApplicationLayer实现具体的应用功能，由软件组件（SWC）组成，基于AutoSAR设计的SWC组件能够提高上层应用软件的复用性和灵活性。

每一个SWC相当于一个.c文件，SWC和SWC之间的通信又会通过Port（端口）实现，SWC内部又有多个runable（运行实体）组成。

3. RTE运行时环境

​

目的：使SWC与ECU的映射无关，隔离APP和BSW

功能：提供跨ECU /ECU内部的通信管理

实现:

1. RTE对Runnables的运行支撑（Runanable的触发条件）

2. RTE对Ports支撑（S/RC/S port的通信方式）

3. 实现SWC之间的通信

4. RTE对数据一致性管理

4. BSW基础软件

4.1 BSW 分层

BSW被抽象划分为四部分：微控制器抽象层，ECU抽象层，服务层以及复杂驱动。

ServiceLayer：服务层

1. 提供给应用程序的服务，例如网络服务、内存管理和总线通信服务等

2. 诊断，非易失性内存管理，操作系统（OS），通讯

3. 内存和ECU管理

特别注意：CDD不属于BSW，它是独立Autosar架构的一些复杂驱动，直接通过CDD_SWC来操作硬件驱动。

ECUAbstraction Layer：ECU抽象层

提供统一的访问接口实现对通信、内存或者I/O的访问，从而无须考虑这些资源由微处理器提供还是由外部设备提供。

1. 使上层软件与ECU硬件设计无关

2. 包含ECU板上外部设备的驱动

3. 内部设备与外部设备的接口（I/O）

MCAL:Microcontroller Abstraction Layer 微控制器抽象层

1. 使上层软件与微控制器硬件无关，实现软硬件隔离。

2. 实现MCU中外设的驱动，可以用来访问内存、通信和I/O等

复杂驱动（CCD）

层跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。

4.1 BSW 组件

如下图所示：

基础软件层的组件及其功能对应如下：

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存储器等。同时，它也可以完成分布式并且可靠的数据存储、数据校验以及默认值的规定等。

5. MCAL微控制器抽象层

MCAL就是硬件驱动的封装，比如CAN、ETH、SPI等外设驱动封装，和芯片息息相关。一般都是购买芯片原厂MCAL的软件包。

​

主要分为4大模块：

微控制器驱动

1) GPT:General Purpose Timer Driver，通用定时器，为操作系统或者其他基础软件模块提供计时功能

2)  Watchdog：看门狗驱动，除防止程序跑飞基本功能外，功能安全还使用看门狗进行程序流监控，比如监控程序执行时间、执行顺序等。

3) MCU：Microcontroller Unit Driver,基本的MCU设置：时钟、休眠、复位设置等。

4)  Core Test：芯片内核测试，提供上电或者周期检测两种方式，检测结果能触发中断。

存储器驱动

1) Flash Test & Ram Test：存储器测试驱动。

2)  Flash/Eep Driver：提供基本的存储器操作，如初始化，擦除，写入，读取等。

通信驱动

CAN、ETH、LIN、SPI等通讯外设的通信功能实现

I/O驱动

1) Port：所有端口的统称，包含了（DIO和配置成特有功能的io口）

2) ADC：模拟/数字转换器，采样模拟信号，转成数字信号。

3)  DIO：Digital Input/Output Driver，数字输入输出驱动，也就是配置成GPIO功能，实现通用的输入输出功能。

4) PWM：生成周期和频率可变的PWM方波

5)  ICU：Input Caputre Unit,输入捕获单元，捕获方波周期或者捕获方波电平持续时间。

6) OCU：Output Compare Unit，输出比较单元，基于定时器单元的比较模块。

参考文献

面包板社区	浅论汽车电子行业的汽车开放系统架构AUTOSAR-汽车
汽车工程师谈技术	AUTOSAR架构 - 知乎