2019年06月12日

事例:ボーイング737MAXの墜落事故


初めての方はこちらを「はじめに

ボーイング737MAXの墜落事故について詳細な内容が書かれた記事があったので、今回はこれを事例にして話をしてみたいと思います。なお目的は事故自身についての考察などではなく、具体的なものを通して今までの記事についての理解を深めてもらう事です。

事故の内容は以下の様なものです。
ボーイング「737MAX8」、初の事故-乗客・乗員189人絶望的 - Bloomberg
エチオピア航空のボーイング737MAXが墜落-157人全員死亡 - Bloomberg
この事故に関しては既にソフトウェアに問題がある事が判明していて、その修正も終わっているようです。

詳細な内容が書かれた記事は以下になります。
ボーイング737 MAXに搭載されたシステムの経緯と問題点 - GIGAZINE
以降この内容に従って進めたいと思います。

事故の原因


上記の記事によると、事故は、簡単に言えば操縦を自動的に補正するMCASというシステムに問題があって墜落したという事のようです。その原因は概ね以下のようです。
1.燃費向上のためエンジンを大型化
2.エンジンが地面に近くなり過ぎるので中心位置を上へずらす
3.機首が上がりやすくなり失速しやすくなる
4.プログラムで自動補正(MCAS)
 A.二つある仰角センサーの一つしか見ていない
 B.パイロット(手動)より優先度が高い
5.MCASの事がパイロットに周知されていない

この中で、まず4Aが直接的な問題で、一つしか見ていないのでそのセンサーが故障した時にMCASの動きがおかしくなる可能性があります。水平飛行の状態でも機種を下に向ける補正を行いかねません。その場合パイロットは修正しようとするはずですが、ここで4Bの問題が効いて修正できません。MCASを切れればいいのでしょうけれども、5の為にそもそもパイロットは何が起きているかも分かりません。その結果墜落に至ってしまったと考えられます。

車のパワーステアリング(パワステ)に例えるならば、エンジンを変えたらカーブでタイヤが曲がり過ぎるようになったので、パワステのシステムを少しいじって補正するようにしたような感じでしょうか。

原因の作り込み理由


なぜそのような原因を作りこんでしまったのかを推測してみます。

まずは「4.プログラムで自動補正(MCAS)」についてです。
そもそも1~3のような状況ならば機体の修正をするのがスジに思えますが、そうしないでプログラムで対処しようとしたのは機体の修正(設計変更)になれば莫大なパワー、コスト、日程がかかるからというのが容易に想像つきます。
皆さんも経験があるのではないでしょうか?
問題点の対応をする時に本当は設計変更しなければならないけれども、それだと影響が大き過ぎてパワーがかかり過ぎてしまうので、とりあえず対処療法で逃げるような事が…

次に「4A.二つある仰角センサーの一つしか見ていない」についてです。
これは内部事情が分からないと流石になんとも分かりませんが、起きている事だけを見ると「事例:天文衛星「ひとみ」の事故」で触れた「言われた通りに作る問題」(要件は誰が固めるべきなのか)の現象と似ています。ただ、訴訟などはないようなので単純にプロジェクトが分断されていて全体を見渡せる風通しの良さが無かっただけかもしれません。

次に「4B.パイロット(手動)より優先度が高い」についてです。
これは自動における非常に本質的な問題です。
自動については「「自動」は簡単ではない」で詳しく書きましたが、手動ありきの自動ではない事ほど恐ろしいことはありません。この記事内でも車の自動運転を例に以下の様に指摘しました。
人間が運転する機能がサポートされないのだとしたらそれは無謀と言っても良い位にハードルが高い事に思えます。
飛行機にしろ船にしろ自動運転は既に実現されていますが手動で運転できないなどという事は聞いた事がありません。
残念ながら今回の事故はまさしく「聞いた事がない」「手動で運転できない」状態にしてしまったと言えます。
「手動ありきの自動」というのは設計思想とも言えるようなものですが、この様な哲学や思想などのようなものは伝承が非常に難しいものです。パワステの例えの様に既にシステムで制御しているならば、追加で補正処理を入れる事にはあまり抵抗感は無いかもしれません。

最後に「5.MCASの事がパイロットに周知されていない」についてです。
補正を自動で暗示的に行ったのと併せて考えると、どうもこの補正の事を表には出したくなかったのではないかという印象を受けます。もしそうならば、こっそりやる事で今までと変わらない、互換性(操作性)が維持されている、とアピールしたかったのかもしれません。
これも日常的に経験する事ですね。ユーザーは操作性が変わる事に敏感ですから、システム商品などではバージョンアップやリプレースではいかに使い勝手が変わらないか、導入のハードルが低いかなどをアピールしたりしますね。

仕様を考えてみた場合


仮に自分の考えに基づくとどの様な仕様になるのかを考えてみたいと思います。
まず、先程も述べたように自動は手動ありきが大原則です。
手動の機能があって自動は単にそれを楽にするものというのが基本的な位置付けです。こういう原則で考えると最悪の場合でも手動という逃げ手があるという安心感があります。実際にこのような原則に基づいて仕様を組み立てたおかげで助けられたことは何回もあります。

では実際に検討してみます。
最初に手動の場合の仕様を考えます。普通に考えたら以下の二つくらいでしょうか。
・失速の危険が感知できたら警告を出す
・失速する操作にはガードをかける
おそらくこの様な機能は搭載されているのではないでしょうか。

では次に自動の仕様はどうなるでしょう。
多分、手動の場合に操作感として思いのほか機種が上がり過ぎて使いづらいということでしょうから、スムーズな操作感となるように機首の角度に従って徐々に補正をかけるという事ではないかと思われます。もしかしたらこれはMCASそのものなのかもしれません。

それではボーイングの仕様と同じなのかと言うとそうではありません。
そもそも初期状態が違います。デフォルトは手動です。自動補正の機能を使いたい場合にはパイロットが自ら指定する必要があります。そして自動補正の機能が働いている間はパイロットに分かる形でステータス表示が必要です。

手動と自動では手動が基本であるという事がまさしく違うところです。それは手動の場合の操作感が今一つだとしても変わりません。
これは普段使っているソフトウェアでもよく経験する事です。自動でやってくれるのはいいのですが、知らない間に勝手に行われていたり、思惑とは違う動きをしたりする事がよくあります。例えばワープロで英単語を入力したら先頭だけ勝手に大文字になったりしますが、知らない人にとっては混乱するばかりでしょう。やはり基本的な動きは入力した文字がそのまま入力されるということだと思います。 

対応方法を考えてみた場合


それでは、もしあなたがこの機体のソフトウェアの責任者だったとして、全体責任者から「ハードウェアの方がこういう事情になったのでソフトウェアの方で上手いこと吸収してくれないか」と言われて今回のMCASの方法を提示されたとしたらどう答えますか?

私の場合ならば「手動ありき」という大原則があるので、断固として機体の設計変更を主張せざるを得ません。多分「ソフトウェアで補正して吸収しようとするのはあまりにも危険だ」と主張すると思います。
その結果、当然揉める事になります。
主張が受け入れられないのは百も承知ですが、技術者が技術に誠実で無かったら技術的な判断をする人が居なくなってしまいます。

しかし今までにない新しいものを生み出すのもまた技術者の使命です。
ですから、ひとしきり揉めた後に「機体の設計変更に比べれば安いものだ」などと主張して、大幅な予算の増額と期間の猶予を要求すると思います。
原則を守りつつ矛盾する要求を満たす方法は無いのかを検討したいからです。そしてもし解決策が見つかったなら、その新しい方法を慎重に開発したいからです。

要求が受け入れられるのか、はたまたプロジェクトから外されるのかは分かりません。しかし、もし自分自身で「これは危険だ!」と思えていたとしたら意見を変えるのは難しいでしょう。

最後に


仕様や対応方法を考えてみましたが、結果を知っているからこういう内容になった訳ではありません。自動に対する考え方から辿るとこういう形になるという帰結を示しただけです。
繰り返しになりますが、事故を起こしたシステムの正しい姿は何かを論じている訳ではありません。航空機の専門家でもありませんし、内部事情が分かる訳でもありません。あくまで具体的なものを通してこれまでの記事の内容をより分かりやすく伝えようと試みているにすぎません。

今回の事故では三百人以上の犠牲者が出てしまいました。現行の受注もキャンセル騒ぎになり、運航も停止されたままです。結果としてこういった事実を知れば、対応の内容がどれだけの重みを持っていたかは誰の目にも明らかだと思いますが、逆に言うとこれ程までの大事故に繋がる可能性を予見できていなかったら「なぜ割り込みを断れないのか」で述べたように反対を貫く事は出来ないのかもしれません。

P.S
書いている最中に以下の様な記事が上がっていました。
ボーイング737MAX、二度と運航してはならない-ネーダー氏(Bloomberg)
主張している方はかつては自動車産業を相手に戦った事もあるようで、原則論を貫き通す姿勢には勇気を貰えますね。

一覧


メニュー

関連


「自動」は簡単ではない
事例:天文衛星「ひとみ」の事故
事例:ANAシステムトラブル


記事を広める



posted by 善 at 17:01 | Comment(0) | 事例 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。