本发明涉及轨道交通中使用的一种信息管理系统。
背景技术：
随着社会的发展，城市人口不断增加。为了方便出行，人们对于汽车的需求日益增加，也使得城市车辆的保有率不断提高。
而城市车辆保有率的提高，导致城市交通拥堵问题日益严重。而且，汽车保有量的增加，也因为其尾气的排放，对于环境的污染日益增加。
为了解决人们出行不便和环境污染的问题，社会开始大力发展轨道交通。轨道交通的有序运行，离不开对其系统运行数据正常的采集、处理、交换和显示。
现有的轨道交通项目中，其管理系统通常是通过网络控制协议tcp、udp进行网络数据的交换，协议按照特定的格式进行数据收集，所述管理系统对收集到的数据进行处理并显示。
其中所述管理系统接收数据的方式大多采用主动获取的形式，其对处理后的数据在页面进行实时显示各状态数据时，也是通过所述页面主动获取的形式进行刷新。
但是，现有的轨道交通项目采用的网络协议内容的格式，不能满足通用的多类型子系统交互网络数据的要求，并且由于涉及的子系统类型较多，需要针对不同的子系统制定专属的网络协议、处理和展示方式。也就是说，其制定的网络协议格式不具备通用性。
进一步的，现有技术中对处理多系统大流量数据、大容量数据的存储以及缓存历史数据存在较大的瓶颈，其不能快速有效的完成数据处理。同时通过页 面获取实时状态信息，页面负担过重，导致其经常不能实时刷新，甚至出现浏览器崩溃的情况。
因此，确有必要来开发一种新型的轨道交通中使用的信息管理系统，来克服现有技术中的缺陷。
技术实现要素：
本发明的目的在于提供一种新型的轨道交通维护管理系统，其能够对轨道交通中的数据进行实时数据采集、处理以及状态显示。
为实现上述发明目的，本发明采用了如下技术方案：
一种轨道交通维护管理系统，其包括数据管理系统、至少两个类型的子系统、消息服务器以及界面。其中所述数据管理系统通过通用协议格式与各个所述子系统之间进行网络数据通信。所述数据管理系统会将其处理后的消息数据发送给所述消息服务器，所述消息服务器再将消息数据实时发送给所述界面进行实时显示。
进一步的，在不同实施方式中，其中所述通用协议格式，采用的数据格式定义至少2层数据结构，其中上层数据结构定义包含了下层数据结构定义中的所有内容。
进一步的，在不同实施方式中，其中所述数据格式定义4层数据结构，从上层数据结构到下层数据结构依次为applicationdata(应用数据定义)、datainfo(数据类型定义)、devdata(具体数据类型定义)以及attrdata(对象属性类型定义)。
进一步的，在不同实施方式中，其中所述上层数据结构applicationdata数据结构中的data字段定义了数据长度，包含其下层数据结构中所述datainfo、devdata、attrdata数据结构中的协议数据。
进一步的，在不同实施方式中，其中所述datainfo数据结构中的info字段定义了数据长度，包含其下层数据结构中所述devdata、attrdata数据结构中的协议数据；而所述devdata数据结构中包括的attrdata字段定义了数据长度，包 含其下层数据结构attrdata数据结构中的协议数据；所述attrdata数据结构定义了数据具体属性值的类型、长度、数据。
进一步的，在不同实施方式中，其中所述数据管理系统与各个子系统之间使用apachemina技术进行数据的发送与接收，为配合所述通用协议格式，其会对数据的编码、解码类进行重写。
进一步的，在不同实施方式中，其中所述数据管理系统在接收数据包时，其会单独启用一个新的工作线程进行数据的处理，从而保证处理数据的及时性。
进一步的，在不同实施方式中，其中所述数据管理系统使用apacheactivemq技术向所述消息服务器进行实时消息数据发送，所述消息服务器为所述界面的消息订阅提供入口。
进一步的，在不同实施方式中，其中所述界面使用apacheactivemq技术向所述消息服务器进行实时消息数据订阅，所述消息服务器向所述订阅的界面进行实时消息数据的推送，所述界面接收到数据进行实时状态显示，从而减少了所述界面的数据负载。
进一步的，在不同实施方式中，其还包括用于数据存储的数据库，其中所述数据库使用其固有的线程池技术进行存储数据的同时，所述数据管理系统还为每个所述子系统启用单独的工作线程池进行数据的存储，从而保证了短暂间隔内采集到大容量数据存储到所述数据库的实时性及完整性。
进一步的，在不同实施方式中，其中所述子系统包括微机监测(wjtx)子系统、区域控制(zc)子系统、连锁(cbi)子系统、车载(obcu)子系统以及ats子系统中的至少两个类型。
相比于现有技术，本发明的优势在于，本发明涉及的一种轨道交通维护管理系统，其提供了一种对于多个不同类型子系统进行实时数据采集、处理以及状态显示的解决方案，有效解决了现有技术中由于收集多个不同类型子系统的数据，而出现的系统不能实时接收、不能实时处理及实时状态显示的问题。
附图说明
图1是本发明的一个实施方式提供的一种轨道交通维护管理系统的逻辑结构图，其中还显示了所述系统内部之间的数据流程。
具体实施方式
以下结合较佳实施例及其附图对本发明涉及的一种轨道交通维护管理系统的技术方案作进一步非限制性的详细说明。
请参阅图1所示，本发明的一个实施方式提供了一种轨道交通维护管理系统，其包括相互之间能够进行网络数据交换的数据管理系统、若干不同类型的子系统、消息服务器、界面以及数据库。
所述数据管理系统与各个子系统之间的通信方式，可以是在连接未建立时，hsi周期性向hsr发送连接初始化数据包(rfc)，所述rfc的applicationdatafield长度为0，周期为1000ms。所述hsr收到所述rfc之后，做出回应，连接建立。
连接建立之后，所述hsi每周期向所述hsr发送poll包，周期长度为500ms。所述hsr收到所述poll包之后做出回复。所述hsr的回复中，当applicationdatafield的长度小于1350时，每周期一个数据包；当超出1350时，需要分多个包进行回复，即：每个周期回复多个包。
所述子系统包括微机监测(wjtx)子系统(多站点)、区域控制(zc)子系统(多站点)、连锁(cbi)子系统(多站点)、车载(obcu)子系统(多辆车)以及ats子系统等等。以上涉及的子系统只是举例性说明，并不限于，其还能根据其所应用的轨道交通实际项目的需要，进行增加。
进一步的，如图1中所示，整个系统内部之间的网络数据交流可以包括5个数据流程。以下将对各个数据流程分别进行说明。
其中数据流程①和②，是所述数据管理系统与各个子系统之间的数据流程。其为网络通信数据采用tcp、udp协议，利用apachemina技术进行数据的发送与接收。在接收每一包网络数据包时，所述数据管理系统会单独启用一个新的工作线程进行数据的处理，保证了处理数据的及时性。
其中为避免所述数据管理系统对各个子系统涉及的不同协议格式数据处理的情况，本发明提出了一个全新的通用协议格式来定义所述网络通信数据，通过遵循所述通用协议格式，所述数据管理系统能够对各个子系统的任何状态数据进行接收，然后对其进行解析，通过解析可得出详细的数据类型含义，提高了代码复用率。
进一步的，在一个具体实施方式中，其中所述通用协议格式中的数据格式定义了4层数据结构，从上层数据结构到下层数据结构依次为applicationdata(应用数据定义)、datainfo(数据类型定义)、devdata(具体数据类型定义)以及attrdata(对象属性类型定义)。其中上层数据结构定义包含了下层数据结构定义的所有内容。具体来讲即：
所述上层数据结构applicationdata数据结构中的data字段定义了数据长度，包含其下层数据结构中所述datainfo、devdata、attrdata数据结构中的协议数据。
所述datainfo数据结构中的info字段定义了数据长度，包含其下层数据结构中所述devdata、attrdata数据结构中的协议数据。
所述devdata数据结构中包括的attrdata字段定义了数据长度，包含其下层数据结构attrdata数据结构中的协议数据。
所述attrdata数据结构定义了数据的具体属性值的类型、长度和数据内容。
在一个具体实施方式中，其中所述通用协议格式中数据格式的具体结构数据定义如下：
datainfo的定义如下：
devdata的定义如下：
attrdata的定义如下：
其中所述applicationdata数据结构定义为：
●typecount，长度为一个字节，用于描述本数据包中包含多少中类型的数据信息；
●info
applicationdatafield中包含的所有的数据信息，是由多个datainfo数据结构组合在一起的数组，长度就是所有的datainfo的长度之和。
所述datainfo数据结构定义为：
●datatype，长度为1个字节，用于描述数据的类型；
●datacount，长度为2个字节，用于描述datainfo结构中包含的具体数据的个数；
●info，由所有的devdata结构组成，长度为所有devdata的长度之和。
所述devdata数据结构定义为：
●attrcount，长度为1个字节，表明data结构中所包含的属性的个数；
●attrdatas，由所有的attrdata组成，长度为所有attrdata结构长度之和。
所述attrdata数据结构定义为：
●attrtype，属性的类型，长度为1个字节；
●attrlen，属性数据的长度，长度为一个字节。即：属性的最长长度为256个字节；
●attrvalue，属性的值，以字节数组的形式定义，长度为attrlen。属性数据的存储格式根据具体应用确定。
数据流程③，是所述数据管理系统按照所述通用协议格式对接收到的所述网络通信数据进行解析，按照约定的数据类型进行翻译，形成数据对象，利用apacheactivemq技术将所述对象数据发送给所述消息服务器进行实时消息发布，所述消息服务器还能为所述界面的订阅提供入口。其中设立单独的所述消息服务器，能够保证数据推送的实时性，提高了系统的整体性能。在不同实施方式中，其中所述消息服务器的设置数量，可根据需要而定，并不限定。
数据流程④，其为对所述网络通信数据进行存储的数据流程。其中所述网络通信数据是使用多线程+线程池的方式存储到数据库中。具体来讲，就是所述网络通信数据存储数据库过程中不但使用所述数据库固有的线程池技术，所述数据管理系统还为每个所述子系统启用单独的工作线程池进行数据的存储，保证了短暂间隔内收集到大容量数据存储到所述数据库的实时性及完整性。
数据流程⑤，是所述界面通过apacheactivemq的订阅技术向所述消息服务器进行消息订阅，所述消息服务器对订阅的所述界面进行实时消息的推送，所述界面接收到数据进行状态的实时显示，如此减少了所述界面的前台页面的数据负载。
其中所述界面，在不同实施方式中，其可以是任意具有数据查询显示功能的单元装置。例如，客户端或是显示页面等等。
本发明涉及的一种轨道交通维护管理系统，其提供了一种对于多个不同类型子系统进行实时数据采集、处理以及状态显示的解决方案，有效解决了现有技术中由于收集多个不同类型子系统的数据，而出现的系统不能实时接收、不能实时处理及实时状态显示的问题。
需要指出的是，上述较佳实施例仅为说明本发明的技术构思及特点，其目的在于让熟悉此项技术的人士能够了解本发明的内容并据以实施，并不能以此限制本发明的保护范围。凡根据本发明精神实质所作的等效变化或修饰，都应涵盖在本发明的保护范围之内。