3. 车载软件栈与AUTOSAR基础
在 S32 这类高性能车载计算平台上，软件栈通常不是“单一操作系统 + 应用”的简单结构，而是由 Classic AUTOSAR、Adaptive AUTOSAR 以及厂商基础软件共同组成的混合体系。理解两者的部署边界、配置入口和验证关注点，是后续做集成与交付的前提。
一、Classic 与 Adaptive 在 S32 上的分工
Classic AUTOSAR 面向硬实时、确定性控制，典型承载 CAN/LIN/FlexRay 通信、诊断、IO 控制、电机与车身控制等任务。它运行在 S32K、S32G 的实时核或 MCU 侧，以 RTE 为中枢，向下通过 MCAL 访问 MCU 外设，向上承载 SWC。Adaptive AUTOSAR 面向高算力、动态部署、面向服务的场景，典型承载智能座舱、域控制器、网关服务、OTA 与感知融合，运行在 S32G 的 A 核（Cortex-A）上，基于 POSIX 操作系统（如 Linux/QNX），以 ARA 为运行时接口，通过 SOME/IP、DDS 等做服务通信。
在 S32G 上常见的部署形态是：A 核跑 Adaptive 与 Linux，M 核（Cortex-M7）跑 Classic AUTOSAR 或 RTOS，两者通过 IPCF（Inter-Platform Communication Framework）或共享内存 + 中断做跨核通信。验证时，跨核通信的时延、丢包与一致性是重点，而不是只看单侧功能。
二、BSW 与 MCAL 配置要点
Classic 侧的配置以 ARXML 为中心，通过 DaVinci Configurator 或 EB tresos 完成。MCAL 是直接操作 S32 寄存器的底层驱动，配置时需重点关注：
- Mcu 模块：时钟树（PLL、分频）、复位源、RAM 初始化。S32G 的 M 核主频、外设时钟必须与硬件设计一致，否则 CAN 波特率会偏差。
- Port / Dio：引脚复用、方向、上下拉、驱动能力。S32 的 SIUL2 引脚多路复用需与原理图逐脚核对。
- Can / CanIf：波特率、采样点、邮箱数量、FIFO 深度。采样点建议 75%~80%，与总线其他节点一致。
- Adc / Pwm / Icu：通道分组、触发源、分辨率、周期。用于电机或传感器采样时，需与触发链对齐。
BSW 层配置要点：COM 的信号映射与发送模式（周期/事件）、PduR 路由表、Dcm 的诊断服务与会话、Dem 的 DTC 与事件、NvM 的块管理与掉电保护。一个常见错误是 COM 信号与 DBC 不一致，导致上位机解析错位，因此配置后必须做 ARXML 与 DBC 的交叉检查。
Adaptive 侧没有 MCAL 概念，配置以 Manifest（JSON/ARXML）为主，包括 Execution Manifest、Service Instance Manifest、Machine Manifest。部署时需关注进程到 CPU 核的绑定、资源组、服务发现配置。S32G 上还需配置 IPCF 通道，明确共享内存地址、通道 ID 与中断号。
三、与验证交付的关联
配置不是“生成代码就结束”，而是验证的输入。建议把验证分为三层：
- 配置一致性验证：ARXML、DBC、硬件原理图三方对齐。检查信号名、周期、字节序、引脚号。可用脚本比对，避免人工遗漏。
- 模块级验证：MCAL 单模块测试（如 CAN 回环、ADC 采样精度）、BSW 模块测试（COM 发送周期、Dcm 会话切换、NvM 掉电恢复）。
- 集成与跨核验证：Classic 与 Adaptive 通过 IPCF 交互，验证时延、丢包、复位后恢复。诊断方面需验证 DoIP 与 CAN 诊断的一致性。
把 Classic 与 Adaptive 的部署边界、BSW/MCAL 配置入口和验证交付物对应起来，就能在 S32 平台上形成可复现、可追溯的软件集成流程，而不是把配置和验证割裂成两件事。