雷达数据在空管自动化系统中的处理方法研究

刘邦强

（中国民用航空三亚空中交通管理站，海南三亚 572000）

0 引言

空管雷达数据融合及处理是空管自动化系统设计的关键模块。随着民航的快速发展，空域内的飞行量也随之增大，空中交通管制的要求更加苛刻，要求空管自动化系统在整个管制空域内实现雷达数据处理的无缝多重覆盖。处理量的增加和保持高精度要求是系统稳定设计的一个矛盾。实际上，由于空域的高度层和特定现场运行情况的不同，在具体空域中，目标的运行状态和常见数量在一定时间段内不会产生突变，并且对雷达处理有个性化要求。航空器的运行状态（平飞、上升、下降或机动）系统的算法实时性和精度要求也不一样。本文从实际出发，提出一种多样化配置的空管自动化雷达数据处理方案，在一个管制中心内对不同区域、不同运行状态的航空器采用不同的雷达数据处理方式，实现雷达数据的灵活配置处理，最终在C#平台上进行仿真验证。

1 空管自动化系统雷达数据处理方法

当前，空管自动化系统主要采用单一的雷达数据处理方式，如南京莱斯系统采用的马赛克处理方式、Telephonics系统采用的加权系数融合方式。马赛克处理方法将系统界面范围内的空域划分为网格马赛克，根据实际经验值，在固定的马赛克方框内采用某一路雷达数据作为融合的主要代表，这种处理方法在高度的融合上非常常见，系统运行开销较小，而且如若经验值得当，运行效果也较为合理（实际雷达站的部署会造成雷达数据在不同区域有不同的质量情况）。但是其也存在不少问题，以高度为例，如若目标在跨越网格，系统将会出现雷达数据切换，从当前雷达切换到另一个雷达，容易出现高度跳变[1]。加权系数融合适用性较强，但是无法降低系统的开销，算法运行复杂、稳定性较弱，容易牵一发动全身。同时，虽然系统的运行较为平滑，但是可能出现系统计算结果和实际目标飞行状态有差异的情况。当然，这些算法在整个区域内采用统一的算法计算方式，在大多数情况下确实能够满足现场运行，但随着未来中国空域改革，如果管制区域范围增大，这种配置显然无法满足实际运行。在某些区域的某些时段，系统的运行可能会出现不可预见的效果，这对于万无一失的管制工作要求来说是不可接受的。在航路飞行监视上，系统的覆盖范围较大，所需处理的目标数量也较大，对雷达处理的目标数量要求较高，而对比其他区域的管制，由于间隔不同，系统对于精度的要求可以适当降低；在终端区和塔台，通常在某一时刻，系统需要处理的目标数量不多，但是对具体目标的精度要求却更高。因此，单一的马赛克或加权系数的处理不适合实际运行。

2 方法研究

综上所述，空管雷达数据处理实际需要两个层面的设计，一是对单雷达数据的处理；二是多雷达数据融合处理。前者是后者的基础，也是空管自动化系统旁路依赖的信息；后者则是空管自动化系统的最终显示基础[2]。

2.1 单雷达数据处理

单雷达数据处理主要处理雷达站发送到自动化系统的点、航迹信息。在实际处理上，雷达数据是以扇区为单位发送的，由于航空器是时刻移动的，因此必然存在有处于扇区交接的点、航迹数据，正常的算法需要考虑该扇区和相邻2个扇区、3个扇区内部的点迹信息，扇区角度达到67.5h。这样的处理算法虽然满足平滑要求，但却降低了算法效率。实际上，当前性能最好的民用航空器以最大的速度飞行也不可能在5 s内移动超过11.5h。因此，在数据处理上可以将其分为点迹扇区和航迹扇区。前者分为16个扇区，后者则为前者旋转半个扇区（11.5h）。利用这种机制，可以实现原来3个扇区内部的数据处理缩减为2个扇区内部的数据处理，算法开销降低33%。这种旋转处理需要根据实际进行延迟补偿，如增加旋转周期一半的时间延迟等，以确保数据的同步完整性。

在雷达的航迹相关和新建上，对扇区A的航迹处理时需要遍历该扇区内部已经建立的航迹，对于每个航迹的相关都需要遍历相邻两个点迹扇区的所有点迹。为了提高算法效率，算法可以设计一个动态自适应窗口进行第一步的过滤。航迹的新建，系统如若遍历完毕没有找到相关的航迹，则将生成一个新的航迹，并将该航迹定义为临时航迹，算法设置判断参数为3，3次同时接受到该航迹，并且临时航迹与点迹的相似值都在相关门限下则可以新建航迹。

2.2 改进型马赛克算法

在马赛克算法的处理上可以做以下改进：依次计算系统单雷达航迹和马赛克单元以及相邻单元的所有航迹的近似值，最后确定雷达航迹是否已和现有航迹相关，如若可以，则将所有航迹信息更新到该相关航迹上；一个系统航迹的数据结构设计可以包含3部雷达的航迹信息；根据正常空管自动化系统的显示周期设计（4～5 s），算法可以将航迹列表中的所有雷达外推到系统更新的时间，并经过动态反馈检查，所有系统航迹相关的雷达进行加权平均得出最优值。在位置和速度的处理上可以有：

式中：i∈[1，3]为不同的雷达信号；k为可自定义的雷达优先等级；M为单雷达信号质量参数；MTQ为系统单雷达航迹与系统航迹近似参数。

由于信号延迟补偿的问题，系统需要至少3个雷达周期才能形成新的航迹，再处理能够得到扇区的所有信号，对收到的信号进行雷达周期一半的延迟加上计算和传输的延迟，一个航迹至少需要2.5 s才能新建。因此，算法可以继续改进。设一个航空器转向，另一个航空器正常飞行，由于雷达原因暂时无法接收到信号，算法必须在处理时预测两个目标，计算航迹的质量系数，输出质量好的航迹。这种情况，系统将对转向的状态进行判断（主要是机动的状态、位置变化速度），如若机动较快突破设计的阈值，系统将采用三维卡尔曼滤波对其进行预测计算，否则继续采用马赛克算法。这种设计的优点还体现在精度的处理上。由于马赛克算法的信息基础是经过单雷达处理后的雷达航迹信息，除了雷达源带来的误差，还有单雷达处理带来的误差[3]，而上述算法主要针对点迹处理，加上三维卡尔曼滤波处理，算法处理精度更高，符合航空器机动的监视情况。大多数情况下，航空器是以固定的速度和高度进行巡航，除了在终端区，航迹基本是平飞或者上升下降，机动状态较少。这种设计可以使得系统在算法计算上，大部分计算都是采用马赛克算法，小部分计算是依赖三维卡尔曼滤波。三维卡尔曼滤波虽然处理实时性强、精度高，但确实无法避免开销较大的问题。算法的设计能从全局方面平衡两者之间的矛盾，取得精度计算和计算量控制之间的有效配合。

在区域的分配设计上，对于区域管制系统将按照上述思路对目标雷达数据进行处理。对于终端区，管制对于数据的处理精度要求更高，航空器的机动情况也更多，更适合采用三维卡尔曼滤波的处理。如果完全按照上述的处理，容易造成多次处理判断，造成无谓的系统开销。因此，算法将从系统中获取具体的终端区范围，在该区域内采用三维卡尔曼滤波为预测算法。

3 软件的仿真与实现

为了测试算法的预测性能和占用资源，采用C#编写软件，软件实现对现场配置的5路雷达测试信号的接入、轨迹的多重同时绘制、不同算法下软件CPU占用率的检测，最终通过图形界面展现[4-8]。

雷达数据的接入需要考虑对不同区域的多重覆盖，并将多路雷达的HDLC信号格式转换为UDP网络格式，通过不同的UDP端口实现对不同雷达信号的区分，最终通过网络接口进行处理。为了实现对比，系统采用4台HPZ420工控机，其中3台为处理终端，分别部署本方案算法验证处理、普通马赛克处理和正常三维卡尔曼滤波处理仿真软件；另一台则为显示终端，用于对比显示最终的处理结果。所有工控机采用一样的硬件配置、仿真软件在雷达数据接收处理模块上的设计一致，以满足系统对资源占用的对比。雷达数据通过协议转换后接入局域网交换机，整个测试将基于该局域网进行模拟仿真。处理终端除了向显示终端发送实时的轨迹处理信号，也向其发送程序的CPU占用率和内存占用的相关资源情况（参数可切换）。C#上实现部分代码如下：

//初始化CPU计数器

pcCpuLoad=new PerformanceCounter（"Processor"，"%Processor Time"，"_Total"）；

pcCpuLoad.MachineName="."；

pcCpuLoad.NextValue（）；

//CPU个数

m_ProcessorCount=Environment.ProcessorCount；

//获得物理内存

ManagementClass mc = new ManagementClass（"Win32_ComputerSystem"）；

ManagementObjectCollection moc=mc.GetInstances（）；

以某终端区的实时雷达信号处理为例，如图1所示。从图中可以看出，本算法计算的轨迹介于普通马赛克算法和正常三维卡尔曼滤波算法轨迹之间，模拟程度较为均衡。而在系统开销上，本算法只需要13.2%，甚至比普通马赛克算法29%还低，这是由于该目标当前处于终端区，该区域雷达覆盖较多，马赛克算法也需要进行多重计算和切换。另一方面，正常三维卡尔曼滤波的开销是三者之中最高的，这主要因为终端区目标机动情况较多。总之，可以看出，在仿真效果上，算法能较为均衡地计算处理雷达数据，并且资源开销降低。

图1 仿真显示图

4 结束语

本文从实际出发，基于传统的雷达数据处理设计算法，提出一种改进的雷达数据处理方法。通过针对目标的实际情况进行灵活地分类处理，使得系统的处理开销小、算法轨迹计算较为准确。方案最终通过C#进行设计仿真，效果如设计预想，可为空管自动化雷达数据处理方面的研究提供参考，也为空管自动化系统日常保障的数据处理分析提供思路。