基于MBSE的通用质量特性建模分析技术研究

李娇，敖亮，任文明

（中国航空综合技术研究所装备服务产品部，北京101400）

0 引 言

随着航空装备复杂程度日益增加、任务多样化、容错机制复杂化等，可靠性、安全性、测试性（以下简称“三性”）等通用质量特性对整机的约束程度越来越大，对“三性”要求也越来越高。但研制周期越来越短，航空装备设计分析与评估验证的难度也越来越大，传统的系统工程方法已无法满足现代高度复杂的航空装备的设计需求。实际上仅仅依靠经验、文档以及部分模型等形式的设计已经造成了设计需求迭代频次增加、分析工作重复、验证不充分、隐蔽性问题等诸多问题。

故障模式影响分析（Failure Mode Effect Anal‐ysis，简称FMEA）［1］是通用质量特性设计分析的主要方法，也是“三性”工作的共用方法，需从FMEA着手解决问题［2］，然而在FMEA实际工程应用中存在很多管理和技术上的问题。

（1）“三性”工作孤立且重复

FMEA是开展“三性”工作的基础，可作为可靠性建模、测试性建模、功能危险性分析（Function Hazard Assessment，简称FHA）等工作的输入，然而目前“三性”工作是独立开展的，工程中存在大量重复工作。

（2）总体与成品单位工作缺乏协同

装备主机与各层级承研单位“三性”工作过程与分析数据缺乏有效协同，甚至各单位表格的表头都不一样、报告繁冗低效、FMEA各约定层次产品的故障传递关系不对应等。

（3）“三性”与设计工作“两张皮”

由于可靠性人员对产品功能结构不够了解，导致分析结果与实际不符，故障改进措施未落实或简化设计改进措施（如加强筛选等），故障设计改进措施只限于纸上，并未真正在产品中落实。

（4）不能实现动态分析

由于作战方式的转变，装备完成任务的能力逐渐受到关注，当底层器件发生故障时，装备可通过一系列的检测、备份、重构等机制实现容错，保证任务的正常执行［3］。传统FMEA不方便对产品功能重构过程进行分析，不能有效支持产品任务可靠性分析。

（5）无法实现多因素分析

GJB/Z 1391—2016中指出“FMEA是分析产品所有可能的故障模式及其可能产生的影响，并按每个故障模式产生影响的严重程度及其发生概率予以分类的一种归纳分析方法，是属于单因素的分析方法”［4］。然而随着产品复杂程度的增加、自主保障模式的推进，很多情况下，多种原因共同作用导致某种故障模式，以及对于影响任务完成的故障模式采取了冗余、容错等保障措施。

（6）没有从系统工程角度出发

对于层级较低的成品，无法从装备安全、任务的功能故障角度开展硬件故障模式的影响分析，导致严酷度等级分析无依据，关键故障模式识别的准确性无法校核。因为没有从系统工程角度出发，无法突出成品影响整机完成任务的重要性，造成大量无效果的工作。

胡晓义等［5］对基于系统结构模型和系统行为模型的两种安全性、可靠性分析方法进行了优缺点分析，但没有将同样依靠故障逻辑模型进行分析评估的测试性纳入进来；陈松［6］指出传统可靠性安全性分析工具FTA、Markov和Petri等很难对系统进行设计，而由达索、空客与波尔多大学在20世纪90年代末合作开发的AltaRica语言则可更好地表现系统的功能和物理架构，但是仅进行了安全性分析，没有考虑可靠性和测试性，依然无法全面解决“三性”重复工作的难题。

在此基础上，本文以功能需求为牵引，在早期需求分析与系统架构设计阶段，实现装备功能架构权衡设计与优化；以故障逻辑为核心，加强系统功能与通用质量特性设计之间的数字化模型集成，推动基于模型的同源数据传递、分析评估、设计反馈等工作模式，实现航空装备基于模型的系统工程（Model Based System Engineer，简称MB‐SE）研制模式下基于数字化平台的多专业协同设计与分析评估。

1 分析过程

1.1 基于MBSE的产品设计分析过程

MBSE是通过形式化的建模手段，从概念设计阶段开始就能够支持系统需求、设计、分析、验证和确认等活动，并持续贯穿整个开发过程和后续的生命周期阶段［7］。

国外，NASA实验室、空客、波音、罗罗、洛克希德·马丁公司等早已在数字化样机建模过程中应用MBSE技术，可用于产品全寿命周期需求捕获，表达与产品定义相关的信息，提供与产品行为全方位的交互机制，实现多学科多领域协同设计［8］，具体过程如图1所示。目前，国内航空、航天部分重点单位也已初步开展MBSE相关工作。

图1 基于MBSE的产品设计分析过程Fig.1 Product design analysis process based on MBSE

MBSE的设计、分析、验证目前多应用于产品设计领域，但针对通用质量特性相关研究内容较少，目前军民机的通用质量特性设计分析不能有效的结合产品的实际物理结构，在工程中存在严重的“两张皮”现象。

1.2 MBSE模式下通用质量特性需求分析过程

MBSE模式下通用质量特性需求分析过程的目标是分析用户需求，是整个研制流程的输入。本文引入Harmony SE方法［7］进行需求分析，需求分析阶段的目的是分析整个项目的输入，即飞机顶层需求，包括功能需求、性能需求、约束和接口需求［9］。基于Rhapsody等软件工具建立用例图、活动图、时序图等，通过建立活动图并关联利益攸关者进行黑盒设计，主要用于分析系统与外部功能的交联关系；然后权衡功能设计架构，基于泳道分配进行白盒设计，主要用于分析系统内部功能模块，具体过程如图2所示。

图2 基于Harmony SE开展功能需求分析Fig.2 Function requirement analysis based on Harmony SE

通过需求分析，用户需求被翻译为系统需求。需求分析的关键步骤是定义系统用例，详细描述角色（利益攸关者）的行为、角色与用例之间的信息流。

然后，开展功能分析，系统功能分析阶段的重点是把系统功能需求转换为系统功能描述。功能分析是基于用例进行的，该阶段建模利用3个Sys‐ML图来展现用例行为：活动图、序列图、状态图，把每个需求分析阶段确认的用例翻译成可执行模型。

最后，进行设计综合，包括架构分析和机构设计两个方面，通过设计综合，采用“自顶向下”的工作思路，利用SysML的模块定义图和内部模块图来描述，把功能架构“映射”成物理架构，最终完成方案设计，具体过程如图3所示。

图3 需求分析开展过程Fig.3 Requirements analysis development process

2 功能故障逻辑建模方法

2.1 建模技术方法

本文建立“功能需求—功能架构—硬件设计”和“功能架构—故障逻辑—故障分析”两层关系，第一部分是产品正向研制过程，第二部分是故障逻辑分析过程，两者通过功能架构紧密结合，使得通用质量特性与产品的物理结构紧密结合，可有效解决“两张皮”问题，形成基于功能故障逻辑模型的协同设计。

（1）功能与故障结合建模思路的由来

为解决“三性”与设计工作“两张皮”这一问题，采用功能与故障结合建模思路，功能是实现各研制阶段产品设计逐步细化和定义上下层级间接口关系的中间桥梁，功能需求分析是假设工作状态正常基础上开展的，然而实际工程中，总会存在功能故障的情况，因此将功能与故障逻辑结合起来，将可靠性、安全性和测试性重复开展的故障逻辑关系分析统一建模，实现模型复用。

此外，装备级、系统级和模块级各层次产品FMEA一体化，具体过程如图4所示，即模型语言，方便总体与成品单位协同。从系统角度出发，方案设计、初步设计和详细设计阶段各设计阶段数据一体化分析。

图4 基于功能故障逻辑一体化过程Fig.4 Logical integration based on functional failure

（2）功能故障逻辑建模原理分析

将功能封装起来看作一个黑盒，黑盒间通过输入输出端口连接，各个黑盒连接起来构成整个系统。黑盒内部是实现该物理功能的硬件结构，通过对输入输出端口进行故障定义，功能交互路径可构建故障逻辑的传递关系，具体过程如图5所示。

图5 故障逻辑模型形成过程Fig.5 Failure logic model formation process

（3）建模语言的选择分析

选好建模语言是实现建模的必要工具，目前存在两种主流建模语言：

SysML是一种通用的针对系统工程应用的图形化建模语言［10］，适用于系统早期的功能架构与物理架构设计，但不能支持可靠性分析、性能仿真。

AltaRica语言是事件驱动，安全性和可靠性研究的主要目标是检测出导致系统从正常状态转变到故障状态的事件，并对事件进行量化。AltaRica定义了控制转换系统（Guarded Transitions Sys‐tems，简称GTS）［11］：系统状态用变量描述，只有相应的事件发生时，系统状态才会发生转变，但是不对事件和状态的物理含义进行假设。GTS可封装到分层“黑盒”里，“黑盒”设置输入输出端口，“黑盒”间通过“线”进行连接，这些“线”代表封装变量之间的约束条件，通过故障判据，激发状态变迁，可靠性、安全性就是和故障做斗争的学科。AltaR‐ica语言非常适合用来描述复杂系统的安全性、可靠性并进行计算分析。

基于以上功能故障逻辑建模原理，AltaRica模型的主要构成元素包括模块、输入/输出端口、状态、事件和转换［12］，以参量化的状态定义为核心，通过事件的触发描述系统或组件的工作模式或故障状态变化，并进一步采用函数调用的方式实现对系统架构层级、组件交互逻辑（正常/故障状态的传递及影响）的定义。AltaRica可以更好的表现系统的功能和物理架构，可满足复杂系统关于系统架构、故障逻辑信息建模工作［13］。

2.2 功能建模过程分析

功能建模用于构建在理想的环境条件下系统的正常工作过程，功能模型用来表征产品架构组成关系、输入/输出端口及各层级交互关系，建模对象可以覆盖整机、系统、分系统、设备、功能电路、元器件等。系统功能建模的过程如图6所示。

图6 功能建模过程Fig.6 Functional modeling process

系统功能建模的主要步骤为

（1）创建顶层功能

选用输出端口，按照系统设计要求，定义系统功能，端口的交互信息用于定义当前功能的具体描述。

（2）创建物理端口

根据系统设计要求和功能原理，不考虑系统内部组成，以系统为最小分析单元考虑其与外部交互的实际输出，以输出端口的形式进行定义，物理端口的交互信息用于详细说明当前端口的实际输出对象，主要包括能量、数据、信号等。

（3）功能与物理的关系映射

构建系统的实际物理输出与系统功能之间的逻辑关系，具体是指本层级的物理输出端口与上层级的功能端口，如图7所示。

图7 功能与物理的关系映射Fig.7 Mapping between function and physics

（4）创建系统内部架构

创建下一层级直至最底层的内部功能架构。①创建下一层单元实际物理输出。

针对各单元模块，采用输出端口创建各单元的实际输出，端口的交互信息用于详细说明当前端口的实际输出对象，如电压、控制信号等。

②系统内部的连接关系构建。

依据系统功能框图或功能原理图，按照系统实际的工作过程和功能流向，将各单元的输出端口连至相应单元作为后者的输入，不限制该项操作，可解决传统FMEA中的技术缺陷，实现多因素故障原因分析。

③系统内部与系统输出的关系构建。

确定完成系统输出的最底层单元和相应模块的输出端口，将各层单元物理端口与相对应的系统功能输出端口进行匹配，并分别连至相应端口，如图8所示。

图8 某层级所有单元与系统功能交互定义Fig.8 All units at a level interact with the system function definition

2.3 故障逻辑建模过程

系统故障逻辑关系的建模［14］过程是以功能建模的结果为基础，首先定义系统级与单元的功能失效，其次以功能建模中的单元交互为故障传递路径，构建单元对系统功能的故障影响关系［15］，其建模的主要对象包括系统的功能失效状态定义、单元的功能故障模式定义、单元输出对象的故障类型定义、系统功能失效的局部故障原因分析、单元故障输出的局部故障原因分析以及单元动态故障逻辑定义，如图9所示。

图9 故障逻辑建模过程Fig.9 Fault logic modeling process

具体建模方法及过程如下：

（1）顶层功能失效状态定义

在系统顶层功能的输出端口上，定义系统功能失效状态［16］，失效状态来自系统各研制阶段下的故障模式数据，如组件的功能故障模式。

（2）系统物理端口失效状态定义

针对其相对应的中间模块的输出端口失效状态定义，通常是按照当前输出的相关故障判据阈值进行划分和定义。对于不对应任何实际硬件单元的功能逻辑模块，则虚拟成一个硬件单元，并进行物理端口失效状态定义。

（3）功能与物理映射

故障逻辑建模过程包括系统内部故障逻辑和功能与物理映射，是一个先外部再内部的顺序。首先，将各层功能与物理端口进行匹配的过程机功能与物理映射［17］，如图10所示。

图10 故障逻辑建模过程Fig.10 Fault logic modeling process

（4）系统内部故障逻辑

系统内部故障逻辑包括局部故障和底层故障逻辑两种，将输出端口的功能失效状态作为顶事件，故障原因既包括自身原因也包括输入端相关因素。

①中间层故障逻辑。

顶事件是中间模块功能输出端口失效状态，底事件仅为中间模块的功能输入端口失效状态。

②底层故障逻辑。

顶事件是底层单元输出功能端口故障模式，底事件为当前模块的输入端口故障模式和自身状态。

3 案例应用

3.1 飞控系统功能架构需求分析

在某直升机飞控系统的架构权衡过程中，首先进行利益攸关者分析，然后对飞控系统的内部功能分析和外部功能交联关系进行分析，在功能需求分析和架构形成过程中，充分考虑横向姿态控制功能、纵向姿态控制功能、航向控制功能和总矩控制功能等关键功能需求，以及与液压系统、导航/大气系统、供电系统等交互关系，如图11所示。

图11 基于Rhapsody功能需求分析Fig.11 Requirement analysis based on Rhapsody

3.2 基于AltaRica语言的功能模型构建

直升机飞控系统主要实现对横向、纵向、航向和总矩的控制功能，飞控系统与其他系统功能交互模型如图12所示，将飞控系统功能“映射”到具体的物理架构，进行飞控系统内部功能关系构建，具体功能模型构建过程见2.2节，功能模型如图13所示。

图12 飞控系统与其他系统的交互关系功能模型Fig.12 Functional model of interaction between flight control system and other systems

图13 飞控系统功能与物理映射关系Fig.13 Function and physical mapping of Flight Control System

3.3 飞控系统故障逻辑建模过程

飞控计算机是飞行控制系统的核心部件，本文以飞控计算机为例说明故障逻辑的建模过程，并对其优越性进行分析。飞控计算机完成飞控系统控制律计算功能，并向伺服系统输出控制指令；同时它还要完成整个系统的管理功能，实现整个系统余度管理计算与逻辑判断、工作模式转换，以及系统状态申报、故障告警和飞控系统的BIT等功能。

基于上述功能模型，结合飞控计算机各种部件的失效模式及状态转移关系，对飞控计算机故障信息进行补充，并以所有输出端口的故障模式为故障树的顶事件进行故障逻辑建模。

飞控计算机的部分失效模式如图14所示，并以飞控计算机的核心部件——前主桨舵机、左主桨舵机为例，说明故障逻辑的建模过程以及优越性。

图14 飞控计算机故障模式Fig.14 Failure mode of flight control computer

在飞控系统中，是存在复杂的冗余机制的，前主桨舵机控制信号故障逻辑关系如图15所示，如若不考虑冗余，则不能反映真实故障情况，本文在各层级故障逻辑建模中考虑冗余备份，冗余机制下存在多个失效状态（如正常、降级和失效），是实现动态分析的基础，更符合真实故障传递过程，针对系统的动态可重构特性可开展基于有限状态机模型的任务可靠性建模分析，可解决传统FMEA不可进行动态分析的技术缺陷。

图15 前主桨舵机控制信号_左故障逻辑关系Fig.15 Logic relation of left fault of control signal of steering gear of front main propeller

此外，传统FMEA分析中，只考虑自身故障原因，本文基于AltaRica语言建模，飞控系统左主桨舵机输出丧失的故障逻辑除了来自自身的原因，如图16所示，还包括液压、电源、舵机控制信号以等故障原因，可解决传统FMEA中的单因素分析问题。

图16 飞控系统左主桨舵机输出丧失故障逻辑Fig.16 Flight control system left main propeller rudder output loss fault logic

3.4 优势性分析

基于MBSE的通用质量特性建模工作存在以下六方面优点：

（1）模型复用，以上故障逻辑模型，可靠性、安全性和测试性均可复用，避免了大量重复工作。

（2）模型语言，高效简洁，传统自底向上进行的FMEA工作过于形式化，分析表格繁冗，分析结果缺乏针对性，纠正措施未有效落实。

（3）功能故障结合，自上下向功能分析与自下向上故障逻辑传递紧密结合，解决设计与通用质量特性“两张皮”现象。

（4）动态分析，可分析存在冗余情况，如图14所示，可实现四选二的复杂冗余系统，传统FMEA不考虑冗余情况。

（5）故障原因分析全面，考虑除左主桨舵机自身因，还包括液压、电源、舵机控制信号以等故障原因。

（6）系统工程角度，以功能需求为驱动，与产品正向研制紧密结合。

4 结 论

本文实现了“功能需求—功能模型—故障逻辑”完整建模过程，基于功能故障逻辑开展“三性”一体化设计分析，避免重复工作。此外，与传统FMEA故障逻辑建模过程相比，采用AltaRica语言建模，实现了功能与故障逻辑结合，可有效解决“两张皮”问题。