THALES空管自动化系统起飞落地报原理简析

THALES空管自动化系统起飞落地报原理简析

李臣恺

民航天津空管分局                天津市         300000

空管自动化系统是为空中交通管制服务提供监视、计划、告警等信息的重要系统，常被民航人员称为空管系统的心脏，而THALES自动化系统是我分局主用的自动化系统，它的主要功能是集中处理飞行器的监视数据、飞行计划数据、气象和航路情报等信息，集成航迹跟踪外推、冲突探测、收发报文、航路预测等功能，能够对来自雷达等监视设备的航迹目标和飞行计划进行自动相关，将有关信息进行图形化处理与显示，以人机交互界面的方式提供所辖区域内的空中交通态势、即将发生的冲突或告警信息，从而使管制人员精准把控航班各种飞行要素，及时准确的对飞行器下达指令，保障飞行器的安全。

在THALES空管自动化系统中，与起飞落地报自动拍发相关的服务器主要包括飞行计划数据处理服务器（FDP）和多监视源数据处理服务器（MSTS），通过对飞行器的位置、高度等的探测触发报文的自动拍发。在本系统中对于起飞报的自动拍发的机制设计为离港航班一旦被激活立刻触发拍发起飞报的操作，FDP服务器中相关软件模块根据计划中的起飞落地机场等信息组装拍发报文；在本系统的设定中，计划进入激活状态主要有两种方式，分别为计划与航迹自动相关和管制手动操作，在实际正常流程中主要通过计划与航迹的自动相关实现激活。系统中对于落地报文的拍发机制主要为系统判定落地后，自动触发拍发落地报，同样交由FDP服务器进行组装拍发，对于落地的判定主要分为按照计划时刻触发的ARR_SENDING事件—计划落地时间+120S后自动拍发落地报和系统航迹触发的ARR_SENDING_ON_APR事件—航迹进入ARR_VOLUME区域（落地确认区域），且120S内未再飞出该区域两种。

从系统的设计原理，我们就可以反推出起飞落地报异常的排查思路，本文将通过两个相关案例，介绍相关排查流程：

一、B0413航班起飞报存在错误，落地机场应为ZZZZ，实际拍发落地机场为ZBCA；

接到问题报告后，查询转报系统中该航班的领航计划报，从报文得知，其报文与01：28拍发，该航班计划于01：35从ZBTJ起飞，30分钟后落地于ZZZZ；查询起飞报，从报文得知该航班实际于03：04从ZBTJ起飞，落地机场为ZBCA；通过比较两个落地机场不一致。下一步，我们进入THALES自动化的日志服务器进行查询系统中该航班的相关处理过程；首先通过FDP服务器的FDX日志查询报文处理过程；该航班FPL报于01：28分拍发，经过查询01：28左右系统未进行此份报文的处理过程，对于该航班的最早报文日志如下：

message received at  2 h  42 m 8 s 268 ms ：ZCZC -TITLE IFPL -ADA -ADARR -ADARRZ -ADD -ADEP ZBTJ -ADES ZBCA

从日志中可知，报文处理事件为02：42 其中ADEP（起飞机场） 为ZBTJ –ADES（落地机场）为 ZBCA；与起飞报一致；

然后我们查询该时间节点的系统处理日志FPL，日志如下：

Message received in MMI_TO_FDP_FLIGHT_PLAN_COMMAND_F at  2 h  42 m 8 s 236 ms

  (FPL-B0413-IG-PC12/-S/C-ZBTJ0300-N0000S0090 TAJ 3913N11717E 3915N11724E TJ895 TJ931 TAJ-ZBCA-0-SPC/N)  Message received from MMI332

从日志中可知，MMI332于02：42分在THALES自动化中手动创建一份该航班的FPL，落地机场为ZBCA。综上所述，01：28拍发的落地机场为ZZZZ的FPL报未进入系统，管制员于02：42手动创建一份落地机场为ZBCA的FPL，在航班自动相关激活后，系统按照该FPL报中的起飞落地机场组装拍发起飞报，导致起飞报中落地机场出现问题。

二、校飞机组未落地拍发落地报。

收到问题报告后，我们查询FDP服务器中的FPL日志，如下：

Message received in POSITION_REPORT_F at  21 h  38 m 18 s 327 ms

          APR for FDR 2443, at fix  20, fix overf. FALSE, before FDRG entry : FALSE, inside ARR_VOLUME : TRUE

          Position report: LAT = 039.09, LONG = 0117.36, Time :  21 38 18, altitude =  550

          Last Good Mode C Initialised = FALSE

          Last Good Mode C =  0

       ==> Inserting Event 'ARR_SENDING_ON_APR'

            ARR_SENDING_ON_APR event inserted

  从日志中我们可以得知，在21：38时航迹进入ARR_VOLUME，系统触发ARR_SENDING_ON_APR事件，开始进行计时，此时系统流程正常，继续查询后续日志如下：

Message received in POSITION_REPORT_F at  21 h  39 m 18 s 230 ms

          APR for FDR 2443, at fix  0, fix overf. FALSE, before FDRG entry : FALSE, inside ARR_VOLUME : FALSE

          Position report: LAT = 039.12, LONG = 0117.34, Time :  21 39 18, altitude =  850

          Last Good Mode C Initialised = FALSE

          Last Good Mode C =  0

      association_processor OUT_ARR_VOLUME, ARR_SENDING_ON_APR event killed

       ==> Inserting Event 'ARR_SENDING'

          association_processor OUT_ARR_VOLUME, ARR_SENDING event inserted

    BEACON 0 is crap on APR, rejected

系统航迹飞出ARR_VOLUME，系统在判定OUT_ARR_VOLUME时，因航迹信号质量较差，将此次航迹报告拒绝，导致航迹虽然飞出ARR_VOLUME，但ARR_SENDING_ON_APR事件未被中止，在120S后系统执行拍发落地报的操作。

本文简单介绍了THALES空管自动化中起飞落地报的拍发机制，并从实际运行中挑选两个案例，依照系统的设计原理，排查问题原因，希望能对从业人员有所帮助。