基于MySQL 的空管設備集中監控系統數據庫設計

閆繼正，張 雷，張海濤

（1.中國電子科技集團公司第四十七研究所，沈陽 110000；2.中國人民解放軍 95979 部隊，新泰 271207）

1 引 言

智慧機場是目前機場建設和發展的趨勢。我國機場一般都存在多種相似、相關且互相獨立的系統，彼此數據無法共享，為了打破這種信息孤島的現狀，空管設備集中監控系統應運而生。它是利用系統集成技術、異構數據采集技術、數據庫技術等進行開發的，將民航機場機房中各個獨立的子系統數據采集出來并進行集中處理，從而實現數據存儲、數據回查、數據分析等功能，并為后續的數據融合和數據挖掘提供支持。數據庫作為系統中存儲與查詢數據的中樞，其設計合理與否直接影響系統運行的效果。根據項目需求進行數據庫分析和設計，能夠最大限度利用數據庫的資源，實現最優最快處理數據的目的［1］。

2 數據庫設計需求與選擇

2.1 數據庫設計需求

空管設備監控系統整體流程如圖1 所示。根據被采集設備的不同，采集單元對被采集設備是一對一或一對多的情況。采集單元對設備發送采集命令，將采集到的數據傳輸到Web 服務器；Web 服務器將數據存儲到數據庫中，使查詢歷史數據成為可能。Web 應用程序通過向Web 服務器請求數據，進行數據展示。結合應用情景，對數據庫的設計應包含如下幾方面的基本考量：

圖1 空管設備集中監控系統整體流程圖

1）數據庫存儲條目數量

空管設備監控系統需要采集空管設備和為保障其工作而配備的各種動力環境保障設備的實時數據。以某民航機場機房為例，一個機房可能存在一到兩臺空管設備以及為保障其工作環境所需要的空調、溫濕度計、UPS、電量計等動力環境保障設備，每臺空管設備需要實時監控的數據參數從幾十項到幾百項不等。根據用戶需求的不同，可以對這些參數進行裁剪，只監控部分重要參數。全部動力環境保障設備參數共約一百項，一個民航機場存在多個這樣的機房，一個機場所有設備需要采集的數據在一千項到兩千項左右，歷史數據需要保存一年。由于每次僅需存儲發生變化的參數，而所有被采集設備有一半的參數為狀態量，基本不變，另外大部分參數也很少變化，因而數據存儲數量不是特別巨大。

2）數據庫存儲頻率

空管設備監控系統采集的空管設備參數的更新頻率均為秒級，動力環境保障設備對于秒級以下的數據更新沒有意義，因而對于數據庫存儲的數據不會太頻繁，實際使用過程中，每10 s、20 s 或更久存儲一次數據庫即可。

2）數據庫工作時間

空管設備監控系統需要長期工作，在工作過程中，數據庫需要高可靠性，不能因為數據庫的宕機而造成巨大損失。

4）數據庫連接實例

空管設備監控系統提供一個連接實例供中心機房使用，提供幾個連接實例供程序調用，所用連接實例數較少。

5）數據庫占用資源

空管設備監控系統是以計算機為處理核心的系統，兼容Windows、Linux 操作系統，在使用數據庫時，數據庫需要盡可能少地占用資源。

2.2 數據庫選擇

綜合來看，空管設備監控系統所需數據庫體量中等，同一時間存取數據量中等，存取時間間隔足夠，需要穩定運行。在滿足這些需求的同時，為進一步應對商業化需求，數據庫選擇要能夠盡可能縮短開發周期，減少開發成本，簡單易用，最好為開源。

結合以上數據庫需求，系統選取以高效、簡潔、可靠性高著稱的免費開源MySQL 數據庫進行開發設計，MySQL 數據庫支持標準化SQL 查詢語言，能夠實現高速存儲數據，同時支持線程池，能夠在充分利用硬件資源的情況下，應對大量的并發請求［2-4］。

3 數據庫設計

結合項目需求分析與空管設備監控系統布置進行系統總體功能設計，系統功能模塊示意圖如圖2所示。

圖2 空管設備集中監控系統功能模塊示意圖

3.1 E-R 圖

根據系統功能需要，對所有必要信息進行分類整理，建立機場、臺站、設備、參數、數據、人員的ER 圖，如圖2 所示。

圖3 系統各實體E-R 圖

根據各E-R 圖與兩兩實體之間的關系，整理可得系統總的E-R 圖如圖4 所示。

圖4 系統整體E-R 圖

3.2 數據庫表設計

根據E-R 圖的理論設計，結合機場實際情況與使用便利性進行分析，建立系統數據庫。系統包括的數據庫表及詳細用途如下：

（1） 機場地區信息表

用于存儲機場所在的地區信息，實現區分各地區機場的目的。包括地區編碼和地區名稱。設計結構要求如表1 所示。

表1 機場地區信息表格式

（2） 機場臺站信息表

用于存儲同一機場不同臺站的基本信息，實現區分同一機場各臺站的目的。包括地區編碼、臺站編碼和臺站名稱。設計結構要求如表2 所示。

表2 機場臺站信息表格式

（2） 臺站設備信息表

用于存儲同一臺站不同設備的基本信息，實現區分同一臺站各設備及配置通信的目的。包括臺站編碼、設備編碼、設備本地編碼、設備名稱、通信方式、配置信息、端口狀態。設計結構要求如表2 所示。

表3 臺站設備信息表格式

（4） 設備本地表

用于實現設備編號與被采集設備實際信息實現一一對應的目的。包括設備本地編碼、設備本地名稱、設備所屬分類、設備所屬子分類、設備供應商、設備型號。設計結構要求如表4 所示。

表4 設備本地表格式

（5） 設備參數表

用于讀取和識別每臺設備所需要采集和記錄數據的參數信息。包括設備本地編碼、參數編碼、參數類型、參數中文名、參數英文名、參數單位、參數精度、參數Warning 和Alarm 的上下限、參數組別、參數含義、備注。設計結構要求如表5 所示。

表5 設備參數表格式

（6） 歷史數據表

用于存儲每臺設備所需要采集的數據歷史值，方便進行備份和歷史回查。包括數據序號、采集時間、設備編碼、參數編碼、數值。設計結構要求如表6所示。

表6 歷史數據表格式

（7） 實時數據表

用于存儲每臺設備所需要采集的數據的實時值，隨著采集數據的變化而不斷更新，實現隨時查看被采集設備最新狀態的目的。包括數據序號、采集時間、設備編碼、參數編碼、數值。設計結構要求如表7 所示。

表7 實時數據表格式

（8） 告警信息表

用于存儲每臺設備所需采集的數據發生的告警記錄，便于分析和查看。包括數據序號、采集時間、設備編碼、參數編碼、數值、告警級別。設計結構要求如表8 所示。

表8 告警信息表格式

（9） 人員表

用于存儲機場運維人員的信息。包括機場編碼、人員編碼、姓名、性別。設計結構要求如表9 所示。

表9 人員表格式

（10） 事件表

用于存儲設備觸發的事件（開關機、切換機、告警、維護等）、人員處置的事件（消除告警、維修、遙控、生成報表、巡檢等）、系統事件（斷線、損壞、故障等）。包括序號、設備編碼、發生時間、事件內容。設計結構要求如表10 所示。

表10 事件表格式

由于使用MySQL 自帶調試窗口進行數據庫建立過于繁瑣，在建立和使用數據庫的過程中使用Navicat 軟件進行數據庫的建立和管理。依據數據庫的各表的設計和實際存儲內容，在建立數據庫時，各表按表1～10 的結構進行建立。其中，歷史數據表按照表6 的結構創建后，由采集程序自動為每個臺站建立一張表，根據采集時間，每月分出一張表［5-6］。

4 效果驗證

為驗證該空管設備集中監控系統數據庫的實用性，在數據庫設計完成后，進行了模擬拷機實驗。實驗環境參照一般支線機場的機房進行配置，分為11個臺站，包含5 臺不同種類型號的空管設備（1 臺GP、1 臺LOC、1 臺VOR、2 臺DME），11 套與各個臺站配套的動力環境監控設備（每套包括2 臺空調、1 臺UPS、1 臺電力表、1 個溫濕度計、2 個水浸傳感器、1個煙霧傳感器、1 個門磁傳感器、1 個紅外傳感器）。

實驗中所有設備的數據均由自行開發的數據模擬軟件生成，模擬數據參照設備實際運行參數范圍，進行小范圍隨機變化，輸出數據至空管設備集中監控系統，空管設備的監控參數條目按照最大條目進行模擬，所有設備數據總量在一千條以上。系統實際工作時數據存儲間隔為10s 或更長。

為更好地檢驗數據庫工作能力，模擬拷機實驗時將存儲間隔設置為1 s，運行一天后，各臺站歷史表的數據量最多約為100 萬條（包括空管設備下滑、航向的臺站）和20 萬條（僅有動環設備的臺站）左右。模擬拷機實驗共進行26 天，中間自然時間跨月，歷史表進行了分表。實驗結束后，每個臺站有兩張表，數據總量約為2500 萬條（包括空管設備的臺站）和1000 萬條（僅有動環設備的臺站）左右，數據量約為所有設備滿參數實際工作一年的總量［7-8］。

由于在數十倍于實際工作環境的條件下進行實驗，造成單張表數據量達千萬以上，在系統軟件進行歷史數據回查時會有延遲；當實驗進行至2～4 天時，數據庫中單表的數據量已經遠超過了實際工作時單表的最大數據量，此時系統軟件進行數據回查操作時，數據庫響應良好。經過模擬拷機實驗，數據庫仍然工作良好，證明此數據庫設計方案可行。

5 結 束 語

空管設備集中監控系統在進行數據庫需求分析后，選擇了高效、簡潔、體量較小的MySQL 數據庫。在進行E-R 分析后，結合實際情況設計并建立了切實可行的數據庫。設計完成后進行了模擬拷機實驗，驗證了數據庫的性能。該數據庫系統在設計并研制完成后，已經用于多家機場的集中監控領域，取得了良好的效果。