1. 智能座舱域控与Hypervisor需求分析

智能座舱域控制器把仪表、中控、抬头显示、后排娱乐、环视与驾驶员监控等多个系统收敛到一颗SoC上。硬件资源被合并，但各系统的安全等级、实时性、操作系统与生命周期并不相同：仪表属于安全相关显示，中控承载应用生态，环视与DMS涉及图像实时处理。Hypervisor的核心价值，就是在同一SoC上为这些异构系统提供隔离、调度与资源共享的受控边界。需求分析要回答的不是"要不要虚拟化"，而是"哪些系统必须隔离、隔离到什么程度、资源如何分配、异常时如何降级"。

一、多系统隔离：从硬件分区到软件边界

隔离需求首先来自安全等级差异。仪表通常要求达到ASIL-B，中控信息娱乐多为QM，两者若共享同一Linux内核，一个应用崩溃或内存越界就可能影响仪表显示。Hypervisor通过Stage-2地址转换、中断控制器虚拟化和设备直通，把物理资源切分为多个虚拟机（VM）。典型做法是：仪表VM独占一个显示通道与看门狗，中控VM使用GPU与音频，环视VM直通ISP与摄像头接口。

隔离不是"全部分开"就越好。过度隔离会导致共享内存、GPU、音频DSP无法复用，成本与延迟上升。工程上常用"分区+受控共享"：CPU核按VM绑定，内存按物理地址段划分，GPU通过虚拟化中间层分时复用，音频通过virtio或共享内存传递。判断隔离是否达标，可观察三个指标：故障VM是否触发其他VM重启、跨VM内存访问是否被IOMMU拦截、中断是否被错误路由。

二、实时性与功能安全约束

座舱内不同任务的实时性要求差异很大。仪表刷新通常要求端到端延迟低于50ms，倒车影像要求低于100ms，而中控应用可容忍数百毫秒。Hypervisor的调度器需要为实时VM提供确定性时延，常见手段包括：为仪表vCPU分配独立物理核、使用实时调度策略、限制中控VM的CPU配额、关闭不必要的电源管理状态。

功能安全方面，Hypervisor本身若作为安全机制的一部分，需满足ISO 26262的ASIL分解要求。工程约束包括：Hypervisor需具备安全监控通道，检测VM心跳；看门狗需能独立复位故障VM而不影响其他VM；关键显示通路需有硬件叠加层与CRC校验。典型场景是仪表黑屏：若仪表VM崩溃，Hypervisor应触发仪表VM重启，同时保持中控与环视继续运行，并在仪表恢复后重新初始化显示通道。

三、资源共用与典型场景

资源共用的核心矛盾是"性能隔离"。GPU、NPU、音频DSP、内存带宽都是共享资源，若一个VM占满GPU，其他VM的渲染就会卡顿。工程上通常采用配额与优先级结合的方式：为仪表VM的显示层设置最高优先级，中控VM的GPU时间片限制在40%以内，环视VM的ISP带宽预留固定值。内存带宽可通过QoS寄存器或Hypervisor的带宽调节器限制。

典型场景一：倒车触发。当挡位切换到R挡，环视VM需在100ms内启动并输出画面。此时Hypervisor应保证环视VM的vCPU立即获得调度，ISP直通通路不被中控VM占用，显示控制器切换到环视图层。若环视VM启动超时，系统应降级为中控VM显示倒车辅助线并提示摄像头不可用。

典型场景二：仪表重启。仪表VM因看门狗超时被Hypervisor复位，中控与环视不受影响。仪表VM重启后需重新初始化显示通道，Hypervisor应保留其内存分区与显示配置，避免重新枚举设备导致延迟。判断恢复成功的依据是：仪表画面在2秒内重新出现，且中控无闪屏或音频中断。

四、需求分析的可执行检查项

在项目早期，需求分析应形成可验证的约束条目，而不是停留在"支持虚拟化"的层面。以下检查项可直接用于评审：

从工程约束看，Hypervisor不是万能层。它解决的是隔离与调度，但无法弥补硬件资源不足。若SoC的GPU算力不足以同时支撑中控3D渲染与环视拼接，再好的虚拟化方案也会导致卡顿。因此需求分析必须与硬件选型同步：先确认CPU核数、GPU算力、ISP通道数、内存带宽是否满足多VM并发峰值，再确定分区方案。典型座舱SoC通常需要8核CPU、至少2个显示通道、独立ISP与NPU，才能支撑仪表、中控、环视、DMS四VM并行。

最终，需求分析输出应包含：VM清单与安全等级、CPU/内存/GPU/ISP分配表、实时性指标、故障域与降级策略、共享资源仲裁规则。这些内容将直接指导后续Hypervisor配置、设备树划分与测试用例设计。