Thales雷達(dá)服務(wù)狀態(tài)過(guò)載告警的分析和處理

邱偉杰

摘要 隨著空管設(shè)備保障部門加大對(duì)thales雷達(dá)的技術(shù)研究，不僅縮短了設(shè)備運(yùn)維的周期，還節(jié)省了大量的維護(hù)資金，thales雷達(dá)的運(yùn)行保障逐漸趨于成熟。在目前航班量逐漸增大的情況下，thales雷達(dá)出現(xiàn)服務(wù)狀態(tài)過(guò)載告警的可能性增大，出現(xiàn)會(huì)更加頻繁。通過(guò)雷達(dá)信號(hào)結(jié)構(gòu)的解析，對(duì)thales雷達(dá)信號(hào)輸出選項(xiàng)和雷達(dá)傳輸信號(hào)路由優(yōu)化，已成功解決雷達(dá)信號(hào)服務(wù)狀態(tài)過(guò)載告警問(wèn)題。

【關(guān)鍵詞】thales 數(shù)據(jù)包 過(guò)載 溢出 緩存帶寬

雷達(dá)管制己成為空管部門的主要管制手段，雷達(dá)的良好覆蓋和信號(hào)穩(wěn)定的重要性逐漸凸顯。在國(guó)內(nèi)大部分地區(qū)，民航系統(tǒng)均部署有法國(guó)產(chǎn)的thales雷達(dá)系統(tǒng)，由于技術(shù)產(chǎn)權(quán)原因，空管設(shè)備保障部門針對(duì)thales雷達(dá)的設(shè)備維保工作長(zhǎng)期受制于國(guó)外廠商，致使空管運(yùn)行保障較為被動(dòng)。隨著空管加大對(duì)thales雷達(dá)的技術(shù)研究，提升自主維保能力，縮短了故障維修周期，還節(jié)省了大量的維護(hù)資金，thales雷達(dá)的運(yùn)行保障逐漸趨于成熟。

運(yùn)行以來(lái)，thales雷達(dá)多次出現(xiàn)雷達(dá)信號(hào)服務(wù)狀態(tài)過(guò)載告警，即“ATC SERVICESTATE OVERLOAD”告警，尤其是運(yùn)行超過(guò)十年以上的雷達(dá)，出現(xiàn)告警會(huì)更加頻繁。通過(guò)雷達(dá)信號(hào)結(jié)構(gòu)的解析，對(duì)雷達(dá)信號(hào)輸出選項(xiàng)和信號(hào)傳輸路由的優(yōu)化，己成功解決雷達(dá)信號(hào)服務(wù)狀態(tài)過(guò)載告警問(wèn)題。

1 Thales雷達(dá)信號(hào)數(shù)據(jù)格式

雷達(dá)信號(hào)格式可通過(guò)空管雷達(dá)信號(hào)監(jiān)控系統(tǒng)ATMM進(jìn)行抓包解析。經(jīng)抓包軟件讀取雷達(dá)送出的原始數(shù)據(jù)包作為樣例：

"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”。通過(guò)ATMM軟件進(jìn)行數(shù)據(jù)分析，如圖1所示。

00 00 01 00 1D……A0//數(shù)據(jù)包的開頭結(jié)尾，與HDLC數(shù)據(jù)格式有關(guān)。

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數(shù)據(jù)包內(nèi)容。

02 00 0B F0 16 75 02 C0 70 11 61//為ASTERIX002數(shù)據(jù)包內(nèi)容。

00 1D//數(shù)據(jù)幀長(zhǎng)度。

雷達(dá)原始數(shù)據(jù)包往往包含多個(gè)ASTERIX數(shù)據(jù)，經(jīng)ATMM系統(tǒng)經(jīng)抓包統(tǒng)計(jì)，其數(shù)據(jù)包長(zhǎng)度多數(shù)超過(guò)200字節(jié)。目前，雷達(dá)設(shè)備的PLINE端口既定9600bit/S傳輸速率的情況下，以此推算，扇區(qū)內(nèi)目標(biāo)數(shù)最多只能容納6個(gè)，即在雷達(dá)32個(gè)扇區(qū)中，每個(gè)扇區(qū)航班目標(biāo)最多6架次，超過(guò)即會(huì)出現(xiàn)隊(duì)列緩存溢出，雷達(dá)信號(hào)服務(wù)狀態(tài)告警，最終自動(dòng)化可能出現(xiàn)目標(biāo)大面積分裂。

2 Thales雷達(dá)信號(hào)服務(wù)狀態(tài)過(guò)載分析

Thales配置有功能較為強(qiáng)大的CBP控制軟件，所有參數(shù)配置和更改可經(jīng)過(guò)CBP軟件來(lái)實(shí)現(xiàn)。在早期Thales雷達(dá)上，雷達(dá)系統(tǒng)配備PLINEA和PLINE B兩個(gè)輸出接口設(shè)備，CBP軟件按照六個(gè)數(shù)據(jù)輸出口配置，每個(gè)Pline有三個(gè)口輸出雷達(dá)數(shù)據(jù)。

2.1 服務(wù)狀態(tài)過(guò)載告警

Thales雷達(dá)對(duì)信號(hào)的告警提示是按照PLINE數(shù)據(jù)端口來(lái)區(qū)分。雙PLINE六個(gè)數(shù)據(jù)端口分別命名為ATCl/ATC2/ATC3/ATC4/ATC5/ATC6。PLINE每個(gè)數(shù)據(jù)端口可以分別進(jìn)行輸出適配數(shù)據(jù)的配置，而不相互影響，端口具有一定的緩存空間，用于雷達(dá)數(shù)據(jù)輸出的隊(duì)列的存儲(chǔ)。

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

2.2 過(guò)載告警分析

雷達(dá)出現(xiàn)“ATC SERVICE STATEOVERLOAD”告警時(shí)，往往會(huì)首先認(rèn)為是相應(yīng)的PLINE故障，需要重啟相應(yīng)的PLINE設(shè)備。

此時(shí)，本地觀察IRIS監(jiān)控，目標(biāo)顯示正常，進(jìn)行雷達(dá)通道切換，故障現(xiàn)象依舊。本地LTM上ATC黃色告警，相應(yīng)PLINE對(duì)應(yīng)端口指示燈的Rl至R3出現(xiàn)一個(gè)或多個(gè)常亮，F(xiàn)A16或FA36對(duì)應(yīng)通道指示燈也同樣出現(xiàn)常亮狀態(tài);斷電重啟PLINE，故障現(xiàn)象會(huì)消失，但經(jīng)實(shí)際驗(yàn)證該方式并不能徹底解決問(wèn)題，故障只是暫時(shí)地緩解，運(yùn)行一段時(shí)間后會(huì)再次出現(xiàn)。

3 雷達(dá)信號(hào)服務(wù)狀態(tài)過(guò)載的解決辦法

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

3.1 雷達(dá)信號(hào)端口輸出選項(xiàng)優(yōu)化

經(jīng)過(guò)對(duì)告警分析，PLINE的ATCl/ATC2/ATC3/ATC4/ATC5/ATC6六個(gè)端口中，只有ATC5沒(méi)有出現(xiàn)過(guò)載告警提示，其余端口均出現(xiàn)。登錄thales本地CBP控制軟件，讀取其各個(gè)端口的輸出選項(xiàng)，如表l所示。

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

最后，通過(guò)關(guān)閉ATCl/ATC2/ATC3/ATC4/ATC6共五個(gè)端口的“042/笛卡爾坐標(biāo)計(jì)算位置”和“200/極坐標(biāo)下的航跡速度”選項(xiàng)的輸出，降低數(shù)據(jù)包8個(gè)字節(jié)，實(shí)現(xiàn)端口輸出數(shù)據(jù)優(yōu)化。同時(shí)，發(fā)現(xiàn)了ATC5的“170/航跡狀態(tài)”缺省輸出是不正確的情況，打開了選項(xiàng)輸出進(jìn)行了優(yōu)化。

3.2 雷達(dá)信號(hào)傳輸路由帶寬優(yōu)化

通過(guò)對(duì)雷達(dá)信號(hào)格式的解析，對(duì)端口選項(xiàng)進(jìn)行了優(yōu)化。因此，對(duì)信號(hào)傳輸路由優(yōu)化的目標(biāo)就顯得非常明確和簡(jiǎn)單，只需兩個(gè)步驟即可完成。

（1）在CBP上將各個(gè)端口的信號(hào)傳輸速率增大至19200bit/S;

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

至此，雷達(dá)信號(hào)服務(wù)狀態(tài)告警徹底解決，在正常航班狀態(tài)下，經(jīng)長(zhǎng)時(shí)間使用觀察，thales雷達(dá)系統(tǒng)未出現(xiàn)“ATC SERVICESTATE OVERLOAD”告警。

4 結(jié)束語(yǔ)

由于受限于thales的產(chǎn)品特性和技術(shù)產(chǎn)權(quán)原因，國(guó)外廠家出于技術(shù)保護(hù)并未給與我們空管設(shè)備維護(hù)人員設(shè)備軟硬件技術(shù)原理資料。我們通過(guò)對(duì)產(chǎn)品的研究，并結(jié)合工作經(jīng)驗(yàn)，分析并找到了解決thales雷達(dá)信號(hào)服務(wù)狀態(tài)過(guò)載告警的原因和解決辦法。此次故障的良好解決，維護(hù)人員的最大心得便是故障的排查一定要耐心細(xì)心，秉承尋根究底原則，找出問(wèn)題發(fā)生的深層原因，方能徹底的解決。希望維護(hù)人員的分析和經(jīng)驗(yàn)，能給與從事空管設(shè)備維護(hù)的同行以啟迪和參考。

參考文獻(xiàn)

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

[2]吳順君.雷達(dá)信號(hào)處理和數(shù)據(jù)處理技術(shù)[M].北京：電子工業(yè)出版社，2008.

[3]蔣小平，談?wù)凾hales雷達(dá)Pline的端口配置[J].空中交通管理，2008.

[4]高光輝.INDRA二次雷達(dá)數(shù)據(jù)格式分析[J].科技視界，2014.

[5]何川，李璐，二次監(jiān)視雷達(dá)目標(biāo)點(diǎn)跡分裂分析與凝聚方法[J]，科技視界，2014.