3. AUTOSAR基础软件架构总览
AUTOSAR的分层架构本质上是在解决一个核心矛盾：应用软件需要跨车型、跨ECU复用，而底层硬件和通信协议却千差万别。分层的目的就是把"变化的"和"不变的"隔离开，让上层软件不必关心下层用的是哪颗MCU、哪路CAN收发器、哪个GPIO引脚。在Stellar这类车规级多核MCU上，这个分层结构尤其重要，因为Stellar内部集成了多个Cortex-R52/R52+内核、丰富的通信外设和功能安全机制，BSW必须把这些硬件能力抽象成统一接口，才能让上层SWC稳定运行。
BSW的四层结构
AUTOSAR基础软件（BSW）从下到上分为四层，每层职责边界清晰：
MCAL（Microcontroller Abstraction Layer，微控制器抽象层）是BSW的最底层，直接操作Stellar的寄存器。它包含Dio、Port、Adc、Pwm、Icu、Spi、Can、Lin、Fls、Eep、Mcu、Wdg等驱动模块。MCAL的职责是把硬件寄存器操作封装成标准API，例如Dio_WriteChannel()、Adc_StartGroupConversion()。在Stellar上，MCAL通常由ST提供的MCAL包配合EB tresos或类似工具生成配置代码，配置项包括引脚复用、时钟分频、采样精度、CAN波特率等。MCAL是唯一允许直接访问寄存器的层，其他层不得绕过它操作硬件。
ECU抽象层（ECU Abstraction Layer）位于MCAL之上，它把MCAL的通道级接口进一步抽象成ECU级接口。例如，MCAL的Adc驱动只提供"启动某个通道组转换"，而ECU抽象层的IoHwAb（I/O Hardware Abstraction）会把它封装成"读取某个传感器值"这样的语义接口。ECU抽象层还包含通信硬件抽象（CanIf、LinIf、FrIf）、存储器硬件抽象（MemIf、Fee、Ea）等。这一层的关键价值是：当硬件通道分配变化时，只需修改ECU抽象层的配置，上层SWC和RTE不受影响。
服务层（Service Layer）提供与硬件无关的通用服务，包括系统服务（Os、EcuM、BswM、ComM、Dcm、Dem、Nvm）、通信服务（Com、PduR、CanTp、LinTp、SoAd、SomeIp）和存储服务（NvM）。服务层是BSW中逻辑最复杂的部分，它负责通信协议栈的报文路由、诊断服务的会话管理、故障事件的存储与老化、非易失数据的读写调度。在Stellar多核场景下，Os服务还需要处理核间通信和任务分配。
复杂驱动（Complex Device Driver，CDD）是一个特殊层，它允许绕过标准分层直接访问硬件，用于实现AUTOSAR标准尚未覆盖或对时序要求极高的功能。例如Stellar上的电机控制PWM死区补偿、高速ADC过采样、功能安全相关的看门狗窗口刷新等，都可能放在CDD中。CDD的代价是牺牲了可移植性，因此必须严格限定使用范围，并做好接口封装。
RTE与SWC的交互关系
RTE是SWC与BSW之间的"胶水层"，它由工具根据SWC的端口定义和BSW模块配置自动生成，开发者不直接编写RTE代码。SWC通过端口（Port）和端口接口（Port Interface）与外界交互，端口分为两类：
- 发送者-接收者端口（Sender-Receiver Port）：用于数据传输。例如车速SWC通过S/R端口把车速值发给仪表SWC，RTE负责在两者之间传递数据，并处理队列溢出、初始值等策略。
- 客户端-服务器端口（Client-Server Port）：用于函数调用。例如诊断SWC通过C/S端口调用Dcm的
Dcm_GetSesCtrlType()获取当前诊断会话状态。
RTE还负责运行实体（Runnable Entity）到OS任务的映射。一个SWC可以包含多个Runnable，RTE根据配置把它们分配到不同的OS Task中，并决定触发方式（周期触发、数据接收触发、操作调用触发）。在Stellar多核上，RTE还需要处理跨核通信：如果两个SWC运行在不同核上，RTE会通过核间通信机制（如共享内存+自旋锁或Mailbox）传递数据，开发者只需在配置中指定核归属，RTE生成代码会自动处理。
Stellar上BSW各模块的职责边界与配置依赖
在Stellar上集成BSW时，最容易出问题的不是单个模块的功能，而是模块之间的配置依赖。以下用一张配置依赖关系表说明关键约束：
| 模块 | 职责边界 | 关键配置依赖 | Stellar注意事项 |
|---|---|---|---|
| Mcu | 时钟、复位、RAM初始化 | 被几乎所有模块依赖，必须最先初始化 | Stellar多核时钟树需分别配置各核PLL |
| Port | 引脚复用与方向 | 依赖Mcu时钟配置；被Dio、Adc、Can等依赖 | 注意引脚与功能安全引脚的冲突 |
| Can | CAN控制器寄存器操作 | 依赖Port引脚配置和Mcu时钟 | Stellar支持多路CAN FD，需配置消息RAM分区 |
| CanIf | CAN报文收发抽象 | 依赖Can驱动和CanTp/PduR | 多核场景下需指定CAN中断归属核 |
| Com | 信号打包/解包、超时监控 | 依赖PduR和RTE | 信号到PDU的映射需与DBC一致 |
| Os | 任务调度、中断管理、资源管理 | 被所有BSW模块依赖 | Stellar多核需配置核间任务和自旋锁 |
| NvM | 非易失数据管理 | 依赖MemIf、Fee、Fls | 注意Fee块大小与Stellar Flash扇区对齐 |
配置依赖的核心原则是：下层模块的配置必须先于上层完成，且参数必须一致。例如Can模块配置的波特率必须与CanIf的控制器引用一致，Com配置的PDU长度必须与PduR的路由表匹配。在Stellar上，由于多核和功能安全特性，还需要额外关注：核间共享资源的互斥配置、看门狗窗口与任务周期的匹配、以及安全相关模块（如Wdg、Fls）的冗余校验配置。
理解BSW分层结构和配置依赖，是后续在Stellar上进行AUTOSAR集成的基础。实际项目中，BSW配置往往占整个项目工作量的30%以上，而其中大部分时间花在排查模块间的配置冲突上。掌握各层职责边界和依赖关系，能显著缩短集成调试周期。