第02篇：AUTOSAR BSW模块家族——谁是“通信担当”？谁是“管家担当”？

第02篇：AUTOSAR BSW模块家族——谁是“通信担当”？谁是“管家担当”？

📖 核心内容目录

1. BSW的三层“夹心”结构回顾——Services / ECU Abstraction / MCAL
2. 通信栈（Communication Stack）——从COM到CAN Driver的数据流路径
3. 诊断栈（Diagnostic Stack）——DCM与DEM的职责分工
4. 存储栈（Memory Stack）——NvM / Fee / Ea / MemIf 的存储层次
5. 图解：一个CAN报文从应用层发到总线上的“旅行路线”

1. 从办公室场景出发：认识BSW的“部门架构”

想象你入职了一家大公司，第一天走进办公区，看到几十个工位上坐满了人，每个人都忙忙碌碌。

你问HR：“他们分别负责什么？”

HR回答：“左边那一排是通信部，负责对外联络；中间那一排是诊断部，负责处理投诉和故障报修；右边那一排是存储部，负责档案管理；角落里的老张是OS部，负责整个办公室的排班调度。”

这就是AUTOSAR BSW模块的构成逻辑——BSW不是一个单独的模块，而是一组模块的集合，按职能划分成若干个“部门”（模块组）。

AUTOSAR CP中的BSW，包含了几十个功能模块。如果逐个学习，会非常零散且效率低下。

好的方法是：先按职能把它们分成“几大家族”，再深入每个家族的具体成员。

2. BSW三层结构快速回顾

在第01篇中，我们已经建立了BSW的基础认知。先花1分钟快速回顾：

今天，我们把这几十个BSW模块，按照职能重新分组，建立一张清晰的“部门组织架构图”。

3. BSW模块的四大家族

在实际开发中，通信家族和诊断家族是你接触频率最高的两个模块组，也是本篇的重点。

下面，我们逐一深入每个家族。

4. 通信家族（Communication Stack）——ECU的“外交部”

通信家族是BSW中规模最大、调用最频繁的模块组。它的核心任务很简单：让数据从一个地方走到另一个地方。

但这个“简单任务”涉及的数据流方向很多：

• 发送方向：ASW产生数据 → 交给通信家族 → 打包成CAN/LIN/以太网帧 → 发送到总线
• 接收方向：从总线收到CAN/LIN帧 → 通信家族解析 → 提取Signal → 交给ASW

4.1 通信家族的核心成员

我们从底层到顶层逐一认识：

重点理解：当你说“我要发一个CAN报文”时，数据实际经过了Com → PduR → CanIf → CanDrv这条链路。

4.2 核心模块深度解析

📦 Com（通信服务模块）

Com是通信家族中工作量最大的模块，它直接与RTE对接。

它的职责包括：

1. Signal打包：把多个Signal（例如：车速、水温、转速）按照DBC定义的布局，打包到一个PDU的Data Field中。
2. Signal解包：从收到的PDU中提取出各个Signal。
3. 信号网关：把从CAN收到的Signal转发到LIN或以太网（跨网络转发）。
4. 通信模式管理：控制通信状态（开启/关闭/待机）。
5. 信号监测：监控Signal的超时、有效性等。

Com模块的配置信息，通常来自系统设计阶段定义的通信矩阵（例如DBC文件）。

📡 PduR（PDU路由器）

PduR是通信家族里的交通警察。它不负责“制造”数据，只负责“路由”数据。

PduR根据配置的路由表，决定一个PDU的去向：

来源 → PduR → 目标 ───────────────────────────── Com发送 → PduR → CanIf（发送到CAN总线） CanIf接收 → PduR → Com（交给上层） CanIf接收 → PduR → Dcm（诊断报文直接走诊断通道） CanIf接收 → PduR → CanTp（长报文需要分段重组）

PduR的路由策略，是实现“诊断报文直接走诊断栈、普通报文走COM”的关键机制。

🔌 CanIf（CAN接口模块）

CanIf是ECU抽象层的代表模块，它的核心价值在于：

• 屏蔽多CAN控制器差异：一个ECU可能有多个CAN控制器（比如CAN0、CAN1），每个控制器的硬件访问方式不同。CanIf向上层提供统一的接口。
• 管理CAN控制器状态：启动、停止、休眠、唤醒。

🔧 CanDrv（CAN驱动模块）

CanDrv是最底层的MCAL模块，直接操作芯片的CAN控制器寄存器。

它的典型函数包括：

// 伪代码示例CanDrv_Init(&canConfig);// 初始化CAN控制器CanDrv_Write(canCtrlId,&pdu);// 发送一个CAN帧CanDrv_Read(canCtrlId,&pdu);// 接收一个CAN帧CanDrv_IrqHandler();// CAN中断处理函数

CanDrv通常由芯片厂商提供底层驱动代码（如英飞凌的iLLD、NXP的MCAL SDK）。

5. 诊断家族（Diagnostic Stack）——ECU的“医院”

诊断家族负责的是：让ECU具备“感知疾病、记录病情、接受治疗”的能力。

在智能汽车上，诊断功能是法规强制要求（如OBD法规），也是售后维修的基础工具。

5.1 诊断家族的核心成员

三个模块的协作关系：DCM负责“接诊”，DEM负责“建档”，FIM负责“下医嘱”。

5.2 核心模块深度解析

🏥 DCM（诊断通信管理器）

DCM是诊断家族里最繁忙的模块。每一条UDS诊断请求，都由DCM处理。

它的典型工作流程是：

1. 收到诊断请求（例如：$22 读取DTC状态）。
2. 解析服务ID和子功能。
3. 检查安全访问状态（如果服务需要安全级别）。
4. 执行对应的诊断操作（如读取DTC、写入数据、执行例程）。
5. 组装正响应或负响应（NRC），发送回去。

DCM需要支持的UDS服务示例：

在座舱MCU开发中，DCM是你打交道最多的模块之一。

📋 DEM（诊断事件管理器）

DEM的职责是管理ECU内部发生的“事件”：

1. 事件监控：应用层或BSW模块报告“某温度传感器值超阈值”。
2. 事件存储：将事件记录为DTC（诊断故障码），存储到非易失性存储器。
3. 快照数据：在事件发生时刻，冻结关键数据（如当时的速度、温度、电压）。
4. 事件状态管理：维护DTC的状态位（如“当前故障”、“历史故障”、“已确认”等）。

DEM与DCM的协作关系：

• DEM负责“制造病历”（监控故障、存储DTC）。
• DCM负责“查看病历”（响应$22读取DTC请求）。

6. 存储家族（Memory Stack）——ECU的“档案馆”

存储家族负责：把需要“永久记住”的数据，写入非易失性存储器（Flash/EEPROM）。

6.1 存储家族的核心成员

6.2 核心模块深度解析

🗂️ NvM（非易失性内存管理）

NvM是存储家族里唯一与上层直接交互的模块。ASW通过RTE调用NvM接口来读写数据。

NvM的功能包括：

• 管理多个数据块（Block），每个Block有唯一的ID。
• 支持即时写入（写穿）或周期写入（写回）。
• 支持数据校验（CRC）和数据冗余（防止写入过程中断电损坏）。
• 支持数据初始化：新ECU首次上电时，写入默认值。

💾 Fee（Flash EEPROM仿真）

Fee模块的目的是：

大多数MCU自带的数据Flash（DFlash）可擦写次数有限（约10万次），直接用于频繁写入数据会快速老化。Fee通过在Flash上实现磨损均衡（Wear Leveling）算法，延长存储寿命。

Fee的内部机制比较复杂，但作为使用者，你只需要知道：

• Fee是NvM和Flash硬件之间的“中间层”。
• NvM的读写请求，通过MemIf → Fee → Flash Driver 完成。

7. 系统服务家族（System Services）——ECU的“总务处”

OS是系统服务家族的核心，我们在后续第9篇（功能安全）中会重点展开。

8. 图解开篇：一个CAN报文从应用到总线的“旅行路线”

现在，我们把通信家族的所有模块串联起来，走一遍完整的CAN报文发送流程。

场景设定

应用层（ASW）需要发送一个“当前车速”信号（车速值=80km/h）到CAN总线上。

完整的数据流路径

第1步：ASW产生数据 ───────────────────────────────────── ASW中的某个Runnable函数调用： Rte_Write_VehicleSpeed(80); // 车速=80km/h ↓ 数据交给RTE 第2步：RTE转交数据给COM ───────────────────────────────────── RTE根据ARXML配置，调用Com模块接口： Com_SendSignal(VehicleSpeed_Signal, 80); ↓ 数据交给COM 第3步：COM打包Signal到PDU ───────────────────────────────────── COM根据DBC定义的布局（起始位、长度、字节序）： - 将80km/h转换为原始值（乘以Factor、加上Offset） - 将原始值填入PDU Data Field的对应位位置 - 填充其他Signal（如果有） Com_SendPdus(); → 调用PduR接口 ↓ PDU（含Signal数据）交给PduR 第4步：PduR路由PDU ───────────────────────────────────── PduR根据路由表查找： - 该PDU的目标通信协议是CAN - 目标CAN控制器是CAN0 - 调用CanIf接口： CanIf_Transmit(canCtrlId=0, &pdu); ↓ PDU交给CanIf 第5步：CanIf添加CAN帧头 ───────────────────────────────────── CanIf将PDU打包成CAN帧格式： - 添加CAN ID（从配置中获取） - 设置DLC（数据长度，通常为8字节） - 调用CanDrv_Write(canCtrlId, &canFrame); ↓ CAN帧交给CanDrv 第6步：CanDrv发送CAN帧 ───────────────────────────────────── CanDrv直接操作CAN控制器寄存器： - 将CAN帧写入CAN控制器的发送邮箱（Tx Mailbox） - 设置发送请求标志 - CAN控制器自动将帧发送到CAN总线 ↓ 最终，物理层将差分信号发送到CAN总线上 完成！

对应的模块调用关系链

ASW → RTE → COM → PduR → CanIf → CanDrv → CAN总线

这个过程是AUTOSAR CP通信栈的标准数据流，你需要像背乘法口诀一样熟悉它。

9. 本篇重点回顾

📝 第二篇交付物清单

请完成以下实践任务，巩固本篇所学：

1. 画出BSW模块家族分类图
   用draw.io或手绘，画出一张包含四大模块家族（通信、诊断、存储、系统服务）的组织架构图，标注每个家族的核心模块名称。

2. 追踪一条接收路径
   思考并写出：当一个CAN帧从CAN总线上到达MCU时，数据依次经过哪些模块？顺序是什么？（提示：与发送路径相反）

3. 模块匹配练习
   把以下功能匹配到对应的模块名称（选填：Com / PduR / CanIf / DCM / DEM / NvM / Fee）：

   • 把车速信号打包成PDU的Data Field → ______
   • 决定一个PDU发到CAN还是LIN → ______
   • 响应诊断仪发送的$22服务请求 → ______
   • 存储故障发生时快照数据 → ______
   • 在Flash上实现磨损均衡 → ______

📚 参考代码片段

以下是一个简化的COM发送伪代码，帮助理解：

// Com模块的发送信号函数（简化版）voidCom_SendSignal(SignalIdType signalId,uint32_tvalue){uint8_tpduData[MAX_PDU_LENGTH];uint16_tpduId=Com_GetPduId(signalId);// 1. 将物理值转换为原始值（Factor + Offset）int32_trawValue=(value/Com_GetSignalFactor(signalId))+Com_GetSignalOffset(signalId);// 2. 将原始值按位布局写入PDU数据缓存Com_PackSignal(pduData,signalId,rawValue);// 3. 调用PduR发送PDUPduR_ComTransmit(pduId,&pduData);}

你已经完成了第二篇的学习。第三篇我们将进入CAN协议的“物理课”——从差分信号、帧格式到DBC解析，彻底搞懂CAN通信的每个细节。