一种轨道交通监测数据的存储和处理方法及系统

暂无

一种轨道交通监测数据的存储和处理方法及系统\n技术领域\n[0001] 本发明提供一种轨道交通监测数据的存储和处理方法及系统，涉及铁路信号数据、铁路通信数据、铁路知识数据、系统报警数据、云计算、云存储、并行计算等技术领域，解决了现有技术中快速膨胀的铁路监测数据的存储及数据处理问题。\n背景技术\n[0002] 现有的轨道交通监测数据的存储方案，是将各个电务段的历史监测数据分别存储在各个电务段中，对数据的分析和挖掘也是各个电务段进行处理的。\n[0003] 如图1所示，该现有的存储系统包括：位于电务车间或工区中的集中监测系统（CSM）数据处理服务器11；位于各站点电务段监测中心的数据分析服务器12、人机交互输入输出设备15和监测数据库16；位于铁路局电务处总监测中心的知识库存储设备19、系统诊断服务器10和人机交互输入输出设备15。其中，集中监测系统数据处理服务器11与位于同一电务车间或工区中的用于监测铁路信号的集中监测设备13连接，集中监测系统数据处理服务器11与数据分析服务器12连接；数据分析服务器12与本电务段的人机交互输入输出设备15、本电务段的监测数据库16和铁路局电务处总监测中心的知识库存储设备19连接；知识库存储设备19与系统诊断服务器10连接，系统诊断服务器10与位于铁路局电务处总监测中心的人机交互输入输出设备15连接。\n[0004] 上述系统中，集中监测系统数据处理服务器11、数据分析服务器12和系统诊断服务器10可以采用现有的集中监测设备或服务器实现；知识库存储设备19可以采用普通的存储设备实现；人机交互输入输出设备15可以是显示器、键盘和鼠标组成的输入输出设备，也可以是具有触摸功能的显示器用作输入输出设备均可。\n[0005] 上述系统中，集中监测系统数据处理服务器11将位于同电务车间或工区中集中监测设备13的历史铁路信号监测数据采集并发送到监测数据库16；数据分析服务器12对这些铁路历史监测数据进行预处理后，整理出知识规则并传输到知识库存储设备19。同时，集中监测系统数据处理服务器11还将各集中监测设备13实时监测到的铁路信号监测数据采集并发送到系统诊断服务器10。系统诊断服务器10对这些实时的铁路信号监测数据进行预处理后，结合知识库存储设备19中的知识数据，得到诊断结果，并通过人机交互输入输出设备\n15，将诊断结果展示给用户。此外，各电务段监测中心的数据分析服务器也可以通过人机交互输入输出设备15将集中监测系统数据处理服务器11上报的监测数据和系统诊断规则等展示给用户。\n[0006] 上述轨道交通监测数据的传统存储方案有以下缺陷：\n[0007] 1）成本高：传统的存储方案要求各个车间/站点的监测数据存储在各电务段的数据库中，对监测数据的分析和挖掘也存放在各个电务段分别进行。这就要求各个电务段需要配置性能较高的服务器及存储设备，同时需要雇佣专门设备维护人员。\n[0008] 2）资源利用率低：当电务段对监测数据进行知识挖掘（如故障规则）的频率较低时，电务段的数据分析服务器大多数时间处于闲置状态。\n[0009] 3）数据关系利用率低：因为各个电务段的监测数据是单独存储的，因此各个电务段的数据进行分析和挖掘时也是隔离的，这就使得挖掘得到的知识受限于本电务段。\n[0010] 4）数据冗余：各个电务段单独存储本电务段的数据资源，并且还需要存储部分重复的数据，这样增加了数据的冗余。\n[0011] 5）不支持并行计算及按线路、电务段等方式的信息查询。\n发明内容\n[0012] 本发明的目的是针对上述问题，提供一种轨道交通监测数据的存储和处理方法及系统，通过云平台、云存储技术提高各种资源和轨道交通监测数据的存储和分析处理效率。\n[0013] 为实现上述目的，本发明采用的技术方案如下：\n[0014] 一种轨道交通监测数据的存储和处理方法，其步骤包括：\n[0015] 1）在车站、电务段及铁路管理部门分别设立集中监测系统，在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接；\n[0016] 2）车站的集中监测系统采集各类监测数据，电务段的集中监测系统收集本电务段包含的车站集中监测系统采集的各类监测数据，并传输给一综合运维平台；\n[0017] 3）在所述综合运维平台上建立HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构，形成云计算平台；通过该云计算平台对所述监测数据进行存储和分析挖掘，产生知识规则数据和各类统计信息，并将所述各类统计信息反馈至电务段的集中监测系统；\n[0018] 4）电务段的集中监测系统将收到的所述各类统计信息传输给铁路管理部门的集中监测系统，铁路管理部门的集中监测系统根据所述各类统计信息产生调度指挥命令，并反馈给电务段的集中监测系统。\n[0019] 进一步地，所述云计算平台包括资源层、数据处理层和接口层，所述HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构位于所述数据处理层上。\n[0020] 更进一步地，所述资源层包括物理资源和虚拟资源，所述虚拟资源通过虚拟化技术对物理资源进行虚拟化产生，包括计算资源池、存储资源池和网络资源池；所述接口层包括各种WebService服务器。\n[0021] 进一步地，所述监测数据包括历史监测数据和实时监测数据；所述云计算平台将获取的历史监测数据转换为文本格式存储在HDFS上，并利用MapReduce并行处理架构对HDFS上存储的历史监测数据建立全文索引，结合发布引擎实现对监测数据的碎片查询；所述云计算平台通过MapReduce并行处理架构对历史监测数据进行数据挖掘，产生所述知识规则数据并存储在Hbase数据库中；所述云计算平台将接收到的实时监测数据与所述知识规则数据进行匹配并进行统计分析，生成所述各类统计信息。\n[0022] 进一步地，所述云计算平台利用统计学原理对历史监测数据进行统计，形成监测信号与故障之间的先验及后验概率，作为故障知识规则数据；进而将实时监测数据及相应的故障知识规则数据进行对比，判断当前系统是否存在安全隐患。\n[0023] 进一步地，所述车站集中监测系统采集如下一种或多种设备的监测数据：TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。\n[0024] 进一步地，所述铁路管理部门包括铁路局和铁路总公司，铁路局的集中监测系统接收所述各类统计信息，并产生所述调度指挥命令反馈给电务段的集中监测系统；铁路局的集中监测系统还将各类统计信息传输给铁路总公司的集中监测系统。\n[0025] 一种轨道交通监测数据的存储和处理系统，包括分别位于车站、电务段及铁路管理部门的集中监测系统，在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接；所述电务段集中监测系统还连接一综合运维平台；\n[0026] 车站的集中监测系统负责采集各类监测数据；\n[0027] 所述综合运维平台为一云计算平台，其上建立HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构，负责从电务段的集中监测系统接收所述监测数据进行存储和分析挖掘，产生各类统计信息和知识规则，并将所述各类统计信息反馈至电务段的集中监测系统；\n[0028] 电务段的集中监测系统负责收集本电务段包含的车站集中监测系统采集的各类监测数据并传输给所述综合运维平台，以及从所述综合运维平台接收所述各类统计信息并传输给铁路管理部门的集中监测系统；\n[0029] 铁路管理部门的集中监测系统负责根据所述各类统计信息产生调度指挥命令，并反馈给电务段的集中监测系统。\n[0030] 进一步地，所述综合运维平台包括资源层、数据处理层和接口层；所述资源层包括物理资源和虚拟资源，所述数据处理层包括HDFS分布式文件系统、Hbase和Oracle数据库及MapReduce并行处理架构，用于数据存储和数据并行处理；所述接口层包括各种WebService服务器。\n[0031] 进一步地，所述虚拟资源包括通过虚拟化技术对物理资源进行虚拟化产生的计算资源池、存储资源池和网络资源池。\n[0032] 进一步地，在电务段和铁路管理部门还设有与所述集中监测系统连接的人机交互设备。\n[0033] 进一步地，所述车站集中监测系统连接如下一种或多种设备以采集监测数据：\nTCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。\n[0034] 进一步地，所述铁路管理部门包括铁路局和铁路总公司，铁路局的集中监测系统负责接收所述各类统计信息，并产生所述调度指挥命令反馈给电务段的集中监测系统；铁路局的集中监测系统还负责将各类统计信息传输给铁路总公司的集中监测系统。\n[0035] 本发明的轨道交通监测数据的存储和处理系统及方法包括监测数据采集、数据存储、数据处理和系统运行状态分析等功能。该方案利用HDFS分布式文件系统、Hbase数据库、Oracle数据库对监测数据的不限量存储；利用MapReduce对监测数据进行并行数据挖掘和分析，快速高效的产生各种统计信息和知识规则；通过全文索引技术，对监测数据进行索引监理，并通过发布对应的查询接口实现碎片查询。\n[0036] 本发明通过云存储技术提高资源和数据的利用率，各个电务段不需要计算和存储能力较强的服务器，只需要普通的终端交互设备即可。在总监测中心的数据中心（即所述云计算平台）配备性能强大的服务器和存储设备，用于搭建分布式文件系统、数据仓库和并行处理系统。采用云平台的优势如下：\n[0037] 动态伸缩：云平台有良好的扩展性能，平台可以随着数据量和计算量的增减动态的添加和删除存储节点和计算节点；\n[0038] 负载均衡技术：云平台的负载均衡组件可以根据各个存储节点和计算节点的负载情况，动态的分配存储和计算任务，提供资源的利用率和数据的处理速度；\n[0039] 数据安全性：数据中心的云平台可以通过简单的配置实现数据的备份和恢复；\n[0040] 数据关系挖掘：各个电务段的监测数据都汇总到运维中心的云平台，通过数据挖掘算法可以挖掘分析各个电务段数据之间的关系；\n[0041] 碎片查询：通过全文检索技术，对历史监测数据建立索引，以支持用户按照不同的方式，如时间、线路查询系统信息；\n[0042] 云存储方案通过数据中心的建设，节省了设备和维护人员的成本，并且通过并行计算和分布式存储技术，提高了数据的安全性、数据存储的能力和数据处理的速度。\n[0043] 本发明通过云平台强大的扩展能力对不断增长的监测数据进行存储。监测数据是随着时间的增长而不断增加，当数据增长到一定量的时候，传统的基于关系型数据库的存储方案，会面临数据分片、系统存储能力不足等问题，需要花费很大的成本。但是云存储方案可以根据存储量的需要，通过简单的配置增加存储空间，以满足动态增长的数据存储的需要。\n[0044] 本发明的云计算平台自身提供了并行处理架构，在对海量的监测数据进行分析和挖掘的时候，编程人员只需要关注与业务逻辑也不需要关注底层的资源调度等问题，就可以实现并行任务。本发明的云计算平台通过本身的数据冗余、数据恢复等策略，保证了数据的安全性和高可用性。\n附图说明\n[0045] 图1是现有的轨道交通监测数据存储系统的架构示意图。\n[0046] 图2是本发明实施例的轨道交通监测数据的存储和处理系统示意图。\n[0047] 图3是本发明实施例的综合运维平台的构成示意图。\n[0048] 图4为本发明实施例的对轨道交通监测数据进行云存储及数据分析处理的流程图。\n[0049] 图5为本发明实施例中应用贝叶斯定理进行故障知识规则挖掘的流程图。\n[0050] 图6为本发明实施例中应用贝叶斯定理进行故障数据的统计分析的流程图。\n[0051] 图7为本发明实施例中云计算平台对TCC采集数据的存储流程图。\n[0052] 图8为本发明实施例中云计算平台对TCC实时采集数据的挖掘处理流程图。\n具体实施方式\n[0053] 下面通过具体实施例和附图，对本发明做详细的说明。\n[0054] 如图2所示，本实施例的轨道交通监测数据的存储和处理系统由以下部分组成：现有各车间、电务段、铁路局、铁道部的集中监测系统；综合运维平台，为一云计算平台。下面分别进行说明。\n[0055] 1、各车间、电务段、铁路局和铁路总公司的集中监测系统\n[0056] 包括位于电务车间或工区中的集中监测系统（信号集中监测），即车站集中监测系统；位于各站点电务段的集中监测系统及人机交互设备；位于铁路局的集中监测系统；位于铁路总公司的集中监测系统。其中，车站集中监测系统与电务段集中监测系统连接；电务段集中监测系统与电路局集中监测系统连接；电路局集中监测系统与铁路总公司集中监测系统连接；电务段集中监测系统与综合运维平台连接。其中，铁路局和铁路总公司也可设立与集中监测系统连接的人机交互设备。该“综合运维平台”可以由不同的运维主体进行维护，比如设备厂商、中国的铁路总公司等专业的铁路行业运维企业等。\n[0057] 车站集中监测系统负责采集各类监测数据，包括TCC/CBI（列控中心/计算机联锁）、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心（调度集中）及、DMS/LAIS（列控设备动态监测系统/列车运行状态系统）、RBC/TSRS（无线闭塞/临时限速服务器）、车载ATP（车载计算机）等设备的监测数据；并将采集的数据通过与电务段集中监测系统的连接传输给电务段集中监测系统；并接受来自电务段集中监测系统的各类维修计划、指挥命令。\n[0058] 电务段集中监测系统负责收集本电务段包含的车站的集中监测系统的采集的监测信息，通过电务段集中监测系统与综合运维平台连接，将数据传输给运维平台；运维平台通过对数据的分析挖掘，将产生的各类统计信息反馈给电务段集中监测系统；电务段集中监测系统将各类统计信息传输给铁路局集中监测系统，并接收铁路局集中监测系统发出的调度指挥命令。\n[0059] 铁路局集中监测系统负责接受来自电务段集中监测系统传输的各类统计信息，并通过人工或者机器分析的方式产生一些调度指挥命令，并发反馈给电务段集中监测系统；\n铁路局集中监测系统也会将部分或全部统计信息传输给铁路总公司的集中监测系统。\n[0060] 铁路总公司的集中监测系统用来接收各类统计信息，也可以查询权限下线路、电务段的信息，并可以根据这些信息下达各种命令。\n[0061] 需要说明的是，上述实施例中的铁路局和铁路总公司是针对中国的铁路交通管理部门而采取的对应的方案，但本发明并不限于此，在其它实施例中也可以是其它各国不同类型的铁路管理部门。上述实施例中的“电务段”适用于中国国家铁路体系，本发明亦不以此为限制，本发明的方案也适用于企业铁路、城市轨道交通等铁路运营体系，此时电务段可采用其它名称，如信号段、通信段等。\n[0062] 2、综合运维平台的云计算平台\n[0063] 该云计算平台包含硬件资源和软件资源两部分，按照层次划分包括资源层、数据处理层和接口层，如图3所示。\n[0064] 资源层：资源层包括物理资源和虚拟资源两部分，物理资源指实际的运行环境，包括计算节点、存储节点和网络资源。虚拟资源主要是指通过虚拟化技术对平台的物理资源进行虚拟化，产生的计算资源池、存储资源池和网络资源池。\n[0065] 数据处理层：数据处理层主要包括HDFS分布式文件系统、Hbase和Oracle数据库及MapReduce并行处理架构，分别用于数据存储和数据并行处理。\n[0066] 接口层：接口层主要包括在虚拟机之上部署的各种WebService服务器，用于接收来自电务段集中监测系统的监测数据并对其进行格式转换和存储；对HDFS上的数据建立索引及数据挖掘；根据实时监测数据进行信息统计和故障监测等；发布碎片索引系统，客户可以根据需要查询相关的数据。\n[0067] 本发明的技术重点在于云计算平台的搭建和应用，主要的功能模块包括物理资源、虚拟资源、HDFS分布式文件系统、Hbase列式数据库、MapReduce并行处理架构、Oracle实时应用集群及资源接口层的WebService服务器集群。\n[0068] 下面具体介绍云计算平台的搭建过程：\n[0069] （1）操作系统：技术人员首先部署Centos服务器版操作系统；\n[0070] （2）虚拟机：通过安装KVM虚拟化软件对底层的计算资源、存储资源和网络资源进行虚拟化和管理，通过对资源的虚拟化形成虚拟化资源池，包括计算资源池、存储资源池和网络资源池，用于部署云计算平台的各个软件系统和存储系统；\n[0071] （3）Hadoop：在虚拟化集群上部署Hadoop开源云计算架构，包括HDFS分布式文件系统，MapReduce并行计算架构；通过对虚拟机的克隆、备份等操作，可以十分容易的对Hadoop集群进行扩展；当需要增加Hadoop集群的计算、存储能力时，只需要启动新的已经配置好的Hadoop Slave节点，然后将节点添加到集群中即可完成对集群计算和存储能力的扩展；\n[0072] （4）HBase：在HDFS上部署HBase列式数据库，用于存储和处理知识规则等数据；\nHBase可以借助HDFS良好的扩展性，实现对系统存储能力的扩展，不需要对HBase做单独的配置；\n[0073] （5）Oracle RAC（Oracle实时应用集群）：Oracle10g以上的版本可以配置实时响应集群，在低版本的服务器上构建高可用性数据库系统，并自由部署应用。并且可以实现负载均衡、高可用、并行事务处理和良好的扩展性；\n[0074] （6）WebService集群：在虚拟机上搭建基于Axis2、Ngnix和Apache的WebService的系统，通过SOAP协议的方式接收客户端发送的数据及服务请求；\n[0075] 图4为应用上述系统对轨道交通监测数据进行云存储及数据分析处理的流程图，包括监测数据采集、数据存储、数据处理和系统运行状态分析几个功能：\n[0076] （1）监测数据采集\n[0077] 监测数据的采集通过与车站集中监测系统直接连接的各种采集器。以TCC采集器为例，车站集中监测系统可以直接获取TCC采集器的历史及实时监测数据。云计算平台通过与电务段集中监测系统的连接，发送监测数据请求，电务段通过与车站的连接将TCC采集器的历史及实时采集数据传输给云计算平台的数据接收及格式转换模块。\n[0078] （2）监测数据存储：对监测数据的存储分为两种，分别是历史监测数据和实时监测数据；\n[0079] a）历史监测数据存储\n[0080] 云计算平台对历史监测数据进行存储和知识规则挖掘，只需要在部署的时候请求一次历史监测数据即可，之后的数据则采用实时监测数据采集的方式汇总到云计算平台的存储系统中。\n[0081] b）实时监测数据存储\n[0082] 云计算平台对实时监测数据除了进行存储之外，还需要对监测数据进行统计和规则匹配，产生系统运行状态诊断信息。\n[0083] 数据接收及格式转换模块接收到来自电务段集中监测系统的监测数据后，解析数据的格式，确定监测数据的设备及监测值，然后将数据插入到Oracle对应的数据库中，并将监测数据转换为文本存储在HDFS文件系统中。\n[0084] （3）监测数据处理\n[0085] 对监测数据的处理分为两种，一种是定期的对云平台的监测数据进行建立索引和知识规则挖掘；第二种是对实时采集的监测数据进行统计和规制匹配。\n[0086] a）监测数据索引建立：数据接收及格式转换模块将获取的历史监测数据转换为文本格式存储在HDFS上，云计算平台利用MapReduce并行处理模块定期（如一天）对HDFS上存储的监测数据结合Lucene对监测数据建立全文索引，结合发布引擎，实现对监测数据的碎片查询。\n[0087] b）监测数据挖掘：云计算平台定期通过MapReduce并行处理架构对历史监测数据进行数据挖掘，产生知识规则数据，并将这部分数据存储在Hbase列式数据库中。\n[0088] MapReduce并行处理架构主要包括Map和Reduce两个阶段，HDFS上的文本监测数据作为输入数据，通过Map阶段将文本分为与计算节点相同数目的文本块，然后对这些文本块用不同的处理器进行运算，将产生的中间结果通过Reduce节点进行汇总，从而产生知识规则数据。将这些规则数据存储在HBase列式数据库中，便于建立索引、快速查询及动态扩容。\n[0089] 知识规则的产生根据不同的信号和应用需求采用不同的数据挖掘算法，常用的如朴素贝叶斯算法（贝叶斯分类的基础是概率推理，就是在各种条件的存在不确定，仅知其出现概率的情况下，如何完成推理和决策任务）。\n[0090] 以故障检测为例，为了产生故障知识规则数据，则需要对历史监测信号（如车载ATP信号）进行分析，利用统计学原理对信号数据进行统计，形成监测信号与故障之间的先验及后验概率，也就是故障知识规则数据。下面以故障监测为例，结合朴素贝叶斯分类器算法详细介绍故障知识挖掘及实时数据分析的流程。\n[0091] 首先介绍贝叶斯定理。贝叶斯定理是关于随机事件A和B的条件概率的一则定理，即：\n[0092]\n[0093] 其中P(A|B)是在B发生的情况下A发生的可能性，各概率值的含义具体解释如下：\n[0094] P(A)是A的先验概率。之所以称为"先验"是因为它不考虑任何B方面的因素；\n[0095] P(A|B)是已知B发生后A的条件概率，也由于得自B的取值而被称作A的后验概率；\n[0096] P(B|A)是已知A发生后B的条件概率，也由于得自A的取值而被称作B的后验概率；\n[0097] P(B)是B的先验概率。\n[0098] 本发明应用贝叶斯定理进行故障知识规则挖掘：A表示故障发生，P(A)表示故障发生的概率；B代表的是与故障发生相关的信号量的集合；P(B)是每个信号量采集得到的对应的概率，其中B是一系列信号的取值；P(B/A)代表在故障发生时，B取值的一些概率。这些都是可以从历史监测数据中统计出来的。\n[0099] 采集的历史监测数据以文本方式保存在HDFS上，在进行处理之前先对数据进行分片，分片的数量等于云平台上Hadoop计算节点的个数，然后使用Mapreduce进行处理（进行知识挖掘），分为两个阶段Map阶段和Reduce阶段，如图5所示：\n[0100] Map阶段：该阶段完成对输入数据的读取及预处理，并计算各个文件的P(A)，P(B)等概率值；Reduce阶段：该阶段接受Map阶段的输出结果，并对结果进行合并，计算全局的P(A)、P(B)和P(B/A)。\n[0101] c）实时监测数据的统计及规则匹配\n[0102] 数据接收机格式转换模块将接收到的实时监测数据与规则库的数据进行匹配并进行统计分析，生成统计信息及系统状态信息（如故障规则可以判断系统是否存在安全隐患），并将这些信息反馈给集中监测系统。\n[0103] 仍以故障检测为例，云平台将实时监测数据及HBase中相应的故障知识规则数据进行对比，根据后验概率和实时信号数据的对比，判断当前系统是否存在故障等安全隐患。\n[0104] 具体来说，在预测的时候，需要根据实时数据也就是B（信号序列）预测A（故障）发生的概率，根据贝叶斯公式知：P（故障/信号）=P（信号/故障）*P（故障）/P（信号），其中与故障相关的信号可能包含多个信号：B=B1B2B3…Bn，根据朴素贝叶斯的独立性假设，各个信号量之间出现的概率是没有关系的，因此P（B）=P（B1）*P（B2）*..*P(Bn).P(A/B)=P(AB)/P(B)=P(B/A)P(A)/P(B)，并且P(A)、P(B)、P(B/A)都已经计算出来了，并且存储在Hbase数据库中，根据实时监测数据和Hbase中的先验后验概率，即可以求出统计信息和故障数据，具体流程如图6所示。\n[0105] 下面进一步以TCC信号为例来描述上述各个模块之间的关系和数据流程：\n[0106] TCC（列控中心）信号库包含三个表，分别是：系统状态表，如表1所示，通信状态表，如表2所示，系统报警表，如表3所示。三个表之间互相联系，系统状态表中任何一个状态故障时会对应系统报警表中的一条记录，通信状态表也是如此。\n[0107] 表1：系统状态表\n[0108]\n指标 值\nI系主机工作状态 主用、备、离线\nII系主机工作状态 主、备、离线\nI系驱采机工作状态 正常、故障\nII系驱采机工作状态 正常、故障\nI系通信机工作状态 正常、故障\nII系通信机工作状态 正常、故障\nI系板卡工作状态（各厂家自定义） 正常、故障\nII系板卡工作状态（各厂家自定义） 正常、故障\n[0109] 表2：通信状态表\n[0110]\n指标 值\nI系与联锁I系通信状态 正常、故障\nI系与联锁II系通信状态 正常、故障\nII系与联锁I系通信状态 正常、故障\nII系与联锁II系通信状态 正常、故障\nI系与TSRS I系通信状态 正常、故障\nI系与TSRS II系通信状态 正常、故障\nII系与TSRS I系通信状态 正常、故障\nII系与TSRS II系通信状态 正常、故障\nI系与相邻TCC I系通信状态 正常、故障\nI系与相邻TCC II系通信状态 正常、故障\nII系与相邻TCC I系通信状态 正常、故障\nII系与相邻TCC II系通信状态 正常、故障\nI系与CTC I系通信状态 正常、故障\nI系与CTC II系通信状态 正常、故障\nII系与CTC I系通信状态 正常、故障\nII系与CTC II系通信状态 正常、故障\nI系与轨道电路通信状态 正常、故障\nII系与轨道电路通信状态 正常、故障\nI系与LEU通信状态 正常、故障\nII系与LEU通信状态 正常、故障\nI系与继电器通信状态 正常、故障\nII系与继电器通信状态 正常、故障\n[0111] 表3：系统报警表\n[0112]\nI系与联锁I系通信故障 I系与继电器通信故障\nI系与联锁II系通信故障 II系与继电器通信故障\nII系与联锁I系通信故障 LDJ驱动、采集不一致\nII系与联锁II系通信故障 UDJ驱动、采集不一致\nI系与TSRS I系通信故障 HDJ驱动、采集不一致\nI系与TSRS II系通信故障 1DJ断丝报警\nII系与TSRS I系通信故障 2DJ断丝报警\nII系与TSRS II系通信故障 轨道状态通信、采集不一致\nI系与相邻TCC I系通信故障 轨道状态通信、采集不一致\nI系与相邻TCC II系通信故障 区间线路方向驱动、采集不一致\nII系与相邻TCC I系通信故障 区段灾害状态告警\nII系与相邻TCC II系通信故障 红灯断丝报警\nI系与CTC I系通信故障 I系主机离线报警\nI系与CTC II系通信故障 II系主机离线报警\nII系与CTC I系通信故障 I系驱采机故障报警\nII系与CTC II系通信故障 II系驱采机故障报警\nI系与轨道电路通信故障 I系通信机故障报警\nII系与轨道电路通信故障 II系通信机故障报警\nI系与LEU通信故障 I系板卡故障报警\nII系与LEU通信故障 II系板卡故障报警\n[0113] 云平台通过存储和处理这些信号数据，挖掘知识规则；然后通过与实时监测数据的对比进行系统状态的统计和辅助决策。\n[0114] （1）TCC信号库的数据存储流程\n[0115] 下面通过图7所示的数据流程图来介绍云计算平台对TCC采集数据的存储流程：\n[0116] a）由云计算平台发起对TCC历史监测数据的请求，通过云计算平台与电务段集中监测系统的连接，将请求转发给本电务段各个车站监测系统；\n[0117] b）车站集中监测系统直接与车站的各个监测信号采集器连接，直接向TCC采集器发出历史数据采集请求；\n[0118] c）TCC采集器将本地存储的历史监测数据通过电务段集中监测系统转发给云计算平台；\n[0119] d）云计算平台的数据接收及格式转换模块将得到的TCC历史监测数据进行格式转换，分别以格式化的方式存储在Oracle集群及文本格式存储在HDFS上；\n[0120] e）云计算平台的MapReduce并行处理架构对HDFS上的历史监测数据进行数据分析和挖掘，到的通信信息及知识规则存储在HBase列式数据库中；\n[0121] f）云计算平台通过部署的Lucene对得到的历史监测数据进行索引建立，根据不同的关键字生成多种索引文件，包括时间、车站、线路等均需要生成对应的索引文件。\n[0122] Lucene是建立在Hadoop之上的开源索引工具，可以通过并行的方式完成对HDFS上的文本数据建立索引。\n[0123] （2）TCC实时监测数据处理流程\n[0124] 下面通过图8所示的数据流程图介绍云计算平台对TCC实时采集数据的处理：\n[0125] a）TCC采集器定期通过集中监测系统将实时采集的监测数据传输给云计算平台；\n[0126] b）云计算平台的数据接收及格式转换模块将接收的TCC实时监测数据传输给实时数据分析模块；\n[0127] c）实时数据分析模块通过对实时监测数据的与HBase中知识规则及统计信息的比较及分析，得到TCC对应的系统状态、通信状态及系统报警状态的统计及分析结果；\n[0128] d）云计算平台通过与电务段的连接将系统实时分析结果反馈给集中监测系统；\n[0129] e）集中监测系统则根据权限将实时的系统状态通过人机交互设备反馈给系统管理人员，管理人员可以根据目前的系统运行状态分发调度指令、维修指令等。\n[0130] 下面进一步以车载ATP（车载计算机）信号为例来描述上述各个模块之间的关系和数据流程：\n[0131] （1）ATP数据存储流程\n[0132] a）由云计算平台发起对车载ATP历史监测数据的请求，通过云计算平台与电务段集中监测系统的连接，将请求转发给本电务段各个车站监测系统。\n[0133] b）车站集中监测系统直接与车站的车载ATP监测信号采集器连接，直接向车载ATP采集器发出历史数据采集请求。\n[0134] c）车载ATP采集器将本地存储的历史监测数据通过电务段集中监测系统转发给云计算平台。\n[0135] d）云计算平台的数据接收及格式转换模块将得到的车载ATP历史监测数据进行格式转换，分别以格式化的方式存储在Oracle集群及文本格式存储在HDFS上。\n[0136] 所述历史监测数据库中的数据以格式化的形式存储，根据车载ATP监测数据的格式设计建立对应的数据库和数据表，所述数据接收及格式转换模块将得到的车载ATP监测数据转化为可以插入到数据表中的数据格式，并将其插入到对应的数据库及数据表中。\n[0137] 所述分布式文件系统以文本格式存储历史监测数据，各个电务段的车载ATP监测信号以不同的文件进行存储，以便于后续对监测信号进行分析和挖掘时使用。\n[0138] e）云计算平台的MapReduce并行处理架构对HDFS上的历史监测数据进行数据分析和挖掘，到的通信信息及知识规则存储在HBase列式数据库中。\n[0139] MapReduce并行处理架构主要包括Map和Reduce两个阶段，HDFS上的文本监测数据作为输入数据，通过Map阶段将文本分为与计算节点相同数目的文本块，然后对这些文本块用不同的处理器进行运算，将产生的中间结果通过Reduce节点进行汇总，从而产生知识规则数据。将这些规则数据存储在HBase列式数据库中，便于建立索引、快速查询及动态扩容。\n[0140] 为了产生车载ATP信号故障知识规则数据，需要对车载ATP历史监测信号进行分析，利用统计学原理对信号数据进行统计，形成监测信号与故障之间的先验及后验概率，也就是故障知识规则数据。\n[0141] f）云计算平台通过部署的Lucene对得到的历史监测数据进行索引建立，根据不同的关键字生成多种索引文件，包括时间、车站、线路等均需要生成对应的索引文件。\n[0142] （2）ATP实时监测数据处理流程\n[0143] a）车载ATP信号采集器定期通过集中监测系统将实时采集的监测数据传输给云计算平台。\n[0144] 针对车载设备ATP处于移动状态的特性，为了实时采集该设备的数据，在车-地WIFI网络具备时将车载设备数据通过WIFI网络传送至车站，在车-地WIFI网络不具备时通过3G/LTE通道直接传输至云计算平台。以此实现系统也能够获取到车载设备ATP的实时监测数据，保证设备综合监控和设备远程运维的设备全面性。\n[0145] b）云计算平台的数据接收及格式转换模块将接收的车载ATP实时监测数据传输给实时数据分析模块。\n[0146] c）实时数据分析模块通过对实时监测数据的与HBase中知识规则及统计信息的比较及分析，得到车载ATP对应的系统状态、通信状态及系统报警状态的统计及分析结果。\n[0147] 进行车载ATP故障检测时，云平台将得到的车载ATP实时监测数据传输给实时数据分析模块，该模块通过将实时数据及HBase中相应的车载ATP故障知识规则数据进行对比，根据后验概率和实时信号数据的对比，判断当前系统是否存在故障等安全隐患。\n[0148] d）云计算平台通过与电务段的连接将系统实时分析结果反馈给集中监测系统。\n[0149] e）集中监测系统则根据权限将实时的系统状态通过人机交互设备反馈给系统管理人员，管理人员可以根据目前的系统运行状态分发调度指令、维修指令等。\n[0150] 尽管为说明目的公开了本发明的具体实施例和附图，其目的在于帮助理解本发明的内容并据以实施，但是本领域的技术人员可以理解：在不脱离本发明及所附的权利要求的精神和范围内，各种替换、变化和修改都是可能的。本发明不应局限于本说明书最佳实施例和附图所公开的内容，本发明要求保护的范围以权利要求书界定的范围为准。