Air Tugとは何か？ --日本の航空安全報告システムASRS報告書を再読する

2015-11-28 | 航空安全

少し時間ができてASRSの更新を見てみた。以前のまとめはこちら。

シンガポール空港でプッシュバックを待機中、地上管制から連絡があった “Aircraft is cleared, but we are waiting AIR TUG.” クルーはAIR TUGが何かわからず、エアバスの機が通り過ぎるのを待っているのだと勘違いした。実はAIR TUGとは牽引車（トウトラクター）、つまりプッシュバック用の車両のことだったが、クルーがまったく知らなかったため誤解が生じた。国によって呼び名がまちまちで、用語の統一が不可欠だということがわかる。
マニラ空港でプッシュバックの方向が逆だったクルーからの地上管制への原話は「Ground, Cockpit. We are cleared for Push Back S4 Heading East Runway 06」なぜかプッシュバックは西向きに行われ、その後Ramp ControlはLのG8Eへロングプッシュバックするよう変更せざるを得なくなった。どうやらS4では通常、西へ推すことが多く、クルーと地上のコミュニケーション不足が誤解を招いた。同様のミスは中国の某空港でも発生している。
滑走前にフラップを展開し忘れるこうした事例は何度も見たことがある。一般的に、想定していた滑走路とは違う場合など、クルーの作業が忙しくなり、Flap setを忘れることは理解できる。ただし、ある会社のシステムでは、Taxi前に展開していないと、コックピットのプリンタが自動的に警告情報を印刷するようになっており、パイロットはそれに気づけるようになっている。
滑走路を間違える問題成田に関するものが最も多く、空港図面に不慣れあるいは忘れているパイロットが少なくないようだが、空港の地上ルートが複雑すぎることも示唆されている。羽田についても数件あり、日本のパイロットにはここはお手の物だが、それでも過度な自信からルートを間違えることがある。

個人的には、音声ベースのATCだけではコミュニケーションミスを完全に防ぐのは難しく、理想的な解決策は、地上車両用のナビゲーションシステムのようなものを導入することだろう。

香港で地上でのニアミス A誘導路を走行中、右へ旋回しようとした際、副操縦士が隣のB誘導路を直進して減速していないトウトラクターに気づき、即座に機長にブレーキを知らせ、衝突を回避した。その後、トウトラクターが異なる地上周波数を使用していたため、管制からの指示を聞いていなかったことが判明した。
GPSを使うべきか？沖縄・那覇空港の地上でEICAS上に数回「NAV UNABLE RNP」が表示され消えた。 SIDはRNAV1のEISARプロシージャ。パイロットはRNAV1ではGPSは必須ではないと考え、GPSをオフにして離陸した。しかし後の分析では、地上でGPSアップデートを行うべきだったか、別のSIDを要求すべきだったと考えられている。以下は<a href=/view1.php?file=doc/AIP-J/ROAH_Naha.pdf>当サイトの那覇空館航図内の注記： Note ※The aircraft equipped with only DME/DME/IRU must be able to update its position without delay at the starting point of take-off roll. 1 ) DME/DME/IRU or GNSS required. 2 ) RADAR service required.
中度の乱気流中にMCPで高度変更乱気流に遭遇し、FL330からFL310への変更を申請したが、なぜかFL300に設定され、 Level off前に副操縦士が気づき訂正してくれた。したがって、MCPだけを見るのではなく、画面上のデータも必ず監視しなければならない。
人はどうしてもミスをするこの号では人的ミスに関する報告が多い。ラジオの周波数がいつの間にかActiveとStandbyが切り替わっていた；管制が頭ではFL230へ降下させるつもりだったが、口に出したのはFL210；高度変更で管制はFL370と言ったが、パイロットはFL270と聞き取った； VNAV PATH MODEを使っていると思っていたが、実は以前に風速の変化でVNAV SPEED MODEに変更したことを忘れており、結果としてアプローチ速度が速すぎた；展開速度を超えてしまい、一瞬フラップを下ろしてしまった；管制は右の空港ルートを要求したのに、機長は左ルートと聞き取った；機長側で気圧補正値30.11を28.80と間違って設定し、当然オートパイロットは低すぎる飛行を行い、慌てて手動飛行に切り替え、BARO Set Disagreeのメッセージで左右の違いに気づいた；直行ARLONをAPOLOと入力してしまった；など。しかし幸いなことに多重チェックの仕組みがあり、大きな問題にはならなかった。
飛行中の機材の問題？感覚的には、ハードウェアではなくソフトウェアの問題もあるようだ：ラジオの塔のStandby周波数が表示上はActiveに切り替わったが、実際に聞こえているのはアプローチ；何度か切り替えを繰り返した後、ようやく塔に切り替わったが、この時の高度はわずか1500フィート；非精密進近でIAN（Integrated Approach Navigation）を使用した際、バンクが不安定になることがある； FAF以降で距離が短い進近で、Final Approach Courseから逸脱した状態でAPPボタンを押すと発生するらしい； FAFより前でVNAVがアームできない。事後調査によると、前方のウェイポイントが現在の高度より高い場合、VNAVはアームできないとのこと。
RNP ARの高度問題 RNP ARでは気圧高度を使用するが、METARのQNH3022を使用した際、PAPI灯が4つとも赤になった。着陸後、それはちょうどMETARが変更される前の値で、着陸時の実際の値は3018だったと判明した。
着陸時にスラストリバーバーを作動中に誤ってゴアラウンドモードをトリガーある空港で自動着陸を使用中、着陸後にスラストリバースを作動させた際、誤って人差し指がTOGAに触れ、画面表示もGAモードに変わった。本来このままゴアラウンドすべきところ、出発時すでに30分遅れていたため、無意識のうちに着陸を続けようとし、オートスロットルを切断し、機首を下げ、さらにスラストリバースを続け、オートパイロットを解除した。その過程で“Pitch attitude high at Landing”となり、ピッチ角が高すぎたが、幸いなことに機体尾部は擦らなかった。

まとめ人はマシンではない。特に繁忙時や緊張状況ではミスがつきものだ。しかし問題を回避せず、自分の過ちを隠さず、友好的に他者と共有する――こうした仕組みと環境は非常に貴重であり、我々部外者にとっても学ぶべき点が多い。