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链接，找起来很方便。

今天听说GPS的周数翻转问题“GPS Week Number Rollover”。原理么很简单，发射的信号里周数用10位二进制表示，只能表示0-1023周。数完了就要从头开始。

需要注意的是时间，我看到一些民航发的文件写的都是2019年4月6日翻转，这很容易让人误解为4月6日零时翻转。其实应该是在4月7日的国际时0点，从1023变为0的一瞬间。我用UNIX时间戳计算了一下：

GPS的起始日期是1980-01-06 00:00:00UTC 。UNIX时间戳是315964800。

第一次翻转发生在1024周后，就是315964800 + 1024 × 604800 = 935280000。代表1999-08-22 00:00:00UTC。

第二次翻转发生在935280000 + 1024 × 604800 = 1554595200。代表2019-04-07 00:00:00UTC。换在北京时间就是2019-04-07 08:00:00

我猜想对于定位应该没什么影响（我猜要有影响也是在翻转瞬间），毕竟飞机上的位置更新，GPS只是数据源之一，无线电定位和惯导都还能发挥作用。

可能还有影响的是导航数据库版有效期，我看FCOM上写，如果导航数据库的有效日期与始终输入的日期不一致，就会跳出NAV DATA OUT OF DATE告警。

另一个需要小心的是数据链，如果飞机的时间真的变成了1999年甚至1980年，上行和下行的数据链是否能正常工作呢？（我猜现代的飞机应该不会这么破）

《MEMORANDUM FOR U.S. OWNERS AND OPERATORS USING GPS TO OBTAIN UTC TIME》可供参考。

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

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

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

我怀疑是不是图错了。

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

最近看到一个文件《关于建立和完善飞行程序反馈机制的通知（电561号）》，如果发现航图上的程序或标准有误的话，可以找NAIP当中写的机场当局的联系方式，还可以联系民航局空管局航行情报服务中心：qsms@aischina.com

文件还对机场的反馈时限进行了说明。希望以后此类通道更加通畅。

昨天，有位同事提醒我，他发现万州机场11号跑道的RNP APCH程序有个高温限制。如图：

所以，我见过高温限制在60摄氏度的。万州机场28摄氏度的高温限制，真是第一次见到。这个温度在今天（春季）就会被突破，今天的最高温度预报为30度，那就更别说大夏天了。

我本来的想法是，既然有低温修正，那应该也可以做高温修正咯。然而，似乎不是这样。我找了一下波音的FCTM，原文如下：

Boeing airplanes have uncompensated Baro-VNAV systems and are prohibited from using LNAV/VNAV minima on approach charts when operating outside of published temperature restriction limits. However, if cold temperature altitude corrections are applied as described in the Cold Temperature Operations Supplementary Procedures chapter of the FCOM, descent to the corrected LNAV (MDA) minima is allowed. There is no procedure for hot temperature corrections.

波音说，没有高温修正这回事。。。。

题外话，关于FCTM的这段文字，公司似乎有个翻译的歧义。原文的意思应该是：当温度超过航图上的温度限制时，不能使用Baro-Vnav的LNAV/VNAV；但是在温度超过航图上的温度限制时，可以做完修正后，使用LNAV。

但是有人会把这句话理解为，只要做了温度修正，不管当前温度是否超过航图限制，都不能使用LNAV/VNAV程序。

FAA发布过一个《Cold Temperature Restricted Airports》。文中提供了一个快速修正的表格，以及修正的例子：

For RNAV (GPS) approaches flown to the LNAV/VNAV line of minima using baro-VNAV vertical guidance, determine if there are published uncompensated baro-VNAV temperature limits. If the reported airport temperature is above or below the published limits, do not use the LNAV/VNAV line of minima unless the RNAV system is capable of temperature compensation and the system is active. Use an alternative line of minima (e.g., LNAV). CTRA correction must still be made on this approach if applicable.

根据低温修正的情况看，高温修正是忽略的。但是就和低温修正一样，如果当前温度超过高温限制，LNAV/VNAV自然是不能用了。但是LNAV仍然能用。

PS：空客的情况我还没找到，如果谁有相关的依据，请告诉我。

最近去丹佛培训的时候，北太平洋灵活航路一直是我比较感兴趣的一个话题。可能这个话题对于有些飞美国的公司来说已经不是什么新鲜事了。我还是想记一点东西，以备以后使用。

PACOTS是Pacific Organized Track System的简称，向东飞行用数字代号，向西飞行用字母代号。向东飞的航路由日本制作，向西飞的航路由美国制作。每条航路之间至少相隔50海里。航路不必从头用到尾，如果公司愿意可以在任意航路点加入或者退出灵活航路。甚至公司可以自己规划一条航路，叫User Preferred Routes (UPR)。

PACOTS通告举例：

J0933/18 1802090700–1802092100
RJJJ E)EASTBOUND PACOTS TRACKS BETWEEN SOUTHEAST ASIA AND NORTH AMERICA, TRACK 14. FLEX ROUTE : DOVAG UKATA 31N150E 33N160E 35N170E 37N180E 38N170W 39N160W 40N150W 40N140W 38N130W ALLBE RCTP/VHHH ROUTE : BORDO Y74 AZAMA Y57 TAMAK V73 DOVAG NAR ROUTE : ACFT LDG KSFO–ALLBE PIRAT OSI KSFO ACFT LDG KLAX–ALLBE PIRAT BURGL IRNMN KLAX RMK : TRK 15 NOT AVAILABLE ATM CENTER TEL:81-92-608-8870

A0597/18 1802091900–1802100800
KZAK E) (TDM TRK F 180209190001 1802091900 1802100800 ALCOA CEPAS COBAD 42N140W 46N150W 49N160W 50N170W 49N180E 47N170E 44N160E KALNA RTS/KSFO GNNRR ALCOA KLAX MCKEY LIBBO BRINY ALCOA KALNA OTR5 ONION RMK/TRK ADVISORY IN EFFECT FOR TRK F TRKS H / I NOT AVAILABLE DUE TO WINDS )

大家可以看到，向东的航线往往和急流轴同向，最大化利用顺风。而向西的航线都尽量和急流轴垂直，避免大顶风。

在时间有效性上的规定是飞过东经160度的一个时间窗口，比如在0700 UTC 到 1400 UTC之间飞过东经160度就能使用本条航路。（Joe说如果差几分钟可以和管制商量，一般都能同意，因为北太平洋航班少。北大西洋航班太多无法协调。）

FAA网站上还有个PACOTS Flight Planning Guidance的文件可以详细看看。

更新：微信网友Panda的信息：FAA还有一个《TRACK ADVISORY USER’S GUIDE FOR DISPATCHERS》写的更详细。

这两天网上微信群里在讨论贵阳DME不工作后，盲降程序还能不能飞的问题。我对这个问题本身没啥疑问，顺便发现一个我以前理解错误的地方。

以前都错误地以为FAF是精密进近的一个点。这两天在微信上看到一篇文章。原来FAP才是精密进近的点，FAF是非精密进近的点。

有个例子是ZYHB的03号盲降，FAF和FAP是分开来的：

在《目视和仪表飞行程序设计标准》中关于FAP和FAF的描述是：

经常在RNP APCH的航图上看到“无温度补偿的航空器的最低温度”，以前从来没担心过。

有说真的，-25度对于东北来说，不算什么，很轻易就能突破。机场往往还有会有个向北的盲降在，因此必须使用RNP APCH的机会不多。

不巧的是，这两天正好鸡西机场的30号盲降不工作。夜间在鸡西机场落地的话，温度肯定低于-25度了。那么RNP APCH的图就都不能用了。

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

我看了一下东北的机场好像都是按-25度制作的，不知道做程序的人是怎么考虑的，也许有别的限制。比如鸡西的1月份最低温度平均为-21度。而漠河机场的11月、12月、1月、2月的最低温度平均都超过-25度，也就是说全年的1/3都有可能不能用RNP APCH。

也许应该让飞行员手工计算高度修正，毕竟有人说加装温度补偿功能蛮贵的。呵呵。

被问到有些航图边上既不是TERPS也不是Standard，什么都没标，代表什么意思？我表示我也没注意过。

然后就去找了一下Jeppesen的说明。原来没标就是代表什么都不是。代表它和其它几个标了的都不同。（大笑）

上面说的是落地标准的计算方法。另外还有保护区的设计规范分TREPS和PANS OPS，有些航图上也会什么都不写。

一个例子是冲绳机场：

然后在JEPPESEN的一个很不起眼的地方找到了说法：

注意最后一行小字Note：如果不写PANS OPS又不写TERPS，就代表这个机场UNKNOWN。（大笑）

这个案例是一位同事发给我的，12月的台风，我觉得有必要和大家分享。

2016年12月12日守夜，晚上2230左右，VCBI机组卫星电话反映，当地代办告知其本次航班的FPL报文航路必须更改，要改走其他航路。

A2611/16 NOTAMN
Q)VOMF/QFAXX/IV/NBO/A/000/999/1300N08011E005
A)VOMM
B)1612121140 C)1612121730 EST
E)OWING TO CYCLONIC STORM ‘VARDHA’ AND FLOODING IN CHENNAI AIRPORT LEADING TOTAL PWR SUPPLY DISRUPTION AFFECTING ANS SERVICES IN VOMM FIR.ATS SERVICES IN PART OF VOMM FIR OVER BAY OF BENGAL IS NOT AVBL. ACFT ENT VOMM FIR ADHERE TO ATS CONTINGENCY PLAN, FLW INTL ATS RTE P574 (CR2) FL350 AND FL370 FOR EAST BOUND,FL320 FOR WEST
BOUND,P762 (CR9) FL270 EAST BOUND AND FL280 WEST BOUND AND P628(CR10) FL350 EAST BOUND ONLY. ATS ROUTES M300,P570 AND UL425 ARE AVBL FOR NML OPS. ALL OTHER ATS ROUTES ARE NOT AVBL

大致内容为受台风和洪水影响，VOMM金奈情报区电力供应中断，导致其除公布的航路外，其他航路均不可用。

经过导航评估，发现目前开放的航路均为跨海航路（东西向），需要执行ETOPS才能走，并且由于更改了航路走向，飞越的国家也和原航路相差很多，需要申请越南/老挝等国的批复，操作起来很有难度。（VCBI有两种走向，一种走内陆有释压，另一种走海上有ETOPS，目前公司选择走释压航路，因此ETOPS航路没有申请过）

与值班主任商量后，考虑到通告预计结束时间为1730UTC，不算太久，可以考虑直接延误航班等航路开放。同时我也告知机组先别上客等我们消息。

我们决定先咨询一下科伦坡代办能否得到航路恢复的具体时间，经过新加坡站长（他也负责科伦坡航班）的询问，以及通过机组直接询问当地代办负责人，得到的回复均是不确定何时能恢复航路。

同时我也在气象网站上查到当时VOMM机场实况是30节的大风和中雨，天气恶劣，感觉当地要恢复设施估计要很久，延误航班等航路开放的方案基本无望。

值班主任准备联合航务、性能支持来评估改走ETOPS的可能性。

这时戏剧的一幕发生了，MCC报告飞机刚刚办了个MEL 28-22-01，主油箱燃油泵故障，MEL条款内明确不可执行120分钟的ETOPS。故依照通告改航执行ETOPS的方案也没戏了。

于是我们又联系了情报导航席位，让他们找一条能从印度内陆绕飞的航路，情报很快找了出来，但是所走的航路为W47，W53，W20航路，是只针对印度国内航班开放的。

我们抱着试一试的态度，考虑到站长的英语表达应该比我清晰，便把改航的内容告诉了新加坡站长，让其转述给科伦坡代办，咨询改航是否可行。

同时张凰华也在微信上联系到了机组，把航路走向告诉他，让他们也和当时在飞机上的代办工作人员核实一下是否能这样改航。

在等消息的同时我们也联系了航务和性能的支持，确认了新的航路不涉及申请飞越批复以及释压。

新加坡站长回复说W47确认可走，但W53和W20需要继续核实，但迟迟没有回复，并且站长表示其能询问的渠道只是当地的商务，未必靠谱。

这时VOMM发布了新的通告，航路关闭时间延长到次日0130UTC。

由于迟迟得不到改航航路的确认，此时机组也已经在飞机上等待了近3小时，我们和运行经理商量后，决定把航班推迟到次日0130UTC，先让机组休息。

这时机组发来微信，他们自己找了条走T4和W42的航路，与代办确认可以这么走，我们立即联系航性情，确认了可行性，且不涉及释压。当即决定按照此航路制作计划。

我立即联系机组告知最后改航的决定，同时让其等我们的新计划。我也马上把新的计划发到了代理邮箱。

为了确保FPL符合当地ATC要求，我在最后RMK内添加了备注：CHANGE ROUTE DUE CYCLONIC STORM ，

并且致电代办斯里兰卡航空签派，在确认已收到我们新计划后，告知其我们需要核实FPL是否符合印度管制要求，请他们再次联系印度管制确认航路走向，并且如果FPL不被印度接受马上通知我们。

机组拿到计划后，我再次电话机组告诉他们等我们半个小时，我们需要核实报文是否被弹回。

半小时后我致电斯里兰卡签派，确认我们新航路可行，且没有被印度管制拒绝后，请示值班主任，电话给机组，让其上客，放行航班。此时已是凌晨2点多。

0308北京时航班起飞后，我在flight radar上时刻关注其走向，在确认它沿着改航的航路正常飞行后，悬着的心才放下。

总结：
1. 当日原先导航席位并未对该条重要通告做出提示，所以我们放行时还是要认真阅读情报区的通告，有疑问的找情报导航核实，国外情报区的通告内容非常多，我们除了用搜索航路关键字来提高效率外，也可以请导航席位来帮忙一起看，确保万无一失。
2. 对于国外没有中文代办的机场，在有问题需要用英语沟通时确实非常困难（尤其是带口音的国家），我的经验是自己的关键词一定要表达清楚，并且要再三复述重点，必须要得到对方YES或者NO的明确答复才行，如果对方实在要说一大堆，可以要求对方用邮件沟通。
3. 有时我们为了交流方便会委托当地站长来协助，但是站长对于偏专业的问题，未必有权威的渠道可以联系，还是需要我们自己去尽量寻找当地的签派或者运控人员来沟通，让信息的来源更加权威可靠。
4. 对于国外代发FPL的航班，我们缺乏有效的监控手段，无法准确及时获知报文是否出问题，只能通过代理航空公司来联系，不知以后能不能通过软件手段对国外代发的FPL做到监控。
5. 事发当日恰逢浦东低云二类运行，当时的其他航班的事务已经有些混乱，这时一定要用好值班记录本，罗列出目前需要自己处理的事情，当时我由于记录的有些乱，导致自己差点忘了飞机的MEL主油箱燃油泵对于主油箱有最低燃油量的要求。

最后附一张台风玉照：

好久没更新了，带两个娃的结果就是完全没有自己的时间。

11月25号的时候，YMML说燃油被污染，对出港航班限制加油，一共只给我公司80吨。这种怪事还是第一次听说。YMML回ZSPD要10小时，计划是一架330和一架777都有航班，只给80吨怎么分的过来！

所以后来的办法就是加降一次悉尼。

改计划，重新申请，还发现ETOPS区域变了，弄得鸡飞狗跳的。终于做出个三个圈的ETOPS计划。

当我们认为此事已成的时候，发现去悉尼的航班爆满，只能去布里斯班加降。

又是一阵鸡飞狗跳。。。。。

我们在工作时，看到落地标准是DH或MDH 200ft的自然会觉得代表Ceiling云底高就是200ft。如果DH或MDH 201ft，那么Ceiling云底高就应该是300ft。这种想到DH/MDH自然就想到Ceiling，或者说DH/MDH “就是” Ceiling的概念一直就在脑海里，以至于有一天，某人和你强调DH/MDH不等于Ceiling的时候，会有些不习惯。

比如说，有些地方就是会强调DH和Ceiling分的很清楚。比如RKTN：

除了注明DH是541ft外，还特别说明了Ceiling是600ft。有没有觉得多此一举？

为此我还专门去查了韩国的AIP图例(GEN 2.3-9)和AIP中的航图。

注意图例中的“362”虽然标的是DH，但是基准是MSL。所以其实是DA。
真正的DH是后面的“Height of DH”。最后的ceiling其实就是DH向上取整。

原版航图：图中DA为652，DH为541，Ceiling为600。和Jeppesen图一样的。

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

为啥DH和Ceiling分得那么清楚呢？我后来想想分得清楚是没错呀，错的是我们。国内吧DH和Ceiling混为一谈其实是不对的。所以国内好多签派员觉得这两个概念是同一个东西。以前在学FAA执照时，教员就和我们反复说过“No Ceiling”。放行时（至少盲降标准时），应该不考虑Ceiling，除非航图中要求Ceiling Required。

想到一个题外话。我特地去查了一下737飞机上的MINS选择器，用来设定决断高或决断高度，它的最小单位是英尺。DH是应该精确到英尺的，机组飞的是DH不是Ceiling。