这项工作研究了在任务式指挥设备中嵌入模拟器的实用性和有效性。其目标是仅使用战区作战计划作为模拟输入,向操作员隐藏所有模拟器细节,使其无需学习新工具。本文讨论了一种原型功能,该功能可根据 SitaWare 中生成的作战计划以及嵌入式无头 MTWS 和 OneSAF 模拟器的模拟结果,生成行动方案(COA)分析。在输入作战计划后,指挥官选择要执行的模拟运行次数,并按下按钮启动模拟,模拟在后台的运行速度比实时运行更快。模拟运行完成后,指挥官可通过图形和图表查看结果,对多次运行进行比较。预计未来的功能将允许指挥官模拟任何梯队和命令,用于训练和兵棋推演。
为了创建嵌入式模拟能力,本文制定了基本规则和预期目标。首要规则是操作员只能与 SitaWare 进行交互。仿真体验必须是完全无头的,对操作员是隐藏的。这一规则分解为许多自动化任务,包括为各种命令输入填充默认值、解构零散命令(FRAGO)、生成空中任务命令(ATO)、执行行为、管理供应水平、考虑后勤因素(在 SitaWare 中称为保持类型)、目标/弹药选择,以及所有通常需要满屋子的操作员和主题专家 (SME) 才能使用的复杂逻辑。它还规定了一种期望,即模拟结果将快速返回,不是实时返回,而是比实时返回更快,这样指挥官就不必等上三天才能执行六个 12 小时 COA 变量。
解决这两项挑战为在 MC 栈中嵌入仿真所涉及的复杂性提供了背景。这些挑战在逻辑中引入了模糊因素,产生的结果颗粒度不如复杂的模拟练习,但也大大简化了指挥官在喝几口咖啡之间查看预测的意图。根据我们的经验,这种方法是独一无二的。虽然我们熟悉使用集合级或实体级模拟的结果差异,但这些结果都是由人类根据指挥官的指导或意图做出明确决策来驱动模拟的。将人从环路中移除,促使我们产生了几个带有明确约束条件的 COA,这样指挥官就可以审查这些 COA,也许会对其中的一些提出质疑,然后通过额外的迭代运行对其进行探索。这是在实验范围内进行的,也是我们希望指挥官在审查结果时所花费的精力。毕竟,我们制作的是预测,而不是水晶球。
创建约束条件有助于自动做出决策,并填充通常由操作模拟器的人员填充的数值。在不同的运行中创建多个限制因素,可让指挥官看到针对特定计划在 COA 中生成的不同观点。这些限制因素包括伤亡、弹药、燃料、装备和总体情况。考虑到在每个 COA 中比较指定的限制因素,最有可能和最危险的结果会被标记出来。
基本的执行设计是这样的:
操作员在 SitaWare 中创建多个计划,三个蓝方COA 和三个红方COA。
操作员描述每个计划的迭代次数,然后按下 “模拟 ”按钮。
模拟器在后台无头运行。用户可在获得结果时查看结果。
运行完成后,操作员对各种约束条件进行筛选。例如,操作员点击一个选项,显示哪个 COA 使用的燃料最少。这将显示其他限制条件的结果,也许使用最少燃料的结果损耗最高。
模拟完成后,当为 “红方”和 “蓝方”指定三个作战行动方案时,有九个不同的任务可供比较。如图 1 所示,每个因素的好结果显示为绿色,中等结果显示为黄色,差结果显示为红色。
在 MC 服务器堆栈中嵌入 OneSAF 和 MTWS 的方法首先从 OneSAF 开始,然后转向 MTWS。在之前的 ITEC 演讲(Lacks,2015 年)和展会现场,展示了 MTWS 和 OneSAF 可以在云中互操作。然而,由于时间和预算的限制,这次将 MTWS 和 OneSAF 嵌入 MC 堆栈的实验并没有达到同时互操作 SitaWare、OneSAF 和 MTWS 三个系统的程度。虽然同时互操作所有三个系统在技术上会有挑战,但技术方面的问题并不妨碍考虑。在集成过程中会遇到一些典型的挑战,例如将持有类型与模拟器枚举相匹配。我们的方法不仅适用于未来 MTWS 和 OneSAF 与 SitaWare 的结合,也适用于其他任何品牌或型号的模拟器。这是一个有待未来探索的概念,也是我们实验范围的终点。
未来与 MTWS、OneSAF 或任何模拟器的兼容性,是通过我们的开源 SitaWare 接口 REpresentational State Transfer(REST)网络服务设计实现的,该服务名为 Sim Controller,用 Node.js 实现。Sim Controller 与 SitaWare 插件对接,用于启动、停止模拟器和模拟器运行状态,以及协调操作员指定的各种模拟器运行。然后,我们在模拟器中开发了一些功能,以协助将 SitaWare 事件和数据转换到本地模拟器,在我们的案例中就是 MTWS 和 OneSAF。这些功能有助于将 SitaWare 中的持有类型与模拟器中的平台、设备和供应枚举进行协商。它们与模拟器交换计划信息,并协助构建场景供模拟器运行。当场景执行完成后,这些功能将协助模拟器保存结果,并将结果存入 SitaWare 数据库,以便日后用于生成报告和图表。