随着各种用户功能的需求不断增加，以及实现这些功能的更强大硬件的出现，汽车的电子电气 (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 系列则在实时应用方面表现出色。

Armv8-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 提供的处理器架构和虚拟机管理程序能够使软件栈彼此隔离，同时不影响安全性和安全功能。

虚拟机管理程序实现的抽象层为汽车和硬件制造商及软件提供商带来了诸多益处。主要的优势包括：

解决软件实现和特定硬件变体之间的依赖问题；

能够更快地在硬件变体之间进行切换；

引入新一代 ECU 并能够复用软件栈；

无需调整软件栈以适应特定版本的硬件配置，即可扩展硬件平台以适应低端和高端部署需求。

借助以上优势，还可减少对特定硬件实现方案的依赖，同时降低了重新实现新硬件平台功能而产生的开发成本。因此，抽象层促进了软件组件的复用，有助于节省时间和资源，并最终缩短产品上市时间。

抽象层的通用接口还提供了一项优势，即允许并行开发。由于接口独立于特定硬件，因此软件开发可以在硬件尚未就绪的情况下先行启动。此外，软件开发也可以在其他环境中进行，例如具有虚拟设备的云端。Arm 虚拟硬件 (Arm Virtual Hardware) 平台就是一个很好的例子，它提供了硬件平台的虚拟变体。

适合 Armv8-R 架构的虚拟机管理程序：

面向 MPU 的 L4Re Micro Hypervisor

要了解虚拟机管理程序的作用及其为软件组件提供的接口，必须先对虚拟机管理程序本身进行了解。它的任务类似于 L4Re Micro Hypervisor，为软件栈的运行提供定义好的环境，并允许必要的资源访问。通常，这意味着通过设备内存和中断机制来访问硬件设备。然而，如果多个虚拟机需要同一设备的服务，则虚拟机管理程序应该为这一设备提供多路复用功能。这样，每个虚拟机都可以共用该设备。

这里的关键挑战是虚拟机如何访问多路复用设备。一种方法是让虚拟机管理程序来模拟虚拟机所需的硬件设备，就像访问实际设备一样。尽管这是一种可行方法，但实现这种模拟既繁琐又容易出错。更好的方法是使用专门为虚拟机和管理程序准备的接口，即 VirtIO。

作为通用硬件抽象层的 VirtIO

VirtIO 是虚拟机和虚拟机管理程序之间共享资源的标准协议，专为此类设置而设计。VirtIO 已经在服务器虚拟化领域得到广泛应用，结构化信息标准推动组织 (OASIS) 开放小组正致力于 VirtIO 驱动程序的标准化。

采用 VirtIO 后，虚拟机无需具备所运行平台的专用驱动程序，虚拟机管理程序也不用为虚拟机所使用的驱动程序提供模拟。VirtIO 常用于服务器，尽管它仍能提供相同的优势，但对于小规模嵌入式领域来说还是一项新兴技术。L4Re Hypervisor 系列使用 VirtIO 作为主要的设备虚拟化技术。

VirtIO 可以灵活地部署虚拟机托管的软件栈，因为它们能够在不同的硬件平台和硬件配置之间轻松迁移。正如软件定义汽车 (SDV) 所倡导的愿景，凭借这种独立于硬件的虚拟机，可以更灵活动态地部署基于虚拟机的工作负载。想要深入了解设备虚拟化，请点击阅读《 为实时系统引入设备虚拟化原则 》。

Cortex-R82 和 L4Re Micro Hypervisor 增强灵活性：兼顾嵌入式和通用操作系统

在 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 实现方案提供了性能基础。