Systemof systems （SoS）——体系

SoS概述 

Systemof systems （SoS，体系）是一个具有资源池、面向特定任务的系统集合或者专门的系统集，它们的能力整合在一起创造一个新的、更复杂的系统，提供比单独的组份系统的总和还要多的功能和性能[1]。目前，SoS是一个有颇多争议的研究学科，其中的参考框架，思维过程、定量分析、工具和设计方法都是不完整的[2]。通常把定义、抽象、建模和分析SoS问题的方法称之为体系工程（System of Systems Engineering，SoSE）。

目前，SoS工程的应用被广泛地扩展到我们几乎所层次的生活。国防领域在SoS早期的工作奠定了SoSE的基础，包括知识基础、技术方法和实践经验。现在，SoSE的概念和原理适用于更多的政府、民间和商业领域。如：

·交通——空中交通管理、铁路网络、地面综合运输、货物运输、公路管理和空间系统；

·能源——智能电网、智能住宅、综合生产/消费；

·卫生保健——区域设施管理、应急服务和个人健康管理；

·自然资源管理——全球环境、区域水资源、森林和可再生资源；

·灾难响应——灾害响应事件包括森林火灾，洪水和恐怖袭击；

·消费产品——综合娱乐和家庭产品集成；

·商业——银行和金融业，媒体电影、广播和电视。

SoS的历史与发展 

20世纪90年代，信息技术的高速发展和广泛应用使得复杂的技术集成和系统管理问题益发突出，现代战争、现代交通等进一步表现为'多个系统或复杂系统组合而成的大规模的系统组合'，体系(SoS,system of systems)和体系工程(SoSE,systemof systems engineering)研究应运而生。国内外学术界普遍认为，体系工程是系统工程的发展与深化,发端于20世纪90年代初期。下图说明了SoS在学术与工业领域的发展历史]。[3]

20世纪90年代，广大学者开始探索解决体系问题的思路与方法，首先认识到传统系统工程在解决体系问题上的不足，然后开始新的途径与方法的探索。SoS在学术上的研究，最早可以追溯到1956年博尔丁把SoS想象成一个理论上的“完全形态”形成一个“理论谱系”，即SoS大于各部分的总和。1991年，Eisner等人把SoS定义为：一组独立采办的系统，每个系统都有一个名义上的系统工程过程；这些系统相互依存和组合运行形成面向整体连贯使命的多功能解决方案。每个系统的优化并不能保证整个体系的优化。

1996年，Manthorpe,Jr.提出将指挥、控制、计算机、通信、信息(C4I)和情报、监视和侦察(ISR)结合成SoS以实现“战场感知”。同样在1996年，迈尔（Maier）首次提出用特征描述方法来区分“单一”系统和SoS。这些特征包括“元素运行独立性、元素管理独立性、进化发展、涌现行为和地理分布”。

SoS最早的工业应用是2001年DoD引入了ASBP-Army Software Blocking Policy (ASBP)V11.4E， ASBP创建了一套机制确保“系统开发”与“程序执行”能够相互和谐。SoS定义为“一组共享/交换信息实现协同交互的系统。”

2001年，DoD的另一个部门在一份报告中使用“系统族”(FoS)概念用于在军事环境中描述SoS：一组相互依赖的系统以不同的方式安排或者相互联接以提供不同的功能。”

2005年——美国成立了依托国防采办大学的体系工程中心(SoSECE,System of Systems Engineering Center of Excellence)和依托老道明大学（Old Dominate University）的国家体系工程研究中心(NCSoSE，National Center for System of Systems Engineering)，标志着专业化体系工程研究机构的正式成立。美国麻省理工大学（MIT）和普度大学（Purdue University）分别从工程系统领域和智能交通系统视角开展体系相关研究。荷兰的戴尔福特大学则在能源开发、电力网络传输等方面开展了体现结构设计相关研究。

2006年——卡耐基梅隆大学发布SoS浏览器。同一年，IEEE SoSE第一次专题会议在洛杉矶召开，同时成立《体系工程》杂志。这些专业化体系工程研究机构、专业杂志的成立，以及大学所开展的体系相关研究，对于体系工程的研究与推进发挥了重大作用。

2007年——DoD发布体系工程指南——体系环境中的系统工程考虑(System of Systems Engineering Guide: Considerations for Systems Engineering in a System of Systems Environment)。该指南描述了SoS环境的特征以及体系工程（SoSE）的复杂性识别。

2008年——DoD发布体系系统工程指南V1.0（Systems Engineering Guide for System of Systems）。体系系统工程指南为系统工程从业人员提供了良好的基础和实践指导，以应对复杂性不断增加的系统环境以及体系所带来的挑战。

2010年在SoS领域有很多贡献。包括Luzeaux 和 Ruault关于SoS的书籍，以及IBM所提出的“全球4万亿美元的挑战——用体系方法建立智慧地球”（Korsten和seider 2010），以及复杂系统设计与管理会议（CSD&M 2013）。

2011年对于SoS而言是辉煌的一年。luzeaux继续他在SoS领域的研究工作，与其他两位作者共同出版了《复杂系统和体系工程》（Luzeaus,Ruault, and Wippler 2011），另外还有《体系建模与仿真》（Cantot and Luzeaux. 2011）。

2011年启动了由Michael Henshaw领导的“跨大西洋体系研究与教育项目”（T-AREA-SoS,2011），其中包括一系列的美-欧研讨会，并形成了几个实体，如：COMPASS，DANSE，PLANET (COMPASS 2011)(DANSE 2011) (PLANET 2011)。

System(s) of Systems定义 

关于System(s) of systems（SoS）的定义超过40种。Maier（1998）曾提出SoS的五项关键特性：

构件系统运行独立性；

构件系统管理独立性；

地理分布；

涌现行为；

以及进化的发展过程。

上述的SoS五项关键特性被称之为“迈尔特性”，Maier将运行独立性与管理独立性确定为SoS术语的两个主要区别特征。一个系统如果不具有这些两个特征，无论其复杂性或其组成部分的地理分布如何都不能被视为SoS。

在国防采办指南中SoS被定义为一组或一系列独立的有用的系统集成到一个更大的系统提供独特的能力的结果。集成后各个独立的系统可以相互依存，是一个相互依存和相互受益的综合系统。

系统和SoS都符合公认的系统定义，系统由部件构成，部件之间相互关联，以及整体大于部分之和；尽管SoS是一个系统，但并不是所有的系统都是SoS[4]。

贾姆什迪综合了几个SoS定义，形成了以下被广泛关注的SoS定义：

SoS是由有限数量的可独立运行的系统，在一个特定的时间段内，为了达成一个确定的更高目标而联接在一起的集合。（贾姆什迪2009）——SEBOK2014

根据这个定义需要指出的是，一个SOS的形成不一定是永久性的现象，而是为了特定的目标（如，鲁棒性、成本、效率等）形成的一个整合和联接系统集。

德劳伦蒂斯和克罗斯利（2005）给前面所描述的SoS的5个特征增加了几个特征，包括：跨学科，系统异构性，和系统网络[5]。因此，SoS表现出以下8个方面的特征：

组份系统运行独立性；

组份系统管理独立性；

地理分布；

涌现行为；

不断进化的发展过程；

跨学科研究；

组份系统异构性

组份系统网络

INCOSESE HandbooK(FOURTH EDITION)对SoS做了进一步的阐述：

SoS是一个SoI（System of intrest），SoS的元素是可独立管理和/或运作的系统。这些互操作和/或综合集成组成的系统通常产生由单个系统独立无法实现的结果。因为一个SoS本身就是一个系统，系统工程师可以选择是否把它作为一个系统或是一个SoS，取决于哪个角度更适合于特定的问题。

SoS适用于系统元素本身也是一个系统的系统，是一个更大的目标系统，因此，系统工程方法同样适用于SoS的研究。2008年8月，DoD发布了体系系统工程指南V1.0。体系系统工程指南的发布，为应用系统工程过程去处理当今世界由网络化的系统和体系所带来的变化迈出了重要的一步。2012年，INCOSE（系统工程国际委员会）成立SoS工作组（SoSWG），SoS工作组的目的就是要在不同类型的SoS中推动和促进系统工程应用，在系统工程社区内扩大和促进SoS知识与价值。美国著名的军工企业诺斯洛普.格鲁曼公司的John Clark（INCOSE CSEP）在2013年的INCOSE的研讨会上曾经将系统工程双V模型应用到SoS中。

虽然SoS是一个更大的系统，可以使用系统工程方法去研究SoS，但是，SoS的特性往往会带来典型的、大规模的跨学科问题，涉及多重的、混合的和分布式系统，面临多方面的挑战，SoS在管理上带来的问题往往会让SoS本身的价值黯然失色。

System(s) of Systems的类型 

在当今的互联世界，SoS的情况非常普遍。在这些情况下，SoS被视为一个系统，SoS被描述为四种类型（Maier1998；dahmann& Baldwin 2008）：

·定向SoS（Directed SoS）——SoS被创建和管理用于实现特定的目的，组份系统集属于SoS。这些组份系统保持独立运作的能力，但是，其正常运作模式服从中央管理的目的。

·公认的SoS（Acknowledged SoS）——SoS有清晰的目标，指定的管理者，以及SoS资源；但是，这些组份系统保持其独立的所有权、目标、资金、开发和维持的途径。系统集的变化是基于SoS和系统之间的互操作协议。

·协同SoS（collaborative SoS）——组份系统集通过或多或少的互动自愿达成一致的中心目的。中央参与者集体决定如何提供或拒绝服务，形成一些执行和维护的标准；

·虚拟SoS（Virtual SoS）——SoS缺乏一个中央管理机构和一个一致的SoS中心目标。具有符合需要的大规模的行为涌现，但这种SoS必须依靠一种无形的机制来维护它。

这种分类是基于成分的独立性程度，它提供了一个基于SoS的目标源头和SoS及其组份系统的利益相关者之间的关系来理解SoS的框架。在大多数实际情况下，一个SoS将反映多种SoS类型的组合。还有其他的分类主要可能集中在组成部分的属性/类型上，等等。

一组系统集可以以SoS方式相互作用，但可能并不一定就是SoS。肯普（Kemp,2013）描述了Ad Hoc(混合蜂窝) 就是“例外”。虽然“混合蜂窝”在管理独立性、地理分布等方面都符合SoS的特点，但是，由于每一个终端不能脱离网络独立运行，因此它并不属于SoS。

系统的用户与业主在充分地理解了彼此之间的依存关系后，为了共同利益而结成协同SoS，这种协同SoS数量在现实中越来越多；在少数情况，尤其是一些未来战争系统，因为有一个明确的共同目标从一开始就驱动各组份系统的开发，这类系统集合就构成了定向SoS，如“辽宁号”与“歼15”；另外，随着网络的出现，系统之间相互连接信息共享的增多，大多数系统都是虚拟SoS的组成部分。

在大多数实际情况下，SoS通常都是几种SoS类型的组合[3]。定向SOS、公认SoS，有公认的权威机构和SoS层级的资源。然而，由于公认SOS包含了独立维护、管理、资源以及独立发展过程的多个系统，这些SoS在很大程度上又都是协同SoS。

SoS与系统的比较 

SoS是一个具有资源池、面向特定任务系统集合或者专门的系统集，它们的能力整合在一起创造一个新的、更复杂的系统，提供比简单的组份系统的总和还要多的功能和性能。SoS与独立的或者有组织的系统之间存在一些差异，这些差异如下表所示。但是这些差异并不是如表中所描述的那样非黑即白。在每一种情况下，不同的实践、系统的复杂性以及系统开发环境的变化——某些SoS的特征也可能适用于某些特定情况下的系统[4]。

系统与SoS的区别

它们都适用于系统工程（SEBOK）

系统工程

SoS

管理和监督

系统

物理工程

社会技术管理与工程

利益相关方

清晰的一组利益相关方

多层次利益相关方混合以及可能的竞争利益

治理

一致的管理和资金

由于SoS和系统两者的管理和资金而增加的复杂性等级，SoS没有控制所有的组份系统

运行重点（目标）

运行重点

设计和开发以满足共同目标

要求使用系统集去满足SoS的目标，而系统目标可能与SoS目标并不一致

实施

采办/开发

一致的采办和开发过程

跨多个系统生命周期，异步采办与开发，涉及到遗留的系统，开发的系统以及技术插入（改造的系统）。

过程

比较好建立

不断地学习和适应

测试与评估

系统的测试与评估是可能的

测试更具有挑战性，因为系统的异步生命周期以及所有部分的复杂性

工程和设计考虑

边界和接口

专注于边界和接口

关注于识别系统对于SoS目标的贡献和使能数据流、控制以及功能，同时平衡系统的需要，或者关注系统之间的交互，很难界定SOI

性能和行为

系统的性能满足目标性能

在满足SoS使能能力需要的同时平衡系统的需要

度量

比较好定义（如INCOSE手册）

难以界定，量化和达成一致

实践中如何界定SoS与系统 

一些复杂的系统，其系统元素本身可能也是一个系统，这样一来，就很容易跟SoS产生混淆。在迈尔特性中提到了5个特性：组份系统运行独立性；组份系统管理独立性；地理分布；涌现行为；以及进化的发展过程。其中最关键的就是两个独立性。如何判断系统的独立性就成为实践中界定SoS与系统的关键。

但是，独立运行与独立管理这两个特性，往往由于人们所处的不同视角而不容易明确界定。为了准确地描述系统的独立性，我们还是从系统的定义来分析。

交互的元素组织起来，以实现一个或多个特定目的的组合。

一组集成的、以完成一个确定的目标的元素、子系统或组件，这些元素包括产品（硬件、软件和紧固件）、过程、人员、信息、技术、设施、服务和其他支持元素。

——INCOSE

INCOSE给出的系统定义，给我们判断系统的独立性提供了启示——是否具有独立的系统目的/目标，有了这一认识基础，我们就可以清楚地给出SoS与系统的界定准则：

SOI的每一个组份系统，1.是否具有独立的系统目的/目标；以及，2.具有独立系统目的/目标的组份系统能否不借助SOI中的其他组份系统独立运行，独立管理。

下面以我们所熟知移动电话系统为例来说明系统与体系的界定问题。

中国移动通信网络与大量的手机终端一起构成了中国移动通信系统，这是一个系统不是SoS。这个系统中的系统元素——手机终端与移动通信网络——都是一个系统，但手机终端与移动通信网络并不是独立的系统，因为不管是手机终端还是移动网络，它们的系统目的/目标是共同的——语音通信，并且手机终端离开移动网络是不能独立运行实现系统目标的。因此，中国移动通信系统只能是系统而不是SoS，手机终端与移动通信网络是这个系统的系统元素，移动SIM与手机卡槽是这两个系统元素之间的接口。

同理，中国联通通信系统与中国移动通信系统一样也只是一个复杂的系统。但是，当中国移动通信系统与中国联通通信系统为了实现手机终端跨网通信这一更高目标，相互开放数据与通讯接口，这就构成了一个协同SoS。

有人可能会说，有的手机插上不同的卡就可以进入不同网络进行语音通信，甚至现在有更多的手机双网双卡。但这仍然改变不了每一个单一的网络（卡）与手机构成一个系统的结果，这里面手机仅仅以COTS（商用货架产品）的形式出现。

同样是手机终端，在WiFi环境下，利用微信的语音通信功能实现手机终端之间的语音通信。在这种情况下，手机终端、WiFi与微信平台构成一个虚拟SoS。因为这个虚拟SoS中的每一个组份系统都有各自的独立系统目标，而且可以脱离开其他组份系统独立运行与管理。

SoS与系统的两个界定准则必须同时成立才能形成完整的判定准则。因为“定向SoS”就是在共同的目标驱动下开发的，但是“定向SoS”中的组份系统可以脱离开“定向SoS”中的其他组份系统独立运行。比如前面所提到的“辽宁号”与“歼15”，他们相互之间是可以脱离对方独立运行。

飞机虽然是一个高度复杂的系统，其系统构成元素如，发动机、航电系统等，都是非常复杂的系统。但是，飞机只能是系统，而不是SoS。因为不管是发动机还是航电系统，它们都没有独立的系统目标，它们的系统目标都只是飞机系统目标的全包含子集。同样是电子设备，飞机和干扰吊舱构成了SoS，这是两个具有独立系统目标，可以独立运行和管理的两个系统。

此外，不论是系统还是SoS，在定义系统的时候都需要将系统纳入到体系（SoS）背景下去考虑，将跟系统有交互的其他系统作为利益相关方进行考虑。

正如本文开篇所提到的，“SoS是一个有颇多争议的研究学科，其中的参考框架，思维过程、定量分析、工具和设计方法都是不完整的”。由于作者水平有限，上述观点不一定准确，仅为抛砖引玉之目的，与读者一起交流。

参考文献

[1] https://en.wikipedia.org/wiki/System_of_systems

[2] Popper, S., Bankes, S.,Callaway, R., and DeLaurentis, D., System-of-Systems Symposium: Report on a SummerConversation, July 21–22,2004, Potomac Institute for Policy Studies, Arlington, VA.

[3] Alex Gorod, S. Jimmy Gandhi, Brian E. White, Vernon Ireland, and Brian Sauser, Modern History of System of Systems, Enterprises, and Complex Systems, CRC Press, July 1, 2014

[4] Systems Engineering Guide forSystems of Systems, Version 1.0, August 2008, DoD

[5] Guide to the SystemsEngineering Body of Knowledge (SEBoK) v1.4, June 29, 2015