基于WEB的通信電源的遠程監(jiān)控研究與實現(xiàn)

隨著IT技術(shù)的發(fā)展，帶動了各行各業(yè)，局域網(wǎng)、廣域網(wǎng)和互連網(wǎng)的普遍實施， 多數(shù)單位有了自己的網(wǎng)站，各系統(tǒng)也建立了自己的網(wǎng)絡。因此，對系統(tǒng)的可靠性要求也提高了。

　　 傳統(tǒng)的UPS電源往往是等到機器出現(xiàn)了故障，不能正常供電，才由值班人員去查找故障所在，這樣勢必耗費很多寶貴的時間，而且很多場合也是不允許的。隨著微 處理器CPU和監(jiān)控軟件的引入，大大增加了UPS的自檢功能。多數(shù)UPS都配備了自己的監(jiān)控軟件，當UPS故障時，監(jiān)控軟件就可以通過面板上的液晶顯示 屏，將故障的部位或器件顯示出來，大大節(jié)省了時間。

　　 隨著網(wǎng)絡技術(shù)的普及，用戶又向UPS提出了更高的要求：UPS應具有無人值守功能，并且不但具有自檢功能，還應具有聯(lián)網(wǎng)功能，即，不但在網(wǎng)上可以隨時觀察 UPS的各項運行參數(shù)，而且在市電或UPS故障時，可以向服務器、工作站等發(fā)出信息，同時也可以打電話、發(fā)傳真或?qū)ず舻仁侄瓮ㄖ蛋嗳藛T。反過來，網(wǎng)絡技 術(shù)以及信息技術(shù)的發(fā)展為UPS通信電源的網(wǎng)絡化監(jiān)控提供了可能，而建立在WEB上的納入工廠整體信息化的遠程監(jiān)控系統(tǒng)，才是未來發(fā)展的方向。

　　 以數(shù)據(jù)庫為中心的監(jiān)控方案

　　 傳統(tǒng)的監(jiān)控方法基本上都是以數(shù)據(jù)庫為中心的解決方案，其中的控制網(wǎng)絡可以是各種現(xiàn)場總線，也可以是其它工業(yè)控制網(wǎng)絡，各個控制節(jié)點通過它進行通訊，監(jiān)控機 通過發(fā)射電臺對電源運行狀況進行監(jiān)測，收集現(xiàn)場信息，經(jīng)處理后傳送給實時數(shù)據(jù)庫服務器；Web服務器根據(jù)客戶端瀏覽器發(fā)來的HTTP請求，通過服務器擴展 模塊，從實時數(shù)據(jù)庫中獲取數(shù)據(jù)，然后傳回給客戶端瀏覽器進行顯示?？梢钥闯?，整個過程都是圍繞著實時數(shù)據(jù)庫服務器展開的。這種方法在實際應用中存在許多不 足。例如，相對于監(jiān)測功能，控制功能的實現(xiàn)比較困難，編程上難度較大，特別是安全性方面如認證、加密。為解決實時性問題，一般采用輪詢方式，由客戶瀏覽器 定時刷新網(wǎng)頁，而這會導致效率低下，有些系統(tǒng)也采用事件觸發(fā)方式，利用數(shù)據(jù)庫服務器的觸發(fā)器功能主動推(push)數(shù)據(jù)，但它一般要求Web服務器與數(shù)據(jù) 庫服務器位于同一臺機器上，不便于系統(tǒng)擴展; 數(shù)據(jù)庫服務器是整個系統(tǒng)的核心，需處理Web服務器與監(jiān)控機的請求，工作負載很重，有可能成為系統(tǒng)性能瓶頸。這些不足之處隨著應用模型的擴大顯得越來越明 顯，需要新的解決方案。

　　 WEB監(jiān)控系統(tǒng)

　　 基于Web的電源遠程監(jiān)控系統(tǒng)，一般可分為3個子系統(tǒng)：即現(xiàn)場監(jiān)測與控制子系統(tǒng)；數(shù)據(jù)存儲與轉(zhuǎn)發(fā)子系統(tǒng)；客戶端接收與命令發(fā)送子系統(tǒng)?，F(xiàn)場子系統(tǒng)負責采集 各個現(xiàn)場控制節(jié)點的運行狀況數(shù)據(jù)，然后傳遞給中間層子系統(tǒng)；中間層子系統(tǒng)是一個中介系統(tǒng)，由工控機、Web服務器和實時數(shù)據(jù)庫服務器組成。工控機通過電臺 發(fā)射信號向現(xiàn)場采集數(shù)據(jù)，Web服務器通過服務器擴展技術(shù)如CGI、ISAPI等完成與客戶子系統(tǒng)以及現(xiàn)場子系統(tǒng)的交互；客戶子系統(tǒng)是用戶直接與之交互的 部分，它接收用戶的輸入，從中間層子系統(tǒng)獲取監(jiān)測數(shù)據(jù)或向其發(fā)送控制命令。

　　 現(xiàn)場信號采集模塊選用研華ADAN4017。研華系列的數(shù)據(jù)采集模塊是一套內(nèi)置微處理器的智能傳感器對計算機接口模塊，它們可以通過一套簡單的ASCII 格式的命令來控制并可以以RS485通信協(xié)議傳輸數(shù)據(jù)，它有信號濾波A/D、D/A轉(zhuǎn)換、數(shù)據(jù)比較以及數(shù)字通信功能。模塊上沒有設置開關(guān)來配置參數(shù)和定標 矯正，只能接受來自主機的命令，來改變模擬量輸入范圍、熱電偶或熱電阻輸入。所有模塊的配置參數(shù)包括I/O地址、通信速率、奇偶校驗，校驗和高低報警均可 以遠程設置。另外看門狗定時器的超強功能可以使系統(tǒng)運行失敗時重新啟動模塊。

　　 因為RS-486網(wǎng)絡具有低噪讀傳感器方式，所以模塊可以放置在靠近噪聲源的地方利用ADAM的RS-485接收模塊，最多可以連接256個數(shù)據(jù)采集模塊到一個RS-485多點網(wǎng)絡上。主機通過RS-232/RS-485轉(zhuǎn)化模塊經(jīng)串口連到485網(wǎng)絡上。

　　 系統(tǒng)中，工控機的功能與前面描述所不同的是它不但與實時數(shù)據(jù)庫服務器進行通信，而且還通過套接字Socket與應用服務器通信，即它將采集到的數(shù)據(jù)傳給數(shù) 據(jù)庫服務器的同時還接收來自應用服務器發(fā)出的控制命令。當用戶訪問系統(tǒng)時，通過瀏覽器向Web服務器發(fā)出HTTP請求，然后ActiveX控件隨同 HTML文件下載到客戶端并由瀏覽器解釋執(zhí)行，ActiveX控件與應用服務器建立Socket連接，用戶進行監(jiān)控操作只要通過ActiveX控件的界面 就可以進行了。

　　 Socket編程

　　 應用程序之間的數(shù)據(jù)交換是數(shù)據(jù)通信的重要問題，在TCP/IP網(wǎng)絡環(huán)境下的應用程序是通過網(wǎng)絡編程界面Socket實現(xiàn)的。Socket通常又稱為網(wǎng)絡套 接字，利用Socket進行通信有兩種方式：第一種是流方式，也稱為面向連接的方式。在這種方式下，每一次完整的數(shù)據(jù)傳輸都要經(jīng)過建立連接、使用連接、終 止連接的過程。在數(shù)據(jù)傳輸過程中，各數(shù)據(jù)分組不攜帶目的地址而且內(nèi)容相同。TCP協(xié)議采用的就是這種方式。第二種是數(shù)據(jù)報方式，又稱為無連接方式。在這種 方式下，每個分組都攜帶完整的目的地址，各分組在系統(tǒng)中獨立傳送。無連接服務不能保證分組的先后順序，不進行分組出錯的恢復與重傳，不保證傳輸?shù)目煽啃?UDP協(xié)議提供無連接的數(shù)據(jù)報服務。

　　使用Socket進行網(wǎng)絡通信程序設計和其它客戶機/服務器模式通信應用程序設計過程一樣，客戶機程序(進程)發(fā)送請求給服務器(進程)，服務器進程對客戶機的請求作出響應，并產(chǎn)生結(jié)果。

　　客戶/服務器模式在操作過程中采取的是主動請求方式，首先服務器方要先啟動，并根據(jù)請求提供相應服務。

　　服務器方

　　1.打開一通信通道并告知本地主機，它愿意在某一公認地址上接收客戶請求；

　　2.等待客戶請求到達該端口；

　　3.接收到重復服務請求，處理該請求并發(fā)送應答信號。接收到并發(fā)服務請求，要激活一新進程來處理這個客戶請求。新進程處理此客戶請求，并不需要對其它請求作出應答。服務完成后，關(guān)閉此新進程與客戶的通信鏈路，并終止。

　　4.返回第二步，等待另一客戶請求； 5.關(guān)閉服務器。

　　?客戶方

　　1.打開一通信通道，并連接到服務器所在主機的特定端口；

　　2.向服務器發(fā)送服務請求報文，等待并接收應答;繼續(xù)提出請求；

　　3.請求結(jié)束后關(guān)閉通信通道并終止。

　　從上面所描述過程可知：

　　1.客戶與服務器進程的作用是非對稱的，因此編碼不同。

　　2.服務進程一般是先于客戶請求而啟動的。只要系統(tǒng)運行，該服務進程一直存在，直到正?；驈娖冉K止。

　　微軟公司聯(lián)合其他軟硬件廠商開發(fā)了Windows下的網(wǎng)絡接口-Windows　Socket，這樣開發(fā)人員就可以在Windows下 方便的編寫基于圖形界面的網(wǎng)絡程序。在使用VC進行開發(fā)時，可以利用MFC提供的CAsyncSocket類和CSocket類，它們都封裝了 Windows　Socket　API。CAsyncSocket類幾乎是一一對應地封裝了Windows?Socket?API，該類使得我們可以使用 面向?qū)ο蟮姆绞竭M行Socket編程，而且可以非常方便地調(diào)用其它MFC對象，CSocket類則提供了一個較高級的Socket支持，它運用了MFC的 序列化類來提供和傳輸Socket對象，使用這兩個不同的類進行開發(fā)，各有優(yōu)缺點。在靈活性方面，CAsyncSocket類接近于直接調(diào)用 Windows　Socket　API，靈活性較大。而CSocket類要求通信的兩個程序必須能同時識別MFC序列化協(xié)議，靈活性較小。在開發(fā)的復雜程 度方面，CAsyncSocket類需要開發(fā)者處理各種數(shù)據(jù)類型，比較復雜。CSocket類則在MFC的序列化類的基礎上不需要開發(fā)者處理各種數(shù)據(jù)類 型，所以比較簡單。最后在系統(tǒng)資源消耗方面，CAsyncSocket類不需要為每個連接建立各自的連接線程，系統(tǒng)資源消耗的少。而CSocket類則需 要為每個連接建立各自的連接線程，連接數(shù)目多時系統(tǒng)資源消耗較多。

　　當服務器端與客戶端建立起通信時，客戶端就可以動態(tài)地獲得服務器端傳送過來的各種信息，而它也可以發(fā)送各種控制指令給應用服務器，使之作出相應的處理。最后，由于監(jiān)控機上運行的監(jiān)控軟件會以日志的方式不斷的寫入數(shù)據(jù)庫，因此，監(jiān)控人員有也可以通過網(wǎng)絡服務器讀取數(shù)據(jù)庫的數(shù)據(jù)來獲得監(jiān)控軟件的運行狀況信息。

　　安全性問題

　　在客戶端中，可以對操作對象設置訪問權(quán)限，同時給操作者分配訪問優(yōu)先級和安全區(qū)，當操作者的優(yōu)先級小于對象的訪問優(yōu)先級或不在對象的訪 問安全區(qū)內(nèi)時，該對象為不可訪問，即要訪問一個有優(yōu)先級設置的對象，要求先具有訪問優(yōu)先級，而且操作者的操作安全區(qū)須在對象的安全區(qū)內(nèi)時，方能訪問。操作 者的操作優(yōu)先級級別從0-999，每個操作者和對象的操作優(yōu)先級級別只有一個。系統(tǒng)安全區(qū)共有64個，用戶在進行配置時，每個用戶可選擇除無以外的多 個安全區(qū)，即一個用戶可有多個安全區(qū)權(quán)限，每個對象也可有多個安全區(qū)權(quán)限。除無以外的安全區(qū)名稱可由用戶按照自己的需要進行修改，以此來保障系統(tǒng)的安 全運行。在軟件運行過程中，優(yōu)先級大于900的用戶還可以配置其他操作者，為他們設置用戶名、口令、訪問優(yōu)先級和安全區(qū)。只要用戶定義了一記錄報警和事件 文件，在運行時，用戶的登錄、注銷和對變量的操作等事件都記錄在報警事件文件中。

　　結(jié)論

　　現(xiàn)實生活中的一切電子設備離開了電源就無從談正常工作，尤其在信息化高速發(fā)展的今天，停電所帶來的經(jīng)濟損失是無法估量的。因此，研究如何提供穩(wěn)定可靠的電源，是很有經(jīng)濟和現(xiàn)實意義的。