MBSE应用于任务工程建模用例¶

Model Based Systems Engineering Methods Applied to the Mission Engineering Modeling Use Case

作者： Jonathan Kidner

本论文部分完成于远征作战系统工程（Expeditionary Warfare Systems Engineering）理学硕士学位的授予要求之下。

导师： David Galvao Wall

机构： Cranfield University 国防与安全学院（Cranfield Defence and Security）

专业方向： 远征作战系统工程（Expeditionary Warfare Systems Engineering）

CRANFIELD UNIVERSITY
2022年

缩略词列表（Acronym List）¶

缩写	全称
act	Activity Diagram（活动图）
bdd	Block Definition Diagram（方块定义图）
CBRN	Chemical Biological Radiological Nuclear（化学、生物、放射与核）
CONOPS	Concept of Operations（作战概念）
DIS	Distributed Interactive Simulation（分布式交互仿真）
DoD	Department of Defense（美国国防部）
DoDAF	DoD Architecture Framework（国防部架构框架）
F2T2EA	Find-Fix-Track-Target-Engage-Assess（发现-固定-跟踪-瞄准-交战-评估）
GCRA	Government Capability Reference Architecture（政府能力参考架构）
GMRA	Government Mission Reference Architecture（政府任务参考架构）
HLA	High Level Architecture（高层体系结构）
ibd	Internal Block Diagram（内部方块图）
INCOSE	International Council on Systems Engineering（国际系统工程委员会）
JCIDS	Joint Capabilities Integration and Development System（联合能力集成与开发体系）
JPL (NASA)	Jet Propulsion Laboratory（美国国家航空航天局喷气推进实验室）
KPP	Key Performance Parameter（关键性能参数）
LVC	Live Virtual Constructive（实装-虚拟-构造一体化仿真）
MATREX	Modeling Architecture for Technology, Research, and Experimentation（技术、研究与实验建模架构）
MDAO	Multi-Domain Analysis and Optimization（多域分析与优化）
ME	Mission Engineering（任务工程）
MEG	OSD’s Mission Engineering Guide（国防部副部长办公室任务工程指南）
MoD	Ministry of Defense（国防部）
MoDAF	Ministry of Defense Architecture Framework（国防部架构框架）
MoP	Measure of Performance（性能度量）
NAF	NATO Architecture Framework（北约架构框架）
NASA	National Aeronautics and Space Administration（美国国家航空航天局）
NDIA	National Defense Industrial Association（美国国防工业协会）
NILE	Naval Integrated LVC Environment（海军综合LVC环境）
OMG	Object Modeling Group（对象管理组织）
OOSEM	Object Oriented System Modeling（面向对象系统建模）
OSD	Office of the Secretary of Defense（美国国防部长办公室）
par	Parametric Diagram（参数图）
SE	Systems Engineering（系统工程）
seq	Sequence Diagram（序列图）
stm	State Machine Diagram（状态机图）
SysML	Systems Modeling Language（系统建模语言）
T&E	Testing and Evaluation（测试与评估）
UAF	Unified Architecture Framework（统一架构框架）
UML	Unified Modeling Language（统一建模语言）
UPDM	Unified Profile for DoDAF and MoDAF（DoDAF与MoDAF统一配置文件）
USD(R&E)	Under Secretary of Defense for Research and Engineering（美国国防部研究与工程副部长）

Abstract¶

本报告探讨了在基于模型的系统工程（Model Based Systems Engineering, MBSE）中采用方法学进展与数字化流程改进，并将其应用于任务工程（Mission Engineering）用例的可能性。该前提基于这样一种假设：系统工程（Systems Engineering）在演变为更复杂的系统体系工程（System of Systems Engineering, SoSE）的过程中，已经与任务工程足够接近，从而在技术上能够建立关联。如果这一假设成立，则现在可以从最初的兵棋（wargames）出发，通过任务工程指南（Mission Engineering Guides）与联合能力集成与开发系统（Joint Capabilities Integration and Development System, JCIDS）流程，构建一条数字化链路（digital thread），并最终形成可被基于 SysML 的系统工程模型吸收与扩展的需求。这将有助于提升自上而下需求的可追溯性与准确性，同时也能促进作为系统设计与开发一部分的自下而上组件层级的任务级权衡研究。

为验证这一假设的真实性，本研究与分析由两次文献综述构成。第一次文献综述聚焦任务工程的驱动因素与指导性文件，并从中提取任何有效模型必须满足的需求。第二次文献综述则考察当前的基于模型的系统工程方法，从文献中筛选那些适用于任务工程的方法，而非仅支持工程层级工具的方法。第二次文献综述所获得的信息提供了满足第一次综述中识别出的需求的方法路径。

在完成文献综述后，通过对两者的目标、宗旨与任务进行分析，将两个主题进行了形式化关联。在此阶段可以明显发现，两者在意图和需求上具有显著相似性，这进一步支持了 MBSE 的进展可以适用于任务工程的用例。作为进一步的概念验证，所识别的方法学被应用于一个综合防空（Integrated Air Defense）任务示例中。通过这一应用进一步验证：MBSE 的方法学、流程与工具确实能够执行任务工程，但需满足两个前提条件：
1. 需要一个外部性能仿真框架；
2. 任何 MBSE 方法学，尤其是在任务工程中，都是不断演进的实体，目前并不适合静态标准化。

通过文献综述、综合分析与概念验证的应用，可以高度确定：基于模型的系统工程的进展能够作为系统体系工程的子集，显著促进任务工程用例的发展。这一结论为任务工程师在支持作战人员（warfighter）进行能力优化与能力开发时提供了更广泛的研发基础与信息来源。

关键词 - Mission Engineering（任务工程）、Model Based Systems Engineering（基于模型的系统工程）、Capability Gap Assessment（能力缺口评估）、Modeling and Simulation（建模与仿真）、Systems Modeling Language (SysML)（系统建模语言）、System of Systems Engineering（系统之系统工程）、Wargaming（兵棋推演）

1. 引言¶

“所有模型都是错的，但有些是有用的” —— George Box

1.1. 假设¶

本文提出，Mission Engineering（任务工程）与 Systems Engineering（系统工程）在本质上具有足够的相似性，使得任务工程能够利用 Model Based Systems Engineering（MBSE，基于模型的系统工程）的进展来发展一种基于模型的任务工程方法论。通过该方法论生成的模型将能够支持基于物理的任务分析工具，同时保持与构成任务的系统权威真实来源之间的可追溯性。

1.2. 目标¶

本文从任务工程视角，识别系统建模与仿真文献中可用于任务层面的需求与最佳实践。通过这项文献综述获得的信息将用于在 Cameo Systems Modeler 中构建一个 MBSE SysML 模型，并将其与 MATLAB 集成，作为任务工程仿真的替代工具。这样一个模型提供了从部级出版物、优先级和条令到任务工程环境定义的可追溯链路。这一定义包括用于生成系统需求所需的仿真领域，以及与物料解决方案开发中使用的 MBSE 模型对接的基于模型的系统工程模式的顶层结构。该路径代表了传统能力缺口识别与解决流程的工程视角，并通过在工程层面采用数字工程和 MBSE 得以实现。

虽然在系统设计周期中纳入任务要素并非新概念，但这些要素通常是从系统工程的视角来理解的。此处的方法是从任务工程视角审视系统工程工具和方法论，以创建一种以任务为中心的方法，而不是直接采用系统建模方法所固有的优先级。

上述工作将在 Distribution Statement A 的限制范围内，基于学术资源开展，并刻意保持与敏感信息的距离。因此，本文将避免对仿真工具进行具体解决方案或直接比较，因为在没有受限信息的前提下无法进行有意义的讨论。文献综述将仅限于识别能够影响活动工具选择的要素。其目标是让用于决策的模型减少错误并更加有用。

1.3. 目标读者¶

本文主要面向刚进入任务工程领域的工程师，帮助其了解该学科的基础内容。其中也包含一些面向更有经验、负责组织内部本体和模式开发的任务工程师的内容。

1.3.1. 文档结构¶

本文件共包含四个主要部分：引言（介绍任务工程与 MBSE 的使用背景）、任务工程文献综述、MBSE 发展与现状的文献综述，以及一个示例任务，用以验证系统工程通过发展到更复杂的系统之系统工程，已经与任务工程足够接近，可以在技术上建立关联。每个章节（到 X.X 层级，只要该章节包含进一步的小节）开头都将包含对其内容的几句总结。

章节与子章节开头的摘要将采用如下形式。以下为正文。

1.3.1.1. 引言¶

论文的第一部分将简要介绍任务工程与 MBSE 的概念、动机和背景，并说明这些方法为何正在取代旧的方法。

1.3.1.2. 任务工程¶

本节介绍任务工程作为概念，描述其产生背景、与兵棋推演的关系、如何支持能力缺口分析与需求生成，以及进行建模时常见的关键性能参数（KPPs）。这些 KPPs 将构成任务工程与 MBSE 之间的基础接口，因为它们是任务层面的需求，可进一步用于推导平台与系统层面的需求。

1.3.1.3. 基于模型的系统工程文献综述¶

本节包含文献综述，从系统工程的介绍、MBSE 的演变、所使用的 Systems Modeling Language (SysML) 的回顾，以及文献综述的重点展开。在更广泛的文献回顾基础上，本文识别了七种最与任务工程相关的 MBSE 方法，并总结关键启示。这些启示将用于第四章的综合。

1.3.1.4. MBSE 对任务工程的支撑¶

本节将在前两个章节奠定的基础上，形式化 MBSE 与任务工程的关联，以验证 MBSE 的发展成果应用于任务工程领域的有效性。该关联通过对照由 SERC 提供的调查结果支持的任务工程流程与 MBSE 流程来建立。本章随后将根据第 2.3 节所识别的方法，演示示例模型的结构、行为、仿真与权衡分析。本节作为概念验证表明，从 MBSE 进展中提取的方法论适用于任务工程，但前提是目前尚不存在一个普适且可实践的标准。

1.3.1.5. 示例任务¶

本节示例任务及其相关模型展示了前文文献综述亮点的实用性，并说明这些方法如何被实际应用。其中包含了对于任何可执行模型都至关重要、但在现有文献中常被忽视的必要连接内容。本文示例任务是：在一个简陋区域（austere location）部署一套 Integrated Air Defense（IAD，综合防空）系统，用于保护作战区域后方的高价值资产。该系统包含一对与指挥节点分置以提高生存性的网络化传感器，通过无线网络通信。有一架来袭敌机，必须在进入其 200 km 武器射程前，通过搜索雷达与跟踪雷达进行探测。由于基地条件简陋，燃料消耗及其带来的后勤问题是关键关注点，限制为每小时 110 kg 燃料消耗。由于需要部署多个该类阵地以覆盖足够区域，运营成本不得超过每天 $2000。目标是确定所选系统能否在给定约束内完成任务。本文中所有信息与参数均来自 Distribution A 来源；在实际分析中，应使用现有工具作为仿真框架的一部分。

1.4. 背景¶

1.4.1. 系统复杂性¶

首先需要探讨的是采用 Modeling and Simulation（M&S，建模与仿真）的理由。传统设计过程通常依赖原型和实物测试，而有效的 M&S 是对该流程的较新补充。然而，驱动这一传统范式转变并提升 M&S 作用的关键因素是“复杂性”：越来越复杂的系统正在更加复杂的环境中运行。根据美国政府问责局（GAO）的简要审查结果，在考虑通胀因素后，F-15 在 1972 年的研发成本为 30.78 亿美元；到 2000 年，F-22 的研发成本估算为 188.8 亿美元，并在同年上升至 204 亿美元 [1], [2]。据估计，F-35 的成本将超过两者，但目前尚难以确定其具体幅度，因为尽管 F-35 已于 2019 年在海军中具备作战能力，其研发仍在持续，成本仍在上升 [3], [4]。然而，这在很大程度上是由于民用与军用航空平台系统复杂性呈指数级增长（如图 1 所示）。

虽然这一趋势部分归因于现代生活中对计算机依赖的增加，但其仍然显著提升了系统复杂度。由此可见，系统因复杂性提升而变得更昂贵，这一事实进一步说明了范式转变的必要性。

1.4.2. 系统工程中的建模与仿真¶

这种范式转变表现为 M&S 的广泛应用，尽管 M&S 只有在后续将讨论的数字化设计周期中才能发挥最大效用。尽管在设计与采购生命周期中采用 M&S 的理由充分，但它并非完美方案。近年的工程分析趋势指出，M&S 在美国国防部（DoD）中的应用既具有价值，也存在不足与未来挑战 [5], [6]。幸运的是，目前许多 M&S 应用的不足可以通过整合现有 M&S 能力与其他评估手段来弥补 [7], [8]。然而，这些能力与开发工作多数仍集中于系统设计与采办阶段。

这可由国防部使用 M&S 的方式加以说明：“国防部持续寻求获取、维持与管理物质及非物质解决方案，以满足作战人员在军事行动中的能力需求，并在和平时期提供高效的保障与战备能力。越来越多的军事能力是通过系统之系统（SoS）方法实现的……系统工程（SE）被认为是系统采办成功的关键要素，对于 SoS 同样重要。” [9]

在国防部内部，系统工程的具体定义与应用基于 DoDD 5000.01、DoDI 5000.02、DoDI 5000.85（重大能力采办）与 DoDI 5000.88 [10]。其目的可概括为：从能力缺口的识别到运行支持，再到处置阶段，引导物质解决方案的全过程。此方法并不强调系统的设计本身，而是强调系统的能力，并通过正式的项目审查与设计方交互，按图 2 所示的里程碑推进 [9], [11]。

图 2 美国国防部采办生命周期 [7]（第 10 页）

除 DoD 外，还有其他机构在本研究相关范围内开展 M&S。与 DoD 强调采办的定义不同，国际系统工程委员会（INCOSE）与美国国家航空航天局（NASA）等机构则采用以设计为导向的方法，这两者涵盖工业与政府领域。

“INCOSE《系统工程手册》基于 ISO 15288 与 ISO 24748-1，概述了系统生命周期的阶段划分：概念、开发、生产、使用、支持与退役……这些生命周期概念不会因 MBSE 而改变，因此 MBSE 方法必须遵循这些既定阶段。” [12]

通用生命周期（ISO/IEC/IEEE 15288:2015）

概念阶段	开发阶段	生产阶段	使用阶段	退役阶段
			支持阶段

图 3 通用生命周期 [13]

INCOSE 正式定义系统工程为：“一种跨学科、综合性方法，利用系统原理、概念及科学、技术与管理方法，确保工程系统的成功实现、使用与退役。” [14] 该定义通过“使用”一词体现了系统的“引导”过程，但其强调程度较 DoD 明显减弱。这种差异源于 INCOSE 注重设计，而 DoD 注重采办。

美国国家防务工业协会（NDIA）系统工程分会 M&S 委员会于 2011 年发布的《基于模型的工程（MBE）小组最终报告》指出了上述差异 [15]，并强调模型在开发与合同管理中的角色界定仍具争议。在 DoD 内部，MBSE 模型代表系统的“基线”，用于需求、投标、交付物及参与传统 SETR 事件的参考。两种模型方法并无“对错”之分，但需要采用不同的建模途径与方法论。

1.4.3. 基于模型的系统工程¶

尽管系统工程目标与理念多样，但其在实际实施方面缺乏具体性。传统的设计与采办流程以文档为中心，图表仅作临时补充 [5]。当前的转变趋势是从基于文字的文档（如本文）转向以模型为核心、作为权威真实来源的模式。这种方法称为 Model Based Systems Engineering（MBSE，基于模型的系统工程），本文后续将深入探讨。目前有两点值得提前说明：

对于大型项目而言，这是一种更低成本的方法，因为它有助于在发布前发现错误 [16]；
系统的权威数字化表示是更大规模 M&S 工作的关键支撑。

第二点的核心在于：模型的质量取决于其输入信息。为构建模型而从文档中提取信息是一项耗时且易出错的工作，且难以获得进行高精度物理仿真所需的全部数据。若拥有可查询信息并能直接与仿真软件相连的系统数字模型，则将成为变革性突破。由于成本与复杂性增加，促进更快更准确的沟通变得至关重要，因为支持团队规模也在扩大。这些团队可能相当庞大，并与平时不直接参与开发的机构交互，如图 4 所示。

图 4 系统与任务开发团队的互联性 [17]

团队规模的扩大及参与机构数量的增加（包括现有成员更深的参与与新工具开发者的加入）使得为系统定义完整范围所需的需求清单也随之增长。幸运的是，MBSE 工具尤其擅长将需求与模型中的具体位置关联起来，因为 MBSE 模型是描述性模型而非分析性模型。需求的识别及其精确流程超出本文范围，但其中包括对后续测试与保障的考虑，这些通常在该阶段为简化需求而被忽略 [17]。

1.4.4. 任务工程¶

前文讨论了以下关键点：

系统因复杂性上升而变得更昂贵；
系统工程存在多种定义与理念；
M&S 已在设计与采办流程中应用多年，但仍面临数据集准确性与时效性挑战；
MBSE 通过摆脱基于文档的信息结构，有潜力为高质量仿真提供数据支撑。

这些因素是理解任务工程（Mission Engineering）在其中作用的关键。随着系统日益复杂，识别恰当的需求与用途变得至关重要，以便合理聚焦开发范围。这种必要性延伸到作战环境，其在五大正式作战域之间以及电子战这一“第六域”之间的互联性不断增强 [18], [19]。由于系统工程定义多样，因此不存在唯一优化的系统工程方法。但只要能够合理论证某一应用不违背系统工程理论，则可以从多元的信息基础中借鉴方法。换言之，若能证明任务工程是系统工程的延伸，则不仅可以通过系统模型更好地支撑任务级分析工具，还能在任务与系统设计一体化的框架中利用更高保真度的基于物理设计工具。工具选择范围的扩大也引出了一个新问题——面向任务的仿真框架应具备怎样的结构。

1.4.5. 任务层级仿真框架¶

虽然超出本文直接范围，但理解任务层级联邦式仿真的概念对任何任务级模型而言至关重要。仿真框架是任务工程的动态仿真部分，其中所开发的模型为仿真框架提供输入信息。为支持任务分析，该框架必须同时满足作战用户需求与系统工程需求。这意味着其必须能够在五大战斗域中实现高保真运行 [20]：

空域（Air）
网络空间（Cyberspace）
陆域（Land）
海域（Maritime）
太空（Space）
电磁频谱（Electromagnetic Spectrum，非正式作战域）

此外，还必须回答典型的任务工程问题。以下为 DoD《任务工程指南》中的示例 [21]：

本研究涉及哪些作战域（空中、地面、水下、太空、网络等）？
模型需要具备何种保真度以充分回应任务描述或分析问题？
需要哪些模型来进行分析（例如 6 自由度、基于物理的模型）？
哪些模型可直接使用？所需模型是否已存在？
模型的溯源性如何（验证、确认、认证等）？我们是否构建了正确的模型以供使用？

在这些需求与问题之上，任务工程与系统工程之间存在一个关键差异：任务的动态与互操作性。已部署的系统通常为相对静态的设计，而兵力编组则根据任务需求进行动态调整。因此，若将系统工程直接应用于任务工程场景，往往会导致僵化且次优的解决方案。

此外，涉及的作战域比表面上更为复杂。某些任务目标可在单一域中完成，但若通过多域协同可能更高效。权衡则在于资源需求、可用性以及新参与者的引入。例如，俄罗斯联邦入侵乌克兰的行动展示了网络域在传统空地一体作战中的重要作用。商业卫星与社交媒体的广泛应用使开源情报（OSINT）成为冲突的新维度，让任何有互联网连接的人都能实时了解战况。尽管深入探讨这些变化对未来作战条令的影响超出本文范围，但可以肯定的是，新的战略侧翼手段使“任务发生在哪里”这一任务工程的基本问题本身也成为战略层面的多变量权衡问题。一个健全的任务工程框架必须能在权衡分析中考虑这些因素，而非依赖任务设计者在前期主观决定。

随着作战域数量的增长给任务工程带来越来越高的复杂性，关于所需模型保真度与风险水平之间的平衡问题变得愈发重要。从时间、成本、信息可得性与安全分级等角度来看，计算任务的所有排列组合都是不可行的。

正如文献综述将展示的那样，针对不同用户群体存在两类工具集。一类是兵棋推演（wargaming）工具，主要用于需求生成与兵棋推演。这些工具在不影响任务演练能力的前提下，持续提升实体建模的保真度。另一类是工程工具集，如计算机辅助设计（CAD, Computer Assisted Drawing），其不断强化跨学科仿真能力，以改进复杂系统的设计。这两类工具集在各自领域内的互操作性仍有限，但这种能力也在不断成熟。例如，任务用户侧的网络化仿真器已可通过 DIS（Distributed Interactive Simulation，分布式交互仿真）或 HLA（High Level Architecture，高层体系结构）进行联动，而工程侧的软件如 Model Center 已能将 CAD 与 MBSE 模型连接起来 [22]。

假设未来能独立发展出任务仿真框架是合理的，这一设想的依据同样来源于系统工程领域的多域分析与优化（Multi Domain Analysis and Optimization，MDAO）。MDAO 是系统工程领域曾面临的类似问题的典型案例——不同学科间必须实现热、电、结构等模型的互操作与集成，以构建统一的仿真环境。熟悉 ANSYS 或 COMSOL 的工程师都会对这一过程的不同阶段有所了解。而这些工具及其公司也已开始将其仿真环境扩展至 MBSE 模型，为未来的集成提供了基础设施 [22]。目前已有一些研究团队正在探索该方向的集成问题。然而，正如前文所述的系

2. 文献综述¶

本节涵盖与任务工程（Mission Engineering）和基于模型的系统工程（Model Based Systems Engineering，MBSE）相关的开源文献。其内容包括该学科的现状介绍及其对资料来源倾向（偏离学术界）的影响。任务工程部分回顾了任务工程从兵棋推演（wargaming）起源至现代实践的发展历程，以及指导当前“做什么”和“如何做”的相关文件。MBSE 部分则阐述了系统工程演变为 MBSE 的过程、业界标准建模语言（SysML），以及与任务工程应用场景相关的多篇文献。本文所述内容将构成当前任务工程目标及其实现途径的基础框架。

2.1. 学术文献综述现状¶

本文的主要参考资料来源于政府与国防工业部门。这是因为任务工程与 MBSE 对大型技术组织（如 NASA、国防工业、美国国防部等）比对学术界更具实际应用价值。由于这些机构的规模与任务范围较大，导致期刊论文相对稀少。此外，该领域还受到敏感信息限制，因为军事或企业针对未来作战或产品规划的详细示例通常不会公开发布。

尽管这些非期刊来源的资料仍需通过政府内部同行评审才能公开发布，但其大多来自权威机构（如 INCOSE 或其他方法论制定者）、公认教材（如《SysML Distilled》或《A Practical Guide to SysML》），或大型国防承包商（如波音公司）的公开资料，因此在各自领域中仍被视为权威来源。然而，由于其偏离传统的学术期刊来源，这一点需要加以说明。

图 5 行业受访者的报告市场领域（左）与组织角色（右）[23]

图 5 说明了上述问题的根源，展示了一项由学术机构在政府委托下、结合产业输入开展的研究，因此该结果可视为出版空间的代表性描述，而非样本偏差。

2.2. 任务工程文献综述¶

任务工程文献综述从 19 世纪中期的起源开始，回顾其至现代应用的发展历程。现代任务工程不仅包括国防部针对重点领域与流程的指导性文件，也涵盖支持任务执行的仿真方法探讨。最后，本节回顾并说明将于后文示例任务中使用的 JCIDS（联合能力集成与开发系统）关键性能参数（KPPs）。本节旨在明确任何建模方法必须满足的任务工程目标，这些考虑因素将为后续 MBSE 章节提供指导。

2.2.1. 任务工程与兵棋推演的历史¶

广义上讲，兵棋推演（wargaming）作为预测战争的手段，与战争本身一样古老 [24]。现代意义上的兵棋推演最初起源于训练非贵族出身军官掌握高层战术的方法 [24]。这些演练的目标在当时及至今，都是分析拟定装备与战术对特定交战结果的潜在影响 [24]。精心设计的兵棋推演在多次冲突中带来了显著的竞争优势，尽管它并不能保证胜利 [25]。
兵棋推演的现代范式始于 1820 年代，两位普鲁士军官冯·赖斯维茨（von Reiswitz）父子开发了一套正式化的地图与棋盘式推演方法。这些要素至今仍是现代兵棋推演的标志，只是现已数字化 [25]。

在美国，兵棋推演最早由海军于 19 世纪 80 年代正式采用，其推动者是威廉·麦卡蒂·利特尔（William McCarty Little），自那时起便成为海军教育与作战筹划的核心组成部分 [24]。

兵棋推演的核心组成部分之一是裁决（adjudication）方法。英国国防部《兵棋推演手册》（Wargaming Handbook）第 3 章 [25] 讨论了不同类型的兵棋推演及其裁决方式。合理的裁决机制是任何兵棋推演最关键的环节之一，因为它与实体定义共同构成了兵棋推演经验与结论的基础。

常见的裁决技术包括：

角色扮演（Role Play）：
“防务兵棋推演有时包含角色扮演元素，但很少完全依赖角色扮演。角色扮演通常倾向于自由或协商式/最小化裁决。限制角色扮演参与者的交互可以降低其影响，但也可能削弱角色扮演的优势（自由思考与创造性）。角色扮演的极致形式是完全开放式、依靠协商裁决的游戏。有研究表明 [42]，在处理人类冲突情境时，角色扮演比单一‘专家’、博弈论模型或模拟交互与未辅助判断更能预测冲突中的决策结果。” [25]

调节（Moderation）：
“调节用于引导兵棋推演实现特定训练目标，或在分析性活动中过滤极端结果。调节通常应用于半刚性裁决中，并可在任意方向上影响结果（趋向平均预期结果）。但调节也有风险，因为趋向平均结果可能掩盖计划受偶然性与运气影响的脆弱性等重要结论。” [25]

作战分析（Operational Analysis）：
“作战分析为裁决者提供参考，通常以最佳、最差与最可能结果的形式呈现。该方法使裁决趋向刚性化。” [25]

计算机辅助（Computers）：
“计算机辅助可采用‘插件’模型或电子表格‘战斗计算器’形式，为裁决提供决策参考。与作战分析类似，其影响方向是更刚性的结果。计算机化仿真可进一步强化这种刚性趋势，并在许多情况下承担完整的裁决功能。” [25]

图 6 兵棋推演裁决方法刚性谱（作者绘制）

每种方法都有其优缺点。然而，对于设计权衡研究而言，计算机化兵棋推演的可重复性尤为重要。随着战争技术复杂性的提高（如网络与电磁领域的引入），裁决过程愈加复杂，计算机裁决的价值随之上升。
总体而言，可用于兵棋推演的轻量化计算机仿真通常在人的心理社会和政治特征等方面作出较大简化。这些简化通常是必要的，因为学习与执行时间有限，且需要为用户提供实时反馈 [24]。

预测分析（Predictive Analysis）可用于弥补有限的历史参照 [26]。其中可包含对人因的刻画，但受限于数据不足与可比性有限。这也是为何近年研究者格外关注纳戈尔诺-卡拉巴赫战争与乌克兰战争等相对对称且装备现代化的冲突案例 [27], [28], [29]。计算机为应对预测分析中固有的高计算需求提供了一种有效手段。

2.2.2. 向任务工程的转变¶

迄今为止，兵棋推演的主要目的一直是作为军事指挥官的训练与决策辅助工具。随着现代军队所依赖技术的复杂度和重要性不断提高，以往对于装备的抽象层次必须被降低。从技术角度来看，在人体本身承担感知、攻击与机动职能的时代，兵棋推演中的参与者天生就是相关系统的技术专家。而现代军队在许多作战中，借助雷达、高超音速导弹以及机械化/机动化/装甲化部队，已大幅超越了人类本身的感知、打击与机动能力。这导致传统兵棋推演中产生误差，因为关键的技术理解已不再存在——鉴于上述领域的发展本身需要专业知识，这种情况完全可以理解。
然而，这种由于装备与技术抽象化所带来的误差亟需修正，而修正的前提是将工程师与系统表示纳入决策与兵力设计的核心环节。这一融合愿景在《国防采办指南》（Defense Acquisition Guidebook）中得到明确表达，该书将任务工程（Mission Engineering, ME）定义为：“有计划地规划、分析、组织与整合现有与新兴的作战与系统能力，以实现期望的作战任务效果。” [21]
该定义既包含了传统兵棋推演中为达成作战效果所进行的规划、分析与组织活动，又强调了系统能力的集成为实现任务效果的内在方法。将技术复杂的系统因素融入传统兵棋推演流程正是任务工程的核心本质。

任务工程并非完全取代兵棋推演，而是根据系统复杂度与分析类型之间的匹配关系进行权衡。图 7 展示了三种方法之间的关系：计算机建模、兵棋推演与合成训练环境。建模通常更具技术性，研究范围较小，包含静态或动态模型；兵棋推演以人为中心，正如引言中所述，其形式更自由、技术要求相对较低；而合成训练环境更适用于高成本的训练任务，其输出可用于支持兵棋推演与建模，在适当情况下将人纳入回路。

图 7 展示了在权衡空间中确定最合适方法的一个维度。任务工程位于图中的星形标记附近。它既不是建立成本最低、速度最快的方法，其技术性考虑也限制了可分析问题的范围。然而，它仍能以有意义的方式将决策者纳入设计过程。此外，对于任务工程，还需考虑另一个维度——技术严谨性（technical rigor）。

图 7 兵棋推演的优势、劣势与交集 [25]

图 8 技术严谨性的正交轴（作者绘制）

图 8 展示了现代战争的另一个关键方面：兵棋推演的技术严谨性。技术严谨性指在研究中考虑系统性能与行为的深度。随着复杂性的增加，必然出现若干权衡，主要体现在成本、研究时间及可分析问题上限等方面。美国《任务工程指南》中以多轴视角描述了技术/分析严谨性与时间、成本之间的权衡关系：

Mission Engineering 在多层级中的应用

图 9 任务工程的三维坐标轴 [21]

二维纸面难以完整表现四维权衡空间，但结论相对直观：人类能轻松处理的复杂性是有限的，在此限制之下，决策复杂性、技术复杂性、范围复杂性与时间引发的复杂性必须相互权衡。这种“人类上限”正是为什么在决策过程中——无论军事或商业领域——始终存在不同层级的分析方法。这也解释了任务工程并非要取代兵棋推演，而是作为一种进化式工具，用于寻找敌方的物理或技术弱点。

综上三图所示，任务工程旨在融合兵棋推演的决策导向特征与较小范围的技术建模（这些模型与系统设计相联系，后续章节将展开说明），以支持能力与方案的预测分析。这种融合通常表现为基于工程模型信息的计算机化兵棋推演，使用概念化系统作为唯一可行的方式来再现所涉及的复杂度。

这种计算机化方式可扩展技术范围，因为计算能力的提升有助于缓解复杂性增加带来的影响。从形式上看，任务工程处于交战建模（单对单）与战役建模（群对群）之间，如图 10 所示。

(U) 国防部 M&S 类别层级

图 10 M&S（建模与仿真）类别层次结构 [119]

在 MBSE 定义的系统基础上正确使用物理与工程模型已能支撑交战级工程分析。多个建模交战可叠加形成单个任务模型，并在增加资源需求的同时保持可追溯性——这正是本文的核心论点。当前趋势表明，只要仿真能力进一步增强以支撑这一思路，这将是下一逻辑步骤。未来若能广泛采用融合实装（Live）、虚拟（Virtual）与构造（Constructive）实体的仿真能力，以在需要时实现现实世界保真度，并通过快速开发与测试的构造实体来降低成本与进度风险，将成为本研究成果应用的关键推动因素。

2.2.3. 任务工程的仿真类型 —— LVC¶

在明确任务工程的定义之后——即一种高度计算机化/仿真化的兵棋推演形式——有必要进一步讨论任务工程如何在支撑采办（acquisition）的更大仿真体系结构中发挥作用。

仿真主要分为三大类 [30]：

实装仿真（Live）：由真实人员操作真实系统的仿真。

涉及个人或群体；
可能使用真实装备；
应提供与真实作战环境相似的操作区域；
应尽量接近实际活动。

虚拟仿真（Virtual）：由真实人员操作仿真系统。虚拟仿真将“人类在环”（Human-In-The-Loop）置于核心位置，重点锻炼以下能力：

动作控制技能（例如：驾驶飞机）；
决策技能（例如：分配火控资源并执行任务）；
通信技能（例如：C4I 团队成员间协同）。

构造仿真（Constructive）：由仿真人员操作仿真系统。真实人员可输入刺激（即提供输入），但不直接参与结果的确定。构造仿真能够：

分析作战概念；
预测可能结果；
压力测试大型组织；
进行测量；
生成统计数据；
执行分析任务。

如前所述，任务工程完全属于构造仿真范畴。通过使用物理硬件（无论是计算机还是人工接口），可将其扩展至虚拟仿真模式，只要其仍处于构造仿真环境之内。当实弹操作被纳入后，任务工程与测试与评估（Testing & Evaluation, T&E）之间的界限开始变得模糊。尽管两者是相互支撑的，但若将其融合，便会超越单独的范畴，形成更高级的概念——这正是“实装-虚拟-构造仿真”（Live Virtual Constructive, LVC）的基本思想。

LVC 被用于降低组织（包括商业和政府机构）的测试与评估（T&E）成本。例如，美国国防部（DoD）拥有多种 LVC 实施体系：海军的 NILE 系统 [31] 与陆军的 MATREX 框架 [32]。此外，非国防机构如 NASA 也使用 LVC 来分析国家空域系统（NAS）中无人机系统（UAS）激增所带来的空域管理问题及其对航天发射的风险 [33]。

由于 LVC 是任务工程所支撑系统的更高层技术方法（任务工程在其中主要对应构造部分），因此有必要深入探讨 LVC 与系统设计周期、任务工程仿真需求、训练及结构之间的关系。LVC 具有广泛适用性的根本原因在于——没有任何一种测试方法是没有妥协的。下表概述了三种测试方式的比较性优缺点。

表 1 实装-虚拟-构造仿真测试方法的优势与劣势对比（综合 [33]-[35]）

方法	优势	劣势
实装（Live）	- 假设与抽象程度较低 - 具备真实性能与响应 - 培训潜力强 - 环境因素真实呈现	- 成本高 - 需使用实装硬件 - 计划周期长 - 重复次数少/数据量有限 - 平台资源竞争
虚拟（Virtual）	- 具备部分训练潜力 - 可进行实验室级测试 - 硬件实时响应	- 至少需原型硬件 - 抽象程度较高 - 研究范围较窄 - 验证与确认（V&V）困难
构造（Constructive）	- 可生成大量数据 - 仅需模型，无需制造原型 - 任务分析灵活 - 支持大规模跨域测试 - 不占用稀缺平台资源	- 准确性取决于工具 - 抽象层级最高 - 计算资源需求高 - 分布式测试可能引入延迟 - 验证与确认（V&V）挑战

在系统设计支持方面，LVC 提供了一种在正式实装测试前进行成本控制的途径 [34]，尤其适用于联合实装测试或演习。在生命周期的不同阶段，关键问题或关键作战问题与关切（COICs, Critical Operational Issues and Concerns）将决定采用何种 LVC 组合。

对于任务工程而言，构造仿真是最适用的测试类型。在该阶段，可通过合理假设与抽象、控制计算需求并谨慎选择工具来获得足够的精度。借助这些工具，任务工程能够以较低成本分析大量系统参与的多种任务，并生成丰富的数据以支持权衡空间探索（trade space exploration）。所生成的数据比实装测试更能满足任务工程的输出需求，因为后者主要用于验证系统是否符合环境保护性要求。此外，任务工程通常处于采办里程碑 A 之前阶段，此时系统尚未开发，需求尚未确定。

对于系统工程而言，LVC 的组合取决于系统成熟度。系统从概念阶段（whiteboard）、数字原型、台架原型逐步发展到实装系统，其测试方式也会从构造仿真逐渐过渡到实装仿真。仿真永远不会完全取代实装测试，正如实装测试永远无法提供实战中才能获得的信息一样。然而，若合理利用前两者（虚拟与构造仿真），则有望在一定程度上减少实战验证的必要性。

尽管 LVC 具有显著优势，但仍面临若干挑战，尤其是在分布式测试领域。全国范围内建立数字互联的仿真中心，以在联合数字战场中发挥各自独特能力，是一种极具价值的手段，但这依赖于一个广域、可互操作的网络。正如稍后在“具备网络化准备能力的联合能力集成与开发系统”（JCIDS）关键性能参数（KPP）部分所讨论的，这并非易事。不同的中心通常使用各自专用的协议与软件，这些系统需被整合进统一框架。
就本文而言，可以认为该问题正持续改善，并已具备相当成熟的能力。针对这些协议与体系架构的比较分析与路线图研究已有大量论文与学位论文专门讨论，更多信息可参考文献 [31]–[39]。

2.2.4. 任务工程的应用场景¶

任务工程在采办流程中可发挥作用的两个主要环节是：
（1）通过 JCIDS（联合能力集成与开发系统）进行能力缺口识别与备选方案分析；
（2）在综合测试策略（Integrated Testing Strategy）中，设计发展性测试（DT, Developmental Test）与作战测试（OT, Operational Test）事件。

表 2 JCIDS、任务工程与测试评估（T&E）目标声明对比

联合能力集成与开发系统（JCIDS）[40]	任务工程 [21]	综合测试 [40]
“由参谋长联席会议主席建立的系统方法，用于识别、评估和优先排序联合作战能力的缺口，并推荐潜在的解决方案以弥补这些缺口。”	“有计划地规划、分析、组织和整合当前与新兴的作战和系统能力，以实现期望的作战任务效果。”	“执行一个无缝衔接的测试计划，生成可供所有评估者使用的可靠定性与定量数据，涵盖发展、维持与作战问题。综合测试允许对测试事件进行协同规划；在单一测试点或任务中，通过不影响参与测试组织目标的前提下，获取可满足多个测试目标的数据。在此背景下，测试点指由时间、三维位置与能量状态以及系统运行配置所定义的测试条件；在测试中对被测系统施加预先计划的测试技术并观察与记录其响应。”

从表 2 的右侧向左侧阅读，代表系统从需求识别到测试评估（T&E）阶段、再到部署前的完整设计周期。
总体而言，仿真已在复杂系统设计中实现了广泛应用，这一点可从多份文件中得到印证 [10], [11], [21], [40], [41]。然而，许多研究和开发工作仍较为封闭（stove-piped），这一观察虽具主观性但反映出现实问题。

在下一节中，将探讨如何利用任务工程作为一种方法，直接将能力缺口识别与测试评估（T&E）阶段相连接，然后在下一章进一步探讨其与系统工程设计流程之间的联系。

2.2.4.1. 与测试的关系¶

综合测试与任务工程的目标具有相同的核心原则——识别可能阻碍预期作战任务效果的作战问题或设计缺陷，并为决策者提供可支撑决策的结果。当将其需求列出时，这种关系变得更加清晰。

综合测试（Developmental Testing 与 Operational Testing）的主要需求包括 [40]：

在复杂的联合任务作战环境中进行评估，涉及不同成熟度水平的系统（整合升级系统与遗留系统）；
以安全且经济的方式尽可能逼近真实作战环境；
使用经过验证的战术、技术与程序（TTPs）；
模拟蓝方与红方力量；
使用已验证的作战情景；
包含威胁与反制威胁；
具备专用的测试靶场（在控制参与者、数据采集与实时及后期分析所需的仪器精度上可能存在差异）；
建立数据采集、管理、归档与检索流程；
系统内嵌传感器与仪器设备。

从上述需求列表中，很难一眼看出这些要求究竟属于综合测试还是任务工程。这正体现了二者的高度重叠性，并支持将任务工程方法进一步应用于发展性测试（DT）与作战测试（OT）的规划中。
就任务工程而言，仿真在满足部分需求方面甚至比实装测试更具优势。这得益于仿真可实现更大量的运行次数，且其在真实度上的不足可通过对量程仪器与数据采集系统的建模补偿。
上述内容摘自《国防采办指南》，其中还特别强调了一项最终要求：

需要具备“分布式实装/虚拟/构造（LVC）联合作战环境”的能力（这是在复杂系统之系统环境中进行测试与训练的唯一可负担方式）。

构造仿真——任务工程的核心工具——被明确指出是综合测试的重要组成部分。
大量文献论证了在综合测试或测试与评估中引入仿真的好处，而关键结论在于：任务工程作为构造仿真的进化形式与应用主体，能够并且应当为测试与评估（T&E）提供支撑。这也为任务工程在其核心职能——能力缺口分析与备选方案分析——中应提供的上下文与接口要求奠定了基础。

2.2.4.2. 备选方案分析 / 能力缺口分析¶

任务工程在系统设计中的两大直接作用是：识别能力缺口，以及在任务层级上进行备选方案分析。指导这两项工作的主要文献有两份：
其一是以系统为中心的《联合能力集成与开发系统》（JCIDS）；
其二是以任务为中心的《任务工程指南》（MEG, Mission Engineering Guide）。

2.2.4.2.1. 任务工程指南流程¶

《任务工程指南》（MEG）的定义此前已提及，简而言之，它是一种在任务层级上以实现对威胁的作战效果为目标的方法。其关键强调点在于“威胁”的重要性，而非针对威胁的“解决方案”。这一区别虽看似抽象，但实际上反映了两种方法论上的本质差异。

MEG 所概述的流程如图 11 所示，从问题陈述 / 任务定义开始，最终形成文档化研究报告。

图 11 任务工程指南流程 [21]

虽然该流程本质上是一个典型的权衡研究（trade study）过程，但任务工程流程的范围界定尤为重要。输出中所强调的 GRA 文档聚焦于任务层面的作战效能指标（MOEs）及任务间效应（例如：一个任务中使用的资产在另一任务中可能不可用）[21]。
这些任务层面的指标可进一步分解为 JCIDS 流程所使用的系统层级指标，如图 12 所示：

图 12 MEG 指标关系图（改编自 [21]）

尽管 MEG 很好地阐述了任务工程中进行深入任务层级权衡研究的流程，但该文件的范围与图 11 所示流程相似，即在输出结果如何被进一步利用方面细节不足。而这正是 MEG 与 JCIDS 流程相衔接的地方。

2.2.4.2.2. JCIDS 流程¶

JCIDS 流程采用自上而下的分析方式，从国家层面的优先事项出发，逐步生成系统层级的需求。根据《JCIDS 手册》，其目标是：

“识别能力缺口以及潜在的物质和非物质解决方案。虽然该流程考虑了条令、组织、训练、装备、领导与教育、人员与设施（DOTMLPF）等全谱系的解决方案，但就本指南而言，其重点在于寻求‘物质性’解决方案。” [40]

JCIDS 更侧重于系统层面，以构建物质解决方案为目标，为进入采办流程做准备。这些物质解决方案的概念需要经过设计与测试，这与前文提到的综合测试环节（Integrated Testing）直接相关。尤其值得注意的是，其总体目标并非单个系统，而是在“多个可互操作系统构成的综合体系架构背景下”进行设计 [40]。
JCIDS 流程主要由两个步骤组成，如图 13 所示：任务分析（Mission Analysis）与信息分析（Information Analysis）。这两个步骤体现了传统工程设计中的“实验—数据分析”迭代循环。

任务分析旨在定义任务主线（mission threads）、研究问题、作战序列以及“成功”的定义。该范围界定的任务分析结果成为信息分析阶段的基础，在此阶段可进行与系统更紧密相关的性能分析与方案权衡。在 JCIDS 框架下，这一流程实际上是任务工程（Mission Engineering）的简化版。这种简化是必要的，因为任务分析 / 工程并非 JCIDS 的核心焦点。然而，JCIDS 仍可从《任务工程指南》（MEG）提供的更详细流程中受益，如图 13 所示。

图 13 《任务工程指南》流程 [21] 支撑 JCIDS 网络化系统流程 [42]

在信息分析阶段结束后，系统需求的高层轮廓被传递至采办流程的下一阶段，以识别最能满足需求的技术或系统。这些输出以关键性能参数（KPP, Key Performance Parameters）的形式呈现，解决方案系统必须根据这些参数进行设计，或基于其派生需求进行开发。KPP 将在后文详细讨论，因为它们是 MBSE 在全新系统设计中建立接口的关键点（见图 16）。

在测试前的系统设计过程中，还有一个名为“备选方案分析”（AoA, Analysis of Alternatives）的步骤，用于比较潜在解决方案。其正式定义为：

“AoA 应描述并包含支持性分析与权衡研究的结果，以确定作为优选系统方案组成部分的最佳保障概念。” [40]

图 14 备选方案分析（AoA）流程示意图 [40]

通过记录 JCIDS 流程生成的需求，并评估高层次的备选方案以进一步细化解决空间，为后续系统工程流程奠定了基础。
如果这些需求按照任务工程的计算机化方式以数字形式记录（例如使用 SysML），则可在流程至解决方案模型之间建立技术关联 / 数字线索（digital thread）。这种关联同时满足了基于模型的系统工程（MBSE）中的需求生成步骤。
这与传统兵棋推演形成鲜明对比——后者依赖书面或口头记录，并通过多级审阅传递至技术执行机构。若实现这些功能领域的双向技术集成，系统开发者与项目经理即可在整个系统设计周期中执行 AoA，从而更好地评估设计权衡并应对任务集变化。这也将使流程更接近 JCIDS 的迭代方法，而非典型设计流程中常见的线性、脆弱的瀑布式模式。

在阐明了 JCIDS、基于能力的评估（CBA, Capabilities-Based Assessment）与 AoA 如何与任务工程相关之后，本文将进一步探讨两者之间的紧密联系。

根据《美国国防部采办指南》：

“在制定物质解决方案的过程中，关键的测试与评估（T&E）信息来源包括基于能力的评估（CBA）、备选方案分析（AoA）、JCIDS 文件等。T&E 领域特别关注的项目包括：[40]”

任务描述、场景、作战构想（CONOPS）、性能属性与效能指标、目标与威胁、作战环境等；
任务到作业（mission-to-task）分解及基于场景的作业绩效标准；
作业到系统 / 子系统的映射与功能关联；
将任务效能指标（MOEs）与系统性能属性和度量相对齐。

这些正是任务工程所旨在生成的成果，使任务工程作为整体需求生成过程的一个子集，能够凭借自身的产出自然地支撑测试与评估（T&E）活动，同时服务于设计需求流程。

2.2.4.2.3. MEG 与 JCIDS 的关系¶

通过对这两种方法的简要介绍可以看出，JCIDS 与 MEG 流程是相互交织的。MEG 对 JCIDS 内嵌的“任务分析（Mission Analysis）”步骤进行了细化，而 JCIDS 则利用并吸收任务工程（Mission Engineering）的成果。
相比现有的 JCIDS 初始阶段，任务工程在方法深度与能力上的增强使其更适合用于改进 JCIDS 的任务分析环节。两种方法的互补关注点可总结如下表 3 所示。

表 3 JCIDS 与 MEG 的比较总结

领域	JCIDS	MEG
关注点	任务中的系统性能	任务整体（系统之系统）
解决空间	新系统	新系统或对现有系统的改进
主要用户	采办部门	采办与作战部门
使用场景	通用	多个特定任务与作战片段（vignettes）
度量指标	关键性能参数（KPPs）	任务层级的成功度量、效能度量与性能度量

这些关注领域的差异需要进一步解释。JCIDS 的关键性能参数（KPPs）虽然将在后文详细讨论，但其本质上属于任务层级指标，因为它们涉及对威胁的考虑，尽管仍带有明显的系统视角倾向 [42]。
相比之下，MEG 的重点是任务效果（mission effect）。这引出了一个问题：如果两者都属于任务层级考量，那么系统工程（System Engineering）究竟从哪里开始？
根据文献回顾，最清晰的划分线在于“是否考虑威胁”。任务层级的 KPP 必须包含一个特定的威胁，而针对该威胁的解决方案则可能是基于系统设计的，或通过替换不同系统来实现。
正如后文示例任务所示，任务层级的 KPP 可以被细化为系统层级的 KPP，例如燃料消耗可由针对特定目标的探测距离推导得到，如图 15 所示。
系统 KPP 与任务 KPP 的划分概念在文献中比缩写本身更具意义，因为 KPP 的使用在实践中并不总是严格区分任务或系统层面。
在本文语境中，KPP 一词仅表示“关键性能参数”，无论其属于系统层级还是任务层级，只要具有相关性即可。

虽然本文在示例任务中将两种方法结合使用，但由于其与 MBSE 方法（见图 16）的集成倾向，内容重点偏向于 JCIDS 的系统导向 KPPs。

图 15 系统与任务指标之间的关系 [21]

这种对 JCIDS 系统导向 KPP 的侧重，源于其作为任务侧与 MBSE 集成的接口位置，如图 16 所示。

图 16 《任务工程指南》（MEG）流程 [21] 支撑网络化系统的 JCIDS 流程 [42]，并为 MBSE 提供输入 [95][98]

2.2.5. 技术任务优先级¶

在前文中已说明任务工程的产出成果可同时用于系统设计过程与测试与评估（T&E）事件规划，并阐述了这些成果的生成方式。接下来将概述当前重点投资的技术领域，这些领域将直接影响未来任务工程的范围与方向。

本文并非旨在深入分析这些高层文件，而是选取三份主要指导性文件，对其内容进行交叉比对，以识别共通点。这些共通项用于限定仿真框架的边界，并可视为当前美国国家层面的战略技术代表性方向（下文保持原有顺序）。

表 4 展示了《美国国家防务战略》（NDS）、国防高级研究计划局（DARPA）以及国防部研究与工程副部长办公室（OUSD(R&E)）所列的技术重点领域。表中保持了各文件中主题的原始顺序，并通过颜色标注突出三者之间的相似技术领域。

表 4 美国 NDS、DARPA SBIR 与 OUSD(R&E) 技术领域优先级对比

优先级	NDS [43], [44]	DARPA 2019 SBIR/STTR BAA [43]	OUSD(R&E) 现代化优先方向 [45]
1	高超音速（在受阻环境下实现联合杀伤力）	人工智能	人工智能 / 机器学习
2	定向能武器（在受阻环境下实现联合杀伤力）	自主性	生物技术
3	指挥、控制与通信（C4ISR）	通信	自主性
4	太空攻防（太空与网络空间作为作战域）	网络安全	网络安全
5	网络安全（太空与网络空间作为作战域）	定向能武器	定向能武器
6	人工智能 / 机器学习（先进自主系统）	高超音速	FNC3（未来网络化指挥、控制与通信）
7	导弹防御（导弹防御）	微电子	微电子
8	量子科学与计算（先进自主系统）	量子科学	量子科学与计算
9	微电子（弹性与敏捷的后勤）	太空	高超音速
10	自主性*（先进自主系统）	核现代化	太空

从三家机构的优先级列表中可以看到显著的共性，这为未来可能出现在任务工程场景中的主题方向提供了明确指导，也因此为建模与仿真框架所需支撑的重点领域提供了方向。

从表 4 可得出两个主要结论：

一致性强 —— 三份清单在重点技术方向上具有高度一致性，这说明建设能够覆盖这些领域的仿真能力是一项值得投入的工作，因为资金与研究方向具有重叠性；
技术跨度广 —— 这些清单覆盖的技术范围极广，表明要建立具备充分技术严谨性的仿真能力将面临较高难度。由于其需整合来自多种来源的信息，因此必须采用一种新的信息输入机制来支撑仿真框架。

鉴于基于模型的系统工程（MBSE, Model Based Systems Engineering）日益普及，MBSE 被视为提供系统真实信息的权威来源是合乎逻辑的选择。

接下来的章节将说明这些共性技术方向如何影响本文示例任务中所使用的信息类型。无论某一技术方向是否被纳入示例任务，其在高层战略层面都具有重要意义。部分技术未被包含，仅因篇幅与敏感性考虑，并不意味着其优先级较低。

2.2.5.1. 人工智能（Artificial Intelligence, AI）¶

OSD 定义：
“国防部将利用人工智能（AI）提升美军的作战效率与效能。作为一个部门，我们正在评估哪些流程与程序可通过采用 AI 技术来实现，以满足作战人员需求并支撑国防优先事项。” [45]

DARPA 目标：
“改进算法、提升数据质量、优化人机协同、破坏对手的技术努力。” [43]

任务工程在本研究中的潜力与应用：
该领域在任务工程中主要体现为对仿真框架的应用，用于提供构造性环境以开发 AI/ML 并降低测试风险。尽管通过实验设计（如本文的示例任务）生成结果并据此训练特定类型的 AI/ML 是可行的，但此类工作超出了本论文关于 MBSE 支撑任务工程的研究范围。

2.2.5.2. 自主性（Autonomy）¶

OSD 定义：
“自主性（Autonomy）扩展并补充了人类能力，其优势包括持续性、体积小、速度快、机动性强，并能降低人员风险。国防部的目标是实现多样化无人 / 混合编队能力的无缝集成，为联合部队提供灵活的作战选项。” [45]

DARPA 目标：
“研究自主系统协同（teaming）、机器感知、推理与智能，以及人机信任与交互机制。” [43]

任务工程在本研究中的潜力与应用：
人工智能是自主性的关键支撑要素，二者在适用性方面具有相似特征。因此，出于篇幅与研究范围限制，本文的示例任务不单独探讨自主性。
在任务工程中，自主性开发可能是最能发挥构造仿真（constructive simulation）优势的场景之一（当用于探索行为特征时），也可能是效用最低的应用之一（当用于目标感知与分类时）。
值得简要指出的是：通过自动化执行任务工程中的实验设计，可通过增加仿真运行次数与权衡空间点密度来缓解任务范围问题，从而获得更高分辨率的权衡空间地形。这种自动化的实现前提是必须具备大量高质量数据，进一步凸显了任务工程中系统“权威真实源”（authoritative source of truth）的重要性 [46]。

2.2.5.3. 定向能武器（Directed Energy, DE）¶

OSD 定义：
“随着定向能武器（DE）成熟为可部署能力，我军有潜力以极高精度、最小附带损害及极低单次交战成本，防御多种威胁。高能激光（HEL）技术及硬件的发展正使激光武器系统日益可行。” [45]

DARPA 目标：
“研究功率扩展、抖动抑制、激光器尺寸与重量、自适应光学、光束传播与目标跟踪。” [43]

任务工程在本研究中的潜力与应用：
在示例任务的建模过程中，定向能系统将主要由以下参数定义：功率容量与生成能力、抖动、功率消耗速率、尺寸与重量。

2.2.5.4. 高超音速武器（Hypersonics）¶

OSD 定义：
“高超音速武器的飞行速度超过音速五倍以上。研究重点在于这些武器在战区或区域冲突中所带来的战术能力：快速响应、高速机动、难以发现、跟踪与拦截。我们正在对攻防作战力量结构进行现代化改造，以利用并威慑此类能力。” [45]

DARPA 目标：
“研究高温材料、高超音速飞行器制造、吸气式推进与高超音速制导与控制系统。” [43]

任务工程在本研究中的潜力与应用：
由于敏感性等多方面因素，高超音速武器不在本文示例任务的讨论范围之内。

2.2.5.5. 太空（Space）¶

OSD 定义：
“美军跨域作战方式依赖于及时且可靠的太空支援效应。鉴于对手的能力与技术进步，我们必须迅速构建更具防御性与弹性的太空态势。强化现有航天器编队的防护与韧性至关重要。” [45]

DARPA 目标：
“开发用于导弹预警、情报、监视、侦察、导航与通信的低轨纳卫星（LEO nanosatellites）。” [43]

任务工程在本研究中的潜力与应用：
尽管太空本身是完整的作战域，但鉴于敏感性问题，本论文示例任务不纳入相关讨论。

2.2.5.6. 微电子（Microelectronics）¶

OSD 定义：
“随着对廉价、轻量化设备需求的增长，微电子技术迅速发展并被广泛应用于国防系统。外国微电子（ME）产业的生产与投资行为正在威胁美国的现代化能力。我们必须开发并交付下一代微电子技术，以提升杀伤力、保障关键基础设施并保持经济竞争力。” [45]

DARPA 目标：
“发展具有经济竞争力的本土制造能力，提升抗辐射加固技术，并开发用于核、太空与电子战的射频（RF）专用技术。” [43]

任务工程在本研究中的潜力与应用：
微电子主要影响任务工程所生成需求的可实现性，因此不直接参与任务层级仿真。这类差异将在下一节讨论任务层级关键性能参数（KPP）的范围与制定方法时进一步说明。

2.2.5.7. 量子科学与计算（Quantum Science and Computing）¶

OSD 定义：
“量子计算机对安全通信构成迫近威胁。保持美国在量子信息科学领域的领先地位将帮助我们应对这些风险。国家安全局（NSA）的加密现代化工作将保护最敏感的通信免受量子计算攻击。量子传感技术将提供新的精确定位、导航与授时能力（PNT），保障部队在 GPS 受限战区的安全。量子网络将极大提升目标探测能力，并利用商用量子计算资源解决国防部最复杂的分析问题。” [45]

DARPA 目标：
“研究量子时钟与传感器、量子通信技术，并开发量子计算支撑技术（如低温技术与光子探测）。 ” [43]

任务工程在本研究中的潜力与应用：
与太空和高超音速技术类似，关于替代 PNT（alt-PNT）与密码科学的设计或性能问题属于重点技术方向，但不适宜在公开文件中讨论。

2.2.5.8. FNC3 —— 通信（Communications）¶

OSD 定义：
“指挥、控制与通信（C4I）技术涵盖了在部队间获取、处理与分发信息的能力。国防部需要建立通向稳健 C4I 系统的清晰路径，确保具备多重冗余的全网络通信能力。现有能力必须具备足够的防护，以应对日益增强的威胁范围与效力。” [45]

DARPA 目标：
“研究高性能、低功耗嵌入式处理器，并开发自配置、自修复与资源分配算法。” [43]

任务工程在本研究中的潜力与应用：
通信能力将在本文的示例任务中体现，其传播机制具有充分的公开资料支撑，可通过仿真框架实现建模。

2.2.5.9. 网络空间（Cyber）¶

OSD 定义：
“网络空间是独特的作战域，既存在重大安全挑战，又具备可能带来作战跨越式发展的潜力，特别是在增强指挥控制、态势感知与自主作战方面。要在快速演化的网络空间中保持技术优势，是维持任务准备状态的关键。” [45]

DARPA 目标：
“研究网络行为问题，开发自防护网络，建立评估网络攻击效应与后果的方法论。” [43]

任务工程在本研究中的潜力与应用：
网络效应在构造仿真环境中既具挑战又具潜力，因为实装网络攻击与仿真系统运行在同类硬件上，形成闭环。
因此，将网络效应与其他构造仿真（如兵棋推演或 LVC 联合演练）结合，可实现较高的精度。引入真实系统硬件可进一步增强虚拟网络攻击的真实性。然而出于敏感性考虑，本文示例任务中不建模网络攻击效应。

2.2.6. 关键性能参数（Key Performance Parameters, KPPs）¶

任务工程的仿真框架为上述能力领域提供了多样的支撑能力（相较于传统的封闭式系统工程、T&E 或基于能力的评估 CBA/JCIDS）。因此，有必要简要回顾这些领域的缺口如何被弥补，以及它们最初是如何被确立为优先方向的。

联合能力集成与开发系统（JCIDS） 是系统需求生成的核心文件。它提供了一套指导原则，用于将兵棋推演与实验的成果转化为系统层级考量，即关键性能参数（KPPs）。因此，JCIDS 同时代表了基于文档的系统工程与 MBSE 的起点——任何系统的开发都始于一组任务需求的转化。

尽管 2018 年版 JCIDS 文件已由 2021 年版取代，但本文附录所引用的公开发行版（Distribution A）为 2018 年版本，因其附件 B（Enclosure B）内容的重要性，以下分析将以此为依据。
附件 B 详细说明了在开发用于执行任务的系统时，即使其性能受损但仍具作战能力，也必须考虑的四个顶层 KPPs [42]：

部队防护（Force Protection）
系统生存性（System Survivability）
可持续性（Sustainment）
能源（Energy）

2.2.6.1. 部队防护（Force Protection, 第一关键性能参数）¶

根据《JCIDS 手册》（2018）附件 B 附录 G 的定义：

“部队防护（FP）KPP 是四个强制性 KPP 之一，旨在确保保护系统使用者、操作员或其他可能受系统或威胁影响的人员安全。尽管 FP KPP 可能包含与系统生存性相似的属性，但其重点在于保护人员免受动能与非动能攻击、化生放核（CBRN）威胁以及环境效应的影响，而非保护系统本身的能力。” [42]

对 FP KPP 的分解包含多个审查要素，JCIDS 手册（2018）在附件 B 中对此进行了详细说明，概括如下：

是否有系统的综合分析文档，涵盖系统计划用途（包括作战环境与节奏）、威胁、脆弱性评估及支持 FP 目标的解决方案？
是否根据附件 B 的标准，提供了足够的防护以抵御动能与非动能攻击以及 CBRN 威胁？
若适用，系统乘员是否能免受环境效应及意外坠毁的伤害？

此外，关于生存性、威胁建模方法、示例用语及适用属性（如电磁频谱 / 非动能、网络、动能）等的更多内容可参见知识管理与决策支持（KMDS）平台。但该平台位于 SIPR 网络，因此超出本文公开讨论范围。本文所引用的全部信息均源自《JCIDS 手册》（2018）。

2.2.6.2. 系统生存性（System Survivability，第二关键性能参数）¶

根据《JCIDS 手册》（2018）附件 B 附录 G 附件 C：

“系统生存性（SS）KPP（四个强制性 KPP 之一）旨在促进关键作战人员能力的发展，使其能够在跨域和适用环境（包括太空）中，生存于动能（即传统、非常规和 CBRN）和非动能（网络和电磁频谱（EMS））威胁下。SS KPP 支持三个以系统为导向的目标：预防、在战术相关时间内的缓解以及从威胁和攻击中恢复。同时，SS KPP 保持对多种环境因素（如热、尘、湿度、EMS 拥挤区域等）的生存性。SS KPP 促进对可能威胁的分析，并推动系统之系统（SoS）方法的发展，通过网络化、自主或半自主系统利用深入、重叠或冗余的防御能力，确保尽管个别组件损失或退化，仍能完成任务。” [42]

系统生存性（SS）KPP 的分解包括若干评审标准。虽然《JCIDS 手册》（2018）附件 C 详细列出了这些内容，但其提炼清单如下：

是否有系统的全面分析文档，包括系统的计划用途（包括作战环境和节奏）、威胁（KE、EM 和 CBRN）、脆弱性评估以及支持 SS 目标的解决方案？
是否可以通过伪装、隐藏与欺骗（CC&D）、态势感知、在战术相关时间内的机动，或加固（即物理装甲、电磁、网络及环境危害防护）实现生存性？
最小化任务周期之间的停机时间，包括维护和战斗损伤修复。
确保系统可恢复，并确定执行维护和修复所需设施的级别及其在系统预期使用下的可用性。
性能属性是否与作战构想（CONOPS）中概述的预期用途一致，且标准是否现实且可测量？

2.2.6.3. 可持续性（Sustainment，第三关键性能参数）¶

根据《JCIDS 手册》（2018）附件 B 附录 G 附件 D：

“可持续性 KPP（强制性 KPP）。可持续性 KPP 旨在确保足够数量的能力解决方案准备好用于支持作战任务。” [42]

该 KPP 涵盖系统的整个生命周期，并且“源自系统可用性需求，以支持所需能力，假设其设计和作战用途如 CONOPS 和 / 或 OMS/MP 中所规定，以及在可靠性、维护概念、生命周期成本和计划维持策略之间的权衡。” [42]

可持续性 KPP 的分解包括若干评审标准。虽然《JCIDS 手册》（2018）附件 D 详细列出了这些内容，但其提炼清单如下：

物料可用性（Material availability）
“可通过数学表达为运行可用终端项数量 / 总数量” [42]
下表概述了针对某个特定地点的管理选项，以确定针对所面对威胁和建议系统能力所需的正确数量。

表 5 单一地点管理的系统总库存（Total System Inventory for Single Location Management）

CONOP S	Trainin g	Attrition	Prepositione d	Average Annual Down [1]	Total
CONUS
OCONUS
TOTAL
注释 1：基于假设的计划维修厂 / 船坞周期的平均不可用分配资产数量

作战可用性（Operational Availability）
这是 KPP 中较复杂的提炼之一，它计算平均年度停机时间并记录在上表中。系统处于“停机”（维修 / 维护）状态的时间比例取决于作战与训练活动的密度与节奏，虽然近似为稳态百分比，但实际上是复杂变量。
可用公式表示为：运行时间 / 总时间。
可靠性（Reliability）
可靠性影响作战可用性。它在指定条件下的特定区间计算。“对于连续使用系统（如飞机），可靠性应以主要使用度量（如运行小时、英里或飞行小时）来衡量。对于离散系统（如一次性弹药），可靠性应以概率衡量。” [42]
[42] 的图 B-23 讨论了不同系统的可靠性类型。该表可总结为：
- 任务可靠性 = 运行小时 / 任务失败次数
- 后勤可靠性 = 运行小时 / 后勤需求
- 计算机无需计算，因为“物料可用性不适用” [42]
可靠性会决定多个会增加后勤负担或减少作战可用性的因素，并代表系统总体性能的关键属性，尤其在后勤占用不可行的情景下。
运维成本（O&S Costs）
衡量系统在整个生命周期中的成本，确保系统在采办上可行，因为一个不完美但可用的系统要优于一个因成本过高而从未被采购的完美系统。

对于复杂系统（如本论文所涉及的系统之系统（SoS）），需要考虑的是可靠性从组件层级向上汇总，但 O&S 与作战 / 物料可用性则应用于 SoS 整体。
此外，《JCIDS 手册》（2018）附件 D 附录 G 附件 B 还包括更多问题，以协助确定上述指标，但由于篇幅原因未在此列出，这些问题是很好的参考，并将在后续章节的示例任务中使用。

2.2.6.4. 能源（Energy，第四关键性能参数）¶

根据《JCIDS 手册》（2018）附件 B 附录 G 附件 E：

“能源 KPP（强制性 KPP）。能源 KPP 旨在通过平衡系统的能量性能和在适用威胁环境下由作战指挥官所要求的维持系统 / 部队所需能源供应，确保部队的作战能力。” [42]

当前战场上的能源几乎完全依赖液体燃料。这种燃料具有巨大的后勤足迹，并拥有独立的供应链，从而放大了末端系统的需求。其余的能源形式是电能，虽然可以从本地电源获取，但通常仍依赖于液体燃料驱动的发电机。

能源相关的性能属性包括：

系统的作战效能与其能源需求之间的函数关系。对于系统之系统（SoS），应识别那些对任务效能最为关键的部分。
将该函数描述为运输中的载荷（质量或体积）/ 每加仑燃料。
峰值能耗时的消耗量（加仑 / 千瓦时）。
系统作为某种“能源节点”时，其需求随类型的不同而变化。

图 17 能源 KPP 的系统角色 [42]

基于能源性能的任务效能分析是否识别出了提供该能量的供应链中最关键的节点？
是否考虑了环境、威胁、作战节奏及已知的供应链限制？

为支持确定这些属性的价值，《JCIDS》文档概述了三步法及若干子步骤。三步如下：

“方法论的第一部分是分析整个机动单元可用的能源供应能力，考虑到其他使用相同能源后勤的消费者。能源供应能力不是一个单一数值，而是供应链在场景期间向未来机动单元输送能源的未来能力的核算。” [42]
“方法论的第二部分涉及考察平台、机动单元及其他使用相同能源后勤的消费者的能源需求。该分析审视系统所需的性能及其对能源源的影响，无论是作为接受者（从其他系统获取能量）还是提供者（向其他系统提供能量）。” [42]（见图 17）
“方法论的第三部分是在场景和威胁的背景下分析能源供应能力与能源需求之间的差异。如何解决这种差异将有助于确定应包含在能源 KPP 中的关键属性及其相关的阈值与目标值。” [42]

能源管理是一个至关重要的考虑因素，因为对能源（例如燃料）的不足考虑可能会导致昂贵的装甲车辆因缺少几加仑燃料而抛锚，被农用拖拉机“回收”并损失。

2.2.6.5. 网络就绪性能（Net-Ready Performance）¶

还有一个第五个强制性评估点，即网络就绪性能属性（Net-Ready Performance Attribute）：

“网络就绪性能属性确保单独开发和部署的能力解决方案之间的互操作性。” [42]

该附加评估点详述于《JCIDS 手册》（2018）附件 B 附录 G 附件 A。

网络就绪性能适用于任何由国防部（DoD）组件采购、获取或操作的信息系统。它要求明确以下内容：

网络接口兼容性（物理和协议兼容性）；
将连接到哪些网络？不仅包括 DoD 网络，还包括盟军网络；
将使用哪些指标描述性能？
吞吐量 / 带宽；
安全性；
谁将管理？如何管理？在何种配置参数下？
对电磁频谱作战（EMSO）的易感性及其在预期作战环境中对频谱管理的合规性。

这些关于网络就绪的问题应由 JCIDS 的哪些部分支持，其对应关系见表 6。该表特别重要，原因有二：
其一，它概述了不同抽象层次的测量类型，以及系统工程如何直接支持任务分析（即任务工程的基础起点）；
其二，它列出了向决策者传递信息的数据源与视图。这些视图（AV-1、OV-1 等）均为 DoDAF 视图，Cameo 已为 SysML 语言实现其扩展，下一节将进一步讨论。

表 6 网络就绪抽象到测量的关联表（Net Ready Abstraction to Measure Linkage Table） [42]

NR 开发步骤	NR 性能属性	属性细节	测量指标	示例数据源
任务分析（Mission Analysis）	支持军事行动（Support to Military Operations）	任务声明（Mission Statement）	系统的总体现实军事任务	执行摘要、CONOPS、AV-1
		任务活动（Mission Activity）	联合作战任务活动	OV-5a/b 或文档
		测量（Measure）	衡量支撑军事行动的联合作战任务活动成功的指标	SV-6/SvcV-6 或 SV-7，或文档
		条件（Conditions）	军事行动必须执行的条件	文档
		网络（Network）	系统必须连接以支撑其军事行动的网络	SV-1/SV-2 或文档
信息分析（Information Analysis）	接入并管理于网络上（Entered and Be Managed on the Network）	测量（Measure）	连接至网络及 / 或系统在网络上被管理所需时间	OV-3、SV-6/SvcV-6 或 SV-7
		网络（Network）	系统必须连接以支撑其军事行动的网络	SV-1/SV-2 或文档
		测量（Measure）	连接至网络及 / 或系统在网络上被管理所需时间	OV-3、SV-6/SvcV-6 或 SV-7
		条件（Conditions）	军事行动必须执行的条件	文档
		信息元素（Information Element）	联合实体之间交换的数据类型 / 种类	OV-3、SV-6/SvcV-6 或 SV-7
	信息交换（Exchange Information）	测量（Measure）	联合信息交换的性能属性 / 成功度量	OV-3、SV-6/SvcV-6 或 SV-7
		条件（Conditions）	军事行动必须执行的条件	文档
		信息元素（Information Element）	联合实体之间交换的数据类型 / 种类	OV-3、SV-6/SvcV-6 或 SV-7
		测量（Measure）	联合信息交换的性能属性 / 成功度量	OV-3、SV-6/SvcV-6 或 SV-7
		条件（Conditions）	军事行动必须执行的条件	文档
		确保信息系统满足属性要求从企业访问军事行动需要哪些服务？	从信息系统指标到派生作战需求提供可追溯性指标、示例架构数据源	OVs、SVs、StdV-1/StdV-2 和 / 或 SvcVs
系统工程与架构（Systems Engineering and Architecture）	支持所有三个属性

网络就绪性能是与系统工程最直接相关的任务分析层，因为它主要依赖系统设计参数，而非作战实施。许多此类参数在现场不可调整，这强调了必须在实验室与设计阶段事先解决这些问题。因此，网络就绪性能及其分析基于系统之系统（SoS）的互操作性。

2.2.6.6. 确定关键性能参数（Determining KPPs）¶

在概述了顶层 KPP 之后，接下来的任务是确定系统在任务中的适用性与评分。尽管《JCIDS 手册》（2018）中概述了一系列豁免条款，可在特定情况下免除部分支持性要求，但这些豁免超出本分析范围，此处仅考虑适用的 KPP [42], [47]。

虽然不同的 KPP 分解之间存在多重重叠，但每个 KPP 都适用于作战系统的不同方面。常见的分析过程如下：

确定适用性。并非所有系统都以相同方式使用所有 KPP。例如，网络作战系统不需要考虑坠毁时的乘员安全。
评估威胁。评估系统在所有领域中可能遇到的动能与非动能威胁。威胁评估对每个系统都至关重要，但并非每个系统都会面对相同威胁或具有相同脆弱性。
确定风险水平。基于评估的威胁和设计系统的脆弱性确定风险水平。当前设计是否处于可接受的风险等级？
制定系统需求。“为系统组件、功能和技术制定清晰、具体且可实现的需求，以确保系统在已识别威胁下的任务成功。如果指定了性能标准，确保其包含现实、可测试和可度量的阈值与目标指标。” [42]
这是将任务工程与系统工程连接的步骤，本研究所开发方法论的核心关注点之一即是如何管理此步骤。
风险管理。在设计过程中应用风险管理，根据前述步骤引导系统开发。综合考虑成本、进度与性能，确保方案既现实又可行，并能以所需数量实现。
向决策者展示分析结果，以可理解的形式呈现分析结论。

图 18 以图示方式表示了相同的流程，但语言略有不同。由于该流程是后续全部研究的基础，因此重复描述是值得的；若执行不当或理解错误，将对系统与能力产生级联影响。

图 18 关键性能参数（KPP）分析过程示意图 [42]

从更加系统中心的角度来看，《采办指南》（Acquisition Guidebook）也给出了其自身的行动清单，以支持通过 JCIDS 框架更一般性地提出的系统解决方案优化过程 [40]。这些行动包括：

按功能研究开发成本；
研究预期作战环境下候选系统的可行性；
执行工程权衡与方案分析（Analysis of Alternatives）；
研究与完善计划中的软件与计算机的可行性，以满足 KPP 要求；
在软件测试期间模拟尚未开发的设备，并在集成阶段仿真系统的互操作环境。

通过结合 KPP 流程与基于模型的系统工程（MBSE）建模过程，可以开发出可追溯到识别能力缺口的任务情景的系统需求。理解该过程是任务工程与系统工程之间的核心接口。

2.2.7. 任务工程综述总结（Mission Engineering Review Summary）¶

本章涵盖了假设任务描述的一半——任务工程部分。回顾任务工程的定义：“为实现所需作战任务效能，对现有与新兴作战和系统能力进行有计划的规划、分析、组织与整合。” [21]
可以清晰看到该定义中“规划、分析、组织”部分的演进。由此为后续探讨可用于支持这些工作的仿真类型、测试与需求奠定了基础。这一部分将把前文讨论的“如何”和“为什么”与“是什么”结合起来。

在国家级优先事项概述的基础上，讨论转向了由 JCIDS 过程定义的顶层 KPP。这些 KPP 对于将作战任务集、能力缺口与能力转化为系统工程师可用于构建设计系统的形式至关重要。简要总结如下：

Force Protection（人员防护）：关注保护人员安全；
System Survivability（系统生存性）：聚焦于增强系统自身的韧性；
Sustainment（可持续性）：确保系统能够在适当层级实现修复与维护；
Energy（能源）：认识到现代战争以燃料为基础，需计及其使用与供应；
Net-Ready Performance（网络就绪性能）：在多军种联合战场中，没有系统是孤立运行的，互操作性在设计与建造阶段即为关键。

2.3. 基于模型的系统工程文献综述（Model Based Systems Engineering Literature Review）¶

MBSE 文献综述章节讨论了系统工程（Systems Engineering）向 MBSE 演进的过程，这是工程环境与工具数字化整体努力的一部分。内容包括针对示例任务的简化 SysML 语言概述，随后介绍七种与任务工程相关的主流 MBSE 方法论，并将其提炼为一种可在示例任务章节中综合应用的统一方法。本节包含了用于回答前文任务目标的“如何”部分。

2.3.1. 系统工程概述（Summary of Systems Engineering）¶

上一章讨论了当前用于高层需求生成的既有流程、其形成原因及当前推荐的起点。然而，现有流程在将四个顶层 KPP 与网络就绪（Net Ready）要求转化为可设计的系统需求方面显得不足。需求分解过程是系统工程的核心，而系统工程师正是任务需求分解结果的最终接收者，因此采用相同的流程是合理的。为支持这一实践延伸，必须首先描述与探讨系统工程这一学科，并重点强调其近期向数字工程（Digital Engineering）趋势的转变。数字工程包括基于模型的系统工程（MBSE）及其关联的系统建模语言（SysML）。
一旦定义了足够支撑当前方法分析的基础概念与语言，即可从现有 MBSE 方法中提取与任务工程相关的可行途径，作为下一章任务工程方法论综合的构建模块。

根据应用情境不同，系统工程有多种工作定义。要构建系统工程的基础，需要从两个广义视角进行分析：工业界与政府部门。政府部门又细分为 NASA 与美国国防部（DoD），因为它们的视角不同。

从工业界视角出发，国际系统工程理事会（INCOSE）将系统工程定义为：

“系统工程是一种跨学科与综合方法，运用系统原理、概念以及科学、技术与管理方法，实现工程系统的成功实现、使用与退役。” [48]

NASA 的定义为：

“系统工程是一门艺术与科学，其目标是在相互制约的条件下开发出可操作的系统，以满足需求。” [49]
系统工程必须考虑系统功能之间及系统与其环境之间的连接或相互作用。在许多情况下，这包括物理、社会与逻辑上的相互关系与环境。” [50]

最后，美国国防部（DoD）定义为：

“系统工程是一种跨学科的工程管理过程，旨在演化并验证一组综合的、生命周期平衡的系统解决方案，以满足客户需求。” [51]

三者之间的共同主题在于：聚焦系统整个生命周期内的多领域与接口。这使系统工程师必须面对极为广泛的考量范围。对于逻辑系统与物理系统而言，这些考量集中于：

记录、追踪与满足需求；
阐明满足需求所需的性能与行为特性；
定义与管理交互 / 接口；
物理接口；
语言 / 协议；
确保组件间的连续性；
明确支撑这些接口的结构。

这一过程贯穿系统生命周期，通常通过被称为“系统工程 Vee 模型”（Systems Engineering Vee）的图示方式呈现。

图 19 线性系统工程流程图（SE Vee）[52]

这种带有反馈的线性流程长期以来一直被美国国防部采办体系广泛采用，因此图中多数要点均用于支撑该流程。然而，随着 MBSE 等方法的发展，该模型的实用性与可行性开始受到质疑 [53], [54]，且在《国防系统工程指南》（Engineering of Defense Systems Guidebook）2022 年 2 月修订版 [10] 中已未出现。这表明设计思维已从线性流程向更具迭代性的模式转变。该问题将在介绍 MBSE 后进一步讨论，因为 MBSE 可能为应对系统工程广度管理提供更优的解决方案。

图 20 迭代系统工程流程 [55]

从线性设计流程向迭代设计流程的转变并非全新概念，最早在 2001 年的《系统工程基础》（Fundamentals of Systems Engineering）[56] 中被提出，并在后续文件中得以实施，如图 20 所示。虽然迭代过程更加复杂且难以管理，但它更贴近复杂系统开发的真实特性，因为没有任何过程是真正线性的，而且它能更早地向相关方提供反馈 [57]。上述两种系统工程模型都明确区分了任务工程在其中的位置与角色——它属于需求分析阶段。图 20 中对需求循环的额外细化在下一章的讨论中尤为值得保留。

无论采用线性的 Vee 模型、迭代循环模型，还是其他系统工程过程的描述形式，其广义上的“宽而浅”（mile wide, inch deep）特征都应让人联想到上一章讨论的兵棋推演起源。两者都具有高层次目标，必须信任子单元（无论是否为人）能够正确运行，并关注它们之间的互操作性，即使这些子单元代表着不同的能力与接口。这种联系在其他学位论文 [58]-[60] 和部分美国国防部官方出版物 [10], [21] 中已被提及。然而，虽然已有先例，但尚未建立令人满意的技术关联。主要结论是：其中一个领域的演进可能适用于另一个领域，而系统工程的发展方向之一正是基于模型的系统工程（MBSE）的出现。

2.3.2. 基于模型的系统工程（MBSE）历史¶

MBSE 是系统工程的较新演进形式，而系统工程本身仅在 20 世纪 50 年代系统复杂度提升后才真正发展起来 [61]。Estefan（2007）追踪了系统工程从军标 Mil-Std 499 的正式文档化到 2002 年的演变过程，期间系统工程从时间驱动（timeline-driven）向更健壮的事件驱动（event-driven）计划转变 [62]。自 2002 年以来，MBSE 的应用持续增长，但在美国国防部（DoD）内部尚未被正式规范化，而是作为支持更大目标的强烈“建议”存在 [10], [63], [64]。

在美国国防部之外，MBSE 已经历了大量发展。MBSE 包含三大支柱 [65]：

建模语言（Modeling language）
建模方法（Modeling Method）
建模工具（Modeling tool）

2.3.2.1. 建模语言（Modeling Language）¶

SysML 是一种基于统一建模语言（UML）的图形化建模语言，已成为 MBSE 领域的主流工具，并被广泛应用于美国国防部。本研究选择使用该语言正是因为其在 DoD 内的普及性。SysML 从 UML 演化而来，其发展时间线如下：

2001 年 1 月 —— INCOSE 模型驱动系统设计工作组（Model Driven Systems Design WG）开始为系统工程应用定制 UML [66]；
2001 年 7 月 —— INCOSE 与对象管理组织（OMG）共同成立系统工程领域特别兴趣小组（SE DSIG）[66]；
2003 年 —— Sanford Friedenthal 与 Cris Kobryn 组织并共同主持 SysML Partners 以开发 SysML [66]；
2007 年 9 月 —— OMG 发布 SysML v1.0 规范 [66]；
2017 年 —— SysML 被国际标准化组织（ISO）正式发布为国际标准 [66]；
2017 年 12 月 8 日 —— SysML v2.0 的开发工作开始 [66]；
2019 年 12 月 —— OMG 发布 SysML v1.6 [67]。

由于 SysML 是 UML 的扩展（见图 21），系统工程因此可以借鉴更早期软件开发中的经验教训。

图 21 UML-SysML 关系示意 [68]

尽管 SysML 与 MBSE 的起源、MBSE 与传统文档中心系统工程的关系、MBSE 优于传统系统工程的理由及其标准演化对于理解 SysML 的完整发展历史十分重要，但这些内容已有充分的文献记载。此处仅简要列出若干相关工作的概要，供希望深入了解的读者参考：

《系统工程设计方法的系统文献综述》（Systematic Literature Review of System Engineering Design Methods）：高层次回顾系统工程设计方法及过程文档化的发展至其在 MBSE 中的实现 [69]。
INCOSE《系统之系统工程新标准》（INCOSE New Standards for System of Systems Engineering, SoS）：简要概述多项已被工业界采用的 ISO/IEEE 系统生命周期与系统之系统标准 [70]。
ISO/IEC/IEEE 15288
ISO/IEC/IEEE 21839
ISO/IEC/IEEE 21840
ISO/IEC/IEEE 21841

其中，本研究最相关的是 21840 与 21841。

《十三年的 SysML：系统映射研究》（Thirteen years of SysML: a systematic mapping study, Wolny et al.）[71]：涵盖 2005–2017 年间的出版物，基于四个主要研究问题分析了文献的作者与地域分布。该论文有助于定量理解 SysML 研究发表状况、观察趋势并寻找额外文献。其相关性在于指出主要出版类型偏重验证研究而非方案提出型研究（如本论文），这一点支持了在文献综述开头提出的观点——与本问题集直接相关的学术论文稀缺，因此需更多依赖工业与政府出版物。

2.3.2.2. MBSE 语言分类（MBSE Language Taxonomy）¶

尽管了解 SysML 的起源有助于理解其结构与设计选择，但这些内容已有充分文档记录，进一步重复意义不大。此处需要的是对该语言的简要概述，为后续章节的应用奠定基础。

2.3.2.2.1. SysML 图表（SysML Diagrams）¶

SysML 由元素（模块、接口、关系等模型构成部分）与视图（即图表，使模型对人类可读）组成。由于图表是理解模型的最佳方式，因此是逻辑上的首要讨论对象。SysML 包含九种图表类型，如下所示：

图 22 SysML 图表与起源 [67]

大多数图表继承自 UML，但也有一些新增图表。图表是查看模型的方式，但本身并不是模型。

各图表在 SysML 中具有不同的用途（斜体为 SysML 专有术语）：

包图（package diagram, pkg）：用于以包的包含层级展示模型的组织方式。包图还可显示包所包含的模型元素以及它们之间的依赖关系 [65]。它是展示整个模型或子模型包含关系的最佳方式，类似于计算机文件目录结构图。
需求图（requirements diagram, req）：用于显示基于文本的需求、需求间的关系（包含、派生、复制）以及需求与满足、验证或细化它们的其他模型元素之间的关系 [65]。需求图是需求表的图形化替代形式，是任务分析初始与最终阶段的主要视图。
活动图（activity diagram, act）：用于指定行为，关注控制流与输入输出的转换。常用于分析与表达系统的期望行为 [65]，适合用于线性分析或功能流。其子类型 opaque action 支持嵌入文本代码以执行复杂逻辑。
模块定义图（block definition diagram, bdd）：显示模块、值类型及其关系 [65]。是宏观结构与组成的主要视图。
内部模块图（internal block diagram, ibd）：用于指定单个模块的内部结构，展示内部部分、接口及流动的信息 [65]。是系统微观结构与互操作细节的主要视图。
参数图（parametric diagram, par）：用于表达系统属性间的约束（方程或不等式），支持性能、可靠性、可用性、功率、质量与成本等工程分析 [65]。
序列图（sequence diagram, seq）：用于指定行为，关注模块间通过操作调用与异步信号的交互，常用于详细设计与测试用例定义 [65]。
状态机图（state machine diagram, stm）：关注模块的状态集合及状态间因事件发生而转变的关系，常用于生命周期开发阶段的行为定义 [65]。
用例图（use case diagram, ucd）：用于传达系统的利益相关者、执行的作战构想（CONOPS）及其参与者，是系统与参与者协作的黑箱视图 [65]。

状态机图与用例图通常出现在系统或任务上下文的最高层，用于分别提供行为与结构的总体视角。由于任务工程关注系统的高层应用，因此图表使用的分布，尤其在状态机图方面，将受到影响，这一差异将在下一章进一步讨论。

这些图表之间存在多路径关联：

图 23 图表间关系 [72]

图 23 展示了跨图表元素之间的关系。需求由活动图（act）中的行为所满足，该行为被分配给系统执行，或由模块定义图（bdd）中的值属性所满足。系统包含部件（组件 1、2）与描述性值（属性 1），代表被建模对象。系统具有接口以管理其内部结构（系统 1 的内部模块图视角）及与其他组件的关系（组件 1、2 的内部模块图视角）。这些关系支持基于多个模块信息的分析（参数图 par），并存储于被引用的最高层模块（如系统 1）中。当理解 SysML 语法后，上述这一段内容可在同等篇幅的 SysML 模型中以更精确的方式传达给另一位系统工程师，并附带更多细节信息。

2.3.2.2.2. SysML 元素（SysML Elements）¶

要完全理解这些图表，另一个关键方面是元素与关系。根据 SysML 1.6 规范，为理解下一节中的方法论，需要定义九种主要元素，并在出现时介绍各自的子类型（完整列表参见规范文档第 8.2 节）。

Block（模块）
图表：bdd

正式定义：
“模块定义了一组特征，用于描述一个系统或其他感兴趣的元素。这些特征可包括结构性和行为性特征，如属性与操作，以表示系统的状态及其可能表现的行为。” [67]

任务工程示例：
模块通常代表系统或组件，如同常规系统工程。然而在任务工程中，它也可表示由多个系统组成的任务集合，这些系统可能具有独特的结构 / 接口和一组特定任务相关参数。因此，一个模块可以表示飞机、雷达、天线或打击任务（无论是具体实例还是使用功能 / 逻辑超类型的通用表示）。

常见子类型：
<<domain>>, <<context>>, <<subsystem>>, <<activity>>

Ports（端口）、Flows（流）、Interfaces（接口）
图表：ibd, bdd

正式定义：

端口（Ports）：
“端口是外部实体可以连接到模块并与之交互的点，其方式不同或较直接连接模块本身更受限。它们是具有类型的属性，该类型定义了外部实体可通过端口连接器访问的特征。” [67]
端口可以嵌套，用于更复杂的接口。
项流 / 流（Item Flow / Flow）：
“项流定义了在模块与 / 或其部件之间、以及跨关联或连接器时流动的事物。流属性定义了可流入或流出的内容，而项流则定义了在特定使用上下文中实际在模块间流动的内容。” [67]
接口（Interface）：
“定义了一组操作与接收动作，是客户端与提供方必须遵循的行为契约。” [65]

任务工程示例：
端口通过接口类型化实现接口。例如，在该接口中可能包括：

表示物理连接的接口模块（如 RJ45 接口）；
指定物理连接类型 / 导线类型的关联模块（如 CAT5）；
指定可跨该接口传输的数据流类型的流属性（如 TCP/IP）。

接口管理通常是模型中最注重细节的部分之一。

常见子类型：
<<Full>>, <<Proxy>>, 原子型（Atomic）与非原子型（Non-atomic）

图 24 一组端口（上）与项流（下）的示意图 [62]

Constraint Block（约束模块）
图表：bdd, ibd, par

正式定义：
“约束模块可用于指定约束网络，这些约束网络表示数学表达式，如 $\{F = m * a\}$ 和 $\{a = dv/dt\}$，用于限定系统的物理属性。此类约束还可用于识别关键性能参数及其与其他参数的关系，这些关系可在系统生命周期内持续追踪。” [67]

图 25 约束模块的示意图 [62]

任务工程示例：
如下一节所述，大多数实际计算最好在 Cameo 外部执行，因为 SysML 及其工具中的仿真方法尚不成熟。Cameo 的优势在于结构或行为建模，约束模块通常仅用于轻量计算或可视化辅助。例如，“仿真”一词在 SysML 规范中未被提及。然而，约束模块（及其行为类比 Opaque Actions 子类型）在与外部仿真交互时起重要作用。约束（及 Opaque Actions）可以用多种语言编写，但由于无法引入额外库文件，限制了其作为该语言编译器更完整接口的实用性。

常见子类型：
<<moe>>, <<objectiveFunction>>

Activity / Actions（活动与动作）
图表：act

正式定义：

Action（动作）：
“动作表示系统运行期间，当活动被执行时将发生的某种处理或转换形式。” [65]
Send Signal（发送信号）：
“发送信号动作是一种特化动作，在启用时异步生成并向目标发送信号实例。” [65]
Accept Event（接受事件）：
“接受事件动作是异步行为中发送信号动作的对应方；它表示活动必须等待异步事件发生后才能继续执行。” [65]

图 26 多种动作类型的示意图 [62]

任务工程示例：
多种不同类型的动作可组合形成一个活动（Activity）。活动可通过 call behavior action 被其他活动图调用。活动常用于状态机中某一状态下的线性过程。例如，传统的“杀伤链”（kill chain）过程，如 F2T2EA [73]，从单个数据包的粒子视角（类似流体流动）来看，是一个线性过程，因为链中任一环节的失败都意味着整个交战失败。

常见子类型：
<<opaqueActions>>, <<callBehaviorAction>>, <<acceptEventAction>>, <<sendSignalAction>>

状态机（State Machines）与状态（States）
图表：stm

正式定义：
“状态机以对象的状态与状态间转换的历史来表示其行为。” [67]

任务工程示例：
当系统或任务复杂到需要将活动进行分组，并仅在满足特定条件时执行时，使用状态机。例如，如果将传统的 F2T2EA 过程从流程视角进行观察，则某个状态中的失败（基于包含的行为，通常由活动图表示）会导致流程回退至前一状态或阻止其继续推进。换言之，如果目标已被发现，但定位精度不足以批准武器释放，则从“目标（target）”状态到“交战（engage）”状态的退出转换条件未被满足，状态不会改变。

常见子类型：
<<compositeState>>

分配（Allocations）
图表：bdd, allocationMatrix, tables

正式定义：
“分配是系统工程师用于描述用户模型中各结构或层级内元素有组织的交叉关联（映射）关系的术语。一个典型例子是将活动分配给模块。” [67]

图 27 一般分配关系的示意图 [62]

任务工程示例：
任务工程中的分配用法与常规系统工程相同，用于连接形式与功能。这在多功能系统可根据其他可用资产与地理维度被分配到不同杀伤链环节时尤为有用。例如，一个雷达系统在某次任务中可能同时承担“发现（find）”和“定位（fix）”功能，而在另一任务中则仅执行“发现”部分，具体取决于系统设计外部的多种因素。

常见子类型：
无（N/A）

用例（Use Case）
图表：ucd

正式定义：
“用例也可被视为通过主体与其行为者间交互完成的功能和 / 或能力。用例图包含用例、行为者及其之间的相关通信。” [67]

任务工程示例：
用例图通常用于系统功能尚在确定的早期生命周期阶段。在任务工程中，它对应于作战构想（CONOP），即系统的潜在使用方式。当这些用例与其他系统相互连接时，便形成了具有潜在用途的系统网络。该网络中的一条路径即为需要分析的特定情景或任务——这也是“杀伤链（kill chain）”与“杀伤网（kill web）”的区别 [65]。
一般而言，这些图表用于将非工程化的任务、情景、CONOPS 解释为系统工程模型可接纳的格式，形成更大本体（ontology）的一部分。因此，用例图主要位于模型的顶层。

操作（Operations）
图表：act, stm, bdd

正式定义：
“操作表示模块在客户调用时执行的行为。通常，操作表示同步行为。” [65]
操作包含负责执行被调用方法的其他行为。

任务工程示例：
虽然操作通常表示同步行为，但可以切换为异步行为，用以替代基本动作。这在系统与功能紧密耦合的权衡空间中具有显著优势——即所有权（ownership）。动作（Action）隶属于其所在的活动（Activity），无法在其他活动图中引用，除非复制或转移所有权。而操作（Operation）隶属于模块，因此可出现在多个活动图中，同时仍由负责执行的系统拥有。一个系统可以同时或分别为多个任务提供相同功能，而这种所有权的保持值得因使用操作方式带来的少量开销（主要是记得关闭异步行为）。

常见子类型：
无（N/A）

需求（Requirements）
图表：req, bdd, table

正式定义：
“需求可以指定系统必须执行的功能或系统必须达到的性能条件。SysML 提供建模结构，用于表示基于文本的需求，并将其与其他建模元素关联。” [67]

任务工程示例：
与分配类似，任务层级的需求基本保持不变。通过如 JCIDS 等流程自上而下生成的系统需求本就会流经任务层需求，只是其设计与分析层级不同于系统底层需求。例如，一个任务需求可能是确保通信链路可靠性，给定特定位置、气象条件和设备配置范围。不同类型的需求有助于区分满足需求的不同途径（如功能性需求对应行为，性能需求对应值属性，接口需求对应端口）。

常见子类型：
<<FunctionalRequirements>>, <<PerformanceRequirements>>, <<interfaceRequirement>>
更多类型及约束参见 SysML 1.6 规范附录 E-3 表。

图 28 含多种需求类型的需求图示意图 [62]

遵循 SysML 的图示化特征，这些元素之间的综合关系更适合以地图而非文本形式展示。图 29 以与语言无关的方式映射了此处讨论的元素及其他部分元素。
图中的关键结论是：没有显而易见的“起点”。一般情况下，流程从需求开始，逐步分解至系统层（从政策到任务层）。此图具有重要意义，因为它概括了上述元素的总体联系，而具体图表仅展示了整体关系的局部片段。

图 29 模型元素间关系映射图 [74]

除该图外，下表（表 7）提供了一个快速参考表，将上述定义与其对应的元素类型进行关联。

本节前面列出的元素代表系统的定义元素。然而，在 SysML 中，“定义”（definition）与“定义的使用”（usage of definition）之间存在关键区别。因此，还有一些此前未明确说明的使用元素。表 7 中的信息对这些附加元素进行了简要概述。

表 7 定义元素与使用元素的映射关系 [75]

定义元素（Elements of definition）		使用元素（Elements of usage）
Actor	types	Reference Property 或 Lifeline
Block	types	Part Property、Reference Property、Lifeline、Atomic Flow Port、Flow Property、Object Node 或 Constraint Parameter
Value Type	types	Value Property、Constraint Parameter、Atomic Flow Port、Flow Property 或 Object Node
Constraint Block	types	Constraint Property
Flow Specification	types	Nonatomic Flow Port
Signal	types	Atomic Flow Port、Flow Property 或 Object Node
Interface	types	Standard Port
Association	types	Connector
Activity	types	Call Behavior Action
Interaction	types	Call Behavior Action
State Machine	types	Call Behavior Action

使用元素（Elements of usage）
Part Property	typed by	Block
Reference Property	typed by	Block 或 Actor
Value Property	typed by	Value Type
Constraint Property	typed by	Constraint Block
Constraint Parameter	typed by	Value Type、Block
Nonatomic Flow Port	typed by	Flow Specification
Atomic Flow Port	typed by	Block、Value Type 或 Signal
Standard Port	typed by	Interface
Flow Property	typed by	Block、Value Type 或 Signal
Connector	typed by	Association
Call Behavior Action	typed by	Activity、Interaction 或 State Machine
Object Node（包括 Pin 与 Activity Parameter）	typed by	Block、Value Type 或 Signal
Lifeline	typed by	Block 或 Actor

2.3.2.3. 通用术语（General Terms）¶

在 MBSE 中存在许多借自其他领域并在此应用的通用术语与概念，而这些术语在系统工程语境中通常未被明确定义。因此，在讨论具体方法论之前，需要先说明以下概念：

黑箱（Black box）与白箱（White box）
设计工程（Design engineering）与逆向工程（Reverse engineering）
逻辑—功能—物理架构（Logical-Functional-Physical architectures）

2.3.2.3.1. 黑箱（Black box）与白箱（White box）¶

黑箱视图是系统的一种外部视角，其中定义了要执行的功能 / 操作（但不说明“如何”执行）、关键属性以及外部接口 [76]。白箱则展示更多信息，包括系统的内部特性，如组成部件或行为实现方法。这些部件本身也可以是黑箱或白箱。

自顶向下建模时的一般方法是先建立黑箱模型，然后逐步增加定义，此时黑箱演化为由多个黑箱组成的白箱。该过程循环重复。最终模型将由若干白箱组成，仅有两个主要例外：
（1）所需保真度的最低层级；
（2）任务中的平台层级。

模型的最低层级根据定义不再包含部件或内部规范（否则这些部件本身就会成为最低层元素）。最低层模型必须根据用户需求进行调整，因为保真度与计算性能之间存在权衡。通常会建立一个尽可能详细的中心模型，从中分支出较浅层模型（在性能优先时使用）。

任务中平台层被视为黑箱的主要原因在于：对每个任务客户而言，高层次的黑箱任务视图本身就是期望输出（相当于 OV-1 视图）。另一个原因是，最低保真度的具体定义是根据客户需求临时确定的。

2.3.2.3.2. 设计工程（Design Engineering）与逆向工程（Reverse Engineering）¶

工程大体分为两类：设计工程与逆向工程。前者涉及构建新的系统（部分或整体），后者则是在现有系统上建模，以更好地理解其功能。

设计工程可进一步细分为两种类型：“从零开始”（clean slate）与“中向外”（middle-out）。
“从零开始”表示创建全新系统、解决新问题、且不与其他系统交互——这种情形在系统工程中已极为罕见，而在任务工程中几乎不存在 [77]。因此，本研究主要关注“中向外”工程，这通常也是“设计工程”所指的类型。JCIDS 流程即旨在支持设计工程，其自上而下的需求生成与实现流程即为典型代表。

逆向工程则是对现有系统进行建模，以记录、数字化并理解其当前形态，并不意味着对外来系统的剖析或利用。在当前阶段，鉴于库存中存在大量遗留系统，逆向工程构成了任务层建模的主要部分。同时，MBSE 目前的统一程度（或缺乏统一）导致许多基于任一工程类型构建的模型间并不兼容。一个系统层级有效采用 MBSE 的标志是：任务层级从逆向工程逐步转向设计工程。

然而，这两种工程类型的方法与工具大体相似。本文后文提出的方法论可适用于两者。

2.3.2.3.3. 逻辑—功能—物理架构（Logical-Functional-Physical Architectures）¶

任何设计模型均包含三个层次：逻辑层、功能层与物理层 [76]。在设计过程中，依据 JCIDS 等流程，首先要明确一组期望能力，然后将其分解为功能性需求（包括结构与行为两方面）。

例如，某功能架构需求集可能是：在 3 小时内从点 $A$ 运送 200 磅货物到点 $B$。
在确定这些需求后，可建立逻辑选项，如：汽车、卡车、轮船、直升机或固定翼飞机。这些是车辆类别（class），并非可直接实现的解决方案，仅定义到足以支持当前分析的程度——细节不受约束，但仍受常识约束。

一旦确定最优运输类别（例如卡车），便可进入物理架构阶段。这是详细的系统工程问题，将产生符合规格的可制造系统。

作为对下一章的提前说明，以下展示了该层级结构在任务工程中的应用示例：

任务提供了派生功能架构的背景；
确定关注系统（system of interest），通常在初期仅存在一个逻辑系统，因为几乎不可能同时设计整个作战序列中的所有系统。大多数大型机构（包括军方）已有现成系统，新系统仅为增量改进；
识别任务中的其余系统，并构建或收集物理模型以作为上下文系统；
在其他物理模型背景下优化逻辑系统；
将最优逻辑系统的规格传递给设计组织（通常为承包商）；
设计组织开发并生产产品，理想情况下首先交付物理模型；
物理架构模型作为逻辑系统的子类型传入任务分析流程，以确保设计持续满足需求并提供洞见机会；
设计组织交付产品，产品转入正式项目阶段，成为下一代关注系统的上下文，流程再次循环。

显然，此过程更偏向于设计流程而非逆向流程。由于 MBSE 的采用相较于 DoD 众多遗留系统的年代相对较晚，仍有大量未建立任何 MBSE 模型的系统，却在关注系统的语境中至关重要。
在逆向工程情境下的功能—逻辑—物理层级中，可以直接将功能层与物理层关联，因为无需进行类别层优化（系统已存在）。
值得注意的是，随着已建模型库的扩展，建立逻辑结构有助于配置管理及与仿真引擎输入的对齐。下一节将探讨在仿真中定义逻辑类超类型（logical class supertype）及物理架构黑箱子类型（subtype black boxes）的概念与实现。

2.3.3. 当前 MBSE 方法论（Current MBSE Methodologies）¶

如前所述，MBSE 实践的采用正在迅速扩散，但尚无统一方法论。由于领域与目标差异，短期内也不太可能出现统一标准。因此，已有若干已发展且与本研究用例高度相关的方法论值得探讨。本节将分析这些方法论及其与任务工程最相关的特性，并在下一章整合关键要点形成统一方法。
这并非对各方法论的全面综述，而是基于经验与文献筛选的与任务工程相关特征摘要 [49], [65], [78]-[81]。

七种被识别的方法论包括：

INCOSE 面向对象系统工程方法（OOSEM）
IBM Rational Telelogic Harmony-SE / IBM Rational Unified Process for Systems Engineering（RUP-SE）
CORE Vitech MBSE 方法论
NASA JPL 状态分析（State Analysis, SA）
系统之系统接口建模（System of Systems Interface Modeling）
超建模（Hypermodeling）与 SAIC 验证配置文件（Validation Profile）
Weilkiens 系统建模过程（SysMOD）

在讨论这些方法论细节之前，有必要简要回顾适用于方法论的关键性能参数（KPP）：

KPP 1：以可仿真的方式捕获并分析可追溯需求。
KPP 2：根据仿真框架需要，定义系统结构（逻辑与物理组件及接口）与行为（操作、状态与转换）。
KPP 3：通过将仿真框架与模型相连接，促进仿真与分析，使模型成为系统真值的权威来源，以支持备选方案分析。
KPP 4：在可用的 SysML 环境（如美国海军部企业级 Cameo Systems Modeler）中，在系统与系统之系统层级执行 1–3 项工作 [82]。

关于模型验证与确认（V&V）的问题始终存在。V&V 是任务工程的内在组成部分，同时也是重大挑战，其前提是必须先有方法论可供验证与确认。因此，V&V 属于未来可能的研究方向，此处仅作概念性考虑。

应强调的是，对这些方法论的更广泛综述已在其他文献中完成，本分析仅限于与任务工程应用场景最相关的部分，全面回顾将显得冗余。

1. INCOSE 面向对象系统工程方法（OOSEM）¶

OOSEM 采用自顶向下的改进型 Vee 模型，强调对象复用，并遵循上述四项 KPP 及模型 V&V。该方法着重逻辑结构，作为满足需求的首层实现手段 [81]。

虽然 OOSEM 与其他方法论（如 Harmony 或 RUP-SE [72]）存在相似之处，但更强调结构性。OOSEM 是面向对象编程原则在系统工程模型中的实现，利用封装、规范与元素复用等机制。鉴于 SysML 源自 UML（如前所述），而 SysML 本质上是面向对象的语言，这一点尤为契合。
对于 MBSE，OOSEM 的优势在于结构复用；而对任务工程而言，其优势加倍明显，因为许多任务级仿真软件（如美国空军研究实验室 AFRL 的 AFSIM [83]）本身即为面向对象架构。

OOSEM 是所讨论方法中最具影响力的之一，推荐进一步阅读：《A Practical Guide to SysML》第 17 章 [72]、INCOSE《系统工程手册》第 9.4 节 [13] 及其他相关论文 [76], [84]-[87]。

OOSEM 的核心启示包括：

自顶向下的流程与方法；
在面向对象结构建模中实施封装、继承与复用的实践。

OOSEM 自顶向下方法¶

OOSEM 遵循图 31（上）所示流程，从任务及其关键性能参数（KPPs）出发，自左至右阅读：先沿对角线以上，再在灰色区域内完成。图 31（下）展示了相同过程的行动流向。

图 31 OOSEM 流程步骤（上）[13] 及 OOSEM 流程图（下）[76]

整合图 31 后的步骤如下：

以任务与前章列出的任务 KPP 为起点；
分析利益相关方需求，并将这些 KPP 细化为更具体的需求；
将这些需求转化为系统需求；
定义逻辑架构（系统、场景与行为）；
在场景中分析逻辑架构系统；
综合 1 至 $\mathrm{N}\left(1 \ldots{ }^{*}\right)$ 个物理架构子类型至逻辑架构；
分析物理架构子类型，优化出最佳解决方案；
确保优化后的物理架构子类型可追溯至原始需求，并记录追溯关系；
通过测试验证系统设计。

此方法适用于任务行为分析，但其对“继承（inheritance）”的强调不太适用于行为建模，因为行为子类型难以明确表示。行为分析更适合采用以功能分解为中心的方法，如 IBM 的 Harmony。

继承与复用（Inheritance and Reuse）¶

继承使用前文 SysML 元素部分介绍的“泛化（Generalization）”关系。图 32 展示了三层继承示例，所有层均为逻辑黑箱元素。（这些模块为逻辑元素，因为其底层未对继承值进行指定；未显示数值或重定义，因而无法直接用于分析。这与继承并不冲突，且当关注系统为星敏感器（star sensor）时，此逻辑层划分反而有助于分析星跟踪器与星图器层级关系。）

图 32 泛化继承示例 [65]

这种结构的优势主要有两点：

一致性与可追溯性 —— 相同类型元素具有统一定义（例如，所有从“星跟踪器（star tracker）”模块派生的子模块都具有相同定义特征），从而能构建组件的可追溯“遗传树”；
接口管理便利 —— 只需在单一定义点维护外部仿真软件接口一致性，例如 AFSIM 中“传感器”的定义只需与模型中的传感器模块一致，而不需分散在多个元素中。这既支持配置管理，又通过模块化降低了数据被未授权修改的风险。

虽然“泛化（Generalization）”最为常见，但还有其他继承类型。图 33 展示了两种额外方式：实例化（Instantiation）与扩展（Extension）。

实例化表示从模板模块创建实例，无法修改行为或接口。由于缺乏灵活性，通常仅在仅需评估系统属性时使用（例如，在给定任务路径上研究飞机速度变化对总体生存率的影响）。此外，Cameo 的仿真工具包在执行前会将所有元素转换为实例，因此若实验设计（DoE）中可追溯性最为重要，直接使用实例可节省步骤。

图 33 替代继承方法 [88]

尽管每种继承方式都有其用途，但此处采用泛化方法，因为相较于实例化与扩展，它在规范层面更具灵活性。实例化不适用的原因是子级需具备不同接口能力，而父级未指定端口。扩展方法的限制在于其“构型限定于属性（properties）”，适用于深层模型，但此处应用的功能角色较“宽”而非“深”，因此避免了多层泛化的复杂性。
然而，为支持后文将讨论的超建模（Hypermodeling）与 SAIC 配置文件中的元导航（metanavigation），将保留扩展机制的使用。

2. Rational 统一过程（RUP）与 IBM Rational Telelogic Harmony¶

Rational 统一过程（RUP）与 Rational Telelogic Harmony 均由 IBM 公司成员为系统工程开发。两者的显著区别在于工具支持：RUP 依托于 IBM 的 Rhapsody 工具，而 Harmony 是一种与工具无关（tool-agnostic）的方法，因此更适合本研究场景。虽然 Cameo 可以读取 Rhapsody 模型，但这种转换过程容易引入误差，使得严格遵循该方法论与 KPP 4 不兼容。综合 IBM 各方法论，可总结出以下关键要点：

功能分解与行为建模的聚焦
多层抽象
需求间关系（intra-requirements relationships）

Harmony¶

IBM Harmony 是一种与工具无关的方法论，采用服务请求（service-request）建模思路 [81]。
该方法强调可执行模型（executable model），这也是实现 KPP 3 所指出的仿真能力的关键属性。它采用带有迭代特性的传统 SE “V” 模型版本，如图 34 所示：

图 34 IBM Harmony 系统/嵌入式设计流程 [89]

Harmony 的核心在于行为建模（behavioral modeling），主要使用活动图（activity diagram）与序列图（sequence diagram），并通过功能分解（functional decomposition）建立行为与需求之间的关系。不同方法论对图表类型重视程度不同，而 Harmony 对 bdd（模块定义图） 的使用极少，而是直接将行为与 ibd（内部模块图） 的细节视图相连接 [89]。
Harmony 的流程以物理结构定义为终点，主要步骤如下：

识别 / 推导系统所需功能；
识别相关系统状态与模式；
将系统功能 / 模式分配给物理架构。

这种以行为为结构与需求之间接口的方式非常契合任务工程（Mission Engineering）的行为驱动特性，将成为下一章整体流程的核心部分。
在后续建模中，这一思路将与 OOSEM 的逻辑系统层结合，用于构建关注系统（System of Interest, SoI），其完整概念将在下一章详细介绍。

RUP SE¶

RUP SE 强调业务建模（business modeling），采用带有部分面向对象特征的螺旋模型（spiral model） [81]。然而，在任务工程所处的项目阶段，螺旋模型强调风险降低，这会削弱备选方案分析的灵活性与实验性，反而通过增加工作量引入额外风险。

在设计实践层面，RUP SE 聚焦于用例流设计（use case flow design）活动，这对软件（RUP SE 的原始设计对象）非常有效，但对逻辑—物理硬件系统的适配不足。然而，RUP SE 不仅是方法论，也是一种流程体系，其中仍有若干要点对仿真与任务工程的需求具有参考意义：

抽象（Abstraction）
需求关系（Requirements Relationships，分配 vs 派生）

抽象（Abstraction）¶

表 8 RUP SE 架构模型层级及用途 [79]

模型层级（Model Levels）	表达内容（Expresses）	示例（Examples）
Context	系统黑箱视图——系统及其参与者构成系统的黑箱视图；同时它是包含该系统的企业的白箱视图。	角色定义、活动建模	用例图规范
Analysis	系统白箱视图——在每个视角中进行系统初步划分，建立概念性方案。	系统划分	产品逻辑分解
Design	在硬件、软件与人员中实现分析层	操作员说明书	软件组件设计
Implementation	将设计模型落实为具体配置	硬件与软件配置

表 8 概述了 RUP SE 的四层抽象结构。其范围覆盖从任务（Context）到实现（Implementation）的完整过程，其中“上下文层（Context）”与“分析层（Analysis）”对任务工程最为相关。“设计层（Design）”也同样重要，其输入来自于图 20 中定义的“系统配置 / 架构”输出。

需求关系（Requirements Relationships）¶

SysML 提供了多种关系机制，允许以不同语义方式编码关系含义。一个主要的不确定性来源在于：
当多个系统协同完成更大功能需求时，或者当一个系统之系统（System of Systems）被视为单一多功能平台独立满足需求时，如何建模其关系。
这一差异取决于视角问题，将在后文讨论。然而，一旦系统视角被确立，RUP SE 对“功能需求的单独 vs 共享所有权”提供了有益划分：

“如果某个局部或子系统被指定独立承担系统需求的实现责任，则该局部或子系统需求为分配需求（allocated requirement）。
若通过分析该局部或子系统与其他部分如何协同以满足系统需求而确定，则该需求为派生需求（derived requirement）。” [79]

需要注意的是，此关系仅适用于需求之间，因为派生关系（derived relationship）的两端必须均为需求实体 [65], [72]。

3. Vitech CORE 方法论¶

Vitech 公司多年来一直参与 SysML 规范制定。其方法论虽名义上与工具无关，但仍偏向自家 CORE 工具集 [67], [79]。
该方法论由并行、迭代的设计循环组成，通过逐层建模实现预设细节层次——常被比喻为“剥洋葱（peeling back the onion）” [78], [79], [81], [90], [91]。

该方法论的描述较为通用，可应用于任务工程。它提供多个值得借鉴的流程要点，而非特定语法特征。其高层流程包括：

整体构造框架（将仿真从结构化 SysML 模型中独立出来）
四步流程（4-Step Process）
“洋葱模型”与并行过程（Onion Model & Concurrent Processes）

整体构造框架（Overall Constructive Framework）¶

图 35 系统工程整体构造框架 [92]

图 35 所示框架强调：系统模型并非设计的唯一支柱。
将仿真从 SysML 模型中分离独立建模并非 CORE 独有，其他方法论亦有类似设计。
但这些框架多聚焦于系统层建模，其中仿真对应于 CAD 层级抽象 [93], [94]。
对于任务工程，这一原则同样适用，只需作如下调整：

图 36 调整为任务层的系统构造框架（改编自 [92]）

该改编符合此前论述的核心逻辑——任务工程是系统工程的延伸。
此图将在示例任务开篇再次引用，用以展示信息流的宏观路径。
其要点包括：仿真位于模型之外；报告与视图需能在模型外部被非技术受众理解。
关于模型输出的可理解性与需遵循的标准，将在下一节（UPDM、UAF、DoDAF 图式标准）中进一步探讨。

Vitech CORE 四步流程（4-Step Process）¶

CORE 在构建设计模型时遵循四步法 [77]：

需求分析（Requirements Analysis）
功能行为分析（Functional Behavior Analysis）
架构综合（Architectural Synthesis）
验证与确认（Validation and Verification，超出本文范围，但为完整性列出）

这四步按顺序执行，并在每步后迭代回溯前一步，以确保一致性，如图 37 所示：

图 37 Vitech CORE 四步流程 [77]

该流程与其他方法（如前述 IBM Harmony）相似，但 CORE 的表述更为简明。
与 Harmony 强调活动图—ibd 直接关联不同，CORE 更注重功能分解的系统化实现，即在体系结构之前进行行为分析（针对系统的每一层进行迭代分解）。
这正是许多系统工程方法所缺乏的环节。
值得注意的是，INCOSE 的系统设计 / 综合是通过系统需求导出的，而非通过行为分析。
结论是：两者应并行推进——需求应源自行为，而不仅仅是系统参数（如重量）。单独采用任一方法都不足以捕捉任务行为或系统复杂性，因此本文采用两者并行的策略。
下一章将进一步说明这种并行方法的应用。

图 38 展示了 CORE 模型四步对应的建模领域（domains），并明确了领域间的过渡关系。在实际操作中，四个领域可共存于同一模型中，包括用于记录 V&V 策略的验证领域。
需求、行为与架构三者间的关系尤为值得明确，如图所示。

图 38 Vitech CORE 四个领域 [95]

洋葱模型（Onion Model）¶

与上述四步类似，“洋葱模型”实质上是迭代分解（iterative decomposition）的形象化称谓。
在 JCIDS 的自顶向下流程基础上，此模型在各层级依次解决行为与结构需求，再进入下一层，递归提高模型保真度。

图 39 Vitech C4ISR 模型分解过程（左）[96] 与递归层过程（右）[79]

图 39 展示了该过程的宏观与微观视角：
从初始构想到最终设计方案的每一步，都通过右图的递归机制提升左侧目标的精度。
逐层推进的意义在于：在错误传播前即可发现并修正 [91]。

该过程可在一次迭代中并行执行，当范围较小时，可同时考虑四个领域并在进入下一层前达成解 [91]。
此方式降低了单步处理的复杂度，遵循前述核心理念——“复杂性的祸害（the evil of complexity）”，即便仅在一个设计冲刺中实现 [97]。

4. JPL 状态分析（State Analysis）¶

JPL 状态分析方法旨在描述系统的行为，即低层行为被封装为逐时刻变化的高层状态，并关注状态之间的转换 [79], [81]。
其结果类似于控制系统（control system），传统上将需求映射到行为，类似于 IBM 的方法论（最初用于软件，在任务工程领域则对应人为行为）[78], [79]。
该过程结构如图 40 所示：

图 40 JPL 状态分析结构 [98]

任务工程中使用状态分析的主要部分位于图中较大的彩色框内——被控系统作为系统模型的一部分，将从状态机之外进行讨论。
对任务工程而言，该方法的主要用途包括：

构建任务层与系统顶层状态机的创建流程；
结合泛化超类型（generalized supertypes）使用构型标注（stereotypes），以实现广泛的继承控制与一致性；并为后文在超建模（Hypermodeling）部分提及的元链（metachaining）提供支持。

该状态分析方法中的核心原则将指导任务内以状态机表示的行为建模与分析，以实现任务目标、操作员意图与过程、行为接口之间的关联。
用于生成任务层状态机的原则如下：

区分被控系统（system under control）与控制系统（control system）；
使用构型标注定义所需的类别。

被控系统 vs 控制系统¶

在 JPL 方法论中，明确区分了被控系统（system under control）与控制系统（control system） [99]。
被控系统由估计器（estimator）和硬件适配器（hardware adaptor）组成，二者通过状态变量进行通信。
论文中的示例是：流量传感器（估计器）向控制软件（控制器）提供流量测量值（state variable），控制器再通过发出命令（功能状态变量 functional state variable）控制阀门（硬件适配器）以调节流体流量 [98]。
这一区分在任务工程中同样存在。
例如，在任务指挥控制（C2）系统中，输入传感器（估计器）负责感知目标信息，而控制系统（控制器）则基于感知结果执行作战决策并发出命令（状态变量），控制下游执行单元（硬件适配器）。
换言之：雷达（估计器）提供空中目标轨迹（state variable）给 C2 节点（控制器），C2 节点再向地空导弹阵地（硬件适配器）发出指令以实施拦截。

这种区分在“杀伤链（kill chain）”中定义角色与职责时尤为重要，因为状态变量在此将作为状态转换触发器。

进一步将控制系统单独抽出还有另一个优势：为用户意图输入与反馈报告提供逻辑入口，这在当前任务工程体系中仍相对欠缺 [100]。
随着人机协同（human-machine teaming）的发展，这一方向将愈发重要，因为人类操作员与行动的物理执行之间的距离正在扩大 [101], [102]。
关于有人 / 无人协同、训练辅助以及与任务工程方法论接口的详细研究超出本文范围。

图 41 JPL 信息流结构 [98]

构型标注（Stereotypes）与超类型（Supertypes）在元素类型化中的使用¶

在 SysML 中，属性继承可通过两种方式实现：超类 / 子类（Super/Sub） 与 构型标注（Stereotype）。
前者已在“继承与复用”部分介绍，适用于追溯性与清晰性需求。
但当某一超类型被过度泛化、广泛应用时，该方法会面临限制 [98]。
因此，正如下一章将进一步讨论的那样，本文方法中顶层类别将采用构型标注（stereotype）定义，以便在模型中广泛应用，而其余架构仍使用前述继承规则构建。

构型标注的继承能力不如超类型强，因为其不携带部件（part）或值属性（value properties），仅能继承通用属性。因此，构型标注将主要用于导航与标签标识，而非基于信息的继承。

本文中使用的主要构型标注包括：

<<functionalStateVariables>>
<<measurement>>

这两个标注用于 SysML 中的 <<valueProperty>> 类型，表示其使用方式。
在此任务场景中，估计器（传感器）提供基于观测估计的 <<measurement>> 给控制器；控制器（即 C2 系统）根据该 <<measurement>> 判断并发出 <<functionalStateVariables>> 命令返回给估计器。
该 <<functionalStateVariables>> 影响被控估计器的状态。

JPL 档案中还定义了其他有用的标注（如 <<estimator>>、<<controller>>），但由于本文用例不够复杂，无需偏离标准 SysML 语法。
此方法是未来在为客户定制任务工程用例时的主要参考之一。

这种用法与 Cameo Systems Modeler 中对架构框架（DoDAF、MoDAF、UPDM、UAF）的实现一致，即语言扩展通过构型标注实现。
这同样适用于后文接口建模部分 [103]。
由此可见，方法论的部分实现将取决于客户需求，因为所需元素与视角取决于其采用的架构框架。

5. 系统之系统接口建模方法（System of Systems Interface Modeling Method）¶

接口（interface）是系统工程中的主要失效点之一。
正确且一致的建模是接口有效运作的关键。
在接口设计时需牢记以下要点 [103]：

接口所需组件（Required Interface Components）
接口（如同系统）具有逻辑、概念与物理三个抽象层次。

接口所需组件（Required Interface Components）¶

接口包含以下部分：

交互元素的连接点；
交换的数据项；
管控交换的约束或规则；
交换介质（如链路）。

这意味着接口是多层结构，尤其是通信接口，既包括物理层效应（如大气影响），也包括软件协议行为与限制（如带宽、时延）。
每个接口必须处理三个方面 [103]：

物理端点（Physical ends）
连接流向（Connection flow）
连接介质（Connection material）

接口抽象（Interface Abstraction）¶

逻辑接口在物理层之上支持逻辑信息流。
例如，当雷达向 C2 系统传递“目标航迹（track）”时，物理实现可能是特定频率上的特定报文类型通过空气传输；但在功能行为分解层面，C2 系统仅需接收“航迹”信息，而无需针对每种报文类型设置条件分支。

通过多层抽象机制，可以像 OOSEM 中系统分解或功能分析中的行为分解那样，自顶向下逐层细化接口结构与细节。
这一机制适用于系统及接口的黑箱与白箱实现形式 [103]，并将在后文讨论的 <<pattern>> 模块定义中体现。

6. 超建模与 SAIC 验证配置文件（Hypermodeling and SAIC Profile）¶

超建模（Hypermodeling）关注图表背后的模型结构，旨在利用 SysML 的深层语义特性，减少构建模型所需视图数量，从而降低整体复杂性与建模时间 [104]。
其符合“简化优先”的目标，主要启示包括：

限制需求与其他元素类型间的关系；
以不透明行为（Opaque Behaviors）与项流（Item Flows）为核心构件；
引入元链（Metachain）导航与表 / 矩阵视图；
利用验证配置文件（Validation Profile）强制保持建模一致性（该特性源自 Hypermodeling）[105]；
引入替代模型（Surrogate Models）。

需求6关系约束（Requirement Relationship Rest）¶

如前所述，SysML 中存在大量关系类型，其语义细微差异可能引发复杂化而非简化。
例如，<<allocate>> 与 <<satisfied>> 都可用于将需求与其他元素相连。
<<allocate>> 是一种较宽松关系，用于“功能性需求只能由 SysML 行为元素（如活动、状态机或交互）满足”的场景 [67]。
类似地，<<realization>> 可替代 <<generalization>> 表示较松的继承关系；<<verify>> 用于执行验证与确认（V&V）的行为，通过返回布尔结果实现 [104]。
此外，<<trace>> 连接需求与其生成工件，而 <<derive>> 与 <<refine>> 连接需求与用例 [104]。

不透明行为与项流（Opaque Behaviors and Item Flows）¶

核心行为元素是不透明行为（Opaque Behavior）及其参数图对应的约束模块（Constraint Block）[67]。
这些元素允许文本式代码嵌入，支持简洁计算与与外部仿真引擎（如 MATLAB）接口交互（见图 36）。

超建模还倡导使用项流（Item Flow）表示系统间的连接及其传输内容。
项流可跨多个图表使用（如 ibd 上的连接器、act 上的对象流、seq 上的消息、stm 上的转换），从而在执行时同步各图表 [104]。

元链（Metachain）是 Cameo 团队定义的术语，用于描述模型元素间的隐式关系。
通过元链，可建立相对路径链接，将原本不直接相关的元素关联起来，并通过表格或矩阵展示大量关系信息（避免因连线过多造成图表混乱）[80]。
尽管此类关系在多跳场景下较脆弱，但若模型结构与元素使用遵循标准，并辅以验证配置文件支持，即可快速生成自动更新的汇总视图，便于模型汇报。

SAIC 验证配置文件（Validation Profile）¶

除 Hypermodeling 外，其他研究也提到通过验证配置文件（Validation Profile）为 SysML 模型添加结构约束的做法，其作用类似于编程语言的编译器错误检查 [104]-[106]。
Hypermodeling 使用了 SAIC 提供的验证配置文件，该配置文件为 MagicDraw/Cameo 与 Rhapsody 专用，基于纯 SysML 语法，因此尚未兼容 UAF/UPDM [107]。
该文件可从 SAIC 官网公开获取 [107]。

虽然 SAIC 配置文件并非唯一选择，但在工具原有编译功能之上增加错误检查与语法一致性校验，有助于提升团队间模型一致性与互操作性。

需要注意的是，SAIC 配置文件除推荐方法外，还对模型元素施加限制。例如，它会对任何引用属性（reference property）发出警告，因为引用关系（association）被认为是组合关系（composition）的弱化形式，未增加实际价值 [107]。
然而在某些情况下（如自动生成的关联块）引用关系是必要的，因为组合与关联/聚合在所有权上不同。
这体现了方法论与验证配置文件之间的紧密耦合关系，也说明缺乏标准化方法论会阻碍更优配置文件的推广（正是本文提出改进的动机之一）。
因此，本文示例任务不会采用 SAIC 验证配置文件，以避免与部分被强调的方法冲突。全面采用 SAIC 配置文件及其方法论是一种过度简化的做法。

替代模型（Surrogate Models）¶

任务工程的核心原则之一是：关注系统（system of interest）即为实战部署平台。
这意味着每个任务层实体应有其对应的系统级模型。
这些模型往往复杂且来自外部机构或 OEM（原始设备制造商）。
出于计算效率、一致性或知识产权保护等考虑，由任务工程师控制形式、系统工程师填充内容的替代模型（surrogate model）非常有用。
在本文的建模中，它还提供了一个清晰的低层抽象边界 [107]。

7. Weilkiens SysMod 流程（SysMod Process）¶

SysMod 流程提出了一种由功能分组（functional groupings）支持的功能参考架构（functional reference architecture）。
该方法通过交替连接“功能需求—实现”、“派生需求（derived requirement）”与“组件实现（component implementation）”三类元素，来实现需求与结构的闭环。但由于功能分解（functional decomposition）已在前文 IBM Harmony 与 Vitech CORE 方法中详细讨论，因此此处不再赘述。
该方法还使用分配矩阵（allocation matrices），这一内容已在“超建模（Hypermodeling）”部分中与元链（metachaining）的应用一并讨论过。

作为未来值得关注的方向，SysMod 引入了功能组（functional groups）的概念，即由多个单元 / 群组聚合而成的集合结构。
这一思想与任务工程的兵棋推演（wargaming）与作战建模（operational modeling）逻辑高度契合。
但需要注意的是：由于现代作战单元的任务导向（task-oriented）特性，静态、刚性定义的功能组在实际中用途有限。
遵循“减少不必要建模元素数量”的原则，本文所采用的任务工程模型直接将作战序列（order of battle）与平台层级（platform level）关联。
在此语境下，“平台（platform）”指已部署实体（例如飞机、舰船或地面载具），而“系统（system）”则为安装在该物理实体上的子系统。
这种区分使模型层次更加清晰。

然而，随着任务工程体系的扩大与模式（patterns）不断积累，未来可能会出现值得以模块化、静态结构形式固化的功能分组模式。届时，SysMod 的分组思想将成为有价值的扩展方向。但就目前而言，尚无足够数据支持这一拓展。

总体而言，SysMod 方法论在理念上与前文提到的功能分解方法一致，其与任务工程相关的要素已在前述部分涵盖。

2.3.4. MBSE 方法论总结（MBSE Methodology Summary）¶

前述章节介绍了多种用于应对不同工程优先目标的 MBSE 方法论，并讨论了各自相对于任务工程（Mission Engineering）的适用性。
虽然尚有其他方法与研究方向，但本节所选方法论已能代表系统建模领域的主要范式。
总体总结如下：

表 9 所述 MBSE 方法论及主要启示
| 方法论（Methodology） | 关键启示（Key Takeaways） | | :--- | :--- | | INCOSE 面向对象系统工程方法（OOSEM） | - 采用与 JCIDS 流程相一致的自顶向下结构建模方式
- 实现封装（encapsulation）、继承（inheritance）与复用（reuse）的设计实践 | | IBM Rational Telelogic Harmony-SE / Rational Unified Process for Systems Engineering (RUP-SE) | - 基于功能分解的行为建模（活动图与 ibd 的语法级关联）
- 多层抽象（levels of abstraction）
- 需求间关系（intra-requirements relationships） | | CORE Vitech MBSE 方法 | - 整体构造框架（将仿真与结构化 SysML 模型解耦）
- 四步法实现功能分解（较 Harmony 的分解范围更广）
- 洋葱模型与层内并行过程（onion model and concurrent processes） | | JPL 状态分析（State Analysis, SA） | - 任务层与系统顶层状态机的创建流程
- 泛化超类型（generalized supertypes）与构型标注（stereotypes）的联合使用 | | 超建模与 SAIC 验证配置文件（Hypermodeling and SAIC Validation Profile） | - 限制需求与其他元素类型间的关系
- 通过验证配置文件强制一致建模
- 以不透明行为与项流为核心机制
- 支持元链导航与表 / 矩阵视图
- 系统级替代模型（surrogate models） | | Weilkiens 系统建模流程（SysMod Process） | - 未来可引入的功能分组思想（functional grouping） |

2.3.5. 表现视图与架构框架（Presentation Views – Architecture Frameworks）¶

在介绍如何将上述建模方法论整合为一个统一方法之前，首先需要明确模型成果应如何呈现给最终用户。
系统建模（Systems Modeling）目前已可支持任务层分析，即便这些分析多源于传统架构，因此需要使 SysML 模型与既有架构图式相匹配。

根据 DoDAF 的定义，架构视图的目的是：

“为国防部各级管理者提供一个全面、统一的架构开发框架与概念模型，以通过跨部门（Department）、能力领域（JCA）、组成机构（Component）与项目（Program）间的有组织信息共享，更有效地进行关键决策。” [42]

这一目标通过标准化不同利益相关方与用户所需的视图（views）实现。
标准化包括统一命名、定义与格式，从而形成大量视图。
例如，DoDAF 2.02 共定义 51 个视点（viewpoints）。
这些视点是长期演化的结果，反映了用户对复杂系统信息需求的不断细化。
图 42 展示了该演化过程的简要历史：

图 42 架构框架的演化历史 [108]

如上图所示，早期的单一架构源如今已分化为四个主要分支：DoDAF、MoDAF、DNDAF 与 NAF。
其中，DoDAF 来自美国；MoDAF 来自英国；DNDAF 来自加拿大；NAF 则用于北约体系。
由于四者拥有共同起源，因此存在大量相似性。
逻辑上，这种分化也引发了重新统一的需求，于是诞生了 UPDM（Unified Profile for DoDAF and MODAF）。
该项目由对象管理组织（OMG，Object Management Group）发起——该组织也是 UML 与 SysML 的制定机构。
NATO 架构能力团队（Architecture Capability Team）于 2012 年正式响应这一努力 [108]。
此后，UPDM 进一步发展为更广义的 统一架构框架（Unified Architecture Framework, UAF），以适应多国架构标准，并弱化过度的国防领域专用术语。目前仍由 OMG 负责维护 [108]。

美国国防部首席信息官（DoD CIO）在 2012 年正式认可此转变，并计划由 UAF 替代 DoDAF。
然而，关于迁移进展的公开资料稀缺，即便在规划的 2016 年采用时间节点后，仍无广泛应用的迹象 [109]。
这反映出统一架构框架的主要挑战之一：方法变革的阻力——尤其当新方法比旧方法更复杂时更难推广。
为说明这种复杂性，图 43 列出了 UAF v1.2 的视点矩阵：

UAF Guoming Mometrost GLANETING	Motivation Mv	Taxonomy Tx	Structure Sr	Connectivity Cn	Processes Pr	States St	Sequences Sq	Information If	Parameters Pm	Constraints Ct	Roadmap Rm	Traceability Tr
Architecture Management Am	Architecture Principles Am-Mv	Architecture Extensions Am-Tx	Architecture Views Am-Sr	Architectural References Am-Cn	Architecture Development Method Am-Pr	-	-	Dictionary Am-If	Architecture Parameters Am-Pm	Architecture Constraints Am-Ct	Architecture Roadmap Am-Rm	Architecture Traceability Am-Tr
Summary & Overview Sm-Ov
Strategic St	Strategic Motivation St-Mv	Strategic Taxonomy St-Tx	Strategic Structure St-Sr	Strategic Connectivity St-Cn	Strategic Processes St-Pr	Strategic States St-St	-	Strategic Information St-If	Environment En-Pm and Measurements Me-Pm and Risks Rk-Pm	Strategic Constraints St-Ct	Strategic Roadmaps: Deployment, Phasing St-Rm-D,-P	Strategic Traceability St-Tr
Operational Op	Requirements Rq-Mv	Operational Taxonomy Op-Tx	Operational Structure Op-Sr	Operational Connectivity Op-Cn	Operational Processes Op-Pr	Operational States Op-St	Operational Sequences Op-Sq	Operational Information Model Op-If		Operational Constraints Op-Ct	-	Operational Traceability Op-Tr
Services Sv		Services Taxonomy Sv-Tx	Services Structure Sv-Sr	Services Connectivity Sv-Cn	Services Processes Sv-Pr	Services States Sv-St	Services Sequences Sv-Sq			Services Constraints Sv-Ct	Services Roadmap Sv-Rm	Services Traceability Sv-Tr
Personnel Ps		Personnel Taxonomy Ps-Tx	Personnel Structure Ps-Sr	Personnel Connectivity Ps-Cn	Personnel Processes Ps-Pr	Personnel States Ps-St	Personnel Sequences Ps-Sq	Resources Information Model Rs-If		Competence, Drivers, Performance Ps-Ct-C, -D, -P Resources Constraints Rs-Ct	Availability, Evolution, Forecast Ps-Rm-A,-E,-F	Personnel Traceability Ps-Tr
Resources Rs		Resources Taxonomy Rs-Tx	Resources Structure Rs-Sr	Resources Connectivity Rs-Cn	Resources Processes Rs-Pr	Resources States Rs-St	Resources Sequences Rs-Sq				Resources Roadmaps: Evolution, Forecast Rs-Rm-E, -F	Resources Traceability Rs-Tr
Security Sc	Security Controls Sc-Mv	Security Taxonomy Sc-Tx	Security Structure Sc-Sr	Security Connectivity Sc-Cn	Security Processes Sc-Pr	-	-			Security Constraints Sc-Ct		Security Traceability Sc-Tr
Projects Pj	-	Projects Taxonomy Pj-Tx	Projects Structure Pj-Sr	Projects Connectivity Pj-Cn	Projects Processes Pj-Pr	-	-	-			Projects Roadmap Pj-Rm	Projects Traceability Pj-Tr
Standards Sd	-	Standards Taxonomy Sd-Tx	Standards Structure Sd-Sr	-	-	-	-	-		-	Standards Roadmap Sd-Rm	Standards Traceability Sd-Tr
Actual Resources Ar	-		Actual Resources Structure Ar-Sr	Actual Resources Connectivity Ar-Cn	Simulation			-	-	Parametric Execution/Evaluation	-	-

图 43 UAF v1.2 视点矩阵 [110], [111]

UAF 中共有 88 个视图（views），比 DoDAF 增加了 37 个。
这意味着 UAF 引入了大量全新视角，其行列与 DoDAF 之间的对应关系并非一一匹配，如图 44 所示：

UAF 与 DoDAF 视点映射（节选）	Motivation Mv	Taxonomy Tx	Structure Sr	Connectivity Cn	Processes Pr	States St	Sequences Sq	Information If	Parameters Pm	Constraints Ct	Roadmap Rm	Traceability Tr
Architecture Management Am	N/A	N/A	N/A	AV-1	N/A	N/A	-	AV-2	N/A	N/A	N/A	N/A
Strategic St	CV-1	CV-2	CV-2	CV-4	CV-1 CV-2	N/A	-	DIV-1	Me-Pm CV-6	CV-4	CV-3 CV-5	N/A
Operational Op	-	OV-1 OV-2	OV-2	OV-2 OV-3	OV-5a OV-5b	OV-6b	OV-6c	DIV-1	-	OV-6a	-	CV-6
Services Sv	-	SvcV-1 SvcV-2	SvcV-1 SvcV-2	SvcV-3b	SvcV-4	SvcV-10b	SvcV-10c	-	-	SvcV-10a	SvcV-8 SvcV-9	SvcV-5
Resources Rs	-	SV-1 SV-2	SV-1 SV-2	SV-1 SV-6	SV-4	SV-10b	SV-10c	-	-	SV-10a	SV-8 SV-9	SV-5a SV-5b

图 44 DoDAF 与 UAF 1.2 视点映射 [111], [112]

展示 UAF 元模型复杂性的目的，是为了说明：架构框架的实现与详细评估过于复杂，无法在简短的综述中全面涵盖。
本文中的介绍仅为后续示例任务提供足够的基础，但任何计划实际应用该方法的用户，都应查阅其客户所采用架构框架的规范标准。

尽管在广泛的使用群体与既有语言体系中推行统一标准存在巨大困难，但拥有统一语言（common language）的价值依然显著——这同样是 SysML 与 UML 诞生的初衷。
由于 UAF、DoDAF、MODAF 等框架代表的都是用于表达模型的视点（viewpoints for communication），因此在设计过程中无需绝对遵循。
这种做法类似于报告编写：报告在特定阶段生成，以展示设计成果，而非持续迭代的工作文件。
因此，所采用的架构框架应由客户需求与项目特点共同决定。

UAF 实现（UAF Implementation）¶

UAF 与其他架构框架一样，是与语言无关（language agnostic）的。
其具体封装与实现方式由工具提供商决定。
在本文所使用的环境中，UAF 由 Cameo 的开发商 No Magic 实现。
Cameo 中的 UAF 实现细节见附录 B：《No Magic 在 Cameo 中实现 UAF 视点的参考指南》。

2.4. 文献综述总结（Literature Review Summary）¶

前一章节介绍了系统工程（Systems Engineering）、SysML、SysML 在 MBSE 中的多种实现方法，以及可叠加在底层模型之上的架构视图（overlays/views），以支持传统架构框架的表达。
这部分内容信息量庞大，通常需要数月的学习周期，但在此简要回顾几个核心要点：

SysML 在 MBSE 中的作用；
系统工程（Systems Engineering）与任务工程（Mission Engineering）的比较；
系统工程方法论中的共通主题；
架构视图叠加（UAF、DoDAF、UPDM 等）。

SysML 是 MBSE 中最常用的图形化建模语言，能够捕获系统或系统之系统（system of systems）的需求、结构与行为，并将三者通过语义链接构成完整体系，这是传统基于文档的工程无法实现的。
这种语义链接结构构成了更高层次建模与仿真的基础，包括任务层与战役层建模——这正是任务工程的核心应用层级。

虽然每种方法论各有优劣，但它们普遍体现出以下趋势：

形式服从功能（Form follows function）；
元素复用（Element reuse）；
针对性精度（Tailored fidelity）与复杂性控制；
递归建模技术（Recursive modeling techniques）。

无论偏重结构建模还是行为建模，这些方法均以模型支持的最终目标为导向。
这说明二者可互补共用——二元对立的“行为导向”与“结构导向”在实践中并不冲突，只要目的相同，它们即可并行融合。
这意味着问题只剩语法层实现，而非理念层冲突。

元素复用（Element reuse）是控制复杂性的核心原则。
它包括继承（inheritance）、封装（encapsulation）与引用（referencing），不仅适用于单个元素，也可扩展至整个模型（模型即元素集合的聚合）。
这构成了联合建模（Federated Modeling）的基础——联合建模对于配置管理（configuration management）与跨机构建模协作至关重要，特别是在涉及国防部（DoD）系统的任务工程场景中。
因此，基于复用原则的联合建模将在后续任务工程方法论中较早出现。

针对性精度（Tailored fidelity）同样旨在避免复杂性。
在建模早期明确模型需回答的问题（即模型的功能目标）是确保模型规模合理的关键。
因此，任何方法论都仅是一种建议，每个客户都需要一定的裁剪。
各方法论普遍承认这种现实限制——这也是它们能够被拆解与组合（如本文所采用方式）的原因。
通过在早期识别模型形式并恰当实施复用，本研究提出的方法可在任务工程领域实现合适层次的精度控制。

递归建模技术（Recursive modeling）是进一步控制复杂度的机制。
若每个抽象层都要求不同的建模方法，建模与教学的难度将显著增加。
递归建模允许在不同抽象层重复使用同一方法，提升一致性与效率。
因此，本研究提出的任务工程建模方法将尽可能采用递归机制。

然而，任何建模方法若无法将结果有效传达给客户，其价值都将大打折扣。
如同针对性精度一样，不同客户拥有不同的内部流程，建模成果必须能够适配这些流程。
这也是为何存在美国（DoDAF）、英国（MoDAF）、加拿大（DNDAF）、澳大利亚、北约以及产业界的多种架构框架。
尽管有统一化努力（如 UPDM、UAF），但目前仍无“一体化”解决方案，采用何种架构框架仍取决于客户。
在此假设下，UAF 作为美国国防部计划采纳的框架，是本文后续示例任务采用的合理选择。

总体来看，无论从 MBSE 的普遍趋势还是其内部方法论的发展，均有大量适用于任务工程的内容可借鉴。
本章的简要综述为下一章奠定了基础——下一章将正式将其综合为一套可用于任务工程的 MBSE 方法论。

3. MBSE 支持的任务工程（MBSE in Support of Mission Engineering）¶

本章基于前文的文献综述，旨在实现两个主要目标：
1. 建立任务工程（Mission Engineering, ME）与 MBSE 的形式化关联；
2. 通过将前文提炼的方法论要素应用于示例任务，综合形成一套完整的建模方法。

任务工程与 MBSE 的形式化关联，是基于两者任务与目标对比后建立的方法论适用性基础。
示例任务则将作为验证案例，证明任务层级的分析与建模可通过 MBSE 方法实现。

本节通过对比任务工程与 MBSE 的流程及 SERC 提供的调研结果，阐述两者的相似性与协同关系。

迄今为止，本文已分别介绍任务工程与 MBSE，并初步揭示了二者间的协同性。
现需正式建立其联系。
两种学科遵循的总体流程基本一致：

识别需求（Identify need）；
提取并细化需求（Elicit and refine requirements）；
确定满足需求的功能行为（Determine functional behavior）；
确定支持该行为所需的结构（Determine supporting structure）；
识别并控制结构组件间的接口与交互（Identify and control interfaces/interactions）；
围绕外部因素进行仿真 / 设计，并验证其仍满足第 2 步定义的需求。

该流程是对前文系统工程与任务工程文献的概括性归纳，意在说明两者在不同抽象层中可递归应用。
范围与抽象层级是二者差异的核心维度。

任务工程的焦点是“任务”——其首层功能行为与结构单位不是单一系统或子系统，而是跨多个领域协同的系统集合（collection of systems），旨在实现整体效能大于部分之和的任务目标。
自“合成兵种（combined arms）”理论提出以来，这种跨域协同结构已被正式纳入作战体系 [113], [114]。
因此，任务工程的抽象起点是国家战略层级（源自政治、经济等非技术因素），向下延伸至技术系统层。
系统层的代表性单元通常是执行任务的机动单元，如单艘水面舰艇。

系统工程（Systems Engineering, SE）则源于应对现代复杂系统的跨学科需求，因而是一种自下而上的方法。
随着系统间互操作性的增强，“系统之系统（System of Systems, SoS）”这一新学科被提出，以处理新的复杂性。

综上可见，任务工程与系统之系统工程（其本身是系统工程的子集）存在显著重叠。
这一重叠沿着前述“范围 / 抽象层轴（scope/abstraction axis）”形成了一个连续谱系（continuum），从系统工程延伸至任务工程，如图 46 所示。

图 46 系统复杂性轴连续谱（Systems Complexity Axis Continuum）

3.1.1. 从系统工程到任务工程的抽象层级关联（Abstraction Linkage from Systems Engineering to Mission Engineering）¶

在探讨系统工程（Systems Engineering, SE）与任务工程（Mission Engineering, ME）关系时，图 46 中所展示的连续轴（contiguous axis）值得进一步讨论。
该轴的关键连接点在于抽象层级（level of abstraction）。
本文中多次提及“抽象”一词，但迄今为止尚未充分阐述其基础意义与在任务工程中的作用。
综合前文关于 NDS 高抽象层级的讨论、RUP SE 的抽象层级部分，以及系统之系统接口建模方法（System of System Interface Modeling Method）中关于接口抽象的内容，可以看出一个清晰的模式：

抽象层级决定了分析的范围、分析类型以及所分析的系统类型；
它同时决定了使用的工具和所服务的客户。

然而，尽管这一思路揭示了抽象层级的重要性及其识别方式，它尚未具体界定任务工程的抽象边界，也未说明任务工程与系统工程的层级关系。

依据 RUP SE 的抽象定义，任务工程主要存在于“上下文层（Context level）”与“分析层（Analysis level）”。
在此范围内，任务本身被视为系统（the mission as the system）。
此时系统尚未实现，硬件或软件的具体配置也未确定。
上下文层与分析层的区别，与系统之系统接口抽象部分描述的“细化层级”类似：

上下文层（Context level）：例如描述“传感器（sensor）输出航迹（tracks）”；
分析层（Analysis level）：进一步具体化为“传感器 = 主动雷达（active radar）”，“航迹 = 特定链路消息类型（Link Message type）”，“接口 = 915 MHz 无线射频链路（wireless RF at 915 MHz）”。

在任务工程的首次分析中，不需要再进入 RUP SE 的设计层（Design level），即不需对系统实现进行建模。
这种抽象层级的限定使得可以引入前文在“超建模与 SAIC 验证配置文件（Hypermodeling and SAIC Profile）”部分提到的代理块（surrogate blocks）。
通过继承特性定义代理块、限定抽象层边界，可建立一个可控的抽象层级（controllable level of abstraction），从而使任务模型能直接关联至系统模型，如“代理模型”部分所述。
这一思路是本章稍后提出的任务工程建模方法论的核心基础，其实现依赖于对系统与任务模型间抽象关系的充分理解与正确应用。

3.1.2. 调研数据（Survey Data）¶

任务工程是系统工程（通过系统之系统工程 System of Systems Engineering, SoSE）的高抽象延伸，这一观点得到了 2018 年美国国防部系统工程副助理部长办公室（DASD(SE)）资助、系统工程研究中心（SERC）开展的调研支持 [115]。
该调研样本主要来自国防工业与政府人员。尽管样本规模有限，但结果总体上支持本文的论点——即任务工程与系统工程密切相关。

图 47 任务工程与系统工程的重叠关系 [115]

尽管该研究总体支持二者的重叠，但对如何描述这种重叠仍存在分歧：
约 50% 的受访者认为任务工程与系统之系统工程相似，
约 30% 则认为任务工程直接属于系统工程的延伸。

图 48 SERC 调研：任务工程与系统工程的重叠分布 [115]

虽然问卷允许多选，但总体结论一致：任务工程与系统工程密切相关。
然而，尽管这种共识提供了理论基础，它并未证明二者在技术与执行层面（technical and executable level）存在一致性。
要验证前文 MBSE 文献综述中提及的细化建模方法是否可应用于任务工程，最直接的方式是对两者的任务（tasks）进行对比。
图 49 列出了系统工程与系统之系统工程（被视为任务工程的等价层级）在不同领域的对照。

	系统工程 (SE)	系统之系统工程 (SoSE)
管理与监督
利益相关方参与	明确的一组利益相关方	多层级利益相关方，可能存在利益冲突
治理机制	管理与资金一致	管理与资金体系更复杂，SoS 无法控制所有组成系统
作战焦点（目标）
作战焦点	为共同目标设计与开发	使用多个系统来实现新的 SoS 目标，这些系统的原始目标可能不一致
实施过程
采购与开发	与既定流程一致	跨越多个系统生命周期，涉及异步开发、遗留系统与新技术引入
工程过程	成熟、固定	依赖学习与适应
测试与评估 (T&E)	可直接进行系统级测试与评估，以性能度量（MoP）为依据	受系统异步生命周期与复杂性影响，SoS 层需定义更抽象的效果度量（MoE），难以量化
工程与设计考量
边界与接口	明确系统边界与接口	SoS 具有动态与可重构特性，边界与接口可变，组件系统可能同时属于多个 SoS
性能与行为	聚焦系统性能目标	聚焦 SoS 层整体性能与能力平衡
度量指标	需求可直接导出	受制于独立管理的组件系统，难以定义、协商与量化

图 49 系统工程与系统之系统工程的对比 [115]

从图 49 可得出一个关键结论：

任务工程与系统工程在本质上相似，只是复杂性更高。

这种复杂性来源于： - 系统数量的增加；
- 利益相关方的多样化；
- 地理层与机动层引入的动态维度。

这一结论可通过系统与部署单元（deployed unit）的配置管理对比得到验证：
系统通常通过工程变更提案（ECP）管理，且结构稳定、接口固定；
而部署单元由多个系统组成，能根据任务（类似设计规范）快速重组。
任务变化的频率远高于系统设计变更频率 [114]。

因此，二者的主要差异在于设计周期、范围与抽象层级，而非根本目标。
只要在任务工程中考虑其动态特性，系统工程的基本原理即可直接应用。

3.2. 任务工程案例中的建模方法应用（Modeling Methodology Applied to Mission Engineering Use Case）¶

本节演示如何将前文识别出的 MBSE 方法论应用于任务工程场景。
这部分内容既是第 3.1 节论点的技术化证明，也是方法论的实践展示。
其内容涵盖结构（structure）、行为（behavior）、仿真（simulation）与权衡分析（trade study），采用 Cameo 与 MATLAB 工具。
本文并非提供逐步操作指南，但对熟悉建模的读者而言，内容足以复现。

展示前文所有关键要点最清晰的方式是通过一个示例模型（example model）。
虽然模型本体附于文后，这里重点指出几个关键亮点，并说明其与表 9 所总结要点的对应关系。

3.2.1. 任务描述（Mission Description）¶

一个综合防空（Integrated Air Defense, IAD）系统被部署于简陋前沿阵地，用以保护作战区域后方的重要目标。
系统包含两个分布式联网传感器，与指挥节点保持一定距离以提高生存性，通信方式为无线网络。
有一架来袭敌机，需在其进入武器射程区（200 km）前被搜索雷达与跟踪雷达同时探测到。
由于基地条件简陋，燃料消耗与后勤保障成为关键约束：燃料消耗不得超过 110 kg/h，且总作战成本不超过 $2000/日。
任务目标是在此约束下验证系统是否能完成任务。

任务工程过程基于该任务描述展开。
该描述作为工程过程的输入文本块，即一切建模内容的起点。
由于本任务描述由研究者生成，需说明其内含假设，因为这些假设会被任务工程过程继承：

传感器为主动雷达（active radar），未考虑被动射频或 EO/IR 方案；
200 km 武器射程区为固定值，不随环境或平台参数动态变化；
燃料消耗为常数，而非负载相关的动态值。

每个任务描述都隐含更多假设，但关键在于——这些假设由作战用户（operational customer）提出，而非建模工程师决定。
它们用于合理界定任务范围，使任务模型能被精确捕获。

3.2.2. 模型结构（Model Structure）¶

确定模型需回答的问题后，必须定义支持该问题分析的结构。
该结构需连接系统级真实模型与任务级分析 / 仿真组件，包含以下要素：

模型结构（package layout）；
基于该结构的建模过程。

3.2.2.1. 参考建模过程（Reference Modeling Process）¶

在实际项目中该部分非必需，但本例用于集中存放模型要素与图表，如图 50 所示。

3.2.2.2. 库（Library）¶

库包（Library Package）是任务模型的构建模块集合。
它为整个建模工作共享、集中管理的资源库，用于确保模板一致性（Template Consistency）。
图 51 展示了其内容结构。

库中包含： - 适配任务仿真框架的代理系统（surrogate systems）；
- 常用组件（信号、约束、接口、数值类型等）。
这些组件因具备高复用性而受严格控制。

模板包（Template Package）则用于存放本地化建模文档与方法说明。

3.2.2.3. 利益相关方（Stakeholders）¶

Stakeholder 包（图 52）用于存放背景资料与支撑文档，以确保模型师 / 工程师与客户的共同理解。
传统的作战可视化图（如 OV-1）等也放置于此处。

3.2.2.4. 顶层功能需求（Top Level Functional Requirements）¶

任务需求在该部分定义。
从 JCIDS 顶层关键性能参数（KPP）出发，任务逐步分解为支撑性需求、功能与性能需求，最终形成性能度量指标（MoP）。
这一过程保证整个任务工程链路的可追溯性，并与任务结构一致（图 53）。

不同类型的需求映射至不同模型元素（例如功能需求对应行为角色）。
通过构型标注（stereotypes）定义这种关系是 SysML 的原生特性，也与 JPL 状态分析中的关键方法一致。

3.2.2.5. 任务工程层（Mission Engineering Level）¶

该层是任务工程工作的主要执行区域。
从库中调用的代理系统、接口与约束在此聚合、连接，并与需求关联。

此包中包含多个智能包（Smart Packages），这些包作为指针引用库中的原始元素。
通过元链（Metachain）填充实现引用，既能按用途组织模型结构，又保持集中管理，便于配置控制。
随着模型规模增长，这种引用方式显著提升工作效率。

此外还包含子任务（Sub-Missions）与任务变体（Mission Variants）包，支持并发任务与权衡研究（trade studies）。

该层的两个矩阵用于快速分配任务角色，并汇总系统在任务中扮演的功能角色，类似传统能力缺口分析文档。

名为 IAD Mission 的上下文块代表整个任务结构，是建模的核心产物。
该块应用了 <> 构型标注，因为任务既非单一系统（如雷达、C2 节点），也非完全外部实体，因而该标注最为合适（图 54）。

最后，该包中还包含若干与仿真（simulation）相关的元素与图表，从任务序列（Mission Sequence）到仿真配置与结果曲线（Graphs）均在其中定义。

3.2.2.6. 系统工程层级（System Engineering Level）¶

系统模型可来自两个来源以支持任务工程：政府和工业界。根据信息来源及系统模型的敏感性，模型可能完全或部分地可供任务工程师使用。因此，位于 Library 包下的代理块（surrogate block）是任务工程所使用的复杂性轴上最低层的元素，因为它是唯一可靠存在的元素。然而，如果系统模型可用（取决于保密级别和专有性），则有必要通过执行“项目使用（project usage）”将其作为只读引用引入此包中。在此示例中，搜索雷达、飞机和 C2 节点是可用的，而跟踪雷达不可用。在其代理中准确地描述系统对于任务的准确性至关重要，并且拥有源模型作为参考可以提高任务工程师的精度和理解。然而，只要任务工程团队与系统工程团队之间有足够的沟通，即使没有模型也可以进行任务工程。

图 55 系统工程层级展开（System Engineering Level Breakout）

3.2.2.7. Distro A 模型模板（Distro A Model Template）¶

为模型设置一个登陆页面或 README 对于任务工程特别有用，因为客户或管理人员可能对 SysML 只有粗浅的理解，还未熟练掌握它。拥有一个文档化且可读的方式来浏览模型，而无需了解包的结构，会非常有帮助。

3.2.3. 模型过程（Model Process）¶

在确定模型是什么之后，接下来要介绍如何构建一个任务工程模型。第一步是识别在建模项目中将要使用的过程。此处的示例将在 SysML 中进行，使用功能性（CORE、IBM、JPL SA）和结构性（OOSEM）分解。不使用 UPDM、UAF 或 DoDAF，以保持示例的通用性。由于每个配置文件都会添加额外的构型标注（stereotypes）和元素，同时重命名或移除其他元素，它们的使用可能会对建立一个普遍理解的示例产生反作用。

3.2.3.1. 利益相关者识别与过程概述（Stakeholder Identification and Process Overview）¶

一旦确定了语言和总体流程，下一步是识别任务的利益相关者。对于此示例，参与者是一个通用的系统工程师和任务工程师，与一个通用的作战客户（Operational Customer）协作。作战客户通常带来需要解决的任务描述，以及可能用于解决该问题的现有遗留选项，和/或新系统在任务中将扮演的功能角色。该新系统被称为关注系统（System of Interest, SOI）。系统工程师提供遗留系统或潜在 SOI 的权威来源。任务工程师负责了解有哪些任务分析工具可用并适用于场景，这取决于作战客户所提出的问题。根据本示例所构建的模型，是系统工程师与任务仿真框架之间的接口，因此由任务工程师拥有并构建，以回答作战客户的问题。

一旦识别出利益相关者，就可以将他们聚集起来并阐明需求。在此情况下，客户提供了前文讨论的示例任务，并希望探索综合防空任务的权衡空间，特别是杀伤链中的探测部分。他们对探测与目标定位距离之间的关系，以及对燃料消耗和成本的影响感兴趣，以支持对假想防空基地后勤可行性的更大范围分析。与往常一样，他们还对识别任务体系结构中的任何能力缺口感兴趣。模型实际上是以下形式的传递函数：

\[ \text { MassFlow}_{\text {fuel }}=f\left(\text { Power}_{\text {radar }}, \text { Power}_{\text {communications }}, \text { EngagementRange}_{\text {threat }}\right) \]

图 56 任务工程过程（Mission Engineering Process）

图 57 通用任务工程用例（Generic Mission Engineering Use Case）

3.2.3.2. 任务叙述与 OV-1 生成（Mission Narrative and OV-1 Generation）¶

在此示例中不存在关注系统（system of interest），因为这是一个作战分析，而不是自下而上的工程。此外，范围相对受限，然而，如将看到的那样，即便是对上述示例进行一次单次迭代的计算，也需要大量的细节。在这一点上，已经有足够的信息生成一个初步的 OV-1：

图 58 IAD 任务 OV-1

任务叙述如下：

威胁飞机正飞向目标（不是通信，因此未显示在图 59 中）；
威胁飞机被搜索雷达探测到（不是通信，因此未显示在图 59 中）；
搜索雷达将该探测结果传递给 C2 节点，此时 C2 节点处于待机状态，等待警报（1. 目标已探测和 2. 目标信息）；
C2 节点通知跟踪雷达，并将来自搜索雷达的航迹输入其内部数据库（3. 目标已探测和 5. 将航迹输入数据库）；
跟踪雷达通过 C2 节点由搜索雷达排队，对威胁飞机进行锁定（4. 目标信息）；
跟踪雷达将改进的目标定位解返回给 C2 节点（6. 目标信息）；
这为后续由某种效应器对威胁飞机进行交战奠定了基础（效应器超出模型范围，因此未显示在图 59 中）。

对于该最后的图，有几个特别需要注意的事项：武器平台与任一雷达之间缺少消息；<> 构型标注，在此图中并不包含于任务包（参见前文关于模型结构的部分）。

逐条分析，这个图展示了预期的通信路径。探测器与威胁之间的交互不太可能是有意的通信，因此是一种基于物理的交互。在这种建模方法中，区分了设计通信和基于物理的交互。设计通信是有意的（但不保证）并传递信息，是基于时间顺序的，并通过活动发送信号表示（图 67）。基于物理的交互无论两个对象的顺序或状态如何都会发生，表示不可避免的交互，并使用参数约束/内部块图进行建模（图 69）。

<> 构型标注表示这既不是物理系统也不是逻辑系统，而是一个系统类别。<> 构型标注将通过泛化关系由那些声称属于该类别的系统的代理继承。（JPL 状态分析与 INCOSE 面向对象系统工程方法（OOSEM））这种继承确保了代理之间的一致性，并使能够控制这些接口以支持任务仿真成为可能。

最后，这个图包含在利益相关者包中，因为它是任务定义过程的一部分生成的。此外，它在任务的最终仿真中不起作用，因为它是自上而下的行为模型。任务没有控制实体来确保每个任务参与者都按照总体计划行事。相反，任务是多个系统的聚合体，这些系统具有各自的行为并协同工作。存在结构性交互，但这些交互属于物理基础类型，因此不适用于行为建模。

3.2.3.3. 任务需求捕获（Mission Requirements Capture）¶

在确定了目标（以燃料消耗、成本和性能为指标评估特定杀伤链的性能）之后，需要在模型中捕获这些目标。

正如在文献综述中所确定的那样，需求从 JCIDS 顶层关键性能参数（KPP）开始并逐层细化。对于本任务，由于未建模或考虑人员，因此未使用部队防护 KPP（Force Protection KPP）。系统生存性被归结为需要在威胁能够攻击目标 C2 节点或传感器本身之前对其进行打击。由于本例中杀伤链范围内的部分仅为探测部分（包括发现、定位和跟踪），唯一的需求是威胁在进入其交战范围之前被探测到。为了使需求能够为满足的值属性着色，必须以能够从中提取方程的方式编写。关键字是“大于/小于”。在这样做时，也会链接任何硬编码到需求中的值，如成本或燃料消耗，当需求是两个目标之间的关系时，如本例的系统生存性 KPP，需要创建一个虚拟变量（“detectionOutrangesEngagement”）。需要注意的是，在此模型创建阶段，“Satisfied by” 列将为空，因为该部分模型尚未构建。能源和保障 KPP 不言自明，而网络就绪能力（Net-Ready Capability）作为唯一一个由不属于任务或其引用的值属性满足的 KPP 显得突出。这些值属性归属于系统间的接口，将在接口实现部分中进行解释。

（表格同上）

图 60 模型中捕获的需求（Requirements Captured in Model）

从图 60 中得出的主要观点是，只有性能需求（performance requirements）是由值属性直接满足的。功能性需求（functional requirements），如兼容网络接口，更难以确保符合性，因为它们不能通过约束来满足，需要人工验证，但应关联到操作或接口。

表中还指定了需求的验证方法。尽管较低抽象层次的系统可以在隔离状态下进行测试，并以现场测试作为验证方法，但任务级别所涉及的系统通常不允许采用这种测试方法。因此，分析成为验证需求是否满足的主要方法，而这种分析的准确性取决于所使用工具的技术严谨性。在此详细说明该列的主要原因是，对于新系统，任务级别的分析取决于较低级别的设计。在“中间出发工程（middle out engineering）”中，当正在为任务角色设计系统时，这些任务级需求应分解为系统级需求，以在任务和系统级别的设计过程中保持可追溯性。

虽然 MBSE 有其优势，并且本文及其他文献已经证明，与基于文档的工程方法相比，模型在较低配置管理工作量下更有用，但理解其局限性同样重要。尽管具有主观性，作为任务和系统工程师，与非技术客户进行期望管理是初步讨论中的关键组成部分。

3.2.3.4. 任务系统定义——结构（Mission System Definition - Structure）¶

现在，目标已被捕获为模型需求，并确定了关注系统（在本例中无，全为遗留系统），下一步是识别参与的系统。从 OV-1 中提取，任务有四个参与者（威胁飞机、两部搜索和跟踪雷达以及一个 C2 节点），然而，还有一件对能源 KPP 分析至关重要的支撑设备：为雷达供电的发电机。虽然它不是杀伤链的功能性部分，因此不在 OV-1 上显示，但它将出现在服务视角（Service Viewpoint）图中。了解这些信息使得可以构建第一个任务图——任务结构 bdd（图 61）。

图 61 任务结构 bdd（Mission Structure bdd）

该 bdd 显示“IAD Mission” 是“Mission”的一个子类型，而“Mission” 本身是“Environment”的一个子类型。这允许在任务模型库增长时实现任务类型的某种专门化。它也遵循 OOSEM 中概述的继承前提。该图还显示了与本文迄今为止的某些语言相矛盾的内容，即这些块是定向组合（directed composition）而非语法上更准确的定向聚合（directed aggregation）。虽然两者都是关联类型，但它们创建了不同类型的属性。此外，组合关系意味着一种所有权水平，对于一个系统更可能是任务组织且流动的任务而言，这种所有权过于严格和脆弱。虽然承认聚合是更正确的关系，但出于一个简单原因，它未被使用：组合关系更易于仿真。如在后续的仿真部分中将进一步讨论的那样，仿真部分属性（composition）与引用属性（aggregation 或 association）之间存在差异。部分属性会在初始化过程中自动创建一个对该部分属性进行类型化的块实例。引用属性则需要手动指定一个对该属性进行类型化的块实例。因此，出于方便考虑，并且承认定向聚合是更技术上正确的语言实现，本示例模型将改用定向组合。技术与实际之间的冲突总是如此。

然而，这种让步并非没有文献依据，因为 SAIC 验证配置文件完全禁止引用属性，在发现时会将其标记。（Hypermodeling and SAIC Profile）尽管如后文关于连接器类型的讨论所述，这种完全拒绝引用属性的方法是一种过于强硬的做法，这也是该配置文件未被采用为此方法论的一部分的原因之一。

撇开语义不谈，“Mission Structure” bdd 的构建依赖于必要系统已创建代理的假设。虽然这是该建模方法论的基本假设，但值得简要概述。由作者为任务工程和 SAIC 的系统之系统建模配置文件独立开发的这两种方法，都依赖于系统块与代理块之间的唯一映射。SAIC 在元素（如端口、系统之系统接口建模方法）之间使用实现关系，而任务工程方法则更进一步，使用系统模型上的唯一 ibd，将系统模型中可能隐藏在其部分中的值属性链接起来，并在需要时转换或组合它们以满足代理块上的值。行为也以类似方式被调整，开发人员与任务工程师协作，将方法应用于所需的操作（继承自功能黑箱模式）。该过程生成一个链接到支持系统模型的代理块，当系统更新和改进时可以更新它。构建和填充代理块的基本结构在图 62 中以非常简化的方式进行了说明。如果需要大量信息来促进与仿真框架的交互，则可以从包含该信息的块中添加另一层继承，以便它不会使显示给 OEM/系统建模人员的代理变得混乱，如图 64 所示。此较低层代理 + 仿真块将根据需要执行或实例化。由于本示例中的仿真框架只是与 Cameo 集成的 MATLAB，因此不需要此层。

图 62 代理块创建与可追溯性（Surrogate Block Creation and Traceability）

图 63 含附加仿真信息的代理块定义（Surrogate Block Definition with Additional Simulation Information）

图 64 代理块值属性可追溯性（Surrogate Block Value Property Traceability）

3.2.3.5. 任务系统定义——行为（Mission System Definition - Behavior）¶

在定义代理模型的同时，结构定义即是行为定义。在此阶段，已经知道代理可用的接口和信息，并且从系统模型中得到了有关其应如何表现的参考信息。直接提取系统级行为是不可行的，因为它可能依赖于结构深度或某些已不存在或已更改的变量。因此，创建新的行为以完整地封装系统的独特行为。这些行为并不是系统模型的抽象，而是为了支持仿真而简化和重新封装的。

此时需要考虑的一个重要问题是仿真框架将如何执行行为。这可能范围很广——从直接实现 Cameo 行为到完全不使用 Cameo 行为、仅限于使用本地行为类型——这完全取决于仿真框架实现的成熟度和细节[120]。这种可变性（正如本文中所有与仿真框架相关的内容一样）排除了本文方法论中具体实现的可能性。因此，这里的假设是：不存在外部行为，所有行为都必须在 Cameo 内构建并专门在其中运行。

既然确定行为仅存在于 Cameo 中，可以从文献综述中提取一些建议：使用不透明动作（opaque actions）、信号（signals）和状态机（state machines）。如前所述，任务没有总体行为。虽然实现一个总体任务层行为会更容易，但那样会呈现出任务的不现实图景，并可能导致错误的结论。相反，行为应同时启动并并发运行，仅基于这些独立并发行为之间的交互运行。虽然任务级图可以用于说明预期的任务流程，但该图中的概念是任务平台执行或实现的操作的抽象。因此，重点放在平台行为而非集中控制上是合理的。因此，作为原则，每个平台代理都由一个状态机控制，它确定任何时刻正在运行的一组活动，如下示例所示（图 65）：

图 65 C2 行为状态机（左上），顶层活动（右上），消息接收（左下）以及航迹存储管理（右下）

这些图中有两个值得注意的点：不透明动作的使用和循环。如在“超建模（Hypermodeling）和 SAIC 配置文件”部分中讨论的那样，不透明动作包含可执行代码，是 ibd/par 图上约束的对应物。在图 65 中，唯一显示的不透明动作是右下角“航迹存储管理”部分中的计时器。不透明动作的特征是能够执行基于文本的代码，这是在一个自包含、简洁格式中捕获详细系统行为的关键属性。在上图中，传入航迹的处理（这在系统模型中可能是详细的可执行行为）被简化为一个持续时间约束。虽然这是一个简单的示例，但注入基于文本的代码的能力允许对更复杂行为进行有效抽象。

循环（Looping）可以通过两种方式完成：在活动内部循环（如上所示），或在状态机中进行自转移（transition to self），如下方“威胁飞机”状态机中所示：

图 66 威胁飞机状态机（Threat Aircraft State Machine）

这两种选项的主要区别在于，自转移会清除未保存到值属性的变量，而活动内部循环则永不退出。图 65 中所示的循环通过在活动引脚上使用 {stream} 属性来实现，它允许在引脚上对值进行缓冲，并在活动尚未完成时将令牌传递给接收方。由于活动在内部循环，它将不会完成，直到发生状态更改。这也有助于确保“接受事件（accept event）”动作大部分时间处于接收状态，因为在重新打开之前要执行的动作更少，从而降低了仿真中信号未被消费的可能性。

虽然前两个状态机中的转换是基于信号的，但在某些情况下，JPL 状态分析（State Analysis）中使用的功能状态变量（functional state variables）非常有用，主要用于需要持久性不等式轴的场景，而这些不等式可能在不同任务中由不同系统构成。实际上，这意味着下方图 67 中的“搜索雷达”状态机需要在接收功率超过灵敏度阈值时，从“无检测”状态转移到“有检测”状态。这种变化可以直接作为触发器中的不等式，但这种转换足够重要，会被用于多个位置，并可能被外部块（如“C2 节点”）查询。“C2 节点”可能需要此信息，以便在其作为“控制系统”对杀伤链其余部分（即“被控制系统”）发出指令时提供输入。

在认为代理模型完成之前，行为建模的最后一点是通过使用关联块（association block）和类型化代理端口（typed proxy port）来实现的决策制定。虽然这确实要求系统在发送消息之前知道该消息能否到达接收方（即“inContact” <> 是基于关联上的参数计算的，JPL 状态分析），但这是一种可行的实现条件通信链接的方法。

图 67 搜索雷达状态机（左上）与行为（左下及上方）

3.2.3.6. 关于 ALH 和点符号的说明（Note on ALH and dot notation）¶

在 Cameo 中存在动作辅助语言（Action Helper Language, ALH）以及有限的点符号（dot notation）支持。可以将一个块传递给约束参数，并通过调用 PartPropertyName.valuePropertyName 访问其内容，ALH 的调用方式为 ALH.getValue(PartPropertyName, "valuePropertyName")。值可以以类似的方式设置。问题在于，如果部件属性名称或值属性名称发生变化，链接将被破坏。这些调用似乎基于字符串比较工作，并且没有一种方法可以像 MATLAB 等集成开发环境（IDE）那样更新所有命名引用。对于在活动图上按属性类型化的元素（如 readStructuralFeature 动作），这不是问题。虽然点符号和 ALH 更简洁，但它们会给建模者带来显著的潜在问题，因为 Cameo 仿真窗口中的编译器（主观上）在识别某些问题时帮助有限。因此，除非建模者确信属性将来不会更改，否则不推荐使用这两种方法。本说明并非对 No Magic 在 Cameo 中实现 SysML 的批评，而是作为一个接近教程示例的警告，并说明了为何该方法未被采用为此示例中代理块方法的一部分。

3.2.3.7. 任务体系结构与参数建模（Mission Architecture and Parametrics）¶

在代理模型构建完毕并与其所参与的任务建立连接后，任务体系结构本身就可以被构建（已进入图 56 中“构建黑箱任务模型（Build Black Box Mission Model）”步骤）。本节的目的有三点：建立信号传输路径、创建启用通信的特定连接器/接口，以及实现支持分析的数学模型。

创建信号路径是直接的，并不偏离在 ibd 上通过类型化代理端口创建连接器的方法。通过具有自有端（owned ends）的关联块指定连接器类型的步骤，允许使用分配给该关联块的参数模型。对于任务工程而言，这具有实用价值，因为通信并非总是可保证的。无论是由于距离还是敌方行为，在模型中加入能操控消息能否传递的逻辑是有益的，特别是在它与高保真仿真引擎相连时。要使用相同接口的两端实现这一点，需要如图 68 所示创建一个以自引用方式定义的具有自有端的关联块。

图 68 自引用关联接口（Self Referential Association Interface）

这种结构提供了系统之系统接口建模方法（System of System Interface Modeling Method）中识别的接口的三个方面：

物理端（Physical ends）——接口块（interface block）；
连接流（Connection flow）——接口块上的流属性（flow properties）；
连接介质（Connection material）——关联块（由其中存储的参数定义）。

当在两个由所属接口块类型化的端口使用之间键入一个连接器时，包含在关联块中的参数将被执行。这些参数通过参与属性构建，这些属性由连接器两端的引用属性类型化。如前所述，这种引用属性的使用在创建关联块时自动生成，与 SAIC 验证配置文件冲突。采用该验证配置文件将需要避免使用关联块或接受一些错误。除了在连接器上提供计算之外，通过关联块类型化连接器还会生成一个连接器属性，这对于访问在关联中计算的信息以满足需求和其他约束至关重要。使用所有这些方法会生成如下所示的结构 ibd：

图 69 任务 ibd（Mission ibd）

该简单图显示了通信可能采取的路径。值得注意的是，“威胁飞机”和“搜索雷达”之间的连接缺少接口，因为这里的关系是物理交互而非有意通信。由于代理块是没有部件的黑箱，连接器无法连接到“搜索雷达”部件中的天线，只能直接连接部件属性。此图还包含两种交互：一种是“威胁飞机”和“搜索雷达”之间基于物理的不可避免交互，另一种是通信建模的基于物理的组成部分，后者与图 67 中描述的部分协同工作。

ibd 的简洁性也掩盖了底层数学的视觉复杂性，如下所示：

图 70 任务层参数图（Mission Level Parametric Diagram）

图 71 连接器参数图（Connector Parametric Diagram）

虽然在“IAD Mission”块上使用参数建模并没有根本上的新意，在“RF Link”关联块上也仅略有不同，但主要结论是：所有计算都是在 Cameo 之外进行的。虽然 Cameo 与 MATLAB 的集成是原生的（需要管理员权限），但这与任务工程仿真框架提供的外部计算保持一致，尽管该框架的细节超出了本文的范围和敏感性。外部仿真的主要动因，如稍后讨论的，是为了利用现有工具，并绕过 Cameo 在变量作用域方面的一个限制。在相同抽象层次之间传递大量变量是极其困难且易出错的，这需要使用冗余变量（这在规模上不可扩展）或使用不会随变量名更改而自动更新的方法。

在此阶段，还需要验证任务的所有功能角色是否得到实现，并总结所使用的系统。这可以通过如下所示的矩阵实现（Hypermodeling and SAIC Profile）：

图 72 与功能角色（上）和物理形式（下）相关的任务代理黑箱（Mission Surrogate Black Box Related to Functional Roles (Top) Physical Form (Bottom)）

虽然功能角色将根据代理块定义自动填充，但在功能角色矩阵中发生三种类别的分配。在“Functional”部分，根据代理块的定义，至相应模式块（pattern block）的泛化将自动填充。“Role”部分是为代理在此特定任务中执行的角色应用构型标注。“Role”必须是“Functional”的子集，因为系统不能在其不具备能力的任务中执行角色。最后的“Side”包简单地表示系统在该任务中属于哪一方。以这种方式应用构型标注允许实现图例和查询表，这对于比示例模型更复杂的任务很有用。这里未包括这些内容，因为在文献综述中未发现关于查询使用的创新内容，除强调在“Hypermodeling and SAIC Profile”中建议使用外。此外，关于模型中元链（metachaining）和导航的必要背景足够复杂，无法在这篇本已不简短的论文中进行任何有用的简要总结。

3.2.3.8. 需求满足（Requirements Satisfaction）¶

对第 106 页中详述的需求部分，唯一的补充是根据“超建模（Hypermodeling）和 SAIC 配置文件”的建议，将需求关系限制为 <> 关系。在此示例中，所有值属性都已填写并与需求关联后，“IAD Mission”的 bdd 如下所示（注意：并非所有继承值都必须重新定义，仅需定义仿真所需的值）。

3.2.3.9. 仿真结果（Simulation Results）¶

当模型基本完成后，就可以开始回答客户最初提出的问题。回顾来看，从问题中提取的需求如上图 60 所示，具体如下：

燃料消耗小于每小时 100 千克；
运行成本小于每小时 2000 美元；
通信功能正常（链路裕度 > 0），比特错误率（Bit Error Rate）小于或等于 $1E^{-6}$；
探测距离超过威胁武器射程；
识别杀伤链执行过程中的任何操作瓶颈。

虽然与仿真框架配合运行将逻辑性地改变具体的仿真与分析流程，但 Cameo 本身具有基本的分析功能，可增强其仿真能力。在仿真配置图上可使用多种内置图表，并通过创建仿真配置块（Simulation Config Blocks）实现预设仿真配置与输出，方便快速切换。由于文献综述中未出现如此精度的仿真，因此这里仅进行基本分析。故仅需对仿真设置进行简要回顾。仿真生成了状态随时间变化图、搜索雷达接收功率的时间曲线图，以及捕获仿真过程中所有事件的任务序列图。此配置如图所示：

图 74 IAD 任务仿真初始求解（Initial Solving for IAD Mission Simulation）

此仿真配置产生了如图 75 至图 79 所示的结果。

图 75 IAD 任务仿真配置图（IAD Mission Simulation Configuration Diagram）

图 76 IAD 任务仿真中搜索雷达接收功率（Power Received by Search Radar）

图 77 IAD 任务仿真中威胁距离与交战距离（Threat Distance to Target and Engagement Range）

图 78 IAD 任务仿真中跟踪雷达接收功率（Power Received by Track Radar）

图 79 IAD 任务仿真状态汇总（State Summary for IAD Mission Simulation）

3.2.3.10. 仿真结果分析（Simulation Results Analysis）¶

总体来看，以上各图回答了最初提出的所有问题。逐项分析如下：

燃料消耗小于每小时 110 千克
图 74 显示燃料消耗为每小时 316 千克，说明该配置未满足需求。
此燃料消耗包含跟踪雷达持续供电的情况。如果系统具备名义上“零油耗待机状态”，并且启动时间足够短，可在发现目标前保持关闭，则燃料消耗可降至每小时 115 千克。虽然仍超过目标值，但这一数值更易通过改进发电机效率、略微降低搜索雷达功率或接受轻微的后勤负担增加来解决。对于当前威胁集，降低搜索雷达平均输出功率至 7600W 是可接受的折中，其探测距离仍可达 460 km（原为 470 km），远超威胁武器射程 200 km。主要假设是跟踪雷达的启动时间足够快以保持系统的有效性。尽管该分析可进一步展开，但在本次仿真中未予建模。
运行成本小于每小时 2000 美元
图 74 显示成本需求已满足，每小时成本为 1600 美元。
通信功能（链路裕度 > 0，BER ≤ $1E^{-6}$）
图 79 显示所有系统在整个仿真期间（初始化后）均满足该条件。
探测距离超过威胁武器射程
对比图 76 与图 77 可见，目标在进入武器射程前已被探测到，约在 2800 ms 时探测距离为 470 km。
即使降低搜索雷达功率，该条件仍成立。
识别杀伤链执行过程中的操作瓶颈
虽非直接仿真输出结果，但如图 80 所示，航迹处理成为瓶颈。
此瓶颈导致航迹数据处理出现显著延迟，影响后续数据融合或武器打击等应用。该延迟虽为简单约束，却反映了硬件计算时间与人工操作交互的总体效应。其为一个 $5-10$ 秒范围的随机变量，用于模拟人机交互的自然差异。不透明动作（opaque action）是此类分析的典型示例，极度依赖对系统模型的细致理解。若缺乏这种细节，本分析仅能揭示处理速率不足以匹配搜索雷达与跟踪雷达信息传入速率，需要进一步研究延迟原因及潜在的风险缓解措施或解决方案。

图 80 C2 节点中的航迹数据积压（左）及含处理延迟的航迹处理活动（右）

3.2.4. 结果应用（Application of Results）¶

上一节中讨论的结果可分为两类：操作性结果与技术性结果。这些结果为后续分析提供输入，用于回答系统级与作战级的不同问题。

传统兵棋推演与任务分析结果通常给出概率。例如，雷达性能以 $\mathrm{P}_{\text{detect}}$ 表示。该概率通常与位置和条件无关，并基于对传感器与目标的多项假设。这些假设对于系统设计者而言存在问题，因为它们在设计最基础层面引入假设，并将传播至最终产品。任务工程（Mission Engineering）以系统工程级精度提供操作层分析，但代价是需要更多迭代或采用蒙特卡罗（Monte Carlo）式分析以抵消 $P_{\text{detect}}$ 所带来的泛化降低。由此生成的数据可用于参数敏感性分析并指导系统需求制定。

对于操作层利益相关者而言，问题更关注能力而非“哪些系统参数是主导设计变量”。能力导向问题更多集中于诸如“所采用的战术、技术与程序是否存在问题？”或“此位置的防空阵地是否为最佳选项，是否应改用战斗空中巡逻（CAP）？”等。虽然高保真仿真环境能减少 $P_{\text{detect}}$ 假设带来的技术误差，但提升并非立竿见影。真正的益处体现在当从能力差距分析中派生系统构建时。

虽然任务工程结果的两种应用均超出任务工程本身的直接范围，但任何数据生成过程都必须理解这些数据的用途，确保其被准确、合乎伦理地使用，并据此调整生成过程。任务工程使两类分析都更精确，且更重要的是，使其在一个集成过程内实现技术关联。

3.2.5. 示例模型总结（Example Model Summary）¶

总体而言，基于该模型的仿真与结果虽属初步，却展示了通过简单模型即可回答与生存性、性能、保障性和可持续性相关的问题，同时揭示出诸如空中搜索雷达生存性受场地道路条件约束等新兴关系。识别此类涌现行为是以这种方式进行分析的最大优势之一。此外，通过该过程创建的要素现已可复用于其他任务，从而缩短后续分析的产出周期。

此外，通过使用 MATLAB 作为外部仿真引擎的代理，以及代理模型的概念，验证了将整个系统抽象近似并连接到外部仿真框架的可行性。虽然仍可进行更严格、更复杂的测试，但对于构建和定制基础方法论而言，该简单示例足以体现此处讨论的创新要点，主要包括：

证明任务建模与分析可基于文献综述中确定的基于模型的系统工程（MBSE）方法开展；
含嵌入式参数与行为的自引用关联块；
基于连接器状态的系统行为；
由仿真框架工具集派生的平台抽象，用于支持代理模型定义。

3.3. 后续工作（Future Work）¶

本方法与示例仅代表该基础方法论的众多可能实现方式之一。作者的意图是：此示例工作应被各客户基于自身需求进行扩展与定制，而非供应商盲目采用。正如在“当前 MBSE 方法论（Current MBSE Methodologies）”一节中所强调的，MBSE 作为一门学科覆盖广泛，如此广度使得单一统一方法对所有用例而言都不切实际。虽然本方法面向任务工程（Mission Engineering）进行了定制，但仅在集成防空（IAD）任务中得到验证，必然还需进一步定制。为说明这一点，以下列举了该方法未来需扩展的若干方向：

代理块定义（Surrogate block definition）
代理块的形式由仿真框架决定。由于本文未定义仿真框架，代理块的具体内容需由用户依据其任务集和当时可用工具确定。
与仿真框架的交互细节：尽管在 <> 层定义的操作旨在为未来集成提供挂钩，但模型如何与外部仿真器交互的细节取决于具体工具，因敏感性原因及其局限适用性，本论文未展开讨论。
此外，若需支持多个客户，可针对不同客户构建代理块层次结构，以适应变化的仿真框架，优化运行时性能与简化性。其概念如图 81 所示：由于示例任务仅涉及单一客户，且出于敏感性考虑，需求与数值均为任意设定，因此该概念未进一步探讨。

图 81 针对不同客户的同一系统多代理块（Multiple Surrogate Blocks of the Same System for Different Customers）

单向端口（One way ports）
当前关联块为自引用形式，适用于 TCP/IP 等双向通信。但对于盲发或单向协议（如 UDP），可考虑使用两种不同接口，以防止某一端产生冗余通信。然而，这会引发所有权问题：哪一端包含关联块？一种假设性解决方案是继承结构，即发送端与接收端均为包含关联块的公共接口的子类型。然而，由于示例任务中通信需双向（传感器向 C2 系统反馈信息，C2 系统对传感器实施控制），故未进一步探讨此概念，该双向控制关系符合 JPL 状态分析中的“控制系统/被控系统”概念。

这些示例表明，该方法论与许多其他方法一样，仍在不断演进。然而，值得进一步探讨的是自本文撰写以来该方法的显著演化。

3.3.1. 演进示例（Example of Growth）¶

本文方法论反复强调的一个主题是：任何方法论都可改进以更好地适应特定用例。实际上，在方法论最终确定与本文写作完成之间，已出现一次演进，本节即为该演化的实例。

本文所述方法的一个关键方面是使用关联块与连接器属性（见图 68 与图 69）。该方法最初用于支持两个实体之间的参数关系，而非行为。当关联块对连接器进行类型化时，已足以满足此用途，因此无需保留或创建连接器属性，尽管其作为连接器类型的可视化表示被生成和显示，因为该网络组件在现代网络化杀伤链中至关重要。然而，将该方法扩展至行为后，导致了图 67 中的决策行为，如下方摘录图 82 所示：

图 82 发送系统上的发送行为（Send Behavior on the Sending System）

虽然此方案能在仿真中正常运行，但它赋予发送平台现实中并不具备的知识，这是次优的。最终解决方案是更充分地利用连接器属性，通过在发送端与接收端之间插入中间层，如下图 83 所示：

图 83 改进的通信行为（Improved Communications Behavior）

此方法要求关联块除了类型化两个连接器外，还需具备由所属接口类型化的代理端口，如下图 84 所示：

图 84 改进的通信模型结构（Improved Communications Model Structure）

虽然此方法增加了关联块及 ibd 内部的元素，但它能使消息传递独立于发送端与接收端，从而避免修改平台行为，更准确地实现信息分层，同时保留前节所述关联块类型化连接器的优势。其结果如图 85 所示：

图 85 关联块交互仪表板视图（Dashboard View of an Association Block Interaction）

连接器状态仍由发送端与接收端的 functionalStateVariables 信息决定。新增的部分是一个状态机控制的动作，当状态激活时转发消息，非激活时不消耗信号令牌。这一设计还能利用 Cameo 的原生错误检查机制，当发送端生成而接收端未消费令牌时发出警告，从而简化调试。此处改进是在解决第 135 页最后一个要点（关于示例任务中假设通信双向性）时提出的。尽管该方法实现了双向性改进与信息分层，但通信连接器仍可能因仿真延迟而“被发送系统超越”，导致丢包。

本节独立列入“未来工作”部分，旨在强调该方法论仍有优化空间。此问题亦引出一个尚未在本文中直接讨论的辩题：可互操作模型 vs 通用标准化方法论。可互操作模型的支持者认为，确保所有人严格遵循统一方法论不现实，因此应着重建立模型间的轻量级接口以实现互操作。而标准化方法的支持者则主张，确保模型互操作性的最佳方式是统一风格指南并严格遵守。尽管本文并未明确支持其中一方，但此类持续演进表明，在当前学科成熟度下，一个静态的标准化模型并不现实。类比文本语言的风格指南：语言可被标准化定义，但并无普适的行业风格标准保证开箱即用的互操作性。这源于目标差异、专业水平、机构知识与建模环境的差异。这些因素共同阻碍了标准化建模方法的直接推广，使得重点仍需放在确保不同模型之间的接口层互操作性上（这正是 SAIC 与 NSWC Crane 并行开发代理模型的初衷）。

3.3.2. 未来发展的总结（Summary of Future Growth）¶

前几节概述了在示例模型开发过程中出现的一些问题。虽然由于已记录的原因，它们未被纳入本文档，但这些问题突显了此类示例模型对于文献分析的实用价值。通过对示例模型的推演，比单纯文字描述更能传达此处提出的方法论的基础性特征，使人更好地理解本文得出的结论应如何被使用——不是作为一个即插即用的解决方案，而是作为“模型化任务工程（Model Based Mission Engineering）”进一步探索的出发点。

除了方法论本身的改进外，还有若干由高保真仿真（high fidelity simulations）与详细系统模型相结合所带来的直接应用。本节将探讨其中两个方面：（1）支持人工智能（AI）开发的合成数据生成；（2）任务级多域优化与分析（Mission-level Multidomain Optimization and Analysis, MDAO）。

AI 训练的主要挑战之一是获得足够数量的数据以获得良好结果。即使是可公开研究的主题，也常因真实世界数据收集困难和成本高昂而受限，而兵棋推演（wargaming）领域的敏感性更使这一问题加剧。生成合成数据（synthetic data）是缓解这一数量问题的手段之一，然而合成数据本质上比真实数据“更不真实”。本文所述方法生成的合成数据可能优于现有来源。尽管它仍受限于生成模型精度所导致的不准确性，但对于非关键应用的训练数据集或作为设计工具而言，基于合成数据训练的机器学习辅助工具仍可能具有实用价值。尤其从设计视角来看，这些工具本身就会被使用，其潜在风险因此在设计环节已被接受。本文所述方法通过将任务级模型与权威系统模型直接关联，可减少生成函数中的假设层次，从而提高合成数据的准确性。

从设计视角出发，将设计级的多域分析优化（MDAO）工具与任务级分析和指标相链接，是该工作流程的有益扩展。虽然目前已有如 AGI Model Center 这类可将 MBSE 模型与 CAD 工具集成的工具，但文献中尚未验证将其与任务级分析直接连接的可行性。本文讨论的方法论之外的下一步工作，正是为任务工程与兵棋推演建立类似的集成性能仿真框架（performance simulation framework）。这样的框架将直接建立在本文奠定的基础上，在示例任务使用 MATLAB 进行交互的地方实现接口连接。

本文讨论的改进与应用只是潜在方向中的一小部分。这些建议符合本文定义的方法论的基础性质。未来工作及该方法论的修改，其主要驱动力应始终以客户需求为中心，同时保持此处讨论的基本原则。

4. 总结与结论（Summary and Conclusions）¶

本论文提出，支持“基于模型的任务工程（Model Based Mission Engineering, MBME）”的方法论可以从“基于模型的系统工程（Model Based Systems Engineering, MBSE）”的发展中演化而来。为验证这一假设，本文对当前任务工程/兵棋推演指导文件与 MBSE 方法论进行了文献综述。任务工程与兵棋推演综述得出了以下结论：

未来的任务将是跨域（cross-domain）的，其复杂性和对技术的依赖性将显著增加（参见技术任务优先级部分）。
基础分析问题仍围绕成本、进度与性能展开，并将在更复杂的范式下保持相关性（用于确定关键性能参数 KPPs）。
支撑这些基础分析问题的五个关键性能参数（KPP）包括：
Force Protection（兵力防护）——关注人员安全；
System Survivability（系统生存性）——关注提升系统自身韧性；
Sustainment（保障性）——关注系统在适当层级上的可维护与可修复；
Energy（能源）——认识到现代战争依赖燃料，需考虑能源使用与供给；
Net-Ready Performance（网络就绪性能）——强调系统互操作性的重要性，因为现代联合作战体系中系统间的互通在设计与建造阶段即已决定。
文献中已有系统工程（Systems Engineering）支撑任务分析（Mission Analysis）的先例。

基于任务工程与系统工程间已存在的联系，本文进一步探讨现有 MBSE 方法论的适用性。通过综述过程，识别出以下关键概念：

系统建模语言（SysML, Systems Modeling Language）是 MBSE 的主导语言；
由于语言的灵活性与应用广度，目前尚无行业标准的 MBSE 方法学。这种灵活性与广泛性表明，将 MBSE 应用于任务工程并非语言的误用，因为其并未过度专化于某一特定用例；
已有部分 MBSE 模型中包含任务（Mission）相关内容（例如文献 [76]、[98]、[116]），但仍以系统为中心。这进一步支持了 MBSE 方法对任务工程的适用性；
对各类 MBSE 方法论的回顾得出了以下结论：
存在支持任务工程目标的 MBSE 总体流程（如 IBM Rational Telelogic Harmony、Onion Model）；
支持面向对象结构的功能分解方法，以反映由平台支撑的任务功能配置（如 INCOSE 面向对象系统工程方法 OOSEM、IBM Rational Telelogic Harmony、JPL 状态分析）；
支持通过约束块与不透明动作实现的外部仿真与本地分析集成（如 Vitech 的 CORE、Hypermodeling 与 SAIC Profile）；
使用代理块（Surrogate Blocks）以单一黑箱形式表示复杂系统模型（如 Hypermodeling、SAIC Profile、系统之系统接口建模方法 System of System Interface Modeling Method）；
不同类别的值属性及其用途分类（JPL 状态分析）；
使用元链导航（Metachains Navigation）改善模型交互体验与客户可视化呈现（Hypermodeling 与 SAIC Profile）；
附加验证配置文件的效用与局限性（Hypermodeling 与 SAIC Profile）。

综合上述两个概念体系后，本文在“MBSE 支撑任务工程”一章中得出结论：任务工程与系统工程通过“系统之系统工程（System of Systems Engineering）”这一概念密切相关。二者的主要区别在于视角与关注重点——是聚焦于任务功能与分析，还是聚焦于系统性能与行为。两种视角可使用相同的工具与方法，仅在高低保真度层次上有所区别。此外，本文论证了两者可沿相同的系统复杂性轴（从组件层到任务层）加以描述（见图 46）。

在正式确立任务工程与系统工程之间的联系、明确任务工程相关的 MBSE 方法论与任务分析目标后，下一步是应用。通过对示例任务的建模，本文突出展示了特定方法论要素及其互操作性，并揭示了贯穿其间的“连接组织”。若无这些衔接要素，综述将是不完整的；而其存在证明了本文提出的方法论确实可以回答现实的操作性问题。

通过文献综述、综合分析与概念验证应用，本文高度确信：MBSE 的进展可显著促进任务工程（Mission Engineering）的应用，后者可视为系统之系统工程的一个子集。此结论为任务工程师在优化与发展其支撑作战能力的过程中，提供了更广阔的开发视野与知识支撑。

5. 附录 A：参考文献¶

[1] "F-35 Joint Strike Fighter: Cost Growth and Schedule Delays Continue | U.S. GAO." https://www.gao.gov/products/gao-22-105128 (accessed Aug. 18, 2022). [2] "Two Cost Studies Pertaining to the F-15 Aircraft Program | U.S. GAO." https://www.gao.gov/products/b-168664-0 (accessed Aug. 18, 2022). [3] "F-35 JOINT STRIKE FIGHTER Cost Growth and Schedule Delays Continue Report to Congressional Committees United States Government Accountability Office," 2022. [4] "Navy Declares Initial Operational Capability for F-35C Joint Strike Fighter - USNI News." https://news.usni.org/2019/02/28/navy-declares-initial-operational-capability-for-f-35c-joint-strike-fighter (accessed Aug. 18, 2022). [5] "Model-based systems engineering: Revolution or evolution?," 2011. [6] "(PDF) Evolution of Model-Based System Engineering Methodologies for the Design of Space Systems in the Advanced Stages of the Project (Phases B-C)." https://www.researchgate.net/publication/280238984_Evolution_of_ModelBased_System_Engineering_Methodologies_for_the_Design_of_Space_Systems_in_the_Advan ced_Stages_of_the_Project_Phases_B-C (accessed Aug. 18, 2022). [7] Necessary DoD Range Capabilities to Ensure Operational Superiority of U.S. Defense Systems. Washington, D.C.: National Academies Press, 2021. doi: 10.17226/26181. [8] P. D. Clive, J. A. Johnson, M. J. Moss, J. M. Zeh, B. M. Birkmire, and D. D. Hodson, "Advanced Framework for Simulation, Integration and Modeling (AFSIM)". [9] Odusda and Tsse, "Systems Engineering Guide for Systems of Systems, V 1.0," 2008. [10] "Engineering of Defense Systems Guidebook," 2022, Accessed: Apr. 17, 2022. [Online]. Available: https://ac.cto.mil/engineering [11] USD (AT\&L), "DoD Instruction 5000.02, January 7, 2015," 2015. [12] R. J. Torok and C. A. Whitcomb, "NAVAL POSTGRADUATE SCHOOL MONTEREY, CALIFORNIA THESIS USING MODEL-BASED SYSTEMS ENGINEERING METHODS TO CAPTURE A DEPARTMENT OF DEFENSE ACQUISITION LIFE CYCLE," 2021. [13] D. Walden, G. Roedler, K. Forsberg, R. Douglas Hamelin, and T. Shortell, "INCOSE Systems Engineering Handbook 4e 2015 07," 2015. [14] H. Sillitto et al., "Systems Engineering and System Definitions," 2019. [15] "Final Report of the Model Based Engineering (MBE) Subcommittee NDIA Systems Engineering Division M\&S Committee," 2011. [16] L. Delligatti, "Business Case for Model-Based Systems Engineering (MBSE) with SysML Metrics from an Aerospace Industry Case Study". [17] G. Bennett, "The Identification of Metrics to Support a Model Based Systems Engineering Approach to Requirements Engineering and Architectural Design". [18] Dod, "DoD Electromagnetic Spectrum Superiority Strategy 2020," 2020. [19] "DoD CIO Says Spectrum May Become Warfighting Domain - Breaking Defense." https://breakingdefense.com/2015/12/dod-cio-says-spectrum-may-become-warfightingdomain/ (accessed Aug. 18, 2022). [20] United States Joint Staff Joint Force Development J7, "Cross Domain Synergy in Joint Operations," 2016. [21] Office of the Under Secretary of Defense for Research and Engineering, "Mission Engineering Guide," Washington, DC, 2020. Accessed: Jan. 27, 2021. [Online]. Available: https://ac.cto.mil/engineering [22] M. Blackburn, "Transforming Systems Engineering through Model-Centric Engineering TR-111," 2018. [23] "SERC-SR-2020-001-Benchmarking-the-Benefits-and-Current-Maturity-of-MBSE-3-2020". [24] M. B. Caffrey, "On Wargaming How Wargames Have Shaped History and How They May Shape the Future," 2019. [25] C. and D. C. UK Ministry of Defense - Development, Wargaming Handbook Development, Concepts and Doctrine Centre. Wiltshire: Ministry of Defence Shrivenham, 2017. [26] M. John and M. Brennan, "Assessment of SIMBAT for Naval Operations," 2006. [27] M. Kofman, K. Migacheva, B. Nichiporuk, A. Radin, O. Tkacheva, and J. Oberholtzer, "Lessons from Russia's Operations in Crimea and Eastern Ukraine," 2014, Accessed: Apr. 03, 2022. [Online]. Available: www.rand.org/giving/contribute [28] "Azerbaijan and Armenia: The Nagorno-Karabakh Conflict," 2021, Accessed: Apr. 03, 2022. [Online]. Available: https://crsreports.congress.gov [29] K. Lakkaraju, J. Reinhardt, J. Letchford, J. Whetzel, B. L. Goldblum, and A. W. Reddie, "Experimental Wargames to Address the Complexity-Scarcity Gap," May 2020. doi: 10.22360/SpringSim.2020.ANSS.010. [30] "Simulator Types - AcqNotes." https://acqnotes.com/acqnote/tasks/simulator-types (accessed Jun. 01, 2022). [31] "NSWC Crane spearheads nearly a decade of Electronic Warfare Live Virtual Constructive testing for Navy > Naval Sea Systems Command > News." https://www.navsea.navy.mil/Media/News/Article/2312378/nswc-crane-spearheads-nearly-a-decade-of-electronic-warfare-live-virtual-constr/ (accessed Jun. 09, 2022). [32] S. Gallant and C. Gaughan, "SYSTEMS ENGINEERING FOR DISTRIBUTED LIVE, VIRTUAL, AND CONSTRUCTIVE (LVC) SIMULATION". [33] "UAS-NAS Live Virtual Constructive Distributed Environment (LVC) Software Design Description," 2015. [34] C. L. Haase, "AFIT Scholar Theses and Dissertations Student Graduate Works Tailoring the Statistical Experimental Design Process for LVC Experiments," 2011, Accessed: Jun. 09, 2022. [Online]. Available: https://scholar.afit.edu/etd/1494 [35] E. H. Page, "Modeling and Simulation, Experimentation, and Wargaming-Assessing a Common Landscape". [36] R. Richbourg Robert Lutz, "Live Virtual Constructive Architecture Roadmap (LVCAR) Comparative Analysis of the Architectures," 2008. [37] C. Meirina, G. M. Levchuk, S. Ruan, K. R. Pattipati, and R. L. Popp, "Normative framework and computational models for simulating and assessing command and control processes," Simulation Modelling Practice and Theory, vol. 14, no. 4, pp. 454-479, May 2006, doi: 10.1016/j.simpat.2005.09.005. [38] P.-G. Taranti, R. Choren, C. Lucena, M. Luck, and P. McBurney, "INTEROPERATING WARGAME SIMULATIONS," in XVIII Simpósio de Pesquisa Operacional \& Logística da Marinha, Aug. 2016, pp. 751-764. doi: 10.5151/marine-spolm2015-140939. [39] Rajarishi Sinha, Vei-Chung Liang, C. J. J Paredis, and P. K. Khosla Mem ASME, "Modeling and Simulation Methods for Design of Engineering Systems," ASME, vol. 1, pp. 84-91, 2001, doi: 10.1115/1.1344877. [40] Office of Secretary of Defense, "Defense Acquisition Guidebook," 2013, Accessed: Jun. 01, 2022. [Online]. Available: https://dag.dau.mil [41] Office of the Under Secretary of Defense for Acquisition and Sustainment, "DOD INSTRUCTION 5000.85 MAJOR CAPABILITY ACQUISITION," 2021. Accessed: Apr. 17, 2022. [Online]. Available: https://www.esd.whs.mil/DD/. [42] J-8, "MANUAL FOR THE OPERATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM," 2018. [43] "USD(R\&E) Top 10 Technology Focus Areas | AiDA." https://aida.mitre.org/top-10-technologyareas/ (accessed Mar. 29, 2022). [44] "2018 National Defense Strategy of The United States of America," 2018. https://dod.defense.gov/Portals/1/Documents/pubs/2018-National-Defense-StrategySummary.pdf (accessed Mar. 29, 2022). [45] "modernization-priorities - DoD Research \& Engineering, OUSD(R\&E)." https://www.cto.mil/modernization-priorities/ (accessed Mar. 29, 2022). [46] "Autonomous Systems Artificial Intelligence and Safeguards. (Conference) | OSTI.GOV." https://www.osti.gov/biblio/1561151 (accessed Jun. 01, 2022). [47] Smith and Chris HR, "CHARTER OF THE JOINT REQUIREMENTS OVERSIGHT COUNCIL AND IMPLEMENTATION OF THE JOINT CAPABILITIES INTEGRATION AND DEVELOPMENT SYSTEM UNCLASSIFIED UNCLASSIFIED," 2021. [48] "STATE OF THE DISCIPLINE 2019 Current and future state of Systems Engineering." [49] "nasa_systems_engineering_handbook_0". [50] M. D. Watson, B. L. Mesmer, P. A. Farrington, and G. C. Marshall, "Engineering Elegant Systems: Theory of Systems Engineering," 2020. [Online]. Available: http://www.sti.nasa.gov [51] "SYSTEMS ENGINEERING FUNDAMENTALS SUPPLEMENTARY TEXT PREPARED BY THE DEFENSE ACQUISITION UNIVERSITY PRESS FORT BELVOIR, VIRGINIA 22060-5565," 2001. [52] "SE Brainbook Home." https://www.dau.edu/tools/se-brainbook (accessed Jun. 12, 2022). [53] D. Seal, D. Farr, and J. Hatakeyama, "The System Engineering Vee-is it Still Relevant in the Digital Age?," 2018, Accessed: Jun. 12, 2022. [Online]. Available: https://ops.fhwa.dot.gov/publications/seitsguide/section3.htm [54] W. K. Vaneman, "The system of systems engineering and integration «vee» model," 10th Annual International Systems Conference, SysCon 2016 - Proceedings, Jun. 2016, doi: 10.1109/SYSCON.2016.7490599. [55] "Space Missile Command Systems Engineering Primer \& Handbook -Concepts, Processes, and Techniques," 2005. [56] "SYSTEMS ENGINEERING FUNDAMENTALS SUPPLEMENTARY TEXT PREPARED BY THE DEFENSE ACQUISITION UNIVERSITY PRESS FORT BELVOIR, VIRGINIA 22060-5565," 2001. [57] N. Mohammed, A. Munassar, and A. Govardhan, "A Comparison Between Five Models Of Software Engineering," IJCSI International Journal of Computer Science Issues, vol. 7, no. 5, 2010, [Online]. Available: www.IJCSI.org [58] D. F. Beam, "SYSTEMS ENGINEERING AND INTEGRATION AS A FOUNDATION FOR MISSION ENGINEERING," NPS, MONTEREY, 2015. [59] P. Beery and E. Paulo, "Application of Model-Based Systems Engineering Concepts to Support Mission Engineering," Systems, vol. 7, no. 3, p. 44, 2019, doi: 10.3390/systems7030044. [60] E. Paulo and P. Beery, "Application of Model-Based Systems Engineering Concepts to Support Mission Engineering," Calhoun: The NPS Institutional Archive, 2019, doi: 10.3390/systems7030044. [61] M. D. Griffin, "HOW DO WE FIX SYSTEM ENGINEERING?". [62] J. A. Estefan, "Survey of Model-Based Systems Engineering (MBSE) Methodologies," 2007. [63] C. Gedo, "Model Based Systems Engineering and Systems Modeling Language DoDAF Plenary," 2012. [64] M. Philomena, P. " Zimmerman, and N. M\&s, "MBSE in the Department of Defense," 2015. [65] Lenny Delligatti, SysML Distilled. Crawfordsville, Indiana: Pearson Education Inc, 2014. [66] P. White, "Welcome to SysML, the Language of MBSE," 2019. [67] "SysML Specifications - Current Version: OMG SysML 1.6," 2019. Accessed: Jun. 15, 2022. [Online]. Available: https://sysml.org/sysml-specs/ [68] Omg, "An OMG Systems Modeling Language TM Publication OMG Systems Modeling Language (OMG SysML ${ }^{\text {TM }}$ )," 2019. [Online]. Available: https://www.omg.org/spec/SysML/20181001/sysmldi.xmi [69] D. C. Sales and L. B. Becker, "Systematic literature review of system engineering design methods," in Brazilian Symposium on Computing System Engineering, SBESC, Jul. 2018, vol. 2018-November, pp. 213-218. doi: 10.1109/SBESC.2018.00040. [70] INCOSE, "New Standards for System of Systems Engineering (SoS)." [Online]. Available: https://www.iso.org/store.html [71] S. Wolny, A. Mazak, C. Carpella, V. Geist, and M. Wimmer, "Thirteen years of SysML: a systematic mapping study," Software and Systems Modeling, vol. 19, no. 1, pp. 111-169, Jan. 2020, doi: 10.1007/s10270-019-00735-y. [72] S. et al Friedenthal, A Practical Guide to SysML : The Systems Modeling Language, 3rd ed. Elsevier Science \& Technology, 2014. Accessed: Jun. 15, 2022. [Online]. Available: https://ebookcentral.proquest.com/lib/cranfield/reader.action?docID=1823236 [73] "Air Force Doctrine Publication (AFDP) 3-05 Special Operations," 2020. [74] Z. Scott and D. Long, "One Model, Many Interests, Many Views," 2017. Accessed: Jun. 26, 2022. [Online]. Available: https://vitechcorpwebdownload.s3.amazonaws.com/white_papers/OneModel.pdf [75] L. Delligatti, "Elements of definition." [76] P. Pearce and S. Friedenthal, "A Practical Approach For Modelling Submarine Subsystem Architecture In SysML," 2013. [77] D. A. Long and Zane. Scott, A primer for model-based systems engineering. Vitech Co, 2011. [78] P. T. Beery, "A model-based systems engineering methodology for employing architecture in system analysis: developing simulation models using systems modeling language products to link architecture and analysis," 2016. [Online]. Available: http://hdl.handle.net/10945/49363 [79] J. A. Estefan, "Survey of Model-Based Systems Engineering ( MBSE ) Methodologies," Jet Propulsion, 2008. [80] Michael J. Vinarcik, "Hypermodeling: A Profile for Teaching SysML Modeling American Society for Engineering Education." Accessed: Jan. 28, 2021. [Online]. Available: https://www.asee.org/public/conferences/140/papers/26050/view [81] B. H. Rao, K. Padmaja, and P. Gurulingam, "A Brief View of Model Based Systems Engineering Methodologies," International Journal of Engineering Trends and Technology (IJETT), Accessed: Jun. 23, 2022. [Online]. Available: http://www.ijettjournal.org [82] J. Moschler, "NAVAIR Systems Engineering Transformation". [83] "AFSIM: The Air Force Research Laboratory's Approach to Making M\&S Ubiquitous in the Weapon System Concept Development Process - CSIAC." https://csiac.org/articles/afsim-the-air-force-research-laboratorys-approach-to-making-ms-ubiquitous-in-the-weapon-system-concept-development-process/ (accessed Jun. 23, 2022). [84] S. Friedenthal, A. Meilich, and H. Lykins, "Adapting UML for an object oriented systems engineering method (OOSEM) MBSE and SysML View project conceptual modeling View project Adapting UML for an Object Oriented Systems Engineering Method (OOSEM)," 2000, doi: 10.1002/j.2334-5837.2000.tb00416.x. [85] P. Pearce and M. Hause, "ISO-15288, OOSEM and Model-Based Submarine Design". [86] S. Friedenthal, L. Izumi, and A. Meilich, "Object-oriented systems engineering method (OOSEM) applied to joint force projection (JFP), a lockheed martin integrating concept (LMIC)," 17th Annual International Symposium of the International Council on Systems Engineering, INCOSE 2007 - Systems Engineering: Key to Intelligent Enterprises, vol. 1, pp. 176-196, 2007, doi: 10.1002/J.2334-5837.2007.TB02961.X. [87] "Object-Oriented SE Method." https://www.incose.org/incose-member-resources/working-groups/transformational/object-oriented-se-method (accessed Jun. 23, 2022). [88] A. E. Trujillo, O. L. de Weck, and A. M. Madni, "An mbse approach supporting technical inheritance and design reuse decisions," 2020. doi: 10.2514/6.2020-4167. [89] H.-P. Hofman, "Deskbook Release 4.1," 2013. [90] S. R. Childers and J. E. Long, "A CONCURRENT METHODOLOGY FOR THE SYSTEM ENGINEERING DESIGN PROCESS," INCOSE International Symposium, vol. 4, no. 1, pp. 226-231, Aug. 1994, doi: 10.1002/J.2334-5837.1994.TB01709.X. [91] S. R. Childers and J. E. Long, "A CONCURRENT METHODOLOGY FOR THE SYSTEM ENGINEERING DESIGN PROCESS," INCOSE International Symposium, vol. 4, no. 1, pp. 226-231, Aug. 1994, doi: 10.1002/j.2334-5837.1994.tb01709.x. [92] "Systems Thinking: Schemas, Metamodels, and MBSE - Community.Vitechcorp.com." https://community.vitechcorp.com/systems-thinking-schemas-metamodels-and-mbse/ (accessed Jun. 26, 2022). [93] P. Graignic, T. Vosgien, M. Jankovic, V. Tuloup, J. Berquet, and N. Troussier, "Complex system simulation: Proposition of a MBSE framework for design-analysis integration," 2013. doi: 10.1016/j.procs.2013.01.007. [94] S. Mittal, U. Durak, and T. Ören, Simulation Foundations, Methods and Applications Guide to Simulation-Based Disciplines Advancing Our Computational Future. Springer, 2017. Accessed: Mar. 02, 2021. [Online]. Available: http://www.springer.com/series/10128 [95] "vitech mbse domains," OMG MBSE Wiki, Oct. 30, 2010. https://www.omgwiki.org/MBSE/lib/exe/detail.php?id=mbse\%3Avitechmbse\&media=mbse:vit ech_mbse_domains.jpg (accessed Jun. 29, 2022). [96] S. H. Dam and J. D. Willis, "Defensible C4ISR Architectures Require the Application of Good System Engineering Practice," 2002, Accessed: Jun. 29, 2022. [Online]. Available: www.spec1.com [97] J. Holt and S. Perry, SysML for Systems Engineering, 3rd ed. London: The Institution of Engineering and Technology, 2018. Accessed: Jun. 15, 2022. [Online]. Available: https://app.knovel.com/web/view/khtml/show.v/rcid:kpSMLSEAOL/cid:kt011W2KU1/viewerType:khtml/root_slug:sysml-systems-engineering/url_slug:introduction-sysml-systems?\&b-toc-cid=kpSMLSEAOL\&b-toc-root-slug=sysml-systems-engineering\&b-toc-title=SysML\%20for\%20Systems\%20Engineering\%20-\%20A\%20Model-Based\%20Approach\%20\%283rd\%20Edition\%29\&b-toc-url-slug=part-iintroduction\&kpromoter=marc\&page=12\&view=collapsed\&zoom=1 [98] D. A. Wagner, M. B. Bennett, R. Karban, N. Rouquette, S. Jenkins, and M. Ingham, "An ontology for state analysis: Formalizing the mapping to SysML," IEEE Aerospace Conference Proceedings, 2012, doi: 10.1109/AERO.2012.6187335. [99] M. Bennett, D. Dvorak, J. Hutcherson, M. Ingham, R. Rasmussen, and D. Wagner, "An architectural pattern for goal-based control," IEEE Aerospace Conference Proceedings, 2008, doi: 10.1109/AERO.2008.4526594. [100] W. Eric Marsh and W. Eric, "An Initial Methodology For The Definition And Implementation Of An Initial Methodology For The Definition And Implementation Of Unmanned Aerial Vehicle Agent Behaviors Unmanned Aerial Vehicle Agent Behaviors Repository Citation Repository Citation", Accessed: Jun. 29, 2022. [Online]. Available: https://corescholar.libraries.wright.edu/etd_all://corescholar.libraries.wright.edu/etd_all/85 [101] T. R. Hernandez, "AFIT Scholar AFIT Scholar Theses and Dissertations Student Graduate Works Modeling Situation Awareness in a UAV Scenario Using SysML Modeling Situation Awareness in a UAV Scenario Using SysML", Accessed: Jun. 29, 2022. [Online]. Available: https://scholar.afit.edu/etd/5039 [102] A. J. Spriggs and S. E. Hooper, "Fusion: A Framework for Human Interaction with FlexibleAdaptive Automation Across Multiple Unmanned Systems," pp. 464-469, 2015, Accessed: Jun. 29, 2022. [Online]. Available: https://corescholar.libraries.wright.edu/isap_2015https://corescholar.libraries.wright.edu/isap_2015/28 [103] P. M. Shames, M. A. Sarrel, and S. A. Friedenthal, "Modeling systems-of-systems interfaces with SysML," 2016, doi: 10.2514/6.2016-2500. [104] M. Vinarcik, "The NeMO Orbiter: A Demonstration Hypermodel," 2018. Accessed: Jun. 29, 2022. [Online]. Available: https://www.academia.edu/37211953/The_NeMO_Orbiter_A_Demonstration_Hypermodel [105] R. A. Noguchi, "Recommended Best Practices based on MBSE Pilot Projects," Jun. 2019. [106] "(PDF) A Mars Octet: Lessons Learned from Federating Eight Student Models in a SysML Class | Michael Vinarcik - Academia.edu." https://www.academia.edu/67778096/A_Mars_Octet_Lessons_Learned_from_Federating_Eigh t_Student_Models_in_a_SysML_Class (accessed Jun. 29, 2022). [107] "SAIC | Digital Engineering Validation Tool." https://www.saic.com/digital-engineering-validation-tool (accessed Jun. 29, 2022). [108] M. Hause, G. Bleakley, and A. Morkevicius, "Technology Update on the Unified Architecture Framework (UAF)," INCOSE International Symposium, vol. 26, no. 1, pp. 1145-1160, Jul. 2016, doi: 10.1002/J.2334-5837.2016.00217.X. [109] W. Okon, "DoD Architectures and Systems Engineering Integration ," 2012. [110] M. C. Hause, "Elemental Links Transitioning UPDM to the Unified Architecture Framework," 2016. [111] Omg, "Enterprise Architecture Guide for UAF (Informative) Appendix C," 2021. [Online]. Available: https://www.omg.org/spec/UAF/20211201/UAF.xmi [112] "Unified Architecture Framework (UAF) Traceability (Informative) Appendix A," 2021. [Online]. Available: https://www.omg.org/spec/UAF/20211201/UAF.xmi [113] J. M. House and U. S. Army, "Toward Combined Arms Warfare:-A Survey of 20th~Century Tactics, Doctrine, and Organization Toward Combined Arms Warfare: A Survey of 20th-Century Tactics, Doctrine, and Organization," 1984. [114] Headquarters Department of the Army, "ADP 3-0 Operations," 2017. Accessed: Aug. 21, 2022. [Online]. Available: https://armypubs.army.mil/ [115] "RT-171: Mission Engineering Competencies," 2018. [116] S. C. Spangelo et al., "Model based systems engineering (MBSE) applied to Radio Aurora Explorer (RAX) CubeSat mission operational scenarios," Jan. 2013. doi: 10.1109/AERO.2013.6496894. [117] "Exponential Growth of System Complexity." https://savi.avsi.aero/about-savi/savi-motivation/exponential-system-complexity/ (accessed Aug. 18, 2022). [118] Naval Surface Warfare Center Crane, "Interoperability of Digital Mission Engineering (DME) Software Suites" https://www.navsea.navy.mil/Portals/103/Documents/Exhibits/ SAS2021/SAS2021-Interoperability_of_DM_NSWC_Crane.pdf, 2021 [119] DASN RDTE, "United States Navy \& Marine Corps Digital systems Engineering Transformation Strategy", https://nps.edu/documents/112507827/0/2020+Dist+A+DON+Digital+Sys+ Eng+Transformation+Strategy+2+Jun+2020.pdf/, 2020 [120] Miller, J. "A State-Based Model for Validating Autonomous Munition Behaviors", https://scholar.afit.edu/cgi/viewcontent.cgi?article=5954\&context=etd, 2021