關于THALES雷達引起自動化目標分裂的分析

林騰飛

摘要：本文對由THALES雷達傳輸異常引起的一連串自動化目標大面積分裂事件進行分析與總結。此次事件不屬于常見的硬件或軟件故障，這是由于外部環境條件發生變化導致的故障。近年來航班量急劇上升，雷達目標數據告警期間達到峰值，超出雷達安裝時預設的傳輸帶寬，傳輸延時導致了雷達輸出目標異常。現在筆者分享一下故障排查和處理過程，以供分析與探討。

關鍵詞：THALES雷達；傳輸速率異常；目標分裂

中圖分類號：TP393 文獻標識碼：A

文章編號：1009-3044（2019）08-0250-02

開放科學（資源服務）標識碼（OSID）：

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

1 設備組成及傳輸路由

1.1 設備組成

THALES雷達的傳輸分兩部分組成，一是雷達數據傳輸至傳輸設備，二是傳輸設備將雷達數據送至各個不同的地區。雷達傳輸由2個HUB、2個Pline組成，HUB之間和Pline之間互相獨立，分別傳輸THALES雷達主備通道的雷達數據，每個Pline設置了4個輸出端口，其中3個在用端口，1個備用端口。傳輸設備由1臺FA16和1臺FA36組成，FA16又分為廣州框和湛江框，分別把雷達數據送給廣州和湛江使用，傳輸路由則是由1臺光端機和2臺微波組成的3條路由傳輸網絡。

1.2 傳輸路由

THALES雷達將處理完成目標信息以網絡信號從雷達雙機的P7和P8端口出發，先經過兩路P7端口接入HUB RCMS/IRIS，作為監控信號連到LTM、STM和IRIS電腦。P8端口輸出的雷達信號分別輸入HUB A和HUB B，然后兩路雷達信號再通過網線傳輸至PLINE A和PLINE B，PLINE可用端口6個，PLINE A和PLINE B分別配置3個可用端口，雷達信號通過PLINE的6個端口傳輸至FA16廣州框、FA16湛江框、FA36。

2 故障現象及排查

2.1 故障告警

自2017年11月份以來，自動化系統出現數次大量雷達目標分裂情況，檢查單路雷達無異常，多路雷達信號融合后才出現雷達目標分裂情況，最后斷開湖光雷達信號后才恢復正常。故障期間，機務員在本地監控終端Iris上觀察雷達目標顯示正常，監控軟件RCMS上頻繁顯示ATC 1/2/3/4 SERVICE_STATE overload 2/3/4告警，平均5秒出現一次告警，隨后1秒內恢復正常。告警現象持續數分鐘后告警自動停止，雷達恢復正常。

2.2 排查過程

第一次故障：根據故障情況，初步判斷故障原因是故障期間航班量較大，雷達目標數量超出雷達單次最大處理能力，造成系統內部過載。

第二次故障時，通過安裝在航管樓的多雷達監控系統上截取到的PLINE A和PLINE B雷達數據包進行比較。A通道數據包指的是plineA的ATCC2端口送出的數據，該端口有告警，B通道數據包指的是plineB的ATCC5端口送出的數據，該端口無告警。詳細看表1，聯系到THALES雷達在14：00：30開始出現Overload告警，再進行數據對比，發現告警出現時，異常端口的時間戳比正常端口慢了5秒以上，此時，判斷是傳輸設備異常導致雷達Overload告警。

第三次出現此告警時，在Iris上觀察雷達目標顯示正常，切換雷達主備通道，發現故障現象依舊。更換HUB2，檢查發現RCMS上ATC黃色告警，且PLINE1指示燈R1至R3常亮靜止，PLINE2指示燈R1常亮靜止，R2閃爍，FA16對應通道指示燈與PLINE現象一致，FA36指示燈靜止；斷電重啟PLINE1，故障現象消失。將雷達3個HUB全部更換為交換機。

第四次出現此告警時，拿異常端口輸出的雷達數據包和正常的ATCC5端口輸出的數據包進行比對分析，發現正常端口輸出的雷達數據包配置與異常端口輸出的雷達數據包不一致，通過CBP軟件查看雷達端口配置，ATCC5端口的三個數據項（笛卡爾坐標計算位置、航跡狀態、極坐標下的航跡速度）沒有激活送出，聯系到原來發現的異常端口輸出的數據包延長較大，懷疑是因為各端口數據量過大導致傳輸延時，ATC5數據量少而沒有延時。

2.3 解決方案

解決方案分兩個步驟完成，第一步：修改Thales雷達的輸出選項，對雷達輸出數據項進行梳理，分成必送項、可選項，將可選項設置為FALSE狀態，必送項設置為TURE狀態，減少數據量，觀察降低了數據量的雷達是否還有告警。第二步：是呈文中南通導部對雷達信號傳輸系統速率進行統一修改，將傳輸速率由9.6K，改為19.2K，因傳輸設備的權限問題，我方僅修改雷達輸出速率。

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

1）點擊cbp rsm970s，進入cbp界面；

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

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

4）點擊ATCC1 UAP for Asterrix 1/2前雙鍵；

5）在彈出窗口中點擊Read，在UAP Cat 001找到“l001 042 is transmitted”和“l001 200 is transmitted”將Value值改為“false”，點擊“write”；

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

參考以上步驟更改channel 2中ATCC1/2/3/4/6的對應參數

修改送出ATCC5“170/航跡狀態”改為ture

1）點擊cbp rsm970s，進入cbp界面；

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

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

4）點擊ATCC5 UAP for Asterrix 1/2前雙鍵；

5）在彈出窗口中點擊Read，在UAP Cat 001找到“l001 170 is transmitted”，將Value值改為“ture”，點擊“write”；

6）參考以上步驟更改channel 2中ATCC5的對應參數。

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

1）點擊cbp rsm970s，進入cbp界面；

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

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

4）點擊Board 1 line 1 configuration前的雙鍵，出現description框，點擊右下角的read，在value列出現現在的狀態，然后在HDLC UI conf中的“speed”選擇“BSD 19200”，然后再點擊右下角的write，出現do you really want to modify the parameter in radar？ 點擊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中的對應參數

6）參考以上步驟更改channel 2中的對應參數。

3 總結

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

目標數據的傳輸的要求，若干數據包存在PLINE的緩存中，積壓過多導致數據包送入自動化系統的時雷達數據包延遲，造成航跡顯示目標分裂。當航班量繼續增長時，還會導致雷達信號輸出寄存器溢出，主用通道告警，最后雷達保護機制起作用，最終導致雷達數據輸出數據自動清零的現象，當輸出數據清零后雷達告警自動結束，雷達重新開始搜索目標后恢復數據輸出。

4 結束語

該故障有其特殊性，對我們以后的設備保障服務很有借鑒價值，希望可以預防此類事件再次發生，現在我們每年對信號占用的帶寬進行評估，必要時，調整雷達信號速率，提高傳輸設備的帶寬，以確保類似故障不再發生。

參考文獻：

[1] 張尉.二次雷達原理[M].北京：國防工業出版社，2007.

【通聯編輯：朱寶貴】