这个主题是系统基础知识领域(KA)的一部分。它给出了描述系统工程的出现的一些方式的背景，以及当前关于它是什么以及它如何影响系统工程(SE)实践的思考。它将讨论这些思想如何与《什么是系统?》中给出的系统的一般定义相联系;特别是，它们如何与不同的工程系统环境相关联。本主题与前面的复杂的系统主题密切相关。

系统工程的出现是整体主义和相互作用的基本系统概念的结果(Hitchins 2007, 27)。系统整体的行为和属性来源于其元素和关系的组织，只有当系统被放置在不同的环境中时才会变得明显。

从这个定义中产生的问题包括:什么样的系统表现出不同的出现方式，在什么样的条件下?它对系统是有利的还是有害的?在工程系统的开发和使用中，我们如何处理系统工程的出现现象?它能被计划吗?如何计划?

关于系统工程的出现有许多不同的，有时甚至是相互矛盾的观点。本课题提出了目前流行的观点，并为大家提供参考。

系统工程的出现概述

正如Checkland所定义的那样，系统工程的出现是“一种原则，即实体展示的属性只有在归属于整体而非部分时才有意义。”(Checkland 1999,314)。紧急系统行为可以被看作是系统元素之间的交互和关系的结果，而不是单个元素的行为。它产生于系统元素的行为和属性以及元素之间的系统结构或允许的交互的组合，并且可能被来自系统环境的刺激所触发或影响。

系统工程的出现在自然界中很常见。

Hitchins还指出，技术系统呈现出萌芽状态。我们可以观察到工程系统环境中各个元素之间的相互作用所产生的许多层次的结果。在简单的层面上，一些系统结果或属性具有相当简单且定义良好的映射到它们的元素;例如，车辆的重心或最高速度是由元素属性及其组合方式决定的。其他行为可以与这些简单的结果相关联，但它们的价值在整个系统中以复杂且难以预测的方式出现。车辆在赛道上的单圈性能与重心和速度有关;但同时也受到驾驶员技能、外部条件、构件等因素的影响。在比赛条件下，赛车只有结合了良好的设计和真实圈数的反馈，才能获得“最佳”的性能。

还有一些结果是不那么有形的，对系统开发人员和用户来说都是一个惊喜。一圈的时间如何转化为一个获胜的赛车团队?为什么跑车比其他性能一样好或更好的汽车更受欢迎?

总能在系统的最高层次观察到突发性。然而，Hitchins(2007, 7)也指出，在某种程度上，系统元素本身可以被视为系统，它们也会出现。Page(2009)将系统工程的出现视为“宏观层面的属性”。Ryan(2007)认为，系统工程的出现是与范围而非系统层次相结合的。用Ryan的话说，范围与空间维度(系统元素彼此之间的关系)有关，而不是与层次有关。

Abbott(2006)不同意上述对系统工程的出现的一般定义。然而，他对系统工程的出现现象超出经典物理学界限的观点提出了异议。他说，“这种更高层次的实体……总是可以被简化成原始的物理力量。”

Bedau和Humphreys(2008)和Francois(2004)对其产生的哲学和科学背景进行了全面描述。

系统工程出现的类型

系统工程出现的类型有各种各样的定义。参见Emmeche et al.(1997)、Chroust(2003)和O’connor和Wong(2006)了解一些变体的具体细节。Page(2009)描述了三种类型的出现:“简单”、“弱”和“强”。

根据Page的说法，简单的出现是由元素属性和关系的组合产生的，发生在非复杂或“有序”的系统中(参见复杂性)(2009)。要实现“受控飞行”的突发性特性，我们不能只考虑机翼、控制系统或推进系统。必须考虑到这三个方面，以及这三个方面相互联系的方式，以及与飞机所有其他部件的联系。佩奇认为，简单的出现是唯一可以预测的出现类型。这种出现的观点也被称为协同效应(Hitchins 2009)。

Page将弱出现描述为系统结构中希望(或至少允许)出现的预期出现(2009)。然而，由于弱出现是一个复杂系统的产物，仅从单个系统组件的特征无法预测实际的出现水平。

“强出现”这个词是用来描述意外的出现;也就是说，直到系统被模拟或测试，或者更令人担忧的是，直到系统在运行中遇到设计和开发过程中没有预料到的情况，才会观察到紧急情况。

在企业倒闭或关门的情况下，强劲的复苏可能是显而易见的。例如，美国-加拿大电力系统停电任务小组(2004年美国-加拿大电力任务小组)所描述的2003年美国-加拿大停电事件就是系统设计导致级联关闭的一个案例。虽然没有设备故障，但关闭是系统性的。正如Hitchins所指出的，这个例子表明出现属性并不总是有益的(Hitchins 2007, 15)。

其他作者对“强烈的，或意想不到的，出现”和“不可预测的出现”的概念做了不同的区分:

• 首先，有一些本来可以预测但在系统开发中没有考虑到的意想不到的特性:“由于观察者的数据集不完整，与手头的现象有关”(Francois, C. 2004, 737)。Jackson等人(2010)认为，理想的出现水平通常是通过迭代实现的。这可能是进化过程的结果，在进化过程中，元素属性和组合被“选择”，取决于它们对系统对抗环境压力的有效性的贡献，或者通过模拟或构建/测试周期的设计参数迭代。基于此，可以细化弱出现的具体值，而强出现的例子只要符合分析，可以在后续迭代中考虑。
• 其次，有一些无法从系统组件的属性中预测到的意外属性:“属性本身，不能从系统部件的行为中推导出来”(Francois, C. 2004, 737)。这种关于出现的观点在社会科学或自然科学中很常见，但在工程学中更有争议。我们应该区分理论的不可预测性和实践的不可预测性(Chroust 2002)。从理论上讲，天气预报是可以预测的，但由于其混乱的性质，超出一定的精度实际上是不可能的。人类意识的出现不能从大脑的生理特性推断出来。对于许多人来说，这种真正不可预测的复杂性类型对工程的价值有限。(请参阅下面的实际考虑。)

特别容易出现的一种系统类型是利益系统(sos)。这样做的原因是，根据定义，SoS是由不同的系统组成的，这些系统被设计成独立运行。当这些系统一起运行时，系统各部分之间的相互作用很可能导致意外的出现。这类系统很可能出现混乱或真正不可预测的情况。

系统工程出现的特征

系统工程出现的特征可以定义如下:“一个属性的一个复杂的系统被认为是“出现”(的情况下),尽管它出现的属性和关系描述简单的成分,它既不是预测,也可约,这些低级特征”(Honderich 1995,224)。

正如上面所讨论的，所有系统都可以具有出现的特征，这些特征可能是可预测的，也可能是不可预测的，也可能是不可建模的。许多关于复杂性的文献都把复杂性的出现作为复杂系统的定义特征。例如，Boccara(2004)指出:“系统工程出现的特征是复杂系统最显著的特征。”一般来说，一个系统越有序，它的出现特征就越容易预测。一个系统越复杂，就越难预测它的系统工程的出现特性。

一些从业者只在提到“强烈的出现”时才使用术语“Emergent”。这些实践者将其他两种形式的紧急行为称为协同或“系统级行为”(Chroust 2002)。采用这种视图，我们将为意外的属性保留术语“Emergent Property”，这些属性可以通过系统开发的迭代建模或细化。

无法预见的情况会造成严重的冲击。许多人认为，系统方法的主要工作是防止不希望出现的情况，以尽量减少意外和潜在不希望出现的结果的风险。这种对紧急属性的回顾通常与识别和避免系统故障特别相关(Hitchins 2007)。

然而，好的SE不只是专注于避免系统故障。它还包括通过理解和利用工程系统中的突发性来最大化机会，通过组件之间的协同交互来创建所需的系统级特性，而不仅仅是组件本身(Sillitto 2010)。

一组重要的突发性属性包括敏捷性和弹性等属性。这些关键的系统属性除了在整个系统级别上没有任何意义。

实际问题

如上所述，管理系统工程的出现的特征一种方法是通过迭代。在设计过程中，迭代设计一个工程系统以达到预期结果的需求比设计一个有序系统所需的需求要长。创建一个能够进行这种迭代的工程系统可能还需要一个更可配置的或模块化的解决方案。其结果是，开发复杂的系统可能比开发有序的系统更昂贵和耗时，而且开发的成本和时间天生就难以预测。

Sillitto(2010)观察到“利用系统工程的出现工程设计领域具有良好的领域数学模型，并在设计和操作中严格控制组件、子系统和过程的变异性。”上面讨论的迭代可以通过使用仿真和建模来加速，因此并不是所有的迭代都需要构建真实的系统并在真实的环境中操作它们。

领域模型的概念由Hybertson在通用模型或模式的背景下进一步探索，这些模型或模式是随着时间的推移而学习并在模型空间中捕获的(Hybertson 2009)。Hybertson指出，要知道一个给定的设计会出现什么情况，包括副作用，需要事后诸葛亮。对于尚未解决的新类型问题，或尚未构建的新类型系统，实际上是不可能预测解决方案或系统的紧急行为的。通过建模和迭代特定的系统设计，我们可以获得一些后见之明，或者至少是一些见解;然而，在一个系统的开发中迭代设计只能产生有限的后见之明，并且通常不能提供完整的系统工程的出现感和副作用。

真正的后见之明和理解来自于构建多个相同类型的系统，并部署它们，然后观察它们在运行中的突发行为，以及将它们置于其环境中的副作用。如果这些观测系统完成,出现和副作用与蒸馏和捕获系统的设计,包括这些设计的变化,提供社区,然后我们能够预测和利用出现。

在这种类型的测试环境中，我们发现了两个因素:什么是有效的(也就是说，什么是需要的突发行为和副作用);什么不起作用(也就是说，什么突发行为和副作用是不受欢迎的)。作品肯定了设计。不能工作的需要在设计中进行修改。这就是为什么多个系统，特别是复杂的系统，必须随着时间的推移和在不同的环境中构建和部署——以学习和理解设计、突发行为、副作用和环境之间的关系。

这两种被捕获的学习类型分别对应于模式和“反模式”，或失败的模式，这两种模式都在系统思维原则和系统思维模式主题的更广泛的背景下进行了讨论。

使用迭代来细化系统工程的出现属性的值，无论是在单个系统的生命周期中，还是通过开发封装了从多个开发中获得的知识的模式，都可以很容易地应用于上面关于强烈系统工程的出现的讨论。从这个意义上说，那些可以观察到但不能与设计选择相关的属性与系统方法无关。然而，当处理工程和管理问题的组合出现在系统语境的系统时，它们是有价值的(Sillitto 2010)。(参见应用于工程系统的系统方法。)