軟件定義汽車：將無處不在的虛擬機以及國產虛擬機分析

軟件定義汽車對應中央服務器計算架構，即Zonal架構，在此架構下，虛擬機將無處不在。軟件定義汽車的實現離不開中央服務器計算架構，這與IT領域的云計算非常相似，云簡而言之就是將IT資源服務化。過去辦公場景中我們每人一臺PC，擁有獨立的IT資源，而云可以將IT資源按需分配給需要的租戶，實現按需、彈性拓展。以前每人一臺PC，現在大家共享一臺超級PC，按需訪問，不用時，資源自動釋放，可供其他用戶使用，這樣資源得以最大化利用，且可以按需擴展，及時滿足使用需求。

在汽車領域，每人一臺PC就是每一個分布式ECU，超級PC就是超級SoC芯片，典型如英偉達的Thor，高通的SA8775以及聯(lián)發(fā)科最新的3納米車載芯片（型號可能會是MT8678），云計算的網絡通信在汽車領域就是車載以太網以及車載以太網協(xié)議棧標準TSN。

中央服務器架構和云計算一樣離不開虛擬機。英偉達的Thor，高通的SA8795以及聯(lián)發(fā)科最新的3納米車載芯片（型號可能會是MT8678）的出現，讓車載算力幾乎與目前主流的PC差不多，汽車電子底層硬件不再是由單一芯片提供簡單的邏輯計算，而是多核 SoC 芯片提供更為復雜控制邏輯以及強大的算力支持。但是汽車領域業(yè)務具有不同的技術需求，比如座艙域 IVI 業(yè)務強調交互體驗、應用生態(tài)豐富，比較適合的操作系統(tǒng)是 Android；儀表盤、輔助駕駛有實時性、可靠性要求，操作系統(tǒng)傾向于 RTLinux、RTOS；智駕域強調大算力融合感知、推演規(guī)劃，也有實時性、可靠性要求，也會選擇 RTLinux、RTOS。在域融合的同時，要保證關鍵業(yè)務的安全可靠，也要考慮應用生態(tài)的可持續(xù)性兼容，這就需要有資源隔離技術來支撐在同一 SOC 上切分資源，可并發(fā)運行多種操作系統(tǒng)，保障互不干擾。

資源隔離技術有多種，從硬件底層逐層向上包括硬件隔離、虛擬化隔離、容器隔離、進程隔離等。硬件隔離的隔離性最好，單隔離域的性能、安全可靠性最好，但靈活性、可配置性差，不能實現硬件共享，導致整個系統(tǒng)的資源利用率差，成本居高不下，不能充分達到軟件定義汽車的目標。

再有就是現在的先進SoC包含多種運算資源，如DSP、NPU、CPU、GPU等（因此也稱之為HPC，異構計算），不同域需要不同的運算資源，這顯然需要資源共享。容器隔離、進程隔離可以更輕量級地實現業(yè)務隔離，但還是在同一個操作系統(tǒng)內，存在著資源干擾、相互安全攻擊的隱患，并且無法支持異構操作系統(tǒng)業(yè)務域融合，影響傳統(tǒng)業(yè)務繼承，不利于生態(tài)發(fā)展。在眾多的資源隔離技術中，虛擬化是安全可靠、彈性靈活的優(yōu)選方案，是軟件定義汽車的重要支撐技術。

Hypervisor 直譯即 “超級監(jiān)督者” ，也稱為虛擬機監(jiān)控程序（VMM）。Hypervisor處于SoC硬件平臺之上，將實體資源（如 CPU、內存、存儲空間、網絡適配器、外設等 ) 轉換為虛擬資源，按需分配給每個虛擬機，允許它們獨立地訪問已授權的虛擬資源。Hypervisor實現了硬件資源的整合和隔離，使應用程序既能共享 CPU 等物理硬件，也能依托不同的內核環(huán)境和驅動運行，從而滿足汽車領域多元化應用場景需求。

Hypervisor 可以劃分為兩大類：

一類是 Type1 裸機型，Hypervisor 直接運行在硬件設備上的，也叫做 Bare-Metal Hardware Virtualization（裸金屬虛擬化環(huán)境）；

一類是 Type2 主機托管型，也叫做 Hosted Virtualization （主機虛擬化環(huán)境）。

Type2 型 Hypervisor 需要借助宿主操作系統(tǒng)來管理 CPU、內存、網絡等資源，由于 Hypervisor 和硬件之間存在一個宿主操作系統(tǒng)，Hypervisor 及 VM 的所有操作都要經過宿主操作系統(tǒng)，所以就不可避免地會存在延遲、性能損耗，同時宿主操作系統(tǒng)的安全缺陷及穩(wěn)定性問題都會影響到運行在之上的VM（虛擬機），所以 ,Type2型 Hypervisor 主要用于對性能和安全要求不高的場合，比如 : 個人 PC 系統(tǒng)。

Type1 型的 Hypervisor 不依賴主機操作系統(tǒng)，其自身具備操作系統(tǒng)的基礎功能。設計上更為簡潔，直接運行于硬件之上，整體代碼量和架構更為精簡，對內存和存儲資源要求更少，可滿足自動駕駛系統(tǒng)功能安全等級要求，也具備進行形式化驗證的條件。所以汽車操作系統(tǒng)更適合使用 Type 1 型 Hypervisor。

隨著微內核操作系統(tǒng)技術的發(fā)展，很多基于微內核操作系統(tǒng)設計的Hypervisor 依賴的 Host OS 已經非常精簡，只包括基本的、不變的功能，如 : CPU 調度和內存管理，設備驅動和其他可變組件處于內核之外，這類Hypervisor 應當歸于 Type1、還是 Type2，業(yè)內存在分歧，但絕大多數都自稱Type1，因為都知道Type1是高大上的。

典型的基于HPC的汽車軟件架構

圖片來源：大陸汽車

從SoC角度看中間件，虛擬機和BSP是一體的，BPU指的就是AI運算。圖片來源：大陸汽車

圖片來源：Elektrobit

從軟件通訊的角度看虛擬機的位置，虛擬機主要是基于以太網硬件之上，未來虛擬機可以在SoC上，也可以在以太網交換機上。

Vector PREE 9.5版本上的虛擬機

圖片來源：Elektrobit

顯然，每個提供自適應AUTOSAR的廠家都需要自己研發(fā)一套虛擬機，VECTOR的叫LEAN虛擬機。

博世旗下的ETAS，其虛擬機叫VRTE，也是其自適應AutoSAR產品的一部分。圖片來源：ETAS

德國大陸汽車旗下的EB用的是L4Re微內核虛擬機。圖片來源：KevnKonzept

鑒于汽車的軟件系統(tǒng)異常復雜，這會帶來不小的性能損耗，同時車載算力遠不如PC那樣容易升級，因此虛擬機要盡量地小，輕量化和高效率，車載SoC的CPU算力要盡可能地高。

早期汽車用虛擬機還有考慮XEN，后期基本上都是微內核，這個微內核虛擬機更接近一個虛擬交換機，主要就是I/O。本來微內核的難度頗高，但KVM和OASIS的出現讓微內核虛擬機變得非常容易，一個不到100人的公司也可以在1年內搞出一個微內核。早期的微內核多數是基于UNIX，而近些年來的微內核技術更接近KVM。

KVM（Kernel-based Virtual Machine，基于內核的虛擬機）是一個基于Linux環(huán)境的開源虛擬化解決方案，最早由以色列Qumranet公司開發(fā)，在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內核可以將主機進程和虛擬機進行統(tǒng)一的管理和調度，這也是KVM名稱的由來。當然，這是典型的Type2的虛擬機。問題是微內核嚴格說也是Type2的，這個界限已經變得模糊。

ARM自8.1后，增加了vhe擴展支持，使得hostos和hypervisor都可以運行在EL2下。此時它們之間可以直接通過函數的方式實現功能調用，因此其效率已經與Type1hypervisor不相上下。而ARM不僅統(tǒng)治了手機領域，也主導了車載領域，你可以不用ARM架構，但ARM指令集，沒有廠家能拒絕。

車載Hypervisor與標準化服務器（x86）+標準化OS（Windows和Linux）的云虛擬化應用場景不同，汽車嵌入式環(huán)境中的虛擬化技術面臨的挑戰(zhàn)是Hypervisor往往需要定制適配底層SoC硬件和上層OS軟件，這一點對于Hypervisor的大規(guī)模商用與普及是一個非常大的技術障礙。

2016年3月，OASIS（Organizationfor the Advancement of Structured Information Standards，結構化信息標準促進組織）正式標準化VirtIO項目，旨在提供一種通用的框架和標準接口，減少Hypervisor對底層不同硬件和上層不同軟件的適配開發(fā)工作量。很快VirtIO標準得到了眾多科技巨頭的支持，包括Apple、Google、ARM、Intel、Red Hat、華為等。Google也在AndroidAutomotive OS中集成對VirtIO的支持。

VirtIO是一套易維護和易擴展的通用設備仿真接口，由前端驅動程序（Front-End Driver）、后端驅動程序（Back-End Driver）和VirtIO虛擬隊列（Virtual Queue）構成。前端驅動程序由Guest OS實現，后端驅動程序由Hypervisor實現，虛擬隊列通常使用環(huán)形緩沖，在Hypervisor和Guest OS之間傳輸數據，每個驅動可以有0個或多個隊列，取決于實際需要。

回到目前虛擬機最常用的座艙領域，智能座艙域融合也是在近幾年啟動，正持續(xù)迭代演進。NXP和芯馳科技采用了硬隔離方案來實現域融合，一方面最大程度地沿用既有技術能力，有確定性保障，但缺少了軟件定義的靈活性，智能化程度有限，是域融合的一種可選方案。

在嵌入式虛擬化技術方面，國外的 QNX、OpenSynergy、PikeOS 等有先發(fā)優(yōu)勢，尤其在汽車領域已耕耘多年的QNX，在這兩年涌現了較多的QNX應用案例。隨著KVM和VirtIO的出現，虛擬機門檻大大降低，國內這幾年也出現了不少芯片廠商、獨立軟件廠商研發(fā)嵌入式虛擬化技術、產品、解決方案，如中瓴智行的 RAITE Hypervisor(RHOS)、中興 GoldenOS、斑馬智行的 AliOS Hypervisor、中汽創(chuàng)智 CAIC Hypervisor 等。國產化方案芯馳 X9HP+ 平臺，采用硬分區(qū)、Hypervisor 兩種方案靈活配置實現中低端智能座艙域控制器產品。

中瓴智行的 RAITE Hypervisor(RHOS)

圖片來源：中瓴智行

圖片來源：中瓴智行

中瓴智行與聯(lián)發(fā)科MT8675緊密合作，據說出貨量已經超過600萬套，可算是國產第一。MT8675 只提供了一個 GPU，座艙域需要在儀表和中控上共享使用 GPU 資源。RHOS 實現了 GPU虛擬化共享，并通過性能優(yōu)化，達到業(yè)界領先的虛擬化效果（損耗 < 6%）。RHOS 支持Suspend to RAM 功能，MT8675 A 核完全下電，滿足智能座艙待機靜態(tài)功耗小于 4mA 要求，對DRAM的消耗也低很多。

對于獨立虛擬機廠家來說，關鍵是SoC的選擇。對車廠或Tier1來說都是先確定SoC，再確定周邊供應商。再有就是像高通這樣的大廠會推薦同樣體量的軟件合作伙伴如QNX，提供完整的服務，但獨立性就差點。對于國內獨立的虛擬機廠家來說，恐怕很難讓高通滿意，因此最好的合作伙伴是聯(lián)發(fā)科。

對于QNX來說，有些麻煩，QNX的確是目前唯一一個能達到ASIL-D等級的操作系統(tǒng)（包含Hypervisor）。但如果需要實現ASIL-D級別的系統(tǒng)，必須把現有的軟件從Linux系統(tǒng)都移植到QNX。雖然QNX也是符合POSIX標準的，但是移植起來還是非常麻煩，最關鍵的是這些移植過去的驅動，其實是沒有安全等級的，畢竟它根基還是LINUX。換句話說，要想做到真正的ASIL-D，那么一開始就必須以QNX為基礎開發(fā)。

虛擬機門檻的降低對獨立軟件廠家非常有益處，但也有些隱憂，比如比亞迪此類大廠，就會內部研發(fā)虛擬機。不過比亞迪這樣垂直供應鏈的廠家國內僅此一家，對獨立軟件廠家來說市場空間還是越來越大。

審核編輯 ：李倩