监控数据统一接收平台的研究与设计

郭永平　朱宇

摘 要：设计了一种能够适应多种类型的监测站、人工采集、外部系统等多种监测数据的统一数据接收平台。该方法对多种类型监控系统数据的接收过程进行了分析，采用面向接口的编程技术及数据库设计技巧，实现了多数据源监控信息的接收，对接收的数据统一进行修正及合法识别，为监测分析系统提供有效的数据。该监控数据统一接收平台的设计为开发通用监控系统数据伺服程序具有一定的借鉴意义。

关键词：监控数据；统一接收平台；研究与设计；伺服程序

中图分类号：TP311 文献标识码：A 文章编号：2095-1302（2016）04-00-04

0 引 言

远程监控系统广泛地应用于水文、国土、环保、道路交通等领域，在自然灾害、安全防护等方面发挥着举足轻重的作用。监控系统中的预测预警功能利用行业内研究分析模型，对采集的数据进行分析，以图表、仿真、动画演进等方式，展示监控对象的发展变化趋势，用于满足决策者的信息需求。数据采集负责远程监控系统数据来源，是整个系统的基础。目前数据采集主要有监测站采集、外部系统集成和人工报送三种方式。远程监控系统的网络结构示意图如图1所示。

1 远程监控系统的数据来源

1.1 自动监测站采集

随着无线网络及传感器技术的发展，自动监测站成为当前监控系统最主要的数据来源，对自动监测站数据的接收是统一数据接收平台的核心内容，需要能够兼容不同版本的传输规约。监测站数据采集系统由自动监测站、传输网络、监控中心三部分组成，自动监测站在数据传递前需对传送信息按照传输规约进行编报，监控中心数据接收则需完成对报文的收取、解译及解译后数据的容错、修正、存储操作。其工作流程如图2所示，具体如下所示：

（1）监测站监测到定点报或加报的条件得到满足；

（2）依据传输规约编制报文；

（3）通过无线网络将编制好的报文发送至监测中心工控机上；

（4）工控机上安装的数据接收程序对报文进行接收；

（5）将接收到的报文按照传输规约进行解包，将其解译为人工可以识别的数字；

（6）根据解译出报文中监测站的信息、修正信息和设定的阈值，按照一定的规则进行容错、修正处理；

（7）对处理的结果进行存储。

1.2 外部系统数据集成

外部系统数据是远程监控系统数据的补充来源之一，具有成本低、数据量大、避免重复投资等特点。如水质监测分析系统需要集成固定实验室系统的检测数据；水雨情监测预警系统需要集成气象局雨量监测数据、水文局水位监测数据。其数据采集方式一般使用发布与订阅模式进行数据集成。具体步骤如下：

（1）发布方将发送的数据写入到接收方可以操作的区域，通知接收方进行数据收取；

（2）接收方读取文件，将数据存储到数据库中。

1.3 人工采集

人工采集模式通过人工观察，将观察结果通过移动终端App或基于PC端的Web应用系统进行上报，上报至监测中心。

2 传统数据接收平台存在的问题

传统的某一版本的数据接收程序仅完成使用特定传输规约自动监测站的数据采集，依赖于监控系统定义的传输规约及特定项目的数据容错、修正规则。外部数据集成及人工采集直接写入分析系统的数据库中，即默认了这两部分数据的有效性。对传统数据接收程序进行分析后，不难发现存在四点缺陷。

2.1 预警预报系统与数据接收系统耦合度高

预警预报系统的职责是使用相应的数据模型和采集到的数据对现场状况进行分析预测，提供告警服务和输出变化趋势分析结果，并不关心数据来源及数据正确与否。人工采集和外部数据集成的数据直接写入分析系统数据库中，预警预报系统除需完成分析预测，还需对这部分数据的合法性进行验证和修正。

2.2 维护成本高

自动监测站在不同时期的传输规约和业务规则会发生相应的变化，传统接收程序是基于具体业务规则开发的，而不是基于抽象接口，在业务规则发生变化时，程序维护工作量大，且容易出错。

2.3 可移植性差

不同项目由于监测对象及应用地区不同，其传输规约和数据处理不同。传统的数据接收程序无法进行移植，必须修改原有程序，成果的复用仅仅是基于代码级别的，无法实现可配置化的开发，程序移植性差，增加了单个项目的开发成本。

2.4 故障排查困难

监控系统中信息加工的环节很多，传感器、编报软件、解译程序、分析算法、安装工艺均有可能存在缺陷。在系统运行阶段，当发生不可预期的错误时，无法进行追溯，从而无法准确的预判系统出现问题的环节。没有保留处理过程数据，不易排查发生故障的原因。

3 概要设计

3.1 框架设计

数据统一接收平台为所有数据采集模式使用统一的数据输出接口。接收平台先将接收到的原始数据存入本地数据库原始数据表中，由数据处理模块统一完成数据的验证与修正，对于不能满足分析系统对采集频率有要求的监测项目，利用平台提供人机交互接口进行统一插补。平台将数据接收使用的数据库同分析使用的数据库进行隔离，分析系统仅转移接收数据库中的合法数据。数据统一接收平台是按照分层模式进行设计的，其应用层和数据接收组件主要通过数据层进行耦合，耦合度比较低。数据统一接收平台应用框架图如图3所示。

（1）应用层：是人机交互的接口，功能有实时数据显示、原始数据查询、质疑数据人工干预、数据插补及出错诊断、参数设置等。同时为数据接收组件提供了标准的调用接口，是报文接收、解译及解译后的数据处理组件的调度程序。

（2）数据层：临时存储数据的本地数据库，包括监测站信息、接收到的原始数据、经数据处理程序处理后的质疑数据和合法数据等。

（3）支撑层：由数据接收统一平台的应用组件组成，包括报文接收、报文解译、数据处理、数据访问、数据集成等应用组件。

（4）网络层：包括传输网络和监控中心的软硬件环境。

（5）采集层：包括自动监测站、外部系统和手工报送的数据。

3.2 本地数据库设计

本地数据库用于存储数据接收的临时数据库，为了确保程序运行性能，该数据库中的数据可以按照一定规则进行清除。本地数据库由原始数据表、质疑数据表及合格数据表三部分组成，其中原始数据表存储接收的原始数据，经过数据处理服务对原始的数据进行处理后，将判断有问题的数据存入质疑数据表，并推送至工作人员工作桌面，交与工作人员进行人工干预，合格数据则存入合格数据表，为分析系统进行转移的程序仅和合格数据表发生关系。本地数据库实体关系图如图4所示。

本地数据库设计中增加了用于存储原始数据表，便于进行错误溯源的功能。如当数据出现异常时，若数据是自动监测站采集的，可由原始数据表中提取原始报文，按照传输规约进行手工解译，便可分析出错误是由监测站软硬件引发的还是监控中心解译程序引发的，若为监测站软硬件故障，进一步对出现异常的数据进行频率分析，即可判定是设备故障还是安装工艺出现问题。

4 系统实现

数据统一接收平台使用微软提供的Visual Studio 2010 软件开发平台进行开发，Visual Studio 2010平台提供了丰富的界面控件和类库，为开发人员提供了极大的便利。接收平台的本地数据库选择MySQL。采用面向接口编程思想进行构件化设计，在自动监测站数据接收中，对容易变化的部分使用了工厂方法模式，统一数据接收平台部分的静态类图如图5所示。

4.1 应用主程序

为C/S结构的应用程序，监控中心运维工作人员与监控系统进行交互的接口，为工作人员提供观察数据接收情况、进行质疑数据的人工处理和数据插补，故障预判等功能。

4.2 数据通讯组件

自动监测站与监控中心工控机通讯是基于TCP/IP的通讯方式，数据通讯组件采用多线程非阻塞式进行报文接收。Visual Studio 2010平台提供了TcpListener 、TcpClient、UdpClient等通讯类，使得通讯程序开发变的非常简单。

4.3 报文解译

报文解译组件引进了工厂方法模式，将主调用程序和具体的实现类进行隔离，它仅依赖于稳定的解译接口和创建解译实例的工厂接口，与具体的解译类无关，这样在数据接收服务程序运行过程中，根据具体运行环境可动态创建具体解译对象，实现可配置化的应用，用于应对传输规约变化。在图5中，定义工厂方法模式的核心类工厂接口，在接口中有获取报文解译实例方法。解译工厂类是实现了工厂接口的具体类，主调用程序仅依赖相关解译的接口，而不是具体的实现。将实例的创建放在几乎不包含业务逻辑的工厂类中创建，这样做的好处是代码结构更清晰。在调用程序和创建工厂之间增加协调类，协调类的作用是避免主程序与子工厂交流，进一步隔离了使用者和对象创建者的关系。同时在协调类中使用反射机制，通过配置文件实现可配置化的应用。在协调类的构造函数中，读取配置文件所要创建的业务对象工厂字符串，通过类的反射实现了工厂对象的创建，由工厂去实例化具体的业务类，程序代码并不涉及是对哪种监测对象进行监测。通过以上代码可以容易看出，调用主程序只关心要执行的操作，具体是哪种工厂创建的实例对其而言是透明的。这样，当实际工作中的传输规约发生变化时，我们只需增加一个实现解译接口的具体类，通过修改配置文件中的使用工厂类名称，即可实现监测数据接收程序的升级或开发，并不对程序原有部分做任何更改。

4.4 数据处理

数据处理模块是业务规则的易变部分，在设计上与报文解译部分类同，由工厂类进行实例的创建，如图5中的水质工厂类，能够创建水质解译实例和水质数据处理实例。

5 数据访问

数据访问模块对数据库的连接、数据查询、更新的二次封装提供数据集合向实体对象转化的ORMapping。将对数据库底层的数据访问操作和上层的商务逻辑分开，提供了调用程序中的数据查询、提取、保存等业务。

6 结 语

监控数据统一接收平台实现了多种数据源的监测数据接收问题，使用统一的处理方法，完成了数据的容错、修正、分类等处理，不间断地为监控数据分析系统提供合法有效的数据。在系统设计中增加了用于存储临时数据的本地数据库，完成了过程数据的存储，解决错误追溯，并将数据接收系统与数据分析系统通过创建不同的数据库进行隔离，提高了程序的稳健性。在业务规则易变的报文解译和数据验证部分，将工厂方法模式和类的反射机制配合使用，使得程序结构更加清晰，增强了软件的可维护性，实现了监控数据接收服务程序可配置化应用与开发，对开发通用的监测数据接收服务程序具有一定的借鉴意义。

参考文献

[1]中华人民共和国水利部.水资源监控管理系统数据传输规约（SL427-2008）[M].北京：北京科文图书业信息技术有限公司，2008.

[2] GAMMA E.Design patterns：abstraction and reuse of object--oriented software[M].Reading，Mass：Addison—Wesley，1995.

[3] 李凤云，严德昆，季峰.GPRS城市供水远程无线监测管理系统[J].机械与电子，2007（1）：80-81.

[4] 黄传华，陈燕，艾丽军.水资源远程实时监控系统传输网络设计探讨[J].中国水利，2004（23）：43-44.

[5] 任中方，张华.MVC模式研究的综述[J].计算机应用研究，2004 （10）：1-4.

[6] Kouresh Ardestani，Kevin Hoffman，Dnald Xie.高效掌握ADO.NET—C#编程篇[M]. 张哲峰，译.北京：清华大学出版社， 2003.

[7]郭永平.水资源信息监控系统的设计与实现[D].西安：西安电子科技大学，2012.

[8]中华人民共和国水利部.国家水资源监控能力建设项目实施方案（2012-2014）[M].2011.

[9]戴智英.计算机软件应用及发展趋势探析[J].电子技术与软件工程，2014（4）：92.

[10] 杨修志.公路桥梁养护管理工作中凝结的新理念[J].北京公路，2011（1）：35-37.

[11]汤涛.NET企业级应用程序开发教程[M]. 北京：清华大学出版社， 2005.