氣象信息實時監視系統改進設計與實現

孫周軍, 肖文名, 宋遠清, 石小英, 王 壘, 陳曉宇, 何婉文

(1.廣東省氣象信息中心,廣東廣州510080;2.陜西省氣象信息中心,陜西西安710014)

0 引言

為做好氣象信息實時傳輸的監視和管理工作,提高氣象數據通信質量,廣東省信息中心組織研發”氣象信息實時監視系統[1]”,以實現各類氣象數據的收集和分發的實時監視,并對漏收、漏發或遲收、遲發的資料進行預警,避免資料的缺收和缺發現象,提高全省各類氣象資料的傳輸時效[2]。系統開發完成后,在全省氣象部門得到推廣應用,取得較好的業務效益,同時也暴露需要改進完善的問題,例如系統響應慢,不兼容火狐瀏覽器等。

通過調查各單位對“氣象信息實時監視系統”的使用體驗,推敲系統實現中采用的具體方法,充分分析現有數據傳輸業務系統的流程,主要針對系統的響應速度、用戶體驗、系統穩定性等進行重新設計與實現。

1 現狀分析

1.1 監控手段

目前,省級中心站對氣象資料傳輸的保障主要依靠氣象信息實時監視系統和目錄檢索的方式;對于臺站傳輸資料的保障主要依靠測報軟件的回執、氣象信息實時監視系統的查詢功能保障資料的傳輸,另外臺站會經常通過電話到省級中心站進行查詢核實。分析以上的資料傳輸保障手段,存在自動化監視程度低,增加值班人員工作量的缺點。

為此,應采用先進的計算機技術,結合移動網絡或電話網絡[3],開發滿足省、市、縣三級氣象資料實時監視系統,加強監控力度,實現自動化,減輕監控和維護保障的工作量,提高資料的傳輸時效。

1.2 關鍵問題

(1)采集資料日志。日志采集是實現資料傳輸監視的核心問題。日志采集的時間點與環節這兩大因素,直接影響監視系統的效率。觀測資料傳輸及時性與完整性是信息網絡業務維護保障的核心內容,因此,日志的提取處理必須避免對資料完整性與傳輸時效性的影響。

(2)合理組織數據。針對原有監視系統響應速度慢問題,設計優化合理的數據存儲結構,有助于降低監視系統開發的復雜度,同時能夠提升系統響應用戶請求的速度。

(3)監視界面的設計。信息傳輸狀態的查詢、展示是監視系統開發成敗的主要因素之一。優良合理的監視布局對用戶而言,能方便清晰地展現用戶所關心的信息。因此,系統的操作應該遵循用戶的使用習慣,展示的信息要正確、及時和完整。

2 系統設計

2.1 軟件總體設計

圖1顯示了實時監視系統的層次結構,可分為4個層次:數據采集層、數據層、邏輯層和展現層。數據采集層主要是在接收到臺站資料或將資料發送到國家局后,采集資料信息數據,另外對已采集到的資料信息數據進行統計加工處理。數據層主要以合理的數據結構存貯數據采集層采集的數據并提供數據存取服務。邏輯層主要負責解析用戶發出的訪問請求,對請求進行業務邏輯計算處理并返回結果。展現層主要負責將采集到和經過統計加工的數據通過Web以圖表的形式展現給用戶。

2.2 軟件總體設計

系統不同的用戶,對系統功能的關注范圍也有所不同:

(1)基層臺站使用單位:注重了解觀測資料是否已經及時傳輸到省信息中心。

(2)省級信息中心用戶:一方面注重及時全面了解各類資料各測報單位是否傳輸規定的報文,另外注重監視收到的資料是否傳輸到國家氣象信息中心。

(3)省級業務管理部門用戶:注重某段時間窗內全省各類資料的傳輸質量統計,并注重掌握傳輸質量低的測站單位與資料類別。

系統在進行具體設計實現時,充分考慮各用戶群的關注焦點,將系統功能劃分為:傳輸質量、詳細查詢、實時監視和系統管理4個主要模塊。

圖2為傳輸質量的主界面,主要完成信息傳輸及時率、缺報率等統計結果的展示。針對省、市業務管理部門用戶,提供年度、整月、周和天全省氣象信息傳輸及時率對照圖表;提供年度、整月、周和天各市氣象信息傳輸及時率對照圖表;提供某類資料逐月、逐天和24小時各區縣氣象信息傳輸及時率對照表。

圖1 系統結構

圖2 傳輸質量模塊

圖3為詳情查詢的主界面。針對臺站和省級用戶,主要實現氣象信息資料收發情況的詳情展示。可根據用戶選擇的時次、地市和資料類別等條件迅速檢索出該類資料的接收與發送情況。展示的內容主要包括資料類別、資料時次、接收與發送時間和資料到達時的字節數。其中,資料字節數信息是對舊系統非常實用的改進功能,在發生臺站傳輸空報文而發生爭議時,該功能便可以提供有力的證據。

圖3 詳細查詢模塊

圖4為省級實時監視的主界面,按照資料類別進行分類,并將每類資料按照觀測時間進行全天顯示,對于高密度觀測時次資料,則顯示2個小時內所有觀測時間資料的時效情況。其中:包括報文及時到達;超時效缺報及報文缺;報文逾限到達。對于省級用戶,可以監視到省內所有站點某類報文24小時內所有時次的到報情況;對于臺站用戶,可以監視到自身臺站需要觀測的資料的24小時內所有時次的到報情況,且該監視內容在2分鐘進行一次刷新,確保監視的及時性。

圖4 省級實時監視模塊

系統管理主要提供系統基礎信息配置,針對省級信息中心用戶,可以進行各類資料考核時效的管理,考核站點信息的管理,通過使用說明檢索系統各功能的使用方法。另外提供用戶關注臺站的設置功能,系統各模塊根據設置的關注臺站進行數據的統計查詢。

3 關鍵技術

3.1 索引技術

充分利用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。

3.2 視圖技術

傳輸詳細信息便按月分表存儲,數據量較大。在實時信息查詢中必須根據用戶選擇的時間窗給出結果。為簡化復雜的業務邏輯并提高開發效率,快速顯示數據,系統將12個月表聯合創建1個視圖,對用戶的查詢請求通過查詢視圖而獲取結果[4-5],避免跨越查詢需要修改檢索Sql中表名的問題。

3.3 豎橫表置換

豎表是普通的建表方式,如表結構為:主鍵、站點、資料時次、時效;如果變成橫表后,則結構為:主鍵、站點、時效+資料時次1、時效+資料時次2、時效+資料時次3……實時監視模塊中的監視數據展現便是橫表的方式,而數據庫中的存儲是采用豎表的方式,Decode函數是Oracle的Sql語言中特有的性質,通過該函數可以實現表格的置換,從而方便的實現某地區一種資料所有時次傳輸時效的顯示。

3.4 預處理技術

對于用戶的統計請求,如果實時的從海量原始數據中進行統計計算,每次相同的請求,都需要進行實時統計計算,給系統造成較大壓力,并且讓用戶等待較長時間。系統從管理用戶角度出發,對海量數據進行統計預處理,形成符合管理部門需求的中間統計結果進行存儲。對于統計訪問請求,能夠直接在中間統計結果中進行簡單查詢,同樣滿足用戶統計訪問請求。與實時統計計算方法比較,只需要計算一次統計結果,產生較小的系統負荷,并無需較長時間等待,傳輸時效統計模塊的實現采用方法取得較好效果。

3.5 跨瀏覽器

目前瀏覽器種類繁多,同一網頁在其中的運行效果有所偏差或無法使用,原因在于廠商在瀏覽器實現中采用的標準或技術有所差別,網頁的開發中涉及的JavaScript腳本與Css樣式技術在不同瀏覽器中的使用方法不同。為使系統能跨瀏覽器運行,采用JQuery腳本類庫進行實現,它是一套跨瀏覽器的基礎腳本庫,實現中涉及到的所有腳本程式均基于該類庫開發。另外在編寫系統的Css樣式時,在樣式文件中一個樣式控制語句按照多種語法進行編寫,達到多瀏覽器正確顯示的效果。

3.6 Spring框架

Spring是一個基于控制反轉(Inversion of Control,IoC)和面向方面編程(Aspect Oriented Programming,AOP)的構建多層[4]J2EE系統的框架[6],對現存的各種框架如Struts、JSF、Hibernate等提供了相應的整合框架。利用框架進行系統開發可有效的提高開發效率,使系統邏輯關系清晰,并具有較好的可擴展性。

4 與舊系統比較

經過改進之后的系統,瀏覽器兼容性得到增強,系統的響應速度大幅度提高,系統采用了圖表和條件選擇面板等功能之后,用戶的體驗效果得到進一步改善。

4.1 瀏覽器兼容性

將改進后的系統與之前的系統分別在 IE(6,7,8,9)、firefox、Mac、Safari、遨游、360、QQ 瀏覽器進行功能測試,新系統布局和功能均正常表現良好;但舊系統則在firefox、Mac、Safari、遨游瀏覽器上布局和功能發生異常行為或無法使用。

表1 系統改進前后對瀏覽器兼容性測試分析標

4.2 響應速度

采用Charles工具監視系統的HT TP請求,采集返回字節數、耗時等詳細信息,計算出系統響應的平均速度。分別訪問舊系統與系統相同的功能模塊,得到對比圖5、圖6,監控模塊與統計模塊的系統響應速度平均有31倍的性能提升,最小11倍,最高達到70倍。表明采用數據庫索引、視圖、預處理和數據結構優化技術取得明顯效果。

4.3 用戶體驗

(1)臺站用戶需要一次能夠看到一種資料24小時的報文傳輸時效,舊系統需要實現這種需求則需要選定24次查詢條件,并點擊24次查詢按鈕,才可達到用戶的上述需求。新系統則對這點進行了改進,只需點擊一次,便可看到24小時的報文傳輸時效。

(2)傳輸質量統計模塊實現中,采用三維柱狀圖表與線性圖表分別展示某時間窗內各種資料的傳輸時效、某類資料各市區和站傳輸時效對比等,用戶更加直觀了解資料的傳輸情況與對比情況。

(3)實現時間選擇面板,用戶可以方便的將檢索時間窗設置在某年、月、周、日內,并利用新設置時間條件運行當前模塊,改變傳統的需要選擇開始、結束時間的做法。

(4)用戶可設置所關注資料傳輸時效的臺站,一次設置后,下次從同一臺終端進入系統則默認展現為用戶所設置臺站的資料傳輸時效。

5 結束語

系統的設計并非完美,需要對下列問題進行思考并給予解決:(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.