新兴主题部分旨在向读者介绍并告知读者在社区内实践系统工程的重要且迅速出现的需求和趋势。它并非包罗万象。相反，涵盖了由 SEBoK 编辑委员会确定的那些极有可能对系统工程实践产生重大影响的主题。

转换导论

本 KA 涵盖的知识反映了 SE 的转型和持续发展，这是由当前和未来的挑战形成的（请参阅 系统工程：历史和未来挑战 ）。 下面简要讨论 SE 转换的概念和它所包含的其他知识领域。

INCOSE 系统工程愿景 2035 (INCOSE 2021) 描述了 SE 的全球背景、SE 实践的当前状态以及 SE 可能的未来状态。 它描述了 SE 继续发展以应对现代系统挑战的多种方式。 下面简要总结这些内容。

系统工程是从许多相关行业（特别是航空航天和国防）中使用的实践组合发展而来的。 这些已被用作任何复杂系统生命周期的标准化方法的基础（请参阅 系统工程和管理 ）。 因此，SE 实践主要基于启发式，正在努力发展系统工程的理论基础（请参阅 系统工程 基础），考虑来自各种来源的基础知识。

系统工程随着系统 复杂性 的长期增长而不断发展。 这种复杂性源于人类和社会需求、全球大趋势、重大工程挑战，然后受到利益相关者期望和企业环境的影响。 系统解决方案需要深度和广度，这些解决方案的设计必须同时考虑技术和社会方面（参见 Socio-technical 系统 ）。

许多系统工程实践已经成为标准（例如研究、风险分析），而其他一些则处于过渡阶段（例如 基于模型的系统工程 、 敏捷 、系统系统）。 最近，人工智能 (AI) 的兴起为注入 AI 的系统的验证和验证带来了前所未有的挑战，但也为在系统设计中实施 AI 方法提供了新的机会。

系统工程已获得行业、学术界和政府的认可。 然而，SE 实践因行业、组织和系统类型而异。 跨行业的系统工程实践的交叉融合已经开始缓慢但肯定地开始。 然而，全球对系统能力的需求已经超过了系统工程的进步。

INCOSE Vision 2035 的结论是，SE 准备在 21 世纪的一些全球挑战中发挥重要作用，它已经开始改变以应对这些挑战，并且它需要进行更重大的 转型 以充分应对这些挑战. 以下要点摘自 Vision 2035 的摘要部分，并定义了未来转型的 SE 领域的属性：

• 系统工程的未来是基于模型的，由企业数字化转型实现。
• 系统工程实践将在处理系统复杂性和实现企业敏捷性方面取得重大进展。
• 系统工程将利用数据科学等其他领域的实践来帮助管理数据的增长。
• 正式的系统工程理论基础将被编纂，导致下一代系统工程方法和工具的新研究和开发。
• 人工智能将影响系统工程实践和系统工程社区设计的系统类型。
• 系统工程教育将从早期教育开始，重点关注终身学习，这将发生重大变化。

SEBoK 涵盖了 SE 的一些未来方向。 随着社会经济知识领域的发展，其他知识领域需要被引入并完全整合到其中。 此 KA 将用于概述 SE 出现的这些转变方面。 随着 SEBoK 的成熟，这种变革性知识将被整合到 SEBoK 的各个方面。

SE转换简介

虽然 SEBoK 的主要关注点是领域独立系统工程的当前实践，但它也关注该领域的未来发展。

该知识领域 (KA) 中的主题总结了 SE 知识，这些知识正在出现并正在转变为系统工程实践的一部分，例如 基于模型的系统工程 (MBSE) 。 一般来说，主题将在这里介绍，然后随着时间的推移扩展到其他 SEBoK KA。

本 KA 涵盖的知识反映了 SE 的转型和持续发展。 有关促成这一演变的当前和未来挑战的摘要，请参阅 系统工程：历史和未来挑战 。 下面简要讨论 SE 转换的概念和它所包含的其他知识领域。

话题

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

• 将系统工程转变为基于模型的领域
• 2009-2018 年基于模型的系统工程采用趋势
• 数字工程
• 基于集合的设计
• Socio-technical 系统
• 系统工程与人工智能

转换

INCOSE 系统工程愿景 2025 (INCOSE 2014) 描述了 SE 的全球背景、SE 实践的当前状态以及 SE 可能的未来状态。 它描述了 SE 继续发展以应对现代系统挑战的多种方式。 下面简要总结这些内容。

系统工程是从许多相关行业（特别是航空航天和国防）中使用的实践组合发展而来的。 这些已被用作任何复杂系统生命周期的标准化方法的基础（请参阅 系统工程和管理 ）。 因此，SE 实践仍然主要基于启发式。 考虑各种来源的基础知识， 正在努力发展系统工程的理论基础（请参阅 系统工程基础）。

系统工程随着系统 复杂性 的长期增长而不断发展。 这种演变大部分集中在关注 SE 特定方面的模型和工具中，例如了解利益相关者的需求、表示系统架构或对特定系统属性进行建模。 跨领域、开发阶段和项目的集成仍然是一个关键的系统工程挑战。

系统工程正在获得行业、学术界和政府的认可。 然而，SE 实践因行业、组织和系统类型而异。 跨行业的系统工程实践的交叉融合已经开始缓慢但肯定地开始。 然而，全球对系统能力的需求已经超过了系统工程的进步。

INCOSE Vision 2025 的结论是，SE 有望在 21 世纪的一些全球挑战中发挥重要作用，它已经开始改变以应对这些挑战，并且它需要进行更重大的 转型 以充分应对这些挑战. 以下要点摘自 Vision 2025 的摘要部分，并定义了未来转型的 SE 领域的属性：

• 与广泛的应用领域相关，远远超出其在航空航天和国防领域的传统根源，以满足社会对可持续系统解决方案日益增长的需求，以在全球竞争环境中提供基本需求。
• 更广泛地应用于社会物理系统的评估，以支持政策决策和其他形式的补救措施。
• 针对“端到端”的生命周期考虑和长期风险，全面整合多个市场、社会和环境利益相关者的需求。
• 支持跨越不同组织和区域边界以及广泛领域的协作的关键整合角色。
• 由更全面的理论基础和复杂的基于模型的方法和工具支持，可以更好地理解面对不确定性的日益复杂的系统和决策。
• 通过在所有学习阶段强调系统思考和系统分析的教育基础设施来增强。
• 由越来越多的专业人士实践，他们不仅在其应用领域拥有技术敏锐度，而且还掌握了应对时代系统和集成挑战所需的下一代工具和方法。

SEBoK 涵盖了 SE 的一些未来方向。 随着社会经济知识领域的发展，其他知识领域需要被引入并完全整合到其中。 此 KA 将用于概述 SE 出现的这些转变方面。 随着 SEBoK 的成熟，这种变革性知识将被整合到 SEBoK 的各个方面。

Socio-technical 系统

尽管有一些具体的定义，但根据具体的工程/科学领域，“Socio-technical 系统”一词的使用方式有很多种。 根据生命周期阶段和具体的系统工程挑战，还有不同的方法来考虑Socio-technical 系统。

概念与理论

Socio-technical 系统的概念描述了人与机器之间的相互关系，发展Socio-technical 系统研究的动机是为了应对工业中的理论和实际工作环境问题（Ropohl，1999）。

过去 60 年来，Socio-technical 系统理论一直在发展，主要关注新技术和工作设计（Davis 等，2014）。 该理论已发展为Socio-technical 系统思维，研究集中在几个关键领域：

• 人为因素和人体工程学（Carayon，2006 年）
• 组织设计（Cherns，1976）
• 系统设计（Clegg，2000；van Eijnatten，1998）
• 信息系统（Mumford，2006 年）

一个设计方法

作为一个设计方法——Socio-technical 系统设计 (STSD)——Socio-technical 系统在组织系统的设计中引入了人、社会、组织和技术元素（Baxter 和 Sommerville，2011 年）。 虽然 Baxter 和 Sommerville (2011) 在将Socio-technical 系统思维定义为一个设计方法时将基于计算机的系统称为设计方法，但通用术语“技术系统”也适用：“Socio-technical 系统思维的基本前提是系统设计应该是一个过程，同时考虑到影响基于计算机的系统的功能和使用的社会和技术因素”（第 4 页）。

系统工程背景

在系统工程背景下，有人认为所有系统都是Socio-technical 系统（Palmer 等人，2019 年）。 然而，系统工程背景下的Socio-technical 系统并没有得到很好的定义，尽管该主题近年来受到了广泛关注（Donaldson，2017；Broniatowski，2018）。 在系统工程文献中有一些例子，其中术语Socio-technical 系统用于指代社会和技术元素相关的系统。 其中包括对基于代理的Socio-technical 系统建模的研究（Heydari 和 Pennock，2018 年）、作为社会关键系统的保险系统（Yasui，2011 年）以及影响企业系统的跨领域系统工程方法（Pennock 和 Rouse，2016 年；Wang等人，2018）。

基于系统工程社区迄今为止所做的工作，系统工程背景中Socio-technical 系统一词的工作定义很简单：

Socio-technical 系统：在社会和技术系统的交叉点运行的系统（Kroes 等人，2006 年） 。

建模Socio-technical 系统

对于如何对Socio-technical 系统进行建模，没有“实践状态”。 然而，系统工程文献中有一些关于系统工程师如何分析这些类型系统的例子。 在系统工程/工程文献之外，社会系统模型的例子越来越多。 在这些示例中发现的建模技术可用于在系统工程环境中评估Socio-technical 系统。 其中许多是系统动力学模型，并且有一本专门研究社会系统分析的期刊，称为 Journal for Artificial Societies and Social Simulation (JASS)，专注于基于代理的建模。

1) 定性建模

• 作为社会关键系统的保险系统（Yasui，2011）

Yasui (2011) 提供了一种新的方法来适应利益相关者在社会系统失败中的目标。 这种新方法是一种“软”系统方法，它结合了 Checkland 和 Scholes (1990) 的 Holon 概念和 Vee 模型。

2) 系统工程中基于代理的Socio-technical 系统建模

• 基于代理的Socio-technical 系统建模（Heydari 和 Pennock，2018 年）

Heydari 和 Pennock (2018) 说明了如何使用基于代理的建模 (ABM) 来支持Socio-technical 系统的设计和治理。 至关重要的是，他们概述了 ABM 在物理、自然和社会应用与社会技术应用中的使用方式之间的区别。

• 影响企业系统的跨领域系统工程方法（Pennock 和 Rouse，2016 年）

Pennock 和 Rouse (2016) 不仅提供了如何将企业定义为一个系统，而且还通过几个 ABM 示例来说明这一点。 他们还强调，在对Socio-technical 系统与传统工程系统进行建模时，重要的是少关注“控制”，而多关注“影响”。

3) 经济建模

• 社会系统建模挑战（Wang 等人，2018 年）

在他们的书《社会系统工程》中，Wang 等人。 （2018 年）不仅概述了建模及其在评估社会系统方面面临的挑战，而且还深入了解了经济学中如何处理社会系统建模。

4) 社会系统的系统动力学建模以适应 SE 社会技术背景

• 社会政策（帕尔默，2017）

Palmer (2017) 概述了系统工程背景下的社会系统，并使用养老金和病假政策系统的系统动力学模型来说明如何将系统工程方法用于社会政策。

• 社会系统工程（García‐Díaz 和 Olaya，2018 年）

García‐Díaz 和 Olaya (2018) 在他们的书（称为社会系统工程）中不仅对社会系统和各种定性和定量建模类型进行了全面概述，而且还强调了参与式系统动力学建模（利益相关者主导的系统设计）。

• 医疗保健（Homer 和 Hirsch，2006 年）

随着系统工程界越来越关注医疗保健技术，Homer 和 Hirsch（2006 年）关于公共卫生系统动力学建模的论文为如何在该领域建模社会系统提供了基础。 例如，慢性病预防、疾病结果、健康和风险行为、环境因素以及与健康相关的资源和交付系统。

人工智能

本文提供了人工智能和机器学习的概述和定义，以及它们对系统工程的重要性和与系统工程的关系。

介绍

人工智能 (AI) 最好的定义可能是系统表现出行为的能力，如果由人类表现出来，就会被认为是智能的。 它是机器处理和从数据中学习、识别和理解模式、解决问题和自主做出决策的能力。 “人工智能”一词可以追溯到 1950 年代初，当时它首次被引入以模拟软件和硬件系统中的人类智能能力——尽管人工智能领域的技术进步很快，但在不久的将来，这个目标仍然遥不可及. 系统工程师需要注意的是，“AI”并不指代特定的技术——智能行为可以通过多种方式在系统中实现，包括传统的软件或硬件逻辑。 使用人工智能的现代系统分为两大类：决策逻辑明确预编程的系统，以及从数据中学习决策能力的系统。 后一类称为机器学习 (ML)，是 AI 支持的现代能力范式转变的主要类别。

人工智能的机器学习基础

ML 建立在统计学和计算机科学学科的基础之上，现代硬件系统（即 CPU 和 GPU）提供的计算能力和内存的进步加速了机器学习。 当今可用的 ML 算法数量不断增加，可分为监督、无监督和强化学习三大类。

• 监督学习是标记输入-输出数据集可用的地方，ML 算法学习数据集中呈现的输入-输出对之间的映射（例如，从清晰标记的汽车和坦克图片中学习）
• 无监督学习是指数据集中的标签不可用，机器学习算法学习输入和输出的分组或聚类（例如，识别常见的客户属性、分类垃圾邮件或检测欺诈交易）
• 强化学习是人工智能代理训练自己根据定义的奖励函数做出决策以影响环境的积极变化（例如，训练机器人通过惩罚碰撞来避开障碍物）

所有 ML 类型的实现方法都需要大型数据集，并且可以基于统计模型或神经网络，包括深度神经网络 (DNN)。 无论实施方法和 ML 的类型如何，部署基于 ML 的 AI 解决方案的工作流程在很大程度上仍然很常见，如图 1 所示（有关这些步骤的详细信息，请参阅 Thomas Siebel 的数字化转型书籍）。

图 1 典型的 ML 工作流程

随着系统工程师开始将 ML 解决方案整合到系统中并为 AI 系统执行系统工程活动，了解用于 ML 实施的统计模型和神经网络的微妙之处以及相关工作流程将变得势在必行。

系统工程师和人工智能

鉴于系统工程领域的整体性，考虑人工智能及其在更大的数字化转型背景下的作用是切实可行的，数字化转型可以定义为大数据、云计算、人工智能和物联网 (IoT) 的融合. 数字化转型使组织能够发展其业务和运营模式。 因此，大多数组织都在收集与其业务、运营、系统、客户和人员有关的大量数据。 大数据创造了需要应用人工智能解决方案的条件，这些解决方案得到了计算能力和内存技术进步的支持，以帮助分析大数据以及实现劳动密集型和耗时过程的自动化。

与数据科学家、人工智能工程师、云计算专家、应用程序开发人员和其他专家协作和沟通的能力正在成为许多系统工程师的必需品。 系统工程师必须对数字化转型生态系统的尽可能多的元素有足够的知识和熟悉，以最好地满足组织的需求及其使命，以确定最能从人工智能应用中受益的业务领域或系统. 了解 AI 开发计划的好处和潜在缺陷也很重要。 为此，系统工程师必须能够识别正确的需求和架构、专业知识、合作组织、技术堆栈、开发平台和其他相关元素。 必须区分系统工程师与数据科学家、数据工程师、应用程序开发人员和 AI 工程师的角色和职责。 市场上充斥着越来越多的人工智能平台，非数据科学家几乎不可能掌握其中的每一个。 此外，人工智能领域的发展速度如此之快，以至于现在许多公司可能会选择避免投资自己的内部数据科学团队来开发人工智能解决方案。 相反，他们可以从以前解决过类似问题的公司购买或许可实施的模型。 此外，还有旨在标准化工作流程并配备适当的技术堆栈来收集、标记、

因此，与其反映数据科学家和其他 AI 领域专业人员的角色和职责，大多数系统工程专业人员对支持和用于创建 AI 应用程序的相关技术有不同程度的了解是有益的包括但不限于以下内容：

• 数据整合
• 关系和非关系数据库
• 云储存
• 企业架构基础设施和 API
• 机器学习学习框架
• 批处理和在线处理
• 可执行环境
• 常用的编程语言
• UI 和数据可视化工具

系统工程和人工智能：SE4AI 和 AI4SE

在 2019 年初由国际系统工程委员会 (INCOSE) 主办的系统工程未来 (FuSE) 研讨会上，AI for SE 和 SE for AI 两个术语首次用于描述为 SE 和 AI 领域设想的双重转型。 “AI4SE”和“SE4AI”标签已迅速成为 SE 社区即将到来的快速进化阶段的象征。 SE 的数字工程转型将支持使用 AI for SE 对 SE 实践进行转型，并推动对支持新一波自动化、自适应和学习系统（称为 SE for AI）的新系统工程实践的需求。 AI4SE 应用 AI 和 ML 技术来改进人类驱动的工程实践。 “增强智能”的这一目标包括实现模型构建的规模和设计空间探索系统的效率等成果。 SE4AI 将 SE 方法应用于智能系统的设计和操作，其成果包括提高安全性、安保、道德等。

系统工程师长期以来一直在寻求改进工程系统，以包括类人智能、思维和自主决策。 在许多情况下，包含智能功能意味着系统行为的不确定性增加，此类系统的设计、验证和确认的复杂性呈指数级增加。 灌输智能的最初方法主要涉及从专家那里获取知识的人在回路中，以机器可理解的某种形式对其进行编码（例如，“知识数据库”），并使系统能够解释编码的知识从而做出所需的最优决策并表现出所需的智能行为。

更近的当代方法代表了系统中灌输智能的下一次演变，其中人类收集所需的数据并对系统进行编程，以便系统可以从人类提供的数据中学习/构建知识。 从数据中学习需要大量的计算资源（处理能力和内存），但最近的进展已经扩展了大量源数据和匹配计算资源的可用性，以实现密集处理和从数据中学习。 最近的机器学习算法就是这种演变的结果。 该系统在设计和开发阶段进行学习，并有望展示有限形式的自适应行为。

在这两种方法中，人类都在循环中验证系统获得的智能，并有意识地决定在系统中部署智能。 预计下一次进化将主要基于系统从与之交互的其他系统中学习（机器对机器学习），并从交互和生态系统（云）中构建其智能。 从最近在强化学习模型和算法方面取得的一些进展可以看出，朝着这个方向发展。 系统通过反复试验进行学习，一旦达到性能预期，就可以在更大范围内应用其行为。

上述增强智能场景将需要 SE4AI 和 AI4SE 的基础和协同基础，以下小节将对此进行简要描述。

SE4AI：解决人工智能的实际实施挑战

人工智能在系统中的日益应用对系统工程界和人工智能界都提出了挑战。 他们的共同目标是确保系统的未来用户可以确定该系统的行为和性能是所需要的。 也就是说，人工智能系统的行为是通过一组活动来验证的，这些活动检查其是否符合系统要求并验证其是否适合满足用户需求。 验证和确认的需求对人工智能系统的工程提出了挑战，因为在人工智能系统中观察到的故障模式是不同的，并且可能无法通过传统的系统工程生命周期方法充分解决。 从系统工程生命周期的角度来看， 需要对传统流程进行适当的剪裁以“设计”一个智能系统——一个在开发过程中学习并为适应行为而设计的系统。 需要新的方法来开发需求，评估这些智能系统何时准备好运行，并确保它们的自适应行为是安全的并产生预期的结果。 使系统获得所需情报所需的数据带来了一些挑战，从有偏见（灌输反映在系统行为中的有偏见的情报）到不能代表系统设想的各种用例场景。 系统的智能仅与用于训练它的数据一样好。 在设计安全有效的人机交互与智能系统这一更广泛的挑战方面，有许多考虑因素。 这些包括（a）利用人类和人工智能的认知优势，（b）获得信任，（c）可解释的智能（d）识别和理解偏见，以及（e）处理不确定性。

总的来说，智能系统的系统工程面临三个关键挑战：

1. 以前在系统工程中没有经历过的新故障模式。 AI 社区认识到，有五种主要故障模式会导致 AI 系统无法按预期安全运行。 这些新的失败模式包括负面影响、奖励黑客攻击、可扩展的监督、不安全的探索和分布转移。
2. 由于不确定性和不断变化的行为，性能的不可预测性。 ML 系统最初从预先确定的数据中学习，并通过验证活动，系统工程师检查系统性能是否符合其预期目的，并在系统规范中捕获。 AI（尤其是 ML）面临的挑战是预测 AI 算法在未来操作中对看不见的数据的性能和行为。 ML 系统表现出不确定的性能，一些系统的性能随着系统在操作期间学习（改变性能）而发展。 这对在系统进入操作之前验证系统合规性提出了挑战。
3. 对未来系统性能缺乏信任和稳健性。 系统验证 基于基本的四步方法：从验证测试中获取结果，将测量结果与预期结果进行比较，推断合规程度，并确定该合规的可接受性。 决定合规性可接受性的一个关键方面是专家判断。 与使用背景的相关性相比，专家判断需要对结果的理解，因此结果需要是可解释的。 人工智能系统的可解释行为是有问题的，因此确定未来系统性能的信任度和稳健性水平具有挑战性。

AI4SE：利用人工智能推进系统工程的最新技术

预计 SE 实践的下一次发展将主要由 AI 技术驱动，以协助系统工程师进行工程开发生命周期活动。 AI4SE 解决了 AI 如何在各个生命周期阶段（包括概念开发、需求、架构设计、实施、集成、验证、确认和部署）增强工程系统的系统工程生命周期。 增强和协助系统工程流程、方法和工具，对工程系统的质量以及各种生命周期活动的周期时间产生切实影响，将是 AI4SE 的一些主要关注领域。 例如， 人工智能技术可以用来为系统架构师提供各种架构和设计决策选项的建议，这些信息基于从早期系统中做出的决策的集体先前经验构建的智能。 第二个例子是利用人工智能技术在验证过程中帮助到达各种角落测试用例。 历史系统工程生命周期数据将是在此类应用中使用 AI 的主要驱动力。 第三个示例涉及模拟方面，其中利用数字和合成环境（例如，数字双胞胎）来了解各种生命周期操作场景，并为系统工程师提供更好的见解，以了解架构设计决策对工程系统的影响。 然而， AI4SE 社区中正在设想一些形式的区别，以反对各种 SE 生命周期工件和工作产品的自动化、数字化和数字链接。 虽然人工智能可能会增强自动化和数字化活动，但这些活动可能仍由传统软件主导，其结果集中在显着缩短生命周期时间和管理规模的效率上。

人工智能在工业和系统中的应用前景

在过去的几十年里，基于机器学习的解决方案在技术和社会系统中无处不在，并带来了新的商业机会甚至新的商业模式。 人工智能的快速商业化正在给所有市场带来深刻的变化。 鉴于人工智能工具和平台的数量不断增加，能力正在进步，开发和实施人工智能解决方案变得越来越容易。 每个行业领域的组织都越来越意识到人工智能是市场领导地位的关键，并且他们都有适合人工智能的流程。 人工智能的早期采用者已经注意到了显着的实实在在的好处，并且鉴于目前存在的较低准入门槛，其他人正在进行重大投资以加速他们的人工智能采用。

人工智能正在被集成到业务和系统的结构中，并且正在部署人工智能解决方案来解决企业每一层的广泛用例。 下表提供了跨不同领域和部门的人工智能应用示例。

致谢

该文章由 INCOSE 的 AI 工作组提供，包括目前正在开发的面向系统工程师的 AI Primer 的摘要部分。 面向系统工程师的 AI Primer 将为 AI 领域及其对系统工程的影响提供更广阔的视野。 AI 工作组感谢（按字母顺序排列）Barclay Brown、Tom McDermott、Rael Kopace、Ramakrishnan Raman、Ali Raz 和 Kevin Robinson 对本文的贡献。

以人工智能为关键元素的系统的验证和确认

正在考虑将人工智能 (AI) 作为关键要素的许多系统。 AI 元素的故障可能导致系统故障（Dreossi 等人 2017），因此需要 AI 验证 和 确认 (V&V)。 包含人工智能功能的元素被视为一个子系统，并且在该子系统及其与所研究系统的其他元素的接口上进行 V&V，就像在其他子系统上进行 V&V 一样。 也就是说，对于包含一个或多个 AI 元素的系统，V&V 的高级定义不会改变。

然而，人工智能 V&V 挑战需要超越传统或传统（没有人工智能元素）系统的方法和解决方案。 本文概述了机器学习组件/子系统如何“适应”系统工程框架，确定了在其 V&V 中带来挑战的 AI 子系统的特征，阐明了这些挑战，并提供了一些潜在的解决方案，同时指出了开放或持续的研究领域在 AI 子系统的 V&V 中。

基于 AI 的系统的 V&V 概述

传统系统是通过 3 个总体阶段进行设计的，即需求、设计和 V&V。 这些阶段适用于每个子系统和研究中的系统。 如图 1 所示，即使子系统基于 AI 技术也是如此。

图 1. 包含机器学习和传统子系统的系统的系统工程阶段。 （SEBoK Original，仿照（Kuwajima et al. 2020））

基于人工智能的系统遵循与传统系统不同的生命周期。 如图 2 所示的一般机器学习生命周期所示，V&V 活动贯穿整个生命周期。 除了分配给 AI 子系统的要求（如传统子系统的情况）外，还可能存在对从 AI 子系统流向系统的数据的要求。

图 2. 一般 AI 生命周期/工作流程。 （SEBoK 原创）

导致 V&V 挑战的 AI 特征

尽管传统系统的 V&V 的某些方面无需修改即可使用，但 AI 子系统的一些重要特征导致其验证和确认面临挑战。 在对工程师的一项调查中，Ishikawa 和 Yoshioka（2019 年）确定了机器学习的属性，这些属性使相同的工程变得困难。 根据接受调查的工程师，带有工程师评论摘要的顶级属性是：

• 缺乏预言机：很难或不可能明确定义系统输出的正确性标准或每个单独输入的正确输出。
• 不完美：人工智能系统本质上不可能 100% 准确。
• 未经测试的数据的不确定行为：系统将如何响应未经测试的输入数据的行为存在很大的不确定性，这可以从输入的微小变化（例如对抗性示例）的行为发生根本变化来证明。
• 行为对训练数据的高度依赖：系统行为高度依赖于训练数据。

这些属性是人工智能本身的特征，可以概括如下：

• 决定论的侵蚀
• 单个输出的不可预测性和不可解释性（Sculley 等人，2014 年）
• 算法的意外、紧急行为和意外后果
• 算法的复杂决策
• 针对输入的微小变化难以保持一致性和弱点（Goodfellow et al., 2015）

人工智能系统的 V&V 挑战

要求

人工智能需求和人工智能需求工程方面的挑战是广泛的，部分原因是一些人将人工智能元素视为“黑匣子”（Gunning 2016）。 形式化规范已经被尝试过，并且已经证明对于那些难以形式化的任务来说是困难的，并且需要决定使用定量或布尔规范以及使用数据和形式化需求。 这里的挑战是设计有效的方法来指定使用基于 AI 或 ML 的组件的系统的期望和不期望属性（Seshia 2020）。

Belani 及其同事（2019 年）概述的 AI 需求工程挑战分类如表 1 所示。

CACE：改变一切，改变一切

GORE：面向目标的需求工程

数据

数据是人工智能能力的命脉，因为它被用来训练和评估人工智能模型并产生它们的能力。 除了可用性、安全性和隐私、可访问性、问责制、可扩展性、无偏见等之外，对 AI 重要的数据质量属性还包括准确性、时效性和及时性、正确性、一致性。 如上所述，无监督方法的正确性嵌入在训练数据和环境中。

存在训练数据覆盖操作空间的问题。 如果数据没有充分覆盖操作空间，那么 AI 组件的行为是有问题的。 但是，对于数据集何时“足够大”并没有强有力的保证。 此外，“大”是不够的。 数据必须充分覆盖操作空间。

数据的另一个挑战是对抗性输入。 塞格迪等人。 (2014) 发现几个 ML 模型容易受到对抗性示例的攻击。 这已在图像分类软件上多次展示，然而，对抗性攻击可以针对其他 AI 任务（例如，自然语言处理）和针对神经网络以外的技术（通常用于图像分类），例如强化学习（例如，奖励黑客）模型。

模型

模型空间中出现了许多 V&V 挑战，下面提供了其中一些挑战。

• 环境建模：未知变量，确定建模的正确保真度，建模人类行为。 挑战问题是提供一种系统化的环境建模方法，即使在环境存在相当大的不确定性时，它也可以为系统的行为提供可证明的保证。 （塞希亚 2020）
• 建模学习系统：非常高维输入空间、非常高维参数或状态空间、在线适应/进化、建模背景（Seshia 2020）。
• 模型和数据的设计和验证：数据生成、定量验证、组合推理和组合规范（Seshia 2020）。 挑战在于开发不依赖于完整的组合规范的组合推理技术（Seshia 2017）。
• 优化策略必须在过度规范和规范不足之间取得平衡。 一种方法不是使用距离（预测结果和实际结果之间）度量，而是使用错误结果（例如，错误分类）的成本作为标准（Faria，2018）（Varshney，2017）。
• 在线学习：需要监控； 需要确保其探索不会导致不安全状态。
• 形式化方法：由于软件的复杂性和系统与其环境的交互而导致的难以处理的状态空间爆炸，这是形式化规范的一个问题。
• 来自代表性不足或不完整的训练数据或依赖反映历史不平等的有缺陷信息的算法 偏差。有偏见的算法可能会导致具有集体不同影响的决策。 在减轻算法偏差的公平性和准确性之间进行权衡。
• 测试覆盖率：AI 组件测试覆盖率的有效指标是一个活跃的研究领域，有几个候选指标，但目前还没有明确的最佳实践。

特性

确保几个 AI 系统属性对于启用对系统的信任是必要的，例如，系统的可信度。 这是 AI 系统的系统可靠性的一个独立但必要的方面。 下面列出了一些重要的属性，虽然范围很广，但并不全面。

• 问责制：指人工智能系统需要对其决策、行动和性能负责，以及对用户和与人工智能系统交互的其他人负责
• 可控性：指人类或其他外部代理干预人工智能系统运行的能力
• 可解释性：指人工智能系统表达影响人工智能系统结果的重要因素或提供其运作背后的细节/原因以便人类理解的属性
• 可解释性：指人类能够理解决策原因的程度（Miller 2017）
• 可靠性：指一致的预期行为和结果的属性
• 弹性：指系统在事件发生后迅速恢复操作的能力
• 鲁棒性：指系统在执行过程中发生错误时保持其性能水平并在错误输入和参数的情况下保持该性能水平的能力
• 安全：指免于不可接受的风险
• 透明度：指需要描述、检查和再现人工智能系统做出决策的机制，并将其传达给相关的利益相关者。

V&V 方法和标准

V&V 方法

在深度学习普及之前，对神经网络的 V&V 的研究涉及对现有标准的适应，例如当时的 IEEE Std 1012（软件验证和验证）过程（Pullum 等人，2007），需要扩大领域启用 V&V (Taylor 2006)，以及用于具有神经网络的高保证系统的 V&V 示例 (Schumann et al., 2010)。 虽然这些书籍提供了技术和经验教训，其中许多仍然相关，但深度学习带来的其他挑战仍未解决。

挑战之一是数据验证。 人工智能所依赖的数据必须经过 V&V。 对 AI 系统很重要的数据质量属性包括准确性、流通性和及时性、正确性、一致性、可用性、安全性和隐私性、可访问性、问责制、可扩展性、无偏见以及状态空间的覆盖范围。 数据验证步骤可以包括文件验证、导入验证、域验证、转换验证、聚合规则和业务验证（Gao et al. 2011）。

AI 组件的 V&V 有多种方法，包括形式方法（例如形式证明、模型检查、概率验证）、软件测试、基于仿真的测试和实验。 一些具体的方法是：

• 用于测试 ML 算法的变形测试，解决预言机问题 (Xie et al., 2011)
• ML 测试分数，包括特征和数据测试、模型开发和 ML 基础设施测试以及 ML 监控测试（Breck 等人，2016）
• 检查与期望行为的不一致并在测试与规范的一致性时系统地搜索最坏情况的结果。
• 确证验证（Webster et al., 2020），其中几种验证方法在不同的抽象级别上工作并应用于同一 AI 组件，可能证明对验证系统的 AI 组件有用。
• 针对强对抗性攻击的测试（Useato，2018）； 研究人员发现，模型可能对弱对抗性攻击表现出鲁棒性，而对强攻击几乎没有准确性（Athalye et al., 2018, Uesato et al., 2018, Carlini and Wagner, 2017）。
• 使用形式验证来证明模型与规范一致，例如 (Huang et al., 2017)。

• 将 V&V 和其他活动的结果作为证据的保证案例，以支持关于具有 AI 组件的系统保证的主张（Kelly 和 Weaver，2004；Picardi 等人，2020）。

标准

标准制定组织 (SDO) 正在认真制定人工智能标准，包括人工智能系统的安全性和可信赖性。 以下只是一些 SDO 及其 AI 标准化工作。

ISO 是第一个成立专家组开展人工智能标准化活动的国际 SDO。 小组委员会 (SC) 42 是 ISO/IEC JTC 1 联合技术委员会的一部分。SC 42 有一个基础标准工作组，以提供框架和通用词汇表，以及其他几个关于人工智能系统计算方法和特征的工作组、可信度、用例、应用程序和大数据。 （ https://www.iso.org/committee/6794475.html ）

IEEE P7000 系列项目是 2016 年启动的 IEEE 全球自主和智能系统伦理倡议的一部分。IEEE P7009，“自主和半自主系统的故障安全设计”是该系列中的 13 个标准之一。 （ https://standards.ieee.org/project/7009.html ）

美国保险商实验室从事技术安全工作已有 125 年历史，已发布 ANSI/UL 4600《自主产品评估安全标准》。 (https://ul.org/UL4600)

SAE G-34，航空人工智能委员会负责创建和维护 SAE 技术报告，包括标准，与人工智能技术相关的实施和认证方面，包括任何用于航空航天安全运行的机载或非机载系统系统和航空航天器。 （ https://www.sae.org/works/committeeHome.do?comtID=TEAG34 ）

将系统工程转变为基于模型的领域

系统工程师一直利用多种模型，包括支持需求开发的功能模型，分析系统行为的仿真模型，以及分析系统各个方面的分析模型，如可靠性、安全性、质量特性、功耗、和成本。 然而，该领域仍然严重依赖基于文档的工件来捕获大部分系统规范和设计信息，例如需求、接口控制文档和系统架构设计描述。 此信息通常分布在许多不同的文档中，包括文本、非正式绘图和电子表格。 这种基于文档的系统工程方法缺乏精确性，从一个工件到另一个工件的不一致，

基于模型的系统工程

基于模型的系统工程 (MBSE) 是建模的形式化应用，以支持从概念设计阶段开始并持续到开发和后期生命周期阶段的系统需求、设计、分析、验证和确认活动 (INCOSE 2007)。 MBSE 方法的一个显着特征是 模型 构成系统工程过程的主要工件。 开发、管理和控制系统模型的重点是从传统的基于文档的方法向系统工程的转变，其中重点是生成和控制有关系统的文档。 通过利用系统模型作为主要工件，MBSE 提供了提高产品质量、增强系统建模工件的重用以及改善系统开发团队之间的沟通的潜力。 这反过来又提供了减少集成和测试系统的时间和成本的潜力，并显着降低部署系统的成本、进度和风险。

MBSE 包括一组多样化的描述性和分析模型，可应用于整个生命周期，从 系统系统 (SoS) 建模到组件建模。 典型模型可能包括用于指定和设计系统的系统架构的描述模型，以及用于分析系统性能、物理特性和其他质量特性（如可靠性、可维护性、安全性和成本）的分析模型。

MBSE 已经发展了很多年。 Wayne Wymore 在他的书（Wymore 1993）中使用了 MBSE 这个术语，它提供了一种基于状态的形式，用于根据输入/输出特征分析系统，以及评估技术独立和技术依赖效用的价值函数系统。 仿真已在整个行业中广泛使用，以提供复杂系统的高保真性能分析。 功能建模的集成定义标准 (IDEF0 1993) 在 1990 年代被引入以支持基本功能建模。 一种称为增强功能流程图（Long 2000）的建模形式已被用于对许多不同类型的系统进行建模。 对象管理组 (OMG) 引入了模型驱动架构 (MDA®) (OMG 2003) 的概念，它利用基于标准的建模方法。 系统建模语言 (OMG SysML™) (OMG 2015) 于 2006 年被 OMG 采用为通用系统建模语言。 此外，2008 年 OMG 采用了 DoDAF 和 MODAF 统一配置文件 (UPDM) (OMG 2013) 来支持企业建模。 还引入了其他几种特定于领域的建模语言。

MBSE 过渡

INCOSE 系统工程愿景 2025（INCOSE 2025，第 38 页）描述了 MBSE 的当前状态如下：成熟的早期阶段类似于 CAD/CAE 的早期阶段。”

SE Vision 2025 还描述了 SE 向基于模型的领域的持续过渡，其中：“正式的系统建模是指定、分析、设计和验证系统的标准实践，并与其他工程模型完全集成。 系统模型适用于应用领域，包括用于表示系统各个方面的广泛模型。 使用互联网驱动的知识表示和沉浸式技术可以在虚拟环境中实现高效和共享的人类理解系统，涵盖从概念到开发、制造、运营和支持的整个生命周期。” 向更加基于模型的领域过渡并非没有挑战。 这需要在实践中取得进步，

INCOSE 系统工程愿景 2035（INCOSE 2035，第 33 页）指出“系统工程的未来主要基于模型”。 进一步的讨论继续进行到项目“系统工程师通常使用本体链接、基于数字双胞胎的模型资产组成特定任务的虚拟模型。这些连接的模型实时更新，提供基于虚拟现实的沉浸式设计和探索空间. 这个虚拟的全球协作空间是基于云的，通过建模即服务启用，并支持利用基于云的大容量计算基础设施的大规模模拟。存在统一的 ModSim 框架系列，使中小型企业与政府机构能够进行协作。

推进实践需要改进建模语言、方法和工具。 建模语言必须在表现力、精确度和可用性方面继续改进。 MBSE 方法，例如在基于模型的系统工程 (MBSE) 方法论 (Estefan 2008) 中强调的那些方法，一直在不断发展，但需要进一步的改进以提供一种在整个系统生命周期内对系统进行建模的严格方法，同时更能适应各种应用领域。 建模工具还必须继续发展以支持建模语言和方法，并与其他多领域工程模型和工具集成，以支持更广泛的基于模型的工程工作。 越来越多地使用建模标准，

采用 MBSE 需要熟练掌握 MBSE 应用的劳动力。 这要求组织提供包括 MBSE 方法、工具和培训的基础设施，并承诺将这种能力部署到他们的项目中。 与任何组织变革一样，必须从战略上着手，以提高这种能力并从他们的经验中学习。

与其他工程领域一样，系统工程向基于模型的领域的过渡被广泛认为对于应对与增加系统复杂性和实现生产力和质量改进相关的挑战至关重要。 SEBoK 将继续反映不断增长的知识体系，以促进这一转变。

2009-2018年基于模型的系统工程采用趋势

MBSE 倡议于 2007 年在新墨西哥州阿尔伯克基美国大使馆套房举行的 INCOSE 国际研讨会 (IW) 上启动。 第一次会议大约有 45 名 INCOSE 成员，在 IW 前两天举行。

为了更好地了解基于模型的系统工程的采用趋势，我们在 2009、2012、2014、2018 和 2019 年进行了调查。

介绍

基于模型的系统工程 (MBSE) 并不是一个新概念。 Wymore (1993) 发表了关于该主题的开创性著作。 本书介绍了 MBSE 背后的数学理论。 从那时起，工程已经从使用基于办公室的工具（例如，Harvard Graphics、Microsoft PowerPoint、Microsoft Visio 等）的基于文本的方法向一组相互关联的图形图表进行了重大转变。 这些图表通常是在具有专门图形用户界面的工具中创建的。

今天，航空工程师不再使用绘图板来创建他们的图纸——他们使用计算机辅助设计 (CAD) 工具。 同样，软件工程师很少使用 EMACS 或 Vi（文本编辑器），相反，他们使用软件 GUI，允许他们在单一环境中编码、检查语法、编译、链接和运行他们的软件。

从广义上讲， 模型 可以被认为是对现实的复制或抽象。 为此，即使是需求文档也可以被视为模型——它代表了真实系统在执行其任务或角色时应该做什么。 虽然系统工程使用模型已经很长时间了，但 MBSE 是系统工程迁移到基于计算机的图形用户界面来执行我们的分析和设计任务，就像我们的其他工程兄弟已经转移到基于计算机的图形用户界面一样。

对可用工具的讨论超出了本文的范围，SEBoK 的做法不是审查或推广特定的工具产品。 然而，公平地说，当前的 MBSE 工具分为三大类：1）使用 IDEF0（也称为 IPO）图、N2 图、功能流程图等的功能分解工具，2）面向对象的工具实施对象管理组的系统建模语言 (SysML)，以及 3) 数学建模工具。

系统工程的这种迁移可能始于 90 年代后期。 INCOSE INSIGHT 出版物宣称 MBSE 是一种新范式（INSIGHT 1998）。 Cloutier (2004) 在海军开放架构项目中解决了从瀑布系统工程方法到面向对象方法的迁移。 那时，SysML 还不存在，团队正在使用统一建模语言 (UML)，它主要是一种软件建模工具。 Zdanis & Cloutier (2007a, 2007b) 基于新发布的 SysML 解决了在系统工程中使用活动图而不是序列图的问题。 2009 年，INCOSE INSIGHT 出版物宣布 MBSE 是新范式（INSIGHT 2009）。

方法

2009 年，对象管理组 (OMG) 委托进行了一项调查，旨在告知 SysML 工作组自 SysML 首次发布以来的必要更改（Cloutier & Bone 2010）。 该调查侧重于流程而不是采用。 从 2012 年开始，INCOSE 又委托进行了三项调查，以了解采用趋势和障碍。 2012、2014 和 2018 年的调查工具保持相对不变（Cloutier 2015，Cloutier 2019a）。 2019 年 1 月，喷气推进实验室 (JPL) 举办了一次 MBSE 研讨会 (Cloutier 2019b)。 对这些参与者进行了一项调查，这些问题的目的是增加从 2018 年调查中获得的知识。 下表显示了每项调查的受访者人数。

表 1. MBSE 调查目的和回应 （SEBoK 原创）

响应和响应人口统计

每个调查都发送给不同的 MBSE 从业者群体。 表 2 显示，在 2018 年调查的 661 份回复中，有 410 份表明了他们的原籍国。 这种国际代表性类似于所有进行的调查。

表 1. MBSE 调查目的和回应 （Cloutier 2019，经许可使用）

作为人口统计数据的一部分，图 1 显示了所代表的行业。 由于“其他”类别太大，因此对数据进行了分析以更好地理解图 2。

图 1. 2018 年 MBSE 调查中代表的行业。 （Cloutier 2019a，经许可使用）

图 2. 2018 年 MBSE 调查中代表的“其他”行业。（Cloutier 2019a，经许可使用）

2018 年的调查表明，MBSE 在传统土木工程行业的应用似乎有所增加——特别是能源、基础设施和交通运输（图 2） 2018 年调查最有趣的方面之一是发现 MBSE 正在应用于系统工程的早期阶段，而在后期阶段则较少，如图 3 所示。

图 3. MBSE 更可能用于系统工程的早期阶段。 （Cloutier 2019a，经许可使用）

JPL 的问题“我们认为 MBSE 在哪里最有希望？”证实了这一点。 图 4 显示，76% 的回复表示系统/子系统架构，42% 的人认为需求分析，39% 的人认为早期概念化（注意：问题允许多个答案）。

图 4. JPL 研讨会关于“MBSE 最有希望的地方”的回应。 （Cloutier 2019b，经许可使用）

图 5. JPL 研讨会关于“管理层重视您的建模经验吗？”的回应 （Cloutier 2019b，经许可使用）

当被问及 JPL 调查的受访者是否认为他们的系统建模经验被认为是支持其组织中系统工程师职业发展的重要技能时，超过 50% 的受访者认为管理层重视他们的经验。 少数人（21%）认为他们的建模经验没有受到重视（图 5）。

主要采用趋势

本文的其余部分将着眼于从 2009 年到 2018 年的调查中确定的一些趋势。图 6 显示 MBSE 正在从国防和太空主导的实践转向其他行业，如图 4 所述。

图 6. MBSE 采用在新行业中的转变。 （Cloutier 2019a，经许可使用）

基于模型的系统工程的影响力似乎正在扩大，因为它不仅在系统工程师的范围内。 虽然系统和软件工程师在 MBSE 实践中发现了价值，但图 6 表明客户正在从 MBSE 实践中发现价值。 有趣的是，软件工程师对 MBSE 的感知价值在每次调查中都在下降。

图 7. MBSE 实践对不同项目部分的感知价值。 （Cloutier 2019a，经许可使用）

图 8. 在组织/公司内成功采用 MBSE 的障碍。 （Cloutier 2019a，经许可使用）

图 8 表明 MBSE 技能的可用性以及对变革的文化和普遍阻力不断增加。 缺乏感知价值反映了图 6 中的发现——软件和硬件工程师没有看到 MBSE 的价值。

结论

2012 年至 2018 年间进行的调查表明，MBSE 实践正在超越传统的国防和太空领域。 大多数 MBSE 从业者发现 MBSE 在概念化、需求分析和系统架构的早期项目阶段最有用。 仍然存在技能短缺，但公司/组织提供的培训较少，以提高 MBSE 技能。 系统工程师、系统工程管理人员和系统工程客户都发现使用模型执行系统工程的价值。

数字工程

美国国防部研究与发展部副部长于 2018 年 6 月发布了美国国防部 (DoD) 数字工程战略，描述了通过创建数字线程来简化 DoD 采购流程的五个目标，从而实现复杂的武器系统（DoD 2018；Zimmerman 2017）。 数字工程的关键是创建计算机可读模型来表示系统的所有方面，并支持系统在其整个生命周期中的设计、开发、制造和操作的所有活动。 这些计算机模型必须基于共享的数据模式，以便实际上数字线程集成了参与新武器系统采购的所有不同利益相关者。

与 MBSE 的关系

基于模型的系统工程 (MBSE) 是数字工程的一个子集。 MBSE 支持需求、架构、设计、验证和确认的系统工程活动。 这些模型必须与其他工程领域（如机械和电气工程）使用的基于物理的模型相关联。 数字工程面临的一项挑战是 MBSE 与基于物理的模型的集成。

数字工程的基础是以所有利益相关者之间可共享的格式表示系统数据（Giachetti et al. 2015; Vaneman 2018）。 SysML 2.0 是几个未来的发展之一，有望提供足以支持数字工程的表示。 定义实体及其之间关系的本体可用于定义与系统工程相关的概念。 这样的表示对于创建以一种有凝聚力和有用的方式将所有模型链接在一起的数字线程是必要的。

数字工程作为一种转型

对于许多组织而言，数字工程代表了他们通常进行系统工程的方式的转变（例如，参见 Bone 等人，2018 年），因为大多数组织都进行文档密集型系统工程过程。 采用数字工程需要同时改变组织执行系统工程活动的方式。 从记录需求、技术审查、架构设计等一切都将基于数字工程环境中的模型（Vaneman 和 Carlson，2019 年）。 数字线程将是有关系统数据的权威事实来源。

数字孪生

数字 孪生 是与数字工程相关但又截然不同的概念。 数字孪生是系统的高保真模型，可用于模拟实际系统。 组织将能够使用数字双胞胎在将设计更改纳入实际系统之前对其进行分析。

Set-Based 设计

Set-based 设计 (SBD) 是一种复杂的设计方法，它通过以下方式实现稳健的系统设计：1) 考虑大量备选方案，2) 在做出决策之前确定可行性，以及 3) 使用从自己的角度进行设计并使用交叉点的专家在他们各自的集合之间优化设计（Singer、Doerry 和 Buckley 2009）。 具有集成框架的基于模型的工程 (MBE)/基于模型的系统工程 (MBSE) 可以在某些情况下（即低保真模型的早期设计阶段）近实时地使用 SBD 贸易空间探索（ Specking 等人，2018a)。 本文提供了有关使用基于模型的设计来创建和评估基于集合的设计的替代方案的见解。

介绍

SBD 分析替代方案而不是单一解决方案。 集合是“两个或多个具有至少一个共同设计选项的设计点”（Specking 等人 2018b）或“设计因素的选项范围”（Singer 等人 2017 年）。 设计因素 是“影响系统级设计的解决方案参数、特性或关系”（Singer 等人，2017 年） 。 系统工程师应开发确定设计因素的集合，并将设计因素分成 集合驱动程序 或 集合修改器 . 设置驱动程序是“定义启用当前和未来任务的系统特征的基本设计决策”，而设置修改器是“添加到系统中并且可以修改以适应新任务和场景的设计决策”（Specking等人 2018b)。

SBD 并不是适用于所有情况的最佳设计方法。 SBD 在早期设计中特别有用，如果项目包含以下属性：

• 大量的设计变量，
• 设计变量之间的紧密耦合，
• 矛盾的要求，
• 允许交易的要求的灵活性，或
• 技术和设计问题没有得到很好的理解——解决方案需要学习（Singer et al. 2017）

在早期设计中，SBD 有助于为需求分析和评估设计决策提供信息（Parnell 等人，2019 年）。 定量 SBD 需要一个集成的 MBE 环境来评估限制和放松要求对可行贸易空间的影响。 例如，图 2 展示了无人驾驶飞行器案例研究的约束或放宽要求的效果，其中所有探索的设计都以橙色显示，贸易空间受非要求约束（例如，要求放宽以不影响贸易空间的物理）在蓝色，黄色的原始无人机可行交易空间，以及宽松（黑色）/受限（红色）交易空间。

图 1. 需求对无人机可行贸易空间的影响 （Parnell 等人，2019 年，经许可使用）

图 3 中的龙卷风图显示了一次一个需求分析的结果。 这使得很容易看到每个单独需求的约束/放松如何影响可行的贸易空间。 图 3 显示“Detect Human Activity at Night”和“Detect Human Activity in Daylight”需求对可行交易空间的影响最大。

图 2. 一对一需求分析的无人机案例研究结果 （Parnell et al. 2019，经许可使用）

改变需求并不总是转化为找到改进的设计。 一次分析散点图中的单个需求提供了重要信息，如图 4 中的示例图所示。仔细分析由每个变化（由不同颜色表示）创建的 Pareto Frontier 并将其与 Pareto Frontier 进行比较非常重要的原始分析。 如果最初的需求水平产生了更好的选择，那么改变（约束或放松）需求是没有意义的。

图 3. 改变最敏感的无人机要求对可行 贸易空间的影响（Specking et al. 2019，经许可使用）

此外，使用 SBD 可以为整个项目和团队增加价值。 一些优点包括：

• 实现可靠、高效的通信，
• 在流程中允许更大的并行性，在流程的早期更有效地使用子团队，
• 允许最关键的早期决策基于数据，以及
• 促进机构学习（Ward et al. 1995）。

基于系统分析集的设计贸易空间探索过程

图 4 说明了 SBD 作为系统设计和分析的概念。 此 SBD 插图包含 5 个不同的特征：

1. 首先确定业务/任务需求和系统要求；
2. 在系统生命周期的探索、概念和开发阶段，使用业务/任务需求和系统要求来执行设计和分析技术；
3. 尽可能同时进行设计和分析；
4. 通过使用可行性、性能和成本数据为需求分析提供信息； 和
5. 通过使用集合考虑大量备选方案并慢慢收敛到单点解决方案（Specking et al. 2019）。

图 4. SBD 系统设计概念框架 （Specking et al. 2019，经许可使用）

SBD 是一个社会技术过程，应该涉及来自多个团队的输入和交互，但图 6 为系统分析师提供了一个 SBD 贸易空间探索过程（Specking 等人，2019 年）。 这个八步过程对于执行早期设计特别有用（Specking et al. 2018b）。 系统分析师首先分析业务/任务需求和系统要求。 系统工程师使用这些信息以及他们自己开发的或系统和子系统团队提供的模型和模拟来开发一个集成模型。 系统工程师包括使用此集成模型评估可行和不可行替代方案的要求。 他们通过将每个设计决策视为统一（离散或连续）随机变量来探索贸易空间。 替代方案由每个设计决策中的一个选项组成。 然后系统工程师使用集成模型来评估每个备选方案并创建可行的贸易空间。 蒙特卡罗模拟是一种能够实现及时替代创建和评估过程的方法。 创建的交易空间将包括基于要求的不可行和可行的替代方案以及任何基于物理的性能模型和模拟。 系统工程师应与适当的利益相关者合作，在贸易空间产生极少数或没有可行替代方案时通知需求。 除了可行性之外，系统工程师还应该使用描述性统计和其他分析和数据分析技术来分析每个设计决策。 此信息提供了有关每个设计因素如何影响可行贸易空间的见解。 一旦交易空间包含可接受数量的备选方案，它就会按集合分类。 这是 SBD 的重要组成部分。 如果不知道设定的驱动因素或设计因素，系统工程师应该通过每个设计决策查看贸易空间以获得洞察力。 系统工程师应该使用优势分析和其他优化方法来根据有效性度量找到最佳或接近最佳的替代方案。 系统工程师应该探索剩余的集合，以获取有关可行交易空间和要求的更多见解。 这个过程的最后一部分是选择一个或多个集合以进入下一个设计阶段。 需要注意的是，这个过程包含循环。 在此过程的任何部分，系统工程师都应使用可用信息，例如来自贸易空间探索或集合评估的信息， 通知需求分析或更新集成模型。 此外，系统工程师应该使用更高保真度的模型和仿真来更新集成模型，因为它们变得可用。 关键是在“正确的”时间从“正确的”人那里获得“正确的”信息。

图 5. System Analysts SBD Tradespace 探索过程 （Specking et al. 2019，经许可使用）

系统中的系统（System of Systems）与复杂性

系统的系统通常被描述为复杂的 (Sheard, 2019) (Luzeau et al.,2011) (Simpson, 2009) (DeLaurentis, 2007) (Ireland, 2014) (Magee, 2004)，正如 系统中的系统（System of Systems）所指出的那样 (SoS) SEBoK 的知识领域。

那么对于那些寻求执行 SoS 工程 (SoSE) 的人来说，问题是如何解决/使用 SoS 复杂性？ 在 INCOSE SoS 和复杂性工作组之间的持续合作中，最近关于表征复杂性的工作已应用于 SoS，以评估 SoS 如何以及为何表现出复杂性，作为识别从复杂性社区到将系统原理应用于系统的方法的基础的系统。 这种合作是由两个社区最近在了解复杂性如何影响系统系统（Watson，2020）的概念以及可以将复杂性思维的指导原则应用于系统工程系统的概念上开展的工作所推动的。 （INCOSE，2016）

应用于系统系统的复杂性维度

系统的系统 (SoS) 如何以及为什么具有不同维度的复杂性？ 根据复杂性的维度（Watson，2019），很明显，SoS 本质上具有丰富的复杂性，如下所述。 对于每个复杂性维度，定义了维度，并简要介绍了使其受制于该维度的 SoS 的特征。 多样性“包括表征系统和/或其环境的结构、行为和系统状态变化”。 （Watson，2019）就其性质而言，SoS 由独立的系统组成。 (Maier, 1998) (ISO, 2019) SoS 可以在提供一系列行为、功能和技术方法的组成系统中表现出巨大的多样性。 SoS 由多个独立的系统组成，它们有自己的用户、管理结构、

连接性“表征系统在其功能和环境之间的连接。 这种连通性的特点是节点的数量、节点类型的多样性、链接的数量以及链接特征的多样性。” （Watson，2019 年）SoS 包括每个组成系统内、SoS 组成部分之间以及 SoS 与其环境之间的连接。 在 SoS 中经常会发现不连续性（一层或多层的连接模式中断）。 这直接链接到“交互性”和“不成比例的影响”的维度，因为连接可能导致复杂的级联交互。 适应性被定义为“主动和/或被动地改变功能、关系和行为以平衡环境和应用程序的变化以实现系统目标”的复杂系统的特征。 （沃森， 2019) SoS 由运行独立的系统组成 [3]； 因此，每个系统的运营商都有自己的参与规则，并且可以根据他们的本地目标以不同的方式对变化做出反应或适应。

多视角是指“理解复杂系统需要多个视角，其中一些是正交的”。 （Watson，2019）SoS 通常由多个独立系统组成，这些系统在 SoS 存在之前开发和运行； 因此，他们每个人都带来了自己的观点，这些观点可能与 SoS 一致，也可能不一致。 对 SoS 的理解考虑了所有这些不同的观点。 这与“多尺度”维度直接相关，因为 SoS 可能包含不同尺度的组成系统。

复杂系统行为“不能完全描述为响应系统。 复杂的系统行为包括非线性。 优化系统行为通常不能仅关注系统内的属性。” （Watson，2019 年）虽然单个系统的行为可能是可预测的，特别是当系统数量很大且具有多种内部行为时，SoS 行为可能变得不可预测。 每个组成部分都被设计为在其自身的环境中独立和安全地运行。 不考虑对自身行为、其他系统和整体 SoS 行为的潜在影响。

“复杂系统中的动力学可能有平衡状态，也可能没有平衡状态。 复杂的系统动力学具有多个尺度或循环。 复杂系统可以停留在动态系统内，也可以由于内部系统变化、外部环境变化或两者兼而有之而产生新的系统状态或状态转换。” (Watson, 2019) 在讨论行为之后，这些影响可能是动态的，会影响其他系统，或者具有导致动态复杂性的反馈循环。 值得注意的是，组成系统不仅可以独立管理，而且还可以独立运行，从而增加了动态复杂性的前景。

“复杂系统的表示可能很难以任何深度正确构建。 在资源有限的情况下，通常不可能预测复杂系统的未来配置、结构或行为。 在这些时间和信息资源的限制下，因果关系和影响网络对开发‘必要'概念模型提出了挑战。” （Watson，2019）SoS 的一个特点是边界条件很难定义，它不仅包括哪些组成系统是 SoS 的成员，还包括组成系统的哪些行为在 SoS 中发挥作用，从而表示SoS 是一个挑战。 进化是复杂性的一个维度，因为“复杂系统状态和结构（物理和行为）随时间的变化可能是由各种原因引起的。 复杂系统状态和结构可能会因复杂系统内、与环境或应用程序中的交互而发生变化。 一个复杂的系统可以具有不平衡（即非稳态）状态并继续发挥作用。” （Watson，2019 年）我们很少“开发和部署”SoS，相反，SoS 通常由现有系统组成； SoS 的变化是由一个或多个组成系统（或环境）的变化引起的，这使得 SoS 的开发成为一个进化过程。

导致不可预知行为的系统涌现是由意外涌现驱动的； “系统功能/响应中整体系统的意外属性（无论是可预测的还是不可预测的）。 给定有限的资源是不可预测的。 无法将行为描述为响应系统。” （Watson，2019 年）根据定义，SoS 由多个独立系统组成。 （迈尔，1998 年）（国际标准化组织，2019 年）。 一个系统的变化可能会导致另一个系统的新行为，从而导致不可预测的结果。 不确定的边界源于“复杂的系统边界与其环境和其他相互作用的系统错综复杂地交织在一起”这一事实。 它们的边界可能是不确定的。 不能仅根据系统内部的进程来区分边界。” （沃森，

系统工程系统中应用复杂性思维的指导原则

INCOSE Complexity Primer (INCOSE, 2016) 概述了复杂性思维的指导原则。 由于 SoS 表现出如上所述的复杂性，下一个问题是如何将这些原则应用于 SoS。

像园丁一样思考，而不是像钟表匠一样思考：“考虑环境和解决方案的复杂性，并考虑为问题制定一个活生生的解决方案，而不是从头开始构建一个系统。” （INCOSE，2016）SoS 通常由支持所需 SoS 功能并通过交互发展的当前和新系统组成。 了解这些“自然”的相互作用效应对于了解组成系统对各种干预措施的反应非常重要。

将勇气与谦逊相结合：“承认复杂性、放弃控制、鼓励多样性和探索未知领域需要勇气。 接受不可减少的不确定性，对现有知识持怀疑态度，并对从失败中学习持开放态度，都需要谦逊。 勇气和谦逊的结合使复杂的系统工程师能够冒真正的创新风险，并从背景中解决方案的迭代原型中快速学习。” (INCOSE, 2016) 这一原则与 SoS 中的认知一致，SoS 工程师正在进入新领域，在该领域中，控制程度、系统技术和功能能力的多样性以及多个重叠的权限之间存在很大差异。

采取适应性的立场：“系统工程师应该通过识别和创造变化、选择最佳版本并放大所选版本的拟合度来模仿生命系统如何应对复杂性。 例如，这意味着要思考“影响”和“干预”，而不是“控制”和“设计”。 (INCOSE, 2016) 对于大多数 SoS 而言，成功的 SoS 工程师认识到影响和干预是游戏的名称，因为在很大程度上控制权仍由成分组成，并且 SoS 架构和设计需要适应当前的状态组成系统，同时解决 SoS 能力目标。 识别和使用模式：“模式由复杂系统表现出来，可以观察和理解，是复杂系统工程中的关键机制。 模式是专门处理出现和副作用的主要手段——即诱导期望出现和副作用的手段，以及避免不希望出现和副作用的手段。” (INCOSE, 2016) 了解系统、它们的行为和交互是 SoSE 的核心要素。 通过对这些建模并将它们视为机会，模式可以成为一种有效的 SoSE 方法。

放大和缩小：由于无法在单一的分析尺度上理解复杂的系统，系统工程师必须养成在许多不同尺度上查看项目的习惯，通过迭代放大和缩小。” (INCOSE, 2016) 有效的 SoSE 通常被称为“中间”流程，需要了解自上而下的 SoS 驱动因素，但也需要尊重参与者的自下而上的需求和能力。 这两种观点之间的动态反映了 SoSE 思维中的这种“放大和缩小”原则。

实现平衡：“在复杂系统中，优化往往适得其反。 当一个部分被优化时，要么整体是次优化的，要么优化的整体变得僵硬，无法随着条件的变化而弯曲。 复杂系统工程师不应进行优化，而应在项目内的竞争紧张之间寻求平衡。 系统工程师可以利用综合思维来生成改进的解决方案并避免二元选择/或权衡。”（INCOSE，2016）在 SoSE 中，如果您尝试“优化”，您可能不了解情况。 SoS 和组成部分的多个（通常是相互竞争的）目标需要继续满足组成部分目标但也解决 SoS 能力的选项。 这直接与“合作”和“看穿新眼光”原则相联系。

从问题中学习：“在不断变化的环境中，随着系统不断发展，元素紧密相连，问题和机遇将不断出现。 此外，由于相变、级联故障、肥尾分布和黑天鹅事件，它们将以令人惊讶的方式出现。” (INCOSE, 2016) SoS 开发被认为是进化的 (Maier, 1998)。 一种生命周期方法，SoS“波浪模型”（Dahmann，2011 年）明确地将 SoS 演进的每一次迭代都从评估自上一波以来的变化开始，认识到从问题中学习和适应的重要性。

元认知：“元认知，或反思一个人的反映方式，有助于识别偏见，使有用的思维模式更频繁，并提高对复杂情况的理解。” （INCOSE，2016）SoS 的痛点之一（Dahmann，2010）是需要“SoS 思维”——一种元认知形式。

专注于结果空间的期望区域，而不是指定详细的结果：“与其将注意力集中在一个精确的解决方案上，不如关注什么样的解决方案范围会产生预期的效果，并进行设计以保持在禁止范围之外。” （INCOSE，2016）重要的是根据广泛的能力（相对于详细的解决方案）定义 SoS 需求，因为在 SoS 中需要考虑更多的因素。 在 SoS 术语中，SoS“需求空间”反映了这一观点。

了解是什么激发了自主代理：“改变奖励将塑造集体行为。 实施激励措施，将系统推向更理想的状态。” (INCOSE, 2016) SoSE (DoD, 2008) 的一个核心要素是了解组成系统及其关系，包括这些系统的目标和长期目标。 这为评估系统将受欢迎的变化提供了基础，并有可能激励成员提供与其目标一致的所需 SoS 功能和服务。 这直接链接到“使用自由秩序”原则，强调在复杂系统中促进自组织的价值。

保持自适应反馈回路：“自适应系统通过反馈机制纠正输出变化。 随着时间的推移，反馈回路可能会达到其控制空间的极限，也可能会为了保持稳定性而被移除。 为了保持稳健性，定期重新审视反馈并确保仍然可以进行调整。” (INCOSE, 2016) 如上所述，SoS 波浪模型 (Dahmann, 2011) 是围绕这一原则构建的，应用于 SoS 开发和演化生命周期。 整合问题：“关注问题之间的关系，而不是单独解决每个问题。 这使得以综合方式解决多个问题的解决方案更少。” (INCOSE, 2016) 在 SoS 方法中 (Cook, 2014)，包括 SoS Wave 模型 (Dahmann 2010) 和 DoD SoS SE 指南 (DoD,