干货实录 | Hypervisor技术在功能安全架构中的应用

本文整理自SASETECH社区技术分享直播《Hypervisor技术在功能安全架构中的应用》主讲人是小鹏汽车智驾SoC功能安全架构师李智宇老师——深耕汽车电子领域十余年熟悉行业内主流的汽车软件技术与开发方法。专注功能安全架构设计逾五年成功主导并交付多个符合功能安全标准的量产项目。本文涵盖汽车电子系统复杂度演进的背景分析、多域融合对功能安全提出的新挑战、Hypervisor技术的分类与选型逻辑、关键技术细节CPU虚拟化/I/O/实时性/隔离性以及在典型芯片架构中的落地实践最后附精选问答。以下是直播精选内容一、复杂度攀升安全开发面临三大矛盾从最早的分布式开发单个MCU完成指定功能各芯片间通过通信协作到今天多域融合的集中式架构汽车电子系统的复杂度呈指数级增长。感知端的传感器种类已经相当丰富超声波雷达、毫米波雷达、激光雷达加上多类摄像头广角型、远距型等数据量激增。这些数据最终汇入决策层的AI计算平台再由执行层通过SoC完成控制动作。在整个链条上传感器的数量和种类在增加AI算法在快速演进软件版本迭代越来越快。这对传统的功能安全开发模式提出了三个核心矛盾第一系统庞大与开发周期长的矛盾。已经没有办法在一个巨型系统里从头到尾完整做一遍功能安全开发。第二算法快速迭代与安全开发节奏的矛盾。算法迭代快但功能安全开发周期慢两者的节奏不匹配。第三成本与安全的权衡。理论上任何复杂系统的功能安全开发都是可行的但在项目周期缩短的大背景下安全落地变得异常困难。正是这三大矛盾让Hypervisor虚拟化技术走入了工程视野。二、多域融合的破局点六大核心能力在软件定义汽车的背景下虚拟化技术之所以能成为关键解核心在于它提供了六大能力第一是模块化开发。只要理清软件模块间的依赖关系处理好共因失效和级联失效一个模块的迭代就不需要影响到另一个模块的功能安全开发。这意味着功能安全不再被绑定到整个系统的版本节奏上。第二是灵活的资源分配。SoC的计算和存储资源可以按需求进行静态配置或动态调整这对于快速迭代环境下的架构演进至关重要。第三是混合临界Mixed-Criticality隔离。同一个SoC内车控类软件可能是ASIL D仪表类可能是ASIL B还有些调试功能是QM——不同安全等级的软件需要安全共存。虚拟化的价值不在于提升某个等级而在于提供隔离基础让它们互不干扰。第四是外设共享。像GPU、显示输出、网络、存储这些硬件资源需要在不同ASIL等级的软件之间安全共享虚拟化提供了统一的管理基础。第五是冗余设计。系统可以分配多份资源做同步运算通过对比检测异常一旦发现故障就切换到冗余备份。第六是系统可用性。每个Guest OS具备独立重启能力故障模块可以单独复位不影响整体系统运行。三、选型逻辑为什么汽车行业选择了Type 1虚拟化的概念在服务器端已经很成熟——日常用的虚拟机、Docker容器都属于广义的虚拟化。但把它搬到汽车电子上选型逻辑就完全不同了。1、Type 1vsType 2汽车行业目前讨论最多的是Type 1裸机型。它直接运行在硬件上不依赖任何主机操作系统特点很鲜明设备代码架构简洁、对资源要求少、具备形式化验证的条件。正是因为代码量小、可验证性强只有Type 1形态能支持高ASIL等级的认证。相比之下Type 2宿主机型需要借助宿主机OS来管理资源——比如在Linux系统上再跑一个虚拟化层。这种方式的延迟和性能损耗更高做高ASIL等级落地的难度要大得多。早期在PC上装虚拟机如Windows上跑VirtualBox再跑Linux本质上就是Type 2的思路并不适合汽车场景。2、容器的本质区别还有一个容易混淆的概念是容器。容器也是运行在Host OS之上的——先有一个基础操作系统再在上面集成容器引擎然后跑各个业务。它的虚拟化程度不如Type 1 Hypervisor彻底隔离性和实时性也都差一截。所以在汽车功能安全领域容器更多用于非安全相关的业务部署。四、三种虚拟化方式的技术路径路Hypervisor实现虚拟化有三种技术路径各有优缺。1、全虚拟化兼容性优先性能代价大全虚拟化通过软件来模拟完整的硬件环境上面的Guest OS完全不感知底层硬件也无需做任何修改——所有适配都由Hypervisor来完成。优势是兼容性极强任何操作系统都可以直接跑。但代价是每次特权级访问都要陷入Hypervisor软件栈中转性能开销很大。所以在汽车领域全虚拟化通常只用来模拟串口、I²C这类简单硬件或者在硬件还没就绪时用QEMU做功能验证。2、硬件辅助虚拟化性能接近物理机但受限于芯片设计Intel最早提出了这个概念——由CPU硬件直接提供资源共享功能。在ARM侧对应的技术是MMU两级页表转换和虚拟异常注入。它的性能非常接近物理机因为特权访问直接由硬件完成不需要Hypervisor在软件层面模拟。兼容性也很好不需要修改Guest OS。安全性也更强。但有一个局限性强依赖CPU硬件设计。当前芯片支持哪些虚拟化功能就用哪些后续无法通过软件迭代来补充。所以当芯片能力不够时就需要其他方案来配合。3、半虚拟化性能好但兼容性差半虚拟化是硬件辅助虚拟化还不够成熟时期的过渡方案。它通过Guest OS与Hypervisor协作来实现Guest OS做前端驱动Hypervisor做后端驱动按照virtio标准通信通过Hypercall完成调用。性能好可以实现复杂的硬件功能网卡、显卡等但代价是需要修改Guest OS的内核——把所有的特权指令替换成Hypercall API。这在量产项目中意味着维护成本大幅上升。行业现状在实际量产项目中这三种方式往往是组合使用的。核心的控制面用半虚拟化或硬件辅助虚拟化保证实时性和确定性非安全相关的数据面用全虚拟化提升兼容性。没有一种方案包打天下选型关键看业务场景。五、从选型到落地Hypervisor的关键技术细节1、CPU虚拟化静态分区与动态调度车载高性能芯片通常采用多核CPU架构。在对称多处理架构下Hypervisor会让Guest OS在指定的CPU核上运行——通常是静态配置的简单可靠。但Hypervisor也可以按优先级进行动态调度最大化利用CPU资源。高负载时提升主频低负载时关闭某些核或降频——对于电车来说功耗降低直接带来续航提升。动态调度的前提是保证可靠性和可预期性防止某个Guest OS的访问导致死锁。所以Hypervisor内部通常集成SystemMonitor来检测各Guest OS的运行状态必要时可以对单个Guest进行复位。2、I/O设备虚拟化前后端配合嵌入式领域多采用半虚拟化来处理I/O设备。前端驱动Guest OS中通过Hypervisor的通信机制发送请求到后端驱动Hypervisor中后端再通过物理驱动访问设备。这一块最大的挑战来自生态——不同厂商的Guest OS和不同Hypervisor之间的衔接。如果Hypervisor是自研的就需要Guest OS的驱动做对应适配这也是半虚拟化最主要的维护成本来源。3、实时性Hypervisor的硬指标在多域融合场景下虚拟机上必然要跑实时系统。Hypervisor的实时性直接决定了整个系统的实时性基础。衡量实时性的两个关键指标是中断延迟从硬件产生中断到Guest OS收到中断的时间和调度延迟高优先级虚拟机从就绪到完成调度的时间。由于Hypervisor的存在中断必然要多经过一层转发如何把这个额外延迟压缩到最小是Hypervisor工程实现的核心竞争力4、一个常见误区免干扰性不等于独立性这是分享中特别强调的一个认知点。Hypervisor提供的是免干扰性——一个系统运行异常不会由于Hypervisor的隔离机制影响到另一个系统。但Hypervisor内部的Guest OS之间不具备独立性。因为同一SoC内各模块共用电源和时钟——除非是芯片架构级的设计如ApplicationIsland和SafetyIsland采用独立的供电和时钟否则独立性无法在Hypervisor层面解决。这个区别直接决定了功能安全架构的设计策略Hypervisor内部不能做ASIL等级拆解但可以做混合临界的不同ASIL等级共存例。六、在芯片中的实际落地以NVIDIA Orin为例Orin的功能安全架构是经典的三层安全监控eGAS架构第一层——Application Island。这是常规计算功能的主阵地。通过Hypervisor技术确保上面跑的不同Guest OS如QNX和Linux的计算功能正确同时提供不同ASIL等级软件的隔离共存。第二层——Safety Island。职责是监控Application Island的运行可靠性。集成了多种安全技术ECC校验、奇偶校验、电源监控、温度监控等。当检测到异常时通过芯片内部的HSMHardware Safety Monitor通知Safety Island执行安全兜底策略——比如让系统进入安全模式。第三层——外部MCU。典型选择如TC397ASIL D提供一个高实时、高可靠的Safety OS。通过心跳监控和带外电源监控与SoC交互确保整个系统在最坏情况下仍有兜底。在Application Island内部Hypervisor上可以同时部署多个操作系统。比如QNX负责高ASIL等级、高实时性的任务和Linux负责高性能计算两者通过Hypervisor的通信机制交互由Hypervisor统一提供Guest OS的监控和系统基础运行能力。NVIDIA的Hypervisor方案是自研的Type 1裸机型Hypervisor不是用KVM等开源方案。在Orin上由于芯片算力有限通常需要2-4块Orin完成智驾系统Hypervisor的应用需求还不是很大。但到了单颗Thor芯片上——算力大幅提升座舱和智驾都要集成进来——Hypervisor就成了刚需。七、精选问答Q1功能安全的就业方向有什么建议答早期从业者多在外资Tier1博世、大陆等做功能安全经理或管理。现在业内真正缺的是既懂技术硬件/软件又懂功能安全的复合型人才尤其是功能安全架构师。功能安全是一个横向领域——软件、硬件、AI、AUTOSAR、Linux都会涉及。从岗位来看软件功能安全工程师和硬件功能安全工程师的需求比功能安全经理要大。后续自动驾驶功能安全强标出台功能安全相关岗位的前景会更好。Q2功能安全软件必须部署在虚拟化环境中吗答不是。如果芯片硬件本身符合功能安全要求直接在裸硬件上跑一个有ASIL等级的OS系统已经符合要求。Hypervisor解决的是两个问题一是不同ASIL等级软件的共存问题二是模块化迭代的成本问题——改一个QM模块不需要对整个系统重新做功能安全开发。Q3Hypervisor对应eGAS三层架构的哪一层答第一层。Hypervisor提供的是不同ASIL等级软件共存的基础条件属于第一层的保障范畴。但具体怎么用、每个业务应该部署在哪个OS上还是要基于安全分析Safety Analysis来决定。Q4Guest OS的独立性还需要进一步考虑吗答很重要。Hypervisor内部的Guest OS之间不具备独立性共用供电和时钟。如果需要做ASIL等级拆解还需要结合芯片级独立供电时钟设计或外部MCU。单个Hypervisor内部的Guest OS之间满足的是免干扰性不是独立性——这是功能安全架构设计中容易忽略的一个关键判断。结语Hypervisor在功能安全架构中的核心价值归结为两点一是解决了不同ASIL等级软件在同一SoC上安全共存的工程难题二是通过模块化开发和独立重启等机制让功能安全开发不再被整个系统的版本节奏绑架。但它不是万能的——提供的是免干扰性而非独立性不能替代芯片安全岛或MCU兜底。每个决策点都需要结合具体的安全分析来判断。从Orin到Thor的演进表明多域融合趋势下Hypervisor的角色也会越来越重。本期分享就到这里希望内容对大家有所启发。当然技术探索的边界远不止于此——如果你有其他想深入钻研的行业话题或者身边有经验丰富、适合来直播间做主题分享的专家老师欢迎添加社区管理员。我们会认真汇总每一条建议持续策划更优质的内容力求为大家带来更多贴近实战的干货。期待你的声音也期待更多精彩内容在社区发生~