系统工程系统（SoSE）并不是一门新学科。 然而，这是系统工程界定义 21 世纪复杂系统的机会（Jamshidi 2009）。 虽然系统工程是一个相当成熟的领域，但 SoSE 代表了当前系统工程师在全球范围内的挑战。 一般而言，SoSE 需要考虑超出通常与工程相关的考虑，包括社会技术和有时社会经济现象。

话题

SEBoK 的每个部分都分为知识领域 (KA)，这些知识领域是具有相关主题的信息分组。 KA 依次被划分为主题。 本 KA 包含以下主题：

• Systems_of_Systems_(SoS)的架构方法
• Systems_of_Systems_(SoS)的社会技术特征
• 能力工程

系统的特征和定义

Maier (1998) 假设了 SoS 的五个关键特征（不是标准）：组件系统的操作独立性、组件系统的管理独立性、地理分布、紧急行为和进化发展过程，并将操作独立性和管理独立性确定为两个主要区别应用术语“Systems_of_Systems_(SoS)”的特征。 不表现出这两个特征的系统不被视为系统中的系统，无论其组件的复杂性或地理分布如何。

在 Maier 的描述中，被认为是 SoS 的一个共同特征，特别是在由多个大型现有系统组成的 SoS 中，基于挑战（在时间和资源上）跨越无数功能、能力和数据的所有可能的逻辑线程SoS 中的系统。 正如文章Emergence中所介绍的，将具有单独复杂行为的系统组合起来会产生与意外或意外行为相关的风险。 在安全受到威胁的情况下，这些情况会变得很严重，例如，通过 SoS 中多个组成系统提供的功能之间的意外交互来威胁安全。

ISO/IEC/IEEE 21839 (ISO, 2019) 提供了 SoS 和组成系统的定义：

Systems_of_Systems_(SoS)— 一组系统或系统元素，它们相互作用以提供任何组成系统都无法单独完成的独特功能。 注意：系统元素可能是必要的，以促进Systems_of_Systems_(SoS)中的组成系统的交互

组成系统 —— 组成系统可以是一个或多个 SoS 的一部分。 注意：每个组成部分本身就是一个有用的系统，有自己的发展、管理目标和资源，但在 SoS 内交互以提供 SoS 的独特能力。

此外，系统中的系统 (SoS) 有多种定义，其中一些取决于应用领域的特殊性 (Jamshidi, 2005)。

应该注意的是，SoS 的形成不一定是一种永久性现象，而是以协调的方式集成和联网系统以实现特定目标（如鲁棒性、成本、效率等）的必要性。

美国国防部（2008 年）将系统工程系统定义为“规划、分析、组织和集成现有和新系统的混合能力，使其成为大于组成部分能力总和的 SoS 能力”。

ISO/IEC/IEEE 15288 Annex G (2015) 还描述了这些特性对系统工程过程实施的影响。 由于组成系统的独立性，这些过程在大多数情况下都是为工程系统和Systems_of_Systems_(SoS)而实施的，并且需要进行定制以支持 SoS 的特性。 下表显示了这些流程，突出显示了这些流程在系统和 SoS 级别上实施的事实，而 SoSE 通常受到系统的限制。

表 1. 应用于系统工程的系统和Systems_of_Systems_(SoS)之间的差异。

最后，基于 INCOSE Systems of Systems 工作组 (Dahmann, 2014) 所做的工作，SoSE 面临的主要挑战已按照七个痛点进行分类。 INCOSE SE 手册的 SoSE 部分介绍了这些挑战。 （INCOSE 2015）。 这些挑战包括：

• SoS的权力。 在 SoS 中，每个组成系统都有自己的本地“所有者”及其利益相关者、用户、业务流程和开发方法。 因此，在大多数 SoS 中都没有为大多数传统系统工程假设的由单一机构负责整个系统的组织结构类型。 在 SoS 中，SE 依赖于横切分析以及组成系统的组成和整合，而这些组成和集成又依赖于这些系统达成一致的共同目标和动机，以共同实现可能与共同目标一致或不一致的集体目标。各个组成系统。
• SoS的领导力。 认识到缺乏共同权威和资金对 SoS 构成挑战，一个相关问题是在 SoS 的多组织环境中的领导力挑战。 当系统 SE 中通常存在缺乏结构化控制需要替代方案来提供连贯性和方向性（例如影响和激励）时，就会遇到领导力问题。
• 组成系统的观点。 Systems_of_Systems_(SoS)通常至少部分由在用系统组成，这些系统通常是为其他目的而开发的，现在正被用来满足具有新目标的新的或不同的应用程序。 这是 SoS SE 面临的一个主要问题的基础； 即，如何从技术上解决由于为 SoS 确定的系统可能在支持 SoS 的程度上受到限制这一事实而产生的问题。 这些限制可能会影响将系统整合到 SoS 中的最初努力，并且系统对其他用户的承诺可能意味着随着时间的推移它们可能与 SoS 不兼容。 此外，由于这些系统是在不同情况下开发和运行的，
• 能力和要求。 传统上（并且在理想情况下），SE 过程从一组清晰、完整的用户需求开始，并提供一种规范的方法来开发满足这些需求的系统。 通常，SoS 由多个具有自己要求的独立系统组成，致力于实现更广泛的能力目标。 在最好的情况下，组成系统可以满足 SoS 能力需求，因为它们满足自己的本地要求。 然而，在许多情况下，SoS 需求可能与组成系统的要求不一致。 在这些情况下，SoS SE 需要确定通过更改组成系统或向 SoS 添加其他系统来满足这些需求的替代方法。 实际上，这是要求系统以 SoS 作为“用户”来满足新的要求。
• 自治、相互依存和出现。 SoS 中组成系统的独立性是 SoS 的 SE 面临的许多技术问题的根源。 一个组成系统可能会独立于 SoS 继续变化，以及该组成系统与其他组成系统之间的相互依赖关系，这增加了 SoS 的复杂性，并进一步挑战了 SoS 级别的 SE。 特别是，这些动态可能导致 SoS 级别的意外影响，从而导致 SoS 中出现意外或不可预测的行为，即使组成系统的行为已被充分理解。
• 测试、验证和学习。 SoS 通常由独立于 SoS 的组成系统组成，这一事实在进行端到端 SoS 测试时提出了挑战，就像通常对系统进行的那样。 首先，除非对 SoS 级别的期望和这些期望的衡量有清楚的了解，否则很难将评估性能水平作为确定需要关注的领域的基础，或者向用户保证其能力和局限性。社会保障体系。 即使对 SoS 目标和指标有清晰的理解，传统意义上的测试也可能很困难。 根据 SoS 环境，可能没有资金或授权进行 SoS 测试。 组成系统的开发周期通常与其所有者和原始持续用户群的需求相关联。 由于多个组成系统受到异步开发周期的影响，要想找到跨 SoS 进行传统端到端测试的方法即使不是不可能，也可能很困难。 此外，许多 SoS 规模庞大且种类繁多，使得对组成系统的每次更改进行传统的完整端到端测试的成本高得令人望而却步。 通常，获得良好的 SoS 性能衡量标准的唯一方法是从实际操作中收集的数据或通过基于建模、模拟和分析的估计。 尽管如此，尽管存在这些挑战，SoS SE 团队仍需要确保 SoS 的操作和性能的连续性。 许多 SoS 规模庞大且种类繁多，使得对组成系统的每次更改进行传统的完整端到端测试的成本高得令人望而却步。 通常，获得良好的 SoS 性能衡量标准的唯一方法是从实际操作中收集的数据或通过基于建模、模拟和分析的估计。 尽管如此，尽管存在这些挑战，SoS SE 团队仍需要确保 SoS 的操作和性能的连续性。 许多 SoS 规模庞大且种类繁多，使得对组成系统的每次更改进行传统的完整端到端测试的成本高得令人望而却步。 通常，获得良好的 SoS 性能衡量标准的唯一方法是从实际操作中收集的数据或通过基于建模、模拟和分析的估计。 尽管如此，尽管存在这些挑战，SoS SE 团队仍需要确保 SoS 的操作和性能的连续性。
• SoS 原则。 SoS 是一个相对较新的领域，因此对将系统思维扩展到 SoS 特定问题的方法的关注有限。 需要开展工作来识别和阐明一般适用于 SoS 的跨领域原则，并开发应用这些原则的工作示例。 迁移到 SoS 环境的普通系统工程师有一个主要的学习曲线，并且在组织内或跨组织的 SoS 知识转移方面存在问题。

SoS 的类型

在当今互联互通的世界中，SoS 发生在广泛的环境中。 在 SoS 被识别并视为一个系统的情况下，SoS 可以被描述为四种类型之一（Maier，1998；Dahmann 和 Baldwin，2008，ISO 21839，2019）：

• 定向 - 创建和管理 SoS 以实现特定目的，并且组成系统从属于 SoS。 组件系统保持独立运行的能力； 但是，它们的正常运行模式从属于中央管理的目的；
• 已确认 - SoS 已确认 SoS 的目标、指定的经理和资源； 但是，组成系统保留其独立的所有权、目标、资金以及开发和维持方法。 系统的变化基于 SoS 和系统之间的合作协议；
• 协作 - 组件系统或多或少地自愿交互以实现商定的中心目的。 核心参与者共同决定如何提供或拒绝服务，从而提供一些执行和维护标准的手段； 和
• 虚拟 - SoS 缺乏中央管理权限和中央一致同意的 SoS 目的。 出现了大规模行为——并且可能是可取的——但这种类型的 SoS 必须依靠相对不可见的机制来维持它。

该分类法基于组成部分的独立程度，并根据 SoS 目标的起源以及 SoS 及其组成系统的利益相关者之间的关系为理解 SoS 提供了一个框架。 在大多数实际情况下，SoS 将反映可能随时间变化的 SoS 类型的组合。 这种分类法是普遍使用的。 它在 15288 附录 G 和 ISO 21841“Systems_of_Systems_(SoS)分类”中进行了介绍。 其他分类法可能侧重于组件的性质/类型、它们的异质性等（Cook，2014）

如上所述，许多 SoS 存在于无法识别的状态； 随着现代系统之间的互联程度不断提高，这一点越来越真实。 Kemp et al (2013) 将此类系统描述为“意外”，但它们可以被描述为“发现”（Dahmann 和 Henshaw，2016），因为只有当它们由于某种原因变得重要时，我们才能识别它们，此时它们可以通常属于上述四类之一，因为它们的重要性意味着它们现在必须以某种明确的方式与管理一起运作。

从 SoSE 的角度来看，另一个潜在的分类将考虑 SoSE 对 SoS 操作的预期/准备水平和 SoS 目标的稳定性水平； 这被 Kinder 等人称为可变性。 人。 （2012）。 这可以从响应特定触发器并在表达需求时立即到位的 SoS 不等。 这种 SoS 的一个例子是危机管理 SoS。 这种类型的 SoS 在操作过程中会动态更新。 在光谱的另一端，开发了明确且稳定的 SoS 来满足特定的持续需求。 这种持久性 SoS 的一个例子是空中交通管理系统。 这种类型的 SoS 是在定义明确的环境中获得和认证的，任何进化需求都意味着正式的 SE 进化和重新认证。

虽然早期对 SoS 的大部分关注都集中在可以调整和应用当前 SE 实践的公认 SoS 上，但人们越来越认识到，SoS 的优势存在于协作和虚拟类型（Honour 2016）以及那些SoS 可能并未得到官方认可，但会影响当今互联世界中的许多更广泛的能力。 在这些情况下，重点转移到将 SoS 理解为社会技术、复杂的自适应系统，而不是当前技术系统的扩展，重点是理解和解决这些类型的 SoS 的固有复杂性。

SoSE 应用领域

SoSE的应用范围很广，并且正在扩展到几乎所有的各行各业。 SoSE 最初是在国防环境中发现的，现在应用范围更广，并且还在不断扩展。 国防领域的早期工作为 SoSE 提供了初步的基础，包括其知识基础、技术方法和实践经验。 此外，信息服务和铁路的平行发展有助于发展 SoSE 实践（Kemp 和 Daw，2015 年）。 现在，SoSE 的概念和原则适用于其他政府、民用和商业领域。

一些例子包括：

• 运输 ——空中交通管理、欧洲铁路网络、综合地面运输、货物运输、公路管理和空间系统，
• 能源 ——智能电网、智能家居、综合生产/消费，
• 医疗保健 - 区域设施管理、紧急服务和个人健康管理，
• 防御 - 军事任务，例如导弹防御、网络传感器、
• 铁路 ——城市、国家、国际铁路系统，
• 自然资源管理 - 全球环境、区域水资源、林业和娱乐资源，
• 灾害响应 - 对包括森林火灾、洪水和恐怖袭击在内的灾害事件的响应，
• 消费类产品 ——综合娱乐与家居产品一体化，
• 商业 银行和金融，
• 媒体 ——电影、广播和电视。

当今系统网络和互连性的增加有助于 SoS 成为常态的数量和领域的增长，特别是随着Systems_of_Systems_(SoS)、网络物理系统和物联网之间的大量融合。 （亨肖，2016）。

系统工程系统与系统工程之间的区别

关于个体或组成系统与 SoS 之间差异的观察结果列于表 1。这些差异并不像表中所暗示的那样非黑即白，在每种情况下，差异程度在实践中有所不同。 现代系统往往是高度互连的，因此导致表 2 中系统工程特征的假设很少得到满足。

表 2. 应用于系统工程的系统和Systems_of_Systems_(SoS)之间的差异。 （INCOSE，2018）

管理和运营独立性（Maier，1998）的特征最根本地将 SoS 的行为与单一系统区分开来：这已被 Rebovich（2009）解释为 SoS 的基本问题：

从单系统社区的角度来看，其作为 SoS 功能的一部分代表了额外的义务、约束和复杂性。 从单系统利益相关者的角度来看，参与 SoS 很少被视为净收益 [Rebovic, 2009]。

SoSE 标准

系统工程系统的第一个标准已被国际标准组织采用。 这些是在 2016 年响应 ISO SoS 标准研究组 (ISO, 2016) 的报告启动的，该报告认识到对 SoS 的日益关注以及标准对 SoSE 成熟的价值。 2019 年通过了三个标准（INCOSE 2020）：

• ISO/IEC/IEEE 21839 – 系统生命周期阶段的系统 (SoS) 考虑因素

该标准提供了一组在人类创建的系统生命周期的关键点上需要解决的关键考虑因素，并将在Systems_of_Systems_(SoS)中交互的组成系统称为感兴趣系统 (SOI)。 这些注意事项与系统生命周期阶段和相关术语的 ISO/IEC/IEEE 15288 和 ISO/IEC/IEEE 24748 框架保持一致。

• ISO/IEC/IEEE 21840 – ISO/IEC/IEEE 15288 在Systems_of_Systems_(SoS)工程环境中的使用指南

本标准为在 SoS 环境中使用 ISO/IEC/IEEE 15288 提供指导。 虽然 ISO/IEC/IEEE 15288 适用于系统（包括组成系统），但本文档提供了将这些流程应用于 SoS 的指南。 但是，ISO/IEC/IEEE 21840 不是 ISO/IEC/IEEE 15288 的独立 SoS 替代品。本文档旨在与 ISO/IEC/IEEE 15288、ISO/IEC/IEEE 21839 和 ISO/ IEC/IEEE 21841 并且不打算在没有它们的情况下使用。

• ISO/IEC/IEEE 21841 – 系统分类法

本标准的目的是为Systems_of_Systems_(SoS)定义标准化分类法，以促进利益相关者之间的沟通。 它还简要解释了分类是什么以及它如何应用于 SoS 以帮助理解和交流。

系统中的系统的架构方法

用于Systems_of_Systems_(SoS)的系统工程(SE) 的 一个关键部分是系统 组合以满足 SoS 需求。 这可能包括简单地连接系统并利用其现有功能，或者可能需要更改系统功能、性能或接口。 随着 SoS 不断发展以满足不断变化的 SoS 目标，这些变化会逐渐发生。 系统工程系统 (SoSE) 通过开发和发展一个技术框架来支持这些变化，该框架充当组成 SoS 的系统的覆盖层。 该框架提供了 架构 对于 SoS。 SoS 架构定义了系统如何协同工作以满足 SoS 目标，并考虑各个系统的细节及其对 SoS 性能或功能的影响。

系统架构师系统的作用

架构是组件的 结构、它们的关系以及随着时间的推移管理它们的设计演变的原则和指南 (IEEE 610.12-1990)。

在 SoS 中，架构是构成 SoS 的系统的技术框架，它指定用户在操作环境中将如何使用系统（有时称为操作概念（CONOP 或 CONOP）、内部和外部关系以及组成系统及其功能之间的依赖关系，最后是端到端功能和数据流以及系统之间的通信。

由于 SoS 主要由现存的独立系统组成，因此这些对 SoS 架构施加了限制，并且可能要求向 SoS 架构的迁移是增量的。 开发 SoS 架构需要考虑组成系统的技术可行性以及 SoS 本身的需求。 组成系统的架构数据也可以是架构 SoS 的重要数据。 这里与将商用现货 (COTS) 产品引入系统有一些相似之处：COTS 产品已经独立管理，但系统开发人员需要足够的数据来确保令人满意的集成。 但是，在这种情况下，COTS 产品不是独立运营的 。

Maier (1998) 对 SoS 特性对 SoS 架构的影响进行了概念性讨论。 此外，美国 DoD SE 的 SoS 指南（2008 年）描述了开发和发展作为 SoSE 核心元素的 SoS 架构的实际考虑。

架构 SoS 的挑战

在新系统开发的情况下，系统工程师可以从一种全新的、不受阻碍的架构方法开始。 然而，在 SoS 中，有助于实现 SoS 目标的系统通常在建立 SoS 时就位，并且 SoS 工程师需要考虑各个系统的当前状态和计划作为开发 SoS 架构的因素。 这一点，再加上组成系统本身可能是复杂系统的事实，给构建 SoS 带来了一系列挑战。 架构方法必须由所考虑的 SoS 类型决定。 虽然定向 SoS 可以以与单体系统大致相同的方式构建，但其他类型则不那么简单， 因为 SOI 的定义可能不太清楚，而且因为 SoS 架构师对组成系统的了解可能是片面的。 此外，尽管在定向 SoS 中，所有者可能有权和资金要求对组成系统的架构进行更改，但在公认的和协作的 SoS 重新架构中，由组成系统的所有者自行决定。 Maier (Maier 1998) 将架构的注意力集中在 SoS 的通信上，认为这是所有类型的共同特征，他将通信划分为与互操作性层相似的层 (NCOIC, 2008)。 在公认和协作的 SoS 重新架构中，由组成系统的所有者自行决定。 Maier (Maier 1998) 将架构的注意力集中在 SoS 的通信上，认为这是所有类型的共同特征，他将通信划分为与互操作性层相似的层 (NCOIC, 2008)。 在公认和协作的 SoS 重新架构中，由组成系统的所有者自行决定。 Maier (Maier 1998) 将架构的注意力集中在 SoS 的通信上，认为这是所有类型的共同特征，他将通信划分为与互操作性层相似的层 (NCOIC, 2008)。

组成系统的独立性意味着这些系统通常不是为优化 SoS 目标而设计的。 甚至可能组成系统应在系统级别以次优方式运行，以实现整体 SoS 有效性。 (Rebovich 2009) 将这一困难阐明为 SoS 的一个基本问题：

从单系统社区的角度来看，其作为 SoS 功能的一部分代表了额外的义务、约束和复杂性。 从单系统利益相关者的角度来看，参与（原文如此）SoS 很少被视为净收益。

SoS 架构的开发和实施可能会受到不愿做出改变或投资于可能非常成熟（例如在维持方面）或当前有效地支持其他用途的组成系统的极大限制。 在这种情况下，可以使用网关和包装等方法将这些系统合并到 SoS 中，而无需对其他系统进行重大更改。

架构分析

大规模系统集成 变得越来越重要，相应地，人们对 SoS 概念和策略的兴趣也越来越大。 异构系统组的性能和功能已成为各种应用的焦点，包括军事、安全、航空航天、分布式能源、医疗保健和灾难管理系统（Lopez 2006；Wojcik 和 Hoffman 2006）。 人们越来越关注利用这些独立系统之间的协同作用来实现所需的整体系统性能（Azarnoush et al. 2006）。

进行建模和仿真以分析架构有效性并验证架构特征。 在文献中，研究人员已经解决了协调和 互操作性的问题在 SoS 中（Abel 和 Sukkarieh 2006；Sahin 等人 2007）。 为了研究 SoS 的特性和参数，需要为系统架构的系统适当地设计逼真的仿真框架。 有一些尝试使用离散事件模拟 (DEVS) 工具为多智能体系统开发模拟框架 (Zeigler et al. 2000a)。 在这些研究工作中，主要关注的是使用 JAVA 的 DEVS 架构。 在 (Mittall 2000) 中，引入了 DEVS 状态机方法。 最后，使用基于 XML 的 JAVA 开发了 DEVS 建模语言（DEVSML），以相对容易地以网络为中心的方式模拟系统。 沙欣等人。 (2007) 最近推出了基于 DEVS 和 JAVA 的基于离散事件 XML 的 SoS 模拟框架。

SoS 工程的开放方法

如上所述，SoS 架构的主要挑战之一是，SoS 的组成系统可能尚未根据其在 SoS 中的角色进行设计、开发和使用，这限制了 SoS 架构选项。 覆盖 这些组成系统并支持 SoS 端到端功能 的架构的程度可以基于开放标准； SoS 可能能够从开放式架构中受益，以进行未来的演进。

从 SoS 作为一个概念转向 SoS 工程的关键挑战是系统工程和管理方法的考虑系统在技术、人力和组织方面的重大差异（Wells 和 Sage 2008）。 设计 SoS 的一种潜在方法可以是 SoSE 的 开放系统方法 （Azani 2009）。 Azani (2009) 列出了以下开放系统原则：

• 开放接口原则 ——开放系统具有可渗透的边界，允许它们与其他系统交换质量、能量和信息；
• 协同原则 ——这一概念表明组成系统之间的合作互动在它们的联合努力中比它们各个部分的总和具有更大的影响。 本质上，这就是出现的原因。
• 自治原则 ——这意味着 SoS 在不受外部干扰的情况下维持和发展其内部秩序。 这可以通过控制论控制、体内平衡或自组织来实现；
• 涌现原则 ——在这种情况下，这是指在 SoS 自组织过程中出现新颖且连贯的结构、模式和属性；
• 守恒原理 ——该原理表明能量和质量（材料）在 SoS 内是守恒的；
• 重新配置原则 ——这是指 SoS 重新配置和调整自身以维持自身免受环境变化的影响；
• 共生原则 ——SoS 内的系统之间存在共生关系； 更透明地，SoS 的成功开发和维持取决于其所组成系统的利益相关者之间的共生合作；
• 模块化原则 - 这认为每个级别和每个系统在某种程度上独立于其他。 在 SoS 设计中，通过标准化接口相互操作的独立模块化系统的开发能够提供更大的灵活性，以促进 SoS 更好的演进。

Azani (2009) 阐述了生物 SoS 使用的开放系统开发策略和原则，讨论了人造 SoS 工程的影响，并介绍了一种集成的 SoS 开发方法，用于工程和开发适应性强、可持续和可互操作的 SoS基于开放系统的原则和策略。

另一方面，Hitchens (2003, 107) 在系统生命周期方面讨论了开放系统的原则，因为他提出的七项原则是系统反应、系统凝聚力、系统适应、连接多样性、有限多样性、首选模式和循环进展。 该描述采用系统动力学方法来展示开放系统如何演变； 该描述适用于自然和人造系统。

开放的推动者包括开放标准和开放规范，它们来自利益社区之间的共识，并由该社区发布并在该社区内免费提供。 一个开放的规范必须确保它的详细程度允许它可以被独立的各方实施。 遵守开放标准旨在确保结果一致（Henshaw 等人，2011 年）。 这与开放系统架构的概念相似，开放系统架构是系统或Systems_of_Systems_(SoS)的架构的开放规范，目的是获得特定的能力。 作为良好设计的一般特征（对于系统或Systems_of_Systems_(SoS)），开放式系统架构应该允许通过添加或更改组件来快速轻松地改进和更新系统功能。 然而，Henshaw 等。 人。

网络和网络分析

由于网络是 SoS 的常见组成部分，因此需要特别注意。 在基于底层网络的 SoS 中，通信和信息交换通常本身就构成了 SoS。 这种支持 SoS 需要像任何其他 SoS 一样进行架构，这将在本节中讨论。 在启用网络 SoS 的情况下，“用户”、更大 SoS 的端到端功能和启用网络 SoS 是由这些用户需求驱动的。 SoSE 概念和网络支持之间的关系，以及超越信息共享的网络和网络分析的概念，已经被国防界广泛探索（Dickerson 和 Mavris 2009）。 例如，在美国海军在指挥、控制、通信、计算机、情报、监视、

使能网络 SoS 架构的差异源于这些 SoS 通常建立在商业技术和架构之上的事实，这些技术和架构在当今动态的技术环境中正在迅速变化。 此外，这些使能网络通常在 SoS 之间共享，因此可能会进一步限制整个 SoS 架构。 例如，许多 SoS（为了成本和便利性）希望通过 Internet 运行，因此必须考虑 Internet 的特性，以期望通过使用共享的支持基础设施提供的性能和安全性。

通过建模、模拟、分析和/或实验室实验探索敏感性并识别可扩展性问题或不同行为（例如，关于要求或使用假设、假设的网络带宽或其他方面）的初始分析特别有助于启用网络 SoS 架构)，超出此范围后性能开始下降。 这种类型的分析为网络架构决策提供了基础。

在定向 SoS 中，由于自上而下的控制，可以选择为特定的 SoS 创建专门的网络。 在其他类型的 SoS 中，如果组成部分已经由某种类型的网络支持，那么整个 SoS 网络方法通常需要适应这些，因为组成部分系统可能需要继续使用其当前方法来支持其原始用户.

互操作性

SoS 内的互操作性意味着每个系统都可以与任何其他系统进行通信和交互（控制），而不管它们的硬件和软件特性或性质如何。 这意味着 SoS 的每个组成成员（和潜在的新成员）都应该能够与其他成员进行通信，而不会出现操作系统、通信硬件等方面的兼容性问题。 为此，SoS 需要 SoS 系统可以使用的通用语言。 这里的挑战是努力在 SoS 的系统之间交换信息和数据的通用语言。 这种系统的例子是 XML（可扩展标记语言），作为一种潜在的候选者（Jamshidi，2009a）。

然而，互操作性必须在许多层面上实现，而不仅仅是在数据/网络层面。 有许多描述互操作性级别的框架。 从军事应用来看，NCOIC（以网络为中心的运营行业联盟）互操作性框架（NCOIC 2008）涵盖了三个广泛的互操作性级别，细分为如下所示的更多层：

• 网络传输：
  • 物理互操作性和
  • 连接性和网络互操作性；

• 信息服务：
  • 数据/对象模型互操作性，
  • 语义/信息互操作性，
  • 行动互操作性的知识/意识；

• 人员、流程和应用程序：
  • 对齐的程序，
  • 对齐操作，
  • 统一战略/学说，
  • 政治或商业目标。

这种互操作性层的范围要求每一层都具有与 SoS 共享目标一致的适当一致性。

在其他活动领域存在互操作性框架。 一个例子是欧洲互操作性框架（European Commission 2004），它侧重于实现商业（尤其是电子商务）互操作性，并在政治背景下分为四个层次：

• 法律互操作性，
• 组织互操作性，
• 语义互操作性，
• 技术互操作性。

SoS 的组件系统之间的互操作性是 SoS 的基本设计考虑因素，可以通过应用标准进行管理。

Systems_of_Systems_(SoS)的社会技术特征

Ackoff (1971) 可能是最早提到Systems_of_Systems_(SoS)，描述了一个主要与组织有关的概念，即社会。 然而，本节关注的是技术 SoS 的社会技术方面，这些方面由相互依赖的资源组成，例如人员、流程、信息和技术，这些资源相互之间以及与环境交互以支持共同的使命。词汇表）。

Systems_of_Systems_(SoS)的社会技术性质

Rebovich (2009) [ 抓住了 SoS 问题的本质：

“从单系统社区的角度来看，它是 SoS 能力的一部分，代表了额外的义务、约束和复杂性。 从单系统利益相关者的角度来看，参与（原文如此）SoS 很少被视为净收益。”

Dahmann (2015) 确定的三个持续存在的 SoS 挑战或痛点与利益相关者视角的问题以及以牺牲或损害整体 SoS 性能为代价的组成系统性能的局部优化直接相关。 它们是：SoS 权威、领导和自治、相互依存关系和出现。 因此，影响决策和人类行为的社会学方面必须与 SoS 的技术方面给予相似的重视。

转向系统工程之外的观点，人体工程学专家认为社会技术系统具有以下特征（Maguire，2014）：

• 有集体作战任务，
• 它们包含社会和技术子系统，
• 它们是开放系统（即与环境有很强的交互作用），
• 系统的概念是一个未完成的系统。

这些也是Systems_of_Systems_(SoS)的特征。 Klein (2014) 指出，研究社会技术系统的方法可以采取“系统影响人”或“人影响系统”两个视角，这取决于 系统边界的绘制方式 。 对于考虑其环境需要考虑社会技术方面的系统来说，这通常是正确的。

尽管主要关注 IT 系统，但 Baxter 和 Sommerville (2011) 指出，新业务 SoS 的引入通常与变更过程一起进行。 他们认为，社会和组织方面经常是破坏性的，并且对变革过程和系统开发过程之间的联系关注不足。 他们提出了两种类型的社会技术系统工程活动：

• 宣传和意识活动，旨在使利益相关者对其他利益相关者的担忧敏感。
• 建设性的参与活动，主要关注准确和有意义地推导需求。

这些活动的有效性可能会受到 SoS 中组成系统的独立管理或操作的挑战。

尽管有很多关于 SoS 的社会技术方面的问题，但有两个重要的问题需要她处理。 首先是需要适当的治理结构，因为运营和/或管理独立性会影响 SoS 自上而下的方向，并可能会影响 SoS 目标的实现。 第二个问题是管理者、运营商或 SoS 的其他利益相关者缺乏态势感知，因此他们可能不了解当地决策对更广泛的 SoS 的影响。

SoS 治理

一般来说，复杂系统的设计和操作都与控制有关，但 SoS 的分类（Dahmann 等人，2008 年）是基于减少中央控制的概念，因为类型从定向到虚拟。 索瑟等。 人。 (2009) 描述了“SoS 的控制悖论”，并断言对于 SoS，“管理”被“治理”所取代。 '控制是规则、时间和带宽的函数； 而指挥是信任、影响力、忠诚度和敏捷性的功能”。

一些从业者发现由 David Snowden 开发的 Cynefin 框架有助于理解 SoS 中可能出现的复杂性的本质。 从知识管理的考虑出发，Kurtz 和 Snowden (2003) 提出了为什么涉及人的系统的行为可能难以预测的三个原因。 首先，人类并不局限于一个身份，因此使用规范对人类行为进行建模可能并不可靠。 其次，人类不限于按照预定规则行事。 第三，人类不限于按局部模式行事。 这些原因都破坏了控制，因此 SoS 的社会学方面使他们的行为难以预测，甚至可能是不确定的。 Cynefin 框架将系统分为四个领域：

• 已知——具有可预测和可重复因果关系的简单系统
• 可知的——服从于系统思维和分析/还原论的方法
• 复杂的——因果关系只能在回顾中辨别并且不会重复的自适应系统
• 混乱——没有因果关系是可感知的

不同类型的 SoS（定向的、承认的、协作的和虚拟的）都可以在上述任何领域中描述，这取决于 SoS 内部的许多因素，但在所有情况下，它都是社会技术 SoS 的社会学元素这最有可能在预测行为时引起歧义。

SoS 的一个主要治理问题是了解风险的所有权并做出可靠的风险估计（Fovino & Masera，2007）。 高水平的连通性以及由于单独拥有/运营的组成系统的相互作用而导致的紧急行为的可能性，意味着重大风险可能未被承认，其缓解措施也可能计划外。

一般来说，治理可以通过提出三个相互关联的问题来总结（Siemieniuch 和 Sinclair，2014 年）：

• 我们是否在做正确的事情（领导力）？
• 我们做这些事情正确吗（管理）？
• 我们如何知道这一点（指标和测量）？

目前，没有公认的框架可以在 SoS 环境中解决这些问题，但 Henshaw 等人。 人。 (2013) 强调架构是可以澄清治理的重要手段。 他们假设 SoS 可以被视为系统之间的一组信任和合同关系（即包括非正式和正式关系）。 因此，组成Systems_of_Systems_(SoS)架构师必须解决整个企业中每个参与组织的信任问题，他/她的系统必须与之互操作。 对于 SoS，技术工程治理涉及定义和确保在组成系统之间的接口处遵守信任。Cassini-Huygens 任务案例研究中提供了在 SoS 中管理接口的困难示例 .

情景意识

情景意识是决策者对他/她做出决策的环境的理解； 它涉及信息、意识、感知和认知。 Endsley (1995) 强调情景意识是一种知识状态。 由于一个组成系统的运营商基于对整体 SoS 的不充分了解（大图）做出决策，导致 SoS 失败的例子不胜枚举。

另一方面，SoS 开发也被视为提高态势感知能力的手段（Van der Laar 等人，2013 年）。 在国防环境中，网络使能能力（NEC）是一种系统方法，其目的是为了更好地利用信息共享来实现军事目标。 NEC 以在需要信息的利益相关者之间有效共享有用信息的能力为基础。 得出的结论是，提高态势感知将提高 SoS 性能，或者至少降低 SoS 级别的故障风险。 因此，管理 SoS 组织的原则应支持跨网络有效共享信息； 从本质上讲，确保 互操作性范围的每个级别得到充分的服务。 运营商需要深入了解他们自己的本地决策可能对不断变化的 SoS 或环境产生的影响； 同样，他们需要了解外部变化将如何影响他们拥有的系统。

SoS 越来越多地包括具有高水平自主决策能力的组成系统，这是一类可以被描述为（系统的）网络物理Systems_of_Systems_(SoS)。 Henshaw (2016) 描述了与 SoS 的关系。 问题的出现是因为自治会降低人类对 SoS 行为的态势感知能力，而且由于缺乏合适的人类模型，SoS 内的自治系统的态势感知能力不足（Sowe，2016 年）

能力工程

能力 越来越多地被用来描述运营能力的系统工程。 INCOSE UK Capability System Engineering Guide（Kemp 和 Daw）基于此分析并描述：

• 能力是通过人员、流程、信息和设备的组合来实现的；
• 他们关心的是交付成果，而不是产出；
• 它们经久不衰，能力得到升级而不是替换；该术语于 2000 年初出现在国防领域，但其概念可以追溯到更早的时期（Checkland，1997）。
• 能力系统工程的概念已用于铁路（Dogan，2012）和医疗保健（皇家工程学院，2017）。

在许多工业部门中被广泛使用，并且已经开始在这些部门甚至内部具有各种特定含义。 基于能力的获取、能力工程和管理、生命能力管理、能力发起人等术语现在在国防和其他地方无处不在。 亨肖等人。 (2011) 已经确定了至少八种能力和能力工程的世界观，并得出结论认为，能力工程的任务在不同社区中的定义不一致。

能力系统工程的目的是确保升级后的能力满足利益相关者的需求。 良好的能力系统工程提供了清晰的视野，从能力的目的，到操作概念和整个系统设计，再到特定的要求和接口

能力工程涉及整个生命周期； 能力权衡的“模糊前端”、传统的“V”型产品生命周期以及“混乱的服务”支持阶段。

能力系统工程使用标准的 SE 工具，从资产所有者-运营商（即军事用户或铁路运输供应商）的角度应用。

Kemp 和 Daw (2014) 指出了能力系统工程与更传统的产品系统工程之间的几个区别：

• 使用说服力和影响力与指挥和控制一样多地执行决策
• 尽可能提高灵活性，因为能力会发生变化。
• 实施向改进能力的过渡作为工程和文化变革。
• 认识到能力通常是复杂的自适应系统。 随着能力的提高，用户或竞争对手会改变他们的行为，从而降低能力的有效性。
• 能力权衡不是简单的比较，相似的事物之间——通常是新设备、更好的培训或新流程之间的选择。

能力工程与Systems_of_Systems_(SoS)之间存在着密切的关系。对某些人来说，能力是一种系统/SoS，对另一些人来说，它是系统/SoS 所做的事情。 Henshaw 等人对此进行了探讨。 (2011)，他描述了至少八种能力和能力工程的世界观

内容

• 1 SoSE 的服务视图
• 2 参考
  • 2.1 参考文献
  • 2.2 主要参考文献
  • 2.3 附加参考

SoSE 的服务视图

正如在整个Systems_of_Systems_(SoS)知识领域中所讨论的那样，“Systems_of_Systems_(SoS)”通常是从将多个系统组合在一起以提供更广泛的能力的角度来处理的。 正如系统中系统的架构方法中所讨论的，SoS 中组成系统的联网通常是 SoS 的关键部分。 在某些情况下，SoS 的全部内容都是信息，SoS 将多个信息系统整合在一起，以支持更广泛社区的信息需求。 这些' 信息技术

信息技术

基于信息技术(IT) 的 SoS 具有与其他 SoS 相同的一组特征，并面临许多相同的挑战。 目前，IT 已采用此类 SoS 的“服务”视图，并越来越多地应用国际标准化组织 (ISO) 20000 系列（信息技术 -- 服务管理）或信息技术基础设施库 (ITIL) v. 3 (OGC 2009 ) 基于信息的 SoS 的设计和管理方法。 服务视角简化了 SoSE，因为它：

• 是用户与 SoS 交互和理解的更自然的方式，
• 允许设计人员设计特定服务以满足定义的性能和有效性目标，
• 可以在整个生命周期内对特定的服务水平进行测试和监控。

尽管尚未证明它具有普遍适用性，但服务视图在 IT 和运输 SoS 中运行良好。

任务工程

本文描述了新兴的任务工程概念，尤其是在美国国防部正在实施的过程中。 任务工程与Systems_of_Systems_(SoS)密切相关，因为大多数任务是通过多个系统的协调和互操作性来完成的。 本文定义了任务工程并描述了任务工程中涉及的系统工程活动。

任务工程的定义

任务工程 描述了系统工程在任务的规划、分析和设计中的应用，其中任务是感兴趣的系统。 任务工程分析任务目标和线程，分​​析可用以及新兴的操作和系统能力，并设计任务架构以实现任务目标（Gold，2016）。 因此，任务工程必须同时考虑运营、技术和采购问题及其集成，以设计实现任务目标的解决方案（Van Bossuyt 等人，2019 年）。 最后，“任务”一词通常用于军事环境，大多数任务工程都是针对军事系统的。 但是，该术语及其描述的过程和知识可以应用于太空任务或其他任务领域。

任务几乎总是由多个系统协调它们的行动和共享数据来执行。 我们将这些称为面向任务的Systems_of_Systems_(SoS)。 理想情况下，以任务为导向的 SoS 可以由作战指挥官快速构思、组装和部署，以应对直接威胁。

定义和原则

任务描述了系统将做什么以及这样做的目的。 使命宣言描述了吉卜林的“六个诚实的仆人”——谁、什么、何时、何地、为什么，有时如何（Kipling 1902）。 该任务为定义有效性措施和制定作战概念（CONOPS）提供了背景。

任务由完成一项或多项操作活动的操作节点完成。 操作节点可以是组织、个人或系统。 操作活动是将一个或多个输入转换为输出或改变系统状态的操作。 系统通过执行操作活动来提供能力。

任务工程活动

以下是任务工程的主要活动：

任务能力分析和定义 ——工程师分析问题场景以确定需要哪些能力并为任务制定 CONOPS。

任务线程定义 ——工程师分析端到端的操作活动集。 起点是对运营活动、它们的排序以及它们之间的信息流进行建模。 对于军事系统，任务线程通常是一个杀伤链，描述了从搜索威胁到参与威胁的活动顺序。

权衡分析 ——工程师开发完成任务的替代方案，并进行贸易研究以确定给定资源和可用时间的最佳替代方案。

任务架构 ——工程师开发一个操作架构，描述能力、操作活动、操作节点和其他相关元素来模拟任务。

需求工程 ——工程师从能力分析、CONOPS 和任务线程中确定功能和非功能需求。 工程师将需求分配给操作节点。 在许多情况下，操作节点中的系统可能需要工程来满足要求。

互操作性分析 ——完成任务的系统之间的互操作性必须发生在操作和技术层面（Giachetti et al. 2019）。 操作互操作性描述了系统协调其活动以支持任务线程完成的能力。 技术互操作性描述了系统交换数据的能力，同时考虑到数据的及时性和质量。 互操作性分析对系统产生额外的要求。

面向任务的 SoS 实施 ——面向任务的 SoS 必须通过设计和开发新系统、修改现有系统和/或修改条令、政策、程序和其他非物质手段来实施，以帮助完成任务。

任务验证和确认 ——工程师验证交付的系统是否满足要求，并验证系统是否满足任务目的和利益相关者的需求。