虚拟化：用于车辆控制的整容提升

作为FACE（未来机载能力环境）成功成果的证明，自FACE 2.0发布以来，几乎每个适用的军事项目对任务系统软件的强制性一致性要求都下降了。但是，即使FACE告知并指导战术任务系统软件设计的各个方面（通信，飞行控制，飞行地图和规划，驾驶舱显示等），车辆控制领域对FACE的采用持保留态度。交付安全关键型硬实时控制系统的必要性引发了人们对FACE多核操作系统段（OSS）固有的复杂性所阻碍的技术可行性的担忧。

最近在车辆控制项目（特别是基于多核处理器的项目）方面的经验已经证明，将CPU虚拟化作为一种强大的工具，可以补充操作系统解决软件组件之间的集成冲突，这些软件组件与平台要求在API ［应用程序编程接口］兼容性和架构假设方面差异很大。

未来机载能力环境 （FACE） 标准将虚拟化主要视为一种硬件整合工具。但随着世界在无人驾驶车辆的发展中不断向前推进，整合车辆控制和任务系统计算的需求将成为强制性的，并且关注点将更加相关。鉴于虚拟化能够实现核心 FACE 原则，其中硬实时控制至关重要，因此值得进一步考虑虚拟化。

人脸的愿景

多年来，军事系统主要基于专有应用程序、中间件、操作系统和/或硬件。这种情况导致了一些问题，包括交货时间长、成本高以及重用现有技术的机会很少。在竞争性招标中对系统进行修改是不可能的，因为唯一有能力进行更改的供应商是原始系统的供应商。

FACE联盟 - 行业供应商，政府专家，学术界和客户之间的合作伙伴关系 - 旨在解决这些问题。在军用航空电子系统中使用开放标准的标准化方法有望降低实施成本，加速开发，确保稳健的架构和始终如一的高质量软件实施，并最大限度地增加重用机会。

航空电子系统中的虚拟化

嵌入式航空电子系统中多核虚拟化的许多好处都有据可查。将具有各种操作系统和应用程序的多台传统单板计算机 （SBC） 整合到单个多核虚拟化 SBC 中的能力被广泛认为是下一代航空电子设备最切实的好处。然而，CPU 虚拟化和虚拟机管理程序提供与实时性能、软件可组合性和架构健壮性相关优势的能力对于资深嵌入式软件社区来说鲜为人知。以下各节讨论在 FACE 参考体系结构上下文中应用的这些优势： 专用分区段，简化实时空间，提高可移植性和重用性。

专用分区段

在过去的十年中，通过CPU虚拟化在单个处理器上运行多个操作系统的能力有了相当大的进步。虽然底层硬件在IT世界中得到普及和普遍采用，但它具有对关注稳健性和可预测性的嵌入式工程师同样具有吸引力的功能。

在传统的平台软件设计中，每个处理器托管一个操作系统 （OS） 内核，负责管理内存分配、执行调度、中断路由、异常处理、外设控制和总线多路复用。现在，支持虚拟化的多核硬件现在能够容纳许多内核，每个内核都分配了不同类型和大小的资源子集。因此，可以在单个设备上实现多个独立的软件运行时，而不会受到公共内核的干扰和随之而来的共模故障危险。这些功能增强了与安全和安保问题相关的基本体系结构属性。

从安全角度来看，使用内置 CPU 虚拟化功能来隔离硬件安全功能，并将应用程序运行时服务与硬件控制接口分开，对于确保系统稳健性大有帮助。这种设计技术消除了通常被利用的威胁向量，这些威胁媒介会导致安全策略绕过、权限提升和完全失去 CPU 控制。

从安全角度来看，使用虚拟化分区功能（例如：

DMA 通道隔离

共享的最后一级缓存分区

内存总线带宽分配

独立的中断、事件和异常处理

在硬件级别以更高的保真度强化和控制软件分区的能力符合 FACE 的理想。图 1 中显示的图表介绍了由 FACE 参考体系结构的虚拟机管理程序实现的“硬件分区段”的概念。该描述显示了一个虚拟机管理程序，该管理程序在两个不同的 CPU 内核上隔离了两组软件。每组都配置了符合 FACE 标准的组件。每组软件在单个操作系统托管的设计上被授予更大的分区属性，其中设备驱动程序和内部服务是分开的。

［图1 |具有 CPU 虚拟化辅助硬件分区段的 FACE 配置示例。

简化实时空间

在FACE中添加另一个部分将是一项重大任务。在操作系统下引入另一类技术和软件层对于对复杂性持谨慎态度的实时和安全意识开发人员来说似乎适得其反。但是，CPU 虚拟化提供的硬件分区和多路复用功能提供了在处理器上封装和映射关键任务的运行时功能子集的机会，该处理器同时托管具有固有更丰富的运行时和服务依赖关系的应用程序。

例如，假设车辆控制运行状况监视器应用程序（如 TMR ［三模块冗余］ 错误检测所需的高频多数投票 CBIT ［连续内置测试］必须与多核处理器上的飞行计划应用程序一起运行。使用基于虚拟机监控程序的解决方案，而不是在共享相同网络堆栈和内核的同一操作系统上同时实现这两个应用程序，运行状况监控应用程序（如图 2 所示）可以是：

映射到单独的 CPU 内核

映射到单独的以太网 MAC

根据独立的线程调度算法运行

与正交中断和阻塞信号量隔离

与 DMA 和操作系统内核内存访问错误隔离

在优化的、简约的、符合 POSIX 标准的运行时环境中运行

［图2 |具有独立实时分区的人脸配置示例。

对于希望简化最坏情况执行时间 （WCET） 分析的实时程序员来说，结果是一个理想的场景。然而，在线路可更换单元 （LRU） 级别，该平台保留了托管具有更丰富的传输服务段 （TSS） 和操作系统段 （OSS） 功能要求的应用程序的能力，这些应用程序不太关心时间和完整性危害。

可移植性和重用

军事程序经常受到板级支持包 （BSP） 非经常性工程 （NRE） 成本的困扰，如果内部平台软件更便携，则可以避免这些成本。众所周知，低级代码模块（尤其是驱动程序）在提供重用和互操作性的有价值的属性方面存在问题。

标准化操作系统内部内核接口是不切实际的，因为它们具有独特的设计和（在许多情况下）专有性质。但是，几类设备驱动程序自然独立于核心服务，需要最少的操作系统功能支持（如文件系统），可以通过虚拟机监控程序隔离，并通过标准进程间通信 （IPC） 接口与应用程序集成。

可以证明，设备可以独立于操作系统进行控制，并与其他组件集成，而无需嵌入专有的操作系统依赖项。考虑一个 OpenGL UA 应用程序，它只需要能够访问 GPU 设备接口的驱动程序。另一个示例：具有 TSS 兼容 I/O 接口的独立 MIL-STD-1553 服务，可用于 PCS ［便携式组件段］ 应用程序（参见图 3）。

［图3 |独立一致性单位 （UoC） 的示例。

TSS 层和本地应用程序运行时软件无需依赖资源映射和 IPC 传输的操作系统实现，而是具有足够的功能来定位依赖模块并与使用标准虚拟机管理程序提供的接口和服务集成。这种方法甚至可以遵循 FACE 一致性单位 （UoC） 包装要求。这一愿景并不牵强，因为诸如OASIS“VIRTIO”之类的虚拟化标准已经存在并且已经确立。正如FACE依靠POSIX来维护OSS的标准规范一样，VIRTIO也可以同样支持提议的硬件分区段。

虚拟化适用于人脸

FACE取得了巨大的成功。但迄今为止，FACE的可移植性和互操作性优势通常仅限于TSS层以上操作系统托管的任务系统软件。

使这种情况恶化的是，将军用航空电子设备瞄准无人系统的发展可能会看到任务系统与车辆控制计算领域的潜在界限减少，FACE的局限性变得更加令人恼火。

为了履行其章程，FACE必须满足车辆控制软件的需求。最近在车辆控制子系统方面的经验已经证明，虚拟化是降低平台软件复杂性的一种手段，可以划分出低级硬件控制访问，同时提供分区和互操作性接口的广为人知的架构优势。推进这些低级能力的标准化，可以弥合车辆控制开发在FACE合规性可行性方面的差距，而不会玷污现有FACE规定对任务系统开发的无可置疑的好处。

审核编辑：郭婷