MBSE: 基于 SysML 的载人登月可靠性安全性需求分析

载人登月是一项十分复杂的航天任务，涉及多系统的协同，传统的基于文档的系统工程方法不利任务的设计。基于模型的系统工程(model-based systems engineering, MBSE)近年来在工业界被证明了是有效解决复杂系统正向设计问题的方法论， 也适用于载人登月相关系统的研发。在 MBSE 流程中，需求分析是顶层设计的第一步，也是各系统开展详细设计的基础。对于复杂系统，尤其是利益攸关方众多的复杂系统，需求分析能够准确捕获各方利益需求，有利于寻找符合利益攸关方需求的优化方案。同时，这些需求也将与系统设计相关联，形成可追溯、易验证的需求条目，以保证系统设计能够满足各方需求，从而设计出符合要求的系统。

载人登月以保障航天员安全为首，同时也必须保证系统的可靠性。因此，在进行系统设计的同时，也必须开展可靠性安全性分析.而可靠性安全性需求分析则是进行基于模型的可靠性安全性分析的基础。可靠性安全性需求通常会作为通用性需求的一部分纳入到正常需求之中^[3]，在现有的方法中并未如系统其他需求一样逐层分解和推导。然而，在进行系统设计时，可靠性安全性分析与系统设计通常由不同的工程人员开展，对于可靠性和安全性需求笼统的捕获和定义方式不利于后续相关分析的展开，难以通过需求验证指导系统的设计。结合可靠性安全性分析在载人航天中的重要性及目前方法的缺陷，有必要进行可靠性、安全性需求分析与验证全闭环流程的研究，以明确的、完整的可靠性安全性需求为牵引，通过仿真验证，完善系统设计。

本文以美国“阿尔忒弥斯”载人登月计划为背景，提出了面向顶层设计的可靠性安全性需求分析及系统设计方法，基于系统建模语言(system modeling language, SysML)建立了可靠性安全性需求分析的模型，通过仿真进行了可靠性安全性需求的验证，并完成了系统设计的改进。

1.基于模型的需求分析与系统设计

系统工程产生于上世纪 40 年代，并于 60 年代美国阿波罗工程时期形成体系。随着系统复杂性的不断增加，尤其是对系统开发质量以及开发周期要求的不断提高，传统的基于文档的系统工程方法已越来越无法满足要求，MBSE 开始兴起并正在逐步成为系统设计的基础。MBSE 从需求阶段开始即通过模型(而非文档)的不断演化、迭代递增而实现产品的系统设计，具有显著优势。1993 年， Wymore[4]出版了专著 Model-based Systems Engineering，标志着 MBSE 的正式问世。但由于软硬件环境的限制，MBSE 并未取得突破性进展。近年来，受软件工程巨大成功的影响，国际系统工程学会(INCOSE)和对象管理组织(Object Management Group, OMG)于 2007 年正式提出了 SysML^[5]，MBSE 成为学术界和工业界研究与关注的重点，取得了较好发展，并在部分工程中进入实用。

MBSE 的方法论有很多，最著名的是 V 型的 Harmony 系统工程方法^[6]，从系统需求出发开始正向设计，再通过仿真进行反向验证。除此之外，IBM 公司提出了统一软件开发过程(RPU)^[7]，Vitech 公司提出了自己的 MBSE 方法^[8]，国际系统工程学会也提出了以目标为导向的系统工程方法^[9]等。这些方法论将需求分析、功能行为设计和设计验证等有效组织起来，使全系统的设计可追溯、易管理。可以看出，需求分析是进行 MBSE 的首要步骤，同时需求分析和系统设计在 MBSE 的全流程之中也是紧密耦合的。为了使 MBSE 全流程建模方法更加实用化，达索公司配合 MagicDraw 软件给出了基于 SysML 的 Magic Grid 方法论^[10,11]，将问题用域来描述，每个系统设计都包含了问题域、解决域、实施域三层，每层都由需求、行为、结构体和参数四个维度的定义来完成描述，形成了方案矩阵，需求分析在每一层中都是首要的。目前，在航空^[12,13]、汽车^[14]与航天^[15,16]等领域，都是结合自身工程实际，在上述方法的基础上通过适当的裁剪或改进，完成系统设计。

从方法论和应用层面来看，系统需求分析有较为成熟的体系，尤其是系统正常功能的设计。即从利益攸关者的要求出发，逐层分解、推导，给出子系统或分系统的设计要求。

2. 基于模型的可靠性、安全性分析

随着 MBSE 在工程领域的成功运用，基于模型的可靠性、安全性分析方法也越来越得到重视。作为系统工程的一部分，可靠性安全性分析也应该融入到 MBSE 的流程之中。

在现有的文献中，以基于 SysML 的设计模型为基础，开展了许多关于基于模型的可靠性安全性分析方法的研究，形成了包括文献^[17, 18]在内的方法论。目前的研究重点是如何运用系统正向设计的产物，定义故障模式和故障传递关系，从而自动开展可靠性安全性分析，生成失效模式及其影响后果分析表和故障树^[19−21]。这些分析方法均需要从顶层的可靠性安全性需求出发， 如何梳理复杂系统的可靠性安全性需求，开展系统设计，则成了复杂系统顶层设计中的重要问题。

在传统的 MBSE 流程中，可靠性安全性需求属于通用需求的一部分。但不同于其他通用需求，可靠性安全性分析多是基于系统的异常行为，其与系统正向设计的区别不仅在于模型上，在开展方法上也有很大差异。为了便于实现可靠性安全性分析与系统设计一体化，需要将可靠性安全性需求提取出来，在进行需求推导的同时，也逐步开展可靠性安全性需求的捕获与定义。

针对可靠性等这类系统非功能性的属性，RUP 方法对此进行了区分^[7]，在系统设计的初始阶段就将系统需求分为了用于捕获系统功能性的需求和覆盖系统非功能属性的需求，如可靠性安全性需求，使可靠性安全性分析尽早融入到 MBSE 之中。此外，在最新的 Magic Grid 方法论之中^[10]，也将可靠性安全性分析考虑其中，即在方案矩阵表中最后一列增加可靠性安全性分析，使每一层的设计都有对应的可靠性安全性分析的介入，验证初始需求， 指导系统设计。

从目前基于模型的可靠性安全性分析方法的发展和实际工程需要来看，可靠性安全性分析需要与系统正向设计同步，即从需求分析起开展，但又必须有所区别，使可靠性安全性分析作为 MBSE 中的一个重要组成部分，在依赖 MBSE 设计过程的基础上也能够独立进行。

需求分析是开展基于模型的复杂系统设计的第一步，负责识别全任务周期中与任务或目标有关利益攸关方的需要和期望，以及设计过程中为完成既定任务需具备的能力，并将其转化为明确的、无歧义、可测量与可追溯的条目化需求模型。而针对可靠性安全性分析和设计，则需要提取利益攸关方对于任务风险的期望、设计过程中应对风险的能力等，并将其转化为符合要求的可靠性安全性需求模型。

基于模型的可靠性安全性需求分析需要与系统正常的需求分析流程相匹配。文献[22]指出载人登月顶层系统结构可分为任务、能力和系统三个层次。任务层面是对事件、资源、交互关系和操作规则等的描述； 能力层面是对系统具备能力的描述； 系统层面是对具体的系统组成、性能和关系等的描述。对应的需求分析也可从这三个层面出发，包括任务需求建模、能力需求建模和系统需求建模。

关于可靠性安全性方面的需求，则需要在任务、能力及系统需求建模的同时进行分别提取和推导，从顶层逐步得到可用于指导系统开展具体设计的可靠性安全性需求条目。对顶层任务，基于模型的系统可靠性安全性需求分析的流程如图 1 所示。

可靠性安全性需求分析在各层中的作用及输入输出产物如下:

1) 顶层的可靠性安全性需求

顶层可靠性安全性需求分析的目标是全面收集并记录任务实施中各利益攸关方与风险相关的需要和期望，并将其转化为明确、可标识的故障管理需求在任务层的模型元素，以便后续在任务分析、系统设计和可靠性、安全性分析过程中快速查询以及提取和追溯. 本层的需求可以从任务层需求中进行提取，其输入为下达的任务及有关指标要求，需要从用例图构建的利益攸关方关系图中取出有关风险或任务异常的信息。输出则为可靠性安全性需求在顶层的模型， 例如对任务成功的期望、对风险的承受度等。

2) 中间层的可靠性安全性需求

中间层需求分析的目标是， 基于覆盖全任务周期的运行场景， 分析、推导出为实现顶层可靠性安全性目标和满足其他相关需求所需具备的能力，并将能力转化为明确可标识的可靠性安全性模型元素。本层的输入为可靠性安全性顶层的需求模型和在能力需求建模中构建的任务场景与系统组成架构，输出为中间层的可靠性安全性需求模型，例如应对风险的能力、确保任务成功的能力等，并形成条目化能力需求和异常时的任务场景。

3) 底层的可靠性安全性需求

底层可靠性安全性需求分析的目标是，基于细化的任务场景及其推导出的关键功能活动，推导关键功能失效风险及相关应对能力， 并将其转化为明确、可标识的系统需求模型元素。本层的输入包括上层可靠性安全性需求模型、任务场景和任务功能架构。输出为可靠性安全性的底层模型，例如各系统、分系统应对风险能力和相关性能要求。

除此之外，为了检验系统的可靠性安全性需求是否正确及合理, 还需要对其进行验证。通过先验知识或开展仿真验证后，最终再将形成的需求条目分发给对应的系统或分系统。否则还需要调整顶层架构设计，重新进行可靠性安全性需求分析及验证。

2017年，美国启动阿尔忒弥斯计划(Artemis Program)^[23,24]，主要支持载人登月和未来的载人火星探测任务。计划在未来 10 年内在月球表面建立一个永久基地，开展人机联合探测, 并以月球作为未来登陆火星的“跳板”，实现载人登火等深空探测的目标。本文以美国阿尔忒弥斯载人登月任务为例，进行该任务的可靠性安全性需求建模分析、顶层设计和需求验证。

1.顶层可靠性安全性需求分析

顶层可靠性安全性续需求分析建模的具体步骤如下:

1) 提取利益攸关方对于任务风险的期望：基于识别的利益攸关方、任务目标、系统边界和外部参与者，根据已识别的利益攸关方对于任务风险的需要、期望和能够明确的约束条件，形成条目化任务需求，并完善所建立的用例图，增加可靠性安全性的需求，使用 requirement 元素承载，并建立利益攸关方与这些可靠性安全性需求的关联关系。

2) 顶层可靠性安全性需求的复核：完成对任务背景或运行环境的建立后，在复核系统设计需求的同时，完成对顶层可靠性安全性需求的复核，如出现不明确的、缺失的任务需求或约束，应重新分析利益攸关方的关系，提取任务目标, 重新建模, 直至所建立的顶层可靠性安全性需求通过审核。

阿尔忒弥斯载人登月任务的顶层涉及的利益攸关方包括国家层面的美国政府和任务主管方美国宇航局(NASA)。从 2019 年美国副总统发布的声明中^[24]可提取出在国家层面的任务需求为 2024 年前将宇航员(包括首位女性)送上月球，NASA 以此为目标，给出了登月的具体需求，包括经费预算(首期追加 16 亿美元)费用、登月目标(建立永久月球基地)、并给出具体技术方案、组织方案以及任务总体风险指标等。结合美国政府的需求，可推导出 NASA 对任务风险的总体原则，例如顺利完成地月往返，确保宇航员安全。此外，为了支持这项总体原则，NASA 结合历史任务和政府期望，给出包括如可靠性安全性指标、总体设计原则、逃逸与应急救生原则在内的相关需求，如图 2 所示(图中需求 requirement 和用例之间使用 dependency 关系关联，用例作为供应端发生变化，也会导致需求的改变，在后续图中，需求与用例、block 间均使用这种关系表达需求对供应端的依赖)。

当捕获得到这些可靠性安全性的需求后，与其它需求一样，需要转换成可执行的可靠性安全性相关的需求条目，如图 3 所示，用于下发、管理及后续可靠性安全性需求的进一步分析。

2. 中层可靠性安全性需求分析

中层可靠性安全性需求分析、建模的具体步骤如下：

1) 基于场景的中层可靠性安全性需求的推导：使用用例图、块定义图等完成初步任务场景、系统组成架构的构建。结合任务场景和顶层可靠性安全性需求，识别推导与任务场景相对应的风险、故障处置等有关的需求，并建立条目化的需求模型。

2) 需求复核：依据任务景，对推导出的中层可靠性安全性需求进行复核，确保每个需求均有相应的任务阶段、关键功能或系统组成与之对应。如出现不明确的、缺失的中层需求，应重新细化任务场景，推导需求，直至其通过审核。

根据阿尔忒弥斯的技术方案，为了支持其任务的成功实施，整个登月系统由以下分系统组成^[24]：太空发射系统(space launch system, SLS)、猎户座飞船(Orion Capsule)、地面支持系统、Gateway 空间站、载人着陆系统、其它商业及国际合作系统。阿尔忒弥斯计划的第一阶段将由三次飞行组成：阿尔忒弥斯 I 为无人环月飞行、阿尔忒弥斯 II 为载人环月飞行并在月球南极登陆、阿尔忒弥斯 III 可能在环月空间站进行在轨操作。每一次任务均需开展相应的分析工作，本文以阿尔忒弥斯 II 为例，根据文献^[25]提出的飞行方案，整个任务将由以下场景支持：将月面上升器送入环月轨道、将返回器送入环月轨道、将登月器送入还月轨道并与上升器完成交会对接、将载人飞船送入环月轨道并与组合体完成交会对接、完成着月和月面活动(期间飞船与返回器交会对接)、月面上升与飞船交会对接并返回地球。

依据上述方案，使用用例图构建任务场景，如图 4 所示。针对每个子场景，则由任务可靠性指标衍生出每个子场景的成功率要求： 若场景中还有宇航员参与，则还会由安全性指标衍生出每个场景宇航员安全率的要求。

同时，为完成这一系列的场景，还需要多个分系统的支持。因此，首先通过如图 5 所示的块定义图构建了阿尔忒弥斯 II 的系统组成架构，涵盖了支持任务开展的运载火箭、飞船等多个系统.针对系统组成架构，也会由任务可靠性指标衍生出对每个参与系统的可靠性要求。

除此之外，由于顶层对于逃逸与应急救生的需求，在系统组成架构中还可以提取出相关系统对于其发生故障时应采取措施的设计原则。例如，每个系统必须设计应急策略确保危害宇航员安全的故障发生后，后果能够得到减缓，或者协助其它系统完成应急策略的执行。在开展具体应急策略设计时，各系统也必须结合飞行场景分阶段进行详细规划。

3. 底层可靠性安全性需求分析

底层可靠性安全性需求的建模、分析的具体步骤如下：

1) 细化飞行阶段，并将关键功能活动分配至对应的系统：以初步任务运行场景为主线和输入，进一步细化飞行方案或飞行场景，分析每个飞行阶段需开展的关键活动或飞行操作，建立关键功能活动之间的逻辑顺序。将识别的关键功能活动分配到相应系统的泳道分区中，并进一步识别和建立系统间、系统内部间信号的传递关系。通过多次迭代，建立可用于支持系统任务逻辑流程仿真的功能模型。

2) 推导底层可靠性安全性需求：在完成关键功能活动分配的基础上，根据关键功能的行为特性识别相关的功能需求、性能需求， 并建立条目化需求模型。提取关键功能所对应的失效模式，可将上层可靠性安全性需求，例如风险概率进行分解，也可根据先验知识， 初步给出关键功能可以容忍的失效概率。

3) 底层可靠性安全性需求复核：依据关键功能和系统需求分配情况，对推导出的底层可靠性安全性需求进行复核，确保每项需求都至少有一个活动或块与之关联。

以 Orion飞船地月转移加速为例，将该任务场景进行细化，得到如图 6 所示的活动图。提取出该任务场景的关键功能，开展故障分析，识别出对应的故障模式， 如图 7 所示。

基于此，可以捕获到底层关于可靠性安全性的需求，即发生此类故障后应该有能力采取对应的处置措施。如图 7 所示，这些底层需求实际上也是对中层需求“阿尔忒弥斯 II 逃逸与应急救生设计原则”的细化。由于这些故障处置措施都需要测控通信系统的参与， 发送相关指令信号。因此，也会衍生出对测控通信系统的额外需求，例如“应急通信能力”需求。

4.可靠性安全性需求验证案例

至此，完成了对顶层系统的设计，并基于此得到了细化的可靠性安全性需求条目。为了检验系统架构是否满足可靠性安全性需求， 需要开展初步的可靠性安全性分析，对相关条目进行验证。

开展可靠性安全性分析的方法有很多，可以采用跨平台的分析方法，使用可用于可靠性安全性分析的一些领域建模语言，例如文献^[26–28]。将系统模型进行映射后，基于此再开展对应的分析工作。 为了便于分析结果及时反馈到系统模型，减少模型交互，本文基于 SysML 开展了相应的分析工作。

根据 4.3节得到的 Orion 飞船地月转移加速过程中的典型故障模式，开展了功能危害分析(functional hazard analysis, FHA)，得到如图 8 所示的分析结果，包括只会导致无法登月和同时导致宇航员损伤两类。

为了验证此阶段的安全性指标，提取出危害宇航员安全的故障模式，如图 9 所示，基于此使用 SysML 参数图构建出以宇航员损伤为顶事件的故障树，如图 10 所示。

根据如图 7 所示的对于逃逸与应急救生策略的需求，针对各项典型故障模式，开展了处置策略的设计，完善了系统架构，如图 11 所示，得到了包含处置故障下的功能逻辑结构。

同样，需要对此阶段的安全性指标进行重新验证，进一步提取出危害航天员安全的故障模式及其他相关元素，如图 12 所示。在构建处置策略与需求间关系的同时，使用 SysML 参数图构建出以新的以宇航员损伤为顶事件的故障树，如图 13 所示。初步给定各故障处置措施成功的概率，重新计算顶事件结果。若根据图 12 中给定的概率值进行计算，得出的结果为 2.119 9e–6，说明新的改进方案满足了对应的需求。

作为系统工程的一部分，可靠性安全性分析在 MBSE 全流程中也应该形成从需求出发到分析验证的完整闭环。本文将可靠性安全性需求从系统需求模型中提取出来，在开展航天任务顶层设计的同时，捕获更为详细的可靠性安全性需求，便于后续的追溯、管理和验证。根据载人登月任务顶层设计的特点，也将任务层的可靠性安全性需求分为顶层、中层和底层，并给出了如何推理得到可靠性安全性需求的流程。以美国阿尔忒弥斯载人登月计划为背景开展了可靠性安全性需求分析、顶层系统设计，并通过 FHA，FTA 对可靠性安全性需求进行了验证。基于分析结果和相关需求，进行了逃逸与应急救生策略的设计，完善了顶层任务架构.本文通过实例给出了在航天任务层面从可靠性安全性需求分析到仿真验证，再到系统改进的完整过程，为开展基于模型的载人登月系统设计与可靠性安全性一体化分析提供了一种方法。

文章来源：华数星河