AIDC簡約模式交互測試系統的設計與實現

（民航珠海進近管制中心，珠海 519015）

1 AIDC簡介

AIDC（Air Trafic Services Inter-facility Data Communication），即空中交通服務設施之間的通信，是由亞太民航組織制定的亞太地區相鄰管制區間進行航班管制電子移交的標準協議[1]。如圖1所述，AIDC協議將一個完整的管制移交過程分解為三個階段：通知階段、協調階段和移交階段，其主要作用是在不同階段通過報文數據的交互來完成相鄰管制單位之間的航班管制移交，相對電話移交大大提升了管制移交效率。在簡約模式下，主要的AIDC報文有ABI（預計邊界報，可不發），EST（預計飛越報），ACP（協調接受報），TOC（管制移交報）以及AOC（移交接受報）。除此之外，還有LAM（邏輯確認報），用于通報對方已對相應報文進行處理。

圖1 AIDC簡約模式報文交互示意圖

2 系統功能需求

AIDC簡約模式交互測試系統設計的主要目的是和空管自動化系統進行AIDC報文交互以測試自動化系統的AIDC功能。因此，必須具備以下功能：

（1）RS232協議的報文接口，可接收發送異步報文。

（2）符合MH/T 4007 《民用航空飛行動態固定電報格式》[2]和MH/T 4008《空管雷達及管制中心設施間協調移交數據規范》[3]的AIDC報文解析處理，以及生成組裝。

（3）簡單飛行計劃手動或自動生成（根據EST報）和顯示，以及狀態顏色更新。

（4）接收和發送報文的顯示、存儲和查詢。

3 系統結構和運行流程

根據功能需求，遵循模塊化的設計原則，將系統劃分為下面幾個模塊：計劃生成模塊、顯示模塊、報文處理模塊、報文組裝模塊、報文發送模塊、報文接收模塊、存儲和查詢模塊。各個模塊之間的關系可以用系統運行流程圖來表示，如圖2所示。

AIDC測試流程從創建計劃開始，系統支持人工創建一份計劃，或者收到自動化系統拍發的EST報，按照EST報文中的內容自動生成計劃。生成計劃后，用戶可人工點擊界面上的計劃，在菜單中選擇手動發報至自動化系統，或者勾選自動回復按鈕后，系統將自動響應自動化系統拍發的報文，譬如自動化系統發送EST報至測試系統，測試系統自動回復LAM報和ACP報完成協調狀態。在顯示模塊上，每條計劃有EST，ACP，TOC和AOC四個圖標狀態，每個圖標有三種顏色，藍色代表未收到或者發送該報，黃色代表該報已經收到或者發出，但未發出或者收到對應的LAM報，綠色代表報文已經收到或者發出，且已經回復或者收到LAM報。

圖2 系統模塊運行流程圖

4 主要模塊實現

本系統采用C#作為開發語言，SQL server作為數據管理軟件。接下來簡要介紹幾個核心模塊的功能實現。

4.1 報文接收模塊

C#自帶SerialPort函數，可以控制串口的關閉以及讀寫串口數據。系統啟動后將讀取運行電腦的串口信息，顯示在串口選擇菜單中。用戶選擇串口后，系統打開相應串口，并將報文接收函數作為事件添加到SerialPort的DataReceived的委托中。每收到一個字符，就觸發一次報文接收函數。報文接收函數將字符存儲在字符串中，并判斷字符串的是否包含一份AIDC報文的頭尾，如果包含頭尾，則將該份報文截出，發送給報文處理模塊。

4.2 報文處理模塊

報文處理模塊取得報文接收模塊發送過來的報文后，按照MH/T 4008《空管雷達及管制中心設施間協調移交數據規范》以及ICAO（國際民航組織）規范文件《ICD AIDC ver3.0》的標準，將報文解析為各個編組及數據項。以一份ACP（協調接受報）報文為例：

DRB4372 251641 FF ZGACADAC 251641 ZGJDADTM

2.347492

-3.ZGAC231036

-4.181225164114

-5.0ED4

-（ACP-CSZ9910/A7035-ZSWZ-ZGSZ）

該報文可劃分為六個部分，按照上述排版，每行即為一個部分（此處僅為方便區分，與實際報文排版不同）。第一部分按照空格隔開，分別代表報文冠字及流水號、轉發時間、電報等級、收報地址、始發時間、發報地址；第二部分2.后跟發報方內部編號；第三部分3.后跟收報方地址前四個字符，以及所回復報文的第二部分內部編號，以此ACP報文為例，所回復的EST報文第二部分應為2.231036；第四部分4.后跟精確到秒的UTC時間，此處時間代表UTC時間2018年12月25日16時41分14秒；第五部分為5.0后跟CRC16校驗碼，校驗對象為第六部分括號以及括號內的內容，即報文正文；第六部分括號內為報文正文，以“-”分割為各個編組，符合MH/T 4008和MH/T 4007規范標準，本例中解析如下：編組3報文類別為ACP協調接受報，編組7航班號CSZ9910，A模式二次代碼7035，編組13起飛機場四字碼ZSWZ，編組16預計落地機場四字碼ZGSZ。

報文處理模塊完成報文解析后，先對報文進行CRC校驗，校驗不通過則不處理，校驗通過后根據不同報文類別觸發不同事件。詳情見表1。

表1 系統收到不同類型報文的響應

4.3 報文組裝模塊

系統可人工或者自動發送AIDC報文，發送前需要進行報文組裝。報文內容組裝時同樣按照MH/T 4007和MH/T4008、ICD AIDC ver3.0的標準進行組裝，此處不做贅述。需要強調的是，本系統發送的報文需要被自動化系統正常解析，因此必須滿足測試對象自動化系統的編碼要求。以美國Telephonics自動化系統為例，配置的AIDC碼型為IA5碼[4]，因此整份報文必須以16進制碼0x01（SOH：start of headline）開始，以16進制碼0x03（ETX end of text）結束，除此之外同時要在報文中四個正確位置加入連續三個字節0x0d（回車），0x0d，0x0a（換行）方能被正常解析。因此在完成報文內容的組裝之后，需要對待測自動化系統的AIDC報文轉化為16進制編碼進行分析，套用其中的編碼規則對系統完成報文發送前的最后組裝。

5 結束語

本文簡要介紹了簡約模式AIDC交互模擬測試系統的設計思路和幾個核心模塊實現方法。該系統是以輔助設備維護人員進行對自動化系統進行AIDC功能測試為目標，結合民航規章規范標準和實際工作經驗，基于C#和SQL編寫的一套測試工具，能從一定程度上滿足現行自動化系統的AIDC功能測試需求，具備廣泛的普適性，以及很大的擴展空間。希冀本文的介紹可對廣大民航業內同行起到少許啟發和借鑒意義，筆者經驗所限，疏漏在所難免，歡迎同行批評指教。