虚拟化技术为为汽车ECU提供基础架构

1.ECU整合趋势和虚拟化的力量

随着信息娱乐和 ADAS 等新功能被添加到汽车中，每辆车中安装的 ECU 数量也在增长。越来越多的 ECU 会产生一些不良副作用：设备管理复杂、重量和功耗只是其中的一部分。

为了阻止这种趋势，汽车行业正在寻求从独立的面向功能的方法转变为集成方法，其中单个 ECU 提供多种功能。

图 1：ECU 整合旨在从单功能 ECU 方法（左）转向多功能 ECU（右）

在尝试向多功能 ECU 迁移时，会出现新的挑战：每个功能可能需要在不同的操作系统上运行，并且 CPU、内存和外围设备等硬件资源必须在它们之间共享。此外，需要确保功能之间的隔离和“不受干扰”。

幸运的是，这正是虚拟化技术帮助提供基础架构的地方，该基础架构允许多个“客户”操作系统（也称为虚拟机或 VM）以安全、独立和隔离的方式执行。

2. 汽车以太网

ECU 中实现的功能变得越来越复杂，需要灵活的互连和更高的数据传输速率。汽车以太网正在成为车载网络解决方案的首选。以太网具有巨大的未来潜力，因为它提供了带宽、轻型布线（例如非屏蔽单双绞线）、庞大的生态系统和可靠的软件基础设施。此外，交换式以太网提供了极大的可扩展性，时间敏感网络 （TSN） 扩展提供了改进的同步、低延迟和可靠性。

当多功能 ECU 使用虚拟化来运行多个操作系统时，一种常见的解决方案是处理各种 VM，就好像它们连接到同一个物理以太网网络一样。

如果只有一个以太网接口，则管理程序提供了在 VM 之间共享接口的机制，并且通常在软件中实现虚拟网络交换机。由于这种软件实现会产生开销，因此硬件制造商正在为其设备添加硬件辅助虚拟化功能，以便在无需管理程序干预的情况下实现共享。

在这篇博客中，我们描述了一个概念验证 （POC），我们在其中比较了让两个 VM 共享一个集成硬件交换机和一个软件交换机的好处。

三、硬件说明

此 POC 基于车载计算机 3 板 （VC3），配备 Renesas R-Car H3 SoC 和 TSN 以太网交换机 （R-Switch2）。以太网交换机在通过 PCIe 连接到 R-Car 的 FPGA 上实现。

R-Switch2 有四个外部端口（1G-T1 连接器）和一个内部端口（命名为 CPU 端口或 tsngw）暴露给 R-Car SoC 中的 CPU。R-Switch2 和 CPU 之间的接口允许在 R-Car 上运行的操作系统成为以太网帧的来源或目的地。

R-Switch2 和 CPU 之间的数据通过多个队列进行交换。每个队列由一个描述符列表表示，这些描述符驻留在主内存中，由运行在 CPU 上的软件设置：

RX 队列中的描述符告诉 R-Switch2 硬件应将 CPU 的传入以太网帧复制到主存储器的哪个位置

TX 队列中的描述符告诉 R-Switch2 硬件 CPU 将其希望发送的帧放置在何处，以便硬件知道应该从主存储器中的哪个位置获取数据

如果在 CPU 上运行管理程序，则可以将队列分配给特定的客户操作系统以进行独立的数据处理。

四、软件说明

对于这个概念证明，选择 Xen v4.14 作为管理程序。开发了额外的前端和后端驱动程序来共享 R-Switch2 硬件，作为典型 Xen 桥接网络的替代方案（更多信息在这里）。Xen（也称为域）上运行着两个客户操作系统：

dom0：一个特权域，可以直接访问大多数 R-Car 外围设备和 R-Switch

domU：无特权的域，不能直接访问任何特定的硬件设备。但是，domU 可以访问两个 R-Switch2 队列（一个 RX 和一个 TX）

下面的图 2 显示了这种配置。

图 2 此 POC 的软件配置

前端和后端驱动程序之间的通信仅用于以下情况：

在初始化时，前端发送请求以保留两个 R-Switch2 队列（1 TX 和 1 RX）

在运行时，前端使用此通信通道通过后端通知 R-Switch2 硬件 TX 队列已准备好进行处理。每当 domU 的 RX 队列中有新数据可用时，后端也使用它来通知前端

请注意，在为 domU 设置队列所需的初始握手之后，前端驱动程序只需直接访问由 R-Switch2 硬件处理的相同队列即可传输和接收帧，而来自 dom0 端的干预最少。与其他用于虚拟机的 SW 网络解决方案相比，这是一个优势，其中 domU 的帧通常与后端驱动程序共享，并由 dom0 中的网络堆栈重新路由。

例如，当 domU 想要通过网络传输一些帧时，使用共享 R-Switch2 解决方案所涉及的步骤如下（如图 3 所示）：

domU 将数据写入自己的 TX 队列

domU 通知 R-Switch2 硬件（通过后端）队列已准备好进行处理

R-Switch2 硬件直接从 domU 队列中获取数据

图 3 来自 domU 的数据包传输示例（R-Switch2 共享）

另一方面，当使用 Xen 桥接网络时，从 domU 传输帧所涉及的步骤是（参见图 4）：

domU 将要传输的数据写入内存

内存与 dom0 中的后端共享

后端将数据包转发到 Xen Bridge

数据包通过 dom0 网络堆栈路由，最终到达网络接口驱动程序

驱动程序将数据包的数据复制到 NIC 队列中

网卡从内存中访问数据

图 4 来自 domU（Xen 桥接网络）的数据包传输示例

5.性能与比较

系统的性能是通过生成来自/到 domU 的恒定比特率 UDP 流并同时测量 dom0 和 domU 上的 CPU 负载来测量的。

即使网络帧是从 domU 传输/接收的，我们也测量 dom0 的 CPU 使用率的原因是，我们希望在软件中实现虚拟交换机的情况下看到更高的负载，因为 domU 数据包需要重新路由通过 dom0 的网络堆栈。

然后将此 POC 中实施的解决方案与 Xen 桥接网络进行比较，这是一种常见的软件解决方案，可实现虚拟交换机并允许在同一网络上连接多个虚拟机。

结果如图 5 和图 6 所示，证实了我们的假设。使用 R-Switch2 共享方案时，dom0 CPU 负载比 Xen Bridged 网络低约 50%，而 domU CPU 负载几乎相同。

图 5 domU 接收测试期间的 CPU 负载（1 Gbps 的恒定数据速率）

图 6 domU 传输测试期间的 CPU 负载（600 Mbps 的恒定数据速率）

R-Switch2 情况下的剩余 dom0 CPU 负载是由来自/到 domU 的事件通知引起的，即当有新的传入数据可用时，dom0 通知 domU，或者 dom0 将来自 domU 的请求转发给 R-Switch2 HW 以开始处理 TX队列。

对于像 Xen Bridge 这样的基于软件的交换机，dom0 有额外的任务来路由 domU 数据包，这可能成为系统的瓶颈。在我们的解决方案中，domU 数据包的路由由集成网络交换机在硬件中完成，从而释放 CPU 资源并提高两个域之间的隔离度。

六，结论

集成的硬件交换机可以简化软件交换机甚至是冗余的，从而为应用程序处理而不是内务管理任务释放资源。评估表明，使用硬件辅助虚拟化可节省超过 50% 的宝贵 CPU 资源。事实证明，瑞萨 R-Switch2 支持多个接收和传输队列在通过虚拟化整合 ECU 的环境中具有明显优势。此功能与对 L2 和 L3 路由和 TSN 扩展的硬件支持一起，使其成为实现未来 ECU 的完美选择。

审核编辑：郭婷