文章目录
前言
AUTOSAR通过纵向协议栈将BSW模块按功能垂直划分，形成高度专业化的“功能链”，同时通过标准接口（如PDUR、MemIf）实现横向协同。这种设计平衡了模块化与性能需求，是AUTOSAR架构的核心思想之一。
一、协议栈的分类
在AUTOSAR架构中，除了横向的分层（APP/RTE/BSW/MCAL），BSW（基础软件层）还从纵向功能维度划分为多个专用协议栈，每个协议栈针对不同的功能领域，具有独立的模块和交互逻辑。以下是详细的纵向协议栈分类及功能说明：
- 通信协议栈（Communication Stack）
- 功能：实现ECU内部及跨ECU的通信，支持多种总线类型
- 核心模块：CAN协议栈、 LIN协议栈、 FlexRay协议栈、Ethernet协议栈
- 内存协议栈（Memory Stack）
- 功能：管理非易失性存储（NVM）的读写、校验和故障恢复
- 核心模块：NVRAM Manager（NvM）、 Flash Driver（Fls）、EEPROM Driver（Eep）、Memory Abstraction Interface（MemIf）
- 系统服务协议栈（System Services Stack）
- 功能：提供基础系统服务，如时间同步、错误管理、ECU状态控制
- 核心模块：ECU状态管理、看门狗管理（WdgM/WdgIf）、 时间同步（StbM）、错误管理（Det/Dem）
- IO协议栈（I/O Stack）
- 功能：处理传感器/执行器的信号输入输出
- 核心模块：IO硬件抽象（Port/IoHwAb）、ADC/DIO驱动、PWM驱动
- 诊断协议栈（Diagnostic Stack）
- 功能：支持车辆诊断、故障记录及在线编程（OTA）
- 核心模块：诊断通信管理（DCM）、 诊断事件管理（DEM）
- 加密与信息安全协议栈（Crypto Stack）
- 功能：保障通信和数据安全（如身份认证、数据加密）
- 核心模块：Crypto Service Manager、Crypto Driver（CryIf/Cry）、安全通信（SecOC）
- 复杂设备驱动（CDD, Complex Device Driver）
- 功能：绕过RTE，直接访问硬件或中断，适合处理高实时性或非标准外设（如雷达、摄像头）
二、通信协议栈
在平常的arm编程中我们常常使用到各种各样的库，简单说就是将芯片的寄存器操作都封装称API函数，方便用户调用。Auto SAR的通信驱动也是一样，是将芯片上的关于通信的功能都封装称一个一个的API函数，供上层调用，而这些API函数是AutoSAR规定好的（通常驱动这一层叫做Mcal）。针对不同的芯片，在这一层就可以做到对上层的接口完全一致。这样的好处就是，当配置好了之后，同一个操作可以兼容所有芯片。
所谓的通信硬件抽象能够将通信控制器的位置以及 ECU的硬件布局进行抽象化处理，其主要任务是提供平等的机制来访问总线通道，而无需考虑其位置（是在芯片上还是在板载上）。在实际的使用过程中，我们主要使用LIN、CAN、FlexRay 三种协议，且其都需要特定的通信硬件抽象。
2.1 通信栈的分层
AUTOSAR 通信栈分为四层，从底层硬件抽象到应用层接口，层层递进：
从上面的流程中，我们可以看到存在两种信息通路，信号（Signal）传递和 COM模块的PDU传递，这是两个不同层级的通信路径，它们的核心区别在于是否经过协议封装和传输的抽象层级。
| 特性 | 信号（Signal） | COM 模块（Communication） |
|---|---|---|
| 定义层级 | 应用层概念，由 SWC 定义和交互 | 服务层模块，负责信号的实际打包/解包和传输 |
| 数据类型 | 原子数据单元（如车速 uint16、温度 float） | 处理信号的集合（报文/PDU），包含多个信号 |
| 配置方式 | 在 ARXML 中定义信号属性（长度、字节序等） | 配置报文（PDU）布局、路由和传输协议 |
| 接口调用 | 通过 RTE 接口（如 Rte_Read_XXX()） | 调用 Com_SendSignal() 或 Com_ReceiveSignal() |
| 抽象级别 | 高层逻辑数据（如车速、温度） | 底层协议实现（如报文打包、路由） |
| 硬件依赖 | 完全独立于硬件 | 依赖通信协议（CAN/LIN/Ethernet） |
这里我们以CAN协议简单举个栗子，应用层下达指令或者信号 → COM 将信号封装为 I-PDU → PDU Router 分发给对应的协议栈 → CAN TP（如需分帧） → 通过CanIf将 N-PDU 转换为 CAN 帧格式（标准/扩展帧） → CAN Driver将数据写入 CAN 控制器。
2.2 重要组件
COM 模块（Communication Module）
- 功能：
- 组包：将应用层信号按照特定规则组合成I-PDU（交互层协议数据单元）
- 解包：接收I-PDU并提取其中的信号数据
- 信号网关：实现不同通信通道间信号的转发和转换
- 信号过滤：基于配置规则筛选特定信号
- 超时监控：监测信号的更新状态，检测通信超时
- 关键点：
- 仅负责信号到I-PDU的映射关系
- 不涉及底层通信协议的具体实现细节
- 工作于AUTOSAR架构的通信服务层
PDU Router（PDU 路由器）
- 功能：
- 根据配置的路由表将I-PDU分发到目标通信协议栈
- 支持的协议栈包括：
- CAN总线协议栈
- LIN总线协议栈
- Ethernet协议栈
- FlexRay协议栈
- 实现不同通信协议间的PDU转换
- 关键点：
- 作为COM模块与底层通信协议的桥梁
- 提供统一的PDU传输接口
- 支持多协议并行通信
Transport Protocol 模块
- 功能：大协议数据单元的拆包和组包，TP模块负责将大协议数据单元（PDU）拆分成多个小的帧进行传输，以及在接收端将这些小的帧重新组合成原始的PDU
- CanTp：符合ISO标准15765-5，用于CAN总线系统。
- LinTp：用于LIN总线系统。
- FlexRayTp：用于FlexRay总线系统。
- 关键点：
- 将上层大尺寸数据分块为多个N-PDU（网络层PDU）或L-PDU（数据链路层PDU）
- 确保数据在传输过程中的完整性和顺序性
Ethernet/IP 相关模块
- SOME/IP：
- 面向服务的通信协议
- Adaptive AUTOSAR核心组件
- 主要特征：
- 服务发现机制
- 事件订阅/发布模式
- 序列化/反序列化功能
- 示例应用：自动驾驶系统中的传感器数据共享
- DoIP（Diagnostic over IP）：
- 基于IP的诊断通信协议
- 支持UDS over IP
- 典型应用场景：
- 车辆OBD诊断
- ECU软件刷写
- 远程诊断
- 关键点：
- 基于Socket的通信机制
- 支持TCP/IP协议栈
- 提供标准化的诊断服务接口
数据链路层 & 物理层接口
-
核心功能：使用驱动层提供的基于帧的服务，进一步向上层提供PDU（协议数据单元）的发送和接收服务。
- CAN Interface（CanIf）：
- 提供统一的CAN硬件抽象接口
- 功能包括：
- 硬件对象管理
- 控制器状态管理
- 错误处理
- LIN Interface（LinIf）：
- LIN总线的抽象接口
- 主要功能：
- 调度表管理
- 帧传输控制
- 唤醒管理
- Ethernet Interface（EthIf）：
- 以太网MAC层控制接口
- 支持功能：
- MAC地址过滤
- VLAN处理
- 流量控制
- CAN Interface（CanIf）：
-
驱动层
- CAN Driver：
- 直接操作CAN控制器硬件
- 实现功能：
- 硬件初始化
- 收发控制
- 错误处理
- 中断管理
- Ethernet Driver：
- 处理PHY和MAC层数据帧
- 主要功能：
- MAC地址配置
- PHY芯片控制
- DMA传输管理
- 中断处理
- CAN Driver：
三、内存协议栈
在内存栈中在服务层（NvM）、抽象层（MemIf、EA、EEP、Fee）、MCAL（Fls、SPI等）中均存在对应的模块，具体如下所示：
3.1 NVM（Non-Volatile RAM Manager）
车ECU内存中存在着各式各样的变量，大多数变量随着ECU的掉电会丢失数据，但也有一部分变量会伴随着整个ECU生命周期而一直存在，而这种不会丢失的数据便依赖与NVM。这部分在NVM详解一文中解释的很好，NVM（非易失内存管理）是应用app层访问非易失性数据的唯一接口，提供非易失数据的管理服务。
在AuoSAR架构中NvM的主要功能可以概述为以下几点:
- 提供了三种Block的管理类型（Native、Redundant、DataSet）
- Native：最常用的单一Block，用于对数据存储要求不高的场景
- Redundant：比Native多了一个相同大小的NV Block，2个NV Block可以形成冗余备份，一个Block异常，从另一个恢复数据
- Dataset：可以多达255个相同大小NV Block，使用比较灵活，可以根据需要对一个数据在NvRAM中以一定的循环偏移进行存储，实现对NvRAM的寿命延长
| 特性 | Native Block | Redundant Block | DataSet Block |
|---|---|---|---|
| 副本数量 | 1 | 2 | ≥ 3（可配置） |
| 可靠性 | 低 | 高（自动容错） | 中高（磨损均衡） |
| 写入性能 | 快 | 慢（双副本写入） | 中等（需管理多副本） |
| 存储开销 | 小 | 中等（2 倍空间） | 大（N 倍空间） |
| 典型应用 | 临时配置、日志 | VIN 码、安全参数 | 里程数据、故障记录 |
- 支持16bit和32bit的CRC校验
- 支持数据操作的优先级机制，支持Immediately写操作
- 给APP提供服务接口，NV Data类型的数据接口在APP层可以直接操作
- NvM与APP的同步机制
- 用于DCM诊断的数据操作
- 支持操作数据读写操作的完成以及错误的回调通知
- 可以配置的ID处理
3.2 MemService
MemService 是 AUTOSAR 基础软件（BSW）中内存服务模块的核心组件，负责为应用层和其他 BSW 模块提供统一的内存管理服务，其核心职责如下：
- 动态内存管理：提供类 malloc/free 的接口（需谨慎使用，因汽车电子通常避免动态分配）。
- 静态内存池管理：预分配固定大小内存块，提高实时性和安全性。
- 内存保护：配合 MPU（Memory Protection Unit）实现访问权限控制（如 ASIL-D 应用）。
- 内存错误检测：检测堆栈溢出、空指针访问等。
| 子模块 | 功能 | 应用场景 |
|---|---|---|
| MemIf（Memory Abstraction Interface） | 统一不同内存硬件（如 Flash/EEPROM/SRAM）的访问接口，供上层模块（如 NvM、Fee）调用 | 屏蔽底层存储差异，使 NvM 无需关心具体硬件 |
| Fee（Flash EEPROM Emulation） | 在 Flash 上模拟 EEPROM 行为，实现磨损均衡（Wear Leveling）和块管理 | 存储频繁更新的数据（如 DTC 记录），延长 Flash 寿命 |
| Ea（EEPROM Abstraction） | 直接操作 EEPROM 硬件（较少使用，现代 ECU 多用 Fee） | 传统 EEPROM 设备的兼容性支持 |
| Fls（Flash Driver） | 提供 Flash 扇区擦除、编程等底层操作 | 被 Fee 调用，实现物理存储写入 |
| RamTst（RAM 自检） | 启动时检测 RAM 故障（如 stuck-at 故障） | 安全关键系统（如动力总成）的启动自检。 |
| MemMap（内存映射配置） | 定义链接脚本中代码/数据的物理地址分配（如 .bss、.data 段） | 确保内存布局符合功能安全要求（如隔离 ASIL-B 和 ASIL-D ） |
四、系统服务协议栈
在上文我们已经简单提到了系统服务协议栈的核心模块包括ECU状态管理、看门狗管理、时间同步、错误管理。这些模块共同构成了汽车电子控制单元(ECU)的基础软件框架，为上层应用提供关键的底层服务支持。
4.1 ECU状态管理
ECU状态管理模块负责协调控制单元的工作状态转换，主要包含以下几种典型状态：
- 启动状态(Startup)：ECU上电初始化阶段，完成硬件自检、软件加载等准备工作
- 运行状态(Run)：正常工作模式，执行主要功能任务
- 休眠状态(Sleep)：低功耗模式，仅维持必要功能
- 关闭状态(Shutdown)：完全断电状态
4.2 看门狗管理
看门狗管理模块通过硬件和软件双重机制确保系统可靠性：
- 硬件看门狗：独立计时器，超时未喂狗则触发系统复位
- 软件看门狗：监控关键任务执行周期，如：
- 10ms周期任务监控
- 100ms周期任务监控
- 1000ms周期任务监控
4.3 时间同步
时间同步模块确保分布式系统中各节点时钟一致：
- 全局时间基准：通常采用CAN总线或Ethernet的精确时间协议(PTP)
- 时间同步精度：典型要求达到±1ms以内
- 应用场景：如ADAS系统各传感器数据的时间对齐
4.4 错误管理
错误管理模块提供全面的故障处理机制：
- 错误检测：包括内存错误、总线错误、任务超时等
- 错误分类：
- 可恢复错误(Recoverable Error)
- 不可恢复错误(Fatal Error)
- 错误处理：
- 错误日志记录
- 系统降级运行
- 安全状态转换
这些核心模块协同工作，为AUTOSAR架构下的电子控制单元提供了可靠的基础服务支持，确保汽车电子系统在各种工况下都能稳定运行。
扫一扫
1669
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
