基于轨道交通的综合监控系统的数据存储方法和装置与流程

本申请涉及轨道通信技术领域，尤其涉及一种基于轨道交通的综合监控系统的数据存储方法和装置。

背景技术：

轨道交通的综合监控系统，是基于现代计算机信息技术、网络技术、通讯和自动控制技术而研发的开放式、模块化、可扩展的分布式大型计算机集成系统。该系统中集成了车辆、电力等子系统，该系统在运行时子系统间的数据信息交互会产生大量的实时数据，比如，空调的温度湿度等，这些实时数据随着时间的变化会一直产生，为了便于对子系统的监控，在实际操作过程中，需要将这些实时数据收集起来作为历史数据存储在历史服务器中，由此，可以基于存储的历史数据监控子系统中有关监控设备的状态变化，并且在监控设备故障时，基于历史数据的分析，判断故障原因以便于及时进行故障的排查等。

相关技术中，如图1所示，由实时服务器接收由用于管理综合监控与集成和互联系统的接口上传的实时数据(front-endprocessor，fep)，其中，fep与子系统连接，获取相关实时数据，进而，实时服务器将实时数据直接发送至历史服务器，以便于历史服务器将实时数据发送至有关存储设备进行存储。然而，这种方式至少具有以下几个技术问题：

第一：历史服务器获取到的实时数据是由fep直接采集到的，而fep采集到的数据频率和数据量依赖于子系统中产生实时数据的监控设备本身，有些监控设备发送实时数据的间隔较小，则由于历史服务器会记录所有接收到的实时数据，导致存储压力较大。

第二：有些实时数据与综合监控系统的监控无关，也就是说，历史服务器中存储的有些数据是无用数据，导致存储空间的浪费。

第三：继续参照图1，历史服务器为了能够接收到实时数据，需要和实时服务器进行通信接口的编程，实时服务器也需要和fep进行通信接口的编程等，由此，实时服务器、历史服务器和fep之间的耦合度较高，各个模块的更新和维护都会彼此制约，实用性较差。

申请内容

本申请提供一种基于轨道交通的综合监控系统的数据存储方法和装置，以解决综合监控系统的实时数据采集和收集的模块间耦合过高、且直接将实时数据全部存储导致存储资源浪费的技术问题。

本申请一方面实施例提供一种基于轨道交通的综合监控系统的数据存储方法，包括：通过opcua标准接口接收历史服务器发送的数据订阅信息；根据所述数据订阅信息从所述综合监控系统中获取对应监控设备所采集的实时数据；根据预设的与所述数据订阅信息对应的数据存储规则，判断所述实时数据是否满足数据存储条件；若满足所述数据存储条件，则通过所述opcua标准接口将所述实时数据发送给所述历史服务器，以使所述历史服务器存储所述实时数据。

本申请另一方面实施例提供一种基于轨道交通的综合监控系统的数据存储装置，包括：接收模块，用于通过opcua标准接口接收历史服务器发送的数据订阅信息；第一获取模块，用于根据所述数据订阅信息从所述综合监控系统中获取对应监控设备所采集的实时数据；判断模块，用于根据预设的与所述数据订阅信息对应的数据存储规则，判断所述实时数据是否满足数据存储条件；发送模块，用于在所述实时数据满足所述数据存储条件时，通过所述opcua标准接口将所述实时数据发送给所述历史服务器，以使所述历史服务器存储所述实时数据。

本申请又一方面实施例提供一种基于轨道交通的综合监控系统的数据存储系统，包括：opcua服务器、历史服务器和综合监控系统，其中，所述opcua服务器包括如上述实施例所述的基于轨道交通的综合监控系统的数据存储，所述轨道交通综合监控系统与所述opcua服务器连接，所述历史服务器通过所述opcua服务器提供的opcua标准接口与所述opcua服务器通信连接。

本申请公开的技术方案，具有如下有益效果：

采用opcua标准接口进行数据的传递，根据历史服务器发送的数据订阅消息创建有关数据的监视项目，所监视的数据节点值发生变化而生成数据存储事件，根据有关数据存储规则将对应的实时数据发送，使用opcua提供的订阅事件监视项的机制实现数据的收集并发送，由此，历史服务器基于opcua作为通信总线收集和发送实时数据，降低了模块间的耦合，提升了系统的可靠性和可伸缩性，并且数据存储规则可配置，提高了综合监控系统的可配置性以及历史服务器的存储资源合理利用率，且降低了历史服务器的存储压力。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

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

图1是根据现有技术的基于轨道交通的综合监控系统的数据存储应用场景示意图；

图2是根据本申请一个实施例的基于轨道交通的综合监控系统的数据存储应用场景示意图；

图3是根据本申请一个实施例的基于轨道交通的综合监控系统的数据存储方法的流程图；

图4是根据本申请一个具体实施例的基于轨道交通的综合监控系统的数据存储方法的流程图；

图5是根据本申请一个实施例的基于轨道交通的综合监控系统的数据存储装置的结构示意图；

图6是根据本申请另一个实施例的基于轨道交通的综合监控系统的数据存储装置的结构示意图；

图7是根据本申请又一个实施例的基于轨道交通的综合监控系统的数据存储装置的结构示意图；

图8是根据本申请再一个实施例的基于轨道交通的综合监控系统的数据存储装置的结构示意图；以及

图9是根据本申请一个实施例的基于轨道交通的综合监控系统的数据存储系统的结构示意图。

具体实施方式

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

下面参考附图描述本申请实施例的基于轨道交通的综合监控系统的数据存储方法和装置。

开放平台通信统一架构(oleforprocesscontrolunifiedrchitecture，opcua):即opc统一架构，涵盖了opc实时数据访问规范(opcda)、opc历史数据访问规范、opc报警事件访问规范和opc安全协议的不同方面，但在其基础之上进行了功能扩展。opcua，是在传统opc技术取得很大成功之后的又一个突破，让数据采集、信息模型化以及工厂底层与企业层面之间的通讯更加安全、可靠。由于opcua独立于厂商，因而，模糊了不同厂商之间的差异性。

人机接口(humanmachineinterface，hmi)：也叫人机界面。人机界面(又称用户界面或使用者界面)是系统和用户之间进行交互和信息交换的媒介，它实现信息的内部形式与人类可以接受形式之间的转换。凡参与人机信息交流的领域都存在着人机界面。

用于管理综合监控与集成和互联系统的接口(front-endprocessor，fep)：fep用于管理综合监控与集成和互联系统的接口,具有转换各种硬件接口、软件协议的能力,同时能有效地把iscs与各集成和互联系统的数据进行隔离。

iscs:即城市轨道交通综合监控系统，由通用计算机、网络设备和大型scada软件平台构成，是支持应用和集成开发的开放系统，可通过开放接口与各专业自动化系统进行信息交互，构建线路运营实时信息共享平台。

正如以上分析的，现有的轨道交通的综合监控系统的技术方案中，将获取的有关实时数据直接传递至历史服务器中进行存储，导致历史服务器的存储资源浪费且历史服务器与传递实时数据的实时服务器之间的耦合度，实时服务器与fep之间的耦合度均较高，系统不稳定，可伸缩性较差。

本申请的申请人经过研究发现，从上层应用对实时数据的需求来看，对于实时数据产生较小的设备而言，往往数据间隔不需要这么小，例如以2秒为单位进行设备数据历史回放就可以满足监控的要求。并且在综合监控系统中，有些实时数据可以不用被记录数据历史，数据收集的间隔可根据实际需要进行灵活的配置，而上述历史数据收集方式无法满足根据配置进行数据收集的要求。

为了解决上述技术问题，适应轨道交通的综合监控系统的集成化、信息化、智能化和节约化的要求，本申请提供了一种基于opcua的实时数据收集的方案，以此来达到降低模块耦合、提高系统稳定性和适用性，并降低历史服务器存储压力的目的。

具体而言，如图2所示，在本申请的实施例中，考虑到opcua作为一种新型的工业系统数据通信标准，提出了一种基于opcua技术标准的历史数据收集方案，方案采用历史服务订阅实时服务(opcua标准服务)的方式，实时获取实时数据，进而基于opcua标准实现对收据的存储，实现了实时数据获取和收集之间的解耦和分离，参照图2，在本申请的实施例中，使用数据组态工具定义有关监控设备是否需要收集实时数据以及实时数据采集间隔、采集方式等对应数据存储规则的配置信息，并将这些配置信息下发到实时服务器和历史服务器，历史服务器根据该配置信息和系统需要确定需要监控的实时数据并添加监视项，其中，实时服务器中创建了基于opcua的节点空间，实时服务器基于对应的opcua标准接口向历史服务器发送监视项对应的实时数据，其中，历史服务器基于配置信息对应的采集间隔等向实时服务器订阅数据信息，充分利用了历史服务器的存储资源，将实时数据的采集和存储事件隔离开来，对实时数据的采集和存储事件对应的模块进行了解耦，模块间的单独运行不相互影响，能够让系统的部署和升级维护更为方便。

具体而言，图3是根据本申请一个实施例的基于轨道交通的综合监控系统的数据存储方法的流程图，本申请基于轨道交通的综合监控系统的数据存储方法的执行主体为实时服务器，也可以称为基于opcua的服务器，如图3所示，该方法包括：

步骤101，通过opcua标准接口接收历史服务器发送的数据订阅信息。

具体地，在本申请的实施例中，历史服务器根据opcua的运行机制通过opcua标准接口发送数据订阅信息，以便于基于opcua的服务器在检测到历史服务器订阅的实时数据后，根据订阅关系将实时数据发送至对应的历史服务器，由此，一方面，相较于传统技术中的一旦检测到实时数据产生即记录的方式，系统的容错性更强，稳定性更高，另一方面，历史服务器可以通过发送数据订阅信息有机的选择其需要存储的实时数据，筛选掉其不需要存储的实时数据，又一方面，历史服务器可以根据其需要采集的实时数据的采集间隔发送数据订阅信息，避免采集间隔较小导致的资源浪费。

在实际应用中，需要构建opcua的节点空间，以便于基于节点空间实现的功能提供opcua标准接口。

在本申请的一个实施例中，获取轨道交通的综合监控系统的数据信息、数据属性信息和方法信息，其中，数据信息反映了轨道交通的综合监控系统中包含的数据类型(比如温度、登录名等)以及数据类型之间的引用关系等，数据属性包括数据的属性比如数据类型的标识、所属监控设备的位置、所属监控设备的类型、所属监控设备的状态等，方法信息包括对各个数据类型的调用方法和控制方法等。opcua的建模实际上是节点与节点之间的引用，节点可以根据不同的用途归属于不同的节点类别在opcua中，最重要的节点类别对象、变量和方法。对象可以拥有变量和方法，而且可以触发数据存储事件。

在本申请的实施例中，以数据信息作为对象节点，以数据信息的数据属性信息作为变量节点(属性节点)，以方法信息作为方法节点，变量节点满足历史服务器对综合监控系统中的实时数据的读取、写入、订阅其变化，方法节点满足实时服务器根据输入的订阅信息向对应监控设备度读取实时数据并返回执行结果。

在本申请的实施例中，基于上述节点空间的创建原理，根据opcua标准将数据信息、数据属性信息和方法信息以节点的方式加载到节点空间，节点的数据变化可触发对应存储事件的产生，节点空间提供了对综合监控系统的实时数据的产生和获取的集合，因而，建立节点空间与历史服务器进行通信交互的opcua标准接口。

当然，为了便于历史服务器对存储事件的订阅，需要提前将包含事件源的数据源注册请求发送给历史服务器，以便于历史服务器选择要订阅的数据源，在本申请的一个实施例中，节点空间构建完毕后，根据节点空间可检测的实时数据发送数据源注册请求，由此，获取数据源后，历史服务器可根据需要选择其要监控的数据源进行订阅，即通过opcua数据注册接口向历史服务器进行数据源注册，通知历史服务器待收集数据在节点空间中对应的数据节点，以通过数据订阅接口接收历史服务器发送的数据订阅信息。

步骤102，根据数据订阅信息从综合监控系统中获取对应监控设备所采集的实时数据。

具体地，在接收到数据订阅信息后，根据数据订阅信息从综合监控系统中获取对应的实时数据，以便于根据该实时数据检测是否为订阅的数据源，比如，当接收到的是空调温度实时数据，则根据数据订阅信息从综合监控系统中获取对应的实时温度等。

在本申请的一个实施例中，根据数据订阅信息启动节点空间中对应的目标数据节点开启数据监视功能，并通过监视启动接口通知历史服务器，通过数据采集接口获取从综合监控系统中采集的对应实时数据，具体而言，确定节点空间中与数据订阅信息对应的目标数据节点，进而，启动对应的目标数据节点，登录到对应的综合监控系统获取与目标数据节点对应的数据，进而，通过数据采集接口获取从综合监控系统中采集的对应的实时数据，该实时数据是对应的综合监控系统与目标数据节点对应的监控设备通信获取的。

由此，基于opcua标准协议的接口进行数据的获取和传输，不需要考虑不同子系统对应的设备厂商之间的生产软件之间的不兼容的问题。

步骤103，根据预设的与数据订阅信息对应的数据存储规则，判断实时数据是否满足数据存储条件。

步骤104，若满足数据存储条件，则通过opcua标准接口将实时数据发送给历史服务器，以使历史服务器存储实时数据。

可以理解的是，在本申请的实施例中，继续参照图2，预先设置存储事件触发对应的数据存储规则，比如，采集的数据类型为空调温度以及存储间隔为1分钟一次，则根据预设的与数据订阅信息对应的数据存储规则，判断实时数据是否满足数据存储触发条件，若满足触发条件，则通过opcua标准接口将对应的实时数据发送给历史服务器，以使历史服务器存储实时数据。其中，为了便于相关管理人员的分析处理，可以将存储的事件发送至管理人员可视的客户端，供管理人员分析处理或者查询相关事件，或者，继续参照图2，可以将存储的事件发送至关系或者时序数据库进行存储。

也可以理解，基于opcua的服务器通过数据采集接口采集现场设备、电力、车辆等综合监控系统中各个子系统的实时数据，并将实时数据送到节点空间进行数据管理，同时通过与数据存储规则进行匹配分析，进而数据存储事件产生，数据存储规则是每个实时数据的存储触发限制，采集到的实时数据需要与数据存储规则进行匹配分析，若达到数据存储规则则触发存储事件的产生，由此，基于订阅事件监视项的机制实现数据源的存储，通过向历史服务器注册数据源，并开启监视功能，在根据订阅关系创建了监视项后，进行实时数据收集并存储，实时数据产生和收集模块分离，模块间的单独运行不相互影响，能够让系统的部署更为方便。

在本申请的一个实施例中，当存储事件被触发时，为了便于该存储事件对应的实时数据的传输成功，可通过通知接口向历史服务器发送包含实时数据的产生通知，以使历史服务器接收实时数据并存储，其中，历史服务器可以将接收到的实时数据存储在本地，也可以存储在单独设置的数据库中，在此不作限制。

需要强调的是，继续参照图2，为了保证实时数据的存储间隔，由数据组态将包含数据存储规则的组态配置信息发送至实时服务器和历史服务器，其中，一方面，实时服务器根据存储规则中的存储时间间隔通过opcua标准的通知接口向历史服务器发送通知，即在订阅的实时数据发生变化后，并不直接基于opcua标准接口向历史服务器反馈，而是在达到对应的存储时间间隔后，向历史服务器发送通知以便于与历史服务器进行存储，另一方面，历史服务器根据存储规则中的存储时间间隔向opcua标准接口发送的数据订阅信息，以主动把握实时数据的存储时间间隔。

为了使得本领域的技术人员更加清楚的了解本申请实施例的基于轨道交通的综合监控系统的数据存储方法，下面结合具体的应用场景进行描述，如图4所示，在该场景中实时数据存储在关系或者时序数据库中。

在具体执行过程中，历史服务器和实时服务器加载包含数据存储规则的配置信息，历史服务器根据存储需要向实时服务器注册数据源，进而，实时服务器根据注册数据源添加监视项，实时服务器开启与监视项对应的目标数据节点的监视并通知历史服务器，当监控到对应的目标数据节点的实时数据发生变化时，向历史服务器发送实时数据产生通知，进而，将对应的实时数据根据数据存储规则对应的发送间隔发送至历史服务器，以使历史服务器将获取到的数据源发送至对应的关系或者时序数据库中进行存储，其中，关系或者时序数据库中可以反馈存储通知给历史服务器。

综上，本申请实施例的基于轨道交通的综合监控系统的数据存储方法，采用opcua标准接口进行数据的传递，根据历史服务器发送的数据订阅消息创建有关数据的监视项目，所监视的数据节点值发生变化而生成数据存储事件，根据有关数据存储规则将对应的实时数据发送，使用opcua提供的订阅事件监视项的机制实现数据的收集并发送，由此，历史服务器基于opcua作为通信总线收集和发送实时数据，降低了模块间的耦合，提升了系统的可靠性和可伸缩性，并且数据存储规则可配置，提高了综合监控系统的可配置性以及历史服务器的存储资源合理利用率，且降低了历史服务器的存储压力。

为了实现上述实施例，本申请还提供给了一种基于轨道交通的综合监控系统的数据存储装置，图5是根据本申请一个实施例的基于轨道交通的综合监控系统的数据存储装置的结构示意图，如图5所示，该基于轨道交通的综合监控系统的数据存储装置包括：接收模块110、第一获取模块120、判断模块130和发送模块140。

其中，接收模块110，用于通过opcua标准接口接收历史服务器发送的数据订阅信息。

在本申请的一个实施例中，如图6所示，在如图5所示的基础上，接收模块110包括通知单元111、接收单元112。

其中，通知单元111，用于通过opcua数据注册接口接收历史服务器发送的数据源注册请求，并根据数据源注册请求进行数据源注册，以及通知历史服务器待收集数据在节点空间中对应的数据节点。

接收单元112，用于通过数据订阅接口接收历史服务器发送的数据订阅信息。

第一获取模块120，用于根据数据订阅信息从综合监控系统中获取对应监控设备所采集的实时数据。

判断模块130，用于根据预设的与数据订阅信息对应的数据存储规则，判断实时数据是否满足数据存储条件。

发送模块140，用于在实时数据满足数据存储条件时，通过opcua标准接口将实时数据发送给历史服务器，以使历史服务器存储实时数据。

在本申请的一个实施例中，发送模块140具体用于通过通知接口向历史服务器发送包含实时数据的产生通知，以使历史服务器接收实时数据并存储。

在本申请的一个实施例中，如图7所示，在如图5所示的基础上，该装置还包括第二获取模块150和接口创建模块160。

其中，第二获取模块150，用于获取综合监控系统的数据信息、数据属性信息和方法信息。

接口创建模块160，用于根据opcua标准将数据信息、数据属性信息和方法信息以节点的方式加载到节点空间，并建立节点空间与历史服务器进行通信交互的opcua标准接口。

在本申请的一个实施例中，如图8所示，在如图5所示的基础上，第一获取模块120包括确定单元121、监视单元122和采集单元123。

其中，确定单元121，用于确定节点空间中与数据订阅信息对应的目标数据节点。

监视单元122，用于启动目标数据节点以开启数据监视功能，并通过监视启动接口通知历史服务器。

采集单元123，用于通过数据采集接口获取综合监控系统中与目标数据节点对应的监控设备所采集的实时数据。

需要说明的是，前述集中在基于轨道交通的综合监控系统的数据存储方法测描述的实施例，也适用于本申请基于轨道交通的综合监控系统的数据存储装置，其实现原理和技术效果类此，在此不再赘述。

为了实现上述实施例，本申请还提出了一种基于轨道交通的综合监控系统的数据存储系统，图9是根据本申请一个实施例的基于轨道交通的综合监控系统的数据存储系统的结构示意图，如图9所示，该基于轨道交通的综合监控系统的数据存储系统包括opcua服务器100、历史服务器200和综合监控系统300，其中，opcua服务器包括如前述实施例描述的基于轨道交通的综合监控系统的数据存储装置，综合监控系统300与opcua服务器100连接，事件服务器200通过opcua服务器100提供的opcua标准接口与opcua服务器100通信连接。

需要说明的是，前述集中在基于轨道交通的综合监控系统的数据存储方法测描述的实施例，也适用于本申请基于轨道交通的综合监控系统的数据存储系统，其实现原理和技术效果类此，在此不再赘述。

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

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

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

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(pga)，现场可编程门阵列(fpga)等。

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

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。