過去2回にわたり、「多目的区画にさまざまなモジュールを搭載できる水上戦闘艦において、統合化した戦闘システムを構築するには」という観点から、いろいろ書いてきた。そこで今回は、統合化したシステムを構築する際の勘所について考えてみたい。艦艇の話が「つかみ」ではあるが、他の分野にも適用できる話かもしれない。→連載「軍事とIT」のこれまでの回はこちらを参照

個別の機能を、どう組み合わせて活用するかが問題

前回にレーダー探知を例にとって、戦闘システムを構成するサブシステムと、航海系の構成要素である航法システムの情報を連携させる話を紹介した。他の分野でも、似たような話はあるのだろうか。

例えば、対機雷戦(MCM : Mine Countermeasures)の場合。自艦が機雷原に進入して機雷探知ソナーを作動させる代わりに、無人潜水艇(UUV)を放って捜索させるのが最近のトレンドだが、そのUUVがとってきた情報をどう活用するか。

  • 海上自衛隊の掃海艦「ひらど」掃海艦艇が任務を遂行する際には、精確な航法と、海底地形に関する情報が不可欠 撮影:井上孝司

海底に敷設された沈低機雷を見つけたら、その位置を記録・表示する。それから掃討に移るが、その過程では海底地形の情報が不可欠だ。すると、測位システムだけでなく電子海図の情報が必要になる。それなら、電子海図のシステムもネットワークにつないでおいて、必要に応じて特定海域の海図データを取り出せるようにする。すると、海底地形と機雷探知データの重畳が可能になる。

海図や海底地形のデータは、両用戦を行う場面でも役に立つ。上陸予定海浜の地形や水深、潮汐に関するデータがなければ、上陸作戦の計画を立てられない。

つまり、電子海図や測位の機能は、航海系でも武器系でも使う可能性があると考えられる理屈。それなら、戦闘用と航海用で同じ機能を別個に持つのは不経済だから、武器系と航海系を同じシステムにまとめて、武器系の側から航海系に属する機能も呼び出せるようにしておくのが良いのかもしれない。

と、ここまで書いたところで「どこかで聞いたような話だな?」と気付いた。第501回で取り上げたことがある、米駆逐艦ズムウォルト級のTSCE(Total Ship Computing Environment)である。TSCEでは戦闘システムだけでなく、航法や機関といった艦制御系も包含して単一のコンピュータ・システムを構築している。

  • ズムウォルト級のTSCEでは、航海系も武器系も統合して単一システムにまとめている 引用:US Navy

MBSEの積極的な活用が必要ではないか?

といった具合にいろいろ考えていくと。戦闘システムをモジュール化、かつ “Plug and Play” 化する場合、「機能をどう切り分けるか」「切り分けた機能同士をどう連携させるか」という、いわばアーキテクチャ作りが重要になる……という話は以前にもちょっと書いた。そこで設計ミスをすると、最後まで失敗が尾を引くことになる。

「それはなにも、“Plug and Play” 化する場合に限ったことではなく、搭載する装備の内容を最初に固定してしまう戦闘艦でも同じ」との意見もあるだろう。それはそうだが、“Plug and Play” 化するとシステム構成が動的に変動するところが違う。

システム構成が動的に変動する場合、後になって問題が露見する可能性が考えられる。それを、現物ができてからテストしたり評価したりするのでは、開発に時間がかかるし、不具合が露見したときの手戻りも大きくなってしまう。何か、もっとうまい解決策はないものか。

となったところでハタと思いついたのが、第556回でも触れた、モデルベースのシステム工学(MBSE : Model-Based System Engineering)だった。

MBSEを活用すると、どんなメリットが?

MBSEでは最初に、これから構築しようとしているシステム(System of Systemsも含む)に対する要件を明確化する。それを、システム→エレメント→コンポーネントといった具合に、細かい構成要素に分解して、必要となるハードウェア・コンポーネントやソフトウェア・コンポーネントを設計・実装していく。

その過程でトレード・スタディを実施して、最適な分割モデルを作る。また、個々のコンポーネント・エレメント・システムの振る舞いが、他のコンポーネント・エレメント・システムにどう影響するかも明確にする。

その後、個々の構成要素をコンポーネント→エレメント→システムという順番で統合・検証していく。そして最終的に、当初の要求を満足できるシステムを作る。

このプロセスを、「統合化された艦載戦闘システム」の開発に適用する。それだけでなく、新たなモジュールを加える場合の検討や設計にも活用する。モジュールの追加対象となる、既存の「統合化された艦載戦闘システム」に関するモデルができていれば、そこに新たな構成要素が加わる場面の検討を迅速にできないだろうか。

多数の構成要素からなり、それらが相互に関わり合い、影響し合う場面では、「モノを作ってからテストする」ではトラブルが出たときの手戻りが大きい。事前の検討をどれだけ進めておけるかが重要ではないだろうか。

著者プロフィール

井上孝司


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