记录一次贵阳冻雨过程

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位编码的过程。