ミッション・エンジニアリングとMBSE(2)迅速開発にどう役立っているのか

前回は、防衛分野における「新しい装備やオペレーションと、それへの対抗手段によるいたちごっこ」の話を取り上げた。そこでいかにして主導権を握り、プロセスを迅速に走らせるかが問題になる。

そこで、アンシス・ジャパンが6月25日に都内で開催した、防衛産業向けのDXに関するセミナーで聞き込んできた話を交えながら、続きを書いてみる。。→連載「軍事とIT」のこれまでの回はこちらを参照。

そこで、ミッション・エンジニアリングの出番

前回に書いたように「いたちごっこのペースが上がっている」状況だからこそ、「ゲームのルールを案出する」手段としてのミッション・エンジニアリング、あるいはそこで使用する装備の研究開発を支えるデジタル・エンジニアリングが重要になる。それをいいたいがために、長々と前置きを展開してきた。

単に高性能・高機能のハードウェアを持つだけではなく、それをどう活用して勝利条件につなげるかも考えなければならない。

「日本もドローンをもっと配備するべきだ」「最強のドローン部隊を編成しよう」ではない。まず、「無人モノをどう活用して勝利条件を引き出すか」という理念を確立する必要がある。それを実現するツールが、ミッション・エンジニアリングである。

米海軍がOCDSSを実証実験

この原稿を書こうとしていた矢先に、米海軍のWebサイトに面白い記事が載った。米海軍航空戦センター航空部門(NAWC-AD : Naval Air Warfare Center Aircraft Division)が実証試験を実施した、OCDSS(Optimized Cross Domain Swarm Sensing)というソフトウェアの話である。このOCDSSは何をしてくれるのか。

• 

  メリーランド州パタクセントリバー海軍航空基地のウェストベイスンマリーナで、行われたOCDSSのデモンストレーションの様子　写真：US Navy

OCDSSは海上での任務目標を達成するために、無人ヴィークル、センサー、配置の最適な組み合わせを決定する場面で使用する。コンピュータ・シミュレーションを何千回も走らせて、任務遂行における各種無人ヴィークルの連係動作を予測する。それにより、任務を達成するために最適な数・タイプ・配置を決定するプロセスを支援する。

まさに現場レベルのミッション・エンジニアリングといえるのではないか。もちろん、こうした現場レベルの話だけでなく、もっと上位のレイヤーでも同様に、シミュレーションを通じた「投入する資産のタイプ、数、配置の最適解追求」という話は出てくる。

人間の頭であれこれ考えるだけでなく、シミュレーションをどんどん走らせて、仮想の試行錯誤をたくさんやる。それにより、迅速に最適なオペレーションを立案して、実行する。そのプロセスを敵対勢力に先んじて走らせることで主導権を握る。敵対勢力が対抗手段を繰り出してきたときにも、それにどう対処するかをシミュレーションの繰り返しによって追求する。

ただしその前提として、「達成すべき勝利条件」「達成すべき任務」を明確にしておかなければならないのは当然の話である。行き着くべきところが分かっていないのに、道案内なんてできない。

デジタル・エンジニアリングを駆使する迅速開発

装備品の研究開発にも同じことがいえる。例えば、ノースロップ・グラマンが開発を進めているB-21レイダー爆撃機。これは前回にも少し言及した。

計画名称LRS-B(Long Range Strike Bomber)の下でプログラムが走り始めて、担当がノースロップ・グラマンに決まったのは2015年。ところが、初号機が完成してロールアウトしたのは、わずか7年後の2022年12月。

では、同じノースロップ・グラマンがATB(Advanced Technology Bomber)計画の下で開発したB-2はどうか。プロトタイプ機・6機の予算を計上して発注したのは1982年のことで(それはプロトタイプ機のシリアルナンバーが「AF82-xxxx」となっていることで確認できる)、初号機のロールアウトはそれから6年後の1988年。

もちろん、プロトタイプ機の予算計上より前から研究開発のプロセスは走っていたわけで、計画が端緒についたのは1978年の話。それから初号機ロールアウトまで10年をかけた。

より高度化・複雑化していて当然といえる新型機の方が迅速に開発できた背景には、デジタル・エンジニアリングの活用があるとされる。いちいち現物を試作する代わりにモデリングとシミュレーションを駆使して、試行錯誤のプロセスを迅速化したことが効いたといえよう。

また、ベル・テクストロンが米陸軍のFLRAA (Future Long Range Assault Aircraft)計画向けに開発しているティルトローター機・MV-75では、実機のプロトタイプより先にヴァーチャル・プロトタイプを2セット納入して、早期の設計改善や、ソフトウェアの開発・インテグレーション・試験に活用するとしている。

• 

  ベル・テクストロンが今年6月に披露したFLRAA　写真：ベル・テクストロン

ちなみにアンシスのセミナーでは、このB-21やMV-75、そしてボーイング/サーブの新練習機T-7レッドホークなどを“digital age”の装備品の例として挙げていた。

デジタル・エンジニアリングが生きるのは、開発過程での試行錯誤や試験だけではない。最終的に確定したデータは、そのまま製造に活用できる。デジタル・データとして持っているものだから、積層造形を活用する場面でも役に立つだろう。

また、何か実機の製作や飛行試験、実運用において不具合が発生したときに、原因究明や対策の過程で、コンピュータ上で現象を再現する使い方もできる。

生きる場面と生きない場面

もっとも、デジタル・エンジニアリングが生きる場面もあれば、そうでない場面もある。

同じようにデジタル・エンジニアリングを駆使して開発を進めている製品でも、ノースロップ・グラマンのLGM-35AセンティネルICBM(Intercontinental Ballistic Missile)では、スケジュール遅延やコスト超過の問題が指摘されている。

センティネルICBMで、どの程度の影響があったのかは分からないが。一般論として(ここ重要)、例えば「COVID-19のパンデミックによる影響」とか「サプライチェーンの混乱」とかいう話が出てくれば、これはもうデジタル・エンジニアリングでは直接的には対処のしようがない。遅延の影響を緩和する努力においては、デジタル・エンジニアリングの出番はあるが。

だから、運用構想・作戦構想を立てる場面におけるミッション・エンジニアリングにしても、あるいは研究開発・試験・評価におけるデジタル・エンジニアリングにしても、「それを一振りするだけで問題が雲散霧消する魔法の杖」みたいなあおり方をするのはよくない。

過去に、「デジタル・エンジニアリングを駆使すれば、○○カ月ごとに新しい戦闘機を送り出せる!」と吹かした人がいたが、こういうあおり屋さんが出てくると、かえってイノベーションの足を引っ張ってしまう。もっと地に足のついた取り組みを進めなければならない。