空管雷达论文范文

空管雷达论文范文（精选7篇）

空管雷达论文 第1篇

空中交通管制是保证飞机安全和有秩序飞行的重要手段, 二次雷达作为空中交通管制的重要工具, 保证二次雷达设备正常运行是空中交通管制的关键之一。由于二次雷达站的地理位置特殊, 雷达站设备遭遇雷击的事故时有发生, 直接影响雷达设备正常运行和飞机飞行安全。因此, 对二次雷达站进行综合性防雷建设显得尤为重要。

1 雷电的形成及危害

1.1 雷电的形成

雷电是雷云之间或雷云与地面之间产生的放电现象。雷云内部或者雷云与雷云之间的放电, 叫云闪, 雷云与大地之间的放电, 叫地闪。云闪一般不会对人类活动造成影响, 对人类活动造成影响的主要是地闪。雷击灾害就是指由地闪产生的雷电流从云中泄放到大地上造成的危害。通常雷击有三种形式, 直击雷、感应雷、球形雷。直击雷是指闪电直接击在建筑物、大地、防雷装置、其他物体上, 产生电磁效应、热效应和机械效应的雷击。感应雷是指在直击雷放电过程中, 强大的脉冲电流对周围的导线或金属物产生电磁感应发生高电压, 继而发生闪击现象的二次雷。球形雷俗称滚地雷, 指通常在强雷暴时出现的外观呈球状的一种奇异闪电。由于球状闪电出现的频率很低, 科学家难以做系统的观测, 至今也没有人拍摄得高质量的照片来作科学研究。

1.2 雷击产生的破坏

1.2.1 直击雷破坏

当雷电直接击在建筑物上, 强大的雷电流使建 (构) 筑物水分受热汽化膨胀, 从而产生很大的机械力, 导致建筑物燃烧或爆炸。另外, 遭受直击雷的金属体 (包括接闪器、接地引下线和接地体) , 在引导强大的雷电流流入大地时, 在它的引下线、接地体以及与它们相连接的金属导体上会产生非常高的电压, 对周围与它们连接的金属物体、设备、线路、人体之间产生巨大的电位差, 这个电位差会引起闪络。在接闪瞬间与大地间存在着很高的电压, 这电压对与大地连接的其他金属物品发生放电的现象叫反击。

1.2.2 感应雷破坏

感应雷破坏也称为二次破坏。它分为静电感应雷和电磁感应雷两种:

1) 静电感应雷

带有大量负电荷的雷云所产生的电场将会在架空线路导线或其他导电凸出物顶部上感应出被电场束缚的正电荷。当雷云对地放电或云间放电时, 云层中的负电荷在一瞬间消失了, 那么在线路上感应出的正电荷也就在一瞬间失去了束缚, 在电势能的作用下, 这些正电荷将沿着线路产生大电流冲击, 对该线路上的设备造成破坏。

2) 电磁感应

雷击发生在供电线路附近, 或击在避雷针上会产生强大的交变电磁场, 此交变电磁场的能量将感应于在该磁场范围内的电子设备或设备电缆上, 进而对电子设备及线路造成破坏。由于避雷针的存在, 建筑物上落雷机会反倒增加, 内部设备遭感应雷危害的机会和程度一般来说是增加了, 对用电设备造成极大危害。因此, 避雷针引下线通体要有良好的导电性, 接地体一定要处于低阻抗状态。

2 二次雷达站的综合防雷

2.1 二次雷达站的环境特点

根据《航空无线电导航台和空中交通管制雷达站设置场地规范》中的规定, 空管二次雷达的场地应开阔、地势较高、四周无严重的地形地物遮挡, 并可获得足够的高、中、低空覆盖。因此, 二次雷达站多数位于山顶或者开阔的平原地带。以温州大罗山雷达站为例, 根据历史资料, 温州区域年平均雷暴日为51.3天, 属于强雷区, 而大罗山雷达站位于海拔700米的大罗山山顶, 四周开阔无遮挡, 整个雷达站就成了雷电容易袭击的对象。

2.2 雷达站供电系统的防雷

由于二次雷达站多数位于远离城市的山顶或者开阔的平原地带, 在建设二次雷达站时, 一般都需要引接或者单独建设配套的供电系统。由于电力部门对供电系统的防雷设计和施工往往存在不重视、不规范的毛病, 导致供电系统在遭受雷击后中断供电, 使雷达信号保障等级降低的情况时有发生, 以温州大罗山雷达站为例, 因电力部门的防雷设计缺陷及施工不规范, 2011年8月, 雷达站供电系统遭雷击, 导致一台配电变压器完全损毁。根据笔者统计, 2010年全年温州大罗山雷达站由于雷击造成的单路供电中断6次, 双路供电中断而使用油机供电3次, 因此有必要对供电系统的防雷进行综合建设。

供电系统的防雷重点在于输电线路防雷及配电变压器防雷。二次雷达站的供电系统输电线路一般采用10k V架空输电线路或者10k V电缆线路。对于10k V架空输电线路的防雷措施主要有以下几项:1) 可架设避雷线, 但由于成本过高, 施工不方便, 基本不采用避雷线;2) 提高线路绝缘子耐压水平, 将10k V绝缘子换为防雷绝缘子, 将大大提高防雷水平;3) 在多雷区应按照一定档距安装线路避雷器, 同时按照要求做好杆塔的接地, 减少雷击断线事故。目前国内10k V电缆线路广泛使用的是交联聚乙烯电缆 (XLPE) , 其在潮湿环境下运行形成水树枝, 水树枝在超高电场的作用下变成电树枝, 高幅值的重复中击电压是加速绝缘劣化并产生电树贯穿的主要原因。对电缆加装铠装或者穿金属管, 并且采用性能优良的金属氧化锌避雷器成为延长电缆寿命的有效方法。电力电缆由于其本身结构特点和与其他电气设施连接的要求, 采取在电缆终端头附近安装避雷器, 同时终端头金属屏蔽、铠装必须接地良好。

配电变压器遭雷击事故的主要原因是由于配电系统遭受雷击时的“正反变换”的过电压引起, 而反变换过电压损坏事故尤甚。由于低压绕组遭受雷击过电压, 通过电磁感应变换到高压侧, 引起高压绕组过电压的现象叫“正变换过电压”。由于高压侧遭受雷击, 作用于低压侧, 通过电磁感应又变换到高压侧, 引起高压绕组过电压的现象叫“反变换过电压”。在配电变压器高压侧装设避雷器, 能有效防止高压侧线路遭雷电波侵入而损坏变压器, 工程中常在配变高压侧装设FS-10阀型避雷器。高压侧装设避雷器后, 避雷器接地线应与变压器外壳以及低压侧中性点连接后共同接地, 以充分发挥避雷器限压作用和防止逆闪络。对于配电变压器, 即使高压侧装有避雷器, 仍然不可避免来自高压侧的反变换过电压或来自低压侧的正变换过电压, 在低压侧装设一组避雷器后, 正反变换过电压就可以受到限制。

2.3 雷达系统的防雷

雷达系统的综合防雷应遵循“综合治理、整体防御、突出重点、重点保护”的原则, 充分利用建筑物钢筋混凝土结构, 将防雷系统的接闪、分流、均压、屏蔽、布线和接地等六要素与建筑物的结构有机地组成一个整体, 进行综合治理, 并对电源系统和信号系统进行重点防护。

2.3.1 直击雷防护

雷电直击建筑物时, 将引起地电位急剧升高, 同时, 雷电流在引下线周围形成急速变化的强大磁场, 感应到雷达机房内通信系统及雷达设备, 会对其安全造成极大危害。防直击雷的装置是由接闪器、引下线、接地装置三部分组成。防雷原理是:由接闪器把强大雷电流接收下来, 然后通过引下线和良好的接地装置迅速而安全地把它泄入大地。根据《建筑物防雷设计规范》 (GB50057-94) 及《FAA-STD-019》的标准, 雷达站天线旁边及雷达天线罩 (有安装雷达天线罩的雷达) 均应安装防直击雷新型避雷针。在雷达塔台边缘等距离设置2到4根等高玻璃钢避雷针。为减少避雷针对雷达天线收发信号的影响, 避雷器支撑杆应采用具有良好电磁通过性的玻璃钢材料, 且玻璃钢材料支撑杆的高度应高于雷达天线顶端2m以上。接闪器安装在玻璃钢支撑杆上, 至少要延伸出玻璃钢顶端2英尺以上, 并可靠固定在玻璃钢杆上。按照《民用航空通信导航监视设施防雷技术规范》7.2.1.2b规定, “一、二次雷达塔的避雷针引下线不应少于四条, 引下线沿天线罩外壁均匀分布, 引下线应采用截面积不少于50mm2的多股铜线”。

2.3.2 感应雷防护

由于雷达站机房内的传输设备及雷达设备均为使用CMOS大规模集成电路的弱电设备, 内部芯片耐压水平低, 高强度的感应雷电脉冲将通过供电、通信、天馈电缆直接进入机房, 对这些设备造成极大的损坏。例如:2011年8月, 温州乐清雷达站发生雷击, 由信号线路进入的感应雷击击坏了Alenia二次雷达的编码器和EDR板。雷达机房的屏蔽是确保机房设备不受雷电感应脉冲损坏的重要措施。屏蔽的要点是:1) 充分利用建筑物的主体钢筋, 将其设置成格栅形屏蔽网格, 所有钢筋交叉接点均需点焊接地, 使之成为屏蔽网;2) 雷达主机房所有窗户亦应采用金属网格窗, 网格尺寸应小于200mm200mm, 和墙内钢筋屏蔽网连接形成一个整体;3) 机房采用静电地板, 板下设置2mm30mm规格的环型架空钢带以备设备保护接地及等电位连接用。在做好屏蔽的前提下, 对进入机房的所有供电线路及通信线路需采用加装铠装层或者穿金属管, 同时在于外界进行通信联系的设备线路接口端均应安装通道式避雷器。所有雷达站天馈设备的线路接口端均应安装相应接口参数的天馈避雷器。对于诸如围界监控、电力监控等附属设备, 由于设备重要性较低, 且设备线路连接贯穿雷达站, 应尽量移出雷达机房, 减少引入雷电波造成设备损坏的风险。

3 防雷系统及器件维护

防雷系统的建设并非是一劳永逸的工程, 诸如接地网的接地电阻变化、避雷器损坏老化、雷雨前后的防雷检查等问题, 均需要规范的制度建设将工作落实到日常的维护工作中。

3.1 地线的维护

地网的接地电阻每年至少进行一次测量, 地网的接地电阻标准为1Ω, 在辅助地级相对保持不变的情况下阻值不应有太大变化, 若测的阻值较大应在半年内重复检测, 若阻值一直呈直线上升则应找出原因。每年雷雨季节前应对接地系统进行检查和维护。主要检查连接处是否紧固、接触是否良好、接地引下线有无锈蚀腐烂、接地体附近地面有无异常, 必要时应挖开地面抽查地下隐蔽部分锈蚀情况, 如果发现问题应及时处理。

3.2 避雷器的维护

对避雷器进行日常维护时, 应观察防雷模块窗口有无变红色, 模块有无变形或拉电弧痕迹, 模块相应的熔断器有无损坏, 避雷器相应的开关或熔断应保证在合闸状态, 否则避雷器不起作用。雷雨前及雷雨后均应及时检查避雷器工作情况, 发现有损坏的或者性能下降到无法满足防雷要求的防雷模块, 应及时进行更换。雷雨季节每星期检查一次, 非雷雨季节每月一次。

4 结论

由于雷击造成的供电系统中断以及雷达设备损坏已经成为民航二次雷达站雷达信号保障的重大不安全因素。因此, 对于民航二次雷达站的防雷进行综合建设成为当务之急。本文只是简要的对民航二次雷达站防雷系统设计进行简要分析, 并且对笔者在雷达站的实际工作中积累的一些对防雷系统及器件的维护经验进行了总结。

参考文献

[1]建筑物防雷设计规范.中华人民共和国标准GB50057-94.

[2]电子计算机机房设计标准.中华人民共和国标准GB50174-93.

[3]FAA-STD-019E, FAA STANDARD, LIGHTNING AND SURGE PROTECTION, GROUNDING, BONDING, AND SHIELDING REQUIREMENTS FOR FACILITIES AND ELECTRONICS EQUIPMENT (22DEC2005) .

[4]李景禄.现代防雷技术.中国水利水电出版社.

空管雷达论文 第2篇

关键词：监视雷达,发射功率,一次雷达,射频

1、STAR 2000型一次雷达系统发射功率的检测与分析

依据中国民航局颁布的《空中交通管制S波段一次监视雷达设备技术规范》中的技术要求, 一次雷达的最大作用距离不应小于110Km (60海里) 。大连THALES一次雷达的最大作用距离为60海里, 对应的一次雷达发射功率为16千瓦。STAR 2000型一次雷达检测发射功率的方法主要有两种:

(1) 通过软件进行测量:也就是通过THALES雷达自身的远程监控系统RCMS或者参数设置软件CBP直接读出一次雷达发射功率的测量值。

在THALES雷达系统远程监控系统RCMS监控画面中使用鼠标右键单击RADAR QUALITY模块, 在弹出菜单中选择MEASURE-MENT选项, 弹出的窗口可以查看到STAR 2000型一次雷达的峰值发射功率, 点击Last Update按钮可以实时更新发射功率数值。

在THALES雷达系统本地监控系统LTM上使用参数设置软件CBP TMR STAR软件, 点击菜单栏的Command按钮, 在弹出的下拉菜单中选择连接STAR 2000型一次雷达主用通道, 等待CBP软件与雷达通道连接成功后, 通过System measurement参数项中的Peak power measurement for f1/f2子项可以查看到一次雷达的峰值发射功率, 发射功率数值自动实时更新。

(2) 是通过硬件进行测量:也就是使用合适量程的峰值功率计从STAR 2000型一次雷达的MWA 2000模块中的耦合器件DC5的耦合端口对发射功率进行测量。

下面以对一次雷达主用通道的发射功率进行测量来举例说明测量方法。1) 将备用通道的一次雷达处理机TMR切换至维护模式;2) 将全固态发射机SST2000机柜面板上的RFON/OFF开关切换至OFF档位;3) 拧下MWA2000模块中耦合器件DC5耦合端口的射频线缆W04;4) 将峰值功率计的传感器探头和衰减器与耦合器件DC5的耦合端口相连接, 应根据峰值功率计的量程选择合适衰减的衰减器, 衰减器连接在耦合器件DC5的耦合端口和峰值功率计的传感器的中间;5) 将一次雷达GRA2500模块中的TFH343接口板上的RC1滑轮旋至“4”档位 (RC1滑轮的档位“4”对应一次雷达的F1频率即2750Mhz, 档位“5”对应一次雷达的F2频率即2850Mhz) 。6) 将SST2000机柜面板上的RFON/OFF开关切换至ON档位, 然后从峰值功率计上读出测量数值Pm;7) 测量完成后, 先将SST2000机柜面板上的RFON/OFF开关切换至OFF档位, 再将RC1滑轮调回“0”即正常工作状态, 然后恢复至一次雷达正常工作状态。

以大连现场为例使用上文的测量方法测得峰值功率计的读数Pm为12.35dBm, 衰减器的衰减值为10dB, 耦合器DC5的衰减值为50.17dB, 可以计算得到大连STAR 2000型一次雷达发射功率PT为:PT=12.35+10+50.17=72.53dBm≈17.864kW

我们可以看出一次雷达辐射的信号从耦合器件DC5的耦合端口经射频线缆到信号分配器SPLT1的P1端口, 经过信号分配器后P2端口输出PWTST1信号, P4端口输出PWTST2信号, P3端口输出PWTST3信号, P5端口接假负载。可以分析出PWTST1、PWTST2信号一次为一次雷达A、B通道发射功率测试值的信号, 这两路信号分别送至一次雷达产生/接收单元GRU中进行处理。

上文所述软件测量方法一中THALES雷达监控软件RCMS和参数设置软件CBP都是通过这两个信号来测量一次雷达发射功率, 其不足之处有二: (1) 可变衰减器AT7或AT8的调整均可以改变RCMS和CBP所显示的测量结果, 所以当可变衰减器发生衰减值漂移或者调整不当的时候都可能造成一次雷达发射功率的软件显示值与实际功率值不一致。 (2) 在THALES雷达系统参数设置软件CBP功率测量换算系数表中参数值的改变, 也可以改变RCMS和CBP显示的一次雷达功率测量值。

从以上两点可以看出, THALES雷达系统自身对一次雷达功率测量值的可操作性很大, 所以使用峰值功率计的硬件测量功率方法在精确度上要优于THALES雷达RCMS和CBP的软件功率测量功率方法

2、结论与分析

综上所述, 可见与STAR2000型一次雷达发射功率的测量值有关的不仅是硬件衰减, 软件参数设置同样可以改变测量值。本文中通过对一次雷达发射功率的测量进行分析与实践, 阐述了发射功率的测量是通过一次雷达发射链路中的耦合信号进行测量的, 同时类比了通过在一次雷达接收链路中耦合嵌入测试信号, 也可以对一次雷达射频部分的接收处理功能进行测试与分析。这些针对STAR2000型一次雷达功能的测试可以应用于更换一次雷达射频部分器件之后对雷达性能的校验, 希望本文的观点可以给大家以参考和启发, 本文中还有许多纰漏之处, 望各位专家不吝赐教。

参考文献

[1]张蔚.《二次雷达原理》.国防工业出版社, 127-128页.

空管雷达论文 第3篇

关键词：飞行计划,雷达航迹,相关因子,SSR

一、引言

在空管自动化系统中, 飞行计划与雷达航迹的相关主要是指根据一定的准则将雷达航迹目标与飞行计划进行关联, 从而为管制用户提供较为完整的飞行态势信息。其中, 雷达航迹主要是指由雷达探测得到的空中目标的位置、方向、速度等数据;飞行计划是指预先或临时确定的与航班相关的飞行航线以及航班的速度、高度、时间、起飞机场、目的机场等参数的总和。通过将雷达航迹与飞行计划的融合, 可以充分利用飞行计划关于目标的属性信息以及雷达关于目标的位置信息, 实现对目标全面及时地了解和掌握。

二、飞行计划与雷达航迹相关技术分析

目前, 存在多种飞行计划与雷达航迹相关的技术, 如传统的SSR关联法;通过飞行计划的三阶段飞行模型航迹预测而采用的方向距离相关法;利用方向因子、偏航因子、时差因子的计算采用的最优关联阈值法;改进的MK-NN算法;基于模糊综合函数的飞行计划与雷达航迹关联法等。通过对以上技术的分析可知, 飞行计划与雷达航迹的相关技术大体上主要分为两类, 一类是采用二次雷达编码 (SSR代码) 关联方法。另外一类是通过建立计划航迹, 利用相关因子 (包含偏航因子、时间因子、方向因子、速度因子等) 和SSR匹配原则完成飞行计划与雷达航迹的相关, 本文定义此种方法为相关因子关联法。

2.1SSR关联法

SSR关联法主要满足以下条件: (1) 雷达航迹没有重复的SSR。若雷达覆盖的区域内航迹处在重复二次代码告警状态, 即同时存在有两个SSR代码相同的雷达航迹, 即使存在相应的飞行计划, 也不做相关处理。 (2) 存在与雷达航迹对应的飞行计划。如要完成雷达航迹与飞行计划的相关, 就要存在与之对应的飞行计划。目前, 飞行计划的来源主要包括RPL库和通过各种AFTN报文 (主要包括PFL、CPL、DEP、EST等) 创建。 (3) 飞行计划满足自动相关的条件。飞行计划只有处在预激活、协调、管制、移交等状态才能与雷达航迹进行相关。

2.2相关因子关联法

由于航班的飞行是有规律性和计划性的, 航班必须按照指定的航路飞行, 我们可以利用当前航迹点的偏航程度、时间、飞行方向、速度等因子, 通过与建立的飞行计划航迹进行比对, 以此来推断哪些飞行计划与哪些航迹点存在关联。

(1) 计划航迹的建立。计划航迹主要是根据航班的飞行计划, 通过航路转换, 将飞机的飞行航路信息转换成航路中各个关键航路点的信息, 这些航路点包括各导航台、各地理参考点、管制区的入界出界点、起飞落地机场等。 (2) 偏航因子。动态航迹点与某航路段的距离 (当前航迹点到航路段的垂直距离) , 可以反映该航迹点处于该航路段的可能性大小;若该航路段是某飞行计划航路的一部分, 则这种偏离程度代表了航迹点偏离计划航路的距离程度, 偏离程度越高说明该航迹与某计划航路相关的可能性越低, 我们认为它是动态航迹点与飞行计划关联质量的一个因子, 并称之为偏航因子。 (3) 时间因子。将雷达航迹点在某航路段上投影, 根据飞行计划信息可以计算出航空器预计到达该投影位置时的时间, 该预计时间与雷达航迹当前的时间相比较存在的时间差, 可反映该航迹点在时间上偏离计划航路的程度, 差值越大, 说明该航迹与某计划航路相关联的可能性越低。 (4) 方向因子。航空器在某航路上飞行是有一定的方向的, 因此可以认为飞行计划中的各航线段也是有方向的。对于入港和飞越的航班, 在其进入交接点附近时予以检查, 雷达航迹的飞行方向与飞行计划的方向应大致符合, 若当前航空器航迹点的方向与某航路段方向的夹角越小, 则该航迹点与该航路段的关联可能性越高。 (5) 速度因子。航空器在飞行过程中是有速度的, 而飞行计划中也有巡航速度信息。如果在某时刻航空器的飞行速度与计划航迹中的巡航速度相差很大, 那么该雷达航迹与飞行计划关联度视为很小。本方法的缺点是由飞行计划推出的计划航迹与真实飞行情况相比, 误差较大。而方向因子、偏航因子、时差因子所确定的阈值范围较大, 在空中目标较多的情况下容易引起误关联。

三、飞行计划与雷达航迹相关解决方案

为保证飞行计划与雷达航迹的相关率, 同时考虑到算法的复杂性, 目前的自动化系统大多是综合上述两类方法, 并结合各管制区域的特点, 较好的解决了飞行计划与雷达航迹的相关问题。然而, 在自动化系统的实际运行中, 由于人为及天气等因素, 往往导致飞行计划与雷达航迹的相关出现不匹配的现象。

造成上述问题的根本原因有两种, 一是管制相关区域内同时存在有两个SSR代码相同的雷达航迹;二是对于同一航班存在两个计划航迹且预分配了相同的SSR。因此, 会出现以下三种情况: (1) 一个雷达航迹对应两个计划航迹; (2) 两个雷达航迹对应一个计划航迹; (3) 两个雷达航迹对应两个计划航迹。

针对上述问题, 本文提出了一种飞行计划与雷达航迹相关的解决方案, 具体内容如下:

(1) 根据整个管制区的情况, 建立两个相关区域:第一个区域本文定义为相关区域A, 以跑到中心点为中心, r为半径, h为高, 建立一个柱体, 其中r、h根据实际情况设定。相关区域A主要是用于本场起飞的航班在塔台管制范围内进行相关处理。第二个区域本文定义为相关区域B, 将管制区边界外扩D, 高为H, 并去掉第一个区域而形成的柱体, 其中D、H根据实际情况设定。相关区域B主要是用于第一种情况外的相关处理。

(2) 相关区域A的相关处理:对于相关区域A, 主要关注的是本场起飞航班的情况。在进行相关处理前, 需建立本场起飞航班的计划库。相关区域A内的相关处理, 仅需查询本场起飞航班的计划库即可。因在本场起飞的航班涉及到跑道、起飞方向的动态变化, 所以雷达航迹的偏航因子、速度因子、方向因子等均不能作为表征因子, 而仅靠时间因子其准确性较差, 所以在相关区域A内, 不适宜使用相关因子关联法, 只能采用SSR关联法。

对于一个雷达航迹对应一条飞行计划的情况, 采用SSR关联法。对于两个雷达航迹对应一条飞行计划的情况, 若两个雷达航迹均在相关区域A, 不做相关处理;若一个雷达航迹在相关区域A, 另一个雷达航迹在相关区域B, 相关区域A内的雷达航迹可以完成相关。

对于一个雷达航迹对应两条飞行计划的情况, 不做相关处理, 可由管制员手动选择相关。对于其他情况, 不作相关处理。

(3) 相关区域B的相关处理。对于相关区域B, 主要关注的是本场落地及飞越航班的情况。在进行相关处理前, 需建立本场落地及飞越航班计划库。相关区域B内的相关处理, 仅需查询本场落地及飞越航班计划库即可。在相关区域B, 可采用SSR关联法与相关因子关联法相结合。

对于一个雷达航迹对应一条飞行计划的情况, 采用SSR关联法。对于两个雷达航迹对应一条飞行计划的情况, 若两个雷达航迹均在相关区域B, 采用相关因子关联法;若一个雷达航迹在相关区域A, 另一个雷达航迹在相关区域B, 相关区域B内的雷达航迹可以完成相关。

对于一个雷达航迹对应两条飞行计划的情况, 采用相关因子关联法。对于其他情况, 不做相关处理。

四、总结

空管雷达站设备管理数据库研究开发 第4篇

关键词：雷达站,设备管理,数据库

1 计算机数据库

自从计算机在1946年发明后不久,人们就遇到了管理大量数据的问题,由此诞生了数据库技术。数据库技术诞生于20世代60年代,现在,在计算机三大应用领域(科学计算、数据处理和过程控制)中,数据处理占70%,所以数据库技术已经是现代计算机系统的一个重要组成部分。利用计算机数据库进行辅助设备管理,一方面可以提高效率,节约时间。另一方面可对设备由原来的静态管理转变为动态管理,使设备管理一直处于最优状态。现在计算机数据库用于设备管理越来越受到重视,设备管理数据库的标准体系也被提出和加以分析研究。

设备管理是对设备的购置、安装、使用、维护、修理、改造、更新直至报废的全过程进行管理,它是一个复杂的系统,需要科学的管理。计算机数据库技术计算速度快,处理数据量大,方便维护使用,所以在很多地方都采用了计算机数据库技术,如文献所提出的航空发动机维修成本数据库等等。

当前,计算机数据库软件很多,如Access,VFP,My SQL, Orcle,DB2等等。其中常用的中小型数据库软件以VFP(Visual Fox Pro)最为常用。该软件表操作简单 , 迅速 , 实现人机交互简单 . 可以编写各种的人机交互系统,使开发者能够轻松使用,对于编写管理信息系统有很大的帮助。所以在航空雷达站设备管理数据库中采用VFP软件进行编写。

2 雷达站设备管理数据库设计分析

雷达站设备管理数据库的设计思想是希望通过数据库可以对当前各设备的大致状态(正常还是待修)有一个了解 ;设备相关的备品备件存放处可以通过本数据库能够迅速找到 ;另外还要有增加设备和减少设备的功能,这是因为雷达站时常要更新一些设备 ;能够对设备进行查询,即通过我知道的设备名称能够查询出相应设备的各项信息来 ;要能够对一些信息进行修改,因为设备的状态或备件的存放地点有可能发生改变,这样就要对相应信息进行更改,以便使设备的信息与设备的实际情况相一致。

基于以上设计思想,在设计数据库时建立了6个功能模块,这六个功能模块分别是搜寻模块、查询模块、添加模块、删除模块、编辑模块以及打印模块。其中搜寻模块有四个功能键组成,分别是第一个、最后一个、下一个、上一个。可以通过这四个功能键对设备进行搜寻,同时也可对所有设备进行一个整体了解。查询模块是为了方便维护人员迅速地找到相关的设备信息,维护人员可以通过输入自己所知的设备的名称直接就使数据库给出相关的设备具体信息。

以上这六个模块基本满足了雷达站设备管理的需要,对设备维护人员是一个很大的帮助,尤其是对新参加工作的设备维护人员来说,无疑是一个很好的帮手,使其无需死记硬背一些死信息,就像一个助手一样帮助了解设备的相关信息。由于是雷达站的内部数据库,避免不相干的人进入,以免造成数据库的混乱,因为本数据库的设计使得进入本数据库的人员对数据库拥有很大的权利可以任意的更改以及增删设备信息,所以安全性是一个重要的问题。在这里,设计了一个密码界面,进入设备数据库的人必须输入正确的密码,否则无法进入。设备数据库的设计思想基本可以通过设备数据库原理框图说明,原理框图见图1。

当通过搜寻模块表单或查询模块表单进入到相应的设备表单时,为了更好地使所建立的数据库服务于实际工作,这里把数据库分成了三个功能模块(见图2)。

在这三个功能模块中,设备明细功能模块的作用主要是提供设备的一些基本信息,例如设备名称、产地、件数、现工作状态是否正常、有无备件等等。便于对相应的大型设备有个总体的把握。

维护记录菜单下包含了三个维修维护人员的子菜单,提供相应工作人员以前的维修维护信息,其功能框图见图3。

针对与每个操作者,提供了相应的以前维修记录。其中包括设备名、维修内容以及维修日期三项。相应的还有一些功能按钮提供一些必要的功能。

其中,使用备件按钮的启动将调出相应设备备件,可以输入所使用的备件个数,则相应的库存备件数就会减少,从而实现备件表的更新。查看记录的设立为的是可以使操作者查看以前的维修记录。新记录的设立是为了让操作者输入新维修记录,以便有利于实际工作需要。确定关闭都是辅助按钮,目的是确定新记录的完成和退出界面。

以上各功能模块,从各个方面进行了考虑,从而保证相应机器设备管理工作的有效进行。

3总结

空管雷达论文 第5篇

一直以来,固定资产的管理都是某科室管理工作中的一个重点,也是一个难点。其原因是直属的各个雷达站分布在不同的地理位置,并且每个雷达站区域范围较大,台站内资产种类繁多。长期以来,对固定资产管理所采用的都是传统纸质的管理方法,这种采用纸质记录本登记和管理固定资产的方法存在以下众多问题:

(1)本台站人员无法快速了解其他台站的资产情况,只能通过电话咨询的方式来了解其他台站的资产情况。

(2)当某件资产因借用或维修等原因在各个雷达站之间移动时,无法对该资产进行快速的跟踪及确定其当前位置。

(3)纸质记录本较难包含某件资产所有的相关信息,资产的转移、清理等过程缺少详细的记录。

(4)各雷达站间人员流动较大,当负责固定资产管理的人员调离本岗位后,后续负责资产管理的人员需要较长时间熟悉本台站的资产情况,包括资产的存放地点,启用日期,使用情况和数量等。

(5)造成资源浪费,当上级资产主管部门重新进行资产核查时,需要大量纸张打印新的资产登记表。

此外,纸质的资产管理方法还存在查询速度慢、责任不清、记录不利保存等问题,效率低下。而基于现代计算机系统的数据库技术是提高企业资产管理效率最为有效的方法。因此,非常有必要针对以上问题,设计与研发一套贴合自身实际应用的固定资产管理系统,用以对某科室范围内的资产进行集中、高效的管理。

1 系统需求分析

空管雷达站固定资产管理系统作为一种企业内部信息管理系统,宜采用C/S(客户端/服务器模式)结构,原因是C/S结构在运行速度、数据安全、人机交互等方面要优于B/S(浏览器/服务器模式)结构,它的优点是能充分发挥客户端PC的处理能力,服务器对客户端的响应速度快,适用于传输速度较快的企业内部网[1]。因此本文的固定资产管理系统选用C/S的结构。

在雷达设备室的日常工作中,资产管理工作主要涉及资产的新增登记、属性修改、进出站、转移、清理和查询等方面。每件资产所包含的属性信息有资产名称、类别、局编码、中心编码、制造厂家、规格型号、系列号、所属台站、存放地点、使用情况、数量、计量单位、原价、增加方式、启用日期等详细的信息。系统在设计时应满足以下要求:

(1)客户端程序在使用上力求操作容易,界面美观,显示条目清晰,在资产登记表里应能包含每件资产所有的属性信息。

(2)需具备资产管理(如新增登记、修改属性、转移、清理等)、资产进出站管理、添加检查/故障记录、数据导入/导出等功能,并着重解决以往资产进出站跟踪难,责任不清等难题。

(3)需具备有较强的检索能力,可以对任意字段、多种组合进行模糊查询,要方便快捷地找到所要查询的各种记录。因为使用时间一长,系统将产生大量的文件和数据。

(4)为不同的用户设定不同的使用权限,较好地保护数据的完整性和安全性。系统管理员可以进行所有的操作,包括资产的转移、清理,删除资产登记记录等;而普通用户只能进行查询、进出站等不影响原始数据安全的操作。

(5)所有用户对数据的操作都将被录入到数据库中,为后期的相关责任追究提供便利,做到责任明确,系统规范使用。

此外,空管雷达站固定资产管理系统还应该具备较高的可扩展性和可维护性,为后期在需要时对软件进行升级。实际上,系统在实际应用中为了迎合日常的使用要求,要不断地进行改进升级才能日趋完善。

2 系统设计与实现

根据前面的需求分析,空管雷达站固定资产管理系统按功能分主要有三大类:资产管理、快速查询和用户管理,其组织结构如图1所示。

系统的设计与实现过程主要围绕这三个功能模块来进行,其开发过程主要包括后台数据库的建立和客户端应用程序开发两部分。对于数据库要求建立数据一致性和完整性强、数据安全性好的库,而对于客户端应用程序则要求应用程序功能完备,容易操作。经过分析,本文采用SQL Sever 2005作为后台数据库系统,Microsoft Visual C++6.0作为客户端应用程序开发工具。这两者均为微软公司的产品,在连接访问和数据安全等方面有较高的可靠性和稳定性,本文详细介绍系统具体的实现过程。

2.1 后台数据库的建立[2]

数据库在企业信息管理系统中起着非常重要的作用,数据库结构设计的好坏将直接影响系统的运行效率以及数据的完整性和一致性。在设计数据库前应充分考虑实际应用的各种要求,包括现有的及将来可能增加的要求。

根据前面的需求分析以及实际中各类资产记录的属性信息,在开始编写客户端应用程序之前,需要先设计好数据库。本文利用SQL Sever 2005创建了一个名为RMSystem的数据库,在该数据库中共建立了7张表,分别用于存放资产登记记录、资产进出站记录、资产转移记录、资产清理记录、设备的故障/检查记录、用户历史操作记录以及用户信息。为方便查找,每张数据表中应尽量包含所有的相关信息,越详细越好。图2为资产登记数据表所包含的属性信息。

在资产登记数据表中,备注信息这一属性是非常关键的。它用于存放某件资产包括设备、备件等除了其他属性以外所有的相关信息,包括该资产的各个组成部分、历史信息等等。在客户端程序主界面中该属性用专门的文本框进行显示,而其他属性分列在视图列表控件中进行显示,这样数据信息在程序界面上显得既直观又全面。

空管雷达站固定资产管理系统除了对固定资产进行高效地管理外,其另一个需要着重解决的问题是对资产进出站的管理。以往的纸质管理办法是每个台站都有一本资产进出站记录本,用于记录该台站的资产进出情况。这样,当某件资产频繁在几个台站间移动时,每个台站都需对其进行重复登记;此外,当缺漏某一台站的登记记录时,无法对该资产进行快速跟踪,确定其目前的所在位置。因此,在设计资产进出站数据表时应对资产进出站的整个流程进行全盘考虑,所有台站的资产进出站记录共享一张数据表。一般来讲,一件资产因借用或送修等原因从某个台站出站到最终返回该站,一般要经过这样一个过程:出站对方接收对方返还入站,中间还经常有在其他台站中转的情况。因此,该数据表中所包含的属性信息如图3所示。

当一件资产从某个台站出站被送到另一个台站,在对方处理完毕后直接返回原所属台站的情况下,图3这些属性可以较直观地记录该资产的进出站信息。若该资产在返回过程中还需要中转至其他台站,则送到第三方台站后该台站的接收人、接收日期等信息可以全部添加到中转/备注信息中。同样地,中转/备注信息在系统程序界面中也是用专门的文本框进行显示,其他的属性信息分列显示在视图列表控件中。这样,通过共享同一张资产进出站数据表,每个人员都可以较直观地通过该系统跟踪各个台站每件资产的进出情况,以及确定该资产当前的所处位置。因此,系统的资产进出站管理功能较好地解决了以往资产进出站跟踪难、责任不清等难题。

其他的数据表如转移记录、清理记录等与资产进出站数据表类似,均按实际使用要求进行设计。值得注意的是,当新增一件资产时,系统为该资产在资产登记表里自动分配一个唯一的资产编号,用于与资产进出站数据表、转移数据表、清理数据表里的同一件资产进行相关联,保护数据的完整性和一致性。

2.2 客户端应用程序设计[3]

本文选用Visual C++6.0作为客户端应用程序的开发工具。Visual C++的微软基础类库MFC封装了大部分的API函数,并提供了一个应用程序框架,简化了和标准了Windows程序设计。在可能的情况下,使用Windows的通用控件,可以大大减轻编程的工作量。同时,在Windows个人桌面系统普及的今天,基于MFC开发的应用程序较好地迎合了人们的日常使用习惯,这种界面的一致性使用户可以轻松学习使用新的软件。

本文中系统客户端应用程序的设计思路是,利用MFC创建基于对话框的应用程序,运行客户端程序时先进入用户登录界面,进行用户身份验证后进入程序主界面。在程序主界面中,利用列表视图控件以报表的形式显示资产登记表中的资产的所有属性;组合框控件和树形视图控件组合在一起,用于对资产登记表中的资产按台站、类别进行查询,例如查询某个台站的空调、消防器材等;资产管理功能由一系列按钮控件以单击弹出相应对话框的方式来完成;通过这些对话框和控件,实现了应用程序和用户之间的信息交换,进而完成对数据的增、删、改、查等操作。客户端程序主界面部分截图如图4所示。

系统客户端应用程序除了需要设计完善的资产管理功能之外,还需要设计全面的、反应迅速的查询功能。因为随着系统的应用,数据库中将积累大量的数据。因此需要在资产登记表、资产进出站记录、资产转移记录和资产清理记录中,都具备对资产记录的所有属性进行组合模糊查询的功能,这样可以方便快捷地找到所要查询的资产记录。通过编写高效简洁的SQL查询语句实现这一功能,最多可以实现6种不同组合的模糊查询,如图5所示的在资产进出站中的查询功能。

此外,客户端应用程序还需具备用户管理、数据导入/导出,查看已到报废年限资产等功能,以及用户登录系统后,如本台站有资产进出站时,提示该用户填写相关记录的功能。客户端应用程序具体的实现过程此处不再详细进行介绍。

3 系统应用

空管雷达站固定资产管理系统自启用一年多以来,运行稳定,功能全面,涵盖了本科室日常工作流程中对资产增、删、改、查以及数据备份恢复等基本管理功能。通过新增登记、属性修改、转移、清理、添加故障/检查记录等功能可以动态地对本科室范围内的资产包括各种设备、备件等进行高效的管理;完善的资产进出站管理功能着重解决了以往资产进出站跟踪难,责任不清等难题;通过一系列的快速查询功能,可以方便地获知每件资产的使用情况、当前所处位置和其他的属性信息。此外,数据导入/导出功能为数据库与Excel表之间的数据录入和导出提供了极大的便利;查看已到报废年限资产的功能可为各台站与本科室的资产管理员及时了解资产报废情况提供最直观的信息。空管雷达站固定资产管理系统主要有以下几个特点:

(1) 系统采用C/S结构,基于企业内部局域网连接。由于采用的是点对点的结构模式, 数据安全 性得到可靠的保证。

(2) 实用性强,完全按照雷达设备室的日常使用要求设计,有效地解决了传统纸质固定资产管理方法存在的难题。

(3) 系统界面友好,操作方便,具有较高的可扩展性和可维护性。

(4)查询功能极为出色,最多有达到6种组合、任意字段的模糊查询方式,可方便快捷地找到所要查询的各种记录。

4 结束语

空管雷达站固定资产管理系统是某科室利用自身的技术与资源优势,结合实际工作需要自行开发的信息管理系统。该系统的启用有效地解决了以往雷达设备室在固定资产管理工作中存在的难题,为实现对某科室的固定资产和资产进出站进行系统化、规范化的管理提供了有力的技术手段。同时,该系统自启用以来,极大地提高了科室固定资产管理的工作效率,让各台站和科室的资产管理员从繁琐的固定资产管理工作中解脱出来,将主要精力投入到设备保障的安全生产当中。

摘要：在详细分析了某科室对各个分散的雷达站内的资产进行集中高效的管理需求基础上,利用SQL Sever数据库和Visual C++6.0集成开发工具,自行研发一套贴合实际应用的固定资产管理系统。系统自投入使用一年多以来,运行稳定,使用方便快捷,极大地提高了某科室固定资产管理工作的效率。

关键词：固定资产管理,雷达站,人工管理方法,固定资产管理系统

参考文献

[1]朱晔.ASP.NET第一步[M].北京:清华大学出版社,2007.

[2]邹建.深入浅出-SQL Server 2005开发、管理与应用实例[M].北京:人民邮电出版社,2008.

空管雷达论文 第6篇

当前,在民航空管系统中大多数雷达数据采用的是传统的A/C模式,该模式在目标数量增加到某一设计局限阈值时将会出现很多问题,包括代码数限制(只能为4096个)、雷达数据目标串扰、混扰,对于航班量较多的机场管制工作,自动化的监视能力将会达到极限,这是空管工作安全绝不允许的。美国MIT林肯实验室提出的S模式,能较好地解决以上问题,并作为国际民航组织接受的一种行业标准逐步替代传统的A/C模式,而这个过程,在中国民航业内尚需时日。因此对其进行一些前期的实验测试,不仅必要而且紧迫。为此,本文以汕头空管站实际Thales雷达为例,利用自动化ATC3000协议转换器开发了一套能够进行S模式测试的实验平台,并对此做了数据融合方面的讨论。

1 关于S模式及优点

S模式的定位精度高,目标容量大,对于高速发展的民航业来说,无疑是最适应的一种模式。其在数据传输过程中,提供了数据可校验。采用了奇偶校验位保护数据(实际工作中有24bit)。而这种校验的产生完全通过冗余编码进行实现,主要通过雷达数据的前32bit或88bi进行生成。冗余方式可以通过与雷达数据的24bit的地址码进行作模2进行操作,并存储与数据规定的AP字段。接收方面则大量采用如“whole message”和“brute force”等技术。这使得数据的准确性进一步的提高。也为测试平台的设计提供了一种参考。另一方面,其将提供点名呼叫,对数据进行目标识别后入库大大提升了前台终端及数据的简洁性,能够减少目标的同步混叠干扰。对于测试平台(仿造自动化设计)的数据处理带来更大的便利。最后,也是测试系统实现的另一个目的,S模式能够提供良好的模式兼容性。在数据融合上,S模式可以采用异频收发的方式,应答A/C模式与S模式的询问,这使得S模式的接入能够完全不影响现有的A/C模式,使得数据的融合变得更加容易。对于具体的S模式的格式与数据模式,由于篇幅关系,不再赘述。

2 系统的设计

系统主要包括初始化模块、数据接收模块、数据解析模块以及数据融合模块。

2.1 数据初始化模块

主要应用于对测试平台的系统坐标、地图设置、经纬度定义等为测试必须的条件做准备。在系统坐标上,根据文献[1]采用的是麦卡托投影法,实验证明该方法能够较好实现测试平台的设计及工作要求。在c#设计中采用picturebox控件进行设计。对于控件坐标而言,系统是以左上角为基准点(原点0,0),往右为X轴正方向,往下为Y轴正方向的。而地图坐标则是以左下角为基准点,往右为X轴正方向,往上为Y轴正方向,并且可以通过平移缩放等功能,将基准点移到任意点上。这里需要使用坐标的转换来完成控件坐标到地图坐标的转换关系。因此可以定义转换函数如下:

另一方面,地图的设计则通过ATC3000自动化的文件进行数据提取并加入到C#中的列表list。地图显示模块则对列表list进行遍历,通过画笔直线进行点与点之间的连接,实现地图绘制。而对于经纬度,以系统中心点作为雷达中心(减少坐标变换次数,降低开发难度),设置相应的参数进行比例尺缩放设计。其余初始化类同。

2.2 雷达数据接收

雷达数据主要通过ATC3000自动化协议转换器进行数据的HDLC转换为UDP协议数据,进行网络广播。因此只需要对其进行网络接收并按照厂家规定的格式进行数据提取便可以实现对雷达原始数据的处理,此处不涉及S模式的解析。在C#设计中,UDP的设计有如下(相当于测试平台是接收终端,而协议转换器是服务器):

2.3 雷达数据的解析模块与融合

对于接收到的雷达数据,S模式与A/C模式虽然格式各异,每一个bit都代表不一样的数据或功能,系统主要实现的是按照规定标准进行解析。而这个标准的解析,直接可以采用模板设计,对其进行模板套用便可以高速将来自雷达接收模块的数据进行分类解析。这个过程将大量应用C#中的字符串处理,包括二进制与十六进制的转换、正则表达式的数据提取以及相关截取字符串的函数。而对于融合设计而言,为了提高测试平台的稳定性,在显示处理之前首先对雷达数据进行二次代码一致性检查,并设置相应的优先级(与现行自动化相似);另一方面,由于跑道的特殊性,在设计上必须对目标进行设定屏蔽区(需要根据当地情况进行设计,这也是3.1地图处理部分功能);再之,则是对于测试平台将采用S模式的24bit地址码作为数据融合的唯一条件以降低系统的目标分裂错误,提高融合数据的可信度。雷达解析数据程序有:

3 结束语

本文提出一种基于C#的空管自动化S模式测试平台,该平台以现运行的雷达、自动化为工具环境进行实地开发,并对数据的完整性和融合性进行了数据实现和测试,了解了S模式的实际工作状态。为S模式引接提供了一种前期准备思路,也提供了现行自动化的多种数据接入一种技术保障手段。

摘要：本文提出一个基于C#设计的自动化平台,该平台应用厂家ATC3000开发的协议转换器,通过ATC3000自动化的自有协议进行设计,实现了对S模式的测试。另外本文将对来自S模式的雷达数据进行融合方面的研究,为S模式应用于空管实际工作做好技术实验。

关键词：雷达数据,S模式,C#,空管自动化

参考文献

[1]曾培彬.基于分布式计算的雷达显示系统设计[J].北京联合大学学报,2013(01).

空管雷达论文 第7篇

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

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, 由此推测管制员在此航班起飞前再次修改了二次代码。为验证此推测, 继续查找日志的相关记录, 命令如下:

由上面一系列日志证实, 确实是因为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时由进近管制员进行了一次释放, 一次释放之后, 标牌立刻由全标牌变为简标牌, 下一秒又自动相关, 变为正确的出港计划的全标牌。针对这一现象, 继续查找计划日志, 命令如下:

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

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

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

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

2.3 案例三

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

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

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

日志原文如下所示:

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

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

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

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

3 结论与建议

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

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

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

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

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

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

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

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

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

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

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

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

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

摘要：本文主要通过三个典型的雷达航迹与飞行计划无法自动相关的案例, 来说明遇到此类问题时, 通常的分析思路、用到的UNIX命令, 以及无法自动相关的一些特殊原因。

关键词：空管自动化系统,雷达航迹,飞行计划,自动相关,UNIX命令

参考文献