ボーイング737MAX　失敗の本質

はじめに

　筆者の現時点での関心事は737MAXについてのFAAがソフトウェアの改修だけで飛行再開を許すのかどうかという点だ。FAAが正常に機能しているのであれば、現状では冗長化されているとは言えないMCAS (Maneuvering Characteristics Augmentation System) の仰角検出手段をあるべき姿にするにはハードウエアの改修は避けられず、当然その方向の指示が出されるものと筆者は考えているからである。

737MAXに関する疑問点
　ボーイング社の737MAX型旅客機（以下737MAXと呼ぶ）の生産が停止されるとの報道がある。半年前には同機の飛行再開は2019年秋には実現されると言われていたが、未だに見通しが不透明である。
　筆者は2019年春に737MAXに関する疑問点をここへの半年前の投稿にあげた。この投稿はニュースで得られた情報によるものだが、半年間の経過を見るとこれらの疑問点は概ね当たっていたのではないかと思う。

　あらためてこれらの疑問点の要約を再掲すると
疑問１：ソフトウェアによる操縦特性の仮想化
疑問２：安易な「禁じ手発動」－ソフトウェアによるパイロット操作の
　　　オーバーライドは許されるのか
疑問３：センサーの信頼性確保方法
疑問４：バードストライクは「想定外」か？
疑問５：あるべき設計方針から乖離していないか？
疑問６：想定した飛行環境は十分と言えるか　
疑問７：トータル・システム・デザインにおける
　　　「ソフトウエアの位置づけの変化」への対応が不十分ではないか？

　当初、ボーイングは737MAXの問題点に関してそれほど深刻に受け止めていなかったように見える。おそらく、疑問２のソフトウェアによるパイロット操作のオーバーライドを取りやめパイロットが主体的に操縦できるようにソフトを改修し、それに伴うシミュレーターの改修、パイロットの再教育等の処置を行うことで問題は解決でき、早期の飛行再開が可能であると捉えていたのではないかと推察される。

高可用システムのあるべき姿

　それが、ここへ来て生産停止という事態に至らざるを得なくなったのはなぜだろうか。「高可用システムとはどうあるべきか」という観点から見た場合のシステムエンジニアリング的観点から見たとき、FAAが重視しているのは、上記の疑問点の中でも特に「疑問3」に相当する点、すなわちMCASに使用されている仰角センサーシステムの出力の信頼性に関する点だと考えるのが自然ではないかと筆者は捉えている。
　「疑問3」が、なぜ機体の生産停止に繋がるかという点であるが、この問題への対処はMCASのソフト改修で済むものではなく、何らかの形でのハードウェア的な改造あるいは追加工事が避けられない点で他の疑問と性質が異なるからである。
　現在の仰角センサーは機首の両側に2個存在するが、それでは2個あるからと言って冗長構成と言えるかと言うとそうではない。なぜならどちらか片方が故障して2個の測定値が異なっても、どちらが正しいか判断のしようがないからである。高可用性システムであるためには、第3の仰角測定装置を用意して多数決論理を取るなど、故障個所を特定できる手段が必要であるし、「疑問4」に対応するためにはバードストライク・フリーなセンサーを具備する必要があるかもしれない。いずれにしても、ソフトウェアでの対処だけでは実現不可能である。生産停止の背景にはこのような対策が不可欠かどうかの議論に結論が出ていないことがあるのではないかと推測するが、あくまで個人的な推測となる。
　しかも、過去に同様な冗長化が軍用機では採用されていたとする記事もあり、冗長化の要求条件は従来から認識されていたものであり、高可用システムとしてはむしろ当然の要求である。これを見ると、より信頼性を要求されるはずの旅客機でこの仕組みが省略されてしまった点については、ボーイングは道を踏み外したと言ってよいだろうと筆者は思う。いずれにしても現状があるべき姿になっていないことだけは確かである。

ソフトウェア制御に伴うリスク

　このようにシステムの信頼性への要求条件から見ると欠陥システムが製品化されてしまったように見えるのだが、それはなぜだろうか。必ずしもボーイングが単に経済性等の理由から恣意的に信頼性を軽視したのが理由なだけではない（もちろんそれが大きいだろうとは思うが）のではない可能性もあると筆者は考えている。
　要求条件を満足する方法としてMCASを採用した場合には、ソフトウェアやセンサーに制御をゆだねることになる。しかし、そのことにより生起するリスクの存在について開発責任者が正しく理解していなかった可能性も検討するべきである。この問題は737MAX だけの問題ではなく、5GやIoT、自動車の自律運転等、これからの時代の高機能・高可用性・リアルタイムの組込みソフトを使用するシステムに共通の課題となる可能性が高い。

　さて、このような製品がボーイングのデザインレビューを通ってしまったという点も理解し難いし、さらにそれがFAAに承認されてしまったという点も不可解だと感じる。このような事が起きた背景に関しては、私は「以下のような事が起こっているのではないか」と言う仮説を持っている。それは『高可用性システムに使用される組込みソフトの検証の必要性に関する認識不足』とでもいうべきものである。おそらく5Gの普及に伴う2020年代のビジネスではこの問題がさらにクローズアップされてくるのではないかと考えている。

複雑化・高度化する組込みシステムと開発リスク

　この事件の背景には「組込みソフトによる制御」の信頼性に対するハードウェア・エンジニアの過剰な期待（あるいは認識不足）があるのではないかという点がまずある。これまで組込みソフトはハードの一部として扱われてきた。家電製品のように組込みソフトが単純で、検証がしやすく、簡単な機能を果たすものであるうちはそれでも良かった。しかし、MCASのように機体の安全性に本質的な影響を及ぼす組込みソフトにおいてはそれでは済まなくなる。これを「疑問7」としている。
　第1に組込みソフト自体が複雑化し、単体での検証が難しくなる。
　第2に組込みソフトがハードウェアに組み込まれた状態でのハードとソフト（場合によってはヒューマン・インターフェースを含めて）のインターフェースの確認は、さらに難しい課題となる。
　第3にこのような組込みソフトはシステム全体の制御を司るので、ハードとソフトを組み合わせたシステム全体でのデザインレビューと総合試験を十分に行うことが必要になる。ここでは「システム全体をハード・ソフトを含めて一段上の観点から見ることが出来る」人材の確保が重要な課題となる。
　第4に、この試験はどこまでのテストをすれば十分かという点は非常に判断が難しいものとなる。
　第5に運用中にソフトウェア、ハードウェアに障害が発生した場合、それをどのように検出し、どう対処するかが設計に組み込まれている必要があり、これに関連する機能の検証も併せて必要となる。

35年前に指摘されていたリスクの再評価の必要性

　このような組込みソフトの課題は最近になって顕在化したものではない。1980年代にはSDI（戦略防衛構想）の開発が企画されたときにダヴィッド・L・パルナス博士のその小論 ”SOFTWARE ASPECTS OF STRATEGIC DEFENSE SYSTEMS” において、SDIのソフトウェアがなぜ開発不可能なのかについて懇切丁寧に指摘されている。その要点をこちらにまとめたので参照されたい。
　SDIほど検証が難しい「組込みソフト」がその後は開発されようとしなかったためか、現在のソフトウェア万能の時代においては、いつの間にか忘れられていた指摘となってしまったように思われるが、ここに指摘されている事実は極めて重く、あらためて考えなおす必要があるように思われる。
　組込みソフトはソフト単体の検証では不十分だという点、ハードとソフトの総合検証は境界条件・環境条件が再現できる項目は検証可能だが、そうでない項目は検証不能である点をボーイングの開発統括責任者が理解していなかったこと、これら点に関する認識不足が問題の本質ではないかと筆者は推測する。
　今後の推移を見守りたい。