1.4 载人深空探测体系工程的内涵

20世纪70年代美国实施的阿波罗登月工程在项目管理上取得了突出成就，通过采用系统工程方法，解决了载人登月工程系统规模大、技术水平高、可靠性与安全性高、研制周期长、参与人员多、投资巨大等复杂项目管理问题。在产品研制过程中，从工程总体的研制要求到产品实现以及在轨运行，产生了具有复杂关联关系的海量设计信息，如系统、分系统、单机设计要求及接口关系等，这些信息当时主要是以文档的形式进行存储、交换与管理的。然而，自1969年形成美国军用标准《系统工程管理》（MIL-STD-499）以来，系统工程方法变化很小。但与此同时，随着载人深空探测任务论证的持续深入，以载人火星探测任务为例，系统的规模和复杂性却在显著地增长，涉及学科领域不断增多，信息管理的难度大大增加，而且不同文档中系统参数状态不一致的问题时常出现，导致出现很多设计安全隐患，因此传统系统工程（Traditional Systems Engineering, TSE）方法已经不能满足需求，急需一种新的方法和手段来改变这一现状。

2012年，NASA在论证重返月球的星座计划时，在一次项目管理挑战研讨会（Project Management Conference, PMC）上提出体系工程的概念，同时来自约翰逊航天中心的技术人员介绍了在航天服开发中应用基于模型的系统工程（Model-Based Systems Engineering, MBSE）的情况，得到了与会各方的赞同和肯定。当前，NASA所属的兰利航天中心、喷气推进实验室等都在项目研发、技术管理等方面积极推进应用MBSE方法，用于巨型复杂任务的项目管理，目的是显著提升项目的经济可承受性、缩短开发时间、有效管理系统的复杂性、提升系统的整体质量水平。

1.4.1 体系工程的概念及特点

体系即系统的系统（System of System, SOS），它不是简单的系统叠加，而是为实现某种能力需求的有机组合，体系具有一般系统组合不具备的功能与能力；体系工程是指面向体系的能力发展需求，在全寿命生命周期中对体系的设计、规划、开发、组织及运作进行系统的管理过程，目标是建立基于能力的动态系统，提供多种能力满足多项任务的需求。未来载人深空探测项目管理将呈现出体系工程的特点，主要体现在以下四个方面：

（1）载人航天任务需求日益复杂，越来越强调体系的能力建设。

在早期的载人航天任务中，通常是完成基于功能的设计，例如载人飞船最早就是为验证人在太空的短期生存能力而设计的，最主要的功能是保障人在太空的短期生存能力；到了空间站任务时期，体系的需求范围大大拓展，系统功能设计日益复杂，例如空间站不仅需保障人在空间的中长期生存功能，还需保障完成各类科学试验载荷的空间科学试验功能，也需保障进行复杂结构的空间组装和维修等功能。当多个舱段进行组装建造完成后，空间站系统表现出来的强大的体系能力，例如组合体的控制与管理能力、在轨运营与后期补给能力、空间应急救援能力，将大大超越单个系统工程，越来越突显出体系工程能力建设的特点，通过不同工程子系统的组合可以满足不同类任务的需求，例如用商业货运火箭发射货运飞船可以完成空间站系统的货物补给运输任务，也可以用载人飞船完成人员和部分货物的补给运输任务。

（2）体系工程中各系统间的接口日益复杂，接口管理和验证至关重要。

以空间站工程为代表的载人航天任务，由于系统组成过于复杂，模块多，进行体系工程设计时首先分解成若干工程大系统，再把工程各大系统分解成子系统，再把子系统分解成单个产品。体系工程中重点强调的是系统间以及子系统间的接口关系，这种接口关系可以简单到信息或数据的传递，也可以复杂到人机交互及管理控制等。子系统之间点对点互联的接口数等于n（n-1）/2，其中n是子系统的数量。例如，目前中国空间站系统拥有7个工程大系统，1个系统工程组织，一共15个子系统（包括航天员系统、空间应用系统、长二F运载火箭系统、长七运载火箭系统、长五B运载火箭系统、载人飞船系统、货运飞船系统、空间实验室系统、空间站系统、光学舱系统、酒泉发射场系统、海南发射场系统、测控通信系统、着陆场系统和工程大总体），各子系统间接口的数量有105个。NASA在DRA 5.0中提出的载人火星探测飞行器体系架构如图1-8所示，从图中可以看出仅仅是飞行器和运载火箭系统已有12个之多，中国空间站系统的飞行器体系架构仅仅相当于图中的深空居住舱、重型运载火箭和载人飞船系统而已，若把发射、测控、着陆、货运补给等多个因素考虑齐全，子系统的个数还需要显著增加，显而易见各子系统间的接口数量和关系更为复杂。

虽然载人航天传统意义上可以通过接口需求/控制文档资料进行管理，但是面对复杂大型的体系工程，接口之间的管理和验证将显得至关重要。最复杂和最重要的接口就是对工程大系统的安全与任务成败起决定作用的子系统间的接口关系，这类接口必须易于理解，易于使用，更改可控易追溯，同时能够易于验证，这将是未来载人航天体系工程面临的突出特点。

（3）体系工程中系统资源裕量管理难度高，越靠近寿命末期成本越高。

以载人登火星为代表的复杂载人航天任务中，体系工程师最重要的工作就是进行系统资源裕量的管理。系统资源管理主要是指质量、体积、能量/功率、数据传输速率、总线带宽、中央处理器（Central Processing Unit, CPU）利用和数据存储量、维修寿命、航天员出舱活动时间等系统级指标；裕量是指两个数值之间的差，通常是指系统需求或分配与实际值之间的差。对于复杂体系工程而言，资源和需求裕量可能是跨系统交叉的，因此需要分层次进行管理和分配。裕量管理的技巧是必须在正确的时间测定出裕量，以操控问题并减少风险，同时为未来的需求存留适量的裕度，包括跨子系统间的支撑裕量来平衡风险。很显然，超过裕量事件的发生时间越靠近任务全寿命周期的后期，花费代价就越高。例如对于机器人探测地外天体任务如需重构系统质量，成本大于20万美元/kg；对于载人探测任务而言，成本往往是10倍以上。

（4）体系工程项目实施的风险大，故障环节多，产品保证难度大。

众所周知，载人航天任务风险管理要求高，必须坚持安全第一的原则。在体系工程中由于工程各大系统中的各子系统生产研制单位地理分布广泛、参研单位众多，如果按照传统项目管理各自管控各自产品的风险，极易造成接口风险失控，系统故障环节多，一旦出现关键环节失效代价极其昂贵，因此将风险管理提升到体系工程师产品保证及质量风险管控的层面，也将是未来载人航天体系工程建设和管理的突出特点。

1.4.2 基于模型的系统工程概念

2007年，国际系统工程学会（International Council on Systems Engineering, INCOSE）在《系统工程2020年愿景》中，给出了“基于模型的系统工程”（MBSE）的定义，基于模型的系统工程是对系统工程活动中建模方法正式化、规范化的应用，以使建模方法支持系统要求、设计、分析、验证和确认等活动，这些活动从概念性设计阶段开始，持续贯穿到设计开发以及后来的全寿命周期阶段。由定义可以看出，MBSE方法与传统基于文档的系统工程方法在基础理论及基本流程方面没有本质区别，区别主要是在设计过程管理方式、工作形式及设计结果展示形式上。

MBSE和TSE的最大区别，就在于系统架构模型的构建方法和工具不同，以及由此带来的工作模式、设计流程等方方面面的区别。也可理解为传统的系统工程变成基于模型的系统工程，实际是从“基于文本” （text - based）向“基于模型”（model-based）的转变。这个模型，指的是用系统建模语言建立的系统架构模型，或者说是系统架构模型的建模语言从“自然语言、文本格式”转向了图形化的系统建模语言（Systems Modeling Language, SysML）。但MBSE并不是完全抛弃过去的文档，而是从过去“以文档为主、模型为辅”向“以模型为主、文档为辅”的转变。

MBSE方法相比于以文档为中心的系统工程方法具有以下优点：

（1）理解、沟通效率提高。可视化的模型比文字更容易被接受，图形化的符号配以文字描述，既直观、形象，又保证了信息的完整性，使不同人员对同一模型的理解更容易达成一致，可以提高不同设计人员之间的沟通效率。

（2）数据获取容易。基于文档的系统工程方法处理的最小对象是文档，用户所需的信息散布在大量的文档之中，因此查找起来要耗费巨大的工作量。而MBSE方法处理的最小对象是数据，结合数据库管理方法，用户能直接获得所需的指标参数，可大幅减少设计人员的工作量。

（3）技术状态可追踪性好。MBSE方法在工作过程中会不断建立模型之间的关系，通过这些关系实现技术状态的追踪性和关联性分析，完成对技术状态的全面分析和控制。

（4）设计验证一体化。MBSE方法在工作过程中强调同时考虑设计与验证，通过建立验证模型与需求模型、功能模型，以及其他设计过程中所用到的相关模型之间的关系，进行验证覆盖性分析，以保证所有项目均满足验证要求。

MBSE方法的最终目标是以模型为基础，构建出经过测试与验证的系统架构。在整个设计过程中，最基本的是构建系统的需求模型、功能模型和物理架构模型。

1．需求模型构建

需求模型是指从系统最顶层的需求直至最底层的需求，以及它们之间逻辑关系构成的集合。按不同侧重点，可将需求分为功能需求、性能需求、接口需求、可靠性需求、安全性需求、人因工程需求等。需求模型用于将系统设计过程中不清晰的期望、要求等转换成需要解决的具体问题，用于指导系统设计。对应于系统的不同层次，需求模型有一个层级结构，最顶层的需求来自用户的使用要求、成本约束、研制周期约束及各利益相关方的期望等，这些顶层需求都被划分为功能需求和性能需求等，并在系统内进行分解与分配，由系统到子系统再到单机部件，层层细化，这个分解和分配过程一直持续到完成完整的满足需求的设计为止。需求模型的构建如图1-9所示。

2．功能模型构建

功能模型是指系统完成既定任务目标所需要的全部功能的集合，其中包括对应系统级（如载人飞船）、分系统级（如测控系统）、产品级（如传感器），甚至更小单元的功能及它们之间的逻辑关系，用于指导系统组成的设计。功能模型在需求模型的基础上，通过逻辑分解进行系统功能分析，同时基于对任务过程的分析，梳理整个过程中的飞行事件，再通过飞行事件识别出每一层次的系统功能，如图1-10所示；之后对功能进行逐级归纳，形成系统的功能模块划分。此外，在功能模型的构建过程中，还要将总结出来的功能与需求模型中的条目进行匹配，确保每项需求都有功能与之对应。对于没有覆盖到的需求，要考虑其是否合理，是否需要添加相应功能对其支持；对于不支持系统需求的功能，考虑将其删除。

3．物理架构模型构建

物理架构模型用于描述构成系统的全部要素及它们之间的接口关系，同样由系统级直至产品，甚至更小单元的层级结构组成。构建系统的物理架构模型时，以需求模型和功能模型为基础，综合考虑性能指标、系统效能、研制成本、系统接口、技术风险等，开展多方案比较，选择能满足用户需求并能较好完成系统功能的系统组成方案。物理架构模型的构建如图1-11所示。

除上述三个基本模型外，完成整个任务设计还需要系统接口模型、产品结构模型、风险分析及验证模型等。建成任务设计所需的模型后，还要根据事先制定的逻辑规则建立不同模型之间的关系，实现对整个工程中数据的全面可达。整个过程反复迭代，不断细化，直至能清晰描述整个设计、验证及工作过程，最终建立一个完整、一致并可方便追溯与查询的体系，实现参数查询、覆盖性分析等工作，以保证系统设计模型的一体化，避免各个组成部分之间的设计冲突，降低风险。图1-12所示为MBSE方法不同模型之间的关系。

综上所述，MBSE将在载人深空探测领域得到广泛的推广使用。为应对基于文档的传统系统工程模式在复杂体系工程中产品和系统研发时面临的挑战，它可以逻辑连贯一致的多视角通用的系统模型为桥梁和框架，实现跨系统、跨领域模型的可追踪、可验证和全寿命周期内的动态关联。它适用于从概念方案、工程研制，乃至使用维护到报废更新的全寿命周期内的活动，从体系工程顶层设计往下到系统、分系统、单机或组件等各个层级内的系统工程过程和活动，包括技术过程、技术状态管理过程、协议过程和项目组织管理过程。