自衛隊での調達が決まったF-35
自衛隊での調達が決まったF-35
[画像のクリックで拡大表示]

 先日、政府は自衛隊の次期主力戦闘機(FX)に、米国など9カ国が共同開発中の米Lockheed Martin社製「F-35 Lightning II」を選定しました。

 航空機産業は技術面で多大な波及効果があることから、FXの選定においても国内の防衛産業の基盤維持が一つの論点となっていました。ただし、今回選定が決まったF-35の場合、Eurofighter社の「Typhoon」といった他のFX候補機と比べると、国内で認められるライセンス生産の割合は低いようで、F-35調達における一つの懸念点となっているようです。

 これはこれで日本の製造業にとって非常に重要な問題なのですが、それとは別に筆者がF-35で思い浮かべたのが、「JSF++」です。

 JSFというのは、F-35のプロジェクト発足当初の名称で「Joint Strike Fighter」の略称です。さまざまな国の多様な目的を持った戦闘機を共通の後継機で置き換える目標を掲げていることから、「joint」という名称が付けられているようです(例えば、日本が調達を決めたのは通常離着陸型のA型ですが、F-35には他にも機体中央のファンで垂直離着陸が可能なB型、艦載機向けのC型もあります)。

 それでJSF++というのは、このF-35(JSF)の電子系の組み込みソフトウエア開発で使われたコーディング規約のことです。

 一般に航空機の電子制御系ソフトウエアというと、信頼性などを重視して、強い静的型付けという特性を持つ「Ada」というプログラミング言語が使われることが多いのですが、F-35の設計が始まった1990年代後半、

・Ada言語の最新ハードウエアにおけるツール・サポートが衰退し始めている
・オブジェクト指向で行った設計を、オブジェクト指向をサポートしないプログラミング言語(Ada)の上で実装したくない
・(1990年代後半のドットコム・ブームの中では)若く有望なソフトウエア技術者はAda言語にほとんど興味を示さない

といった要因があり、C++が採用されました。

 ただし、C++をセーフティ・クリティカルな航空機のソフトウエア開発に適用するというLockheed Martin社の決断に対しては、F-35の共同開発国である英国が難色を示したようで(英国は国防省でC++の信頼性についての先行研究も実施していました)、その後、C++を安全に利用するためのコーディング規約についてLockheed Martin社および米英の当局の協議、さらにはC++の言語設計者である、かのBjarne Stroustrup氏のレビューなどを経て、JSF++が策定されました(JSF++自体は、こちらで公開されています)。

自動車分野にも波及

 このJSF++は、その後、自動車などの組み込みソフトウエア向けのC++コーディング規約「MISRA C++」の基にもなりました。

 MISRAといえば、C言語版の組み込み分野向けコーディング規約「MISRA C」で有名ですが、C++向けについては航空機分野で先に策定され、それを「輸入」した形です。

 「組み込みソフトウエアの複雑さでは、航空機分野の方が自動車分野より先を行っていたということだ」と、英MIRA Ltd.でMISRAのProject Managerを務めるDavid Ward氏は、当時語っていました。

 JSF++は単なるコーディング規約ですが、それ以外にも航空機などをはじめとする防衛分野では、ソフトウエア開発の面でさまざまな先進的な手法・技術が培われています(関連記事)。UMLモデルなどから、実行可能なソース・コードを自動生成するアプローチである「モデル駆動開発(MDD:model driven development)」も、日本国内では知名度が低いのですが(関連記事)、米国の防衛産業では比較的活発に実践されているようで、F-35と同じLockheed Martin社製の戦闘機「F-16」の制御ソフトウエア開発にも使われました。

F-35のソフトウエア規模は1800万行

 このように防衛産業というとソフトウエア工学分野で先進的なイメージがあるのですが、今回、日本の自衛隊での調達が決まったF-35は、そのソフトウエア開発で大いに苦しめられています。度重なる納期遅れの大きな要因の一つが、ソフトウエア開発となっているのです。

 F-35のシステムは、反復型(インクリメンタル型)かつコンカレントな開発プロセスが採用されており、開発が開始されて以降、段階的に機能を増やす戦略を採っています。「Block 0.1」、「Block 0.5」、「Block 1.0」、「Block 2.0」、「Block 3.0」という五つの段階があり、フライト制御ソフトウエアやナビゲーションといった基本機能は最初のBlock 0.1で実装し既にリリース済み。データ・リンク機能など戦闘に必要なフル・システムはBlock 3.0で、2014年末ころにリリースという段取りです。

 F-35は既に初飛行自体は終えており、2011年には一部、米軍への納入も始まっていますが、このように一部のソフトウエアは依然、開発・検証中です。Block 1.0以降の各Blockの進捗は2006年当時の計画よりそれぞれ2年ほど遅れているそうで、現在はBlock 2.0のフェーズにあるようです。

 米国議会の政策チェック機関(日本の会計検査院のような組織)であるGAO(Government Accountability Office)によると、F-35のソフトウエア規模は全体で1800万行。このうち新規開発は1160万行で、同じステルス型戦闘機として有名な「F-22A」と比べても4倍の規模だそうです。コード規模はPDR(Preliminary Design Review)の段階からは40%増え、その後のCDR(Critical Design Review)の段階からも13%増えたとか。

 航空機といえば、2011年11月に就航した米Boeing社の旅客機「787 Dreamliner」も、度重なるソフトウエア開発・検証の遅延が一つの要因となり、ローンチカスタマーである全日空への納入が3年以上も遅れました。

 ソフトウエア規模の拡大が進む日本の組み込みソフトウエアの開発現場でも、航空機分野の事例から学ぶべきことは多そうです。

 なお、航空機分野のソフトウエア開発の仕組みを今、注視すべき理由は実はもう一つあるのですが、その解説はまた別の機会に…。