基于SysML的通信卫星故障分析方法研究

种婧宜，周昊澄，袁文强，陈余军

(1. 中国空间技术研究院通信与导航卫星总体部，北京 100094；2. 北京空间技术研制实验中心，北京.100094；3. 杭州电子科技大学，浙江 杭州 310018)

1 引言

随着我国航天技术的不断发展，通信卫星系统呈现出复杂化、多功能化和高度集成化等特点，其系统设计过程日趋复杂。由于通信卫星所处的环境极其恶劣，并且现阶段卫星在轨维修技术尚不成熟，因此对通信卫星的可靠性要求极高。目前，一般是通过保证软硬件的高可靠性以及设计足够的冗余度来提高卫星的可靠性[1]。为此，需要在研制过程中进行全面的可靠性分析，确保卫星在轨发生异常时能够及时响应，采取有效措施，最大程度保证整星安全和任务的顺利完成。经过多年的研究和实践，通信卫星的常规可靠性分析手段如故障模式与影响分析(FMEA)、故障树分析(FTA)等方法已经得到了广泛的应用。

现阶段的故障分析遵循传统系统工程以文档为中心的模式，在系统初步方案设计的基础上，通过信息的整合分析，以文档形式输出，缺少数字化模型。随着通信卫星系统复杂度的提升，传统故障分析模式暴露出诸多缺陷，例如故障信息的歧义性，文档维护困难、故障与其它模型元素相互独立难以保证数据同源、设计更改成本高、信息重用性差以及难以实现设计早期的仿真验证等[2]。

针对上述问题，本文创新性地提出一种面向通信卫星的基于SysML(Systems Modeling Language)的故障分析框架，并以姿态控制系统为例，重点阐述了其故障分析的模型化过程。

2 故障分析特点与现状

现代通信卫星系统属于典型的复杂系统，在现阶段以文档为中心的研制模式中，大量文档以自然语言叙述为主，含有表格等非自然语言作为辅助说明，没有系统模型的支撑。随着系统的日益复杂化，这种模式存在的问题主要体现在以下几方面。

1)信息解读二义性

通信卫星由多个子系统构成，研制过程包含方案设计、初样研制以及正样研制等多个阶段，涉及众多来自不同单位和部门的工作人员。在故障分析过程中各分系统进行分析后以文档形式由总体设计人员整合输出。以文档为中心的协同过程由于自然语言的非标准化与非形式化，极易因为不同人员对信息解读的不一致而导致错误。

2)信息维护困难

在卫星研制过程中，不同设计阶段、不同系统层级将产生众多与故障分析相关的文档，单纯以手动方式维护庞大数量的文档十分困难，增加了人力、时间成本，且难以保证不同文档之间信息的一致性。

3)故障分析与系统设计融合度差

在传统系统工程中，故障分析相对于系统设计存在一定的滞后性。在不断迭代中，一旦发生设计更改，难以实时传递给故障分析，设计更改成本较高。同时故障信息与其它模型元素如功能、组件互相独立，只能以人工形式进行检索和关联，无法实现故障的自动追溯。另外，现阶段故障分析与故障处置的有效性与正确性需要在方案设计完成后通过测试与试验进行验证，难以进行早期的系统级仿真验证。

4)信息重用性差

通信卫星产品具有平台化、系列化的特点，继承性强。以文档为中心的研制模式下，已有项目的信息散落于大量文本中，难以建立基于系统模型的模型库，后续项目研制过程无法高效地借鉴使用。

针对现阶段卫星故障分析过程所面临的问题，基于模型的系统工程(Model based systems engineering，MBSE)为通信卫星的故障分析提供了新的思路。MBSE是建模的形式化应用，以支持系统需求、设计、分析、验证和确认活动，从概念设计阶段开始，一直持续到开发和后期生命周期阶段[3]。将MBSE与通信卫星故障分析过程相结合，可以有效解决系统复杂度增长为故障分析带来的问题，提高卫星故障分析的有效性和可靠性设计水平。

目前，MBSE在航空、航天、武器装备等领域得到了广泛的研究与应用。美国NASA已将MBSE的研究扩展到可靠性分析领域，提出将可靠性分析纳入系统架构设计中，保证分析模型的一致性和可追溯性，优化系统设计过程[4]。

3 故障分析总体框架

基于SysML的通信卫星故障分析框架主要包括故障信息表征、故障影响与追溯分析、故障处置行为建模三个部分，整体流程如图1所示。该框架的基础是基于SysML的故障信息表征，以实现对故障信息以及系统模型的统一规范表达。SysML是用于系统建模的通用标准化描述语言，可以支持多领域系统的描述、设计、分析与验证。SysML是领域无关的，因此在本流程中首先基于卫星领域的语义特点对SysML进行扩展，定义面向卫星故障分析的领域元模型。然后基于所定义的元模型，可以对卫星的故障模式、系统功能、架构等信息进行可视化建模。接下来围绕所建立的SysML系统模型，使用特定的关联元素对故障模式、功能、架构等模型元素进行关联，实现故障影响的动态追溯。在故障处置方面，利用SysML用例模型精化处理特定故障的用例场景，为卫星系统设计过程提供有效的指导。最后利用SysML的活动建模详细展开故障处置行为过程，以活动图的形式直观表达故障处置过程并进行动态的仿真，在系统设计早期暴露不合理的逻辑，及时识别故障预案存在的问题。

图1 基于

4 姿态控制系统故障信息表征

4.1 故障信息表证元模型

元模型的定义是对故障信息进行统一表征的基础，元模型可以理解为“模型的模型”，是对模型元素的进一步抽象[5]。SysML本身就是一种通用元模型，对于小规模系统可直接使用，但是对于通信卫星这一大型特定系统，需要在SysML通用元模型的基础上进行剪裁与拓展，定义适用于卫星故障分析的新构造型(stereotype)，便于设计人员理解和应用。

针对实际建模所研究的问题，需要规范表达通信卫星的故障模式，因此定义新的元类型《故障模式》，它的基类为Class，用于对所有故障模式的建模。在功能层面，由于功能的本质可以理解为系统一种动态的行为过程，因此基于SysML中的Activity基类扩展定义了《功能》这一新类型，用于对通信卫星系统功能的建模。在模型元素关联方面，为了清晰表达故障模式影响的功能范围以及和组件失效之间的追溯关联，这里基于Dependency基类定义了《归因于》、《违背》和《关联》三种新类型。具体定义的通信卫星故障信息表征元模型如2所示。

图2 通信卫星故障分析元模型

4.2 故障模式、系统架构与功能建模

在定义表征元模型的基础上，可以进行卫星故障模式、系统功能、系统架构等内容的建模，进一步形成通信卫星的领域模型库。该过程在实际工程应用中需要以本领域的专业知识为基础，同时结合SysML的语义特点，初步构建一般需要花费较多的工作量。但是由于模型具有良好的重用性，后续研制过程可以高效复用，大大缩短研制周期。

在故障模式的建模中，利用《故障模式》元类型对通信卫星的故障模式进行表征，形成典型故障模式库。以姿态控制系统为例，根据文献[1，6，7]可以定义姿态控制系统常见的故障模式如图3所示，这里利用SysML中的块定义图表示故障模式及其层次关系，故障模式的父类和子类之间用composite表示其包含关系。为了更加清晰直观，姿态控制系统的故障模式从两个角度进行建模，分别对应系统功能角度和组件功能角度。

图3 基于元模型的姿态控制系统故障模式

实现卫星故障模式功能影响范围的分析与自动追溯，需利用元模型中的《功能》类型创建系统功能的SysML模型。根据文献[7]可以梳理出姿态控制系统的功能及其分解关系，建立如图4所示的功能模型，父功能和子功能之间通过composite关联表示其分解关系。这里通过块定义图表达的不同层级功能之间的关系，可以在功能影响追溯中表示故障影响在不同层级之间的传递。

图4 姿态控制系统功能

在故障分析中，故障一般和组件失效相关联，因此有必要对系统架构组成进行建模。在SysML中，可以直接用Blocks定义不同的组件。在姿态控制系统中，组件主要包括敏感器、控制器和执行机构三大类，每类包含多种组件，因此这里用composite表示其结构上的关联组成关系，如图5所示。

图5 姿态控制系统架构

5 故障影响与追溯分析

通过基于SysML的故障信息表征，已经初步建立了卫星的故障模式、系统功能以及架构组成的模型，为了进一步开展故障影响分析，需要利用SysML特定的关联元素建立上述模型之间的关联。

5.1 故障的功能影响范围分析

以姿态控制系统为例，对应于4.2节创建的故障模式和系统功能模型，这里仍从两个角度展开故障模式与功能的追溯影响分析。如图6所示，上部分表示系统角度故障对功能的影响，下部分表示组件角度故障对功能的影响。这里利用元模型定义的新类型《违背》来表达故障对功能的影响，同时通过composite关联来描述功能层级的追溯，表达功能影响从底层向更高层级的传递。

图6 故障与功能的追溯关系

在SysML建模中，还可以以追溯矩阵的形式表达故障与功能的追溯关系，如图7所示。矩阵纵向表示故障模式，横向表示系统功能，矩阵中的箭头表示故障将追溯到该功能，左边的数字统计了该故障所影响的功能数量。以姿态测量故障为例，该故障将违背卫星姿态测量与确定、姿态捕获、姿态机动、姿态稳定这四个功能。通过追溯矩阵，可以更加清晰地表达故障与功能之间的追溯与关联关系，准确快速地定位特定故障模式所影响的功能范围。

图7 故障对功能影响的追溯矩阵

5.2 故障与组件失效的关联分析

卫星姿态控制系统的功能由敏感器、控制器和执行机构等组件共同实现，每个潜在的故障都和一定的组件失效相关联。这里利用元模型中定义的新类型《关联》构建故障和组件失效的关系，如图8所示。同样，可以采用追溯矩阵的形式表达故障和组件失效的追溯关系，如图9所示。

图8 故障与组件失效的关联关系

图9 故障与组件失效追溯矩阵

通过故障与功能以及组件之间的追溯和关联分析，可以快速定位故障所影响的功能范围以及相关联的失效组件。相比于传统的文档形式描述，追溯矩阵的表达形式更加直观清晰，同时由于模型的唯一性，一旦发生设计更改，所有相关的追溯关系将会实时同步，实现自动的动态追溯与数据维护，相比传统的手动修改与维护方式可以节省成本，同时保证信息的正确性。

6 故障处置行为建模与仿真

6.1 故障处置一般流程

为了提高卫星在轨运行的可靠性，在系统设计过程中需要针对所有可能的故障模式设计完整的故障预案，详细展开故障处置的过程。

根据MBSE的方法论，首先应明确整个卫星故障分析与故障处理过程涉及的利益相关方并进行规范的建模表达。卫星故障处置的一般过程是先由飞控中心数据判读人员根据遥测数据发现故障，并上报飞控指挥人员以及总体研制单位，然后总体研制单位和相关分系统的设计人员进行故障分析并选择处置预案，最后通过飞控中心发送上行指令至卫星进行故障处置与系统重构。根据SysML建模规范，以用例图的形式对故障处置过程的利益相关方进行定义与表达，如图10所示。利益相关方模型将和故障处置行为模型相关联，利用SysML中带泳道的活动图可以直观描述故障处置过程中不同利益相关方之间的动作、信号流动以及交互过程，如图11所示。

图10 故障处置利益相关方模型

图11 故障处置一般流程

6.2 精化用例场景

处理特定的故障模式，可以认为是系统的一种特殊需求，因此可以利用SysML的用例模型精化用例场景。以姿态超差这一故障模式为例，可以精化出处理姿态超差故障的用例，针对此用例场景，在对卫星系统功能行为进行设计时，需要为其分配相应的行为，如图12所示。这里还通过元模型定义中的《归因于》这一关联元素构建了故障模式之间的追溯关系。姿态超差这一故障模式可以追溯到执行机构故障、敏感器故障以及控制器故障三个故障模式，同时其违背了姿态捕获、姿态机动以及姿态稳定这三个系统功能，进一步将间接影响到卫星的姿态控制功能，最终可能影响整个飞行任务的顺利完成。因此，通过特定关联元素可以完整、清楚地表达故障分析的整个过程。

图12 针对特定故障模式精化用例场景

6.3 故障处置行为建模与仿真

接下来，可以对故障处置过程展开详细的行为建模，如图13(1)活动图所示为姿态超差故障的处置预案，包括星上自主处理和地面发送上行指令进行系统状态重构两个过程，同时需要根据遥测数据实时记录卫星状态。其中星上自主处理阶段的行为过程可以进一步展开，图13(2)和(3)的活动图分别为星上自主处置过程的一级和二级展开模型，一级展开行为模型可以直观清晰的表示出从OBC判断姿态超差故障到卫星对地搜索成功的一系列行为，而二级展开行为模型可以进一步表达出重要部件切换过程及状态变化。整个故障处置过程可以通过上述行为模型进行初步的仿真验证，图13为其运行的某个瞬间。在运行的过程中，通过活动图模型元素边框的颜色变化可以直观显示出信号的流动以及动作的交互状态，动态展示故障处置的整个运行过程，验证逻辑动作的合理性与正确性，在系统设计早期及时识别故障处置方案的潜在问题，保证故障预案的正确性与有效性，为卫星的系统设计提供重要指导。

图13 姿态超差故障处置行为建模

7 结论

本文将MBSE与通信卫星故障分析过程相结合，系统性阐述了基于模型的通信卫星故障分析方法。提出了基于SysML的卫星故障分析整体框架，将传统基于文档的故障分析过程通过模型的形式进行表达与分析，实现了基于SysML的故障建模与仿真验证，验证了本方法对于通信卫星姿态控制故障表征、逻辑描述和影响分析的有效性和直观性。