フライトシミュレーター愛好家のノート

中文 English 日本語 Français Deutsch Español 한국어 Русский 繁體中文

タイトル:エンジン始動時にAPUを切り忘れたミス 日本のASSE報告201603を読む

本サイトではAPUの話題をよく取り上げています。例えば、

<a href="/x-plane10/2017/06/a350-detail. target="_self">A350の機体の細部をもう一度見てみる <a href="/x-plane10/2017/01/777-cold-and-dark-startup. target="_self">ボーイング777のコールド・アンド・ダーク始動に挑戦 <a href="/x-plane10/2016/07/787-apu-inlet-door-opened. target="_self">飛行中に開かれたボーイング787のAPU吸気口ドア <a href="/x-plane10/2016/07/apu-inlet. target="_self">APU吸気口ドア (APU Air Inlet Door) の比較 <a href="/x-plane10/2012/07/airline-pilot-23-push-back. target="_self">旅客機操縦探秘 2.3 旅客機のプッシュバックとエンジン始動 などがあり、この話題には比較的敏感なようです。

今日、日本航空安全報告システムASRS報告 201603を見ていたところ、 エンジン始動中にAPUを切ってしまった事例を見つけましたので、ここで簡単に紹介します。

プッシュバックの許可を得た後、エンジン始動 (ENG START) の操作を開始しました。 第2エンジン (ENG 2 START) が始動した後、 機長は地上と連絡を取り、パーキング・ブレーキ (Parking Brake) を設定しました。 この間、副操縦士は機長から Normal Start の指示を受ける前に、APUを切ってしまいました。

機長も副操縦士もAPUの状態に気づかず、ENG 1 の始動を開始しました。 APUブリードがオフ (APU BLEED OFF) になっていたため、 N2の上昇が遅く、かつEGTの上昇速度が非常に速かった ため、直ちに始動を中止しました。

その後、チェックリストを再度確認し、地上要員および地上管制と連絡を取り、 ついにAPUがオフになっていることを発見しました。 その後、APUを再始動してから第1エンジンを始動し、その後はすべて正常でした。

事後の分析において、この操作ミスが起きた当時は風が非常に強く、 プッシュバック時にストレート・プッシュバック方式を採用していました。 テール・ウインドがあると思い込んでいたため、エンジン始動が遅くなると考え、 APUがオフになっていることに気づくまでにより長い時間がかかってしまいました。

では、なぜ副操縦士は誤ってAPUを切ってしまったのでしょうか? 当日の天候は悪く、風も強かった上、プッシュバック中にちょうど滑走路変更が発生しました。 一連の出来事により副操縦士の注意力が散漫になり、 機長の Normal Start 指示を聞いた後、 条件反射のようにAPUを切ってしまったのです。。

また、その航空会社では以前APUを切り忘れるミスが発生したことがあったため、 APUを关闭する際には「APU OFF」とコールすることを規定していました。 しかし、このような多忙な状況下では、その手順が忘れられてしまっていました。

今回のASRS報告書には、航空会社の現場からの様々なミスに関する160件の報告が紹介されており、 フライトの各段階に関連しています。読むのは少し退屈かもしれませんが、 実際の航空運航を理解する上で非常に役立ちます。 たとえば、優秀なパイロットでもこのような初歩的なミスを犯すことがあるとわかります! (ある例では、機体が滑走路に入り、機長がTOGAボタンを押して離陸しようとしたところ、 エンジンに反応がないことに気づきました。 急いで滑走路から退出し、あれこれ手間取った後、ようやくエンジンの自動モードがオンになっていなかったことに気づきました。。)

人間は機械ではないため、様々なミスを犯すことがありますが、ASRSを通じて、 お互いに交流し、改善し合うことができると信じています。

この世界のほとんどのものには脆弱性があります。 例えば、航空業界における音声によるATC通信には、 電波障害、訛り、話速、言語、不明確な表現、誤解を招きやすい指示などの脆弱性が含まれています。 また、自身の仕事には常に情報セキュリティが関わってきますが、 そこでも常に脆弱性と向き合っています。 例えば、OS/システムソフトウェア/アプリケーションのバグやセキュリティホール、 設計時のシステム容量計画の不足、ユーザー要件分析の不足、システム間インターフェース設計の性能不足、テストケースの不足などが存在します。 人間は最大の脆弱性の要因となる可能性があり、忙しいとき、緊張しているとき、疲れているときにミスを犯しやすく、 すべてが順調でストレスがない時ほど、かえってミスを犯しやすくなります。

脆弱性が普遍的に存在すること認めて初めて、仕事において正しい姿勢を保ち、 幸運に頼らず、一歩一歩着実に進むことができるのです。