Probable Cause of Comair 5191

　本日の朝８時半過ぎ、NTSB: National Transportation Safety Board （米国運輸安全委員会）から一通のメールが舞い込んでいました。

Subject （件名）は、
　「NTSB DETERMINES COMAIR 5191 FLIGHT CREW FAILED TO USE AVAILABLE CUES TO DETERMINE LOCATION DURING TAKEOFF」

昨年８月２７日午前６時６分３３秒〔米国東部夏時間〕、Comair 5191/27AUG LEXATL N431CA (Canadair CL-600-2B19 (CRJ200ER) Regional Jet) が、ケンタッキー州レキシントンは「 Lexington-Blue Grass 空港」で離陸に失敗、４７名のお客様と２名のクルーの尊い命が失われました。合掌。

最終的に事故に至ったのは、運航乗務員が Tower から離陸許可を発出れた Runway 22 ではなく、滑走路長の短い Runway 26 から離陸滑走を開始したため、滑走路内で離陸できずに、滑走路先の森に激突、炎上したことによります。

事故発生から、NTSB は事故調査に着手し、これまでにも幾つかの安全勧告を出すと同時に、今年１月には CVR: Cockpit Voice Recorder ならびに ATC 交信記録の Transcription を公表しました。

【関連投稿】
　「 Comair 5191/27AUG LEXATL ATC Transcription 」

今朝来たメールは、probable cause （有力な原因）と共に５項目の recommendations （勧告）からなる IMMEDIATE RELEASE です。

当該事故の最終報告書は、数週間中に公開されるとのことです。

NTSB の Mark V. Rosenker 氏は、

“ This accident was caused by poor human performance, Forty-nine lives could have been saved if the flightcrew had been concentrating on the important task of operating the airplane in a safe manner.”

と言ったそうです。

極めて乱暴な意訳をするならば、
　「エアマンシップの欠如により４９名の尊い命が奪われた」
と言えましょうか。

NTSB は、

－運航乗務員が地上走行中ならびに離陸滑走開始前に、利用可能な可視目標物（標識やペイント；所謂 visual cue ）を的確に利用しておらず、運航乗員間で自機位置の相互確認を行っていなかった。

－地上滑走中、運航乗務員間で交わされていた運航には無関係な会話が、自機位置認識・注意力欠如を招いた。

－FAA: Federal Aviation Administration （米国連邦航空局）の、滑走路横断許可に関するルールの適用が不適切であった。

ことを主たる probable cause として述べています。

勧告については、詳細は省略しますが、

－運航者に対する注意喚起と規則遵守の徹底

－空港管理者に対する空港インフラ（ペイント等）の整備の徹底

－管制方式の改定

が述べられていると同時に、疲労や訓練体制等へも言及しています。

悲惨な事故が発生してから１１ヶ月、間もなく事故調査報告書が公になります。

---

************************************************************
　　　　　　　　　　　NTSB PRESS RELEASE
************************************************************

National Transportation Safety Board
Washington, DC 20594

FOR IMMEDIATE RELEASE: July 26, 2007

SB-07-38

************************************************************

NTSB DETERMINES COMAIR 5191 FLIGHT CREW FAILED TO USE
AVAILABLE CUES TO DETERMINE LOCATION DURING TAKEOFF

************************************************************

Washington, DC -- The National Transportation Safety Board today determined the probable cause of the Comair flight 5191 accident in Lexington, Kentucky was the flight crew's failure to use available cues and aids to identify the airplane's location on the airport surface during taxi and their failure to cross check and verify that the airplane
was on the correct runway before takeoff. Contributing to this accident were the flight crew's nonpertinent conversation during taxi, which resulted in loss of positional awareness and the Federal Aviation
Administration's failure to require that all runway crossings be authorized only by specific air traffic control clearances.

"This accident was caused by poor human performance," said NTSB Chairman Mark V. Rosenker. "Forty-nine lives could have been saved if the flightcrew had been concentrating on the important task of operating the airplane in a safe manner."

On August 27, 2006, about 6:07 a.m., Comair flight 5191, a Bombardier CRJ-100, (N431CA) crashed upon takeoff from Blue Grass Airport in Lexington, Kentucky. The flight crew was instructed to take off from runway 22, an air carrier runway that is 7,003 feet long. Instead, the flight crew lined up the airplane on runway 26, a 3,501-foot-long runway, and began the takeoff roll. Runway 26 crosses runway 22 about 700 feet south of the runway 22 threshold. Of the 47 passengers and 3 crewmembers onboard, 49 were fatally injured and one (the first officer) received serious injuries. Impact forces and a postcrash fire destroyed the airplane.

As a result of this accident, the safety Board made the following recommendations:
　　　　To the Federal Aviation Administration:
1. 　　　Require that all 14 Code of Federal Regulations Part 91K, 121, and 135 operators establish procedures requiring all crewmembers on the flight deck to positively confirm and cross check the airplane's location at the assigned departure runway before crossing the hold short line for
takeoff.

2. 　　　Require that all Code of Federal Regulations Part 91K, 121, and 135 operators install on their aircraft cockpit moving map displays or an
automatic system that alerts pilots when a takeoff is attempted on a taxiway or a runway other than the one intended.

3. 　　　Require that all airports certified under 14 Code of Federal Regulations Part 139 implement enhanced taxiway centerline markings and surface painted holding position signs at all runway entrances.

4. 　　　Prohibit the issuance of a takeoff clearance during an airplane's taxi to its departure runway until after the airplane has crossed all intersecting runways.

5. 　　　Revise Federal Aviation Administration Order 7110.65, "Air Traffic Control," to indicate that controllers should refrain from performing administrative tasks, such as the traffic count, when moving aircraft are in the controller's area of responsibility.

The Safety Board reiterated two previously issued recommendations to the FAA:
Amend 14 Code of Federal Regulations (CFR) Section 91.129(i) to require that all runway crossings be authorized only by specific air traffic control clearance, and ensure that U.S. pilots, U.S. personnel assigned to move aircraft, and pilots operating under 14 CFR Part 129 receive adequate notification of the change.

Amend Federal Aviation Administration Order 7110.65, "Air Traffic Control," to require that, when aircraft need to cross multiple runways, air traffic controllers an issue explicit crossing instruction for each runway after the previous runway has been crossed.

Previously issued recommendations to the FAA resulting from this accident include:
Require that all 14 Code of Federal Regulations Part 121 operators establish procedures requiring all crewmembers on the flight deck to positively confirm and cross-check the airplane's location at the assigned departure runway before crossing the hold-short line for takeoff.

Require that all 14 Code of Federal Regulations Part 121 operators provide specific guidance to pilots on the runway lighting requirements for takeoff operations at night.

Work with the National Air Traffic Controllers Association to reduce the potential for controller fatigue by revising controller work-scheduling policies and practices to provide rest periods that are long enough for controllers to obtain sufficient restorative sleep and by modifying shift rotations to minimize disrupted sleep patterns, accumulation of sleep debt, and decrease cognitive performance.
Develop a fatigue awareness and countermeasures training program for controllers and for personnel who are involved in the scheduling of controllers for operational duty that will address the incidence of fatigue in the controller workforce, causes of fatigue, effects of fatigue on controller performance and safety, and the importance of using personal strategies to minimize fatigue. This training should be provided in a format that promotes retention, and recurrent training should be provided at regular intervals.

Require all air traffic controllers to complete instructor-led initial and recurrent training in resource management skills that will improve controller judgment, vigilance, and safety awareness.

Earlier this year, the Board issued the following recommendation to the National Air Traffic Controller Association:
Work with the Federal Aviation Administration to reduce the potential for controller fatigue by revising controller work-scheduling policies and practices to provide rest periods that are long enough for controllers to obtain sufficient restorative sleep and by modifying shift rotations to minimize disrupted sleep patterns, accumulation of sleep debt, and decreased cognitive performance.

　　（以下省略）

ThinkPad 故障再び ... 天罰

　約１年半前と同じ症状が再発です。

メインマシンとして活躍中だった ThinkPad T42 が、昨夕、突然に電源が落ちて、再起動を試みたら Beep 音と共に
　"Fan Error"
と表示され、Windows が起動しません。

普通にしていると（とある操作をしないと）、電源投入後からの F1 キー連打でも BIOS 設定画面にすら入れません。

この症状、冒頭でも述べたように、２００５年１２月１４日に発生した不具合と同じでありまして、そのときは、“保障期間内”ということもあり、即刻入院させて修理したのでした。

今回も修理に出そうか・も少し待つか悩みましたが、当該マシン、HDD を購入時の 80GB から 160GB への増設させており、中にはデジカメで撮影した画像データや iPod で楽しむ兼語学学習用（一説には眠りを誘う）BBC, CNN, ABC, FAA などの Podcast のデータも相当に入っているのです。

普段から一番使っているマシンなので、愛着もありますしね。

データ類のバックアップは抜かりなく実施しているので、この際、予備機へ機材変更しても良いのですが ～何と予備機の方がスペックが上；PW7074 の -200 から GE90-115B の -300ER に乗り換える感じ～ 、データの移行の手間、修理代はいくらか、直ってきたその後どうする？（日常的に、巨大推力の快適さを暫し味わってしまうと....）など等を考えて、速攻でドック入りさせるのは思い留まっております。

Beeper が鳴って Fan Error が表示されても、Escape キーを押すと、protection override できることは前回の故障で経験済みでして、起動は問題なくできるのです。

が、いまどきの『心で踊るのよ』社のプロセッサは、チップセットやグラフィック・チップ等とも相まって適切な冷却無しでは、あっという間に温度が上がり、Overheat Protection で何の前触も無く電源を落とすのは明白です。

“暫らくは使おう”と決めたからには、"Fan Error" を補う策を講じなければなりません。

早速、携帯電話の FeliCa Chip の Area 0 に 32 Block を割り当てて入っている、某ポイントを調べたら、１万円以上を捻出できるではありませんか。

『よし、これだ！』と、オペセン帰りに、某所のヨ○バ△へ Technical LDG です。

最近は Note PC 用のファン付き冷却台座も種類が豊富になり、選択肢が増えました。

見た目、強力そうなクーラーパッド（アルミ製で DC5V で２つのファンをぶん回す；USB 給電のものもあったが、己を冷やすために己の電力食われたのでは本末転倒と判断）と、PCMCIA スロットに差し込んで、PC 内部の熱を逃がす FAN （こちらは、USB Bus Power だけれど、USB port はクーラーパッドに備えるそれを利用）をポイントで入手、こうして慣れたマシンで、内心ビクビクしながら書いているのであります。

放熱効果も良好で、また、ThinkPad T42 に備える「バッテリー省電力ウィザード」で“ FAN ERROR 対策用設定 ”なる新たなプロファイルを作成、AC 駆動時の CPU Power 等を抑え発熱を防ぐ設定を施したので、期待通り、いや、期待以上の効果が得られていると言えましょう。

その代償として、高スペックのデスクトップＰＣを凌ぐ音がしておりますが....。

それにしても、何故にぶっ壊れたのでしょう。パーツ交換しても１年半でまたぶっ壊れるとは....。

原因は何となく解っているのです。

“天罰”です、生意気なことを言った。

○○さん、ごめんなさい。

---

きょうのところは、まだビクビクで「時間との勝負」で仕上げてますが、ちょっと落ち着いたら、仕入れたブツの写真をば掲載するつもりです。

Maintenance...

maintenance

1　（…を）保つこと《 of... 》;持続;維持
costs of ～ [=～ costs]　 維持費.
2　営繕,保守,メンテナンス
building ～　 建物の保守.
3　擁護;主張.
4　《英》扶養;扶助料,養育費
separate ～　 （妻に対する）別居手当.
5　〔法〕訴訟幇助（ほうじょ）.

Progressive English-Japanese Dictionary, Third edition © Shogakukan 1980,1987,1998 /プログレッシブ英和中辞典 第3版 ©小学館 1980,1987,1998

メンテナンスを怠ると、夏のこの時期、草 －得てして雑草－ が生い茂ります。

こんな愚ブロクですが、それなりには見栄えを気にするので、草むしりが必要です。

また、メンテナンスを怠ると、トラックバックの公開が遅れて失礼になることもあります。

何処の世界においてもメンテナンスは大切です。

２００７年台風第４号［アジア名： MAN-YI （マンニィ） アジア名通番３２，命名国・地域：香港，意味：海峡の名前］の動きが非常に気になるところではありますが、本日夕刻より（念のため）“ MAY RETURN ”をかけて、２泊３日パターンであります。

MAN-YI の動き次第では３泊４日パターンになってしまうかも....。

先の投稿にコメントを寄せて下さっている皆様、返信が遅れて大変申し訳ございません。今しばらくご辛抱をお願いいたします。

Dreams will come true ? ( Phase I )

　「セーフコ・フィールド」を本拠地とする“マリナーズ”、背番号５１の“イチロー”選手はメジャー７年目の今シーズンも打率３割６歩と好調で、７年連続２００本安打の記録（彼には一つの通過点なのかもしれませんが....）に向けて活躍を続けているようです。

現在、“マリナーズ”は、“オークランド・アスレチックス”とアウェイ（マカフィー・コロシアム）での四連戦中。三戦目となる七夕のナイトゲームは４－０で完封勝利、三連戦成績を●○○の２勝１敗とし、明日のシアトルの街にエールを送りました。

一夜明けて、７月８日［日］の午後〔現地時間〕には、いよいよ Dreamliner こと Boeing 787 の初号機が Boeing 社の Everett 工場の組み立てラインからお外に出ます。 Roll-Out です。

未だ空を飛ぶ訳ではないので、複合素材をふんだんに使った“張子の虎”ではありますが、いよいよ、その現物が公衆？の面前に現れる訳です。

末っ子？のデビューを祝うために、Boeing 社では、歴代７シリーズを並べて、Roll-Out をお出迎えする演出を行なうようです。

予報によると、明日のお天気は「晴れ時々くもり」、予想最高気温は７１Ｆ（約２１．５℃）とちょっと低めですが、きっと夢の第一章にはまずまずではないでしょうか。

７８７デビュー前日である、７月７日の午後７時７分（米国の表記では、7/7/07 ）に、Boeing 707 が Boeing Field に降り立った、その時点から Dreamliner Roll-Out イベントは開始されているのでした。

以上、シアトルよりＰＡＸがお伝えしました....、と言ってみたい！！

A 707, on 7/7/07, landing at 7:07

Before the landmark 787 Dreamliner arrives tomorrrow, Boeing honored those models that came before — and with a dramatic sense of timing. Seizing once-a-century opportunity, the company landed a parade of its 700-series planes at its Seattle field within minutes of one other, starting with this 707 at 7:07 p.m. on July 7th, 2007.

The Seattle Times: NEW - 09:35 PM
© 2007 The Seattle Times Company

© 2007 ERIC KAYNE / THE SEATTLE TIMES

ドリームライナー ロールアウト カウントダウン

　Boeing787、Dreamliner のアセンブルがシアトルの Everett 工場で着々と進んでおり、２００７年７月８日（英語表記では、07/08/07 ... 787 ）の Roll Out が間近に迫ってきました。

Roll Out のイベントは、現地時間〔 PDT: 米国西海岸の夏時間 〕の午後３時３０分から、日本時間では７月９日［月］の午前７時３０分から webcast で中継が予定されています。

順調に進めば、来年５月に全日空に最初の Dreamliner がデリバリーされる予定です。

受領した青社では、早速、北京オリンピックを見据えて、中国線にも投入するのではないでしょうか。

「順調に進めば」と記したのは、新型機の開発においては何が起こるか解らないからです。
※ Airbus A380 も当初の予定通り順調に進めば、今頃は、既にシンガポール航空が商用運航に供していた筈です。

Dreamliner の組み立ては順調そうで、Boeing 社の開発チームも、楽観的な姿勢を崩していませんが、全く問題なく順調か、というと必ずしもそうではないようです。

既に数多く報道されていてご存知だと思いますが、この Dreamliner 、複合素材をふんだんに取り入れ、予め組み立てられた主要パーツを胴体に取り付ける、という組み立て手法がとられています。

中部国際空港－セントレア－から、DreamLifter で主翼を空輸したのはご記憶にあるかと思います。

とある報道によると、一号機において、この主翼、右側の主翼は、胴体部分と完璧に（ dead-on ）取り付けられたそうですが、左側の主翼と胴体部分との間には、0.25 inch ( ボ社の公表した値は 40/1000 inch ）［１インチは２．５４センチなので、0.25 inch とすると６ミリ； 40/1000 inch とすると１ミリ］の隙間が生じたそうです。

ボーイング社によると、直径５．７４ｍ の胴体でこの隙間は決して許容できる値では無い、としながらも、隙間が発見された時点では、部品調達が間に合わず（業界全体でファスナーの供給不足が発生している）胴体と主翼との構造部分で全てのファスナーを装着していない、仮の取り付け状態であったとも言及しています。

Roll Out の段階で、機体構造的には組み立てを終えていることになりますが、その後、機体内部の配線や空調ダクト、電子システム装着、ならびにエンジンを取り付けての地上テストを実施しなければなりませんので、ボーイング社のテスト・パイロットによる初飛行は、８月下旬～９月頃になる見込みです。

エンジンと言えば、去る６月１９日に、Rolls-Royce 社が Dreamliner 向けに開発した Trent 1000 が、Boeing 740-200 の No.2 Engine として飛行テストが実施されました。

Dreamliner のエンジンは、General Electric GRnx と Rolls-Royce Trent 1000 から選択できますが、Dreamliner の売りは、どちらのエンジンを採用しても、主翼とエンジンとを取り付ける「パイロン」と呼ばれる構造部分が共通であることです。

※蛇足ですが、コックピットのウィンドウが４面というのも、ボーイング社としては珍しい....（通常は６面です）。


Photo Credit: Boeing Photo

このようなセールスポイントと共に、不安点も露呈してしまった Dreamliner ですが、徹底的な飛行テストと品質管理を行なって、Dream とならぬようにデリバリーされることを願っています。

ちなみに、１号機から６号機までがメインで試験飛行に供されるため、それら６機は、ボーイング社の目標としている機体重量を超過してしまうであろうことから、全日空にデリバリーされる機体は７号機になる予定です。

ボーイング社にとっても、ここからが本当の正念場と言えるでしょう。

【タイトル画像について： Photo Credit: Boeing Photo 】

ＦＥ ～ ＳＢＯ ～ ＡＨＭ

　今でこそ、双発機が至極当り前のごとく太平洋上に提灯行列をつくり、ノンストップで本邦や東アジア諸国から北米まで飛んでおりますが、ちょっと前（「ちょっと」てどの位かは歳がバレルのでノーコメント）までは、コックピットに５人も乗り込み、それも、マルチ編成での５人では無くて、シングル編成で５人、なんて時代でした。

航空機の性能も、太平洋をノンストップで横断できるでもなかったので、マルチプル編成なんぞ無縁でした。

パイロット２名に加え、航空機関士、航空士（ナビゲーター）、航空通信士もの大所帯で海越えしていたのでした。

猫の額の程のコックピットに野郎が５人では、さぞかし“むさ苦しい”空間だったでしょうが、そこは、クルーは一つ、言葉は不適切ですが、ある種の“運命共同体”として、ロマンを持った野郎達の熱気と緊張感が上手くバランスされて、良い雰囲気だったとも聞いています。

やがて、地上航法支援施設の進化や、航空機の航続性能の向上，自律航法装置の導入などで、航空通信士・航空士が飛行機を降り、今や、航空機関士（ＦＥ：フライト・エンジニア）も乗務していない、いわゆる２名乗務のハイテク機が主流となりました。

航空機関士が行なっていた、エンジンや航空機の各種システムのモニタとチェックは、コンピュータがとってかわり、航空機関士の前に広がっていた夥しい量の計器は、EICAS: Engine Indication and Crew Alert System ディスプレイに、クルーが必要として呼び出したとき、または、システムに何らかの異常が発生したときに表示されるのが基本となり、航空機関士が操作していたスイッチ類は、最小限に削られ、航空機関士が行なっていたモニタとそれに応じて実施するアクション（スイッチ類の操作）は、コンピュータにプログラミングされ、センサとアクチュエータが見えないところで行なわれるようになりました。

それで、昨日も今日も数多の２名運航機が、ETOPS 運航を OPERATION NORMAL で実施しているのですから、技術の進歩とは凄いものです。

総じて、パイロットの前の計器は、ＦＤ，速度計など等、頻繁に動くものが多く、それらの計器類を順次眼で追い、プラス外の景色や体感する加速度等から、航空機の初動を察知し、先を読んで機体の姿勢を修正することが求められます。その計器類や外界を順次眼で追うことを、俗に“スキャニング”といいますが、適切な“スキャニング”速度で適切な舵をあてないと、大抵はお客様がイヤイヤと首を振ることになります。“スキャニング”が遅いと、初動をタイミングよく捉えられず、舵をあてても、補正量が多くなりすぎ、今度はオーバーした量を戻すべく、また舵をあてる、と悪循環が続きます。逆に速過ぎても、必要以上に過敏に反応し無駄な舵を使うことになるので、操縦する航空機の性能・特性に合った最適な速度で“スキャニング”することが求められます。

一方、航空機関士の目の前に広がる計器類は、その殆どがダイナミックな動きをしません。ダイナミックに動き、インジケータがクリスマス・ツリーのように点灯したときは、それは非常事態です。
車で例えると、燃料計や、暖気後の水温計のように、長時間かけて僅かずつ変化するか、ある一定の近辺に留まっているかが殆どです。

このように、通常であれば動きが少ない、大きく動いたときは異常、といった性格が、コンピュータを多重化させて置き換えるには壁が比較的低かったのでしょう。コンピュータが見事に航空機関士らしく役目を担ってくれています。

ここで「らしく」と言ったのは、如何にハイテク化され多重化されたコンピュータとは言え、航空機関士という人間には敵わないからです。

誤解を防ぐために....。だからと言って、今日のハイテク機の安全性を全面的に否定するつもりはありませんし、今日の二名運航機および、その運航管理体制に安全性を損なう重大な問題があるとも思っていません。
※一方で、完璧だとは思っていないのも偽らざるところです。

「敵わない」というのは、ほんの些細な兆候を捉え、そこえの注意力にやや重みをおいてモニタを続けるとか、システムの知識を活かし、関連性のある計器をモニタしたりスイッチを操作して様子を探ったり、といった、所謂、人間ならではの機転の利いた行動を行なえる、という側面を重視した場合です。

逆に、単調な“動かぬ”計器を黙々とモニタする、といった点では、多重化されたコンピュータの方が優れている部分もあります。

が、コンピュータはプログラムされた通りの動作しかしません。これは、プログラムが単純であろうと、沢山の情報を取り込んで複雑な処理を行なう高度なプログラムでも変りありません。

「じわりじわり」の変化、とか、間欠的・不定期に発生するほんの短時間の微小なブレ、などを航空機関士は見逃しません。それも飛行中、リアルタイムでそのような事象を捉え、各種情報と複合的に判断し、適切な予防措置を講じたり、あるいは、目的地に到着したら直ぐ調べてもらえるよう、社内無線等を使い、メカニックさんと「○○が△△なので□□が疑わしいようです。念のためパーツ準備して（いざとなれば交換するつもりで）見てもらえますか」などと連絡しておけば、事前に故障の芽を摘み取ることに多いに寄与します。

昨今のハイテク機でも、以前、航空機関士の定位置だった場所（または右席後方）にメンテナンス・ターミナルがあり、飛行と飛行のインターバルに、前レグのデータを調べ、異常がないか、次のレグにリリースしても問題ないかを入念にチェックしますので、安全性という意味では担保されています。ただ、前レグのデータで仮にちょっとした異常があり、念のためパーツを交換しよう、となった場合、そこから新たなタスクがスタートするので、次のレグの出発遅延（極端な場合は機材変更）が生じる可能性が高くなります。

こう考えると、航空機関士の役割は、＋１名を超えるものがあると言えましょう。

航空機関士は、乗務している航空機のシステムに精通しています。

パイロットも座学で、限定の機種に対するシステム知識は得ていますし、SIM や LOFT では、そのシステムの知識無くしては解決できないようなトラブルが課せられ汗を流しています。

今の機械の信頼性やシステムの複雑さからすると、それで十分で、またそれ以上を求めるのは非効率的なのかもしれません。

DC-8 世代までは、パイロットも「左翼の内側のエルロンは、何番の油圧系統がこれこれこうつながっていて、ハイドロがロスすると、なにそれのワイヤでどのくらい制御可能で、それに要する力は、なにそれ」というレベルまで解っていて操縦していました。

が、747 の登場と共に、トレーニング・プログラムがそれまでのものとは一変し、ＳＢＯ：Specific Behavioral Objective とが導入され、微に入り細にわたってのシステム・構造を理解する座学や訓練が無くなりました。

それまでだったら、
脚の素材はこれこれで、直径○○で重さは△△、装着しているタイヤの径は□□で、タイヤの素材は××にプライアーが何層で云々、
と習っていたものが、
この機種の脚は、タイヤの適正空気圧は○○ PSI で、時速△△ノットまで耐えられ、最大着陸重量の□□倍で××Ｇの接地まで耐えられる。タイヤ温度が○○°でヒューズが飛びフラット・タイヤとなる。云々
という内容を覚えましょう、と....。

大規模・複雑化・多重化されたシステムを全て覚えるのは事実上不可能ですし、それよりは、通常の運航と異常時の対処に注力して、それに関連することに限定して覚えましょう。複雑なシステムは、メカニックさんやメーカのエンジニアが知っているので、『餅は餅屋』と言うことで、との発想です。

『餅は餅屋』で、航空機関士の領分だったところが、コンピュータに置き換わり、航空機関士の呼びかけは、EICAS Message として表示されるだけになってしまいました。

航空機を製造する側も運航する側も、この状況を手放しで喜んでいる訳ではありません。

双方に、より効率的で安全にも寄与する＋αが必要と認識しており、（不適切な表現ですみません）ついに航空機関士もどきを乗務させる動きが出てきました。

乗務するのはＡＨＭくんです。AHM: Airplane Health Management, Boeing 社での呼び名です。

ＡＨＭくん、飛行中、リアルタイムで乗務機でモニタしている生のデータ（主たる情報源は、CMC: Central Maintenance Computer や ACMS: Airplane Condition Monitoring System ）を地上に送信、メカニックさんに調子を伝えます。

ＡＨＭくんには某陰具というウルトラ出来る影武者が居て、メカニックさんは実は、ＡＨＭくんと直接ではなくて某陰具がかかえるホスト・コンピュータを介して機体の様子を知ることになるのです。


この影武者、某陰具、ボスが製造した機体のことなら隅から隅までご存知で、さらには、故障個所のデータベースや「こういうデータがでているときはどこそこが故障している、故障間近である可能性大」といった knowledge base も備えている兵。
「○○時に到着予定の××便は到着後どこそこの個所をメンテナンスしなければなりませんよ」という情報を飛行中の生のデータからはじきだし、メカニックさんに教えてくれます。

メカニックさんは、「それならば、これこれのパーツを準備して（実は某陰具は、メンテに必要なパーツリストはもとより、手順書も準備してしまう）スタンバイしておこう」とか、「これは、短いインターバルでは無理だから、機材変更として、次の□□便はスポット△△に JA ○○○ をトーイングして、××便はスポット●●●に変更」などと、事前に手当てができるのです。

ＡＨＭにより、航空機関士が上空からカンバニーでメカニックさんと話し合うのと同様のことは１００％では無いにせよ、実現できるようになりました。

が、乗務してはいるものの、PF または PIC の「じゃぁ、どこどこの様子見てきてもらえますか」とかには対応できないので、航空機関士と等価になり得ないことは言うまでもありません。


Copyright © 2007 The Boeing Company