3. 座舱系统软件架构
SA8155 座舱系统并不是“一个操作系统跑所有应用”，而是以 Hypervisor 为底座，把 QNX、Android、Linux、AUTOSAR AP/CP 等不同安全等级、不同实时性要求的软件域混合部署在同一颗 SoC 上。理解这套架构的关键，不是记住各 OS 的名字，而是看清“谁负责隔离、谁负责实时、谁负责生态、谁负责通信”。
一、核心原理：Hypervisor 是资源仲裁者，不是业务系统
Hypervisor 运行在 EL2（或等效虚拟化层级），向下管理 CPU、内存、中断、外设与 GPU 等硬件资源，向上为每个 Guest OS 提供虚拟化视图。它本身不承载座舱业务，而是决定“哪个虚拟机在什么时刻、以什么优先级、访问哪块资源”。在 SA8155 上，典型部署是：
- QNX 虚拟机：承担仪表、HUD、实时控制、安全告警等 ASIL 相关功能，强调确定性时延与快速启动。
- Android 虚拟机：承担中控娱乐、导航、语音、应用生态，强调图形渲染、多媒体与丰富应用框架。
- Linux 虚拟机：承担网关、日志、OTA、部分 AI 推理或调试服务，强调可裁剪与工具链灵活。
- AUTOSAR AP/CP：通常以进程或独立核的形式与 QNX/Linux 协同，CP 偏实时信号采集与执行，AP 偏服务化通信与 SOA 接口。
因此，混合部署的本质是“按安全与实时需求切分域”，而不是按功能菜单切分。仪表不能因为 Android 卡顿而黑屏，倒车影像不能因为应用启动而延迟，这就是 Hypervisor 隔离存在的意义。
二、方法流程：从“分域”到“通信”的四步落地
- 资源分区：为每个 VM 分配 CPU 核、内存块、GPU 时间片、显示图层与音频通道。例如 QNX 独占 1~2 个 A 核用于实时任务，Android 使用剩余核与大内存，Linux 使用小内存但保留网络外设。
- 启动时序编排：Hypervisor 先启动，再按安全等级拉起 QNX，确保仪表与倒车影像在 2 秒内可用；Android 可稍后启动，但必须保证与 QNX 的显示合成不互相阻塞。
- 通信通道建立：控制信号走 vSocket、SOME/IP 或 DDS，大数据走共享内存、DMA-BUF 或 virtio 队列。音频、视频、触控事件需要独立通道，避免与诊断日志争抢。
- 监控与降级：Hypervisor 监控各 VM 心跳，Android 崩溃不应影响 QNX；若共享内存通道异常，应降级到安全提示或备用通道。
核心判断：凡是“不能卡、不能黑、不能丢”的功能，优先放 QNX 或 AUTOSAR CP；凡是“需要生态、需要频繁迭代”的功能，放 Android；凡是“需要工具链、需要网关能力”的功能，放 Linux。通信机制的选择，取决于时延、带宽与安全等级，而不是开发便利性。
三、案例场景：倒车影像与中控导航同时工作
用户挂入倒挡，QNX 侧的倒车影像服务必须在 200ms 内出图，同时 Android 侧导航仍在后台运行。此时系统行为如下：
- QNX 通过 Hypervisor 的显示虚拟化通道，直接占用一个高优先级图层，不被 Android SurfaceFlinger 阻塞。
- 摄像头数据通过共享内存或 DMA-BUF 直接送入 QNX 显示管线，避免经过 Android 用户态拷贝。
- Android 导航通过 vSocket 向 QNX 发送“倒车状态”订阅，QNX 回传状态后，Android 暂停部分动画以降低 GPU 占用。
- 若 Android 发生 ANR，QNX 仍能独立完成倒车影像渲染，Hypervisor 只回收 Android 的 GPU 时间片。
这个场景说明：混合部署的价值不是“把多个 OS 塞进去”，而是让关键功能在资源竞争时仍能获得确定性服务。
四、常见误区与复盘
| 误区 | 现象 | 正确做法 |
|---|---|---|
| 把仪表也放到 Android | Android 卡顿导致仪表掉帧或黑屏 | 仪表放 QNX，Android 只做娱乐域 |
| 所有跨域数据都走 vSocket | 大图/音频拷贝导致 CPU 占用高、时延大 | 控制走 vSocket，数据走共享内存/DMA-BUF |
| 忽略 Hypervisor 中断路由 | 触控或摄像头中断丢失，响应抖动 | 明确 vIRQ 归属与优先级，避免中断风暴 |
| AUTOSAR AP/CP 边界不清 | 实时信号被服务化框架拖慢 | CP 管硬实时 IO，AP 管 SOA 服务与编排 |
排障提示：当座舱出现“Android 一卡，仪表也抖”时，优先检查 Hypervisor 的 CPU 配额、GPU 时间片与共享内存通道是否被 Android 侧异常占用；当跨域通信时延突然升高时，先看 vSocket 队列深度与共享内存拷贝次数，再查 AUTOSAR AP 服务发现是否频繁重连。
五、配置与观测示例
以下为 Hypervisor 侧常见的资源分区与通信观测片段，用于理解“隔离”与“通道”在工程中的落地形式：
# 伪配置：VM 资源分区
vm.qnx.cpu = "core0,core1"
vm.qnx.mem = "0x80000000-0x9FFFFFFF"
vm.qnx.prio = 90
vm.android.cpu = "core2,core3,core4,core5"
vm.android.mem = "0xA0000000-0x1FFFFFFF"
vm.linux.cpu = "core6"
vm.linux.mem = "0x20000000-0x27FFFFFF"
# 跨域通信通道
channel.control = "vSocket:5000"
channel.video = "shmem:0x30000000,size=64MB"
channel.audio = "virtio-audio:0"
channel.can = "virtio-can:0"
# 观测命令（示意）
cat /proc/hypervisor/vm_status
cat /proc/hypervisor/virq_stat
dmesg | grep -i "vsocket\|shmem\|virtio"复盘时建议把“功能—OS 归属—通信通道—时延预算—降级策略”做成一张清单，每新增一个座舱功能，都先回答它属于哪个域、走哪条通道、最坏时延是多少、异常时如何降级。只有把这些问题在架构阶段定清楚，SA8155 的混合部署才不会退化成“多个系统互相抢资源”的混乱局面。