基于Hypervisor的汽车域控制器解决方案

概述了基于Hypervisor的汽车域控制器方案出现的原因及其基本架构;介绍了虚拟机监挫器的不同类别及其优缺点和适用场景;介绍了 PikeOS Hypervisw虚拟化和分区间通信的原理及基本应用；设计了适用于PikeOS Hypervisor的 RTOS和Linux体系；设计了 PikeOS Hypervisor上RTOS分区和Linux分区间的通信程序和脸证方法；设计了 PikeOS 实时性能的测试程序;并在赛灵思ZCU 104单片机上运行从而验证了设计方案的可行性。

引言

当今的汽车制造商正竞相通过使用人机界面(HMI）,基于云的服务，车辆自组织网络(VANET)和自动驾驶等技术在未来的车辆中部署这些创新的新功能。这些新技术增加了车辆电气和电子(E/E)架构的复杂性，并要求软件系统要支持汽车间及汽车和云端的互连及交互。随着现代车辆中100多个ECU的出现，电子控制单元(ECU)的数量不断增加。这迫使汽车OEM厂商将多个单元整合到一个单一的高计算平台中。

尽管这种方法简化了车辆的网络模型，但它给汽车软件系统架构带来了更多挑战。这些挑战同样存在于智能座舱, 高级驾驶员辅助系统(ADAS),智能穿戴设备和远程信息通信系统等领域中。更复杂的是，这些软件应用程序中对在安全性和互连性方面有更严格的实时性和功能安全性要求。对车载通信和对安全性有严格要求的系统通常需要实时操作系统(RTOS)，而与安全性无关的信息娱乐应用程序或基于AI的无人驾驶应用程序则在Linux通用操作系统上运行。两个OS的组合使这些应用程序具有异构性质。

可以在同一电子控制单元上添加两个微控制器(MCU)。一个MCU运行基于Linux的应用程序，该应用程序负责AI等算法和信息娱乐功能等高计算任务，而另一个MCU运行通常用于车载和诊断通信的简单、实时的应用程序。这两个MCU通过串行外围设备接口连接，从而允许这两个应用程序之间进行通信。

尽管此方法允许重用标准软件体系结构，但为每个系统添加专用硬件效率不高且成本很高。而且，通过串行通信接口在这些系统之间大量的数据通信无法保证其通信的可靠性。另一种方法是在Linux上移植实时应用程序。这种方法很难满足汽车行业的实时性和安全性要求。

而通过使用高性能的Embedded Hypervisor硬件和虚拟化技术可在同一处理器上整合多个操作系统。这是开发异构的汽车应用程序的有效方法。本文介绍如何使用PikeOS Hy-pervisor程序将实时RTOS应用程序与基于Linux的应用程序整合在同一 ECU,并通过共享内存进行相互通信。所描述的解决方案使用Xilinx ZCU104评估板。

1 虚拟化架构与方法

本节定义了虚拟化环境的特征以及用于满足异构汽车应用程序要求的方法。

1.1 虚拟化的环境

实现一致的虚拟化环境的核心在于处理影响处理器硬件状态的敏感指令。实现此目的技术可以分为全虚拟化、半虚拟化和硬件辅助虚拟化等三类。

图1 全虚拟化结构

全虚拟化:全虚拟化(Full virtualiz ation),也称为原始虚拟化技术，它使用虚拟机协调客户操作系统和原始硬件。Guest OS发出的指令必须由Hypervisor(虚拟机管理程序)来捕获和处理。全虚拟化的运行速度要快于硬件模拟，但是性能方面不如裸机，因为Hypervisor需要占用一些资源。全虚拟化最大的优点是操作系统无须经过任何修改。

半虚拟化:半虚拟化(Paravirtualization)是另一种类似于全虚拟化的技术。在半虚拟化下，修改Guest OS内核，将原生设备 驱动从Guest OS中移出，放入经Hypervisor授权的设备虚拟机 (Privileged VM)中，在每个Guest OS中内部，系统为每个virtual I/O设备安装一个特殊的驱动程序(Parameter Virtualization Driver)，由该驱动程序负责I/O请求的传递。设备虚拟机在经过VMM授权后,解析收到的I/O请求并映射到实际物理设备, 最后交给它的原生设备驱动程序来控制硬件完成。因此操作系统自身能够与虚拟进程进行很好的协作。优点在于耗费资源相对少，性能提高。缺点是只能运行经过相应修改的Guest OS。

图2 半虚拟化结构

硬件虚拟化又称 Hardware Assisted Virtualization，Hypervi-sor需要硬件的协助才能完成对硬件资源的虚拟，基本思想是引入新的指令和处理器运行模式，使得Hypervisor和Guest OS运行在不同的模式下,Guest OS只能在受控的模式下运行，当需要Hypervisor进行监控和模拟时，由硬件支持模式切换，如Intel-VT和arm-v8中新增Hypervisor工作模式,特权和敏感调用自动陷入hypervisor,不再需要二进制翻译或半虚拟化器。

1.2 内存虚拟化

在虚拟化平台上，Guest OS中的地址转换包括从虚拟地址(WrtualAddress)到中间物理地址(Intermediate Physical Ad-dress),以及从中间物理地址到物理地址(Physical Address)两个地址转换阶段，以使Guest OS内核对内存地址的管理与物理内存脱钩。这是通过使用第二阶段页表转换将中间物理地址转换为物理地址来实现的。图3显示了在虚拟机管理程序上运行的虚拟机的地址转换阶段。

图3 虚拟机管理器地址转换

1.3 嵌入式虚拟机管理器

虚拟机管理器，又称Hypervisor,它提供抽象层,处理物理和虚拟资源(例如物理与虚拟CPU或内存)之间的转换，并管理虚拟机(VM)的创建和支持。目前，通常使用两种类型的管理程序(图4)：

Type 1裸机虚拟机管理程序：一种在硬件上本机运行的管理程序，因为它充当核心中的操作系统。

Type 2托管虚拟机监控程序：此类型的虚拟机监控程序必须由另一个操作系统托管，并且仅负责使用主机操作系统可用的资源来虚拟化客户操作系统。

图4 虚拟机管理器种类

Type 1虚拟机管理程序不必预先加载底层操作系统。通过直接访问底层硬件而无需其他软件(例如操作系统和设备驱动程序)，Type1虚拟机管理程序移植成本较高,但管理程序直接在物理硬件上运行相对较安全叫因为裸机虚拟机管理程序可避免操作系统通常存在的安全问题和漏洞。这可确保每个访客VM与恶意软件和活动保持逻辑隔离。

对于Type2虚拟机管理程序而言，底层操作系统的存在会引入不可避免的延迟，因为所有该管理程序的活动和每个VM的工作都必须通过主机操作系统。此外，主机操作系统中的任何安全问题或漏洞都可能会危及在其上运行的所有虚拟机。因此，Type2管理程序通常不用于数据中心计算，并且仅用于客户端或最终用户系统，其中性能和安全性较少受到关注。

如图5所示,PikeOS Hypervisor是Type 1型的管理程序» 它基于一个提供核心功能的小型微内核。通过这些功能，可以将系统资源(例如内存,I/O设备,CPU时间等)划分为单独的子集。PikeOS微内核用作虚拟机管理程序或虚拟机监视器 (VMM),并捕获用户程序执行特权指令或以其他方式访问其集合以外资源的任何尝试。

图 5 PikeOS Hypervisor 架构

1.4 分区间通信

PikeOS内核提供了通信机制，允许不同分区的线程通过 共享内存交换数据并彼此同步，又称为分区间通信(IPC,Inter Partition Communication)。

IPC消息类型。

数据复制：将数据从发送线程的地址空间复制到接收线程的地址空间。

数据映射：映射消息允许发送方与另一任务共享其内存的一部分。内存区域必须是页面对齐的(P4_PAGESIZE),但是没有大小限制。

IPC消息传递有一个系统调用:p4_ipc()。在单个呼叫期间,它可以按以下顺序执行四个转移操作：

(1)使用数据复制将消息发送到线程；

(2)使用数据映射将消息发送到线程；

(3)使用数据复制从线程接收消息；

(4)使用数据映射从线程接收消息。

p4_ipc()还能够在等待IPC接收时等待事件，在标志参数中设置P4_IPC_EV_RECV。执行阶段如下：

图6 分区间通信步骤

阶段1：PREP

准备阶段PREP是初始阶段，针对每个对p4_ipc()的调用 执行。在这里,PikeOS内核副本将用户参数放入内核空间，并检查发送和接收消息描述符的内容。

阶段2：SEND_WAIT

SEND_WAIT阶段涵盖了直至但不包括实际消息传输的所有步骤。它允许发件方以使其执行与接收器同步。发送者仅在接收者准备就绪时离开此阶段(具有完成RECV_WAIT)或发生超时或IPC取消。

阶段3：SEND_BUF

在阶段SEND_BUF中，已复制的数据将从发送线程的地址空间复制到收件方的地址空间

阶段4：SEND_MAP

在阶段SEND_MAP中,将在接收者的地址空间中创建到包含以下内容的物理内存的映射:映射消息的数据。

阶段5：RECV_WAIT

RECV_WAIT阶段与SEND_WAIT阶段相当，但是从接收方的角应来看。它允许接收方，以使其与发送方同步。接收方仅在发送方准备好后才离开此阶段(已完成SEND_WAIT)或收到事件，或者发生超时或IPC取消。

阶段6：RECV_BUF

在阶段RECV_BUF中，已复制的数据将从发送线程的地址空间复制到收件方的地址空间。

阶段7：RECV_MAP

在阶段RECV_MAP中，在接收方的地址空间中创建到包含以下内容的物理内存的映射：映射消息的数据。

阶段8：完成

当IPC的发送和接收部分均已正确完成时，最后阶段 DONE终止系统调用，并返回带有成功完成代码的用户应用程序代码。如有必要，返回给用户之前，可以清除线程的事件计数器。 

2 系统实施与配置

本节介绍如何在PikeOS虚拟机管理程序中封装RTOS和Linux来宾,并在RTOS的应用和Linux的应用之间实现分区间通信。 

2.1 PikeOS Hypervisor 配置原理

由于虚拟机管理程序被设计为微内核，因此它允许用户根据来宾需要配置将哪些驱动程序和组件添加到虚拟机管理程序映像中。在PikeOS的开发软件CEDEO中，由integration project来整合所有的系统、驱动、应用配置，生成供硬件的二进制文件。

图7 PikeOS Hypervisor软件开发结构

如图7所示Integration project中有各类项目的custom pool,其中存放RTOS (PikeOS)原生应用和Linux内核的 GUEST OS(ElinOS),对于pikeos内核和原生驱动的修改可以基于kernel fusion project, System Software Fusion Project进行。各个分区之间的通信等设置由VMIT进行配置。系统管理程序解析项目配置并生成二进制文件后，它将使用映像树源文 件(ITS)将所有来宾二进制文件以及系统管理程序二进制文件打包到单个整体映像中,然后可将其部署在目标硬件上。

2.2 虚拟Guests OS配置

图8 ElinOS配置

对于Linux OS, PikeOS Hypervisor使用了预先构建的Lin-ux发行版，名为ElinOS，其包含对嵌入式应用程序有用的丰富 功能集。ElinOS通过半虚拟化层进行虚拟化，从而可以在虚 拟机管理程序上运行。如图8所示，在PikeOS Hypervisor里为ElinOS分配资源分区和通信端口。

对于RTOS, PikeOS Hypervisor使用预先构建的PikeOS, PikeOS的概念结合了实时操作系统(RTOS)、虚拟化平台和基 于Eclipse的嵌入式系统集成开发环境(IDE)。

2.3 IPC配置

本文构建的分区间通信体系由一个控制器应用程序Con-troller application和一个计算器应用程序Calculator application组成。Controller application在ElinOS分区，Calculator application 位于PikeOS分区。Calculator application简单地无限执行计算循环,将执行的迭代次数写入共享内存。Controller application定期读取共享内存，并显示每个计算器执行的迭代次数。应用程序将IPC通道用作交换控制信息(如任务ID和共享内存地址)的机制。

图9 IPC结构

其后为每个application配置输入和输出的通道口，并在 VMIT(Virtual Machine Initialization Table)中为通道口建立连接，如图10所示。

图10 通道口配置

为其通信创建和分配适当大小的共享内存，如图11所示。

图11 共享内存配置

2.4 实时性测试

为校验在ZCU104上同时部署ElinOS和PikeOS是否会影响PikeOS的实时性,分别在仅部署PikeOS和同时部署Eli-nOS和PikeOS的情况下，在PikeOS分区构建名为Real-Time Verification的应用，测试程序的基本思路如下：对于Task A、Task B，假设初始时刻A处于运行状态，而B处于阻塞状态，在时间t0时，任务A唤醒B，在时间t1时，任务B开始恢复执行。那么，任务响应时间就是t1-t0这一段时间。通过设置多组任务，循环多次测试，即可计算得到任务平均响应时间taverage-response和最坏响应时间tworst-response。以任务平均响应时间和最坏响应时间作为RTOS实时性的评价标准。

3 测试结果与验证

在PC上通过PikeOS CEDEO配置的镜像传输到Xilinx ZCU104单片机上，用串口线连接PC和ZCU104评估板，用PC上的putty软件打印显示ZCU104的启动信息和运行信息。

相对于只在ZCU104上运行ElinOS，在虚拟环境中同时部署ElinOS和PikeOS，启动时间仅增加不超过7%，这是管理程序调度程序处理增加的开销。这代表最低系统管理程序为运行PikeOS的基本功能而引入的开销。

表 1 PikeOS Hypervisor 启动时间

可以从console中看到，Hypervisor启动后，ElinOS和Pi-keOS 都正常启动，并且Controller application开始循环将Calculator application的执行的迭代次数输出到console上。

图12 console输出

经过验证，用PikeOS Hypervisor实现了在同一块ECU上实现Linux和RTOS的同时部署，并能较好得保证RTOS的实时性。同时可以方便得通过共享内存实现Linux application和RTOS application的相互通信。

对于实时性测试，结果如下图所示，相对于单独部署PikeOS, 同时在ZCU104上部署ElinOS和PikeOS时任务平均响应时间和最坏响应时间均未明显提高。

图13 实时性测试结果

4 结语

在移动机器人路径规划过程中，为解决由机器人转角带来的时间浪费，本文提出在传统遗传算法的基础上添加角度控制与路径信息融合，同时加入插入算子与删除算子。最后在MATLAB建立的栅格环境下进行了验证，结果显示相比于传统的遗传算法，改进的遗传算法在转弯，搜索效率，收敛速度得到了提升，改进的遗传算法在路径规划上是有效。

参考文献：

[1] 宋宇，王志明.基于改进遗传算法的移动机器人路径规划 [J],现代电子技术,v.42;No.551(24):172-175. 

[2] Tuncer A , Yildirim M . Dynamic path planning ofmobile robots with improved genetic algorithm [J]. Computers & Electrical Engineering, 2012, 38(6):1564-1572. 

[3] FAN Yuan, LI Wenfeng, HE Lijun.基于改进遗传算法的智 能仓储多移动机器人协同调度[J].武汉理工大学学报(信息与管理工程版),2019, 041(003):293-298,311. 

[4] Deng L, Ma X, Gu J, et al. Planning multi-robot formation with improved poly-clonal artificial immune algorithm[C]// 2013 IEEE International Conference on Robotics and Biomimetics (ROBIO). IEEE, 2013. 

[5] Karami A H , Hasanzadeh M . An adaptive genetic algor-ithm for robot motion planning in 2D complex environments[J].Computers & Electrical Engineering, 2015, 43: 317-329. 

[6] Yi Z, En-Can D, Tong-Hui R. Path Planning of Mobile Robot Based on an Improved Genetic Algorithm[J]. 2016. [7] Lin D, Shen B, LiuY, et al. Genetic algorithm-based compliant robot path planning: an improved Bi-RRT-based initialization method [J]. Assembly Automation, 2017, 37(3): 261-270. 

[8] Ni J, Wang K, Huang H, et al. Robot path planning based on an improved genetic algorithm with variable length chromosome[C]//2016 12th International Conference on Natural Computation and 13th Fuzzy Systems and Knowledge Discovery (ICNC-FSKD). IEEE, 2016. 

[9] Jun H , Qingbao Z . Multi-objective Mobile Robot Path Planning Based on Improved Genetic Algorithm[M]. 2010. 

[10] Lee J , Kim D W . An Effective Initialization Method for Genetic Algorithm-based Robot Path Planning using a Directed Acyclic Graph[J]. Information Sciences, 2015, 332.

文章转载自公众号：智能汽车开发者平台