基于AltaRica的航电系统动态重构建模方法与流程

本发明属于航空系统任务可靠性建模
技术领域：
，具体涉及一种基于altarica的航电系统动态重构建模方法。
背景技术：
：随着新一代航空装备向综合化、模块化、智能化方向发展，以动态可重构技术、容错技术、测试性技术、内容管理系统(cms)技术为代表的大量新技术在装备中得到普及和应用。动态可重构是航电系统的重要特性，重构系统最突出的优点在于当故障发生时，系统的功能动态重构的方式是预先设定好的，当一个配置集合中的模块发生故障时，系统将按照设计蓝图(blueprint)寻找下一可用的配置集合并完成配置。由于动态可重构系统自身具有系统功能复杂、系统功能失效时序相关、各子系统相互依赖、重资源调度等典型特征，因此给系统任务可靠性建模工作带来了新的挑战。如何有效构建系统任务可靠性模型、准确表征容错设计的复杂交互过程和状态交联关系，成为开展动态可重构航电系统任务可靠性分析评估的关键难题。在可靠性动态建模技术方面，国内外学者作了大量的研究，并对一系列可靠性建模方法进行了探索，如markov、动态故障树、petri网方法、有限状态机等，但是这些方法在工程中开展全面推广与技术应用还存在一定不足。马尔科夫模型广泛用作复杂的故障容错系统进行可靠性分析的技术，但是随着系统复杂度的不断提高，其状态集合的数量将呈指数级增长，进而导致模型状态空间产生爆炸致使模型无法求解。动态故障树模型把传统的故障树分析扩大到动态系统性能，具有顺序相关、资源共享、可修复以及冷、热备份等特性，但是由于其最终解析过程是转化为相应的markov模型而做进一步求解，故同样面临着空间爆炸导致模型无法求解的问题。petri网与有限状态机模型都用于描述存在条件与事件间的关系，是一种重要的动态系统建模工具，但随着系统复杂度提高，依靠人工梳理系统各层级的动态交互及影响关系变得十分困难，且模型构建结果无法有效表征系统架构特性，不利于模型的检查与复用，从而导致其工程的可用性不高。altarica是法国工业界和学术界联合开发，以卫士转换系统(guardedtransitionsystem,gts)语义为基础进行系统正常和故障行为建模与分析的语言。该建模方法是以参量化的状态定义为核心，通过事件的触发描述系统或组件的工作模式或故障状态变化，并进一步采用函数调用的方式实现对系统架构层级、组件交互逻辑(正常/故障状态的传递及影响)的定义，可满足复杂系统关于可靠性分析过程中关于系统架构、故障逻辑信息建模工作。altarica模型的主构元素包括模块、输入/输出端口、状态、事件和转换。(1)模块，用于表示系统的功能模块或软硬件单元，通过对模块相关元素(包括端口、状态、事件等)的补充定义，可实现系统内部的故障传播逻辑定义；(2)输入/输出端口，用于定义模块中被传递的输入或输出数据，这些数据可来自于系统架构、icd文件、fmea/fmes等相关数据内容；(3)状态，用于表述组件模块在系统运行过程中可能所处的所有状态集合，其定义主要分为如下两类：功能状态——系统正常情况下的工作模式或工作状态；失效状态——来自系统各研制阶段下的故障模式数据，如组件的功能故障模式；(4)事件，事件是模块状态发生跳变的触发条件，是构建系统动态行为的核心元素，事件的定义内容可包括：系统正常行为下各组件自身工作状态发生跳变的触发条件；其他模块的输入激励信息；组件故障模式；(5)转换，用于定义模块输出与其输入、自身状态之间的转移关系，包括：系统正常状态之间、正常状态与故障状态之间的跳变关系；考虑输出端的故障类型及其与输入故障、自身故障状态之间的逻辑定义。技术实现要素：本发明的目的是为了提出一种对航电系统动态重构过程进行功能与故障逻辑建模的方法，以便进行航空系统的可靠性研究。本发明提供的基于altarica的航电系统动态重构建模方法，包括如下实现步骤：步骤一：整理与分析系统动态重构设计特性；以系统架构以及容错设计实现过程的相关资料为输入，相关资料可以是文档或模型等，梳理当前系统中采用动态容错设计手段的故障容错过程，明确其容错设计工作原理，包括故障检测与控制对象、故障切换触发条件、组件工作模式等。典型的航电系统动态重构机制主要包括考虑切换单元的冷备份、温备份或热备份架构和ima架构。步骤二：构建系统功能模型；以altarica语言的图形化建模手段为基础构建系统功能模型，构建系统功能模型包括系统架构、组件交互关系以及组件正常工作模式及状态，描述系统在正常工作模式下的功能交互关系，与系统正向设计方案保持一致。步骤三：构建系统故障逻辑模型；在功能模型基础上，通过故障状态以及触发事件的扩展定义，以完整描述系统在故障发生与容错设计条件下各组件工作状态的跳变与影响关系，实现系统动态容错设计的建模过程。步骤四：构建系统任务可靠性模型；在系统故障逻辑建模的基础上，依据任务剖面及系统任务失效判据，得出可表示“顶层任务失败-阶段任务失败-系统功能失效状态-单元功能失效状态”逻辑关系的系统任务可靠性模型。优选的，系统功能模型的具体建模过程如下：(1)以系统功能框图为输入，构建系统顶层功能模型，描述系统功能定义；(2)以系统架构为输入，构建系统架构组成模型，并定义各单元输入/输出端口信息；(3)以单元实际工作模式为输入，定义单元工作状态信息；(4)以系统架构为输入，构建正常状态下各单元之间、单元与系统之间的交互关系。优选的，系统故障逻辑模型具体建模过程如下：(1)根据fha或fmea分析结果确定系统各顶层功能失效状态，以端口类型扩展定义方式定义系统功能失效状态；(2)根据单元级fmea分析结果确定系统各单元功能失效状态，以扩展定义方式定义系统底层单元自身功能失效状态和端口失效状态；(3)根据单元各状态跳转关系，以触发事件扩展定义方式描述在故障发生与容错设计条件下各单元工作状态的跳变；(4)根据fta分析结果确定各单元输出端口与输入端口、自身状态局部故障逻辑关系，以触发事件扩展定义方式描述其逻辑关系。优选的，系统任务可靠性模型具体建模过程如下：(1)根据系统任务剖面划分，定义系统任务起止状态；(2)根据任务起止状态定义，构建各状态跳转关系；(3)定义系统任务失效判据。与现有技术相比，本发明具有以下有益效果：(1)有效解决传统方法中关于状态爆炸和模型无法求解问题；(2)以面向对象的建模思想为主线，在明确各模块的输入、自身工作和输出状态的条件下，仅需以当前目标模块为对象，构建其自身状态跳变的触发机制(输入状态或部分全局状态影响)以及自身状态、输入状态对其输出状态的影响关系，最终通过各组件之间、组件与系统之间的连接关系实现整体系统的故障逻辑建模。该方法无须设计人员采用人工推演的方法分析系统状态与组件状态之间映射及影响关系，极大程度地降低了建模难度，提高模型准确性。(3)模型构建完成后可较好地反映系统架构设计和重构策略设计，便于与系统设计人员进行模型确认，增强模型的可读性，可更好地支持模型修改与后期维护。附图说明图1系统功能建模流程；图2系统顶层功能定义；图3系统架构组成定义；图4各单元之间、单元与系统之间交互关系定义；图5系统故障逻辑模型建模流程；图6a状态块在状态机图中表示方式；图6b触发事件在状态机图中表示方式；图7静态单元的动态故障逻辑关系定义；图8a故障逻辑关系构建过程一；图8b故障逻辑关系构建过程二；图8c故障逻辑关系构建过程三；图8d故障逻辑关系构建过程四；图9动态重构单元的动态故障逻辑关系定义；图10任务阶段有限状态机定义；以及图11基于altarica的航电系统动态重构建模方法步骤示意图。具体实施方式下面结合附图和实施例对本发明作进一步的详细说明。本发明提出一种对航电系统动态重构过程进行功能和故障逻辑建模的方法。首先，以系统架构以及容错设计实现过程的相关资料(基于文档或基于模型)为输入，梳理当前系统中采用动态容错设计手段的故障容错过程，明确其容错设计工作原理，包括故障检测与控制对象、故障切换触发条件、组件工作模式等；然后，基于altarica模型元素构建系统功能模型，描述系统在正常工作模式下的功能交互关系；然后以有限状态机理论为基础，对功能模型进行故障状态以及触发事件的扩展定义；最后，基于系统任务失效判据构建系统任务可靠性模型，用于支持系统任务可靠性评估工作。本发明的创新之处在于以基于altarica语言实现系统正常和故障行为建模方法为理论基础，通过其语言自身关于状态转移、状态影响、状态传递特性的强大分析能力，给出了一套可专用于解决复杂动态容错特性的多阶段任务系统可靠性建模方法。步骤一：整理与分析系统动态重构设计特性；系统动态重构设计特性分析,整理建模所需元素。以系统架构以及容错设计实现过程的相关资料为输入，相关资料可以是文档或模型等，梳理当前系统中采用动态容错设计手段的故障容错过程，明确其容错设计工作原理，包括故障检测与控制对象、故障切换触发条件、组件工作模式等。航电系统动态重构机制包括切换单元的冷备份、温备份或热备份架构和ima架构；通过系统动态重构特性分析确定动态重构过程，分解动态重构过程为一个个子状态，确立每个状态配置情况和状态之间转换需要的触发和转换动作。可按照如下表1中的表格对动态重构进行总结。表1动态重构过程总结示例表事件名称事件分布类型事件分布参数事件触发条件原始状态目标状态事件分布类型用于定义状态转移的分布类型，事件分布类型说明如下：(1)exponential(λ)：事件发生概率服从指数分布；(2)weibull(α,β,γ)：事件发生概率服从威布尔分布；(3)lognormal(μ,σ)：事件发生概率服从对数分布；(4)constant(c)：常数分布，当事件满足触发条件时，将c作为因子乘以起始状态的可达概率得到当前事件的发生概率；(5)dirac(d)：延迟分布，以事件满足触发条件为0时刻开始计时，在t＝d时刻完成事件触发。步骤二：构建系统功能模型；以altarica语言的图形化建模手段为基础构建系统功能模型，构建系统功能模型包括系统架构、组件交互关系以及组件正常工作模式及状态，描述系统在正常工作模式下的功能交互关系，与系统正向设计方案保持一致。功能模型是以系统功能为出发点，描述系统各组成单元之间的功能关系、数据关系和接口关系的图形化表达方式。功能模型组成元素包括模块、输入/输出端口和工作状态，其中：系统中有输入输出行为的单元称为模块；描述系统最底层组成单元的模块称为单元模块；端口用来定义单元之间交互信息的输入或输出；端口的交互信息用于详细说明当前端口的实际输出对象，主要包括能量、数据、信号等；如果功能模块a有一个输出作为功能模块b的一个输入，称功能模块a到功能模块b之间存在结构连接关系，则将模块a的输出端口连至模块b的输入端口。altarica语言图形化模型元素与功能模型匹配关系如表2所示。表2altarica语言图形化模型元素与功能模型匹配表序号altarica模型元素功能模型元素1模块(class)系统顶层功能模块2子模块(class)系统单元模块3输入端口(inflow)输入端口4输出端口(outflow)输出端口5状态(state)工作状态系统功能建模流程参考图1，具体建模方法如下：(1)系统顶层功能建模，以系统功能框图或文档为输入，构建系统顶层功能模型，描述系统功能定义，其中端口的交互信息用于定义当前功能的具体描述，而端口名称可参照系统设计要求中相关的功能编号。举例：xx系统具有四个功能分别为功能1、功能2、功能3、功能4，构建结果参考图2，包括1个系统和4个功能；(2)单元组成与端口建模，以系统架构为输入，构建系统架构组成模型，并定义其输入/输出端口信息，其中端口用于定义实际输出对象。举例：xx系统由a、b、c、d和e五个单元组成，定义各单元输出端口，如表3定义了设备端口和交互关系。因此在图2的基础上对系统进行细化，图2中的系统变为a、b、c、d和e共5个单元，每个单元上根据表3包括有相应的输出端口，构建结果参考图3；表3设备端口和交互关系定义(3)系统与单元状态建模，以单元实际工作模式为输入，构建单元工作状态信息，通常可按“空闲/工作/无法工作”进行构建；(4)系统与单元交互关系建模，以系统架构为输入，构建正常状态下各单元之间、单元与系统之间的交互关系，具体通过端口连接关系表示。举例：根据如表3设备交互关系定义构建单元之间交互关系，即在图3的基础上将单元和功能之间通过端口进行连接，构建结果参考图4。步骤三：构建系统故障逻辑模型；故障逻辑模型是在功能模型基础上，描述系统各组成单元之间、单元与系统之间的故障传递关系的图形化表达方式。故障逻辑模型组成元素包括状态、转移和事件。状态用于定义系统各研制阶段的故障模式数据，如组件的功能故障模式；转移用于定义正常状态与故障状态之间的跳变关系，如系统解算功能处于正常状态下，当事件发生时，系统解算功能状态变为丧失。还可以实现考虑输出端的故障类型及其与输入故障、自身故障状态之间的逻辑定义，如当系统故障状态为y，且/或输入端口故障为a时，系统输出b。事件用于定义系统在工作过程中导致状态发生变化的触发机制和条件。其主构因素包括迁移的起始状态、单元的输入端口、同一动态区域内其他单元的状态、任务剖面的状态等，具体含义如下：①起始状态表示当前迁移的起始状态；②目标状态表示当前迁移的终止状态；③输入端口表示对于有直接物质流交互的(如冷备份机制中主工作单元的故障信号)，可直接按照单元的输入端口作为判定因素；④全局状态表示对于没有物质流交互的(如任务阶段对工作机制的影响)，可通过全局状态变量作为判定条件；⑤操作符表示操作类型，常用的逻辑操作符包括and、or、if、then、else等，可根据具体的逻辑判定弹性编写。altarica语言图形化模型元素与故障逻辑模型匹配关系如表4所示。表4altarica语言图形化模型元素与故障逻辑模型元素匹配表序号altarica模型元素故障逻辑模型元素1状态(state)失效状态2事件(event)事件3转移(trans)转移系统故障逻辑建模流程参考图5，具体建模方法如下：(1)系统功能失效状态建模，根据功能风险分析(fha)或故障模式及其影响分析(fmea)的结果中确定系统各顶层功能失效状态，以端口类型扩展定义方式定义系统功能失效状态；系统端口名称：状态定义(2)单元功能失效状态建模，根据单元级fmea分析结果确定系统各单元功能失效状态，以扩展定义方式定义系统底层单元自身功能失效状态和端口失效状态；单元端口名称：状态定义单元功能名称：状态定义(3)动态故障逻辑建模，根据单元各状态跳转关系，以触发事件扩展定义方式描述在故障发生与容错设计条件下各单元工作状态的跳变。一种方式是通过状态机图构建不同事件触发的状态转移关系，另一种方式是形式化语言编辑事件触发条件和触发后影响。条件：(工作状态＝正常)and(模块a故障)影响：工作状态＝降级工作(4)局部故障逻辑建模，根据fta分析结果确定各单元输出端口与输入端口、自身状态局部故障逻辑关系，然后以触发事件扩展定义方式描述其逻辑关系。以事件“单元b输出端口解算错误”为例，假设单元a输出端口非指令执行故障模式和单元b指令解算功能错误同时发生导致单元b输出端口解算错误，则其触发条件的形式化定义结果为：(单元b输出端口＝正常)and((单元a输出端口＝非指令执行)and(单元b指令解算功能＝错误))。其中，状态机图构建步骤如下：1)根据单元模块功能失效状态定义，生成表示单元正常和故障状态的状态块。状态块在状态机图中表示方式为圆形，圆形内包括单元名称和单元状态，具体表示方式可以参考图6a；2)根据各状态跳转关系，定义触发事件。触发事件在状态机图中表示方式为圆角长方形，圆角长方形内包括引起状态跳转的触发事件名称，如某单元故障，具体表示方式可以参考图6b；3)梳理各状态之间跳转关系。a)不存在动态重构机制的单元，则表示为由正常状态通过触发事件转换成不同故障状态，在状态机图中可以表示为从单元正常的状态块出发的箭头指向故障模式，然后从故障模式出发的箭头再指向故障状态的状态块，表示方法可以参考图7；b)具有动态重构机制的单元，考虑不同初始状态通过触发事件转换成不同状态，通过迁移区分不同初始状态。举例：整个设备a由模块a和模块b组成，其中模块a功能先故障，则设备处于降级_b工作状态，然后模块b也故障，则整个设备a失效；如果模块b功能先故障，则设备处于降级_a工作状态，然后模块a也故障，则整个设备a失效；如表5所示状态跳转关系；表5状态跳转关系4)通过连线实现各状态与触发事件连接关系。基于表5总结的各状态跳转关系可知，设备如果从“工作状态：正常”状态出发，经过“模块a故障1”迁移后，状态变为“降级_b工作”；设备从“降级_b工作”状态出发，经过“模块b故障2”迁移后，状态变为“工作状态：失效”。“正常→降级_b工作→失效”故障逻辑关系构建过程如图8a-8d所示，其中从状态块到触发事件的实线箭头表示初始状态和迁移，从触发事件到状态块的虚线箭头表示迁移和转移结果，根据表5状态跳转关系，动态故障逻辑建模结果如图9所示。步骤四：基于任务失效判据构建系统任务可靠性模型；altarica语言图形化模型元素与任务可靠性模型匹配关系如表6所示。表6altarica语言图形化模型元素与任务可靠性模型元素匹配表序号altarica模型元素任务可靠性模型元素1状态(state)任务起止、成功、失败状态2事件(event)阶段成功事件、阶段失败事件3转移(trans)任务状态转移任务可靠性建模过程如下：(1)任务状态构建针对任务阶段划分，分别构建各阶段的开始状态、总体任务成功与任务失败状态，并确定状态类型。假设某系统的任务剖面共分为p1-p4共计四个阶段，则系统的任务起止状态定义结果如表7。表7任务起止状态定义序号状态名称状态类型1p1开始nominal2p2开始nominal3p3开始nominal4p4开始nominal5任务成功nominal6任务失败failed(2)任务状态转移关系构建针对已定义的任务起止状态，构建各状态之间的触发事件以实现任务状态随事件的跳变转移。以表7为例，则其任务状态转移构建结果如图10所示。(3)任务失效判据关系构建在任务状态转移模型的基础上，通过对事件类型、事件触发条件的定义，用于构建任务失效判据，即在当前任务阶段时间内，若其失效判据满足则判定任务失败，系统无法进入下一任务阶段，反之则在当前任务阶段时间结束后自动接入下一状态，以此类推。其中，各事件的类型及分布定义如下：1)“阶段成功”事件定义：分布类型均为dirac(d)，无触发条件，其中参数d为当前阶段的持续时间；2)“阶段失败”事件定义：其事件类型均定义为dirac(1e-07)，即在一个极小的仿真时间内可完成状态跳变。其中，各事件触发条件定义如下：1)阶段成功事件的触发条件仅为其自身阶段状态，以事件“p1完成”为例，其触发条件的形式化定义结果为：任务状态＝p1开始；2)阶段失败事件的触发条件则为当前阶段的任务失效判据，以事件“p1失败”为例，假设其功能失效判据为功能f1与功能f2的任一丧失，则其触发条件的形式化定义结果为：(任务状态＝p1开始)and((功能f1＝丧失)or(功能f2＝丧失))。系统任务可靠性模型建模完成后，用于后续可靠性活动，至少包括：在产品的方案涉及阶段，可进行可靠性的分配和预计；在产品的制造阶段，用于故障的分析(可靠性分析)；在产品制造出来之后，对产品的固有可靠性进行评估等。最后应说明的是：以上所述的各实施例仅用于说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或全部技术特征进行等同替换；而这些修改或替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。当前第1页12