目录

往期推荐

Autosar培训笔记整理＜一＞

AUTOSAR 产品

AUTOSAR Classic Platform (CP):

AUTOSAR Foundation:

AUTOSAR Acceptance Tests (TC)

AUTOSAR Methodology and Templates

AUTOSAR Tools

CP VS AP

Autosar软件架构

 Top view

AUTOSAR基础软件划分为以下层次：

微控制器抽象层

微控制器抽象层由以下模块组组成：

示例：SPIHandlerDriver

ECU抽象层

I/O 硬件抽象

通信硬件抽象

内存硬件抽象

Onboard Device Abstraction

加密硬件抽象

服务层

复杂驱动层

运行时环境 (RTE)

虚拟功能总线 (VFB)

基本软件模块

服务类型

驱动程序（内部）

驱动程序（外部）

接口Interface

handler

管理器manager

库Libraries

---

往期推荐

1. ETAS工具链自动化实战指南＜一＞
2. ETAS工具链自动化实战指南＜二＞
3. ETAS工具链自动化实战指南＜三＞
4. AUTOSAR工程师必读：Artop的核心功能
5. Vector工具链自动化实战指南＜一＞
6. isolar高手秘籍| ECU Configuration三分钟速成！
7. 掌握核心步骤：RTA-BSW以太网配置全解析
8. 一文详解TC399 CAN MCAL 配置
9. LSL常见应用场景及示例＜一＞
10. LSL常见应用场景及示例＜二＞
11. LSL常见应用场景及示例＜三＞
12. 为什么Autosar钟情arxml而非json？大揭秘！
13. 深入浅出：SOME/IP-SD的工作原理与应用
14. 【技术进阶】|一文掌握Autosar ComStack的精髓！
15. 【AutoSAR进阶】|实战详解ETAS工具链UDS 0x2f服务核心配置！
16. 实战详解ETAS工具链CanTp模块自动化配置

17. Autosar培训笔记整理＜一＞

AUTOSAR（汽车开放系统架构，通常简称为“AR”）是一种开放且标准化的汽车软件架构，由汽车制造商、供应商和工具开发者共同开发。

AUTOSAR 产品

AUTOSAR 产品涵盖了一系列支持汽车电子/电气系统开发的标准化软件解决方案。以下是一些关键的 AUTOSAR 产品：

AUTOSAR Classic Platform (CP):

• 经典平台是 AUTOSAR 的基础架构，主要用于处理实时和安全关键的汽车电子控制单元（ECU）。

• 它支持高度集成的硬件和软件组件，适用于传统汽车系统中的电子电气架构（E/E架构

AUTOSAR Adaptive Platform (AP):

• 自适应平台是专为处理高级驾驶辅助系统（ADAS）、自动驾驶和互联车辆等新兴技术而设计的。

• 它支持动态配置和更新，并且能够处理复杂的软件应用程序和数据密集型任务。它提供了更灵活的中间件支持，并能够适应不断变化的系统需求，同时支持高性能计算和在线软件更

AUTOSAR Foundation:

AUTOSAR 基础层包括一系列为 Classic 和 Adaptive 平台提供支持的基础模块和工具集。这些模块涵盖了跨平台的标准接口和服务，为不同 AUTOSAR 平台之间的互操作性提供了基础

AUTOSAR Acceptance Tests (TC)

• 接受测试是为了验证 AUTOSAR 规范的实现是否符合标准。

• 它为开发人员和供应商提供了一个通用的测试框架，以确保产品的一致性和互操作性。

AUTOSAR Methodology and Templates

AUTOSAR 方法学和模板为软件开发过程提供了系统化的方法和规范。这些模板涵盖了从需求捕获、设计、实现到测试的整个开发生命周期，帮助开发人员有效地管理复杂的 E/E 架构。

AUTOSAR Tools

AUTOSAR 工具集包括各种支持开发、配置、集成和测试 AUTOSAR 基于软件的工具。这些工具可以由第三方工具供应商提供，帮助开发人员在 AUTOSAR 标准的框架下完成高效的软件开发工作。

CP VS AP

Autosar软件架构

 Top view

AUTOSAR架构在最高抽象层次上区分了三层软件：应用层、运行时环境（RTE）层和基础软件层，这些软件层运行在微控制器上。

AUTOSAR基础软件划分为以下层次：

1. 服务层

2. ECU抽象层

3. 微控制器抽象层

4. 复杂驱动程序层。

基础软件层进一步划分为功能组。例如，服务层包括系统服务、内存服务和通信服务。

微控制器抽象层

微控制器抽象层是基础软件的最底层软件层。它包含内部驱动程序，这些驱动程序是可以直接访问微控制器（μC）和内部外设的软件模块。

任务

使上层软件独立于微控制器

属性

实现：依赖于微控制器

上层接口：标准化且与微控制器无关

微控制器抽象层由以下模块组组成：

• 微控制器驱动：用于内部外设的驱动（例如看门狗、通用定时器），以及具有直接微控制器访问的功能（例如核心测试）。

• 通信驱动：用于 ECU 内部通信（例如 SPI）和车辆通信（例如 CAN）的驱动。OSI 层级：数据链路层的一部分。

• 内存驱动：用于芯片内存设备（例如内部闪存、内部 EEPROM）和内存映射的外部内存设备（例如外部闪存）的驱动。

• I/O 驱动：用于模拟和数字 I/O 的驱动（例如 ADC、PWM、DIO）。

• 加密驱动：用于芯片上的加密设备（如 SHE 或 HSM）的驱动。

• 无线通信驱动：用于无线网络系统的驱动（车载或外部通信）。

示例：SPIHandlerDriver

SPIHandlerDriver 允许多个客户端对一个或多个 SPI 总线进行并发访问。为了抽象出所有与 SPI 微控制器引脚相关的特性，这些引脚专用于芯片选择，因此应由 SPIHandlerDriver 直接处理。这意味着这些引脚不应在 DIO 驱动中可用。

ECU抽象层

ECU抽象层接口连接微控制器抽象层的驱动程序。它还包含用于外部设备的驱动程序。

功能

提供一个API，用于访问外设和设备，而不考虑它们的位置（微控制器内部/外部）以及它们与微控制器的连接方式（端口引脚、接口类型）。

任务

使上层软件独立于ECU硬件布局。

属性

实现：独立于微控制器，依赖于ECU硬件

上层接口：独立于微控制器和ECU硬件

I/O 硬件抽象

I/O 硬件抽象是一组模块，用于从外设 I/O 设备的位置（芯片内或板上）和 ECU 硬件布局（如 μC 引脚连接和信号电平反转）中抽象化。I/O 硬件抽象不对传感器/执行器进行抽象。

不同的 I/O 设备可能通过 I/O 信号接口进行访问。

任务：

• 表示与 ECU 硬件连接的 I/O 信号（如电流、电压、频率）。

• 隐藏 ECU 硬件和布局属性，使其对更高层的软件透明。

属性：

• 实现：与 μC 独立，依赖于 ECU 硬件

• 上层接口：与 μC 和 ECU 硬件独立，依赖于信号类型，按照 AUTOSAR 规范进行指定和实现（AUTOSAR 接口）

通信硬件抽象

通信硬件抽象是一个模块组，它将通信控制器的位置和 ECU 硬件布局抽象化。对于所有通信系统，都需要特定的通信硬件抽象（例如，对于 LIN、CAN、FlexRay）。

任务：

提供均等的机制来访问总线通道，无论其位置（芯片上/板载）。

属性：

实现：微控制器独立，依赖于 ECU 硬件和外部设备。

上层接口：依赖于总线，微控制器和 ECU 硬件独立。

示例：一台 ECU 配有一个具有 2 个内部 CAN 通道的微控制器，并且还配有一个具有 4 个 CAN 控制器的额外板载 ASIC。CAN-ASIC 通过 SPI 连接到微控制器。

通信驱动程序通过总线特定接口（例如 CAN 接口）进行访问。

内存硬件抽象

内存硬件抽象是一组模块，它将外部内存设备（芯片上或板载）的位置和 ECU 硬件布局抽象化。

内存驱动程序通过特定于内存的抽象/仿真模块（例如 EEPROM 抽象）进行访问。通过在 Flash 硬件单元上仿真 EEPROM 抽象，可以通过内存抽象接口实现对这两种类型硬件的统一访问。

任务：

提供统一的机制来访问内部（芯片上）和外部（板载）内存设备及内存硬件类型（EEPROM、Flash）。

属性：

实现：微控制器独立，依赖于外部设备。

上层接口：微控制器、ECU 硬件和内存设备独立。

示例：芯片上的 EEPROM 和外部 EEPROM 设备可以通过相同的机制进行访问。

Onboard Device Abstraction

Onboard Device Abstraction包含了用于 ECU 板载设备的驱动程序，这些设备不能被视为传感器或执行器，例如内部或外部看门狗。那些驱动程序通过微控制器抽象层访问 ECU 板载设备。

任务：

抽象化 ECU 特定的板载设备。

属性：

实现：微控制器独立，外部设备依赖。

上层接口：微控制器独立，部分依赖于 ECU 硬件。

加密硬件抽象

加密硬件抽象是一组模块，用于抽象化加密原语的位置（内部硬件、外部硬件或基于软件的）。

任务：

提供平等的机制来访问内部（片上）和软件加密设备。

属性：

实现：微控制器独立

上层接口：微控制器、ECU 硬件和加密设备独立

示例：AES 原语可以在 SHE 中实现，也可以作为软件库提供。

加密服务由两个模块组成：

• 加密服务管理器（Crypto Service Manager）：负责加密任务的管理。

• 密钥管理器（Key Manager）与密钥供应主设备（无论是在非易失性内存中还是加密驱动程序中）交互，管理证书链的存储和验证。

任务：

以统一的方式向应用程序提供加密原语和密钥存储。抽象化硬件设备和属性。

属性：

实现：微控制器和ECU硬件独立，高度可配置

上层接口：微控制器和ECU硬件独立，按照AUTOSAR规范进行规定和实现（AUTOSAR接口）

服务层

服务层是基本软件中的最高层，同时也是对应用软件最为重要的一层。虽然I/O信号的访问由ECU抽象层处理，但服务层提供以下功能：

• 操作系统功能

• 车辆网络通信和管理服务

• 存储服务（如NVRAM管理）

• 诊断服务（包括UDS通信、错误存储和故障处理）

• ECU状态管理、模式管理

• 逻辑和时间程序流程监控（看门狗管理器）

任务

为应用程序、RTE（运行时环境）和基本软件模块提供基础服务。

属性

• 实现：大多独立于微控制器和ECU硬件

• 上层接口：独立于微控制器和ECU硬件

复杂驱动层

复杂驱动程序是实现基础软件栈中非标准化功能的模块。例如，它可以实现复杂的传感器评估和执行器控制，通过特定的中断和/或复杂的微控制器外设（如 PCP、TPU）直接访问 μC，例如：

• 注射控制

• 电动阀控制

• 增量位置检测

任务：

满足处理复杂传感器和执行器的特殊功能和时序要求。

属性：

• 实现：高度依赖于微控制器、ECU 和应用

• 对软件组件的上层接口：根据 AUTOSAR 规范进行指定和实现（AUTOSAR 接口）

• 下层接口：对标准化接口的访问受限

运行时环境 (RTE)

RTE 是一个为应用软件（AUTOSAR 软件组件和/或 AUTOSAR 传感器/执行器组件）提供通信服务的层。

AUTOSAR 软件组件通过 RTE 与其他组件（ECU 内部和/或 ECU 之间）和/或服务进行通信。

任务

使 AUTOSAR 软件组件与映射到特定 ECU 的独立。

属性

• 实现：特定于 ECU 和应用程序（为每个 ECU 单独生成）

• 上层接口：完全独立于 ECU

虚拟功能总线 (VFB)

• 它是AUTOSAR中的一个核心概念，将应用程序与基础设施解耦。

• 软件组件（SWC）在抽象层面上仅通过通信ports与该虚拟化总线进行通信。

• VFB 处理单个 ECU 内部以及 ECU 之间的通信。从应用程序的角度来看，不需要详细了解底层技术或依赖关系。

• 它支持硬件无关的应用软件开发和使用。

基本软件模块

服务类型

基本软件可以细分为以下几种服务类型：

• 输入/输出 (I/O): 标准化访问传感器、执行器和ECU板载外设。

• 内存: 标准化访问内部/外部内存（非易失性内存）。

• 加密: 标准化访问包括内部/外部硬件加速器在内的加密原语。

• 通信: 标准化访问：车辆网络系统、ECU板载通信系统以及ECU内部软件。

• 车外通信: 标准化访问：车辆与外部通信、车内无线网络系统、ECU车外通信系统。

• 系统: 提供标准化的（操作系统、定时器、错误内存）和ECU特定的（ECU状态管理、看门狗管理）服务和库函数。

驱动程序（内部）

驱动程序包含控制和访问内部或外部设备的功能。内部设备位于微控制器内部。内部设备的示例包括：

• 内部 EEPROM

• 内部 CAN 控制器

• 内部 ADC

用于内部设备的驱动程序称为内部驱动程序，位于微控制器抽象层（Microcontroller Abstraction Layer）。

驱动程序（外部）

外部设备位于微控制器之外的ECU硬件上。外部设备的例子包括：

• 外部EEPROM

• 外部看门狗

• 外部闪存

用于外部设备的驱动程序称为外部驱动程序，位于ECU抽象层中。它通过微控制器抽象层的驱动程序访问外部设备。

这种方式也支持集成在系统基础芯片（SBCs）中的组件，如收发器和看门狗。

示例：具有SPI接口的外部EEPROM的驱动程序通过SPI总线的处理程序/驱动程序访问外部EEPROM。

接口Interface

接口（接口模块）包含将架构上方的模块与其下方的模块进行抽象化的功能。一般而言，接口位于ECU抽象层中。例如，接口模块可以抽象化特定设备的硬件实现。它提供了一个通用的API，以访问特定类型的设备，无论该类型设备的数量或不同设备的硬件实现如何。接口不改变数据的内容。

例如：一个CAN通信系统的接口提供了一个通用的API，以访问CAN通信网络，无论ECU内有多少CAN控制器或硬件实现（芯片内、芯片外）如何。

handler

• handler是一个特定的接口，用于控制一个或多个客户端对一个或多个驱动程序的并发、多重和异步访问。即，它执行缓冲、排队、仲裁和复用。

• handler不改变数据的内容。

• handler功能通常被整合在驱动程序或接口中（例如，SPI处理器驱动程序、ADC驱动程序）。

管理器manager

manager为多个客户端提供特定服务。在纯粹的处理器功能不足以抽象多个客户端的情况下，需要使用管理器。

除了处理器功能外，管理器还可以评估、改变或调整数据的内容。通常，manager位于服务层。

例如：NVRAM管理器管理对内部和/或外部存储设备（如闪存和EEPROM内存）的并发访问。它还执行分布式和可靠的数据存储、数据检查、默认值提供等功能。

库Libraries

Libraries是为相关目的提供的一组函数集合。

特点：

• 可以被基础软件模块（包括RTE）、软件组件、库或集成代码调用。

• 在调用者的上下文中运行，处于相同的保护环境下。

• 只能调用其他库。

• 支持重入。

• 没有内部状态。

• 不需要任何初始化。

• 是同步的，即没有等待点。