赵永辉
河南省环境监控中心
污染源自动监控数据传输技术研究
赵永辉
河南省环境监控中心
为增强污染源自动监控数据传输的可靠性、上传数据的完整性,解决实际工作中遇到的数据传输和接收问题,对污染源自动监控数据采集和传输、接收平台的数据接收和入库进行了技术研究、探讨分析与实施改造。
污染源;自动监控;数据传输;数据库
河南省环保厅投资6.7亿,以“覆盖全省、功能完备、技术先进、全国一流”为目标,建设了全省环境自动监控系统,利用现代化环境自动监测技术和信息网络技术,对环境质量、污染源排污情况等实行全过程监控,提升了全省环境管理的科学化、数字化和现代化水平。
污染源自动监控系统是全省环境自动监控系统的重要组成部分,如图4所示是在全省几百个重点污染企业建立上千个监控基站,通过监控基站的自动监测设备对企业污染物排放状况进行自动分析,并将分析结果数据通过网络上传到省、市环境监控机构的监控平台上,环境监控机构通过对数据进行监控和分析,为环境决策和管理执法提供依据。
图1
为规范污染源自动监控数据传输,保证污染源监控基站、传输网络和监控平台之间的连通,环保部制定了《污染源在线自动监控(监测)系统数据传输标准》(HJ/ T212-2005,以下简称《传输标准》),规定了污染源监控基站和监控平台接收程序之间数据通讯、控制和报警等信息的传输通讯协议,此协议对应于 ISO/OSI 定义的 7层协议的应用层,通常在TCP/IP协议基础上实现。
笔者所在单位在省环境监控平台部署了上级部门下发的污染源自动监控系统软件,用于接收污染源监控基站上传数据并进行监控管理。此系统中监控基站与接收程序之间的数据通讯使用《传输标准》规定的传输协议。经过将近1年的使用,随着数据库中数据量的累积,频繁出现数据堵塞无法入库的数据接收故障。具体表现为数据库服务器长时间持续高吞吐量访问磁盘,达到每秒几十不高问题,对污染源监控基站数据上传采取了下列措施。
3.1.1 污染源监控基站发送的数据指令要严格遵照相关标准。要求监控基站上传的数据指令要严格遵守《传输标准》,并按照如下格式顺序,以利于提高接收程序解析数据包的效率:
ST=xx;CN=xx;QN=xx;PW=xx;M N=xx;CP=&&DataTime=xx;各因子监测值=xx... &&。
其中:ST=系统编号、CN=命令编号、QN=请求编号、PW=访问密码、MN=数据采集仪编号, CP=数据区标识。
3.1.2 严格规范污染源监控基站上传的数据类型、污染因子。禁止多余和无用的数据上传,例如废气监控基站只上传下列数据类型:二氧化硫浓度、氮氧化物浓度、烟尘浓度、烟气流量、烟气含氧量、烟气温度、烟气压力等因子的10分钟数据和小时数据。接收程序接收数据时同时进行判断,不符合要求的数据一律丢弃,不予入库,减少数据库操作和存储压力。
3.2 实现污染源自动监控数据的可靠传输
通过扩展传输协议,实现污染源自动监控数据传输的确认重发和自动补传机制,增强数据上传的可靠性,避免因网络或接收平台故障造成的数据缺失。
3.2.1 实现污染源监控基站上传数据的确认重发机制。要求污染源监控基站上传数据后,需等待接收程序返回的入库成功确认信息。接收程序接收到数据并入库成功后,会向监控基站返回一条确认信息。监控基站如果收不到确认信息,则重发这条数据(有一定时间间隔),数据重发最多2次,如果仍未成功,则把此条数据放到补传队列中,通过“数据自动补传”机制来传输此条数据。
以废水监控基站向监控平台上传一条10分数据为例介绍确认重发指令的交互过程。
(1)监控基站向接收程序上传一条数据:
ST=32;CN=2051;QN=2011021011 4012001;PW=123456;MN=01523160184 009;CP=&&DataTime=20110210114000 ;B01-Cou=22.10,B01-Avg=36.83,B01-Min=35.95,B01-Max=37.59&&
"S T=3 2"代表废水污染源;"C N=2 0 5 1"代表1 0分钟数据;"QN=20110210114012001"表示本条指令编号;"MN=01523160184009"代表基站数据采集仪序列号。"CP=&&DataTime=20110210114000;B01-Cou=22.10,B01-Avg=36.83,B01-Min=35.95,B01-Max=37.59&&"是数据区内容,包括监测时间、流量的平均值、最大最小值等。
(2)接收程序在收到这条数据指令后,进行解析并将数据存储到数据库中,然后向监控基站返回一个确认应答:
ST=91;CN=9014;CP=&&QN=201102 10114012001;CN=2051;&& M甚至上百M字节,服务器几乎无法响应其它操作,致使接收平台接收的数据无法入库,造成数据丢失。同时如果出现网络或程序故障,监控基站数据无法及时入库就会造成数据丢失,无法弥补。这些故障和不足对日常管理和监控工作造成很大的不便,急需解决。
笔者组织专人对污染源自动监控系统软件、数据库、服务器、网络等进行了分析,以期找到故障原因和解决办法。
污染源自动监控系统软件完全按照软件手册和相关要求进行部署,数据库和通讯服务器采用高于主流性能配置的服务器,超出系统软件对于服务器的硬件要求,使用的服务器操作系统、Sql Server数据库管理系统安装无误且进行了优化配置,网络畅通无阻。因此,数据接收故障可以排除服务器和网络因素。
通过跟踪分析,发现造成数据接收故障的原因主要有以下几方面:
2.1 污染源自动监控系统软件对海量数据存储管理存在不足,优化不够,数据库性能较低。每天重点污染源数据库接收数据超过40万条,几个主要的数据表均在千万条纪录以上,最大的数据表1年的纪录条数接近5000万。如此海量数据,数据库没有有效的海量数据存储管理机制,造成单张数据表数据量过于庞大,对数据库的简单操作都会造成对磁盘的大量读写,数据库性能低下,随时间推移数据库逐渐无法响应监控基站数据入库的请求,造成堵塞。
2.2 污染源自动监控系统软件的数据接收程序处理能力较弱,对上千个监控基站同时上传的大量数据包进行解析和入库的能力不足。该系统设计初衷是用于省辖市监控平台直接接收监控基站数据,监控基站数量较少,数据接收程序压力较小,省辖市监控平台通过数据交换技术同步到省级监控平台;根据工作需要,我省环境监控平台直接接收全省1000多个监控基站数据,数据接收程序压力很大,超出处理能力。
2.3 污染源监控基站与监控平台接收程序的数据通讯属于不可靠传输。对于每条监控数据,监控基站只发送一次,数据传输和入库是否成功,接收程序和监控基站均不进行确认;一旦因网络或数据库故障等原因造成数据丢失,数据传输系统缺乏有效的补救措施,无法进行补传,造成数据永久缺失。
2.4 污染源监控基站上传数据不够规范,没有严格按照相关标准协议和规定传输数据,存在大量无用信息上传的情况,加重了数据堵塞的程度。3.解决方法
针对以上故障原因分析,笔者组织专人对污染源监控基站的数据传输与接收进行了有针对性的深入研究,采取了四个方面的一系列技术方法和管理措施,较成功地对重点污染源自动监控数据传输与接收进行了性能优化和故障解决。
3.1 规范污染源自动监控数据上传
针对大量无用数据上传和数据解析效率
其中"S T=9 1"表示系统交互;"CN=9014"表示数据应答。
"C P=&&Q N=2 0 1 1 0 2 1 0 1 1 4 0 1 2 0 0 1;C N=2 0 5 1;&&"表示是对指令编号为2 0 1 1 0 2 1 0 1 1 4 0 1 2 0 0 1(QN=20110210114012001)的10分钟数据(CN=2051)所作的确认回应。
(3)监控基站一定时间间隔内收到确认应答后,本次指令交互过程结束;如果一定时间间隔内收不到确认应答,会重复步骤(1),重发这条数据指令。
3.2.2 实现污染源监控基站的数据自动补传机制。因通讯或程序故障,造成监控基站无法向接收程序发送数据时,监控基站要把故障期间采集的数据进行本地存储,待故障解决后再向接收程序补传这些数据。监控基站补传数据时,如果收不到接收程序发送的确认信息,则要持续重发这条数据,直到收到确认信息。数据重发不能影响补传队列中其它数据的正常补传,避免造成数据补传的堵塞。
具体实现方式如下(不是唯一实现方式):
3.2.2.1 监控基站需持续监听与接收程序的通讯链接,一旦通信链接中断,新采集的数据不再向接收程序上传,而是放入本地补传数据表。
3.2.2.2 待通讯连接正常后,监控基站向接收程序发送补传数据表中最新一条数据,并等待接收程序的确认信息。
3.2.2.3 监控基站如果收到确认信息则从补传数据表中删除此条数据,开始补传下一条数据;如果收不到接收程序发送的确认信息,则重发这条数据(有一定时间间隔),数据重发最多2次,如果重发2次后仍然收不到确认信息,此条数据不做处理,开始补传下一条数据(两条数据正常补传也有一定时间间隔)。
3.2.2.4 监控基站对补传数据表中的所有数据均进行过一遍补传后(无论成功与否),若补传数据表中仍然存在需补传数据,则重复(2)、(3)步骤,直到数据补传表中不存在需补传的数据。
3.2.2.5 数据补传表中只保留最近7日的数据,超过7日的数据要删除并转存到其它表中永久保存。
3.3 完善监控平台数据接收程序功能
为保障接收程序的长期无故障稳定可靠运行,采取了以下完善方法。
3.3.1 优化接收程序性能。接收程序工作时,与前端每个监控基站均建立一个TCP通讯链路,即使1000个基站同时上传数据,则相当于1000个接收程序同时在一对一的接收数据,保证了通讯链路的畅通。同时,根据接收程序使用的服务器是16核CPU的现状,1个核开辟1个线程可达到最佳数据转发存储性能,因此接收程序开辟16个线程把接收到的数据存储到数据库中,对服务器的CPU利用最大化。
3.3.2 建立备用数据库。接收程序使用的服务器上建立本地备用数据库,接收程序时刻监听与主数据库的通讯状况,一旦出现通讯故障,接收到的数据暂时存入本地备用数据库中,待与主数据库通讯恢复正常后,再将备用数据库中的数据补传到后台数据库中。
3.3.3 完善接收程序异常处理机制。通过加强代码分析、长期压力测试,分析接收程序的BUG,增强接收程序稳定性;数据接收异常时,利用短信告警功能告知相关工作人员;利用Watchdog守护进程软件时刻监听接收程序工作状况,一旦出现崩溃、中断等异常情况,Watchdog守护进程软件会自动重启数据接收程序,使数据接收程序继续正常工作。
3.3.4 接收程序实现日志功能。记录数据接收情况、程序运行情况、与数据库连接状态、与监控基站连接状态等信息,一旦出现故障,可以据此判断原因和详情。
3.4 优化自动监控数据库
数据库是重点污染源自动监控系统软件的核心,提高数据库存储和查询的效率对于解决此次数据接收故障至关重要,为此对数据库进行了下列优化设计。
3.4.1 重新优化设计数据库。根据实际工作需求,对数据库进行存储和应用查询优化设计,建立合适的索引;并用性能更强ORACLE 11G数据库替代原平台使用的SQL SERVER数据库。
3.4.2 完善海量数据存储技术。针对数据量庞大的问题,数据的存储采用数据表空间分区技术,对数据按月进行物理存储,避免单张数据表纪录条数过多情况,单张表数据量可控制在500万条纪录以内,可根据索引来自如地查询历史数据,极大地提高查询和存储效率。
以上各种技术方法和措施实施后,污染源监控基站数据传输通畅,入库顺利,查询快捷,出现传输故障可进行补传,基本解决了数据堵塞和缺数的问题,实现了数据可靠传输和数据库性能优化。
[1] 污染源在线自动监控(监测)系统数据传输标准,HJ/T212-2005
10.3969/j.issn.1001-8972.2012.06.045