隨著各種用戶功能的需求不斷增加，以及實現這些功能的更強大硬件的出現，汽車的電子電氣 (E/E) 架構正在持續演進。過去，經典的汽車 E/E 架構將功能分配到多達 100 個電子控制單元 (ECU) 中。然而，增加汽車 ECU 數量正在變得更為困難。所有 ECU 都需要占據空間和消耗電力，還會增加汽車重量，不僅數量龐大，而且連接設備所需的電線總長超過了四公里。隨著 ECU 數量增多，加之對新功能的需求不斷上升，如何對 ECU 上運行的軟件進行更新也成為一大難題。如果采用集中式 E/E 架構，可通過單一通道（中央 ECU）部署軟件更新，這與分布式 E/E 架構相比，大幅簡化了更新流程。

為了進行整合（例如在單個系統上運行多種功能）并在不同應用之間保持分隔，需要對硬件平臺和整個系統的軟件架構都提出更高的要求。

為了滿足日益增長的區域架構需求，近年來已開始部署首批相關設計。Arm 是當前汽車領域發展的先鋒，提供了基于 Arm Cortex-A CPU 的解決方案，使虛擬化成為可能。其中一個例子是 ICAS1（車載汽車服務器），這是大眾汽車的電動汽車平臺中所使用的中央計算系統，為 ID.3 等車型提供支持。ICAS1 采用基于 Kernkonzept L4Re Hypervisor 的 Elektrobit 虛擬機管理程序，用于隔離多個軟件棧。

虛擬化為整合帶來了顯著好處，因為它幾乎無需修改就可以使用現有軟件。而這需要在硬件和實際軟件功能之間設置一個合適的軟件層，即虛擬機管理程序。

ECU 用于常規的汽車駕駛環境中，因此安全問題至關重要。為此，實施強有力的安全措施必不可少，其中實時應用不可或缺。Cortex-A 系列專為計算密集型操作而設計，而 Arm Cortex-R 系列則在實時應用方面表現出色。

相較于之前的 Armv7-R 架構，基于 Armv8-R 架構的 Cortex-R 處理器（例如 Cortex-R52+）引入了新的虛擬化功能。隨著基于 Armv8-R 的最新一代處理器問世，Arm 進一步將虛擬化與安全性相結合。通過在基于內存保護單元 (MPU) 的處理器上啟用虛擬化，能夠以更佳的方式滿足實時條件，同時盡可能確保安全需求。由于該架構專注于確定性執行行為和鎖步核心，因此同時具備實時性和安全特性。

與前幾代 ECU 相比，Cortex-R 處理器的算力顯著提高，時鐘頻率高達 1 GHz，并支持集群配置，進一步為 ECU 整合奠定了基礎。憑借更大的計算能力，單個處理器上可托管前幾代產品的多個 ECU 軟件棧。

得益于虛擬化功能，Armv8-R 架構可以在單個核心上托管多個操作系統（例如經典的 AUTOSAR 實例），并確保必要的隔離以滿足安全性要求。

圖：ECU 整合示例：每個虛擬 ECU (vECU) 都運行著原本在單獨 ECU 上使用的完整軟件棧

正如上圖所示，原本在不同 ECU 上運行的功能（如擋風玻璃雨刷和電池管理控制）現在被堆疊至單個功能強大的 ECU 中。在這個情況下，底層軟件層必須確保軟件棧之間不會互相影響。它們之間的屏障必須足夠牢靠，以至于安全相關的軟件組件也需要獨立執行并相互隔離。

為了控制和編排單獨的軟件棧，以及處理器和硬件，我們需要操作系統的功能。這可以通過 L4Re Micro Hypervisor 得到實現。它作為硬件和軟件之間的軟件層，可為軟件功能提供強大的隔離。

L4Re Micro Hypervisor 在硬件和運行的軟件之間提供了一個抽象層。通過將軟件棧部署到虛擬機 (VM) 中，虛擬機管理程序可以隔離軟件棧，同時繼續在操作系統等現有環境中運行。因此，無需對軟件架構進行改造。例如，原先在 ECU 中運行的控制擋風玻璃雨刷器的軟件棧可視為一個整體，只需進行一些微小的調整。

Armv8-R 提供的處理器架構和虛擬機管理程序能夠使軟件棧彼此隔離，同時不影響安全性和安全功能。

虛擬機管理程序實現的抽象層為汽車和硬件制造商及軟件提供商帶來了諸多益處。主要的優勢包括：

借助以上優勢，還可減少對特定硬件實現方案的依賴，同時降低了重新實現新硬件平臺功能而產生的開發成本。因此，抽象層促進了軟件組件的復用，有助于節省時間和資源，并最終縮短產品上市時間。

抽象層的通用接口還提供了一項優勢，即允許并行開發。由于接口獨立于特定硬件，因此軟件開發可以在硬件尚未就緒的情況下先行啟動。此外，軟件開發也可以在其他環境中進行，例如具有虛擬設備的云端。Arm 虛擬硬件 (Arm Virtual Hardware) 平臺就是一個很好的例子，它提供了硬件平臺的虛擬變體。

要了解虛擬機管理程序的作用及其為軟件組件提供的接口，必須先對虛擬機管理程序本身進行了解。它的任務類似于 L4Re Micro Hypervisor，為軟件棧的運行提供定義好的環境，并允許必要的資源訪問。通常，這意味著通過設備內存和中斷機制來訪問硬件設備。然而，如果多個虛擬機需要同一設備的服務，則虛擬機管理程序應該為這一設備提供多路復用功能。這樣，每個虛擬機都可以共用該設備。

這里的關鍵挑戰是虛擬機如何訪問多路復用設備。一種方法是讓虛擬機管理程序來模擬虛擬機所需的硬件設備，就像訪問實際設備一樣。盡管這是一種可行方法，但實現這種模擬既繁瑣又容易出錯。更好的方法是使用專門為虛擬機和管理程序準備的接口，即 VirtIO。

VirtIO 是虛擬機和虛擬機管理程序之間共享資源的標準協議，專為此類設置而設計。VirtIO 已經在服務器虛擬化領域得到廣泛應用，結構化信息標準推動組織 (OASIS) 開放小組正致力于 VirtIO 驅動程序的標準化。

采用 VirtIO 后，虛擬機無需具備所運行平臺的專用驅動程序，虛擬機管理程序也不用為虛擬機所使用的驅動程序提供模擬。VirtIO 常用于服務器，盡管它仍能提供相同的優勢，但對于小規模嵌入式領域來說還是一項新興技術。L4Re Hypervisor 系列使用 VirtIO 作為主要的設備虛擬化技術。

VirtIO 可以靈活地部署虛擬機托管的軟件棧，因為它們能夠在不同的硬件平臺和硬件配置之間輕松遷移。正如軟件定義汽車 (SDV) 所倡導的愿景，憑借這種獨立于硬件的虛擬機，可以更靈活動態地部署基于虛擬機的工作負載。想要深入了解設備虛擬化，請點擊閱讀《 為實時系統引入設備虛擬化原則 》。

在 Arm 處理器產品組合中，基于 Armv8-R 架構的 Cortex-R52+ 處理器通過提供確定性執行特性來滿足安全性和實時用例需求。Cortex-R52 和 Cortex-R52+ 是首批在 R 系列上提供虛擬化功能的處理器，支持在單個處理器上運行多個獨立的軟件棧。Cortex-R52 和 Cortex-R52+ 為 32 位處理器。

另外還有 64 位的 Cortex-R82AE，這是 Arm 新推出的 64 位 Armv8-R 處理器，專門面向汽車安全應用。Cortex-R82AE 的主要新功能之一是能夠在 EL1 的虛擬機中支持基于 MMU 和 MPU 的保護，同時托管通用操作系統（如 Linux）及實時操作系統。虛擬機管理程序級別 (EL2) 繼續使用 MPU，為虛擬機管理程序、實時和安全應用及虛擬機提供確定性內存訪問能力。

基于微內核的開源 L4Re Micro Hypervisor 可支持 32 位的 Cortex-R52 和 Cortex-R52+，以及 64 位的 Cortex-R82AE。它能夠充當虛擬機的主機，使用 MPU 或 MMU，而且支持與虛擬機并行的原生應用（稱為 MicroApps）。

L4Re MicroApps 可實現小巧可靠的軟件組件，而無需運行整個操作系統（包括虛擬機中的應用）。借助配套的 L4Re Hypervisor，還可支持 Armv8-A 處理器，并提供相同的靈活功能。

圖：示例為基于 Arm Cortex-R82AE 的區域 ECU 系統，運行 L4Re Micro Hypervisor，托管兩個基于 MPU 的虛擬機和一個 Linux 虛擬機

L4Re MicroApps 可監測虛擬機并提供 VirtIO 服務。《MCU 虛擬化：L4Re Micro Hypervisor》白皮書 ^[1] 深入探討了基于 MPU 的處理器（32 位和 64 位）的虛擬化。其中還介紹了 L4Re Micro Hypervisor 的虛擬化功能如何幫助構建靈活且面向未來的汽車系統，從而實現軟件定義汽車。

基于 Armv8-R 的處理器和 MPU 的虛擬機管理程序（例如 L4Re Micro Hypervisor）為安全的區域 ECU 實現方案提供了性能基礎。開源的 L4Re Micro Hypervisor 現已發布于 https://github.com/kernkonzept 上。