论文部分内容阅读
【中图分类号】TP27 【文献标识码】A 【文章编号】1672-5158（2012）09-0056-01
空管自动化系统是民航空管部门实施对空指挥的核心系统，它能为管制员提供實时、精准的飞行动态和航班计划。在自动化系统中，FDP服务器主要是负责完成飞行电报处理、飞行计划处理、航班相关数据管理、飞行计划冲突探测、飞行计划与系统航迹相关等功能。
青岛目前使用的自动化系统为南京莱斯公司生产的NUMAN2000自动化系统。2012年6月4日，自动化系统出现FDPI自动重启，导致系统某些功能失效，本次故障期间对管制运行造成了一定的影响，以下将对FDP自动重启过程进行分析。
一、故障描述和分析
2012年6月4日09：03（UTC时间，本文的所有时间为UTC时间），FDPI自动重启，导致系统某些功能失效；在10：17采用单服务器模式（FDPI），系统可以正常工作；在16：12恢复FDP2，系统恢复在east正常工作模式。1、FDPI故障（6月4日：08：57）
监控日志显示FDPI故障：
2012.06.04 08：57：010nly ONE FDP in systeml
2012.06.04 08：57：01FDPI：stopped
2012.06.04 08：57：21NetAonFDPI is TimeOut
2012.06.04 08：57：21NetB onFDPI isTimeOut
2012.06.04 08：57：21NetC onFDPI isTimeOut
此时在FDP2上的CETC FDP进行数据库切换：
20120604085702：→recv 0x1500 reconnet oracel
故障前的计划条数：550
RetrievePlanStatus start！1
20120604085627：→RetrievePlmaStatus PlanNumbe=550！！
20120604085627：→RetrievePlanStatus 1 1 1 PlanNumbeR=550！！
20120604085627：→RetrievePlaxtStatus 22222 PlanNumber=550！！
故障后计划条数：156
20120604085727：→RetrievePlanStatus start！！
20120604085727：→RetrievePlmaStatus PlanNumber=156！！
20120604085727：→RetrievePlanStatus 111 PlanNumber=156！！
20120604085727：→RetrievePlaxtStatus 22222 PlanNumber=156！！
依据HP工程师的分析，FDPI出现CPU读写错误，此时数据同步出现故障，FDPI由于故障重新启动。（该现象目前无法正常复现，由于系统未记录数据复制日志，无法完全确认数据复制异常的原因，依据目前在测试平台中对FDPI重新启动、断电等的各项测试，均未见复制异常）此时由于没有对应的计划，CETC FDP进程对人机界面发来的CFL高度设置指令不响应。
2、FDPI重启成功（6月4日：09：05）
监控日志显示FDPI重启成功：
2012.06.04 09：05：33NetAonFDPI is up
2012.06.04 09：05：33NetB onFDPI is up
2012.06.04 09：05：33NetC onFDPI is up
3、FDP2上重拉FDP进程（6月4日：09：12）
重拉CETC FDP进程，是对次日计划的重新提取，进行隔日切换的转换，生成了计划：例如
20120604091235：→FlightToCurrent aeid=DKHll70，speed=K0900，rfl=S0900，mmdd=20120604，FltPlaxtNum 998
CreateCurrentPlan PlanlnDatabase acid=DKHl 170，plan no=0，status=FUR，domint=，terminate=！
计划的状态为FUR
此时，新生成的计划系统赋予了计划号，由于前面的同步错误，导致新生成的计划和原来的计划计划号一致，但实际不是同一个航班，该情况导致管制员修改CFL失效。例：雷达日志：ACID：CSZ9879Plan no=4177
计划日志：
20120604091448：→0x2403 plan no=4177，CFL=180，buff[19]=M，buff[4]=ld！
20120604091448：→send to asyn acid=GCR6525，depad=ZSOF，destad=ZSQD，sector=4，releateflag=，active=N
20120604091448：→
Modifly CFL on track label：
hostif=0ACID：GCR6525 ASSR：Plma no：4177 CFL：S0180
4、将FDPI人工切换为主机（6月4日：09：14）
监控日志显示人工切换到FDPI：
2012.06.0409：14：16Manual Swltch FDPI to be MAIN
2012.06.0409：14：16FDPI is main FDP
说明FDPI重启后，将FDP2的数据进行了同步，同步是正常的。
5、重启FDP2（6月4日：09：44） 监控日志显示FDP2关闭：
2012.06.04 09：44：49FDPI is mam FDP
2012.06.04 09：44：49Only ONE FDP in systeml
2012.06.0409：45：12NetAonFDP2isTimeOut
2012.06.0409：45：12NetB on FDP2isTimeOut
2012.06.0409：45：12NetC 0nFDP2isTimeOut
監控日志显示FDP2启动成功：
2012.06.0409：56：41NetAonFDP2is up
2012.06.0409：56：41NetB on FDP2is up
2012.06.0409：56：41NetC on FDP2is up
上述日志表明FDP2重启后恢复正常，FDPI的计划不受影响，不会因为FDP2的启动影响管制员的CFL操作。此时飞行电报处理模块显示连接数据库故障，系统进入死循环，后来人工在SMP上重启CETC ADO（飞行电报处理进程）进程：
6、关闭FDP2（6月4日：10：17）
监控日志显示FDP2关闭：
2012.06.04 10：17：35FDPI is mam FDP
2012.06.04 10：18：02Net A on FDP2 is Time Out
2012.06.0410：18：02Net B on FDP2 is Time Out
2012.06.0410：18：02Net C on FDP2 is Time Out
此后，计划不断根据电报建立新计划，并在全系统发布，系统功能逐渐正常。
7、重启FDP2，恢复正常运行（6月4日：12：10）
二、FDP故障时对管制的影响及应急措施
当FDP故障时，对管制造成的影响可能有以下几种：
1）CFL高度无法操作
故障现象：当FDP故障时，主备数据库同步存在BUG，自动化数据库的某些计划丢失，导致计划处理不正常，丢失计划的航班无法修改CFL高度，从而造成管制员对CFL高度无法操作。
解决方法：①首先在FPL窗口中调出计划，查看航班计划时候正常，如果航班不正常，可以让站调重发DEP报，重建计划后即可对CFL操作。②指导管制员挂简标牌，即可打CFL高度。③利用第五行附加信息，代表CFL高度。
2）无法正常拍发DEP和ARR报
故障现象：FDP进程和ADO进程不正常，均能造成塔台不能正常拍发起飞和落地报
解决方法：由于二十八所自动化设备，所以自动和手动拍发报文均不可正常，协调管制员通知站调拍发报文。
3）无法打印进程
故障现象：FDP服务器故障，进程无法打印
解决方法：如果计划正常，可以手动打印进程单；若果计划不正常，指导管制员手动填写空白进程单。
4）对于新进出港的航班，计划无法相关
故障现象：对于之前已经相关的航班显示正常，对于后来新起飞及进入本区域的航班无法相关
解决方法：如果存在计划，则手动相关；如果计划不存在，重建计划；如果计划不存在，可以挂简标牌，这种状态也可以进行扇区移交。
5）航班错相关，无法操作
故障现象：FDP切换后，数据库中的部分计划仍然存在RDP缓存中，造成计划无法终止，当有相同SSR的航班时，系统则会相关成之前的计划，造成错相关。
解决方法：第一步：重拉RDPI和RDP2的RADAR进程，清除RDP中的缓存的雷达目标和计划相关的信息；第二步：重拉各管制席位终端，清除SDD中的缓存信息。
通过对自动化设备的维护，针对FDP故障进行了简单小结，希望对以后遇到问题有所帮助。但是对数据库的了解还只是冰山一角，希望以后多于莱斯公司的工程师探讨，对设备有更深入的了解，使空管自动化系统能更稳定的运行。
空管自动化系统是民航空管部门实施对空指挥的核心系统，它能为管制员提供實时、精准的飞行动态和航班计划。在自动化系统中，FDP服务器主要是负责完成飞行电报处理、飞行计划处理、航班相关数据管理、飞行计划冲突探测、飞行计划与系统航迹相关等功能。
青岛目前使用的自动化系统为南京莱斯公司生产的NUMAN2000自动化系统。2012年6月4日，自动化系统出现FDPI自动重启，导致系统某些功能失效，本次故障期间对管制运行造成了一定的影响，以下将对FDP自动重启过程进行分析。
一、故障描述和分析
2012年6月4日09：03（UTC时间，本文的所有时间为UTC时间），FDPI自动重启，导致系统某些功能失效；在10：17采用单服务器模式（FDPI），系统可以正常工作；在16：12恢复FDP2，系统恢复在east正常工作模式。1、FDPI故障（6月4日：08：57）
监控日志显示FDPI故障：
2012.06.04 08：57：010nly ONE FDP in systeml
2012.06.04 08：57：01FDPI：stopped
2012.06.04 08：57：21NetAonFDPI is TimeOut
2012.06.04 08：57：21NetB onFDPI isTimeOut
2012.06.04 08：57：21NetC onFDPI isTimeOut
此时在FDP2上的CETC FDP进行数据库切换：
20120604085702：→recv 0x1500 reconnet oracel
故障前的计划条数：550
RetrievePlanStatus start！1
20120604085627：→RetrievePlmaStatus PlanNumbe=550！！
20120604085627：→RetrievePlanStatus 1 1 1 PlanNumbeR=550！！
20120604085627：→RetrievePlaxtStatus 22222 PlanNumber=550！！
故障后计划条数：156
20120604085727：→RetrievePlanStatus start！！
20120604085727：→RetrievePlmaStatus PlanNumber=156！！
20120604085727：→RetrievePlanStatus 111 PlanNumber=156！！
20120604085727：→RetrievePlaxtStatus 22222 PlanNumber=156！！
依据HP工程师的分析，FDPI出现CPU读写错误，此时数据同步出现故障，FDPI由于故障重新启动。（该现象目前无法正常复现，由于系统未记录数据复制日志，无法完全确认数据复制异常的原因，依据目前在测试平台中对FDPI重新启动、断电等的各项测试，均未见复制异常）此时由于没有对应的计划，CETC FDP进程对人机界面发来的CFL高度设置指令不响应。
2、FDPI重启成功（6月4日：09：05）
监控日志显示FDPI重启成功：
2012.06.04 09：05：33NetAonFDPI is up
2012.06.04 09：05：33NetB onFDPI is up
2012.06.04 09：05：33NetC onFDPI is up
3、FDP2上重拉FDP进程（6月4日：09：12）
重拉CETC FDP进程，是对次日计划的重新提取，进行隔日切换的转换，生成了计划：例如
20120604091235：→FlightToCurrent aeid=DKHll70，speed=K0900，rfl=S0900，mmdd=20120604，FltPlaxtNum 998
CreateCurrentPlan PlanlnDatabase acid=DKHl 170，plan no=0，status=FUR，domint=，terminate=！
计划的状态为FUR
此时，新生成的计划系统赋予了计划号，由于前面的同步错误，导致新生成的计划和原来的计划计划号一致，但实际不是同一个航班，该情况导致管制员修改CFL失效。例：雷达日志：ACID：CSZ9879Plan no=4177
计划日志：
20120604091448：→0x2403 plan no=4177，CFL=180，buff[19]=M，buff[4]=ld！
20120604091448：→send to asyn acid=GCR6525，depad=ZSOF，destad=ZSQD，sector=4，releateflag=，active=N
20120604091448：→
Modifly CFL on track label：
hostif=0ACID：GCR6525 ASSR：Plma no：4177 CFL：S0180
4、将FDPI人工切换为主机（6月4日：09：14）
监控日志显示人工切换到FDPI：
2012.06.0409：14：16Manual Swltch FDPI to be MAIN
2012.06.0409：14：16FDPI is main FDP
说明FDPI重启后，将FDP2的数据进行了同步，同步是正常的。
5、重启FDP2（6月4日：09：44） 监控日志显示FDP2关闭：
2012.06.04 09：44：49FDPI is mam FDP
2012.06.04 09：44：49Only ONE FDP in systeml
2012.06.0409：45：12NetAonFDP2isTimeOut
2012.06.0409：45：12NetB on FDP2isTimeOut
2012.06.0409：45：12NetC 0nFDP2isTimeOut
監控日志显示FDP2启动成功：
2012.06.0409：56：41NetAonFDP2is up
2012.06.0409：56：41NetB on FDP2is up
2012.06.0409：56：41NetC on FDP2is up
上述日志表明FDP2重启后恢复正常，FDPI的计划不受影响，不会因为FDP2的启动影响管制员的CFL操作。此时飞行电报处理模块显示连接数据库故障，系统进入死循环，后来人工在SMP上重启CETC ADO（飞行电报处理进程）进程：
6、关闭FDP2（6月4日：10：17）
监控日志显示FDP2关闭：
2012.06.04 10：17：35FDPI is mam FDP
2012.06.04 10：18：02Net A on FDP2 is Time Out
2012.06.0410：18：02Net B on FDP2 is Time Out
2012.06.0410：18：02Net C on FDP2 is Time Out
此后，计划不断根据电报建立新计划，并在全系统发布，系统功能逐渐正常。
7、重启FDP2，恢复正常运行（6月4日：12：10）
二、FDP故障时对管制的影响及应急措施
当FDP故障时，对管制造成的影响可能有以下几种：
1）CFL高度无法操作
故障现象：当FDP故障时，主备数据库同步存在BUG，自动化数据库的某些计划丢失，导致计划处理不正常，丢失计划的航班无法修改CFL高度，从而造成管制员对CFL高度无法操作。
解决方法：①首先在FPL窗口中调出计划，查看航班计划时候正常，如果航班不正常，可以让站调重发DEP报，重建计划后即可对CFL操作。②指导管制员挂简标牌，即可打CFL高度。③利用第五行附加信息，代表CFL高度。
2）无法正常拍发DEP和ARR报
故障现象：FDP进程和ADO进程不正常，均能造成塔台不能正常拍发起飞和落地报
解决方法：由于二十八所自动化设备，所以自动和手动拍发报文均不可正常，协调管制员通知站调拍发报文。
3）无法打印进程
故障现象：FDP服务器故障，进程无法打印
解决方法：如果计划正常，可以手动打印进程单；若果计划不正常，指导管制员手动填写空白进程单。
4）对于新进出港的航班，计划无法相关
故障现象：对于之前已经相关的航班显示正常，对于后来新起飞及进入本区域的航班无法相关
解决方法：如果存在计划，则手动相关；如果计划不存在，重建计划；如果计划不存在，可以挂简标牌，这种状态也可以进行扇区移交。
5）航班错相关，无法操作
故障现象：FDP切换后，数据库中的部分计划仍然存在RDP缓存中，造成计划无法终止，当有相同SSR的航班时，系统则会相关成之前的计划，造成错相关。
解决方法：第一步：重拉RDPI和RDP2的RADAR进程，清除RDP中的缓存的雷达目标和计划相关的信息；第二步：重拉各管制席位终端，清除SDD中的缓存信息。
通过对自动化设备的维护，针对FDP故障进行了简单小结，希望对以后遇到问题有所帮助。但是对数据库的了解还只是冰山一角，希望以后多于莱斯公司的工程师探讨，对设备有更深入的了解，使空管自动化系统能更稳定的运行。