黄 冉，武新峰，崔桂玲，彭祺擘

（中国航天员科研训练中心，北京 100094）

1 引言

当前，各航天强国高度重视载人航天发展，出台多项政策牵引载人航天体系研制［1］。载人航天工程涉及系统多、方案复杂、接口繁琐，是公认的巨系统。传统系统工程方法以文档为核心，其众多的信息分散在不同的设计文档中，对复杂、动态的交互活动难以全面正确地描述、保证文档一致性；不同设计人员所关注的领域不同，从同一文档中读取的信息很容易产生理解差异；设计过程中经常出现反复迭代等情况，已经无法满足研制需求［2-3］。

为解决以上问题，国际系统工程学会（International Council on Systems Engineering，INCOSE）倡导基于模型的系统工程（Model-Based Systems Engineering，MBSE）方法应运而生［4］，采用更加经济、迅速且高质量的开发方法解决复杂系统设计［5］。为了支持MBSE，INCOSE 和对象管理组织（Object Management Group，OMG）在统一建模语言UML（Unified Modeling Language）的基础上衍生了一种新的系统建模语言SysML（Systems Modeling Language）。

随着MBSE 的发展，针对巨系统的特点，基于模型的体系工程（Model-Based Systems of Systems Engineering，MBSoSE）得到了INCOSE 和OMG 的大力支持［6-7］。体系作为系统工程的新发展方向，所有独立系统可作为内在驱动，获得比传统系统工程更加优异的能力和性能。体系框架呈现一个高级视点，诠释各个独立系统间的相互作用，描述组成系统、体系、系统与环境的关系以及指导设计的原则，显像化体系涌现性和演化特征，可很好地支持决策者分析理解体系与环境概貌等［8］。正确完备的体系框架展现合理的体系顶层定义，是设计可以顺利开展的重要基础。NASA、美国国防部、ESA 都在积极地推动统一体系框架应用。2017 年10 月，OMG 发布了最新体系统一架构（Unified Architecture Frame，UAF）模型，提供了一种互通互容、能力强大的体系框架标准［9-11］，具有更加细致、合理的矩阵视图。

本文采用MBSoSE 思想，基于UAF 模型提出载人航天体系框架设计方法，已期解决各系统技术接口交叉复杂、研制过程异构演化、顶层需求非指标化、技术管理动态变化、设计影响多级涌现等问题，实现相对优势方案设计以及模型的结构化定义，并通过数字化模型仿真，用以方案验证和快速迭代更新。

2 框架设计

2.1 UAF 体系框架

UAF 作为最新的体系设计框架理念，支持MBSoSE，使用面向对象的设计思想，围绕真实的世界概念，采用自上而下分解和自下而上归纳相结合的设计方法。UAF 兼容美国国防部体系框架（Department of Defense Architecture Framework，DoDAF）、英国国防部体系框架（Ministry of Defense Architecture Framework，MoDAF）和北约体系框架（NATO Architecture Framework，NAF）等现有常见体系框架，创新性强，具备强大的兼容性和可扩展性。

基于UAF 的体系框架模型对问题空间进行分割、分析、归纳、抽象，从多个领域和视角建模，相互逻辑更加完整合理；以需求为牵引，覆盖战略目标、业务支撑到技术实现，并从分类（taxonomy）、结构（structure）、关联性（connectivity）、流程（processes）、状态（states）、交互场景（interaction）、信息（information）、参数（parameter）、可追溯性（traceability）等11 个矩阵视角开展体系建模，以达到模型互相支持、互为支撑；既是描述、分析、规范、设计和验证体系的方法论，也是体系顶层设计的具体成果展现形式。UAF 综合考虑体系各方面要素和相互关系，实现更加细致、合理、相对独立的视图设计，这些视图将不同设计者的愿望和思想体系化，并共同构成了对体系的整体认识。其元模型也更加完备，与DoDAF 12 个元模型相比［12］，UAF 80 多个元模型（模型元素）不管在数量上还是在完备上都有很大的提升。

UAF 具有很强的灵活应用性，可根据任务需求剪裁和组合，但目前OMG 发布的仅有抽象的指导性文件，没有具体的开发程序，且目前国内外并没有达成一致的、适用于各个行业的基于UAF体系框架具体设计流程和方法。

2.2 载人航天体系框架设计流程

鉴于UAF 特点，本文结合UAF 框架设计指导方法和载人航天任务工程总体技术特点，以任务顶层需求为驱动，利用UML 和SysML 建模语言，从纵向和横向2 个维度开展载人航天建模流程设计。

梳理任务分析背景和顶层需求，以实现需求为牵引，开展体系能力设计，构建支撑能力的业务目标以及总体实现框图，且根据目标配置支持系统资源以及资源实现方式。以任务需求为起点进行6 个自上而下的领域设计，包括顶层需求域、战略域、任务域、地基支持系统域、天基支持系统域、总结域。将每个领域分解为静态、动态、交互、支撑、约束等多视图；每一个视图的设计结果自下而上反过来完善、修正上层设计，多轮迭代体现在整个架构的开发过程，最终构建科学、合理、完整的载人航天架构。每一个新的输出视图都会实现输入视图的迭代复核，迭代表现在整体和细化2 层，其中整体迭代为每个设计域之间的迭代，一个设计域的结果为下一个设计域的输入，同时下一个设计域结果修正上一个设计域，形成一个完整闭环；细化迭代为每个设计域内的模型都是架构活动的循环迭代过程，同时也是迭代结果，通过细化迭代构建出更加完善合理的映射关系，保障该设计域的完备性和逻辑合理性，设计流程如图1所示。

图1 基于UAF 的载人航天体系框架设计流程Fig.1 Design process of manned space system based on UAF

1）顶层需求域以顶层需求为设计起点，使用SysML 需求图捕获，后续开发的各个阶段均是需求与功能或设计要求的上下级交互，各个视角的构建均在需求的牵引下开展，在不同的设计阶段层层细化，并通过追溯视角更新，一步步关联设计与需求。

2）战略域完成体系能力定义和战略目标设计。该域各个视角的构建均在顶层需求的牵引下开展，主流程以完成总体构想，即高层概念图模型为目的，实现顶层抽象描述，不涉及具体工程实现过程。辅助流程需全面分析任务，添加国内外背景和载人航天现有任务组织体架构，预想能力实现的初步方式以及初步分解阶段。本域以高层概念图为主流程设计输出结果。

3）任务域完成候选系统能力分配和业务能力支撑设计。主流程将高层概念图逐步细化，形成技术要求中能力需求部分。辅助流程更加清晰完整地描述任务目标和功能、分析设计约束、任务状态、性能操作流程，任务要素相互关系，逐步分析出实现任务能力所需的系统功能以及系统设置方案，辅助视图完善了主流程的技术要求内容。本域以系统技术要求为设计输出结果。

4）天基和地基支持系统域完成技术、资源实现的抽象设计，即开发可执行系统，完成模型仿真迭代和体系优化重组。主流程根据任务架构和现有天基、地基支持系统设置情况，以任务域技术要求分解视图为输入，完成支持系统能力配置，系统和功能流程定义，各系统总体技术实现方案设计等。辅助设计通过假设、权衡支持系统配置情况，定义系统状态转换方式，信息、能量等接口方式，复核支持系统配置和技术实现方式合理性，辅助视图完善了主流程的系统功能。该域以功能活动为输出结果，结果在主流程中通过自下而上的方式，大规模扩充上一级任务域技术要求，全方面明确各系统对载人航天任务的支持性能和功能要求。

5）总结域通过模型逻辑仿真，完成方案设计的验证工作，以工程总体设计模型和报告为结束标志。

3 建模

载人登月任务是载人航天的典型巨系统任务，而巨系统作为复杂组织体涉及的不仅是求解问题，亦是对目标更好实现方式的探索［13］。载人登月任务是多系统、复杂协同设计任务，在成本进度严格约束下，如何在方案阶段完成最优总体设计是一项重大挑战［14］，本文选取该任务，使用UML 和SysML 标准建模语言，采用基于UAF 的载人航天体系框架设计流程开展建模实践。

3.1 战略域建模

全面分析载人登月任务国内外背景、载人航天任务组织体架构，建立战略域模型，包括：载人登月任务总体构想图、顶层能力结构图、登月飞行任务规划图、能力实现战略图、国内外背景分析图、追溯矩阵、载人登月顶层方案概念图等，实现概念和环境关系的总体描绘，确定发展战略；以实现战略目标为牵引，完成载人登月任务顶层能力体系的设计。

载人登月任务总体构想图使用SysML 术语中的Strategic Structure 图／表模型呈现（本文所述元素均为SysML 定义术语），如图2 所示。使用enterprise goal 元素建立载人登月任务的总体目标（即能力愿景），例如工程、科学等，愿景可与后续设计的各阶段元素进行结合，例如其中愿景-1 为全阶段任务，愿景-2 为其中某一阶段任务，每一个模型元素设计均可与其余元素建立相应关系，关系图同时可复核前期设计模型的正确性。根据能力愿景完成阶段和能力目标设计，使用whole life enterprise 元素呈现任务阶段，例如载人探月、科考等；使用capability 元素呈现不同任务阶段顶层能力，并建立之间的exhibits、trace、refine 等关系；使用actual enterprise phase 元素建立项目实际运行阶段目标，并可进行详细描述。

图2 载人登月愿景和目标模型示意图Fig.2 Schematic diagram of manned lunar landing vision and target model

分 解 顶 层 能 力，使 用 Strategic Taxonomy图／表呈现，如图3 所示。根据图3 输入，使用actual enduring task 元素，进行阶段目标划分，例如近地飞行、无人探月、载人探月、科考等；使用capability 元素进一步细化图3 中顶层能力目标，并建立之间的composition 关系，例如载人地月往返能力细化为进入轨道、载人飞行、任务支持等能力；同时建立能力capability、顶层需求requirement与任务阶段的verify 或exhibits 关系，例如近地飞行目标验证了工程目标、任务通用要求等。通过此步骤，梳理顶层需求、愿景、能力和阶段目标的自上而下的设计关系。

图3 载人登月顶层能力结构分解示意Fig.3 Top-level capability structure for manned lunar landing

分析任务运行环境或任务背景环境，使用environment 图展示，将可识别的运行环境条件（如自然环境、已有的技术条件、管理体系和可用的资源等）添加为任务背景的组成部分，建立任务环境和国内外载人登月进展情况模型，图4 为俄罗斯载人探月计划背景模型示意。

图4 俄罗斯载人探月背景模型示意Fig.4 Schematic diagram of Russian manned lunar exploration background model

构建任务初步规划，使用Strategic Phasing 图呈现能力满足关系，明确每个能力所需的实际项目支持方式。结合环境分析和国内外任务阶段情况，将阶段actual enduring task 元素进一步具象化实际项目阶段project 元素，并关联每个项目最重要的资源支撑能力，如图5 所示，例如近地飞行阶段追溯验证项目为火箭，火箭验证项目的成果可以满足无人近地飞行的能力要求，而资源支撑需要飞船和火箭。

图5 能力满足方式示意图Fig.5 Schematic diagram of capability satisfaction mode

通过上述各类关联元素，可自动构建能力依赖矩阵，如图6 所示，具像化显示需求、能力、愿景之间的相互支持关系。通过该步骤，可对建立的模型逻辑关系进行复核，如出现不明确的、缺失的任务需求或约束，可手动增加约束关系，并优化对应模型，直至任务需求、背景描述完整、合理。随着后续设计细化，该追溯关系将不断进行扩展。

图6 能力-愿景追溯关系矩阵示意Fig.6 Capability-vision traceability matrix

构建载人登月工程总体层级技术方案设想，完成顶层方案概念图，并可通过专家评估的方式，选出1～4 个初步最优方案，如图7 所示。该方案应包括系统初步设置情况说明，其中现有系统使用operational concept role 元素、新增需研制的系统使用capability configuration concept role 元素、新增需预研系统使用technology concept role 元素，并使用arbitrary connecter 表明系统之间的支持关系，用以抽象概述关联交互内容。使用environment concept role 元素表达太空环境，包括地球、火星、月球、小行星等。每个待选方案使用uc图，描述内部详细方案。后续在需求和初步总体方案的牵引下，对任务设计逻辑扩展，以便架构从战略域向下映射成更详细的系统功能行为，将体系的顶层能力转换为细化可实现的系统设计要求。本文后续以图7 中方案3 为例，即大推力火箭将载人飞船和月面飞行器一次性送入月球轨道，一次发射直接奔月、返回采用月球轨道交会对接的模型进行说明。

图7 概念设计示意Fig.7 Schematic diagram of conceptual design

3.2 任务域建模

构建载人登月任务能力实现的业务体系，建立模型包括能力分解图、系统设置图、任务活动及关系图、设计约束图等，用以清晰完整地描述任务目标和功能活动、要素相互关系，系统设置情况。对每个系统建立初步条目化技术要求模型，使用requirement 元素表达，以完成系统对任务的支持作用说明。

开展任务活动及关系分解设计，使用Operational Connectivity 图呈现，清晰描述系统之间的交互类型，包括信息、数据、指令等，如图8 所示。其中每一个系统的operational performance 元素可按照设计颗粒度要求进一步细化，形成内部的Operational Internal Connectivity 图，内部交互规则等。结合接口形式进一步分解设计，形成具体功能活动，使用Operational Process 图，实现抽象层面的活动分解，例如交会对接、组合体运行、载人落月等等。

图8 任务接口设计示意Fig.8 Design of task interface

定义任务域技术要求，以飞行活动operational activity 元素作为基本技术要求输入，建立每个活动分析其所需的性能和功能约束，使用Operational Constraints 建立性能moe 表；使用Operational Actual Measurement 表建立功能要求。以飞行活动action 对应的性能和功能约束operation constraint 进一步细化系统初步要求，同时反过来复核系统设置的正确性，能力分解的合理性。最终以requirement 和rule specification 共同作为该域设计结果。自动建立追溯关系，完成任务域设计复核，如图9 所示。如出现不明确的、缺失的任务活动或约束，可手动增加约束关系并优化模型，直至描述完整、合理。

图9 任务域追溯示意Fig.9 Task domain traceability

3.3 地基支持系统域建模

根据任务架构和现有地基支持系统设置情况，通过假设、权衡系统配置，确定实际规格以及对任务的详细支持方式和能力要求。地基支持域模型包括分类及能力配置图、系统间相互关系图、功能活动分解及流程图、设计约束要求图、追溯矩阵等。

以任务域技术要求作为输入，战略域的能力capability 元素作为牵引，使用Services Taxonomy图／表、Services Structure 图，建立地基支持系统分类方式，完成功能定义，每一个任务支持系统service specification 元素内部可建立状态基图services states，用于抽象描述该系统的主要工作状态。

开展地基支持系统功能分解和接口分析。按照接口类型选择合适元素，例如供电、供气等物理接口使用flow port 元素，信息、指令等逻辑接口使用proxy port 元素，空间支持、程序支持等接口使用services port 元素等。以地基支持系统services function 元素为输入，分析其所需的设计性能和功能约束，该步骤模型自下而上细化功能域技术要求设计，并完善设计结果。自动建立追溯关系，完成支持系统域设计复核，包括功能活动-任务域技术要求追溯和功能活动-任务域能力追溯等，直至支持系统描述完整、合理。

3.4 天基支持系统域建模

依据现有飞行器系统设置情况，分析地基系统与天基系统接口，通过假设、权衡确定实际配置，明确各系统支持能力／功能要求。天基支持系统模型包括天基系统能力配置及功能分解图、天基系统交互关系图、功能活动图、天基与地基系统交互图、设计约束要求图、追溯矩阵等。

以任务域技术要求为输入，开展能力配置及功能分解图，完成飞行器系统定义和组成关系图Resources Taxonomy，并通过进一步细化飞行器内部模块配置，使用Resources Structure 图，完成功能的配置分解，内部功能使用resources role 元素，例如月球车内部配置通信模块、行驶模块和能源模块等。建立系统交互关系图Resources Connectivity 图／表，以及飞行器内接口交互Resources internal Connectivity 图／表，并进行交互流方向说明，并自动生成Resources Connectivity 矩阵完成视图化检验。细化每个飞行器功能，使用Resources Process 图、Resources Process Flow 图，完成天基系统活动分解，用于描述天基系统如何实现任务Resources Function，每一个function 元素可继续细化为子功能，并建立关联说明（capable to performer、association、generalization 元素、composition 等关联元素）。该步骤可细化梳理交互信息，迭代优化上一步天基支持系统交互设计结果。以天基和地接支持系统功能活动为输入，梳理天基-地基系统交互关系Conceptual Data Model 图，使用use 元素进行地基功能service function 和天基配置resources artifact 的资源使用交互说明，如图10 所示，例如返回舱需要使用大量的地基着陆场资源，该步骤再次复盘信息模型的完备性。

图10 天基-地基支持系统功能交互图示意Fig.10 Functional interaction of space-earth support system

以天基支持系统function 元素作为输入，分析其所需的设计性能和功能约束要求，建立飞行器设计性能moe 表。使此步骤对每个分系统设计所需时间建立计划图。该模型自下而上细化功能域技术要求设计，完善设计结果。自动建立追溯关系，完成支持系统域设计复核，包括功能活动-任务域技术要求追溯、功能活动-任务域能力追溯和天基-地基活动追溯，如图11 所示，如出现不明确的、缺失的功能、活动、要求或约束，可手动增加约束关系并优化对应模型，直至支持系统描述完整、合理。

图11 功能活动-任务域能力追溯矩阵示意Fig.11 Space support domain function vs activity task domain capability traceability matrix

3.5 逻辑仿真验证

传统的基于文本的系统工程设计方法只能在实物阶段进行设计验证，无法在方案初期开展［15］。基于模型的系统工程可在设计初期开展仿真验证，识别逻辑问题［16-18］，从而实现设计自洽。本文采用CATIA Magic 软件对上述模型开展逻辑仿真，通过模型自动生成的时序图、追溯图等，加快设计师在每个设计域阶段复核、检验，不断修复完善模型。在仿真过程，逐步识别了冗余功能不足，接口设计不合理，接口输入输出类型不匹配，信息流设计不全面，功能、活动、要求或约束不全面等设计缺陷，通过不断完善，最终完成设计。每次识别出问题，可快速迭代完善、修改模型，所有设计师均可在线实时获得变更信息，快速识别是否对其余模型有影响，实时更新效设计方式，大大减少了协同工作量。

4 结论

1）本文借鉴统一框架模型设计思想，并在体系设计初期引入MBSoSE，实现科学、完整、深刻地认识载人航天任务，完成方案权衡。

2）完成面向对象的逐层递进建模，实现总体与系统大量接口快速设计，高效率完成方案更新和验证迭代。

3）基于UAF 的建模方法提高了架构设计的标准化程度，弥补了现有专有模型与型号工程研制标准化要求的差距，解决现有数字化建模方法不统一、基于不同架构的模型无法互相交互、难以开展全任务统一管理与追溯的问题。将已有系统和新增系统能力融合，共同转换为体系能力，达到1+1＞2 的效果，为载人航天体系架构提供了完整的设计指导。

4）通过载人登月建模示例可以看出，基于UAF 的多领域、多视角的视图模型，可覆盖任务筹划、顶层要求、任务分析、系统总体方案设计、逻辑仿真、迭代优化等工程技术总体全设计过程，并实现方案设计可评估，模型化的总体技术方案可充分发挥模型的优点，系统性地识别环境影响因素及其不确定性，并予方案可视化，确保方案优选，降低研制风险；且可在设计初期通过仿真发现大量非合理的设计要素，将验证闭环前移，提高设计质量和研制效率。