1. BSW概述：AUTOSAR架构总览

大家好，我是老张。做汽车嵌入式这行十几年了，今天咱们聊聊AUTOSAR里的BSW。

说实话，我刚接触AUTOSAR那会儿，也被这庞大的架构搞得头晕。但干久了你会发现，它其实就三层：应用层、RTE、基础软件层。BSW就是最底下那层，负责跟硬件打交道。

1.1 AUTOSAR架构总览

AUTOSAR架构，说白了就是一套标准化的汽车软件平台。它把软件分成了三层：

• 应用层（SWC）：写业务逻辑的地方，比如车窗控制、雨刮控制
• 运行时环境（RTE）：应用层和BSW之间的桥梁，负责通信
• 基础软件层（BSW）：跟硬件直接交互，提供各种服务

你想想看，没有这套分层，每个ECU都得从头写驱动，那得多累？

1.2 BSW在AUTOSAR中的位置

BSW夹在RTE和硬件之间。它不直接跟应用层打交道，所有通信都通过RTE转发。

我习惯把BSW比作一个"管家"。应用层是主人，RTE是传话的仆人，BSW就是那个负责具体干活的管家。主人说"我要开窗"，管家就去操作电机。

1.3 BSW模块分类

BSW里模块挺多的，但归纳起来就四大类。我一个个说。

系统服务

这组模块负责ECU的"后勤保障"。比如：

• EcuM（ECU管理器）：管启动、休眠、唤醒的
• BswM（BSW管理器）：管模式切换的
• WdgM（看门狗管理器）：防止程序跑飞的
• Dem（诊断事件管理器）：记录故障码的

存储服务

负责数据的持久化存储。主要模块：

• NvM（非易失性存储器管理器）：存配置参数、故障码这些掉电不能丢的数据
• MemIf（存储器接口）：抽象层，屏蔽不同存储介质的差异
• Fee（Flash EEPROM仿真）：用Flash模拟EEPROM

嗯，这里要注意。NvM的配置很讲究，块大小、校验方式、写入策略，每一项都影响性能和寿命。我建议你在项目初期就把存储需求梳理清楚，不然后面改配置很痛苦。

通信服务

这是BSW里最复杂的一块。包括：

• CanIf（CAN接口）：CAN通信的抽象层
• CanTp（CAN传输协议）：处理大数据分包传输
• Com（通信管理器）：信号级别的路由
• PduR（PDU路由器）：报文级别的路由
• LinIf、EthIf：其他总线接口

你想想看，一个现代汽车上有几十个ECU，它们之间怎么通信？全靠这些模块在背后默默工作。

I/O服务

跟外部硬件打交道的模块：

• Dio（数字I/O）：管高低电平的
• Adc（模数转换器）：读模拟信号
• Pwm（脉宽调制）：控制电机、灯光
• ICU（输入捕获单元）：测频率、脉宽

1.4 BSW与RTE的关系

BSW和RTE的关系，说白了就是"服务提供者"和"服务调度者"的关系。

RTE负责把应用层的请求转发给BSW，BSW处理完后再把结果返回。RTE不干具体活，它就是个调度员。

举个例子：应用层想读一个传感器的值。

// 应用层代码（SWC）
void ReadSensor(void)
{
    uint16 sensorValue;
    
    // 通过RTE调用BSW的I/O服务
    Rte_Read_RP_SensorValue(&sensorValue);
    
    // 处理数据
    if(sensorValue > 100)
    {
        // 做点什么
    }
}

// RTE内部会调用BSW的Adc模块
// Rte_Read_RP_SensorValue -> Adc_ReadGroup()

看到没？应用层根本不知道底层用的是哪个ADC通道、采样率多少。这些细节都被BSW封装好了。

我个人习惯把这种关系叫做"解耦的艺术"。应用层只关心业务逻辑，BSW只关心硬件操作，RTE在中间做翻译。这样任何一层变了，其他层都不受影响。

---

可可精品资料库