F-35ライトニングIIのソフトウェア

過去3回に渡って、F-35ライトニングIIのさまざまな機能・能力について解説してきた。その中でも言及しているが、F-35ではソフトウェア制御の比重が高まっている。実はF-35に限らず、最近のウェポン・システムは多かれ少なかれ、似たような傾向があるが。

ということで今回は、そのF-35のソフトウェア開発に関する話を。

ウェポン・システムのソフトウェア

「コンピュータ、ソフトなければただの箱」なんてことをいうが、それはウェポン・システムの場合でも同様である。しかも、実際に開発に携わった経験がある方ならお分かりの通り、コードを書くだけでなく、それをテストするために必要な手間と時間の負担が大きい。

ソフトウェアのテストで何が大変なのかといえば、通り一遍の、設計仕様通りの使い方をする場面だけではなく、そこから外れた場面についてもテストする必要がある点だ。そして、そういうところでトンでもないバグが出ることがある。

ちなみにF-35の場合、機体そのものだけでなく、それを支援する地上側のシステムでもさまざまなソフトウェアを必要とする。その機上・地上をひっくるめたシステム全体のソフトウェアの規模が、従来の戦闘機と比べると、べらぼうに大きい(なお、地上側のシステムについては次回に取り上げる予定なので、今回は解説を割愛する)。

どれくらい大規模なのかというと、米議会の付属機関で、日本では会計検査院にあたるGAO (Government Accountability Office)という組織がまとめた報告書で、ソースコードの行数について「1,900万行」とか「2,200万行」とかいう数字が出てきているぐらいである。

絶対的な数字として見れば「なるほど巨大だ」と思うが、某社のルータ製品で使用しているソフトウェアの規模も、ソースコードの行数だけ見れば、実は似たようなものであるらしい。おっと、閑話休題。

その巨大なソフトウェアを一気にすべて作成・テストするのは負担が大きすぎるので、段階的な開発を行うようになっている。F-35の場合、まず「機体を飛ばすためのソフトウェア」を作り、次に「基本的な戦闘機能を実現するソフトウェア」を追加する。この段階では使用できる兵装の種類を限定して、空対空戦闘と、一部の空対地兵装の利用を可能にする。そして、最終版のソフトウェアで、当初に計画していた兵装や任務・すべてに対応することとしている。

だから、初期版のソフトウェアでも飛行試験はできるし、機能限定版のソフトウェアでも、対応している機能に限れば試験や訓練に供することはできる。

F-35をめぐる報道で「ブロック2がどうのこうの」とか「ブロック3がどうのこうの」という言葉が出てくるのは、基本的には、このソフトウェアのバージョンに関わる話である。ちなみに、ブロック3で最後というわけではなく、今後も継続的にソフトウェアを更新して、能力向上や兵装の追加を進めていくことになるだろう。

パソコンやスマートフォンのソフトウェアと同じで、毎年のように新しいソフトウェアがリリースされることになっても不思議はない。だから、F-35に「最終完成型」というものは存在せず、引退するまでバージョンアップが続くことになるのではないか。

どのみち、完成した機体の引き渡しを受けて、それですぐに実戦部隊を編成できるわけではない。まず、運用評価試験や要員の錬成を行わなければ、部隊建設もままならないのである。ここのところを見落として、「機体が完成すれば直ちに実戦配備可能」と思い違いをしている人が少なくないようだが。

そういう事情があるから、まずは「飛行機としての機能を実現するソフトウェア」や「基本的な任務遂行に必要なソフトウェア」を優先的に開発しているわけだ。第一、すべてのソフトウェアが完成するのを待っていたら、それだけ開発試験も運用評価試験も部隊建設も遅れてしまう。

ちなみに、この軍用機の研究・開発・試験・評価(RDT&E : Research, Development, Testing and Evaluation)については、目下「航空ファン」誌で連載している最中なので、そちらも読んでみていただけると嬉しい。

記述も大変だがテストも大変

問題は、そのソフトウェアを記述して、さらにテストする方法である。ちなみに、F-22ラプターのソフトウェアはAda言語で記述していたが、F-35のソフトウェアは驚くなかれ、C++言語で記述する。

2,000万行になんなんとするソフトウェアともなると、開発に携わる技術者の数も膨大なものになるから、最初に「ソフトウェア開発者向けのガイドライン」なる文書を配布して、可読性が高く、再利用しやすいソフトウェアを記述するように神経を使っている。

そして、そのソフトウェアをテストするのに、未完成品のソフトウェアをいきなり実機に載せてテストするのではリスクが大きい。そこで、CATBirdという専用の試験機を用意している。

この機体はボーイング737を改造して作ったもので、F-35の実機が搭載するものと同じコンピュータや各種センサーを搭載しており、特にセンサーの配置については実機と同じ位置関係になるようにしている。そうでないとテストにならない。

ただし、CATBirdの飛行そのものは、母体となったボーイング737の機能をそのまま使っているから、試験対象となるミッション・システム、あるいはそこで使用するソフトウェアに不具合が出ても、機体が墜ちることはない。これなら安心してテストできる。そして、検証と熟成が進んだ状態で、新しいソフトウェアをF-35の実機にインストールして評価試験に供するわけだ。

近年、こういう風に既存の機体を改造したテストベッドを用いて、センサーやコンピュータといったミッション・システム、あるいはそこで使用するソフトウェアの開発・試験を進める事例が増えている。

執筆者紹介

井上孝司

IT分野から鉄道・航空といった各種交通機関や軍事分野に進出して著述活動を展開中のテクニカルライター。マイクロソフト株式会社を経て1999年春に独立。「戦うコンピュータ2011」(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて「軍事研究」「丸」「Jwings」「エアワールド」「新幹線EX」などに寄稿しているほか、最新刊「現代ミリタリー・ロジスティクス入門」(潮書房光人社)がある。