Thales雷達服務狀態過載告警的分析和處理

邱偉杰

摘要 隨著空管設備保障部門加大對thales雷達的技術研究，不僅縮短了設備運維的周期，還節省了大量的維護資金，thales雷達的運行保障逐漸趨于成熟。在目前航班量逐漸增大的情況下，thales雷達出現服務狀態過載告警的可能性增大，出現會更加頻繁。通過雷達信號結構的解析，對thales雷達信號輸出選項和雷達傳輸信號路由優化，已成功解決雷達信號服務狀態過載告警問題。

【關鍵詞】thales 數據包 過載 溢出 緩存帶寬

雷達管制己成為空管部門的主要管制手段，雷達的良好覆蓋和信號穩定的重要性逐漸凸顯。在國內大部分地區，民航系統均部署有法國產的thales雷達系統，由于技術產權原因，空管設備保障部門針對thales雷達的設備維保工作長期受制于國外廠商，致使空管運行保障較為被動。隨著空管加大對thales雷達的技術研究，提升自主維保能力，縮短了故障維修周期，還節省了大量的維護資金，thales雷達的運行保障逐漸趨于成熟。

運行以來，thales雷達多次出現雷達信號服務狀態過載告警，即“ATC SERVICESTATE OVERLOAD”告警，尤其是運行超過十年以上的雷達，出現告警會更加頻繁。通過雷達信號結構的解析，對雷達信號輸出選項和信號傳輸路由的優化，己成功解決雷達信號服務狀態過載告警問題。

1 Thales雷達信號數據格式

雷達信號格式可通過空管雷達信號監控系統ATMM進行抓包解析。經抓包軟件讀取雷達送出的原始數據包作為樣例：

"oo OO Ol 00 1D FF 04 16 75 A0 07 4A1C OD BB BC F2 0D FE 89 07 92 73 38 07 3843 78 11 58 40 02 00 0B F0 16 75 02 00 70 11 61AO”。通過ATMM軟件進行數據分析，如圖1所示。

00 00 01 00 1D……A0//數據包的開頭結尾，與HDLC數據格式有關。

FF C4 16 75 A0 07 4A 1C OD BB BC F2OD FE 89 07 92 73 38 07 38 43 78 11 58 40//為ASTERIXO01數據包內容。

02 00 0B F0 16 75 02 C0 70 11 61//為ASTERIX002數據包內容。

00 1D//數據幀長度。

雷達原始數據包往往包含多個ASTERIX數據，經ATMM系統經抓包統計，其數據包長度多數超過200字節。目前，雷達設備的PLINE端口既定9600bit/S傳輸速率的情況下，以此推算，扇區內目標數最多只能容納6個，即在雷達32個扇區中，每個扇區航班目標最多6架次，超過即會出現隊列緩存溢出，雷達信號服務狀態告警，最終自動化可能出現目標大面積分裂。

2 Thales雷達信號服務狀態過載分析

Thales配置有功能較為強大的CBP控制軟件，所有參數配置和更改可經過CBP軟件來實現。在早期Thales雷達上，雷達系統配備PLINEA和PLINE B兩個輸出接口設備，CBP軟件按照六個數據輸出口配置，每個Pline有三個口輸出雷達數據。

2.1 服務狀態過載告警

Thales雷達對信號的告警提示是按照PLINE數據端口來區分。雙PLINE六個數據端口分別命名為ATCl/ATC2/ATC3/ATC4/ATC5/ATC6。PLINE每個數據端口可以分別進行輸出適配數據的配置，而不相互影響，端口具有一定的緩存空間，用于雷達數據輸出的隊列的存儲。

Thales雷達數據包是嚴格按照扇區輸出，系統將天線掃描一周4秒鐘（360°），均分成32個扇區分別打包數據輸出，每1/8秒會向PLINE相應的端口送出數據包，經隊列緩存送往FA16和FA36等接入設備。當PLINE某一端口數據包的數量超出其隊列緩存容量時，監控系統相應通道出現服務狀態過載告警，提示“ATC SERVICE STATE OVERLOAD”，并頻繁滾動出現。過載端口的雷達信號送至自動化系統會出現延遲，個別信號延遲甚至超過5S以上，經自動化處理后DP可能出現目標大面積分裂，如圖2所示，嚴重影響管制指揮。

2.2 過載告警分析

雷達出現“ATC SERVICE STATEOVERLOAD”告警時，往往會首先認為是相應的PLINE故障，需要重啟相應的PLINE設備。

此時，本地觀察IRIS監控，目標顯示正常，進行雷達通道切換，故障現象依舊。本地LTM上ATC黃色告警，相應PLINE對應端口指示燈的Rl至R3出現一個或多個常亮，FA16或FA36對應通道指示燈也同樣出現常亮狀態;斷電重啟PLINE，故障現象會消失，但經實際驗證該方式并不能徹底解決問題，故障只是暫時地緩解，運行一段時間后會再次出現。

3 雷達信號服務狀態過載的解決辦法

雷達之所以出現服務狀態告警其根本原因是PLINE端口隊列緩存不足，雷達信號數據包出現溢出。Thales雷達PLINE端口數據傳輸數據按照廠家安裝調試時初設9600bit/S，相應FA16和FA36傳輸速率往往也是考慮使用9600bit/S（S模式數據除外），在航班量不大的情況下，此種方式一般不會出現溢出告警，但航班量增大后過載告警的可能性增大。要徹底解決該問題，應從兩方面考慮：第一，在既定9600bit/S雷達數據傳輸速率的情況下，進一步優化PLINE端口輸出的選項，降低無效數據的占比;其次，提高FA16和FA36的傳輸帶寬。實際中，這兩種方法同時使用，方能徹底解決信號服務狀態過載告警問題。

3.1 雷達信號端口輸出選項優化

經過對告警分析，PLINE的ATCl/ATC2/ATC3/ATC4/ATC5/ATC6六個端口中，只有ATC5沒有出現過載告警提示，其余端口均出現。登錄thales本地CBP控制軟件，讀取其各個端口的輸出選項，如表l所示。

對PLINE輸出端口ATCl/ATC2/ATC3/ATC4/ATC5/ATC6的比對，可以明顯看出ATC5的選項打開較少，相對其他端口“042/笛卡爾坐標計算位置”、“100/MODE-C代碼和MODE-C代碼確認指示”、“170/航跡狀態”和“200/極坐標下的航跡速度”為禁止輸出，可降低ASTERIX數據包9字節。因此，其他端口信號服務狀態告警的情況下，ATC5沒有出現數據包的過載溢出，依然保持正常狀態。其他各端口“040/極坐標計算位置”選項和“042/笛卡爾坐標計算位置”選項同時開啟，并不合理，二者只需其一，導致數據資源浪費。

最后，通過關閉ATCl/ATC2/ATC3/ATC4/ATC6共五個端口的“042/笛卡爾坐標計算位置”和“200/極坐標下的航跡速度”選項的輸出，降低數據包8個字節，實現端口輸出數據優化。同時，發現了ATC5的“170/航跡狀態”缺省輸出是不正確的情況，打開了選項輸出進行了優化。

3.2 雷達信號傳輸路由帶寬優化

通過對雷達信號格式的解析，對端口選項進行了優化。因此，對信號傳輸路由優化的目標就顯得非常明確和簡單，只需兩個步驟即可完成。

（1）在CBP上將各個端口的信號傳輸速率增大至19200bit/S;

（2）登錄FA16和FA36控制終端，將對應傳輸鏈路帶寬增加至19200bit/S。

至此，雷達信號服務狀態告警徹底解決，在正常航班狀態下，經長時間使用觀察，thales雷達系統未出現“ATC SERVICESTATE OVERLOAD”告警。

4 結束語

由于受限于thales的產品特性和技術產權原因，國外廠家出于技術保護并未給與我們空管設備維護人員設備軟硬件技術原理資料。我們通過對產品的研究，并結合工作經驗，分析并找到了解決thales雷達信號服務狀態過載告警的原因和解決辦法。此次故障的良好解決，維護人員的最大心得便是故障的排查一定要耐心細心，秉承尋根究底原則，找出問題發生的深層原因，方能徹底的解決。希望維護人員的分析和經驗，能給與從事空管設備維護的同行以啟迪和參考。

參考文獻

[1]丁鷺飛，耿富錄，陳建春.雷達原理[M].西安：西安電子科技大學出版社.2002： P142-230.

[2]吳順君.雷達信號處理和數據處理技術[M].北京：電子工業出版社，2008.

[3]蔣小平，談談Thales雷達Pline的端口配置[J].空中交通管理，2008.

[4]高光輝.INDRA二次雷達數據格式分析[J].科技視界，2014.

[5]何川，李璐，二次監視雷達目標點跡分裂分析與凝聚方法[J]，科技視界，2014.