汽车ECU的虚拟化技术初探(一)

1.为什么要提汽车ECU的虚拟化？

2.虚拟化技术分类

2.1 硬件虚拟化

2.2 操作系统虚拟化

问题引入：

Hypervisor是如何来管理和隔离硬件资源，保证各个不同功能的应用程序的资源使用安全和资源调度？
没有MMU就做不了虚拟化？

1.为什么要提汽车ECU的虚拟化？

要讲汽车ECU的虚拟化，首先要从汽车电子电气架构的演进roadmap开始说起。汽车行业领头羊博世将整车电子电气架构定义成了六个主要发展阶段，如下：

模块化阶段：汽车上每个 ECU 负责特定的功能，比如车灯控制器，制动控制器等，这些控制器像叶子一样挂在CAN总线上，随着汽车功能增多这种架构日益复杂，无法持续。
集成化阶段，单个 ECU 负责多个功能，ECU 数量较上一阶段减少。在这两个阶段，汽车电子电气架构仍处于分布式阶段，ECU 功能集成度较低。
集中化阶段，即现在比较主流的功能域控阶段。功能域即根据功能划分的域控制器，最常见的是如博世划分的五个功能域（动力域、底盘域、车身域、座舱域、自动驾驶域）。域控制器间通过以太网和 CANFD（CAN with Flexible Data-Rate）相连，其中座舱域和自动驾驶域由于要处理大量数据，算力需求逐步增长。动力总成域、底盘域、车身域主要涉及控制指令计算及通讯资源，算力要求较低。
域融合阶段。在功能域基础上，为进一步降低成本和增强协同，出现了跨域融合，即将多个域融合到一起，由跨域控制单元进行控制。比如将动力域、底盘域、车身域合并为整车控制域，从而将五个功能域（自动驾驶域、动力域、底盘域、座舱域、车身域）过渡到三个功能域（自动驾驶域、智能座舱域、车控域）。
车载电脑阶段，随着功能域的深度融合，功能域逐步升级为更加通用的计算平台，从功能域跨入位置域（如特斯拉的前域、左域、右域）。区域控制器平台（Zonal Control Unit，ZCU）是整车计算系统中某个局部的感知、数据处理、控制与执行单元。它负责连接车上某一个区域内的传感器、执行器以及 ECU等，并负责该位置域内的传感器数据的初步计算和处理，还负责本区域内的网络协议转换。
车云阶段，将汽车部分功能转移至云端，车内架构进一步简化。车的各种传感器和执行器可被软件定义和控制，汽车的零部件逐步变成标准件，彻底实现软件定义汽车功能。

可以看到，随着电子电气架构的更新，整车所需的ECU数量更少，但每个ECU功能更加丰富，例如将制动、转向、动力控制的功能全部集中到一个ECU。这种功能的集中对控制器所采用芯片的资源保护提出了巨大的挑战。

因此，借鉴座舱域控将QNX、Android集中到一块SOC的经验，在MCU上实现虚拟化技术，将不同功能安全等级的系统部署到同一个硬件平台上。如下图：

2.虚拟化技术分类

虚拟化技术按照虚拟化层次通常可以分为硬件虚拟化和操作系统虚拟化两类。

2.1 硬件虚拟化

进一步的，硬件虚拟化可细分为 Type1 和 Type2 两类；

Type1类型的虚拟化

虚拟化管理程序直接运行在裸硬件上，因此也叫作裸机虚拟化；如下图，Hypervisor一般是一个嵌入在Host OS内核里面的一部分，能够直接操作控制硬件并管理多个虚拟机（Guest VM）。每个虚拟机都有自己的操作系统和应用程序（下图的APP+Guest OS），可以完全独立运行。

Tpye2类型的虚拟化。

与Type1类型的虚拟机不一样，Type2类型虚拟化是指在已经装载好OS的的硬件上运行一个Hypervisor软件，这个软件作为应用程序管理多个Guest VM。

可以看到，Type 1 和 Type2的虚拟化最大区别在于Type 1的Hypervisor可以直接操作硬件，没有多余的开销，性能相对比较高；Type2的Hyperviosr访问硬件资源，还必须经过Host OS。可以看到座舱域仪表和中控使用的就是Type1类型的虚拟化技术。

因此在汽车领域，由于对功能安全等级、实时性有较高要求，一般均使用 Type1的Hypervisor，Hypervisor 之上直接运行多个客户操作系统 (GuestOS)；那么这里就出现了今天的首个问题，Hypervisor是如何来管理和隔离硬件资源，保证各个不同功能的应用程序的资源使用安全和资源调度？这个我们稍后再谈。