基于C/B/S參與感知氣象服務系統的研究與設計

邱忠洋，雷正翠，蔣 駿

(常州市氣象局，江蘇 常州 213000)

0 引 言

2016年底的中國氣象局發布了《關于發展智慧氣象的若干思考》一文，文章高度重視并關注“智慧氣象”的戰略研究，闡述了智慧氣象的內涵和特征，提出了發展智慧氣象的三大戰略——氣象大數據戰略、“互聯網氣象+”戰略和氣象平臺戰略，初步確立了2020年的發展目標和重點任務[1]。智慧氣象是不斷發展的動態過程，需要用新趨勢新方向引領智慧氣象的發展。智慧氣象的成果需要具備智能化、可配置、可評價、可感知的概念。

隨著科技的發展，移動設備上集成了許多傳感器，數據處理能力增強，使得移動設備可以集通信、計算、感知一體的新型傳感器節點，一系列的感知模式應運而生，參與感知就是其中之一。國外加州大學的Deborah Estrin教授對于參與感知有這樣的定義：“參與感知是這樣一個過程：在感知過程中，個體或群體使用功能越來越強大的移動手機和云端服務器來收集和分析語義信息”[2]。實際意思就是通過收集和分析個人和群體的各種行為所產生的數據，通過研究大量的個性數據得出相關的結論，研究方法多樣，最主要是強調了人的參與，而分析的結果也跟參與的人群的數量成正比。

在國內，傳統的天氣預報主要依托于數值預報產品，而氣象要素數據的獲取也基本來源于定位式的氣象自動站，雖然相比較于早期經驗式的預報模式，預報準確性有了很大的提高。但是預報的精細化程度和準確率還是達不到個性化人群的需求。如果將參與感知融合到氣象預報中來，也就是將用戶作為模擬移動的自動站，將參與采集的相關氣象數據通過手機上傳至感知數據庫，與傳統的氣象數據進行融合處理。必定會提高氣象預報的精細化和準確性。

該文主要從參與感知的概念、感知數據的處理、原型系統的框架設計等幾個方面進行了闡述。通過實踐證明系統應用是可行的、有效的。

1 關鍵要點

1.1 參與感知

1.1.1 參與感知

參與式感知最早起源于無線傳感網絡(wireless sensor networks)的興起，傳感網絡可以利用多種傳感器為生物追蹤、環境監測以及災難預測等科研活動提供大量實時、全方位、多層次的觀測數據[3]。通過各種不同的無線傳感器建立一個交互式的、參與式的傳感器網絡集群。而這個網絡集群則是由多種不同類型的信息傳感器節點組成，每個節點都可以自主地采集信息，數據通過多跳路由發送到匯集節點(sink node)，匯聚節點將采集到的數據通過TCP/IP網絡協議或者無線方式(WIFI、GPRS、GSM)發送到遠程終端，由終端服務器對上傳的數據進行解析、融合、存儲，并實時維持與終端用戶的通信。

1.1.2 氣象參與感知模型構建

目前依托參與感知所構建的模型比較多，比如伯克利大學的Common Sense Project[4]就是參與感知在城市空氣質量監測的應用，系統的感知設備被部署在了車輛、街頭以及人們正常使用的移動設備中，可以搜集多種帶有標簽的數據比如溫度、二氧化碳濃度等，再以短信的方式上傳，最后由系統對這些數據進行分析和可視化展示。

該文以氣象參與感知網絡構建為例，移動設備為氣象感知提供了溫度傳感器、濕度傳感器、壓強傳感器、風向傳感器等。當然除了智能手機以外還有手環、PDA、平板等，也都可以實現對不同定位的感知數據獲取和上傳。這種非定位的數據獲取為感知數據的采集提供了大量的數據樣本資源，對數據分析的準確性提供了支撐。當前參與感知氣象服務客戶端就是將多組氣象傳感數據進行匯聚處理，通過感知數據與自動站數據以及其他數據進行融合，最后將結果反饋給用戶。該文所研究的氣象參與感知網絡結構強調了人的作用，通過人為手持移動設備接受任務組件可以互動的參與式感知網絡來方便地收集、分析和共享氣象信息。在整個感知網絡中感知節點最重要的是用戶的移動設備，所以在該系統中不存在自上而下的節點控制，而是由設備擁有者控制，隨其移動而移動。系統框架結構如圖1所示。

圖1 系統框架結構

1.2 氣象數據

1.2.1 氣象數據的特點

氣象數據種類繁多，對數據的實時性要求高。按照類型可以分為常規和非常規觀測資料。比如基本站資料(溫度、濕度、氣壓、風速、風向)等屬于常規天氣資料，非常規特殊天氣資料包括加密自動站、探空、雷達、風廓線雷達、衛星等。氣象資料具有連續性，時序性極強，對于這些數據的采集都是按照時間順序進行存儲，計算，統計，整理和保存的。同時氣象資料還具有一定的規律性，表現在資料的周期性強，無論是多年長系列，還是年內、季節內、月內等系列，都有一定的周期性[5]。由于數據具有不確定性和復雜性，導致對氣象資料的研究一直是氣象科研工作的重中之重，外加天氣系統的混沌本質和預報本身存在的不確定性，導致天氣預報想大幅提高預報準確率變得十分困難。

1.2.2 感知氣象數據庫

為統一對各種氣象數據進行處理，提出建立感知氣象數據庫(數據庫結構見圖2)。感知氣象數據庫處理的對象包含了多種氣象數據，比如傳統基本自動站的數據、各種戶外傳感器采集來的感知數據、衛星云圖數據、雷達圖數據、智能終端反饋數據、客戶端提供的天氣現象描述、災情直報、圖片上傳等。 因此在對數據庫進行設計時，需盡量讓數據表具備完整性、可拓展性、獨立性、共享性、安全性、可控性、規范性和統一性。

圖2 數據庫結構

感知數據庫主要用于存儲兩個方面的數據，一是元數據，也就是原始數據，即未經處理的一手數據；這樣做的好處在于能夠保證原始數據的真實性和獨立性，為二次使用提供元數據基礎，比如樣本研究、數據挖掘等。二是將元數據經過質控，融合之后的數據。經過融合處理的數據可直接推送給用戶指導決策，其數據的普適性和靈活性較強，也可為其他行業提供接口服務，使用將十分廣泛[6-8]。

在數據庫的數據處理和存儲過程中，對感知數據去偽存真、去粗取精，不被低質量的數據所蒙蔽，讓精煉后的數據可以高精度地反映物理世界，將成為提升參與感知質量的重要一環[9]。

1.3 C/B/S 模式

感知數據的采集、分析、融合、入庫采用了C/S模式(Client/Server)這種軟件系統體系結構，通過客戶端、服務器、數據庫三級模式，將感知數據的接收定位在了服務器上，而業務邏輯的處理，包括解碼、質控、融合、入庫放在了客戶端。這種開發方式合理分配了Client端和Server端的任務，降低了系統的通訊開銷。該模式下系統開發的靈活性、安全性、可拓展性得到了保障，系統維護也比較方便。服務器與數據庫進行交互，通過網間通信與客戶端就可以進行互動[10]。

在數據的推送、反饋、展示方面系統采用了B/S模式(Browser/Server)，手持終端通過Post/Get方式向服務器發送請求，服務器則是通過API接口的方式響應請求，提供服務，反饋數據。這種在規則下的API接口可以提供給眾多其他應用，適用性極強，包括WEB、App、Wechat等。

C/B/S混合模式框架如圖3所示。

圖3 C/B/S 混合模式框架

2 參與感知氣象服務客戶端總體框架的設計

2.1 新型參與感知預報模式

現行預報模式，預報員根據各種氣象觀測資料(自動站、云圖、雷達數據等)進行研究分析，結合各種數值預報產品做出預報結論[11]。再以各種媒體渠道(電視、廣播、LED、QQ、微信、微博等)將數據推送給決策機構和用戶。而在面對用戶個性化的需求，如何給這些用戶提供不同的應對措施方面關注度并不到位。這是氣象部門科研發展遇到的瓶頸問題之一。當然目前很多非氣象部門已經在研究個性化服務，比如彩云天氣、墨跡天氣等。

新型參與式感知的預報模型則是在現有預報模式的基礎上增加了以人為導向的需求。通過用戶自身的參與，將天氣實況和自身的需求共享，有助于預報工作的及時訂正，還可以為用戶提供可靠的預警預報服務和應對策略。如果參與的人員足夠得多，數據樣本將足夠得豐富，這對于氣象深度挖掘具有十分重要的作用。無疑將推動氣象預報的進一步發展。

2.2 模型構建

在模型構建方面，主要還是參考氣象行業當前的數據處理流程，加上對感知網絡架構的研究，總體來看主要分為如下四個層級(見圖4)：數據感知層、數據匯聚傳輸層、服務器層、應用層[12-13]。

圖4 參與感知框架

數據感知層：感知層主要包括兩個方面，一是傳感器設備層，二是移動便攜式感知終端。傳感器層主要是數據采集所使用的sensor節點群集。采集的參數類型豐富，如溫度、濕度、壓強、風速、風向、雨量等。而便攜式感知終端則主要以無線傳感設備為主，比如手機、PAD、手環、筆記本電腦等。感知網絡以氣象信息為主，另外通過ZIGBEE、RFID等相關感知技術獲取周邊氣象信息。

數據匯聚傳輸層：數據經過匯聚通過網絡協議上傳，網絡結構基本與現行的網絡通信結構無縫對接，完全實現了氣象數據傳輸通信的順暢和共享。而在小型網絡內部，傳輸協議需要握手協定，比如WiFi、藍牙、紅外線等。將數據以協議的方式上傳至服務器，這種方式有利于保障數據的安全性。

服務器層：服務器層主要是將數據匯聚層的數據進行收集、整理和加工。在該層接收的數據類型繁多，如傳統臺站txt報文，衛星云圖，雷達，用戶上傳的文字、圖片等。接下來由服務器端的C/S架構的程序對數據進行解碼、質控、融合計算及入庫存儲。融合計算工作是該層工作的核心部分。最后一步就是數據的服務了，服務器層提供了API服務功能，包括服務注冊、服務發布、服務組合、服務調度，為應用層提供了多樣化的服務基礎。

應用層：應用層主要對接服務器層提供的各種服務接口，可以將處理后的氣象數據信息以web、mobile phone、computer、email、LED等多種方式向外廣播發送，發布的渠道多樣化。而實際的產品信息包括了氣象個性化服務、環境監控、災害氣象預報等，可以以反饋的形式傳遞至感知節點，為用戶提供切實有效的應對指導措施。

3 軟件框架設計

3.1 軟件數據流

實際軟件研發過程中，對涉及到的數據流進行了模塊化劃分，主要就是數據源模塊、數據處理模塊、提供的服務模塊以及應用模塊(見圖5)。

圖5 數據流圖

數據源模塊重點研究感知數據的處理，每一臺移動智能設備都有固定的物理標識，以此獲取其定位以及設備所覆蓋的周邊實時有效的氣象信息。數據采集之后有一個自檢的過程，合格的數據將進行進一步的整理。整理之后的數據進入數據處理模塊，在數據處理模塊中首先是對數據接收，之后進行分類、解碼、質量控制，再進行融合分級、評估鑒定，最后再作存儲入庫。入庫后的數據進入服務模塊，該模塊主要就是調用數據提供服務注冊，經過實際注冊并通過驗證的用戶才可以使用該服務。保證了數據的安全性，該模塊為實際應用提供API接口服務。這一平臺的設計使用了Restful輕量級框架。當數據進入應用模塊時，數據則是以圖形化的方式展示出來，包括天氣預報、個人專業服務、公共服務等。

與此同時，數據也將反饋給上傳數據智能的終端節點，為這些用戶提供專業的服務和應對措施。在數據流中，最為重要的是數據融合，融合的原因是氣象數據的復雜量大，融合的目的是通過一系列大數據處理的手段將數據質量提高，使信息協調優化便于理解和接受。

目前研究融合主要分兩個步驟，一級融合就是簡單的將感知數據入庫，與基礎數據實現數據級別融合。二是與雷達回波、衛星云圖的特征進行融合，也就是結合雷達回波所觀測到的空間雨區分布和云圖觀測到的云系特征，綜合判定天氣狀況，過程之中通過GIS空間插值、數據挖掘算法訓練海量數據，提高短時臨近數據的準確性和穩定性[14-15]。在做預報結論之前還參考了中國天氣通、彩云天氣等相關成熟產品。

3.2 軟件平臺設計

就框架設計而言，系統包含了兩個方面的內容，數據處理下的融合入庫系統(C/S架構)，數據調用平臺系統(B/S架構)。

平臺基于前期數據處理的穩定性和復雜性考慮采用C/S架構模式，在該架構下采用了多線程的操作方式，將繁雜多樣的氣象數據解析融合入庫歸納到各自的線程中。主要包括了主線程、讀寫線程、解析線程以及入庫線程。主線程主要進行數據報文文件的預處理及掃描定時器的設定，并啟動寫線程，讀寫線程被啟動后，則進行數據文件的讀取，文件辨別，接著進行文件分類，分類完畢則進入解析線程。解析線程則是對文件進行讀取截取字段，提取各個要素值，接著調用各種質控方法對數據進行質量控制、數據分析、劃分數據等級，最后則是調用入庫線程，執行寫的操作并寫日志保存。所有操作完成之后將結果向主線程反饋。在此過程中逐漸形成感知數據庫模型的數據基礎，為接下來的數據訪問提供了數據基礎。

調用平臺采用了B/S模式，模式的好處在于可以隨時隨地進行查詢和瀏覽數據。業務拓展簡單，通過添加網頁即可添加服務器功能，數據以接口的方式存在，其共享性能十分強大。具體流程，首先需要初始化頁面和相關接口。初始化接口如果連接不上則繼續發送請求，已連接則進入數據處理階段，調用已寫好的數據庫服務API，系統后臺使用了mybatis框架作為后臺數據處理服務架構。

前端訪問通過線程頁面發送請求，返回的響應來自三個方面，一是直接啟動數據接口進入數據處理模塊，由數據處理模塊將用戶所需要的數據反饋給頁面。二是通過服務接收線程發送請求，由該線程推給API server，之后反饋數據，這是基于用戶請求會發生變化的前提下進行的，可在此流程中更新數據接口。三是用戶直接與接口溝通，發送請求返回數據。所有流程完成之后將結果反饋給參與體驗的用戶[16-18]。從具體應用的角度出發，服務可以涵蓋例如app、wechat、微博、網站等各項不同的應用。軟件架構流圖如圖6所示。

4 運行效果與分析

4.1 系統運行環境

系統已有原型，系統的開發環境主要分為兩個方面，C/S客戶端采用.NET技術，C#語言進行開發，后臺使用了Oracle作為同步數據庫。B/S系統采用了JAVA語言、JavaScript技術和數據服務mybatis框架同步編程，同時結合Oracle數據庫來存儲數據。APP采用了當前較為成熟的Vue.js技術、elementUi技術、Mysql數據庫技術以及Mybatis后臺框架技術等。系統運行于Windows及Linux服務器，兼容性良好。這些技術的應用可以解決系統實施中在技術上存在的基本問題。

4.2 運行結果及效果分析

該系統主要由三個子系統組成，包括參與感知氣象信息演示系統、參與感知數據采集及反饋APP、預報氣象要素解析入庫系統。經過一個月的試運行，實際采集數據24萬余條，反饋數據6萬余條，經過與實況數據的對比，系統的反饋對于預報的調整有著比較有效的指導價值。在技術層面，系統實際運行效果良好，系統壓力測試性能良好。對子系統各模塊的優化分析讓系統在建設過程中思路清晰，系統的數據處理的性能和展示性能變得更加實用，響應速度變快。軟件可擴展性更強。

目前系統已形成原型，但是如何進一步提高數據的精確度，從而更好地為公眾提供精細化服務，還需要進一步研究和探索。

5 結束語

參與感知概念的提出，是基于公眾的力量。一個重要的概念“眾包”，將本來應該由特定人員完成的任務，交給了非特定自由人員來自愿完成，這種建模來源于大型互聯網網絡研究。該文提出的參與感知與氣象預報結合的業務，就是將無所動態的人員當成氣象數據傳輸的自動站，可以實時傳遞相關氣象信息，再結合的傳統自動站數據、衛星云圖、雷達圖等數據融合處理。預報精細化程度得到明顯提高。

文章重點描述了參與感知的模型建立、感知數據庫的構建、軟件數據流、軟件架構整體設計這幾個方面。

軟件的優點在于：

①研究用戶的反饋和對氣象信息的需求，針對這些需求做預報和應急方案，針對性較強；

②系統采用C/B/S混合模式進行開發，各功能進行了模塊化的設計，便于系統的擴展；

③將參與感知的概念引入氣象預警預報工作中，這一設想為今后預報工作提出了新的思路。

系統在研發過程中，除了借鑒了當前比較成熟的傳感器技術、通信技術、數據庫技術等，還有一些需要實際解決的問題。比如感知數據的接收、分類、解碼、入庫，海量數據的處理，在質控和融合方面各種算法研究。這些技術的集中應用，有效地提高了預報的精細化程度，能夠為用戶提供專業的服務和有效的措施。該文在參與感知與氣象系統結合方面的確取得了進展。但是目前系統工作仍存在著不足，如系統還沒有完善、算法研究不精細等。在接下來的研究中，將逐步優化各模塊的設計，進一步深化算法研究，在保證系統高性能運行的同時不斷集成更多的功能。