MIXR 混合现实仿真平台¶

Douglas D. Hodson , David P. Gehl

Air Force Institute of Technology, WPAFB, OH, USA

论文原文Int'l Conf. Scientific Computing | CSC'18 |

摘要¶

混合现实仿真平台（MIXR, The Mixed Reality Simulation Platform）是一个开源软件项目，旨在支持健壮、可扩展、虚拟与构造型、独立及分布式仿真应用的开发。其最常见的用例是支持可执行仿真应用的开发，用于组建实时、交互式、分布式虚拟环境（DVE）。

MIXR 的核心基础架构被设计为有利于开发可按确定性方式执行、满足实时交互/响应时间要求的应用，同时为场景定义、I/O 以及标准互操作接口（如 DIS、HLA 等）提供一定程度的配置灵活性。

MIXR 代码库已被用于开发众多支持实兵、虚拟与构造（LVC, Live, Virtual, and Constructive）仿真的军事应用，这类仿真亦称为“混合现实”仿真 [1]。

本文描述了该软件平台本身，以及它如何划分代码以利用多核/多 CPU 个人计算机，支持实时仿真应用的开发。

关键词： MIXR，DVE，LVC，混合现实 (mixed reality)，仿真 (simulation)

1. 引言¶

混合现实仿真平台（MIXR）是一个起源于美国国防部（DoD）的开源软件项目。它已被用于支持多个领域的分布式应用开发，包括实兵、虚拟与构造（LVC）仿真。

MIXR 定义了一种高级的组织模式，为仿真应用（有时称为模拟器）提供结构。换句话说，该软件为开发者定制应用提供了蓝图，从而简化仿真应用的创建。它融合了传统面向对象（OO, Object-Oriented）软件设计原则，并结合了实时系统的理念，以满足人机和/或硬件交互的需求。

通过提供系统组件的抽象表示（即抽象类），可以以优化运行时性能的方式混合不同精度级别的系统模型。对于虚拟和混合现实仿真，系统的抽象表示使开发者能够调优应用以高效运行，从而满足人机和/或硬件（环中）交互的延迟截止要求。对于纯构造型仿真应用（其中交互截止要求不存在或不那么重要），可以选择“更高级别”或更详细（可能处理器消耗更高）的系统模型。

该软件利用了模型-视图-控制器（MVC, Model-View-Controller）模式，将功能组件划分为独立包。在该领域中，MVC 概念更进一步，通过提供其他视图，例如抽象网络接口，以支持特定的互操作解决方案；典型案例包括分布式交互仿真（DIS, Distributed Interactive Simulation）协议和高层体系结构（HLA, High Level Architecture）。

基于该软件的具体应用非常多样，包括现役和未来的战斗机、轰炸机平台模拟器，无人机（UAV）地面控制站，综合防空系统（IADS），未来战场管理器等；更多信息见 [2] 和 [3]。

2. 简史¶

MIXR 软件代码库的起源可追溯至 20 世纪 80 年代末，当时它采用 C 语言编写，并运行在 Commodore Amiga 1000（是的，就是 Commodore Amiga！）上。由于 C 语言并不直接支持面向对象编程范式，代码库自行定义了一套类 OO 基础架构，以支持这种编程方式。90 年代初，基于 C 的 OO 系统被转换为 C++，应用开发和运行平台也转向 Silicon Graphics（SGI）工作站。自 1997 年起，开发平台从 SGI 工作站转向个人计算机（PC）。

最初（并非特指 1997 年）代码库并没有官方名称；直到 2002 年才被命名为“增强型空空-空地联动环境仿真（EAAGLES, Enhanced Air-to-Air, Air-to-Ground Linked Environment Simulation）”；后又更新为“联动仿真分析与生成的可扩展架构（Extensible Architecture for the Analysis and Generation of Linked Simulations）”。此次更新去除了“空空”“空地”等领域专用术语，强调了该软件面向通用建模与仿真能力的设计初衷。

2003 年，EAAGLES 在 DoD 社区变得更加知名——在世界最大建模、仿真与培训会议 I/ITSEC（Interservice/Industry Training, Simulation and Education Conference）上，展示了一款基于 EAAGLES 的战斗机座舱应用。尽管这套“战斗机座舱”模拟器只用了几个月开发，却表现得无可挑剔，充分证明了应用设计和底层框架的优越性。

2006 年 7 月，原 EAAGLES 代码库的一个重要子集被公开发布，成为众所周知的 OpenEaagles。与此同时，专门网站上线，提供信息、文档和发布版本。2009 年，出版了《Design & Implementation of Virtual and Constructive Simulations Using OpenEaagles》一书 [4]。此后，相关版本不断更新发布。

2017 年，OpenEaagles 更名为 MIXR，原因包括：

项目名称与关注领域更好地契合，即开发混合现实仿真应用。参见 [1] 和 [5]，了解混合现实仿真与 LVC 仿真的关系；
明确从“框架（framework）”向“平台（platform）”转变，表明有意识地以不同方式暴露其功能/能力，而不仅限于传统的 OO 风格继承（如子类化）；
指示项目正从“传统 C++”代码库过渡到“现代 C++”代码库，以提升质量、能力、可理解性，并降低复杂性。

如今，MIXR 代码库在其所提供的功能和能力方面已相当稳定。由于较长的开发历史，它积累了大量“内嵌”知识，这些都是支持大量仿真应用开发过程中沉淀下来的。目前的重点是进一步完善和提升其灵活性，使其能为更广泛的用户群体所用。

3. 术语¶

在过去几十年中，出现了许多等价术语，用于描述创建共享虚拟世界、供人类和/或硬件交互的实时分布式仿真。例如，分布式虚拟环境（DVE, Distributed Virtual Environments）、网络化虚拟环境（NVE, Networked Virtual Environments）以及分布式虚拟仿真（DVS, Distributed Virtual Simulation）。如今亦如此，但趋势是更普遍地将这些系统称为“混合现实”环境或仿真，这一说法也更清晰地反映了它们的本质。

这类系统的一个共同架构特征是：多个基本自治的独立仿真应用以异步方式执行，通过网络交换数据，实现一个共享虚拟世界的“幻觉”（在军事领域，也称为“合成战场”）。在军事领域，应用之间数据交换的方式由互操作协议定义，其中若干协议被发布为 IEEE 标准，例如分布式交互仿真（DIS, Distributed Interactive Simulation）和高层体系结构（HLA, High-Level Architecture）。这些分布式仿真通过为人类和/或硬件提供接口，使其能够在共享虚拟世界中交互。

由于人类和/或硬件被纳入所表示的目标系统（即“环中”in-the-loop），由此产生了额外的互动响应时间需求，从而将整个系统归为实时系统类别。在构建这些实时系统时，需在响应速度和模型精度之间进行权衡。

MIXR 代码库从零开始设计，充分考虑了这些需求，使得可在确定性执行性能和模型精度之间进行权衡。

4. 软件分类¶

框架（framework）是一组协作类，组成特定类型软件的可复用设计 [6], [7]。通过为框架中的抽象类创建特定应用的子类，可以将框架定制为某一具体应用 [8]。工具包（toolkit）是一组相关且可复用的类，提供有用的通用功能，是面向对象版本的子程序库 [8]。

图1：平台定位

如图1所示，基于框架构建的应用是通过“扩展”来实现的；在 C++ 中，通常是通过继承对类进行子类化。而仅仅使用库功能（如工具包）的应用，并不会表现出同样类型的依赖（具体来说，是耦合）。

尽管 MIXR 明显组织为一个框架，通过扩展类来开发应用，但其目标是让其更像通用的建模与仿真平台。换言之，无需继承类即可开放更多功能。

无论哪种方式，MIXR 都不是像 Microsoft Word 或典型游戏引擎那样的可执行应用程序。它并不定义 main() 函数；而是将这些细节交由开发者自行决定，完全掌控应用如何组装和配置。

MIXR 用 C++ 编写，并被划分为不同包，为开发者作为功能工具包（即库）按需调用。例如，MIXR 定义了一个图形工具包，可用于便捷开发操作员/载具界面和显示。

这种组织方式，使得该软件能够创建多样化的仿真应用。派生出的仿真应用通常可独立运行，也可在分布式网络环境中运行。基于标准协议（如 DIS 和/或 HLA）进行交互的分布式应用，几乎可以做到“开箱即用”。

5. 虚拟仿真需求¶

与人参与者（或硬件）交互的仿真，必须在规定的截止时间内响应（延迟或响应时间）。仿真若不能及时响应（就像其所代表的系统一样），将令操作员沮丧，并可能影响仿真结果。面临这种高要求的软件系统，属于实时系统（real-time system）范畴。实时系统的设计和组织，目的就是让关键（通常是周期性的）任务能够按时完成。

任务调度的标准方法有两种：基于优先级和前台/后台系统。基于优先级的设计为系统中每个任务分配一个优先级，最高优先级的就绪任务优先执行。任务调度由操作系统管理。

在前台/后台系统中，应用本身控制任务调度。前台任务通过跳转表或由指针组成的受控列表来执行，任务按列表顺序逐一执行。非周期事件和后台任务在所有“最高优先级”任务执行完后才获得处理时间。

MIXR 采用前台/后台系统架构，但不是用跳转表（或函数列表）管理，而是将线程执行路径融入类层次结构的设计。其专门利用多核/多CPU PC 平台的优势，可创建高优先级前台线程。由于具备多处理器，采用 Windows、Linux 等通用操作系统也能保证高优先级、关键实时前台线程的可靠执行。

需要强调的是，基于 MIXR 的应用以循环或帧为基础进行系统执行，而非离散事件处理器。这种方式满足了其设计需求，即支持不同精度水平的模型（包括更高层次的物理模型、数字信号处理模型）以及实现实时性能要求。模型状态可用状态机捕捉，状态转换可利用消息传递机制实现。

6. 实时仿真平台¶

MIXR 采用 C++ 编写，原因如下：

大多数实时系统为了性能采用 C 语言开发 [9]。面向对象语言往往被怀疑影响性能，而整体性能通常重于灵活性。但在建模与仿真领域，我们认为面向对象语言（如 C++）带来的优势远大于轻微的性能损失；
C++ 具有良好的可移植性，几乎所有平台都有编译器。这使开发者可以在主流操作系统（Windows、Linux 等）上构建基于 MIXR 的应用；
C++ 支持多种编程范式，灵活性高；
可自定义内存管理方式，不会影响应用的整体性能。因此，优先采用 new 和 delete 操作符，而不是无法控制的垃圾回收。

本文不可能覆盖所有定义的类，但有几个关键类值得介绍，以帮助理解代码结构。

Object ：Object 类是 MIXR 代码库的 C++ 系统对象。不同于 Java、Ruby 等其他面向对象语言，C++ 并未提供系统对象，也不内置垃圾回收。这两点在比对语言原生特性时似乎是劣势，但对于需要满足实时要求的应用领域，反而是优势。

C++ 能灵活定义这些机制以适应不同应用领域。例如，对于不太关心耗时内存管理操作的应用，代码库提供了智能指针以自动管理对象的创建和销毁。相反，若应用必须满足时间约束（即实时系统），对象的无序创建与销毁可能导致性能问题。

Object 的一个能力是为所有对象提供简单的引用计数系统，用于内存管理。Object 允许开发者手动控制和优化以性能为导向的应用，例如对建模射频（RF）发射包或红外（IR）几何信息的实时处理。

系统对象的另一个细微但重要方面是类型检查。有了系统对象，并且所有类都从其派生，可实现对象的动态类型转换，避免无类型函数与类相关的陷阱。正因如此，MIXR 编码标准明确禁止使用 void 指针。

Component ：在面向对象编程中，容器类（container class）是指包含其他对象的类。MIXR 的 component 类不仅如此，还包括更多功能。Component 可容纳其他组件，同时定义了一套基本的消息系统，贯穿整个代码库。

MIXR 从一开始就旨在便于创建实时运行和/或与人参与者交互的仿真应用。带有时延/响应截止要求的应用，通常将关键任务与非关键任务分离。例如，以特定频率执行气动模型，与写入硬盘或打印文档这种非关键操作分开处理。

这种分离通过 component 类的两个方法实现。在设计模型时，需要以关键方式执行的代码（通常是数学计算）放在重写的虚函数 updateTC()（更新关键任务）中；可非关键执行的代码放在重写的虚函数 updateData() 中。

这种代码组织方式有如下优点：

由于关键代码与后台代码明确分离，应用可按需设计以满足性能要求；
与某一模型关联的全部代码（关键与后台）在同一类中，逻辑清晰。

如图2所示，可以将仿真应用的一个实例看作一棵 Component 组件树。调用树顶（根）的 updateTC() 方法，将自动执行所有子组件的 updateTC()。换句话说，每个组件都会执行其子组件的相关代码，直到整棵树处理完毕。后台代码同理。

图2：组件树

MIXR 编码标准对 updateTC() 中的编写规则做了详细规定（如不得有阻塞 I/O 调用）。这些规则与实时系统开发中的通用指导原则一致。

7. 应用结构¶

使用 MIXR 作为仿真基础的软件开发者，通常通过使用现有类（即模型）或扩展它们以添加细节来构建应用。最终，为应用定义 main() 函数。

主流程通常执行以下任务：

读取定义并创建对象层次结构的配置文件。MIXR 提供解析器实现该功能；解析器定义了简单的类无上下文语法输入语言，易于扩展，
创建并设置要执行的线程。对于非实时应用（如纯构造型应用），可能只需单线程。对于包含关键时序代码的虚拟仿真，通常会创建前台和后台线程，
按需通过调用 updateTC() 和 updateData() 执行仿真。如果应用是虚拟仿真，高优先级线程将负责处理前台任务。

开发者完全定义主流程，以支持多种执行场景；MIXR 不定义 main() 函数！此外，应用的主流程代码通常简洁明了，大部分工作在于新类的设计与扩展。

仿真应用通常按照图3所示结构组织。以组件树思维，Station 类位于顶部或根节点。其它组件都是 Station 的子组件。

Station 连接模型与视图（如图形显示、I/O 设备和控制、互操作网络）。Station 拥有一个 Simulation 实例，管理玩家列表（即实体或平台），并跟踪仿真时间，包括当前处理的周期、帧和阶段。

作为基于帧的系统，delta 时间作为参数传入 updateTC()，以便进行正确的时间相关计算。模型依赖 delta 时间进行计算，意味着系统频率可变时无需修改每个模型（只要满足奈奎斯特采样率）。附加的时间信息以周期（16 帧，或称主帧）和阶段形式记录。阶段控制数据流在模型中的顺序。目前定义了四个阶段：

动力学（Dynamics）——更新玩家或系统动力学，包括气动、推进和传感器位置（如天线、红外导引头）；
发送（Transmit）——在此阶段发送射频（R/F）辐射，可能包含数据链消息。计算射频范围方程参数，包括发射功率、天线模式、增益和损耗；
接收（Receive）——处理并滤波接收的辐射，将探测报告或数据链消息排队等待处理；
处理（Process）——处理数据链消息、传感器探测报告与跟踪，更新状态机、机载计算机、射击列表、导航计算机、自动驾驶仪或其他玩家及系统决策逻辑。

玩家（Player）是一个增加动力学和其他独特行为的组件。可附加的组件包括特征（signatures）、天线、传感器和挂载物。代码库中包含了派生的空中和地面玩家。

图3：应用结构

定义了一个抽象互操作网络接口，以便集成特定协议，例如 DIS，用于支持与其他分布式仿真应用的互操作。该网络接口自动在玩家列表中创建新玩家。对仿真而言，这些玩家与其它玩家无异。

8. 图形¶

平台定义了多个图形工具包，用于开发操作员/载具界面显示。图形工具包基于 OpenGL 实现所有基本绘制操作，从而几乎兼容所有平台。

图形绘制的基础包含于 graphics 包中，提供绘制位图、输入/输出字段、字体、多边形、读数器、纹理等图形对象的类。

如图4所示，图形架构定义了 Graphic、Page 和 Display 类之间的层级关系。

Graphic 类封装了图形相关属性，如颜色、线宽、闪烁频率（用于闪烁图形）、坐标变换、顶点及纹理坐标、选择名和剪切区域信息。作为组件，Graphic 可包含其他图形。

Page 类定义“图形页”，有助于创建多功能显示器（MFD），可定义特定的页转换事件。Display 类定义了绘制所需的所有资源，如字体、色表以及显示视口的物理和逻辑尺寸。最后，开放源代码的 GUI 工具包（如 Glut、Fox、FLTK 和 Qt）可用于提供丰富的界面。

MIXR 图形类简化操作员/载具显示开发，并利用开源 GUI 工具包，但不旨在替代面向视觉场景图的显示（如抬头显示器或图像生成器）。MIXR 的整体理念是避免重复造已经被其他应用和/或包很好实现的轮子。

基于该结构的更高级工具包包括仪表库，内含拨盘、按钮、计量器、仪表指针以及无数其他功能完备的仪器，还有简单地图。

所有图形工具包独立于仿真建模环境。模型不包含任何图形专用知识，图形也不包含模型专用知识。两者连接的代码存在于 Station 类中。

通过 Station 类的 ownship 指针，任何玩家的控制和显示都可以随时切换。玩家间切换有助于从不同视角观察仿真交互。

所有图形类均派生自 Graphic，后者又派生自 Component。作为组件，所有关键时序代码可写入 updateTC() 方法，后台处理代码可写入 updateData() 方法。有时在实时系统开发中，图形绘制需设置比其他后台处理更低的优先级，因此 Graphic 类内定义了另一个方法，作为执行实际 OpenGL 图形绘制的占位符。

图4：图形类层级结构

MIXR 发布的示例应用演示了基本图形功能，通过绘制一个在屏幕上移动并碰撞墙壁反弹的“虫子”。示例代码组织如下：位置、速度和方向的数学计算在 updateTC() 中完成；绘制准备工作在 updateData() 中进行；实际图形绘制由 Graphic 的 draw() 方法执行。

如此组织代码，使应用开发者能灵活决定代码执行方式，并定义线程以满足响应时间要求。上述示例中，设置线程实时执行与“虫子”运动相关的关键数学计算，而在非关键时序下，由操作系统（或本例中的 Glut）利用空闲时间绘制“虫子”。

9. 设备输入输出与联动¶

MIXR 对输入输出设备及完整联动系统进行了抽象，使硬件接口对应用程序表现为一个单一（统一）设备，呈现多个模拟（轴）和数字（按钮）值，如图5所示。该联动包包含多个输入设备的接口代码，包括操纵杆和基于 USB 的设备。同时，它也扩展支持与其它商业输入卡和数据采集设备交互。

设备初始化后，通过调用 IODevice 类中定义的虚函数 receive()，可以获取设备的最新数值。还能检测按钮状态变化以及为模拟输入设置死区。

图5：设备类层级结构

Station 类定义了轴和按钮如何连接到仿真应用的模型和视图。

10. 示例应用¶

MIXR 软件发行版包含构建新应用的代码，以及展示如何利用其固有功能的示例。有关早期军事产品的详细描述，参见文献 [2]。内容涉及早期的战斗机座舱、地面控制站和群指挥所。

11. 发展机遇¶

近四十年来，MIXR 代码库在结构和功能方面不断改进与演进。从最初用 C 语言及开发者自建的类 OO 系统，到主流的 C++；从 Commodore Amiga 1000 到当代个人电脑，MIXR 已被证明是一款实用且功能强大的软件开发产品，支持了广泛的仿真应用创建。

基于此，我们并不认为 MIXR 已“完成”——事实上，我们相信自 2011 年现代 C++ 推出（近 13 年来的首次重大语言更新）以来，代码库迎来了新的机遇。例如，C++ 标准库不断扩展，提供跨平台的线程、高精度时钟和原子操作等解决方案，MIXR 可利用这些来减少代码库的规模和复杂度。同时，随着图形处理单元（GPU）作为典型 PC 的内置功能被广泛采用，针对并行数据中心操作的优化也带来了新的可能。

编程范式和惯用法也发生变化；出于多种原因，过度继承受到限制，包括：1）易于误用，如将继承用于代码复用（即“实现继承”），2）减少（或放松）紧耦合代码，3）为满足新用例需求重构继承关系。

由于 MIXR 存续时间较长，其继承结构相对稳定且定义清晰；但随着对不同潜在技术的建模与仿真需求增加，这种情况可能发生变化。

12. 结语¶

MIXR 是开源且免费提供的；可连同一套示例程序从 www.mixr-platform.org 下载使用。

附录：¶

C++ 编码标准：当开发新的或扩展现有的 OpenEaagles 类时，应遵循这些编码标准。此文档还定义了在开发 C++ 应用程序时应遵循的一些有用指导原则。

Basic 类： OpenEaagles 框架 Basic 包中包含的许多类。它还包含框架的一些底层设计理念。

BasicGL 类： OpenEaagles 框架 BasicGL 包中包含的许多类。

References¶

[1] D. D. Hodson, "Military simulation: A ubiquitous future," in 2017 Winter Simulation Conference (WSC), 2017, pp. 4024-4025.

[2] D. D. Hodson, D. P. Geh1, and R. O. Baldwin, "Building distributed simulations utilizing the EAAGLES framework," Interservice/Industry Training, Simulation and Education Conference (I/ITSEC), 2006.

[3] "MIXR Platform website," http://www.mixr-platform.org, accessed: 2018-06-23.

[4] D. M. Rao, D. D. Hodson, M. S. Jr, C. B. Johnson, P. Kidambi, and S. Narayanan, Design & Implementation of Virtual and Constructive Simulations Using OpenEaAGLes. Linus Publications, 2009.

[5] D. D. Hodson and R. R. Hill, "The art and science of live, virtual, and constructive simulation for test and analysis," Journal of Defense Modeling and Simulation: Applications, Methodology, Technology, vol. 11, no. 2, pp. 77-89, 2014.

[6] P. L. Deutsch, "Design reuse and frameworks in the smalltalk-80 system," in Software Reusability, Volume II: Applications and Experience, T. J. Biggerstaff and A. J. Perlis, Eds. Addison-Wesley, 1989, pp. 57-71.

[7] R. E. Johnson and B. Foote, "Designing reusable classes," Journal of Object-Oriented Programming, no. 2, pp. 22-35, 1988.

[8] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1995.

[9] P. A. Laplante, Real-Time Systems Design and Analysis. WileyInterscience, 2004.

作者简介¶

DOUGLAS D. HODSON 是美国俄亥俄州赖特帕特森空军基地空军技术学院（AFIT）的计算机工程副教授。1985 年，他获得赖特州立大学物理学学士学位，1987 年获得代顿大学电光学硕士学位，1999 年获得代顿大学工商管理硕士学位，2009 年在 AFIT 完成博士学位。他的研究兴趣包括计算机工程、软件工程、实时分布式仿真和量子通信。他还是 DAGSI 学者和 Tau Beta Pi 会员。

DAVID P. GEHL 受雇于 L3 Link Training & Simulation 公司，拥有超过 45 年的人机交互仿真与训练经验，专注于人因工程研究，拥有丰富的飞行员/操作员-载具界面、飞机系统模型（气动学、雷达、武器投送、导航、视觉系统等）以及实时系统开发知识。此前，他曾担任可扩展联动仿真分析与生成架构（EAAGLES）仿真框架的主要架构师。1979 年获得赖特州立大学计算机科学学士学位，1986 年获得系统工程硕士学位。