论文部分内容阅读
摘 要：空管自动化系统硬件设计寿命为6～8 a，国内现在飞速增加的航班量已大大超出几年前的预计，硬件升级更换又需要一定的周期，一部分设备尤其是运算量很大的几个关键服务器负担已接近或达到设计临界值。在现有硬件设备条件下如何应对服务器负担问题已成为上海地区空管自动化系统一大难题。文章描述了上海空管专题研究克服雷达处理服务器负担高企的方法。
关键词：RDP，CPU占用率，航迹
中图分类号： 文献标识码：A 文章编号：1006-8937（2014）32-0078-01
1 相关情况概述
随着近几年我国航空事业的飞速发展，空域流量越来越大，高峰时间段航班量屡创新高。航班量增加的同时，提供管制服务的空管自动化系统的负担也越来越大。上海地区使用的THALES空管自动化系统（以下简称THALES系统）2005年投入使用，负责区域包括整个华东地区高空及上海、合肥共三个机场。系统负担已接近极限，尤其是雷达处理服务器告警频频。在硬件升级之前如何利用现有资源降低服务器负担为现阶段的重点，本文详述了技术人员如何采取合理手段实现这一目的。
2 服务器状况
近期雷达处理服务器（RDP）CPU占用率居高不下，2014年以来几乎每周都会出现多次CPU告警，即占用率超过60%，最高到过66%。一般出现在航班高峰时段，空域中飞行器700多，近期极端情况曾出现超过800的，其中处于管制指挥的大概有一半左右。
按照THALES公司技术人员的反馈，CPU在70%以下是相对安全的。目前虽然没有达到过70%，但已相当接近，春节或夏天航运高峰可能会更高，服务器负担高企已经成为一个隐患，需要提前制定应对措施。
3 采取的应对措施
RDP处理的主要是系统航迹生成、航迹与计划相关及告警判断。我们可以直接干涉的就是系统航迹数，特别是没有挂单的系统航迹。没有挂单的航迹除了个别是飞行计划的原因，大部分都是还没有进入FDRG的当前不需要管制指挥的目标，这类目标占所有系统航迹的一半左右。目前我们可以采取的措施大致分以下两种。
3.1 关闭雷达
这是个风险较大的措施，因为这种做法只是简单的去除某一地区的雷达目标，而无法区分该目标是否处于管制状态。且为了有效减少系统航迹就必须关闭区域周边没有多重覆盖的雷达，航迹减的越多对服务器减负越有效，但同时错杀正在管制的有用目标的可能性也越大。
3.2 设置BLK_AREA过滤目标
名词解释：BLK_AREA/NAI_AREA
NAI_AREA是针对某部雷达覆盖区域内划定的一个区域，在该区域内只更新原有的航迹信息，不会初始化航迹，即不会产生新目标。
BLK_AREA也是针对某部雷达覆盖区域内划定的一个区域，在该区域内不会更新原有的航迹信息，也不会初始化航迹，也就是完全没有目标。
可以在离线数据中设置BLK_AREA，把一些目前雷达可见但实际上管制员并不关心的雷达目标过滤掉，RDP也就不必理会这些数据，从而有效降低RDP负担。NAI_AREA则可以用来抑制某一地区某部雷达信号不稳定造成的目标分裂情况，目前看来有几种目标是可以被过滤掉的。
①与上海根本无关的目标（比如我国台湾地区有很多无关目标）。
②航路与上海相连，但离进入上海管制还有很远距离（有些航班在离上海FDRG很远就被发现，要半个多小时甚至更久才会移交给上海，没必要这么早就看到，离开上海FDRG的航线更不需要看这么远）。
③FDRG内不在航线上的军用航空器。相比关闭雷达，设置BLK_AREA/NAI_AREA的风险是可控的，且抑制范围可以从小到大慢慢调整。不过因为是通过数据发布实现的，所以不能随时屏蔽与开启，所有调整必须提前做好规划与准备。
4 前期准备工作
4.1 关闭雷达的准备
①根据雷达威力图确认周边单部雷达关闭后影响到的覆盖区域；②在测试平台上验证，周边单部雷达关闭后对系统航迹及RDP CPU的影响；③请管制部门协助评估周边单雷达关闭对管制工作可能带来的风险。
4.2 设置BLK_AREA/NAI_AREA过滤目标的准备工作
①请管制部门提供可以设置BLK_AREA/NAI_AREA的区域，分为三类：完全无关的区域、航路延伸离开FDRP足够远的区域、FDRG内军方活动区；②在测试平台上测试三类区域设置后对系统航迹及RDP CPU的影响；③请管制部门评估可能的风险并商定可过滤哪一类区域。
考虑到过滤目标后也会过滤目标的冲突告警等信息，且FDRG内雷达多重覆盖，暂不考虑在主系统上过滤第三类区域。
5 测试情况
经过与管制部门的沟通，先期在我国的台湾及中南地区设置BLK_AREA。
我国台湾地区相关雷达为福州及厦门雷达，在离线参数中用多个环形来近似模拟地形，过滤地区为岛的内部区域，预计高峰时间段能减少近10个目标。
中南地区相关雷达为赣州、揭阳、韶关雷达，管制部门实际关注的是靠近华东的目标，将相对较远处的区域设为BLK_
AREA，预计高峰时间段能减少20多个目标。
在测试平台上测试情况见表1：（测试平台数据量较小，CPU一般在40%～50%）。
可以看出，服务器CPU占用率和系统航迹数是成正比的，当BLK_AREA生效时，系统航迹数减少，CPU占用率也略微降低。
6 补充说明
自动化系统测试平台是一个小规模自动化系统，具有独立的服务器、席位和信号引接部分，采用单网配置，软件版本与参数设置与现有主系统相匹配，用于测试各类引接信号及软件补丁。
测试平台和主用平台相比，软硬件上配置都不同，具体表现在
①节点数大大不同，测试平台席位和服务器数量都很少，且没有冗余配置；②雷达引接数不同，主系统ACC接了24路，测试平台当时只有13路有效的雷达信号；③软件配置不同，我们最关心的THALES主系统RDP服务器集成了两个软件模块MTP和RDP（分别用于处理系统航迹和告警等），测试平台上将MTP模块与RBP模块一起装到了shmrrbp01da上，而把RDP模块与CDP模块一起装到了shmrcdp01da上。所以上表的CPU只能反映航迹数的影响，并不能完全模拟主系统RDP服务器的CPU 状态。
7 结 语
根据测试情况已能基本认定采用设置BLK_AREA的方法对降低系统航迹数和RDP CPU占用率是有效的，测试效果经管制部门评估后就可以在主用系统上实施，其设置范围还可以扩大到与华北地区及各航路延伸段。考虑到航迹数与CPU比例关系并非完全线性且测试平台在规模上与实际平台有所区别，实际效果还要在主系统中试用以后才能确认，关闭雷达的方法由于风险较大将作为紧急情况下的备选手段。
参考文献：
[1] 黄萍.S模式雷达大THALES空管自动化系统中的应用[J].交通管理，2010，（8）.
[2] 张媛媛.空管自动化雷达处理的论述[J].科技信息，2014，（8）.
关键词：RDP，CPU占用率，航迹
中图分类号： 文献标识码：A 文章编号：1006-8937（2014）32-0078-01
1 相关情况概述
随着近几年我国航空事业的飞速发展，空域流量越来越大，高峰时间段航班量屡创新高。航班量增加的同时，提供管制服务的空管自动化系统的负担也越来越大。上海地区使用的THALES空管自动化系统（以下简称THALES系统）2005年投入使用，负责区域包括整个华东地区高空及上海、合肥共三个机场。系统负担已接近极限，尤其是雷达处理服务器告警频频。在硬件升级之前如何利用现有资源降低服务器负担为现阶段的重点，本文详述了技术人员如何采取合理手段实现这一目的。
2 服务器状况
近期雷达处理服务器（RDP）CPU占用率居高不下，2014年以来几乎每周都会出现多次CPU告警，即占用率超过60%，最高到过66%。一般出现在航班高峰时段，空域中飞行器700多，近期极端情况曾出现超过800的，其中处于管制指挥的大概有一半左右。
按照THALES公司技术人员的反馈，CPU在70%以下是相对安全的。目前虽然没有达到过70%，但已相当接近，春节或夏天航运高峰可能会更高，服务器负担高企已经成为一个隐患，需要提前制定应对措施。
3 采取的应对措施
RDP处理的主要是系统航迹生成、航迹与计划相关及告警判断。我们可以直接干涉的就是系统航迹数，特别是没有挂单的系统航迹。没有挂单的航迹除了个别是飞行计划的原因，大部分都是还没有进入FDRG的当前不需要管制指挥的目标，这类目标占所有系统航迹的一半左右。目前我们可以采取的措施大致分以下两种。
3.1 关闭雷达
这是个风险较大的措施，因为这种做法只是简单的去除某一地区的雷达目标，而无法区分该目标是否处于管制状态。且为了有效减少系统航迹就必须关闭区域周边没有多重覆盖的雷达，航迹减的越多对服务器减负越有效，但同时错杀正在管制的有用目标的可能性也越大。
3.2 设置BLK_AREA过滤目标
名词解释：BLK_AREA/NAI_AREA
NAI_AREA是针对某部雷达覆盖区域内划定的一个区域，在该区域内只更新原有的航迹信息，不会初始化航迹，即不会产生新目标。
BLK_AREA也是针对某部雷达覆盖区域内划定的一个区域，在该区域内不会更新原有的航迹信息，也不会初始化航迹，也就是完全没有目标。
可以在离线数据中设置BLK_AREA，把一些目前雷达可见但实际上管制员并不关心的雷达目标过滤掉，RDP也就不必理会这些数据，从而有效降低RDP负担。NAI_AREA则可以用来抑制某一地区某部雷达信号不稳定造成的目标分裂情况，目前看来有几种目标是可以被过滤掉的。
①与上海根本无关的目标（比如我国台湾地区有很多无关目标）。
②航路与上海相连，但离进入上海管制还有很远距离（有些航班在离上海FDRG很远就被发现，要半个多小时甚至更久才会移交给上海，没必要这么早就看到，离开上海FDRG的航线更不需要看这么远）。
③FDRG内不在航线上的军用航空器。相比关闭雷达，设置BLK_AREA/NAI_AREA的风险是可控的，且抑制范围可以从小到大慢慢调整。不过因为是通过数据发布实现的，所以不能随时屏蔽与开启，所有调整必须提前做好规划与准备。
4 前期准备工作
4.1 关闭雷达的准备
①根据雷达威力图确认周边单部雷达关闭后影响到的覆盖区域；②在测试平台上验证，周边单部雷达关闭后对系统航迹及RDP CPU的影响；③请管制部门协助评估周边单雷达关闭对管制工作可能带来的风险。
4.2 设置BLK_AREA/NAI_AREA过滤目标的准备工作
①请管制部门提供可以设置BLK_AREA/NAI_AREA的区域，分为三类：完全无关的区域、航路延伸离开FDRP足够远的区域、FDRG内军方活动区；②在测试平台上测试三类区域设置后对系统航迹及RDP CPU的影响；③请管制部门评估可能的风险并商定可过滤哪一类区域。
考虑到过滤目标后也会过滤目标的冲突告警等信息，且FDRG内雷达多重覆盖，暂不考虑在主系统上过滤第三类区域。
5 测试情况
经过与管制部门的沟通，先期在我国的台湾及中南地区设置BLK_AREA。
我国台湾地区相关雷达为福州及厦门雷达，在离线参数中用多个环形来近似模拟地形，过滤地区为岛的内部区域，预计高峰时间段能减少近10个目标。
中南地区相关雷达为赣州、揭阳、韶关雷达，管制部门实际关注的是靠近华东的目标，将相对较远处的区域设为BLK_
AREA，预计高峰时间段能减少20多个目标。
在测试平台上测试情况见表1：（测试平台数据量较小，CPU一般在40%～50%）。
可以看出，服务器CPU占用率和系统航迹数是成正比的，当BLK_AREA生效时，系统航迹数减少，CPU占用率也略微降低。
6 补充说明
自动化系统测试平台是一个小规模自动化系统，具有独立的服务器、席位和信号引接部分，采用单网配置，软件版本与参数设置与现有主系统相匹配，用于测试各类引接信号及软件补丁。
测试平台和主用平台相比，软硬件上配置都不同，具体表现在
①节点数大大不同，测试平台席位和服务器数量都很少，且没有冗余配置；②雷达引接数不同，主系统ACC接了24路，测试平台当时只有13路有效的雷达信号；③软件配置不同，我们最关心的THALES主系统RDP服务器集成了两个软件模块MTP和RDP（分别用于处理系统航迹和告警等），测试平台上将MTP模块与RBP模块一起装到了shmrrbp01da上，而把RDP模块与CDP模块一起装到了shmrcdp01da上。所以上表的CPU只能反映航迹数的影响，并不能完全模拟主系统RDP服务器的CPU 状态。
7 结 语
根据测试情况已能基本认定采用设置BLK_AREA的方法对降低系统航迹数和RDP CPU占用率是有效的，测试效果经管制部门评估后就可以在主用系统上实施，其设置范围还可以扩大到与华北地区及各航路延伸段。考虑到航迹数与CPU比例关系并非完全线性且测试平台在规模上与实际平台有所区别，实际效果还要在主系统中试用以后才能确认，关闭雷达的方法由于风险较大将作为紧急情况下的备选手段。
参考文献：
[1] 黄萍.S模式雷达大THALES空管自动化系统中的应用[J].交通管理，2010，（8）.
[2] 张媛媛.空管自动化雷达处理的论述[J].科技信息，2014，（8）.