CN103338261B - 一种轨道交通监测数据的存储和处理方法及系统 - Google Patents
一种轨道交通监测数据的存储和处理方法及系统 Download PDFInfo
- Publication number
- CN103338261B CN103338261B CN201310279514.0A CN201310279514A CN103338261B CN 103338261 B CN103338261 B CN 103338261B CN 201310279514 A CN201310279514 A CN 201310279514A CN 103338261 B CN103338261 B CN 103338261B
- Authority
- CN
- China
- Prior art keywords
- data
- monitoring system
- centralized monitoring
- electricity business
- business section
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Abstract
本发明涉及一种轨道交通监测数据的存储和处理方法及系统,首先在车站、电务段及铁路管理部门设立集中监测系统;车站的集中监测系统采集各类监测数据,电务段的集中监测系统收集车站集中监测系统采集的各类监测数据;在一综合运维平台上建立HDFS分布式文件系统、Hbase和Oracle数据库以及MapReduce并行处理架构,形成云计算平台,进而对所述监测数据进行存储和分析挖掘,产生知识规则数据和各类统计信息;铁路管理部门的集中监测系统产生调度指挥命令并反馈给电务段的集中监测系统。本发明采用云存储技术以及并行处理架构,提高了轨道交通资源和数据的存储和分析处理效率,保证了数据的安全性和高可用性。
Description
技术领域
本发明提供一种轨道交通监测数据的存储和处理方法及系统,涉及铁路信号数据、铁路通信数据、铁路知识数据、系统报警数据、云计算、云存储、并行计算等技术领域,解决了现有技术中快速膨胀的铁路监测数据的存储及数据处理问题。
背景技术
现有的轨道交通监测数据的存储方案,是将各个电务段的历史监测数据分别存储在各个电务段中,对数据的分析和挖掘也是各个电务段进行处理的。
如图1所示,该现有的存储系统包括:位于电务车间或工区中的集中监测系统(CSM)数据处理服务器11;位于各站点电务段监测中心的数据分析服务器12、人机交互输入输出设备15和监测数据库16;位于铁路局电务处总监测中心的知识库存储设备19、系统诊断服务器10和人机交互输入输出设备15。其中,集中监测系统数据处理服务器11与位于同一电务车间或工区中的用于监测铁路信号的集中监测设备13连接,集中监测系统数据处理服务器11与数据分析服务器12连接;数据分析服务器12与本电务段的人机交互输入输出设备15、本电务段的监测数据库16和铁路局电务处总监测中心的知识库存储设备19连接;知识库存储设备19与系统诊断服务器10连接,系统诊断服务器10与位于铁路局电务处总监测中心的人机交互输入输出设备15连接。
上述系统中,集中监测系统数据处理服务器11、数据分析服务器12和系统诊断服务器10可以采用现有的集中监测设备或服务器实现;知识库存储设备19可以采用普通的存储设备实现;人机交互输入输出设备15可以是显示器、键盘和鼠标组成的输入输出设备,也可以是具有触摸功能的显示器用作输入输出设备均可。
上述系统中,集中监测系统数据处理服务器11将位于同电务车间或工区中集中监测设备13的历史铁路信号监测数据采集并发送到监测数据库16;数据分析服务器12对这些铁路历史监测数据进行预处理后,整理出知识规则并传输到知识库存储设备19。同时,集中监测系统数据处理服务器11还将各集中监测设备13实时监测到的铁路信号监测数据采集并发送到系统诊断服务器10。系统诊断服务器10对这些实时的铁路信号监测数据进行预处理后,结合知识库存储设备19中的知识数据,得到诊断结果,并通过人机交互输入输出设备15,将诊断结果展示给用户。此外,各电务段监测中心的数据分析服务器也可以通过人机交互输入输出设备15将集中监测系统数据处理服务器11上报的监测数据和系统诊断规则等展示给用户。
上述轨道交通监测数据的传统存储方案有以下缺陷:
1)成本高:传统的存储方案要求各个车间/站点的监测数据存储在各电务段的数据库中,对监测数据的分析和挖掘也存放在各个电务段分别进行。这就要求各个电务段需要配置性能较高的服务器及存储设备,同时需要雇佣专门设备维护人员。
2)资源利用率低:当电务段对监测数据进行知识挖掘(如故障规则)的频率较低时,电务段的数据分析服务器大多数时间处于闲置状态。
3)数据关系利用率低:因为各个电务段的监测数据是单独存储的,因此各个电务段的数据进行分析和挖掘时也是隔离的,这就使得挖掘得到的知识受限于本电务段。
4)数据冗余:各个电务段单独存储本电务段的数据资源,并且还需要存储部分重复的数据,这样增加了数据的冗余。
5)不支持并行计算及按线路、电务段等方式的信息查询。
发明内容
本发明的目的是针对上述问题,提供一种轨道交通监测数据的存储和处理方法及系统,通过云平台、云存储技术提高各种资源和轨道交通监测数据的存储和分析处理效率。
为实现上述目的,本发明采用的技术方案如下:
一种轨道交通监测数据的存储和处理方法,其步骤包括:
1)在车站、电务段及铁路管理部门分别设立集中监测系统,在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接;
2)车站的集中监测系统采集各类监测数据,电务段的集中监测系统收集本电务段包含的车站集中监测系统采集的各类监测数据,并传输给一综合运维平台;
3)在所述综合运维平台上建立HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构,形成云计算平台;通过该云计算平台对所述监测数据进行存储和分析挖掘,产生知识规则数据和各类统计信息,并将所述各类统计信息反馈至电务段的集中监测系统;
4)电务段的集中监测系统将收到的所述各类统计信息传输给铁路管理部门的集中监测系统,铁路管理部门的集中监测系统根据所述各类统计信息产生调度指挥命令,并反馈给电务段的集中监测系统。
进一步地,所述云计算平台包括资源层、数据处理层和接口层,所述HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构位于所述数据处理层上。
更进一步地,所述资源层包括物理资源和虚拟资源,所述虚拟资源通过虚拟化技术对物理资源进行虚拟化产生,包括计算资源池、存储资源池和网络资源池;所述接口层包括各种WebService服务器。
进一步地,所述监测数据包括历史监测数据和实时监测数据;所述云计算平台将获取的历史监测数据转换为文本格式存储在HDFS上,并利用MapReduce并行处理架构对HDFS上存储的历史监测数据建立全文索引,结合发布引擎实现对监测数据的碎片查询;所述云计算平台通过MapReduce并行处理架构对历史监测数据进行数据挖掘,产生所述知识规则数据并存储在Hbase数据库中;所述云计算平台将接收到的实时监测数据与所述知识规则数据进行匹配并进行统计分析,生成所述各类统计信息。
进一步地,所述云计算平台利用统计学原理对历史监测数据进行统计,形成监测信号与故障之间的先验及后验概率,作为故障知识规则数据;进而将实时监测数据及相应的故障知识规则数据进行对比,判断当前系统是否存在安全隐患。
进一步地,所述车站集中监测系统采集如下一种或多种设备的监测数据:TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。
进一步地,所述铁路管理部门包括铁路局和铁路总公司,铁路局的集中监测系统接收所述各类统计信息,并产生所述调度指挥命令反馈给电务段的集中监测系统;铁路局的集中监测系统还将各类统计信息传输给铁路总公司的集中监测系统。
一种轨道交通监测数据的存储和处理系统,包括分别位于车站、电务段及铁路管理部门的集中监测系统,在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接;所述电务段集中监测系统还连接一综合运维平台;
车站的集中监测系统负责采集各类监测数据;
所述综合运维平台为一云计算平台,其上建立HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构,负责从电务段的集中监测系统接收所述监测数据进行存储和分析挖掘,产生各类统计信息和知识规则,并将所述各类统计信息反馈至电务段的集中监测系统;
电务段的集中监测系统负责收集本电务段包含的车站集中监测系统采集的各类监测数据并传输给所述综合运维平台,以及从所述综合运维平台接收所述各类统计信息并传输给铁路管理部门的集中监测系统;
铁路管理部门的集中监测系统负责根据所述各类统计信息产生调度指挥命令,并反馈给电务段的集中监测系统。
进一步地,所述综合运维平台包括资源层、数据处理层和接口层;所述资源层包括物理资源和虚拟资源,所述数据处理层包括HDFS分布式文件系统、Hbase和Oracle数据库及MapReduce并行处理架构,用于数据存储和数据并行处理;所述接口层包括各种WebService服务器。
进一步地,所述虚拟资源包括通过虚拟化技术对物理资源进行虚拟化产生的计算资源池、存储资源池和网络资源池。
进一步地,在电务段和铁路管理部门还设有与所述集中监测系统连接的人机交互设备。
进一步地,所述车站集中监测系统连接如下一种或多种设备以采集监测数据:TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。
进一步地,所述铁路管理部门包括铁路局和铁路总公司,铁路局的集中监测系统负责接收所述各类统计信息,并产生所述调度指挥命令反馈给电务段的集中监测系统;铁路局的集中监测系统还负责将各类统计信息传输给铁路总公司的集中监测系统。
本发明的轨道交通监测数据的存储和处理系统及方法包括监测数据采集、数据存储、数据处理和系统运行状态分析等功能。该方案利用HDFS分布式文件系统、Hbase数据库、Oracle数据库对监测数据的不限量存储;利用MapReduce对监测数据进行并行数据挖掘和分析,快速高效的产生各种统计信息和知识规则;通过全文索引技术,对监测数据进行索引监理,并通过发布对应的查询接口实现碎片查询。
本发明通过云存储技术提高资源和数据的利用率,各个电务段不需要计算和存储能力较强的服务器,只需要普通的终端交互设备即可。在总监测中心的数据中心(即所述云计算平台)配备性能强大的服务器和存储设备,用于搭建分布式文件系统、数据仓库和并行处理系统。采用云平台的优势如下:
动态伸缩:云平台有良好的扩展性能,平台可以随着数据量和计算量的增减动态的添加和删除存储节点和计算节点;
负载均衡技术:云平台的负载均衡组件可以根据各个存储节点和计算节点的负载情况,动态的分配存储和计算任务,提供资源的利用率和数据的处理速度;
数据安全性:数据中心的云平台可以通过简单的配置实现数据的备份和恢复;
数据关系挖掘:各个电务段的监测数据都汇总到运维中心的云平台,通过数据挖掘算法可以挖掘分析各个电务段数据之间的关系;
碎片查询:通过全文检索技术,对历史监测数据建立索引,以支持用户按照不同的方式,如时间、线路查询系统信息;
云存储方案通过数据中心的建设,节省了设备和维护人员的成本,并且通过并行计算和分布式存储技术,提高了数据的安全性、数据存储的能力和数据处理的速度。
本发明通过云平台强大的扩展能力对不断增长的监测数据进行存储。监测数据是随着时间的增长而不断增加,当数据增长到一定量的时候,传统的基于关系型数据库的存储方案,会面临数据分片、系统存储能力不足等问题,需要花费很大的成本。但是云存储方案可以根据存储量的需要,通过简单的配置增加存储空间,以满足动态增长的数据存储的需要。
本发明的云计算平台自身提供了并行处理架构,在对海量的监测数据进行分析和挖掘的时候,编程人员只需要关注与业务逻辑也不需要关注底层的资源调度等问题,就可以实现并行任务。本发明的云计算平台通过本身的数据冗余、数据恢复等策略,保证了数据的安全性和高可用性。
附图说明
图1是现有的轨道交通监测数据存储系统的架构示意图。
图2是本发明实施例的轨道交通监测数据的存储和处理系统示意图。
图3是本发明实施例的综合运维平台的构成示意图。
图4为本发明实施例的对轨道交通监测数据进行云存储及数据分析处理的流程图。
图5为本发明实施例中应用贝叶斯定理进行故障知识规则挖掘的流程图。
图6为本发明实施例中应用贝叶斯定理进行故障数据的统计分析的流程图。
图7为本发明实施例中云计算平台对TCC采集数据的存储流程图。
图8为本发明实施例中云计算平台对TCC实时采集数据的挖掘处理流程图。
具体实施方式
下面通过具体实施例和附图,对本发明做详细的说明。
如图2所示,本实施例的轨道交通监测数据的存储和处理系统由以下部分组成:现有各车间、电务段、铁路局、铁道部的集中监测系统;综合运维平台,为一云计算平台。下面分别进行说明。
1、各车间、电务段、铁路局和铁路总公司的集中监测系统
包括位于电务车间或工区中的集中监测系统(信号集中监测),即车站集中监测系统;位于各站点电务段的集中监测系统及人机交互设备;位于铁路局的集中监测系统;位于铁路总公司的集中监测系统。其中,车站集中监测系统与电务段集中监测系统连接;电务段集中监测系统与电路局集中监测系统连接;电路局集中监测系统与铁路总公司集中监测系统连接;电务段集中监测系统与综合运维平台连接。其中,铁路局和铁路总公司也可设立与集中监测系统连接的人机交互设备。该“综合运维平台”可以由不同的运维主体进行维护,比如设备厂商、中国的铁路总公司等专业的铁路行业运维企业等。
车站集中监测系统负责采集各类监测数据,包括TCC/CBI(列控中心/计算机联锁)、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心(调度集中)及、DMS/LAIS(列控设备动态监测系统/列车运行状态系统)、RBC/TSRS(无线闭塞/临时限速服务器)、车载ATP(车载计算机)等设备的监测数据;并将采集的数据通过与电务段集中监测系统的连接传输给电务段集中监测系统;并接受来自电务段集中监测系统的各类维修计划、指挥命令。
电务段集中监测系统负责收集本电务段包含的车站的集中监测系统的采集的监测信息,通过电务段集中监测系统与综合运维平台连接,将数据传输给运维平台;运维平台通过对数据的分析挖掘,将产生的各类统计信息反馈给电务段集中监测系统;电务段集中监测系统将各类统计信息传输给铁路局集中监测系统,并接收铁路局集中监测系统发出的调度指挥命令。
铁路局集中监测系统负责接受来自电务段集中监测系统传输的各类统计信息,并通过人工或者机器分析的方式产生一些调度指挥命令,并发反馈给电务段集中监测系统;铁路局集中监测系统也会将部分或全部统计信息传输给铁路总公司的集中监测系统。
铁路总公司的集中监测系统用来接收各类统计信息,也可以查询权限下线路、电务段的信息,并可以根据这些信息下达各种命令。
需要说明的是,上述实施例中的铁路局和铁路总公司是针对中国的铁路交通管理部门而采取的对应的方案,但本发明并不限于此,在其它实施例中也可以是其它各国不同类型的铁路管理部门。上述实施例中的“电务段”适用于中国国家铁路体系,本发明亦不以此为限制,本发明的方案也适用于企业铁路、城市轨道交通等铁路运营体系,此时电务段可采用其它名称,如信号段、通信段等。
2、综合运维平台的云计算平台
该云计算平台包含硬件资源和软件资源两部分,按照层次划分包括资源层、数据处理层和接口层,如图3所示。
资源层:资源层包括物理资源和虚拟资源两部分,物理资源指实际的运行环境,包括计算节点、存储节点和网络资源。虚拟资源主要是指通过虚拟化技术对平台的物理资源进行虚拟化,产生的计算资源池、存储资源池和网络资源池。
数据处理层:数据处理层主要包括HDFS分布式文件系统、Hbase和Oracle数据库及MapReduce并行处理架构,分别用于数据存储和数据并行处理。
接口层:接口层主要包括在虚拟机之上部署的各种WebService服务器,用于接收来自电务段集中监测系统的监测数据并对其进行格式转换和存储;对HDFS上的数据建立索引及数据挖掘;根据实时监测数据进行信息统计和故障监测等;发布碎片索引系统,客户可以根据需要查询相关的数据。
本发明的技术重点在于云计算平台的搭建和应用,主要的功能模块包括物理资源、虚拟资源、HDFS分布式文件系统、Hbase列式数据库、MapReduce并行处理架构、Oracle实时应用集群及资源接口层的WebService服务器集群。
下面具体介绍云计算平台的搭建过程:
(1)操作系统:技术人员首先部署Centos服务器版操作系统;
(2)虚拟机:通过安装KVM虚拟化软件对底层的计算资源、存储资源和网络资源进行虚拟化和管理,通过对资源的虚拟化形成虚拟化资源池,包括计算资源池、存储资源池和网络资源池,用于部署云计算平台的各个软件系统和存储系统;
(3)Hadoop:在虚拟化集群上部署Hadoop开源云计算架构,包括HDFS分布式文件系统,MapReduce并行计算架构;通过对虚拟机的克隆、备份等操作,可以十分容易的对Hadoop集群进行扩展;当需要增加Hadoop集群的计算、存储能力时,只需要启动新的已经配置好的HadoopSlave节点,然后将节点添加到集群中即可完成对集群计算和存储能力的扩展;
(4)HBase:在HDFS上部署HBase列式数据库,用于存储和处理知识规则等数据;HBase可以借助HDFS良好的扩展性,实现对系统存储能力的扩展,不需要对HBase做单独的配置;
(5)OracleRAC(Oracle实时应用集群):Oracle10g以上的版本可以配置实时响应集群,在低版本的服务器上构建高可用性数据库系统,并自由部署应用。并且可以实现负载均衡、高可用、并行事务处理和良好的扩展性;
(6)WebService集群:在虚拟机上搭建基于Axis2、Ngnix和Apache的WebService的系统,通过SOAP协议的方式接收客户端发送的数据及服务请求;
图4为应用上述系统对轨道交通监测数据进行云存储及数据分析处理的流程图,包括监测数据采集、数据存储、数据处理和系统运行状态分析几个功能:
(1)监测数据采集
监测数据的采集通过与车站集中监测系统直接连接的各种采集器。以TCC采集器为例,车站集中监测系统可以直接获取TCC采集器的历史及实时监测数据。云计算平台通过与电务段集中监测系统的连接,发送监测数据请求,电务段通过与车站的连接将TCC采集器的历史及实时采集数据传输给云计算平台的数据接收及格式转换模块。
(2)监测数据存储:对监测数据的存储分为两种,分别是历史监测数据和实时监测数据;
a)历史监测数据存储
云计算平台对历史监测数据进行存储和知识规则挖掘,只需要在部署的时候请求一次历史监测数据即可,之后的数据则采用实时监测数据采集的方式汇总到云计算平台的存储系统中。
b)实时监测数据存储
云计算平台对实时监测数据除了进行存储之外,还需要对监测数据进行统计和规则匹配,产生系统运行状态诊断信息。
数据接收及格式转换模块接收到来自电务段集中监测系统的监测数据后,解析数据的格式,确定监测数据的设备及监测值,然后将数据插入到Oracle对应的数据库中,并将监测数据转换为文本存储在HDFS文件系统中。
(3)监测数据处理
对监测数据的处理分为两种,一种是定期的对云平台的监测数据进行建立索引和知识规则挖掘;第二种是对实时采集的监测数据进行统计和规制匹配。
a)监测数据索引建立:数据接收及格式转换模块将获取的历史监测数据转换为文本格式存储在HDFS上,云计算平台利用MapReduce并行处理模块定期(如一天)对HDFS上存储的监测数据结合Lucene对监测数据建立全文索引,结合发布引擎,实现对监测数据的碎片查询。
b)监测数据挖掘:云计算平台定期通过MapReduce并行处理架构对历史监测数据进行数据挖掘,产生知识规则数据,并将这部分数据存储在Hbase列式数据库中。
MapReduce并行处理架构主要包括Map和Reduce两个阶段,HDFS上的文本监测数据作为输入数据,通过Map阶段将文本分为与计算节点相同数目的文本块,然后对这些文本块用不同的处理器进行运算,将产生的中间结果通过Reduce节点进行汇总,从而产生知识规则数据。将这些规则数据存储在HBase列式数据库中,便于建立索引、快速查询及动态扩容。
知识规则的产生根据不同的信号和应用需求采用不同的数据挖掘算法,常用的如朴素贝叶斯算法(贝叶斯分类的基础是概率推理,就是在各种条件的存在不确定,仅知其出现概率的情况下,如何完成推理和决策任务)。
以故障检测为例,为了产生故障知识规则数据,则需要对历史监测信号(如车载ATP信号)进行分析,利用统计学原理对信号数据进行统计,形成监测信号与故障之间的先验及后验概率,也就是故障知识规则数据。下面以故障监测为例,结合朴素贝叶斯分类器算法详细介绍故障知识挖掘及实时数据分析的流程。
首先介绍贝叶斯定理。贝叶斯定理是关于随机事件A和B的条件概率的一则定理,即:
其中P(A|B)是在B发生的情况下A发生的可能性,各概率值的含义具体解释如下:
P(A)是A的先验概率。之所以称为"先验"是因为它不考虑任何B方面的因素;
P(A|B)是已知B发生后A的条件概率,也由于得自B的取值而被称作A的后验概率;
P(B|A)是已知A发生后B的条件概率,也由于得自A的取值而被称作B的后验概率;
P(B)是B的先验概率。
本发明应用贝叶斯定理进行故障知识规则挖掘:A表示故障发生,P(A)表示故障发生的概率;B代表的是与故障发生相关的信号量的集合;P(B)是每个信号量采集得到的对应的概率,其中B是一系列信号的取值;P(B/A)代表在故障发生时,B取值的一些概率。这些都是可以从历史监测数据中统计出来的。
采集的历史监测数据以文本方式保存在HDFS上,在进行处理之前先对数据进行分片,分片的数量等于云平台上Hadoop计算节点的个数,然后使用Mapreduce进行处理(进行知识挖掘),分为两个阶段Map阶段和Reduce阶段,如图5所示:
Map阶段:该阶段完成对输入数据的读取及预处理,并计算各个文件的P(A),P(B)等概率值;Reduce阶段:该阶段接受Map阶段的输出结果,并对结果进行合并,计算全局的P(A)、P(B)和P(B/A)。
c)实时监测数据的统计及规则匹配
数据接收机格式转换模块将接收到的实时监测数据与规则库的数据进行匹配并进行统计分析,生成统计信息及系统状态信息(如故障规则可以判断系统是否存在安全隐患),并将这些信息反馈给集中监测系统。
仍以故障检测为例,云平台将实时监测数据及HBase中相应的故障知识规则数据进行对比,根据后验概率和实时信号数据的对比,判断当前系统是否存在故障等安全隐患。
具体来说,在预测的时候,需要根据实时数据也就是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所示。
下面进一步以TCC信号为例来描述上述各个模块之间的关系和数据流程:
TCC(列控中心)信号库包含三个表,分别是:系统状态表,如表1所示,通信状态表,如表2所示,系统报警表,如表3所示。三个表之间互相联系,系统状态表中任何一个状态故障时会对应系统报警表中的一条记录,通信状态表也是如此。
表1:系统状态表
指标 | 值 |
I系主机工作状态 | 主用、备、离线 |
II系主机工作状态 | 主、备、离线 |
I系驱采机工作状态 | 正常、故障 |
II系驱采机工作状态 | 正常、故障 |
I系通信机工作状态 | 正常、故障 |
II系通信机工作状态 | 正常、故障 |
I系板卡工作状态(各厂家自定义) | 正常、故障 |
II系板卡工作状态(各厂家自定义) | 正常、故障 |
表2:通信状态表
指标 | 值 |
I系与联锁I系通信状态 | 正常、故障 |
I系与联锁II系通信状态 | 正常、故障 |
II系与联锁I系通信状态 | 正常、故障 |
II系与联锁II系通信状态 | 正常、故障 |
I系与TSRS I系通信状态 | 正常、故障 |
I系与TSRS II系通信状态 | 正常、故障 |
II系与TSRS I系通信状态 | 正常、故障 |
II系与TSRS II系通信状态 | 正常、故障 |
I系与相邻TCC I系通信状态 | 正常、故障 |
I系与相邻TCC II系通信状态 | 正常、故障 |
II系与相邻TCC I系通信状态 | 正常、故障 |
II系与相邻TCC II系通信状态 | 正常、故障 |
I系与CTC I系通信状态 | 正常、故障 |
I系与CTC II系通信状态 | 正常、故障 |
II系与CTC I系通信状态 | 正常、故障 |
II系与CTC II系通信状态 | 正常、故障 |
I系与轨道电路通信状态 | 正常、故障 |
II系与轨道电路通信状态 | 正常、故障 |
I系与LEU通信状态 | 正常、故障 |
II系与LEU通信状态 | 正常、故障 |
I系与继电器通信状态 | 正常、故障 |
II系与继电器通信状态 | 正常、故障 |
表3:系统报警表
I系与联锁I系通信故障 | I系与继电器通信故障 |
I系与联锁II系通信故障 | II系与继电器通信故障 |
II系与联锁I系通信故障 | LDJ驱动、采集不一致 |
II系与联锁II系通信故障 | UDJ驱动、采集不一致 |
I系与TSRS I系通信故障 | HDJ驱动、采集不一致 |
I系与TSRS II系通信故障 | 1DJ断丝报警 |
II系与TSRS I系通信故障 | 2DJ断丝报警 |
II系与TSRS II系通信故障 | 轨道状态通信、采集不一致 |
I系与相邻TCC I系通信故障 | 轨道状态通信、采集不一致 |
I系与相邻TCC II系通信故障 | 区间线路方向驱动、采集不一致 |
II系与相邻TCC I系通信故障 | 区段灾害状态告警 |
II系与相邻TCC II系通信故障 | 红灯断丝报警 |
I系与CTC I系通信故障 | I系主机离线报警 |
I系与CTC II系通信故障 | II系主机离线报警 |
II系与CTC I系通信故障 | I系驱采机故障报警 |
II系与CTC II系通信故障 | II系驱采机故障报警 |
I系与轨道电路通信故障 | I系通信机故障报警 |
II系与轨道电路通信故障 | II系通信机故障报警 |
I系与LEU通信故障 | I系板卡故障报警 |
II系与LEU通信故障 | II系板卡故障报警 |
云平台通过存储和处理这些信号数据,挖掘知识规则;然后通过与实时监测数据的对比进行系统状态的统计和辅助决策。
(1)TCC信号库的数据存储流程
下面通过图7所示的数据流程图来介绍云计算平台对TCC采集数据的存储流程:
a)由云计算平台发起对TCC历史监测数据的请求,通过云计算平台与电务段集中监测系统的连接,将请求转发给本电务段各个车站监测系统;
b)车站集中监测系统直接与车站的各个监测信号采集器连接,直接向TCC采集器发出历史数据采集请求;
c)TCC采集器将本地存储的历史监测数据通过电务段集中监测系统转发给云计算平台;
d)云计算平台的数据接收及格式转换模块将得到的TCC历史监测数据进行格式转换,分别以格式化的方式存储在Oracle集群及文本格式存储在HDFS上;
e)云计算平台的MapReduce并行处理架构对HDFS上的历史监测数据进行数据分析和挖掘,到的通信信息及知识规则存储在HBase列式数据库中;
f)云计算平台通过部署的Lucene对得到的历史监测数据进行索引建立,根据不同的关键字生成多种索引文件,包括时间、车站、线路等均需要生成对应的索引文件。
Lucene是建立在Hadoop之上的开源索引工具,可以通过并行的方式完成对HDFS上的文本数据建立索引。
(2)TCC实时监测数据处理流程
下面通过图8所示的数据流程图介绍云计算平台对TCC实时采集数据的处理:
a)TCC采集器定期通过集中监测系统将实时采集的监测数据传输给云计算平台;
b)云计算平台的数据接收及格式转换模块将接收的TCC实时监测数据传输给实时数据分析模块;
c)实时数据分析模块通过对实时监测数据的与HBase中知识规则及统计信息的比较及分析,得到TCC对应的系统状态、通信状态及系统报警状态的统计及分析结果;
d)云计算平台通过与电务段的连接将系统实时分析结果反馈给集中监测系统;
e)集中监测系统则根据权限将实时的系统状态通过人机交互设备反馈给系统管理人员,管理人员可以根据目前的系统运行状态分发调度指令、维修指令等。
下面进一步以车载ATP(车载计算机)信号为例来描述上述各个模块之间的关系和数据流程:
(1)ATP数据存储流程
a)由云计算平台发起对车载ATP历史监测数据的请求,通过云计算平台与电务段集中监测系统的连接,将请求转发给本电务段各个车站监测系统。
b)车站集中监测系统直接与车站的车载ATP监测信号采集器连接,直接向车载ATP采集器发出历史数据采集请求。
c)车载ATP采集器将本地存储的历史监测数据通过电务段集中监测系统转发给云计算平台。
d)云计算平台的数据接收及格式转换模块将得到的车载ATP历史监测数据进行格式转换,分别以格式化的方式存储在Oracle集群及文本格式存储在HDFS上。
所述历史监测数据库中的数据以格式化的形式存储,根据车载ATP监测数据的格式设计建立对应的数据库和数据表,所述数据接收及格式转换模块将得到的车载ATP监测数据转化为可以插入到数据表中的数据格式,并将其插入到对应的数据库及数据表中。
所述分布式文件系统以文本格式存储历史监测数据,各个电务段的车载ATP监测信号以不同的文件进行存储,以便于后续对监测信号进行分析和挖掘时使用。
e)云计算平台的MapReduce并行处理架构对HDFS上的历史监测数据进行数据分析和挖掘,到的通信信息及知识规则存储在HBase列式数据库中。
MapReduce并行处理架构主要包括Map和Reduce两个阶段,HDFS上的文本监测数据作为输入数据,通过Map阶段将文本分为与计算节点相同数目的文本块,然后对这些文本块用不同的处理器进行运算,将产生的中间结果通过Reduce节点进行汇总,从而产生知识规则数据。将这些规则数据存储在HBase列式数据库中,便于建立索引、快速查询及动态扩容。
为了产生车载ATP信号故障知识规则数据,需要对车载ATP历史监测信号进行分析,利用统计学原理对信号数据进行统计,形成监测信号与故障之间的先验及后验概率,也就是故障知识规则数据。
f)云计算平台通过部署的Lucene对得到的历史监测数据进行索引建立,根据不同的关键字生成多种索引文件,包括时间、车站、线路等均需要生成对应的索引文件。
(2)ATP实时监测数据处理流程
a)车载ATP信号采集器定期通过集中监测系统将实时采集的监测数据传输给云计算平台。
针对车载设备ATP处于移动状态的特性,为了实时采集该设备的数据,在车-地WIFI网络具备时将车载设备数据通过WIFI网络传送至车站,在车-地WIFI网络不具备时通过3G/LTE通道直接传输至云计算平台。以此实现系统也能够获取到车载设备ATP的实时监测数据,保证设备综合监控和设备远程运维的设备全面性。
b)云计算平台的数据接收及格式转换模块将接收的车载ATP实时监测数据传输给实时数据分析模块。
c)实时数据分析模块通过对实时监测数据的与HBase中知识规则及统计信息的比较及分析,得到车载ATP对应的系统状态、通信状态及系统报警状态的统计及分析结果。
进行车载ATP故障检测时,云平台将得到的车载ATP实时监测数据传输给实时数据分析模块,该模块通过将实时数据及HBase中相应的车载ATP故障知识规则数据进行对比,根据后验概率和实时信号数据的对比,判断当前系统是否存在故障等安全隐患。
d)云计算平台通过与电务段的连接将系统实时分析结果反馈给集中监测系统。
e)集中监测系统则根据权限将实时的系统状态通过人机交互设备反馈给系统管理人员,管理人员可以根据目前的系统运行状态分发调度指令、维修指令等。
尽管为说明目的公开了本发明的具体实施例和附图,其目的在于帮助理解本发明的内容并据以实施,但是本领域的技术人员可以理解:在不脱离本发明及所附的权利要求的精神和范围内,各种替换、变化和修改都是可能的。本发明不应局限于本说明书最佳实施例和附图所公开的内容,本发明要求保护的范围以权利要求书界定的范围为准。
Claims (11)
1.一种轨道交通监测数据的集中存储和处理方法,其步骤包括:
1)在车站、电务段及铁路管理部门分别设立集中监测系统,在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接;
2)车站的集中监测系统直接连接各种采集器,负责采集各类监测数据,包括历史监测数据和实时监测数据,电务段的集中监测系统收集本电务段包含的车站集中监测系统采集的各类监测数据,并传输给一综合运维平台;车站和电务段的集中监测系统不存储采集到的监测数据,只由综合运维平台存储采集到的监测数据;
3)在所述综合运维平台上建立HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构,形成云计算平台;
所述云计算平台将获取的历史监测数据转换为文本格式存储在HDFS上,并利用MapReduce并行处理架构对HDFS上存储的历史监测数据建立全文索引,通过全文索引技术对监测数据进行索引监理,并通过发布对应的查询接口实现碎片查询,支持用户按照不同的方式查询系统信息,包括按照时间查询和按照线路查询;
所述云计算平台接收到实时监测数据后,解析数据的格式,确定监测数据的设备及监测值,然后将数据插入到Oracle对应的数据库中,并将监测数据转换为文本存储在HDFS文件系统中;
所述云计算平台通过MapReduce并行处理架构对历史监测数据进行数据挖掘,产生知识规则数据并存储在Hbase数据库中,并将接收到的实时监测数据与所述知识规则数据进行匹配并进行统计分析,生成各类统计信息,并将所述各类统计信息反馈至电务段的集中监测系统;
4)电务段的集中监测系统将收到的所述各类统计信息传输给铁路管理部门的集中监测系统,铁路管理部门的集中监测系统根据所述各类统计信息产生调度指挥命令,并反馈给电务段的集中监测系统。
2.如权利要求1所述的方法,其特征在于:所述云计算平台包括资源层、数据处理层和接口层,所述资源层包括物理资源和虚拟资源,所述HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构位于所述数据处理层上,所述接口层包括各种WebService服务器。
3.如权利要求2所述的方法,其特征在于:所述虚拟资源通过虚拟化技术对物理资源进行虚拟化产生,包括计算资源池、存储资源池和网络资源池。
4.如权利要求1所述的方法,其特征在于:所述云计算平台利用统计学原理对历史监测数据进行统计,形成监测信号与故障之间的先验及后验概率,作为故障知识规则数据;进而将实时监测数据及相应的故障知识规则数据进行对比,判断当前系统是否存在安全隐患。
5.如权利要求1或2所述的方法,其特征在于,所述车站集中监测系统采集如下一种或多种设备的监测数据:TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。
6.如权利要求1或2所述的方法,其特征在于:所述铁路管理部门包括铁路局和铁路总公司,铁路局的集中监测系统接收所述各类统计信息,并产生所述调度指挥命令反馈给电务段的集中监测系统;铁路局的集中监测系统还将各类统计信息传输给铁路总公司的集中监测系统。
7.一种采用权利要求1所述方法的轨道交通监测数据的集中存储和处理系统,其特征在于,包括分别位于车站、电务段及铁路管理部门的集中监测系统,在车站与电务段的集中监测系统间以及电务段与铁路管理部门的集中监测系统间建立通信连接;电务段的集中监测系统还连接一综合运维平台;
车站的集中监测系统负责采集各类监测数据;
所述综合运维平台为一云计算平台,其上建立HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构,负责从电务段的集中监测系统接收所述监测数据进行存储和分析挖掘,产生知识规则数据和各类统计信息,并将所述各类统计信息反馈至电务段的集中监测系统;
电务段的集中监测系统负责收集本电务段包含的车站集中监测系统采集的各类监测数据并传输给所述综合运维平台,以及从所述综合运维平台接收所述各类统计信息并传输给铁路管理部门的集中监测系统;
铁路管理部门的集中监测系统负责根据所述各类统计信息产生调度指挥命令,并反馈给电务段的集中监测系统。
8.如权利要求7所述的系统,其特征在于:所述云计算平台包括资源层、数据处理层和接口层,所述资源层包括物理资源和虚拟资源,所述HDFS分布式文件系统、Hbase数据库、Oracle数据库以及MapReduce并行处理架构位于所述数据处理层上,所述接口层包括各种WebService服务器。
9.如权利要求7或8所述的系统,其特征在于:在电务段和铁路管理部门还设有与所述集中监测系统连接的人机交互设备。
10.如权利要求7或8所述的系统,其特征在于,所述车站集中监测系统连接如下一种或多种设备以采集监测数据:TCC/CBI、轨道电路应答器、CTC站机电源屏、信号安全网、GSM-R无线网信号安全网、CTC中心、DMS/LAIS、RBC/TSRS。
11.如权利要求7或8所述的系统,其特征在于,所述铁路管理部门包括铁路局和铁路总公司,铁路局的集中监测系统负责接收所述各类统计信息,并产生所述调度指挥命令反馈给电务段的集中监测系统;铁路局的集中监测系统还负责将各类统计信息传输给铁路总公司的集中监测系统。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310279514.0A CN103338261B (zh) | 2013-07-04 | 2013-07-04 | 一种轨道交通监测数据的存储和处理方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310279514.0A CN103338261B (zh) | 2013-07-04 | 2013-07-04 | 一种轨道交通监测数据的存储和处理方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103338261A CN103338261A (zh) | 2013-10-02 |
CN103338261B true CN103338261B (zh) | 2016-06-29 |
Family
ID=49246355
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310279514.0A Active CN103338261B (zh) | 2013-07-04 | 2013-07-04 | 一种轨道交通监测数据的存储和处理方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103338261B (zh) |
Families Citing this family (46)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103646541B (zh) * | 2013-12-16 | 2017-05-24 | 电子科技大学 | 一种基于Hadoop的车辆拥挤度获取方法 |
CN103678936B (zh) * | 2013-12-26 | 2017-09-22 | 清华大学 | 一种多部件工程系统中异常部件定位方法 |
CN104765651B (zh) * | 2014-01-06 | 2019-02-26 | 中国移动通信集团福建有限公司 | 一种数据处理方法和装置 |
CN103780696A (zh) * | 2014-01-23 | 2014-05-07 | 北京荣之联科技股份有限公司 | 基于分布式推送的云监控方法、装置及系统 |
CN103812699A (zh) * | 2014-02-17 | 2014-05-21 | 无锡华云数据技术服务有限公司 | 基于云计算的监控管理系统 |
CN103902838B (zh) * | 2014-04-17 | 2018-06-01 | 北京泰乐德信息技术有限公司 | 一种基于云计算的tmis车流测定方法及系统 |
CN105335362B (zh) * | 2014-05-28 | 2019-06-11 | 阿里巴巴集团控股有限公司 | 实时数据的处理方法及系统、即时处理系统 |
CN104077552B (zh) * | 2014-07-07 | 2017-08-25 | 北京泰乐德信息技术有限公司 | 一种基于云计算的轨道交通信号综合运维方法及系统 |
CN104168334A (zh) * | 2014-09-02 | 2014-11-26 | 成都绿线网络科技有限公司 | 一种基于saas云平台的中间件 |
CN104281980B (zh) * | 2014-09-28 | 2018-04-27 | 华电国际电力股份有限公司技术服务中心 | 基于分布式计算的火力发电机组远程诊断方法及系统 |
CN104320448B (zh) * | 2014-10-17 | 2019-11-01 | 张维加 | 一种基于大数据的计算设备的缓存与预取加速方法和装置 |
CN104331435B (zh) * | 2014-10-22 | 2017-11-21 | 国家电网公司 | 一种基于Hadoop大数据平台的低影响高效率的海量数据抽取方法 |
CN104516955A (zh) * | 2014-12-16 | 2015-04-15 | 北京中交兴路车联网科技有限公司 | 一种海量车机轨迹数据的存储方法 |
CN104612531B (zh) * | 2014-12-31 | 2016-05-04 | 重庆川仪自动化股份有限公司 | 轨道交通安全屏蔽门控制系统的通信响应方法 |
CN104702676B (zh) * | 2015-02-12 | 2018-08-21 | 中国铁路总公司 | 一种铁路分布式数据中心资源调度方法 |
CN104890702A (zh) * | 2015-05-27 | 2015-09-09 | 中国铁路总公司 | 一种铁路信号车地综合分析监测系统 |
CN105206021A (zh) * | 2015-08-28 | 2015-12-30 | 陕西西北铁道电子有限公司 | 一种轨道车揭示命令的远程发布系统 |
CN105243914A (zh) * | 2015-11-26 | 2016-01-13 | 湘潭电机股份有限公司 | 一种城市轨道交通车辆行车实验装置 |
CN105574593B (zh) * | 2015-12-18 | 2020-05-05 | 中南大学 | 基于云计算和大数据的轨道状态静态检控系统及方法 |
CN107276782B (zh) * | 2016-04-07 | 2020-10-16 | 中国移动通信集团福建有限公司 | 一种信息处理方法、设备和系统 |
CN106021613A (zh) * | 2016-06-30 | 2016-10-12 | 武汉理工大学 | 一种基于Hadoop的桥梁健康监测系统 |
CN106406296B (zh) * | 2016-12-14 | 2019-04-23 | 东北大学 | 一种基于车载和云端的列车故障诊断系统及方法 |
CN106708016B (zh) * | 2016-12-22 | 2019-12-10 | 中国石油天然气股份有限公司 | 故障监控方法和装置 |
CN107241397A (zh) * | 2017-05-24 | 2017-10-10 | 清华大学 | 一种基于云平台的多级列车调度指挥系统 |
CN107707659A (zh) * | 2017-10-11 | 2018-02-16 | 郑州云海信息技术有限公司 | 一种大数据分析方法和系统 |
CN108306789A (zh) * | 2018-01-30 | 2018-07-20 | 安徽皖通邮电股份有限公司 | 一种并行测试批量产品并云端处理测试数据的测量方法 |
CN108860223B (zh) * | 2018-05-31 | 2020-11-06 | 北京全路通信信号研究设计院集团有限公司 | 一种数据处理系统及方法 |
CN109218400A (zh) * | 2018-08-06 | 2019-01-15 | 深圳宇翊技术股份有限公司 | 一种基于虚拟化和分布式架构实现的pis中心子系统 |
CN109299155A (zh) * | 2018-08-21 | 2019-02-01 | 南京理工大学 | 一种基于大数据的城市轨道交通信号设备故障诊断系统及其诊断方法 |
CN109376168A (zh) * | 2018-10-23 | 2019-02-22 | 广东电网有限责任公司 | 一种主网设备的大数据分析系统 |
CN109377090A (zh) * | 2018-11-22 | 2019-02-22 | 湖南铁路科技职业技术学院 | 一种基于云服务的铁路运输数据通讯支撑平台 |
CN109214724A (zh) * | 2018-11-22 | 2019-01-15 | 湖南铁路科技职业技术学院 | 一种基于云服务的铁路运输安全管理系统 |
CN110027596B (zh) * | 2019-03-29 | 2020-07-24 | 北京交通大学 | 一种基于云计算的轨道交通列车运行控制系统 |
CN110320842B (zh) * | 2019-07-16 | 2021-09-07 | 东北大学 | 用于氧化铝生产过程的多尺度数据采集与处理装置及方法 |
CN111065095A (zh) * | 2020-01-08 | 2020-04-24 | 方楚持 | 一种无线量子通信信息传递方法 |
CN111176121A (zh) * | 2020-02-06 | 2020-05-19 | 山东大学 | 一种基于云平台的整车控制器优化系统及方法 |
CN111475489A (zh) * | 2020-04-14 | 2020-07-31 | 北京思特奇信息技术股份有限公司 | 一种数据处理的方法和装置 |
CN111930807B (zh) * | 2020-08-17 | 2021-09-10 | 广州新科佳都科技有限公司 | 一种轨道交通数据分析方法、装置、设备及存储介质 |
CN112183771A (zh) * | 2020-08-18 | 2021-01-05 | 北京城建信捷轨道交通工程咨询有限公司 | 一种轨道交通智能运维生态系统及其运行方法 |
CN112003956B (zh) * | 2020-10-27 | 2021-01-15 | 武汉中科通达高新技术股份有限公司 | 一种交管系统 |
CN112660211A (zh) * | 2021-01-16 | 2021-04-16 | 湖南科技大学 | 铁路机车智能运维管理系统 |
CN112622990A (zh) * | 2021-01-16 | 2021-04-09 | 湖南科技大学 | 城轨地铁车辆智能运维管理系统 |
CN113220681A (zh) * | 2021-05-07 | 2021-08-06 | 中车青岛四方车辆研究所有限公司 | 一种以太网数据记录分析装置 |
CN113581248A (zh) * | 2021-05-31 | 2021-11-02 | 通号(北京)轨道工业集团有限公司轨道交通技术研究院 | 一种计轴监测方法及系统 |
CN113625264A (zh) * | 2021-06-16 | 2021-11-09 | 中国铁道科学研究院集团有限公司铁道建筑研究所 | 一种并行处理铁路检测大数据的方法及系统 |
CN113704310B (zh) * | 2021-09-08 | 2023-05-23 | 北京城建设计发展集团股份有限公司 | 一种轨道交通行车指挥系统及行车数据处理方法 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101917237A (zh) * | 2010-07-27 | 2010-12-15 | 北京全路通信信号研究设计院 | 一种铁路信号监测方法和系统 |
CN101950297A (zh) * | 2010-09-10 | 2011-01-19 | 北京大学 | 一种海量语义数据的存储和查询方法及装置 |
CN102663577A (zh) * | 2012-04-13 | 2012-09-12 | 苏州盛世华安智能科技有限公司 | 一种基于云平台的智慧城市物联系统 |
US8412733B1 (en) * | 2003-03-15 | 2013-04-02 | SQL Stream Inc. | Method for distributed RDSMS |
CN103049556A (zh) * | 2012-12-28 | 2013-04-17 | 中国科学院深圳先进技术研究院 | 一种海量医疗数据的快速统计查询方法 |
CN103064670A (zh) * | 2012-12-18 | 2013-04-24 | 清华大学 | 基于位置网的创新平台数据管理方法及系统 |
-
2013
- 2013-07-04 CN CN201310279514.0A patent/CN103338261B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8412733B1 (en) * | 2003-03-15 | 2013-04-02 | SQL Stream Inc. | Method for distributed RDSMS |
CN101917237A (zh) * | 2010-07-27 | 2010-12-15 | 北京全路通信信号研究设计院 | 一种铁路信号监测方法和系统 |
CN101950297A (zh) * | 2010-09-10 | 2011-01-19 | 北京大学 | 一种海量语义数据的存储和查询方法及装置 |
CN102663577A (zh) * | 2012-04-13 | 2012-09-12 | 苏州盛世华安智能科技有限公司 | 一种基于云平台的智慧城市物联系统 |
CN103064670A (zh) * | 2012-12-18 | 2013-04-24 | 清华大学 | 基于位置网的创新平台数据管理方法及系统 |
CN103049556A (zh) * | 2012-12-28 | 2013-04-17 | 中国科学院深圳先进技术研究院 | 一种海量医疗数据的快速统计查询方法 |
Also Published As
Publication number | Publication date |
---|---|
CN103338261A (zh) | 2013-10-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103338261B (zh) | 一种轨道交通监测数据的存储和处理方法及系统 | |
CN104077552B (zh) | 一种基于云计算的轨道交通信号综合运维方法及系统 | |
CN101916507B (zh) | 桥梁健康监测系统 | |
CN112650762B (zh) | 数据质量监控的方法、装置、电子设备以及存储介质 | |
CN105554059A (zh) | 基于北斗导航技术的物流运输智能感知与位置服务系统 | |
CN101997709B (zh) | 一种根告警数据分析的方法及其系统 | |
CN105631026A (zh) | 一种安全数据分析系统 | |
CN109255523A (zh) | 基于kks编码规则和大数据架构的分析指标计算平台 | |
CN103491354A (zh) | 一种系统运行监控可视化平台 | |
CN103593804A (zh) | 一种电力信息通信调度监控平台 | |
CN103765411A (zh) | 数据分析系统 | |
CN104008443A (zh) | 一种陆地观测卫星数据地面接收站网的任务规划调度系统 | |
CN110990391A (zh) | 多源异构数据的整合方法、系统、计算机设备及存储介质 | |
CN102880802A (zh) | 一种用于面向工矿企业安全生产云服务平台系统的重大危险源的分析评价方法 | |
CN104777827A (zh) | 高速铁路信号系统车载设备故障诊断方法 | |
CN102929827A (zh) | 一种用于面向工矿企业的安全生产云服务平台的无线传感器数据采集集群 | |
CN102903010A (zh) | 一种用于面向工矿企业的安全生产云服务平台的基于支持向量机的异常判断方法 | |
CN102930372A (zh) | 一种用于面向工矿企业安全生产云服务平台系统的关联规则的数据分析方法 | |
CN104464271A (zh) | 智能交通运维管理系统 | |
DE102017208293A1 (de) | Industrielle Einrichtungsverwaltungssysteme und Verfahren dafür | |
CN114267178A (zh) | 一种车站的智能运营维护方法及装置 | |
CN113179173A (zh) | 一种用于高速公路系统的运维监控系统 | |
CN104954181A (zh) | 一种分布式集群设备故障预警方法 | |
CN105096664A (zh) | 一种中小型机场异地在线指挥调度托管系统 | |
CN106789347A (zh) | 一种基于告警数据实现告警关联和网络故障诊断的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |