系统工程方法论是指用于解决复杂系统问题的一套工作步骤、方法、工具和技术。从总体上说，可以把美国国防部看作是通过各类作战司令部将各系统组合在一起以实现各项军事任务目标的大型体系。然而，无论从开发还是采办的角度，目前国防部主要聚焦于独立系统（或平台单装），大多数系统的演进过程仍然没有清晰规划体系级系统工程。随着美国防部逐渐从以平台为中心转向以能力为中心，未来美国国防部必然会更加重视体系系统工程，并逐渐形成一套体系级系统工程的方法论。

本文详细分析了体系系统工程的背景、四大类型、七大核心要素，并附上美国国防部SoS详细样例。

文章仅供参考，观点不代表本机构立场。

体系的系统工程方法论浅释（上）

作者：学术plus高级评论员 扬帆

1、提出体系系统工程的背景

系统工程方法论是指用于解决复杂系统问题的一套工作步骤、方法、工具和技术。系统工程方法论是在系统工程的实践中不断形成和发展起来的。发展至今，系统级系统工程方法论已臻于成熟，相关文献众多；而体系级系统工程方法论却仍属初期探索阶段，专门阐述体系级系统工程方法的资料比较少。而当今大多数的军事系统都是一个或多个体系的组成部分，即使它们自身并没有意识到这一点。

从总体上说，可以把美国国防部看作是通过各类作战司令部将各系统组合在一起以实现各项军事任务目标的大型体系。然而，无论从开发还是采办的角度，目前美国防部主要聚焦于独立系统（或平台单装），大多数系统的演进过程仍然没有清晰规划体系级系统工程。随着美国防部逐渐从以平台为中心转向以能力为中心，而基于能力的观点更需要发现和发掘上述独立系统之间的关系，因此，未来美国国防部必然会更加重视体系系统工程，并逐渐形成一套体系级系统工程的方法论。

2、体系（SoS）与系统簇（FoS）有何区别？

  • 系统（system）：由一些按规律交互或独立的要素组成的功能性、物理性和/或行为性组合，该组合中的要素形成一个统一整体。

  • 体系（SoS）：包含一系列系统，这些系统既可以单独发挥功效，也可被集成为一个具有独特能力的更大系统。无论是独立的系统，还是体系都服从系统的定义，每个系统都由各部分组成、各部分之间存在联系、总体大于部分之和。虽然，体系是一个系统，但并不是所有的系统都是体系。

  • 系统簇（FoS）：包含一系列通过不同方法实现相似功能的系统，运行这些系统可达到相似或互补的效果。例如，作战人员需要具备跟踪移动目标的能力。系统簇可以通过搭载了适当传感器的无人或有人航空器、天基传感器平台、或特战侦察行动等实现该能力。

上述每一个系统都可以跟踪移动目标，但其跟踪移动目标的持续性、精确度、及时性等特性均不相同。而搭载跟踪传感器的无人或有人航空器、天基传感器平台、或特战侦察设备等就构成一个系统簇。上述FoS的定义包含了完整性。从本质上看，系统簇与体系完全不同，因为系统簇缺乏将各系统整合为一个更高级别系统的概念。系统簇作为一组系统，并不需要包含新的功能和特性，实际上，在系统簇中，其各组成系统甚至不用连接成一个整体。

3、体系系统工程（systems engineering 简称SE）定义和体系类型

体系（SoS）系统工程是组合已有系统和新的系统并形成体系，规划、分析、组织和集成体系能力的工程过程，从而使体系能力大于各组成系统能力之和。

根据SoS分类学定义，可将美国国防部的SoS分为以下4种类型：

l 虚拟型。虚拟型SoS缺少一个中心管理责任人（或责任主体），也没有对SoS达成一致的中心目标。这种类型的SoS可能会涌现大规模的行为，但必须依靠一种相对不可见的机制才能得以维持。早期，通过无中心的通信和数据链系统进行交互的空战系统可以认为是一种典型的虚拟型SoS。

l 协作型。在协作型SoS中，各组成系统通过或多或少地自愿交互的方式，以实现达成一致的中心目标。互联网就是一个协作型的系统。互联网的工程技术人员制定标准，但是没有权利强制执行标准。互联网的主要玩家可以集体决定如何提供服务或拒绝服务，从而达到类似强制执行标准和维护标准的效果。

l 承认型（或认可型）。承认型SoS具有达成共识的目标、指定的SoS项目经理和资源；然而，其组成系统仍保持独立性，有其独立的目标、经费和发展路线图。改变某个组成系统需要在SoS和该系统之间进行协商合作。目前，美国大部分的SoS属于承认型SoS，如军事卫星通信系统（MILSATCOM）、弹道导弹防御系统（BMDS）、海军一体化火力控制-防空（NIFC-CA）等。其主要目的是，将现有系统集成为承认型SoS（有时承认型SoS也会包含一些新研系统），使体系具备现有系统不具备的新能力，或者大大提升现有系统的能力。

l 指导型。指导型SoS是指为了实现特殊目标而建造和管理的集成体系。在长期运行期间，指导型SoS采用中心化管理方式，以不断实现这些特殊目标以及系统所有者希望实现的其它新目标。组成系统仍具有独立运行的能力，但它们的主要模式是服从指导型SoS的中心管理目标，即作为指导型SoS的一部分运行。指导型SoS代表着SoS未来的发展方向。

4、美国国防部SoS的样例

5、体系系统工程的七大核心要素

体系系统工程共有7个核心要素，是对体系系统工程主要活动容的归纳总结。图5-1表达了7个核心要素及其关系，图5-2表达了7个核心要素在一次SoS升级活动过程中的主要运用时段。图5-3是对图5-2中一次SoS升级活动过程的细化，从中也可以看出SoS级系统工程和系统级系统工程的不同职责和作用。

图5-1体系系统工程的7个核心要素及其相互关系

图5-2 体系系统工程聚焦于对SoS的升级改进（而非对各组成系统的改进），通过分阶段增量推进方式，从而最终达到SoS的能力目标

图5-3 在一次SoS升级过程（即一次增量）中，体系系统工程的主要活动内容

5.1. 逐步将体系的能力目标转化成体系级需求（以下简称能力目标转化）

当首次确认一个正式SoS项目时，会将其各组成系统的工程团队召集在一起，理解和描述该SoS未来的技术愿景。一般用需求能力的方式表达SoS的目标，组成系统的工程师与SoS项目经理、用户一起，负责将系统技术需求转化为SoS的高等级需求，为SoS的技术规划提供坚实基础，从而不断推动SoS的能力演进。

为了实现上述目标，SoS的系统工程团队需要理解SoS的性质及其未来发展的动态范围，预见SoS未来的运用环境或作战环境，对未来执行和演变过程中SoS的变化作出预判。SoS组成系统的工程师们在将能力需求转化成技术需求的过程中持续发挥积极作用；并且当形势变化和SoS演进时，识别出新的技术需求。

5.2. 逐步理解组成体系的各系统及其关系（以下简称理解各系统关系）

SoS系统工程最重要的作用之一是理解SoS各组成系统对SoS能力的贡献以及各组成系统之间的相互关系。在单独的系统采办过程中，系统工程师一般能清晰地描述一个新系统的边界以及与外部系统的接口关系。而在SoS采办过程中，工程师们必须清楚影响SoS能力的系统全集，以及清楚这些系统如何相互作用和为SoS能力目标做出贡献。SoS中的一些关键系统可能不受SoS项目经理的直接控制，但会对SoS的目标产生很大影响。有可能无法找到所有对SoS目标有影响的系统，所以最重要的是，理解SoS的主要参与者、他们之间的关系以及他们的驱动力是什么，从而发现和评估实现SoS目标的选项，并对作战环境等外部因素变化对SoS的影响做出预测。

理解SoS各组成系统的功能是理解以下3方面内容的基础：

1）这些系统如何支持实现SoS的目标；

2）与SoS相关的系统的技术细节是什么（例如，共享或交换任务信息的方法）；

3）系统当前的开发计划，包含时间和同步性考虑。最后，SoS系统工程师需要识别出SoS及其组成系统的利益攸关方和用户，理解他们的组织结构以及他们在SoS中的作用。

5.3. 逐步评估SoS性能符合能力目标的程度（以下简称评估能力目标的性能）

在SoS开发环境中，可能存在多种实现能力目标的方案。这意味着SoS工程师需要建立测量标准和方法以独立评估各种方案所能达到的SoS性能。识别出最重要的任务主线并聚焦于端到端的性能评估是能力评估的重要内容。由于SoS常常包含部署在作战一线的装备，因此对SoS性能的评估应该基于作战人员的经验反馈和在作战场景中出现的问题。通过监视在现场或演习中的表现，SoS系统工程师能主动发现和评估需要关注的领域、在SoS中新出现的行为或现象、以及组成系统的变化对SoS的影响。

5.4. 开发、演进、维护SoS的架构（以下简称开发和演进SoS架构）

一旦SoS系统工程师厘清了SoS的高级技术目标、识别出哪些组成系统是实现SoS目标的关键、定义了SoS的当前性能指标，就开始开发SoS的总体架构，SoS架构的演进过程总是从当前已有的SoS架构开始。SoS架构重视SoS的作战概念以及这些作战概念所包含的功能、各组成系统的依存关系、以及内外接口。这包含端到端的功能活动以及所需交互的数据流。SoS架构为评估对系统的变化需求以及其他需求选项提供了技术框架。若开发一个新系统，系统工程师可以在没有任何限制条件的情况下，从头开始设计一个崭新的系统架构方案。

然而，在SoS中，在SoS建立之时，一般就已经确定了对SoS目标有贡献的各个组成系统，SoS工程师需要考虑这些组成系统各自的现状和发展计划，这是开发SoS架构重点需要考虑的因素。在开发SoS架构的过程中，SoS工程师应识别出所有的可选项，寻找折中后的最佳方案，当在SoS和系统的需求和限制条件之间不能找到平衡点时，通过反馈和沟通解决问题。

5.5. 监视和评估各种变化对SoS性能的影响（以下简称监视和评估变化）

SoS系统工程的一个重要内容就是对将会影响SoS功能或性能的变化进行预测。这包含由SoS组成系统引起的内部变化，也包含外部需求的改变。因为SoS包含多个独立的组成系统，体系工程师必须意识到这些系统独立于SoS的演进发展过程，而系统的演进可能会影响SoS。通过理解这些提议或潜在变化对SoS的影响，SoS工程师能干预或预防问题、或者开发一个战略以减轻这些变化对SoS的影响。

5.6. 关注SoS的需求和解决方案选项（以下简称关注需求和方案选项）

任何一个SoS都会同时有SoS级和组成系统级的需求。取决于不同的环境，SoS工程师可能在这两个级别或者其中一个级别上发挥作用。在SoS级上，SoS系统工程师与各组成系统一起，收集、评估、优化用户需求，从而评价为满足这些需求而提出的各个选项。当识别能满足SoS需求的各选项并考虑这些选项对各组成系统的影响时，工程师理解各组成系统及其技术和组织的内涵和限制条件是至关重要的。

SoS工程师有责任与各组成系统的需求管理者一起，识别出将由各个组成系统解决的特殊需求。这个向各组成系统分解和分配需求的过程在SoS级被组合在一起，因为多个负责采办的利益攸关方在SoS级进行互动交互。其目的是找到能平衡各组成系统和SoS需求的选项，因为在大多数情况下SoS并没有一个明确的、有决定权的机构。由各组成系统的工程师负责设计对各自系统的改变。对于一个经过良好设计的SoS架构，将提供一个较为稳定持久的框架，以应对设计变更和需求变化，也能够缓和SoS某一领域变化对其他领域的影响。

5.7. 协调同步SoS的升级（以下简称同步升级）

一旦确定了为满足需求而设计的选项，SoS工程师就需要担负起与SoS项目发起者、SoS项目经理、组成系统的发起者、项目经理、系统工程师和合同商一起工作，资助、规划、按合同推进、集成和测试SoS升级工作。由组成系统的所有者实施对所有系统的实际变更和升级，但SoS工程师负责同步整个SoS升级过程，在协调、集成和测试中承担领导责任，对升级过程进行监督，以确保各系统达成一致的变更能够被贯彻执行并支持SoS的目标。

6、系统工程过程如何支撑体系系统工程？

系统工程可归纳出如下16个过程，其中8个技术过程和8个技术管理过程，每个过程与其主要支撑的体系系统工程核心要素之间的映射关系如表6-1所示。

表6-1 各系统工程过程与其主要支撑的体系系统工程核心要素之间的映射关系

（详细过程解析请关注本号后续更新）

7、小结

当前，美国国防部对SoS越来越重视，因为国防部逐渐从以平台为中心转向了以能力为中心。不断有新的SoS被发现并成为系统工程和管理的主题。一般，当前国防部的SoS项目不是新的采购项目，这些SoS项目只是对按照一定能力需求对现有系统和新研系统的组合集进行修改。一个SoS只是在现有系统和新研系统上覆盖了一层，而这些系统仍保留自己的身份、管理模式和系统工程过程。不同于完全控制这些系统，SoS的经理和系统工程师们与其组成系统的经理和系统工程师们协同，利用和影响这些系统的开发过程，从而满足SoS的需求。

基于在SoS系统工程方面的既有经验，提出以下五条方法。

1）对SoS系统工程而言，在进行系统工程的（设计方案）权衡和决策时，重视组织上的问题和技术上的问题一样重要。

2）SoS系统工程师需要承认系统级系统工程和SoS级系统工程的作用及其相互关系。SoS的系统工程师专注于那些对SoS成功至关重要的方面而将与组成系统相关的问题留给这些系统的系统工程师。

3）SoS的技术管理需要平衡要求系统参与（SoS系统工程）的程度，致力于透明和信任，并积极参加与系统和SoS均相关的领域。

4）SoS的架构设计应是开放式的，与各组成系统是松散耦合关系，尽量减少对组成系统的影响，从而为组成系统应对变化的需求和未来的技术机遇提供最大的灵活度。

5）SoS设计的战略和权衡研究需要尽早开展，并将在整个SoS演进过程中持续进行，这将是一个需要长期持续的过程。

声明：本文来自学术plus，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。