基于MySQL 的空管設備集中監(jiān)控系統(tǒng)數(shù)據(jù)庫設計

閆繼正，張 雷，張海濤

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

1 引 言

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

2 數(shù)據(jù)庫設計需求與選擇

2.1 數(shù)據(jù)庫設計需求

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

圖1 空管設備集中監(jiān)控系統(tǒng)整體流程圖

1）數(shù)據(jù)庫存儲條目數(shù)量

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

2）數(shù)據(jù)庫存儲頻率

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

2）數(shù)據(jù)庫工作時間

空管設備監(jiān)控系統(tǒng)需要長期工作，在工作過程中，數(shù)據(jù)庫需要高可靠性，不能因為數(shù)據(jù)庫的宕機而造成巨大損失。

4）數(shù)據(jù)庫連接實例

空管設備監(jiān)控系統(tǒng)提供一個連接實例供中心機房使用，提供幾個連接實例供程序調用，所用連接實例數(shù)較少。

5）數(shù)據(jù)庫占用資源

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

2.2 數(shù)據(jù)庫選擇

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

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

3 數(shù)據(jù)庫設計

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

圖2 空管設備集中監(jiān)控系統(tǒng)功能模塊示意圖

3.1 E-R 圖

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

圖3 系統(tǒng)各實體E-R 圖

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

圖4 系統(tǒng)整體E-R 圖

3.2 數(shù)據(jù)庫表設計

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

（1） 機場地區(qū)信息表

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

表1 機場地區(qū)信息表格式

（2） 機場臺站信息表

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

表2 機場臺站信息表格式

（2） 臺站設備信息表

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

表3 臺站設備信息表格式

（4） 設備本地表

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

表4 設備本地表格式

（5） 設備參數(shù)表

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

表5 設備參數(shù)表格式

（6） 歷史數(shù)據(jù)表

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

表6 歷史數(shù)據(jù)表格式

（7） 實時數(shù)據(jù)表

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

表7 實時數(shù)據(jù)表格式

（8） 告警信息表

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

表8 告警信息表格式

（9） 人員表

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

表9 人員表格式

（10） 事件表

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

表10 事件表格式

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

4 效果驗證

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

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

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

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

5 結 束 語

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