氣象自動觀測集成平臺設計

朱東紅，吳東麗，郭 劍，闕艷紅，劉立業，劉興良，張會可，郭淵杰

?

氣象自動觀測集成平臺設計

朱東紅1，吳東麗2，郭 劍1，闕艷紅1，劉立業1，劉興良1，張會可1，郭淵杰1

（1. 中國電子科技集團公司第27研究所，河南 鄭州 450000；2. 中國氣象局氣象探測中心，北京 100081）

由于不同氣象設備數據通信協議多樣化，且氣象業務觀測要素越來越多樣化、定制化，導致每新增一種新的業務觀測，相配套的軟件從通信、應用、存儲等都需要重新設計開發，這導致了很多重復開發，造成了資源的浪費。氣象自動觀測集成平臺致力于解決不同氣象儀器廠商、不同設備間的通信協議解析、適配問題；統一設計RESTful API數據接口，為平臺上層定制化的業務應用提供有力支撐；在軟件邏輯層面實現觀測業務可定制。平臺軟件擬采用敏捷開發方法，平臺在構建初期被合理切分為多個子模塊，各個子模塊都經過測試，具備可視、可集成和可獨立運行使用的特征。經測試試用，本平臺能夠兼容、接入多種氣象觀測設備，真正實現了專業氣象領域業務軟件的集約化，大大提高了開發和交付效率。

氣象；適配；定制；集成

0 引言

隨著科技的日新月異，許多新型儀器設備進入氣象領域，越來越多的氣象業務實現了自動化觀測。然而，這些新增的觀測系統均獨立運行，通常是每新建設一種業務，就增加一套中心站軟件和應用軟件，造成了現有氣象信息中心服務器使用效率低、觀測數據重復、混亂、集約化程度低等問題，維護這些軟件及數據需要耗費大量的人力資源。并且原有業務軟件系統擴展性差，設備通信協議多種多樣，數據質量系統控制不夠完善，存儲系統雖然積累了大量氣象歷史數據，但各為系統，數據價值挖掘能力不足[1]。隨著業務系統不斷增多，值班人員工作量也將不斷增加。因此迫切需要針對現有的氣象觀測系統進行集成與管理。

針對上述問題及不斷發展的氣象觀測業務需求，平臺將致力于實現觀測業務運行集約化[2]，開發涵蓋觀測數據采集、質量控制、數據傳輸、觀測產品制作和運行狀態監控、設備故障遠程診斷等各類業務及管理信息的綜合氣象觀測業務一體化平臺，實現實時監控、考核評估綜合氣象觀測業務運行狀況、實時數據質量控制、設備故障遠程診斷或人工指導下的故障診斷維修、觀測產品快速制作等功能，全面提高業務觀測管控水平。

本文從平臺技術架構、技術選型、關鍵數據與存儲結構、平臺數據處理流程、基于本平臺的應用示例等方面進行詳細闡述。

1 平臺技術架構

1.1 總體架構

圖1為氣象自動觀測集成平臺（以下簡稱平臺）總體架構圖，平臺為基于B/S結構的上層應用提供定制化的數據服務接口，其主要由數據收集與協議適配、消息中間件、中心站、后臺管理、數據訪問接口、緩存和數據存儲等模塊組成。數據收集與協議適配模塊負責接收解析遠程設備上傳的觀測數據，消息生產、命令調試和鏈路管理。數據接收與解析：為不同的協議（設備）開發其專屬的解析動態庫（DLL），以插件的形式進行統一管理，對新設備的接入只需提供協議動態庫或者按照指定格式生成數據文件即可。消息生產：對消息中間件來說該模塊為消息生產者（Message Producer）,對解析后的觀測數據，按照平臺內部的統一的數據交換格式，生產一條消息推送到消息中間件的消息隊列（Message Queue）以供中心站消費[3]。命令調試:為前端（上層應用）發出的設備調試命令提供雙向透明通道。鏈路管理：該模塊設計為能夠接入5000個設備，對每個設備的上線、離線等行為進行實時監視，為每個設備提供一條高效的通信鏈路。消息中間件模塊是數據收集與協議適配模塊和中心站模塊間的通信手段，其內部以先進先出（FIFO）的隊列數據結構作為通信載體，同時它提供多種消息模式以供選擇，并能夠通過簡單配置使消息數據定時持久化到磁盤。中心站模塊主要負責消息消費、質量控制、產品生成和推送。消息消費：對消息中間件來說中心站為消息消費者（Message Consumer），它從消息隊列取出隊頭數據，按照平臺數據規則進行消息數據解析。質量控制：對解析后的數據實施中心站級別的質量控制、輸出入庫。產品生成與推送：按照規定（國家/省級氣象局），定時從數據庫讀取觀測數據，以預定格式生成各種報文文件，通過FTP協議推送到指定服務器。后臺管理模塊負責平臺配置，例如觀測要素指標、用戶權限等。數據訪問接口提供基于用戶名和密碼的登陸認證、權限管理和Restful API數據接口，用戶登陸成功后返回給前端令牌（AccsessToken）以供后期數據請求使用。在數據訪問接口和數據存儲層增加緩存是為了提高接口并發訪問速度，減少磁盤I/O，降低數據庫負載，當用戶發起接口請求時，服務端會首先查詢緩存，如果有所需數據，直接從緩存返回，反之，再查詢數據庫。

圖1 氣象自動觀測集成平臺總體架構

1.2 技術選型

平臺需要實現的主要功能：并行高效應對數以千計的遠程設備突發式數據傳輸問題，為新設備接入提供插件式支持；為上層應用提供Restful API風格的HTTP接口；并提供接口級別的安全訪問控制功能；平臺內部進程間可靠、高效的通信技術。為實現上述功能，平臺主要使用如下技術。

平臺與上層應用、平臺內部數據收集與中心站數據交換均采用JSON格式。JSON（JavaScript Object Notation）是一種獨立于編程語言的數據傳輸格式[4]，它與XML相比具有輕量化、簡潔、層次結構清晰、解析傳輸更加高效等優點。數據收集與協議適配模塊需要較強的處理效率，使用具有面向對象、靈活、執行處理效率高等特點的C++語言來開發。

為實現HTTP接口，平臺數據訪問接口（Web后端）采用Java語言開發、SSH（Spring、SpringMVC、Hibernate）框架。Spring充當容器管理角色，它融合了IoC（Inversion of Control，控制反轉）、DI（Dependency Injection，依賴注入）等重要的編程思想。對于Spring來說，所謂IoC就是由Spring來負責控制對象的生命周期和對象間的關系，所謂DI就是由Spring在程序運行時動態的將某個依賴關系注入到組件中。IoC和DI并非為程序增加了更多功能，而是為了提升組件的可重用性，并為系統搭建一個靈活、可擴展的結構平臺[5]。Hibernate用來做數據持久層，它對JDBC做了良好封裝、對系統沒有侵入性（所謂的輕量級）、提供了一級緩存和二級緩存、擯棄了以數據庫為中心的思想，使得在后端接口開發中能做到完全面向對象[6]。SpringMVC（MVC即Model、View、Controller）是整個平臺后端業務邏輯的核心，其有諸如強大的約定大于配置的契約式編程、與Spring框架集成方便、分層設計、模塊解耦等優點。處理流程為：前端控制器DispatchServlet接收HTTP請求，調用處理器映射器HandlerMapping查找相應的處理器，處理器映射器根據URL查找處理器Handler，并給前端控制器返回生成的處理器和處理器攔截器HandlerIntercepter，前端控制器調用處理器適配器HandlerAdapter，處理器適配器調用相應的處理器，處理器將出路結果以ModelAndView形式返回給處理器適配器，處理器適配器將ModelAndView返回給前端控制器，前端控制器將ModelAndView傳給視圖解析器ViewResolver，視圖解析器將解析后的View返回給前端控制器，經渲染后將模型數據填充到HTTP請求域中返回，至此，一次HTTP請求處理過程結束[7-8]。如下圖2所示：

圖2 SpringMVC執行流程

平臺數據接口安全性包括用戶認證（Authen-tication）和用戶授權（Authorization）。用戶認證是指驗證某個用戶是否為平臺系統中的合法主體，即用戶能否訪問系統；用戶授權是指驗證某個用戶是否有權限執行某個操作。本平臺用戶授權粒度為角色、權限、資源三級，即用戶屬于角色（多對一），角色擁有權限（一對多），權限擁有資源（一對多）。對于以上應用場景，Spring Security框架都有很好的支持，它支持多種主流認證方式，并提供定制化、細粒度的授權控制。其執行流程為：當Web服務器啟動時，加載Spring Security過濾器MySecur?ityFilter，同時為其注入MyInvocationMetadata SourceSe?rvice和MyAccessDecisionManager類，前者在執行時會提取數據庫中預存的用戶權限形成列表，并循環該列表，根據權限獲取對應的資源列表，將資源（URL）作為key，權限列表作為value，形成Map數據結構，當用戶登陸時調用loadUserByUsername方法，認證成功后根據用戶名從數據庫提取該用戶擁有的權限列表（UserDetails）。當用戶請求某個資源（URL）時，觸發MyAccessDecisonManager類，執行其decide方法攔截資源訪問請求，將資源和Map中的key對比，若相同，就提取出對應的value（list），即若要請求這個資源（URL），必須具有跟這個資源相對應的權限值列表（Authorizations），以此Auth?orizations進行循環和UserDetails中的權限進行對比，若有一個（也可多個）相同，即授權通過，返回資源數據，否則終止請求向下傳遞，向用戶返回信息提示未經授權的訪問。如下圖3所示：

圖3 Spring Security執行流程

所謂平臺內部間的進程通信意即數據收集與協議適配端和中心站端的數據交換，為實現此目標，平臺選用Apache下的開源消息總線ActiveMQ。它支持多種語言編寫客戶端，可以很方便的和Spring框架融合，支持諸如in-VM, TCP, SSL, NIO, UDP, JGroups, JXTA多種消息傳輸協議，支持通過JDBC和journal提供高速的消息持久化，可以采用集群部署，避免單點故障，并且用戶社區極為活躍[9]。

使用緩存提高了平臺數據訪問速度，緩存也即內存，平臺使用Redis內存數據庫作為緩存層。Redis的性能極高，其存取復雜度都是O（1），支持豐富的數據類型如String、List、Hash等，所有操作都具有原子性，如果需要，Redis也可以持久化緩存數據[10-12]。

2 數據處理流程

圖4為平臺0層數據流圖，該圖主要包含三個方向的數據流，即數據收集存儲、產品生成和終端用戶數據/命令請求。

圖4 平臺b層數據流

數據收集存儲：通過主動/被動方式獲取傳感數據，解析后封裝成平臺規定的統一消息格式（JSON格式，如{‘key1’:’value1’, …, ’keyn’: ’valuen’}）,然后將數據推送（即入隊）至消息中間件ActiveMQ，ActiveMQ使用消息存儲器kahaDB對消息進行持久化，直到該消息被消費掉（即出隊）。中心站從消息中間件讀取消息，解析數據，對數據施加平臺級質量控制后入庫存儲。另外，數據收集一般要比中心站入庫速度要快（因為中心站入庫涉及磁盤I/O），這容易導致消息消費速度遠遠低于生產速度，加之某些業務系統可能對數據的實時性要求較高，因此，可以運行多個中心站以加快消息被消費處理的速度。

產品生成：中心站根據具體業務需求按時從數據庫讀取觀測數據，按照指定格式生成數據產品（一般指報文）推送至第三方數據中心。

終端用戶數據/命令：1）數據，終端客戶（瀏覽器/桌面應用）向API服務端發送HTTP登陸認證請求，認證成功后服務端按照一定的算法生成AccessToken令牌給終端用戶，終端用戶將攜帶AccessToken（放在HTTP請求頭）進行數據請求，服務端收到請求，取出AccessToken，依據數據庫中的配置，判斷該終端用戶是否有本次數據請求的權限，驗證通過后，服務端先從緩存查找是否有本次請求的數據，如果有，則直接從緩存返回數據，否則，重新去數據庫查詢后將結果返回給終端用戶，同時以本次查詢結果更新緩存，其HTTP請求序列見下圖5。2）命令，命令請求登陸認證與授權同數據請求一樣，區別在于請求到達服務端后命令被轉發至數據收集端，數據收集端根據命令參數再轉發至相應的遠程設備，命令返回后將沿著同樣的通道返回至終端用戶。

圖5 數據請求序列圖

3 關鍵存儲結構

平臺設計的核心思想是盡量避免業務軟件尤其是數據收集、中心站（處理、入庫）軟件的重復開發，提高軟件的可重用性，能夠為上層多種觀測業務提供支撐，并為新的氣象觀測業務提供靈活的接入方式。為實現上述功能，在數據庫中設計以下關鍵表結構。

（1）觀測業務分類表

表1 觀測業務分類示例

Tab.1 Examples of observed business classifications

（2）用戶信息表

表2 用戶信息示例

Tab.2 Sample User Information

（3）觀測要素字典表

表3 觀測要素字典示例

Tab.3 Examples of observational elements dictionaries

（4）觀測業務與觀測要素映射表

表4 觀測業務與觀測要素映射示例

Tab.4 Examples of observation services and observation elements mapping

平臺內部可以定義多種氣象觀測業務，并為每種業務進行編碼和命名（表1）；平臺針對業務類型進行用戶系統隔離（表2），在用戶信息表中增加業務編碼字段與用戶id字段組成該表的聯合主鍵，不同的業務系統可以擁有相同的用戶id；按照氣象觀測要素建立觀測要素字典信息表（表3），該表內容盡可能全面涵蓋各種氣象觀測要素，并對該表定期按需維護以保證其完整性和一致性，表中要素編碼值即為要素在數據庫中存儲時的字段名，為平臺增加新的氣象觀測業務時，只需從該表中選取觀測要素進行組合寫入映射表中（表4），映射表中每條記錄表達了某種觀測業務下擁有的觀測要素信息（存儲時的字段名）和觀測要素的存儲位置信息（字段隸屬的表名），映射關系以JSON字符串形式存儲，數據收集端接收解析設備上傳的數據，按照觀測要素字典信息并附加業務編碼將數據重新封裝、傳輸到中心站端，中心站根據映射表解析數據并入庫。這樣做的好處在于為平臺增加新觀測業務時，只需要通過平臺管理系統進行業務配置，而不必重復開發中心站軟件；對數據收集端只需要知道觀測要素字典（以手冊形式提供）和觀測業務編號加載對應的DLL插件，重用原來的通信架構即可。

4 基于平臺的應用實例

本節通過一個應用實例（新鄭智慧園區數據監控系統）展示平臺如何通過后臺管理接入新的業務系統，并簡單介紹該系統的功能組成。

首先新建新鄭智慧園區數據監控系統，如下圖6，其次為業務系統映射觀測要素集合，即為第3節表4增加記錄。新鄭智慧園區數據監控系統主要包含9個氣象觀測要素數據：空氣溫度、空氣濕度、風速、風向、雨量、輻射、氣壓、土壤濕度、土壤溫度，如下圖7。配置完后，平臺即可收集、處理、存儲該業務系統的觀測數據，而不必重復開發平臺的數據收集與協議適配端和中心站端。

新鄭智慧園區數據監控系統主要包括基于GIS的臺站位置顯示、監控要素實時數據顯示、監控要素歷史數據查詢分析（曲線和表格）、設備故障報警、監控要素數據超限報警等，如下圖8。

5 平臺部署

圖9為平臺部署圖，平臺各個模塊均是基于Windows平臺，各個服務器既可運行在統一局域網內（LAN），也可部署在多個異構網絡環境，通過Internet互相連接通信。其中消息服務器、數據庫服務器、API接口服務器、前端服務器需要Java虛擬機支撐，安裝JDK1.8，中心站軟件采用C#開發，需要安裝.net framework 4.0，緩存服務器安裝Redis4.0.9。

6 結論

本文介紹了開發設計氣象自動觀測集成平臺的必要性和緊迫性，在介紹時側重說明平臺設計的核心思路、整體架構和各個模塊的技術選型，不拘泥于具體的代碼實現。平臺實現了多種業務系統的數據統一收集、質控、存儲，在新業務接入上真正實現了通過后臺簡單配置即可收集、存儲業務數據的功能，避免了功能模塊的重復開發，提高了軟件開發效率，基本達到了當初的設計要求，在實際應用中取得了不錯的效果。

圖6 平臺后臺管理系統

圖7 業務映射

圖8 新鄭智慧園區數據監控系統

下一步的工作，將對平臺進行優化，同時從硬件、軟件方面實現平臺訪問的高并發性、平臺數據的高可用性，為上層定制化的應用系統提供穩定、高效的數據與接口支撐。同時，也為以后打造氣象觀測領域專用云平臺做一次探索和技術積淀。

圖9 平臺部署

[1] 中國氣象局, 氣象信息化發展規劃(2018-2022年)[Z]. 2017.

[2] 中國氣象局, 綜合氣象業務發展規劃(2016-2020年)[Z]. 2017.

[3] 馮雪, 孫丙宇, 方薇, 吳斌. 基于物聯網的電梯安管系統通信模塊[J]. 計算機系統應用, 2017, 26(4): 210-211.

[4] Bassett, L. 魏嘉汛譯. JSON必知必會[M]. 北京: 人民郵電出版社, 2016.

[5] Walls, C. 張衛濱譯.Spring實戰(第4版)[M]. 北京: 人民郵電出版社, 2016.

[6] Bauer, C. &G.King. 楊春花, 彭永康, 俞黎敏譯. Hibernate實戰(第二版)[M]. 北京: 人民郵電出版社, 2008.

[7] Warin, G. 張衛濱, 孫麗文譯. 精通Spring MVC 4[M]. 北京: 人民郵電出版社, 2017.

[8] 韓凌波. 基于mvc架構的普法考試系統設計與實現[J]. 軟件, 2015, 36(3): 132-133.

[9] 錢崢, 胡亞旦, 黃旋旋. 基于“消息中間件”技術的氣象信息總線[J]. 氣象科技, 2016, 44(2): 217-218.

[10] 程晗, 汪學明, 等. 基于Redis的海量智慧醫療小文件存儲架構設計[J]. 計算機應用與軟件, 2018, 35(4):87.

[11] 李鵬鵬, 鄭揚飛, 劉玉龍. Redis在即時通訊系統中的應用[J]. 軟件, 2017, 38(1): 115-116.

[12] 伍紹佳, 杜林, 廖麗. 基于云平臺的數字化校園信息門戶系統實踐研究[J]. 軟件, 2017, 38(1): 31-32.

Design of Integrated Platform for Meteorological Automatic Observation

ZHU Dong-hong1, WU Dong-li2, GUO Jian1, QUE Yan-hong1, LIU Li-ye1, LIU Xing-liang1, ZHANG Hui-ke1, GUO Yuan-jie1

(1. CETC27, Zhengzhou 450000, China; 2. Meteorological observation center of China Meteorological Administration, Beijing 100081, China)

Due to the diversity of data communication protocols of different meteorological equipments, and the more and more diverse and customized meteorological service observation elements, each new kind of business observation is needed, and the corresponding software needs to be redesigned and developed from communication, business application and storage, which leads to many repetitive development, which causes the waste of resources. The specialized Meteorological automatic observation integrated platform is devoted to solve the communication protocol parsing and matching problems between different meteorological instruments manufacturers and different equipments, unify the design of RESTful API data interface, provide strong support for the customized business application above the platform, and make the observation service in the software logic level customizable. The platform software is to adopt Agile development method, the platform is divided into several sub modules in the early stage of construction, each sub module has been tested, and has the characteristics of visualization, integration and independent operation. After testing, the platform can be compatible, access to a variety of meteorological observation equipment, truly realize the professional meteorological business software intensification, greatly improve the development and delivery efficiency.

Meteorological; Matching; Customizable; Integration

TP311. 52

A

10.3969/j.issn.1003-6970.2018.07.039

朱東紅(1986-)，男，工程師，主要研究方向：分布式計算；吳東麗(1977-)，女，副研究員，主要研究方向：農業氣象觀測和農業氣象災害風險評估；郭劍(1986-)，男，工程師，主要研究方向：地理信息系統；闕艷紅(1986-)，女，工程師，主要研究方向：控制工程；劉立業(1992-)，男，工程師，主要研究方向：自動化；劉興良(1995-)，男，工程師，主要研究方向：軟件工程；張會可(1990-)，女，工程師，主要研究方向：電子與通信工程；郭淵杰(1984-)，男，工程師，主要研究方向：嵌入式系統。

本文著錄格式：朱東紅，吳東麗，郭劍，等. 氣象自動觀測集成平臺設計[J]. 軟件，2018，39（7）：182-190