湖南省區域站站點信息管理系統設計

潘翔宇 呂冠儒 黎澤勛

摘 要：針對湖南省區域氣象自動站站點信息管理混亂的情況，用IntelliJ IDEA作為開發工具，采用b/s的數據結構，以組件化、平臺化的開放性技術理念，設計一套實用可靠的區域站站點信息管理系統，以信息化技術手段實現區域站站點信息的規范化管理，為設備運維和業務發展提供準確的站點信息支撐，具有很強的實用性。

關鍵詞：信息管理系統；區域自動氣象站；數據表設計

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1671-2064（2018）22-0034-02

湖南省氣象局已完成了省級區域中心站地面氣象觀測監控管理平臺的建設，數據傳輸流程由“站-市-省”三級結構變成了“站-省”兩級結構，提升了傳輸時效，減少了市級運維人員的壓力，也對臺站信息準確性等支撐能力提出了更高的要求。然而我省區域站個數多、品牌雜、變動大，站點信息管理較為混亂，已經無法滿足業務運行和發展要求，如何獲取準確的站點信息，為設備運維和業務發展提供更好的保障，是一個值得研究的課題。針對本省實際情況，開發一套區域站站點信息管理系統，通過信息化手段實現臺站設備信息的規范化管理，具有很強的實用性。

1 功能設計

1.1 總體功能設計

系統基于網頁應用的方式設計，對接納入本省氣象內網平臺進行使用，工作人員通過一個界面就能完成區域站業務全流程覆蓋，包括站點狀態監控和資料的應用等，系統將按照管理職能，建立相應權限的3類賬戶，基層臺站賬戶、業務管理賬戶、系統運維賬戶。

（1）系統運維賬戶：該賬戶主要提供給系統運維人員（湖南省氣象信息中心）使用，完成系統的運維管理，包含創建和刪除各類型用戶賬戶、查詢和導出臺站信息、日志管理等系統運維相關功能。

（2）業務管理賬戶：該賬戶主要提供給省級業務管理機構（省氣象局觀網處）使用，完成全省站點信息的業務管理，包含審核基層臺站賬戶提交的站點信息修改申請，完成站點信息的更新錄入，查詢和導出站點信息，查看站點更改記錄等。

（3）基層臺站賬戶：該賬戶主要提供給市（州）級業務管理機構（各市（州）局業務科）使用，完成本市站點信息的業務管理，包括提交站點信息更改申請，查詢和導出站點信息，查看站點更改記錄等。

1.2 工作流程設計

系統主要工作流程如圖1所示，主要由基層臺站賬戶提交站點信息變更申請，業務管理賬戶收到申請后對相關信息進行審核，并將審核結果反饋給基層臺站賬戶。若審核通過，系統將會通知運維賬戶完成更改信息的錄入，并將結果反饋給相關賬戶；若審核沒通過，更改申請將會被駁回至申請人，不會轉到系統運維賬戶。

業務管理賬戶也能夠直接提出站點信息更改申請，運維賬戶將收到相關信息后，將信息錄入數據庫完成更新，并將結果反饋至業務管理賬戶和基層臺站賬戶。

1.3 功能模塊設計

1.3.1 站點信息要素

站點信息要素的完整性是設計重點，須充分滿足使用要求。系統包括：地市名、縣區名、站名、區站號、站址、考核等級、經度、緯度、觀測站海拔高度（m）、氣壓傳感器距地高度（m）、自動站型號、自動站生產廠商、設備ID號、要素數和內容、供電方式、安裝時間、啟用時間、站址環境。

1.3.2 站點信息查詢

系統支持以臺站號、地市名、站名、設備ID號等要素為檢索內容，進行站點信息查詢，其中業務管理賬戶和系統運維賬戶可以查詢全省的臺站信息，基層臺站賬戶查詢出本市所有臺站的信息[1]。

1.3.3 站點信息審核

審核由行政管理人員操作，如不同意更改申請，系統直接彈出原因反饋窗口，比如不符合實際情況、信息錯誤，其他等選項等，若管理人員在7個工作日內沒有處理更改申請，設定默認結果為“不通過”。

1.3.4 站點信息導出

系統支持導出單個站點或批量站點的臺站信息，格式為標準excel文件，并且按照不同業務系統的要求，生成對應內容的表格。

1.3.5 站點信息“校準”

系統加入了本地化校準的機制，確保信息的準確和規范性，申請人必須準確規范的提交臺站更改信息，否則將會彈出錯誤提示。對于傳感器據地高度，設定閥值為范圍為0.5-5米；對于設備ID號，進行重復性檢查，確保唯一性；對于地市名、縣區名、自動站廠商和型號，采用菜單欄選擇的方式，杜絕人工填寫；對于精度和緯度，地址若不在該縣范圍內（引入GIS模塊審核），將無法提交。

1.3.6 站點信息更改記錄

系統采用“留痕”的設計理念，即每一條修改內容，都會產生修改記錄，確保站點信息管理的嚴謹。主要內容如下：以時間的形式，以列表的形式排序，顯示單個臺站信息更新記錄，并且顯示對應的區站信息，包含申請、審核和更新時間；以時間的形式，以列表的形式，按照修改時間排序，顯示出1年內所有的臺站更改記錄；以時間的形式，以列表的形式排序，顯示出1年內各市（州）氣象局站點信息更改記錄。

2 技術設計

2.1 設計原則

系統按照如下原則進行設計：

（1）全流程管理原則：實現從站點信息錄入，修改，審核的全流程管理。

（2）可追溯原則：站點信息從錄入、修改和審核全流程管理中的站點信息、時間、人員和操作等信息都能夠進行追溯。

（3）開放設計原則：采用組件化、平臺化的開放性結構進行設計，包括開放標準、技術、結構、系統組件和用戶接口等，既保證系統的最大復用能力，又減少了功能擴充的影響，也能夠滿足業務功能擴展要求。

2.2 開發工具

系統采用IntelliJ IDEA作為開發工具，它在業界被公認為最好的java開發工具之一，對比其他流行的開發工具，具有以下的優點：

（1）調試更加方便：在程序調試中，筆者經常需要求一些表達式的值，該工具不僅能夠直觀的顯示表達式的值，還能夠很好地理解可能需要的表達式，并給出的建議參數變量，開發人員直接編輯并能立刻得到這個表達式的值。

（2）開發效率更高：在代碼自動生成和重構方面更加智能，比如生成某個類的測試類，能夠正確的放到test的相應目錄下，并且針對不同的情況給用戶提供最合適的解決方案。

（3）目錄分層少而清：該工具的目錄分層很少，但是卻很清晰，IDE配置的東西都能在Settings下找到，工程的配置也能在Project Settings下找到。

2.3 技術架構

系統采用Velocity+SpringBoot的開發架構，對控制層、服務層、實體層以及數據層進行了封裝。Velocity是一個基于Java的模板引擎，使Web設計人員與Jave程序員的并行工作，在提高工作效率的同時，滿足系統界面操作友好性和可維護性，在以模型-視圖-控制器（MVC）模型開發系統時，網頁設計人員更注重于前端界面程序設計，程序員專注于后臺代碼的編寫。Spring Boot是由Pivotal團隊提供的全新框架，用來簡化新Spring應用的初始搭建以及開發過程。該框架使用了特定的方式來進行配置，從而使開發人員不再需要定義樣板化的配置[2]。

2.4 數據表設計

系統設計3種類型，共計5張表，內容如下：

（1）用戶表（user）：主要是用來進行賬戶管理，分別對應基層臺站賬戶、業務管理賬戶、系統運維賬戶等3類賬戶，其中基層臺站賬戶包含16個用戶，分配給14個市（州）氣象部門。其余業務管理和系統運維只包含1個用戶。

（2）作業表：該表主要包括實時表、歷史表和臺站信息表。實時表主要用于臨時存儲站點申請信息，該表在一般情況下為空，有臺站提出更改申請時，更改消息按隊列排序進入該表，等待進行處理，處理完之后再清空該信息；歷史表主要用來全流程追溯和流痕處理，所有更改過記錄都存入到該表中，該表的內容只進行遞增，具備時間標記等；臺站信息表保存站點信息的最終狀態，除非新增站點，里面的記錄條數保持不變。

（3）同步表：該表按照維護人員要求，導出不同要素內容的excel信息表。

3 結語

該系統的設計完成，為本省區域站業務運維和發展提供了準確的站點信息支撐，其開放式設計為系統二次開發和功能擴展奠定技術框架，以該系統為基礎，我省計劃陸續接入土壤水分、交通站、農氣站等各類型站點，最終實現所有設備信息管理全覆蓋，為全省氣象業務集約化和扁平化發展提供一種實用的管理工具。

參考文獻

[1]馮俐，沙莉，戴軍，李大明.省級區域站設備管理系統設計與實現[J].氣象水文海洋儀器，2011，28（03）：65-67.

[2]王鶴琴，張林靜，朱珍元.基于Spring MVC的后臺管理系統開發研究[J].黃山學院學報，2018，20（03）：18-22.