雷达终端自动化系统瞬断故障分析与排除 _研究生毕业论文 -经管之家官网！

免费学术公开课,扫码加入

摘要：本文针对洛克西德马丁雷达终端自动化处理系统在运行中出现的一例较为复杂的系统瞬断故障进行深入分析研究，并在分析研究的基础上改造了原系统的网络传输结构，成功地解决了此问题。

关键词：雷达终端自动化处理;ORACLE数据库;网络拓扑;网络流量分析;高级复制

0、引言

ASTEC系统是美国洛克西德马丁公司生产的多雷达终端自动化处理系统。江西空管分局的马丁系统于2000年引进，已运行近1O年。该系统为管制部门提供稳定连续的实时动态飞行信息及管制辅助功能，最大能处理8部雷达信号。系统采用星型和总线型混合以太网结构，总共挂接了包括区域管制室和塔台管制室在内的14个显示终端处理器【1】。系统目前引接了6部雷达信号，比当初建成时多了一倍。随着数据处理量的增大，系统的一些问题逐渐暴露出来，如最近两年来该系统连续出现双通道非人工干预下的自动切换以及管制席位短暂雷达目标丢失，即所谓的瞬断现象，尤以最近以来这种瞬断现象出现频繁且成上升趋势，甚至每天多达4至5次，严重影响到管制指挥工作，威胁空管安全。本文就该故障排除过程进行分析论述，供大家参考交流，希望能对技术人员在今后排除类似故障有所启发。

1、故障现象系统瞬断现象出现没有规律，有时为整个系统出现，即所有显示席位出现短暂目标丢失，也有仅单个管制席位出现瞬断现象的情况。该现象发生时，雷达目标丢失约一个雷达扫描周期，随即恢复正常，观察技术维护席的系统状态窗无任何告警信息，管制席在工作期间有时伴有管制员发出的计算机指令，响应极慢，键盘锁死，不能正常调用飞行计划的现象。除系统雷达数据处理机OPS0/OPS1双通道出现自动切换外，所有席位的进离港列表和区域进出列表等内容全部丢失。技术维护人员只能从系统状态窗的OPS0/OPS1颜色判断主用机器的切换，此时偶尔伴有ORA CLE数据库出错信息，如oracle interface processing error，也有FDP未激活的提示。

2、故障分析考虑到全系统瞬断问题比较严重，危害性大，笔者决定抓住关键，集中主要精力重点突破，同时兼顾单席位的瞬断问题，排故过程中如发现二者之间存在关联可予以合并。但引起这种软故障的原因很多，涉及面宽，查找难度较大，排除周期长。经过技术人员对多次故障发生现象分析，瞬断的主要原因就是两台雷达数据处理机OPS自动切换造成的，因为人工切换OPS也会出现这个现象。什么原因导致OPS自动切换，为什么在瞬断的时候会伴有ORA CLE数据出错的情况。笔者认为这之间有必然联系，或许是由数据库出错导致切换。因此我们决定先从数据库分析着手解决这个问题。

以往出现数据库出错时(比如不能扩展表空间或写表出错等情况)，我们往往执行系统提供的Purge.sh脚本。分析该脚本后我们发现它把数据库全部清空，然后重新启动数据库，之后系统可以稳定运行一段时间。如果不清空数据库而是直接重启系统的话系统依然不稳定，OIP(Oracle数据库接口进程)一直报错，这说明是系统数据库的错误导致单机不能提供服务。因为管制员的操作大部分与飞行数据有关，而这些数据又多存在数据库里，所以管制员的键盘指令出现TIMEOUT现象，即我们称之为死锁的情况。因此我们可以认为单个OPS上数据库问题导致另一台OPS认为主用系统不能提供服务，于是切换机制使备用系统成为主用，继而出现了瞬断现象。但是另一个问题是：备用系统既然成为主用了，为什么数据库还是报错，依然不响应管制员操作，一定要清空并重启数据库才行。

进一步分析后，我们认为此时数据库的错误必然和两个OPS有关，或者说在两个OPS上都出现了错误，只是系统仅仅显示了主用系统的错误信息。马丁系统采用Oracle高级复制技术嘲同步两个OPS的数据库，通过网络包分析，OPS之间通信数据量很大，系统采用3COM 的1OMbps集线器，集线器上有网络利用率指示，发生数据库出错时网络数据量很大。因此我们推断因为网络堵塞的原因造成高级复制的同步不能完成，同时造成主用OPS不能及时响应管制员操作。

网络上的六台数据处理机接在lOMbps的HUB上，采用10Base-T接口，而在HUB的AUI口通过粗铜轴缆从机房到区域调度室再到塔台连接共12个终端工作站。很明显马丁公司为节约成本且又顾及网络传输的距离使用了10Base一5技术，所有计算机都共享10Mbps的带宽。我们通过网络流量分析软件snifer[.5]进一步分析整个系统的数据流量，如表一所示。

从表一中可以看到IP地址末位为20和21的机器之间数据通信量几乎为整个系统的一半以上，其次是20主机的广播数据占了30%以上，这两台主机正是自动化系统的主要雷达飞行计划数据处理机(OPSO和OPS1)。经过分析，广播数据主要是OPS向各席位主机发送的目标报告和时钟等数据，而OPS之间的数据传输为Oracle数据库之间的通信和同步数据。由此我们可以得到这样的结论：该自动化系统大部份的数据交换途径是通过了HUB上的采用10Base—T接口的机器之间完成的，还有一部份数据是通过HUB 上的AUI接口进人挂在基于lOBase.5协议的粗缆上的终端工作站，而所有这些数据的宽带都是10Mbps，而且数据在粗缆中传播时延还没考虑。可见该系统在雷达接人数量较少时这l0M 的宽带还能满足要求，随着雷达接人数量增多，并且飞行计划数据也接人后，系统的带宽就相对不够用了，不断增加的数据量还增大了网络冲突的概率，导致网络出现阻塞，也使得带宽的利用率进一步下降。所有这些最终导致一个严重的后果，就是数据库之间通信和高级复制不能实时完成，很多需要同步的数据积压导致数据库最后崩溃。同样此时终端工作站的数据连接请求在飞行计划处理机上也得不到响应，出现无响应和timeout的情况。

3、故障排除针对以上分析得出的结论，我们决定改造马丁系统的网络，最简单直接的想法是增加网络带宽以减少网络阻塞。于是我们直接抛弃了IOM 的HUB，更换为100M的交换机，更换了所有机器的IOM 网卡为100M 网卡。由于区域管制室的机器离终端机房近，不足4O米，我们甩掉了10Base一5的粗缆重新铺设了五类线。到塔台管制室的机器由于距离远，我们保留使用了10Base一5粗缆，仍然通过原来10MHUB的AuI接口接入网络，但是这根粗缆上面只挂接了塔台的两个终端工作站但是这样经过网络改造好的系统在稳定工作一段时间后还是出现了瞬断现象，不过没有出现过整个系统瞬断问题，只是单个终端工作站上瞬断。我们再次用Snifer软件分析网络数据，发现了新问题，网络里有不少过期数据。

详细分析后我们得出结论：系统为保证数据的实时性，在原来HUB传输的基础上将所有数据包的生存期TTL都设的很小，为1秒。然而通过交换机后，由于交换机存储转发机制的存在，在数据量大时，数据的时延很大，竟然有2秒多，这样的数据被交换机转发到网络上时就直接被终端工作站抛弃。单个工作站在一段时间内由于收不到飞行计划处理机的及时响应而认为该主机停止工作，自动切换去连接备机而把当前所有数据放弃，最终导致出现瞬断现象。基于此结论我们不得不放弃了100M 的交换机而改为100M 的HU B，改造完成的系统网络拓扑结构如图二所示。

经过这样改造以后，系统从2007年3月运行至今，稳定性一直非常良好，基本上没有再出现过原来的数据库出错和键盘锁死情况，从而彻底解决了系统原来存在的问题。

4、结束语

随着飞行流量的增加，雷达终端自动化处理系统在空管技术保障体系中的作用日益突出，作为一名维护维修机务员除了深入了解掌握自动化系统的结构和原理外还应该拓宽知识面，熟悉相关的计算机网络通信知识，才能够能动地解决一些设备保障工作中出现的难点故障，为管制部门提供更高质量的服务。

参考文献

【1]Automation system for terminal and enrout control，LOCKHEED MARTIN ，2000.

【2]孙风栋。Oracle数据库基础教程[M】。北京：电子工业出版社，2007.

【3]陈善广。计算机网络原理与通信技术【M】。北京：清华大学出版社，2007.

【4]高彦刚。实用网络流量分析技术[M】。北京：电子工业出版社，2009.

【5】西蒙斯基着。陈逸，谢婷译。Snifer Pro网络优化与故障检修手册[M】。北京：电子工业出版社，2004.

「经管之家」APP：经管人学习、答疑、交友，就上经管之家！
免流量费下载资料----在经管之家app可以下载论坛上的所有资源，并且不额外收取下载高峰期的论坛币。
涵盖所有经管领域的优秀内容----覆盖经济、管理、金融投资、计量统计、数据分析、国贸、财会等专业的学习宝库，各类资料应有尽有。
来自五湖四海的经管达人----已经有上千万的经管人来到这里，你可以找到任何学科方向、有共同话题的朋友。
经管之家（原人大经济论坛），跨越高校的围墙，带你走进经管知识的新世界。
扫描下方二维码下载并注册APP