AUTOSAR的故事-昂辉科技

AUTOSAR的故事

发布时间：2025-04-30 浏览数：27

一、AUTOSAR架构概览

随着汽车向智能化、网络化、信息化方向不断发展，车载微控制器的数量呈几何级增长，由于汽车元件生产厂商的差异，导致汽车电子软件之间差异较大，不同厂家的软件不能复用。这不仅使汽车电子产品研发周期延长，而且使汽车软件开发成本增加。

为此，在2002 年，为解决上述问题，宝马、博世以及奔驰等知名企业联合起来提出了汽车网络开放式架构标准AUTOSAR，旨在统一汽车软件领域。次年，他们便着手开展相关工作，开始绘制 AUTOSAR 的草图。而对于这个要定义的统一架构，其具体涵盖哪些内容呢？彼时，一位工程师将自己的想法通过草图展现了出来。

在一次研讨会上，一位工程师向众人阐释AUTOSAR架构主要分为三层。话音未落，会场突然安静，众人心中疑惑：这么简单的架构真能统一复杂的汽车软件吗？但这位工程师并未在意，而是继续深入讲解。此架构关键在于基础软件（BSW）部分，它还可进一步细分为三层：

服务层（Services Layer）处于 BSW 的最高层，其作用是为应用（Application）提供访问由抽象层（Abstraction Layer）覆盖的 IO 信号等的途径。
ECU抽象层（ECU Abstraction Layer）主要是为底层驱动提供抽象接口，方便上层应用调用底层功能。该层将ECU结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器或者I/O的访问。
微控制器抽象层（MicrocontrollerAbstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。

而应用（Application）部分与其他架构中的应用类似，这里不再赘述。另外，运行时环境（Runtime Environment，简称 RTE）值得一提，它为应用提供通信服务，应用通过 RTE 能够访问 BSW 的功能，并且提供了统一标准的接口，极大地增强了各模块的可移植性，让各模块保持相对独立。

随后，工程师进一步细化架构图，并加以解释。比如 Memory Service，它能够让应用通过 RTE 进行调用，还创建了很多便于应用访问的接口，其实现方式是通过调用 Memory Hardware Abstraction 来访问 Memory Drivers。通过这样的三层关系，基本能够满足市面上大部分功能需求。不过，总会存在这几层架构无法实现的功能，此时 Complex Drivers 就派上用场了，它允许用户自行定义，以实现一些复杂的驱动功能。

以 Memory Service 为例，它为 Application（应用程序）提供了便利，能让 Application 通过 RTE（运行时环境）进行调用，并且设置了诸多可供应用程序访问的接口方法。而 Memory Service 访问 Memory Drivers（内存驱动程序）的方式，是通过调用 Memory Hardware Abstraction（内存硬件抽象层）来实现的。

通过这三层关系就实现市面上大部分功能需求了。但是，总会有这几层实现不了的功能吧，怎么办？Complex Drivers就可以提供给用户自己定义啦，可以做一些复杂的驱动。

基础软件（BSW）按照功能类型还可细分如下：

Input/Output (I/O):它实现对传感器、执行器及板上外围器件的标准化访问，为不同设备搭建统一交互通道，保障汽车电子系统采集与指令下达的准确与稳定。
Memory:规范对非易失性存储器（NVM）的访问，确保车辆重要数据能有序存储、便捷读取，支撑系统数据管理的高效和安全。
Crypto:提供密码原语访问标准，涵盖内外部硬件加速器，保障车辆关键信息传输时加密、解密操作规范，维护信息安全。
Communication:负责访问车辆内各通信系统，制定统一 “通信规则”，让 ECU 间及内部软件能顺畅交互、协同工作，确保系统通信有序。
Off-board Communication:专注车辆到外部通信的标准化访问，在车与云端、路侧单元等交互时，确保按标准有序开展，助力汽车与外界互联互通。
System:提供操作系统等通用服务，以及 ECU 特定服务（如 ECU 状态管理、看门狗管理器等），全方位支持系统运行，是保障汽车电子系统稳定可靠的关键所在。

除此之外，还有一个容易被忽略的部分 ——Library（库）。它实际上是众多函数的集合，具备以下特点：

可被 BSW 模块（包括 RTE）、软件组件（SW-C）、集成代码调用
在同一保护环境中，于调用方的上下文中运行
只能调用库自身内容
具有可重用性，即可以被重复调用而不影响其功能和数据
没有内部状态，不会因多次调用产生额外的状态变化
不需要任何初始化操作，调用时相对便捷
是同步的，不存在等待点，调用过程较为直接

二、AUTOSAR的基础软件层

基础软件（BSW）在 AUTOSAR 架构中至关重要，工程师对此进行了详细讲解，参会人员也越发觉得 AUTOSAR 有望成为行业统一标准，并期待了解更多细节内容。

2.1.MCAL（Microcontroler Abstraction Layer，微控制器抽象层）

Microcontroller Drivers（微控制器驱动）：具备直接访问微控制器内部外围设备（例如看门狗、通用定时器等）的权限，像核心测试等相关驱动程序都归属于此，负责对这些内部设备进行驱动管理。
Communication Drivers（通信驱动）：涵盖车载 ECU（例如 SPI 接口相关）和车辆通信（例如 CAN 总线等）的驱动程序，属于 OSI 层中数据链路层的一部分，保障通信链路的正常运行。
Memory Drivers（存储驱动）：负责对片上存储设备（例如内部闪存、内部 EEPROM）以及存储器映射的外部存储设备（例如外部闪存）进行驱动管理，方便数据在不同存储介质中的读写操作。
I/O Drivers（输入 / 输出驱动）：用于模拟和数字 I/O 的驱动器（例如 ADC、PWM、DIO 等），实现对各种输入输出信号的处理和控制。
Crypto Drivers（加密驱动）：针对 SHE 或 HSM 等片上加密设备的驱动程序，确保加密相关操作能顺利执行。

例如，SPIHandlerDriver 允许多业务并发访问，它抽象出了 SPI 的所有功能，但用于 SPI 功能的 IO 在使用时不能另作他用，以此保证 SPI 功能的独立性和稳定性。

2.2. CDD（Complex Driver，复杂驱动）

CDD 用于实现 BSW 里面非标准化功能。也就是说，在标准化定义之外的功能，像 UART（通用异步收发传输器），由于 MCAL 中没有对其进行标准化定义，就可以通过 CDD 来实现相应功能。

2.3. I/O Hardware Abstraction（I/O 硬件抽象）

这是一组模块，它的主要作用是从外围 I/O 设备（片上或板上）的位置以及 ECU 硬件布局（例如微控制器引脚连接和信号电平反转等情况）中进行抽象，但不会从传感器 / 执行器中抽象出来。可以通过 I/O 信号接口来访问不同的 I/O 设备，以此简化对 I/O 设备的操作和管理。

2.4. Communication Hardware Abstraction（通信硬件抽象）

同样是一组模块，不过它是从通信控制器的位置和 ECU 硬件布局方面进行抽象。对于不同的通信系统（例如 LIN、CAN、FlexRay 等），都需要特定的通信硬件抽象来进行适配。例如，当 ECU 具有带 2 个内部 CAN 通道的微控制器，并且还有带 4 个 CAN 控制器的附加板载 ASIC，且 CAN - ASIC 通过 SPI 连接到微控制器时，就可通过总线特定的接口（例如 CAN 接口）去访问通信驱动程序，确保通信的正常开展。

2.5. Memory Hardware Abstraction（存储硬件抽象）

该模块是从外围存储设备（片上或板载）的位置和 ECU 硬件布局中抽象出来的一组模块。例如，能够通过相同的机制去访问片上 EEPROM 和外部 EEPROM 器件，并且可以借助特定于存储器的抽象 / 仿真模块（例如 EEPROM 抽象）来访问存储器驱动程序。通过在闪存硬件单元顶部模拟 EEPROM 抽象，还能通过存储器抽象接口对这两种类型的硬件实现通用访问，方便了对不同存储硬件的统一管理。

2.6. Onboard Device Abstraction（板载设备抽象）

包含用于 ECU 板载设备的驱动程序，这里的板载设备不能简单视为传感器或执行器，如内部或外部看门狗等设备。这些驱动程序通过微控制器抽象层来访问 ECU 车载设备，从而实现对相关板载设备的有效控制和管理。

2.7. Crypto Hardware Abstraction（加密硬件抽象）

它是从加密基元（内部或外部硬件或基于软件的加密元素，例如 AES 原语在 SHE 中实现或者作为软件库提供等情况）的位置进行抽象的一组模块，便于对加密相关硬件进行统一管理和操作。

2.8. Crypto Services（加密服务）

加密服务管理器，其职责是对加密作业进行全面管理，确保加密操作按要求有序执行。
密钥管理器，它负责与密钥预配置主机（在非易失性存储器 NVM 或加密驱动程序中）进行交互，并管理证书链的存储和验证工作，保障加密过程中的密钥和证书管理安全可靠。

2.9. Communication Services（通信服务）

是一组用于车辆网络通信（涵盖 CAN、LIN、FlexRay 和以太网等常见网络类型）的模块，它们通过通信硬件抽象与通信驱动程序进行接口对接。这部分涉及的内容较多且重要，比如涉及到 CAN、LIN 甚至 TCP/IP 等通信协议相关内容，后续通常需要另外召开会议深入讨论，以更好地梳理和明确相关细节及应用。

讲到这里，会上的其他人听着听着有些懵逼，越讲越复杂了，工程师停了下，说，通信服务这部分，涉及到CAN、LIN甚至TCP/IP等，内容很多也很重要，后续我们另外召开会议讨论吧。

2.10. Memory Services（存储服务）

主要由一个模块 ——NVRAM 管理器构成，它负责对非易失性数据进行管理（涵盖从不同的内存驱动器读取 / 写入数据等操作）。它以一种统一的方式向应用程序提供非易失性数据，包括对内存位置和属性等信息进行汇总整理，同时还提供诸如保存、加载、校验和保护、验证以及可靠存储等非易失性数据管理机制，确保数据的安全性和完整性。

2.11. System Services（系统服务）

是一组可为所有层的模块所使用的模块和功能集合。例如实时操作系统（包含计时器服务）以及错误管理器等都属于系统服务范畴。其中部分服务依赖于微控制器（例如操作系统本身），可能还会支持特殊的微控制器功能（例如时间服务）；部分服务则依赖于 ECU 硬件和应用程序（例如 ECU 状态管理），还有些是与硬件和微控制器相对独立的。它既为基本软件模块提供支持，也为上层应用提供基本的服务保障。