摘 要：本文阐述了某地NUMEN自动化系统相似航班号告警功能升级现场测试中SC告警失效的排查过程，通过深层次分析进程间信息流转，得出故障原因为扇区信息传递错误并最终定位故障软件。本文总结的故障分析定位法，可为今后技术部门处理软件故障提供参考。
关键词：空管自动化系统；相似航班号；告警失效；软件测试
1引言
在众多软件系统中，空管自动化软件由于其高复杂性、高效率性、高精度性和高安全性给软件功能升级带来了一系列的难题。软件测试验证是软件功能升级的第一道安全线，尽管软件版本提交现场前厂家已经做过充分测试，但现场测试时也不能掉以轻心。本文中的案例就是现场已经完成基本功能测试，在进行告警持续性验证时发生的偶发现象，只有当航迹数量足够多时才能复现SC告警失效，故障现象隐蔽。经厂家复核，全国现场相似航班号告警均有该问题，需要统一修改软件。
2SC告警失效现象
2020年5月，笔者测试NUMEN自动化系统相似航班号告警功能。将DBMS中的雷达参数“RDF_SCALL_A”设置为1，其他相似航班告警参数设为0。表示当同一航空公司航班号末尾超过2位（含）以上字符相同，位置相同，且航班均由同一个席位管制，系统进行相似航班号告警提醒。
.png)
3故障原因分析
3.1故障原因分析
相似航班号功能升级涉及6个模块：CETC_REP、CETC_SPS、CETC_RAD、CETC_SDD、CETC_ZLD、CETC_CALL(新增)。
检查DBMS配置正确，在02:35~03:22期间系统没有做过分合扇也没有发布数据或重启软件。02:41:32，航班BBB1356、BBB1256符合告警条件没有告警，直到5分钟后才开始告警，这期间没有对航班进行任何操作，以上分析可将故障定位至此次升级的软件。
3.2日志分析
测试期间日志中涉及的扇区、席位对应关系如表1所示。
.png)
1)CETC_RAD进程
《2020051402_SDP_radtag.log》日志：
①二次代码A6435挂简标牌BBB1356：
2020/05/14 02:41:32> 收到RADTAG命令0x0602> 发送源机器号=36
增加或修改RADTAG> code=6435 trackno=11> call=BBB1356 扇区号=8 CFL=(N)0(0ft) 自由文本=>
②二次代码A1537挂简标牌BBB1256：
2020/05/14 02:41:54> 收到RADTAG命令0x0602> 发送源机器号=36
增加或修改RADTAG> code=1537 trackno=58> call=BBB1256 扇区号=8 CFL=(N)0(0ft) 自由文本=>
③二次代码A2241挂简标牌BBB2356：
2020/05/14 02:44:50> 收到RADTAG命令0x0602> 发送源机器号=36
增加或修改RADTAG> code=2241 trackno=70> call=BBB2356 扇区号=8 CFL=(N)0(0ft) 自由文本=>
④二次代码A2241删除简标牌BBB2356：
2020/05/14 02:56:32> 收到RADTAG命令0x0602> 发送源机器号=36
删除RADTAG> call=BBB2356 code=2241 trackno=70>
CETC_RAD日志记录的36号机对二次代码做的增、删简标牌动作与笔者在ACSDD5所做操作一致，且简标牌都由区调8号扇区管制。
2)CETC_CALL进程
《2020051402-CALL_track.log》日志：
02:41，根据表1，CALL软件认为航班BBB1356在8号扇区（ACSDD5席位）、航班BBB1256在1号扇区（TWSDD2席位），与实际情况不符。日志记录如下：
2020/05/14 02:41:35> tracknum=11 call=BBB1356 sec[8]> begin
2020/05/14 02:41:56> tracknum=58 call=BBB1256 sec[1]> begin
统计2020051402-CALL_track.log日志中航班所属扇区如表2所示。
.png)
表2中日志记录的告警情况与SDD界面看到的SC告警失效现象一致。02:41:56，CALL认为BBB1356属于区调扇区、BBB1256属于塔台扇区，且处于不同的管制席位，不满足告警条件，因此不告警。02:44:51，CALL认为BBB1256、BBB2356都属于塔台席位产生告警。因此，尽管02:44:51有了SC告警，但以上航班的管制扇区实际为区调，其告警基础是错误的。在测试过程中，BBB1356、BBB1256、BBB2356也一直由区调ACSDD5席位管制，期间没有分合扇也没有移交给塔台，CETC_CALL日志中记录的sec[1]与事实不符。
3.3故障软件定位
上述案例就是由于RAD判断的扇区信息与CALL接收到的扇区信息不一致，导致符合相似航班号告警条件的航班没有产生SC告警。
本次升级与扇区属性相关的软件有CETC_RAD、CETC_ZLD、CETC_CALL。RAD负责确定航班所属扇区；ZLD是总联负责中间通信，接收扇区信息并发送给其他软件[1]；CALL根据扇区信息和航班号规则判断是否告警，信息流程如图6所示。
.png)
图6 扇区消息传递过程
RAD进程判断的扇区与CALL进程接收的扇区不一致，问题出在三个软件之间扇区消息的传递环节，需要修改软件。
3.4解决措施
经软件代码检查，发现航迹目标的管制扇区在取用前初始化方式不恰当。RAD进程将有飞行计划相关的目标和RADTAG（简标牌）目标打包到一帧航迹数据中，CALL进程解析时，如果RADTAG目标在数据帧中位置靠后，那么RADTAG目标的管制扇区会错误地取用前面的相关计划目标的扇区号，这种情况发生的概率极低，只有当已相关的航迹数量较多时才会偶尔出现。
此问题会导致符合告警条件的航班由于扇区解析错误不告警，或本来不应该提示告警的目标对错误地发出相似航班号告警，如本例中02:44:51错误认为BBB1256、BBB2356都属于TWR扇区产生告警。修改CETC_RAD和CETC_CALL软件后测试正常。
4结束语
本文对现场测试中发生的一起SC告警功能失效故障进行了分析，得出了造成该故障的原因为软件中的扇区信息不一致，需要修改对应功能的软件。本文总结的以日志分析定位问题软件的排故方法，希望能给技术人员以借鉴，掌握自动化软件排障工作的流程和思路。
参考文献
[1] 南京莱斯信息技术股份有限公司. NUMEN-2000 空管自动化系统技术手册[M]. 南京:南京莱斯信息技术股份有限公司, 2013.