摘 要： 基于循環(huán)上報和主動查詢相結合的機制，設計了數(shù)字光纖直放站中RU的告警信息同步機制及具體方案，并且搭載嵌入式VxWorks操作系統(tǒng)，給出了具體的代碼實現(xiàn)。測試結果表明，該系統(tǒng)功能完善，達到了設計目標，大大提高了數(shù)字光纖直放站的可靠性和穩(wěn)定性，同時也非常利于對設備的維護。
關鍵詞： 數(shù)字光纖直放站；VxWorks操作系統(tǒng)；循環(huán)上報；告警信息同步
0 引言
鐵道通信網(wǎng)絡中，數(shù)字光纖直放站是一種分布于鐵道沿線為鐵路系統(tǒng)內(nèi)部的通信、調(diào)度等工作服務的無線信號中繼設備，由近端機和遠端機（Remote Unit，RU）組成[1]。圖1為數(shù)字光纖直放站結構框圖，近端機和遠端機按照鏈形組網(wǎng)方式進行連接。近端機由兩塊時間分布控制單元（Time Distributed Master Unit，TDMU）及射頻設備組成。遠端機由兩塊數(shù)字處理板（Digital Processing Board，DPB）和射頻設備組成，兩塊DPB之間通過RS232總線通信。遠端機的兩塊DPB按照主備用模式工作，主DPB處于工作狀態(tài)，備DPB處于關閉備份狀態(tài)。在主DPB出現(xiàn)故障時，主DPB根據(jù)故障類型通過RS232總線開啟備DPB的功能開關或執(zhí)行相應配置，完成主備用的功能切換[2-4]。
RU告警信息的同步有兩層含義：其一，RU與網(wǎng)管中心告警信息的同步；其二，RU兩塊DPB之間告警信息的同步。
實際應用中發(fā)現(xiàn)，當一個RU的兩塊DPB上報的告警信息不一致時，導致網(wǎng)管中心對兩塊DPB的狀況做了錯誤的判斷，誤將正常工作的DPB判斷為故障DPB，為維修人員的工作帶來了麻煩。
針對RU告警信息的同步問題，通過對數(shù)字光纖直放站告警管理功能的深入研究，本文提出在RU與網(wǎng)管中心之間以及在RU的兩塊DPB之間分別采用循環(huán)上報機制[5-7]和主動發(fā)送與查詢相結合機制的實現(xiàn)方案，同時搭載嵌入式VxWorks操作系統(tǒng)，給出了具體的代碼實現(xiàn)。
1 RU告警信息同步的設計與實現(xiàn)
1.1 RU告警信息同步的實現(xiàn)過程
圖2為告警信息同步方案邏輯框圖，告警信息同步方案涉及3個部分：網(wǎng)管中心、告警同步單元和告警處理單元。告警信息同步的實現(xiàn)過程為：主DPB告警檢測模塊檢測各個告警的狀態(tài)，檢測出告警狀態(tài)發(fā)生改變的告警項。告警屏蔽模塊首先根據(jù)告警項之間的優(yōu)先級關系對這些告警項進行屏蔽處理，高優(yōu)先級的告警項優(yōu)先上報，低優(yōu)先級的告警項待高優(yōu)先級的告警項恢復正常后再進行上報；然后將告警項的告警狀態(tài)上報給各個模塊或者單元。一方面，主DPB將告警狀態(tài)上報給網(wǎng)管中心；另一方面，主DPB將告警狀態(tài)通知主DPB告警處理單元，主DPB告警處理單元收到信息后進行應急處理。同時，主DPB將告警狀態(tài)通過RS232總線告知備DPB，備DPB收到信息后，通過告警信息解析模塊解析信息。一方面，備DPB將告警狀態(tài)上報給網(wǎng)管中心；另一方面，備DPB將告警狀態(tài)告知備DPB告警處理單元，備DPB告警處理單元收到信息后進行應急處理。
1.2 備DPB通知模塊與主DPB告警解析模塊的信息交互
圖3為備DPB通知模塊與主DPB告警解析模塊的信息交互示意圖。初始上電時，首先判斷DPB的工作狀態(tài)。若DPB為主DPB，判斷告警項的告警狀態(tài)，如果告警狀態(tài)發(fā)生改變，將告警狀態(tài)發(fā)送給備DPB的主DPB告警信息解析模塊。若收不到備DPB的告警回復信息，則下次繼續(xù)發(fā)送；若收到備DPB的告警回復，停止發(fā)送。初始上電時，若DPB為備DPB，則向主DPB發(fā)同步信息包，主動查詢主DPB共享告警項的告警狀態(tài)，實現(xiàn)初始上電時兩塊DPB告警信息的同步。此后備DPB通過主DPB告警信息解析模塊解析主DPB傳來的告警信息，實現(xiàn)兩塊DPB告警信息的同步。
1.3 DPB與網(wǎng)管中心的信息交互
圖4為DPB與網(wǎng)管中心的信息交互示意圖。若DPB告警狀態(tài)發(fā)生改變，則DPB將告警狀態(tài)上報給網(wǎng)管中心。若DPB規(guī)定時間內(nèi)收到網(wǎng)管中心的告警響應信息，則改變告警項的同步狀態(tài)，停止上報。若沒有收到網(wǎng)管中心的告警響應消息，則按照告警重發(fā)處理機制繼續(xù)上報告警消息。
告警重發(fā)處理過程如圖5所示。DPB上報告警信息后，在規(guī)定的時間內(nèi)如果收到網(wǎng)管中心的告警確認，則表明本次告警信息上報成功，停止上報；如果沒有收到網(wǎng)管中心的告警確認，則表明本次告警信息上報失敗，DPB繼續(xù)上報告警。如果連續(xù)3次告警信息上報失敗，DPB停止上報，在間隔一個規(guī)定的時間后繼續(xù)上報告警；如果再連續(xù)3次失敗，則在間隔一個規(guī)定的時間后繼續(xù)。如此循環(huán)上報，直至收到網(wǎng)管中心的告警響應[8]。
告警重發(fā)特殊情況處理如下：在循環(huán)上報告警過程中產(chǎn)生了新的告警，則新的告警信息與原來沒有確認的告警信息一起上報，原來已確認的告警信息不上報，循環(huán)重新開始[9]。
2 RU告警信息同步的軟件實現(xiàn)
數(shù)字光纖直放站選擇性能穩(wěn)定、功耗低的ARM7微處理器作為主控制器，搭載VxWorks操作系統(tǒng)[10-12]來完成軟件架構的搭建。
雖然告警同步實現(xiàn)過程的軟件平臺已經(jīng)確定，但如何實現(xiàn)告警項的管理仍然很棘手。對于每個告警項而言，告警項的要素很多，要素之間不是簡單地羅列而是有著某種邏輯關系。如何實現(xiàn)告警檢測時間的管理，如何實現(xiàn)循環(huán)上報中時間的管理，在上報過程中如何實現(xiàn)新舊告警的邏輯關系等，這些都是需要考慮的問題。
基于以上問題，本文采用單個結構體及結構體數(shù)組來實現(xiàn)對告警項各個要素的管理。告警信息管理結構體和告警上報控制結構體如下。其中，成員AlmTimersCnt為告警檢測總時間計數(shù)器，實現(xiàn)了告警項檢測時間的管理；告警上報控制結構體中的成員NextSendTime為告警項下次上報的時間，用來實現(xiàn)循環(huán)上報中時間的管理；成員AlmRptTryCnt為告警項上報總次數(shù)，與成員NextSendTime一起來實現(xiàn)新舊告警項上報的邏輯關系。
告警信息管理結構體組成成員：
typedef struct alarm_info
{
UINT8 AlmIndex；/*告警項的索引號*/
UINT8 AlarmEna；/*告警項的使能開關*/
UINT8 CurAlmState；/*告警項的當前狀態(tài)*/
UINT8 SyncAlmState；/*告警項網(wǎng)管中心的同步狀態(tài)*/
UINT8 Rs232SyncAlmState；/*告警項鄰板的同步狀態(tài)*/
UINT8 AlmProSyncState；/*告警處理單元的同步狀態(tài)*/
UINT8 AlmRptState；/*告警項的上報狀態(tài)*/
UINT8（*IsAlmRaise）（void）；/*告警項檢測函數(shù)的地址*/
UINT32 AlmRaiseCnt；/*告警項異常次數(shù)計數(shù)器*/
UINT32 AlmIdleCnt；/*告警項正常次數(shù)計數(shù)器*/
UINT32 AlmTimersCnt；/*告警項檢測總時間計數(shù)器*/
}
告警上報控制結構體組成成員：
typedef struct alarm_rpt_ctrl
{
UINT32 NextSendTime；/*告警項下次上報的時間*/
UINT32 AlmRptTryCnt；/*告警項上報的次數(shù)*/
}
告警信息同步過程的關鍵代碼如下。其中，AlmRaiseCheck函數(shù)為告警檢測模塊的代碼實現(xiàn)，AlmMaskCheck函數(shù)為告警屏蔽模塊的代碼實現(xiàn)，AlmRptCheck函數(shù)為網(wǎng)管中心上報模塊的代碼實現(xiàn)，AlmProRptCheck函數(shù)為告警處理單元通知模塊的代碼實現(xiàn)，AlarmSync函數(shù)為備DPB告警通知模塊與主DPB告警信息解析模塊信息交互的代碼實現(xiàn)。
LOCAL void AlarmManTask（void）
{
UINT8 AlmProTimer=0；
wdStart（SampleTimerId，（int）AlmSampleTime，
?。‵UNCPTR）AlmSampleTimer，0）；
AlmResetRptTimer（）；
while（1）{
semTake（semAlmSampleT，WAIT_FOREVER）；
AlmRaiseCheck（）；
AlmMaskCheck（）；
AlmRptCheck（）；
if（（（AlmProFlag==0）&&（AlmProTimer++>8））||
?。ˋlmProFlag==1））{
AlmProRptCheck（）；
AlmProTimer=0；
AlmProFlag=1；
}
AlarmSync（）；
taskDelay（5）；
}
printf（"!!!Exit AlarmManTask...Error，errno=0x%08X\n"，
errnoGet（））；
return；
}
3 告警信息同步實現(xiàn)過程的測試與結果
測試平臺分為硬件平臺與軟件平臺。硬件平臺為PC、調(diào)試串口和數(shù)字光纖直放站；軟件平臺為串口超級終端軟件和網(wǎng)管中心的網(wǎng)管軟件。圖6為串口的超級終端信息打印圖，主DPB檢測到告警狀態(tài)發(fā)生改變時，將告警項的狀態(tài)信息按照圖中的組包格式發(fā)送給備DPB，主DPB收到告警響應消息后停止發(fā)送。圖7為網(wǎng)管中心告警監(jiān)控界面，其中紅色按鈕表示告警項產(chǎn)生告警，綠色按鈕表示告警項告警恢復。
告警信息同步過程的測試分為三個層次：告警檢測的測試、備DPB通知模塊與主DPB告警解析模塊的信息交互的測試和DPB與網(wǎng)管中心的信息交互測試[5-7]。測試時，數(shù)字光纖直放站按照圖1所示連接方式組網(wǎng)。告警檢測環(huán)節(jié)主要測試告警項是否產(chǎn)生誤告警及非法告警，采用參考文獻[6]中遍歷的方法進行測試。經(jīng)測試發(fā)現(xiàn)，沒有產(chǎn)生誤告警及非法告警。另外兩種測試采取手動制造告警的方式進行驗證，測試中以電源1故障告警和輸入電壓過壓告警為例進行說明。
首先，手動制造電源1故障告警、輸入電壓過壓告警，主DPB按照圖6所示格式組包，串口打印出主備DPB間的信息交互過程；同時網(wǎng)管中心收到了兩塊DPB上報的告警數(shù)據(jù)，電源1故障告警及輸入電壓過壓告警燈變?yōu)榧t色。然后，手動制造電源1故障告警恢復、輸入電壓過壓告警恢復，主DPB按照圖6所示格式組包，串口打印出主備DPB間的信息交互過程，同時網(wǎng)管中心收到了兩塊DPB上報的告警恢復數(shù)據(jù)，電源1故障告警及輸入電壓過壓告警燈變?yōu)榫G色。
4 結論
本文設計了RU告警信息的同步實現(xiàn)方案，在射頻設備或者DPB出現(xiàn)故障時，該方案既可以及時將告警狀態(tài)上報給網(wǎng)管中心，利于設備的維護；又可以在維修人員未到達前，對相關硬件進行調(diào)整，保證信號的可靠傳輸。該方案提高了系統(tǒng)的穩(wěn)定性與健壯性。通過測試驗證了該方案的可行性，可適用于安全性較高的領域。
參考文獻
[1] 劉立海.數(shù)字光纖直放站特性及其在GSM-R無線覆蓋中的應用分析[J].鐵道通信信號，2012（9）：30-35.
[2] 鐘楊斌.基站覆蓋延伸系統(tǒng)在無線網(wǎng)絡覆蓋優(yōu)化中的應用研究[D].北京：北京郵電大學，2008.
[3] 高婷婷.鐵路GPRS系統(tǒng)冗余備份的研究[J].鐵路通信信號工程技術，2013（S1）：250-254.
[4] 洪治.淺談高速鐵路GSM-R系統(tǒng)干擾現(xiàn)狀及對策[J].中國無線電，2013（3）：28-29.
[5] 蘇潔，溫蕾.直放站監(jiān)控管理告警處理機制及測試方法分析[J].電信網(wǎng)技術，2010（3）：57-60.
[6] 敖姣.直放站調(diào)測系統(tǒng)軟件設計與研究[D].武漢：武漢郵電科學研究院，2009.
[7] WCDMA直放站嵌入式監(jiān)控終端研制[D].成都：電子科技大學，2007.
[8] GB/T 1.1-2009.鐵路數(shù)字移動通信系統(tǒng)（GSM-R）光纖直放站網(wǎng)絡管理系統(tǒng)[S].2009.
[9] YD/T 2231-2011.2 GHz WCDMA數(shù)字蜂窩移動通信網(wǎng)模擬直放站設備網(wǎng)管接口技術要求[S].2011.
[10] 張培輝.基于VxWorks和MPC565無人機飛行控制軟件設計與開發(fā)[D].南京：南京航空航天大學，2012.
[11] 張林，王芙蓉.VxWorks嵌入式實時系統(tǒng)任務機制的研究[J].微型機與應用，2005，24（3）：11-13.
[12] 廖崇琦，文臣，鄧文，等.一種基于VxWorks的可重構軟件框架設計[J].微型機與應用，2013，32（12）：22-24.