關(guān)于THALES雷達(dá)引起自動(dòng)化目標(biāo)分裂的分析

林騰飛

摘要：本文對(duì)由THALES雷達(dá)傳輸異常引起的一連串自動(dòng)化目標(biāo)大面積分裂事件進(jìn)行分析與總結(jié)。此次事件不屬于常見的硬件或軟件故障，這是由于外部環(huán)境條件發(fā)生變化導(dǎo)致的故障。近年來航班量急劇上升，雷達(dá)目標(biāo)數(shù)據(jù)告警期間達(dá)到峰值，超出雷達(dá)安裝時(shí)預(yù)設(shè)的傳輸帶寬，傳輸延時(shí)導(dǎo)致了雷達(dá)輸出目標(biāo)異?！，F(xiàn)在筆者分享一下故障排查和處理過程，以供分析與探討。

關(guān)鍵詞：THALES雷達(dá)；傳輸速率異常；目標(biāo)分裂

中圖分類號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2019）08-0250-02

開放科學(xué)（資源服務(wù)）標(biāo)識(shí)碼（OSID）：

THALES雷達(dá)是湛江空管站2007年在湖光雷達(dá)站正式開放使用的二次雷達(dá)設(shè)備，它為湛江空管站提供了最迅速、準(zhǔn)確、連續(xù)、直接和豐富的雷達(dá)管制服務(wù)，眾所周知，雷達(dá)在空中交通管制起著重要的作用，稍有不慎，就會(huì)造成管制模式的改變，特別是現(xiàn)在的多雷達(dá)工作模式，一臺(tái)雷達(dá)的異常數(shù)據(jù)往往造成整個(gè)片區(qū)的數(shù)據(jù)異常，雷達(dá)覆蓋范圍內(nèi)的管制單位都會(huì)造成重大的影響，而THALES雷達(dá)設(shè)備運(yùn)行已經(jīng)接近十年，而這十年是我國(guó)民航事業(yè)的高速發(fā)展的時(shí)期，航班量逐年增加，THALES雷達(dá)及其傳輸設(shè)備的配置已漸漸無法滿足現(xiàn)在的航班大流量的使用要求。這次是湛江空管站近期發(fā)生的一起THALES雷達(dá)的傳輸引起的自動(dòng)化目標(biāo)大面積分裂故障。

1 設(shè)備組成及傳輸路由

1.1 設(shè)備組成

THALES雷達(dá)的傳輸分兩部分組成，一是雷達(dá)數(shù)據(jù)傳輸至傳輸設(shè)備，二是傳輸設(shè)備將雷達(dá)數(shù)據(jù)送至各個(gè)不同的地區(qū)。雷達(dá)傳輸由2個(gè)HUB、2個(gè)Pline組成，HUB之間和Pline之間互相獨(dú)立，分別傳輸THALES雷達(dá)主備通道的雷達(dá)數(shù)據(jù)，每個(gè)Pline設(shè)置了4個(gè)輸出端口，其中3個(gè)在用端口，1個(gè)備用端口。傳輸設(shè)備由1臺(tái)FA16和1臺(tái)FA36組成，F(xiàn)A16又分為廣州框和湛江框，分別把雷達(dá)數(shù)據(jù)送給廣州和湛江使用，傳輸路由則是由1臺(tái)光端機(jī)和2臺(tái)微波組成的3條路由傳輸網(wǎng)絡(luò)。

1.2 傳輸路由

THALES雷達(dá)將處理完成目標(biāo)信息以網(wǎng)絡(luò)信號(hào)從雷達(dá)雙機(jī)的P7和P8端口出發(fā)，先經(jīng)過兩路P7端口接入HUB RCMS/IRIS，作為監(jiān)控信號(hào)連到LTM、STM和IRIS電腦。P8端口輸出的雷達(dá)信號(hào)分別輸入HUB A和HUB B，然后兩路雷達(dá)信號(hào)再通過網(wǎng)線傳輸至PLINE A和PLINE B，PLINE可用端口6個(gè)，PLINE A和PLINE B分別配置3個(gè)可用端口，雷達(dá)信號(hào)通過PLINE的6個(gè)端口傳輸至FA16廣州框、FA16湛江框、FA36。

2 故障現(xiàn)象及排查

2.1 故障告警

自2017年11月份以來，自動(dòng)化系統(tǒng)出現(xiàn)數(shù)次大量雷達(dá)目標(biāo)分裂情況，檢查單路雷達(dá)無異常，多路雷達(dá)信號(hào)融合后才出現(xiàn)雷達(dá)目標(biāo)分裂情況，最后斷開湖光雷達(dá)信號(hào)后才恢復(fù)正常。故障期間，機(jī)務(wù)員在本地監(jiān)控終端Iris上觀察雷達(dá)目標(biāo)顯示正常，監(jiān)控軟件RCMS上頻繁顯示ATC 1/2/3/4 SERVICE_STATE overload 2/3/4告警，平均5秒出現(xiàn)一次告警，隨后1秒內(nèi)恢復(fù)正常。告警現(xiàn)象持續(xù)數(shù)分鐘后告警自動(dòng)停止，雷達(dá)恢復(fù)正常。

2.2 排查過程

第一次故障：根據(jù)故障情況，初步判斷故障原因是故障期間航班量較大，雷達(dá)目標(biāo)數(shù)量超出雷達(dá)單次最大處理能力，造成系統(tǒng)內(nèi)部過載。

第二次故障時(shí)，通過安裝在航管樓的多雷達(dá)監(jiān)控系統(tǒng)上截取到的PLINE A和PLINE B雷達(dá)數(shù)據(jù)包進(jìn)行比較。A通道數(shù)據(jù)包指的是plineA的ATCC2端口送出的數(shù)據(jù)，該端口有告警，B通道數(shù)據(jù)包指的是plineB的ATCC5端口送出的數(shù)據(jù)，該端口無告警。詳細(xì)看表1，聯(lián)系到THALES雷達(dá)在14：00：30開始出現(xiàn)Overload告警，再進(jìn)行數(shù)據(jù)對(duì)比，發(fā)現(xiàn)告警出現(xiàn)時(shí)，異常端口的時(shí)間戳比正常端口慢了5秒以上，此時(shí)，判斷是傳輸設(shè)備異常導(dǎo)致雷達(dá)Overload告警。

第三次出現(xiàn)此告警時(shí)，在Iris上觀察雷達(dá)目標(biāo)顯示正常，切換雷達(dá)主備通道，發(fā)現(xiàn)故障現(xiàn)象依舊。更換HUB2，檢查發(fā)現(xiàn)RCMS上ATC黃色告警，且PLINE1指示燈R1至R3常亮靜止，PLINE2指示燈R1常亮靜止，R2閃爍，F(xiàn)A16對(duì)應(yīng)通道指示燈與PLINE現(xiàn)象一致，F(xiàn)A36指示燈靜止；斷電重啟PLINE1，故障現(xiàn)象消失。將雷達(dá)3個(gè)HUB全部更換為交換機(jī)。

第四次出現(xiàn)此告警時(shí)，拿異常端口輸出的雷達(dá)數(shù)據(jù)包和正常的ATCC5端口輸出的數(shù)據(jù)包進(jìn)行比對(duì)分析，發(fā)現(xiàn)正常端口輸出的雷達(dá)數(shù)據(jù)包配置與異常端口輸出的雷達(dá)數(shù)據(jù)包不一致，通過CBP軟件查看雷達(dá)端口配置，ATCC5端口的三個(gè)數(shù)據(jù)項(xiàng)（笛卡爾坐標(biāo)計(jì)算位置、航跡狀態(tài)、極坐標(biāo)下的航跡速度）沒有激活送出，聯(lián)系到原來發(fā)現(xiàn)的異常端口輸出的數(shù)據(jù)包延長(zhǎng)較大，懷疑是因?yàn)楦鞫丝跀?shù)據(jù)量過大導(dǎo)致傳輸延時(shí)，ATC5數(shù)據(jù)量少而沒有延時(shí)。

2.3 解決方案

解決方案分兩個(gè)步驟完成，第一步：修改Thales雷達(dá)的輸出選項(xiàng)，對(duì)雷達(dá)輸出數(shù)據(jù)項(xiàng)進(jìn)行梳理，分成必送項(xiàng)、可選項(xiàng)，將可選項(xiàng)設(shè)置為FALSE狀態(tài)，必送項(xiàng)設(shè)置為TURE狀態(tài)，減少數(shù)據(jù)量，觀察降低了數(shù)據(jù)量的雷達(dá)是否還有告警。第二步：是呈文中南通導(dǎo)部對(duì)雷達(dá)信號(hào)傳輸系統(tǒng)速率進(jìn)行統(tǒng)一修改，將傳輸速率由9.6K，改為19.2K，因傳輸設(shè)備的權(quán)限問題，我方僅修改雷達(dá)輸出速率。

ATCC1/2/3/4/6“042/笛卡爾坐標(biāo)計(jì)算位置”和“200/極坐標(biāo)下的航跡速度”改為false；

1）點(diǎn)擊cbp rsm970s，進(jìn)入cbp界面；

2）選擇command命令，在下拉式菜單中選擇connect channel 1；

3）接上通道后，在第三行下拉菜單中，選擇ATCC1/ATCC4 configuration；

4）點(diǎn)擊ATCC1 UAP for Asterrix 1/2前雙鍵；

5）在彈出窗口中點(diǎn)擊Read，在UAP Cat 001找到“l(fā)001 042 is transmitted”和“l(fā)001 200 is transmitted”將Value值改為“false”，點(diǎn)擊“write”；

6）參考以上步驟更改ATCC2/3/4/6參數(shù)；

參考以上步驟更改channel 2中ATCC1/2/3/4/6的對(duì)應(yīng)參數(shù)

修改送出ATCC5“170/航跡狀態(tài)”改為ture

1）點(diǎn)擊cbp rsm970s，進(jìn)入cbp界面；

2）選擇command命令，在下拉式菜單中選擇connect channel 1；

3）接上通道后，在第三行下拉菜單中，選擇ATCC2/ATCC5 configuration；

4）點(diǎn)擊ATCC5 UAP for Asterrix 1/2前雙鍵；

5）在彈出窗口中點(diǎn)擊Read，在UAP Cat 001找到“l(fā)001 170 is transmitted”，將Value值改為“ture”，點(diǎn)擊“write”；

6）參考以上步驟更改channel 2中ATCC5的對(duì)應(yīng)參數(shù)。

ATCC1/2/3/4/5/6傳輸速率改為BSD 19200

1）點(diǎn)擊cbp rsm970s，進(jìn)入cbp界面；

2）選擇command命令，在下拉式菜單中選擇connect channel 1；

3）連接上通道后，在第三行小窗口中，選擇Physical line configuration；

4）點(diǎn)擊Board 1 line 1 configuration前的雙鍵，出現(xiàn)description框，點(diǎn)擊右下角的read，在value列出現(xiàn)現(xiàn)在的狀態(tài)，然后在HDLC UI conf中的“speed”選擇“BSD 19200”，然后再點(diǎn)擊右下角的write，出現(xiàn)do you really want to modify the parameter in radar？ 點(diǎn)擊yes，完成此修改；

5）參考以上步驟更改Board 1 line 2 configuration、Board 1 line 3 configuration、Board 4 line 1 configuration、Board 4 line 2 configuration和Board 4 line 3 configuration中的對(duì)應(yīng)參數(shù)

6）參考以上步驟更改channel 2中的對(duì)應(yīng)參數(shù)。

3 總結(jié)

THALES雷達(dá)的overload告警是由于在航班高峰時(shí)段湖光THALES雷達(dá)可以探測(cè)到的航班數(shù)量突然增大，導(dǎo)致雷達(dá)輸出端口數(shù)據(jù)量過大，而此時(shí)湖光雷達(dá)站至航管樓和廣州的FA16和FA36的9.6kbps的傳輸帶寬不能滿足THALES雷達(dá)的過量

目標(biāo)數(shù)據(jù)的傳輸?shù)囊?，若干?shù)據(jù)包存在PLINE的緩存中，積壓過多導(dǎo)致數(shù)據(jù)包送入自動(dòng)化系統(tǒng)的時(shí)雷達(dá)數(shù)據(jù)包延遲，造成航跡顯示目標(biāo)分裂。當(dāng)航班量繼續(xù)增長(zhǎng)時(shí)，還會(huì)導(dǎo)致雷達(dá)信號(hào)輸出寄存器溢出，主用通道告警，最后雷達(dá)保護(hù)機(jī)制起作用，最終導(dǎo)致雷達(dá)數(shù)據(jù)輸出數(shù)據(jù)自動(dòng)清零的現(xiàn)象，當(dāng)輸出數(shù)據(jù)清零后雷達(dá)告警自動(dòng)結(jié)束，雷達(dá)重新開始搜索目標(biāo)后恢復(fù)數(shù)據(jù)輸出。

4 結(jié)束語

該故障有其特殊性，對(duì)我們以后的設(shè)備保障服務(wù)很有借鑒價(jià)值，希望可以預(yù)防此類事件再次發(fā)生，現(xiàn)在我們每年對(duì)信號(hào)占用的帶寬進(jìn)行評(píng)估，必要時(shí)，調(diào)整雷達(dá)信號(hào)速率，提高傳輸設(shè)備的帶寬，以確保類似故障不再發(fā)生。

參考文獻(xiàn)：

[1] 張尉.二次雷達(dá)原理[M].北京：國(guó)防工業(yè)出版社，2007.

【通聯(lián)編輯：朱寶貴】