机载系统通用故障诊断软件平台设计

曹 琪, 柯 旭, 宋博文, 莫文静

(航空工业成都飞机工业(集团)有限责任公司,四川 成都 610073)

机载设备是飞机上必不可少的功能保障系统、也是典型的复杂系统。各机载设备是否可以稳定、有效地工作,直接决定了飞机能否可靠地正常运行、完成任务并安全返航[1]。但随着技术的发展与需求的提高,其智能化、综合化的程度仍在不断提高,其功能与结构也更加复杂与多样,导致单元之间的关联关系错综复杂,进而使得机载设备在出现故障时,故障不再以孤立形式存在,而更多的是呈现出关联故障模式[2]。因此,当故障发生后,如缺乏及时的故障检测及隔离机制,将会造成系统失效,甚至导致难以承受的灾难性后果。

机载设备故障诊断平台提供的主要服务是接收测试数据,然后基于对象本体及专家提供的原始知识,或从数据提炼归纳出的知识进行故障的推理判断,得到可有效指导后续故障处理工作开展的诊断结果。

针对机载系统故障诊断,目前主流的故障诊断方法研究分为以下3类[3]。

① 基于多信号流图模型的故障诊断方法。如文献[4]和文献[5]中基于故障树模型的方法,分别针对自动飞行系统和发动机开展了故障诊断系统的研究,研究结果表明基于模型的故障诊断方法虽然可在一定程度上实现对新故障的预测,但预测结果易受模型本身影响,一旦模型构建不全面或错误,将直接导致诊断结果无效。

② 基于专家知识系统的故障诊断方法。该方法虽然可有效解决机载设备中的实际故障问题,如文献[6]针对飞机航空电子设备建立了故障诊断的专家知识系统,并通过规则推理及 Hash 算法实现了故障的快速检索及定位,但其故障诊断的准确率和效率易受知识库知识的准确性和知识库规模的影响,尤其针对复杂系统的故障诊断,知识库将随系统规模的增加急剧扩大并呈现复杂化状态,进而导致诊断效率急剧下滑。

③ 基于数据驱动的故障诊断方法。与上述2种定性分析方法不同的是该方法可实现对故障的定量分析,可结合主流的机器学习或深度学习算法直接处理大量的测试数据,分析挖掘其潜在的特征,进而实现机载设备潜在故障的有效识别与预测,如文献[7]。此外,基于数据驱动的故障诊断方法与上述2种方法相比,可有效降低对先验知识的依赖,但其样本数据的质量与大小直接决定所提取故障特征的有效性,特征无效将直接导致无法有效识别出潜在故障,且目前暂未有公开的机载设备故障诊断测试数据集,在实际应用中须提前布局,采集机载设备故障数据,因此故障诊断实现周期长,短时间内无法快速投入现场使用。

而现有常用机载设备故障诊断软件平台大多仅针对特定对象选取上述方法之一设计实现,存在诊断策略单一、诊断理论基础弱、诊断知识复用性与共享性差和诊断平台通用性低等问题。例如文献[8]中的机载CPU板硬件故障诊断平台设计,可有效定位CPU板硬件故障;但其针对性较强,知识复用性与共享性差,平台很难通用化。已有的少量针对通用测试诊断平台的相关研究中,多以通用测试为主,弱化了故障诊断部分,且平台所支持的诊断方法单一。例如文献[9]提出的一种基于模型的通用故障诊断平台;文献[10]提出的基于混合总线的机载电子设备通用测试诊断平台设计,其诊断方法主要是以数据驱动为主,辅以专家系统模糊推理机,虽然具有较强的可扩展性与通用性,但诊断实现需要大量的高质量数据,即诊断结果的可解释性易受数据规模大小以及数据质量好坏的影响。因此在面对不同场景、不同对象的需求时,上述通用诊断平台均无法支持现场测试诊断人员根据实际需求快速选择更有效的故障诊断方法,进而导致平台的通用性大打折扣。

因此,机载设备通用故障诊断平台应有机结合3类故障诊断方法,通过将基于模型和专家知识系统的诊断输出作为基于数据驱动的样本数据基础,将基于数据驱动的输出反馈至知识库,以提高诊断结果的质量与平台的通用性。为进一步提高机载设备故障诊断水平,满足关键装备技术国产化需要,本文设计一款机载设备通用故障诊断软件平台,在搭载3种诊断方法的基础上,实现对知识的科学管理、表示与复用共享,以及对故障的快速响应与精准定位。

1 需求分析

机载系统故障诊断,尤其是军机的故障诊断与传统大众商品的故障诊断不同,其设计、生产和使用各阶段的诊断方式不同,且不同机载设备的诊断方式差别也很大,为实现机载系统的通用故障诊断,要求诊断软件整合多种诊断方法实现混合驱动。

针对在地面环境(如总装测试)中机载设备测试成本高、故障种类多、诊断排故难等问题,为提高诊断效率、准确性与通用性,需要研制机载系统通用故障诊断平台,具体要求如下。

① 支持多级的权限管理、允许用户实现账号信息的注册、登录和修改等功能;

② 支持对机载设备的结构信息、故障信息、测点与测试信息进行增、删、改、查;

③ 支持多信号流图(Multi-Signal Flow Graph,MSFG)的图形化建模;

④ 支持故障模式、影响及危害性分析(Failure Mode Effects and Criticality Analysis,FMECA)文件的载入与自动解析;

⑤ 支持基于模型生成故障-测试依赖矩阵(又称D矩阵);

⑥ 支持对模型进行测试性参数分析;

⑦ 支持基于TEAMS-RT算法的故障推理;

⑧ 支持专家规则的增、删、改、查、在线编辑和绑定;

⑨ 支持可执行任务的增、删、改、查;

⑩ 支持离线上传数据以执行专家规则任务,获得基于专家知识的诊断结果,支持诊断结果的下载;

2 软件设计

2.1 架构设计

为提高机载系统故障诊断平台的可扩展性、降低机载系统测试诊断成本、提升诊断系统的通用性与诊断过程的可监视性,系统设计采用B/S架构,将平台前端与后端进行解耦处理,可有效满足基于云平台的部署需求。其中平台前端浏览器具有人机交互界面,提供外部数据导入、故障建模、诊断推理、诊断查询等用户指令的接收功能,与后端建立通信并将后端的响应数据以可视化的形式反馈至用户;后端服务器响应前端请求,提供基于数据库的数据存储与管理、用户管理、网络通信、故障诊断业务逻辑与实现等功能,完成前端指令的执行工作。故障诊断软件平台架构如图1所示,包含以下5层。

图1 故障诊断软件平台架构图

① UI应用层:为用户提供作为平台基础与具备核心功能的人机交互界面,通过诊断知识、模型和结果的可视化配置,有效提供诊断过程的可监视性。

② 数据交互层:提供前后端信息交互传递接口,以保证平台的稳定应用。

③ 业务逻辑层:平台功能实现的核心层,完成平台的数据处理、诊断模型构建和推理等工作,采用模块化的方式构建,减少了各功能之间的耦合程度,便于软件维护。

④ 中间件层:提供后端框架引擎与基础配置工具。

⑤ 数据层:以数据库为主,独立文件为辅,实现诊断知识、测试数据、诊断记录、平台信息等数据的存储。

2.2 核心功能设计

为有效提升故障诊断平台的通用性,设计了模型、数据、专家知识驱动的混合诊断方法,软件平台功能模块如图2所示,这样用户可以根据诊断需求自由选择1个或多个诊断方法,以更好地服务于不同机载设备的多样输入输出形式。此外,为提升软件平台的适用性,设计了必要的辅助管理功能,包括用户管理和诊断结果管理。

图2 软件平台功能模块图

2.2.1 基于多信号流图模型的故障诊断模块

鉴于多信号流图[11]可清晰表示故障与测点关系,可直接用于故障诊断,且在文献[12]和文献[13]中应用多信号流图实现了对多种机载设备的有效诊断,因此将其作为核心模块之一,软件主要通过多信号流图建模以及TEAMS-RT算法[14-15]实现。基于多信号流图模型的故障诊断流程如图3所示。

图3 基于模型的故障诊断流程

传统的多信号流图建模需要技术人员根据诊断对象的系统结构与原理分析手动建模,本文为提高建模效率,充分利用系统设计时提供的故障模式、影响和危害分析FMECA文件,通过FMECA载入模块快速实现故障模式提取,以省去烦琐的建模过程,让技术人员更关注于信号传递、故障模式之间的关系,提高建模效率。技术人员利用多信号流图建模模块与已载入的FMECA故障信息,以信号、部件故障与测点为主要元素建立多信号流图,即完成模型的构建。

基于建立的多信号流图,测试性分析模块将其转化为D矩阵,并计算相关测试行参数。一般地, D矩阵的行对应一个故障模式,列对应一种测试或一个测点。对于复杂系统,综合考虑效率与计算成本,诊断推理模块基于测试结果,应用TEAMS-RT算法对生成的D矩阵进行分析,实现对故障模式的判断。

2.2.2 基于专家知识系统的故障诊断模块

专家推理机[16]可将传统的专家知识转换为数条计算机可执行的机载设备故障诊断规则,具备灵活、精准、执行速度快等优势。

本文将构建IF-THEN专家推理机作为本模块实现的核心,同时为有效提高知识的复用性,设计了基于Python函数的统一规则编辑模板,可利用专家规则编辑模块提供的滤波、阈值比较、逻辑组合判断等功能,快速将抽象的专家知识编辑为诊断规则,并将其存储至规则库集中管理。基于专家知识系统的故障诊断流程如图4所示。

图4 基于专家知识系统的故障诊断流程

在对不同机载设备进行诊断应用时,先通过规则库管理模块检索所需规则,再利用专家规则绑定模块将规则与实际测点绑定。为完成机载系统的复杂诊断需求,专家规则绑定模块可对测点绑定多条规则,从而完成专家推理机的构建。基于已构建的专家推理机,诊断结果监视模块对机载设备的测试数据进行推理分析,并将诊断结果以表格形式进行可视化展示与存储。

2.2.3 基于数据驱动的故障诊断模块

鉴于数据驱动可只基于数据本身潜在的故障特征实现设备的异常检测与故障预测,无须依赖先验知识,可作为基于模型与基于专家知识诊断方法的补充。尤其在现场技术人员对机载设备结构与原理知识掌握不足、专家知识缺乏的情况下,可直接利用该模块提供的功能完成设备的故障预测。基于数据驱动的故障诊断流程如图5所示。

图5 基于数据驱动的故障诊断流程

对于测试数据,为方便存储与管理,设计数据的上传与管理模块实现对测试数据的自动载入和集中管理。对于诊断算法,由于机载系统的测试数据特点不同,其诊断算法多种多样,为有效提高诊断算法的复用性,需要对诊断算法的输入格式进行规范化处理,为提高基于数据诊断的可扩展性,设计训练与测试脚本载入模块,对不同测试数据加载多种类型的诊断算法,以满足不同机载设备的诊断需求。

训练模型与模型管理模块基于已载入的测试数据与诊断算法进行算法模型的训练,进而得到诊断模型。基于得到的诊断模型,执行测试与结果管理模块完成对机载设备的异常检测与故障预测。

2.2.4 用户管理模块与诊断结果管理模块

机载系统种类多、数量大且异常复杂,需要多专业协同工作与管理,为保证平台的有序运行,需要使用用户管理模块。平台管理者按需通过用户增、删、改、查模块添加新用户,通过角色管理模块完成用户的角色设置,通过权限管理模块完成角色权限设置,支撑数据、脚本、模型和结果的共享,提高诊断效率。

为方便共享诊断知识,设计诊断结果管理模块对诊断数据进行统一管理。一方面设计诊断报告生成模块,以规范输出诊断报告;另一方面设计平台使用记录模块与诊断结果历史记录模块,将使用记录与诊断结果缓存至后端服务器,以备故障知识的查询或故障复现使用。

2.3 交互设计

为保证机载系统故障诊断过程中数据的有效传递和平台的正常运行,系统设计平台内外部交互方式如图6所示。

图6 平台交互示意图

平台内部交互指通用故障诊断平台前端浏览器与后端服务器之间的通信,综合考虑机载系统故障诊断过程的可监视性和诊断结果的可检索性,设计实现2种内部通信模式,具体包括:① 基于Axios的前后端异步通信模式,该模式由前端主动发起,主要用于服务器端数据的拉取、前端指令的提交与响应等,基于该模式可有效满足指令、信息或文件的双向流通;② 基于WebSocket的前后端实时通信模式[17],以支撑完成故障诊断推理的实时交互。

平台外部交互指诊断平台与外部环境的交互,主要表现为用户与平台前端的交互。鉴于基于模型或知识的机载系统故障诊断需依赖大量的专家先验知识,以及基于数据驱动的机载系统故障诊断需依赖大量测试数据,为有效减少数据处理时间、提高故障诊断效率,外部交互设计预留支持.json、.xlsx和.py等格式文件的数据交换接口,以支持内外部数据的自动解析与转换。诊断平台前端接收用户数据上传指令,从本地读取用于机载设备故障诊断模型建模所需的FMECA文件与专家知识等,自动解析成平台所需的数据形式,并在浏览器界面展示,以便用户查看并检查数据的正确性。

3 3种诊断方法间的关系

3种诊断方法彼此独立,在合适的条件下,可并行完成不同机载设备或诊断需求的故障诊断任务。当熟悉机载设备结果与原理、但测试数据不充裕时,可优先选择基于多信号流图模型的诊断方法完成对机载设备的故障诊断。

3种诊断方法相互联系,生成的诊断结果可以相互利用,如图7所示。在机载系统的诊断应用中,为有效保证诊断结果的可靠性、提升诊断效率,平台支持3种方法的串联组合使用。如针对以多信号流图模型为主的机载系统故障诊断应用中,为有效提升诊断效率与诊断结果的准确性,可通过基于专家知识系统的故障诊断模块与基于数据驱动的故障诊断模块实现对测试数据的预处理,将其转换为符合TEAMS-RT算法输入的标准数据格式,再结合多信号流图生成的D矩阵,从而有效完成机载设备的故障诊断。

图7 3种方法之间的关系示意图

4 应用实例与对比分析

4.1 应用实例

以某型号无人机大气数据系统为例,应用本文平台完成实际故障的诊断,以充分验证平台的有效性。此案例以基于模型的故障诊断为主体方法,使用规则推理机和基于数据驱动的故障诊断方法为TEAMS-RT算法提供测试向量,最终依靠TEAMS-RT算法得到诊断结果。详细故障诊断流程如图8所示。其中最右侧通路为基于模型的故障诊断,中部通路为数据驱动部分,左侧通路为规则推理部分。事实上,在一些其他情况下,也可以直接对规则推理机或数据驱动方法的结果赋予意义,直接作为故障诊断结果,如图8中的(A)、(B)位置所示。

图8 某型号无人机大气数据系统的故障诊断流程

在建模方面,本案例选择了静压引气管测压孔堵塞、静压受感器开路等11个常见的重要部件故障模式,以及静压机内测试、总温探头人工检测等13个可执行的测试进行分析,然后通过软件平台的多信号流图建模模块完成了机载大气数据系统的多信号流图模型构建,模型与软件界面如图9所示。

图9 机载大气数据系统多信号流图建模与软件界面

其中TEAMS-RT算法的输入来源包括:① 基于多信号流图建模模块自动生成D矩阵。② 多渠道诊断得到的布尔测试向量组,该向量组包括结合实际情况,通过构建含有13个规则的推理机,对传感器已接收数据进行逻辑、门限等判断,输出基于专家知识系统模块诊断的布尔测试向量;针对长时间的无标签数据,采用独立森林异常检测算法进行检测,得到基于数据驱动模块诊断的布尔测试向量和外部导入平台的其他布尔测试向量。

此案例生成的D矩阵与测试诊断结果如图10所示。测试结果表明,平台基于已生成的测试向量组与D矩阵执行TEAMS-RT算法成功将故障定位至静压引气管路泄漏,这将充分证明研究设计的机载系统通用故障诊断软件平台的实际有效性。

图10 D矩阵与测试诊断结果图

4.2 对比分析

从平台所支持的诊断策略、是否支持诊断知识共享,以及平台的适用范围即平台通用性3个方面对提出的平台与现有的机载设备故障诊断平台进行比较,对比结果如表1所示。本文设计的故障诊断平台不仅支持多策略的组合诊断,也支持不同诊断策略间诊断知识的共享与复用,可有效提升机载系统故障诊断平台的通用性与诊断效率。

表1 本文平台与现有机载设备故障诊断平台对比表

5 结束语

针对机载系统,本文设计实现了一种通用故障诊断软件平台。该平台通过搭载模型、数据、专家知识驱动的3种可独立或组合运行的故障诊断方法,可有效满足不同机载设备的诊断需求,提高机载设备的故障诊断效率,为后续机载系统的通用故障诊断测试研究提供了平台技术支撑。