莱斯空管自动化系统雷达航迹与飞行计划无法自动相关典型案例分析

路 雯

（民航河北空管分局，河北 石家庄 050802）

0 引言

在日常工作中，笔者经常接到管制部门反映的一些问题，其中包括自动相关问题、进程单打印问题、自动发报问题等等，在这些问题中，雷达航迹和飞行计划自动相关问题占有相当大的比重。若某个航班不能实现自动相关，此时需要管制员在飞行动态显示席屏幕上找到与计划二次代码一致的航迹，并手动进行相关，这会浪费管制员一定的时间和精力。因此，自动相关功能非常重要。本文就雷达航迹与飞行计划无法自动相关这类问题选出几个典型案例进行分析讲解，供大家参考。

1 雷达航迹和飞行计划相关的定义及限制条件

所谓雷达航迹和飞行计划相关是指在雷达数据融合后的综合航迹和飞行计划功能产生的飞行计划之间建立一种链接关系，从而在飞行动态显示席（下文统称SDD）为雷达航迹挂上全标牌，为管制员提供航空器的位置、航班号等信息。这种链接关系可以通过系统的自动相关功能来实现，也可以通过管制员的人工干预来完成。

为了避免自动相关出错，进行配对判断时，雷达航迹和飞行计划需同时满足如下检查条件，才认为两者应该进行配对，有一条不满足则不会自动相关：

(1)计划的状态不属于静止、未来、取消、终止之一。

(2)航迹以前没有被人工相关、去相关过。

(3)航迹位于飞行情报区内，并且已经稳定更新了3个周期以上。

(4)航迹与飞行计划都具有二次代码，并且两个二次代码相同。

(5)和计划的二次代码相同的航迹同时只存在一个；和航迹的二次代码相同的计划同时只存在一个。

(6)航迹位置在飞行计划所描述的计划航路附近40公里以内。

(7)推算出航迹将要到达最近的计划航路报告点的时刻，与计划中的预测时刻比较，误差在1小时之内。

(8)航迹的飞行方向与本段计划航路的指向相差在70度之内。

在值班过程中，比较常见的影响雷达航迹和飞行计划自动相关的案例经笔者总结，大致有如下几种：

(1)未收到计划的相关报文或者相关报文格式错误系统无法解析，导致计划的状态未能及时更新，不符合自动相关条件。

(2)有其他雷达航迹正在使用相同二次代码，导致计划找航迹失败；有其他计划正在使用相同二次代码，导致航迹找计划失败。

(3)有其他符合自动相关条件且具有相同二次代码的雷达航迹提前使用了航班计划，导致正常航班起飞时计划已经结束。

除上述常见案例，笔者也遇到一些比较特殊的案例，下面就这些案例进行分析说明，供大家参考。

2 典型案例分析

2.1 案例一

案例重演：UTC（下文统用此时间）时间10：15，塔台管制员反映出港航班HBH3209/A3023起飞几分钟后才自动相关。反映时刻距此航班起飞已经过了40多分钟。笔者在SDD查看，发现此航班已经飞出管制区，在飞行计划处理席（下文统称FDOP）查看，发现计划状态为终止。

案例的实际分析处理过程：首先，笔者将管制员手动拍发起飞报中的实际起飞时间设为初始时刻，在SDD上进行回放，发现09：30时，SDD上出现二次代码为3023的雷达航迹，但是一直到09：33此航迹才与计划自动相关。

继续分析未及时自动相关的原因。首先考虑是否存在相同二次代码的其他航迹或计划导致航迹与计划匹配失败。观察SDD上是否有此航班的二次代码重复告警，在FDOP查找是否有相同二次代码的其他航班的计划，结果均未找到，初步排除因存在相同二次代码的航迹或计划导致此航班未能自动相关。

借助系统日志分析。切换到系统后台，打开终端窗口并远程登录主用飞行数据处理服务器（下文统称FDP），进入计划日志目录，找到相关日志并查看09：30时刻的记录，所用命令如下：

通过阅读日志，发现此航班在起飞时刻计划状态处于正常的预激活状态，排除计划状态未处于预激活状态而导致不能自动相关这个原因。日志原文如下所示，其中“status=PREA”字段表示计划处于预激活状态：

远程登录到主用雷达数据处理服务器（下文统称RDP），进入雷达日志目录，找到相关日志并查看09：30时刻的记录，所用命令如下：

通过阅读日志，发现3023航迹在被雷达扫描到的时刻，航迹找计划，提示“在多份中没有找到合适的计划”。说明确实有重复二次代码的计划存在。日志原文如下所示：

返回计划日志，查找有关二次代码3023的记录。命令如下：

从日志的09：30记录往回看，发现此条记录，日志原文如下所示：

此记录说明，在09：24时，管制员修改TWB9602航班的二次代码为3023。于是查找FDOP中有关TWB9602航班的报文。但发现此航班的起飞报中的二次代码已改为A3020，由此推测管制员在此航班起飞前再次修改了二次代码。为验证此推测，继续查找日志的相关记录，命令如下：

从09：24时刻往后看，发现在09：32时刻，果然有一条管制员修改TWB9602航班二次代码为3020的记录，日志原文如下所示：

由上面一系列日志证实，确实是因为HBH3209航班在雷达扫描到的时刻，存在相同二次代码的计划，系统不能确定使用哪条计划，从而导致航迹与计划不能自动相关。后来管制员在09：32时更改TWB9602航班计划的二次代码为A3020，航迹3023重新搜寻并找到唯一匹配的计划，从而在09：33时自动相关上了。

案例总结：上述案例是一个二次代码重复导致无法自动相关的特殊案例。因为一般遇到的二次代码重复的情况，都是可以很直观的在SDD或FDOP中查出。而此案例，因为管制员在笔者接到问题时，已经更改了TWB9602航班的重复二次代码，从而给后续分析带来些许困难。此案例也反应出管制员正确填写二次代码的重要性。

2.2 案例二

案例重演：08：50，管制员反映一架出港航班B9719/A4110未自动相关，另一架出港航班B9563/A4122未相关对正确的计划。

案例的实际分析处理过程：接到问题后，笔者立刻查看SDD，此时两架航班已经起飞且高度超过1000米。其中，B9719航班的标牌处于简标牌状态，B9563航班的标牌正常相关但是落地机场是石家庄机场。

查看FDOP，发现这是两架转场航班，从邯郸飞来石家庄，再飞回邯郸。两航班出港计划的二次代码仍延用进港计划的二次代码，计划处于激活状态，收到的飞服值班员手动拍发的落地报和起飞报时间正确，格式正确。

通过回放发现，这两架航班在进近时大概下降到几十米，未经着陆，即又爬升，整个过程未曾从SDD上消失，上升时仍挂着进港时的全标牌。于是判断，航班起飞后仍相关着进港时的计划，是因为雷达没有探测到两航班航迹消失，系统不认为计划结束，因而起飞时仍然挂着进港标牌。继续回放发现，B9719航班在08：42：00时去相关了，于是远程登录到主用FDP，进入计划日志目录，查找有关相关的记录，所用命令如下：

查到的日志原文如下所示：

由日志我们可以看到，08：42分时，管制员进行了操作，“flag=4”，说明是人工去相关。系统对于人工去相关的航迹是不会再去搜索计划与其相关了，所以，从管制员反映情况到现在，B9719一直未再自动相关，是正常的。

再继续回放发现，B9563航班在09：06：18时由进近管制员进行了一次释放，一次释放之后，标牌立刻由全标牌变为简标牌，下一秒又自动相关，变为正确的出港计划的全标牌。针对这一现象，继续查找计划日志，命令如下：

grep B9563 AllLog2014010909.log|grep 201401090906<== 查找有关B9563航班的在1月9日09：06分的日志记录

查到的管制员进行一次释放操作的日志原文如下所示：

管制员一次释放后航迹与计划自动相关的日志原文如下所示：

由日志我们了解到，在09：06：18时，由于管制员的一次释放操作，使得B9563航班的进港计划自动结束，与此同时，航迹与进港计划自动去相关（flag=2）。去相关后的航迹开始寻找与之匹配的计划，七秒之后，与之有相同二次代码的出港计划与航迹自动相关（flag=1）。

B9563航班直到管制员一次释放后才结束进港计划并自动去相关，是因为系统对于处于管制状态的计划是不会自动结束的，即使它已经收到了飞服值班员人工拍发的落地报。

案例总结：笔者在此次案例的处理过程中，通过查看回放录像，找到事件转变的关键时间点，一步步的寻找日志中的记录，从而找到回放录像中发生的一系列现象的原因。可见，有时通过回放录像来分析也不失为一个快捷的途径。通过此案例，也可以看到管制员操作的不妥之处，对于此类特殊飞行的航班，管制员若想自动相关，正确的作法是对航班进行一次释放，或者联系飞服值班员人工结束进港计划，而不是人工去相关。

2.3 案例三

案例重演：04：45,管制员反映JAA830/A0767普吉—石家庄进港航班无法自动相关。

案例的实际分析处理过程：经笔者查看，此航班已经进入飞行情报区，但计划状态仍为静止状态，静止状态的计划是不能与航迹自动相关的。在系统设置里，计划航迹距离管制区边界90分钟时，会使计划由静止状态转变为预激活状态。显然，此航班的计划没有按正常生命周期进入预激活状态。

04：48时，观察到计划状态转变为预激活状态，但是航迹与计划仍然没有自动相关。此时航班按正常航路飞行，并未偏航，于是，借助RDP里的相关日志进行分析，命令如下：

日志原文如下所示：

语句“tdob_time=81149(must<==3600 or>=24*3600-3600)”意为计划航迹与实际航迹的距离超出1小时的系统设定值。

由此我们可以看到，当04：48计划转变为预激活状态时，航迹找到了计划，但是因为计划航迹与实际航迹的距离超出了1小时的系统设定值，因此不能自动相关。此种情况一般是航班偏航或者系统计算过点时间错误所致。此航班已经观察到未偏航，因此，推断系统计算过点时间错误。而过点时间计算错误，一般要从收到FPL报的首次过点时间计算开始查找原因。用以下命令查找日志记录：

通过查找发现如下解析过点时间的日志：

由日志可以看到在解析第二个航路点“NOB”时，上一个点到此点的时间和此点到下一个点的时间都是一个多小时，这是不正常的。在数据库中查找NOB点的坐标，与航图上坐标对比，发现坐标确实与实际不符。分析到此，即可解释此航班没有正常预激活并自动相关的原因了，是因为数据库中的航路点坐标不正确。

案例总结：此案例中通过航班没有正常预激活与自动相关，推断出过点时间计算错误，并由此查找到了数据库中收录数据的错误。由此可见，无法自动相关也可能是系统数据不完善造成。分析自动相关案例，可以找到数据库中收录数据的不足。

3 结论与建议

通过上述三个案例，我们可以了解到，遇到雷达航迹与飞行计划无法自动相关的情况，一般有如下几种分析方法：

(1)在FDOP看此航班的报文是否齐全且正确。

(2)在SDD席位看有无与此航班二次代码相同的航迹。

(3)在FDOP看计划条或报文里有无与此航班二次代码相同的计划。

(4)在FDOP看航班的计划状态是否满足自动相关的条件。

(5)分析FDP服务器中的计划日志和RDP服务器中的相关日志，来找到关键事件的记录。

(6)观看回放录像，查找关键时间点是否有事件发生，再结合日志进行分析。

上述三个案例，我们也可以总结出影响雷达航迹与飞行计划自动相关的比较特殊的因素有如下几点：

(1)管制员填入的二次代码不正确或者填入的时机不对。

(2)航空器在做某些特殊的飞行，致使其航迹不能满足自动相关的条件。

(3)管制员对软件运行机制不太熟悉，未能使用正确的方法来使航迹与计划自动相关。

(4)系统数据库里的资料不准确或者不完善。

鉴于雷达航迹与飞行计划自动相关的重要性，作为维护空管自动化系统的技术人员，必须深入学习雷达航迹与飞行计划相关的条件机制。只有对每一例无法自动相关案例认真剖析、总结，才能在日常工作中遇到类似的情况时及时、准确的处理解决。管制员作为软件的使用者，也应该时常复习软件操作手册，按照软件的使用说明，在正确的时间用正确的方法对软件进行操作。同时，双方也应加强交流沟通，把各自的经验和心得进行分享与传授，这样，才能更好的保障飞行安全。

［1］莱斯自动化系统现场值班维护手册[Z].南京莱斯信息技术股份有限公司,2013.