CN102708134B

CN102708134B - 由维修程序开发故障模型

Info

Publication number: CN102708134B
Application number: CN201210060958.0A
Authority: CN
Inventors: S.辛赫
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2011-03-10
Filing date: 2012-03-09
Publication date: 2014-11-26
Anticipated expiration: 2032-03-09
Also published as: US20120232743A1; DE102012100390A1; US8527441B2; CN102708134A

Abstract

本发明涉及由维修程序开发故障模型。具体地，公开了一种用于由结构化的文本文档（例如维修程序）开发故障模型的方法和系统。维修程序或其他结构化的文本文档使用诊断规则被解析以提取症状，故障模式，和相关性。测试程序和修理指令也被解析以创造故障树并且识别额外的症状和故障模式。可达性分析然后被用于发现故障树中的隐藏的依赖性，由此产生额外的相关性。产生的症状，故障模式，和相关性然后被汇编到故障模型中，其能够用于车辆车载的实时故障诊断，或者用于维修车间处的车外诊断。

Description

由维修程序开发故障模型

技术领域

本发明总体涉及用于开发故障模型的方法和系统，更具体地，涉及用于由结构化的文本文档源（例如维修程序）开发故障模型的方法和系统，其从文档中的诊断故障信息提取症状，故障模式，可维修零件，和它们之中的相关性，解析测试程序以识别更多故障模型数据，使用可达性分析以发现隐藏的依赖性，并且将所有提取的数据汇编到产生的故障模型中。

背景技术

现代车辆是复杂的机电系统，采用许多子系统、部件、装置和模块，它们使用先进的算法和数据总线在彼此之间传递操作信息。与其他东西一样，这些类型的设备和算法容易出现错误、故障和故障，它们影响车辆的操作。为了帮助管理此复杂性，车辆制造商开放了故障模型，其将各种故障模式与车辆显示的症状匹配。

车辆制造商通常从各种不同数据源开发故障模型。这些数据源包括工程数据、保养程序文档、来自客户和维修技师的文本信息、保单数据等。虽然所有的这些故障模型能够为用于诊断和修理问题的有用工具，故障模型的开发会是耗时的，劳动密集型的，并且在一些情况下在一定程度上是主观的。另外，手动创造的故障模型可能不能一致地捕捉所有的故障模型，症状，和车辆系统中存在的相关性。此外，因为将文本手动转换成故障模式，症状，可维修零件，和相关性数据的困难和易出错属性，大量的故障模型数据贮存在遗留维修文档中，其中其经常为仅部分提取，或者完全被忽视。

需要一种从不同类型的结构化的文本数据源开发故障模型的方法。这种方法可以不仅减小创造故障模式所需的时间量和工作，还可以产生具有更多且更好的内容的故障模型，由此在区域中产生更精确的故障模式诊断，减小修理时间和成本，改进首次修复率，并且改进客户满意度。

发明内容

根据本发明的教导，公开了一种用于由结构化的文本文档（例如维修程序）开发故障模型的方法和系统。维修程序或其他结构化的文本文档使用诊断规则被解析以提取症状，故障模式，可维修零件，和它们之中的相关性。测试程序和修理指令也被解析以创造故障树并且识别额外的症状和故障模式。可达性分析然后被用于发现故障树中的隐藏的依赖性，由此在故障和症状之中产生额外的相关性。产生的症状，故障模式，可维修零件，和相关性然后被汇编到故障模型中，其能够用于车辆车载的实时故障诊断，或者用于维修车间处的车外诊断。

根据下面结合附图的描述和所附权利要求，本发明的另外的特征将变得明显。

本发明还提供了以下方案：

1. 一种用于为硬件或软件系统产生故障模型的方法，所述方法包括：

提供结构化的文本文档，其包含关于硬件或软件系统的诊断信息；

从所述结构化的文本文档提取故障模型数据；

解析所述结构化的文本文档中包含的测试程序和修理指令，以产生故障树和获得额外的故障模型数据；

在所述故障树上执行可达性分析以识别跨功能依赖性；以及

由所述故障模型数据和所述跨功能依赖性汇编故障模型。

2. 如方案1所述的方法，其特征在于，提取故障模型数据包括使用诊断规则来从所述结构化的文本文档中包含的诊断故障信息和扫描工具表提取故障模型数据。

3. 如方案1所述的方法，其特征在于，解析测试程序和修理指令包括识别第一症状的测试，和识别可从测试推论的故障模式和第二症状。

4. 如方案1所述的方法，其特征在于，在所述故障树上执行可达性分析包括确定在所述故障树中哪里故障模式跨功能地依赖于多于一个症状。

5. 如方案1所述的方法，其特征在于，所述故障模型数据包括症状，故障模式，和相关性值。

6. 如方案5所述的方法，其特征在于，症状包括诊断故障代码（DTC）症状和非DTC症状。

7. 如方案5所述的方法，其特征在于，汇编故障模型包括产生故障模式的行，产生症状的列，和将相关性值放置在行和列的交叉点中。

8. 如方案7所述的方法，其特征在于，其进一步包括使用跨功能依赖性来限定故障模型中的额外的相关性值。

9. 如方案1所述的方法，其特征在于，硬件或软件系统是车辆或车辆子系统。

10. 如方案9所述的方法，其特征在于，结构化的文本文档是车辆或车辆子系统的维修程序文档。

11. 一种用于为车辆或车辆子系统产生故障模型的方法，所述方法包括：

提供维修程序文档，其包含关于车辆或车辆子系统的诊断信息；

使用诊断规则来从维修程序文档中包含的诊断故障信息和扫描工具表提取故障模型数据；

解析所述维修程序文档中包含的测试程序和修理指令，以产生故障树和获得额外的故障模型数据；

在所述故障树上执行可达性分析以识别跨功能依赖性，其中所述可达性分析包括确定在所述故障树中哪里故障模式跨功能地依赖于多于一个症状；以及

由所述故障模型数据和所述跨功能依赖性汇编故障模型。

12. 如方案11所述的方法，其特征在于，所述故障模型数据包括症状，故障模式，和相关性值。

13. 如方案12所述的方法，其特征在于，汇编故障模型包括产生故障模式的行，产生症状的列，和将相关性值放置在行和列的交叉点中。

14. 如方案11所述的方法，其特征在于，其进一步包括结合车辆或车辆子系统为故障诊断使用故障模型。

15. 一种用于产生故障模型的系统，所述系统包括：

提供结构化的文本文档的装置，所述结构化的文本文档包含关于硬件或软件系统的诊断信息；

从所述结构化的文本文档提取故障模型数据的装置；

解析所述结构化的文本文档中包含的测试程序和修理指令，以产生故障树和获得额外的故障模型数据的装置；

在所述故障树上执行可达性分析以识别跨功能依赖性的装置；以及

由所述故障模型数据和所述跨功能依赖性汇编故障模型的装置。

16. 如方案15所述的系统，其特征在于，提取故障模型数据的装置使用诊断规则来从所述结构化的文本文档中包含的诊断故障信息和扫描工具表提取故障模型数据。

17. 如方案15所述的系统，其特征在于，解析测试程序和修理指令的装置识别第一症状的测试，和识别可从测试推论的故障模式和第二症状。

18. 如方案15所述的系统，其特征在于，执行可达性分析的装置确定在所述故障树中哪里故障模式跨功能地依赖于多于一个症状。

19. 如方案15所述的系统，其特征在于，汇编故障模型的装置产生故障模式的行，产生症状的列，和将相关性值放置在行和列的交叉点中。

20. 如方案15所述的系统，其特征在于，结构化的文本文档是维修程序文档，硬件或软件系统是车辆或车辆子系统。

附图说明

图1是系统的示意图，所述系统采取结构化的文本文档，使用适当的过程自动地解析它们以产生故障模型，并且在车载和车外系统中使用产生的故障模型；

图2是方法的流程图，其能够由结构化的文本文档（例如维修程序）开发故障模型；以及

图3是图示，其示出了由维修程序文档创造的诊断树如何能够用于经由可达性分析在故障模型中发现隐藏的依赖性。

具体实施方式

下面的针对本发明涉及用于由结构化的文本文档开发故障模型的方法和系统的实施例的讨论本质上仅是示例性的，且决不意在限制本发明或其应用或使用。例如，本发明具有用于车辆故障诊断的特定应用。然而，本发明同样可应用于其他产业上的故障诊断，诸如航空航天和重型设备，以及可应用于使用故障模型的任何机械、电气或机电系统中的故障诊断。

故障模型早已为车辆和其他系统的制造商所用，以记录和理解故障模式，可维修零件和相关症状之间的相关性。作为故障模型基础的故障模式，部分，和症状数据能够在包括文本文档的各种文档中发现。但是因为文本文档会是困难且耗时地检查故障模型内容，很多类型的文本文档传统上已经不用于为特点车辆或系统开发故障模型，并且由此制造商还没有获得文本文档中包含的所有数据的益处。本发明通过提出用于由结构化的文本文档自动地开发故障模型的方法和系统来提供一种此问题的解决方案。以此方式开发的故障模型能够直接用作故障诊断工具，或者其能够用作高保真度工程设计故障模型的快速开发的基准。

图1是系统10的示意图，其采取结构化的文本文档输入，应用文本处理规则，解析技术和其他类型的分析来创造故障模型，并且使用产生的故障模型用于车辆车载和车外的诊断目的。系统10被示出为使用维修程序文档12作为输入。其他类型的结构化的文本文档也可被使用，但是文档12的讨论将足以解释故障模型开发中包含的概念。维修程序文档12与很多其他类型的维修程序一起可包括诊断故障信息表，电路和系统测试程序，扫描工具表，和修理指令。

结构化的文本解析模块18能够如下所述地接收维修程序文档12并且执行若干解析和分析步骤，从而产生故障模型22。故障模型22包含文档12中所述的故障模式和症状的代表。作为数字数据库，故障模型22能够被加载到车辆24的车载处理器用于实时系统监控，或者在维修设施处的诊断工具26中使用。以数据库的形式，故障模型22还能够在远程诊断中心处使用以用于实时检修车辆问题。例如，车辆症状数据和顾客抱怨可以经由远程信息处理系统发送到远程诊断中心，其中诊断推理机可以使用故障模型22做出诊断。然后客户顾问可以最适合的动作步骤建议车辆24的驾驶员。作为可打印文档，故障模型22能够由维修车辆的技术人员读取，或者由车辆开发人员28使用以创造改进的维修程序文档和新的车辆和系统设计。

故障模型22的简化表示是二维矩阵，该矩阵包含故障模式作为行，症状作为列，每行与列的交叉是相关值。零件识别数据通常包含在故障模式中。行与列的交叉点包含的相关值通常被称为因果关系权重。在最简单的情况下，所有因果关系权重都具有值0或1，其中，0指示特定故障模式与特定症状之间无相关性，1指示特定故障模式与特定症状之间直接相关。然而，也可以使用0与1之间的因果关系权重值，并且指示特定故障模式与特定症状之间的相关性的强度等级。0和1的因果关系权重值通常被称为硬因果关系或相关性，而0和1之间的因果关系权重值被描述为软。在多于一个的故障模式与一个或一组特定症状相关联的情况下，这被称为模糊组。

在更完整的形式中，故障模型22可以包括附加矩阵维度，该维度包含诸如信号和操作的信息，当这些与故障模式和症状相关时。然而，为了清楚，将按照二维矩阵维度（即故障模式和症状）以适当地包括的可维修零件信息描述基于文本文档的故障模型开发方法。

图2是方法的流程图30，其能够用于结构化的文本解析模块18以从维修程序文档12产生故障模型22。在框32，维修程序文档12被提供，并且关于文档源的信息被记录。例如，维修程序文档12的一个实例的主题可能是特定发动机，而维修程序文档12的另一实例可能以前悬架处理。维修程序文档12必须是机器可读文档，如标准通用置标语言（SGML）或可扩展置标源码（XML）文档。

在框34，一组诊断规则用于从维修程序文档12中包含的诊断故障信息提取故障模型数据。维修程序文档12将通常包含表形式的诊断故障信息，其显示在捕获特定诊断故障代码时会存在什么条件。当参数或参数组合被检测超出其正常范围时，诊断故障代码（DTC）是由车辆车载的控制器捕获的故障代码。例如，维修程序文档12中的诊断故障信息表可包括行，其包含不同电路，如压力传感器信号线和压力传感器5伏基准线。相同诊断故障信息表可包括列，其包含电路的不同故障模式，如短路到地和开路。行和列的组合代表完整故障模式，如压力传感器信号线短路到地。在行和列的交叉点是一个或多个DTC，如果适合的话，其代表与故障模式相关联的一个或多个症状。行和列的交叉点也可包含非DTC症状的描述，如下面将要讨论的。因此，基于维修程序文档12中包含的诊断故障信息，在故障模式和一个或多个症状之间描绘相关性。在框34使用的诊断规则可能是相对简单的，例如，显示，1的因果关系权重在症状关联到故障模式处被指定。更复杂的诊断规则也可被限定，如处理多于一个DTC症状在行和列的交叉点中存在的情况。为了诊断故障信息表明相关性的症状和故障模式的所有组合，此故障模型提取在框34完成。如果该数据在结构化的表中可用，如上述诊断故障信息表，在框34处应用的诊断规则也可被用来捕获机械故障和症状。机械故障模式的例子是“反常的制动器转子”，和相关联的症状是“制动过程中的震动”。虽然机械故障往往不触发DTC症状，故障和非DTC症状可包含在结构化的表中，并且因此可被捕获以在框34处由诊断规则用于故障模型22。

在框36，一组诊断规则用于从在维修程序文档12中典型地包含的扫描工具表提取故障模型数据。扫描工具数据表可包含类似的行和列以诊断上述故障信息表，如行包括压力传感器信号线和压力传感器5伏基准线，和列包括短路到地和开路。因此，故障模式可以行和列的组合代表，如压力传感器信号线短路到地。在扫描工具数据表的情况下，在行和列的交叉点驻留的症状不是DTC，而是扫描工具值。例如，对于压力传感器信号线短路到地，扫描工具值为0伏。因此，基于维修程序文档12中包含的扫描工具数据表，在故障模式和症状之间描绘相关性。为了扫描工具数据表明相关性的症状和故障模式的所有组合，此故障模型提取在框36完成。

在框38，电路和系统测试程序被解析以获得故障模型数据。维修程序文档12将通常包括电路和系统测试程序，其设计用于辅助诊断问题中的维修技术人员。例如，在燃料箱压力读数不准确的情况下，电路和系统测试程序能够被用来确定燃料箱压力传感器本身是否有问题，接线电路是否有问题，处理传感器信号的发动机控制模块是否有问题，或其某些组合是否有问题。在框38被解析的电路和系统测试程序将通常描述为了诊断问题所遵循的步骤顺序。显示电路和系统测试程序如何能够被解析以提取症状和故障模式的例子在下文讨论。总之，解析逻辑被限定如下：

在测试程序中搜索动词，如“测试”或“测量”。

识别紧随动词的电路或系统，以确定什么电路或系统被测试，和什么条件被测试；这限定了症状。

寻找症状之后的条件陈述和动作，如“如果测量如此，则这样做”；

如果动作是更换部件，这代表与症状相关联的故障模式。

如果动作是测试一些其他东西，这代表另一症状被测试。

使用上述解析技术，在框38症状和故障模式能够可靠地从电路和系统测试程序提取。维修程序文档12可还包括修理指令，其可以如上所述的用于电路和系统测试程序的相同方式解析，以产生一组症状和故障模式。测试程序或修理指令中包含的测试步骤顺序和成果还产生诊断树，其连接一组症状和故障模式，如下面讨论。在框40，可达性分析被执行以学习诊断树中隐藏或跨功能依赖性，其在框38被捕获。

图3是视图，其显示了诊断树50如何能够从电路和系统测试程序或修理指令构建，和诊断树50中的数据如何能够被用来使用可达性分析来填充故障模型70。如前所述，维修程序文档12可包括电路和系统测试程序和/或修理指令，其中框38被解析以获得故障模型内容。测试程序或修理指令通常包括步骤顺序，如下：

a）测量触点A和触点B之间的电压。

b）如果电压小于X，则更换部件123。

c）如果电压大于或等于X，则测量触点C和触点D之间的电压。

上述步骤顺序a）—c），加上来自维修程序文档12的额外步骤，能够作为诊断树50描绘，其包含症状52，54和56，和故障模式62，64，66和68。在诊断树50中，每个症状52-56导致其他症状，或导致故障模式。例如，从上述步骤a）和b），症状52可被写为“触点A和触点B之间的电压小于X”。如果这种陈述为真，那么故障模式62，部件123故障，能够被诊断。然而，如果描述症状52的陈述为假，那么诊断树50导致其他症状，如上述陈述c）中描述的。这样，诊断树50能够从维修程序文档12中包含的测试程序或修理指令构建。

故障模型70，这可为故障模型22的子集，能够从诊断树50构建，诊断树50具有作为列的症状52-56和作为行的故障模式62-68，如所示的。接下来的步骤是行—列交叉点的每个中填充相关性或因果关系权重。常见的实践是使用来自诊断树的数据，以识别故障模型相关性，这对于直接依赖性是已知的，其中症状的确认直接导致故障模式。在诊断树50中，症状52具有与故障模式62的直接依赖关系。对于症状54和故障模式64是同样的。症状56具有与故障模式66和68的直接依赖关系。这些直接依赖关系显示为具有故障模型70中的1的因果关系权重值。

然而，除了上述直接依赖关系，在诊断树50中包含额外的数据。隐藏或跨功能的依赖关系也可能存在，和可被称为通过已知的可达性分析识别。使用可达性分析，识别跨功能的依赖性，例如，在症状52和故障模式64，66和68之间。能够看出，故障模式64-68的每个依赖于多于仅存在或不存在症状52。例如，故障模式64还依赖于存在或不存在症状54。症状54和故障模式66和68之间存在类似的情况。因为这些依赖性的直接或跨功能性质，小于1的因果关系权重可被指定。

故障模型70包含因果关系权重72，74，76，78和80，其中因果关系权重72-80的每个代表跨功能依赖性，并且驻留在故障模式行和症状列的交点。如前所述，因果关系权重72-80的每个是0和1之间的值，指定特定故障模式和特定症状之间的相关性的程度。跨功能依赖性的因果关系权重可以基于多少水平的某些故障模式从某些症状去除而指定。例如，因果关系权重72可以为0.5的分配值，因为故障模式64是从症状52去除的一个水平。同样，因果关系权重74和76可以为0.25的分配值，因为故障模式66和68是从症状52去除的两个水平。这些因果关系权重指定例子仅为说明性的；其他客观标准，或主题专家，可以用于指定因果关系权重到跨攻能依赖性，其经由可达性分析显示。故障模型70中所有的其他交叉点或依赖性（其不由因果关系权重72-80之一填充）具有意味着没有相关性的0因果关系权重，或意味着直接相关性的1因果关系权重。在框40执行的可达性分析将通常不添加新的故障模式行或症状列到故障模型22，而是将以额外的非0因果关系权重填充现有的行和列。

在流程图30的框42中，故障模型22被组装和提供为结构化的文本解析模块18的输出，包含故障模式，症状，和在框34由诊断故障信息识别的相关性，在框36的扫描工具数据，在框38的电路和系统测试程序，和在框40的可达性分析。故障模型22然后能够用于多种用途，如前所述的车辆24车载的和车外的。故障模型22也能够用于高保真工程设计故障模型的快速开发的基准。

为了更完整地描述故障模型开发方法，将详细地讨论例子。例子将显示故障模型内容如何使用图2的方法被提取。在这个例子中，与车载远程信息处理系统的部分相关的维修程序信息被分析。具体地，认为是远程信息处理控制模块与麦克风的相互作用。

远程信息处理控制模块为麦克风提供信号电路上供给的电压。远程信息处理控制模块为漏极电路上的麦克风提供接地。如果信号电路，漏极电路，远程信息处理控制模块，或麦克风中有任何故障，则指定为DTC B2455的诊断故障代码被触发。DTC B2455具有多义性的7组故障模式，如下：

1、信号电路对地短路或开路。

2、信号电路对电压短路。

3、远程信息处理控制模块信号电路连接器故障。

4、远程信息处理控制模块漏极电路连接器故障。

5、漏极电路开路。

6、漏极电路对电压短路。

7、麦克风故障。

多义性组代表三种不同的可维修零件——即，远程信息处理控制模块信号电路连接器，远程信息处理控制模块漏极电路连接器，和麦克风——除了7种故障模式以外。

表1包含与上述远程信息处理系统麦克风电路相关的诊断故障信息，将在维修程序文档12中找到。

表1

。

能够在表1中看到，如果麦克风信号电路对地短路或对电压短路，或开路时，DTC B2455将被触发。如果麦克风漏极电路是开路的，DTC B2455也将被触发。由于麦克风漏极电路代表地，没有与短路漏极电路的地相关联的故障。最后，漏极电路短路到电压的情况并非以DTC为特征，而是诊断故障信息表包含标记，该标记指示在这种情况下将显示什么症状。在这个例子中，标记1描述没有DTC症状作为“麦克风不工作-无法听到呼叫”。如先前关于流程图30的框34所述的，故障模型22能够通过首先结合电路名与电路故障类型而填入以产生故障模式，如“麦克风信号短路到地。”然后，对于DTC症状和非DTC症状，相关性能够基于诊断故障信息表中的数据建立。例如，无论什么地方为特点故障模式存在症状，1的因果关系权重可以被分配。

继续上面的例子，额外的故障模型数据能够从维修程序文档12中的电路和系统测试程序被提取。由于与DTC B2455相关联的多义性组，来自电路和系统测试程序的额外故障模型数据将有助于正确诊断问题。涉及DTC B2455的电路和系统测试程序的例子如下：

1、点火关闭（OFF），断开麦克风处线束连接器。

2、点火关闭（OFF）和扫描工具断开，等待直到所有保留的辅助电源为OFF，测试漏极电路连接器和地之间小于10欧姆，允许直到5分钟电路电阻下降到其最低读数。

如果大于指定范围，测试开路/高电阻的电路。

3、点火打开（ON），测试信号电路连接器和地之间的9.5-10.5V。

如果小于指定范围，测试短路到地或开路/高电阻的电路。如果电路测试正常，更换远程信息处理控制模块。

如果大于指定范围，测试短路到地的电路。如果电路测试正常，更换远程信息处理控制模块。

4、如果所有电路测试正常，更换麦克风。

电路和系统测试程序，如上面列出的那些，能够使用以下规则被解析：

1、在测试步骤中搜索词语“测试”，“测试所述”，或“观察”。采取具有这些词语的整个句子并且保存它作为技术人员测试。

2、如果具有以箭头特征“”开始的句子，那么认为第二水平测试和故障，其依赖于前面的测试。可达性分析能够被用来关联第二水平测试与第一水平故障模式。

3、搜索“更换”以构建故障模式和可维修零件。

4、如果具有以箭头特征“”开始的一个开头的多个句子，那么其指示具有该故障模式的多个模式。

5、通过将开头数与测试和故障模式信息一起存储保存测试顺序。

除了诊断故障信息和电路和系统测试程序，也可能解析DTC设置条件和运行条件，以学习故障模型中的负相关性；即不以其他特定DTC设置的DTC。修理指令也被解析以学习电路和系统测试程序中未提及的可维修零件。

由于上述的所有解析和分析，开发了一部分故障模型22，涉及远程信息处理系统的麦克风电路，如下面表2所示：

表2

其中症状S1-S6是：

·S1=DTC B2455

·S2=“2.0 - 测试远程信息处理模块漏极电路连接器和地之间小于10欧姆 - B2455”

·S3=“2.1 - 测试开路/高电阻的电路 - B2455”

·S4=“3.0 - 测试远程信息处理模块漏极电路连接器和地之间的9.5-10.5伏 - B2455”

·S5=“3.1 - 测试短路到地或开路/高电阻的电路 - B2455”

·S6=“3.2 - 测试短路到电压的电路 - B2455”

并且故障模式FM1-FM7是：

·FM1=“麦克风漏极开路”

·FM2=“麦克风漏极电路短路到电压”

·FM3=“麦克风故障”

·FM4=“麦克风信号电路对地短路或开路”

·FM5=“麦克风信号电路短路到电压”

·FM6=“远程信息处理控制模块信号电路连接器故障”

·FM7=“远程信息处理控制模块漏极电路连接器故障”。

在值1在表2的行—列交叉点示出的情况下，这表明特定症状和特定故障模式之间的直接相关性。在交叉点中没有示出值的情况下，表面没有相关性。如前所述，可达性分析可以被执行以发现跨功能或间接相关性，这可能导致软相关性，或0和1之间的因果关系权重。

还可能会发生常见故障。例如，远程信息处理控制模块可以在地和电源电路中呈现常见故障。这种故障将触发与远程信息处理控制模块相关联的多个DTC——包括DTC B2455，其涉及麦克风电路，以及其他。这些常见故障常常包括在维修程序文档12中，并且能够在前述框34由诊断规则捕获。在这种情况下，故障模型22将包括常见故障的故障模式行，并且相关性将为每个可应用子系统DTC症状而建立。

来自结构化的文本文档（如维修程序文档12）的故障模型开发能够成为有价值的工具，能够迅速且完全地捕获包含在这种文档中的丰富的故障模型信息。使用如上所述的技术，结构化的文本文档能够被解析和分析以产生故障模型22。然后故障模型22能够被用来例如执行车辆24中的车载计算机的实时故障诊断，从而使用工具26或在远程诊断中心处执行车外故障诊断，或由车辆开发人员28使用以更新维修文档或设计未来的车辆、系统或部件。

很多益处能够自动从文本文档开发故障模型。一个明显的益处能够可靠地以最小量的人力劳动从文本文档产生高保真故障模型。车辆的故障模型或复杂的子系统常常包含成千上万的症状和成千上万的故障模式。产生这些庞大文档的自动过程产生非常大的人力节省。而且，通过限制检查和处理少量边缘项目的人的参与，人为错误或疏忽的机会大大减少。能够从文本文档开发故障模型22的另一益处能够捕获有价值的遗留维修数据，其将很可能不用于故障模型开发。这能够做到，因为一旦诊断规则如上所述被开发，在应用故障模型开发方法到额外的文档涉及很少更大效果，包括包含技术维修公告，和历史或遗留维修信息的文档。

最后，本文所述方法使其能够发现和存档隐藏或忽视的相关性，因此提高产生的故障模型数据的质量。故障模型22是强大的文档，其能够使车辆制造商提高客户满意度，降低保修成本，和提高未来产品设计。故障模型22还能够用作高保真工程设计故障模型的快速开发的基准。

上述讨论仅公开了和描述了本发明的示例性实施例。本领域的技术人员将容易认识到，根据此讨论、附图以及权利要求，在不脱离所附权利要求中限定的本发明的精神和范围的情况下，在此可以进行各种改变、修改和变型。

Claims

1.一种用于为车辆或车辆子系统产生故障模型的方法，所述方法包括：

提供结构化的文本文档，其包含关于车辆或车辆子系统的诊断信息；

从所述结构化的文本文档提取故障模型数据；

在所述故障树上执行可达性分析以识别跨功能依赖性；以及

由所述故障模型数据和所述跨功能依赖性汇编故障模型,

其中，所述结构化的文本文档是车辆或车辆子系统的维修程序文档；以及

汇编故障模型包括产生故障模式的行，产生症状的列，和将相关性值放置在行和列的交叉点中。

2.如权利要求1所述的方法，其特征在于，提取故障模型数据包括使用诊断规则来从所述结构化的文本文档中包含的诊断故障信息和扫描工具表提取故障模型数据。

3.如权利要求1所述的方法，其特征在于，解析测试程序和修理指令包括识别第一症状的测试，和识别可从测试推论的故障模式和第二症状。

4.如权利要求1所述的方法，其特征在于，在所述故障树上执行可达性分析包括确定在所述故障树中哪里故障模式跨功能地依赖于多于一个症状。

5.如权利要求1所述的方法，其特征在于，所述故障模型数据包括症状，故障模式，和相关性值。

6.如权利要求5所述的方法，其特征在于，症状包括诊断故障代码症状和非诊断故障代码症状。

7.如权利要求1所述的方法，其特征在于，其进一步包括使用跨功能依赖性来限定故障模型中的额外的相关性值。

8.一种用于为车辆或车辆子系统产生故障模型的方法，所述方法包括：

由所述故障模型数据和所述跨功能依赖性汇编故障模型，

其中，汇编故障模型包括产生故障模式的行，产生症状的列，和将相关性值放置在行和列的交叉点中。

9.如权利要求8所述的方法，其特征在于，所述故障模型数据包括症状，故障模式，和相关性值。

10.如权利要求8所述的方法，其特征在于，其进一步包括结合车辆或车辆子系统为故障诊断使用故障模型。

11.一种用于产生故障模型的系统，所述系统包括：

从所述结构化的文本文档提取故障模型数据的装置；

由所述故障模型数据和所述跨功能依赖性汇编故障模型的装置，

其中，汇编故障模型的装置产生故障模式的行，产生症状的列，和将相关性值放置在行和列的交叉点中；以及

所述结构化的文本文档是维修程序文档，硬件或软件系统是车辆或车辆子系统。

12.如权利要求11所述的系统，其特征在于，提取故障模型数据的装置使用诊断规则来从所述结构化的文本文档中包含的诊断故障信息和扫描工具表提取故障模型数据。

13.如权利要求11所述的系统，其特征在于，解析测试程序和修理指令的装置识别第一症状的测试，和识别可从测试推论的故障模式和第二症状。

14.如权利要求11所述的系统，其特征在于，执行可达性分析的装置确定在所述故障树中哪里故障模式跨功能地依赖于多于一个症状。