隨著IT技術的發展， 帶動了各行各業， 局域網、廣域網和互連網的普遍實施， 多數單位有了自己的網站， 各系統也建立了自己的網絡。因此， 對系統的可靠性要求也提高了。
　　傳統的UPS電源往往是等到機器出現了故障，不能正常供電，才由值班人員去查找故障所在， 這樣勢必耗費很多寶貴的時間， 而且很多場合也是不允許的。隨著微處理器CPU和監控軟件的引入， 大大增加了UPS的自檢功能。 多數UPS都配備了自己的監控軟件， 當UPS故障時， 監控軟件就可以通過面板上的液晶顯示屏， 將故障的部位或器件顯示出來， 大大節省了時間。
隨著網絡技術的普及， 用戶又向UPS提出了更高的要求：UPS應具有無人值守功能， 并且不但具有自檢功能， 還應具有聯網功能， 即， 不但在網上可以隨時觀察UPS的各項運行參數， 而且在市電或UPS故障時， 可以向服務器、 工作站等發出信息， 同時也可以打電話、 發傳真或尋呼等手段通知值班人員。反過來， 網絡技術以及信息技術的發展為UPS通信電源的網絡化監控提供了可能， 而建立在WEB上的納入工廠整體信息化的遠程監控系統， 才是未來發展的方向。
以數據庫為中心的監控方案
　　傳統的監控方法基本上都是以數據庫為中心的解決方案，其中的控制網絡可以是各種現場總線，也可以是其它工業控制網絡，各個控制節點通過它進行通訊，監控機通過發射電臺對電源運行狀況進行監測，收集現場信息，經處理后傳送給實時數據庫服務器；Web服務器根據客戶端瀏覽器發來的HTTP請求，通過服務器擴展模塊，從實時數據庫中獲取數據，然后傳回給客戶端瀏覽器進行顯示。可以看出，整個過程都是圍繞著實時數據庫服務器展開的。這種方法在實際應用中存在許多不足。例如，相對于監測功能，控制功能的實現比較困難，編程上難度較大，特別是安全性方面如認證、加密。為解決實時性問題，一般采用輪詢方式，由客戶瀏覽器定時刷新網頁，而這會導致效率低下，有些系統也采用事件觸發方式，利用數據庫服務器的觸發器功能主動推(push)數據，但它一般要求Web服務器與數據庫服務器位于同一臺機器上，不便于系統擴展; 數據庫服務器是整個系統的核心，需處理Web服務器與監控機的請求，工作負載很重，有可能成為系統性能瓶頸。這些不足之處隨著應用模型的擴大顯得越來越明顯，需要新的解決方案。
　　WEB監控系統
　　基于Web的電源遠程監控系統，一般可分為3個子系統： 即現場監測與控制子系統；數據存儲與轉發子系統； 客戶端接收與命令發送子系統。現場子系統負責采集各個現場控制節點的運行狀況數據，然后傳遞給中間層子系統；中間層子系統是一個中介系統，由工控機、Web服務器和實時數據庫服務器組成。工控機通過電臺發射信號向現場采集數據，Web服務器通過服務器擴展技術如CGI、 ISAPI等完成與客戶子系統以及現場子系統的交互；客戶子系統是用戶直接與之交互的部分，它接收用戶的輸入，從中間層子系統獲取監測數據或向其發送控制命令。
　　現場信號采集模塊選用研華ADAN4017。 研華系列的數據采集模塊是一套內置微處理器的智能傳感器對計算機接口模塊，它們可以通過一套簡單的ASCII格式的命令來控制并可以以RS485通信協議傳輸數據，它有信號濾波A/D、 D/A轉換、數據比較以及數字通信功能。模塊上沒有設置開關來配置參數和定標矯正，只能接受來自主機的命令，來改變模擬量輸入范圍、熱電偶或熱電阻輸入。所有模塊的配置參數包括I/O地址、通信速率、奇偶校驗，校驗和高低報警均可以遠程設置。另外看門狗定時器的超強功能可以使系統運行失敗時重新啟動模塊。
因為RS-486網絡具有低噪讀傳感器方式，所以模塊可以放置在靠近噪聲源的地方利用ADAM的RS-485接收模塊，最多可以連接256個數據采集模塊到一個RS-485多點網絡上。主機通過RS-232/RS-485轉化模塊經串口連到485網絡上。
　　系統中，工控機的功能與前面描述所不同的是它不但與實時數據庫服務器進行通信，而且還通過套接字Socket與應用服務器通信，即它將采集到的數據傳給數據庫服務器的同時還接收來自應用服務器發出的控制命令。當用戶訪問系統時，通過瀏覽器向WEB服務器發出HTTP請求，然后ActiveX控件隨同HTML文件下載到客戶端并由瀏覽器解釋執行，ActiveX控件與應用服務器建立Socket連接，用戶進行監控操作只要通過ActiveX控件的界面就可以進行了。
　　Socket編程
　　應用程序之間的數據交換是數據通信的重要問題，在TCP/IP網絡環境下的應用程序是通過網絡編程界面Socket實現的。 Socket通常又稱為網絡套接字，利用Socket進行通信有兩種方式： 第一種是流方式，也稱為面向連接的方式。在這種方式下，每一次完整的數據傳輸都要經過建立連接、使用連接、終止連接的過程。在數據傳輸過程中，各數據分組不攜帶目的地址而且內容相同。TCP協議采用的就是這種方式。第二種是數據報方式，又稱為無連接方式。在這種方式下，每個分組都攜帶完整的目的地址，各分組在系統中獨立傳送。無連接服務不能保證分組的先后順序，不進行分組出錯的恢復與重傳，不保證傳輸的可靠性UDP協議提供無連接的數據報服務
　　使用Socket進行網絡通信程序設計和其它客戶機/服務器模式通信應用程序設計過程一樣，客戶機程序(進程)發送請求給服務器(進程)，服務器進程對客戶機的請求作出響應，并產生結果。
　　客戶/服務器模式在操作過程中采取的是主動請求方式，首先服務器方要先啟動，并根據請求提供相應服務。
　　服務器方
　　1.打開一通信通道并告知本地主機，它愿意在某一公認地址上接收客戶請求；
　　2. 等待客戶請求到達該端口；
　　3. 接收到重復服務請求，處理該請求并發送應答信號。接收到并發服務請求，要激活一新進程來處理這個客戶請求。新進程處理此客戶請求，并不需要對其它請求作出應答。服務完成后，關閉此新進程與客戶的通信鏈路，并終止。
　　4. 返回第二步，等待另一客戶請求
　　5.關閉服務器。
　　客戶方
　　1.打開一通信通道，并連接到服務器所在主機的特定端口；
　　2.向服務器發送服務請求報文，等待并接收應答;繼續提出請求；
　　3.請求結束后關閉通信通道并終止。
　　從上面所描述過程可知：
　　1.客戶與服務器進程的作用是非對稱的，因此編碼不同。
　　2.服務進程一般是先于客戶請求而啟動的。只要系統運行，該服務進程一直存在，直到正常或強迫終止。
　　微軟公司聯合其他軟硬件廠商開發了Windows下的網絡接口-Windows Socket，這樣開發人員就可以在Windows下方便的編寫基于圖形界面的網絡程序。在使用VC進行開發時，可以利用MFC提供的CAsyncSocket類和CSocket類，它們都封裝了Windows Socket API。 CAsyncSocket類幾乎是一一對應地封裝了Windows Socket API，該類使得我們可以使用面向對象的方式進行Socket編程，而且可以非常方便地調用其它MFC對象，CSocket類則提供了一個較高級的Socket支持，它運用了MFC的序列化類來提供和傳輸Socket對象，使用這兩個不同的類進行開發，各有優缺點。在靈活性方面，CAsyncSocket類接近于直接調用Windows Socket API，靈活性較大。而CSocket類要求通信的兩個程序必須能同時識別MFC序列化協議，靈活性較小。在開發的復雜程度方面，CAsyncSocket類需要開發者處理各種數據類型，比較復雜。CSocket類則在MFC的序列化類的基礎上不需要開發者處理各種數據類型，所以比較簡單。最后在系統資源消耗方面，CAsyncSocket類不需要為每
個連接建立各自的連接線程，系統資源消耗的少。而CSocket類則需要為每個連接建立各自的連接線程，連接數目多時系統資源消耗較多。
當服務器端與客戶端建立起通信時，客戶端就可以動態地獲得服務器端傳送過來的各種信息，而它也可以發送各種控制指令給應用服務器，使之作出相應的處理。最后，由于監控機上運行的監控軟件會以日志的方式不斷的寫入數據庫，因此，監控人員有也可以通過網絡服務器讀取數據庫的數據來獲得監控軟件的運行狀況信息。
　　安全性問題
　　在客戶端中，可以對操作對象設置訪問權限，同時給操作者分配訪問優先級和安全區，當操作者的優先級小于對象的訪問優先級或不在對象的訪問安全區內時，該對象為不可訪問，即要訪問一個有優先級設置的對象，要求先具有訪問優先級，而且操作者的操作安全區須在對象的安全區內時，方能訪問。操作者的操作優先級級別從0-999，每個操作者和對象的操作優先級級別只有一個。系統安全區共有64個，用戶在進行配置時，每個用戶可選擇除"無"以外的多個安全區，即一個用戶可有多個安全區權限，每個對象也可有多個安全區權限。除"無"以外的安全區名稱可由用戶按照自己的需要進行修改，以此來保障系統的安全運行。在軟件運行過程中，優先級大于900的用戶還可以配置其他操作者，為他們設置用戶名、口令、訪問優先級和安全區。只要用戶定義了一記錄報警和事件文件，在運行時，用戶的登錄、注銷和對變量的操作等事件都記錄在報警事件文件中。
　　結論
　　現實生活中的一切電子設備離開了電源就無從談正常工作，尤其在信息化高速發展的今天， 停電所帶來的經濟損失是無法估量的。因此，研究如何提供穩定可靠的電源， 是很有經濟和現實意義的。