AutoSar BSW介绍

前言

BSW层是整个AUTOSAR架构的重点，本文主要对AutoSar BSW相关知识进行了汇总，仅作为自学使用，以方便后续查漏补缺。

基础软件（BSW）

BSW层是整个AUTOSAR架构的重点。

BSW分层

服务层（Service Layer）

• 为ASW（通过RTE）、BSW其他模块提供抽象服务，如：操作系统、任务调度、诊断服务、网络管理、存储器服务、总线通信管理服务等。
• AUTOSAR运行模块间的“水平”交互

ECU抽象层（ECUAL，ECU Abstraction Layer）

• 底层驱动的抽象，同时它也是外设的驱动，它提供了可以访问外设和底层MCU的API接口
• 对控制器的基础功能和接口进行统一，如：CAN报文内容的解析、网关报文的转发、存储器读写流程的控制。
• 与整个硬件（PCB）有关。使上层软件可以独立于硬件

微控制器抽象层（MCAL）

• 结构上：位于BSW的底层。
  • 包含与MCU硬件直接相关的驱动软件，如：对存储器、寄存器、IO的操作。
  • 封装了MCU硬件的特定特性，这种封装为ECU抽象层提供了一个AUTOSAR定义的接口，使其独立于MCU硬件。从而提供与硬件无关的接口，使上层软件ASW不依赖于具体的硬件。
• AUTOSAR MCAL规范，包括：
  • 功能概述
    定义模块实现的具体功能，如定义mcu驱动程序提供基本控制器初始化、时钟初始化、电源管理模式等特定功能。
  • 依赖关系
    定义模块间的依赖关系
  • 功能规范
    定义包括复位、时钟管理等一般功能规范。还定义错误分类、错误检测等功能规范。
  • API规范
    定义模块包含的数据类型、模块内部的类型定义、函数定义等
  • 功能时序图
    定义用户代码与驱动模块完成特定功能的时序
  • 配置规范
    定义了提供给用户进行初始化及驱动能力配置选项的规范说明。
• MCAL 核心作用
  • 硬件抽象
    将MCU的硬件特性（如寄存器配置、外设操作等）封装成标准化的API，使上层软件无需关心具体的硬件型号
  • 统一接口
    提供跨平台的驱动程序接口（如GPIO、CAN通信），确保应用代码可移植到不同MCU。
  • 降低开发成本
    避免针对不同平台芯片重复开发驱动代码，加速ECU软件开发流程。
• MCAL模块
  • MicroController Drivers
    • 作用：配置MCU的核心功能，如时钟、电源模式、中断控制器（如NVIC）。
      • GPT Driver（通用定时器）
      • WDG Driver（WatchDog）
      • MCU Driver（Micro Controller Unit）
  • Memory Drivers
    • FLS Driver（Flash）
      • EEPROM
      • RAM
  • I/O Drivers
    • Port
    • Dio
    • ADC
    • PWM
    • Icu（Input Capture Unit输入捕获单元）
    • Ocu
  • Communication Drivers
    • Spi
    • LIN
    • CAN
    • FlexRay
    • ETH
    • Uart
  • Complex Drivers
    • 作用：处理非标准外设或高实时性需求。如直接控制传感器、执行器，包括：
    • 电机控制
      • 高精度定时器
• MCAL代码
  • 静态代码
    MCAL的核心代码，提供符合软件规范以及微控制器硬件规范的底层驱动程序，支持访问微控制器的片内外设。如TC3x，MCAL BASIC部分驱动静态代码，每个模块都包含.c/h文件，不需要用户修改。
  • 动态代码
    通过工具生成的代码，代码生成工具需要导入PDF（Parameter Definition File）文件，通常为.arxml或.xdm为后缀，其定义了配置参数的描述及其最小/大值。
    • 一般使用的配置工具是EB，它导入PDF后能够提供图形界面进行相关配置，然后最终生成动态代码。
    • 生成的动态代码，包括2部分：
      • 一部分是与静态代码配合完成底层驱动工作，大部分名称格式为*_Cfg.c/h或*_PBCfg.c/h。
      • 另一部分，EB生成以.xdm为后缀的配置文档，保存了当前的配置信息。还生成了以.arxml为后缀的ECU描述文件。
• MCAL开发
  • 使用EB开发MCAL总结参考：​MCAL开发 & EB使用总结​

复杂设备驱动（CDD）

• 在AUTOSAR架构中具有独特的特性。为直接访问非标准控制器硬件提供了一种标准化的机制，并提供了ASW通过RTE访问的AUTOSAR接口。
• 跨越于微控制器硬件层和RTE之间，其主要任务是整合具有特殊目的且不能用MCAL进行配置的非标准功能模块，将该部分功能嵌入到AUTOSAR基础软件层中，从而实现处理复杂传感器以及执行器的特定功能和时间要求。
• 为用户提供可以自行编写特殊设备驱动软件的可能性。
• 提供复杂传感器和执行器的驱动
• 重要的应用模块可以直接访问硬件资源。如：胎压监测、喷油量控制

MCU硬件（Microcontroller Hardware）

• 位于微控制器“内部”的设备，如：内部EEPROM、CAN控制器
• 微控制器外部通过SPI连接的硬件芯片

BSW功能

IO功能

• 包括：DIO、ADC、PWM等。示例：
  

Communication功能

• AUTOSAR COM模块
  • 上层模块：RTE
  • 下层模块：PDU Router
    • 用于处理不同通信协议之间的数据路由和转换。
    • PDU Router 的核心功能是将来自不同通信总线（如 CAN、LIN、FlexRay、以太网等）的消息进行路由、转换和分发，以确保不同网络节点之间的数据能够正确传输和处理。

Memory功能

• NVM（NVRAM Manger）：应用层访问非易失性数据的唯一接口，提供非易失性数据的管理服务
  • 上层：RTE
  • 下层：Flash / EEPROM Driver接口

BSW的模式管理

BSW的看门狗实现

BSW的诊断系统实现

BSW的操作系统实现

OS服务

可以把AUTOSAR的OS服务理解为FreeRTOS。

• OS Application
  • 一系列对象的集合：Tasks、ISRs、Alarms、Counters
  • 每个核有1~N个 OS Applications
  • OS Applications内通信使用RTE
  • OS Applications之间通信使用IOC
  • ECU间通信使用Com
• task

BSWM

• 对通讯进行控制
• ECU状态处理
• 初始化设置

ECUC

• 初始化
• 对Hardware的一些设置
• PDUR

通信流程/链路

• 框图
  
• CAN协议栈
  • CAN数据的收发属性，都是直接在工具上配置的。描述：
    
    
    
• CANIF 模块
  • CAN驱动的抽象模块，向上提供统一的接口。
  • 隔离对CAN硬件的操作。
  • PDUs
    • PDU（Protocol Data Unit） 通信协议中的数据单元
      在汽车电子中，PDU 可以是从 CAN 总线、LIN 总线、以太网等不同协议中提取的消息。
    • HOH
• PDuR 模块
  • 联系上层和下层，不对数据处理，只进行转发。
  • 可以起到网关的作用。
• COM模块
  
  • Tx filter
  • Rx filter
  • Update Bit (UB位)
    • 增加一个标志位，表示该数据是否有更新。
    • 示例，如：节点A和节点B之间通信时，在同一个message中有data1和data2，但是A只想把data1发送给B，这时只需要把data1的UB置位，data2的UB不置位
  • Signal Group
  • Gateway