在電子電氣系統(tǒng)架構(gòu)從分布式向域集中式演進的大背景下，各種功能模塊都集中到少數(shù)幾個域控制器中，以前需要N個ECU（Electronic Control Unit，電子控制單元）實現(xiàn)各種功能，現(xiàn)在只需要一個DCU（Domain Control Unit，域控制器），節(jié)省了大量的線束和接插件，減輕了車身整體重量。
但是，在汽車電子電氣系統(tǒng)中，不同的ECU提供不同的服務(wù)，具有不同的優(yōu)先級，對底層操作系統(tǒng)的要求也不一樣。例如，根據(jù)ISO 26262標(biāo)準(zhǔn)，汽車儀表系統(tǒng)與娛樂信息系統(tǒng)屬于不同的安全等級，具有不同的處理優(yōu)先級。汽車儀表系統(tǒng)與動力系統(tǒng)密切相關(guān)，要求具有高實時性、高可靠性和強安全性，以QNX操作系統(tǒng)為主，而信息娛樂系統(tǒng)主要為車內(nèi)人機交互提供控制平臺，追求多樣化的應(yīng)用與服務(wù)，以Linux和Android為主。
要使不同類型的操作系統(tǒng)運行在同一個計算平臺，最直接的技術(shù)路徑就是虛擬化。虛擬化作為一項底層IT核心技術(shù)一直被廣泛應(yīng)用于云計算領(lǐng)域，它的作用是通過Hypervisor軟件模擬出一個具有完整硬件系統(tǒng)功能、運行在一個完全隔離環(huán)境中的計算機系統(tǒng)。
虛擬化的概念被引入到車載操作系統(tǒng)之后，供應(yīng)商不再需要設(shè)計多個硬件來實現(xiàn)不同的功能需求，而只需要在車載主芯片上進行虛擬化的軟件配置，形成多個虛擬機，在每個虛擬機上運行相應(yīng)的軟件即可滿足需求。
虛擬化（Hypervisor）解決方案提供了在同一硬件平臺上承載異構(gòu)操作系統(tǒng)的靈活性，同時實現(xiàn)了良好的高可靠性和故障控制機制, 以保證關(guān)鍵任務(wù)、硬實時應(yīng)用程序和一般用途、不受信任的應(yīng)用程序之間的安全隔離，實現(xiàn)了車載計算單元整合與算力共享。
如果說“云“虛擬化是過去20年的技術(shù)風(fēng)口，那么”物“虛擬化將會是下一個20年不容錯過的技術(shù)風(fēng)口。雖然兩種技術(shù)同根同源，但是，基于嵌入式的物虛擬化與傳統(tǒng)的云計算虛擬化還是有其不同的地方。
**定位目標(biāo)不同：**云虛擬化關(guān)注虛擬機的熱遷移、資源彈性按需分配、靈活管理，而嵌入式虛擬化關(guān)注實時性、可確定性、功能安全（Functional Safety) 及小身材（Footprint）等。
**可用的資源多寡不同：**云服務(wù)器的計算能力和內(nèi)存資源遠多于嵌入式系統(tǒng)，后者對資源的使用幾乎達到“斤斤計較”的地步。
軟件發(fā)布模式不同。云虛擬化軟件是同一套二進制代碼部署在所有服務(wù)器上運行，而嵌入式虛擬化軟件和嵌入式硬件往往是綁定的，大多數(shù)情況下是一物一系統(tǒng)。
車載虛擬化操作系統(tǒng)首先是一個穩(wěn)定可靠、性能良好、具備實時響應(yīng)能力的微內(nèi)核，承載在虛擬機上的應(yīng)用程序按照預(yù)先設(shè)定的優(yōu)先級運行，確保在高優(yōu)先級虛擬機中運行的實時進程能夠及時獲得對計算資源的必要訪問，無論低優(yōu)先級虛擬機執(zhí)行的繁忙程度如何，同時，強制性地將關(guān)鍵應(yīng)用程序和實時操作系統(tǒng)與非關(guān)鍵應(yīng)用程序和普通操作系統(tǒng)安全隔離。
小知識
所謂微內(nèi)核（Microkernel），是指內(nèi)核進程僅提供最基本的服務(wù)，例如進程調(diào)度、進程間通信、信號、時鐘、中斷等，而其它的服務(wù)（例如文件系統(tǒng)、內(nèi)存管理、設(shè)備驅(qū)動、網(wǎng)絡(luò)協(xié)議棧等）都獨立于內(nèi)核以單獨的進程運行，它們與內(nèi)核進程和其它進程之間通過內(nèi)核提供的消息傳遞機制進行通信。
微內(nèi)核是相對于宏內(nèi)核而言的，Linux是典型的宏內(nèi)核，除了時鐘、中斷、進程調(diào)度、進程間通信外，文件系統(tǒng)、內(nèi)存管理、設(shè)備驅(qū)動管理等都由內(nèi)核完成。
一般而言，車載虛擬化操作系統(tǒng)要求具備三點技術(shù)要求：
使用資源分區(qū)技術(shù)嚴(yán)格隔離和分配資源。
靈活高效的實時和非實時任務(wù)調(diào)度機制。
進程間通信，實現(xiàn)消息在虛擬機之間通信。
1、資源分區(qū)
微內(nèi)核將全局內(nèi)存空間劃分為靜態(tài)可配置的資源池，虛擬機啟動時，將相應(yīng)的內(nèi)存頁地址空間分配給它，虛擬機中的任務(wù)線程總是連接到這部分地址空間，并且它只能訪問和管理這部分地址空間，此機制確保了虛擬機之間的嚴(yán)格隔離。當(dāng)一個虛擬機中的應(yīng)用程序出現(xiàn)故障時，只會影響分配給它的內(nèi)存，而不會影響其它虛擬機的內(nèi)存池。這是一個簡單的解決方案，因為它維護了一個最小的受信任的代碼庫，唯一的挑戰(zhàn)是開發(fā)人員應(yīng)該預(yù)先預(yù)測Guest OS的內(nèi)存需求。
2、任務(wù)調(diào)度機制
常見的操作系統(tǒng)任務(wù)調(diào)度機制有兩種：
基于優(yōu)先級：一旦內(nèi)核把資源分配給某進程，該進程便會一直執(zhí)行下去，直到該進程結(jié)束或發(fā)生某事件被阻塞（例如主動調(diào)用延時），才把資源分配給其它進程。在這種情況下，如果某個高優(yōu)先級的任務(wù)運行時間過長，最好有阻塞機制，讓出CPU使其它低優(yōu)先級的任務(wù)也有機會運行。
基于時間片：所有任務(wù)的執(zhí)行優(yōu)先級相同，當(dāng)內(nèi)核分配給該進程的時間片結(jié)束，內(nèi)核會立即停止執(zhí)行該進程，將時間片分配給其它進程執(zhí)行，即便這個任務(wù)還沒有執(zhí)行完。
車載虛擬化系統(tǒng)同時承載實時車控系統(tǒng)和非實時娛樂系統(tǒng)，這兩種系統(tǒng)對于任務(wù)的時間響應(yīng)要求有著本質(zhì)的不同：
實時系統(tǒng)：一般要求基于優(yōu)先級的調(diào)度方式，對于不同優(yōu)先級的任務(wù)，完全基于優(yōu)先權(quán)原則來運行，一旦高優(yōu)先級的任務(wù)就緒，它可以無條件地搶占任何正在執(zhí)行的、低于自己優(yōu)先級的進程，無論正在運行的進程是否已經(jīng)進入內(nèi)核調(diào)度階段。在一些實時操作系統(tǒng)的實現(xiàn)中，同時支持基于時間片的調(diào)度方式，當(dāng)幾個任務(wù)的優(yōu)先級相同時，會按照時間片來管理，在優(yōu)先級相同的任務(wù)間切換運行。
非實時系統(tǒng)：一般情況下沒有任務(wù)優(yōu)先級的概念，所有任務(wù)默認優(yōu)先級相同，任務(wù)調(diào)度采用時間片調(diào)度方式。
車載虛擬化內(nèi)核應(yīng)該具備靈活的時間調(diào)度機制，既支持基于優(yōu)先級的任務(wù)調(diào)度方式，又支持基于時間片的任務(wù)調(diào)度方式。
3、進程間通信
Hypervisor在對虛擬機進行嚴(yán)格安全隔離的同時，也需要支持不同虛擬機進程之間以受控方式相互通信。最基本的進程間通信包括同步消息傳遞和共享內(nèi)存兩種方式。
同步消息傳遞：采用客戶端/服務(wù)器（Client/Server）模式，它實現(xiàn)了兩個進程之間的點對點通信。
共享內(nèi)存：一種相對高效的進程間通信方式，對于效率要求較高、數(shù)據(jù)量較大的場景，通常采用這種方式。共享內(nèi)存段被視為共享文件系統(tǒng)，為每個虛擬機進程配置對共享內(nèi)存的讀寫訪問。
在車載虛擬化領(lǐng)域，主流的虛擬機技術(shù)提供商包括BlackBerry QNX Hypervisor（閉源）及Intel與Linux基金會主導(dǎo)的ACRN（開源）。但截至目前，只有QNX Hypervisor應(yīng)用到量產(chǎn)車型，它也是目前市場上唯一被認可功能安全等級達到ASIL D級的虛擬化操作系統(tǒng)。
QNX是由加拿大QSSL公司（QNX Software System Ltd.）開發(fā)的實時操作系統(tǒng)，既能運行于以Intel x86、Pentium等CPU為核心的硬件環(huán)境，也能運行于以PowerPC、MIPS等CPU為核心的硬件環(huán)境。
小知識
2004年，全球領(lǐng)先的音響產(chǎn)品制造商哈曼國際工業(yè)集團（Harman International Industries）收購QNX，2010年4月，BlackBerry母公司RIM以2億美元從哈曼國際手中收購QNX。
QNX操作系統(tǒng)的應(yīng)用范圍極廣，包括控制保時捷跑車的音樂和媒體功能、核電站、美國陸軍無人駕駛坦克的控制系統(tǒng)、BlackBerry PlayBook平板電腦等。
2021年2月，BlackBerry正式發(fā)布QNX Hypervisor 2.2版本，該版本基于QNX Neutrino實時操作系統(tǒng)（RTOS）7.1。
QNX Hypervisor是基于Type-1（直接運行于裸機）、實時優(yōu)先級的微內(nèi)核管理程序，符合IEC 61508 SIL-3（用于工業(yè)安全），IEC 62304（用于醫(yī)療設(shè)備軟件）和ISO 26262 ASIL-D（用于汽車安全）等標(biāo)準(zhǔn)。
整個QNX操作系統(tǒng)是由微內(nèi)核調(diào)度管理的一組進程的集合，與硬件總線結(jié)構(gòu)非常相似，稱之為“軟件總線”。
QNX是一個基于優(yōu)先級搶占的操作系統(tǒng)，線程優(yōu)先級用0\~255的數(shù)字表示，數(shù)字越大，優(yōu)先級越高。優(yōu)先級0是內(nèi)核中的IDLE線程。同時，優(yōu)先級64是一個分界嶺，優(yōu)先級1\~63是非特權(quán)優(yōu)先級，一般用戶都可以用，而64\~255必須是有Root權(quán)限的線程才可以設(shè)置。調(diào)度程序在選擇下一個運行的線程時，將檢查每個處于就緒狀態(tài)的線程的優(yōu)先級，具有高優(yōu)先級的線程將被優(yōu)先執(zhí)行。
QNX基本的任務(wù)調(diào)度算法使用的是按優(yōu)先級搶占的調(diào)度方法。這種方法保證在任何時刻都是優(yōu)先級最高的任務(wù)占用CPU時間。優(yōu)先級最高的任務(wù)可以中斷當(dāng)前運行的任務(wù)。這種方法適用于工業(yè)實時性要求較高的場合。
在基本調(diào)度算法的基礎(chǔ)上，當(dāng)兩個或更多具有相同優(yōu)先級的線程同時處于就緒狀態(tài)，并且都是當(dāng)前就緒隊列中最高優(yōu)先級的任務(wù)時，QNX提供了四種調(diào)度方法來解決問題：
先進先出（First In First Out，F(xiàn)IFO）：先進入任務(wù)隊列的線程被選擇執(zhí)行，直到它自動放棄，或者被一個級別更高的線程打斷運行。
輪詢（Round Robin）：先進入任務(wù)隊列的線程被選擇執(zhí)行，直到它自動放棄，或者被一個級別更高的線程打斷運行，或者它消耗完了自己的時間片（時間片為50ms，是系統(tǒng)分配給每個線程用于運行的時間單位）。
自適應(yīng)調(diào)度（Adaptive Scheduling）：如果一個線程消耗完自己的時間片時仍未被阻塞，線程優(yōu)先級將被減1，稱為優(yōu)先級衰減。一個線程只能降低一次優(yōu)先級。如果該線程被阻塞，則將立即恢復(fù)為原來的優(yōu)先級。這種算法不適用于實時控制系統(tǒng)，主要應(yīng)用于后臺有計算密集的任務(wù)，且同時需要響應(yīng)用戶的交互信息，此時，計算線程可以擁有足夠的CPU資源，同時對用戶請求又有很快的響應(yīng)。
零星調(diào)度（Sporadic Scheduling）：引入Initial Budget、Replenishment Period、Max Number of Pending Replenishments三個參數(shù)，使一個線程可動態(tài)執(zhí)行于Normal Priority和Low Priority兩個優(yōu)先級。
Initial Budget（C）：線程在Normal Priority下允許執(zhí)行的時間。
Low Priority：由于某種原因，線程不再以Normal Priority運行，就將該線程的優(yōu)先級降至此優(yōu)先級。
Replenishment Period（T）：只有在這個時間段內(nèi)，線程才被允許消耗完它的Initial Budget。
Max Number of Pending Replenishments：限制Replenishment Period的發(fā)生次數(shù)。
當(dāng)線程的優(yōu)先級降低到Low Priority時，它可能會被執(zhí)行，也可能不被執(zhí)行，取決于系統(tǒng)當(dāng)時其它線程的優(yōu)先級。一旦一個Replenishment Period（T）到來，該線程的優(yōu)先級立即升至Normal Priority，這樣，只要適當(dāng)配置系統(tǒng)中各線程的C和T，就可以使每個線程都可以在每個T內(nèi)被執(zhí)行C時間值。
零星調(diào)度將一個線程需要執(zhí)行的時間分拆成若干段進行執(zhí)行（這也是“零星調(diào)度”名稱的由來），這種算法適用于一個周期內(nèi)具有執(zhí)行時間上限的線程，可以使一個線程對非周期事件進行服務(wù)，而不用擔(dān)心影響其它硬實時線程的執(zhí)行期限。
ACRN由Linux基金會于2018年3月在“Linux嵌入式大會”上發(fā)布，是一款靈活、開源的（BSD-3-Clause License）、輕量級Hypervisor參考軟件。Intel開源技術(shù)中心為ACRN項目的發(fā)布貢獻了源代碼，早期支持者包括Intel、ADLink（凌華科技）、Aptiv、LG和東軟等。
2020年6月，ACRN v2.0正式發(fā)布，采用**“Partition Mode”+“Sharing Mode”的“**Hybrid Mode”架構(gòu)設(shè)計。
Partition Mode（左側(cè)）的VM獨享CPU、內(nèi)存、I/O外設(shè)等資源，在運行時沒有ACRN Hypervisor的性能開銷，可以達到最大****的隔離性和更高的實時性。這個VM既可以作為Safety VM監(jiān)控整個物理平臺的健康狀態(tài)，在系統(tǒng)發(fā)生嚴(yán)重故障時采取緊急措施，又可以作為實時VM獲得更好的實時性。
Sharing Mode（右側(cè)）有一個Service VM，它的作用類似于Xen虛擬化架構(gòu)中的Dom0，通過Device Model模塊在User VM（類似于Xen虛擬化架構(gòu)中的DomU）之間共享外設(shè)，同時管理各個VM的生命周期，并調(diào)用Libvirt接口對外提供遠程調(diào)用和編排的標(biāo)準(zhǔn)接口。需要特別說明的是，為了使RTVM（右側(cè)黃色VM）能夠運行硬實時OS（例如VxWorks、Zephyr、Xenomai等），ACRN進行了特別的設(shè)計與代碼優(yōu)化，例如Local APIC直通等，使RTVM達到接近裸金屬的實時性能。
Hybrid Mode架構(gòu)具有兩個特點：
利用Partition Mode的VM運行Safety VM監(jiān)控物理平臺狀態(tài)，同時利用Sharing Mode中的RTVM運行RTOS實現(xiàn)實時控制，滿足復(fù)雜工業(yè)場景的需求。
通過ACRN Hypervisor實現(xiàn)了異構(gòu)負載的整合，例如，實時和非實時負載、安全功能和非安全功能的隔離等。
為了保持ACRN Hypervisor代碼庫盡可能精簡且高效，大部分設(shè)備模塊的實現(xiàn)都駐留在Service VM，Service VM可以運行Clear Linux（Intel基于GPL協(xié)議的開源項目），也支持其它Linux發(fā)行版或者專有RTOS作為Service OS。如果沒有Partition Mode中的Pre-launched VM，Service VM是ACRN Hypervisor創(chuàng)建的第一個虛擬環(huán)境，以系統(tǒng)最高優(yōu)先級的虛擬機形式存在，通過Device Model模塊向Guest OS提供I/O模擬操作。
ACRN Hypervisor基于Intel IA-32處理器的硬件輔助虛擬化技術(shù)（Intel VT-x）。
Intel VT-x引入了一種新的CPU操作，稱為VMX（Virtual Machine eXtensions），以及兩種新的CPU工作模式和10條新的虛擬專用指令（VMPTRLD、VMPTRST、VMCLEAR、VMREAD、VMWRITE、VMCALL、VMLAUNCH、VMRESUME、VMXOFF和VMXON）。兩種工作模式分別為VMX root operation（根虛擬化操作）和VMX non-root operation（非根虛擬化操作），其中，VMX root operation被設(shè)計用于給Hypervisor使用，VMX non-root operation則由Guest OS使用。兩種工作模式都支持Ring 0～Ring 3，因此，Hypervisor和Guest OS可以自由選擇它們所期望的運行級別。
硬件輔助虛擬化技術(shù)就是通過在VMX root operation和VMX non-root operation兩種工作模式之間相互切換實現(xiàn)的。
運行在VMX root operation模式下的Hypervisor通過顯式調(diào)用VMLAUNCH或VMRESUME指令切換到VMX non-root operation模式，硬件自動加載Guest OS的上下文，于是Guest OS獲得運行，這種轉(zhuǎn)換稱為VM entry。Guest OS運行過程中遇到需要Hypervisor處理的事件，例如外部中斷或缺頁異常，或者主動調(diào)用VMCALL指令請求Hypervisor的服務(wù)的時候（與系統(tǒng)調(diào)用類似），硬件自動掛起Guest OS，切換到VMX root operation模式，恢復(fù)Hypervisor的運行，這種轉(zhuǎn)換稱為VM exit。VMX root operation模式下，軟件的行為與在沒有VT-x技術(shù)的處理器上的行為基本一致；而VMX non-root operation模式則有很大不同，最主要的區(qū)別是此時運行某些指令或遇到某些事件時，發(fā)生VM exit。
ACRN Device Model是一個類似QEMU的硬件設(shè)備模擬軟件，依賴以下三個子系統(tǒng)協(xié)同工作：
1、設(shè)備仿真（Device Emulation）
Device Model為User VM中的設(shè)備驅(qū)動提供設(shè)備仿真例程（Routines），用來模擬各種不同種類的硬件設(shè)備，這些設(shè)備仿真例程將各自的I/O處理程序注冊到I/O調(diào)度器（Dispatcher）。當(dāng)User VM產(chǎn)生I/O設(shè)備訪問請求時，I/O調(diào)度器將這些請求分發(fā)到相應(yīng)的設(shè)備仿真例程，實現(xiàn)硬件模擬。
2、VHM（Virtio and Hypervisor Service Module）
以Service OS的內(nèi)核模塊形式存在，作為ACRN Hypervisor與Device Model之間的橋梁，為設(shè)備模擬提供必要的服務(wù)，具體的服務(wù)流程如下：
ACRN Hypervisor通過中斷通知VHM新的IOREQ到來。
VHM將IOREQ標(biāo)記為“正在處理”，同時將其發(fā)送給設(shè)備模擬、GVT-g（Intel開源的GPU虛擬化解決方案）、VBS-K（Virtio Backend Service Kernel-land）等做進一步處理。之后，VHM可以處理新的IOREQ。
一旦IOREQ被處理完成，VHM將被通知（內(nèi)核態(tài)通過函數(shù)調(diào)用方式通知，用戶態(tài)通過IOCTL的方式通知），之后，VHM通過Hypercall方式進一步通知ACRN Hypervisor該IOREQ處理完成。
3、I/O請求（I/O Path）
下圖展示了ACRN中訪問一個虛擬I/O的流程。
當(dāng)Guest OS執(zhí)行I/O指令時，VM exit發(fā)生，ACRN Hypervisor獲得CPU控制權(quán)，首先判斷VM執(zhí)行退出的原因，例如PIO或MMIO等。
ACRN Hypervisor對產(chǎn)生VM exit的指令進行譯碼，將譯碼得到的信息（包括PIO訪問、訪問字節(jié)數(shù)、讀/寫方式、目標(biāo)寄存器等）放到與ACRN VHM、ACRN Device Model共享的物理頁面中，然后以中斷的方式通知Service OS中的VHM做進一步處理。
Service OS中的VHM接收到中斷后，查詢與該IOREQ相關(guān)的所有信息。
VHM首先會檢查是否應(yīng)該由內(nèi)核態(tài)的Device Model來處理該IOREQ。如果是，相應(yīng)的內(nèi)核模塊之前注冊的Callback函數(shù)會被VHM調(diào)用；否則，如果沒有內(nèi)核態(tài)的Device Model來處理IOREQ，VHM則會將該IOREQ保留在共享頁面中，并喚醒ACRN Device Model對該IOREQ進行處理。
ACRN Device Model采用與VHM相同的機制對IOREQ進行處理。Device Model的I/O執(zhí)行線程會首先查詢IOREQ具體的信息，同時檢查是否有設(shè)備仿真模塊實現(xiàn)了該IOREQ對應(yīng)的邏輯。如果有相應(yīng)的模塊，那么該模塊對應(yīng)的Callback函數(shù)將會被調(diào)用。
ACRN Device Model完成設(shè)備模擬仿真后，將結(jié)果保存到共享頁面。
完成IOREQ的模擬和仿真后，ACRN Device Model通過VHM的API將控制權(quán)返回給ACRN Hypervisor。
ACRN Hypervisor得知IOREQ處理完成，將結(jié)果保存到vCPU的相應(yīng)寄存器中。
ACRN Hypervisor更新完vCPU寄存器后，進一步更新IP地址寄存器指向下一條Guest OS指令，同時恢復(fù)Guest OS的執(zhí)行。
Hypervisor介乎于底層DCU硬件和上層OS軟件之間，與標(biāo)準(zhǔn)化服務(wù)器（x86）+標(biāo)準(zhǔn)化OS（Windows和Linux）的云虛擬化應(yīng)用場景不同，汽車嵌入式環(huán)境中的虛擬化技術(shù)面臨的挑戰(zhàn)是Hypervisor往往需要定制適配底層DCU硬件和上層OS軟件，這一點對于Hypervisor的大規(guī)模商用與普及是一個非常大的技術(shù)障礙。
2016年3月，OASIS（Organization for the Advancement of Structured Information Standards，結(jié)構(gòu)化信息標(biāo)準(zhǔn)促進組織）正式標(biāo)準(zhǔn)化VirtIO項目，旨在提供一種通用的框架和標(biāo)準(zhǔn)接口，減少Hypervisor對底層不同硬件和上層不同軟件的適配開發(fā)工作量。
目前，VirtIO標(biāo)準(zhǔn)得到了眾多科技巨頭的支持，包括Apple、Google、ARM、Intel、Red Hat、華為等。Google也計劃在Android Automotive OS中集成對VirtIO的支持。
VirtIO是一套易維護和易擴展的通用設(shè)備仿真接口，由前端驅(qū)動程序（Front-End Driver）、后端驅(qū)動程序（Back-End Driver）和VirtIO虛擬隊列（Virtual Queue）構(gòu)成。
前端驅(qū)動程序由Guest OS實現(xiàn)，后端驅(qū)動程序由Hypervisor實現(xiàn)，虛擬隊列通常使用環(huán)形緩沖，在Hypervisor和Guest OS之間傳輸數(shù)據(jù)，每個驅(qū)動可以有0個或多個隊列，取決于實際需要。例如，網(wǎng)絡(luò)驅(qū)動（virtio-net）可能使用了兩個虛擬隊列（分別用于接收和發(fā)送），而塊存儲驅(qū)動（virtio-blk）可能只需要一個。
除了網(wǎng)卡、PCI、塊存儲、控制臺、輸入等常用設(shè)備之外，傳感器、CAN網(wǎng)絡(luò)、媒體編解碼設(shè)備等汽車領(lǐng)域的一些特殊類型硬件，可能是未來VirtIO標(biāo)準(zhǔn)完善的方向。
汽車電子電氣架構(gòu)從分布式向域集中式發(fā)展的趨勢已成定局，越來越多的功能被整合到少數(shù)幾個域控制器中，從而出現(xiàn)了多種不同的功能復(fù)用同一個硬件平臺的需求。
Hypervisor虛擬化為同一個硬件平臺承載多種不同類型的操作系統(tǒng)、不同時間響應(yīng)要求的業(yè)務(wù)應(yīng)用提供了關(guān)鍵的技術(shù)支撐。借助Hypervisor虛擬化技術(shù)，既消除了硬件冗余，簡化了總體設(shè)計，降低了整車重量，又滿足了資源復(fù)用、算力共享、安全隔離的需求。
當(dāng)前，大多數(shù)的Hypervisor都需要與指定的底層硬件和上層Guest OS配合使用，隨著越來越多的Hypervisor提供商和Guest OS供應(yīng)商遵循VirtIO標(biāo)準(zhǔn)，以及VirtIO標(biāo)準(zhǔn)對特定汽車硬件的虛擬化支持，Hypervisor將進一步解耦車載軟硬件，車載系統(tǒng)供應(yīng)商將更容易在不同的DCU硬件平臺上支撐不同的Guest OS和應(yīng)用程序，從而真正實現(xiàn)軟件定義汽車。
作者：歐珊瑚
來源：https://mp.weixin.qq.com/s/Ilv9nn0Fy5o6p3p2\_oiacw
聯(lián)系客服
