3. Snapdragon域控软件栈与分区
Snapdragon Ride、8295/8775 这类域控芯片在 HIL 台架上最容易被误解的一点是：把它当成“一块跑某个操作系统的板子”。实际上它是一台多虚拟机、多安全等级、多实时性要求并存的“片上分布式系统”。同一颗 SoC 上，QNX 负责仪表与安全相关实时任务，Linux 承担感知与计算密集任务，Android 提供座舱 HMI 与生态应用，Hypervisor 负责把它们隔离在各自虚拟机里，AUTOSAR AP/CP 则分别落在高性能域与实时控制域。验证时如果分不清“这条用例到底在验证哪一层”，就会出现用例归属混乱、故障注入打错对象、结果无法判读的问题。
软件栈的分层与分区关系
从下往上可以这样理解：最底层是 SoC 硬件与 Hypervisor（常见为 QNX Hypervisor 或基于 ARM 虚拟化扩展的 Type-1 Hypervisor），它把 CPU 核、内存、外设（如 CAN 控制器、以太网 MAC、显示控制器、GPU）切分成多个 VM。每个 VM 里再跑各自的 Guest OS：VM0 通常是 QNX，承载仪表、安全监控、部分 AUTOSAR AP 服务；VM1 是 Linux，跑感知、规划、数据记录；VM2 是 Android，跑座舱 HMI。AUTOSAR CP 一般不在这些富 OS 里，而是落在 MCU 侧（如安全岛或独立 MCU），通过 CAN/Ethernet 与 SoC 通信。
中间件层是验证中最容易被忽略的“粘合层”。QNX 侧常用 SOME/IP、DDS 或自研 IPC；Linux 侧常用 ROS 2、DDS、共享内存；Android 侧用 Binder、AIDL。跨 VM 通信则依赖 Hypervisor 提供的虚拟网卡、vdev 或共享内存通道。OTA 模块通常作为独立服务运行在 Linux 或 QNX 上，负责差分升级、A/B 分区切换、回滚。验证时，中间件和 OTA 不是“背景”，而是故障传播的主要路径。
分层验证策略：每层验证什么、怎么判读
把上面的分区映射到 HIL 验证，可以形成四层策略。第一层是硬件与 Hypervisor 层，验证重点是虚拟化正确性：VM 能否按配置启动、内存是否越界、虚拟中断是否按时投递、SMMU 是否拦截非法 DMA。典型做法是在 Hypervisor 日志中检查 VM 启动时间戳，用共享内存计数器测量跨 VM 通信往返时延。示例判据：VM0 到 VM1 的 64 字节消息往返时延在空载下应小于 200 μs，若超过 1 ms 则需排查 vdev 队列深度或 CPU 亲和性配置。
第二层是 Guest OS 与中间件层。QNX 侧关注实时线程的周期抖动，Linux 侧关注调度延迟与内存压力，Android 侧关注启动时间与 ANR。中间件验证要覆盖序列化/反序列化正确性、QoS 配置（如 DDS 的 RELIABLE 与 BEST_EFFORT）、以及跨 VM 服务发现。例如在 Linux 侧用 ros2 topic hz 观察感知话题频率，同时用 QNX 侧仪表服务订阅同一数据，检查端到端时延是否满足 50 ms 约束。
第三层是 AUTOSAR AP/CP 层。AP 侧验证服务化接口（SOME/IP 方法调用、事件订阅）和状态管理；CP 侧验证周期任务、总线通信、UDS 诊断和安全机制。HIL 中常用 CANoe 或类似工具模拟剩余总线，注入报文丢失、CRC 错误、总线关闭等故障，观察 CP 侧是否在规定时间内进入安全状态。示例：注入 5 帧连续 CAN 报文丢失后，安全监控应在 100 ms 内触发降级，该时间由看门狗周期和任务调度共同决定。
第四层是 OTA 与系统级联动。OTA 验证不能只测“升级成功”，而要覆盖 A/B 分区切换、断电恢复、版本回滚、跨 VM 一致性。典型场景：在 Linux 侧触发 OTA 下载，升级包写入备用分区，重启后 Hypervisor 引导新分区，QNX 和 Android 需同步切换到匹配版本。若 Android 版本与 QNX 不匹配，HMI 可能无法显示仪表数据。验证时应在升级前后分别记录各 VM 的版本号与关键服务状态，并模拟升级过程中断电，确认回滚后系统仍能正常启动。
验证用例归属与结果判读示例
下面给出一个跨层用例的简化记录表，用于说明如何把“现象”映射到“层”和“判据”。表中数据为教学示例，非实测结果。
| 用例编号 | 注入/操作 | 观察层 | 观察量 | 判据（示例） | 失败时优先排查 |
|---|---|---|---|---|---|
| HV-01 | 配置 VM1 内存配额减少 20% | Hypervisor | VM1 启动日志、OOM 计数 | VM1 仍能启动，无 OOM | 内存预留、balloon 驱动 |
| MW-03 | DDS RELIABLE 话题注入 10% 丢包 | 中间件 | 端到端时延、重传次数 | 时延 < 80 ms，重传 < 3 次 | QoS 配置、网络队列 |
| CP-07 | CAN 总线连续 5 帧丢失 | AUTOSAR CP | 安全状态标志、降级时间 | 100 ms 内进入降级 | 看门狗周期、任务优先级 |
| OTA-02 | 升级写入 50% 时断电 | OTA / 系统 | 重启后版本号、服务状态 | 回滚到旧版本，各 VM 正常 | A/B 标志、引导加载顺序 |
判读时要注意“层间耦合”：OTA-02 失败可能表现为 Android 无法启动，但根因在 Hypervisor 引导配置或 QNX 侧 OTA Agent 的分区标志写入。因此 HIL 台架应保留各 VM 的独立日志通道，并在时间轴上对齐。建议在测试脚本中为每个用例打上“层标签”，失败时先按标签过滤日志，再沿故障传播路径向上或向下排查。
最后强调一个实践原则：分区不是目的，隔离才是。验证时要主动制造“越界”场景——让 Linux 侧高负载、让 Android 侧频繁 GC、让 CP 侧总线拥塞——观察 Hypervisor 是否守住隔离边界，QNX 实时任务是否仍满足截止时间。只有这些边界被验证过，软件栈的分层策略才算真正落地。