第2章 BSW架构概览：AUTOSAR分层架构、BSW模块组成、BSW与功能安全的关系

好，咱们进入正题。这一章我打算聊聊BSW的架构概览。说实话，很多工程师一上来就扎进代码里，结果对整个BSW的“地图”没概念。这就像你开车去一个陌生城市，没有导航，光盯着油门和刹车，肯定要迷路。

我个人习惯，在讲任何模块之前，先画一张大图。这张图就是AUTOSAR的分层架构。你把它印在脑子里，后面学什么模块都不会乱。

2.1 AUTOSAR分层架构：一张你必须记住的图

AUTOSAR把汽车嵌入式软件分成了三层。从上到下分别是：

• 应用层（ASW）：跑业务逻辑的，比如车窗控制、雨刮策略。这一层不关心硬件。
• 运行时环境（RTE）：相当于一个“通信总线”，负责应用层和底层之间的数据交换。
• 基础软件层（BSW）：这就是咱们课程的核心。它负责跟硬件打交道，提供标准化的服务。

BSW本身又分成了好几块：服务层、ECU抽象层、微控制器抽象层（MCAL）和复杂驱动。嗯，这里要注意，复杂驱动不是标准BSW的一部分，但经常被放在一起讨论。

2.2 BSW模块组成：你每天都会打交道的“老伙计”

BSW模块很多，我挑几个跟功能安全关系最密切的来讲。你在项目中，大概率天天跟它们打交道。

2.2.1 操作系统（OS）

这个不用多说。AUTOSAR OS必须支持OSEK/VDX标准，并且要能实现内存保护、时间保护。我在项目中遇到过，一个任务跑飞了，如果没有OS的内存保护，整个ECU都可能挂掉。这就是为什么ISO 26262要求OS必须支持“自由干扰”的隔离。

2.2.2 通信栈（Com Stack）

包括CAN、LIN、以太网等。功能安全要求通信不能出错。比如，你发送了一个“刹车”信号，结果因为总线错误变成了“加速”，那后果不堪设想。所以，通信栈里必须有安全机制，比如CRC校验、序列号、超时监控。

2.2.3 内存栈（Mem Stack）

负责NVM（非易失性存储器）的管理。比如存储故障码、配置参数。功能安全要求数据不能损坏。我曾经见过一个案例，因为掉电导致NVM写了一半，数据全乱了。后来我们加了“双备份”和“校验和”机制，才解决了问题。

2.2.4 诊断栈（Diagnostic Stack）

负责UDS诊断。功能安全要求诊断功能本身不能引入风险。比如，你通过诊断刷写了一个错误的数据，导致ECU功能异常。所以，诊断栈需要有安全访问、数据完整性校验等机制。

2.3 BSW与功能安全的关系：不是“附加题”，是“必答题”

很多人觉得，功能安全是应用层的事，BSW只是提供一些“辅助功能”。这个想法很危险。我告诉你，BSW本身就是功能安全的一部分。

为什么这么说？

• BSW是安全机制的载体：比如看门狗、内存保护、ECC校验，这些机制都实现在BSW里。没有它们，应用层再安全也没用。
• BSW是故障检测的“第一道防线”：硬件故障（比如RAM位翻转）往往先被BSW检测到，然后上报给应用层做处理。
• BSW是安全通信的“守门员”：确保数据在传输过程中不被篡改、不丢失、不重复。

2.4 一个简单的例子：看门狗（Wdg）模块

咱们拿看门狗模块举个例子。看门狗是BSW里一个很小的模块，但功能安全离不开它。

它的作用很简单：监控系统是否“死机”。如果程序跑飞了，看门狗会触发复位，让系统重新启动。

在功能安全里，看门狗属于“安全机制”。它的配置需要满足ASIL等级要求。比如，ASIL D要求看门狗必须独立于主核，并且有独立的时钟源。

配置代码大概长这样（简化版）：

/* 看门狗配置示例 */
Wdg_ConfigType WdgConfig = {
    .WdgTimeout = 100,  /* 超时时间100ms */
    .WdgMode = WDG_MODE_AUTO,  /* 自动模式 */
    .WdgTriggerSource = WDG_TRIGGER_OS_TASK  /* 由OS任务触发 */
};

你看，就这么几行配置，背后涉及的安全逻辑可不少。比如，超时时间设得太短，会导致频繁复位；设得太长，又起不到保护作用。这些都需要根据系统安全目标来权衡。

2.5 本章小结

这一章咱们把BSW的架构和模块捋了一遍。你记住三点：

1. AUTOSAR分层架构是基础，BSW是中间那层，承上启下。
2. BSW模块很多，但功能安全重点关注OS、通信、内存、诊断。
3. BSW不是“配角”，它是功能安全落地的核心执行者。

下一章，咱们会深入聊聊“功能安全需求如何分解到BSW模块”。你想想看，一个ASIL D的需求，怎么拆成BSW里一个个具体的配置项？嗯，那才是真正考验功力的时候。