《一种轨道交通监测数据的存储和处理方法及系统.pdf》由会员分享，可在线阅读，更多相关《一种轨道交通监测数据的存储和处理方法及系统.pdf（20页珍藏版）》请在专利查询网上搜索。
1、10申请公布号CN103338261A43申请公布日20131002CN103338261ACN103338261A21申请号201310279514022申请日20130704H04L29/08200601G06F17/3020060171申请人北京泰乐德信息技术有限公司地址100080北京市海淀区知春路51号慎昌大厦5225室72发明人鲍侠74专利代理机构北京君尚知识产权代理事务所普通合伙11200代理人余长江54发明名称一种轨道交通监测数据的存储和处理方法及系统57摘要本发明涉及一种轨道交通监测数据的存储和处理方法及系统，首先在车站、电务段及铁路管理部门设立集中监测系统；车站的集中监测系。
2、统采集各类监测数据，电务段的集中监测系统收集车站集中监测系统采集的各类监测数据；在一综合运维平台上建立HDFS分布式文件系统、HBASE和ORACLE数据库以及MAPREDUCE并行处理架构，形成云计算平台，进而对所述监测数据进行存储和分析挖掘，产生知识规则数据和各类统计信息；铁路管理部门的集中监测系统产生调度指挥命令并反馈给电务段的集中监测系统。本发明采用云存储技术以及并行处理架构，提高了轨道交通资源和数据的存储和分析处理效率，保证了数据的安全性和高可用性。51INTCL权利要求书2页说明书12页附图5页19中华人民共和国国家知识产权局12发明专利申请权利要求书2页说明书12页附图5页10申。
3、请公布号CN103338261ACN103338261A1/2页21一种轨道交通监测数据的存储和处理方法，其步骤包括1）在车站、电务段及铁路管理部门分别设立集中监测系统，在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接；2）车站的集中监测系统采集各类监测数据，电务段的集中监测系统收集本电务段包含的车站集中监测系统采集的各类监测数据，并传输给一综合运维平台；3）在所述综合运维平台上建立HDFS分布式文件系统、HBASE数据库、ORACLE数据库以及MAPREDUCE并行处理架构，形成云计算平台；通过该云计算平台对所述监测数据进行存储和分析挖掘，产生知识规则数据和。
4、各类统计信息，并将所述各类统计信息反馈至电务段的集中监测系统；4）电务段的集中监测系统将收到的所述各类统计信息传输给铁路管理部门的集中监测系统，铁路管理部门的集中监测系统根据所述各类统计信息产生调度指挥命令，并反馈给电务段的集中监测系统。2如权利要求1所述的方法，其特征在于所述云计算平台包括资源层、数据处理层和接口层，所述资源层包括物理资源和虚拟资源，所述HDFS分布式文件系统、HBASE数据库、ORACLE数据库以及MAPREDUCE并行处理架构位于所述数据处理层上，所述接口层包括各种WEBSERVICE服务器。3如权利要求2所述的方法，其特征在于所述虚拟资源通过虚拟化技术对物理资源进行虚拟。
5、化产生，包括计算资源池、存储资源池和网络资源池。4如权利要求1或2所述的方法，其特征在于所述监测数据包括历史监测数据和实时监测数据。5如权利要求4所述的方法，其特征在于所述云计算平台将获取的历史监测数据转换为文本格式存储在HDFS上，并利用MAPREDUCE并行处理架构对HDFS上存储的历史监测数据建立全文索引，结合发布引擎实现对监测数据的碎片查询。6如权利要求4所述的方法，其特征在于所述云计算平台通过MAPREDUCE并行处理架构对历史监测数据进行数据挖掘，产生所述知识规则数据并存储在HBASE数据库中；所述云计算平台将接收到的实时监测数据与所述知识规则数据进行匹配并进行统计分析，生成所述各。
6、类统计信息。7如权利要求6所述的方法，其特征在于所述云计算平台利用统计学原理对历史监测数据进行统计，形成监测信号与故障之间的先验及后验概率，作为故障知识规则数据；进而将实时监测数据及相应的故障知识规则数据进行对比，判断当前系统是否存在安全隐患。8如权利要求1或2所述的方法，其特征在于，所述车站集中监测系统采集如下一种或多种设备的监测数据TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSMR无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。9如权利要求1或2所述的方法，其特征在于所述铁路管理部门包括铁路局和铁路总公司，铁路局的集中监测系统接收所述各类统计信息，并产。
7、生所述调度指挥命令反馈给电务段的集中监测系统；铁路局的集中监测系统还将各类统计信息传输给铁路总公司的集中监测系统。10一种轨道交通监测数据的存储和处理系统，其特征在于，包括分别位于车站、电务权利要求书CN103338261A2/2页3段及铁路管理部门的集中监测系统，在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接；电务段的集中监测系统还连接一综合运维平台；车站的集中监测系统负责采集各类监测数据；所述综合运维平台为一云计算平台，其上建立HDFS分布式文件系统、HBASE数据库、ORACLE数据库以及MAPREDUCE并行处理架构，负责从电务段的集中监测系统接收所。
8、述监测数据进行存储和分析挖掘，产生知识规则数据和各类统计信息，并将所述各类统计信息反馈至电务段的集中监测系统；电务段的集中监测系统负责收集本电务段包含的车站集中监测系统采集的各类监测数据并传输给所述综合运维平台，以及从所述综合运维平台接收所述各类统计信息并传输给铁路管理部门的集中监测系统；铁路管理部门的集中监测系统负责根据所述各类统计信息产生调度指挥命令，并反馈给电务段的集中监测系统。11如权利要求10所述的系统，其特征在于所述云计算平台包括资源层、数据处理层和接口层，所述资源层包括物理资源和虚拟资源，所述HDFS分布式文件系统、HBASE数据库、ORACLE数据库以及MAPREDUCE并行处。
9、理架构位于所述数据处理层上，所述接口层包括各种WEBSERVICE服务器。12如权利要求10或11所述的系统，其特征在于在电务段和铁路管理部门还设有与所述集中监测系统连接的人机交互设备。13如权利要求10或11所述的系统，其特征在于，所述车站集中监测系统连接如下一种或多种设备以采集监测数据TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSMR无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。14如权利要求10或11所述的系统，其特征在于，所述铁路管理部门包括铁路局和铁路总公司，铁路局的集中监测系统负责接收所述各类统计信息，并产生所述调度指挥命令反馈给电务段的集中。
10、监测系统；铁路局的集中监测系统还负责将各类统计信息传输给铁路总公司的集中监测系统。权利要求书CN103338261A1/12页4一种轨道交通监测数据的存储和处理方法及系统技术领域0001本发明提供一种轨道交通监测数据的存储和处理方法及系统，涉及铁路信号数据、铁路通信数据、铁路知识数据、系统报警数据、云计算、云存储、并行计算等技术领域，解决了现有技术中快速膨胀的铁路监测数据的存储及数据处理问题。背景技术0002现有的轨道交通监测数据的存储方案，是将各个电务段的历史监测数据分别存储在各个电务段中，对数据的分析和挖掘也是各个电务段进行处理的。0003如图1所示，该现有的存储系统包括位于电务车间或工区。
11、中的集中监测系统（CSM）数据处理服务器11；位于各站点电务段监测中心的数据分析服务器12、人机交互输入输出设备15和监测数据库16；位于铁路局电务处总监测中心的知识库存储设备19、系统诊断服务器10和人机交互输入输出设备15。其中，集中监测系统数据处理服务器11与位于同一电务车间或工区中的用于监测铁路信号的集中监测设备13连接，集中监测系统数据处理服务器11与数据分析服务器12连接；数据分析服务器12与本电务段的人机交互输入输出设备15、本电务段的监测数据库16和铁路局电务处总监测中心的知识库存储设备19连接；知识库存储设备19与系统诊断服务器10连接，系统诊断服务器10与位于铁路局电务处总。
12、监测中心的人机交互输入输出设备15连接。0004上述系统中，集中监测系统数据处理服务器11、数据分析服务器12和系统诊断服务器10可以采用现有的集中监测设备或服务器实现；知识库存储设备19可以采用普通的存储设备实现；人机交互输入输出设备15可以是显示器、键盘和鼠标组成的输入输出设备，也可以是具有触摸功能的显示器用作输入输出设备均可。0005上述系统中，集中监测系统数据处理服务器11将位于同电务车间或工区中集中监测设备13的历史铁路信号监测数据采集并发送到监测数据库16；数据分析服务器12对这些铁路历史监测数据进行预处理后，整理出知识规则并传输到知识库存储设备19。同时，集中监测系统数据处理服务。
13、器11还将各集中监测设备13实时监测到的铁路信号监测数据采集并发送到系统诊断服务器10。系统诊断服务器10对这些实时的铁路信号监测数据进行预处理后，结合知识库存储设备19中的知识数据，得到诊断结果，并通过人机交互输入输出设备15，将诊断结果展示给用户。此外，各电务段监测中心的数据分析服务器也可以通过人机交互输入输出设备15将集中监测系统数据处理服务器11上报的监测数据和系统诊断规则等展示给用户。0006上述轨道交通监测数据的传统存储方案有以下缺陷00071）成本高传统的存储方案要求各个车间/站点的监测数据存储在各电务段的数据库中，对监测数据的分析和挖掘也存放在各个电务段分别进行。这就要求各个电。
14、务段需要配置性能较高的服务器及存储设备，同时需要雇佣专门设备维护人员。00082）资源利用率低当电务段对监测数据进行知识挖掘（如故障规则）的频率较低时，电务段的数据分析服务器大多数时间处于闲置状态。说明书CN103338261A2/12页500093）数据关系利用率低因为各个电务段的监测数据是单独存储的，因此各个电务段的数据进行分析和挖掘时也是隔离的，这就使得挖掘得到的知识受限于本电务段。00104）数据冗余各个电务段单独存储本电务段的数据资源，并且还需要存储部分重复的数据，这样增加了数据的冗余。00115）不支持并行计算及按线路、电务段等方式的信息查询。发明内容0012本发明的目的是针对上述。
15、问题，提供一种轨道交通监测数据的存储和处理方法及系统，通过云平台、云存储技术提高各种资源和轨道交通监测数据的存储和分析处理效率。0013为实现上述目的，本发明采用的技术方案如下0014一种轨道交通监测数据的存储和处理方法，其步骤包括00151）在车站、电务段及铁路管理部门分别设立集中监测系统，在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接；00162）车站的集中监测系统采集各类监测数据，电务段的集中监测系统收集本电务段包含的车站集中监测系统采集的各类监测数据，并传输给一综合运维平台；00173）在所述综合运维平台上建立HDFS分布式文件系统、HBASE数据库。
16、、ORACLE数据库以及MAPREDUCE并行处理架构，形成云计算平台；通过该云计算平台对所述监测数据进行存储和分析挖掘，产生知识规则数据和各类统计信息，并将所述各类统计信息反馈至电务段的集中监测系统；00184）电务段的集中监测系统将收到的所述各类统计信息传输给铁路管理部门的集中监测系统，铁路管理部门的集中监测系统根据所述各类统计信息产生调度指挥命令，并反馈给电务段的集中监测系统。0019进一步地，所述云计算平台包括资源层、数据处理层和接口层，所述HDFS分布式文件系统、HBASE数据库、ORACLE数据库以及MAPREDUCE并行处理架构位于所述数据处理层上。0020更进一步地，所述资源层。
17、包括物理资源和虚拟资源，所述虚拟资源通过虚拟化技术对物理资源进行虚拟化产生，包括计算资源池、存储资源池和网络资源池；所述接口层包括各种WEBSERVICE服务器。0021进一步地，所述监测数据包括历史监测数据和实时监测数据；所述云计算平台将获取的历史监测数据转换为文本格式存储在HDFS上，并利用MAPREDUCE并行处理架构对HDFS上存储的历史监测数据建立全文索引，结合发布引擎实现对监测数据的碎片查询；所述云计算平台通过MAPREDUCE并行处理架构对历史监测数据进行数据挖掘，产生所述知识规则数据并存储在HBASE数据库中；所述云计算平台将接收到的实时监测数据与所述知识规则数据进行匹配并进行。
18、统计分析，生成所述各类统计信息。0022进一步地，所述云计算平台利用统计学原理对历史监测数据进行统计，形成监测信号与故障之间的先验及后验概率，作为故障知识规则数据；进而将实时监测数据及相应的故障知识规则数据进行对比，判断当前系统是否存在安全隐患。0023进一步地，所述车站集中监测系统采集如下一种或多种设备的监测数据TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSMR无线网信号安全网、CTC中心、说明书CN103338261A3/12页6DMS/LAIS、RBC/TSRS。0024进一步地，所述铁路管理部门包括铁路局和铁路总公司，铁路局的集中监测系统接收所述各类统计信息，并产生。
19、所述调度指挥命令反馈给电务段的集中监测系统；铁路局的集中监测系统还将各类统计信息传输给铁路总公司的集中监测系统。0025一种轨道交通监测数据的存储和处理系统，包括分别位于车站、电务段及铁路管理部门的集中监测系统，在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接；所述电务段集中监测系统还连接一综合运维平台；0026车站的集中监测系统负责采集各类监测数据；0027所述综合运维平台为一云计算平台，其上建立HDFS分布式文件系统、HBASE数据库、ORACLE数据库以及MAPREDUCE并行处理架构，负责从电务段的集中监测系统接收所述监测数据进行存储和分析挖掘，产生各。
20、类统计信息和知识规则，并将所述各类统计信息反馈至电务段的集中监测系统；0028电务段的集中监测系统负责收集本电务段包含的车站集中监测系统采集的各类监测数据并传输给所述综合运维平台，以及从所述综合运维平台接收所述各类统计信息并传输给铁路管理部门的集中监测系统；0029铁路管理部门的集中监测系统负责根据所述各类统计信息产生调度指挥命令，并反馈给电务段的集中监测系统。0030进一步地，所述综合运维平台包括资源层、数据处理层和接口层；所述资源层包括物理资源和虚拟资源，所述数据处理层包括HDFS分布式文件系统、HBASE和ORACLE数据库及MAPREDUCE并行处理架构，用于数据存储和数据并行处理；所。
21、述接口层包括各种WEBSERVICE服务器。0031进一步地，所述虚拟资源包括通过虚拟化技术对物理资源进行虚拟化产生的计算资源池、存储资源池和网络资源池。0032进一步地，在电务段和铁路管理部门还设有与所述集中监测系统连接的人机交互设备。0033进一步地，所述车站集中监测系统连接如下一种或多种设备以采集监测数据TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSMR无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。0034进一步地，所述铁路管理部门包括铁路局和铁路总公司，铁路局的集中监测系统负责接收所述各类统计信息，并产生所述调度指挥命令反馈给电务段的集中监测系统。
22、；铁路局的集中监测系统还负责将各类统计信息传输给铁路总公司的集中监测系统。0035本发明的轨道交通监测数据的存储和处理系统及方法包括监测数据采集、数据存储、数据处理和系统运行状态分析等功能。该方案利用HDFS分布式文件系统、HBASE数据库、ORACLE数据库对监测数据的不限量存储；利用MAPREDUCE对监测数据进行并行数据挖掘和分析，快速高效的产生各种统计信息和知识规则；通过全文索引技术，对监测数据进行索引监理，并通过发布对应的查询接口实现碎片查询。0036本发明通过云存储技术提高资源和数据的利用率，各个电务段不需要计算和存储能力较强的服务器，只需要普通的终端交互设备即可。在总监测中心的数。
23、据中心（即所述云计算平台）配备性能强大的服务器和存储设备，用于搭建分布式文件系统、数据仓库和并行说明书CN103338261A4/12页7处理系统。采用云平台的优势如下0037动态伸缩云平台有良好的扩展性能，平台可以随着数据量和计算量的增减动态的添加和删除存储节点和计算节点；0038负载均衡技术云平台的负载均衡组件可以根据各个存储节点和计算节点的负载情况，动态的分配存储和计算任务，提供资源的利用率和数据的处理速度；0039数据安全性数据中心的云平台可以通过简单的配置实现数据的备份和恢复；0040数据关系挖掘各个电务段的监测数据都汇总到运维中心的云平台，通过数据挖掘算法可以挖掘分析各个电务段数据。
24、之间的关系；0041碎片查询通过全文检索技术，对历史监测数据建立索引，以支持用户按照不同的方式，如时间、线路查询系统信息；0042云存储方案通过数据中心的建设，节省了设备和维护人员的成本，并且通过并行计算和分布式存储技术，提高了数据的安全性、数据存储的能力和数据处理的速度。0043本发明通过云平台强大的扩展能力对不断增长的监测数据进行存储。监测数据是随着时间的增长而不断增加，当数据增长到一定量的时候，传统的基于关系型数据库的存储方案，会面临数据分片、系统存储能力不足等问题，需要花费很大的成本。但是云存储方案可以根据存储量的需要，通过简单的配置增加存储空间，以满足动态增长的数据存储的需要。004。
25、4本发明的云计算平台自身提供了并行处理架构，在对海量的监测数据进行分析和挖掘的时候，编程人员只需要关注与业务逻辑也不需要关注底层的资源调度等问题，就可以实现并行任务。本发明的云计算平台通过本身的数据冗余、数据恢复等策略，保证了数据的安全性和高可用性。附图说明0045图1是现有的轨道交通监测数据存储系统的架构示意图。0046图2是本发明实施例的轨道交通监测数据的存储和处理系统示意图。0047图3是本发明实施例的综合运维平台的构成示意图。0048图4为本发明实施例的对轨道交通监测数据进行云存储及数据分析处理的流程图。0049图5为本发明实施例中应用贝叶斯定理进行故障知识规则挖掘的流程图。0050图。
26、6为本发明实施例中应用贝叶斯定理进行故障数据的统计分析的流程图。0051图7为本发明实施例中云计算平台对TCC采集数据的存储流程图。0052图8为本发明实施例中云计算平台对TCC实时采集数据的挖掘处理流程图。具体实施方式0053下面通过具体实施例和附图，对本发明做详细的说明。0054如图2所示，本实施例的轨道交通监测数据的存储和处理系统由以下部分组成现有各车间、电务段、铁路局、铁道部的集中监测系统；综合运维平台，为一云计算平台。下面分别进行说明。00551、各车间、电务段、铁路局和铁路总公司的集中监测系统说明书CN103338261A5/12页80056包括位于电务车间或工区中的集中监测系统（。
27、信号集中监测），即车站集中监测系统；位于各站点电务段的集中监测系统及人机交互设备；位于铁路局的集中监测系统；位于铁路总公司的集中监测系统。其中，车站集中监测系统与电务段集中监测系统连接；电务段集中监测系统与电路局集中监测系统连接；电路局集中监测系统与铁路总公司集中监测系统连接；电务段集中监测系统与综合运维平台连接。其中，铁路局和铁路总公司也可设立与集中监测系统连接的人机交互设备。该“综合运维平台”可以由不同的运维主体进行维护，比如设备厂商、中国的铁路总公司等专业的铁路行业运维企业等。0057车站集中监测系统负责采集各类监测数据，包括TCC/CBI（列控中心/计算机联锁）、轨道电路应答器、CTC。
28、站机电源屏、信号安全网、GSMR无线网信号安全网、CTC中心（调度集中）及、DMS/LAIS（列控设备动态监测系统/列车运行状态系统）、RBC/TSRS（无线闭塞/临时限速服务器）、车载ATP（车载计算机）等设备的监测数据；并将采集的数据通过与电务段集中监测系统的连接传输给电务段集中监测系统；并接受来自电务段集中监测系统的各类维修计划、指挥命令。0058电务段集中监测系统负责收集本电务段包含的车站的集中监测系统的采集的监测信息，通过电务段集中监测系统与综合运维平台连接，将数据传输给运维平台；运维平台通过对数据的分析挖掘，将产生的各类统计信息反馈给电务段集中监测系统；电务段集中监测系统将各类统计。
29、信息传输给铁路局集中监测系统，并接收铁路局集中监测系统发出的调度指挥命令。0059铁路局集中监测系统负责接受来自电务段集中监测系统传输的各类统计信息，并通过人工或者机器分析的方式产生一些调度指挥命令，并发反馈给电务段集中监测系统；铁路局集中监测系统也会将部分或全部统计信息传输给铁路总公司的集中监测系统。0060铁路总公司的集中监测系统用来接收各类统计信息，也可以查询权限下线路、电务段的信息，并可以根据这些信息下达各种命令。0061需要说明的是，上述实施例中的铁路局和铁路总公司是针对中国的铁路交通管理部门而采取的对应的方案，但本发明并不限于此，在其它实施例中也可以是其它各国不同类型的铁路管理部门。
30、。上述实施例中的“电务段”适用于中国国家铁路体系，本发明亦不以此为限制，本发明的方案也适用于企业铁路、城市轨道交通等铁路运营体系，此时电务段可采用其它名称，如信号段、通信段等。00622、综合运维平台的云计算平台0063该云计算平台包含硬件资源和软件资源两部分，按照层次划分包括资源层、数据处理层和接口层，如图3所示。0064资源层资源层包括物理资源和虚拟资源两部分，物理资源指实际的运行环境，包括计算节点、存储节点和网络资源。虚拟资源主要是指通过虚拟化技术对平台的物理资源进行虚拟化，产生的计算资源池、存储资源池和网络资源池。0065数据处理层数据处理层主要包括HDFS分布式文件系统、HBASE和。
31、ORACLE数据库及MAPREDUCE并行处理架构，分别用于数据存储和数据并行处理。0066接口层接口层主要包括在虚拟机之上部署的各种WEBSERVICE服务器，用于接收来自电务段集中监测系统的监测数据并对其进行格式转换和存储；对HDFS上的数据建立索引及数据挖掘；根据实时监测数据进行信息统计和故障监测等；发布碎片索引系统，客说明书CN103338261A6/12页9户可以根据需要查询相关的数据。0067本发明的技术重点在于云计算平台的搭建和应用，主要的功能模块包括物理资源、虚拟资源、HDFS分布式文件系统、HBASE列式数据库、MAPREDUCE并行处理架构、ORACLE实时应用集群及资源接。
32、口层的WEBSERVICE服务器集群。0068下面具体介绍云计算平台的搭建过程0069（1）操作系统技术人员首先部署CENTOS服务器版操作系统；0070（2）虚拟机通过安装KVM虚拟化软件对底层的计算资源、存储资源和网络资源进行虚拟化和管理，通过对资源的虚拟化形成虚拟化资源池，包括计算资源池、存储资源池和网络资源池，用于部署云计算平台的各个软件系统和存储系统；0071（3）HADOOP在虚拟化集群上部署HADOOP开源云计算架构，包括HDFS分布式文件系统，MAPREDUCE并行计算架构；通过对虚拟机的克隆、备份等操作，可以十分容易的对HADOOP集群进行扩展；当需要增加HADOOP集群的计。
33、算、存储能力时，只需要启动新的已经配置好的HADOOPSLAVE节点，然后将节点添加到集群中即可完成对集群计算和存储能力的扩展；0072（4）HBASE在HDFS上部署HBASE列式数据库，用于存储和处理知识规则等数据；HBASE可以借助HDFS良好的扩展性，实现对系统存储能力的扩展，不需要对HBASE做单独的配置；0073（5）ORACLERAC（ORACLE实时应用集群）ORACLE10G以上的版本可以配置实时响应集群，在低版本的服务器上构建高可用性数据库系统，并自由部署应用。并且可以实现负载均衡、高可用、并行事务处理和良好的扩展性；0074（6）WEBSERVICE集群在虚拟机上搭建基于。
34、AXIS2、NGNIX和APACHE的WEBSERVICE的系统，通过SOAP协议的方式接收客户端发送的数据及服务请求；0075图4为应用上述系统对轨道交通监测数据进行云存储及数据分析处理的流程图，包括监测数据采集、数据存储、数据处理和系统运行状态分析几个功能0076（1）监测数据采集0077监测数据的采集通过与车站集中监测系统直接连接的各种采集器。以TCC采集器为例，车站集中监测系统可以直接获取TCC采集器的历史及实时监测数据。云计算平台通过与电务段集中监测系统的连接，发送监测数据请求，电务段通过与车站的连接将TCC采集器的历史及实时采集数据传输给云计算平台的数据接收及格式转换模块。0078。
35、（2）监测数据存储对监测数据的存储分为两种，分别是历史监测数据和实时监测数据；0079A）历史监测数据存储0080云计算平台对历史监测数据进行存储和知识规则挖掘，只需要在部署的时候请求一次历史监测数据即可，之后的数据则采用实时监测数据采集的方式汇总到云计算平台的存储系统中。0081B）实时监测数据存储0082云计算平台对实时监测数据除了进行存储之外，还需要对监测数据进行统计和规则匹配，产生系统运行状态诊断信息。0083数据接收及格式转换模块接收到来自电务段集中监测系统的监测数据后，解析数说明书CN103338261A7/12页10据的格式，确定监测数据的设备及监测值，然后将数据插入到ORACL。
36、E对应的数据库中，并将监测数据转换为文本存储在HDFS文件系统中。0084（3）监测数据处理0085对监测数据的处理分为两种，一种是定期的对云平台的监测数据进行建立索引和知识规则挖掘；第二种是对实时采集的监测数据进行统计和规制匹配。0086A）监测数据索引建立数据接收及格式转换模块将获取的历史监测数据转换为文本格式存储在HDFS上，云计算平台利用MAPREDUCE并行处理模块定期（如一天）对HDFS上存储的监测数据结合LUCENE对监测数据建立全文索引，结合发布引擎，实现对监测数据的碎片查询。0087B）监测数据挖掘云计算平台定期通过MAPREDUCE并行处理架构对历史监测数据进行数据挖掘，产。
37、生知识规则数据，并将这部分数据存储在HBASE列式数据库中。0088MAPREDUCE并行处理架构主要包括MAP和REDUCE两个阶段，HDFS上的文本监测数据作为输入数据，通过MAP阶段将文本分为与计算节点相同数目的文本块，然后对这些文本块用不同的处理器进行运算，将产生的中间结果通过REDUCE节点进行汇总，从而产生知识规则数据。将这些规则数据存储在HBASE列式数据库中，便于建立索引、快速查询及动态扩容。0089知识规则的产生根据不同的信号和应用需求采用不同的数据挖掘算法，常用的如朴素贝叶斯算法（贝叶斯分类的基础是概率推理，就是在各种条件的存在不确定，仅知其出现概率的情况下，如何完成推理和。
38、决策任务）。0090以故障检测为例，为了产生故障知识规则数据，则需要对历史监测信号（如车载ATP信号）进行分析，利用统计学原理对信号数据进行统计，形成监测信号与故障之间的先验及后验概率，也就是故障知识规则数据。下面以故障监测为例，结合朴素贝叶斯分类器算法详细介绍故障知识挖掘及实时数据分析的流程。0091首先介绍贝叶斯定理。贝叶斯定理是关于随机事件A和B的条件概率的一则定理，即00920093其中PA|B是在B发生的情况下A发生的可能性，各概率值的含义具体解释如下0094PA是A的先验概率。之所以称为“先验“是因为它不考虑任何B方面的因素；0095PA|B是已知B发生后A的条件概率，也由于得自B。
39、的取值而被称作A的后验概率；0096PB|A是已知A发生后B的条件概率，也由于得自A的取值而被称作B的后验概率；0097PB是B的先验概率。0098本发明应用贝叶斯定理进行故障知识规则挖掘A表示故障发生，PA表示故障发生的概率；B代表的是与故障发生相关的信号量的集合；PB是每个信号量采集得到的对应的概率，其中B是一系列信号的取值；PB/A代表在故障发生时，B取值的一些概率。说明书CN103338261A108/12页11这些都是可以从历史监测数据中统计出来的。0099采集的历史监测数据以文本方式保存在HDFS上，在进行处理之前先对数据进行分片，分片的数量等于云平台上HADOOP计算节点的个数，。
40、然后使用MAPREDUCE进行处理（进行知识挖掘），分为两个阶段MAP阶段和REDUCE阶段，如图5所示0100MAP阶段该阶段完成对输入数据的读取及预处理，并计算各个文件的PA，PB等概率值；REDUCE阶段该阶段接受MAP阶段的输出结果，并对结果进行合并，计算全局的PA、PB和PB/A。0101C）实时监测数据的统计及规则匹配0102数据接收机格式转换模块将接收到的实时监测数据与规则库的数据进行匹配并进行统计分析，生成统计信息及系统状态信息（如故障规则可以判断系统是否存在安全隐患），并将这些信息反馈给集中监测系统。0103仍以故障检测为例，云平台将实时监测数据及HBASE中相应的故障知识规。
41、则数据进行对比，根据后验概率和实时信号数据的对比，判断当前系统是否存在故障等安全隐患。0104具体来说，在预测的时候，需要根据实时数据也就是B（信号序列）预测A（故障）发生的概率，根据贝叶斯公式知P（故障/信号）P（信号/故障）P（故障）/P（信号），其中与故障相关的信号可能包含多个信号BB1B2B3BN，根据朴素贝叶斯的独立性假设，各个信号量之间出现的概率是没有关系的，因此P（B）P（B1）P（B2）PBNPA/BPAB/PBPB/APA/PB，并且PA、PB、PB/A都已经计算出来了，并且存储在HBASE数据库中，根据实时监测数据和HBASE中的先验后验概率，即可以求出统计信息和故障数据，。
42、具体流程如图6所示。0105下面进一步以TCC信号为例来描述上述各个模块之间的关系和数据流程0106TCC（列控中心）信号库包含三个表，分别是系统状态表，如表1所示，通信状态表，如表2所示，系统报警表，如表3所示。三个表之间互相联系，系统状态表中任何一个状态故障时会对应系统报警表中的一条记录，通信状态表也是如此。0107表1系统状态表0108指标值I系主机工作状态主用、备、离线II系主机工作状态主、备、离线I系驱采机工作状态正常、故障II系驱采机工作状态正常、故障I系通信机工作状态正常、故障II系通信机工作状态正常、故障I系板卡工作状态（各厂家自定义）正常、故障II系板卡工作状态（各厂家自定义。
43、）正常、故障说明书CN103338261A119/12页120109表2通信状态表0110指标值I系与联锁I系通信状态正常、故障I系与联锁II系通信状态正常、故障II系与联锁I系通信状态正常、故障II系与联锁II系通信状态正常、故障I系与TSRSI系通信状态正常、故障I系与TSRSII系通信状态正常、故障II系与TSRSI系通信状态正常、故障II系与TSRSII系通信状态正常、故障I系与相邻TCCI系通信状态正常、故障I系与相邻TCCII系通信状态正常、故障II系与相邻TCCI系通信状态正常、故障II系与相邻TCCII系通信状态正常、故障I系与CTCI系通信状态正常、故障I系与CTCII系通信。
44、状态正常、故障II系与CTCI系通信状态正常、故障II系与CTCII系通信状态正常、故障I系与轨道电路通信状态正常、故障II系与轨道电路通信状态正常、故障I系与LEU通信状态正常、故障II系与LEU通信状态正常、故障I系与继电器通信状态正常、故障II系与继电器通信状态正常、故障说明书CN103338261A1210/12页130111表3系统报警表0112I系与联锁I系通信故障I系与继电器通信故障I系与联锁II系通信故障II系与继电器通信故障II系与联锁I系通信故障LDJ驱动、采集不一致II系与联锁II系通信故障UDJ驱动、采集不一致I系与TSRSI系通信故障HDJ驱动、采集不一致I系与TSR。
45、SII系通信故障1DJ断丝报警II系与TSRSI系通信故障2DJ断丝报警II系与TSRSII系通信故障轨道状态通信、采集不一致I系与相邻TCCI系通信故障轨道状态通信、采集不一致I系与相邻TCCII系通信故障区间线路方向驱动、采集不一致II系与相邻TCCI系通信故障区段灾害状态告警II系与相邻TCCII系通信故障红灯断丝报警I系与CTCI系通信故障I系主机离线报警I系与CTCII系通信故障II系主机离线报警II系与CTCI系通信故障I系驱采机故障报警II系与CTCII系通信故障II系驱采机故障报警I系与轨道电路通信故障I系通信机故障报警II系与轨道电路通信故障II系通信机故障报警I系与LEU通。
46、信故障I系板卡故障报警II系与LEU通信故障II系板卡故障报警0113云平台通过存储和处理这些信号数据，挖掘知识规则；然后通过与实时监测数据的对比进行系统状态的统计和辅助决策。0114（1）TCC信号库的数据存储流程0115下面通过图7所示的数据流程图来介绍云计算平台对TCC采集数据的存储流程0116A）由云计算平台发起对TCC历史监测数据的请求，通过云计算平台与电务段集中说明书CN103338261A1311/12页14监测系统的连接，将请求转发给本电务段各个车站监测系统；0117B）车站集中监测系统直接与车站的各个监测信号采集器连接，直接向TCC采集器发出历史数据采集请求；0118C）TC。
47、C采集器将本地存储的历史监测数据通过电务段集中监测系统转发给云计算平台；0119D）云计算平台的数据接收及格式转换模块将得到的TCC历史监测数据进行格式转换，分别以格式化的方式存储在ORACLE集群及文本格式存储在HDFS上；0120E）云计算平台的MAPREDUCE并行处理架构对HDFS上的历史监测数据进行数据分析和挖掘，到的通信信息及知识规则存储在HBASE列式数据库中；0121F）云计算平台通过部署的LUCENE对得到的历史监测数据进行索引建立，根据不同的关键字生成多种索引文件，包括时间、车站、线路等均需要生成对应的索引文件。0122LUCENE是建立在HADOOP之上的开源索引工具，可。
48、以通过并行的方式完成对HDFS上的文本数据建立索引。0123（2）TCC实时监测数据处理流程0124下面通过图8所示的数据流程图介绍云计算平台对TCC实时采集数据的处理0125A）TCC采集器定期通过集中监测系统将实时采集的监测数据传输给云计算平台；0126B）云计算平台的数据接收及格式转换模块将接收的TCC实时监测数据传输给实时数据分析模块；0127C）实时数据分析模块通过对实时监测数据的与HBASE中知识规则及统计信息的比较及分析，得到TCC对应的系统状态、通信状态及系统报警状态的统计及分析结果；0128D）云计算平台通过与电务段的连接将系统实时分析结果反馈给集中监测系统；0129E）集中。
49、监测系统则根据权限将实时的系统状态通过人机交互设备反馈给系统管理人员，管理人员可以根据目前的系统运行状态分发调度指令、维修指令等。0130下面进一步以车载ATP（车载计算机）信号为例来描述上述各个模块之间的关系和数据流程0131（1）ATP数据存储流程0132A）由云计算平台发起对车载ATP历史监测数据的请求，通过云计算平台与电务段集中监测系统的连接，将请求转发给本电务段各个车站监测系统。0133B）车站集中监测系统直接与车站的车载ATP监测信号采集器连接，直接向车载ATP采集器发出历史数据采集请求。0134C）车载ATP采集器将本地存储的历史监测数据通过电务段集中监测系统转发给云计算平台。0。
50、135D）云计算平台的数据接收及格式转换模块将得到的车载ATP历史监测数据进行格式转换，分别以格式化的方式存储在ORACLE集群及文本格式存储在HDFS上。0136所述历史监测数据库中的数据以格式化的形式存储，根据车载ATP监测数据的格式设计建立对应的数据库和数据表，所述数据接收及格式转换模块将得到的车载ATP监测数据转化为可以插入到数据表中的数据格式，并将其插入到对应的数据库及数据表中。0137所述分布式文件系统以文本格式存储历史监测数据，各个电务段的车载ATP监测信号以不同的文件进行存储，以便于后续对监测信号进行分析和挖掘时使用。说明书CN103338261A1412/12页150138E。