省級氣象裝備保障業務一體化系統應用進展

劉偉+宮軍+董克非+牛虎+易濤

[摘 要]現代化氣象探測設備種類繁多、數量龐大，傳統的人工紙質化管理模式已不能滿足氣象裝備保障的智能化管理需求。而建立氣象裝備保障智能信息管理系統，可實現對全省各類氣象裝備全壽命的跟蹤，提高省氣象裝備庫存管理的科學性和現代化水平，及省氣象技術裝備配置、調撥供應等技術保障體系的運轉效率，同時也可以提升各類氣象裝備備件的實際運行效能。基于此，本文探討了省級氣象裝備保障業務一體化系統的應用進展。

[關鍵詞]氣象裝備；融合；一體化

doi：10.3969/j.issn.1673 - 0194.2017.22.045

[中圖分類號]TP315；P414 [文獻標識碼]A [文章編號]1673-0194（2017）22-00-02

1 研究背景

隨著科學科技的發展和現代化氣象業務的需求，氣象裝備使用的種類和數量也在不斷增加，全國目前已建立并投入業務運行的國家級地面氣象觀測設備主要包括：新一代天氣雷達站156個，L波段雷達探空站120個，自動氣象觀測站2 422個，國家級土壤水分觀測站1 688個，國家級GNSS/MET水汽觀測站601個，國家級雷電觀測站357個，各級地方氣象部門建成的鄉鎮及以下區域自動氣象站約有5萬余個，裝備供應保障任務越來越重。通過裝備保障業務一體化系統建設，建立信息化、集約化、標準化的省級裝備保障業務一體化系統，以統一的保障規范、編碼規范、編碼條目、站網信息、倉儲信息為基礎，將全國范圍內現有的裝備信息全部進行規范化入庫，包括在用、庫存的所有裝備，實現裝備保障業務信息化。通過應用現有省級與國家級CIMISS建設資源，融合交互省級現有4個業務系統（運行監控（ASOM）、動態管理、計量檢定、測試維修）數據與功能，實現裝備保障業務集約化。同時，建立健全保障業務流程，實現裝備從出廠、驗收到臺站應用報廢的全壽命跟蹤管理，并集約相關企業展示信息、領導機構發布信息，保證保障管理的閉環與信息通暢，實現裝備保障業務標準化。

應用現有省級與國家級CIMISS資源，建立省級裝備保障業務一體化，統一數據資源池，從物理與邏輯兩個層面融合省級現有的運行監控系統、動態管理系統、計量檢定系統、測試維修系統的基礎數據與業務數據，并將全國范圍內現有的裝備信息全部進行規范化入庫，包括在用、庫存的所有裝備，實現省級裝備保障業務的集約化建設；同時，建立標準的省級裝備保障業務規范，以統一的數據資源池為基礎，結合現有各業務系統已實現的功能與流程，通過切割與取舍這些功能，建立省級裝備保障業務一體化平臺，實現省級業務流程再造與標準化管理。

2 技術選型

2.1 設備信息

省級裝備保障業務一體化系統中具有二維碼形式管理設備，從而通過二維碼可以跟蹤氣象裝備全生命周期數據，使用光學識別、射頻識別等感知層技術，依據《氣象觀測裝備分類與編碼方法》規定的編碼規則，標記每一個觀測設備及備件，使一體化系統中所有測試具有唯一性的“身份證”。

2.2 軟件架構

在系統建設方面選用應用廣泛的面向對象的Java語言；后端使用Springmvc、Mybatis框架；前端使用jQuery、EasyUI；數據庫采用SQL SERVER 2008。

Springmvc具有強大的靈活性和擴展性，基于注解方式使用可以減少XML配置文件，只需要關注功能實現，使用更方便。Springmvc具有非常好的單元測試框架，無需啟動服務器即可快速進行單元測試，這對開發質量提高有非常大的幫助。

Spring框架版本提高到使用4.x，此版本支持大量Java新的規范標準，與各個第三方框架也有更好的兼容性。

使用Dubbo框架抽離核心業務開發獨立接口對外提供服務，Dubbo是一個分布式服務框架，提供了服務注冊和監控管理等功能，在Java中能夠友好地開發服務和被調用，對調用者而言，就像調用本地方法一樣簡單。服務抽離以后，不但能滿足現有系統的使用，還能為今后可能的其他系統提供服務。

目前，系統的卡頓主要是由于頁面渲染由后端進行處理，后端存在大量的查詢，這部分操作是同步進行的，一旦時間過長，會讓頁面響應緩慢，造成卡頓。為了解決這個問題，系統采用前后端分離的設計，頁面和數據異步加載，減少頁面響應時間，提高用戶體驗。并且前端分離后，采用模塊化框架進行管理，讓Java Script組織結構更加合理便于開發維護。

引入Mybatis持久化框架，簡化數據庫操作邏輯，單獨維護管理SQL，與程序代碼解耦。

2.1 軟件分層架構設計

軟件架構采用多層、模塊化設計，最大化解耦，降低各個層級和模塊之間的依賴，便于后期擴展和維護，且各個模塊彼此獨立。

架構技術說明。①依賴管理選型：項目采用Spring框架處理依賴管理，將對象之間的依賴關系交由Spring進行控制，避免硬編碼造成的程序過渡耦合，可以讓開發人員更加專注于上層業務實現。②面向切面：Spring框架提供了面向切面編程功能，許多不易用傳統面向對象實現的功能使用面向切面可以輕松應對。③事務管理：Spring框架還提供了聲明式事務管理功能，數據庫事務不再需要硬編碼，通過聲明式的方式靈活進行事務的管理，提高開發效率和質量。④單元測試：基于Spring框架后，可以實現用非容器依賴的編程方式進行幾乎所有的測試工作，單元測試不再是件成本高昂的事情，隨手可做。最后，Spring不排斥各種優秀的框架，相反，其可以降低各種框架的使用難度，特別是在系統引入技術較多時，統一代碼風格有重要作用。⑤持久化框架：持久化框架采用Mybatis實現，Mybatis是一個基于XML的輕量級持久化框架，其可以很好地把數據庫SQL代碼從程序代碼中剝離出來，讓代碼可讀性更高、更整潔。并且基于Mybatis可以很好地處理數據庫的入庫查詢類型轉換以及日志記錄工作。⑥權限框架：權限控制使用Apache Shiro進行管理，Shiro在保持強大功能的同時，還在簡單性和靈活性方面擁有巨大優勢，能夠非常清晰地處理認證、授權、管理會話以及密碼加密。⑦前端框架：系統引入了包含模板渲染、界面UI組件庫、模塊化管理等核心功能的前端框架，并且各個框架都只專注于核心的功能，非常輕量級，對于后期可能發生的意外變化有很高的適應性。除了最流行的jQuery，界面使用基于jQuery的Easyui組件庫，對界面進行美化和交互動作實現。模塊化管理方面使用Requrejs進行管理，可以讓Java Script代碼像Java代碼一樣具有清晰的層次結構和封裝復用功能。同時Requrejs也對css、html模板進行管理，每一次的請求服務器只需要返回變化的一小部分數據，前端對數據進行渲染并展示在瀏覽器上，大大減輕了服務端的壓力。⑧前端架構設計：前端采用Requrejs框架進行構建，采用模板+腳本+樣式的模式在客戶端瀏覽器進行頁面渲染，后臺服務只負責提供數據和處理數據，沒有任何頁面渲染工作，這樣的架構方式將后臺服務渲染頁面的工作交給客戶端瀏覽器進行，大大減輕了服務器的負載壓力。同時Requrejs的模塊化功能解決了前端Java Script腳本數量龐大難以管理的難題，依據按需加載，與后臺進行數據交互，提高系統性能。endprint

2.2 服務架構

2.2.1 Dubbo服務

業務層處理采用SOA設計思想，面向服務設計理念，把業務層邏輯抽象為服務，降低業務復雜度和優化系統結構。基于Dubbo實現的服務集群可以有效保障業務高性能、高可用運行，Dubbo對Java非常友好，可以像調用一個本地方法一樣調用服務，對開發者沒有其他額外工作。

在Dubbo中使用Zookeeper作為服務注冊中心，服務端和客戶端彼此通過Zookeeper進行協調調用，服務在運維中支持熱部署，有效減輕維護工作量，并且Dubbo是分布式的，可針對業務負載情況進行多點集群部署，提高系統承載能力。

使用Dubbo后，這些服務除了為一體化系統提供服務，還可為其他系統提供服務，無需再開發。

2.2.2 部署架構設計

系統采用多層分布式架構，按照職責劃分可分為以下幾層。

Web服務層：負責協調、調度客戶端請求，對請求進行負載均衡分發處理，管理部署所有Web靜態資源。

Web服務接口層：負責業務后臺處理和轉發請求，對接Dubbo服務。

Dubbo服務層：分布式的服務治理框架，把核心業務邏輯獨立成單獨的服務統一進行注冊管理。

3 功能設計

省級裝備保障業務一體化系統，將現有省級大氣探測中心4套業務系統進行整合、打通、融合，從而開發成一套整體業務系統。其主要功能模塊包括：數據采集分析、運行監控、觀測數據、維護維修、物資供應、計量檢定以及運行評估等功能點。

3.1 數據采集分析

融合現有ASOM采集功能，在現有ASOM數據采集分析功能的基礎上進行升級改造，通過省級Cimiss接口獲取10類裝備（包括天氣雷達、風廓線雷達、探空系統、國家級自動站、區域自動站、土壤水分站、GNSS/MET水汽觀測站、雷電監測站、大氣成分站以及風能站）站點數據情況、數據延誤情況、數據準確情況等信息，進行質控分析。

3.2 運行監控

融合現有ASOM運行監控模塊功能，將數據采集后的結果以GIS地圖形式或時序圖，帶有運行狀態展示、數據展示、站點填圖、數據填圖、告警展示、少量數據統計展示等功能，將數據直觀展示給用戶使用。

3.3 觀測數據

融合現有ASOM觀測數據模塊功能，以國家級自動站為例，可以詳細查詢降雨、風向、風速等信息。

3.4 維護維修

融合現有ASOM維護單管理功能，臺站級維護人員每天填寫設備日巡查單據，每周填寫周維護單據，每月填寫月維護單據，汛前填寫汛前巡檢單據。

融合現有ASOM維護維修模塊中故障單、停機通知功能及現有省級測試維修平臺整體業務功能，實現通過設備運行監控情況，系統可以分析設備告警信息，由告警生成故障單信息及停機信息。

3.5 物資供應

融合現有ASOM供應管理模塊及物資動態管理系統所有功能，并修復兩套系統不完善的功能點，通過該功能模塊實現全省設備采購、調撥、送修、送檢、啟用、換下以及報廢的全生命周期流程管理，且可以通過多維護信息展示查詢分析設備的使用狀況、維修情況等信息。

3.6 計量檢定

融合現有物資供應系統送檢功能與計量檢定（3MS）系統所有業務功能，實現檢定人員通過省級一體化系統統一入口，將全省送檢至檢定人員處的設備進行計量檢定，從而完成設備計量檢定。

4 運行效果

系統上線運行后打通了現在大探中心業務科室的數據流程，減輕了業務人員完成一項工作還需登錄多套系統的繁瑣工作，且數據流程打通后實現了設備全生命周期管理及查詢。

5 結 語

氣象裝備保障業務一體化系統的建設，在現有4套業務系統（運行監控（ASOM）、動態管理、計量檢定、測試維修）的基礎上，整合業務流程及數據流程，融合4套業務系統中所有站網信息數據、人員信息數據、配置碼表數據。其中，運行監控（ASOM）系統融合數據采集分析、運行監控、觀測數據、維護維修、信息發布、運行評估功能模塊；物資動態管理系統與運行監控（ASOM）系統中供應管理模塊功能進行重新設計數據整合、梳理，開發出更符合實際業務流程的物資供應管理模塊，實現設備裝備采購、調撥、送修、送檢、啟用、換下、報廢以及消耗全生命周期流程集約化管理；一體化系統實現在計量檢定系統中單點登錄，數據送檢出庫至計量檢定系統，檢定結束將檢定結果同步回一體化系統中對應數據的閉環流程；一體化系統實現在測試維修平臺中單點登錄，數據送修出庫至測試維修平臺，測試維修結束將測試維修結果同步到一體化系統中對應數據的閉環流程；從而省級及省級以下業務人員只需登錄省級裝備保障業務一體化系統中即可進行各大業務操作，不需再登錄4個系統分別操作，實現了省級裝備保障業務的集約化建設，并完成了省級業務流程再造與標準化管理。

主要參考文獻

[1]楊金紅，高玉春，邵楠，等.氣象裝備供應保障管理系統的改進與完善[J].氣象水文海洋儀器，2014（1）.

[2]郎東梅，高玉春，杜建蘋.淺談我國氣象技術裝備物流體系建設的發展[J].氣象水文海洋儀器，2012（3）.

[3]趙偉東，張焱.現代氣象裝備供應保障管理體系建設初探[J].華章，2011（30）.

[4]湯文寧，張大偉.現代氣象裝備供應保障管理體系建設初探[J].氣象水文海洋儀器，2008（4）.endprint