CN102682187A - 一种用于轨道交通设备的智能故障诊断方法 - Google Patents

Abstract

本发明涉及一种用于轨道交通设备的智能故障诊断方法，包括以下步骤：1)将诊断逻辑转换为流程图数据，并将该数据存储为适用轨道交通领域的知识表示文档；2)推理机Cflow把“流程图”加载到内存；3)Cflow根据流程图数据适用的设备类型，为每个单独的设备建立自己的流程实例遍历器CVisitor；4)CVisitor在CThreadManager的推理驱动机制下不断运转；5)每个Cvisitor每次运转都执行知识表示的遍历分析算法；6)CVisitor在访问到流程图数据的数据点时，根据数据点的描述，去CDataBuffer类取数据等步骤。与现有技术相比，本发明具有第一次将故障诊断模型应用于轨道交通设备微机监测中，用计算机全方位的分析诊断设备等优点。

Description

一种用于轨道交通设备的智能故障诊断方法

技术领域

本发明涉及一种智能故障诊断方法，尤其是涉及一种用于轨道交通设备的智能故障诊断方法。

背景技术

目前，对设备的微机监控并实现智能诊断在设备维护中有越来越广泛的应用；在轨道交通系统中，设备状态的微机监测技术也已成熟。但是在其基础上，尚缺乏可实用的设备状态的智能诊断和分析技术。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种用于轨道交通设备的智能故障诊断方法。

本发明的目的可以通过以下技术方案来实现：

一种用于轨道交通设备的智能故障诊断方法，其特征在于，包括以下步骤：

1)将诊断逻辑转换为流程图数据，并将该数据存储为适用轨道交通领域的知识表示文档；

2)推理机(Cflow)把“流程图”加载到内存；

3)Cflow根据流程图数据适用的设备类型，为每个单独的设备建立自己的流程实例遍历器(CVisitor)；

4)CVisitor在推理机驱动器(CThreadManager)的推理驱动机制下不断运转；

5)每个Cvisitor每次运转都执行知识表示的遍历分析算法；

6)CVisitor在访问到流程图数据的数据点时，根据数据点的描述，去数据获取器(CDataBuffer)类取数据；

7)CDataBuffer会访问外部采集器提供的数据缓存内存区寻找该数据点所描述的设备的某段时间内的数据；

8)CVisitor根据取到的数据做自定义表达式的逻辑运算，满足逻辑表达式，则进入该表达式对应的后续节点，所有后续节点都不满足，则跳出一次遍历；

9)CVisitor在深度遍历过程中最后访问结果点后，提交该诊断结果信息给报警器(CAlarm)；

10)CAlarm做结果的后续处理，包括存储、展示。

所述的数据点的描述包括通用表述方式、轨道交通专业知识表述，所述的轨道交通专业知识表述包括进路前后轨道区段、区间前后轨道区段、道岔所在区段、信号机继电器码位。

所述的结果点描述为轨道交通设备故障和预警信息：例如“轨道故障红信息”表述为轨道区段在无车占用情况下出现的非正常红光带。

与现有技术相比，本发明具有以下优点：

1)第一次将故障诊断模型应用于轨道交通设备微机监测中，用计算机全方位的分析诊断设备。

2)定义了专用于轨道交通领域的“知识表示方法”和“推理机制”。

3)实现了高效的“推理驱动机制”。

4)实现了面向轨道交通领域的特有的遍历分析算法。

附图说明

图1为本发明的流程图；

图2为本发明的推理驱动机制的适当时间计算示意图。

具体实施方式

下面结合附图和具体实施例对本发明进行详细说明。

实施例

如图1所示，一种用于轨道交通设备的智能故障诊断方法，包括以下步骤：

1)将诊断逻辑转换为流程图数据，并将该数据存储为适用轨道交通领域的知识表示文档；

2)推理机Cflow把“流程图”加载到内存；

3)Cflow根据流程图数据适用的设备类型，为每个单独的设备建立自己的流程实例遍历器CVisitor；

4)CVisitor在CThreadManager的推理驱动机制下不断运转；

5)每个Cvisitor每次运转都执行知识表示的遍历分析算法；

6)CVisitor在访问到流程图数据的数据点时，根据数据点的描述，去CDataBuffer类取数据；

7)CDataBuffer会访问外部采集器提供的数据缓存内存区寻找该数据点所描述的设备的某段时间内的数据；

8)CVisitor根据取到的数据做自定义表达式的逻辑运算，满足逻辑表达式，则进入该表达式对应的后续节点，所有后续节点都不满足，则跳出一次遍历；

9)CVisitor在深度遍历过程中最后访问结果点后，提交该诊断结果信息给CAlarm；

10)CAlarm做结果的后续处理，包括存储、展示。

“轨道交通设备的智能故障诊断方法”包括以下特点

(一)“推理驱动机制”的高效实现

推理机的驱动依靠CThreadManger来实现。CThreadManger管理一个线程数组，每个线程都是一个不间断的循环，循环内部检查“这个线程所拥有的流程实例”的“遍历频率”，(例如某个实例是1分钟遍历一次，这个频率是由用户画“流程图”时候定义的)，到了这个时间，则进入这个“流程实例的遍历阶段”。

(二)“推理机驱动”线程机制

用户可自定义驱动线程的个数，多个或多核CPU时一般建议设置为“CPU核数-1”。预留1核用于数据的缓存，采集处理，以保证数据来源的实时性和准确性。

推理机CFlow在实例化每个CVisitor时，会把每个“流程实例”平均分配到各线程中，或者根据优先级设置，先分配优先级高的流程。

(三)“推理机驱动”遗弃机制：

当CPU处理负荷不了“流程实例”数时，会抛弃掉优先级低的“流程实例”的运行并记录日志。该机制保证了推理机在异常状态下的稳定运行。

“推理机驱动”回溯机制：采用“回溯”方式来分析数据。

“回溯”方式是相对于“实时”的一种数据获取方式。即指数据存在后，并不立即分析它，而是把数据先都缓存，再根据适当的时机回过头来分析数据。

“回溯”方式的好处在于：

由于分析数据时，不需要等待未准备的数据，所以线程不会进入等待状态。

(例如故障红逻辑，红光带亮起后，并不会立刻分析这个红光带，因为流程的后续点里面有描述【取当前时间的5-10s后的数据】。实时方式则需要等待10s以获取数据，回溯方式则在10s后再进入分析阶段，把“当前时间”定义为“红光带的触发时间”。)

可以处理开关量和模拟量有时延的情况。实际系统中根据采集器的性能，可能数据有小量时间延迟和错位，用实时方式处理这种延时则经常要进入等待状态，回溯方式更为清晰和高效。

(四)“适当的时机”回头分析：“适当的时机”的计算如图2所示：

每个“流程图”中都会定义一个“遍历频率”，CThreadManager线程循环中根据这个频率，进入该流程的分析。每次流程的分析会对所有满足“顶点”的秒进行遍历。“最大向后时间”是加载流程时预先查找各“取值点”，取离“当前时间”最大的时间。“分析时间段”是偏移过“最大向后时间”之后真正的数据分析的时间段。

一个“流程图”是针对“一类设备分析”的知识表述，(例如故障红，是针对站内区段的故障的一个描述)。推理机在加载了“流程图”后，会实例化它，为该车站的每个站内区段都实例化一个“流程实例”CVisitor。CVisitor被CThreadManager驱动做“流程图”的遍历，并维护遍历的中间状态。

(五)遍历算法

遍历算法是基于“有向图的深度优先遍历算法”的改造。加入了“用户点”的中断处理：因为流程中会有要求用户交互的点，例如“请输入X值，或请断开X线后测量X值”。实现方法：

加入了一个“中断开始点队列”vector<CDot*>m_startVec。

1)预先加载根节点到m_startVec。

2)依次取m_startVec其中之一开始深度遍历，并把开始遍历的点清除出m_startVec。

3)当遍历到用户点时，把用户点加入m_startVec，并把CVisitor的变量m_userDone置位，表示要等用户输入了，跳出这次遍历。

下次遍历：

4)检查m_userDone位，如果用户准备好了，继续以m_startVec做深度遍历，转到2)。

5)如果用户没准备好，跳出这次遍历，等待下一次遍历。

(六)点的访问

1)数据取值：在“流程工具”中提供了很多取值方式的描述。

a)最简单的：取当前设备的当前时间的数据，

b)取一段时间的数据，

c)取左右同类设备的数据，

d)取站内进路中前后设备的数据，

e)取区间设备前后轨道的数据，

f)取全局设备，例如“总人解，总反位”的数据等等。

推理机的CVisitor会根据这些描述，做相应处理：处理方式是调用一段在程序中预设好的代码段。其他取值方式的实现类似。以故障红流程图的6DG为例。

找左右同类设备的步骤。

a)CVisitor会去“站场图”中找到6DG的内部道岔6#，

b)CVisitor向CDataBuffer获取6#道岔在T时间(回溯的遍历时刻)的位置为定位，

c)CVisitor再去“站场图”中找到6#道岔定位的左连接和右连接。

2)数据分析：以“自定义表达式”方式实现对获取的数据计算和分析。表达式的输出都为“1或0”，表示“满足或不满足”。

描述包括：

a)基本数据运算：加减乘除、三角函数、绝对值。

b)基本比较：大于，小于，等于

c)One of一段时间内的一个数据满足即满足

d)Allof一段时间内所有数据满足即满足

e)X％of一段时间内百分之X数据满足即满足等等

推理机的CVisitor会调用“自定义表达式解析器”来解析这些“表达式”，并输出“满足”“不满足”，以跳到相应的出口。(自定义表达式解析器解析过程参见相应文档)。

3)结果

当遍历到“结果点”时，流程遍历退出，并把“结果点”的信息发送给CAlarm做展示，存储等相应后续处理。

Claims (3)

1.一种用于轨道交通设备的智能故障诊断方法，其特征在于，包括以下步骤：

1)将诊断逻辑转换为流程图数据，并将该数据存储为适用轨道交通领域的知识表示文档；

2)推理机(Cflow)把“流程图”加载到内存；

3)Cflow根据流程图数据适用的设备类型，为每个单独的设备建立自己的流程实例遍历器(CVisitor)；

4)CVisitor在推理机驱动器(CThreadManager)的推理驱动机制下不断运转；

5)每个Cvisitor每次运转都执行知识表示的遍历分析算法；

6)CVisitor在访问到流程图数据的数据点时，根据数据点的描述，去数据获取器(CDataBuffer)类取数据；

7)CDataBuffer会访问外部采集器提供的数据缓存内存区寻找该数据点所描述的设备的某段时间内的数据；

8)CVisitor根据取到的数据做自定义表达式的逻辑运算，满足逻辑表达式，则进入该表达式对应的后续节点，所有后续节点都不满足，则跳出一次遍历；

9)CVisitor在深度遍历过程中最后访问结果点后，提交该诊断结果信息给报警器(CAlarm)；

10)CAlarm做结果的后续处理，包括存储、展示。

2.根据权利要求1所述的一种用于轨道交通设备的智能故障诊断方法，其特征在于，所述的数据点的描述包括通用表述方式、轨道交通专业知识表述，所述的轨道交通专业知识表述包括进路前后轨道区段、区间前后轨道区段、道岔所在区段、信号机继电器码位。

3.根据权利要求1所述的一种用于轨道交通设备的智能故障诊断方法，其特征在于，所述的结果点描述为轨道交通设备故障和预警信息。

Images