前回は、同じ戦闘空間に属する複数の機能を個別に、独立した形で開発・実装するのではなく、ひとつの統合化されたシステムとして開発・実装する話について説明した。その例として、航空機用の電子戦システムを取り上げた。

今回は、こうした「ひとつの統合化されたシステム」を実現するために何が必要か、という話を取り上げてみたい。→連載「軍事とIT」のこれまでの回はこちらを参照。

全体最適には何が必要か？

「ひとつの統合化されたシステム」を実現しようとしたときに、ある種の部分最適化で「機能ごとに最高のモノを作って並べる」という考え方で進めても、おそらくはうまくいかない。当初から全体を俯瞰する形で、全体最適を考えなければならない。

すると、最初に「このシステムで実現したいことは何か」という全体コンセプトを明確に固める必要がある。その上で、個々の構成要素について、何を受け持たせるか、そこで実現すべき能力や具体的な数字として現れる仕様はどうするか、といったことを固めていく流れとなろう。

構成要素をつなぐインタフェース

その過程で、個々の構成要素の間を取り持つインタフェースをどうするか、という話も出てくる。

これは本連載の第266回で書いた話とも被るが、物理的インタフェース、電気的インタフェース、データ・フォーマットなどの上位インタフェースをどうするか、という意味になる。

こうした話を最初にきっちり策定しなければならないが、そこで重要なのは「将来のための拡張性・発展性も考慮する」「インタフェース仕様を、必要に応じて開示する」といったあたり。だから、「うちはアーキテクチャ設計の専門チームを置いています」というメーカーも現れる。

こうした配慮は、後日の新機能追加や既存機能の更新を容易にする。それだけでなく、特定のメーカーに依存しない、オープンな改良計画をも可能にする。米国防総省は、開発中のウェポン・システムについてオープン・アーキテクチャ化を求めるのが一般的だが、それは将来の更新や能力拡張まで視野に入れているためだ。

そうした土台を構築した上で、実際にさまざまなサブシステムを組み合わせてひとつのシステムをまとめ上げたり、複数のシステムを組み合わせてSystem of Systemsを実現したりするのがシステム・インテグレーション作業。その後の試験も骨が折れる部分となろう。

ソフトウェアをつなぐインタフェース

ソフトウェアについても事情は変わらない。ひとつのソフトウェアは複数の機能別モジュールに分けて開発・導入するのが一般的だから、そのソフトウェア・モジュール間のインタフェースをどうするかが問題になる。

また、異なるシステムを組み合わせて、ひとつの統合化したシステムを構成することになれば、そのシステムとシステムの境界でも、ソフトウェア同士のインタフェースに関する話は必然的に出てくる。

もしも、逆の順番、つまり個々の機能をスタート点とするボトムアップ型で物事を運ぶと、どうなるか。個別の構成要素を組み合わせてみた段階で凸凹(物理的な話ではなくて比喩としての)が発生して、それを均すために余計な手間をかけることになる。それでは時間も経費も余分にかかってしまう。

デジタル・エンジニアリングの活用

そうなると、実際にモノを試作しては試してみるプロセスを繰り返す方法では、時間も経費もかかってしまう。そこはデジタル・エンジニアリングをおおいに活用したいところではないだろうか。

例えば、最初に策定した全体像に基づいて、個別の構成要素をモデリングして、デジタル・ツインを作成する。それを、最初は単独で、次は組み合わせた状態でコンピュータ上で実際に動かしてみて、どういう問題が起きるかを把握する。それに基づいて手直しを行ったら、また同じようにテストする。

複数のシステムを組み合わせて「統合化されたシステム」を作ることになれば、そのシステム同士の相互作用が問題になる可能性が高い。それを早い段階であぶり出して、つぶしておきたい。すると、MBSE(Model-Based System Engineering)も不可欠のツールとなる。

そして、ある程度まで仕上がったと判断できたところで現物を作り、フィールド試験に持ち込む。最後は現物を使って試験を行わなければならないが、早い段階でのリスク低減なら、モデリングやシミュレーションを活用する意味は大きい。

それだけでなく、実戦の場における機能・動作・有用性についても、モデリングやコンピュータ・シミュレーションを駆使して検証する。つまり「こういう戦闘場面で、このシステムはどこまで任務達成に寄与できるか」を検証するわけだ。こうなると、ミッション・エンジニアリングの領域に入ってくる。

こうでもしないと、複雑化・大規模化したSystem of Systemsを、なるべく迅速・確実・低コストで実現することは不可能ではないだろうか。

  • 米Lockheed Martinはさまざまなシステムの開発にMBSEを利用している　引用：Lockheed Martin

プラットフォームとのインタフェース

このほか、SWaP-C(Size, Weight, Power, and Cost)の問題もある。

プラットフォーム側の機器設置スペースは限られているから、もちろん小型軽量化は欠かせない。また、既存製品の置き換えを行う場合には、既存製品と同じフォームファクタにまとめる工夫も求められる。

F/A-18E/Fスーパーホーネット用のAN/APG-79レーダーをF/A-18Cに搭載しようとしたら、レドームのサイズが違うせいで収まってくれず、アンテナ・アレイを小型化した派生型を作ることになった事例もある。

もちろん、プラットフォーム側の電源供給能力も有限だから、低消費電力化できるのであれば、それに越したことはない。

著者プロフィール

井上孝司


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