摘? 要: 以移動交換系統網元層故障管理模塊為例,介紹了實時系統的軟件設計中,在保證系統實時性的前提下,提高軟件系統可靠性的軟件設計技術。
關鍵詞: 網元? 移動交換系統? 實時系統? 可靠性? 故障管理
?
典型的GSM/CDMA移動通信網由交換分系統、基站分系統和大量移動用戶終端三大部分組成。其中,交換分系統也稱為移動交換系統(MSS),由移動交換中心(MSC)、歸屬位置寄存器(HLR)、被訪位置寄存器(VLR)、設備識別寄存器(EIR)、鑒權中心(AUC)、短消息中心(SMSC)等諸多網絡元素(Network Element,簡稱為網元)和操作維護中心(OMC)構成。交換分系統是移動通信系統的控制交換中心,也是移動網與其他通信網的接口。交換分系統中任何一個網絡元素出現故障都有可能對整個移動通信系統產生嚴重影響。在交換分系統中,操作維護中心和各網元實體上的故障管理模塊是網元層網絡管理系統的一個重要組成部分。本文以移動交換系統網元層故障管理模塊為例,介紹在實時系統的軟件設計過程中,在保證系統實時性的前提下,提高軟件系統可靠性的一些軟件設計技術。
1? 故障管理模塊概述
故障管理模塊在交換分系統中所處的位置如圖1所示。
故障管理模塊存在于OMC和各網元實體之上。OMC上的故障管理模塊一般設計為客戶端/服務器(C/S)結構,其實現的功能包括:故障信息的持久性保存(一般是寫入數據庫)、故障信息的顯示、網元機架圖的顯示等。網元上的故障管理模塊負責收集各業務進程和控制進程產生的故障信息,經過處理后把這些故障信息轉發到OMC。故障信息也稱為告警消息。一條告警消息在C++中表現為一個具體的對象,包括告警發生時間、恢復時間、發生位置、具體內容和流水號等若干屬性。
故障管理模塊是監控交換分系統是否正常工作的主要工具,是電信運營商非常重視的一個軟件模塊。電信運營商對故障管理功能的最基本的要求就是:實時準確,不漏警,不虛警。為了達到這個要求,故障管理模塊的設計必須在保證實時性的基礎上,確保故障信息的準確無誤。
2?網元上故障管理模塊的設計和實現
交換分系統中的各種網元實體(如MSC、HLR等)都是典型的分布式實時系統,一般由若干個模塊構成。交換分系統中的設備都要求全年24小時不間斷工作,所以每個模塊都采用了主機備用冗余的設計。網元中故障管理模塊的結構示意圖如圖2所示。每個模塊都有主用和備用2個模塊處理機(MP),2個模塊處理機同時處于工作狀態。備用MP只和主用MP通信,負責備份主用MP中的重要數據。一旦主用MP發生故障,備用MP可以在不中斷業務的情況下迅速地轉為主用工作狀態。
?
?
從圖中可以看出,故障管理模塊同時運行在主用和備用MP中。故障管理模塊在MP中用3個進程實現。
(1)告警收集進程:收集各業務進程和單板控制進程產生的告警信息,進行必要的格式轉換等數據預處理工作,然后把處理后的告警信息放入當前告警列表和消息發送隊列。當前告警列表存儲在MP內存中的一個數據緩沖區。主用和備用MP中的告警數據緩沖區總是處于一致狀態。
(2)告警發送進程:主要的任務是將告警發送隊列中的告警消息發送到OMC上的故障管理模塊。
(3)告警同步進程:主要完成網元和OMC之間告警消息的周期性同步、斷鏈同步處理以及主用和備用MP之間的周期性同步和倒換同步處理。該進程是實現不漏警、不虛警要求的重要機制。
3?OMC中故障管理模塊的設計和實現
OMC設計為C/S結構。故障管理模塊同時存在于客戶端和服務器上,分別用不同的應用進程實現。服務器上的故障管理模塊實現的功能有:保存告警信息到數據庫;轉發告警信息到上一級的網絡管理中心;轉發告警信息到客戶端;處理客戶端的數據庫操作請求和參數修改請求;控制告警箱等。客戶端的故障管理模塊實現的功能有:最新告警的實時顯示;歷史告警的查詢和打印;告警屏蔽設定和解除;機架圖的實時顯示;人機命令界面等。
在C/S結構的系統中,服務器處于核心地位,服務器端的故障管理進程要確保能長時間正常工作。在OMC系統中,可以使用看門狗機制監控故障管理進程。看門狗實際上是一個錯誤監控程序,可以用一個高優先級的應用進程來實現。看門狗進程定時向故障管理進程發送握手消息,故障管理進程收到此消息后會立刻發回一個確認消息。如果在一段時間內收不到故障管理進程的響應,看門狗進程就認為故障管理進程發生異常。此時看門狗進程就會殺掉并重新啟動故障管理進程,使故障管理進程恢復正常運行狀態。
4?使用定時同步機制保證故障信息的準確性
從用戶使用的角度看,故障管理模塊必須保證2種信息的準確性:機架圖和活動告警。機架圖是對網元上各種單板位置和狀態的直觀顯示。網元有無故障,用戶通過查看OMC客戶端上的機架圖就能一目了然。
為了確保機架圖顯示的實時性,可以把機架圖在內存中按線形結構存儲。例如一個機架由7層機框組成,每層機框有27個板位,該機架在內存中就可以用2個長度為27×7的一維數組表示:aRackState[189]和aRackType[189]。aRackState[189]是表示單板狀態的數組,aRackType[189]是表示單板類型的數組,二者結合就是完整的機架圖信息。OMC和網元上的故障管理模塊都在各自的內存中維護機架圖數組。OMC中維護內存機架圖數組的目的在于保證客戶端界面上的機架圖顯示能很好地實時刷新,并且還便于和網元中的機架圖數組保持數據同步。網元中的內存機架圖數組由網元上的告警進程和控制進程共同維護。數組中的信息和網元中的內存數據庫保持一致,其數據是高度可靠的。為了保證OMC和網元的機架圖數組的數據一致性,需要引入定時同步機制確保二者的數據完全相同。
最簡單的同步辦法是每隔一定時間把OMC上的機架圖數組發送到網元上,由網元上的告警同步進程逐字節地比較OMC和網元機架圖數組的異同。由于1個網元可能由10個以上的機架構成,而同步間隔一般都是若干秒,因此在很短的時間里把很多數組傳來傳去對底層通信系統的總體性能會有一定影響。
本系統采用的辦法是比較OMC和網元機架圖數組的校驗和。同步過程由OMC上的故障管理進程發起,該進程計算出OMC上的機架圖數組的校驗和,然后把該校驗和發送到網元上的告警同步進程。網元上的告警同步進程收到該校驗和后,立刻計算出本機內存中的機架圖數組的校驗和,然后比較這2個校驗和的值。如果這2個值不一致,說明前、后臺機架圖不一致,網元上的告警同步進程就把本機內存中的機架圖數組發送到OMC,OMC中的機架圖數組隨即得到更新。
計算校驗和的算法采用了16位循環冗余校驗CRC(Cycle Redundancy Check)算法。它可以對一個數據塊進行校驗,是一種高效的差錯控制方法。16位CRC算法能夠檢查出所有的單位錯、雙位錯、奇位數錯及小于等于16位的突發性錯,還能檢查出17位突發性錯的99.997%,大于等于18位突發性錯的99.998%。如此高的可靠性,可以滿足用戶對機架圖準確性的嚴格要求。
活動告警是指當前沒有恢復的、正在發生的告警。其同步過程與機架圖類似,此處不再展開討論。
5?持續改善軟件設計與開發質量
前面介紹的主備冗余、定時同步和看門狗機制都不同程度地提高了故障管理模塊的可靠性,但這些機制并不能完全確保不漏警、不虛警。網元中的每個模塊處理機都是一個運行在PSOS、VxWorks等實時操作系統之上的大型實時系統。MP上運行著大量的應用進程,軟件故障不可避免地存在其中。相當比例的漏警、虛警事故與硬件無關,而是由業務模塊和故障管理模塊中的軟件錯誤導致,所以提高軟件設計質量和開發質量是進一步提高故障管理模塊可靠性的重要手段。
提高軟件系統設計質量和開發質量的途徑是多樣的,例如使用設計模式優化軟件結構、在開發過程中進行單元測試等。對于已經完成開發的軟件,使軟件質量獲得持續改善的重要手段是代碼重構。不漏警、不虛警是比較苛刻的要求。要達到這個目標需要故障管理模塊設計者不懈努力。
參考文獻
1? 梁振軍,梁波.計算機網絡教程.北京:海洋出版社,1991
2? 鄭宗漢.實時系統軟件基礎.北京:清華大學出版社,2003
3? Subramanian M.Network Management:Principles and Practice.Addison Wesley Longman,2000
4? Fowler M.Refactoring:Improving the Design of Existing?Code.Addison Wesley Longman,2000