CN107004234A - 用于组件故障模式监测的系统和方法 - Google Patents

Abstract

根据一个方面，存在用于组件故障模式监测的系统和方法。该系统包括用于管理由工程师在现场得到的关于设计的产品的数据的故障模式报告模块，并且包括故障检修会话数据库。该故障模式报告模块被配置为与用于存储和管理关于产品设计的数据的产品生命周期管理模块进行通信。该故障模式报告模块使用与产品生命周期模块中的材料清单相对应的感兴趣的组件，基于感兴趣的组件搜索故障检修会话的集合，并且提供在现场所遇到的针对感兴趣的组件的故障模式的报告。可以向研究和设计工程师提供该报告，以便告知未来的组件的设计。

Description

用于组件故障模式监测的系统和方法

技术领域

本文中的公开涉及用于跟踪和管理关于复杂装备的设计的数据的方法和系统以及用于诊断关于复杂装备的问题的方法和系统。

背景技术

复杂装备由代表与设计以及运行维护两者有关的挑战的系统、子系统、组件和子组件组成。设计工程师和其他设计师往往针对特定规范或者为了满足特定设计需求来设计复杂装备和其组成部分。现场工程师和其他技师往往不得不在现场管理装备的维护。取决于所涉及的装备的复杂度，装备的设计和维护两者均能够代表复杂的且棘手的处理。

致力于复杂装备的维护和保养的现场工程师受益于装备的先前体验。了解问题的特定症状先前如何与装备的该问题或故障的根本起因有关，这能够帮助现场工程师诊断随后的问题。由于症状和起因之间的关系变得愈发复杂，现场工程师有必要使用为跟踪这些关系而具体设计的工具。

一种这样的工具利用了基于案例推理技术。在申请人的美国专利号7,225,176中提供了基于案例推理技术的系统和方法的示例。具体地，基于案例推理技术包含基于问题案例和已知的已解决案例的属性将该问题案例匹配到该已解决案例。

利用包括基于案例推理的工具显著地增加了与装备问题和故障的症状和起因有关的信息的可用性。现场工程师和技师往往是遇到先前未曾遇到的故障的第一人。因此，使用这样的工具的现场工程师和技师可以生成使特定组件的故障与作为该故障的起因的子组件联系的重要数据。类似地，系统的故障可能由子系统引起，并且子系统的故障可能由特定组件引起。

新产品往往是对先前设计的逐步改进(或再加工)。因此，关于系统、子系统和组件的特定故障模式的知识代表了会对设计工程师有价值的信息。具体地，设计工程师能够使用该知识，以便设计出避免当前产品所经历的已知问题的未来产品。

然而，当开始复杂装备的设计时，设计工程师通常无法访问由现场工程师生成的所有信息。由于某一种原因，设计工程师用于设计复杂装备的计算机系统与现场工程师用于诊断问题并执行维护的计算机系统是不同的且是分离的。通常，这些计算机系统由不相干的出售商提供，并且可能没有针对互动来设计。此外，设计工程师和现场工程师可能为分离的且不相干的公司工作。尽管如此，向设计工程师提供由现场工程师生成的故障模式信息是有好处的。

因此，需要一种允许装备设计师获取组件故障模式和出现率的报告的组件故障模式监测，以便告知设计过程当前装备的改善和未来的装备设计。

发明内容

本申请涉及用于组件故障模式监测的系统和方法。

根据一个方面，公开了一种组件故障模式监测系统。系统包括用于管理由现场工程师得到的关于设计的产品的数据的故障模式报告模块。故障模式报告模块被配置为与用于存储和管理关于产品设计的数据的产品生命周期管理模块进行通信。

故障模式报告模块包括用于存储故障检修事件的细节和成果的故障检修会话数据库。

故障模式报告模块被配置为与产品生命周期管理模块进行通信，从产品生命周期管理模块接收感兴趣的组件，针对与感兴趣的组件相关联的故障检修会话的集合搜索故障检修会话数据库，在故障检修会话的集合内识别故障模式，并且向产品生命周期管理模块传送所识别的故障模式。

产品生命周期模块可以进一步包括从中确定感兴趣的组件的材料清单。

所识别的故障模式例如在被传送到产品生命周期管理模块时，可以基于特定的识别的故障模式在故障检修会话的集合内出现的频率来进行优先排序。

该系统可以包括与故障模式报告模块进行通信的故障检修模块，在一些实施例中，故障检修模块可以包括基于案例的推理引擎。根据某些实施例，故障检修会话数据库可以利用由故障检修模块生成的故障检修会话来填充。

如果使用基于案例的推理引擎，则基于案例的推理引擎可以通过考虑用于直接地识别与感兴趣的组件相关联的故障模式的定论属性和用于间接地识别与感兴趣的组件相关联的故障模式的确认属性，来执行基于案例的推理。

根据一些实施例，故障检修模块能够基于产品生命周期管理模块或其他外部系统内的纠正和预防措施数据库，来接收与识别的感兴趣的组件相对应的纠正措施的集合。

根据另一个方面，存在一种组件故障模式监测方法。该方法包括识别感兴趣的组件，针对与感兴趣的组件相关联的会话的集合搜索会话数据库，识别与感兴趣的组件相关联的会话内的故障模式，以及报告基于所识别的感兴趣的组件识别的故障模式。

感兴趣的组件可以从材料清单中识别，并且所报告的经识别的故障模式可以基于在会话的集合内出现的频率来进行优先排序。

根据一些实施例，会话数据库可以利用作为故障检修方法的结果生成的会话来填充，在一些情况下，会话数据库可以包括基于案例的推理。

当故障检修方法包括基于案例的推理时，则可以通过考虑用于直接地识别与感兴趣的组件相关联的故障模式的定论属性和用于间接地识别与感兴趣的组件相关联的故障模式的确认属性来执行基于案例的推理。可以在基于案例的推理会话期间基于定论问题来确定定论属性。可以在基于案例的推理期间基于确认问题来确定确认属性。

根据另一个方面，存在一种用于组件故障模式监测的非暂时性计算机可读介质。非暂时性计算机可读介质包含至少一个组件和会话记录。至少一个组件对应于在产品生命周期管理软件中列出的组件。会话记录包括用于识别故障模式的存在并且与组件相关联的至少一个属性，以及与至少一个属性相对应的故障模式。对至少一个组件内的感兴趣的组件进行标识用于识别出与感兴趣的组件相关联的特定故障模式。

可以根据基于案例的推理的结果生成会话，并且至少一个组件可以包括纠正和预防措施列表中的组件的集合，其基于现场可更换的和/或现场可修理的组件。属性可以是在基于案例的推理期间已经分别基于定论和/或确认问题所确定的定论属性和/或确认属性。

附图说明

现在将参照以下附图仅通过示例描述本公开的某些实施例，其中：

图1是根据一个实施例的用于组件故障模式监测的系统的示意图；

图2是根据一个实施例的用于组件故障模式监测的系统的模块图；

图3是描绘产品生命周期管理、故障检修、故障模式报告和故障检修会话数据之间的数据关系的数据图；并且

图4是描绘根据一个实施例的组件故障模式监测的方法的流程图。

具体实施方式

可以以硬件或软件或者两者的组合来实施在本文描述的系统和方法的实施例。然而，优选地，这些实施例在计算机程序中实施，计算机程序在均包含至少一个处理器、数据存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备和至少一个输出设备的可编程计算机上执行。例如且不进行限制，可编程计算机可以是主计算机、服务器、个人计算机、膝上计算机或者智能电话。对应用程序代码应用输入数据，以执行在本文描述的功能并且生成输出信息。通过已知的方式将输出信息应用于一个或多个输出设备。

优选地，每个程序以高级程序或面向对象编程和/或脚本语言实施，以与计算机系统进行通信。然而，如果期望，这些程序能够以汇编或机器语言实施。在任何情况下，语言可以是编译的或解释型语言。每个这样的计算机程序优选地被存储在由通用或专用可编程计算机可读取的存储介质或设备(例如ROM或软磁盘)上，用于当存储介质或设备由计算机读取时配置和操作计算机，来执行在本文描述的过程。还可以考虑将本发明的系统实施为利用计算机程序配置的计算机可读存储介质，其中如此配置的存储介质使计算机以特定和预定义的方式操作，以执行在本文描述的功能。

参考图1，在其中图示出根据一个实施例的用于组件故障模式监测的系统100。系统100包括经由联网装备106、114和118连接的各个计算机102、104、110和112以及数据库108和116。

通常，系统100可以被考虑为包括与设计工程和现场工程两者有关的组件。计算机102和104、数据库108和联网装备106是在设计工程中使用的装备的示范。计算机110和112、数据库116和联网装备114是在现场使用的工程装备的示范，诸如用于故障检修。联网装备118是诸如因特网、广域网(WAN)或局域网(LAN)的通信手段的示范，设计工程装备通过这些通信手段与现场工程装备进行通信。

设计工程师可以访问可以是工作站的计算机102，以便访问、维持或者生成与他们先前已经设计的或者处于设计过程中的特定系统或组件的产品生命周期管理有关的信息。也可以使用可以是服务器的计算机104。在各个实施例中，产品生命周期管理模块的某些方面可以位于计算机102或计算机104或者两者的组合(或附加的计算机，未示出)上并且由其执行。此外，与产品生命周期管理有关的信息可以被存储在数据库108中，数据库108可以或可以不与计算机102或计算机104任一个物理地集成。

产品生命周期管理模块的各个方面可以位于不同的物理位置，和/或由不同的组织或公司来操作。

产品生命周期管理模块可以包括与现有系统或组件有关的文档功能。(在这里，“系统”或“组件”是产品生命周期管理所涉及的“产品”)。产品生命周期管理模块还可以包括系统或组件的3D建模或渲染功能，并且可以支持分析与特定系统或组件有关的故障模式和相关影响的能力。

产品生命周期管理模块包括故障报告和纠正措施系统。故障报告和纠正措施系统总体上致力于帮助工程师理解如何改善当前和未来的设计，以及识别现有设计的问题和当前需要。具体地，故障报告和纠正措施系统可被认为包括问题识别数据库以及纠正和预防措施数据库。

现场工程师可以访问可以是便携式计算设备的计算机110和/或可以是工作站计算机的计算机112，以便访问现场工程工具。在各个实施例中，现场工程工具的某些方面可以位于计算机110或计算机112或者两者的组合(或附加的计算机，未示出)上并且由其执行。此外，与现场工程工具有关的信息可以被存储在数据库116中，数据库116可以或可以不与计算机110或计算机112任一个物理地集成。

在一些实施例中，在现场使用的工程工具的各个方面可以位于不同的物理位置，和/或可以由不同的组织或公司来操作。考虑这一点，并且考虑到产品生命周期管理模块相对于在现场使用的工程工具，可能另外位于不同的物理位置和/或由另外不同的组织或公司操作并且由不同的出售商提供，本申请的一些实施例能够实现平台不可知的、出售商不可知的或者用户不可知的操作。也就是说，本申请的一些实施例能够实现由特定公司操作的一个平台上的产品生命周期模块与由不同公司操作的不同平台上的现场使用的工程工具之间的协作。

现场工程工具可以包括装备数据下载，诸如可以由装备的原始工程制造商(或设计师)来提供。装备数据可以包括用户指南、用于装配、使用和维护的说明，等等。现场工程工具还可以包括由现场工程师为特定系统或组件生成的装备缺陷和维修记录。

现场工程工具包括故障检修模块。根据一些实施例，故障检修模块包括基于案例的推理，其使用基于案例的推理引擎来基于问题案例和已知的已解决案例的属性将该问题案例匹配到该已解决案例。

设计工程师可以访问计算机102和/或104(或另一个计算机，未示出)，以便访问关于特定系统或组件的故障模式报告。故障模式报告模块可以在设计工程计算机和现场工程计算机的任何组合上操作。在一些实施例中，故障模式报告模块可以在现场工程计算机110和/或112上操作，并且可以向设计工程计算机102和/或104传送故障模式报告。在其他实施例中，通过向计算机102和/或104或数据库108传送数据，或者通过为计算机102和/或104提供对计算机110和/或112和/或数据库116上的相关数据的访问，故障模式报告模块可以使用由现场工程计算机提供的数据在设计工程计算机102和/或104上操作。

参考图2，描绘根据一些实施例的组件故障模式监测系统200。该系统包括产品生命周期管理模块202以及与产品生命周期管理模块202进行通信的故障检修和故障模式报告模块204。

产品生命周期管理模块202用于特定组件的构思、设计、实现和服务。产品生命周期管理模块202包括材料清单206以及故障报告和纠正措施系统(FRACAS)208。

材料清单206大体上被组织为系统内的组件的层级结构。基本上，层级结构可以被描述为“系统”和“组件”之间的关系，其中，在层级结构的一个层级上，系统是各组件的组织；并且每个组件就其本身而言可以是由其自己的位于层级结构的下一个较低层级的组件组成的“系统”。

具体地，层级结构内的某些组件被认为是现场可修理的或现场可更换的。当系统或装备装配在现场使用中时遇到问题或故障时，该问题或故障的起因可以被确定为特定组件。如果已经出故障的特定组件与现场可修理的或现场可更换的部分相比在材料清单层级结构上较低，那么从现场工程师的观点来看，该问题或故障实际上穿过层级结构至现场可修理的或现场可更换的组件的级别。

产品生命周期管理模块202内的FRACAS 208包括纠正和预防措施(CAPA)数据库210以及问题识别数据库212。

纠正和预防措施数据库210包含在材料清单206中列出的组件的相关信息，如装备的原始工程制造商或设计工程师所知的。该信息包括对组件故障进行响应的措施(诸如修改的部件、服务公告、改善的维护程序以及针对检测到的问题的其他这样的解决方案)的指令。

问题识别数据库212包含根据自故障检修会话捕捉的故障模式报告而生成的信息。

故障检修和故障模式报告模块204包括故障检修模块214、故障模式报告模块218以及故障检修会话数据库220。

故障检修模块214用于生成并记录与现场工程师所遇到的特定症状和问题有关的故障检修会话，例如这可以使用基于案例的推理(CBR)引擎216来完成。这些故障检修会话被存储在故障检修会话数据库220中。故障模式报告模块218用于基于存储在故障检修会话数据库220中的现场工程师所遇到的关于设计工程师感兴趣的特定组件的故障模式，来提供与该感兴趣的组件有关的故障模式报告。

故障模式报告模块218使用与产品生命周期管理模块202中的材料清单206中的组件相对应的感兴趣的组件的标识符。故障模式报告模块218然后在故障检修会话数据库220内搜索与感兴趣的组件相关联的故障检修会话集合，并且在故障检修会话集合内识别故障模式。这些故障模式形成报告的基础，该报告然后可以例如被提供给产品生命周期管理模块202，在那里该报告可以由设计工程师访问。

根据一些实施例，故障模式报告模块218可以包括在故障检修和故障模式报告模块204内，如所示的。替换地，故障模式报告模块218可以是与图2中示出的模块204分开地操作的独立模块。照此，故障检修模块214和故障模式报告模块218可以在单个计算机系统上一起操作；或故障检修模块214和故障模式报告模块218可以在分开的计算机系统上操作。此外，根据其他实施例，故障检修模块214和故障模式报告模块可以由独立的出售商生产，并且可以在相同的或不同的计算机系统上操作。

使用故障检修模块214来生成和记录故障检修会话。具体地，使用故障检修模块214通过故障检修活动来检测服务中组件的故障迹象。当目前在现场服务中的装备出现问题时，故障检修模块214向现场工程师和技师提供指南。

一旦已经使用故障检修模块214生成并记录了故障检修会话，就可以将故障检修会话存储在故障检修会话数据库220中。具体地，故障检修模块214可以维持故障检修会话的数据库，以供故障检修模块214使用。另外地，由故障模式报告模块218使用故障检修会话数据库220，以便生成故障模式报告。照此，故障模式报告模块218可以包括故障检修会话数据库220，或者故障模式报告模块218可以从故障检修模块214内访问故障检修会话数据库220。

感兴趣的特定组件可以在材料清单206内被识别，并且被传送到故障检修模块214，如由箭头222所示的。基于识别的感兴趣的组件，故障检修和故障模式报告模块204(或故障检修模块214，根据具体情况)生成与该感兴趣的组件有关的故障模式报告，并且向问题识别数据库212传送故障模式报告，如由箭头224所指示的。在不存在产品生命周期管理模块的情况下，或者如果可用的材料清单不适合于服务应用，则可以手动地制造感兴趣的组件的列表。

如上所述，在一些实施例中，可以使用分离的模块214和218，每个均用于故障检修和故障模式报告；而在其他实施例中，一个故障检修和故障模式报告模块204可以执行模块214和218中每一个的功用。此外，如上所述，材料清单206、纠正和预防措施数据库210以及问题识别数据库212可以包括在产品生命周期管理模块202内。

可以以各种方式组织被传送到问题识别数据库212的故障模式报告。在一些实施例中，该报告可以包括基于每个故障模式出现的频率的故障模式的优先排序列表。因此，向接收该报告的设计工程师通知关于感兴趣的组件的最频繁出现的故障模式。类似地，可以基于更换成本、更换时间、平均组件生命周期等等来组织报告。如由箭头224所指示的，故障检修和故障模式报告模块204(或故障模式报告模块218，根据具体情况)通过就技师在故障检修期间捕捉的故障模式进行报导来馈送问题识别数据库212。

在其他实施例中，纠正和预防措施数据库210可以使用来自故障模式报告的更多信息，如由箭头226所指示的。纠正和预防措施数据库210包括响应于组件故障的措施(其可以包括诸如修改的部件列表、服务公告、改善的维护程序和针对检测到的问题的其他解决方案之类的事情)的指令。箭头226所指示的通信可以牵涉自动化处理，或者可以牵涉诸如由工程师或技师响应于组件故障而手动创建措施的指令。在任何情况下，由箭头224所指示传送的故障模式报告可用来通知在纠正和预防措施数据库210内创建响应于组件故障的措施的指令。

一旦响应于组件故障的措施的指令位于纠正和预防措施数据库210内，它们就可以被提供给故障检修和故障模式报告模块204(或故障检修模块214，根据具体情况)，如由箭头228所指示的。照此，来自纠正和预防措施数据库210的信息可以用于通知由现场工程师和技师执行的随后的故障检修会话和维护程序。

参考图3，描绘一数据图，其示出了产品生命周期管理数据302、故障检修数据304、故障模式报告数据306和故障检修会话数据308之间的一些关系。

产品生命周期管理数据302包含材料清单310(构成装备的组件装配的列表，被描绘为组件312和子组件)。具体地，某些组件是现场可修理的或现场可更换的。这些组件有资格被认为是感兴趣的组件，用于跟踪在现场操作的装备所遇到的故障模式。

感兴趣的组件可以是较大装配的一部分，诸如可以被定义在材料清单310的层级结构中。故障模式和相关联的关键症状处于故障检修处理的核心。故障模式通常出现在组件层级(例如特定部件已经出故障)。故障模式也可出现在系统或装配层级(例如，故障是由不正确的操作或有问题的状况引起的)。

故障检修模块和/或故障检修会话数据库包含多个解决方案。每个解决方案与修复措施——诸如更换有缺陷的组件，相关联。故障检修模块使用利用基于案例的推理引擎的解决方案，来产生将最终确认观察的问题与特定解决方案之间的匹配的故障检修指南。

故障检修数据304包含位于组件域314内的组件列表。该组件列表反映产品生命周期管理数据304内的材料清单310。照此，组件列表由组件316和子组件318(或系统和组件)的层级结构表示。尽管为了说明示出了两个层级，但层级结构可以是任何数量的层级深度。

因为组件列表由层级结构表示，所以可存在构成感兴趣的特定组件316的部件(子组件318)的另外故障。(例如，燃料增压泵可以由电动机、电动机驱动电路、泵、外壳、密封物、螺栓等等组成)。这些子组件318中的每一个可以具有影响该较大装配的行为的一个或多个故障模式。然而，在故障检修处理之后被发现需要更换的项是该较大装配(组件316)，而不是较小的部件(子组件318)。因此，借助于故障检修模块中的解决方案，小部件(子组件)的所有故障模式归因于该较大装配(组件)，解决方案中的每一个描述单个故障模式与其可观察到的效应。因此，一个组件可以具有多个解决方案，这是因为其可能以多个方式出故障。如上所述，解决方案、故障模式和可观察到的效应与针对特定组件316或子组件318的属性320有关。

以有利于产品生命周期管理数据302中的每个项的一对一关系的格式，来存储故障检修数据304的组件域314内的组件316的列表。例如，可以在故障检修数据304中使用与在产品生命周期管理数据302中使用的相同的组件部分编号方案。

存储在故障检修模块中的每个解决方案包含多个属性320，多个属性320以组合形式唯一地定义用于支持在解决方案中描述的故障模式的存在的迹象。具体地，两种类型的属性具有特定相关性：“定论”属性，和“确认”属性。定论属性直接地识别组件中的故障(例如，“螺线管的连续性检查测量‘断路’”)。确认属性间接地识别故障(例如“更换螺线管解决了该问题”)。

根据一些实施例，如由图3中的虚线所指示的，可以在故障检修数据304内创建单独的域。具体地，可以创建纠正和预防措施(CAPA)域322。CAPA域322的组件324可以仅仅包括材料清单310中的感兴趣的组件312(即，仅仅现场可修理的和现场可更换的部件)。此外，在CAPA域322下，定论类型属性326和确认类型属性328的相关实例被复制并且与感兴趣的组件324相关联地被存储。

通过复制或输入感兴趣的组件324的列表来建立CAPA域322。一旦在CAPA域322下列出感兴趣的组件324，就存在充足的信息来识别产品生命周期管理模块中的感兴趣的组件312。(即，故障检修数据304的CAPA域322内的信息足以识别产品生命周期管理数据302的材料清单310中的组件312)。随后，从故障检修数据304的组件域314复制与感兴趣的组件324的故障有关的所有定论属性326和确认属性328并且使之与CAPA域322下的感兴趣的组件324相关联。

CAPA域322的创建不是在每个实施例中是必要的。在单独的CAPA域322(或除组件域314之外的其他域)内，使组件域314中的(属性320当中的)定论和确认属性与产品生命周期管理数据302的材料清单310中的组件312相关联是必要的。

故障检修模块的使用生成了将故障检修活动文档化的会话。故障检修会话数据308可以包括会话ID 330、时间戳332、属性334(包括定论336和确认338属性)、故障模式340、以及有关的关键组件342。故障检修会话数据308还可以包括与特定故障检修会话有关的名称、日期、测试结果等等。

具体地，故障检修模块识别解决特定问题的解决方案。当这发生时，故障检修模块将定论和/或确认属性呈现给现场工程师或技师以用于最后确认。确认的属性334然后被存储在故障检修会话数据308中，诸如存储在故障检修模块和/或故障检修会话数据库内，其可以在这里被查询以用于随后的报告目的。

当故障检修模块识别作为问题的起因的解决方案时，其实际上也识别故障模式340。使用故障检修模块所存储和收集的数据允许产品生命周期管理数据302中的感兴趣的组件312与其在现场遇到的并且已经通过技师的故障检修活动检测到的故障关联。

因为感兴趣的组件312、324、342与定论326、336和/或确认328、338属性之间的关联，因此该解决方案能够容易地与出现在感兴趣的组件312、324、342内的故障模式340相关联。此外，故障检修会话数据能够指示在故障检修会话期间捕捉的详细信息，以及追溯到执行故障检修的技师的信息。

参考图4，描绘组件故障模式监测的方法400。

根据一些实施例，方法400可以在步骤402开始。在其他实施例中，用于组件故障模式监测的方法可以在不同的步骤——诸如步骤412开始。

在步骤402，由现场工程师或技师识别现场的装备的新问题。技师在故障检修模块中输入与该问题相关联的属性。根据一些实施例，故障检修模块可以是图2中示出的故障检修模块214，并且可以包括基于案例的推理引擎216。在步骤402，创建故障检修会话。

在步骤404，故障检修模块识别对于技师来说潜在的已解决案例的排序集合。使用基于案例的推理，故障检修模块可以通过将与该问题相关联的至少一个属性与已知已解决案例的属性匹配来识别潜在的已解决案例。识别的潜在的已解决案例可以或可以不表示技师可接受的单一解决方案。

如果在步骤406没有找到技师可接受的单一解决方案，那么该问题案例未被解决。在该情况下，在步骤408，技师基于通过故障检修模块的基于案例的推理所提供的相关问题来获取与该问题有关的新的属性信息，并且该方法再次对步骤404进行迭代。

如果该问题案例在步骤406已经被解决并且单一解决方案已经被技师接受，然后故障检修会话结束。在步骤410，根据具体情况，故障检修会话被存储在故障检修模块和/或故障检修会话数据库中。

在步骤402至410的针对牵涉各个组件的多个问题的多个实例之后，将在故障检修模块或故障检修会话数据库中累积相当大数量的故障检修会话。步骤402至410可以通常包括基于案例的推理方法420的高级步骤。

当诸如设计工程师的用户寻找特定组件的故障模式报告时，执行步骤412。在步骤412，识别感兴趣的组件。根据一些实施例，可以基于材料清单(诸如在产品生命周期管理模块——诸如图2中示出的模块202中可用的)识别感兴趣的组件。

在步骤414，针对与感兴趣的组件有关的故障检修会话记录，搜索故障检修会话数据库。在先前的步骤404至410期间，故障检修模块已经利用作为故障检修会话的解决方案生成的会话填充了故障检修会话数据库。

在步骤416，识别与感兴趣的组件相对应的特定故障模式。在故障检修会话记录的创建期间(例如，在步骤404至410期间)，已经识别作为问题的起因的解决方案，并且，因此实际上已经识别了故障模式。因此，当感兴趣的组件随后(诸如从材料清单中)被识别时，存储在故障检修会话记录中的数据使感兴趣的组件与现场遇到的故障关联。

在步骤418，将所识别的与感兴趣的组件有关的故障模式报告给用户。根据一些实施例，可以基于在现场出现的频率(即，故障模式已经出现的次数)来对报告的故障模式进行优先排序。

Claims (20)

1.一种组件故障模式监测系统，包括：

故障模式报告模块，用于与产品生命周期管理模块一起使用来管理由现场工程师得到的关于所设计的产品的数据，所述产品生命周期管理模块用于存储和管理关于产品设计的数据；

与所述故障模式报告模块进行通信的故障检修会话数据库；

所述故障模式报告模块被配置为：

与所述产品生命周期管理模块进行通信；

从所述产品生命周期管理模块接收感兴趣的组件；

搜索所述故障检修会话数据库，以获得与所述感兴趣的组件相关联的故障检修会话的集合；

在所述故障检修会话的集合内识别故障模式；以及

向所述产品生命周期管理模块传送所识别的故障模式。

2.根据权利要求1所述的系统，其中：

所述感兴趣的组件基于所述产品生命周期管理模块内的材料清单来确定。

3.根据权利要求1所述的系统，其中所识别的故障模式基于在所述故障检修会话的集合内出现的频率进行优先排序。

4.根据权利要求1所述的系统，进一步包括与所述故障模式报告模块进行通信的故障检修模块。

5.根据权利要求4所述的系统，其中所述故障检修会话数据库已经利用由所述故障检修模块生成的故障检修会话来填充。

6.根据权利要求5所述的系统，其中所述故障检修模块包括基于案例的推理引擎。

7.根据权利要求6所述的系统，其中所述基于案例的推理引擎通过考虑用于直接地识别与所述感兴趣的组件相关联的故障模式的定论属性和用于间接地识别与所述感兴趣的组件相关联的故障模式的确认属性，来执行基于案例的推理。

8.根据权利要求2所述的系统，其中：

所述故障检修模块被配置为基于所述产品生命周期管理模块内的纠正和预防措施数据库，来接收与所识别的感兴趣的组件相对应的纠正措施的集合。

9.一种组件故障模式监测方法，包括：

识别感兴趣的组件；

搜索会话数据库，以获得与所述感兴趣的组件相关联的会话的集合；

在与所述感兴趣的组件相关联的所述会话内识别故障模式；以及

报告基于所识别的感兴趣的组件识别的故障模式。

10.根据权利要求9所述的方法，其中所述感兴趣的组件从材料清单中识别。

11.根据权利要求9所述的方法，其中所报告的经识别的故障模式基于在所述会话的集合内出现的频率来进行优先排序。

12.根据权利要求9所述的方法，其中所述会话数据库已经利用作为故障检修方法的结果所生成的会话来填充。

13.根据权利要求12所述的方法，其中所述故障检修方法包括基于案例的推理。

14.根据权利要求13所述的方法，其中所述基于案例的推理通过考虑用于直接地识别与所述感兴趣的组件相关联的所述故障模式的定论属性和用于间接地识别与所述感兴趣的组件相关联的所述故障模式的确认属性来执行。

15.根据权利要求14所述的方法，其中所述定论属性已经在所述基于案例的推理期间基于定论问题确定，并且所述确认属性已经在所述基于案例的推理期间基于确认问题确定。

16.一种用于组件故障模式监测的非暂时性计算机可读介质，包括：

与在产品生命周期管理软件中列出的组件相对应的至少一个组件标识；

会话记录，包括：

用于识别故障模式的存在的至少一个属性，所述至少一个属性与所述至少一个组件标识相关联；以及

与所述至少一个属性相对应的故障模式；

其中利用所述至少一个组件标识对感兴趣的组件进行标识用于识别出与所述感兴趣的组件相关联的特定故障模式。

17.根据权利要求16所述的非暂时性计算机可读介质，其中所述会话从基于案例的推理的结果来生成。

18.根据权利要求16所述的非暂时性计算机可读介质，其中所述至少一个组件标识包括位于纠正和预防措施列表中的组件的集合，所述组件的集合基于现场可更换的和现场可修理的组件。

19.根据权利要求16所述的非暂时性计算机可读介质，其中所述至少一个属性是用于直接地识别所述故障模式的确认属性和用于间接地识别所述故障模式的定论属性中的至少一个。

20.根据权利要求19所述的非暂时性计算机可读介质，其中任何确认属性已经在所述基于案例的推理期间基于确认问题被确定，并且任何定论属性已经在所述基于案例的推理期间基于定论问题被确定。