基于插件技术的微机监测故障诊断系统平台研究

陈芳慧

摘要：铁路信号微机监测系统是保证行车安全，监测铁路信号设备运用质量的支持系统。目前的诊断系统对设备异常和故障事件的实时分析以及诊断支持水平还很低下，没有能够对采集到的数据自动分析处理并给出处理意见的专家系统功能。因此很有必要在现有存在的检测系统上，分析基于微机监测检测智能化系统的解决办法，该文通过对插件技术的分析应用，结合目前微机监测平台的问题对平台系统重新设计架构，并总结了新架构下平台的优点，基本解决了现有平台的不足。

关键词：微机监测；故障诊断；插件

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）29-0001-03

铁路微机监测系统是一个实时系统。它能够实时跟踪记录并反映出信号设备的运行情况，并应该能够根据采集到的数据自动调整分析，得出较为准确的故障结果，及时提示预警。但目前实际使用中的微机监测平台都还不具备故障诊断给出意见的智能功能。现有微机检测系统存在的问题有：

1）微机监测系统对数据没有很好的处理利用。由于微机监测系统采集到的数据涉及的面广、量大，仅仅靠现场工作人员凭借经验分析，不仅工作量大，而且不能够将数据整合处理分析，延误故障处理，甚至导致潜在故障的发生。

2）不能够进行故障点判断和故障分析处理指导意见。目前的微机监测系统只能够将采集到的数据以曲线图的形式呈现，与正常的曲线图做一比较，之后的故障分析，还是得靠有现场经验的工作人员依据经验来分析判断，不能脱离人为因素，而且人为因素在故障诊断时占主导地位，非常有可能造成故障诊断出错，这种微机故障诊断平台非常不智能化。

3）不能预警潜在故障危机。正是由于2）中不能脱离人为因素，故只有在故障发生之后才开始补救，没有在故障发生之前就能将故障排除，这种情况造成的经济成本可想而知。

基于以上总结的现有微机监测系统存在的问题，开发一个智能化微机监测故障诊断系统是铁路电务段非常需要的。

1微机监测故障诊断平台的功能需求

针对目前微机监测平台存在的问题，总结提出微机监测故障诊断平台的功能需求。

正常情况下：

1）实时电流图的跟踪监视；

2）自动记录入库电流数据和各开关量采集点信息；

3）异常报警；

4）人机联系，有异常情况及时给相关负责人电话报警。

事故的监测和处理：

1）事故时可以快速采集电流数据；

2）综合分析故障原因，打印故障发生时间，设备状态，故障电流等相关数据，为工作人员后续处理故障提供数据分析支持和建议；

3）将各种故障电路图入库，以实现故障具体定位。尤其要以时间为依据，按月，季度，年进行分析。

2微机监测故障诊断平台系统故障诊断方法

铁路信号设备故障种类繁多，按照设备类型大致可以分为道岔电流故障，轨道电路故障以及电源故障等。微机监测系统一般利用计算机和信息采集机对模拟量和开关量进行监测。故障诊断一般采取以下方法：

1）数据曲线对比。通常情况下，我们是将故障曲线与正常曲线进行对比分析，最好是在同一坐标下，这样便于工作人员进行分析判断

2）综合情况进行判断。因为有时信号设备的故障发生原因不是单一类型的，很有可能是多个问题的叠加。所以有必要结合之前的情况进行综合判断，需要结合之前的情况动态回放，综合分析得出结果。

3）借助专家诊断系统辅助分析。应用这一功能的前提是专家库里所包含的意见分析要足够详细，这需要不断地扩充改进完善专家库系统。

3“平台-插件”设计的关键技术

由上述微机监测平台现存的诸多问题以及平台功能需求，亟待开发出一种灵活兼顾可扩展重用的软件系统，它的基础功能应该有以上常用故障診断方法。基于面向组件的开发技术恰恰满足了这种需求。组件化程序开发技术是一种结合结构化程序设计与面向对象程序设计技术优点的新型软件开发技术，它更侧重于系统整体性。它的主要设计理念是将复杂化的软件分解成为若干功能组件，不限开发语言与环境，最终各个组件通过定义好的协议接口能够有效的组织在一起而完成任务就可以。插件技术是组件技术的一种典型代表，它要比com组件技术简单。插件技术的实现以动态链接库（DILL）为目前最优方案，它更为灵活，开发速度更快。本文利用插件技术的特点，对现有微机监测故障诊断系统进行新的架构设计。

我们主要利用插件技术的特点，将一些可重用的模块做成插件，不同故障类型可以通过定义具有通用接口的应用插件实现。故障诊断并给出分析意见可以通过统一的插件宿主程序对故障插件的解析与动态调用实现。专家库也可以作为一个插件模块，插件之间可以通过宿主程序在规定好的接口协议范围内通信，更好的得出结果。基于此对现有系统进行重新架构。

1）故障诊断平台宿主程序

插件技术通过把软件的需求和功能进行划分，把基础的功能需求放在宿主程序中。铁路微机监测故障诊断平台中，应该有基本的实时电流图显示功能，电流数据曲线回放功能，电流数据录入分析诊断功能等，而这些功能其实都是一个界面显示的功能，可以通过插件本身来完成，宿主平台只需要调用他们即可，所以宿主平台起到了一个显示屏的作用。宿主程序它只是一个插件的骨架，通过扫描插件的位置，并且匹配该插件是否符合规定的插件接口标准来判断其是否是该系统的插件，进而能够加载插件。它必须为支持插件提供插件管理功能以及协调各插件。主要的实现功能应该是由具体的插件实现的。其中，主程序部分应该能够实现注册/反注册插件，启用/禁用插件，显示插件基本功能信息，配置插件参数。

2）故障诊断平台插件模块

插件模块应有专家库，道岔故障库，轨道故障库等故障库等。它们实现了整个系统的所有功能。其中故障诊断应以现有的最优算法给出结果，配合专家诊断，最终得出较为合理的诊断结果和维护意见。它的实现过程是，首先定义一个名为IPlugin的类，作为通用插件模块的接口。它不需要定义任何公共的方法和属性，然后以此为父节点，然后依次定义接口，当然就相似模块也可以依次继承。在这里，实现以动态链接库（Dy-namic link library，DLL）的形式。具体的插件模型结构图如下：

该故障模块插件主要有IPlugin，IData，IView，以及IMethods接口。1）IPlugin的作用是身份识别。它包含了插件的基本信息，如插件名称，版本信息，插件描述，工具栏等相关资源，以及主程序对插件进行操作时的相关方法。2）IData接口的作用是数据传输。当插件模块被识别并加载运行之后，通过操作系统自带的数据库引擎从故障数据库中读取所需数据，转换到内存中的动态数据库以及故障诊断所需的数据结构中，完成数据的输入。3）IView的作用是用视图显示的功能将数据处理后的结果以曲线的形式反映出来。并且，在需要录入数据的时候，完成数据的输入，即人机交互的功能体现与此。（4）IMethods的作用是提供处理数据所需的算法，数据通过它提供的算法处理后得出结果。以上四个接口相互配合完成工作。

3）接口设计

采用插件技术最为重要的就是接口设计。这里的接口设计应该包括两个部分的内容，一个是宿主程序的接口设计，另外一个当然就是插件接口的设计。插件接口实现了宿主程序对插件的主要操作。核心代码如下：

class IPlugin{

//插件接口

public：

CString IPlugin_name；//插件名称

CString IPlugin_vertion；//插件版本

CString IPlugin_description；//插件描述

IHugin0{}

virtualintRegister（）=0；//注册插件，成功返回0

virtualintUrrregister（）=0；//反注册插件，成功返回0

…//插件资源

void Initialize（）；//插件初始化设置

void Dispose（）；//清除插件资源

}；

IPlugin是插件的接口，里面定义了插件的名称，版本，描述，以及各种资源。可根据情况进行加载和删除。它定义了宿主程序对插件的所有基础操作方法。

BOOL IPluginHost（void**pHost）//宿主程序接口函数

{

*pHost=new CPlugDaocha；//CPlugDaocha公有派生于纯虚类IPlugin

return*pHost！=HULL；

//其他方法函数

}

IPluginHost是宿主程序的接口，由于它的作用它必须是公有的，用于在主程序里创建插件对象，实现对插件的调用。CPlugDaocha是插件程序里的动态链接库的一个类，即道岔故障类，由主程序里的插件基类（相当于接口，是纯虚类）派生而来，提供插件的基础功能。IPluginHost作為主程序的接口函数，向插件提供插件对宿主程序的所有操作方法。

在完成各种准备工作后可以并行进行插件与宿主程序的开发，最后完成各部分的单独调试以及连接调试就可以。同时需要注意的是，宿主程序虽然功能比较简单，但是最主要是有扫描发现插件并能够加载运行的功能。

4）插件实现

本文中的插件实现以动态库的形式实现，开发平台为VC++。这里的插件都是基于IPlugin类的，这样就统一了插件的接口标准，然后在宿主程序接口中创建实例，从而完成对插件的调用，当然，这只是实例的创建，在资源方面，还是要以动态库的形式调用，这主要同过动态库的导出函数来实现，核心代码如下：

LIBRARY“CPlugDaocha”

DESCRIPTION‘…

EXPORTS

IPluginHost@1

这段代码首先定义了加载的插件名称，然后通过函数IPI-uginHost来创建插件对象。进而完成插件的功能。

4总结

由于铁路对微机监测系统的使用需求很高，但实际中现有的微机监测系统无论从系统架构，使用的通信协议，以及各个厂家的微机监测系统又有区别，使得目前使用的微机监测系统情况颇为复杂。采用插件技术是可以解决这些问题的，总结如下：

1）可以不考虑编程环境和语言，用通用的接口开发，使得开发过程更为方便。

2）在一定程度上克服了系统的不稳定性。因为各个模块之间是独立的，所以如果出现其中的某个模块失灵，也不会对整个系统造成大的影响。

3）更容易扩展程序和功能。可以将微机监测和故障诊断巧妙地结合起来，通过模块的形式将诊断插入，不仅灵活增加了系统功能，更加方便了修改。