注册领666大礼包，学习金和优惠券下单直接使用
本文以美国“阿尔忒弥斯”载人登月计划为背景，提出了面向顶层设计的可靠性安全性需求分析及系统设计方法，基于系统建模语言(systemmodelinglanguage,SysML)建立了可靠性安全性需求分析的模型，通过仿真进行了可靠性安全性需求的验证，并完成了系统设计的改进。
1.基于模型的需求分析与系统设计
MBSE的方法论有很多，最著名的是V型的Harmony系统工程方法[6]，从系统需求出发开始正向设计，再通过仿真进行反向验证。除此之外，IBM公司提出了统一软件开发过程(RPU)[7]，Vitech公司提出了自己的MBSE方法[8]，国际系统工程学会也提出了以目标为导向的系统工程方法[9]等。这些方法论将需求分析、功能行为设计和设计验证等有效组织起来，使全系统的设计可追溯、易管理。可以看出，需求分析是进行MBSE的首要步骤，同时需求分析和系统设计在MBSE的全流程之中也是紧密耦合的。为了使MBSE全流程建模方法更加实用化，达索公司配合MagicDraw软件给出了基于SysML的MagicGrid方法论[10,11]，将问题用域来描述，每个系统设计都包含了问题域、解决域、实施域三层，每层都由需求、行为、结构体和参数四个维度的定义来完成描述，形成了方案矩阵，需求分析在每一层中都是首要的。目前，在航空[12,13]、汽车[14]与航天[15,16]等领域，都是结合自身工程实际，在上述方法的基础上通过适当的裁剪或改进，完成系统设计。
从方法论和应用层面来看，系统需求分析有较为成熟的体系，尤其是系统正常功能的设计。即从利益攸关者的要求出发，逐层分解、推导，给出子系统或分系统的设计要求。
2.基于模型的可靠性、安全性分析
随着MBSE在工程领域的成功运用，基于模型的可靠性、安全性分析方法也越来越得到重视。作为系统工程的一部分，可靠性安全性分析也应该融入到MBSE的流程之中。
在现有的文献中，以基于SysML的设计模型为基础，开展了许多关于基于模型的可靠性安全性分析方法的研究，形成了包括文献[17,18]在内的方法论。目前的研究重点是如何运用系统正向设计的产物，定义故障模式和故障传递关系，从而自动开展可靠性安全性分析，生成失效模式及其影响后果分析表和故障树[1921]。这些分析方法均需要从顶层的可靠性安全性需求出发，如何梳理复杂系统的可靠性安全性需求，开展系统设计，则成了复杂系统顶层设计中的重要问题。
在传统的MBSE流程中，可靠性安全性需求属于通用需求的一部分。但不同于其他通用需求，可靠性安全性分析多是基于系统的异常行为，其与系统正向设计的区别不仅在于模型上，在开展方法上也有很大差异。为了便于实现可靠性安全性分析与系统设计一体化，需要将可靠性安全性需求提取出来，在进行需求推导的同时，也逐步开展可靠性安全性需求的捕获与定义。
针对可靠性等这类系统非功能性的属性，RUP方法对此进行了区分[7]，在系统设计的初始阶段就将系统需求分为了用于捕获系统功能性的需求和覆盖系统非功能属性的需求，如可靠性安全性需求，使可靠性安全性分析尽早融入到MBSE之中。此外，在最新的MagicGrid方法论之中[10]，也将可靠性安全性分析考虑其中，即在方案矩阵表中最后一列增加可靠性安全性分析，使每一层的设计都有对应的可靠性安全性分析的介入，验证初始需求，指导系统设计。
从目前基于模型的可靠性安全性分析方法的发展和实际工程需要来看，可靠性安全性分析需要与系统正向设计同步，即从需求分析起开展，但又必须有所区别，使可靠性安全性分析作为MBSE中的一个重要组成部分，在依赖MBSE设计过程的基础上也能够独立进行。
需求分析是开展基于模型的复杂系统设计的第一步，负责识别全任务周期中与任务或目标有关利益攸关方的需要和期望，以及设计过程中为完成既定任务需具备的能力，并将其转化为明确的、无歧义、可测量与可追溯的条目化需求模型。而针对可靠性安全性分析和设计，则需要提取利益攸关方对于任务风险的期望、设计过程中应对风险的能力等，并将其转化为符合要求的可靠性安全性需求模型。
基于模型的可靠性安全性需求分析需要与系统正常的需求分析流程相匹配。文献[22]指出载人登月顶层系统结构可分为任务、能力和系统三个层次。任务层面是对事件、资源、交互关系和操作规则等的描述；能力层面是对系统具备能力的描述；系统层面是对具体的系统组成、性能和关系等的描述。对应的需求分析也可从这三个层面出发，包括任务需求建模、能力需求建模和系统需求建模。
关于可靠性安全性方面的需求，则需要在任务、能力及系统需求建模的同时进行分别提取和推导，从顶层逐步得到可用于指导系统开展具体设计的可靠性安全性需求条目。对顶层任务，基于模型的系统可靠性安全性需求分析的流程如图1所示。
可靠性安全性需求分析在各层中的作用及输入输出产物如下:
1)顶层的可靠性安全性需求
2)中间层的可靠性安全性需求
3)底层的可靠性安全性需求
除此之外，为了检验系统的可靠性安全性需求是否正确及合理,还需要对其进行验证。通过先验知识或开展仿真验证后，最终再将形成的需求条目分发给对应的系统或分系统。否则还需要调整顶层架构设计，重新进行可靠性安全性需求分析及验证。
2017年，美国启动阿尔忒弥斯计划(ArtemisProgram)[23,24]，主要支持载人登月和未来的载人火星探测任务。计划在未来10年内在月球表面建立一个永久基地，开展人机联合探测,并以月球作为未来登陆火星的“跳板”，实现载人登火等深空探测的目标。本文以美国阿尔忒弥斯载人登月任务为例，进行该任务的可靠性安全性需求建模分析、顶层设计和需求验证。
1.顶层可靠性安全性需求分析
顶层可靠性安全性续需求分析建模的具体步骤如下:
1)提取利益攸关方对于任务风险的期望：基于识别的利益攸关方、任务目标、系统边界和外部参与者，根据已识别的利益攸关方对于任务风险的需要、期望和能够明确的约束条件，形成条目化任务需求，并完善所建立的用例图，增加可靠性安全性的需求，使用requirement元素承载，并建立利益攸关方与这些可靠性安全性需求的关联关系。
2)顶层可靠性安全性需求的复核：完成对任务背景或运行环境的建立后，在复核系统设计需求的同时，完成对顶层可靠性安全性需求的复核，如出现不明确的、缺失的任务需求或约束，应重新分析利益攸关方的关系，提取任务目标,重新建模,直至所建立的顶层可靠性安全性需求通过审核。
2.中层可靠性安全性需求分析
中层可靠性安全性需求分析、建模的具体步骤如下：
1)基于场景的中层可靠性安全性需求的推导：使用用例图、块定义图等完成初步任务场景、系统组成架构的构建。结合任务场景和顶层可靠性安全性需求，识别推导与任务场景相对应的风险、故障处置等有关的需求，并建立条目化的需求模型。
2)需求复核：依据任务景，对推导出的中层可靠性安全性需求进行复核，确保每个需求均有相应的任务阶段、关键功能或系统组成与之对应。如出现不明确的、缺失的中层需求，应重新细化任务场景，推导需求，直至其通过审核。
根据阿尔忒弥斯的技术方案，为了支持其任务的成功实施，整个登月系统由以下分系统组成[24]：太空发射系统(spacelaunchsystem,SLS)、猎户座飞船(OrionCapsule)、地面支持系统、Gateway空间站、载人着陆系统、其它商业及国际合作系统。阿尔忒弥斯计划的第一阶段将由三次飞行组成：阿尔忒弥斯I为无人环月飞行、阿尔忒弥斯II为载人环月飞行并在月球南极登陆、阿尔忒弥斯III可能在环月空间站进行在轨操作。每一次任务均需开展相应的分析工作，本文以阿尔忒弥斯II为例，根据文献[25]提出的飞行方案，整个任务将由以下场景支持：将月面上升器送入环月轨道、将返回器送入环月轨道、将登月器送入还月轨道并与上升器完成交会对接、将载人飞船送入环月轨道并与组合体完成交会对接、完成着月和月面活动(期间飞船与返回器交会对接)、月面上升与飞船交会对接并返回地球。
依据上述方案，使用用例图构建任务场景，如图4所示。针对每个子场景，则由任务可靠性指标衍生出每个子场景的成功率要求：若场景中还有宇航员参与，则还会由安全性指标衍生出每个场景宇航员安全率的要求。
同时，为完成这一系列的场景，还需要多个分系统的支持。因此，首先通过如图5所示的块定义图构建了阿尔忒弥斯II的系统组成架构，涵盖了支持任务开展的运载火箭、飞船等多个系统.针对系统组成架构，也会由任务可靠性指标衍生出对每个参与系统的可靠性要求。
3.底层可靠性安全性需求分析
底层可靠性安全性需求的建模、分析的具体步骤如下：
1)细化飞行阶段，并将关键功能活动分配至对应的系统：以初步任务运行场景为主线和输入，进一步细化飞行方案或飞行场景，分析每个飞行阶段需开展的关键活动或飞行操作，建立关键功能活动之间的逻辑顺序。将识别的关键功能活动分配到相应系统的泳道分区中，并进一步识别和建立系统间、系统内部间信号的传递关系。通过多次迭代，建立可用于支持系统任务逻辑流程仿真的功能模型。
3)底层可靠性安全性需求复核：依据关键功能和系统需求分配情况，对推导出的底层可靠性安全性需求进行复核，确保每项需求都至少有一个活动或块与之关联。
以Orion飞船地月转移加速为例，将该任务场景进行细化，得到如图6所示的活动图。提取出该任务场景的关键功能，开展故障分析，识别出对应的故障模式，如图7所示。
4.可靠性安全性需求验证案例
开展可靠性安全性分析的方法有很多，可以采用跨平台的分析方法，使用可用于可靠性安全性分析的一些领域建模语言，例如文献[26–28]。将系统模型进行映射后，基于此再开展对应的分析工作。为了便于分析结果及时反馈到系统模型，减少模型交互，本文基于SysML开展了相应的分析工作。
根据4.3节得到的Orion飞船地月转移加速过程中的典型故障模式，开展了功能危害分析(functionalhazardanalysis,FHA)，得到如图8所示的分析结果，包括只会导致无法登月和同时导致宇航员损伤两类。
为了验证此阶段的安全性指标，提取出危害宇航员安全的故障模式，如图9所示，基于此使用SysML参数图构建出以宇航员损伤为顶事件的故障树，如图10所示。
根据如图7所示的对于逃逸与应急救生策略的需求，针对各项典型故障模式，开展了处置策略的设计，完善了系统架构，如图11所示，得到了包含处置故障下的功能逻辑结构。