航空事故を技術的に考察してみる(11)ソフトウェアが関わることの難しさ

筆者は仕事の関係で、F-35の不具合に関する情報を常に追っている。そこで見られる興味深い傾向は、「ソフトウェアの修正によって対処します」「ソフトウェアの修正で解決しました」という事案が目につくこと。

コンピュータ制御が増えた故の帰結

どうしてそんなことになるかといえば、F-35にはコンピュータ制御のものが多いからだ。コンピュータ制御ということは、そのコンピュータに対して動作を指令するソフトウェアの内容次第で動作内容が変わるということだ。したがって、ソフトウェアにバグがあると制御の内容がおかしくなる。

逆に、制御の内容を改善するのにハードウェアは弄らず、ソフトウェアの修正だけで対処できるのはコンピュータ制御の利点である。ソフトウェアは不具合を生む原因になる一方で、不具合を解決する手段にもなる。

以前に記事にしたことがある、ボーイング737MAXのMCAS(Maneuvering Characteristics Augmentation System)もまた、ソフトウェアが問題になったシステムである。コンピュータが、特定の条件下で水平尾翼の取り付け角を変更して、強制的に機首下げの力を発生させることで、迎角(AoA : Angle of Attack)の増大を防ぐ。

• ボーイング737MAX　写真：米Boeing

• AoAセンサーが搭載されている場所　資料：米Boeing

• ボーイング737MAXのフライトデッキディスプレイ　資料：米Boeing

ところが、その条件設定が問題になった。複数あるAoAセンサーが常に正確なデータを送ってくるという前提になっている場合、その前提が崩れると問題になる。そうなった時に、どのような動作をするのが正しいのか。MCASで問題になったのはそこである。

AoAセンサーから送られてくる数字は絶対に信用できるのか。複数のAoAセンサーから送られてくる迎角の数字に食い違いが生じたら、どちらを信じるのか。そこで信頼してはならないものを信頼してしまい、それに基づいて強制機首下げを発動すると、事故になってしまう。

もっともこれは、コーディングの際に生じたバグというよりは、仕様策定における詰めが甘かったというほうが正しいと思う。いわゆるスペック・バグというやつではないだろうか。

ちなみに、慣性航法装置(INS : Inertial Navigation System)も多重系になっているが、これは多数決である。例えば、3台のINSがあって、そのうち1台だけ違う数字を出してきたら、残りの2台を信じるというロジックになっている。

このほか、ソフトウェアがどういう条件下でどういう動作をするかを、使用する側がちゃんと承知していないと喧嘩になる、という類の話もある。フライ・バイ・ワイヤ(FBW : Fly-by-Wire)を導入した飛行機で、問題になったことがある話だ。

テストケースを組み立てる難しさ

メカニカルな制御では、制御を司る物理的なハードウェアが存在しており、それの動きは目に見える。ところが、コンピュータ上でソフトウェアを走らせて制御すると、動きが目に見えない。しかも、ソフトウェアの開発やテストに携わった経験がある方ならおわかりかと思うが、ソフトウェアの不具合は意外なところで出る。

「仕様通りの条件値で、仕様通りの使い方をしていれば問題なく動く」ものが、「仕様から外れた条件値」あるいは「仕様から外れた使い方」になった途端にバグを出す。これだけならわかりやすいが、実際には、特定の条件が複数そろった時に、初めてバグを出すこともある。

試験において不具合をいぶり出せるかどうかは、どういうテストケースを設定するかにかかっている。あらゆる可変要素について、あらゆるパラメータの組み合わせを総当たり式に試せば、と考えるだけなら簡単だが、実際にそれをやるのは骨が折れる。中には「そういう条件の組み合わせはあり得ないので除外して良い」ということもあるかもしれない。

では、どの範囲について、どういう組み合わせで試せば「大丈夫」といえるのか。そういう問題になる。

何か特定の操作を行ったり、特定の操作を繰り返したり、特定の操作の組み合わせを行ったりした時に限って条件が満たされてしまい、致命的な不具合につながることもある。その「特定の操作」は、設計者が想定もしていなかったようなものであるかもしれない。

当たり前すぎる話ではあるが、まず「こういう事態が起きる」という想定を行わなければならない。それがなければ、当然ながらテストケースに盛り込まれることはない。起きる可能性があると想定するから、テストケースに盛り込まれるのである。これは、何かのパラメータが想定範囲を超えた値になってしまった場合にも、同様にいえることである。

かように、ソフトウェアの不具合をいぶり出すのは骨が折れる作業である。そうなると、機体や搭載システムの試験あるいは審査、あるいはアクシデントやインシデントが発生した時の調査に際しても、ハードウェア主体で動いていた時代とは違う考え方が求められるようになるのかもしれない。