1.引言

在信息化的時代,構成網絡核心的許多關鍵設備對運行環(huán)境有著十分嚴格的要求,，因而必須按國家相關標準和具體需要建立包含供配電,、UPS,、空調,、消防、保安,、漏水檢測等環(huán)境保障設備的機房系統,。因此，機房系統的可靠與否直接關系到網絡能否正常,、持久,、穩(wěn)定地運行，為此,，我們在吸收先進的監(jiān)控技術的基礎上,，結合機房管理實際情況，設計出了機房環(huán)境設備計算機集中監(jiān)控系統(簡稱機房監(jiān)控系統),。

2.機房監(jiān)控系統的構成

機房監(jiān)控系統由控制器,，前端數據采集傳感器,、讀卡器、電鎖,、門磁,、開門開關和通信管理機、管理主機,、管理軟件等組成,。概括來講，整個機房監(jiān)控系統可劃分為三個部分：控制器,、通信管理機、服務器系統,，構成示意圖如圖1所示,。

圖1 機房監(jiān)控系統構成示意圖

3.通信管理機的任務需求與分類

通信管理機是整個機房監(jiān)控系統的一個輔助設備，它的任務是在脫離服務器的情況下,仍然能夠自行對控制器或稱下位機進行實時的管理與控制,。通信管理機除了完成對下位機的管理與控制外,，還應該可以根據用戶的不同需求,對來自上位機隨時產生的任務進行處理。綜合起來講,通信管理機的任務主要來自三個方面:定時數據采集任務,、上位機下達的任務,、報警任務,下面分別介紹和解釋這三種任務的要求與功能，并簡單敘述硬件資源要求,。

3.1定時數據采集任務

我們假設,，一個通信管理機最多能夠與64個控制器建立聯系。我們很清楚,這64個控制器的情況不會完全相同,，也就是說,，有64個控制器的優(yōu)先級的存在,優(yōu)先級高的,我們要對其進行頻繁數據采集，優(yōu)先級低的,，要適時地進行數據采集,，以提高整個系統的效率。因此,才提出長~短定時數據采集兩個任務,。

3.2上位機下達的任務

3.2.1服務器下達到嵌入式計算機的配置信息

服務器下達的嵌入式計算機配置信息的任務主要有以下三種:根據用戶的要求對定時數據采集時間進行修改,；根據用戶的要求對通信管理機所管理的控制器的信息進行修改9根據用戶的要求對嵌入式計算機的系統參數進行修改。

服務器或控制器的系統升級或是其它情況的改變,，使得通信管理機原有的一些初始化參數不能滿足新的要求,，于是需要對這些參數進行必要的改動。例如,，嵌入式計算機系統時間,、串口通信數據傳輸格式等等。我們還為嵌入式計算機配置了電話號碼,，以備將來擴展功能使用,。

3.2.2服務器下達到下位機的配置信息

服務器對機房的控制與管理,，主要是通過服務器下達給機房的控制信息這一步驟實現的。服務器下達的控制器的配置信息主要有以下幾項內容:對指定的門進行授權;對下位機系統進行校時;對控制器的其他信息的配置,。

對控制器的其它信息的配置9也是對控制器進行管理的一項重要指標,。比如，控制器的報警信息,、電源信息,、濕度信息、溫度信息,、損壞程度信息等的配置,，都是一個控制器能夠正常工作的重要的條件信息。根據不同控制器所處的不同環(huán)境,，我們需要對其環(huán)境信息進行必要的配置,，以便它能夠滿足特殊環(huán)境的需要。

3.2.3主動要求上傳指定控制器的數據采集信息

有時,，在整個機房監(jiān)控系統正常工作的情況下,，用戶終端需要馬上讀取特定門的出入信息以供其它方面的需要，這就要求通信管理機能夠及時地響應這一服務要求,，因此,，通信管理機的設計要能夠根據服務器上位機的要求，主動上傳指定控制器的數據采集信息,。

3.2.4在服務器主動請求的條件下,，與指定控制器建立聯系，對其進行實時的控制與修改

在特殊的情況下9或是在比較重要的場合,，對于比較重要的地點的門進行實時的控制與管理是十分必要的,。如果僅僅是一般意義上的數據采集上傳，再對其進行修改授權,，將不能滿足特殊條件下用戶對門的控制的特殊要求,。因此，通信管理機的這一任務的設計是必不可少的,。

3.3報警的任務

報警是任何系統設計所不可缺少的一個重要組成部分,。同樣，報警在機房監(jiān)控系統中,，也是十分重要的,。通信管理機的報警任務主要來自以下幾個方面:通信超時報警;通信故障報警;控制器的故障信息報警(包括配電系統的報警、環(huán)境系統報警,、門禁系統報警等),。

3.4通信管理機的資源配置

從通信管理機的任務需求情況來看，它的硬件要求不高,。概括起來,，硬件要求主要有以下幾個方面:一個嵌入式計算機操作系統;TurboPascal5.0的編輯平臺;大小空間為8MB的電子磁盤;一個與之相配的調制解調器.由于要同時與上位機和下位機通信,，所以，要求同時使用嵌入式計算機的兩個串口COM1,、COM2,。硬件電路要求配以8254可編程定時器和8259A可編程中斷控制器。

4.通信管理機軟件的實現

根據對通信管理機設計的分析,，我們把整個軟件劃分為以下幾個模塊來分別實現:Modem控制模塊,、

定時器模塊、上位機任務模塊,、報警任務模塊,、定時數據采集任務模塊。

4.1調制解調器控制模塊

在對調制解調器的控制中9首先要對Modem的設置信息進行安排,，這個過程叫Select Modem Set,，它允許用戶詳細說明所用的通信口、波特率,、停止位和數據位的位數，以及奇偶校驗位和電話號碼,。這些數據項存放在一個記錄類型Modem Set Type中,該類型定義如下：

調制解調器設置好后9中斷由過程裝入.該過程保存原來中斷矢量地址,裝入過程AsyInt的地址,然后將InS8250UART芯片準備好用來通訊,。對于計算機與調制解調器的通信，我們采用RS232標準進行串口通信,。

在設計定時器時,，應當注意的問題是所使用的計時器芯片雖然有三個通道，但是其中一個專門用來刷新RAM,，一個專門用來使揚聲器產生聲音,，9這兩個定時器中斷都不能轉到其它用途。所以,，我們要定時就只能使用第三個計時器,，它是專門用來產生BIOS中斷的，定時中斷頻率為18.2Hz因為在程序設計時需要不同的定時時間,因此,要采用置標志位的方法來實現擁有多個不同的定時時間,。每次脈沖調用定時器中斷08h中斷,。

這里尤其要注意:由于中斷返回與普通過程返回相比，中斷返回還要從堆棧中彈出FLAG標志,，因此,，在設計定時器中斷時，PUSHF指令不可缺省,。而且要特別注意調用一次原中斷處理程序,。

4.3上位機任務模塊

對于該模塊的設計我們要注意三點:(1)上位機下達任務的優(yōu)先級最高應當首先響應。(2)上位機任務的形成是在串口接收到完整的數據后產生的,，采用循環(huán)隊列方式,，任務加到隊列尾部,。(3)循環(huán)檢查串口是否有上位機傳來的數據，而后才查看該隊列是否為空,。通信管理機對上位機下達任務的響應設計成過程的形式,，安排在主程序的循環(huán)體中。在該過程中,，具體按以下步驟執(zhí)行:

Step1:檢查上位機下達任務的隊列是否為空,，空則退出過程；

Step2:從任務隊列中取出一個任務,，根據該任務號讀取所對應的任務文件,；

Step3:從文件中讀取命令控制字并進行解釋；

Step4:根據解釋的命令對隨后的數據進行一次性處理,，并返回到Step1,。

4.4報警任務模塊

報警任務模塊仍然采用隊列方式。報警任務的隊列與前兩個隊列相比就略顯簡單,。它采用循環(huán)隊列控制方式,，在子程序模塊的應用過程中產生。它的優(yōu)先級高于定時數據采集任務,，但低于上位機下達給通信管理機的任務,。

報警任務的形成來自三個方面:設備間的通信超時報警，通信故障報警,，控制器故障報警,。其中，控制器故障的報警包含兩種情況:一種是常規(guī)報警,，一種是突發(fā)報警,。對于突發(fā)報警，比如,，由于非正常使用或非法使用而造成的報警,，為了縮短反應時間，無需經過通信管理機,，可直接上傳到上位機,，以便作出緊急處理。

通信管理機對報警任務的響應設計形式與上位機任務類似,，以一個過程的形式存在,，安排在主程序的循環(huán)體中。在該過程中9我們按以下步驟執(zhí)行:

Step1:檢查報警達任務隊列是否為空,，空則退出過程,；

Step2:從報警隊列中取出一個任務，根據該任務號及時上傳指定控制器的報警信息；

Step3:根據該任務號,，在本機顯示報警信息并返回到Step1,。

4.5定時數據采集任務模塊

定時數據采集任務隊列的設計不同于上位機下達任務隊列的形式。采用順序的存儲結構,，但不是循環(huán)隊列,，這完全是為了兼顧其任務類型的獨有特點，滿足定時任務的特別需要,。定時數據采集任務是分成兩個部分進行的,，包括數據采集存盤與主動上傳兩個過程，這樣的設計是為能夠及時地響應上位機傳來的任務和報警任務等優(yōu)先級較高的任務隊列,。因此,，該隊列的任務總是成對地出現，具有一定的規(guī)律性,。長,、短定時任務隊列的安排是一樣的:當隊列不空時就響應隊列中的一個任務，并跳出定時任務隊列,，繼續(xù)循環(huán)主函數;當隊列執(zhí)行空,，才一次加載整個定時數據采集任務隊列。定時數據采集任務隊列采用數組方式,。所以,，任務標號選擇相鄰的兩個作為一對任務。當任務標號為單數時對應任務為數據采集存盤,，當任務標號為偶數時對應的任務為上傳數據。當一組任務全部執(zhí)行完畢后,，

才重新回到數組頭,。這也是所謂的當任務空時一次性全部加載任務。

4.6程序流程圖

根據設計思路9我們按著如圖2所示的程序流程圖來設計整個通信管理機的軟件,。

圖2 通信管理機軟件流圖

5.系統的仿真以及通信管理機的性能測試

為了能更好地設計與完善通信管理機,，我們簡單地制定了一套模擬整個機房監(jiān)控系統的方案。通過這套方案,，可以進一步檢測通信管理機的實際性能,，以便于對其自身存在的問題加以修改，從而對將要進一步擴展的功能加以完善,。

5.1模擬仿真整體思路設計

如圖3所示,，由于實驗條件的限制9我們采用兩臺PC機來分別模擬機房監(jiān)控系統的上位機和下位機。其中,，特別要注意的是服務器要選用Windows2000的操作系統,，而控制器則可隨意選用各種操作系統。

圖3 模擬仿真示意圖

5.2模擬仿真及實驗結果

在所設計的試驗條件下，實際聯機操作的測試結果均與所設計的仿真計劃的預期結果相吻合,。實驗的結果雖然不能完全代表通信管理機設計的正確性與合理性,，但是已經能夠說明在這種設計下，通信管理機的基本功能已經實現,。這為下一步對通信管理機進行功能擴展,，技術改進，以及版本升級奠定了堅實的基礎,。

6.結束語

通信管理機是整個機房監(jiān)控系統的一個重要組成部分,，它實現了任務管理。計算機通信,。遠程控制等許多功能,，是整個服務系統的得力助手。通信管理機的設計,，主要是基于計算機的串口通信和嵌入式計算機的一些簡單控制來逐步實現的,。雖然任務復雜，但分成模塊單獨實現9使得思路清晰,、實現容易,。

來源：環(huán)境監(jiān)控系統 機房動力環(huán)境監(jiān)控系統 http://youring.cn/solution/  本文采集于網絡，如有問題有聯系刪除