软件定义汽车：将无处不在的虚拟机以及国产虚拟机分析

软件定义汽车对应中央服务器计算架构，即Zonal架构，在此架构下，虚拟机将无处不在。软件定义汽车的实现离不开中央服务器计算架构，这与IT领域的云计算非常相似，云简而言之就是将IT资源服务化。过去办公场景中我们每人一台PC，拥有独立的IT资源，而云可以将IT资源按需分配给需要的租户，实现按需、弹性拓展。以前每人一台PC，现在大家共享一台超级PC，按需访问，不用时，资源自动释放，可供其他用户使用，这样资源得以最大化利用，且可以按需扩展，及时满足使用需求。

在汽车领域，每人一台PC就是每一个分布式ECU，超级PC就是超级SoC芯片，典型如英伟达的Thor，高通的SA8775以及联发科最新的3纳米车载芯片（型号可能会是MT8678），云计算的网络通信在汽车领域就是车载以太网以及车载以太网协议栈标准TSN。

中央服务器架构和云计算一样离不开虚拟机。英伟达的Thor，高通的SA8795以及联发科最新的3纳米车载芯片（型号可能会是MT8678）的出现，让车载算力几乎与目前主流的PC差不多，汽车电子底层硬件不再是由单一芯片提供简单的逻辑计算，而是多核 SoC 芯片提供更为复杂控制逻辑以及强大的算力支持。但是汽车领域业务具有不同的技术需求，比如座舱域 IVI 业务强调交互体验、应用生态丰富，比较适合的操作系统是 Android；仪表盘、辅助驾驶有实时性、可靠性要求，操作系统倾向于 RTLinux、RTOS；智驾域强调大算力融合感知、推演规划，也有实时性、可靠性要求，也会选择 RTLinux、RTOS。在域融合的同时，要保证关键业务的安全可靠，也要考虑应用生态的可持续性兼容，这就需要有资源隔离技术来支撑在同一 SOC 上切分资源，可并发运行多种操作系统，保障互不干扰。

资源隔离技术有多种，从硬件底层逐层向上包括硬件隔离、虚拟化隔离、容器隔离、进程隔离等。硬件隔离的隔离性最好，单隔离域的性能、安全可靠性最好，但灵活性、可配置性差，不能实现硬件共享，导致整个系统的资源利用率差，成本居高不下，不能充分达到软件定义汽车的目标。

再有就是现在的先进SoC包含多种运算资源，如DSP、NPU、CPU、GPU等（因此也称之为HPC，异构计算），不同域需要不同的运算资源，这显然需要资源共享。容器隔离、进程隔离可以更轻量级地实现业务隔离，但还是在同一个操作系统内，存在着资源干扰、相互安全攻击的隐患，并且无法支持异构操作系统业务域融合，影响传统业务继承，不利于生态发展。在众多的资源隔离技术中，虚拟化是安全可靠、弹性灵活的优选方案，是软件定义汽车的重要支撑技术。

Hypervisor 直译即 “超级监督者” ，也称为虚拟机监控程序（VMM）。Hypervisor处于SoC硬件平台之上，将实体资源（如 CPU、内存、存储空间、网络适配器、外设等 ) 转换为虚拟资源，按需分配给每个虚拟机，允许它们独立地访问已授权的虚拟资源。Hypervisor实现了硬件资源的整合和隔离，使应用程序既能共享 CPU 等物理硬件，也能依托不同的内核环境和驱动运行，从而满足汽车领域多元化应用场景需求。

Hypervisor 可以划分为两大类：

一类是 Type1 裸机型，Hypervisor 直接运行在硬件设备上的，也叫做 Bare-Metal Hardware Virtualization（裸金属虚拟化环境）；

一类是 Type2 主机托管型，也叫做 Hosted Virtualization （主机虚拟化环境）。

Type2 型 Hypervisor 需要借助宿主操作系统来管理 CPU、内存、网络等资源，由于 Hypervisor 和硬件之间存在一个宿主操作系统，Hypervisor 及 VM 的所有操作都要经过宿主操作系统，所以就不可避免地会存在延迟、性能损耗，同时宿主操作系统的安全缺陷及稳定性问题都会影响到运行在之上的VM（虚拟机），所以 ,Type2型 Hypervisor 主要用于对性能和安全要求不高的场合，比如 : 个人 PC 系统。

Type1 型的 Hypervisor 不依赖主机操作系统，其自身具备操作系统的基础功能。设计上更为简洁，直接运行于硬件之上，整体代码量和架构更为精简，对内存和存储资源要求更少，可满足自动驾驶系统功能安全等级要求，也具备进行形式化验证的条件。所以汽车操作系统更适合使用 Type 1 型 Hypervisor。

随着微内核操作系统技术的发展，很多基于微内核操作系统设计的Hypervisor 依赖的 Host OS 已经非常精简，只包括基本的、不变的功能，如 : CPU 调度和内存管理，设备驱动和其他可变组件处于内核之外，这类Hypervisor 应当归于 Type1、还是 Type2，业内存在分歧，但绝大多数都自称Type1，因为都知道Type1是高大上的。

典型的基于HPC的汽车软件架构

图片来源：大陆汽车

从SoC角度看中间件，虚拟机和BSP是一体的，BPU指的就是AI运算。图片来源：大陆汽车

图片来源：Elektrobit

从软件通讯的角度看虚拟机的位置，虚拟机主要是基于以太网硬件之上，未来虚拟机可以在SoC上，也可以在以太网交换机上。

Vector PREE 9.5版本上的虚拟机

图片来源：Elektrobit

显然，每个提供自适应AUTOSAR的厂家都需要自己研发一套虚拟机，VECTOR的叫LEAN虚拟机。

博世旗下的ETAS，其虚拟机叫VRTE，也是其自适应AutoSAR产品的一部分。图片来源：ETAS

德国大陆汽车旗下的EB用的是L4Re微内核虚拟机。图片来源：KevnKonzept

鉴于汽车的软件系统异常复杂，这会带来不小的性能损耗，同时车载算力远不如PC那样容易升级，因此虚拟机要尽量地小，轻量化和高效率，车载SoC的CPU算力要尽可能地高。

早期汽车用虚拟机还有考虑XEN，后期基本上都是微内核，这个微内核虚拟机更接近一个虚拟交换机，主要就是I/O。本来微内核的难度颇高，但KVM和OASIS的出现让微内核虚拟机变得非常容易，一个不到100人的公司也可以在1年内搞出一个微内核。早期的微内核多数是基于UNIX，而近些年来的微内核技术更接近KVM。

KVM（Kernel-based Virtual Machine，基于内核的虚拟机）是一个基于Linux环境的开源虚拟化解决方案，最早由以色列Qumranet公司开发，在2006年10月出现在Linux内核的邮件列表上，并于2007年2月被集成到Linux 2.6.20内核中，成为内核的一部分。2008年，Qumranet被RedHat所收购，但KVM本身仍是一个开源项目，由RedHat、IBM等厂商支持。与VMwareESX/ESXi、微软Hyper-V和Xen等虚拟化产品不同，KVM的思想是在Linux内核的基础上添加虚拟机管理模块，重用Linux内核中已经完善的进程调度、内存管理、I/O管理等代码，使之成为一个可以支持运行虚拟机的Hypervisor。因此，KVM并不是一个完整的模拟器，而只是一个提供了虚拟化功能的内核插件，具体的模拟器工作需要借助QEMU来完成。

通过KVM模块的加载将Linux内核转变成Hypervisor，KVM在Linux内核的用户（User）模式和内核（Kernel）模式基础上增加了客户（Guest）模式。Linux本身运行于内核模式，主机进程运行于用户模式，虚拟机则运行于客户模式，使得转变后的Linux内核可以将主机进程和虚拟机进行统一的管理和调度，这也是KVM名称的由来。当然，这是典型的Type2的虚拟机。问题是微内核严格说也是Type2的，这个界限已经变得模糊。

ARM自8.1后，增加了vhe扩展支持，使得hostos和hypervisor都可以运行在EL2下。此时它们之间可以直接通过函数的方式实现功能调用，因此其效率已经与Type1hypervisor不相上下。而ARM不仅统治了手机领域，也主导了车载领域，你可以不用ARM架构，但ARM指令集，没有厂家能拒绝。

车载Hypervisor与标准化服务器（x86）+标准化OS（Windows和Linux）的云虚拟化应用场景不同，汽车嵌入式环境中的虚拟化技术面临的挑战是Hypervisor往往需要定制适配底层SoC硬件和上层OS软件，这一点对于Hypervisor的大规模商用与普及是一个非常大的技术障碍。

2016年3月，OASIS（Organizationfor the Advancement of Structured Information Standards，结构化信息标准促进组织）正式标准化VirtIO项目，旨在提供一种通用的框架和标准接口，减少Hypervisor对底层不同硬件和上层不同软件的适配开发工作量。很快VirtIO标准得到了众多科技巨头的支持，包括Apple、Google、ARM、Intel、Red Hat、华为等。Google也在AndroidAutomotive OS中集成对VirtIO的支持。

VirtIO是一套易维护和易扩展的通用设备仿真接口，由前端驱动程序（Front-End Driver）、后端驱动程序（Back-End Driver）和VirtIO虚拟队列（Virtual Queue）构成。前端驱动程序由Guest OS实现，后端驱动程序由Hypervisor实现，虚拟队列通常使用环形缓冲，在Hypervisor和Guest OS之间传输数据，每个驱动可以有0个或多个队列，取决于实际需要。

回到目前虚拟机最常用的座舱领域，智能座舱域融合也是在近几年启动，正持续迭代演进。NXP和芯驰科技采用了硬隔离方案来实现域融合，一方面最大程度地沿用既有技术能力，有确定性保障，但缺少了软件定义的灵活性，智能化程度有限，是域融合的一种可选方案。

在嵌入式虚拟化技术方面，国外的 QNX、OpenSynergy、PikeOS 等有先发优势，尤其在汽车领域已耕耘多年的QNX，在这两年涌现了较多的QNX应用案例。随着KVM和VirtIO的出现，虚拟机门槛大大降低，国内这几年也出现了不少芯片厂商、独立软件厂商研发嵌入式虚拟化技术、产品、解决方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中兴 GoldenOS、斑马智行的 AliOS Hypervisor、中汽创智 CAIC Hypervisor 等。国产化方案芯驰 X9HP+ 平台，采用硬分区、Hypervisor 两种方案灵活配置实现中低端智能座舱域控制器产品。

中瓴智行的 RAITE Hypervisor(RHOS)

图片来源：中瓴智行

图片来源：中瓴智行

中瓴智行与联发科MT8675紧密合作，据说出货量已经超过600万套，可算是国产第一。MT8675 只提供了一个 GPU，座舱域需要在仪表和中控上共享使用 GPU 资源。RHOS 实现了 GPU虚拟化共享，并通过性能优化，达到业界领先的虚拟化效果（损耗 < 6%）。RHOS 支持Suspend to RAM 功能，MT8675 A 核完全下电，满足智能座舱待机静态功耗小于 4mA 要求，对DRAM的消耗也低很多。

对于独立虚拟机厂家来说，关键是SoC的选择。对车厂或Tier1来说都是先确定SoC，再确定周边供应商。再有就是像高通这样的大厂会推荐同样体量的软件合作伙伴如QNX，提供完整的服务，但独立性就差点。对于国内独立的虚拟机厂家来说，恐怕很难让高通满意，因此最好的合作伙伴是联发科。

对于QNX来说，有些麻烦，QNX的确是目前唯一一个能达到ASIL-D等级的操作系统（包含Hypervisor）。但如果需要实现ASIL-D级别的系统，必须把现有的软件从Linux系统都移植到QNX。虽然QNX也是符合POSIX标准的，但是移植起来还是非常麻烦，最关键的是这些移植过去的驱动，其实是没有安全等级的，毕竟它根基还是LINUX。换句话说，要想做到真正的ASIL-D，那么一开始就必须以QNX为基础开发。

虚拟机门槛的降低对独立软件厂家非常有益处，但也有些隐忧，比如比亚迪此类大厂，就会内部研发虚拟机。不过比亚迪这样垂直供应链的厂家国内仅此一家，对独立软件厂家来说市场空间还是越来越大。

审核编辑 ：李倩