CN109391629B - 轨道交通综合监控系统数据处理方法 - Google Patents

Abstract

本发明涉及一种新型轨道交通综合监控系统数据处理方法，综合监控系统在接入集成子系统后,依照各子系统设备特征制作采集信息列表，将数据采集进入实时库进行数据处理、报警配置、转发配置等集中式的配置管理。根据配置中心的各项配置对实时数据进行报警推送、存储、查询，并将实时数据按照压缩策略存入时序数据库存储为历史数据，供平台查询。同时实时数据可以使用不同转发配置对外进行数据转发。

Description

轨道交通综合监控系统数据处理方法

技术领域

本发明涉及一种轨道交通综合监控系统数据处理方法。

背景技术

随着我国轨道交通的高速发展，轨道交通管理和建设单位对轨道交通自动化程度和集成化程度的要求越来越高。以往仅以车站为单位的车站级综合监控系统已很难满足现代轨道交通管理的需求，因此建设中央级甚至线网级综合监控系统是城市轨道交通自动化系统的发展趋势。

在综合监控系统中，彼此孤立的各类设备控制系统通过网络和集成软件将全线车站或轨道交通运营网络内的各条线路及其各子系统有机地连接在一起，建立一个信息共享平台，实现不同工况下各线路、车站、子系统的联动，信息高度共享和系统自主决策。但对于一些建设年代久远的老旧线路并未建设综合监控系统，各项运营管理和维护工作还需浪费大量的人力、物力。由于信息的封闭和传递不畅，中央调度人员不能及时掌握全线各站的设备运行情况和故障报警信息，不能及时对线路运营造成调整，也会造成轨道交通管理水平的提高。因此对老旧线路进行改造并增设综合监控系统，让中央调度人员及时准确地了解全线各子系统的运行情况，并在发生突发事件时及时处置、统一指挥、协调管理是轨道交通行业发展的趋势。由于老旧线路未建设车站级综合监控系统，综合监控系统网络建设需要采用集中式的网络结构，中央综合监控系统直接与各车站的子系统进行通信，而深度集成的综合监控系统接入的子系统数量众多，因此接入数据量规模非常庞大。如果建设线网级综合监控系统将要处理数条线路的数据，数据规模更是异常巨大。而现有的综合监控系统的数据处理方式难以满足海量数据的吞吐要求。

发明内容

本发明的目的是：提供一种能够负载高数据量的轨道交通综合监控系统数据处理方法。

为了达到上述目的，本发明的技术方案是提供了一种轨道交通综合监控系统数据处理方法，其特征在于，包括以下步骤：

步骤1、根据轨道交通综合监控系统的各子系统设备特征与协议进行采集点抽象与归纳，生成统一格式的采集信息列表；

步骤2、根据采集信息列表，读取各采集点信息并根据各采集点的数据类型配置不同的数据点处理方式；当采集点需要报警时，则在配置中心针对报警点进行配置；当采集点需要转发时，则在配置中心将转发点进行配置，配置完成后由配置中心生成一份转发信息表，由实时缓存数据根据转发信息表进行转发；

步骤3、将采集到的海量实时数据缓存入实时缓存库中，将实时缓存库部署在内存中，实时缓存库采用分布式方式部署；

步骤4、采集数据缓存入实时缓存库后，随着数据采集周期不断更新实时缓存库中的数据值，对实时缓存库的数据进行入库处理，实时数据入库至时序数据库，以时序数据库作为历史库，时序数据库以时标和设备标签为关键字进行存储和抽取；

步骤5、实时缓存库根据配置中心配置进行报警入库，包括以下步骤：

报警处理服务第一次运行时从配置中心抽取报警相关配置并缓存于内存中，报警处理服务根据所抽取的配置从实时缓存库中抽取需要进行报警判断的实时数据，报警信息根据产生与确认状态分为3种，分别为：报警产生未确认、报警产生已确认、报警已恢复；

若实时数据满足报警条件，则生成一条报警信息进入实时报警库，此时报警状态为报警产生未确认，当用户对此报警进行人工确认后，报警服务将此报警状态设置为报警产生已确认，当此报警已被人工确认且恢复时，此报警信息将进入历史报警库；

当用户查看完整的实时报警列表时，客户端从实时报警库中展示以时间为默认排序条件，距今由近至远进行排列的实时报警数据；

在报警栏与实时报警列表中均可对未确认状态的报警进行人工确认操作，确认后此条报警状态将置为报警产生已确认，已确认且与已恢复的报警会进入历史报警库，进入历史报警库时将存储此报警的报警产生未确认状态、报警产生已确认状态、报警已恢复状态共三条记录；

实时缓存数据根据配置中心配置进行转发，包括以下步骤：

转发服务第一次运行时从配置中心拉取转发相关配置并缓存于内存中，转发服务从实时缓存库中拉取需要转发的数据并更新至内存中，同时根据配置中心采集点类型不同与转发配置中的转发协议的不同，采取不同的转发策略；

在进行转发服务启动时，转发数据量不能超过所配置转发协议本身的承载上限，当转发数据量超出此范围时，在配置中心做好转发点规划，配置多个转发服务进行转发；

步骤6、在系统长时间运行后，对时序数据库中的数据进行压缩，减少硬盘占用。

优选地，步骤1中，所述采集信息列表中的各采集点的数据类型分为数字量、模拟量、字符串三类；

步骤2中，数据点处理方式的配置方法包括：当采集点的数据类型为数字量时，读取此采集点的取反标志，若取反标志为1时，说明对此采集点的值进行取反配置，若取反标志为0时，则此采集点的值不作变化；当采集点的数据类型为模拟量时，需读取此采集点的乘算系数，当乘算系数为1时，说明此采集点的值不作变化，当乘算系数不为1时，则对此采集点的值按系数进行配置；当采集点的数据类型为字符串时，则需要根据协议的具体情况进行详细处理。

优选地，步骤4中，实时缓存库的数据进行入库处理时，采用telegraf进行数据抽取，实时缓存数据经telegraf套件从实时缓存库批量抽取至时序数据库，入库完成后即完成了实时数据落地进入历史库的操作。

优选地，实时缓存数据进入时序数据库时，由telegraf套件抽取的数据进行周期抽取，保证时间戳按等差数列排列，且按升序方式存储，达到提高时间戳压缩比的目的。

优选地，步骤5中，选取mongodb作为实时报警库与历史报警库进行报警数据的存储。

优选地，步骤5中，用户对报警进行人工确认时，在实时数据满足报警条件进入实时报警库的同时将此实时数据传入rabbitmq消息队列，将实时报警数据推送给用户，在rabbitmq中定义队列时将队列容量定义为固定容量，用户通过客户端获取报警推送时，若客户端为web客户端，直接使用stomp协议从rabbitmq消息队列中拉取，也可根据所选用的客户端不同采用不同的rabbitmq client进行消息拉取。

优选地，步骤5中，转发策略的确定方法为：

1)配置中心配置为modbus协议转发时，转发服务将自身模拟为modbus从站，对外提供modbus/tcp服务，根据该采集点的数据类型和所配置的占用地址将数据更新至对应的转发服务模拟modbus从站中；

2)配置中心配置为IEC-104协议转发时，转发服务将自身模拟为IEC-104主站，对外提供IEC-104tcp服务，根据该采集点的数据类型和所配置的占用地址将数据更新至对应的转发服务模拟IEC-104主站中；

3)配置中心配置为http协议转发时，将http服务端地址加入配置中心，转发服务作为http client将转发数据以JSON形式包含在http post请求中发送至http服务端，在收到服务端正常响应后，进行下一次数据发送。

在本发明提供的方法中，综合监控系统在接入集成子系统后,依照各子系统设备特征制作采集信息列表，将数据采集进入实时库进行数据处理、报警配置、转发配置等集中式的配置管理。根据配置中心的各项配置对实时数据进行报警推送、存储、查询，并将实时数据按照压缩策略存入时序数据库存储为历史数据，供平台查询。同时实时数据可以使用不同转发配置对外进行数据转发。采用了上述技术方案后，使得本发明能够负载高数据量。

附图说明

图1为本发明的系统示意图。

具体实施方式

下面结合具体实施例，进一步阐述本发明。应理解，这些实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。

本发明提供的一种轨道交通综合监控系统海量数据处理方法，包括以下几个方面：各子系统采集信息列表制作；数据配置中心生成配置；采集数据进入实时缓存库；实时缓存数据落地进入时序数据库；实时缓存数据根据配置中心配置进行报警入库；实时缓存数据根据配置中心配置进行转发；时序数据库数据压缩。

(1)各子系统采集信息列表

根据各子系统设备特征与协议进行采集点抽象与归纳，生成统一格式的采集信息列表，需要的数据包含：设备名称、所属子系统、设备类与设备点对应关系、采集周期、通信协议、数据点类型等。

在采集信息列表中数据类型可分为数字量、模拟量、字符串三类，如EMCS、FAS、AFC系统中较多使用MODBUS协议，则将采集时的线圈点归类为数字量，保持寄存器中的点归为模拟量；PSCADA系统采用IEC-104协议，则将采集时的遥信量归为数字量，遥测量归为模拟量；CCTV、PA及PIS系统中较多采用基于私有协议与明码报文进行通信，则均归类为字符串类型。

采集信息列表制作完成后可对全线设备进行较好的抽象与归纳，维护与管理时也较为清晰。

(2)数据配置中心生成配置

配置中心主要作用为将采集模块中的数据点依照不同的数据处理步骤，配置不同的处理方式，并推送至下一个数据处理步骤进行数据配置读取，所有数据处理步骤配置皆在配置中心集中维护。

根据采集信息列表，读取采集点信息并配置数据点处理方式，处理方式根据采集点类型有如下几种配置：当采集点为数字量时，需要读取此采集点的取反标志，若取反标志为1时，说明对此值进行取反配置，若取反标志为0时，则此值不作变化。当采集点为模拟量时，需读取此值的乘算系数，当乘算系数为1时，说明此值不作变化，当乘算系数不为1时，则对此值按系数进行配置。当采集点为字符串时，则需要根据协议的具体情况进行详细处理。

当采集点需要报警时，则需要在配置中心针对报警点进行配置。配置采集点是否需要报警、报警级别、报警触发条件等，如针对数字量的0/1跳变报警，针对模拟量的低，低低，高，高高报警等。

当采集点需要转发时，则需要在配置中心将转发点进行配置。配置此采集点是否需要转发、转发协议、转发时所占用的地址号等。配置完成后由配置中心生成一份转发信息表，由实时缓存数据根据配置中心配置进行转发。

(3)采集数据进入实时缓存库

当采集数据量较大时，数据直接序列化入库易造成硬盘IO压力过大，且硬盘读写速度也会成为影响整个系统性能的瓶颈。所以将采集到的海量实时数据先缓存入实时缓存库中，再进行后续其他数据处理步骤。将实时缓存库部署在内存中，可保证较高的数据读写效率。实时缓存库采用分布式方式部署，可防止采集点过大时导致服务器内存耗尽问题，为将来系统扩容提供扩展能力。

(4)实时缓存数据落地进入时序数据库

采集数据缓存入实时缓存库后，随着数据采集周期不断更新实时缓存库中的数据值，若不对实时缓存库的数据进行入库处理，则无法记录采集点的历史值。数据点入库时，传统的关系型数据库写入性能会随着数据量的增大而下降，实时数据入库时各数据值并无复杂的关联关系，因此将此类数据入库至时序数据库，以时序数据库作为历史库。

时序数据库以时标(TimeStamp)和设备标签为关键字进行存储和抽取，并可实现针对某一设备任意时段内的测量值的高性能存储，这样可以非常方便地抽取某个设备在指定时间段内采集量的连续值。

采用telegraf进行数据抽取，时序数据库以influxdb为例，实时缓存数据经telegraf套件从实时缓存库批量抽取至influxdb时序数据库，influxdb对实时数据中的设备标签与采集时标进行索引，入库完成后即完成了实时数据落地进入历史库的操作。

(5)实时缓存数据根据配置中心配置进行报警入库

报警处理服务第一次运行时从配置中心抽取报警相关配置并缓存于内存中，报警处理服务根据所抽取的配置从实时缓存库中抽取需要进行报警判断的实时数据。报警信息根据产生与确认状态分为3种：

A)报警产生未确认(came/unacknowledged)

B)报警产生已确认(came/acknowledged)

C)报警已恢复(went)

若实时数据满足报警条件，则生成一条报警信息进入实时报警库，此时报警状态为报警产生未确认(came/unacknowledged)，当用户对此报警进行人工确认后，报警服务将此报警状态设置为报警产生已确认(came/acknowledged)，当此报警已被人工确认且恢复时(处在went状态)，此报警信息将进入历史报警库。

由于子系统数量众多，设备数量巨大，在系统长时间运行后会积累大量的报警数据，此时进行报警数据查询时对查询效率有较高要求，因此选取mongodb作为实时报警库与历史报警库进行报警数据的存储，mongodb单表查询效率较高且易进行分布式拆分与扩展的，从而满足海量报警数据的存储与查询需求。

在实时数据满足报警条件进入实时报警库的同时将此数据传入rabbitmq消息队列将报警数据推送给用户。在大多数场景下，实时报警展示至用户时，用户无需切换至完整实时报警列表页面即可在常驻实时报警栏进行查看，常驻实时报警栏展示报警条数多为5-10条左右，因此在rabbitmq中定义队列时将队列容量定义为固定容量即可(根据实际使用时常驻实时报警栏展示条数而定)。在客户端获取报警推送时(消费rabbitmq推送队列消息时)，若为web客户端可直接使用stomp协议(基于websocket协议)从rabbitmq中拉取，也可根据所选用的客户端不同采用不同的rabbitmq client进行消息拉取。

当用户查看完整的实时报警列表时，客户端从实时报警库(mongodb)中展示以时间为默认排序条件，距今由近至远进行排列的实时报警数据。

在报警栏与实时报警列表中均可对未确认(came/unacknowledged)状态的报警进行人工确认操作，确认后此条报警状态将置为报警产生已确认(came/acknowledged)。已确认且与已恢复的报警会进入历史报警库(mongodb)，进入历史报警库时将存储此报警的报警产生未确认(came/unacknowledged)状态、报警产生已确认(came/acknowledged)状态、报警已恢复(went)状态共三条记录。

(6)实时缓存数据根据配置中心配置进行转发

转发服务第一次运行时从配置中心拉取转发相关配置并缓存于内存中，转发服务从实时缓存库中拉取需要转发的数据并更新至内存中，同时根据配置中心采集点类型不同与转发配置中的转发协议的不同，采取不同的转发策略。

A)配置为modbus协议转发时，转发服务将自身模拟为modbus从站，对外提供modbus/tcp服务。根据该点的数据类型和所配置的占用地址将数据更新至对应的转发服务模拟modbus从站中。

B)配置为IEC-104协议转发时，转发服务将自身模拟为IEC-104主站，对外提供IEC-104tcp服务。根据该点的数据类型和所配置的占用地址将数据更新至对应的转发服务模拟IEC-104主站中。

C)配置为http协议转发时，需将http服务端地址加入配置中心，转发服务作为http client将转发数据以JSON形式包含在http post请求中发送至http服务端，在收到服务端正常响应(http response code 200)后，进行一下次数据发送。

在进行转发服务启动时，转发数据量不能超过所配置转发协议本身的承载上限，如modbus协议，寄存器上限为65535个，当转发数据量超出此范围时，需要在配置中心做好转发点规划，配置多个转发服务进行转发。

(7)时序数据库数据压缩

在系统长时间运行后会积累庞大的历史数据，因此需要对数据进行压缩从而减少硬盘占用。

以influxdb时序数据库为例，轨道交通综合监控系统中数字量数据占很大比例，每字节可存储8位数字量点(即8bit存储8个DI值)，此种存储方式已为数字量最优存储方式。而时序数据存储时，每个采集的实时值皆对应一个时间戳(timestamp)，时间戳在数据存储所占的比例为50％，因此对时间戳数据的压缩会影响整体数据的压缩比。根据influxdb使用的压缩算法s8b，当时间戳有序且为等差数列时，将有效提高压缩比，如当前存在1538760049000，1538760050000，1538760051000，1538760052000，1538760053000五个相差1000的时间戳，则在存储时可表示为[1538760049000,1000,5]，1538760049000代表了第一个时间戳，1000表示等差数列差值，5表示数据以此规律重复5次，从而大大压缩时间戳存储所占容量。因此在上述实时缓存数据进入时序数据库时，由telegraf抽取的数据进行周期抽取，保证时间戳按等差数列排列，且按升序方式存储，达到提高时间戳压缩比的目的。

当数据量为模拟量时，时间戳压缩方式也可采用这种压缩方式，由telegraf抽取的数据进行周期抽取。但模拟量压缩涉及到压缩精度和失真问题，考虑到数据准确性要求，绝大部分模拟量值不进行压缩，小部分模拟量值(根据专业及实际监控需求，精度要求较低的采集量)可进行求平均值压缩，旋门压缩(采用influxdb本身压缩策略)进行数据压缩。

上述内容按步骤可以描述为：

第一步：根据各子系统设备特征与协议进行采集点归类与抽象，生成统一格式的采集信息列表，需要的数据包含：设备名称、所属子系统、设备类与设备点对应关系、采集周期、通信协议、数据点类型等。

第二步：根据采集信息列表信息配置数据处理方式、报警条件、转发功能(协议，转发点等)。

第三步：部署实时缓存库，可单机部署也可分布式部署。

第四步：部署influxdb时序数据库，并配置对应的数据压缩策略。

第五步：部署rabbitmq报警推送队列。

第六步：部署mongodb作为实时报警库与历史报警库。

第七步：依次序启动采集模块，报警服务，转发服务。

第八步：对比实时缓存库中数据与设备实际数据是否匹配；查看报警服务中推送队列报警数据是否正常被压入队列；出现报警时，实时报警库与历史报警库是否有数据进入；查看时序数据库是否有历史数据存入。

若第八步检测均正常，则实施部署成功。

Claims (7)

1.一种轨道交通综合监控系统数据处理方法，其特征在于，包括以下步骤：

步骤1、根据轨道交通综合监控系统的各子系统设备特征与协议进行采集点抽象与归纳，生成统一格式的采集信息列表；

步骤2、根据采集信息列表，读取各采集点信息并根据各采集点的数据类型配置不同的数据采集点处理方式；当采集点需要报警时，则在配置中心针对报警点进行配置；当采集点需要转发时，则在配置中心将转发点进行配置，配置完成后由配置中心生成一份转发信息表，由实时缓存数据根据转发信息表进行转发；

步骤3、将采集到的海量实时数据缓存入实时缓存库中，将实时缓存库部署在内存中，实时缓存库采用分布式方式部署；

步骤4、采集数据缓存入实时缓存库后，随着数据采集周期不断更新实时缓存库中的数据值，对实时缓存库的数据进行入库处理，实时数据入库至时序数据库，以时序数据库作为历史库，时序数据库以时标和设备标签为关键字进行存储和抽取；

步骤5、实时缓存库根据配置中心配置进行报警入库，包括以下步骤：

报警处理服务第一次运行时从配置中心抽取报警相关配置并缓存于内存中，报警处理服务根据所抽取的配置从实时缓存库中抽取需要进行报警判断的实时数据，报警信息根据产生与确认状态分为3种，分别为：报警产生未确认、报警产生已确认、报警已恢复；

若实时数据满足报警条件，则生成一条报警信息进入实时报警库，此时报警状态为报警产生未确认，当用户对此报警进行人工确认后，报警服务将此报警状态设置为报警产生已确认，当此报警已被人工确认且恢复时，此报警信息将进入历史报警库；

当用户查看完整的实时报警列表时，客户端从实时报警库中展示以时间为默认排序条件，距今由近至远进行排列的实时报警数据；

在报警栏与实时报警列表中均可对未确认状态的报警进行人工确认操作，确认后此条报警状态将置为报警产生已确认，已确认且与已恢复的报警会进入历史报警库，进入历史报警库时将存储此报警的报警产生未确认状态、报警产生已确认状态、报警已恢复状态共三条记录；

实时缓存数据根据配置中心配置进行转发，包括以下步骤：

转发服务第一次运行时从配置中心拉取转发相关配置并缓存于内存中，转发服务从实时缓存库中拉取需要转发的数据并更新至内存中，同时根据配置中心采集点类型不同与转发配置中的转发协议的不同，采取不同的转发策略；

在进行转发服务启动时，转发数据量不能超过所配置转发协议本身的承载上限，当转发数据量超出此范围时，在配置中心做好转发点规划，配置多个转发服务进行转发；

步骤6、在系统长时间运行后，对时序数据库中的数据进行压缩，减少硬盘占用。

2.如权利要求1所述的一种轨道交通综合监控系统数据处理方法，其特征在于，步骤1中，所述采集信息列表中的各采集点的数据类型分为数字量、模拟量、字符串三类；

步骤2中，数据点处理方式的配置方法包括：当采集点的数据类型为数字量时，读取此采集点的取反标志，若取反标志为1时，说明对此采集点的值进行取反配置，若取反标志为0时，则此采集点的值不作变化；当采集点的数据类型为模拟量时，需读取此采集点的乘算系数，当乘算系数为1时，说明此采集点的值不作变化，当乘算系数不为1时，则对此采集点的值按系数进行配置；当采集点的数据类型为字符串时，则需要根据协议的具体情况进行详细处理。

3.如权利要求1所述的一种轨道交通综合监控系统数据处理方法，其特征在于，步骤4中，实时缓存库的数据进行入库处理时，采用telegraf进行数据抽取，实时缓存数据经telegraf套件从实时缓存库批量抽取至时序数据库，入库完成后即完成了实时数据落地进入历史库的操作。

4.如权利要求3所述的一种轨道交通综合监控系统数据处理方法，其特征在于，实时缓存数据进入时序数据库时，由telegraf套件抽取的数据进行周期抽取，保证时间戳按等差数列排列，且按升序方式存储，达到提高时间戳压缩比的目的。

5.如权利要求1所述的一种轨道交通综合监控系统数据处理方法，其特征在于，步骤5中，选取mongodb作为实时报警库与历史报警库进行报警数据的存储。

6.如权利要求1所述的一种轨道交通综合监控系统数据处理方法，其特征在于，步骤5中，用户对报警进行人工确认时，在实时数据满足报警条件进入实时报警库的同时将此实时数据传入rabbitmq消息队列，将实时报警数据推送给用户，在rabbitmq中定义队列时将队列容量定义为固定容量，用户通过客户端获取报警推送时，若客户端为web客户端，直接使用stomp协议从rabbitmq消息队列中拉取，也可根据所选用的客户端不同采用不同的rabbitmq client进行消息拉取。

7.如权利要求1所述的一种轨道交通综合监控系统数据处理方法，其特征在于，步骤5中，转发策略的确定方法为：

1)配置中心配置为modbus协议转发时，转发服务将自身模拟为modbus从站，对外提供modbus/tcp服务，根据该采集点的数据类型和所配置的占用地址将数据更新至对应的转发服务模拟modbus从站中；

2)配置中心配置为IEC-104协议转发时，转发服务将自身模拟为IEC-104主站，对外提供IEC-104tcp服务，根据该采集点的数据类型和所配置的占用地址将数据更新至对应的转发服务模拟IEC-104主站中；

3)配置中心配置为http协议转发时，将http服务端地址加入配置中心，转发服务作为http client将转发数据以JSON形式包含在http post请求中发送至http服务端，在收到服务端正常响应后，进行下一次数据发送。

Images