AutoSAR 学习笔记2：AutoSAR架构

1 应用层（ASW）

2 运行时环境层（RTE）

RTE 是专门为应用软件（AutoSAR 软件组件和 / 或 AutoSAR 传感器 / 执行器组件）提供通信服务的层。在 RTE 之上，软件架构风格从 “分层” 转变为 “组件风格”。AutoSAR 软件组件通过 RTE 与其他组件（内部和/或内部 ECU）或服务进行通信。它的作用是使 AutoSAR 组件完全独立于 ECU ,如下图：

RTE 的实施特定与 ECU 和 应用程序（为每个 ECU 单独生产）。

3 基础软件层（BSW）

BSW 进一步被抽象划分为 4 层，分别是微处理器抽象层（Microcontroller Abstraction Layer，MCAL）、ECU抽象层（ECU Abstraction Layer）、软件服务层（Service Layer）以及复杂驱动层（Complex Driver，CDD），如下图：

BSW 从服务类型的角度，将上述 4 层 更进一步的细分成一系列的软件组件服务组件，包括系统服务、存储服务和通信服务等，如下图：

3.1 微处理器抽象层（Microcontroller Abstraction Layer，MCAL）

微处理器抽象层（Microcontroller Abstraction Layer，MCAL）位于 BSW 的最底层，它包含了跟硬件相关的驱动程序，可以直接访问微处理器和片内外设。它的作用是让 MCAL 层的上层软件独立于 MCU 硬件。MCAL 的实现依赖于 uC。进一步，MCAL 又可分为微处理器驱动模块组（Microcontroller Drivers）、存储器驱动模块组（Memory Drivers）、加密驱动模块组（Crypto Drivers）、无线通信驱动模块组（Wireless Communication Drivers）、通信驱动模块组（Communication Drivers）以及 I/O 驱动模块组（I/O Drivers）,如下图：

各个部分由具体的与微控制器硬件相对应的驱动模块组成如下图：

3.1.1 微处理器驱动（Microcontroller Drivers）

微处理器驱动由通用定时器驱动（General Purpose Timer Driver，GPT Driver）、看门狗驱动（Watchdog Driver，WDG Driver）、微处理器单元驱动（Microcontroller Unit Driver，MCU Driver）和内核测试（Core Test）四个部分组成。

3.1.2 存储器驱动（Memory Drivers）

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

3.1.3 加密驱动（Crypto Drivers）

加密驱动（Crypto Drivers）由片上加密驱动设备（如 SHE/HSM）组成。

3.1.4 无线驱动（Wireless Communication Drivers）

无线驱动（Wireless Communication Drivers）由无线网络系统（车内无线网络或非车载通信系统）组成。

3.1.5 通信驱动（Communication Drivers）

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

3.1.6 I/O 驱动（I/O Drivers）

I/O 驱动（I/O Drivers）由 PORT 驱动、DIO（Digital Input/Output） 驱动、ADC 驱动、PWM 驱动、ICU（Input Capture Unit）驱动、OCU（Output Compare Unit）驱动六部分组成。

3.2 ECU 抽象层（ECU Abstraction Layer）

ECU 抽象层（ECU Abstraction Layer）位于 MCAL 之上，对接 MCAL 所提供的驱动程序，并同时包含对外部设备的驱动程序，然后负责向上提供统一的访问接口实现对通信、内存或 I/O 口的访问。从而使得上层模块无需考虑这些资源是由微处理器提供的还是由外部设备提供的。它的作用是让 ECU 抽象层的上层软件独立于 ECU 硬件。ECU抽象层的实现与 uC 无关，但依赖于 ECU 硬件。进一步，ECU 抽象层可以分为板载设备抽象（Onboard Device Abstravtion）、存储器硬件抽象（Memory Hardware Abstraction）、加密硬件抽象（Crypto Hardware Abstraction）、无线通信硬件抽象（Wireless Communication Hardware Abstraction）、通信硬件抽象（Communication Hardware Abstraction）以及 I/O 硬件抽象（I/O Hardware Abstraction），如下图：

3.2.1 板载设备抽象（Onboard Device Abstravtion）

板载设备抽象（Onboard Device Abstraction）包含 ECU 板载设备的驱动，这些设备不能被认为是传感器或执行器，例如内部或外部看门狗。这些驱动访问 ECU 板载设备通过微处理器抽象层。它的作用是从 ECU 指定的板载设备上抽象。板载硬件抽象的实现与 uC 无关，但依赖于 ECU 外部设备。

例：

3.2.2 存储器硬件抽象（Memory Hardware Abstraction）

存储器抽象（Memory Hardware Abstraction）是一组从外设存储设备（片上或板载）和 ECU 硬件布局抽象出来的模块。例如：片上的 EEPROM 和 外部的 EEPROM 设备都可以通过相同的机制访问。存储设备被访问通过存储器特定的抽象/仿真模块（例 EEPROM 抽象）。通过在 Flash 硬件单元上的抽象模拟 EEPROM 抽象，可以通过内存抽象接口对两种类型的硬件进行通用访问。它的作用是通过相同的机制去访问内部（片上）和外部（板载）存储设备和类型的存储硬件（EEPROM，Flash）。存储器硬件抽象的实现与 uC 无关，但依赖于外部设备。

例：

3.2.3 加密硬件抽象（Crypto Hardware Abstraction）
加密硬件抽象（Crypto Hardware Abstraction）是一组从加密原语（基于内部或外部硬件或软件）抽象出来的模块。例如：AES 原语在 SHE 中被实现或作为软件库被提供。它的作用是提供相同的机制去访问内部（片上）和软件加密设备。加密硬件的实施与 uC 无关。

例：

3.2.4 无线通信硬件抽象（Wireless Communication Hardware Abstraction）

3.2.5 通信硬件抽象（Communication Hardware Abstraction）

通信硬件抽象（Communication Hardware Abstraction）是一组从通信控制器和 ECU 硬件布局抽象出来的模块。对于所有的通信系统都需要一个特定的通信硬件抽象（例如 LIN、CAN、FlexRay）。例如：一个 ECU 微控制器有 2 个内部 CAN 通道和一个 附加的板载带有 4 个 CAN 控制器的（ASIC）专用集成芯片，CAN-ASIC 通过 SPI 方式连接微控制器。通信驱动被访问通过总线特定的接口（CAN 接口）。它的作用是提供相同的机制去访问总线通道，而不管它的位置（片上/板上）。通信硬件抽象的实现与 uC 无关，但依赖于 ECU 硬件和外部设备。

例：

3.2.6 I/O 硬件抽象（I/O Hardware Abstraction）

I/O 硬件抽象（I/O Hardware Abstraction）是一组从外设 I/O 设备（片上或板载）和 ECU 硬件布局（例如 uC pin 脚连接和信号电平倒置）抽象出来的模块。I/O 硬件抽象不会从传感器/执行器抽象处理。不同的 I/O 设备可以通过 I/O 信号接口访问。它的作用是表示连接到 ECU 硬件的 I/O 信号（例如电流、电压、频率）。从更高的软件层隐藏 ECU 硬件和布局属性。I/O 硬件抽象的实施与 uC 无关，但依赖于 ECU 硬件。

例：

3.3 软件服务层（Service Layer）

软件服务层（Service Layer）位于 BSW 的最高层，同时与应用层软件也有关联。I/O 信号可以通过 ECU 抽象层获取，但服务层提供以下接口：操作系统功能、车辆网络通信管理服务、内存服务（NVRAM 管理）、诊断服务（包括 UDS 通信、错误存储和故障处理）、ECU 状态管理、模式管理、逻辑和时间流监控（Wdg 管理器）。它的作用是给应用层、RTE、BSW 模块提供最基础的服务。服务层的实现大多与 uC、ECU 硬件无关。进一步按照服务对象不同，服务层可以分为系统服务（System Services）、内存服务（Memory Services）、加密服务（Crypto Services）、非车载通信服务（Off-board Communication Services）以及通信服务（Communication Services），如下图:

3.3.1 系统服务（System Services）

系统服务（System Services）由一个模块组成，并且模块的函数可以被所有层的模块使用。例如实时操作系统（包括定时器服务）和错误管理器。其中一些服务是：uC 相关的（如操作系统：OS），并可能支持特殊的 uC 功能（如定时器服务），部分依赖于 ECU 硬件和应用程序（如 ECU 状态管理器）或部分独立于硬件和 uC。它的作用是为应用层和基础软件层提供服务。系统服务的实施部分依赖于 uC 和 ECU 硬件和 指定的应用程序。

例：

3.3.2 内存服务（Memory Services）

内存服务（Memory Services）由一个模块组成，即 NVRAM 管理器。它负责非易失性数据的管理（从不同的内存驱动读/写）。它的作用是以统一的方式向应用程序提供非易失性数据。提供非易失性数据管理机制，如保存、加载、校验和保护验证、可靠存储等。内存服务的实施与 uC 和 ECU 硬件无关，具有高度的可配置性。

例：

3.3.3 加密服务（Crypto Services）
加密服务（Crypto Services）由两个模块组成：1. 加密服务管理器负责加密工作的管理；2.密钥管理器与密钥供应主机（在 NVM 和 Crypto Driver 中）交互，并管理证书链的存储和验证。它的作用是以统一的方式向应用程序提供加密原语和密钥存储。加密服务的实施与 uC 和 ECU 硬件无关，具有高度的可配置性。

例：

3.3.4 非车载通信服务（Off-board Communication Services）

3.3.5 通信服务（Communication Services）

通信服务（Communication Service）是一组用于车载网络通信的模块（CAN、LIN、FlexRay 和以太网）。通信服务通过通信硬件抽象与通信驱动进行交互。它的作用是为车载通信网络和车载网络的诊断通道提供一个统一的接口，为网络管理提供统一的服务，以及从对应的应用程序中隐藏相关协议和消息属性。通信服务的实施与 uC 和 ECU 硬件无关，但部分依赖于总线类型。

例：

3.3.5.1 CAN 通信

CAN 通信服务是一组带有 CAN 通信网路的车载网络系统。它的作用是为 CAN 网路提供统一的接口，以及从应用程序中隐藏相关协议和消息属性。

3.4 复杂驱动（Complex Drivers，CDD）

复杂驱动的定义是在 AutoSAR 中未规定的、具有非常高的时间限制或用于迁移等目的的外设驱动。复杂驱动层跨越于 MCAL 和 RTE 之间，其主要任务是整合具有特殊目的且不能用 MCAL 进行配置的非标准功能模块，将该部分功能嵌入到 AutoSAR 基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。复杂驱动程序跟单片机和 ECU 硬件紧密相关。它的作用是满足处理复杂驱动传感器和执行器的特殊功能和定时要求，如下图：

复杂驱动可以使用特定的中断或复杂的微控制器外设（如 PCP、TPU）来直接访问微控制器，从而实现对复杂传感器的评估和执行器的控制，比如喷油控制、电磁阀控制、增量位置检测等，如下图：

复杂驱动的实施依赖于 uC、ECU 和应用层。

3.5 BSW 的组件及其功能总结

BSW 的组件及其功能对应如下：

1. 输入/输出：对传感器、执行器以及 ECU 板级外设的访问入口进行标准化；
2. 内存：对内部和外部的内存（非易失性存储器）的访问入口进行标准化；
3. 加密：对加密原语的访问入口进行标准化，包括内部/外部硬件加速器；
4. 通信：对汽车网络系统、ECU 通信系统以及 ECU 内部软件的访问入口进行标准化；
5. 非车载通信：对车和 X 通信、车载无线网络系统和 ECU 车载外通信系统的访问入口进行标准化；
6. 系统：提供标准化的规定（针对操作系统、定时器及错误存储器）、ECU 特定的服务（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）。
   例：SPIHandlerDriver
   SPIHanderDriver 允许并行访问一个或多个 SPI 总线，如下图：
   
   为了抽象出专用于片选的 SPI 微控制器引脚的所有特征，这些特征应由 SPIHandlerDriver 直接处理。这意味着这些引脚在 DIO Driver 中不可用，如下图：
   
   4 管理器（Manager）
   管理器为多重的客户端提供特定的服务。当单纯的处理程序不能满足对多重的客户端进行抽象时，就需要用到管理器来进行处理。除了处理功能外，管理器还可以对数据内容进行评估、改变或是适应数据内容。
   一般而言，管理器数据服务层。例如：非易失性存储器（NVRAM）的管理器负责对内部或外部存储设备进行并行的访问，如 Flash、EEPROM 存储器等。同时，它也可以完成分布式并且可靠的数据存储、数据校验以及默认值的规定等.