“欧洲猫-X”系统管制操作手册.doc
《“欧洲猫-X”系统管制操作手册.doc》由会员分享，可在线阅读，更多相关《“欧洲猫-X”系统管制操作手册.doc（61页珍藏版）》请在冰点文库上搜索。
“欧洲猫-X”系统管制操作手册
前言
中国民航总局于1996年开始建设北京、上海、广州三大区域管制中心（NESACC）项目，三大区域管制中心的空管自动化处理系统采用泰利斯（THALES）公司开发研制的“欧洲猫（EUROCAT）-X”应用系统。
为了方便管制员充分了解“欧洲猫-X”系统的结构与管理、运行；正确理解系统对飞行数据和雷达数据的处理过程；熟练掌握系统在实际工作中的各项功能，华东空管局空管中心组织专门人员编辑、出版《“欧洲猫-X”系统管制操作手册》
编辑人员在深入理解“欧洲猫-X”系统的基础上，参阅了泰利斯公司提供的《Operational_HMI_Spec_Rev_C》、《ESSS_Rev_G》、《ATCOperatorCourse》等操作手册，结合实际的管制工作，从方便管制员学习、理解的角度出发，着手编辑、整理这套管制操作手册。
编辑工作受到华东空管局领导的高度重视，期间空管中心更是投入了大量的人力和精力。
本手册共分三章，内容涵盖“欧洲猫-X”的系统结构、主要功能处理的工作原理、各席位的人机界面操作、系统的降级模式运行等。
由于编辑任务紧急、编辑人员水平的局限，造成本手册存在疏漏及不妥之处，恳请使用者谅解和不吝指正。
编辑委员会
2004年5月
第一章系统概述
第一节系统结构
“欧洲猫-X”是一套完善的空管自动化应用系统，系统中每个管制席使用统一的数据平台，优化的人机工作界面，通过直观的图形工具和方便的自动化数据处理以及有效的预警功能，给现有的管制工作带来了技术层面的革新。
“欧洲猫-X”系统提供强大、灵活与实用的功能：
高度自动化的空中交通管制辅助功能；人性化设计的操作界面；处理的多重冗余；未来新版本以及新功能的升级、扩展；高仿真的模拟功能；特情时的应急备份。
上海区域管制中心使用的“欧洲猫-X”系统的功能处理共分设四个分部：
区域分部、进近分部、虹桥塔台分部、浦东塔台分部。
另外区管中心还配设了一套独立的模拟培训（SIMU）/紧急备份（TEB）系统
系统的各种功能处理模块分布在各个分部
相互间的数据交换通过各自的通信数据处理模块（CDP）实现
浦东塔台分部
虹桥塔台分部
进近分部
区域分部
“欧洲猫-X”系统的功能处理结构：
系统采用上述的功能处理结构有利于：
各功能分部拥有独立的雷达数据处理系统，而且通过网络作为媒介，能够实现功能分部的远程布局，同时保证每个分部的每一个席位获得相同的工作界面和相同的飞行数据与处理。
空管工作中的各种需求被设计成系统的各个处理模块。
每个处理模块都具备双重冗余。
系统将区域、进近、塔台各分部共用的处理模块都定义在区域分部，相对应的席位比如：
数据管理席等也因此被定义在区域分部，这与实际的区域管制室是两个不同层面的概念。
其他独立的功能处理模块被配置到各自的分部，不同分部之间的数据交换通过各自的通信数据处理模块（CDP）实现。
各处理模块通过工作网进行相互间数据交换和功能整合，工作网提供了各处理模块放置和采集数据的一个工作平台。
工作网也是双重冗余，由A网（LANA）、B网（LANB）组成。
系统另外配置第三条网络—“服务网（ServiceLAN）”主要用作旁路应急备份以及下线数据的传输。
FDP
RFP
RDP
HMI
CDP
RECP
RBP
FPCP
AGDP
ASPB
OASYS
ADDP
DBM
MTP/SNMAP
多雷达航迹处理/安全网及监控处理
ADS/CPDLC/PDC
自动相关监视/地空数据链通讯
/预起飞许可
军方数据处理
飞行数据处理
雷达数据处理
人机界面处理
单雷达航迹处理
通信数据处理
飞行计划冲突探测
空地数据处理
雷达旁路处理
纪录备份处理
系统运行监控
空域情况重放
数据库管理
DPR/DAF
数据准备/数据分析
工
作A网
工
作网B
服务网S
下图为区域分部的各个处理模块：
下图为进近分部的各个处理模块：
（进近使用区域分部提供的雷达旁路处理）
MRTS
SNMAP
HMI
CDP
RECP
OASYS
多雷达航迹处理
人机界面处理
安全网及监控处理
通信数据处理
纪录备份处理
系统运行监控
工
作网A
工
作网B
服务网S
下图为虹桥和浦东塔台分部各自独立但同样的各个处理模块：
（塔台使用进近分部提供的多雷达航迹处理）
HMI
CDP
RBP
人机界面处理
通信数据处理
雷达旁路处理
“欧洲猫-X”系统在构筑自身稳固的运作体系的同时，也保证了与外围工作环境的良好交流。
系统与外部通行的接口有：
航空固定远程通讯网络（AFTN）接口、雷达数据输入端口、航空器定位报告系统（ACARS）接口、气象数据（GRIB）输入端口、修正海压（QNH）传感器输入端口、全球定位系统（GPS）时间输入端口、军方数据处理（ADDP）输出端口、以及需要与系统交联的其他空管自动化系统接口。
第二节雷达数据处理（RDP）
在当前以雷达管制为主的工作环境下，雷达数据的自动化处理对于管制工作的重要性是毋庸置疑的。
“欧洲猫-X”系统的雷达数据处理分成了单雷达航迹处理模块，多雷达航迹处理模块，安全网及监控处理。
对于雷达航迹的处理，区域和进近两个分部采用不同的处理方式。
区域分部采用单雷达航迹处理（RTP）和多雷达航迹处理（MTP）相结合的处理方式。
单雷达航迹处理是指由接入系统的雷达向单雷达航迹处理器（RFP）发送飞机的航迹、点迹、云量等雷达数据，RFP对接收到的航迹进行属性辨认，并检查C模式高度的正确性，最后生成飞机的单机航迹（LocalTrack）。
多雷达航迹处理（MTP）是指由多雷达航迹处理器（MTP）把RFP提供的单机航迹融合生成系统航迹（SystemTrack）。
其系统航迹的融合计算过程如下图示：
系统航迹更新周期
单机航迹1更新周期
单机航迹2更新周期
单机航迹3更新周期
飞行轨迹
系统航迹
单机航迹1（雷达1）
单机航迹2（雷达2）
单机航迹3（雷达3）
单机外推航迹1
单机外推航迹2
单机外推航迹3
更新后的系统航迹位置
=
各单机外推航迹的权重中心
进近分部采用的雷达航迹处理方式是多雷达航迹处理（MRTS），与区域分部雷达航迹处理的方式：
RTP+MTP不同。
多雷达航迹处理（MRTS）的处理方式是MRTS处理器直接接收雷达送来的飞机点迹（Plots）进行融合计算生成系统航迹（SystemTrack），不需要经过RFP处理，也不接收RFP生成的单机航迹。
而且，MRTS的航迹处理模式也与MTP不同，它采用美国最新航天技术--卡尔曼滤波技术进行对飞行器的追踪处理，生成航迹的精确度要比MTP胜出许多。
下图为MRTS系统航迹的融合计算过程：
系统航迹更新周期
点迹1更新周期
点迹2更新周期
点迹3更新周期
飞行轨迹
系统航迹
点迹1（雷达1）
点迹2（雷达2）
点迹3（雷达3）
隐型系统航迹
更新后的系统航迹位置
=
最后一个隐型系统航迹的外推
系统航迹包含了工作所需的飞行数据：
航迹识别号、位置、速度矢量线、更新时间、雷达的工作状态、应答机编码/模式、C模式高度及正确性、修正后的高度、高度趋势、高度显示、航迹渐消显示、低于过渡高度显示、上升/下降率、高度的更新时间、系统航迹的质量、应答机识别显示、军方紧急情况显示。
安全网及监控处理（SNMAP）是雷达数据处理中不可或缺的组成部分，主要功能为：
系统相关（CentralCoupling）；自动位置报告（APR）；各类雷达警告的产生。
其中航迹的系统相关为管制工作带来极大的帮助，为了最大程度避免错误的自动相关和最大限度的使用应答机编码资源，SNMAP建立了航路走廊模式。
SNMAP给每个航班根据飞行计划的航路定义了一条从起飞机场到落地机场的航路走廊。
如下图所示：
ADEP
ADES
系统航迹被系统自动相关的条件：
1、航迹当前未被相关；2、航迹的应答机编码属于系统定义的编码组范畴；3、航迹的应答机编码与欲相关的飞行计划分配的编码相同；4、航迹速度大于下线设定值；5、航迹位置在航路走廊里。
飞行计划被系统自动相关的条件：
1、飞行计划当前未被相关；2、飞行计划分配的编码属于系统定义的编码组范畴；3、飞行计划分配的编码与欲相关的航迹的应答机编码相同；4、飞行计划已处于协调（Coordinated）状态；5、飞行计划未曾被手动解除过系统相关。
所以，当飞行计划中分配的编码（ASSR）或之前分配的编码（PSSR）与系统航迹使用的编码一致，而且系统航迹在该飞行计划航路的走廊里，SNMAP就可以自动完成系统航迹的系统相关。
如果飞行计划中的ASSR编码或PSSR编码与系统航迹的编码一致，但是系统航迹在飞行计划航路的走廊之外，系统不会自动相关，但可以通过人工相关完成。
一旦系统相关以后，即使系统航迹离开了航路的走廊，相关也将一直被保持，直到系统航迹消失或飞行计划分配的编码被修改相关才被自动解除。
系统允许人工解除相关。
自动位置报告（APR）是由SNMAP向飞行数据处理模块（FDP）提供系统航迹的位置信息和C模式高度信息。
FDP利用APR确定系统航迹航在计划航路上的位置。
第一次APR就发生在系统相关时。
生成APR的事件：
1、航迹被系统相关；2、在相关期间，每次系统航迹的更新；3、航迹飞越每个航路点；4、系统航迹的消失；5、航迹离开或进入航路走廊。
系统航迹飞过航路上的某个航路点之后，飞过的那部分航路走廊就被SNMAP删除，称为航路走廊的“坍塌”。
这种处理方式有利于应答机编码的重复使用。
ADEP
ADES
有效的雷达警告为管制工作提供足够的安全保障，SNMAP根据系统航迹产生下列警告：
n特殊编码告警（7700、7600、7500）
n低高度告警（MSAW）
n高度偏离告警（CLAM）
n进近航道偏离警告（APM）
n临时危险区侵入警告（TDAW）
n偏航警告（RAM）
n危险区侵入警告（DAIW）
n应答机重码警告（DUPE）
n短期冲突警告（STCA）
第三节飞行数据处理（FDP）
与以往使用的空管自动化软件不同，“欧洲猫-X”系统是围绕着航班的飞行计划在发挥它强大的空管自动化辅助功能，所以对飞行数据进行处理是系统最核心的处理部分。
系统中航班的飞行数据主要来自各类飞行计划电报、RDP提供航迹和机组报告由管制员输入系统的飞行信息。
FDP把接收到的某个航班的所有飞行数据进行有机地处理，并把这些有效的数据归总统称为航班的飞行数据记录条（FDR）。
飞行数据记录条（FDR）就像一部完整记录航班全部过程的录像，它记录并保存航班整个飞行的所有信息。
打开该航班的飞行计划窗口可以查看和修改航班的FDR。
航班在系统中就是以FDR的形式存在，系统对航班的所有处理也是通过对它的FDR进行处理来完成。
所以系统中航班的电子进程单、航迹标牌的大部分信息以及计划航迹（FlightPlanTrack）都是依赖FDR而存在。
FDP根据系统中各类下线定义的系统参数（VSP）对FDR执行各种自动化处理。
同时，管制席（EC/PLC）、主任管制席（SUP）、飞行计划处理席（FDO）都可以按照实际工作需要，通过飞行计划窗口、电子进程单、航迹标牌对FDR进行人工更新、处理。
FDR通过图像式显示在工作界面上：
飞行计划窗口
电子进程单
航迹的符号和位置
航迹标牌
FDP为实现对系统的飞行数据进行有效的处理，定义了三种类型的数据处理区域：
飞行数据区（FDRG）、飞行计划系统区（FPSA）、飞行计划扩展区（FPEA）。
其中的飞行数据区（FDRG）实际就是运行本系统的管制中心的整个飞行管制区域，在FDRG之内，系统才对FDR进行完全的处理，在FDRG之外的另外两个区域，FDP只是对飞行计划进行必要的分析和简单的处理。
FDRG
FPSA
FPEA
整个FDRG被完整地分割成各个物理扇区（VolumetricSectors），各个物理扇区通常就是实际工作中各个管制扇区，它由管制扇区的物理边界、高度的上限、下限来界定。
但是如果进近管制设置了进、离港扇区，就无法从物理位置上分割两个物理扇区；另外在系统定义中，塔台管制没有物理扇区。
为了满足上述工作上的需要，系统在物理扇区的层面下又定义了功能扇区的概念，因此在一个物理扇区中可以包含两个或两个以上的功能扇区（FunctionalSectors），比如进近的一个物理扇区中可以含有：
离场扇区、进场扇区两个功能扇区。
塔台或地面管制席也被分配了各自的功能扇区。
如下图所示：
区域的高扇和低扇分别定义为上下两个物理扇区；进近的进场和离场扇区就被定义为一个物理扇区里的两个功能扇区。
FDP在收到各类飞行数据生成一个FDR的同时，也为系统绘制了FDR的飞行轨迹（Trajectory），并随着FDR被更新，也随时更新飞行轨迹。
轨迹是FDP根据收到的航班的各类飞行计划或动态提供的飞行数据衍生推算出航班将要经历的一个四维空间：
航路及每个重要的点、每个点的应飞高度（AFL）、每个点的预计时间（SETO）。
所以，上述扇区的定义和飞行轨迹的计算对于系统来讲是至关重要，FDP就是利用FDR的飞行轨迹与各种扇区之间的关系来实现三大核心功能：
1、电子进程单的发送；2、航班的自动移交；3、不同飞行管制区之间航班的信息自动交换及移交。
飞行轨迹与扇区的关系决定了FDP的处理，如下图示意：
离穿越点”C”15分钟时，FDP自动向下一管制中心派发一份EST报
离穿越点”B”3分钟时，FDP把航班从”BlueSector”移交到”GreySector”
离穿越点”A”30分钟时，FDP自动向”BlueSector”所在席位发送航班的进程单
A
B
C
FDP能够根据FDR的飞行计划以及系统收到的各类飞行数据产生独立的警告为管制工作提供辅助的安全保障，FDP根据飞行计划产生下列警告：
nMPR-MissedPositionReport
nETO-EstimatedTimeOverDiscrepancy
nU-CoordinationFailure
第四节飞行数据记录条（FDR）
对于“欧洲猫-X”系统的用户来讲，只有真正理解FDR在系统中的担任的角色和它的发展进程，才能真正掌握“欧洲猫-X”系统，充分发挥系统的各种功能。
系统把航班飞行在实际工作中的不同阶段简洁地设计成FDR的不同状态，由此建立一种用户与系统之间统一的工作机制，明确双方在航班飞行的每个阶段该做何事，能做何事。
FDR在系统中被认为是一个“生命”，它的“一生”被分成与FDRG不同关系的四个基本阶段：
1、航班进入FDRG的准备阶段；2、航班进入FDRG前的实质阶段；3、航班进入FDRG后的管制阶段；4、航班离开FDRG后的阶段。
FDR的整个过程真实表现了航班在系统运行的管制区内的进程，最终利用每个状态的递进为系统创建起一套完善的飞行数据自动化处理模式。
FDR的正常的状态进程有：
未来（Future）、未激活（Inactive）、预激活（Preactive）、协调（Coordinate）、激活（Uncontrolled）、进入（Handoverfirst）、管制（Controlled）、移交（Handover）、结束（Finsh）、取消（Cancle）等状态。
如下图所示：
航班进入FDRG的实质阶段
阶段
航班离开FDRG后
的结束阶段
航班进入FDRG后的
管制阶段
航班进入FDRG前的准备阶段
协调事件
激活事件
生成事件
进入FDRG事件
接收事件
移交事件
结束事件
取消事件
生成事件
预激活事件
未来状态
未激活状态
预激活状态
协调状态
进入状态
管制状态
移交状态
结束状态
激活状态
取消状态
每种状态依次递进，每次递进必然是因为某个事件的触发。
事件本身的产生有两种：
一种是系统根据设置自动产生：
1、基于各类VSP的设定（如：
预计起飞时间45分钟前触发FDR进入预激活状态）；2、相关电报的接收（如：
收到EST报触发FDR进入协调状态）；3、自动功能的发生（如：
系统相关触发FDR进入激活状态）。
第二种是系统根据人工操作某项系统功能而产生。
FDR的事件发生和触发状态变化的举例说明：
1、生成事件为收到PLN报：
CES555，从浦东调机到虹桥，预计起飞时刻为08:
00，提前一天FDP收到PLN报，自动生成一个未来状态的FDR。
2、生成事件为收到FPL报：
当天，FDP收到CES555的FPL报，自动把FDR从未来状态触发到未激活状态。
3、预激活事件为时间：
到了07:
15，FDP自动把CES555的FDR从未激活状态触发到预激活状态。
4、协调事件为人工执行协调功能：
CES555开车完毕准备好滑行，浦东塔台管制员点击电子进程单的功能区执行协调功能，人工把FDR从预激活状态触发到协调状态。
5、激活事件为系统相关：
CES555起飞后被SNMAP自动系统相关，随即FDP自动把FDR从协调状态触发到激活状态。
6、进入事件为自动：
按照工作程序规定，FDP直接把CES555的FDR从激活状态触发到进入状态。
7、接收事件为人工执行接收功能：
浦东塔台管制员在工作界面上执行接收（ACC）功能，FDP把CES555的FDR从进入状态触发到管制状态。
8、移交事件为人工执行移交功能：
浦东塔台管制员在工作界面上把CES555移交（HND）给进近，FDP把的FDR从管制状态触发到移交状态。
9、接收事件为人工执行接收功能：
进近管制员在工作界面上执行接受（ACC）功能，FDP把CES555的FDR从移交状态触发到管制状态。
10、移交事件为人工执行移交功能：
进近管制员在工作界面上把CES555移交（HND）给虹桥塔台，FDP把的FDR从管制状态触发到移交状态。
11、接收事件为人工执行接收功能：
虹桥塔台管制员在工作界面上执行接受功能，FDP把CES555的FDR从移交状态触发到管制状态。
12、结束事件为时间：
CES555落地后2分钟，FDP把CES555的FDR从管制状态触发到结束状态。
13、取消事件为时间：
结束状态后2分钟，FDP把CES555的FDR从结束状态触发到取消状态。
第五节电报处理
系统能够对当前民航各类飞行报文进行智能的自动化处理，无疑为减少人员负担、提高工作效率作出了很大的贡献。
“欧洲猫-X”系统对于各类飞行电报进行的各种完整自动化处理更大程度地发挥着系统对管制工作的提升和优化。
系统的研发就始于对中国民航实际工作的深刻理解，所以系统在这方面的处理同样传承整个设计的原则，充分体现了工具在符合国际标准体系的同时，体现对实际工作环境的适应和推动能力。
系统能够处理各类ICAO电报和中国民航电报。
FDP接收某个航班的各类飞行报文，搜集、整理其中的各类飞行元素，并创建、更新该航班的FDR。
FDP对部分报文的处理如下图所示：
长期计划库（RPL）
ETD/ETB前24小时
FDR
未来状态
飞行预报（PLN）
更正报（COR）
生成或修改
取消
自动生成
倒入
修改
取消报（ABS）
FDR
未激活状态
领航计划报（FPL）
修改、触发
生成
领航计划报（FPL）
人工创建（LPL）
生成
ETD/ETB前45分
自动生成
航班时刻表
FDR
预激活状态
返航报（RTN）
备降报（ALN）
生成
生成
随着航班流量的日益增多，上述各种飞行报文已经不能满足管制工作对航班实时信息交换的需求。
因此国际民航组织推出了一种新的报文标准：
相邻管制中心数据通信（AIDC）报文，一种在亚太地区相邻管制中心之间实现自动化移交功能的电报协议。
这种协议的执行必须要求双方的空管自动化系统都具备处理该类报文的自动化功能。
“欧洲猫-X”系统为三大区域管制中心实现这种先进的管制技术提供了一个坚实的平台，它处理AIDC报文的能力为将来不同飞行管制区之间飞行数据的自动交换做好了充分准备。
举例说明：
1、CCA101正从FDRG-A飞向FDRG-B。
对于B系统，CCA101的FDR处于预激活状态。
此时，A系统按照工作协议在CCA101进入边界前30分钟由它的FDP自动向B系统发出CCA101的边界预报（ABI），B系统的FDP收到ABI后就自动更新它的系统中CCA101的FDR中的移交点及时间、高度和其他有关元素。
2、CCA101离边界15分钟，A系统自动向B系统发出CCA101的预计飞越报（EST），B系统收到EST后就自动触发它的系统中的CCA101的FDR从预激活状态转入协调状态，并更新FDR中的相关元素。
3、CCA101进入B系统的雷达覆盖区，被B系统自动系统相关，B系统中，CCA101的FDR进入激活状态，SNMAP开始向FDP传送APR，实时更新FDR的信息。
4、CCA101离边界3分钟，A系统的管制员在工作界面上执行向B系统移交CCA101，A系统就自动向B系统发送移交报（TOC），B系统收到TOC后就自动触发它的系统中的CCA101的FDR从激活状态转入进入状态。
5、B系统的管制员在工作界面上看到CCA101正被移交过来，就执行对CCA101的接收功能，B系统就自动向A系统发出接收报（AOC），A系统收到AOC后就完成CCA101的电子移交，B系统就自动触发它的系统中的CCA101的FDR从进入状态转入管制状态。
作为两个管制中心使用两套系统的管制员，在整个移交过程中，就像在处理自己管制中心内部不同扇区的航班移交一样，简单地在工作界面上完成了整个过程，但实际的后台运行是两个系统通过对各种AIDC报文的自动处理帮助管制员进行了必需的飞行数据交换。
系统除了对上述报文的处理能力之外，还可自动拍发一些国际民航组织（ICAO）电报，如：
起飞报（DEP）、落地报（ARR）等。
第二章人机界面的功能与操作
系统完善的功能最终将体现在工作界面的应用与操作是否更方便、更人性化。
“欧洲猫-X”系统的人机互动是由人机界面处理模块（HMI）实现。
系统通过工作显示屏和蜂鸣器向用户提供系统处理的结果；用户通过键盘、鼠标实现与系统之间的信息交换与互动。
系统根据不同的工作需要配置不同的操作席位，上海区域管制中心“欧洲猫-X”主系统的管制席位有：
主任管制席（SUP）、飞行计划处理席（FDO）、主管制席（EC）、副管制席（PLC）、塔台管制席（TC）、塔台副管制席（AC）。
虽然系统中不同功能的席位存在工作界面和功能操作的差异，但系统为用户提供了统一的应用层面，相同的功能在不同类型的席位上是一致的。
所以本章以主管制
升级会员 