智能座艙的影分身術:Hypervisor(一)
本文主要分析了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. 虛擬化的分類
- 應用程序的虛擬化:比如JAVA VM,其本質是對二進制的轉換;
- 操作系統的虛擬化:比如容器/Docker技術,其本質利用對特定進程可用的算力、存儲、IO資源的管理,幾乎沒有額外系統開銷,在云服務中使用較多;
- 硬件虛擬化:比如Xen,KVM,對算力及IO的影響小,額外開銷成本少。KVM是目前云計算虛擬化的主力。
虛擬化的TYPE-1與TYPE-2
- TYPE1類型的虛擬機,直接運行的硬件基礎上,比如XEN。
- TYPE2類型的虛擬機,是在完整的OS上進行上進行,比如KVM。
對于最新的Hypervisor技術。無論TYPE1類型還是TYPE2類型,都可以采用硬件輔助加速功能。在汽車領域,由于算力限制、實時性要求高,多數據情況會使用硬件虛擬化技術,即TYPE1。
2. 硬件虛擬化的思路與方案
- 全虛擬化(Full-Virtualized):依賴硬件虛擬化技術,不需要修改被虛擬系統的內核。
- 半虛擬化(Para-Virtualized):不依賴硬件虛擬化技術,需要修改被虛擬系統的內核。
- 透傳(Pass Through):直接使用物理設備,不經過虛擬監管程序。
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協議
- 目前還沒評論,等你發揮!