基于Hypervisor智能驾舱的AUTOSAR解决方案

本文主要是介绍基于Hypervisor智能驾舱的AUTOSAR解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

MENTOR嵌入式管理程序

目前，通常使用两种类型的管理程序（图6）：

Type 1本机管理程序：一种在硬件上本机运行的管理程序，因为它充当核心中的操作系统。
Type 2托管虚拟机监控程序：此类型的虚拟机监控程序必须由另一个操作系统托管，并且仅负责使用主机操作系统可用的资源来虚拟化客户操作系统。

图6：虚拟机管理程序虚拟化的工作原理是从硬件上运行的应用程序中抽象出物理硬件和设备。虚拟化流程管理和配置该系统的资源，包括处理器、内存、存储和网络资源。这使该系统能够同时承载多个工作负载，从而在整个企业中以更具成本效益和能源效率的方式利用可用的服务器和系统。虚拟化需要利用虚拟机管理程序，该管理程序通常称为虚拟机监视器或VMM。虚拟机管理程序是一个软件程序，它提供抽象层，处理物理和虚拟资源(例如物理与虚拟CPU或内存)之间的转换，并管理虚拟机(VM)的创建和支持。

虚拟机管理程序运行的物理硬件通常称为主机，而管理程序创建和支持的VM统称为客户机。

Type 1和Type 2管理程序差异

Type 1虚拟机管理程序直接在主机的物理硬件上运行，它被称为裸机虚拟机管理程序;它不必预先加载底层操作系统。通过直接访问底层硬件而无需其他软件(例如操作系统和设备驱动程序)，Type1虚拟机管理程序被视为用于企业计算的高效性能优越的虚拟机管理程序。同时，管理程序直接在物理硬件上运行也非常安全，因为裸机虚拟机管理程序可避免操作系统通常存在的安全问题和漏洞。这可确保每个访客VM与恶意软件和活动保持逻辑隔离。

Type 2虚拟机管理程序可追溯到x86虚拟化的早期阶段，当时已有系统已经在使用操作系统并且虚拟机管理程序被部署为更高的软件层。虽然Type 1和Type 2管理程序的目的和目标是相同的，但是对于Type 2虚拟机管理程序而言，底层操作系统的存在会引入不可避免的延迟，因为所有该管理程序的活动和每个VM的工作都必须通过主机操作系统。此外，主机操作系统中的任何安全问题或漏洞都可能会危及在其上运行的所有虚拟机。

因此，Type 2管理程序通常不用于数据中心计算，并且仅用于客户端或最终用户系统(有时称为客户端管理程序)，其中性能和安全性较少受到关注。例如，软件开发人员可能会使用Type 2虚拟机管理程序创建VM，以便在发布之前测试软件产品。

Mentor嵌入式管理程序是第一种类型的管理程序，对于嵌入式系统应用程序而言，它本质上更为方便，在这种应用程序中，操作系统足够简单，可以在具有确定性行为的硬件上本地运行。对于Arm目标，Mentor虚拟机管理程序利用Arm虚拟化扩展，使简单的类型1虚拟机管理程序的选择更适合CPU虚拟化的设计。Arm引入了一种新的HYP模式，该模式不像其他模式那样具有丰富的寄存器，因此管理程序需要足够简单才能利用这些寄存器。Mentor的虚拟机管理程序针对嵌入式应用程序，并使用微内核体系结构进行设计，其中内核核心整合了虚拟机管理程序在物理硬件上运行所需的最基本功能。这种方法具有许多好处，可通过配置增加其他组件和服务，并且它减小了系统中可信计算基的大小，从而使系统最关键的部分更容易达到最高安全级别。它还根据来宾需求（例如未使用的功能）通过将相应功能从虚拟机监控程序映像中删除来最小化虚拟机监控程序的内存占用。

图7：Mentor嵌入式Hypervisor Mentor嵌入式管理程序（图7）还利用Arm TrustZone在虚拟机之间提供更好的隔离，并支持多种类型的来宾OS，例如：

▪安卓 ▪AUTOSAR ▪Mentor嵌入式Linux ▪Nucleus RTOS

来宾之间的硬件设备访问

Mentor嵌入式Hypervisor提供了多种用于硬件设备访问的模型，从而在系统设计中提供了更大的灵活性。其中一些模型包括：

直接访问：将硬件设备分配给允许直接访问的虚拟机专有。这种情况适用于硬件设备只能由一个虚拟机使用，其无需管理程序干预，系统性能得到了优化提高。
共享访问：当硬件设备由虚拟机拥有并且该设备是共享时，则在虚拟机级别完成对硬件的访问处理。
模拟访问：一种用于在虚拟机之间共享硬件设备的通用模型，在每个虚拟机认为它拥有硬件设备的同时，虚拟机监控程序通过陷阱来模拟对设备的访问控制。
虚拟访问：类似于虚拟机管理程序模拟了对硬件设备的访问，但是虚拟机不拥有硬件设备，并使用虚拟驱动程序进行硬件访问，从而消除了对设备进行模拟访问的需要，从而减少了虚拟访问及开销。

虚拟设备的VirtiO支持

虚拟设备访问模型被认为是一种准虚拟化技术，因为它要求虚拟机实现与虚拟机管理程序的软件接口，以便无需任何类型的模拟访问即可处理虚拟设备访问。

VirtIO是半虚拟设备驱动程序的虚拟化标准，提供了标准的应用程序可编程接口，因此虚拟机管理程序和虚拟机可以使用它与常见的虚拟设备进行交互。如图8所示，VirtIO架构设计包括在来宾中实现的前端驱动程序，在管理程序中实现的后端驱动程序以及处理来宾和管理程序之间的通信的虚拟队列。每个VirtIO设备将具有自己的前端驱动程序和最终驱动程序实现。除了前端驱动程序（在来宾操作系统中实现）和后端驱动程序（在 hypervisor 中实现）之外，virtio 还定义了两个层来支持来宾操作系统到 hypervisor 的通信。在顶级（称为 virtio）的是虚拟队列接口，它在概念上将前端驱动程序附加到后端驱动程序。驱动程序可以使用 0 个或多个队列，具体数量取决于需求。例如，virtio 网络驱动程序使用两个虚拟队列（一个用于接收，另一个用于发送），而 virtio 块驱动程序仅使用一个虚拟队列。虚拟队列实际上被实现为跨越来宾操作系统和 hypervisor 的衔接点。但这可以通过任意方式实现，前提是来宾操作系统和 hypervisor 以相同的方式实现它。

Mentor虚拟机管理程序对VirtIO设备使用内存映射输入输出（MMIO）方法，并支持VirtIO Net，VirtIO Block和VirtIO Console设备。Linux也支持VirtIO。图8：VirtIO架构概述。

汽车软件的虚拟化

用于解决本文前面所述的复杂性（座舱域单元）的当前方法既成本高昂又缺乏性能。在应对这些复杂性时，在汽车软件体系结构中使用虚拟化将提供更好的方法。这可以通过将不同的异构汽车平台封装在运行于同一硬件上的虚拟机中来实现。这种方法不仅通过使用VM间通信而不是串行连接提供了一种更有效的通信方式，而且还减少了向每个平台添加专用微控制器的成本。通过将遗留平台重用为封装的虚拟机，也无需新的适应工作，从而降低了开发成本。

可以使用简单的共享内存访问技术或通过使用更多的结构化框架（例如VirtIO）来实现VM间通信。尽管AUTOSAR不支持VirtIO，但它提供了一个称为复杂设备驱动器（CDD）的规范，该规范允许以标准化方式集成不受支持的驱动程序，例如VirtIO。

尽管虚拟化可以为汽车软件带来好处，但这种方法的适用性取决于对应用程序性能的评估-在虚拟化环境中运行时，请确保仍然满足系统的严格实时要求。

系统实施

本节介绍如何在Mentor虚拟机管理程序中封装AUTOSAR和Linux来宾，以在TI Jacinto 6信息娱乐平台上运行。

MENTOR 管理程序配置

由于虚拟机管理程序被设计为微内核，因此它允许用户根据来宾需要配置将哪些驱动程序和组件添加到虚拟机管理程序映像中。来宾信息通过设备树源文件（DTS）提供给管理程序。这些文件由Mentor虚拟机管理程序数据驱动的配置绑定定义，并由虚拟机管理程序用于了解虚拟机的数量，地址映射，分配给每个虚拟机的资源以及虚拟设备的数量。系统管理程序解析项目配置并生成二进制文件后，它将使用映像树源文件（ITS）将所有来宾二进制文件以及系统管理程序二进制文件打包到单个整体映像中，然后可将其部署在目标硬件上。

虚拟GUESTS

对于Linux来宾，Mentor嵌入式Linux使用了预先构建的映像，该映像是基于Yocto Project的商业Linux发行版，并包含对嵌入式应用程序有用的丰富功能集。Mentor嵌入式Linux通过半虚拟化层进行虚拟化，从而可以在虚拟机管理程序上运行。对于AUTOSAR来宾，VSTAR实施AUTOSAR标准。VSTAR OS无需进行任何虚拟化工作即可在Arm®Cortex-A15硬件上运行，这显示了Arm中硬件辅助虚拟化扩展的强大功能。但请务必注意操作系统支持哪种类型的计时器。在虚拟环境中，来宾OS直接使用物理计时器是不切实际的，因为这会增加可能影响应用程序性能的仿真开销。另一种解决方案是使用Arm虚拟计时器或为虚拟机分配专用的通用计时器，因此不需要模拟来宾对该计时器的访问。

来宾配置中的另一个关键因素是虚拟机到CPU内核的映射。多个虚拟机之间的CPU共享会导致上下文切换开销，并增加设计的复杂性，因为这将取决于所使用的调度算法。这将影响应用程序性能，并且不适用于实时虚拟机，因为需要保证确定性的行为才能满足所有硬定时要求。因此，将在虚拟机和CPU之间使用一对一的映射。

AUTOSAR演示

对于AUTOSAR演示应用程序，目标是达到时间表的严格实时要求到期点触发。在虚拟化环境中实现此目标的关键因素是：

IRQ路由到虚拟机
通用中断控制器访问
虚拟计时器访问图9概述了该演示。AUTOSAR应用程序在专用的虚拟机上作为VM1运行核心，应用程序利用AUTOSAR密码库执行MAC的两个操作验证和AES解密（每100毫秒）的加密数据，并负责另一个应用程序处理解密的数据。这是使用调度表（图10）进行组织的，该调度表是AUTOSAR OS实体包含多个具有固定偏移量的到期点，以确保数据解密和数据处理任务之间的相对同步。图9：AUTOSAR演示平台模型

图10：时间调度表和任务激活

Linux应用程序在专用内核上作为VM2运行，并与管理程序共享UART控制台，以允许在管理程序控制台和Linux控制台之间切换，后者允许与Linux文件系统接口（图11）。

图11：在Mentor虚拟机管理程序和Mentor嵌入式Linux控制台之间切换

AUTOSAR应用程序运行结果

在虚拟环境中运行时，CPU的总负载仅增加了约0.2％，这是 IRQ路由和管理程序调度程序处理增加的开销。这代表最低系统管理程序为运行VSTAR OS的基本功能而引入的开销。通过分析AUTOSAR应用程序的时序行为，以检查应用程序运行期间虚拟机监控程序开销的影响。通过VSTAR OS提供hook函数例如进入内核，退出内核，更改某些任务的状态，触发事件/警报等这些执行路径上的关键点，并结合读取通用计时器来监视应用程序运行期间关键事件的计时。

由于没有虚拟计时器访问或GIC CPU接口访问的开销，因此在虚拟环境中运行时，AUTOSAR OS的内核进入和退出时间没有任何变化。IRQ路由时间非常短（1 GHz时钟频率为561纳秒），因此OS定时器中断的等待时间不受影响。此外，VSTAR AUTOSAR OS还可以用作无滴答计时器，定时器中断仅在OS操作点上触发，而不是在每个固定的时间段上触发。结果，无滴答计时器功能限制了所需的虚拟计时器中断次数，并减少了IRQ路由的开销-调度表到期点和调度任务的时间均未受到影响。经过验证，用AUTOSAR OS运行时测量，在虚拟环境中运行时，应用程序性能不会受到影响。