记录一次贵阳冻雨过程

2021年12月27日贵阳的第一份预报是这样的:TAF ZUGY 270903Z 2712/2812 02003MPS 6000 BKN015 OVC033 TX02/2807Z TNM02/2722Z TEMPO 2717/2723 -FZDZ=

然后在1945分更改了预报,整晚小冻雨:TAF AMD ZUGY 271145Z 2712/2812 02003MPS 6000 BKN015 OVC033 TX02/2807Z TNM03/2722Z BECMG 2713/2714 2500 -FZRA BR FEW002 BKN012 OVC026 BECMG 2801/2802 6000 NSW BKN015 OVC033=

当时的实况是:METAR ZUGY 271100Z 02004MPS 4000 -RA BR FEW008 BKN015 OVC030 M02/M03 Q1027 NOSIG= 气象席位认为,其实贵阳已经开始冻雨了。

下一个实况的确开始冻雨了:METAR ZUGY 271200Z 02004MPS 3000 -FZRA BR SCT006 BKN015 OVC030 M02/M03 Q1027 BECMG TL1330 2500 SCT004 BKN012 OVC026=

然后冻雨了一整晚:

METAR ZUGY 271300Z 01003MPS 3500 -FZRA BR SCT006 BKN015 OVC030 M02/M03 Q1027 BECMG TL1430 SCT004 BKN012 OVC026=
METAR ZUGY 271400Z 02003MPS 4000 -FZRA BR SCT005 BKN013 OVC026 M02/M03 Q1027 NOSIG=
METAR ZUGY 271500Z 01003MPS 4000 -FZRA BR SCT005 BKN013 OVC026 M02/M03 Q1028 NOSIG=
METAR ZUGY 271600Z 04002MPS 4000 -FZRA BR SCT005 BKN013 OVC026 M02/M03 Q1027 NOSIG=
METAR ZUGY 271700Z 04003MPS 4000 -FZRA BR SCT006 BKN013 OVC026 M02/M03 Q1026 NOSIG=
METAR ZUGY 271800Z 02003MPS 4000 -FZRA BR SCT006 BKN013 OVC026 M02/M03 Q1026 NOSIG=
METAR ZUGY 271900Z 03002MPS 4000 -FZRA BR SCT005 BKN013 OVC026 M02/M03 Q1026 NOSIG=
METAR ZUGY 272000Z 03003MPS 5000 -FZRA BR FEW005 BKN013 OVC026 M02/M03 Q1025 NOSIG=
METAR ZUGY 272100Z 03003MPS 7000 -FZRA FEW005 BKN013 OVC026 M02/M03 Q1025 BECMG TL2230 FEW005 BKN015 OVC026=
METAR ZUGY 272200Z 03002MPS 8000 FEW005 BKN013 OVC030 M02/M03 Q1024 REFZRA BECMG TL2330 FEW005 BKN015 OVC026=

双EEC备用模式,BOTH EEC ATLN AND DISPLAY SOURCE

前几天遇到一个航班空中故障。机组下行的ACARS是这样的:

WE/MEET/BOBT/EEC/ALTN,FA,ILAND/DSPLY/SOURCE

可能是机组发ACARS时候输入有误,我们一下没明白BOBT是啥意思,后来想了一下,应该是BOTH的意思。以往只遇到过一个EEC变为备用模式,两个同时ALTN是第一次遇到。看了一遍QRH,倒是没有什么大的影响。

然后我就想理解一下为什么DISPLAY SOURCE会一下子影响两个EEC。

在网上找了一下资料。原来,在EEC和ADIRU之间,还有一个DEU(显示电子组件),是这家伙坏了。

Both EEC’s require input from two DEU’s to operate in the NORMAL mode.If only one DEU is enerqized both EEC’s receive 1 DEU input and change to the SOFT ALTERNATE mode indicated by two amber ALT lights on the ENGINE CONTROL panel,accompanied by a MASTER CAUTION.Of course you’ll also see an amber DSPLY SOURCE indication on both PFD’s indicating that there is 1 DEU providing info to all 6 DU panels.

NORMEL时两个EEC使用两个DEU的数据。如果只有一个DEU可用,那么两个EEC从一个DEU获得数据,并工作在SOFT ALTN模式,两个EEC备用模式灯都亮。。。。当然,同时还会有DSPLY SOURCE的告警,代表了一个DEU为6个DU显示数据。

所以,小飞机还是小飞机呀,系统冗余只有两套,只能舍弃其中一个,而如果有三套冗余的话,就可以自动比对数据、剔除错误数据了。这让我想到了MAX上的迎角探测器也只有两个,如果能标配三个的话,就不会出现后面的事情了。

记录一次欧控的乌龙限制

在本月初,制作ZSNB至LHBP的航班放行时,遇到了欧控航路校验不通过的情况。如图:

回想起曾经写过的一个帖子:Route Availability Document (RAD)。没想到有朝一日真的会用到它。于是,我通过欧控的网站想了解一下“EUMNUM1A”这个限制代码究竟是什么意思。

在这个位置有一个限制的列表。点进去之后可以下载一个EXCEL文件。其中包括了所有EU限制的代码解释。但是在EXCEL里没有找到EUMNUM1A这个代码。不过,我筛选了所有包含UM1A的限制,说的都是关于白俄罗斯的航空公司禁止使用空域的事。

这就很奇怪了。然后,查询了RAD网站上的Appendix 2: Area definitions中对“NM”代码的定义,指的是北大西洋空域和欧洲以外的空域。

所以EUMNUM1A的限制,大概是指EU发布,对于北大西洋和欧洲以外的,白俄罗斯注册的航空公司关闭空域的限制?

在和欧控电话沟通的过程中,对方也说不清倒底是什么问题。所以安全起见,我们的航班绕开了白俄罗斯空域。

最搞笑的是,第二天,同样的航路,再次提交FPL电报至欧控网站后,EUMNUM1A的限制代码已经消失了。因此我们觉得是欧控自己的系统有问题。

ZSNB-LHBP

布达佩斯以前就飞过,我对布达佩斯这座城市很有好感。现在很火的网红打卡点武康大楼,就是那座三角形地块的房子,由邬达克设计。邬达克就是匈牙利人,所以我在布达佩斯的街头,满眼望去都是武康大楼的样子。或者反过来说,武康大楼,就像是从布达佩斯建筑群中,切出的一块芝士蛋糕。

本次运行中,最大的变数是白俄罗斯。前段时间,因为白俄罗斯用军机拦截了一架客机,造成欧盟对白俄罗斯航司限制了领空。同时也警告其他航司,建议避开白俄罗斯空域。

所以,公司准备了备用航路,如果有意外情况,可以随时启用。

美国和欧盟都发了相关的通告。但作为地球另一边的大国,肯定不能按着美国的说法做。

签派员除了会放航班,还要懂得国际政治。话说国际远程的放行费是不是可以涨一涨了!

自动化签派放行和处理NOTAM的坑

今天遇到一件有意思的事情,有个航班从奥克兰NZAA起飞,需要选择ETOPS备降场,可选的只有奥克兰NZAA和基督城NZCH。但是由于公司的宵禁数据库显示,奥克兰宵禁,基督城的长跑道02/20关闭。我们正在纠结如何调整和控制起飞时间,避开宵禁和跑道关闭时,我们注意到基督城的NOTAM原始内容是:

(B0960/21 NOTAMN
Q)NZZC/QMRLC/IV/NBO/A/000/999/4329S17232E005
A)NZCH B)2102180600 C)2102191900
D)DAILY 0600-1900
E) GRASS RWY 02/20 CLSD DUE IRRIGATION)

也许是系统自动判断错误,或者是人工判断失误,这条通告实际指的是基督城的02/20号草跑道,而不是长跑道。(长跑道和草跑道名字相同,真是醉了。)

在油管上找到的在02号草跑道落地的视频:https://youtu.be/NNNsiY0f4kQ

=======================有趣的分割线=======================

联想到目前正在推进的新一代放行系统,理论上可以做到“自动”放行。但是对后台数据维护是一个很大的挑战。开玩笑的说,以前签派员看错通告,那是放错一个航班,以后数据维护出错,那可能放错100个航班。

787的防冰MEL

去年的10月份,一架787在起飞30分钟后出现了EAI PRSOV L(左发防冰压力调节和关断活门)状态信息。虽然在QRH中没有什么需要操作的内容。但是在MEL的状态信息页,波音很周到地提供了对应的MEL条款。

按照以往737的惯性思维,我猜这些MEL会说是把发动机防冰活门失效在开位,并增加油耗;或者把活门失效在关位,并不得在结冰气象条件下运行。由于这个航班是一个10小时的洲际航班,我担心飞出去飞不回来。

然后是我们看到MEL条款写的是把活门失效在半开位(好新奇)。我猜是因为787的发动机功率太大,如果完全失效在开位太猛了。随后发现O项内容,也仅仅是燃油增加1.6%,似乎还可以,起飞性能也够,对回程航班没有很明显的影响。

===================================

在了解787防冰系统的时候,从一位飞行员朋友那里了解到787发动机的另一个防冰功能,冰晶防冰(ICA)。

图中9指示ICA生效

冰晶防冰是一种全自动的功能,不过我查了一下MEL和QRH,如果ICA功能故障的话,空中没有操作要求,但是地面不能放行。FCOM对ICA的描述如下:

另一篇波音的文章介绍冰晶积冰是一种高空的积冰,往往影响发动机的内部核心机。

High-altitude ice crystals in convective weather are now recognized as a cause of engine damage and engine power loss that affects multiple models of commercial airplanes and engines. These events typically have occurred in conditions that appear benign to pilots, including an absence of airframe icing and only light turbulence. The engines in all events have recovered to normal thrust response quickly. Research is being conducted to further understand these events. Normal thunderstorm avoidance procedures may help pilots avoid regions of high ice crystal content.

拆除救生筏之后的限制

众所周知,拆除救生筏的飞机不能运行延伸跨水。上个月就遇到一个很奇葩的运行案例。航班从郑州飞虹桥,本身不牵涉到延伸跨水,但是由于华东区域雷雨覆盖,本该往南飞行的航班,向北绕飞。眼看要绕到山东半岛了。

机组报告说去青岛备降。我想想不对啊~如果去青岛,等晚上虹桥机场关闭,航班只能改去浦东,那么青岛浦东之间就是延伸跨水运行了。

好大的坑,然后只能要求机组不要去青岛,改去济南吧。

在济南落地后,告诉机组一个天津回上海的航班成功穿过了雷雨,让机组参考那个航班的轨迹飞回来。

纪念一下这个奇葩的航班。

为什么飞机的24位地址码出错

大约1个月前,发生一件奇怪的事情,经常有管制单位向我们反映,管制的二次雷达上看到飞机发射的地址码和FPL电报里的CODE不一致。这架飞机的地址码应该是7811D1,但是管制看到的是7891D1。虽然管制能继续指挥,但是缺少了扩展信息,无法自动匹配到航班信息。

而且这个问题,在不同时间、不同空间无规律发生。比如这架飞机飞重庆时发现地址错误,但是明天飞重庆就变成正确的,或者在上海飞时深圳是正确的,深圳回上海时又出错了。

因为这两个数据在二进制上看,只相差一位:

7811D1 = 11110000001000111010001
7891D1 = 11110001001000111010001

因此最初机务认为是某个插头松了。但是机务检查时,一切都是正常的。

最后,经过机务的不懈检查,发现是因为两部ATC应答机中,ATC1的编码错误,ATC2的编码是正确的。不同的机组每天飞行时,在两部ATC应答机中挑选一部用,所以造成这个错误的24位地址问题随机出现。

我斗胆去看了一眼机务的“SYSTEM SCHEMATIC MANUAL ”,ATC1的设置在M1987,而ATC2设置在M1988上。

通过这个例子,我才知道737飞机的24位地址是物理设置的,就像以前我修电脑,拔主板的跳线一样。但是我猜软件设置也不是做不到,以前看Discovery频道介绍空军一号的时候就说,空军一号可以伪装成任意一架飞机。无非就是发射了另一架飞机的24位地址。

另外,想起来半年前,我们在监控航班位置的时候,出现过同一架飞机,同时出现在两个地理位置的情况。我猜想一定是另一架飞机的24位地址设置错了。

PS:推荐微信公众号 九品机务《修改飞机24位地址码》解释了飞机上设置24位编码的过程。

墨尔本短跑道起飞案例

应该是非常久没写东西了。为了自己的业务不荒废,还是要定期写点。分享最近遇到的几个有意思的事情吧。

前几个月,墨尔本YMML因长跑道16/34关闭,使用09/27短跑道起飞。墨尔本常用的跑道是16/34.该条跑道条件较好,跑道长3657M,性能很好。09/27是一条短跑道,长度仅为2286M,起飞有限载。

在2286米的跑道上起飞,借助OPT的力量,所有参数都选“最优”。载量总算是能满足。那么还有什么办法能把性能榨干呢?

我突然想到备用前重心的事情。话说787除了正常的重心前限之外,OPT中还开放了一个14%的重心。我隐约记得还有第二个备用前重心的。翻阅AFM,果然发现了21%的重心。

分析了下性能,用21%大约可以提高1.2吨业载。但是如果使用21%备用前重心必须要配载部门可接受。问平衡要了以往的舱单,重心位置配在17.44%。要想配在23%(21+2)也许会改变配载流程(传说用21%的重心时,要求平衡配在21+2=23%之后)。

最后还有一个法规上的问题,在这次处置的过程中,我发现性能工程师用的桌面版计算软件里,其实前重心是可以随意输入的。

试想一下,如果为了追求榨干性能,那么我能不能让平衡给我个重心位置,比如17%,然后用软件当场算一个15%的前重心的起飞性能呢?从法律上讲,是否合规呢?是否违反上图下方的文字描述呢?

签派员的国际运行熟悉是很有必要的

7日的时候,难得值了个班。由于新型肺炎病毒的影响,航班很少。这时候值班,显得有些“无聊”。

情报通知我,在上海ZSPD去奥克兰NZAA的航线上,昨天有个通告,说这个区域的管制员罢工,没有管制服务:

A0182/20 努美阿 (NWWW)
DUE TO ATC STRIKE, ATC OPERATIONS INTERRUPTED. NO ATC SERVICES IN ALL AIRSPACES MANAGED BY TONTOUTA EXCEPT FOR EMERGENCY, MEDEVAC AND RESCUE MISSION FLIGHTS.

这个区域正好在航路上。我当时想,反正有西线航路可以备用,所以不是很在意。由于通告上没有说明高度,我先入为主地认为是努美阿的情报区,高度是无限高。

随后,我越看这个通告越觉得有疑问。疑问一是努美阿NWWW只是个机场并不是一个情报区。疑问二是努美阿所在的情报区NADI情报区(NFFF)的通告中并没有罢工通告。

然后我让情报员去检查了努美阿NWWW机场的管制范围,通告中的“ALL AIRSPACES MANAGED BY TONTOUTA”其实只包括上图中紫色范围的FL245以下的范围。

顺便说一下,努美阿NWWW所在国是法属的新喀里多尼亚New Caledonia。这个国家的AIP竟然在法国的AIP下面。这太难了~

随后我打了电话问机组,了解到这个区域是由NADI指挥的。机组也认为飞越努美阿NWWW应该没问题,不受罢工影响。但是保险起见,希望签派员能和NADI的管制员确认一下。

NADI原来是斐济的第一大城市,随后找了斐济的AIP,找到了区调的电话。随后我拿起电话,给大半个地球之外的一个岛国管制员打了个电话。幸好对方口音不重,确认了对方不罢工。

回想整个事情经过,如果签派员“偷懒”的话,就当这个区域不能用,改走另一条航路,可能就要这个航班多花1小时的耗油。

另一方面,这种国际远程航班运行起来的确太复杂了,签派员不但要关心航行情报的书面内容,还要关心各国的地理、战争、政治、罢工、病毒、民俗习惯、英语水平。所以说签派员的国际运行熟悉真的很有必要。

PS:https://www.eurocontrol.int/articles/ais-online 收集了各国的AIP链接,找起来很方便。

记录一下7号晚上温州的平流雾

METAR ZSWZ 071400Z 32004MPS CAVOK 18/10 Q1018 NOSIG=
METAR ZSWZ 071300Z 02003MPS 6000 R03/1100 FEW015 14/14 Q1018 NOSIG=
METAR ZSWZ 071200Z 04003MPS 020V080 0300 R03/0375 FG VV001 15/15 Q1017 BECMG FM1330 0350=

从300米变化到CAVOK只用了2个小时。我一直想,有没有什么数值预报的产品,可以更好地预报机场的风向变化?

EUROCONTROL的CDM时间

我们飞欧洲的经验不是很足,上个月遇到一些航班不正常之后,我就很想了解一下欧洲的流量控制和CDM工作原理。

记得还是高中的时候,喜欢编程和Linux。那时知道了KISS原则,就是“keep it simple and stupid”,软件设计得越简单越好,每个软件只实现一个简单的功能。只要保持接口的开放和简洁,就方便让多个程序连接在一起,实现一个复杂的功能。

EUROCONTROL有一本ATFCM USERS MANUAL,文中介绍了报文处理的逻辑。就像是一份通讯协议说明书。书中把我们平时用的FPL之类的AFTN报文,扩展成了方便计算机处理的语句。比如,协议中有“TITLE”关键字,还为每个航班FPL报分配了一个ID。这样方便追踪和解析。只要看懂几个关键字:ACK、REJ、FLS、SAM、DES就能大致了解这套协议的工作方法。

特别是为FPL分配ID的做法,这个主意真是太棒了。这样就减少了系统匹配航班的烦恼。比如后续的DLY报或CNL报,你可以通过检查ID来确定DLY或CNL的是不是正确的FPL。

反观国内,空管的CDM时间分配,没有一套简单的报文接口,甚至我现在连这套CDM系统的公开文档都没看到(也许我不知道,谁有文档的请告诉我)。

也许中国人一向不喜欢太简单太透明的东西。

SLATS PRIMARY FAIL和MEL使用的问题

前几天讨论到这个故障,在QRH中没有特别的要求。

但是在MEL中直接就不能放行了。

这样的标准落差造成在航班滑出后至起飞前的控制就比较敏感了。我没有找到特别新的DDG,但是在2010年的描述里找了一下英文原文。

对比一下有些公司的中文MEL,文中描述为”自身动力滑行前”。我个人认为这样的描述不太好。

好在现在公司的手册已经把MEL与QRH的切换时间改为了”设置起飞推力”。也就是在起飞推力前出现的故障,都需要看MEL。并且对MEL的m项和o项也有了更具体的规定。需要机务确认完成m项工作才能放行。

起飞标准VIS800?

昨天值班的时候,发现一个机场的起飞标准是VIS800。

但是,这个机场是有RVR设备的,而且报文中报告RVR值。这一版的航图更新内容就是增加RVR(只增加了落地RVR标准和平面图上的RVR设备标志)。根据公司手册和规章,我就得按照RVR来控制起飞。所以,起飞标准就变成了RVR800。

但是,搞笑的是,这个机场的落地标准才RVR550。因此会出现可以落地但是不能起飞的情况。

我怀疑是不是图错了。

曾经相同情况出现在黄山机场,不过目前黄山机场已经更新了航图。

放行放的是标准还是风险?

昨天因为台风的原因,大阪机场被淹了。幸好大阪的航班都取消了,但是羽田RJTT的航班仍然继续放行。我们提前一天晚上就在商量对策,决定去程改个日本北面沿海的航路,避开台风,回程有两个选择,一个仍然是北面绕回来,另一个是南面绕回来,等台风具体位置再定。至于风,我也没多想,觉得羽田这么多跑道,到时候总能有一个方向能落。把航路嘱咐了一下席位上的签派员就准备睡了。

没想到第二天早晨的羽田困扰的是风向和备降场。

先说备降场。羽田的备降场一般都是大阪RJBB,但是大阪现在肯定不能去了,我们又没有更靠北的机场可用,于是就选了成田RJAA。因为两个机场太近了,而且也想选回来,因此再加了一个虹桥(备降航路也是朝北绕的)。幸好落地不超重。

其次是风。预报180度30节阵风40节的样子。由于本打算用16号的目视盘旋,但是机组称16的目视盘旋白天不用,而且他们从没飞过。于是我想用22的盲降放行。但是侧风比较大,如果按40节风速算,侧风27节(标准为40节)。如果再晚落地,风速可能继续变大。也就是说,这个航班是有时间压力的。

TAF RJTT 032307Z 0400/0506 18018KT 9999 FEW015 BKN030 TEMPO 0400/0402 4000 -SHRA BR FEW005 BKN008 BECMG 0403/0405 18030G40KT TEMPO 0406/0412 18045G55KT

本来我的想法是,只要侧风标准不超,我就放。但是在和机长电话联系的过程中,机长觉得风险有点大,其实我也觉得有点大。我知道手册里写着最大侧风是40节,但是我也觉得不会有机组愿意在30以上的侧风条件下落地。毕竟手册只是一种理论情况。因为和机长以前就认识,沟通还算顺畅(虽然听到了我最讨厌机长说“你放我就走,你不放我就不走”之类的话),慢慢地,我被机长说服了(捂脸表情)。之后,因为外部原因,就是提高协调级别了。最终航班还是放行了。

今天,我看了一下flightradar上的飞行路径,查了一下气象报文,发现航班是用23号落地的。根据,我现在找到的报文,落地时间段内,最大的侧风可能有35节。

METAR RJTT 040430Z 17030KT 9999 -SHRA FEW010 BKN/// 30/25 Q1003 TEMPO 19032G42KT=
METAR RJTT 040400Z 17028G39KT 9999 -SHRA FEW010 BKN/// 30/25 Q1003 NOSIG=

另外,对于白天不用16号目视盘旋的说法,也许是机组的误传。我查了航图,日本人只说“perfer”,没说不允许用。

==========================丑陋的分割线=======================

总结:

1、我不想再听到机长说“你放我就走,你不放我就不走”之类的话。根据121法规,机长要依据放行资料,自己作出一个航班能否运行的决定,而不是听从签派员的那个决定!!!!

2、对于台风天,除了提前想好航路是否改航,还是把目的地的风以及备降场提前考虑好。

思考:

放行放的是标准还是风险?公司boss希望运控成为一个“控风险”的部门,既然是“控风险”,那必然出现“灰色地带”、“仁者见仁智者见智”、“事后诸葛”之类的事情。

如果一个航班,都满足标准,但是风险的确够大,是否还要坚持放行?根据我实际工作的经验,两种情况都有可能,而且,不管哪种选择,都可能事后被人捅刀子。

空中两套自动驾驶仪都不工作,这种倒霉的事真能碰到。

昨日有一个上海飞松山的航班,在起飞后几分钟报告两套自动驾驶仪都接不通。

一套不工作我听说过,两套都接不通,这就稀奇了。曾经在考试中问过别人的问题:“空中如果两套自动驾驶都不工作该怎么办”,成了真实的情况。我一边联系机务,一边想到RVSM,RNP,RNAV,二类都不能用了,还能不能飞松山?松山是不是有RNP APCH?飞往台湾的航路上能不能申请RVSM以下运行?我记得飞台湾有高度限制,具体是多少怎么突然想不起来了。如果飞过去还能不能飞回来。我承认在当时以上问题我一个答案都没有,而且有时间压力的情况下,的确慌乱了。

机务建议继续飞往松山,回程可MEL。我只能先把机务的意见转告机组。在那一瞬间,我想让飞机返航,但是我又拿不定主意,因为我只是扫了一眼飞行计划、QRH和MEL,还没有时间看航路上的限制,没有充分的理由。我本来想先让飞机飞一会,如果发现不行再返航,因为油量是足够的。但是我记得飞台湾的交界点肯定有高度限制,而且航班很快就会飞到交界点的,这个时间压力对我影响很大。幸好,随后飞机又出现了速度配平故障灯,机组考虑到复合故障,就决定返航了。

今天,有时间回忆一下昨天发生的事情,对自己的不足做个弥补。

先说QRH,我在事发当时看了QRH中自动驾驶仪的内容。两部都失效没有什么必要的操作,改为人工操纵就行了。今天看了速度配平的QRH也是没有什么内容。这两个系统都是辅助设备。

再看看MEL。
22-01B两部自动驾驶都可以失效,但是飞行时长可接受,而且不能执行延程运行、RNP AR、RNP-1、RNP-4、RVSM、RNAV-1、RNAV-2、CAT-II。
22-10速度配平系统2套可以失效1套。要求机务验证剩下的1套工作正常,速度配平不工作灯工作正常。因此,我认为就算自动驾驶都失效可以放行,空中出现速度配平灯亮,说明两套速度配平系统可能都有故障,或者是别的什么系统引起了两个速度配平系统故障。在松山能不能按这条MEL放行回来还真不好说。

再说回两套自动驾驶失效,上海和松山之间是否需要上述运行能力呢?航路如图所示,高度KASKA之前是9200米,之后是FL300。(情报说KASKA有特殊的交接协议,因此是双数高度层,而且有高度限制。我和管制朋友核实的确如此。)

因为计划的飞行高度层在RVSM内,我本来想说机组和管制申请降一个高度层,从92降到84,就可以不用进RVSM了,但是现在发现B591这一段的MEA是FL291因此无法降低高度,所以没有RVSM的话,这段就没法飞。另外,发现B591这一段是RNAV航路,但备注中写也可以接受NON-RNAV的飞行,不过再往南的L2航路也是一条RNAV的航路,没说可以接受NON-RNAV。所以没有RNAV能力,L2这段也没法飞。再看看松山的图。松山的进场没有RNAV,10号/28号有APCH但是也有传统。综上所述,这条航路至少需要RVSM和RNAV,因此两套自动驾驶都坏没法飞。

==============================================================

总结需要改进的地方:

1)在有时间压力的情况下,找出一个航班必须的所有运行能力是很难的。我现在坐在办公室的电脑上,花了1个小时来确认手册和航图。

2)EFB里的jeppesen航图软件可以加快这个过程,可以把航路输入进去,点击航路带号就能找到航路属性和信息。

3)空中出现故障养成看MEL的习惯。这个例子就很典型,QRH上什么都没有,MEL上一大堆限制(两套速度配平故障根本不能放行)。

4)返航落地注意检查落地超重,至少提醒机组主意超重。

5)做好资源管理,一个人查手册,一个人寻求机务、飞行支援,一个人回甚高频。