第2章：AUTOSAR经典平台（CP）架构详解：应用层、RTE、基础软件层（BSW）的职责与交互
好，咱们直接进入正题。AUTOSAR CP 架构，说白了就是一套把汽车软件拆成三层的标准。哪三层？应用层、RTE、基础软件层。我当年刚接触时也觉得分层太多，后来做项目才明白——这分层救了多少人的命。
2.1 应用层（ASW）—— 业务逻辑的舞台
应用层，就是放你业务代码的地方。比如车窗控制、雨量感应、自动泊车，这些都算。它由一个个 SWC（Software Component） 组成。
每个 SWC 内部，又分成 Runnable。你可以把 Runnable 理解成一个个小函数，系统会周期性地调用它们。举个例子：
/* 一个典型的 SWC Runnable 示例 */
void WindowMotor_Control(void) {
/* 读取传感器状态 */
uint8 windowPos = Rte_IRead_WindowMotor_CurrentPosition();
/* 判断是否需要动作 */
if (windowPos < TARGET_POSITION) {
Rte_IWrite_WindowMotor_MotorCmd(MOTOR_UP);
} else {
Rte_IWrite_WindowMotor_MotorCmd(MOTOR_STOP);
}
}
你看，应用层代码里没有直接操作寄存器的语句。它只通过 RTE 接口 读写数据。我个人习惯，写 SWC 时尽量让每个 Runnable 只做一件事，这样测试起来特别方便。
2.2 RTE（运行时环境）—— 软件的总线
RTE 是什么？说白了，它就是应用层和 BSW 之间的 中间人。应用层不能直接调用 BSW 的函数，必须通过 RTE。
RTE 主要干三件事：
- 数据传递：把 SWC 的读写请求，转成 BSW 能理解的信号
- 任务调度：决定哪个 Runnable 什么时候跑
- 通信管理：跨 ECU 的数据交换，也由 RTE 封装
你想想看，如果没有 RTE，每个 SWC 都得知道底层硬件细节。那换一个 MCU，所有代码都得重写。RTE 的存在，让应用层彻底跟硬件解耦。
2.3 基础软件层（BSW）—— 硬件的管家
BSW 是离硬件最近的一层。它又分成三块：
| 子层 | 职责 | 我踩过的坑 |
|---|---|---|
| 服务层 | 提供操作系统、存储、诊断等服务 | 曾经把 NVM 写入放在中断里，结果死锁了 |
| ECU 抽象层 | 封装 MCU 外设，比如 SPI、I2C | 不同 MCU 的 SPI 时序不一样，抽象层帮我省了大半年 |
| MCAL | 直接操作寄存器，最底层 | MCAL 配置错一个 pin，整个 CAN 通信就挂了 |
嗯，这里要注意：BSW 的配置极其繁琐。我曾经花了两周时间，只为了调通一个 CAN 收发器的 MCAL 配置。所以我的建议是——能用工具生成的，千万别手写。
2.4 三层如何交互？
咱们用一个实际场景来说明：按下车窗升降按钮。
- BSW 层：MCAL 检测到 GPIO 电平变化，通知服务层
- RTE：把 GPIO 事件转成 SWC 能识别的信号，触发对应的 Runnable
- 应用层：Runnable 读取按钮状态，判断是升还是降，然后通过 RTE 写电机控制信号
- BSW 层：RTE 把控制信号传给 MCAL，MCAL 驱动电机
你看，数据流是：BSW → RTE → ASW → RTE → BSW。每一层各司其职，谁也不越界。
2.5 我的总结
AUTOSAR CP 的三层架构，其实就一句话：应用层只管业务，BSW 只管硬件，RTE 负责牵线搭桥。
刚开始学的时候，你可能会觉得 RTE 是多余的。但等你做过三五个项目，换过两三种 MCU 后，你就会发现——RTE 是汽车软件里最聪明的设计之一。它让代码可复用、可移植、可测试。
下一章，咱们聊聊 RTE 的生成工具链。那玩意儿配置起来，嗯，也挺有意思的。