嵌入式虚拟化支持多核实时应用程序的可扩展性

嵌入式虚拟化对 OEM 有几个积极的影响。例如，一旦有一种方法可以拆分应用程序以在多个内核上运行同时保持确定性，该解决方案随后可以使实时应用程序能够向上或向下扩展它们使用的内核数量。借助可扩展性，OEM 可以为其产品提供一系列性价比选项，而无需更改软件。

虚拟化在计算机科学中并不是一个新概念，但随着多核处理器的出现，它引起了新的兴趣。尽管虚拟化被认为是保持多个处理器内核忙碌的一种方式，但需要注意的是，大多数类型的服务器或客户端虚拟化并非旨在满足时间关键型嵌入式处理的需求。这些虚拟化方法通常以相同的方式对待多核芯片上的所有处理器。在这些系统中，单个操作系统 （OS） 在处理器可用时将任务分配给处理器，以试图使所有处理器尽可能地负载处理任务。

服务器和客户端虚拟化通常会虚拟化所有硬件，包括 I/O 接口。当 I/O 接口需要服务时，虚拟机监视器 （VMM） 会处理请求并将结果传递给它所支持的操作系统客户端。没有办法确保在属于该客户端的 I/O 需要服务时加载特定的 OS 客户端，也没有一种全局方法可以将特定 I/O 与客户端 OS 和在其上运行的应用程序相关联。因此，无法准确保证处理 I/O 事件需要多少时间。因此，这种方法不适用于处理嵌入式系统中的实时处理。

嵌入式系统设计人员希望直接控制系统以获得确定性和一致的性能。虽然需要平衡整体处理器利用率并保持多核处理器尽可能繁忙，但这并不是首要任务。首先，嵌入式设计人员正在寻找能够帮助他们在增加功能和/或降低 OEM 产品成本的同时保持确定性的软件技术。

嵌入式设计人员正在寻找一种软件平台，使他们能够组合不同类型的操作系统，以便针对手头的任务优化处理——例如，处理关键 I/O 时序要求的实时操作系统和通用操作系统（ GPOS） 来利用 COTS 图形丰富的应用程序，这些应用程序运行人为导向的功能。他们还在寻找扩展应用程序的解决方案，以便他们可以使用相同的应用程序代码库提供不同的产品。这降低了工程开发成本，缩短了上市时间，更重要的是，使新产品能够基于经过验证的软件，这些软件可以在性能和可靠性方面不断升级。

嵌入式虚拟化保留了确定性

为了使嵌入式应用程序具有确定性，它必须从开发项目的一开始就进行设计。确定性不是可以在最后添加的东西。必须特别考虑以确保应用程序线程可以直接控制它们所依赖的 I/O 接口。

图 1 显示了一个拾放装配系统，其中 TenAsys 的 Windows 实时操作系统 （RTOS） 托管在四核处理器的三个内核上，而人机界面 （HMI） 托管在第四个内核上。运行 Microsoft Windows 的核心。运行在不同 CPU 上的实时任务在需要时通过全局对象网络进行通信。该自动化装配系统包括三个实时子系统：引导装配机器人的视觉系统、多轴机器人以及将组件索引到装配位置然后运出装配单元的材料运输系统。开发和调试此类应用程序以确保每个组件按要求可靠运行的理想方法是将应用程序拆分为单独的组件。

图 1：嵌入式系统可以节省成本并保持实时响应能力，同时通过在多核处理器上托管多个操作系统来添加功能。

例如，HMI 将是一个单独的应用程序模块，可以在 Windows 等非实时环境中运行。这需要一个可以划分平台资源的操作系统环境——I/O、内存、中断和 CPU 内核（在多核处理器平台的情况下）——以允许应用程序模块完全独立地运行。嵌入式虚拟化环境支持这一点，允许不同的实时任务在特定的处理器内核上运行。操作软件对物理 I/O 接口进行分区，以便来自设备之一的中断仅中断处理该设备的处理器。这确保了处理实时事件的可预测响应时间。

多核芯片上的多个操作系统环境的托管由称为嵌入式虚拟化管理器的软件或包含在 RTOS 中的特殊嵌入式虚拟化功能进行管理。

嵌入式虚拟化可以以不同的方式实现，具体取决于处理器提供的硬件虚拟化支持量。半虚拟化解决方案使用软件技术来修改客户操作系统，允许它们并肩工作，而不会相互影响或损害系统的实时响应能力。实现提供了不同程度的平台分区，并且通常仅限于在一个平台上一次运行两个操作系统——一个 RTOS 和一个 GPOS。一些实现已经发展到 GPOS 不需要任何修改并且很容易支持最新版本的 GPOS 的地步。当将 GPOS 耦合到 RTOS 的目的是按原样使用传统 RTOS 应用软件时，这是一个真正的优势，无需任何修改，

多年来，其中一些实现已经过优化，可为特定的操作系统组合提供最佳性能。这样做的缺点是每个实现都特定于特定的操作系统组合，提供通用虚拟化解决方案以支持多种操作系统组合是一种不切实际的方法。

最近推出的 VT（由 Intel 处理器支持）等硬件辅助虚拟化功能通过提供内置于处理器中的硬件辅助，消除了半虚拟化的一些软件复杂性。通过使用硬件虚拟化支持，可以构建 VMM 以在不了解客户操作系统的情况下运行。因此，VMM 可以支持针对该平台的任何操作系统。

英特尔处理器特性，如 VT-x（VT 特性的一个子集）确保客户操作系统发出的任何内存地址都自动映射到物理内存中的适当地址位置。同样，称为 VT-d 的硬件辅助虚拟化功能自动映射总线主控 DMA 设备的 I/O 内存访问，使作为来宾 RTOS 应用程序一部分的本机 I/O 驱动程序无需修改即可在虚拟化环境中使用。这些硬件辅助功能大大降低了 VMM 的复杂性，并使嵌入式虚拟化成为更可行的解决方案。

使可伸缩性在实时应用程序中发挥作用

虽然嵌入式虚拟化为将实时应用程序拆分为单独的独立操作组件提供了理想的环境，但拆分应用程序需要一种机制来支持进程间通信 （IPC）。

过去，设计人员经常在应用子系统之间建立以太网链路，并使用 TCP/IP 堆栈在子系统之间进行通信，但这种方法繁琐、速度慢，有时不可靠，并且给系统的行为增加了不确定性，影响了确定性。

更好的 IPC 方法是使用称为全局对象网络的概念。 全局对象网络提供了一个具有内置启动和发现服务的托管通信环境，使应用程序能够在加载时动态分布在一个或多个 CPU 上。自动找到需要其他进程服务的进程，并且本地管理器记录它们的位置以跟踪已建立的 IPC 链接。如果通信链路或目标进程发生故障，管理器会通知启动进程。此外，当启动过程不再需要 IPC 链接时，本地管理器通过清除所有记录来保持系统清洁。由于全局对象网络与操作系统集成，其开销很低，并且不需要应用程序开发人员创建任何自定义软件。

操作系统管理全局对象的位置和存在，进程通过这些对象传递信息以确保系统的完整性。例如，一个进程在多个处理器上使用的对象是“保持活动状态”的，只有在所有进程都终止时才会被删除。这需要底层管理基础架构来确保不会过早删除对象，或者不会因为未使用资源清理不当而导致内存泄漏。同样，如果一个处理节点在其进程终止之前发生故障，管理器需要通知所有其他处理节点上的全局对象管理器它们应该清除对故障节点上对象的任何本地引用。

GOBSnet 通信示例

图 2 显示了图 1 所示系统的软件架构的高度简化视图。除了 RTOS 和实时过程软件，Cores 0-2 还运行 INtime GOBS manager 软件，其功能是管理全局对象通信。（GOBSnet 是 TenAsys 的全球对象网络，由公司的 INtime Distributed RTOS 和 INtime for Windows RTOS 支持。）

图 2： GOBSnet 促进了在不同处理器内核上运行的实时进程之间的通信。

使用 GOBSnet，一个内核上的进程可以使用全局内存对象与另一个内核上的另一个进程通信。启动进程，图 2 中的“进程 1”，创建内存对象并将其编入该内核的根进程中。完成此操作后，运行在其他处理节点上的进程可以找到内存对象，从而为所有进程提供高效的共享内存接口。这同样适用于 IPC 使用的所有对象范围（包括信号量和邮箱）。

第二步是让其他进程定位内存对象并获取其内存位置。这是通过指定处理器名称来开始搜索来完成的。当进程找到对象时，它将其位置、类型和参数存储在处理器节点的 GOBS 管理器中的引用对象中，并保留该引用对象的句柄。从那时起，当远程进程（本例中的进程 2 或进程 3）想要写入或读取内存对象时，它会使用引用对象的句柄来检索适当的内存对象信息以访问它。

当进程 2 或进程 3 终止其节点的 GOBS 管理器时，该管理器会清除有关远程内存对象的所有引用对象信息。当进程 1 终止时，它会删除它创建的所有对象，包括内存对象。如果这不是最佳操作，则可以选择使用计数器创建内存对象。每当另一个进程连接到内存对象时，计数器就会增加，而每当这些关联的进程之一终止时，计数器就会减少。结果是内存对象仅在与其连接的所有进程都终止时才被删除。这允许远程进程进程 2 和进程 3 可以继续通过内存对象传递信息的情况，即使启动进程进程 1 已经终止。

无论实时应用程序分布在同一多核芯片上的 CPU 之间，还是网络在一起的不同微处理器组件上的不同 CPU 内核之间，都可以使用 GOBSnet 通信。通过围绕这种灵活的系统软件架构设计系统，嵌入式系统开发人员有足够的空间来提高其产品的处理能力或相应地缩小其处理能力，以应对未来的挑战。

审核编辑：郭婷