首页> 中国专利> 使用诊断故障代码马尔可夫链的故障诊断和预测

使用诊断故障代码马尔可夫链的故障诊断和预测

摘要

本发明涉及使用诊断故障代码马尔可夫链的故障诊断和预测。具体地,用于故障诊断的系统和方法包括接收限定了事故模式和诊断故障代码之间的关系的信息,以及提取诊断故障代码数据,包括与多个事故模式有关的多个诊断故障代码的设定时间、频率数据和诊断故障代码序列信息。所述系统和方法还包括使用多个事故模式的每个的诊断故障代码数据构造马尔可夫链、使用所述诊断故障代码数据训练所述马尔可夫链以学习一组状态参数、以及使用训练的马尔可夫链计算多个事故模式的每个的诊断故障代码序列的可能性。

著录项

  • 公开/公告号CN102073318A

    专利类型发明专利

  • 公开/公告日2011-05-25

    原文格式PDF

  • 申请/专利权人 通用汽车环球科技运作公司;

    申请/专利号CN201010554574.5

  • 发明设计人 S·辛赫;V·R·哈列;R·舒古尔;

    申请日2010-11-17

  • 分类号G05B23/02(20060101);

  • 代理机构72001 中国专利代理(香港)有限公司;

  • 代理人崔幼平;杨楷

  • 地址 美国密执安州

  • 入库时间 2023-12-18 02:39:01

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2013-06-12

    授权

    授权

  • 2011-07-13

    实质审查的生效 IPC(主分类):G05B23/02 申请日:20101117

    实质审查的生效

  • 2011-05-25

    公开

    公开

说明书

技术领域

本发明总体涉及故障诊断和预测系统,更具体地,涉及使用时间标记诊断故障代码(或故障代码)和马尔可夫链的故障诊断和预测的改进方法。 

背景技术

在汽车工业中不断努力来通过将故障诊断和预测特征结合到车辆中以改进车辆的质量和可靠性。传统地,由技术人员将扫描工具或其他诊断工具(例如,TECH IITM,MDITM)连接到车辆的电子控制单元(ECU)而进行故障诊断。一旦连接,诊断故障代码(DTC)从ECU提取并用于确定是什么导致了事故。在一些情况下,单独的DTC不足以精确地确定问题的根本原因,因为一个DTC或DTC的组合可能是多种事故模式的症状。另外,在没有关于什么时间每个DTC发生的任何信息的情况下,难以确认故障的真实原因。 

近年来,车辆故障诊断已经利用车载诊断的实施而改进,该车载诊断配置成自动访问车辆DTC以给车辆操作者或技术人员提供诊断信息而不必从外部连接到ECU。然而,现有技术不能够区分具有相同DTC特征的两种事故模式,因为它们不是以系统的方式利用DTC点火时间信息。 

因此,需要系统和方法配置成:1)以统计方法利用DTC的设定时间和频率,其能够诊断和隔离事故模式,尤其是不明确的事故模式(即,具有共同DTC特征样式的事故模式);2)还通过为何时系统不具有任何DTC建模来诊断间歇故障;和3)利用事故模式的可接受的置信限度来预测到接下来事故状态的剩余时间(RTFS)。 

发明内容

根据本发明的教导,用于故障诊断的系统和方法包括接收限定了事故模式和诊断故障代码之间的关系的信息,以及提取诊断故障代码数据,包括与多个事故模式有关的多个诊断故障代码的设定时间、频 率数据和诊断故障代码序列信息。所述系统和方法还包括使用多个事故模式的每个的诊断故障代码数据构造马尔可夫链、使用所述诊断故障代码数据训练所述马尔可夫链以学习一组状态参数、以及使用训练的马尔可夫链计算多个事故模式的每个的诊断故障代码序列的可能性。 

结合附图从下列描述和所附权利要求中,本发明额外特征将变得明显。 

本发明还提供如下方案: 

方案1.一种故障诊断和预测系统,其包括: 

多个电子控制单元,其中所述多个电子控制单元中的至少一个配置成: 

接收限定了事故模式和诊断故障代码之间的关系的信息; 

提取与具体事故模式有关的多个诊断故障代码的诊断故障代码数据; 

使用所述具体事故模式的诊断故障代码数据构造马尔可夫链; 

使用所述诊断故障代码数据训练所述马尔可夫链以学习一组状态参数; 

使用经训练的马尔可夫链计算所述具体事故模式的诊断故障代码序列的可能性;以及 

使用所述经训练的马尔可夫链预测趋势。 

方案2.如方案1所述的系统,其特征在于,所述诊断故障代码数据包括设定时间、频率数据和诊断故障代码序列信息。 

方案3.如方案1所述的系统,其特征在于,所述诊断故障代码数据从现场事故数据和历史数据提取。 

方案4.如方案1所述的系统,其特征在于,所述具体事故模式从包含多个事故模式的不确定组中选择。 

方案5.如方案4所述的系统,其特征在于,为不确定组中的多个事故模式的每个构造马尔可夫链。 

方案6.如方案5所述的系统,其特征在于,为不确定组中的多个事故模式的每个计算诊断故障代码序列的可能性。 

方案7.如方案6所述的系统,其特征在于,以最可能故障的顺序对多个事故模式的每个的可能性排序。 

方案8.如方案1所述的系统,其特征在于,还包括使用经训练的马尔可夫链预测到接下来事故状态的剩余时间。 

方案9.如方案1所述的系统,其特征在于,一组状态参数包括所述马尔可夫链的每个状态的初始和转移概率。 

方案10.如方案1所述的系统,其特征在于,所述多个电子控制单元的至少一个为中央诊断电子控制单元。 

方案11.如方案1所述的系统,其特征在于,限定了事故模式和诊断故障代码之间的关系的信息为诊断矩阵的形式。 

方案12.如方案1所述的系统,其特征在于,所述诊断故障代码的每个代表所述马尔可夫链的状态。 

方案13.如方案12所述的系统,其特征在于,所述马尔可夫链构造成包括无诊断故障代码状态以诊断间歇事故。 

方案14.一种故障诊断的方法,其包括: 

接收限定了事故模式和诊断故障代码之间的关系的信息; 

提取诊断故障代码数据,包括与多个事故模式有关的多个诊断故障代码的设定时间、频率数据和诊断故障代码序列信息; 

使用多个事故模式的每个的诊断故障代码数据构造马尔可夫链; 

使用所述诊断故障代码数据训练所述马尔可夫链以学习一组状态参数; 

使用经训练的马尔可夫链计算多个事故模式的每个的诊断故障代码序列的可能性。 

方案15.如方案14所述的方法,其特征在于,还包括使用所述经训练的马尔可夫链在给定范围上预测趋势。 

方案16.如方案14所述的方法,其特征在于,还包括通过以最可能故障的顺序对多个事故模式的每个的可能性排序来确定故障诊断。 

方案17.如方案16所述的方法,其特征在于,还包括将所述故障诊断通信至线上通信系统。 

方案18.如方案16所述的方法,其特征在于,还包括将所述故障诊断通信至离线通信系统。 

方案19.一种有形地具体化计算机可执行指令的计算机可读介质,其用于: 

接收限定了事故模式和诊断故障代码之间的关系的诊断矩阵; 

提取诊断故障代码数据,包括与多个事故模式有关的多个诊断故障代码的设定时间、频率数据和诊断故障代码序列信息; 

使用多个事故模式的每个的诊断故障代码数据构造马尔可夫链,其中所述诊断故障代码的每个代表所述马尔可夫链的状态; 

使用所述诊断故障代码数据训练所述马尔可夫链以学习一组状态参数,其中所述一组状态参数包括所述马尔可夫链的每个状态的初始和转移概率; 

使用训练的马尔可夫链计算多个事故模式的每个的诊断故障代码序列的可能性。 

通过以最可能故障的顺序对多个事故模式的每个的可能性排序来确定故障诊断;以及 

使用训练的马尔可夫链预测到接下来事故状态的剩余时间。 

方案20.如方案19所述的系统,其特征在于,所述马尔可夫链构造成包括无诊断故障代码状态以诊断间歇事故。 

附图说明

图1示出根据一个实施例的示例性故障诊断和预测系统; 

图2示出示例性诊断矩阵; 

图3是示出故障诊断和预测算法的示例性数据采集和训练阶段的流程图; 

图4示出示例性DTC序列; 

图5a和5b示出具体事故模式的示例性DTC马尔可夫链;以及 

图6是示出故障诊断和预测算法的示例性测试阶段的流程图。 

图7是以动态规划预测到接下来事故状态的剩余时间的视图。 

具体实施方式

本发明实施例的下列讨论涉及使用时间标记诊断故障代码(DTC)和马尔可夫链的故障诊断和预测且本质上仅为示例性的,并且绝不用于限制本发明或者其应用或使用。 

图1示出示例性故障诊断和预测系统10,其具有与中央诊断ECU14通信的多个电子控制单元(ECU)12。每个ECU 12配置成从车辆(未示出)内的各个传感器和部件接收诊断故障代码(DTC)。DTC 实质上为故障(事故)代码,其指示车辆运行参数或参数组已经超过预定阈值或者与DTC相关联的某些诊断测试已经失效。在一些实施例中,DTC还可被称作为症状。由ECU 12接收到的DTC通常存储在位于每个ECU 12内的ECU存储器模块16中。在本实施例中,每个ECU 12配置成将DTC传送至中央诊断ECU 14,其包括用于确定和预测事故模式的算法20。 

在一个实施例中,诊断ECU 14配置成与车载灵活计算平台22例如OnStarTM直接通信。另外,或替代地,系统可配置成与离线通信平台通信,其中诊断ECU 14连接到外部界面,例如Tech IITM或多诊断界面(MDITM)。本领域技术人员理解由图1示出的系统仅为示例性的并且其他系统配置可等同地应用到此处包含的诊断和预测系统和方法。例如,替代系统可配置成使得没有中央诊断ECU 14。代替地,每个ECU 12可包括算法20并各自地相互通信,和/或与线上/离线通信平台22通信。 

算法20能够以两个阶段来表达:数据采集和训练阶段,以及测试阶段。在数据采集和训练阶段中,算法20收集数据并使用数据收集体构造马尔可夫链。数据收集体包括但不限于现场事故数据和历史数据,其包括每个DTC的设定时间(即,触发DTC的时间)、频率、以及DTC序列信息。通过了解每个DTC发生的时间和发生频率,算法20能够确定每个马尔可夫链状态的参数,例如初始概率和转移概率。每个状态的初始概率指示关于该状态在开始(即t=0)时的现有知识。这些概率可使用历史现场事故数据或从领域知识获得。使用此处公开的途径,“无DTC”状态的初始概率将在其他所有状态中最高。转移概率指示从一个状态移动到另一个状态的概率。DTC马尔可夫链的完整描述将在下面讨论。 

数据收集体还可包括与事故模式和每个DTC之间的关系相关的信息。该关系经常使用能够由中央诊断ECU 14、单个ECU 12中任一个、或由任何其他计算装置生成和存储的表或矩阵来表达。图2中示出示例性诊断矩阵24,其示出事故模式(FM)1-12和DTC 1-13之间的关系。事故模式能够具有一个或多个重叠DTC,或者它们可具有共同DTC特征样式,其中DTC对于多于一个事故模式是相同的。例如,图2的诊断矩阵24显示事故模式1和2(分别为FM1和FM2) 具有相同的DTC特征样式,即,DTC1和DTC2。当DTC具有相同的特征样式时,它们被认为是不确定组的一部分,因为事故模式仅根据其DTC样式不可区分。 

图3是示出算法20的示例性数据采集和训练阶段30的流程图。在步骤32,诊断矩阵24被输入到实施算法20的计算装置,其在本例中为中央诊断ECU 14。算法20仅考虑是不确定组的一部分的事故模式。在步骤34,与具体事故模式有关的设定时间、频率和DTC序列信息从现场事故和历史数据中提取。图4中示出示例性DTC序列。在步骤36,通过将“无DTC”和“DTC”作为马尔可夫链的状态为具体事故模式构造DTC马尔可夫链。“无DTC”状态代表没有误差条件或DTC发生之间的时间流逝,并且使得能够确定间歇事故。在步骤38,算法20使用DTC设定时间和频率数据训练马尔可夫链以学习状态参数,即,初始概率和转移概率。在步骤40为每个事故模式构造DTC马尔可夫链并将其存储在中央诊断ECU 14的存储器18中。 

图5a示出具有四个状态:DTC1、DTC2、DTC3和无DTC的具体事故模式的示例性DTC马尔可夫链42。对于每个DTC状态,tN代表DTC设定时间,nN代表DTC频率。为每个状态生成的转移概率是DTC设定时间tN和频率nN的函数。图5b示出示例性DTC马尔可夫链43的另一个例子,其中0.98和0.7代表自转移概率,0.02和0.3代表到其他状态的转移概率。 

图6是示出算法20的示例性测试阶段44的流程图。在步骤46,测试数据的DTC序列被输入到中央诊断ECU 14。在步骤48,使用存储的马尔可夫链计算所有事故模式的DTC序列的可能性。在步骤50,通过以最可能故障的顺序对每个事故模式的可能性排序来执行故障诊断。在步骤52,对于每个马尔可夫链在给定预测范围上预测趋势。使用一种途径,使用Viterbi(维特比)算法为每个事故模式计算该预测,所述Viterbi算法是用于计算所观察到的事件序列的概率的已知算法。参照图7,在步骤54,使用动态规划以可接受的置信限度预测到接下来事故状态的剩余时间(RTFS)。 

包括ECU12、诊断ECU 14和线上/离线通信系统22的系统10可在一个或多个合适的计算装置上实施,所述计算装置通常包括应用程序,其可为软件应用程序,该软件应用程序有形地实施为计算装置内 的计算机可读介质上的一组计算机可执行指令。计算装置可为多种计算装置的任一种,例如个人计算机、处理器、掌上型计算装置,等等。 

计算装置通常均包括可由例如上述所列的一个或多个装置执行的指令。计算机可执行指令可由计算机程序编译或解释,该计算机程序使用多种程序设计语言和/或技术产生,所述程序设计语言和/或技术包括但不限于单独或组合的JavaTM、C、C++、Visual Basic、Java Script、Perl,等等。通常,处理器(例如,微处理器)例如从存储器、计算机可读介质等接收指令,并且执行这些指令,由此执行一个或多个处理,该处理包括此处所述的处理的一个或多个。这些指令和其他数据可使用多种已知的计算机可读介质来存储和传送。 

计算机可读介质包括参与提供数据(例如,指令)的任何介质,该数据可由例如计算机的计算装置读取。这种介质可采取很多形式,包括但不限于非易失性介质、易失性介质和传送介质。非易失性介质包括例如光盘或磁盘和其他持续存储器。易失性介质包括动态随机存取存储器(DRAM),其典型地构成主存储器。计算机可读介质的常见形式包括计算机能够从中读取的任何介质。 

应理解的是上面描述旨在为说明性的并且不是限制性的。除了提供的例子以外的很多替代途径或应用在本领域技术人员阅读了上面描述后将是明显的。本发明的范围不应参照上面描述而确定,而是替代地应该参照所附权利要求、以及该权利要求给予保护的等同方案的全部范围来确定。希望并预计进一步的开发将在此处讨论的领域中发生,并且公开的系统和方法将被并入这种进一步的例子中。总之,应理解的是本发明能够修改和变化并且仅由所附的权利要求限制。 

本实施例已经具体示出和描述,其仅为最佳模式的说明。本领域技术人员应理解的是在权利要求的实践中可采用此处描述的实施例的各种替代方案,而不脱离本发明的精神和范围,并且这些权利要求及其等同物的范围内的方法和系统由此被覆盖。该描述应被理解为包括此处描述的元件的所有新颖的和非显而易见的组合,并且权利要求可在本申请或以后的申请中表现这些元件的任何新颖的和非显而易见的组合。而且,前面的实施例是说明性的,并且没有单个特征或元件对于可在本申请或以后的申请中要求保护的所有可能组合是必不可少的。 

权利要求中使用的所有术语旨在给出它们最宽的合理构造,以及本领域技术人员理解的其普遍意义,除非有与之相反的明确指示。尤其地,例如“一个”、“该”、“所述”等的单数物品的使用应被读作阐述一个或多个所指示的元件,除非有阐述与之相反的明确限制的声明。 

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号