智能座舱的影分身术:Hypervisor(一)

智能座舱的影分身术:Hypervisor(一)

首页冒险解谜跳跃的堆栈自行车更新时间:2024-08-03

本文主要分析了Hypervisor的主要概念、可靠程度以及在智能座舱中的应用。

第一次接触Hypervisor大约是2003年左右,在Linux上通过VMware运行Windows;2007年在联想花了一个月研究Xen/KVM在服务端的应用,再往后几年放弃了Linux桌面。

离开了研发团队就再也没有了同时运行多个系统的需求,虚拟化技术被抛到脑后,看到Hypervisor在终端设备上的应用,我第一反应是虚拟化还可以这么玩!

为了便于大家理解这个概念,我再举个不准确的例子。

一个计算机假设有10亿个计算单元,每次执行任务时只能只有1亿个被用到,这时我们可以假设这个1计算机是10个计算机。这10个计算机可以同时做不同的事,比如一台运行财务用、一台运行开发用,但两用户互不影响。这种利用空闲资源的各种办法就叫虚拟化(Hypervisor)。

用于互联网用户而言,现在我们每时每刻都在使用基于Hypervisor的互联网云服务。云服务使用虚拟化技术的核心目的是可以动态分配资源,可以有效利用空闲资源。相当于自行车的分时租赁,每个人都交了押金,但自行车依然闲置,上下班的时候根据使用情况再调度。先简单的理解为有隔离计算能力的分时复用吧。

与云平台商业化运作的不同,车辆中虚拟化产品面对的不是动态的用户,而是各种相对固定的计算任务。算力分配在产品出厂前就已经固定,算力即不会过度闲置,也不会过度紧张,也不会动态调配,更不存在利用闲置资源进行商业变现的机会。

在汽车电子电气系统中,不同的功能单元需要不同的服务、有不同的优先级、有不同的计算安全冗余而存在。特别是需要将各种计算单元进行整合、算力共享,最终通过Hypervisor来完成降低成本。相当于以前我买五六个大件ECU,现在只需要一个,省去了大量的线束、接插件、多次生产、多次研发、多次测试的成本,减轻了车身整体重量。

未来域乐域控制器、自动驾驶域控制器、中央计算机里面都可能会使用Hypervisor技术。汽车行业对于有逼格的东西一向抱有着警惕的眼神的,Hypervisor这个很少会被翻译成中文的名称,背后就隐藏着满满的逼格,比Superman还要高一个档次。

幸好汽车行业对能省钱的东西还是喜欢的紧(考虑到自己有很长一段时间没有上手具体技术,我尽量对与技术相关的内容作价值分析,但实在看不懂相关技术,请直接跳到最后点打赏或在看)。

一、Hypervisor的主要概念

虚拟机(Hypervisor/Virtual Machine)是在同一硬件机器上,允许运行多个相互隔离的不同系统的软件技术。

虚拟化对隐藏了真实的计算机硬件,可以自已模拟成为另一种计算平台(为了更直观,大家看一下在Mac OS上运行Windows,来自parallels官网)。

1. 虚拟化的分类

  1. 应用程序的虚拟化:比如JAVA VM,其本质是对二进制的转换;
  2. 操作系统的虚拟化:比如容器/Docker技术,其本质利用对特定进程可用的算力、存储、IO资源的管理,几乎没有额外系统开销,在云服务中使用较多;
  3. 硬件虚拟化:比如Xen,KVM,对算力及IO的影响小,额外开销成本少。KVM是目前云计算虚拟化的主力。

虚拟化的TYPE-1与TYPE-2

对于最新的Hypervisor技术。无论TYPE1类型还是TYPE2类型,都可以采用硬件辅助加速功能。在汽车领域,由于算力限制、实时性要求高,多数据情况会使用硬件虚拟化技术,即TYPE1。

2. 硬件虚拟化的思路与方案

PV和FV都是用来描述设备被虚拟/模拟的程度,PT是直接使用物理设备,未进行虚拟化。

为什么我们使用虚拟化支持?是因为大多数的设备不支持并发性的访问。

为了并发访问设备,全虚拟化的设备将被完全仿真(所有功能),所有操作系统都不能直接访问该物理设备,所有的操作都要通过虚化监管程序协助执行,效率明显较低。

PV通过抽象理想的物理设备,采用分离设备驱动模型的方式,该模型将设备驱动分为前端驱动,后端驱动,其中前端驱动运行在guest os中,而后端驱动运行在hypervisor中,前端通过共享内存的方式交换数据,来提高效率。

通常半虚拟化性能通常高于全虚拟化,其性能非常接近设备的物理性能。常用用于PV的框架有VirtIO,来标准化半虚拟设备。

考虑到传统虚拟化技术中共享物理平台的I/O效率低下,在有足够I/O硬件可用的情况下,通过将I/O物理设备直接分配给虚拟机,虚拟机监视器不再干涉其访问独占的I/O物理设备,我们将这种方式称之为Pass Through(PT)。

PT模式,可以利用使用最新的驱动,充分发挥新硬件的功能;PV、FV面向新设备时,除了额外开销,都存在驱动更新问题。

同时如果硬件本身支持并发访问的话,XEN可借助件硬辅助虚拟化进一步减少虚拟化负责,增强虚拟化性能。

3. 支持硬件虚拟化的CPU

硬件虚拟化技术依赖于CPU与GPU等硬件设备的支持。X86架构世界的虚拟化在Intel与AMD的配合下高度一下,选择多样。

但是根据《智能座舱选择怎么样的SOC算力?》我们知道:汽车领域SOC都是ARM架构,ARM对虚拟化支持如何?

在2011年开始ARM v7-A和ARM v8-A体系结构包括可选的虚拟化扩展。

4. 汽车界虚拟化的软件

针对ARM架构,Xen是一款即支持半虚拟化,又支持全虚拟化的虚拟化软件。

可以使用ARM 硬件虚拟化扩展,支持全虚拟化方式运行,操作系统可以使用真实的设备驱动与真实的虚拟硬件直接通信,尽可能减少使用Hypervisor接口调用中仿真操作带来的开销。

除了Xen之外,还有Opensynergy、ACRN Hypervisor、Global Hypervisor、Mentor Hypervisor、QNXHypervisor、Redbend Hyeprvisor。

但目前真正有量产车型的虚拟机好象只有QNX的Hypervisor,它是目前市场上唯一被认可功能安全等级达到ASIL D级。

5. 支持GPU的虚拟化

进行虚拟化为是了串行硬件设备的复用,并行处理。与CPU的串行模型完全不同,GPU是并行编程模型。为了使用GPU的能力,我们通常使用OPEN GL、OpenCL或者GPU自身支持API来进行图形应用的开发。

GPU虚拟化方案常有以下三种模式(类似于CPU):

PowerVR的GPU虚拟化是完整的硬件虚拟化解决方案,其中每个Guest OS都有完整的驱动程序堆栈,并可以直接向GPU提交任务硬件。该解决方案不需要用于任务提交的管理程序干预,导致最大的利用率可用的GPU资源。 PowerVR GPU最多可以支持八个虚拟机,每个操作系统可以是独立并行运行。

(Mail和Adreno的虚拟化资料我没有怎么查,不了解情况。)

二、Hypervisor靠谱吗

听到虚拟机大家可能首先想到的是被人多有诟病的JAVA虚拟机,因为执行过程中存在二进制解释过程,速度慢是其带自带属性。

车载硬件算力受限,大家也没有见过哪个手机运行过虚拟机,Hypervisor速度是不是会对计算机的性能带来很大的影响?对于新技术应该认真思考是不是靠谱,即不自大也不盲从。

车载硬件算力受限,类似大家也没有见过手机运行过虚拟机,Hypervisor速度是不是会对计算机的性能带来很大的影响?

答:不会的。

汽车产品的虚拟化一般指的是硬件虚化化技术,开销较小,通过CPU负载不超过2%,DDR小于20MB,EMMC小于50MB。大数的Hypervisor技术代码量在3万行以内,Xen的代量较大在30万量级。

既然在云服务中虚拟化技术已经被广泛的使用,那是不是说在终端产品的中使用很成熟?

答:不是的。

首先,云服务和终端产品采用Hypervisor技术的需求与目的完全不同;其次,ARM的指令集、异构运算、能耗管理不同;再次汽车功能安全要求标准不同;最后虚拟化技术在汽车领域还没有进行过大规模的量产应用。

虚拟化技术可以省多少成本?

答:理论上来讲可以降本。

从产品设计的角度来说,能降多少成本的关键在于能将多少个分布式ECU整合到域控制器中。需要进行综合衡量。

但是由于目前主要主要使用的是QNX Hypervisor QNX仪表 Kanzi的组合,从入门费、席位费、服务费、授权费到其他开发成本,以及有效的技术支持,从短期来看单台成本降低可能没有想的那么大,但综合来看还是值得的。

三、Hypervisor在智能座舱中的应用

Hypervisor的复杂性与影响因子很多,为什么还要在智能座舱中使用Hypervisor技术。

因为降本需求,在单个SOC上运行多个不同安全级别的操作系统最便宜(当然不是因为车内屏幕数量的增加)。

在智能座舱的想象中,假定我们运行四个系统,仪表是安全ASIL B,信息娱乐系统是ASIL QM,L0-L2级的ADAS属于ASILB或C、以及HUD系统。

这意味着我们可能需要运行三个或者四个不同的系统(仪表和HUD可能会共用一个系统,该系统支持分屏幕输出)。

作者:updatedb;公众号:强哥的面包屑 / MyCrumbs。

本文由 @updatedb 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

查看全文
大家还看了
也许喜欢
更多游戏

Copyright © 2024 妖气游戏网 www.17u1u.com All Rights Reserved