基于分布式對象封裝的集成ＳＭＳ報警控制系統模型研究

摘要:針對監控系統中對設備的遠程報警和控制上存在的異網#65380;異構等問題，提出在分布式監控平臺中引入短信息服務(SMS)分布式服務體系的設計理念來建立遠程監視控制系統，給出了網絡化SMS體系的監控系統功能模塊結構和工作程序流程，同時采用CORBA服務組冗余等容錯策略來提高系統的可靠性。另外，系統中的分布式監控模塊將各種監控平臺逐一封裝為CORBA對象，可用于分布式子系統的無縫透明連接。

關鍵詞:分布式系統; 短信息服務體系; 報警控制; 公共對象請求代理體系結構; 容錯; 可靠性

中圖分類號:TP319文獻標志碼:A

文章編號:1001－3695(2008)02－0587－04

隨著我國通信基礎設施日益完善，固定電話#65380;移動電話用戶總數接近兩億。截止到2003年10月底，中國移動用戶已經超過了固定電話用戶。手機短信也成為移動運營商的一大增長點。短信在通信市場上的作用如此巨大和普及，使用個人通信終端實現對家用電器#65380;工業設備的遠程控制也開始成為眾所關注的問題。為了更好地使家用電器和工業設備長時間可靠工作#65380;及時安全報警，減少人力投入，人員不在現場時，能快速報警并對相關事故進行相應處理，在一些監控系統的基礎上，添加短信報警及控制系統是非常必要的。但是對于基于分布式應用的監控體系而言，需要本地數據庫支持，且不兼容異地#65380;異構平臺，而且采用公共無線網絡進行通信，對系統的安全性也提出了較高的要求[1]。

利用COBRA中間件，本文建立了一個通用的短信報警控制系統模型，采用了基于SMS和面向分布式對象的方法，很好地滿足了分布式網絡體系的要求，并具有良好的安全性，可擴展性和可移植性。本文介紹其主要設計思想。

1系統功能的設計

系統向外出人員提供報警功能并以短信方式發送報警信息，然后按照用戶的反饋信息對需要進行遠程控制的狀態參數#65380;控制變量進行調整，從而實現短信報警與控制。具體功能如下所示:

a)短信報警。當現場發生報警后，由系統將報警內容以短信的形式發送到相關管理人員的手機上，使管理人員可及時了解現場信息。

b)短信控制。當處理報警事故的相關管理人員收到報警短信后，根據具體的報警故障(高級別故障可由專家系統作出及時的處理)，按照事先制定的描述規范編寫短信(操作碼)發送到數據處理中心;系統在檢驗用戶合法性后根據短信內容對相應設備進行故障處理并反饋給管理人員。

c)設置短信有效期#65380;收/發狀態報告，并有超時處理功能。

d)采用雙向告警機制。正向報警為正常狀態信息;反向報警根據實際情況進行多個級別的警情設定。

e)設有用戶鑒權和安全日志功能。

2系統模型的建立

系統采用基于擴展CORBA內核ORB技術的實時#65380;開放分布式系統中間件平臺。CORBA(common object request broker architecture)提供了面向對象的標準化互操作規范，使用戶可以透明地獲取信息#65380;實現交互。CORBA獨立于網絡協議#65380;編程語言和軟/硬件平臺，因而成為目前最有生命力的跨平臺技術[2]。該平臺有效地利用了各種操作系統的資源，使得應用程序建立在構件化的基礎上，便于新應用模塊的擴展。

整個中間件平臺采用模塊化的分層設計結構和基于SMS的設計思想，便于靈活地擴展新的操作系統的功能。所謂SMS是指計算機系統管理的相關設備報警資源以及提供的控制接口總稱，其所含服務可以看做是一種數據庫的中間件擴展，完成從數據源的配置管理到數據獲取和傳輸等一系列功能，使數據消費者同底層的數據源隔離，具有良好的可擴展性#65380;可部署能力和負載平衡能力。因此本系統網絡具有配置靈活#65380;跨平臺可移植性好#65380;可擴展性強等優點。在進行模型設計時要解決好粒度劃分#65380;類的接口和集成層次的確定#65380;對象間的通信以及SMS可靠性等問題。

2.1模塊的劃分與SMS粒度的確定

根據分布式應用需求，主框架設計主要包括兩大模塊#65380;三種服務(即SMS)，其層次如圖1所示。

為了滿足不同監控系統類型并方便程序的升級和擴充，將每一種服務或模塊封裝成一個或多個分布式CORBA對象。下面對其中的各個模塊#65380;服務名詞進行解釋。

1)短信報警控制模塊作為本系統的數據處理中心，提供報警素材管理#65380;警情通知和報警信息管理功能;提供控制指令查看#65380;修改和傳遞功能;提供用戶權限表查看和修改功能;提供系統安全日志的查看功能。

2)分布式監控模塊分布式環境下數據源與數據消費者分離，分布式監控模塊負責具體的多個分布式設備的狀態參數集成#65380;監視和控制，向短信報警控制模塊提供各種指令操作接口。

3)安全服務網絡中用戶通過短信發出控制指令時要通過安全服務鑒權，獲得相應用戶權限后可根據用戶權限進行允許的操作。安全服務維護用戶權限表和系統安全日志，提供對系統用戶的安全認證#65380;授權和鑒權，系統安全記錄#65380;安全策略實施#65380;管理等功能，是考慮到在分布式環境下對不同網絡元素進行安全性檢驗和管理時所需要的各種基本服務而設計的。

4)網管服務提供分布式網絡管理功能，利用并封裝CORBA的名字服務，在其基礎上提供接口為CORBA對象注冊。通過方法調用獲取工程對象的信息結構，維護內存中鏈表記錄CORBA對象及其相關內容的信息，便于其他服務和模塊的查找使用，并用于監視系統中各子系統的工作狀況。

5)實時數據服務用來從分布式監控模塊的監控變量索引表中，檢索并提供報警所需的實時數據和相關信息。數據傳輸按照FIFO原則進行，也可以根據報警或控制的優先級調整發送次序。優先級由事件的優先級#65380;用戶級別#65380;數據類型等共同確定。

2.2集成SMS的分布式對象

依據系統建模及面向對象的方法，服務模型可以抽象為服務客戶端代理#65380;服務本體以及兩者之間的分布式環境三大部分[3]。服務代理包括模板組態端和數據提供源端的代理;服務本體包括指令處理內核#65380;服務管理內核#65380;數據發布內核三部分，如圖2所示。分布式環境由CORBA ORB以及CORBA核心服務組成，它們提供了本體和代理之間的通信機制。

在使用SMS體系中的各種服務時，服務轉變為消費者代理;消費者代理與服務本體之間#65380;服務本體與分布式監控模塊之間也是數據消費者與數據提供者的關系。服務客戶端代理部署在消費者端，作為短信報警控制模塊的一部分存在;服務本體(數據服務消費者代理)可以部署在網絡的任意節點，并以獨立的CORBA對象形態存在;服務本體則部署在數據提供源端(分布式監控模塊)作為一個CORBA對象存在。

圖3顯示了系統內部的通信關系;同時也說明了系統通過接口調用向外部的GSM#65380;WAP和其他數據通信網絡應用系統提供接入解決方案[4]。

2.3數據結構設計

通信過程中所使用到的數據存放在動態申請的內存中，這些動態數據保證了報警和控制信息的靈活性。分布式監控模塊以類CDeviceInfo的實例形式記錄了設備的各種信息。類CDeviceInfo的定義如下:

class CDeviceInfo

{AnsiString szDeviceTypeNo;

TList *tlstDeviceControlCommonedInfo;

TList *tlstDevicePortDescribeInfo;

TList *tlstDeviceWarningInfo;

……

boolSaveDevData (… ); // 存儲設備信息

void LoadDevData (… ); // 載入設備信息

}

類CDeviceInfo中，szDeviceTypeID記錄用來惟一標志設備庫中設備的型號;鏈表tlstDeviceControlCommonedInfo#65380; tlstDevicePortDescribeInfo和 tlstDeviceWarningInfo分別記錄當前設備中的用戶可用控制信息#65380;通信端口及其描述信息和報警信息。一旦發生報警事件，需要注意的是，函數SaveDevData和LoadDevData分別用于存儲和載入設備信息，系統通過這兩個函數完成內存中動態數據與硬盤文件和數據庫數據之間的轉換。

為了使用和更新的方便，設計中將信息拆分為兩部分:一部分可以看做信息頭，即與用戶數據無關的部分，這一部分主要用于服務內部和服務之間信息的查找定位;另一部分被定義為數據域，即實際需要的信息。下面為系統中報警與控制信息的數據結構定義:

structSwarning//報警短消息導出結構

{/*信息頭 */

short nAlertLevel; //報警級別

string szCellPhoneNum;

//管理人員手機號碼(多個用“;”分隔)

/* 信息頭 */

/* 數據域 */

string szZoneName; //所屬區域名

enum eErrorType; //故障類型

string szTime; //故障時間

string szHostName; //主機名

string HostIP; //主機IP地址

……

/*數據域*/

}

structSMessageControl //短消息控制命令導入結構

{/* 信息頭 */

string szChgObjectName;

//改變對象的名稱:工程名#65380;通信端口#65380;設備名

string szStaName; //子站名稱

short nControlPRI; //控制優先級

……

/* 信息頭 */

/* 數據域 */

short nChgObjectType; //改變對象的類型:工程端口子站

short nChgInfo; //設備狀態標志

long lBourn; //報警閾值修改信息

short nGroupNum; //設備所屬組號

boolean bActType;

//動作狀態，為true時啟動，為1時停止

string szCellPhoneNum; //發送控制短信的號碼

/*數據域*/

};

關于其他數據結構及具體內容，限于篇幅不再詳細介紹了。

3程序流程

短信報警與控制系統基本流程如圖4所示，具體程序略。

對于每條報警，用戶可以進行個性化的定義，如選擇使用手動控制短信服務或自動控制短信服務(即超時處理系統)?？筛鶕煌瑑炏燃墑e的報警配置兩種服務的用戶，兩種服務對應的硬件設施是不同的，所使用的控件也是不同的。

通過圖4所示的流程可以看到，在分布式環境中使用SMS最關鍵的是安全性[5]。下面給出了保證系統高可用性(high availability，HA)所采取的策略和方法。

4SMS容錯策略

4.1冗余服務組

網絡容錯主要是為了保證在系統運行過程中，正在使用的SMS在出錯時系統仍然可用。作為基于對象封裝的組件模型來說，服務這樣一個顆粒在容錯系統中是可以接受的[6，7]。

在CORBA容錯模型中，引入了冗余服務組的概念，定義如下:

a)服務組。提供相同功能的服務被分成服務組來管理，如兩個或兩個以上的命名服務組織在一個命名服務組管理，兩個或兩個以上的安全服務組織在一個安全服務組管理，組內各個成員保持狀態和數據的一致性。

b)主服務(primary)。只有primary執行客戶請求。一個服務組中只有一個primary，其余服務組成員狀態和數據都要與primary保持一致。

c)備份服務(backup)。一個服務組中至少應配置兩個備份服務。在主服務存在的條件下，備份服務需要時時與主服務狀態和數據保持一致;在主服務崩潰時，其中一個備份服務將按照策略由服務管理器指定為新的主服務。

4.2可靠性機制

使用時將同一個服務的多個副本(冗余服務組)運行在網絡不同主機上，作為一個組來進行管理，每個服務組應包含一個主服務和至少一個備份服務。當主服務失效時，系統將升級一個備份服務為主服務，繼續向CORBA對象提供服務，保證系統正常運行。

a)服務的容錯基于復制策略，利用資源冗余的優勢，將系統同一功能復制在多個節點上，即使一個失效，其他操作也能保證系統正常運行。

b)容錯對象復制算法基于CORBA的調用機制，采用primary_backup復制算法[8]。算法要求客戶方主動參與容錯，在請求調用時能夠識別服務器失效并重新調用請求，保證數據的一致性同時也提高了系統的可用性和可靠性。

c)客戶端主動參與容錯，在請求調用時能夠識別服務器失效并重新調用請求，算法能保證調用最多只被執行一次。

d)容錯系統采用超時機制實現失效檢測，即檢測機制周期地給被監控實體(主機或服務等)發送詢問信息，若對方在一定時間內沒有應答，則認為它失效。

需要說明的是，分布式系統的數據源是分散數據源，即每臺運行網管服務的機器都維護一個本地服務的內存信息。服務容錯就是使備份服務的內存信息與主服務的內存信息保持一致。在兩者始終保持一致的情況下，當主服務退出，只要升級一個備份服務為主服務即可，所采用的容錯機制對用戶來講是完全透明的。此外，每個系統在運行時都需要投運一個網管服務主服務和至少一個備份服務。實驗表明備份服務越多服務的效率越低，因此服務的個數與系統性能有直接的關系，備份服務的個數也不能過多。

5結束語

本文所設計的系統可以隨時發現與處理設備故障#65380;減少事故時間，各種遙控操作#65380;設備檢修及系統事故均可存盤保存，并可打印記錄，從而減輕了管理#65380;值班人員的勞動強度。通過遙控還可以合理調配參數，實現優化運行，有效節約了成本。

短信報警控制系統利用CORBA技術，使用面向SMS的設計觀點，模型的設計思想并不依賴于具體的設備及操作系統，因此具有很好的可移植性。它將其服務及功能模型都封裝為CORBA對象，還可以將使用不同平臺的監控管理系統連接起來。此外，由于引入了容錯機制，在SMS發生異常問題時，能夠有效地繼續對外提供可用服務。

參考文獻:

[1]KAPSALIS V，KOUBIAS S，PAPADOPOU LOS G.OPC－SMS: a wireless gateway to OPC－based data sources[J].Computer Standards Interfaces，2002， 24(5):437－451.

[2]HENNING M，VINOSKI S.基于C++ CORBA高級編程[M]. 徐金梧， 徐科，等譯. 北京: 清華大學出版社， 2000.

[3]PAPAJORGJI P，BECK H W，BRAGA J L.An architecture for developing service－oriented and component－based environmental models[J].Ecological Modelling，2004，179(1):61－76.

[4]WU C H，JAN Rong－hong. System integration of WAP and SMS for home network system[J]. Computer Networks，2003，42(4):493－502.

[5]COTRONEO D，MAZZOCCA N，ROMANOL， et al. Building a dependable system from a legacy application with CORBA[J]. Journal of Systems Architecture，2002，48(1－3):81－98.

[6]ZHAO W，MOSER L E，MELLIAR－SMITH P M. End－to－end latency of a fault－tolerant CORBA infrastructure[J]. Performance Evaluation， 2006，63(4):341－363.

[7]LIANG D，FANG Cen－liang，YUAN S M，et al. A fault tolerant object service on CORBA[J]. Journal of Systems and Software， 1999，48(3):197－211.

[8]周明輝， 郭長國， 吳泉源，等. 基于CORBA的容錯對象復制算法[J]. 計算機研究與發展， 2002， 39(3):290－294.

[9]牛明博， 史浩山， 牛海發，等. 面向異構網管理的多級中間件體系[J]. 微電子學與計算機， 2006，23(1):21－24.

[10]HAUNG Y R，HO Jan－ming. Overload control for short message transfer in GPRS/UMTS networks[J].Information Sciences， 2005，170(2－4):235－249.

[11]LIU Jin－shan.Supporting QoS－aware service discovery in ubiquitous computing environments[D].France:University of Versailles－Saint Quentin en Yvelines， 2006.

[12]EPHREMIDES A，HAJEK B. Information theory and communication networks:an unconsummated union[J]. IEEE Trans on Information Theory，1998，44(6):2416－2434.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”