一种轨道交通系统综合网管方法、装置及系统

摘要

本发明提出了一种轨道交通系统综合网管方法、装置及轨道交通综合网管系统。方法用于轨道交通系统中子系统网管和数据处理中心之间的数据传输管理，包括：接收子系统网管上传的数据，并将所述数据转换为具有通用的数据模式的规范化消息数据；将所述规范化消息数据传输到消息队列中间件服务器；所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布；根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心。降低了数据处理中心和各个子系统网管之间数据的直接耦合，保证整个综合网管系统的稳定性，利用消息队列中间件的高可用性保证数据的完整性。

权利要求

1.一种轨道交通系统综合网管方法，用于轨道交通系统中子系统网管和数据处理中心之间的数据传输管理，其特征在于，包括：接收子系统网管上传的数据，并将所述数据转换为具有通用的数据模式的规范化消息数据；

将所述规范化消息数据传输到消息队列中间件服务器；

所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布；

根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心。

2.根据权利要求1所述的轨道交通系统综合网管方法，其特征在于，所述接收子系统网管上传的数据，并将所述数据转换为具有通用的数据模式的规范化消息数据，包括：接收子系统网管根据第一协议上传的数据，并根据所述第一协议解析得到解析后的数据；

将所述解析后的数据按照第二协议转换为具有通用的数据模式的规范化消息数据；

其中，所述第一协议和第二协议为不同的通信协议。

3.根据权利要求1所述的轨道交通系统综合网管方法，其特征在于，所述将所述规范化消息数据传输到消息队列中间件服务器，包括：将所述规范化消息数据以各个子系统网管的识别标识作为关键值，按照所述关键值顺序传输到所述消息队列中间件服务器。

4.根据权利要求1所述的轨道交通系统综合网管方法，其特征在于，所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布，包括：在所述消息队列中间件服务器中为每个所述子系统网管建立一个对应的消息队列，获取消息数据的来源子系统网管，并将所述消息数据发布到与所述来源子系统网管对应的消息队列中。

5.根据权利要求4所述的轨道交通系统综合网管方法，其特征在于，还包括：对消息队列中间件服务器中的消息进行定期检查，从各个消息队列中清除满足预设丢弃条件的消息。

6.根据权利要求1所述的轨道交通系统综合网管方法，其特征在于，所述根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心之后，还包括：数据处理中心将消息数据进行分类存储，将消息数据中的临时性数据存储在本地数据库，设备监控数据存入云端数据库。

7.一种轨道交通系统综合网管装置，用于轨道交通系统中子系统网管和数据处理中心之间的数据传输管理，其特征在于，包括：接口适配器模块，用于接收子系统网管上传的数据，将所述数据转换为具有通用的数据模式的规范化消息数据，以及将所述规范化消息数据传输到消息队列中间件服务器；

消息队列中间件服务器，用于获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布，以及根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心。

8.根据权利要求7所述的轨道交通系统综合网管装置，其特征在于，所述接口适配器模块接收子系统网管上传的数据，将所述数据转换为具有通用的数据模式的规范化消息数据，包括：接收子系统网管根据第一协议上传的数据，并根据所述第一协议解析得到解析后的数据；

将所述解析后的数据按照第二协议转换为具有通用的数据模式的规范化消息数据；

其中，所述第一协议和第二协议为不同的通信协议。

9.根据权利要求7所述的轨道交通系统综合网管装置，其特征在于，所述接口适配器模块将所述规范化消息数据传输到消息队列中间件服务器包括：将所述规范化消息数据以各个子系统网管的识别标识作为关键值，按照所述关键值顺序传输到所述消息队列中间件服务器。

10.根据权利要求7所述的轨道交通系统综合网管装置，其特征在于，所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布，包括：在所述消息队列中间件服务器为每个所述子系统网管建立一个对应的消息队列，获取消息数据的来源子系统网管，并将所述消息数据发布到与所述来源子系统网管对应的消息队列中。

11.根据权利要求10所述的轨道交通系统综合网管装置，其特征在于，所述消息队列中间件服务器还用于：对消息队列中间件服务器中的消息进行定期检查，从各个消息队列中清除满足预设丢弃条件的消息。

12.一种轨道交通系统综合网管系统，包括通信连接的多个子系统网管、数据处理中心、数据库和综合网管中心，其特征在于，还包括：根据权利要求7-12中任意一项所述的轨道交通系统综合网管装置，所述轨道交通系统综合网管装置与所述多个子系统网管和所述数据处理中心通信连接，用于所述多个子系统网管和所述数据处理中心之间的数据传输管理。

13.根据权利要求12所述的轨道交通系统综合网管系统，其特征在于，所述数据处理中心还用于将消息数据进行分类存储，将消息数据中的临时性数据存储在本地数据库，设备监控数据存入云端数据库；

所述综合网管中心还用于从所述云端数据库获取所述设备监控数据，并进行设备监控和故障统计处理以及大数据分析。

说明书

一种轨道交通系统综合网管方法、装置及系统

技术领域

[0001] 本发明涉及轨道交通技术领域，更确切地说，涉及轨道交通综合网管系统中轨道交通系统综合网管方法、装置及轨道交通综合网管系统。

背景技术

[0002] 轨道交通管理系统是轨道交通运营的基础，用于对轨道交通系统中的各个子系统和设备等进行管理，而能够高效无误的运行是轨道交通系统一个基本要求。轨道交通系统是一个复杂的系统，它包括众多子系统，以及大量的系统设备，且每个子系统往往还包括自己的子系统网管，因此，轨道交通管理系统的构成非常复杂。一般来说，轨道交通管理系统可包括综合网管系统，综合网管系统包括各个子系统网管、数据处理中心和综合网管中心等组成部分，由综合网管系统对各个子系统网管进行统一管理。这就要求综合网管系统对各个子系统的设备状态信息和告警信息进行全面的掌握和集中处理，对综合网管系统的通信和信息处理能力都有很高的要求。

[0003] 现有的技术方案中，各个子系统网管都是直接连接到综合网管的数据处理中心，综合网管数据处理中心负责对获取到的设备数据信息进行处理，并把最终数据保存到存储设备。如此，能够实现对各个子系统设备状态的基本监控和各种信息的存储，但当子系统过多，或者系统内的设备数量过多，大量的实时数据并发时，难以保证系统不会有数据丢失，系统可靠性难以保证。

[0004] 并且，存在大量数据处理的无序性，可能出现先接收到的数据被滞后处理，而新的数据却被滞后的数据覆盖掉的情况，从而导致设备状态的监控出现差错，从而误导网管人员。

发明内容

[0005] 本发明旨在至少在一定程度上解决上述相关技术中的技术问题之一。提供一种多个子系统网管进行数据发送时，能够保证数据及时处理保存且不会丢失的轨道交通系统综合网管方法。

[0006] 为了达到上述目的，根据本发明第一方面的实施例提出了一种轨道交通系统综合网管方法，用于轨道交通系统中子系统网管和数据处理中心之间的数据传输管理，其包括：

[0007] 接收子系统网管上传的数据，并将所述数据转换为具有通用的数据模式的规范化消息数据；

[0008] 将所述规范化消息数据传输到消息队列中间件服务器；

[0009] 所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布；

[0010] 根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心。

[0011] 在一些实施例中，所述接收子系统网管上传的数据，并将所述数据转换为具有通用的数据模式的规范化消息数据，包括：

[0012] 接收子系统网管根据第一协议上传的数据，并根据所述第一协议解析得到解析后的数据；

[0013] 将所述解析后的数据按照第二协议转换为具有通用的数据模式的规范化消息数据；

[0014] 其中，所述第一协议和第二协议为不同的通信协议。

[0015] 在一些实施例中，所述将所述规范化消息数据传输到消息队列中间件服务器，包括：

[0016] 将所述规范化消息数据以各个子系统网管的识别标识作为关键值，按照所述关键值顺序传输到所述消息队列中间件服务器。

[0017] 在一些实施例中，所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布，包括：

[0018] 在所述消息队列中间件服务器为每个所述子系统网管建立一个对应的消息队列，[0019] 获取消息数据的来源子系统网管，并将所述消息数据发布到与所述来源子系统网管对应的消息队列中。

[0020] 在一些实施例中，所述的轨道交通系统综合网管方法，还包括：

[0021] 对消息队列中间件服务器中的消息进行定期检查，从各个消息队列中清除满足预设丢弃条件的消息。

[0022] 在一些实施例中，所述根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心之后，还包括：

[0023] 数据处理中心将消息数据进行分类存储，将消息数据中的临时性数据存储在本地数据库，设备监控数据存入云端数据库。

[0024] 通过本发明的轨道交通系统综合网管方法，利用综合网管的数据处理中心和消息队列中间件服务器这种两层分离的结构模式，可以降低数据处理中心和各个子系统网管之间数据的直接耦合，保证整个综合网管系统的稳定性，此外，利用消息队列中间件服务器中消息队列中间件的高可用性保证数据的完整性，很好地解决了网络不可靠下的消息丢失问题和高并发情况下的性能瓶颈，以及子系统网管消息洪流出现时对下游综合网管数据处理中心造成的流量冲击。

[0025] 为了实现上述目的，根据本发明第二方面的实施例提供了一种轨道交通系统综合网管装置，用于轨道交通系统中子系统网管和数据处理中心之间的数据传输管理，其包括：

[0026] 接口适配器模块，用于接收子系统网管上传的数据，将所述数据转换为具有通用的数据模式的规范化消息数据，以及将所述规范化消息数据传输到消息队列中间件服务器；

[0027] 消息队列中间件服务器，用于获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布，以及根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心。

[0028] 在一些实施例中，所述接口适配器模块接收子系统网管上传的数据，将所述数据转换为具有通用的数据模式的规范化消息数据，包括：

[0029] 接收子系统网管根据第一协议上传的数据，并根据所述第一协议解析得到解析后的数据；

[0030] 将所述解析后的数据按照第二协议转换为具有通用的数据模式的规范化消息数据；

[0031] 其中，所述第一协议和第二协议为不同的通信协议。

[0032] 在一些实施例中，所述接口适配器模块将所述规范化消息数据传输到消息队列中间件服务器包括：

[0033] 将所述规范化消息数据以各个子系统网管的识别标识作为关键值，按照所述关键值顺序传输到所述中间件服务器。

[0034] 在一些实施例中，所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布，包括：

[0035] 在所述消息队列中间件服务器为每个所述子系统网管建立一个对应的消息队列，[0036] 获取消息数据的来源子系统网管，并将所述消息数据发布到与所述来源子系统网管对应的消息队列中。

[0037] 在一些实施例中，所述消息队列中间件服务器还用于：

[0038] 对消息队列中间件服务器中的消息进行定期检查，从各个消息队列中清除满足预设丢弃条件的消息。

[0039] 通过本发明的轨道交通系统综合网管装置，利用综合网管数据处理中心和消息队列中间件服务器这种两层分离的结构模式，可以降低数据处理中心和各个子系统网管之间数据的直接耦合，保证整个综合网管系统的稳定性，此外，利用利用消息队列中间件服务器中消息队列中间件的高可用性保证数据的完整性，很好地解决了网络不可靠下的消息丢失问题和高并发情况下的性能瓶颈，以及子系统网管消息洪流出现时对下游综合网管数据处理中心造成的流量冲击。

[0040] 为了实现上述目的，根据本发明第三方面的实施例提供了一种轨道交通系统综合网管系统，包括通信连接的多个子系统网管、数据处理中心、数据库和综合网管中心，还包括：根据本发明第二方面实施例中任意一项所述的轨道交通系统综合网管装置，所述轨道交通系统综合网管装置与所述多个子系统网管和所述数据处理中心通信连接，用于所述多个子系统网管和所述数据处理中心之间的数据传输管理。

[0041] 在一些实施例中，所述数据处理中心还用于将消息数据进行分类存储，将消息数据中的临时性数据存储在本地数据库，设备监控数据存入云端数据库；

[0042] 所述综合网管中心还用于从所述云端数据库获取所述设备监控数据，并进行设备监控和故障统计处理以及大数据分析。

[0043] 根据本发明第三方面的实施例的轨道交通综合网管系统，具有与第一方面和第二方面的方法和装置类似的有益效果，不再赘述。

附图说明

[0044] 本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

[0045] 图1是基于发布-订阅模式的消息队列工作原理示意图；

[0046] 图2是根据本发明的一个实施例的轨道交通系统综合网管系统的结构框图；

[0047] 图3是根据本发明实施例的轨道交通系统综合网管方法的流程示意图；

[0048] 图4是根据本发明的一个实施例的消息队列的存储结构示意图；

[0049] 图5是根据本发明的另一个实施例的轨道交通综合网管系统的结构框图；

[0050] 图6是根据本发明实施例的消息队列中间件服务器的结构框图；

[0051] 图7是根据本发明实施例的轨道交通系统综合网管工作过程示意图。

具体实施方式

[0052] 下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

[0053] 现有技术中存在各种不足的原因之一在于该类方案中处理中心直接连接各个子系统网管，要求数据综合网管处理中心具有很强的并发处理能力，当数据处理中心接收到各个子系统大量的设备状态实时信息和告警信息时，综合网管数据处理中心不仅要对各个子系统数据进行匹配，并且要快速对接收到的数据进行各种处理和保存，如果不能及时的将数据处理掉，大量堆积在服务器里，很容易造成数据丢失的问题。

[0054] 此外，综合网管数据处理中心接收到数据后，按照先来先处理的方法依次处理数据，但是由于网络传输延迟等问题，有可能某个设备先前的数据被滞后接收，导致滞后的数据覆盖了最新数据，从而使得设备实时监控出现偏差。

[0055] 本公开主要技术思路包括：提供消息队列中间件服务器，所述消息队列中间件服务器上设置有消息队列中间件，各个子系统网管需要提供给数据处理中心的数据，经由消息队列中间件服务器中转，从而将各个子系统网管和数据处理中心解耦。具体而言，各个子系统网管的消息数据将不会直接发送到数据处理中心，而是先发送到消息队列中间件服务器；消息队列中间件服务器获取所述消息数据的主题，并根据所述消息数据的主题进行发布；之后，消息队列中间件服务器根据子系统网管数据处理中心的订阅信息，将各个消息队列中的消息数据依次发送到数据中心。亦即，数据处理中心也不是直接从子系统网管接口获取数据，而是从消息队列中间件服务器获取数据。

[0056] 从而，利用综合网管数据处理中心和消息队列中间件服务器这种两层分离的结构模式，可以降低数据处理中心和各个子系统网管之间数据的直接耦合，保证整个综合网管系统的稳定性，此外，利用消息队列中间件的高可用性保证数据的完整性，很好地解决了网络不可靠下的消息丢失问题和高并发情况下的性能瓶颈，以及子系统网管消息洪流出现时对下游综合网管数据处理中心造成的流量冲击。

[0057] 为了便于对本公开的理解，首先对消息队列技术的一些基本概念和发布-订阅模型的工作原理进行简单介绍。要说明的是，在本公开中，涉及消息队列技术中的各种概念，以本领域通用含义为准，以下介绍仅仅是为了便于对本公开的理解，而不能视为是对各个概念的全部内涵和/或外延的限制。

[0058] 消息生产者(producer)：发送消息到消息队列。

[0059] 消息消费者(consumer)：从消息队列接收消息。

[0060] 消息队列(queue)：一个先进先出的消息存储区域。消息按照顺序发送接收，一旦消息被消费处理，该消息将从队列中删除。

[0061] 消息(message)是消息队列传输机制中的数据传输单位，一条消息本质上就是一段数据，它能被一个或者多个应用程序所理解，是应用程序之间传递的信息载体。

[0062] 主题(topic)：可以视为消息的一种标识。消息的生产者可以为消息添加主题，并按照主题发布到消息队列中间件，消息消费者订阅所需的主题。本领域中，有时也直接以topic来表示发布-订阅模型或者此种工作模式。通过消息的主题和发布-订阅模型，可以支持将一条消息发送到多个订阅者的机制。

[0063] 点对点/queue消息队列模型：一个生产者向一个特定的队列发送消息，一个消费者从该队列中接收消息。消息的生产者和消费者可以不同时处于运行状态。每一个成功处理的消息都由消息消费者签收确认(acknowledge)。这种模式下，每条消息发往一个消息消费者。

[0064] 发布-订阅消息模型：发布-订阅模型中，消息生产者可根据一个特定的消息主题发布消息。消息消费者可能对接收来自特定消息主题的消息感兴趣，可以通过订阅感兴趣的主题来获得该主题下相应的消息。每条消息可以有一个或多个主题，每个主题可能有0个、1个或多个订阅者。在这种模型下，发布者和订阅者可以彼此可以解耦，彼此不知道对方的存在。

[0065] 参见图1，其中示出了消息队列中，按照主题设置队列的一种发布-订阅模式的工作原理。由消息生产者产生带有主题的消息，将消息发布到其主题对应的消息队列。消息队列中的消息将被发送到所有订阅了该消息主题的消息消费者，例如消息消费者1和消息消费者2。从而，可以将一条消息发送到多个接收者。

[0066] 下面参考附图对本发明实施例的方法和装置进行详细的说明。

[0067] 图2是根据本发明一个实施例的轨道交通系统综合网管系统结构示意图。其中，综合网管系统10包括多个子系统网管300，综合网管装置200，数据处理中心100，综合网管中心400，以及数据库500。系统各个部分之间通过有线或者无线的方式通信连接。多个子系统网管300产生的数据发送到综合网管装置200，再由综合网管装置200处理后发送到数据处理中心。

[0068] 首先，结合图3，对从综合网管装置200角度出发的轨道交通系统综合网管方法进行介绍。图3是根据本发明实施例的轨道交通系统综合网管方法的流程示意图。

[0069] 参见图3，本发明的轨道交通系统综合网管方法，主要用于轨道交通系统中子系统网管和数据处理中心之间的数据传输管理，可包括步骤S110到S140。在一些实施例中，轨道交通系统综合网管方法还可以进一步包括步骤S150和S160。

[0070] S110，接收子系统网管上传的数据，并将所述数据转换为具有通用的数据模式的规范化消息数据。

[0071] 轨道交通系统的子系统网管可以包括时钟系统网管、FAS(火灾报警系统)系统网管、广播系统网管、视频监控系统网管、乘客服务系统网管等。各个子系统网管可能使用不同的协议进行通信，上传的数据也有不同的格式。因此，需要进行格式转换，以便于数据处理中心的统一处理和存储。

[0072] 例如，可接收子系统网管根据第一协议上传的数据，并根据所述第一协议解析得到解析后的数据；将所述解析后的数据按照第二协议转换为具有通用的数据模式的规范化消息数据。其中，所述第一协议和第二协议可为不同的通信协议。第一协议通常是根据子系统网管的类型确定，而第二协议则根据数据处理中心的通信和数据需求而定。

[0073] S120，将所述规范化消息数据传输到消息队列中间件服务器。

[0074] 规范化的消息数据具有综合网管系统通用的数据模式，便于在后续数据处理过程中的操作。为了使数据更为有序化，所述将所述规范化消息数据传输到消息队列中间件服务器，可包括将所述规范化消息数据以各个子系统网管的识别标识作为关键值顺序发送到所述中间件服务器。当然，也可以按照其它顺序，例如按照消息数据的接收时间顺序发送到中间件服务器等。

[0075] S130，所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布。

[0076] 消息队列中间件工作在发布-订阅模式，可以采用只设置一个消息队列，或者按照主题设置多个消息队列等各种组织形式。

[0077] 为了保证相同子系统的数据按照顺序进行发送和接收，所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布可包括：在所述消息队列中间件服务器为每个所述子系统网管建立一个对应的消息队列，获取消息数据的来源子系统网管，并将所述消息数据发布到与所述来源子系统网管对应的消息队列中。

[0078] 参见图4是根据本发明的一个实施例的消息队列的存储结构示意图。

[0079] 例如，轨道交通综合网管系统中，共有n个子系统网管，对应每个子系统网管分别建立消息队列M1，M2到Mn。每个消息队列Mp的用于存储来自子系统网管p的消息数据，p∈[1,n]，p为自然数。当新的消息数据到达消息队列中间件服务器时，将根据其来源(为了便于操作，可以将消息数据的来源子系统网管作为消息的一个主题)，被发布到对应的消息队列，例如可以按照子系统网管的识别标识(ID值，如1到n)顺序发布。当然，子系统网管的识别标识也可能是其它形式，例如，字母或者字母和数字的组合等。本实施例的目的只是将识别标识作为消息数据发送顺序的参考，而不是要给对应的各个子系统设置优先级。因此，将所述规范化消息数据以各个子系统网管的识别标识作为关键值，按照所述关键值以某种指定的顺序进行数据传输即可。对于各个自己系统网管之间的排序关系并无特殊要求。

[0080] 每个消息队列的长度可以是不同的，例如，消息队列M1中包括消息数据M11到M1i，M11到M1i的主题为子来自系统网管1的消息数据；消息队列M2中包括消息数据M21到M2j，M21到M2j的主题为来自子系统网管2的消息数据；消息队列Mn中包括消息数据Mn1到Mnk，Mn1到Mnk的主题为来自子系统网管n的消息数据。

[0081] 通过上述消息队列的构建方式，可以保证，对于每个消息队列，其中的各个消息数据都是按照时间顺序排列的。从而根据消息队列的工作原理，各个消息队列中的消息数据可按照时间顺序被数据处理中心获取。保证对于同一个子系统网管，信息及指令按照顺序进行发送和接收，而不同子系统网管的消息及指令可以是无序的。

[0082] 也或者，可以根据消息数据的主题建立相应的消息队列，这种方式适用于消息数据主题数量相对确定，数据处理中心对某种类型的主题有特殊需求的场景。此时，可以根据数据处理中心的预先设置的订阅主题优先级排序，例如对应实时数据的主题赋予较高的优先级。对应地，在向数据处理中心传输数据时，对高优先级主题的数据优先传输。

[0083] 此外，由于数据处理中心是根据需要选择订阅的主题，可能存在某些子系统网管上传的数据没有被订阅的情况，为了避免这些不被需要的数据占据系统资源，可以进行定期清除。例如，可对消息队列中间件服务器中的消息进行定期检查，从各个消息队列中清除满足预设丢弃条件的消息。例如，预设丢弃条件可以是消息的主题都没有被订阅，消息在消息队列中间件服务器中存在时间大于预设的时长阈值，例如对于临时性数据超过1天或几天，非临时性数据超过1个月或数个月没有被数据处理中心订阅，即进行清除等。

[0084] S140，根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心。

[0085] 消息队列中间件服务器可以与数据处理中心设置在地理位置相邻的机房，从而减少消息数据的传输延迟。也可以单独设置，本发明对此没有要求。

[0086] S150，数据处理中心将消息数据进行分类存储，将消息数据中的临时性数据存储在本地数据库，设备监控数据存入云端数据库。

[0087] 临时数据往往不需要长期保存，存储在本地数据库便于对数据的处理，并且在处理结束后定期删除。不会占用过多的资源。而设备监控数据则可能需要长期保存，并且其它系统，例如综合网管中心可能会调用设备监控数据，因此，存在云端的数据库，便于数据的共享，也能节约有限的本地存储资源。

[0088] S160，综合网管中心从所述云端数据库获取所述设备监控数据，并进行设备监控和故障统计处理以及大数据分析。

[0089] 综合网管中心可以通过数据库访问接口从云端获取各子系统网管数据，根据设备监控数据，进行相应监控和故障处理。随着人工智能和大数据技术的日益成熟，还可以采用AI和大数据方法对设备监控数据进行进一步的分析，获得关于设备运行和保养等的进一步的信息。

[0090] 采用本发明的轨道交通系统综合网管方法，各个子系统网管输出的数据并不直接传输给综合网管数据处理中心，而是先传输给消息队列中间件服务器，综合网管数据处理中心也不是直接从子系统网管接口获取数据，而是从消息队列中间件获取数据。

[0091] 利用综合网管数据处理中心和消息队列中间件服务器这种两层分离的结构模式，可以降低数据处理中心和各个子系统网管之间数据的直接耦合，保证整个综合网管系统的稳定性，此外，利用消息队列服务器中消息队列中间件的高可用性保证数据的完整性，很好地解决了网络不可靠下的消息丢失问题和高并发情况下的性能瓶颈，以及子系统网管消息洪流出现时对下游综合网管数据处理中心造成的流量冲击。

[0092] 为了实现上述第一方面实施例中的方法，本发明第二方面的实施例提出了轨道交通系统综合网管装置。

[0093] 所述装置的实现可包括一个或多个计算设备，所述计算设备包括处理器和存储器，所述存储器上存储有包括可在所述处理器上运行的计算机程序指令的应用程序。所述应用程序可以划分为多个程序模块，用于系统各个组成部分的相应功能。其中，程序的模块的划分是逻辑上的而非物理上的，每个程序模块可以运行在一个或多个计算设备上，一个计算设备上也可以运行一个或一个以上的程序模块。以下对本发明的系统按照程序模块的功能逻辑划分进行详细说明。

[0094] 参见图5，图5是根据本发明实施例的轨道交通综合网管系统的结构框图。与图3的实施例类似，其中，综合网管系统20包括多个子系统网管300，综合网管装置200，数据处理中心100，综合网管中心400，以及数据库500。系统各个部分之间通过有线或者无线的方式通信连接。综合网管装置200与所述多个子系统网管和所述数据处理中心通信连接，用于轨道交通系统中子系统网管和数据处理中心之间的数据传输管理，多个子系统网管300产生的数据发送到综合网管装置200，再由综合网管装置200处理后发送到数据处理中心。其中，综合网管装置200进一步包括接口适配器210和消息队列中间件服务器220。

[0095] 接口适配器模块210，用于接收子系统网管上传的数据，将所述数据转换为具有通用的数据模式的规范化消息数据，以及将所述规范化消息数据传输到消息队列中间件服务器。

[0096] 其中，述接口适配器模块接收子系统网管上传的数据，将所述数据转换为具有通用的数据模式的规范化消息数据，可包括：接收子系统网管根据第一协议上传的数据，并根据所述第一协议解析得到解析后的数据；将所述解析后的数据按照第二协议转换为具有通用的数据模式的规范化消息数据；其中，所述第一协议和第二协议为不同的通信协议。

[0097] 所述接口适配器模块将所述规范化消息数据传输到消息队列中间件服务器包括：将所述规范化消息数据以各个子系统网管的识别标识作为关键值，按照所述关键值顺序发送到所述中间件服务器。

[0098] 消息队列中间件服务器220，用于获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布，以及根据数据处理中心的订阅主题，将消息队列中间件服务器中具有所述订阅主题的消息数据发送到所述数据处理中心。

[0099] 所述消息队列中间件服务器获取所述规范化消息数据的主题，并按照所述主题进行消息数据的发布可包括：在所述消息队列中间件服务器为每个所述子系统网管建立一个对应的消息队列，获取消息数据的来源子系统网管，并将所述消息数据发布到与所述来源子系统网管对应的消息队列中。

[0100] 此外，所述消息队列中间件服务器还用于：对消息队列中间件服务器中的消息进行定期检查，从各个消息队列中清除满足预设丢弃条件的消息。

[0101] 图6是根据本发明实施例的消息队列中间件服务器的结构框图。所述消息队列中间件220可进一步包括：消息接收单元221、消息队列配置单元222、消息队列存储单元223和消息发送单元224。

[0102] 消息接收单元221，用于接收规范化消息数据。

[0103] 消息队列配置单元222，用于根据所述消息数据的主题将消息数据发布到对应的消息队列。

[0104] 消息队列存储单元223，用于存储各个消息队列。

[0105] 消息发送单元224，用于根据订阅信息将各个消息队列中的消息数据发送到数据处理中心。

[0106] 其中，所述消息队列可以采用图4所示的存储结构。按照子系统网管建立不同的消息队列，存储相应的消息数据。

[0107] 所述数据处理中心100获取订阅的消息后，可对数据进行处理和将消息数据存储到数据库500。数据库500可包括本地数据库和云端数据库，数据处理中心100可将消息数据进行分类存储，将消息数据中的临时性数据存储在本地数据库，设备监控数据存入云端数据库。

[0108] 所述综合网管中心400可从所述云端数据库获取所述设备监控数据，并进行设备监控和故障统计处理以及大数据分析，以及从本地数据库获取临时性数据进行数据处理。

[0109] 参见图7，图7是根据本发明实施例的轨道交通系统综合网管工作过程示意图。

[0110] S201，各个子系统网管生成相应的子系统数据。例如，包括时钟系统网管、广播系统网管等在内的n个子系统。

[0111] S202，接口适配器模块与各个子系统网管进行匹配通信，接收子系统数据，例如采用第一协议。

[0112] S203，将接收的子系统数据进行转换，转换成规范化的消息数据，并发送到消息队列中间件服务器。

[0113] S204，在消息队列中间件服务器，按照n个不同的子系统分别建立n个队列，将来自不同子系统的消息数据置入对应的队列。

[0114] S205，数据处理中心以订阅主题的方式，从消息队列中间件服务器预订消息，并在有相应的订阅的主题消息到达时，从消息队列中间件获取消息。

[0115] S206，对消息进行分析处理。例如，可对消息数据进行分类，分出其中的临时性数据和设备监控数据等。

[0116] S207，将消息数据存储到数据库。例如，可根据数据的分类，将临时性数据存储在本地数据库，将设备监控数据存储到云数据库。

[0117] S208，综合网管中心从数据库获取数据，并根据获取的数据实现各种综合的网管功能。

[0118] 本发明轨道交通系统综合网管装置的各个组件或模块的具体实现可以参见相应的方法实施例，在此不再赘述。

[0119] 需要说明的是，在本说明书的描述中，流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

[0120] 本技术领域的普通技术人员可以理解实现上述实施例的方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

[0121] 应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一个实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

[0122] 在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

[0123] 此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是两个或两个以上，例如两个，三个等，除非另有明确具体的限定。

[0124] 尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。