中文版《复杂指挥与控制系统的基于模型的系统工程流程》

由于问题和解决方案的复杂性不断增加，复杂和社会技术系统的系统工程变得越来越困难。这导致了基于模型的系统工程（MBSE）的发展，它在软件工具的架构框架和建模语言的支持下应用建模。在需求分析和概念开发阶段，建模被应用于捕捉和表示系统的利益相关者的心理模型。该软件工具能够通过各种图表和视图在数据库中捕获模型信息。这种以数据为中心的方法确保了定义的模型元素及其关系的一致性和可追溯性。由于指挥和控制（C2）系统可以被看作是复杂的社会技术系统，MBSE应该有助于捕捉需求以支持概念解决方案的开发。本文介绍的MBSE方法有助于捕捉C2系统的需求，以及识别主要的逻辑块元素和它们所需的功能。这种方法通过开发适合特种作战的复杂作战环境的概念C2系统解决方案得到了证明。

1 引言

系统工程的基本目标是通过使系统的存在来解决问题（Stensson 2010，Walden等人，2015）。系统方法，通过系统思考，旨在理解整体背景下的部分，同时与环境互动并适应环境。系统工程由跨学科活动组成，以确保利益相关者的需求能以低成本和及时的方式得到满足。然而，今天的问题往往是复杂和不明确的，其影响范围超过了所关注的系统。

从本质上讲，系统工程过程是一种发现、学习和持续改进的迭代方法，以获得对需求和突发特性的洞察力（Walden等人，2015）。系统工程过程的输入是来自客户或利益相关者的需求，必须对其进行分析，以发现定义解决方案系统的目的、目标和高级功能的需求（Buede 2000, Ramos等人2012, Walden等人2015, Oliver等人2009）。从最初的高层次需求中定义操作环境和预期场景，以得出系统所需的角色、任务和功能（Stanton 等人，2012）。

Holt & Perry (2008)列出了系统工程的三害：复杂性、沟通和理解。系统的复杂程度取决于系统元素的数量和它们的互动。对问题和用户需求的不正确理解导致了不准确的需求和系统工程的不正确应用。工程师、开发团队和利益相关者之间的沟通问题导致了对需求和相关模型含义的解释。设计团队和制造团队之间的沟通不畅，会进一步加剧这种情况。对系统工程产生能够在复杂环境中有效运行的系统的要求是不断增加的。建模是解决复杂问题的一种方式，并能使人们有效地理解和沟通。

基于模型的系统工程（MBSE）作为一种方法，提供了一个由过程和支持工具组成的解决方案，以解决复杂性问题。各种形式的模型和结构可以用来捕捉和表示有关问题的信息和知识。一个合适的模型，从利益相关者的心理模型中衍生出来，用来吸收和解释重要的信息（De Weck等人，2011，Sterman 1994）。

在系统工程中，模型是通过系统的原理图和网络图来构建的。建模可以通过理解系统整体和部分之间的关系来帮助系统设计，从而得出突发属性（Buede 2000, Ramos等人 2012, Maria 1997, Ramos等人 2011）。模型也往往比基于文本的系统工程文件更有助于发展系统概念和需求，因为它们支持对问题的知识进行实验，并发展对不同解决方案的影响的理解（Estefan 2007）。

MBSE采用了建模语言，如系统建模语言（SysML）或统一建模语言（UML）。该语言利用图形符号，用相关的参数、属性和限定信息来加强。这些语言被用来通过图表对复杂的系统及其架构进行建模，这些图表通过各种一致的观点捕捉、分析和指定系统的行为、结构、要求、关系和能力。模型的不同观点可用于实验问题的知识，并发展对不同解决方案的影响的理解（Ramos等人，2012；Buede，2000；Oosthuizen和Venter，2016）。在规划中采用MBSE的其他优势包括管理问题的复杂性、重用信息元素和支持系统性思维（Ramos等人，2012，Walden等人，2015）。

本文报告了通过实施MBSE过程对C2系统进行概念建模的实践经验。首先，讨论了系统工程和建模文献，以定义MBSE流程，然后将其与实践经验联系起来。该过程通过为特种作战开发一个概念性的C2解决方案来展示。与常规部队相比，特种作战往往在更复杂的环境中运作，有着独特的要求。

2 指挥与控制概念

C2是一个统称，涉及军事行动的指挥和控制的多个方面。指挥被定义为赋予或授权给武装部队的个人指挥、协调和控制军事力量的权力（Brown 1996, MoD 2017）。这代表了人类意愿的创造性表达，以阐明和传递完成任务所需的意图。指挥链网络描述了授权的流动，其任务是产生意图。指挥权来自拥有最多任务状态信息的个人（Young 2017）。

"控制 "被定义为指挥官对下属组织的部分活动所行使的权力，其中包含了执行命令或指令的责任。控制包括通过设定边界、管理资源和调整行动以实现指挥官意图的结构和流程来管理风险。控制的目的是确保通过调整所需的活动来实现既定意图（Brown 1996, Young 2017）。

C2系统的目的是指导、调整和协调部队在多个领域的意图和活动。C2系统必须灵活适应，以满足不断变化的环境、背景和任务的要求（Oosthuizen and Pretorius 2013, MoD 2017）。

C2能力被进一步定义为设计和执行联合行动的动态和适应性（复杂）社会技术系统（国防部2017）。复杂的社会技术系统包括行为、工具和技术，由人、结构、技术和流程之间的相互作用促成。C2为个人和组织提供了重点，以整合和最大限度地利用他们的资源和活动来实现预期的结果（国防部2017）。具体的C2解决方案的特点是环境和任务类型所需的网络分权程度。具体的C2解决方案的适当性受到以下三个环境变量的影响（Young 2017）：

1.环境的变化率。不寻常的任务类型导致了任务的不确定性。同时，任务期间较快的变化率需要更大程度的情况意识分散和更新率。

2.要素的连接程度。一个环境中的多个独立元素比一个具有多个高度连接元素的复杂环境更容易分析和理解。复杂环境中的任务更难分解，需要更大程度的控制权下放。

3.利益相关者的利益程度。利益相关者对活动的开展施加标准、约束或期望。利益的程度与指挥所需的集中化程度呈反向关系。

所选择的C2方法必须适应所应用的作战环境。当代特种作战的作战环境是复杂的。该环境的特点是一个全球性的系统，由许多相互作用的变量组成，这些变量造成了相互交织的国家、政治、经济、社会、精神、文化和军事利益、挑战和威胁。影响特种作战复杂环境的主要因素包括以下几个方面（Ott 2002, Madden et al. 2016, Johansen 2015, Votel 2016）：

1.全球化。由技术进步（互联网、移动电话、卫星通信）形成的全球化，成倍地提高了变化、创新和商业的速度。技术允许在全世界范围内即时传输信息。国际恐怖组织可以从偏远地区有效运作，同时从全球任何地方得到支持（资金、培训和招募）。重大事件发生时，媒体也会在全球范围内进行近乎实时的报道。

2.城市化。越来越多的世界人口迁移到城市地区。交战方越来越多地寻求城市地区的庇护，以隐藏在人口中。这减轻了武器和传感器的技术优势，增加了打击的附带损害的威胁。

3.地缘政治趋势。更多的政治权力和军事能力正被非国家行为者所掌握。这导致了复杂的区域安全发展和来自弱国和失败国家领土的威胁。这些威胁不能被孤立地解决。

4.军事技术趋势。军事技术继续快速发展，导致新的军事竞争领域的出现。因此，运营商可能会对新交战方的能力感到惊讶。敌人有机会获得先进的武器系统和网络能力，为他们提供了越来越多的胁迫性选择。

5.偏远作战地区。崎岖、多山的地形、洞穴、恶劣的气候可能会限制武器或行动支持的能力。恐怖组织往往在这些偏远和不稳定的地区进行训练、维持、计划和行动。为了在偏远地区开展行动，特别行动人员必须与当地居民和领导人进行接触，获得他们的认可和信任，以收集情报支持行动。

6.冲突的模式。冲突的模式正在随着环境的变化而变化。低强度和不对称的冲突正在世界 "欠发达 "地区展开，一方是正规军，另一方是游击队、恐怖分子，甚至是平民。这些冲突往往是残酷的、血腥的、丑陋的，不依靠现代武装力量的高科技武器。其目的是在外部帮助下破坏一个政权的稳定。非正规的威胁通常在国家控制的领土边缘和无人管理的空间里兴风作浪。

7.行动的持续时间。特别行动的财政和政治可持续性使其更具吸引力。特别行动的小规模方法允许采取降低成本的战略，迫使对手花费不成比例的资源来抵御友好的能力。他们支持对环境有更深入的了解，以预测不稳定的爆发点，减少行动和战略盲点。

已实施的C2系统要求有能力收集、分配和转化数据为情报，以执行快速决策。决策必须支持指挥部队的能力，跨越多个领域和任务。有效的C2取决于基于对形势的理解而作出的行动决定。理解被定义为对特定情况的感知和解释，以提供有效决策所需的背景、洞察力和预见性。理解使决策者能够利用数据分析和可视化，从现有的信息中找出新的机会和威胁（MoD 2017）。

标准和传统的系统工程方法可能不足以支持这些复杂环境所需系统的开发。这些复杂性可能会导致C2系统的模糊和综合要求。系统工程兄弟会正在向MBSE发展，以应对复杂问题的系统开发（Walden等人，2015）。

3 基于模型的系统概念开发

3.1 基于模型的系统工程

建模是一个反复的过程，通过一个标准的、严格的、结构化的方法来开发、使用和更新模型，以获得对一个系统行为的洞察力。模型被定义为对现实或其选定部分的明确和不完整的表述或理想化的抽象，以帮助其描述和理解（Ramos等人，2012；Maria，1997）。模型必须在真实性和简单性之间取得平衡，以便能够理解和模拟（Maria 1997, Gau Pagnanelli等人，2012）。

在系统工程中，模型被用来描述与一个系统相关的结构、行为、操作和特征，以及与操作环境的选定的交互。环境包括使能系统和其他系统（Buede 2000, Hitchins 2008）。建模行为和产生的模型本身支持对问题的洞察，作为决策的基础（Maria 1997, Harrison et al. 2007, Buede 2000）。模型被用来对问题的知识进行实验，并发展对不同解决方案的影响的理解。这支持通过用视觉工具澄清需求来改善解决方案的开发决策（Walden等人，2015；Ramos等人，2012）。

在开发系统概念和需求方面，模型往往比基于文本的文件更有用，因为共同的符号以一致的方式描述了许多系统特征和属性（Buede 2000，Ramos等人，2012）。在系统工程中，建模解决问题的主要优势可以归纳为以下几点（Buede 2000，Ramos等人2012，Maria 1997，Walden等人2015）：

1.管理复杂度。建模有助于通过以下方式解决系统分析和方案设计的复杂性：

a) 通过对问题的多角度的可视化分析，实现系统理解。

b) 指导识别导致复杂性的元素和相互作用。

c) 改进影响分析，以确定解决方案的潜在后果。

d) 利用模型的可追溯性发现原因和影响。

2.用系统的术语捕捉问题。利益相关者检查他们自己的思维（心理模型），并将概念传达给其他人，以确认系统需求和行为。模型通过澄清需求来支持改进的系统开发决策。

3.捕获、分析、分享和管理信息。拥有一个标准语言的建模方法的好处是改善利益相关者之间的沟通，管理系统复杂性的能力，产品质量，知识捕获和教授和学习系统工程基本原理的能力。模型支持实验，以及对问题的知识进行定性和定量分析。

4.重复使用和自动化。建模使现有的信息和知识在新项目中得到重用，从而节省时间和金钱。通过用脚本执行可重复的任务，建模也有利于问题分析过程中的自动化。

然而，复杂的社会技术系统的建模仍然是困难的，因为它必须呈现系统中人类工作的结构和行为。行为是由人、操作者、系统元素和环境之间的动态交互引起的。在多个抽象层次上对系统界面进行建模，可能有助于理解复杂系统及其相互作用（Bahill & Szidarovszky 2009, Piaszczyk 2011, Oosthuizen and Pretorius 2014）。

MBSE被定义为建模的正式应用，以支持整个系统生命周期阶段的系统需求、设计、分析、验证和确认活动（Gau Pagnanelli等人，2012）。MBSE专注于应用丰富的信息模型来补充传统的系统工程方法（Walden等人，2015；Estefan，2007）。任何MBSE的实施都应该至少解决以下要素（Meyer 2014, Tschirner et al. 2015, Gau Pagnanelli et al. 2012, Karban et al 2012）：

1.流程。流程提供了为实现特定目标而在不同的细节和聚合水平上执行的任务的逻辑顺序。现有的MBSE流程，需要根据具体的实施环境进行调整。MBSE过程的基本步骤应该包括信息（需求）捕获、模型生成、验证和实施。这个过程不需要和传统的系统工程标准一样。

2.方法。方法包括执行流程中所列任务的一系列技术。每个方法本身也可以是一个过程。

3.工具集。工具是提高特定方法中任务效率的工具。工具只是促进任务的执行，并提供模型中捕获的信息的存储库。

MBSE不仅仅是开发一套图来粘贴到基于文本的报告中。仅仅使用标准建模符号来绘制这些图表并不能改善模型。MBSE的元模型（Holt and Perry 2017），如图1所示，指出了被建模的系统与架构框架内建模工具的应用之间的关系。这个元模型为开发适合特定应用领域的MBSE方法提供了基础。

在通过一些视图对系统进行建模之前，如图1中间的 "目标 "栏，需要建立支持结构。首先，需要一个架构来定义模型的视图。建模方法应用了一个架构框架。任何适合问题和解决方案空间的架构框架（如面向服务的架构、NAF、MoDAF或DODAF）都可以被MBSE方法应用。在所有情况下，都需要进行一定程度的定制。架构框架由描述系统及其行为所需的各种观点组成，这些观点由标准本体定义。对系统模型的不同观点被用来分析不同层次的系统（Kossiakoff等人，2011，Ryan等人，2014）。

图1:基于模型的系统工程元模型

系统的各种观点通过图示来体现。为了拥抱MBSE的力量，建模者应该超越基于文本的工具。这些基于文本的工具，如Visio™和Powerpoint只为基于文本的文件提供图片。它们不能管理复杂图表中元素之间的关系。应该为MBSE实施专门的以数据为中心的工具。这些工具实现了公认的建模符号，如SysML和UML，以通过图表开发一致的系统视图。SysML用于通过系统结构、参数、属性、要求、行为和关系的图来对复杂系统进行建模（Friedenthal等人，2012；Hause，2014）。

行为图表示情况的各个部分及其因果互动（Friedenthal等人，2012；Hause，2014）。系统的行为是用用例图、活动图、序列图和状态机图来建模的。用例图提供了系统功能的高级描述。活动图中记录了活动之间的数据流和控制流。顺序图代表了系统中合作部分之间的交互。需求图确保层次结构和推导、满足、验证和细化关系是清晰的。系统参数约束和其他参数，如性能、可靠性和物理特性，在参数图中被捕获（Hause 2014）。

Hause 2014）。块定义图通过层次、关系和分类来描述系统结构。内部块状图描述了系统的内部结构，包括部件、端口和连接器。块图中的块可以代表系统层次结构的任何一级，将系统描述为部件的集合，以及它们之间的连接，从而实现通信和其他形式的互动。端口提供了对块的内部结构的访问，以便在更大的结构范围内使用该对象。需求视图指定了从利益相关者需求中得出的所需结构和行为属性。参数视图提供了系统的关键工程参数，用于评估性能、可靠性和物理特性（Friedenthal等人，2012；Hause，2014）。

实施MBSE的这种元模型将帮助系统工程师（建模者）组织和展示信息，以支持开发基于模型的有形需求，从而开发解决方案的选择。根据建模工具，模型中捕获的信息可以以文本形式导出，用于审查和合同目的。通过一个以数据为中心的工具实现的MBSE使系统工程师能够管理需求和模型元素之间的关系。需求变化的影响可以追溯到它们所影响的模型元素。下一节将提出一个C2系统的建模过程。

3.2 指挥与控制系统的建模过程

从上面的讨论可以看出，MBSE是一种设计和开发复杂系统的现代方法。原则上，这个过程遵循自上而下的模型应用，而不是基于文件的文本来指定、设计、集成、验证和操作一个系统。MBSE采用了一个过程来开发和增加模型的细节，使用一个并发和增量的过程来支持利益相关者之间的沟通（Estefan 2007，Walden等人2015，Oosthuizen和Pretorius 2015）。

图2:基本MBSE建模过程

图2中用于C2系统建模的基本MBSE流程是松散地基于MoDAF的。该方法根据INCOSE手册和其他资料进行了调整和简化，包括以下活动（Walden等人，2015，Ryan等人，2014，Hause 2014）：

1.分析利益相关者的需求。这项活动抓住了 "现有 "系统的局限性和潜在的改进领域，以支持开发 "未来 "的解决方案。现有的基于文本的用户协议和其他需求文件可以为模拟利益相关者的需求提供有用的输入。

a) 确定系统的背景。第一步是定义系统的边界，以及与外部系统或操作环境的接口。系统上下文图的目的是将注意力集中在开发一套完整的系统需求和约束条件时应该考虑的外部因素和事件上。

b) 生成用例。高层次的系统功能是从用户需求中捕捉到的，在 "使用视图 "中，它由包的分层结构中的一些用例图组成。这项活动定义了支持任务要求的系统要求。系统被建模为一个与外部系统和用户交互的黑盒子。从用例中，系统所需的结构和行为是通过一个反复的过程得出的。

2.生成功能架构。系统功能以活动图的形式进行建模，定义从用例中得出的行为之间的关系。用例描述和命名中的动词应被用来定义活动。功能架构的建模使得系统功能需求的开发成为可能。

3.生成逻辑架构。系统被分解和划分为逻辑元素，它们相互作用，满足系统需求。逻辑元素是由用例中的名词衍生出来的。系统的逻辑元素用方框图来定义它们之间的关系。场景也用泳图来建模，泳图结合了活动图和块定义图。泳图将活动分配给逻辑块元素，并呈现出活动的逻辑流程。逻辑架构的建模使得非功能系统需求的开发成为可能。

4.生成解决方案的实施。这一步描述了定义资源分配的物理系统元素或节点之间的关系。在逻辑架构中确定的块通过块图的属性被实例化。内部块状图被用来模拟系统元素之间的接口，以及交换的信息元素。逻辑架构中的元素可以为多种可能的解决方案实现而实例化。

解决方案架构是这个建模过程的输出，并将被用来得出系统的功能、接口、数据和性能要求。一些解决方案可能会被生成，以输入到方案选择过程中。根据合同准则，需求可能会以文本形式或模型库的形式输出。

从图2中的连接器可以看出，这是一个迭代的过程。每个周期都会提高模型的完整性和准确性。视图也可用于支持C2系统的作战概念（ConOps）的发展。用一个以软件数据为中心的MBSE工具来实施这个过程将确保所有的模型元素和它们的标识被管理，以保持一致性和可追溯性。这个过程适用于大多数架构框架。

在这个过程中尚未解决的方面包括需求和顺序图；它们是在实施解决方案的设计的较低层次上需要的。本文讨论的过程中没有包括的其他步骤包括选择首选的架构以及验证和核实拟议的解决方案系统。这个框架是制定指定特种作战C2系统的过程的基础。

4 特种作战的指挥与控制概念建模

本节实现了图2中的过程，为特种作战定义了一个概念解决方案C2系统。这是在MBSE工具Enterprise Architect™中用SysML生成模型的一些视图来完成的。为了说明问题，我们将只提供有限数量的模型输出图。本节提供的信息将支持下一节的建模方法的演示，以定义一个可能需要用于特种作战的通用C2系统。本节提供的信息将支持下一节中的建模方法的演示，以定义一个可能需要用于特种作战的通用C2系统。

4.1 特种作战背景

对特定作战环境的方法的每一次应用都将导致不同的C2概念解决方案。为特种作战量身定做的C2系统的开发必须支持任务，可能会产生关键任务的不利后果。特种作战的主要特征，区别于更多的常规作战，包括以下内容（Johansen 2015, Kiras 2015, Votel 2016, Brown 1996, Eaton et al：）

1.能力。特种作战人员实施与普通陆军、海军或空军不同的（专业）能力和技能（如解救人质），而不会产生高成本和失败的风险。

2.敏捷性和灵活性。特种作战人员可以迅速抓住机会，适应不可预见的要求和行动挑战。这使他们能够与合作伙伴整合，开发战略机会，以对抗对手采用的非正规和混合方法。他们可以更灵活地直接（外科手术式打击）以及间接（特种作战）地运用武力。他们可以在基础设施有限或受限的恶劣环境中孤立地行动（没有定期和持续的支持）。

3.作战规模。特别行动往往是非正统的、高风险的小单位秘密或公开的行动。考虑到特别行动小组的规模相对较小，以及指挥系统很短的事实，小组可以在比大型常规部队更短的时间内部署。

4.持久和长期的行动。非正规和低强度的冲突需要长期（数月和数年）和持续的行动，以扭转对手的意志和对抗的根本原因。这就对战术、行动或战略层面的连续性和知识管理提出了要求。它允许对人的领域进行深入了解，这对于识别和影响相关行为者以获得可接受的结果是必要的。

5.支持。行动通常是在国家边界之外进行的，与OPFOR线后的既定行动或支持基地相距甚远。这些行动需要专业的支持（公开的和秘密的），不能由任何常规部队进行。这需要量身定做的能力、保护和后勤支持。特别行动可能需要秘密技术，以确保低能见度，而诸如隐蔽性、欺骗性和间接方法等概念总是被应用。与总部的联系、进入和保持安全的通信渠道对特种作战来说是一个挑战。

6.作战节奏。由于其规模和灵活性，特别行动单位可以在高节奏下行动。特种作战人员可以早期、持续和精确地采取行动，以创造所需的决策空间和战略选择，提供可持续的结果。

7.国家政策的工具。特别行动组人员经常被部署去执行外交政策，这增加了敏感性和风险程度。可以从军事或国家指挥的最高层雇用和领导特别行动战术单位，以实现特定的政治或战略目标。

8.低层决策。尽管行动是由最高层授权的，但可能产生战略结果的决定往往是在最低的战术层面上做出的。各单位积极鼓励任务指挥，以个人专长为基础的参与式决策是当务之急。

9.联合、机构间、政府间和多国行动。当代特别行动倾向于联合、机构间、政府间和多国行动（JIIM），并以共同的目标和共同的目的形成网络。目标必须通过本地或代理部队来实现，并与之合作。人员面临着与其他行动参与者协调、消除冲突和利用特别行动活动的挑战。部署特别行动资产是为了收集可能无法通过其他方式获得的信息。与外部角色的信息共享可能会削弱信任。

以上列出的这些作战特点将影响到为特种作战所制定的作战方案。该解决方案系统必须应对多样化、自主、复杂和高节奏的行动。由于其应用的多样性，特种作战也可以从战术、作战或战略层面进行控制。在较低的战术层面，外部关系被减少，线性等级制度占主导地位，并以指令的方式提供指挥。在作战和战略层面上，与外部伙伴和其他行为者的交往将更加普遍。这些可能不在同一个指挥结构之下，需要以较不直接的方式进行合作和影响。另外，在不同的情况下，不同C2级别的指挥官将获得不同程度的授权（国防部2017）。

特种作战ConOps将需要一个模块化的C2系统，因为同一个用户在不同的任务中可能面临不同的挑战。C2系统必须支持对局势的理解，以实施对活动的控制和协调（Rantakokko等人，2010年，Alberts 2011）。管理一个模块化系统的元素和接口可能会成为一个复杂的问题。建议的MBSE过程将协助系统工程师为预期的复杂性和分歧情况得出具体要求。

4.2 上下文分析

系统上下文图，如图3所示，定义了系统与环境之间的边界，显示了系统与之交互的实体。这张图是感兴趣的系统的高层视图（黑盒）。感兴趣的系统和外部系统上的小蓝块是接口，以方便信息在接口上的流动。箭头表示信息的流动。外部环境主要由系统和系统外的利益相关者组成。它也提供了对将要开发的实际感兴趣的系统的关注。这张图是要设计的解决方案系统的界限。

图3:上下文图

C2系统将着重于界面（如显示器）和信息处理元素，这些元素将被部署在操作人员和他们的指挥官身上。通信系统被看作是C2系统的外部。通信是C2系统的一个促成因素。它通常由外部单位控制，并由其他人用于不同的目的。C2系统还需要与部署在特种作战人员身边的外部传感器相连接。为了使特种作战C2系统支持实施协作或边缘C2方法，将需要有效的通信接口和互操作性。

4.3 用例

用例是用来捕捉和表示特种作战C2系统的高层次系统功能和用途。用例还确定了不同的场景，以衍生出系统所需的功能。用例被结构化为包，如下图4所示，以管理不同层次的建模水平。各包之间的箭头描述了它们之间的依赖关系。用例的来源包括各种公布的理论文件以及与主题专家和其他利益相关者的互动。用例也构成了开发ConOps的基础。

图4:用例包

图5给出了战术级用户使用特种作战C2系统生成态势感知信息的简略用例。态势感知支持指挥官和操作人员了解作战情况以支持决策。态势感知支持C2的快速决策。态势感知需要支持根据收到的新信息或目标的变化在短时间内改变和调整计划，即使行动是在有限的信息下进行的。信息由经过分析和添加背景的信息对象组成。信息比数据对象处于更高的抽象水平（经过处理）。

图5:过程信息用例

系统需要实现基于角色的认证，以保护信息的安全性和完整性。这只允许某些用户以规定的访问（需要知道）权限访问信息。与任务相关的作战环境信息是由观察事件的信息收集资源在系统中采集的。要在系统中捕获的典型信息可能包括图像、视频、自己的位置报告、气象信息、地理（地形）信息和社会媒体。

还需要进行信息整理，以接收、处理和显示有关友军和敌军活动或能力的当前信息。信息被显示在（覆盖）地形上，以产生一个共同的作战图。对数据进行处理以增加其价值，并使其成为可用的 "信息"。这涉及到对不断变化的政治和军事环境的正确评价和理解。来自不同传感器的数据需要进行融合，以便为特定用途提供最适用和准确的信息。最后，特别行动操作人员需要能够在紧急情况下销毁系统中的所有信息，以防止机密信息落入敌对势力之手。

类似的用例可以被生成，以解决战略或操作层面的用户和拟议系统的使用。不同的用例也可以为特定的场景生成。其目的是在启动下一层次的分析之前，确定系统的所有用途和行为者。

4.4 功能架构

C2要执行的功能是由用例中的动词得出的。系统的功能逻辑结构被记录在一些活动图中，以定义活动（功能）之间的关系。图6显示了所选功能活动的层次结构。

图7提供了功能结构的另一种观点，它由相同的元素（活动）组成，但它们之间有不同的关系（控制和信息流）。首先，C2系统中的信息是通过对作战环境中的元素的传感（集成）和操作人员的视觉观察来获取的，包括对感兴趣的元素的位置和描述。额外的信息被收集，并与GIS数据进行整理，以建立各种信息位之间的联系。

图6:功能架构层次结构

这些信息被储存起来用于显示和分析。选定的信息要显示给操作人员，以便为指挥官提供一个完整的战斗空间图，以及命令、回应和协调行动的能力。另一个关键方面是分析信息，以提高捕获信息的价值和可用性。同样，端口被用来定义各项活动之间的接口。

图7:功能架构

4.5 逻辑架构

C2系统的逻辑结构，如图8所示，包括从用例中的名词衍生出来的系统元素，以提供结构和工具（系统元素）。系统被分解和划分为逻辑元素，这些元素相互作用以满足系统要求，使用块中的块。

图9提供了图8中C2系统的逻辑元素之间的接口。该图由相同的元素（块）组成，但它们之间有不同的关系（接口）。有关系统的外部边界上的端口与上下文图中定义的端口相对应。这些端口定义了项目和信息与外部系统和情况管理系统操作者的流动接口。

图8:系统架构结构

如图10所示，逻辑架构中定义的逻辑系统元素执行功能。这里，图6和图7的活动被分配给图8和图9的块状元素。特种作战C2系统中捕获的信息在显示器上呈现给操作人员。该显示器使操作人员能够查看信息并与之互动。显示的信息可以包括由地图组成的共同行动战场图，其中有自己的部队、友军、威胁部队和目标位置。可根据需要过滤的其他信息包括任务状态、人员健康状态、电子攻击警告和实时视频或照片图像。这些信息可能来自于同地的传感器，这些传感器可能被整合到C2系统中。

图9:带有接口的系统架构

信息分析工具或应用程序支持对捕获的信息进行分析和处理，以支持情报过程（周期）以及发展局势意识。该工具通过态势感知显示器访问存储的信息，以查看、回放和处理数据库中的信息。C2系统中的所有信息都存储在一个集中的数据库中。该数据库需要一个适合于所有特种作战任务的数据元模型和本体论。

图10:逻辑架构

4.6 方案实施

建模过程的最后一步是将逻辑和功能结构转换为具体的解决方案选择，以便进行分析和权衡。选定的解决方案描述将构成所需采购的C2系统的系统需求说明的基础。如图11所示，这一步描述了定义资源分配的物理系统元素或节点之间的关系。

在逻辑结构中确定的块是通过块图的属性来实例化的。SysML块（UML类）被实例化为属性（UML对象），以模拟不同的解决方案。一个块可以通过多个属性进行实例化，如综合传感器和情况意识显示逻辑元素。信息分析工具在战术部署的个人综合C2系统中没有被实例化，因为操作者可能没有时间进行信息分析。这种方法使系统工程师能够在其系统设计中实现模块化。

图11:C2系统解决方案实施

4.7 可追溯性

用软件工具实现MBSE的一个优点是能够保持工具中捕获的各种元素之间的可追溯性，如图12所示。这种可追溯性使系统工程师能够实施变更管理。一个用例中的变化可以被追踪到系统解决方案中的影响。这些块中的任何一个都可以被追踪到用户、系统或实施的需求。

图12:元素可追溯性

4.8 讨论

本节展示了基于MBSE的C2系统开发方法，该方法将在复杂环境中使用。这个过程是独立于架构框架的，并且可以连接到基于能力的系统建模中。建模的力量是为所有的系统元素及其关系和相互作用提供一个可视化的表示。一张图片胜过1000个字。模型帮助利益相关者理解他们的需求和系统解决方案的含义。由于复杂的关系更容易被视觉化和管理，模型的图表在审查时仍然更容易使用。

在这个过程的每一步，都有可能为系统定义和添加需求。每个需求都可以与一个特定的元素相关联或被追踪。在需求和系统元素之间甚至可以有多对多的关系。如果存在一个需求列表（如用户需求），它可以被导入到工具中，并与各种模型元素相联系。

大多数MBSE工具使建模者能够为模型元素和关系添加文本描述。这些工具也有自动化的应用，可以将图与元素的描述导出为基于文本的报告，供利益相关者正式审查和接受。报告可以是需求说明的形式，也可以是只包含模型所要求的特定信息的系统描述的ConOps。

在开发和实施系统的组织中，模型的可移植性也很重要。对模型元素（用例、活动和逻辑块）的访问和对需求的追踪将有助于权衡和设计决策。