引气压力低造成航班返航

都说我值班倒霉。周六的时候一个航班起飞后报告左发引气压力低。空调和增压方面没有特殊情况。航班正在大约起飞30分钟后的巡航阶段。机务也监控到引气压力低了。在通过卫星电话和机组联系,尝试重置两次后,都没能提高引气压力。

在处置过程中,我惊讶地发现,波音737的引气压力低是没有QRH的。最后我们决定用引气跳开(BLEED TRIP OFF)这条来处理,虽然引气跳开是因为超压或超温,我们现在是没压力,但是结果都是一样地把一边的引气关掉。

从检查单上可以看到,关闭一侧的引气和对应的空调组件,但是剩下的一个引气不足以支撑另一侧高流量的空调组件+大翼防冰。因此就要避开结冰条件了。

不巧,这个航班是从上海飞乌鲁木齐,不但有可能用到大翼防冰,还存在释压供氧航段。如果硬着头皮使用大翼防冰,那可能造成引气跳开和失压。所以考虑返航了。检查了一下载量和油量,落地正好不超重。

我顺便看了一下320系列的QRH,空客系列有个AIR ENG 1/2 BLEED ABNORM PR,虽然我也没看到这个ABNORM是指高压还是低压。

从空客320的MEL上看,MEL36-11-01A中提到了一个引气失效后的放行操作流程。特别提示:

飞行机组应考虑到结冰条件的严重性。如果剩余的发动机引气供给系统也不工作时,将失去机翼防冰。

并且在飞行过程中,如果需要使用大翼防冰,可以将受影响一侧的空调组件关闭。

从波音737的MEL上看,MEL36-11-03压力调节和关断活门(PRSOV)一个引气失效的情况下,要求不在积冰气象条件下飞行(应该是不够大翼防冰了),飞行高度FL250以下。并且在地面时,为了防止发动机EGT超温,不能给两个空调供气。

从这个角度看,737的空调是要比320的弱一点。

记录一次贵阳冻雨过程

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个航班。