一种用于列车运行监控系统的设备故障智能诊断及处理销号的方法与流程

本发明涉及列车运行监控系统(以下简称lkj)的信息化管理领域，尤其涉及机车lkj设备故障分析及处理的方法。

背景技术：

列车运行监控系统(lkj)为机车的行车安全提供了重要保障，lkj设备运用质量是行车安全的基础，路局各级管理人员和使用人员对lkj设备故障的检测分析、维修处理、运用质量高度重视。

目前，路局主要采用地面处理软件解析lkj运行记录文件，将机车的运行记录文件按协议解析后通过软件打开查看，由人工查询机车运行记录信息分析机车设备故障，分析发现故障信息后通知检修人员进行设备更换、维修，维修后的设备再次装车运用。

然而，人工分析lkj设备故障准确率不高、不及时，分析发现的故障信息无法自动流转为检修任务，维修后的设备装车的运用质量难于跟踪。

综上所述，为解决目前lkj设备故障分析及处理存在的弊端，确保lkj设备的运用质量，利用网络技术、数据分析、流程引擎、消息推送等技术，亟需一种机车lkj设备故障智能诊断及处理销号的方法，保证lkj设备故障分析、处理销号的准确、及时、可靠、可控。

技术实现要素：

为了确保铁路安全运输，列车运行监控系统(lkj)发挥了至关重要的作用。目前，我国铁路正处在跨越式发展的特殊时期，各级管理人员及作业人员对机车lkj设备的故障检测、维修测试都高度重视，投入大量的人力对lkj设备质量进行卡控，但由于lkj设备复杂、故障类型和发生条件的多样性和时变性等特点，通过人工查阅全程记录进行分析lkj设备故障，效率不高，并且分析结果完全依赖以分析人员的业务水平和经验，无法准确判断设备故障或者故障趋势。另外，对于lkj设备的维修质量，主要由人工把控，难于跟踪维修后的设备安装到机车上运行故障是否已消除。

因此，本发明要解决的技术问题在于：

(1)目前lkj设备的故障分析主要通过人工查阅lkj运行记录文件中的全程记录进行分析，人工分析效率不高，还容易出现误看、漏看，严重依赖以分析人员的专业水平。缺乏一种智能检测、分析设备故障的手段；

(2)lkj设备的检修主要依赖以故障修和定期修，无法智能分析设备的故障规律和趋势，并对设备的潜在故障进行预警；

(3)目前lkj设备的维修质量主要由人工把控，维修后设备运用情况主要通过人工盯控，难于跟踪设备在维修后的运用过程中故障是否消除，存在质量安全隐患。缺乏一种故障处理销号的卡控手段；

(4)设备的故障分析、故障处理等作业由不同部门协同完成，目前故障信息、故障处理信息没能做到信息共享、数据流通，分析人员和检修人员之间无法实现故障信息的自动流转和检修任务的自动派送，可能导致故障处理不及时等问题；

(5)故障分析—>机车设备更换—>送修—>故障维修—>修后装车—>首趟分析销号等作业环节，没有实现信息化的流程协作管理，管理人员难于跟踪故障处理的进度、执行详情和完成质量等；

(6)各种故障统计、维修记录采用人工的方式，结果准确性不高，台帐记录查询困难，不利于设备质量的跟踪管理。

综上，为满足铁路lkj设备故障检测、故障处理销号的信息化发展要求，本发明提供了一种机车lkj设备故障智能诊断及处理销号的方法，通过系统智能分析lkj运行文件、设备运行状态信息，判断lkj设备的故障信息或故障趋势，实现机车lkj设备从故障修到预警修；lkj设备维修装车后，自动分析机车首趟运行产生的lkj运行文件(以下简称首趟文件)，判断机车lkj设备故障是否已消除，实现故障处理的闭环卡控。

在一个实施例中，本发明提供了一种用于列车运行监控系统(lkj)的设备故障智能诊断及处理销号的方法，其特征在于，所述方法包括：

a:设置一故障条件配置文件；

b:读取并解析所述故障条件配置文件，将各种故障类型的判断依据解析并写入一故障条件对象数组；

c:机车运行入库后，上车转储lkj运行文件并上传至地面服务器的指定目录；

d:读取并按协议解析所述lkj运行文件，将所述lkj运行文件中的每一条记录信息解析写入内存数据表中，每一条记录至少包括发生时间、事件、状态值；

e:根据所述故障条件对象数组中的故障判断条件，对所述内存数据表中的记录信息进行遍历和统计分析，判断是否满足故障条件，如果满足，则执行故障处理流程，如果分析未发现故障，则执行步骤f；

f:提取所述lkj运行文件中的机车型号、机车号信息，查询所述lkj运行文件中提取的机车在数据库的机车故障信息表中是否存在未销号的故障信息，如果查询到未销号记录信息，则将故障处理状态置为“已销号”，并结束流程；如果未查询到满足条件的记录信息，结束流程。

所述步骤e中的执行故障处理流程包括：

g:将步骤d中检测到的故障信息写入数据库的机车故障信息表中，处理状态置为“待处理”；

h：利用流程引擎技术自动启动故障处理流程，利用消息推送技术将故障信息推送给相关检测、检修作业人员，进行故障处理提醒；

i：收到故障处理任务后，执行机车故障设备更换和送修流程；

j：收到故障设备后，执行故障维修流程，维修后的设备交由检测人员进行装车运用；

k：机车lkj设备更换后运行入库，再次启动步骤c。

所述步骤a包括：

在配置文件中按约定格式配置各种故障类型的判断条件，或者潜在发生故障的条件，以生成“故障条件”配置文件。

所述发生故障的条件至少包括事件、时间段(周期)、次数、阀值。配置格式为：“故障类型＝[事件代号][周期][次数][阀值]”。

某类故障的判断条件可以是多种场景的组合，采用“&&”符号将“[事件代号][周期][次数][阀值]”进行组合。

当所述故障判断条件发生变化时，只需修改所述故障条件配置文件。

本发明自动分析lkj运行文件、车载实时状态数据，利用大数据分析及检索技术实现lkj设备故障的诊断和预警，通过对检修机车首趟文件进行分析，实现机车lkj设备检修质量的闭环卡控。具体创新点和有益效果如下：

(1)上述方案流程步骤201、202中通过配置文件配置故障条件，程序动态加载和解析配置文件的方法，当故障判断条件发生变化时，只需修改配置文件即可，而不用修改系统(方法)的判断逻辑，避免了故障判断条件的变化导致系统(方法)的频繁修改，大大减轻了系统的维护工作量，增强了系统的实用性；

(2)上述方案流程步骤205中根据故障条件，利用大数据分析技术对记录信息进行统计、分析、检索，实现了设备故障的智能诊断和预警，将人工分析变为智能分析，减轻了分析人员工作量，并解决了人工分析存在的不足，大大提高了作业效率和作业质量；

(3)上述方案步骤206中，通过自动分析lkj运行文件实现机车故障的销号，将人工盯控变为机控，解决了人工跟踪机车故障处理情况存在的弊端和安全隐患；

(4)上述方案步骤208至210中，利用流程引擎技术，实现了多个部门协同作业，信息共享，解决了管理人员难于跟踪故障处理的进度、执行详情和完成质量等难题，提高了设备质量管控水平。

附图说明

本发明的以上发明内容以及下面的具体实施方式在结合附图阅读时会得到更好的理解。需要说明的是，附图仅作为所请求保护的发明的示例。在附图中，相同的附图标记代表相同或类似的元素。

图1示出了根据本发明一实施例的机车lkj设备故障智能诊断及处理销号的业务流程图；

图2示出了根据本发明一实施例的机车lkj设备故障智能诊断及处理销号的方法流程图。

具体实施方式

以下在具体实施方式中详细叙述本发明的详细特征以及优点，其内容足以使任何本领域技术人员了解本发明的技术内容并据以实施，且根据本说明书所揭露的说明书、权利要求及附图，本领域技术人员可轻易地理解本发明相关的目的及优点。

术语定义：

lkj：列车运行监控系统；

lkj运行文件：机车上的lkj设备运行产生的文件，文件中记录lkj设备在运行中的各种状态信息和发生的事件信息；

地面处理：一种将lkj运行文件按协议解析为文本文件并打开查看的软件；

首趟文件：机车发生故障并故障处理后，首趟运行入库转储的lkj运行文件，简称为首趟文件或首趟运行文件；

车载实时状态数据：机车在运行过程中的实时状态信息，包括速度、各板件状态、管压、缸压等信息；

机车运行入库：机车完成一趟运输任务后，需要到指定地点(机务段)进行检测、检修和交接工作，完成运行任务后到机务段进行测试、交接工作这一过程成为机车运行入库；

转储lkj运行文件：通过ic卡、手持终端等设备，将lkj设备上的形成的lkj运行文件转储(拷贝)至服务器的操作，成为转储lkj运行文件；

图1示出了根据本发明一实施例的机车lkj设备故障智能诊断及处理销号方法的业务流程图。

根据设定的故障条件自动检索、分析lkj运行文件和车载实时状态数据，判断lkj设备质量状态和故障趋势，利用消息推送技术将故障信息自动转化为设备更换、检修任务下达给相关检测、检修人员，利用流程引擎技术实现故障分析—>机车设备更换—>故障设备送修—>故障设备维修—>修后装车—>首趟分析销号等作业流程的自动路由和闭环，实现了故障分析、故障处理作业的全程盯控；设备维修(更换)上车后，系统自动分析机车的首趟文件，检测设备故障是否消除，如果已消除，则自动闭环机车设备故障，将机车的故障处理和设备的检修质量由人控变为机控。

图2示出了根据本发明一实施例的机车lkj设备故障智能诊断及处理销号的方法流程图。

步骤201:在配置文件中按约定格式配置各种故障类型的判断条件，或者潜在发生该故障的条件，以生成“故障条件”配置文件。故障发生的条件包括事件、时间段(周期)、次数、阀值等信息。配置格式如下：“故障类型＝[事件代号][周期][次数][阀值]”，如果某类故障的判断条件是多种场景的组合，可以用“&&”符号将“[事件代号][周期][次数][阀值]”进行组合，例如，某一故障类型的发生条件为两种事件的组合，配置格式为“故障类型＝[事件代号1][周期1][次数1][阀值1]&&[事件代号2][周期2][次数2][阀值2]”。

步骤202:读取并解析“故障条件”配置文件，将各种故障类型的判断依据解析并写入“故障条件对象数组”。

步骤203:机车运行入库后，上车转储lkj运行文件并上传至地面服务器的指定目录。

步骤204:读取并按协议解析步骤203中上传的lkj运行文件，将lkj运行文件中的每一条记录信息解析写入内存数据表中，每一条记录包括发生时间、事件、状态值等信息。

步骤205:根据步骤202中描述的“故障条件对象数组”中的故障判断条件，对内存数据表中的记录信息进行遍历和统计分析，判断是否满足故障条件，如果满足，则执行步骤207—210，如果分析未发现故障，则执行步骤206。

步骤206:提取lkj运行文件中的机车型号、机车号信息，查询lkj运行文件中提取的机车在数据库“机车故障信息表”中是否存在未销号的故障信息，如果查询到未销号记录信息，则将故障处理状态置为“已销号”，并结束流程；如果未查询到满足条件的记录信息，结束流程。

步骤207:将步骤204中检测到的故障信息写入数据库“机车故障信息表”中，处理状态置为“待处理”。

步骤208：利用流程引擎技术自动启动故障处理流程，利用消息推送技术将故障信息推送给相关检测、检修作业人员，进行故障处理提醒。

步骤209：收到故障处理任务后，执行机车故障设备更换和送修流程。

步骤210：收到故障设备后，执行故障维修流程，维修后的设备交由检测人员进行装车运用。

步骤211：机车lkj设备更换后运行入库，再次启动步骤203。

本发明自动分析lkj运行文件、车载实时状态数据，利用大数据分析及检索技术实现lkj设备故障的诊断和预警，通过对检修机车首趟文件进行分析，实现机车lkj设备检修质量的闭环卡控。具体创新点和有益效果如下：

(1)上述方案流程步骤201、202中通过配置文件配置故障条件，程序动态加载和解析配置文件的方法，当故障判断条件发生变化时，只需修改配置文件即可，而不用修改系统(方法)的判断逻辑，避免了故障判断条件的变化导致系统(方法)的频繁修改，大大减轻了系统的维护工作量，增强了系统的实用性；

(2)上述方案流程步骤205中根据故障条件，利用大数据分析技术对记录信息进行统计、分析、检索，实现了设备故障的智能诊断和预警，将人工分析变为智能分析，减轻了分析人员工作量，并解决了人工分析存在的不足，大大提高了作业效率和作业质量；

(3)上述方案步骤206中，通过自动分析lkj运行文件实现机车故障的销号，将人工盯控变为机控，解决了人工跟踪机车故障处理情况存在的弊端和安全隐患；

(4)上述方案步骤208至210中，利用流程引擎技术，实现了多个部门协同作业，信息共享，解决了管理人员难于跟踪故障处理的进度、执行详情和完成质量等难题，提高了设备质量管控水平。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述发明披露仅仅作为示例，而并不构成对本申请的限定。虽然此处并没有明确说明，本领域技术人员可能会对本申请进行各种修改、改进和修正。该类修改、改进和修正在本申请中被建议，所以该类修改、改进、修正仍属于本申请示范实施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本申请至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一替代性实施例”并不一定是指同一实施例。此外，本申请的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，本领域技术人员可以理解，本发明的各方面可以通过若干具有可专利性的种类或情况进行说明和描述，包括任何新的和有用的工序、机器、产品或物质的组合，或对他们的任何新的和有用的改进。相应地，本申请的各个方面可以完全由硬件执行、可以完全由软件(包括固件、常驻软件、微码等)执行、也可以由硬件和软件组合执行。以上硬件或软件均可被称为“数据块”、“模块”、“引擎”、“单元”、“组件”或“系统”。此外，本发明的各方面可能表现为位于一个或多个计算机可读介质中的计算机产品，该产品包括计算机可读程序编码。

计算机可读信号介质可能包含一个内含有计算机程序编码的传播数据信号，例如在基带上或作为载波的一部分。该传播信号可能有多种表现形式，包括电磁形式、光形式等等、或合适的组合形式。计算机可读信号介质可以是除计算机可读存储介质之外的任何计算机可读介质，该介质可以通过连接至一个指令执行系统、装置或设备以实现通讯、传播或传输供使用的程序。位于计算机可读信号介质上的程序编码可以通过任何合适的介质进行传播，包括无线电、电缆、光纤电缆、rf、或类似介质、或任何上述介质的组合。

本申请各部分操作所需的计算机程序编码可以用任意一种或多种程序语言编写，包括面向对象编程语言如java、scala、smalltalk、eiffel、jade、emerald、c++、c#、vb.net、python等，常规程序化编程语言如c语言、visualbasic、fortran2003、perl、cobol2002、php、abap，动态编程语言如python、ruby和groovy，或其他编程语言等。该程序编码可以完全在用户计算机上运行、或作为独立的软件包在用户计算机上运行、或部分在用户计算机上运行部分在远程计算机运行、或完全在远程计算机或服务器上运行。在后种情况下，远程计算机可以通过任何网络形式与用户计算机连接，比如局域网(lan)或广域网(wan)，或连接至外部计算机(例如通过因特网)，或在云计算环境中，或作为服务使用如软件即服务(saas)。

此外，除非权利要求中明确说明，本申请所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本申请流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本申请实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本申请披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本申请实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本申请对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本申请一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本申请引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档、物件等，特此将其全部内容并入本申请作为参考。与本申请内容不一致或产生冲突的申请历史文件除外，对本申请权利要求最广范围有限制的文件(当前或之后附加于本申请中的)也除外。需要说明的是，如果本申请附属材料中的描述、定义、和/或术语的使用与本申请所述内容有不一致或冲突的地方，以本申请的描述、定义和/或术语的使用为准。

最后，应当理解的是，本申请中所述实施例仅用以说明本申请实施例的原则。其他的变形也可能属于本申请的范围。因此，作为示例而非限制，本申请实施例的替代配置可视为与本申请的教导一致。相应地，本申请的实施例不仅限于本申请明确介绍和描述的实施例。