浅析空管自动化系统备降延误报引发的典型案例

刘子园

【摘 要】本文以南京莱斯空管自动化系统为例，介绍了空管自动化系统报文处理流程，并总结了日常维护工作中系统接收处理CPL（现行飞行变更报）报和DLA（延误报）报引发的典型案例及分析过程。

【关键词】空管自动化系统；报文处理；备降；延误

0 引言

空管自动化系统通过处理多雷达信号、飞行计划和动态电报，为空中交通管制员提供飞行态势显示、飞行相关动态信息和各项告警功能等，协助管制员完成空中交通指挥和疏导工作。随着民航事业的发展，国内航班量快速增长，空管自动化系统在空中交通管理体系中越来越突显其重要地位，有效地确保了管制辖区内的飞行安全，提高了飞行效率。

因为天气或者其它不可抗拒原因，使得一些航班返航、备降或者延误。空管自动化系统在处理这类报文时，有时会遇到由于报文时间、报文内容或者其它因素导致航班状态有异或其它问题，本文结合笔者所在单位使用的南京莱斯空管自动化系统，介绍系统处理报文机制及遇到此类问题时的分析过程。

1 莱斯空管自动化系统报文处理流程

莱斯空管自动化系统接收AFTN网（航空固定电信网）的民航电报，处理系统飞行计划有关的数据。系统能够处理AFTN格式电报、SITA（国际航空电信公司）格式电报，获取气象电报、航行通告的机场信息。系统能够处理AIDC（空中交通管制设施间数据通信）电报，实现管制中心间管制数据的协调和移交。系统能够自动或手工向外输出飞行电报，实现飞行数据的动态输出。

系统对接收的报文进行分类处理，气象电报移交至气象数据处理模块单独处理，AFTN电报、AIDC电报和SITA报进行报文解析处理，经处理后的正确报文，由主处理机发送到各席位的飞行计划显示席显示，并保存到数据库中；特殊报文（错报、部分SITA 报等）送至飞行计划处理席等待人工处理，人工处理后，保存至数据库中。

系统接收返航、备降CPL报处理过程：在系统分析报文后，若存在与报文相关的原计划，则修改原计划的落地计划，按CPL的航路修改计划的航路；若不存在原计划，则系统创建新计划。

2 典型案例

2.1 案例一

2.1.1 问题反馈

站调值班员反映NOK6320（曼谷-石家庄）航班备降太原，在进港动态列表看不到该航班信息，但在飞越动态列表中看得到该航班信息。同是备降航班，HBH3220（虹桥-石家庄）航班备降太原，却在进港动态列表和飞越动态列表中都能看到该航班信息。

2.1.2 问题分析

查看NOK6320航班收到的CPL报文，该报文第18编组中含有“RMK/ALTERNATE”标记，说明该CPL报文为备降报，编组16中的目的机场为新的备降机场。自动化系统在解析该报文后会将NOK6320航班的落地机场修改为备降机场，并将该航班计划移到飞越动态列表中。

查看HBH3220航班收到的CPL报文，该报文第18编组中无“RMK/ALTERNATE”标记。自动化系统在解析该报文后，认为不是该航班的备降报，会保持该航班原计划不变，即该计划仍在进港动态列表中，同时系统会在飞越动态列表中再新建一个航班号同为HBH3220的计划，因此在进港动态列表和飞越动态列表中都能看到该航班信息。

2.2 案例二

2.2.1 问题反馈

塔台管制员反映CUA5928航班，备降到石家庄，在管制过程中未自动相关。

2.2.2 问题分析

查看CUA5928航班相关报文，发现只收到一份CPL报，系统收到该报文时间为UTC（世界协调时）时间0601，因无FPL报或DEP（起飞报）报等其它报文，系统将收到CPL报的时间判断为起飞时间，与航班实际起飞时间超出2小时。而系统判断自动相关机制中有一条为“推算出航迹将要到达最近的计划航路报告点的时刻，与计划中的预测时刻比较，误差在1小时之内”，2小时已超出了这个设定值，因此航迹不会自动相关。

2.3 案例三

2.3.1 问题反馈

进近管制员反映CBJ5533（海口-石家庄）航班没有自动打印进程单，也没有自动相关。

2.3.2 问题分析

查看CBJ5533航班相关报文，该航班收到DLA报，报中预计起飞时间为UTC1820，而收到DEP报的时间为UTC1025，比DLA报中预起时间早了近八个小时。系统设定预起时间前两个小时后收到的DEP报才有效，即UTC1620后收到DEP报才有效。所以收到的DEP报不被系统承认，自然不能打印进程单。系统设定进入管制区前90分钟计划进入预激活状态，而由报文中预起时间UTC1820可知，飞机实际起飞时计划远没到预激活状态，因而也不能自动相关。

2.4 案例四

2.4.1 问题反馈

进近管制员反映KZU6425（出港航班、外航）航班打印出两份进程单，其中的机型和巡航高度信息有误。

2.4.2 问题分析

查看KZU6425航班相关报文和进程单，FPL报中的起飞落地机场为：ZBSJ-UNNT。两份DLA报中，一份起飞落地机场为ZBSJ-UATT，一份起飞落地机场为ZBSJ-UNNT。

起飞落地机场为ZBSJ-UATT的计划打印进程单是因为当时临时计划库里有这份计划，DLA报激活了此计划，并引用了城市航线班机对航路里的机型B767，因为城市航线班机对航路里无巡航高度，所以引用了默认高度9000。而起飞落地机场为ZBSJ-UNNT的计划虽然收到了FPL报，但此份FPL报不是由我们的站调值班员发的，这样的报文是无效的。城市航线班机对航路里的机型和FPL报里的一样，都是A310，但巡航高度没有，所以也默认9000。

2.5 案例五

2.5.1 问题反馈

塔台管制员反映两个备降石家庄的航班已落地，但在飞行计划栏中仍显示为起飞状态。

2.5.2 问题分析

查看两个航班相关报文，发现这两个航班均为收到ARR（落地报）报后，才收到CPL报。系统处理机制为航班落地后系统收到ARR报，计划将变为终止状态。但只要航班收到CPL报，系统仍会将航班状态变为起飞状态，只是计划状态不变，仍是终止状态。

3 结束语

通过对系统接收处理CPL报和DLA报引发的几个典型案例的分析，只有深入了解系统处理报文流程，航班状态机制，了解各种报文格式及编组，才能在日常工作中遇到相应问题时，迅速找到问题所在并解决问题，为管制部门提供更好的保障服务。

[责任编辑：薛俊歌]