鄭琳

（中國民用航空汕頭空中交通管理站，汕頭 515000）

0 引言

空管智能化的進一步發(fā)展，空管自動化系統(tǒng)成為一個數據豐富、邏輯復雜的綜合信息處理系統(tǒng)。為了提高運維能力和效率，根據民航局空管局的行業(yè)標準要求，空管自動化廠家提供了相關的系統(tǒng)運行日志。日志文件的記錄雖然對運維人員在排查故障時發(fā)揮著重要作用，但是，當前日志普遍存在信息冗余度高、邏輯設計復雜等特點，導致采用人工診斷的方式逐行檢查日志耗時相對較長、全面性相對較差，難以滿足高效率、高質量的運維要求。因此，通過日志分析系統(tǒng)對系統(tǒng)日志進行科學的分析和重現對技術保障部門運維人員有著切實可行的意義。本文根據中國民用航空汕頭空中交通管理站（以下簡稱民航汕頭空管站）的空管自動化系統(tǒng)在實際應用中的工作經驗，提出一種日志分析方法并通過軟件設計實現。

1 系統(tǒng)日志概述

空管自動化系統(tǒng)主要分為雷達數據處理和飛行計劃處理兩個部分。在雷達數據處理過程中除了飛行位置和姿態(tài)等顯示外，管制員最密切關注和時常反饋的即是飛行航班的相關狀態(tài)。軟件設計以民航汕頭空管站所采用的南京萊斯空管自動化系統(tǒng)NUMEN2000為例，主要針對系統(tǒng)在FDP服務器/home/atc/log/fdp_log路徑下部署的AllLog*.log（以下簡稱AllLog日志）和RDP服務器/home/atc/log/radar_log路徑下部署的*_SDP_couple.log（以下簡稱couple日志）多類型日志進行合并分析和重現。系統(tǒng)日志以每小時一個文本文件的形式存儲，目前每個AllLog日志平均有六萬行，每個couple日志平均有一萬行。而從一個航班計劃的生成到結束，航班生命周期普遍需要經歷4-6個小時，這無疑對人工診斷和故障排查增加了難度。因此，如何基于廠家開發(fā)人員編寫的系統(tǒng)日志產生規(guī)則，梳理、分析系統(tǒng)已產生日志的具體內容和規(guī)則是軟件系統(tǒng)實現和快速定位故障的關鍵性步驟。

2 日志分析與系統(tǒng)實現

2.1 日志分析方法

軟件主要通過C#設計實現，將日志文件中的記錄提取并轉換為滿足使用需求的結構化描述。首先通過文件流遍歷項目指定路徑下的已采集到的日志文件的所有行，再逐行解析，通過正則表達式匹配、解析目標數據字段等預處理并存儲到航班類objectPLAN對象屬性中。方法關注、解析的字段包含有：日志記錄時刻、航班號、二次代碼、24位地址碼、計劃狀態(tài)、相關狀態(tài)、相關因素/相關結果、雷達狀態(tài)、起飛/落地機場、預起/實起時間、飛行總時間、實落時間、航路固定點、預計過點時間、出界點/時間、入界點/時間、報文、扇區(qū)、航跡號、計劃號、FIPS系統(tǒng)推送標識等80個航班類相關的屬性（含12個屬性變化值標識）。如匹配AllLog日志日志行的status字段而非日志塊中的STATUS作為航班計劃狀態(tài)屬性的描述，C#正則表達式可以設計如下：“Regex reg_status=new Regex（"status（?:=|:）（.+?（，|））"）”。

每個日志行的內容格式各不相同，包含的目標數據字段也有差異。根據實際日志結構，可以將日志解析分為日志行解析和日志塊解析。日志行解析通過該行逐字段匹配，生成一個航班類對象、過濾不重要信息并將可以匹配到的字段值存儲到定義的對象屬性中。日志塊解析通過匹配塊首行的字符串格式，連續(xù)性地讀取后續(xù)多行日志，根據分類生成一個或多個航班類對象。這里提到的日志行和日志塊（連續(xù)的多行日志）同時分布在同一個日志文件中且一般多次穿插出現。區(qū)分日志行符合日志行解析還是日志塊解析只能通過匹配塊首行字符串的多種可能性正則表達式來實現，滿足匹配的實施對應類型日志塊的邏輯解析，不滿足的則實施日志行解析。

其中日志塊解析的識別格式有以下兩種，如圖1。

（1）“固定點日志塊”，通過解析塊首行的num字段值遍歷后續(xù)值數量的日志行，將塊首行的航班號字段值和計劃號字段值賦值給后續(xù)多行類對象的對應屬性；即塊首行不生成類對象，首行后的num行日志都生成一個類對象，屬性既包括本行解析字段，也包括塊首行的航班號和計劃號屬性。

（2）“相關信息日志塊”，通過解析塊首行的格式，遍歷后續(xù)8行日志，合并所有字段從而生成一個類對象；即整個日志塊只生成一個類對象，屬性由塊內所有行（含塊首行）日志能夠解析的字段組成。

軟件定義鏈表（LinkedList）作為存儲一系列航班類對象的數據結構。軟件依次遍歷AllLog日志和couple日志所有行后，生成多個帶有時標（日志記錄時刻屬性，格式為yyyyMMddHHmmss，精確到秒）的航班類對象。同時，需要經歷條件篩選、鏈表插入、對象去重、對象合并等多個中間步驟才能生成一個完整的、無冗余、合理的以時間為線索的滿足航班排查的鏈表。在條件篩選步驟中，軟件設置有前臺交互窗口，運維人員可以選擇排查航班的屬性并輸入對應的屬性值，可選屬性有航班號、二次代碼或地址碼。軟件后臺會根據輸入的航班屬性值匹配所有航班類對象，匹配成功的才能實施鏈表插入。而對象合并指的是因存在多行時標一致的日志（即可能存在多個時標但屬性或屬性值不一樣的航班類對象），故針對同個時標的多個航班類對象進行合并。該步驟既要將包含有不同屬性的日志行對象合并，也需要將有值更新的對象屬性進行合并，從而合并成單一時刻的鏈表對象，以滿足合理化的對象鏈表設計，具體流程可以參考圖2。

圖1 日志解析

圖2 系統(tǒng)實現流程

2.2 方法實現

排查故障時，技術人員會著重關注日志中可能引發(fā)事件變化的屬性和發(fā)生變化的時間節(jié)點。因此，軟件運用該種排查思路來實現下一步的日志分析和重現，故將航班類對象的部分關鍵屬性（以下簡稱基礎屬性）進行值比較，同時將結果存儲到對象定義的“屬性變化值標識”屬性中（以下簡稱變化值屬性），以便將這些變化值屬性的特定值作為判斷航班事件變化的節(jié)點，從而幫助實現系統(tǒng)對于數據處理過程的重現。同時，考慮到航班類對象有newstatus新狀態(tài)值和oldstatus舊狀態(tài)值的字段解析，可以在一定程度還原系統(tǒng)對于status基礎屬性的變化處理，因此也加入到生成航班類status_change變化值屬性的生成邏輯中。

各變化值屬性定義的關聯基礎屬性包括有，二次代碼、24位地址碼、計劃狀態(tài)、扇區(qū)、雷達狀態(tài)、相關狀態(tài)、報文、相關因素/結果、航跡號。軟件會遍歷已生成的完整鏈表，首先通過比較每一個對象與前一個對象的基礎屬性是否一致來定義布爾類型的變化值屬性值。即若前后對象的基礎屬性值不同，則該對象的變化值屬性值為true。其中，因考慮到某對象需要比較的基礎屬性可能存在沒有屬性描述和屬性值為空的區(qū)別，故當被比較的對象沒有基礎屬性的描述時，算法會往鏈表頭方向繼續(xù)比較，直到找到有該基礎屬性描述的對象才終止該項比較。

根據民航汕頭空管站對于所屬NUMEN2000的運行經驗及廠家的協助，現此梳理并形成現場空管自動化系統(tǒng)對于數據處理過程的日志知識庫（產生規(guī)則）來實現日志分析與數據重現。飛行計劃生命周期，管理著一個航班飛行計劃由生成到取消全過程的狀態(tài)轉變?，F場的空管自動化系統(tǒng)飛行計劃狀態(tài)主要有，未來狀態(tài)（FUR）、靜止狀態(tài)（NACT）、預激活狀態(tài)（PREA）、激活狀態(tài)（ACT）、終止狀態(tài)（FIN）和取消狀態(tài)（CNL）。不同的觸發(fā)事件和飛行事件，可能推動生命周期的發(fā)展，導致計劃狀態(tài)的改變和航班的相關狀態(tài)改變。而報文和相關因素作為觸發(fā)事件的關鍵因素，主要借助航班類對象定義的變化值屬性來分析處理過程日志。因此，形成了以報文、計劃狀態(tài)、二次代碼、24位地址碼、時間檢查、航路檢查、相關狀態(tài)、相關結果、航跡號為首要因素的日志知識庫。在首要因素的判斷條件下，再開展多條匹配規(guī)則的層次化判斷，輔以進行異常提示，以形成一份完整的、準確的、合理的日志重現報告，從而幫助技術保障人員進行故障事件排查。最終形成的軟件界面實現如圖3。

圖3 軟件平臺界面

3 結語

本文以民航汕頭空管站運行現場的NUMEN2000空管自動化系統(tǒng)關于數據處理過程在日志中的記錄為基礎，同時考慮飛行航班的基礎屬性和觸發(fā)事件的關鍵因素，提出一種空管自動化日志分析方法，并通過軟件設計實現。現場通過真實案例驗證了軟件的實用性和準確性，可以有效提高技術保障人員快速排查和定位故障，具有良好的實際應用性能。