一种空管自动化系统日志分析方法的设计与实现

郑琳

（中国民用航空汕头空中交通管理站，汕头 515000）

0 引言

空管智能化的进一步发展，空管自动化系统成为一个数据丰富、逻辑复杂的综合信息处理系统。为了提高运维能力和效率，根据民航局空管局的行业标准要求，空管自动化厂家提供了相关的系统运行日志。日志文件的记录虽然对运维人员在排查故障时发挥着重要作用，但是，当前日志普遍存在信息冗余度高、逻辑设计复杂等特点，导致采用人工诊断的方式逐行检查日志耗时相对较长、全面性相对较差，难以满足高效率、高质量的运维要求。因此，通过日志分析系统对系统日志进行科学的分析和重现对技术保障部门运维人员有着切实可行的意义。本文根据中国民用航空汕头空中交通管理站（以下简称民航汕头空管站）的空管自动化系统在实际应用中的工作经验，提出一种日志分析方法并通过软件设计实现。

1 系统日志概述

空管自动化系统主要分为雷达数据处理和飞行计划处理两个部分。在雷达数据处理过程中除了飞行位置和姿态等显示外，管制员最密切关注和时常反馈的即是飞行航班的相关状态。软件设计以民航汕头空管站所采用的南京莱斯空管自动化系统NUMEN2000为例，主要针对系统在FDP服务器/home/atc/log/fdp_log路径下部署的AllLog*.log（以下简称AllLog日志）和RDP服务器/home/atc/log/radar_log路径下部署的*_SDP_couple.log（以下简称couple日志）多类型日志进行合并分析和重现。系统日志以每小时一个文本文件的形式存储，目前每个AllLog日志平均有六万行，每个couple日志平均有一万行。而从一个航班计划的生成到结束，航班生命周期普遍需要经历4-6个小时，这无疑对人工诊断和故障排查增加了难度。因此，如何基于厂家开发人员编写的系统日志产生规则，梳理、分析系统已产生日志的具体内容和规则是软件系统实现和快速定位故障的关键性步骤。

2 日志分析与系统实现

2.1 日志分析方法

软件主要通过C#设计实现，将日志文件中的记录提取并转换为满足使用需求的结构化描述。首先通过文件流遍历项目指定路径下的已采集到的日志文件的所有行，再逐行解析，通过正则表达式匹配、解析目标数据字段等预处理并存储到航班类objectPLAN对象属性中。方法关注、解析的字段包含有：日志记录时刻、航班号、二次代码、24位地址码、计划状态、相关状态、相关因素/相关结果、雷达状态、起飞/落地机场、预起/实起时间、飞行总时间、实落时间、航路固定点、预计过点时间、出界点/时间、入界点/时间、报文、扇区、航迹号、计划号、FIPS系统推送标识等80个航班类相关的属性（含12个属性变化值标识）。如匹配AllLog日志日志行的status字段而非日志块中的STATUS作为航班计划状态属性的描述，C#正则表达式可以设计如下：“Regex reg_status=new Regex（"status（?:=|:）（.+?（，|））"）”。

每个日志行的内容格式各不相同，包含的目标数据字段也有差异。根据实际日志结构，可以将日志解析分为日志行解析和日志块解析。日志行解析通过该行逐字段匹配，生成一个航班类对象、过滤不重要信息并将可以匹配到的字段值存储到定义的对象属性中。日志块解析通过匹配块首行的字符串格式，连续性地读取后续多行日志，根据分类生成一个或多个航班类对象。这里提到的日志行和日志块（连续的多行日志）同时分布在同一个日志文件中且一般多次穿插出现。区分日志行符合日志行解析还是日志块解析只能通过匹配块首行字符串的多种可能性正则表达式来实现，满足匹配的实施对应类型日志块的逻辑解析，不满足的则实施日志行解析。

其中日志块解析的识别格式有以下两种，如图1。

（1）“固定点日志块”，通过解析块首行的num字段值遍历后续值数量的日志行，将块首行的航班号字段值和计划号字段值赋值给后续多行类对象的对应属性；即块首行不生成类对象，首行后的num行日志都生成一个类对象，属性既包括本行解析字段，也包括块首行的航班号和计划号属性。

（2）“相关信息日志块”，通过解析块首行的格式，遍历后续8行日志，合并所有字段从而生成一个类对象；即整个日志块只生成一个类对象，属性由块内所有行（含块首行）日志能够解析的字段组成。

软件定义链表（LinkedList）作为存储一系列航班类对象的数据结构。软件依次遍历AllLog日志和couple日志所有行后，生成多个带有时标（日志记录时刻属性，格式为yyyyMMddHHmmss，精确到秒）的航班类对象。同时，需要经历条件筛选、链表插入、对象去重、对象合并等多个中间步骤才能生成一个完整的、无冗余、合理的以时间为线索的满足航班排查的链表。在条件筛选步骤中，软件设置有前台交互窗口，运维人员可以选择排查航班的属性并输入对应的属性值，可选属性有航班号、二次代码或地址码。软件后台会根据输入的航班属性值匹配所有航班类对象，匹配成功的才能实施链表插入。而对象合并指的是因存在多行时标一致的日志（即可能存在多个时标但属性或属性值不一样的航班类对象），故针对同个时标的多个航班类对象进行合并。该步骤既要将包含有不同属性的日志行对象合并，也需要将有值更新的对象属性进行合并，从而合并成单一时刻的链表对象，以满足合理化的对象链表设计，具体流程可以参考图2。

图1 日志解析

图2 系统实现流程

2.2 方法实现

排查故障时，技术人员会着重关注日志中可能引发事件变化的属性和发生变化的时间节点。因此，软件运用该种排查思路来实现下一步的日志分析和重现，故将航班类对象的部分关键属性（以下简称基础属性）进行值比较，同时将结果存储到对象定义的“属性变化值标识”属性中（以下简称变化值属性），以便将这些变化值属性的特定值作为判断航班事件变化的节点，从而帮助实现系统对于数据处理过程的重现。同时，考虑到航班类对象有newstatus新状态值和oldstatus旧状态值的字段解析，可以在一定程度还原系统对于status基础属性的变化处理，因此也加入到生成航班类status_change变化值属性的生成逻辑中。

各变化值属性定义的关联基础属性包括有，二次代码、24位地址码、计划状态、扇区、雷达状态、相关状态、报文、相关因素/结果、航迹号。软件会遍历已生成的完整链表，首先通过比较每一个对象与前一个对象的基础属性是否一致来定义布尔类型的变化值属性值。即若前后对象的基础属性值不同，则该对象的变化值属性值为true。其中，因考虑到某对象需要比较的基础属性可能存在没有属性描述和属性值为空的区别，故当被比较的对象没有基础属性的描述时，算法会往链表头方向继续比较，直到找到有该基础属性描述的对象才终止该项比较。

根据民航汕头空管站对于所属NUMEN2000的运行经验及厂家的协助，现此梳理并形成现场空管自动化系统对于数据处理过程的日志知识库（产生规则）来实现日志分析与数据重现。飞行计划生命周期，管理着一个航班飞行计划由生成到取消全过程的状态转变。现场的空管自动化系统飞行计划状态主要有，未来状态（FUR）、静止状态（NACT）、预激活状态（PREA）、激活状态（ACT）、终止状态（FIN）和取消状态（CNL）。不同的触发事件和飞行事件，可能推动生命周期的发展，导致计划状态的改变和航班的相关状态改变。而报文和相关因素作为触发事件的关键因素，主要借助航班类对象定义的变化值属性来分析处理过程日志。因此，形成了以报文、计划状态、二次代码、24位地址码、时间检查、航路检查、相关状态、相关结果、航迹号为首要因素的日志知识库。在首要因素的判断条件下，再开展多条匹配规则的层次化判断，辅以进行异常提示，以形成一份完整的、准确的、合理的日志重现报告，从而帮助技术保障人员进行故障事件排查。最终形成的软件界面实现如图3。

图3 软件平台界面

3 结语

本文以民航汕头空管站运行现场的NUMEN2000空管自动化系统关于数据处理过程在日志中的记录为基础，同时考虑飞行航班的基础属性和触发事件的关键因素，提出一种空管自动化日志分析方法，并通过软件设计实现。现场通过真实案例验证了软件的实用性和准确性，可以有效提高技术保障人员快速排查和定位故障，具有良好的实际应用性能。