一种故障诊断监控数据库服务实现方法

暂无

一种故障诊断监控数据库服务实现方法\n技术领域\n[0001] 本发明涉及嵌入式故障诊断、数据采集、UPnP网络中间件等技术领域，主要是一种故障诊断监控数据库服务实现方法。\n背景技术\n[0002] 第一方面：故障诊断系统\n[0003] 随着科技的进步，故障诊断技术迅速发展起来，在工业监测等方面应用非常广泛。\n20世纪后期，嵌入式技术得到蓬勃发展，使故障诊断仪器设备功能不断完善，同时体积越来越小。嵌入式手持式故障诊断仪器设备是新时期故障诊断技术的标志之一。嵌入式手持式诊断仪不仅在功能上克服了传统单片机故障诊断仪计算能力不足的局限，而且便于携带，使用灵活，性价比较高，因而成为目前手持式故障诊断仪的趋势架构。\n[0004] 然而，传统的手持诊断仪只能孤立的对某台设备的当前状态进行数据采集和分析，如果要对企业众多的设备进行归类对比，就不能满足要求了。手持诊断仪也不易于对设备进行全天候的实时监测，而这却正是工业现场关键设备，比如电厂的汽轮机所需要的。\n[0005] 由于工业生产规模不断扩大，众多设备协同工作、管理，使得故障监测设备进行联网成为必然。一种传统的方法是将各个目标设备上的传感器采集的模拟信号直接通过线缆连接到监控中心，在控制中心的故障监测诊断系统再对信号进行集中处理和分析，对信号的传输距离、抗干扰要求很高；而且由于是星型网络结构，其扩展能力直接受到系统的最大接入容量的限制。另一种目前比较流行的故障诊断网络解决方案是基于互联网的服务器客户机架构。但这种网络故障诊断系统是基于实地址的，对网络的架构变化的动态支持不够。\n[0006] 第二方面：故障诊断系统中的数据库服务\n[0007] 早期的故障诊断监测系统不具备数据库服务，使其监测能力受到很大的限制。工控机模块的出现以及嵌入式技术的不断发展使故障诊断系统具备数据库服务成为可能。而传统的数据库一般在一一对应的模式下运行，这使得整个系统中的服务冗余，每一个数据采集点都带有数据库服务，而单个数据库服务的利用效率并不高；此外，数据库之间并未联网，不能实现数据采集点之间的数据比较。\n[0008] 网络技术的迅猛发展使得数据库也独立的成为故障诊断网络中的一个节点。它可以同时服务于多个数据采集点和控制点，存储多个设备的运行数据，回放多个设备的历史数据，并支持设备间的数据比较。网络化提供了较强大的数据库服务，但同时也增加了配置、维护的工作量。在这种模式中，一个新的数据采集点加入网络之后，数据库并不能主动的发现并访问该采集点的数据，需要人为地在数据库、采集点两端配置数据库访问的相关参数；当一个节点退出网络时亦然。\n[0009] 第三方面：UPnP——通用即插即用技术\n[0010] UPnP是新一代的网络中间件，它扩展了传统单机设备和计算机系统的概念，将传统的即插即用(PnP)功能扩展到网络环境，使得设备和服务一旦接入网络，立即就可以使用。UPnP模型设计可以支持大量的设备制造商的不同设备的“零配置”、自主联网、自动发现等。通过UPnP，设备可以动态的加入网络，获得IP地址，发现网络上的其他设备以及其提供的服务——这一切均是自动完成，实现监测仪器网络的配置智能化。\n[0011] 目前，UPnP技术主要运用于智能家庭电子领域，一般在较高端的设备中实现。将UPnP技术运用于工业设备监测领域，在较低端的嵌入式系统中实现UPnP，尚在尝试阶段。\n发明内容\n[0012] 本发明主要解决一般工业监测系统中数据库服务存在的缺陷，提供了一种故障诊断监控数据库服务实现方法。\n[0013] 本发明的设计依据是：UPnP是一种基于通用网络协议(TCP/IP、HTTP、SOAP等等)之上的架构，为PC或智能设备提供了便利的点对点互连。UPnP技术使得设备能够自动地和其他设备建立连接并协同工作，从而形成便于用户使用的特定功能网络。UPnP架构支持了设备、服务的无缝联接、自动发现、零配置。UPnP这些优点都能为本发明所关注的工业检测系统所利用，本发明即建立于UPnP网络架构之中，并成为符合UPnP规范的一种数据库服务。\n[0014] 本发明的硬件环境为由数据采集卡、工控服务器、工业局域网、无线接入点、PDA组成的工控故障诊断网络环境。本发明软件部分由两个模块构成：数据库模块和网络中间件。\n[0015] 本发明解决其技术问题所采用的技术方案：这种故障诊断监控数据库服务实现方法，实现步骤如下：\n[0016] 第一步：建立数据库模块。\n[0017] 数据库模块使用开源、免费的MySQL，安装在嵌入式故障诊断与监控网络中的PC机上或数据服务器中，MySQL为本发明提供了可靠的数据库服务。在数据库中，我们建立所需的数据表格，用于存放故障诊断系统所设计的各种数据，包括被监控设备的运新状态数据、数据采集卡的配置数据等等。各个数据表之间通过某些表格索引建立一定的映射关系，这样使得用户在查询的时候只要提供最关键的几个查询条件，例如时间和设备号，就能够从各个数据表中找到相应的数据项，从而完整地恢复那个时刻的设备运行状态。\n[0018] 第二步：建立数据收集网络中间件模块。\n[0019] 负责数据收集的网络中间件模块是一个具有UPnP特性的模块，相当于一个内嵌式的UPnP控制点(Embedded UPnP ControlPoint)，主要完成对网络上的UPnP故障采集设备服务信息的侦听和记录，以及定时地逐一地访问网络中正在工作的UPnP故障采集设备，获取被监控机械的运行数据并保存到数据库中。本发明采用数据采集设备信息链表来记录故障诊断网络中存在的UPnP故障采集设备。该链表的每个节点都是一个数据采集设备信息结构体，用于存放数据采集设备的UPnP特征信息。通过这些特征信息，数据收集网络中间件模块便能在网络中定位某个数据采集设备并调用它所提供的服务。\n[0020] 在数据收集网络中间件模块，本发明采用了一种监听和定时调度相结合的算法：\n[0021] 1.数据收集网络中间件模块进程在完成初始化之后，进入阻塞等待(suspendedwaiting)状态，等待UPnP故障采集设备的登陆、离开以及定时器触发的定时中断信号。\n[0022] 2.当某个新的UPnP故障诊断设备登陆到网络中，数据收集网络中间件模块能监听到该设备发出的“登陆”消息，发现该设备，退出阻塞状态，获取该设备的UPnP特征信息及服务信息，记录到数据采集设备信息结构体中，并把该结构体插入到数据采集设备信息链表中。\n[0023] 3.当某个原来在线的UPnP故障诊断设备退出网络，数据收集网络中间件模块能监听到该设备发出的“退出”消息，从而退出阻塞状态，在数据采集设备信息链表中找到相应的节点，删除该节点。\n[0024] 4.当定时器触发的定时中断信号到达，数据收集网络中间件模块退出阻塞状态，访问数据采集设备信息链表，根据一个全局指针找到此次要访问的数据采集设备，读出它的信息，依此信息去定位并访问它的数据发布服务，得到数据包，连接数据库，把数据包存入相应的数据表中，然后更新全局指针，使其指向下一个准备访问的节点。\n[0025] 该监听和定时调度混合算法中，数据采集设备信息链表的容量和定时器周期长度都是可以根据不同的故障诊断网络的规模而设定，具有良好的适应性。\n[0026] 第三步：建立数据查询服务模块。\n[0027] 提供数据库查询服务的网络中间件模块是另一个具有UPnP特性的模块，相当于一个内嵌式的UPnP设备(Embedded UPnP Device)，主要向用户监控设备提供数据库信息，并根据用户提出的查询条件(如时间和设备号)进行预查询，然后向用户监控端反馈相关的数据信息(如“满足该条件的数据包个数”等等)。\n[0028] 本发明在数据查询服务模块中定义了查询信息结构体，用于存储预查询的条件及结果。不同的用户监控端对应不同的查询信息结构体，这些结构体节点形成一个预查询信息链表。\n[0029] 当用户监控端提出预查询请求，本模块在链表中查找该控制端对应的结构体节点，如果不存在这样的节点，则创建一个并插入到链表中。然后本模块解析预查询条件并将其存储在查询信息结构体中。当预查询完成，本模块把预查询结果写入到该节点的相应位置，同时把数据库的基本访问信息(如数据库IP、登陆名、密码等)写入到查询信息结构体中。\n[0030] 当用户监控端索取预查询结果，本模块首先在链表中找到相应节点，查看预查询完成情况，如果显示为未完成，则向用户控制端返回“预查询未完成”消息。如果显示为“已完成”，则把包含此次查询完整信息的查询信息结构体反馈给用户监控端。\n[0031] 通过维护预查询信息链表，本模块可以并行地为多个用户控制端提供数据查询服务。\n[0032] 通过数据库模块、数据收集网络中间件模块、数据查询服务模块的配合，本发明实现了对多个数据采集设备的数据收集、存储、发布的全流程自动化。\n[0033] 本发明具有如下优点：\n[0034] 1.支持网络架构的动态变化。由于UPnP网络中间件的支持，设备的加入和退出造成的数据库配置变化都是在数据库端自动完成，简化了因网络拓扑结构的变化而带来的注册、配置等工作，节约了数据库运行成本。\n[0035] 2.数据库采用轮询设备的方法，向网络中注册的多个数据采集设备索要数据，实现了自动的一对多服务。少量数据库服务节点就可以服务于整个故障诊断于监控网络的要求。\n[0036] 3.实现了数据库服务的零配置提供。用户无需事先知道数据库的方位和访问限制，就可以方便地访问并获得数据。\n[0037] 4.可以同时接受多个用户控制端的查询请求，实现了多用户并行查询。\n[0038] 5.如果用户提出的预查询条件不能匹配合适的数据包，本发明将在反馈中提出查询建议，帮助用户找到其关心的数据。\n附图说明\n[0039] 图1数据库服务节点的内部结构及其与外部的交互示意图；\n[0040] 图2UPnP设备信息循环链表示意图；\n[0041] 图3UPnPDeviceDiscoverSink函数流程图；\n[0042] 图4UPnPDeviceRemoveSink函数流程图；\n[0043] 图5AlarmAction函数流程图；\n[0044] 图6InsertDataPackageIntoDB函数流程图；\n[0045] 图7数据收集网络中间件模块main函数流程图；\n[0046] 图8预查询信息链表示意图；\n[0047] 图9handel_new_query_in_queue函数流程；\n[0048] 图10database_pre_query函数流程图；\n[0049] 图11“数据库预查询及数据回放”过程意图。\n具体实施方式\n[0050] 下面结合附图和实例对本发明作进一步介绍：\n[0051] 本发明实例为面向大型旋转设备的故障诊断系统，该系统由MSP430数据采集卡、Hp-5550-PDA用户监控端、工控机数据库服务节点、工业局域网组成；该系统被运用于冶金、水利等行业。本发明作为故障诊断网络中的一类节点，向整个网络提供网络数据库服务。\n[0052] 以下将介绍其中数据库服务的实现：\n[0053] ◆第一步：数据库服务节点内部结构设计\n[0054] 如图1所示，为数据库服务节点的内部结构及其与外部的交互示意图。数据库服务节点由MySQL数据库、数据收集网络中间件模块、数据查询服务模块三部分组成。数据收集网络中间件模块从数据采集设备获取数据，然后存储到MySQL数据库中。数据查询服务模块接受用户监控端的预查询请求，对MySQL数据库进行查询，将得到的结果反馈给用户控制端。\n[0055] ◆第二步：MySQL数据库设计\n[0056] 下面两表为MySQL数据库中的数据表。本发明实例针对大型旋转设备故障诊断的需求，在MySQL数据库中建立了两张数据表格：目标设备运行数据表格(PackageTable)和参数配置表表格(PCTTable)。\n[0057] Table1：PackageTable\n[0058] \n数据域 ID device_type device_id time pct_no data\n数据类型 int int int time int blog\n意义 表Key 设别类型 设备ID 采集时间 PCT序号 数据\n[0059] Table2：PCTTable\n[0060] \n数据域名 ID pct_no pet\n数据类型 int int blog\n意义 表Key PCT序号 参数配置表\n[0061] 数据库主要用于存储数据采集点采集并发布的设备运行时数据(DataPackage)，以及数据采集器的参数配置表(PCT)。两类数据之间通过参数配置表序号(PCT_no)建立联系，数据包到参数配置表存在映射关系：\n[0062] f(Package_no)＝PCT_no\n[0063] 每一个设备运行数据包都对应唯一的一个参数配置表。通过读取并加载相应的参数配置表，控制点才能够正确解析数据包实现历史回放功能。\n[0064] ◆第三步：数据收集网络中间件模块设计\n[0065] 如图2所示，为UPnP设备信息循环链表示意图。链表中的每个设备信息节点对应与一个UPnP数据采集设备，其中存储着该设备的UPnP特征信息和UPnP服务信息。有一个UPnP设备链表头指针，指向某个作为链表头的节点，仅当该节点被删除的时候该指针才被更改指向另一个节点。此外还有一个当前UPnP设备指针，指向下一次轮询时的数据来源设备。\n[0066] 如图3所示，为数据收集网络中间件模块中UPnPDeviceDiscoverSink函数流程图。该函数在有新数据采集设备进入网络的时候被执行，首先获取新数据采集设备的UPnP特征信息和UPnP服务信息并写入到一个UPnP设备信息结构体中，然后再将该结构体插入到UPnP设备信息循环链表中作为一个节点。\n[0067] 如图4所示，为数据收集网络中间件模块中UPnPDeviceRemoveSink函数流程图。\n该函数在某个数据采集设备从网络中退出的时候被执行，首先在UPnP设备信息循环链表中找到相应的节点，然后从链表中删除该节点并释放节点的空间。\n[0068] 如图5所示，为数据收集网络中间件模块中AlarmAction函数流程图。该函数在定时器alarm信号到达之后被执行，完成对某个数据采集设备的数据的收集和存储。首先，从当前UPnP设备指针所指的节点中读出UPnP设备特征信息，定位某个UPnP数据采集设备，然后访问该设备，调用其GetPackage服务得到数据包，存入数据库中，再读取数据包中的PCT_no信息，到PCTTable中查询是否有相应得PCT存在，若否，则调用该数据采集设备的GetPCT服务获取PCT并存储。\n[0069] 如图6所示，为数据收集网络中间件模块中InsertDataPackageIntoDB函数流程图。该函数被AlarmAction调用，完成将某个从数据采集设备中得到的数据包插入到MySQL数据库中的操作。首先从数据包中解析出一些信息，根据这些信息构造SQL语句，连接数据库，执行SQL语句将数据包插入数据库，最后关闭数据库连接。\n[0070] 如图7所示，为数据收集网络中间件模块main函数流程图。主函数在完成初始化工作之后进入阻塞等待状态，等待数据采集设备进入网络、离开网络的信号以及定时器出发的alarm信号，执行完相应的信号处理函数之后，再次回到阻塞等待状态。\n[0071] ◆第四步：数据查询服务模块设计\n[0072] 如图8所示，为预查询信息链表示意图。链表中的节点为预查询信息结构体，每个节点对应于一个控制端。结构体中存储着用户提出的预查询条件，并且在预查询执行过程中，数据查询服务模块将写入数据库连接信息和预查询结果，在这之后，整个结构体作为一次预查询的完整信息，将被反馈给对应得用户监控端。\n[0073] 如图9所示，为数据查询服务模块中的handel_new_query_in_queue函数流程图。\n该函数在数据查询服务模块接受到用户监控端提出的预查询请求后被执行，完成将新的查询条件插入到预查询信息链表中恰当位置的操作。首先遍历链表，找到该用户监控端对应的节点(通过ControlPoint_id来标识)，若无，则新建一个节点插入到链表中。然后，解析用户的请求，得到预查询条件，写入到该节点相应的位置中。\n[0074] 如图10所示，为数据查询服务模块中的database_pre_query函数流程图。该函数在预查询条件被写入到预查询信息链表之后被执行，完成对数据库的查询并将结果写入到预查询信息结构体中。首先，获取数据库的连接信息并写入到结构体中；然后查询PackageTable中数据包的存在性，查询这些数据包的一致性，查询PCTTable中参数配置表的存在性，将这些查询的结果写入到结构体中；最后将该结构体反馈给用户监控端。\n[0075] ◆第五步：用户监控端和数据库查询服务模块之间的配合流程设计[0076] 如图11所示，为“数据库预查询及数据回放”过程中用户监控端和数据库查询服务模块的流程配合示意图。其流程如下：\n[0077] 1.用户在PDA或PC机的用户监控端图形界面中选择某个数据库服务节点，输入预查询条件(设备号、数据包起止时间)。\n[0078] 2.用户监控端调用数据库查询服务模块的服务，将预查询条件提交。\n[0079] 3.数据库查询服务模块得到预查询条件，解析并保存到查询信息链表中。\n[0080] 4.数据库查询服务模块根据预查询条件，调用database_pre_query函数去查询数据库，并将查询结果写入查询信息链表中。\n[0081] 5.用户监控端向数据库查询服务模块提出获取预查询结果的请求，数据库查询服务模块向其返回预查询信息结构体，其中包含了数据库连接信息和预查询结果。\n[0082] 6.用户监控端解析预查询结果，并在图形界面中提示下一步可进行的操作。\n[0083] 7.如果可以进行“历史数据回放”，则利用从查询信息结构体中得到的数据库连接信息，建立与数据库的连接。\n[0084] 8.访问PCTTable，得到PCT，并载入到用户监控端系统中。\n[0085] 9.开始循环地向数据库中PackageTable索取数据包，解析得到的数据包并在图形界面显示，进行“历史数据回放”。\n[0086] 10.若用户停止历史数据查询，则推出循环，结束。