墨尔本短跑道起飞案例

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

前几个月,墨尔本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)做好资源管理,一个人查手册,一个人寻求机务、飞行支援,一个人回甚高频。