《基于模型的系统工程方法应用于任务工程建模用例》169页报告

2023 年 4 月 6 日 专知

本报告研究了将基于模型的系统工程中的方法学进展和数字流程改进应用于任务工程使用案例的可能性。前提是基于假设：系统工程通过演变为更复杂的系统工程，已经接近于任务工程，在技术上有了联系。如果是真的，那么现在就有可能创建一条数字线，从最初的兵棋推演，通过任务工程指南和联合能力集成与发展系统的过程，变成能够在基于SysML的系统工程模型中消化和建立的需求。这将有助于提高自上而下需求的可追溯性和准确性，并有助于在任务层面进行自下而上的组件贸易研究，作为系统设计和开发的一部分。

为了确定这一假设的真实性，研究和分析包括两个文献回顾。第一个文献综述涉及任务工程的驱动因素和指导文件，从中得出任何有用模型必须满足的要求。第二篇文献回顾研究了当前基于模型的系统工程方法，从文献中寻找那些适用于任务工程的方法，而不是那些仅仅支持工程级别的工具。在第二次文献审查中获得的信息提供了在第一次审查中确定的要求可能被满足的方法。

文献审查完成，这两个主题就会通过分析各自的目的、目标和任务而正式联系起来。在这个阶段，很明显，这两个主题的意图和要求有很大的相似性，证明MBSE的进展可以适用于任务工程的使用案例。作为进一步的概念证明，所确定的方法被应用于一个综合防空任务的例子。通过这一应用，进一步验证了MBSE方法、过程和工具可以进行任务工程，但有两点需要注意：一个外部性能模拟框架是必要的，任何MBSE方法，特别是任务工程，是一个不断发展的实体，目前还不适合静态标准化。

通过文献回顾、综合和概念应用的验证，我们非常有信心地确定，基于模型的系统工程的进展可以使作为系统工程的一个子集的任务工程使用案例受益。这一结论为任务工程师在优化和发展他们的能力以支持作战人员时提供了更大的发展和信息的范围。

关键词：任务工程、基于模型的系统工程、能力差距评估、建模和仿真、系统建模语言 (SysML)、系统工程系统、兵棋推演

基于模型的系统工程

尽管证明了系统工程有广泛的目标和理念，这对以后的工作很重要，但在实际执行方面却缺乏具体性。传统的设计和获取过程是以文件为中心的，图表是临时使用的[5]。现在有一种转变，即从用word创建的文件，转向一个中心模型，作为权威的真相来源。这种方法被称为基于模型的系统工程（MBSE），我们将在后面进行更深入的探讨，现在有两个方面值得一提：

对于大型项目来说，这总体上是一种比较便宜的方法，因为它有助于在发布前抓住错误[16]。
系统的权威性数字表示是大型M&S工作的一个关键因素。

第二点是基于这样一个事实：模型只有在提供给它们的信息中才是好的。从文档中提取要放入模型的信息是一项耗时且容易出错的任务，很少能获得高度详细的基于物理的模拟所需的所有信息。拥有一个可以查询信息并直接连接到仿真软件的系统数字模型是一个改变游戏规则的因素。由于一个尚未讨论的关于成本和复杂性增加的因素，促进更好和更快的沟通是至关重要的：支持团队的人员也在增加。如图4所示，这个团队可以发展到相当大，并与通常不在直接开发过程中的组织对接：

团队的增长和参与组织的增加（从现有参与者的更多参与，到新工具的开发者）也扩大了对一个未来系统进行全面考察所需的需求清单。幸运的是，由于MBSE模型是描述性的，而不是分析性的，所以MBSE工具特别善于将需求与模型中的位置联系起来。需求的识别，以及如何做好的详细过程，超出了本文的范围，但包括诸如后期测试和支持的考虑，在这个阶段通常不会考虑这些，因为要保持需求更易于管理[17] 。

任务工程

在前面的章节中，本文已经讨论了以下要点：

系统由于越来越复杂而变得越来越昂贵。
关于系统工程的定义和理念有很大的不同。
M&S已经成为设计和获取过程的一部分，但在及时获得准确和完整的数据集方面存在挑战。
基于模型的系统工程是对基于文件的信息的一种转变，它有可能为更高质量的模拟提供信息。

这些考虑是理解任务工程如何发挥作用的关键。随着系统变得越来越复杂，当务之急是确定适当的要求和用途，从而使开发时间得到适当的集中和界定。这种必要性延伸到作战环境中，五个正式领域和作为第六个有效领域的电子战之间的相互联系正在增加[18], [19]。系统工程的定义千差万别，意味着没有一种单一的方法对系统工程进行优化。因此，有一个多样化的信息基础可供借鉴，只要能证明这种应用不是对系统工程理论的误用。换句话说，任务工程是系统工程的一个延伸。如果这种联系能够被建立，那么不仅现有的任务级分析工具能够更好地提供来自系统模型的数据，而且与系统设计相结合的任务能够利用所有更高保真度的基于物理的设计工具。为任务分析人员提供的工具方面的孔径的打开，开启了面向任务的仿真框架将是什么样子的问题。

任务级仿真框架

虽然超出了本文的直接范围，但理解联合任务级仿真的概念对任何任务级模型都至关重要。仿真框架是任务工程的动态仿真部分，这里开发的模型是将信息输入仿真框架的结构。为了支持任务分析，一个框架必须能够满足客户的操作要求和系统工程要求。这意味着在5个作战领域内以高保真度进行操作：

空中
网络空间
陆地
海上
空间
电磁波谱（不是正式的领域）

典型的任务工程问题也必须被回答。来自国防部任务工程指南的例子[21]：

本研究涉及哪些领域（空中、地面/水面、水下、空间、网络等）？
在模型中需要多少保真度来充分回应任务描述/分析问题？
需要什么模型来进行分析？(例如，6-DOF，基于物理的)
哪些模型是已经可以获得的？所需的模型是否已经存在？
该模型的血统是什么（验证、确认、认证等）？我们是否建立了正确的模型来使用？

在这些要求和问题之上，任务和系统工程之间有一个主要的区别：任务的动态、互操作性。所部署的系统是相对静态的设计，而部队的设计往往是由任务决定的动态的任务导向。因此，将系统工程直接应用于任务工程的用例，会导致僵硬和次优的解决方案。

关于哪些领域的问题比可能立即显现的更复杂。一个任务的目标可以在一个单一的领域内完成，或者通过多个领域的相互作用可以更好地完成任务。权衡的结果是增加资源需求、资源可用性和纳入潜在的新参与者。俄罗斯联邦对乌克兰的入侵表明了网络领域在一个传统的空地战攻击中的效用。商业卫星和社交媒体的广泛使用为开放源码情报（OSINT）提供了一个新的维度，即让任何有互联网连接的人都能在前排看到冲突。虽然详细探讨这些变化对未来理论的影响超出了本工作的范围，但只需指出，从战略上包抄对手的新选择意味着任务工程的一个基本问题，即任务发生地，现在本身就是一个战略层面的多变量贸易研究。一个强大的任务工程框架必须能够在这里将这些因素作为交易的一部分来考虑，而不是依靠任务设计者事先做出这个决定。

随着越来越多的领域给任务工程带来的复杂性，必要的保真度与风险水平的问题变得更加重要。从时间/成本/信息可用性/分类的角度来看，计算一个任务的每一种排列组合是不可行的

正如文献回顾所显示的那样，有两套针对不同客户的工具。一种是主要集中在需求生成和战争演习的战争演习工具。这些工具一直在稳定地给他们的实体增加越来越多的保真度，而不影响发挥任务的能力。另一个工具集由工程工具组成，如计算机辅助绘图（CAD），它们一直在稳步增加跨学科的模拟，以改善日益复杂的系统设计。这两个工具集在他们自己的阵营中往往具有有限的互操作性。但这种能力也在不断成熟，任务客户通过DIS或HLA的网络模拟器，以及像Model Center这样的软件将CAD与MBSE模型联系起来[22]。

仿真框架的最终独立发展是一个现实的假设，这背后是有道理的。这个理由是来自系统工程界的另一个理由，即多领域分析和优化。多领域分析和优化（MDAO）是系统工程界不得不克服类似问题的一个案例，当时不同的学科不得不开始将热、电和结构模型等互操作到一个凝聚的环境中。任何熟悉ANSYS或COMSOL的工程师都会看到不同程度的这个过程。这些工具和公司也已经开始将他们的环境扩展到MBSE模型，为最终的整合提供了基础设施[22]。目前已经有一些团体在探索这个集成课题。然而，他们，就像上面对系统工程的定义一样，对实际的模型创建很轻。因此，虽然这些努力和先例给了人们足够的信心，一个联合仿真框架将显现出来，但本文提供了一个透明的、详细的实现，以补充即将到来的文献回顾。