上海数字空管系统运行风险分析

谢云璇

民航华东空管局

一．系统基本信息

数字化起飞前放行DCL（Departure Clearance Delivery）系统和数字化航站自动情报服务D-ATIS（Data link-Automatic Terminal Information Service）系统构成民航数字空管系统。

DCL系统通过基于地空数据链的双向通信实现飞行员与塔台管制员间的信息交换，和电子进程单系统相结合，实现数字化放行。DCL系统自动接收来自自动化系统的应答机编码等信息，并且和飞行计划系统的飞行计划信息进行比对，减少了管制工作量，解决了机场话音通信频道拥挤、话音歧义性问题，能减少管制中人为因素的影响，大幅增强了信息传送的安全性，提高了效率。

D-ATIS系统通过合成语音 (Text-to-Voice)和数据链两种方式向飞行员提供起飞和降落阶段所需要的有关机场气象情况和机场状况信息,能够有效解决繁忙机场因使用人工话音放行造成的低效率和安全隐患，并能够显著提高大型机场管制服务效率和信息服务水平。

二．典型不正常保障案例

（一）典型不正常保障案例一

表 1 典型不正常保障案例一

2020年6月13日16：50，上海浦东大终端无法获取最新的虹桥DATIS情报通播，未影响管制运行。

技保中心虹桥无线值班员检查多频服务器状态正常，DATIS通播正常更新。从虹桥DATIS多频服务器可以正常PING通至浦东，浦东DATIS正常，浦东可以PING通至虹桥，确认链路正常。联系北京数据公司，核对通播号一致，确认设备正常。网络中心确认该业务的传输网，网络相关设备、中继、IP均正常，业务端口有数据且无异常。

虹桥值班员尝试重启多频服务器，重启后19：30大终端反馈设备恢复正常更新。

（二）典型不正常保障案例二

表 2 典型不正常保障案例二

2020年7月16日，虹桥塔台DCL电子进程单中的20：00的通播版本号未更新，值班员查看AFTN网关及多频服务器状态正常，虹桥塔台DATIS正常更新，网关的网络信息服务日志无报错，联系大终端无线询问通播状态也正常。维修中心值班员查看接收日志是20：02有同分同毫秒收到R和S取了前一个R，观察20：32收到只有一个T，与管制确认后续显示都正常。

（三）典型不正常保障案例三

表 3 典型不正常保障案例三

2020年8月28日19：20，北京数据公司报数字空管业务浦东至北京ATM链路中断，值班员登录ATM网管查看，发现该链路有远端告警，通报北京该情况，北京回复已将该业务切换至PSTN电话网备用链路。

19:31，虹桥塔台管制员向维修中心报所有航班DCL放行失败，收不到机组申请，联系软件工程师和虹桥无线协查。

20:11，维修中心值班员查看监控有DCL航班放行成功、与用户确认恢复正常。

20:26，数字空管监控系统显示DCL服务器的BGS-M告警。技保值班员发现AGS灯为红色，联系北京数据公司以及天航信排查。

21：00，数字空管业务版本号未更新，确认为浦东至虹桥专线业务中断，值班员使用SDH专线，用笔记本可以ping通，询问北京数据公司，疑因该SDH专线依附于ATM，至切换至PSTN网时，该链路失效。

8月29日02：34， ATM链路恢复正常。

（四）典型不正常保障案例四

表 4 典型不正常保障案例四

2020年12月27日09:32，上海虹桥塔台报DCL放行失败，稍后浦东塔台，华东十地报相同问题。各地检查设备，软件均正常，电话询问北京数据公司，北京称AGS核心网关设备故障导致了压报，各地收报有时延，处理后恢复正常。11:29，值班员与各用户确认恢复正常。

（五）典型不正常保障案例五

表 5 典型不正常保障案例五

2021年2月3日16:50，浦东大终端报用户反映OMSS系统不更新通播数据。随后，虹桥塔台也反映相同现象。

值班员联系网控排查中继线路，联系无线检查D-ATIS服务器等设备。17:25网控反馈网络传输线路均正常，无线反馈D-ATIS服务器及其相关设备运行正常，但无法PING通OMSS系统服务器。

值班员报修电信运营商协查，同时联系网控测试，PING测结果正常，判断浦东至青浦网络传输链路无异常。

17:44浦东值班员重启D-ATIS多频服务器后，用户确认业务恢复。

三．风险分析

随着航班量的逐渐增加，数字空管系统在管制运行中的重要性也与日俱增，实际运行中有近一半的故障会影响管制，所以对其风险进行分析控制十分必要。

1、DATIS系统软件多次出现不明原因故障（见案例一）,重启服务器、网关和应用软件即可恢复正常,但具体原因不明。

2、运行管理支持系统（OMSS系统）不更新D-ATIS数据问题曾多次发生，可能原因有多种：网络传输线路故障、虹桥、浦东两场D-ATIS数据源故障、青浦OMSS服务器及防火墙设备故障、浦东D-ATIS多频服务器故障等。故障会引起上海三地OMSS系统用户接收虹桥、浦东两场气象通播信息中断，对管制工作有一定的影响。

3、数字空管系统涉及多个单位的业务交叉，业务流程较为复杂，运行维护人员很难快速定位故障点并进行排故，导致应急处置时间过长。

4、数字空管系统是北京民航数据公司的子系统，全年出现多次因北京数据公司原因导致的故障（见案例三、案例四），该类故障存在持续时间长，影响范围大，排故过程不透明等风险，容易造成较长时间的DCL放行失败。

5、缺少设备软硬件的监控系统，由监控告警发现的故障仅占总故障的19%，值班员无法及时发现和定位故障，导致应急和排故处置时间过长。

6、由于数字空管系统涉及到的多个设备部门故障登记通报的标准不一，导致后期故障溯源和风险分析工作存在障碍。

四、风险防范措施

1、加强对相关部门的人员培训，让值班员认真学习巩固系统结构和运行流程，以便能及时确认故障点。

2、持续做好设备检查，重视巡检和备件的定期测试，确保故障后能尽快恢复运行。对投产年限较长的系统抓紧更新。

3、优化应急处置流程，增加交叉单位的交流，缩短故障定位和排故时间。

4、增强与北京数据公司的沟通，建议其及时通报故障信息，并协助安排备份手段。

5、做好联合应急演练，提高人员应急处置能力。

6、统一信息通报和故障登记标准，针对多发故障组织联合分析会。