孙周军, 肖文名, 宋远清, 石小英, 王 垒, 陈晓宇, 何婉文
(1.广东省气象信息中心,广东广州510080;2.陕西省气象信息中心,陕西西安710014)
为做好气象信息实时传输的监视和管理工作,提高气象数据通信质量,广东省信息中心组织研发”气象信息实时监视系统[1]”,以实现各类气象数据的收集和分发的实时监视,并对漏收、漏发或迟收、迟发的资料进行预警,避免资料的缺收和缺发现象,提高全省各类气象资料的传输时效[2]。系统开发完成后,在全省气象部门得到推广应用,取得较好的业务效益,同时也暴露需要改进完善的问题,例如系统响应慢,不兼容火狐浏览器等。
通过调查各单位对“气象信息实时监视系统”的使用体验,推敲系统实现中采用的具体方法,充分分析现有数据传输业务系统的流程,主要针对系统的响应速度、用户体验、系统稳定性等进行重新设计与实现。
目前,省级中心站对气象资料传输的保障主要依靠气象信息实时监视系统和目录检索的方式;对于台站传输资料的保障主要依靠测报软件的回执、气象信息实时监视系统的查询功能保障资料的传输,另外台站会经常通过电话到省级中心站进行查询核实。分析以上的资料传输保障手段,存在自动化监视程度低,增加值班人员工作量的缺点。
为此,应采用先进的计算机技术,结合移动网络或电话网络[3],开发满足省、市、县三级气象资料实时监视系统,加强监控力度,实现自动化,减轻监控和维护保障的工作量,提高资料的传输时效。
(1)采集资料日志。日志采集是实现资料传输监视的核心问题。日志采集的时间点与环节这两大因素,直接影响监视系统的效率。观测资料传输及时性与完整性是信息网络业务维护保障的核心内容,因此,日志的提取处理必须避免对资料完整性与传输时效性的影响。
(2)合理组织数据。针对原有监视系统响应速度慢问题,设计优化合理的数据存储结构,有助于降低监视系统开发的复杂度,同时能够提升系统响应用户请求的速度。
(3)监视界面的设计。信息传输状态的查询、展示是监视系统开发成败的主要因素之一。优良合理的监视布局对用户而言,能方便清晰地展现用户所关心的信息。因此,系统的操作应该遵循用户的使用习惯,展示的信息要正确、及时和完整。
图1显示了实时监视系统的层次结构,可分为4个层次:数据采集层、数据层、逻辑层和展现层。数据采集层主要是在接收到台站资料或将资料发送到国家局后,采集资料信息数据,另外对已采集到的资料信息数据进行统计加工处理。数据层主要以合理的数据结构存贮数据采集层采集的数据并提供数据存取服务。逻辑层主要负责解析用户发出的访问请求,对请求进行业务逻辑计算处理并返回结果。展现层主要负责将采集到和经过统计加工的数据通过Web以图表的形式展现给用户。
系统不同的用户,对系统功能的关注范围也有所不同:
(1)基层台站使用单位:注重了解观测资料是否已经及时传输到省信息中心。
(2)省级信息中心用户:一方面注重及时全面了解各类资料各测报单位是否传输规定的报文,另外注重监视收到的资料是否传输到国家气象信息中心。
(3)省级业务管理部门用户:注重某段时间窗内全省各类资料的传输质量统计,并注重掌握传输质量低的测站单位与资料类别。
系统在进行具体设计实现时,充分考虑各用户群的关注焦点,将系统功能划分为:传输质量、详细查询、实时监视和系统管理4个主要模块。
图2为传输质量的主界面,主要完成信息传输及时率、缺报率等统计结果的展示。针对省、市业务管理部门用户,提供年度、整月、周和天全省气象信息传输及时率对照图表;提供年度、整月、周和天各市气象信息传输及时率对照图表;提供某类资料逐月、逐天和24小时各区县气象信息传输及时率对照表。
图1 系统结构
图2 传输质量模块
图3为详情查询的主界面。针对台站和省级用户,主要实现气象信息资料收发情况的详情展示。可根据用户选择的时次、地市和资料类别等条件迅速检索出该类资料的接收与发送情况。展示的内容主要包括资料类别、资料时次、接收与发送时间和资料到达时的字节数。其中,资料字节数信息是对旧系统非常实用的改进功能,在发生台站传输空报文而发生争议时,该功能便可以提供有力的证据。
图3 详细查询模块
图4为省级实时监视的主界面,按照资料类别进行分类,并将每类资料按照观测时间进行全天显示,对于高密度观测时次资料,则显示2个小时内所有观测时间资料的时效情况。其中:包括报文及时到达;超时效缺报及报文缺;报文逾限到达。对于省级用户,可以监视到省内所有站点某类报文24小时内所有时次的到报情况;对于台站用户,可以监视到自身台站需要观测的资料的24小时内所有时次的到报情况,且该监视内容在2分钟进行一次刷新,确保监视的及时性。
图4 省级实时监视模块
系统管理主要提供系统基础信息配置,针对省级信息中心用户,可以进行各类资料考核时效的管理,考核站点信息的管理,通过使用说明检索系统各功能的使用方法。另外提供用户关注台站的设置功能,系统各模块根据设置的关注台站进行数据的统计查询。
充分利用Oracle数据库索引技术,提高SQL语句的执行效率。程序开发人员在执行SQL语句时要采用一定策略利用索引,并且将有索引的字段放在Where条件的前面,如果查询不使用索引或索引失效的情况下,数据库系统会进行全表扫描,执行效率非常慢。对于Oracle而言,在某日期字段A上建有索引,若使用“=”符号进行匹配检索,执行效率非常高;但对于需要跨天的查询若使用“>=”与“<=”符号进行匹配检索,此时索引失效,执行效率很低。所以在信息查询模块的实现中,对用户请求的开始时间与结束时间进行分情况处理,例如若用户需要检索2011-12-01 01:00:00到2011-12-01 23:45:00的数据时,SQL1=Where年月日字段=“2011-12-01”and时分秒字段 >=“01:00:00”and时分秒字段 <=“23:45:00”;SQL2=Where年月日时分秒字段>=“2011-12-01 01:00:00”and年月日时分秒字段<=“2011-12-01 23:45:00”,SQL1的执行效率要远远高于SQL2。
传输详细信息便按月分表存储,数据量较大。在实时信息查询中必须根据用户选择的时间窗给出结果。为简化复杂的业务逻辑并提高开发效率,快速显示数据,系统将12个月表联合创建1个视图,对用户的查询请求通过查询视图而获取结果[4-5],避免跨越查询需要修改检索Sql中表名的问题。
竖表是普通的建表方式,如表结构为:主键、站点、资料时次、时效;如果变成横表后,则结构为:主键、站点、时效+资料时次1、时效+资料时次2、时效+资料时次3……实时监视模块中的监视数据展现便是横表的方式,而数据库中的存储是采用竖表的方式,Decode函数是Oracle的Sql语言中特有的性质,通过该函数可以实现表格的置换,从而方便的实现某地区一种资料所有时次传输时效的显示。
对于用户的统计请求,如果实时的从海量原始数据中进行统计计算,每次相同的请求,都需要进行实时统计计算,给系统造成较大压力,并且让用户等待较长时间。系统从管理用户角度出发,对海量数据进行统计预处理,形成符合管理部门需求的中间统计结果进行存储。对于统计访问请求,能够直接在中间统计结果中进行简单查询,同样满足用户统计访问请求。与实时统计计算方法比较,只需要计算一次统计结果,产生较小的系统负荷,并无需较长时间等待,传输时效统计模块的实现采用方法取得较好效果。
目前浏览器种类繁多,同一网页在其中的运行效果有所偏差或无法使用,原因在于厂商在浏览器实现中采用的标准或技术有所差别,网页的开发中涉及的JavaScript脚本与Css样式技术在不同浏览器中的使用方法不同。为使系统能跨浏览器运行,采用JQuery脚本类库进行实现,它是一套跨浏览器的基础脚本库,实现中涉及到的所有脚本程式均基于该类库开发。另外在编写系统的Css样式时,在样式文件中一个样式控制语句按照多种语法进行编写,达到多浏览器正确显示的效果。
Spring是一个基于控制反转(Inversion of Control,IoC)和面向方面编程(Aspect Oriented Programming,AOP)的构建多层[4]J2EE系统的框架[6],对现存的各种框架如Struts、JSF、Hibernate等提供了相应的整合框架。利用框架进行系统开发可有效的提高开发效率,使系统逻辑关系清晰,并具有较好的可扩展性。
经过改进之后的系统,浏览器兼容性得到增强,系统的响应速度大幅度提高,系统采用了图表和条件选择面板等功能之后,用户的体验效果得到进一步改善。
将改进后的系统与之前的系统分别在 IE(6,7,8,9)、firefox、Mac、Safari、遨游、360、QQ 浏览器进行功能测试,新系统布局和功能均正常表现良好;但旧系统则在firefox、Mac、Safari、遨游浏览器上布局和功能发生异常行为或无法使用。
表1 系统改进前后对浏览器兼容性测试分析标
采用Charles工具监视系统的HT TP请求,采集返回字节数、耗时等详细信息,计算出系统响应的平均速度。分别访问旧系统与系统相同的功能模块,得到对比图5、图6,监控模块与统计模块的系统响应速度平均有31倍的性能提升,最小11倍,最高达到70倍。表明采用数据库索引、视图、预处理和数据结构优化技术取得明显效果。
(1)台站用户需要一次能够看到一种资料24小时的报文传输时效,旧系统需要实现这种需求则需要选定24次查询条件,并点击24次查询按钮,才可达到用户的上述需求。新系统则对这点进行了改进,只需点击一次,便可看到24小时的报文传输时效。
(2)传输质量统计模块实现中,采用三维柱状图表与线性图表分别展示某时间窗内各种资料的传输时效、某类资料各市区和站传输时效对比等,用户更加直观了解资料的传输情况与对比情况。
(3)实现时间选择面板,用户可以方便的将检索时间窗设置在某年、月、周、日内,并利用新设置时间条件运行当前模块,改变传统的需要选择开始、结束时间的做法。
(4)用户可设置所关注资料传输时效的台站,一次设置后,下次从同一台终端进入系统则默认展现为用户所设置台站的资料传输时效。
系统的设计并非完美,需要对下列问题进行思考并给予解决:(1)日志提取环节改进:在报文发送到国家气象信息中心的环节提取接收日志不合理。因为从接收到传输给国家局之间有一定的时延,在资料传输国家局时提取资料接收日志,间接地增加台站用户了解资料是否上传到信息中心的时延。台站用户需要及时了解省信息中心收报情况,所以这种不合理可能导致用户不使用系统进行查询,而直接电话省气象信息中心咨询,或直接进入接收目录进行查询,弱化了系统建设的实用性。图7、图8分别给出改进前后的日志提取流程,并且需要在以后开发中解决。改进可以提高系统采集资料接收日志的及时性,减少台站值班人员查询资料到达省信息中心的等待时间。
(2)语音电话追报:在省气象信息中心人员发现有台站在时效警戒时间内还未发报时,中心值班人员需要电话提醒台站发报人,目前人工进行电话追报,给值班人员带来很大压力。结合语音电话系统,将未发报的告警提示信息自动拨打到台站值班电话或值班负责人手机进行语音提示,可减少避免人工电话追报的工作任务[7]。
改进后的气象信息实时监视系统投入试运行以来,得到全省市、县气象工作人员的广泛使用,在系统反映速度、用户体验等细节上给出了较高的评价。系统的建立与改善对提高广东省实时气象资料的传输时效起到了很好的保障作用。
[1] 梁慎青,石小英,梁苑苑,等.气象信息实时监视系统的开发及应用[J].广东气象,2009,31(1):57-59.
[2] 孙林花,李仲龙,孙润,等.基于元数据技术的气象数据收发全网监视系统[J].干旱气象,2009,27(3):294-297.
[3] 梁海河,孟昭林,张春晖,等.综合气象观测运行监控系统[J].气象,2011,37(10):1292-1300.
[4] 罗琦,韩茜,李文莉,等.基于WEBGIS的气象科学数据查询显示系统的设计与实现[J].干旱气象,2010,28(4):494-498.
[5] 沙莎,邱新法,何永健.基于GIS的自动气象站数据系统的研发[J].干旱气象.2011,29(3):372-376.
[6] 孔霞,吕峰.基于Spring的Web框架的设计以及其应用[J].电脑知识与技术.2009,5(18):5050-5052.
[7] 冉井旺,戴滔.语音报警在集中监控系统中的设计应用[J].自动化应用.2011,(3):1-3.