舱驾融合的关键—Hypervisor-EDN 电子技术设计

 近几年涌入车载Hypervisor领域的玩家非常多，也以巨头为主，那么什么是Hypervisor呢？

jZ3ednc

喊出一句架构升级的口号，给新架构取个响亮的名字，隔三差五在媒体面前吹嘘一番，似乎是近几年主机厂乐此不疲的事情。具不具备自动驾驶能力，外界可以通过对产品360°路测进行一个直观的评价。但架构升级成果如何，更像是大家族兄弟姐妹间争夺家产的私家事，表面上一片祥和，背地里暗流涌动。外人也只能从家丁、护院、婢女的口中听闻些许八卦。

笔者刚好也从坊间听闻了这样一则八卦，热衷于架构升级的某主机厂，花了几十亿，历经四五年，从分布式架构升级到域架构。熬到首台车量产时，一位多事的员工细数域架构内的ECU数量，惊讶的发现原来ECU员工编制一个没少，反而多出了几个域控制器领导编制。说好了的融合，新增的域控制器领导也仅是承担了替代ECU的职责以及整车新增的部分需求。这与分布式架构下，新增需求升级/新增ECU似乎并无两异。

踩坑的先行者们，开始逐渐清醒，BOSCH学院派的架构演进路线上的域架构作为一种过渡状态，似乎并不是那么美丽，有点类似自动驾驶领域的SAE L3自动驾驶，看起来容易做起来难。于是乎，这部分先行者又着急地喊出了一步到位中央集中式架构的口号，像极了前两年自动驾驶公司集体放弃SAE L3，进攻SAE L4的景象。

从几家宣传的中央集中式架构方案中，智能座舱和自动驾驶相关功能将集中到一个高性能计算单元上，并跑在在一颗SOC上，主动安全及功能降级策略放在另外一颗安全MCU上执行。上海嘉定创新港内喊出的“银河全栈3.0”中央集中式方案便是由两个高性能计算单元（HPC1和HPC2）和四个区域控制器构成（Zone1~4）。其中HPC1便负责智能座舱、自动驾驶的功能，HPC2部分职责是承担自动驾驶备份控制作用。

在这种中央集中式架构下，意味着一个SOC上将同时运行智能座舱和自动驾驶等功能。而智能座舱和自动驾驶功能不论是在功能安全、信息安全、实时性还是算力需求层面都有不小的差异，且这些功能目前都是用不同的操作系统（Linux、QNX、Android、RTOS等）去实现。如果汽车行业统一的操作系统不能尽快诞生（目测也不会诞生），那么一颗SOC上如何部署多个不同的操作系统，成为中央集中式架构必须直面的问题。

还好这个问题，互联网领域曾经遇到过，并且已经成熟应用，可以说是超级奶爸一般的存在。汽车领域仅在智能座舱域得到过成功应用，妥妥的新上门女婿。自动驾驶圈黑话第二十期，作者就和大家一起讨论下这位在汽车行业崭露头角，并有希望解决舱驾融合过程痛点的虚拟化关键技术—Hypervisor。

什么是Hypervisor

要回答“什么是Hypervisor”,我们不得不扒一扒其在互联网领域成名的黑历史。

早些年，如果某家公司想搭建邮件系统和文档管理两个应用，则需要购买两台服务器，每台服务器运行一个应用。这个时候每个服务器性能刚好够每个应用挥霍，应用在物理上又完全隔离，互不干扰，一派祥和。但在摩尔定律的见证下，服务器性能基本上每两年翻一番，单位计算能力的成本却在不断下降。在某个时间点，便出现了这样一个甜蜜的烦恼，我在市面上能买到的最低配置的服务器性能也够我的两个应用同时使用。

如果两个应用装在一台服务器上，不但资源调用可能发生冲突，维护起来也很麻烦。但是如果我买两台服务器的话，性能浪费上像极了大炮打蚊子，金钱浪费上像极了地主家的傻儿子。如何解决一台服务器运行多个相互隔离的不同操作系统应用的问题，成为了摆在互联网发展道路上的巨大障碍。

但在互联网领域前辈前赴后继的努力下，终于找到了克服障碍的方案：虚拟化技术。通过虚拟化技术，可以在一台物理服务器上模拟出多个具有完整硬件配置并运行在完全隔离环境中的计算机系统。这个模拟的计算机系统也就是我们平时亲切称呼的虚拟机（VM，Virtual Machine）。

汽车领域开发工程师对虚拟化技术多少都有过接触。如果你是一名车联网JAVA开发工程师，那么你肯定用过JAVA VM，这是一种应用程序虚拟化技术；如果你是一名自动驾驶集成开发工程师，那么你应该会和Docker相爱相杀过，这是一种操作系统虚拟化技术；如果你是一名大数据平台开发工程师，那么KVM似乎是你绕不过去的坎，这是一种硬件虚拟化技术。

但是谁去负责虚拟机的虚拟资源和物理硬件之间的转换工作，谁去负责虚拟机的创建、删除、配置呢，这便是本文主角Hypervisor的职责,中文直译就是“超级监督者”，一类具有此类职责软件的总称。

Hypervisor将全面接管物理服务器的CPU、内存、硬盘、网卡等硬件资源，并把他们抽象成逻辑资源池，并按需分配给每个虚拟机。通过Hypervisor的这一番神奇操作，每个虚拟机都能独立使用自己的虚拟CPU，内存，硬盘，网卡等硬件资源。

互联网领域常用的Hypervisor类型主要有两种，Type 1（裸机类型）和Type 2（寄居类型），如下图所示。

在Type 1中，Hypervisor直接运行在物理硬件之上，向下直接管理所有硬件资源，向上通过Hypervisor创建多个虚拟机，在虚拟机上安装操作系统及部署应用；

在Type 2中，物理硬件上先安装一层操作系统，利用操作系统管理所有硬件资源，操作系统上再安装Hypervisor，后面操作同Type 1。（如果你有过在Windows电脑安装虚拟机，然后在虚拟机上安装Linux操作系统经历的话，那么你对Type 2的印象肯定刻骨铭心。）

Type 1类型的Hypervisor直接运行在物理硬件之上，直接访问物理硬件并管理所有硬件资源，在延时、安全性和效率上更胜一筹。但此类型Hypervisor需要硬件支持，移植难度大，开发成本也较高，在互联网领域常用于数据计算中心。

Type 2类型的Hypervisor运行在某个操作系统之上，利用操作系统访问物理硬件，因此在延时方面具有不可避免的劣势。且底层操作系统的任何Bug都将危及其上的虚拟机，因此安全性方面相对较弱。但是移植难度小，开发成本低。在互联网领域常用于客户端系统。

在汽车领域，由于变态的实时性及安全性要求，目前主流选择Type 1方案。Hypervisor除了上文提到的硬件资源分配功能，还具有如下功能。

（1）设备模拟。Hypervisor可以创建客户操作系统可以访问的一些虚拟硬件组件，是否需要取决于客户操作系统上运行的应用程序；

（2）内存管理。Hypervisor负责为自身和客户操作系统管理和分配硬件内存资源；

（3）设备分配和访问。Hypervisor通常可以将硬件组件分配给客户操作系统，并控制客户操作系统实际可以访问哪些硬件组件；

（4）上下文切换。当Hypervisor需要在内核上安排新的客户操作系统时，Hypervisor必须通过将在该处理器内核上运行的现有客户操作系统的“上下文”（即操作条件）保存到内存中来“切换上下文”。然后进行加载新的客户操作系统时，可以从内存中访问新的客户操作系统，而不会中断执行环境；

（5）捕获指令。客户操作系统可能会根据其访问权限级别执行技术上不应执行的指令。Hypervisor可以分析客户操作系统尝试发送到硬件的指令，并模拟硬件对客户操作系统指令的响应；

（6）异常处理。发生异常（即异常行为）时，可以将某些异常路由到Hypervisor进行处理；

（7）虚拟机管理。如前所述，Hypervisor最终负责启动和停止客户操作系统在其上运行的虚拟机。

汽车领域为什么会拥抱Hypervisor

在汽车电子电气架构处于分布式的时代，每个ECU负责一个功能，可以说各司其职，泾渭分明，路不拾遗。但是自从BOSCH公开了其电子电气架构演进的内功心法后，江湖便掀起了内卷潮，各自闭门修炼，以期早日取Bosch而代之。

这个心法口诀的核心就是：分久必合。而在这个时间点，正是域融合称王，分布式退位的阶段。暂不表文章开头隐喻的升级域架构的辛酸苦楚，只提在融合中涌现出来的一位优秀代表—座舱域，这也是Hypervisor目前为止在汽车领域攻下的第一城和唯一一城。

在矛盾的重点转移到满足人民群众日益增长的精神需求之后，座舱内便热闹了起来。中控大屏、液晶仪表、抬头显示、行车记录仪，流媒体后视镜，后排娱乐系统等悉数登场，整个座舱内俨然成为屏幕家族狂欢的舞台。如果按照分布式电子电气架构的思路，每新增一个大的功能新增一个零件，别说主机厂成本上能不能接受，狭隘的空间内如何布置这些控制器问题都够主机厂布置工程师喝几壶。

在域融合心法的指引下，既然大家都是初来乍到，又没有把柄被巨头Tier1抓住，那么座舱内各种大屏走向联合是合乎发展规律的事情。并在联盟中挑选出一位德才兼备的盟主—智能座舱域控制器，负责联盟内外事务。

盟主刚上位，就面对一个棘手的问题。液晶仪表/抬头显示负责的部分功能与动力系统、辅助驾驶系统强关联，具有较高的实时性、安全性要求，因此多以安全实时的操作系统QNX为主。而中控大屏/行车记录仪/后排娱乐系统主要提供娱乐、导航、车辆控制等多样化功能，对丰富的生态资源和信息安全有较高的要求，因此多以生态丰富的Android和Linux操作系统为主。

盟主想到了两种方案，一种方案自己修炼影分身之术，也就是在一个座舱域控制器中放置两颗MCU芯片。一颗芯片装QNX操作系统跑仪表相关功能，一颗芯片装Android或Linux操作系统跑大屏相关功能。两颗芯片通过外围串行接口相连并进行通信。这是一种形态上的融合，各单元依然独立地完成各自任务，因此功能边界非常清晰。但是每个芯片都需要一个最小系统，不仅浪费硬件资源，还没法实现硬件资源拓展。且信号在多个芯片之间进出带来的延迟而导致的性能局限，都将是此种方式挥之不去的噩梦。

此种融合方案的带头大哥便是Tesla，其区域架构方案也一直是各家模仿的对象。整个架构包括一个中央计算单元和三个区域控制器，中央计算单元负责ADAS/ADS功能、信息娱乐功能和网络通信功能。Tesla将实现ADAS/AD功能的FSD芯片，实现信息娱乐功能的MCU芯片，实现网络通信功能的模组集成在一个电路板上，并采用一套液冷系统。每个芯片独立运行各自的操作系统并独立完成各自的任务，外界一般称其为“准中央集中式架构”。但笔者特别想说，没有Tesla的命，别去模仿Tesla。

另外一种方案是盟主雇个专业的经理人，帮自己打点底下的小兄弟，也就是业界比较认可的终极融合方案“一芯多屏”，即是一颗芯片，跑多个操作系统，从而支持仪表、抬头显示和各种大屏的功能，同时满足各个应用对实时性、可靠性、安全性等的不同要求。这时上文提到的互联网领域成熟应用的虚拟化和Hypervisor技术便自然而然的吸引了汽车大佬们的目光，并成功上演了一段跨界姻缘。

虚拟化和Hypervisor在座舱域的成功应用，给了电子电气架构不断融合下去的勇气和信心。尤其是到了中央集中式架构阶段，整车可能就剩下一台高性能中央计算单元。而这台高性能中央计算单元，既要实现智能座舱功能，又要实现自动驾驶功能。而这些功能的差异更加明显，所需支持的操作系统类型也更加丰富。

而Hypervisor的到来，物理硬件层面，可以根据功能需求自由分配每个操作系统所需的资源，充分而又灵活地利用高性能的SOC的高超运算能力。功能实现层面，还可按照不同主机厂的需求灵活搭载各种不同的操作系统组合，并运行具有不同算力要求、不同功能安全等级，不同信息安全等级、不同实时性要求的软件。

车载Hypervisor的技术要求

Hypervisor虽在互联网领域大放异彩，但汽车领域的特殊性，决定了不可能完全照搬互联网的成熟经验。Hypervisor在汽车领域适配的过程中，必须正视和尊重以下和互联网领域的差别：

（1）物理硬件层面。互联网的集群服务器模式，可以让其拥有灵活可扩展的高计算能力和大存储能力，Hypervisor完全不用操心自己需要消耗多少计算和存储资源的问题。而在成本极其敏感的汽车领域，不管是当下的域控制器还是后面的高性能中央计算单元中的主芯片，其计算能力和存储能力就显得捉襟见肘。降低CPU占用、AI算力消耗和存储需求将会是贯穿整车项目开发始终的工作。Hypervisor自身的轻量化能力，成为衡量其能否在汽车领域大规模应用的一个关键指标；

（2）安全冗余层面。互联网领域面对的是动态的用户任务，互联网大佬期望Hypervisor可以动态分配物理硬件资源，有效利用闲置资源，从而实现降本增效的作用；汽车领域面对的是相对固定的用户计算任务，任务所需硬件资源在出厂前已由工程师设计分配好。汽车大佬们期望Hypervisor在实时性、可靠性、安全性等方面可以更加出众；

（3）适配开发层面。在汽车领域，MCU/MPU/SOC类型丰富的你无法想象，操作系统多的也让你数不胜数，如何减少Hypervisor在适配底层不同硬件和上层不同操作系统的工作量，是横亘在Hypervisor面前的另外一座高山。

汽车领域和互联网领域的差别，决定了Hypervisor要想在汽车领域继续攻城拔寨，必须继续修炼直至拥有如下能力：

（1）安全冗余层面。Hypervisor必须具备通过资源分区技术严格隔离和分配资源的能力。当一个虚拟机中的应用程序出现故障时，只可以影响分配给它的内存，而不会影响其它虚拟机的内存池。当然前提是开发人员提前规划好应用的内存需求。

（2）通用开发框架层面。汽车领域需要一种权威的Hypervisor通用框架和标准接口，以减少适配底层不同硬件和上层不同操作系统时的开发工作量。目前VirtIO标准已得到汽车行业一众巨头的支持，未来有希望脱颖而出，实现大一统；

（3）任务调度机制。汽车领域存在大量实时任务和非实时任务，而这两种系统对于任务的时间响应要求有着本质的不同。Hypervisor应该具备灵活的时间调度机制，既能支持基于优先级的任务调度方式，又能支持基于时间片的任务调度方式；

（4）进程间通信机制。Hypervisor在对虚拟机进行严格安全隔离的同时，也需要支持不同虚拟机进程之间以受控方式进行相互通信。而最基本的进程间通信包括同步消息传递和共享内存两种方式。

车载主流Hypervisor产品介绍

近几年涌入车载Hypervisor领域的玩家非常多，也以巨头为主，包括Xen Hypervisor，OpenSynergy、ACRN Hypervisor、Global Hypervisor、Mentor Hypervisor、QNX Hypervisor、Redbend Hyeprvisor等。但非常遗憾的是，QNX Hypervisor是目前唯一应用到量产车型的Hypervisor，它也是目前市场上唯一一个功能安全等级达到ASIL D级的虚拟化操作系统。由此也可见Hypervisor的开发难度。

下面挑选三款比较有代表性的Hypervisor产品进行简单对比。

小结

“兵马未动、粮草先行”这是多少鲜血总结出来的经验。一时的落地除了收割韭菜，似乎对社会不会有大的促进。而储备好粮草的长期落地，才是收获广大群众感情的更有效方案。而在架构升级，自动驾驶领域，我们的粮草就是关键基础技术的攻坚，关键基础技术的突破。

责编：Lefeng

文章来源及版权属于汽车电子与软件，EDN电子技术设计仅作转载分享，对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。如有疑问，请联系Demi.xia@aspencore.com

阅读全文，请先

汽车电子与软件

进入专栏

上一篇： 鸿光盛业推出180W电源解决方案，笔电、储能电源多领域适用 下一篇： 智能汽车中毫米波雷达的应用和未来趋势

微信扫一扫
一键转发
最前沿的电子设计资讯
请关注“电子技术设计微信公众号”

热门评论
最新评论

换一换

杂志声明

舱驾融合的关键—Hypervisor