宫昕昱

摘  要：雷达融合处理是ATC自动化系统最核心的功能，也是自动化系统稳定运行的根本。文章以民航二所空管公司的AirNet自动化系统在实际运行中发生的一起航迹丢失案例，深入分析了异常发生的过程及导致异常的原因。在此基础上对自动化系统的雷达融合机制进行了一定程度的探讨，提出了一些建议。

关键词：雷达融合处理;AirNet自动化系统;航迹丢失

中图分类号：V355.1        文献标志码：A         文章编号：2095-2945（2019）27-0017-04

Abstract： Radar fusion processing is the core function of ATC automation system， and is also the basis of stable operation of automation system. In this paper， a case of track loss occurred in the actual operation of AirNet automation system of air traffic control （ATC） companies of civil aviation is taken as an example， and the process of abnormal occurrence and the causes of abnormal occurrence are analyzed in depth. On this basis， the radar fusion mechanism of automation system is discussed to a certain extent， and some suggestions are put forward.

Keywords： radar fusion processing; AirNet automation system; track loss

引言

ATC空管自动化系统是空中交通管制员最主要的手段之一[1]。雷达融合处理是自动化系统最核心的功能，其稳定性极大程度决定了一套自动化系统在实际运行中的性能表现和用户体验。近年来，随着终端区飞行流量急速增长，以及高空移交区管中心，自动化上的雷达航迹呈现出更加复杂高低扇飞行姿态。雷达航迹在位置上的接近，给自动化雷达融合处理增加了难度。而单雷达信号由于覆盖范围、雷达头故障、传输等原因带来的信号不稳定，也对自动化系统雷达处理的稳定性和强健度提出了考验。

2015年5月，民航二所空管公司AirNet自动化系统在中国民航空中交通管理局下属的包括重庆、厦门在内的九地空管分局和空管站投入运行。本文基于多年对该系统的保障维护实践，以2015年9月30日在重庆空管分局发生的一起较为典型又极具研讨价值的AirNet系统航迹丢失案例展开分析，进一步探讨了自动化系统中雷达融合相关机制的目标与方向。为下一步AirNet系统的软件改进，以及其他空管单位的AirNet系统运行提供一些建议与参考。

1 AirNet雷達航迹丢失现象

2015年9月30日20：06，重庆区域（区调）管制席位反映AirNet自动化中，从恩施ENH的进港航班CHB6252标牌（计划应答机为A5670）与实际应答机为A5070的目标进行了错误相关，而实际应答机A5670的目标（航班号本应为CDG8792）的雷达航迹在AirNet自动化上没有出现。而在Telephonics自动化中，两个目标的雷达航迹均显示正常。对目标丢失过程进行回放与梳理如下。

在多雷达下，19：53：00，应答机为A5070（高度8400米）和A5670（高度7800米）的两个航班同时从东面向本场飞行，高度差为600米，水平间隔为5公里。其中A5070应属于成都区管高扇指挥，A5670为武汉移交过来的低扇航班。19：56：09，航迹A5670完成与其计划CHB6252自动相关。而A5070未能正常完成自动相关，如图1所示。

19：56：35，多雷达下，A5670航迹的二次码突然变为A5070，系统出现DUPE告警。随后系统将两个目标判断为A5070这一个航迹，从图2可以看到，19：56：44，5070和5670的航迹均进入推测航迹状态，同时A5670的航迹位置跳变至A5070的位置上去，而原A5670的尾迹点已经中断。

19：56：57，航迹结束推测状态，此时系统彻底将两个航迹判断为A5070这一个航迹并将其融合，同时重新开始跟踪这个新的A5070的航迹位置;在图3可以看到，A5070之前的尾迹点消失，证明这个航迹是重新开始计算的。同时，原本属于的标牌CHB6252也错误相关至A5070，如图3所示。

19：57：12，区调管制员根据标牌航班号CHB6252将目标接管。此时，管制员在SDD上接管的其实是不该属于他指挥的A5070目标，他并不知道真正该他指挥的A5670目标其实就在A5070下方600米处，但在15秒前已经丢失。

2 航迹丢失原因分析

从上述的异常过程可见，9月30日的航迹丢失是一起连环性的自动化系统处理异常案例，而不仅仅只是单个航迹因为雷达信号原因导致的短时间航迹丢失。对该异常情况根据时间顺序进行分解，可以拆分为以下四个方面的问题：

（1）为何A5070没有正常自动相关？

（2）为何多雷达下，A5670的二次码会突变为A5070？

（3）为何两个目标二次码一致后，存在那么明显的高度差，系统却将两个目标判断为了一个航迹？

（4）为何在融合出现错误后，A5670对应的CHB6252飞行计划与标牌会错误相关至A5070？

根据异常情况的4个方面问题，对异常原因进行逐级的分析。

2.1 A5070自动相关异常

首先需要分析的是：为何A5070没有正常完成与飞行计划的自动相关？AirNet系统对进港航班的自动相关机制为：进港航班在收到DEP起飞报后，将报中的二次代码自动填入计划;当进港航班的航迹进入相关区（或外扩区）后，触发相关判断，完成自动相关。

A5070与A5670从东面几乎同时进入外扩相关区，那么按照机制两个目标也应该几乎同时完成与计划的相关。对A5070的DEP报文进行查询，其报文内容如图4所示。

从DEP报文可以看到，报文中的二次代码填写格式存在错误。根据AirNet系统FDP的处理情况提示“编组7[5070]不是5为的SSR模式和编码，解析中止”可知，报文错误格式的二次代码填写，导致系统对该DEP报解析失败，A5070对应的飞行计划中没有二次码，从而造成A5070目标无法正常相关。

2.2 A5670融合航迹二次码突变

本次异常情况的直接原因是在多雷达融合下，目标A5670的二次码突变为A5070。多雷达融合信号是单雷达信号融合处理后的结果，多雷达出现异常往往与单雷达有关。基于此思路，对单雷达信号依次进行回放。

根据目标位置，在出现信号丢失的前后时间段中，可以发现目标的单雷达为：恩施雷达（ES）、张家界雷达（ZJJ）和铜仁雷达（TR）。其中恩施雷达和铜仁雷达在故障时刻及其前后时间段中信号均正常。但张家界雷达信号出现问题。

首先，在异常时刻之前19：53：45，张家界雷达信号下，目标A5670发生第一次突变，二次码变为A5470，高度跳变为7290，如图5所示;然后目标二次码保持在A5470，直至19：55：10，才又重新恢复为5670。

19：56：34，张家界单雷达的A5670目标发生第二次突变，二次码变为了A5070（如图6所示）。1秒后，多雷达的A5670目标二次码也变为A5070，单雷达信号突变时间与多雷达融合信号突变时间完全吻合。可以确定多雷达信号二次码突变就是张家界单雷达信号导致。

2.3 A5070与A5670错误判定与融合

解决了二次码突变的原因后，接下来需要分析的是，为什么二次码突变成一样，系统就会将两个目标判定并融合为一个航迹？

目前在AirNet自动化系统中，为了抑制目标分裂，系统通过一个区域配置文件associate.cfg中划设的区域及其参数设置，去对“两个相同二次码航迹是否为同一个目标”进行判断。发生异常时的associate.cfg设置为：在3500-8500高度层中，两个目标必须满足水平距离小于8公里，垂直距离小于250米，才会判断为同一目标。从发生异常时的两个目标的高度差和水平距离看，虽然水平距离（5公里）小于8公里，但垂直距离（600米）并未小于250米，因此按照此机制执行，不应该将两个目标判断为一个目标。

但当笔者进一步观察associate.cfg设置的区域边界时，发现associate.cfg区域并没有覆盖到异常发生时的目标位置，如图7所示。因此可以判断，9月30日异常发生时，两个目标没有进入associate.cfg区域，因此上述判斷机制没有生效。系统按照默认值水平距离8公里，垂直距离300米去进行融合判断，从而将两个航迹融合为了一个航迹。

2.4 CHB6252标牌错误相关

由于发生了融合错误，系统将两个目标判断为了一个目标。因此系统将A5607的航迹号赋予给了A5070。FDP处理时，发现已经相关的飞行计划CHB6252，虽然二次码有变化，但航迹号未变，因此没有去相关，而保持相关。从而导致CHB6252错误相关在A5070上。

3 雷达融合机制探讨

根据原因分析的四个方面，除了第一点的未正常相关是由于报文内容有误，其余三点均与AirNet系统的软件处理机制，尤其是雷达融合机制及其配置有关。在高空移交后的高低扇运行模式下，9月30日这样的两架航班上下层同向飞行的飞行姿态经常存在。那么自动化系统需要什么样的处理机制，去有效地避免同类异常情况再次出现？根据上述异常原因，分别从多雷达融合选择机制，相近航迹判定，计划与航迹号的关联这三个环节展开探讨。

3.1 多雷达融合的二次代码选择

在9月30日的异常案例中，AirNet系统在多雷达融合处理中存在一个明显的问题：在异常时刻三部单雷达覆盖目标，而恩施和铜仁两部雷达的二次码都是正常的情况下，融合处理为什么偏偏会采纳不正常的张家界的单雷达信号？这一问题涉及多雷达融合的二次码选择机制。

在多雷达的融合处理中，需要对航迹位置、二次码、高度、速度这四项进行融合处理[2]。其中，航迹位置可以参照多部雷达的位置最终判断出一个中间值;高度可以对比多部雷达的高度差进行平均计算;速度可以通过单独计算融合信号的速度来规避单雷达的影响。唯有二次码，多雷达融合时只能是选择某一部单雷达提供的二次码数值。根据自动化系统的处理机制，系统在目标出现的第一时间，会选择首先探测到该目标的单雷达提供的二次码。那么当这部雷达的二次码出现错误时，要如何确保融合雷达的二次码不受影响？

笔者认为，在多重雷达覆盖且所有单雷达平均权重前提下，“少数服从多数”的二次码选择机制是确保融合雷达正常的正确处理方式。多雷达在航迹更新时，判断当前选择的单雷达二次代码与其他单雷达二次码是否一致，若不一致则选择其他单雷达的二次码作融合使用。这样，一个航迹只要在三重雷达覆盖下，且两部单雷达不同时出现二次码跳变，则基本可以确保该航迹融合信号的二次码正确稳定。这也是雷达多重覆盖的存在意义之一。如图8所示，对9月30日的情况在该机制下进行模拟，即使张家界雷达出现二次码突变，融合雷达信号也不会受到影响。而融合信号二次码若不发生突变，便不会有后面的融合和相关一系列错误发生。

3.2 位置相近航迹的融合判断

在AirNet自动化系统中，对于两个航迹位置接近的目标，系统会根据配置管理DBM上的一个区域配置文件associate.cfg里设置的融合条件，去判断两个目标究竟是两个真实的航迹，还是一个航迹产生的分裂。这一机制的引入，很大程度地避免了雷达航迹分裂和假目标的出现。

从另一方面，虽然AirNet系统提供给用户这样一个可以灵活配置的文件，但associate.cfg的区域应该如何配置，参数如何设置才能满足运行要求，才能避免出现本文案例的类似问题？可以从以下几点考虑。

（1）由于区调，进近，塔台的航空器的间隔不一致，因此在一个管制区内建议划分多个associate区域分别为区进塔使用。这些associate区组合起来尽量能够包含管制区所有区域范围。同时，结合不同管制室各自的航空器安全间隔参数，对各自的associate区域的判定条件进行设置。

（2）将区调范围的associate区域进行外扩，从而尽量避免本文案例的相近航班在associate区域外出现航迹错误融合的情况。

（3）associate区域不可能无限外扩，所以AirNet系统仍然需要对默认的判定值进行调整，可以考虑将其调整为与区调的设定值相同。

3.3 计划与航迹号的关联

从上述原因分析可知，在AirNet系统中，飞行计划与雷达航迹相关后，会与该雷达航迹的航迹号（这个航迹号是系统在建立航迹时在后台自动分配的编号）产生关联。一旦该航迹的二次代码发生变化，飞行计划会通过与航迹号的关联，从而保持与该航迹的相关。

这一机制的作用是：当航空器在空中由于飞行员或其他原因导致应答机二次码改变后，自动化系统中航迹不会与飞行计划相关。这时，AirNet系统提供了一个DS告警，提示管制员当前目标的二次码与飞机计劃中的二次码不一致。该功能在管制指挥中发挥了良好的作用。

但是，从本文案例中可知，一旦航迹出现融合错误后，飞行计划可能会跟随其关联的航迹号，错误相关至其他航迹上去，为管制员带来更大的误导。在这种情况下，飞行计划与航迹号的关联反而成为束缚。那么这一机制是否具有存在的必要？笔者认为该问题具有进一步探讨的空间。但如果能够将各种异常状况，有效地控制在多雷达融合选择和相近航迹判定这前两个环节中，那么飞行计划与航迹号关联便不会成为束缚，可以考虑保留。

4 结束语

雷达融合处理是ATC自动化系统的核心功能，也是自动化系统稳定运行的根本。9月30日出现的航迹丢失案例是一起典型的由于系统处理机制及其他外部原因，从而突破了系统的各个判定条件，最终导致系统处理异常的设备不正常情况。其可能带来的风险值得我们关注。本文以该案例为契机，在对案例进行详细梳理和深入分析的基础上，对AirNet系统雷达融合相关机制展开了研究和探讨，提出了一些建议。希望为未来AirNet系统的软件改进，以及其他空管单位的AirNet系统运行提供一些参考与帮助。

参考文献：

[1]赖欣，黄邦菊.空管自动化系统信息安全评估研究[J].计算机科学，2014，41（S1）：474-476.

[2]蒋乃欣，张军，罗喜伶，等.空管多雷达数据融合系统的设计与实现[J].航空电子技术，2004，35（2）：33-35.