2. AUTOSAR基础
在开始集成外设驱动之前，必须先建立对 AUTOSAR 整体框架的认知。AUTOSAR（AUTomotive Open System ARchitecture）并不是一个具体的软件库，而是一套标准化的软件架构规范，它把汽车 ECU 软件拆分为可复用、可替换、可配置的组件，并通过标准化接口把它们连接起来。理解这套架构，是后续把 MCAL、ECU 抽象层、服务层和外设驱动正确"嵌入"到工程中的前提。
一、经典平台与自适应平台：两种定位
AUTOSAR 目前主要分为两个平台，它们面向不同的计算场景：
- Classic Platform（CP，经典平台）：面向深嵌入式、硬实时、资源受限的微控制器（如 TC3xx、S32K、RH850）。它基于静态配置、OSEK/VDX 操作系统，任务调度确定性极强，是发动机、车身、底盘、电机控制器等 ECU 的主流选择。外设驱动集成绝大多数发生在 CP 上。
- Adaptive Platform（AP，自适应平台）：面向高性能计算单元（如智能座舱域控、自动驾驶域控），基于 POSIX 操作系统，支持动态加载、面向服务通信（SOA）、C++ 应用。它强调算力、并行与软件更新能力，而非微秒级硬实时。
两者并非替代关系，而是分工协作：CP 负责确定性控制与外设时序，AP 负责高算力感知、决策与大数据处理，二者通过车载以太网、SOME/IP 等通信方式协同。
二、分层架构：从硬件到应用的纵向切分
AUTOSAR CP 的核心思想是"分层 + 接口标准化"。自上而下可分为应用层、运行时环境（RTE）和基础软件（BSW）三大部分，BSW 内部又细分为服务层、ECU 抽象层、微控制器抽象层和复杂驱动。下图展示了这一分层结构以及各层之间的调用与依赖关系：
从图中可以看到，应用层不直接触碰硬件，而是通过 RTE 与 BSW 交互；BSW 内部再逐层向下，最终由 MCAL 操作寄存器。这种"层层隔离"正是 AUTOSAR 可移植性的来源。
三、BSW、RTE、SWC 三个核心概念
SWC（Software Component，软件组件）是应用功能的封装单元。一个 SWC 只描述"做什么"，不关心"在哪里运行、如何通信"。它通过端口（Port）和端口接口（Port Interface）对外暴露数据或操作，例如一个车速采集 SWC 提供 Sender 端口输出车速信号。
RTE（Runtime Environment，运行时环境）是 SWC 之间的"通信中间件"。它把 SWC 的端口连接关系在配置阶段解析为具体的函数调用或数据拷贝，使 SWC 之间既可以同 ECU 内通信，也可以跨 ECU 通信，而 SWC 代码本身无需修改。RTE 还负责 Runnable 实体的调度触发。
BSW（Basic Software，基础软件）是标准化、与硬件相关或与通信相关的底层集合，包括操作系统、通信栈、存储栈、诊断栈、IO 硬件抽象等。它向上通过 RTE 为 SWC 提供服务，向下通过 MCAL 访问硬件。
四、外设驱动集成在架构中的位置
结合本课程主题，外设驱动集成主要落在 MCAL 与 ECUAL 两层。以 ADC 采集为例，其数据流路径如下：
ADC 硬件采样
↓
Adc 驱动（MCAL）读取结果寄存器
↓
IoHwAb（ECUAL）将原始值转换为物理量
↓
RTE 端口数据更新
↓
SWC 读取车速/温度信号并执行控制逻辑集成时需要关注的关键配置项包括：AdcGroup 的转换模式（单次/连续）、采样时间、结果对齐方式、通知函数，以及 IoHwAb 中的缩放因子与偏移量。这些参数一旦配置错误，SWC 拿到的数据就会失真，而问题往往被误判为"应用逻辑错误"。
五、常见误区与复盘要点
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 把 SWC 当普通 C 函数直接调用 | 绕过 RTE，跨组件耦合严重 | 通过端口与 RTE 通信，保持组件独立 |
| 在 SWC 中直接写寄存器 | 破坏分层，移植困难 | 硬件访问下沉到 MCAL 或 CDD |
| 混淆 CP 与 AP 的适用场景 | 在 MCU 上强行套用 AP 的 SOA 模型 | 硬实时控制用 CP，高算力服务用 AP |
| 忽略 RTE 生成配置 | 端口未连接，数据始终为初值 | 集成前核对 RTE 连接与 Runnable 映射 |
掌握经典平台与自适应平台的定位差异、分层架构的纵向切分，以及 BSW、RTE、SWC 三者的职责边界，是后续进行 MCAL 配置、驱动移植与系统集成的基础。只有把每个外设驱动放到正确的层级中，才能保证工程既满足实时性要求，又具备良好的可移植性与可维护性。