3. AUTOSAR分层架构与S32适配策略
AUTOSAR 的两套平台并不是简单的“新旧版本”关系，而是面向不同算力、不同安全等级、不同部署形态的两条技术路线。经典平台（Classic Platform, CP）以静态配置、硬实时、微控制器为根基；自适应平台（Adaptive Platform, AP）以动态调度、面向服务、高性能计算单元为根基。在 NXP S32 系列域控制器上，二者往往同时存在：S32K/S32G 等实时核承担 CP 侧控制逻辑，S32R/S32Z 或带高性能 A 核的 SoC 承担 AP 侧计算与服务编排。理解分层模型与 BSW/RTE/SWC 的关系，是后续裁剪与集成决策的前提。
一、经典平台的分层模型
CP 自上而下分为应用层、运行时环境（RTE）、基础软件层（BSW）。应用层由若干软件组件（SWC）构成，SWC 不直接访问硬件，只通过端口（Port）与接口（Interface）声明通信需求。RTE 是虚拟功能总线（VFB）的具体实现，把 SWC 之间的 Sender/Receiver、Client/Server 通信映射为具体的任务、队列或函数调用。BSW 再细分为服务层、ECU 抽象层、微控制器抽象层和复杂驱动：服务层提供 OS、通信、诊断、存储、模式管理；ECU 抽象层把外设寄存器操作封装为统一 API；MCAL 直接操作 S32 的寄存器与中断；复杂驱动用于 MCAL 无法覆盖的特殊外设或高实时旁路。
关键点在于：SWC 的可移植性来自“只依赖 RTE 接口”，而 RTE 与 BSW 的绑定关系由配置决定。因此在 S32 上做适配时，真正需要改动的通常不是 SWC 源码，而是 RTE 生成配置、BSW 模块参数和 MCAL 驱动配置。
二、自适应平台的分层模型
AP 的分层逻辑与 CP 不同：它不再以“任务+中断”为调度核心，而是以进程、线程和面向服务的通信为核心。自上而下大致为：自适应应用（AA）通过 ara::com 等 API 访问服务；功能集群（Functional Cluster）提供通信、执行管理、状态管理、诊断、持久化、加密等能力；ARA（AUTOSAR Runtime for Adaptive Applications）是这些 API 的统称；再往下是 POSIX 操作系统与 Hypervisor，最终落到 S32 的高性能核与硬件加速器。
AP 的“服务”是运行时可发现、可动态绑定的。一个 AA 不需要知道对端进程在哪个核、哪块板，只需通过服务标识与实例标识发起 FindService 与 Subscribe。这种动态性带来灵活性，也带来启动时序、服务可用性和资源竞争的新问题，因此在 S32 上通常需要 Hypervisor 做核间隔离与资源配额。
三、BSW、RTE、SWC 三者的关系
可以用一句话概括：SWC 是“需求与算法的载体”，RTE 是“SWC 之间以及 SWC 与 BSW 之间的契约层”，BSW 是“把契约落到具体硬件与协议栈的执行体”。SWC 通过端口声明需要发送或接收的数据元素、需要调用的服务操作；RTE 根据这些声明生成通信代码，把 S/R 映射为队列或全局变量，把 C/S 映射为函数调用或跨核代理；BSW 则提供 RTE 所需的底层能力，例如 Com 提供信号打包、PduR 提供路由、CanIf 提供控制器抽象、Can 驱动操作 S32 的 FlexCAN 寄存器。
在 S32 上做集成时，最常见的错误是“绕过 RTE 直接调用 BSW”。这会让 SWC 与具体 ECU 绑定，失去可移植性，也会破坏 RTE 对并发与一致性的管理。正确做法是：SWC 只依赖 RTE 接口，若确实需要特殊外设访问，应通过 CDD 封装并由 RTE 暴露受控接口。
四、S32 上的裁剪与集成原则
裁剪不是“能删就删”，而是围绕功能安全、实时性、资源占用和认证成本做取舍。以下原则可作为工程判断依据：
- 按通信矩阵裁剪协议栈。若整车网络只使用 CAN FD 与以太网，LinIf、FrIf 可不集成；若诊断只走 DoIP，则 Dcm 的 CAN 传输层可关闭。裁剪后必须重新生成 RTE 与 BSW 配置，不能只改编译开关。
- 按实时性决定 CDD 边界。当控制周期小于 100 μs 或抖动要求小于 5 μs 时，Com 的队列与任务调度可能引入不可接受延迟，此时用 CDD 直接操作 S32 的 eMIOS/ADC 并配合中断，但需在安全分析中单独论证。
- 按核分配 BSW 实例。S32 多核场景下，CanIf、Com、PduR 通常按核分区，跨核通信通过 IPC 或共享内存；RTE 需配置跨核代理，避免同一 PDU 被两个核同时处理。
- 按安全等级隔离。ASIL-D 相关 SWC 与 QM 应用应通过 MPU 分区，BSW 的 WdgM、E2E、Dem 需覆盖安全相关路径；AP 侧则通过 Hypervisor 隔离不同安全域。
- 按启动时序编排。EcuM 负责 CP 侧初始化顺序，AP 侧由 Execution Management 管理进程启动；两者通过服务发现或共享内存同步，避免 AP 服务未就绪时 CP 已开始发送控制指令。
五、一个可执行的裁剪检查表示例
下表以“S32G 域控、CAN FD + 以太网、无 LIN、诊断走 DoIP”为假设场景，给出裁剪判断的参考字段。参数为示例，实际项目需按通信矩阵与安全需求确认。
| BSW 模块 | 是否保留 | 判断依据 | 配置影响 |
|---|---|---|---|
| Can / CanIf / CanTp | 保留 | CAN FD 控制与诊断报文 | 配置控制器数量、波特率、邮箱 |
| LinIf / Lin | 裁剪 | 无 LIN 从节点 | 移除后需重生成 RTE 端口映射 |
| EthIf / TcpIp / DoIP | 保留 | 诊断与大数据传输 | 配置 VLAN、IP、Socket 连接 |
| Com / PduR | 保留 | 信号打包与路由 | 按 PDU 更新通信矩阵 |
| NvM / Fee / Fls | 保留 | 标定与故障码持久化 | 配置块大小、擦写周期 |
| CDD（自定义） | 按需 | 高实时 PWM 捕获 | 需安全分析与接口评审 |
裁剪完成后，必须做三件事：重新生成 RTE 并检查端口映射是否完整；运行通信与诊断的冒烟测试，确认被裁剪模块不再被引用；更新安全分析与资源预算，确认 CPU 负载、RAM 占用和启动时间仍在目标范围内。只有这三步都通过，裁剪才算真正闭环。