📚 课程目录第3章 S32G软件架构与量产验证对象

3. S32G软件架构与量产验证对象

S32G作为中央网关，其软件不是单一程序，而是由多个运行环境、多个核、多个分区共同构成的复合系统。量产验证的第一步，不是急着写测试用例，而是先把“软件架构”和“验证对象”对应清楚：哪些软件跑在哪个核上、由谁启动、谁管理谁、哪些接口是跨域边界。只有边界清晰，测试边界才清晰。

一、四层软件栈与运行位置

从下往上，S32G的软件可以分成四个层次。最底层是Bootloader，通常包含BootROM、HSE固件、以及用户可刷写的二级引导（如基于AUTOSAR CP的Flash Bootloader或U-Boot SPL）。它负责上电自检、镜像校验、A/B分区选择、跳转到应用。第二层是Hypervisor，在S32G上常见的是基于ARM虚拟化扩展的Type-1 Hypervisor，把多个核和内存划分成若干虚拟机（VM），让AUTOSAR CP实时域与AUTOSAR AP高性能域共存。第三层是运行环境：AUTOSAR CP（Classic Platform）跑实时控制、CAN/LIN/以太网通信、诊断；AUTOSAR AP（Adaptive Platform）跑面向服务的通信、OTA管理、日志与大数据处理。第四层是应用与中间件：诊断栈（UDS/OBD）、OTA客户端、网络管理、存储管理、安全模块等。

需要特别注意的是，S32G有多个Cortex-A53核和Cortex-M7核。典型划分是：M7核运行AUTOSAR CP或安全监控，A53核运行Hypervisor及其上的AP/CP虚拟机。验证时必须先确认“被测对象运行在哪个核、哪个VM、哪个分区”，否则测试结果无法归因。

二、固件分区与OTA的验证对象

量产验证中，固件分区是最容易被忽视却最容易出问题的对象。S32G通常把Flash划分为：Bootloader区、A/B应用镜像区、标定/配置区、日志区、HSE密钥区。A/B分区的意义在于OTA升级失败时可回滚。验证时要覆盖三类场景：正常升级后新镜像启动、升级中断电后回滚到旧镜像、以及A/B镜像版本号与校验值的一致性。

OTA本身不是单一模块，而是一条链：云端下发→AP侧OTA客户端接收→写入备用分区→校验→通知Bootloader切换→重启生效。这条链上每个环节都是验证对象。例如，AP侧客户端要验证断点续传和签名校验；Bootloader要验证切换标志位和回滚逻辑；诊断栈要验证升级期间的会话保持与故障码上报。

三、诊断栈的测试边界

诊断栈横跨CP和AP。CP侧通常实现UDS on CAN/CAN-FD和DoIP的基础服务，AP侧实现基于SOA的诊断服务和大数据上传。验证边界要区分：诊断请求从哪个物理通道进入、由哪个VM处理、响应时间是否满足量产指标。典型示例参数：UDS会话切换响应时间要求小于50ms，DoIP激活线唤醒到可诊断状态小于200ms，这些是合理假设的工程目标值，实际以项目诊断规范为准。

验证对象清单建议按“核—VM—分区—接口”四要素登记，每个测试用例都标注它覆盖的是哪一层、哪个边界。这样出现问题时能快速定位是Bootloader、Hypervisor还是应用层的问题。

四、各模块的测试边界划分

Bootloader的测试边界是：上电到应用跳转之间的所有行为，包括校验失败、分区损坏、看门狗复位。Hypervisor的测试边界是：VM启动顺序、资源隔离、VM间通信、异常注入下的隔离性。AUTOSAR CP的测试边界是：RTE接口、BSW服务、MCAL驱动、通信栈。AUTOSAR AP的测试边界是：ARA接口、服务发现、进程生命周期。诊断栈的测试边界是：会话层、服务层、传输层、以及跨VM的诊断路由。

实际项目中，建议用一张“软件模块—验证层级—测试类型—通过准则”的对应表来管理。例如：

软件模块	运行位置	核心验证对象	典型通过准则（示例）
Bootloader	M7 / A53 启动核	镜像校验、A/B切换、回滚	断电回滚成功率100%，切换标志正确
Hypervisor	A53	VM隔离、启动顺序、资源分配	单VM异常不影响其他VM运行
AUTOSAR CP	VM0 / M7	RTE、通信栈、诊断基础服务	CAN报文周期抖动小于±10%
AUTOSAR AP	VM1 / A53	服务发现、OTA客户端、日志	服务发现时间小于500ms
诊断栈	跨VM	UDS/DoIP、会话、路由	会话切换小于50ms，无超时

五、验证顺序与依赖关系

量产验证不能并行乱做，要遵循依赖顺序：先验证Bootloader能正确启动和回滚，再验证Hypervisor能正确拉起各VM，然后验证CP和AP各自的基础功能，最后验证跨域的诊断和OTA。原因是：如果Bootloader都不稳定，上层所有测试结果都不可信。同理，Hypervisor隔离没验证通过，CP和AP的测试环境就不干净。

推荐验证顺序（示例）：
1. Bootloader 单模块：上电、校验、A/B切换、回滚
2. Hypervisor 单模块：VM启动、隔离、资源分配
3. CP 基础：RTE、通信、MCAL
4. AP 基础：ARA、服务发现、进程管理
5. 诊断栈：UDS/DoIP 会话与服务
6. OTA 端到端：下发、写入、校验、切换、回滚
7. 跨域集成：诊断路由、OTA与诊断并发

需要强调的是，每一层的验证都要有明确的“进入条件”和“退出条件”。进入条件例如：Bootloader已通过回滚测试；退出条件例如：连续100次上电启动均成功进入应用。这些条件不是形式，而是保证后续测试结果可复现的基础。

常见误区：把AUTOSAR CP和AP当成两个独立项目分别验证，忽略Hypervisor和Bootloader对它们的影响。实际量产问题中，相当比例来自启动链和分区切换，而不是应用逻辑本身。

总结来说，S32G软件架构的验证对象可以归纳为“一条启动链、两个运行环境、三类分区、四类接口”。启动链是Bootloader到Hypervisor到应用；两个运行环境是CP和AP；三类分区是Bootloader区、A/B应用区、配置与日志区；四类接口是CP内部RTE、AP内部ARA、CP与AP跨VM接口、以及对外诊断与OTA接口。把这张对象图建立起来，后续的测试用例设计、覆盖率统计和问题归因才有共同的语言。