海湾战争拉开了现代化战争的序幕，美军首次实现了三军联合作战，同时也认识到联合作战对于提升作战能力的重要性。后续美军推出的多种作战概念都沿袭了联合作战的指导方针，如陆空战、空海一体战、网络中心战和多域战等。装备的研制过程通常使用系统工程方法来组织和管理，美国国防部在组织联合作战装备研制过程中发现，传统的系统工程方法遭遇到了管理瓶颈，需要用一种新的概念来描述联合作战系统，这就是体系（System of Systems，SoS），而体系研制的工程过程也应该有相应的工程方法与之对应。
美国国防部在一些学者研究成果的基础上，结合多个联合作战系统开发的实践经验，于2004年推出了体系的系统工程指南（Systems Engineering Guide for Systems of Systems），下文称“体系工程指南”，作为美军联合作战体系开发的工程指导。
本文主要对该指南进行解读，为我军开展装备体系设计的过程管理提供参考。
两位重要贡献者
纵观美国国防部的体系工程指南，其主要内容离不开两位研究者的研究成果。一位是迈尔（maier），一位是朱迪思·达曼（Judith Dahmann）。迈尔研究了体系与一般系统的本质区别，提出了体系的五大特征，并对体系进行了分类，迈尔的研究成果对体系与体系工程学术领域产生了重要影响，在INCOSE的系统工程手册中也引用了迈尔的体系特征与体系分类。朱迪思·达曼是目前活跃在体系工程学术界的引领者，她提出了体系工程的核心元素模型，被美国国防部采纳，作为本体系工程指南的核心内容，她还提出过体系工程的波浪（Wave）模型，揭示了体系不断演化的特性。
迈尔的体系特征与体系分类
《体系工程指南》的第一章“前沿”中对体系的概念定义、体系的分类和美国国防部目前主要在研的联合作战体系进行了介绍，主要借鉴了迈尔的研究成果；第二章描述了系统与体系的区别，从特征、管理模式、操作环境和工程实施因素四个方面进行概要描述。
关于“体系”概念的定义存在着较大的争议。因为系统本身定义为由相互关联的子系统组成的，而体系也定义为由多个系统组成的系统集合，“体系”依然符合“系统”的定义，因此，体系是一类特殊的系统，但不是所有复杂系统都能称为体系。于是研究人员把重点放在了体系与一般系统的本质区别上。
Mayer提出了区分体系和一般系统的5个特征，分别是：
1）运行独立性：即使体系解散了，成员系统依然能独立运行且能发挥自己的用处；
2）管理独立性：体系的成员系统有自己所有权和管理权；
3）进化式发展：体系的目标和功能会持续变化，因此体系不会显示出完成的形式，进化会一直在路上；
4）行为涌现性：体系整体涌现出的行为能力不来自于任何成员系统，而这恰恰是体系设计的目的所在；
5）地理分布性：体系的成员系统往往分布在不同的地理环境，彼此通过网络连接，只交换信息，不交换物质或能量。
迈尔也根据体系总体对成员系统的管控程度将体系分为4种类型。
1）虚拟型（Virtual）。体系缺乏中央管理机构和集中一致的中心目标，但虚拟体系必须依赖不可见的机制来维持运转，会涌现出大尺度的行为，例如经济体系；
2）协作型（Collaborative）。具有一致的中心目标，体系的成员系统间或多或少地通过自愿协作的方式来达成中心目标，但仍缺乏中央管理机构。互联网就是一个典型的协作体系的例子；
3）公认型（Acknowledged）。体系具有中央管理机构，但是中央机构对于成员系统并没有完全的权力，成员系统保持其独立的所有权、目标和资金。美军的三军联合作战体系便是典型的公认型体系；
4）导向型（Directed）。体系不仅具有中央管理机构，能够对体系的成员系统进行指挥和控制，约束成员系统的发展。导向型体系是一种强管控的体系。从四种体系的定义来看，是否具有中央管控以及管控的力度是进行体系分类的依据。
体系工程与系统工程的区别
《体系工程指南》第二章从管理和监督、运行环境、体系构建实施过程以及工程与设计的考虑四个方面解释了体系工程与系统工程的区别，对于理解体系工程管理的复杂性与实施过程的挑战很有帮助。
在管理和监督上，系统的利益相关方是比较明确的，而体系的利益相关方首先分为体系与成员系统两个层面，都拥有不同的利益相关者，而且利益相关者团队各自都有自己的目标和组织背景。体系级的利益相关者可能对于成员系统的约束和发展计划知之甚少，而成员系统的利益相关者可能对于体系的利益也并不关心，可能对于体系提出的需求赋予较低的优先级甚至可能抵制体系对系统的需求，因此，体系层管理团队与成员层的管理团队之间存在着复杂的利益权衡与博弈。而如果一个成员系统被包含在多个体系中，可能面临的管理局面就更加复杂。
在运行环境中的单个系统，其任务目标是建立在结构化的需求上，或者与已定义的作战概念和开发的优先顺序相关的能力开发过程之上的，换句话说，在运行环境下，每一个单个系统都有其服务的重点和使命任务。而体系设计旨在创造超越独立系统能力之外的能力，这势必在功能上和信息共享方面对单个系统提出新的需求，而这些需求尚未在单个系统原有的设计中考虑。单个系统在考虑体系层面提出的新需求的时候一方面需要考虑对原有用户的影响，另一方面还需要考虑不同系统在命名规则、符号体系、交互规则和大量人机界面方面的不一致给体系的使用和培训带来的挑战。总之，体系工程必须在体系的需求和单个系统本身的需求之间找到平衡。
在体系构建实施过程上，单个系统的采购一般只需关注于系统的生命周期和采办类型定义的里程碑，一般通过单一的国防部项目管理和系统工程计划来进行管理，而且能够进行整个系统的测试和评估。而对于体系来说，体系包含多种处于不同开发阶段的系统，包括原有的系统、开发中的系统、技术更新的系统、已过寿命期但仍使用的系统等。体系的管理者与系统的工程师们需要对现有的系统工程过程进行扩展或裁剪来满足不同系统的独特考虑，并满足体系的整体要求。体系能力的发展或演变通常不取决于单一组织，而是涉及多个国防部项目执行办公室、项目经理人，以及运行和支持的团体。这导致体系级的系统工程师的任务更加复杂，他必须掌握体系的成员系统的演进计划，开发优先级及其不同步的开发计划，以便规划和协调体系内各成员系统逐步实现其目标。除此类开发挑战外，根据成员系统的复杂性和分布情况，可能难以或无法完全测试和评估体系的功能。
在工程和设计的考虑上，设计单个系统要考虑的重要因素包括边界、接口以及性能和行为。系统边界是一个很重要的概念，我们常说系统有明确的需求边界，而体系则没有。边界是指界定系统范围的功能界限，界限内属于系统，界限外属于外部环境，与系统的关系通过信息交互的接口来考虑。单个系统的性能和行为一般具有自主性，即主要靠系统自身的属性，但其实也与环境中的其他因素有关，例如对通信、命令和控制的依赖。相比之下，体系的性能不仅取决于单个成员系统的性能，还取决于系统间端到端的组合行为。为使体系发挥作用，成员系统必须共同工作才能达到必要的端到端性能。因为能够使体系达到所要求的能力要求的系统组合有多种，因此体系的边界相对模糊。
朱迪思·达曼的体系工程核心元素
《体系工程指南》第三章与第四章以朱迪思·达曼提出的核心要素模型为主要内容，描述了体系工程在传统系统工程之外的7个核心要素过程，如图1所示。给出了7个核心要素过程执行的细则以及传统的系统工程过程与核心要素过程之间的关系。这些内容来自于朱迪思·达曼的数篇论文成果。
图1 体系工程核心要素模型
朱迪思·达曼的体系工程核心要素过程介绍如下：
1)转换能力目标
能力目标是体系存在的必要性，体系能力目标是整个体系工程的总目标，因此如何将体系的能力目标分解为成员系统的需求是体系构建的关键。《体系工程指南》中举例说明了能力目标的形式，如：
●提供卫星通信（MILSATCOM：军用卫星通讯系统）
●提供全球导弹防御（BMD：弹道导弹防御系统）
●为所有客户提供单一的战场空间视图（SIAP：单一综合航空影像系统）。
美国国防部的装备发展已经由原来的基于威胁的需求开发转变为面向能力的需求开发方式，这一点在前期对美国国防部的JCIDS的解读中有过详细描述。总之，能力是体系设计的总目标，通过能力目标转换，才能获得体系成员系统的开发需求，因此能力分解是体系工程的核心过程。
2)理解系统和关系
体系的能力目标是通过成员系统间交互与协作共同涌现出来的，因此成员系统之间的关系是体系设计的重要内容。
我们能首先想到的是体系的成员系统的功能以及功能之间的数据交换关系，《体系工程指南》中举例美国海军的NIFC-CA体系作为示例说明，如图2所示。
图2 美国海军NIFC-CA体系数据交换示意图
由于体系的特点，《体系工程指南》中还举例其它重要的系统关系，包括：
●系统之间的组织关系（由谁负责系统的管理和监督？）；
●利益相关者，包括SoS和成员系统的用户以及体系设计工程师们的机构背景；
●资源关系（谁负责资助系统的哪些方面以及它们与SoS资助机构之间的关系）；
需求关系（成员系统的需求与SoS能力之间的关系是什么？）；
●成员系统的开发过程和计划与SoS之间的关系。
3)能力目标性能评估
体系工程的验证与确认过程是评估体系的效能输出对能力目标的满足程度，因此该过程也是非常重要的。
体系开发过程中有两个层次的测试，一个是开发测试和评估；一个是操作测试和评估。体系能力目标的性能评估主要在操作测试和评估层次，即在体系的成员系统开发完成后，在体系层进行体系整体的集成后开展体系能力目标验证。
4)开发、演进和维护体系框架
体系一般都具有较为稳定的架构，体系的架构来源于现实的业务逻辑，而随着业务目标的变化，体系的架构会随之改变，需要持续维护，因此该过程也是体系工程的核心元素过程。
针对体系架构，美国国防部专门开发了一个架构框架描述标准，即DoDAF，前期我们也专门进行过解读。《体系工程指南》中引用DoDAF的内容，指出架构包含：
●作战概念，用户如何在作战环境中使用系统；
●体系内部和外部系统的功能、关系和依赖性；
●端到端功能，数据流以及通信。
美军的作战体系框架，基本都是以OODA环和C4ISR为基础的，OODA是指观察、调整、决策和执行；4ISR分别对应指挥、控制、通信、计算机、情报、侦察与监视，C4ISR与OODA的对应关系如图3所示。
图3美军作战体系架构基础框架示意图
5)监测和评估变化
体系是持续进化的，没有“完成”的模式。体系业务需求的改变，成员系统的升级以及非预期的涌现性的发现，都会带来体系的进化，体系设计者需要随时关注体系中的变化并评估变化对体系的影响，因此该过程也是体系工程的核心元素过程。
《体系工程指南》中指出，体系设计工程师们需要关注以下变更内容：
●持续监控建议的或潜在的更改，并评估其对SoS的影响；
●确定增强功能和性能的机会；
●排除或缓解SoS和单个系统的故障问题；
●与系统工程师就成员系统进行协商，以了解如何进行系统更改，以防止对SoS产生不利影响，反之亦然；
●在部署单个系统更新/更改时更新SoS产品基准。
监测和评估体系需求的变化过程是一个配置管理的过程，因此体系工程的实施部门应该建立规范的配置管理制度。
6)处理新需求和选项
一旦体系中出现新的需求，设计者需要分析需求的影响和优先级，并协调新需求的利益相关方共同处理，这项核心元素过程活动最终将形成一份用于使SoS不断演进的技术规划。
7)体系的协调升级
在发现和分析完体系新的需求后，需要对体系的升级工作进行计划与组织。在执行计划和完成体系升级的同时，体系工程团队还需评估修改后的体系的新效能，还需要对为支持体系而对成员系统做出的变更进行测试和评估。
Dahmann核心元素模型中的7个核心元素过程，可以总结为两个阶段，即体系构建阶段（1,2,3,4）,和体系的进化升级阶段（5,6,7）。这正是体系生命周期的两大阶段。Dahmann在后续的研究中，根据体系进化升级的特点，还提出了体系工程Wave模型,生动展示了工程体系不断发现需求、处理需求，架构升级以及体系不断进化的过程。
系统工程对体系工程的支持
《体系工程指南》第四章第2节，介绍了完整的系统工程的每一个过程阶段与体系工程的7个核心元素过程之间的关系。系统工程过程包括：需求开发、逻辑分析、设计解决方案、实现、集成、验证、确认、交付、决策分析、技术规划、技术评估、需求管理、风险管理、配置管理、数据管理和接口管理过程。显然，此系统工程过程参考了NASA的系统工程过程模型，如图4所示。
图4 NASA系统工程过程模型
美国国防部体系工程试点项目
在《体系工程指南》附录中，列举了参与体系工程试点的体系项目，以及项目的基本情况介绍。通过这些项目可以看出美国国防部在落实联合作战道路上的雄心。这些项目包括：陆军作战指挥系统、空军作战重心（AOC）武器系统、弹道导弹防御系统（BMDS）、美国海岸警卫队（USCG）指挥与控制（C2）融合系统、通用航空指挥控制系统、空军分布式通用地面系统（DCGS）、国防部情报信息系统（DoDIIS）、未来作战系统（FCS）、军事卫星通信（MILSATCOM）、海军一体化火控-防空（NIFC-CA）系统、国家安全局（NSA）项目、海军水面战中心系统工程项目、单一综合空中图像（SIAP）、SMC/EA：空间和导弹系统中心工程与建筑管理局、太空雷达系统（SR IPO）、战区联合战术网络、战区医疗信息项目。读者感兴趣可以阅读参考。
总结
美国国防部体系工程指南是美国国防部在开展联合作战体系工程研制过程中，结合学者的研究成果和传统的系统工程方法，经过多个体系级工程实践经验的磨练而总结出来的指导方法。虽然该指南契合的是美国国防部的装备采购和管理规范，未必完全符合我国的体系级装备研制管理流程，但从技术层面上，其总结的体系工程核心元素模型以及体系工程的两大阶段，即构建阶段和演化发展阶段，对于我们开展体系工程理论和实践应用研究具有很好的指导意义。
声明：本文来自体系工程，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
