今回は前回に引き続き、MBSE(Model-Based System Engineering)、すなわちモデルベースのシステム工学について書いてみる。前回は概論みたいな内容だったから、今回はもう少し具体的な話に踏み込んでみる。→連載「軍事とIT」のこれまでの回はこちらを参照

MBSEを活用する武器開発の事例

何か具体的な製品開発の事例はないものか。ということで、2023年5月にRTXを訪れた際にブリーフィングを受けた話が出てくる。

RTXのレイセオン部門(旧レイセオン・ミサイルズ&ディフェンス)が、AIM-120 AMRAAM (Advanced Medium Range Air-to-Air Missile)空対空ミサイルの改良計画や、GBU-53/Bストームブレーカー誘導爆弾の開発を進める際に、ミッション・エンジニアリングやMBSEを活用しているという話を聞いた。

  • F-22の機内兵器倉にAIM-120Dを搭載しているところ 写真:USAF

(1)兵装で達成する任務を検討

最初に行ったことは、「その兵装でどんな任務を達成するのか」を、モデリングとシミュレーションを用いて検討すること。このプロセスを通じて、任務達成のために必要だが、現時点では欠いている機能・能力を洗い出す。これはミッション・エンジニアリングの領域であり、大局を理解するために必要なプロセスである。

何が欠けているのかが分かったら、それを開発したり、既存製品を改良したりしなければならない。つまり、任務の達成を阻害する能力の穴(capability gap)を埋めるプロセスとなる。そこで、それを実現するために、どういう機能・性能を持たせればよいかという要求仕様を明確化する。

(2)要求仕様実現に必要となる構成要素の洗い出し

すると、その要求仕様を実現するために必要となる構成要素(技術、ハードウェア、ソフトウェアといったもの)を洗い出す段階に進む。

ここでは構成要素同士の関係性という話も出てくるので、これはMBSEの領域といえる。構成要素が互いにどう関わり、どう影響し合うかを明確にして、それを皆で共有する(V字モデルの左側)。

(3)システム・インテグレーション

その後は個々の構成要素の開発や試験、構成要素同士を組み合わせる、システム・インテグレーションの段階に話が進む。もちろん、その過程では、いちいち現物を試作して動かす代わりに、モデリングやシミュレーションを駆使する場面もあるだろう。(V字モデルの右側)

そして最終的に、ミサイルや誘導爆弾といった兵装の完成品に統合する。できあがった兵装は開発試験や運用評価試験にかけて、試験で判明した不具合・要改良点をフィードバック、再度の開発・統合・試験に回す。

  • F-15Eの翼下兵装パイロンに搭載したGBU-53/Bストームブレーカー。弾体の下面に折り畳み式のウィングが付いており、これを展開して滑空させる  写真:USAF

具体的にはどうなるの?

ここまでは実際に聞いてきた話だが、話が抽象的だから、もうちょっと具体的な内容にしてみよう。なお、以下で挙げる例は、RTXで聞いた話とはまったく関係ないことをお断りしておく。

例えば、「既存の空対空ミサイルを使用する想定で、航空戦のシミュレーションを走らせたところ、撃ったミサイルがなかなか当たらず、敵機の排除に困難を来した」との状況を想定する。そこで重要なのは、「なぜ当たらなかったのか」を明確にすることである。

例えば。レーダー誘導ミサイルが、敵のECM(Electronic Countermeasures)に打ち勝つことができずにだまされた、とする。それなら、レーダー誘導機構のECCM(Electronic Counter Countermeasures)能力が capability gap ということになるので、ECCMのソフトウェアを改良する、という結論になろうか。

すると、ECCMのソフトウェアと、それが関わる他のサブシステムの関係性が問題になる。ソフトウェアを書き直せば振る舞いが変わるが、それが他のハードウェアやソフトウェアにどう影響するかが問題だ。

振る舞いによる影響だけではない。書き直しによってソフトウェアが大規模化すれば、ストレージやメモリの所要にも影響があるかもしれない。プロセッサの能力が不足するかもしれない。そういう関わりもあり得る。

こうした問題を事前に把握して、皆で共有できる方が、後でビックリさせられずに済むのでありがたい。そこでMBSEですよ、というわけだ。

MBSEも、あくまで手段である

ただし、ここで「MBSEを使うこと」が目的になってしまえば、それは「手段の目的化」という脱線につながる。MBSEはあくまで、「高度で複雑な巨大システムを効率よく構築するための支援手段」。MBSEを利用するだけでベストプラクティスが手に入るわけではない。

また、巨大システムの開発では必然的に、複数のメーカー、複数の組織が関わることになる。すると、開発に携わる当事者すべてが「共通言語」を持つ必要がある。そのためには、MBSEあるいはそれを実現するためのツールが業界標準に則っていることも重要になろう。

本稿はMBSE導入の手引きというわけではなく、「こういう手法があり、実際にウェポン・システム開発の現場で用いられている」という形で入口を示すのが目的。実際に開発現場にMBSEを導入することになれば、ちゃんとしたドキュメントやソリューションが必要になるのはいうまでもない。

これは筆者が最近、しつこく書いて回っている話だが、単に「仮想敵国が使用しているものよりも高性能の武器、優れた技術、優れた技量を持つ兵士がいれば勝てる」という単純な話ではないだろう。

強力な拳を持つことは重要だが、それでどこを殴って勝利につなげるかという思想を明確にしなければならない。それに、その強力な拳(すなわち統合化されたウェポン・システム)を、いかにして迅速・確実に開発・配備・改良するかという課題もある。

拳をどう活用するかを考えるのはミッション・エンジニアリングであるし、その拳を実現するための開発はMBSEの領域ということだ。

著者プロフィール

井上孝司


鉄道・航空といった各種交通機関や軍事分野で、技術分野を中心とする著述活動を展開中のテクニカルライター。
マイクロソフト株式会社を経て1999年春に独立。『戦うコンピュータ(V)3』(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて『軍事研究』『丸』『Jwings』『航空ファン』『世界の艦船』『新幹線EX』などにも寄稿している。このほど、本連載「軍事とIT」の単行本第4弾『軍用レーダー(わかりやすい防衛テクノロジー)』が刊行された。