筆者は仕事の関係で、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)を導入した飛行機で、問題になったことがある話だ。

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

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

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

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

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

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

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

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

著者プロフィール

○井上孝司

鉄道・航空といった各種交通機関や軍事分野で、技術分野を中心とする著述活動を展開中のテクニカルライター。

マイクロソフト株式会社を経て1999年春に独立。『戦うコンピュータ(V)3』(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて『軍事研究』『丸』『Jwings』『航空ファン』『世界の艦船』『新幹線EX』などにも寄稿している。