システムの統合化(13)水上戦闘艦の “Plug and Play” 化(2)

前回は、「水上戦闘艦の分野で多用途区画を設置する事例が出てきている。そこに戦闘システムと関わるモジュールを追加すると、艦側のシステムと連接して統合化したシステムを構成する必要が生じる」という話を書いた。

今回は、それを具現化するために何が必要か、ということを考えてみる。特定の艦やクラスを念頭に置いた話ではなく、一般論として、「こんな仕掛けが必要ではないかなー」という話である。→連載「軍事とIT」のこれまでの回はこちらを参照。

モジュールの参加・退出を認識する

まず、艦内ネットワークに新たなモジュールを参加させたり、あるいは取り下ろしのためにモジュールを退出させたりしたときに、そのことを直ちに知る仕掛け。

一つの考え方として、モジュールをネットワークに接続したときにブロードキャストする方法が考えられる。ネットワークにつながっている他のノードがちゃんと聞き耳を立てていれば、この方法により、新たなモジュールが参加したことを把握できよう。

ところが、ブロードキャストだけでは退出の告知ができない。「参加のブロードキャスト」と「退出のブロードキャスト」を別個に用意する手も考えられるが、後者をどのタイミングでどうやって出すんだ、という問題はあり得る。それに、取り外しに限ったことではなく、戦闘被害による機能喪失を把握する必要もある。

すると、誰かがネットワーク上の各ノードに対して定期的にロール・コール(呼び出し)をかけて、存在していること、機能していることを確認する手はあり得よう。もっとも、これはこれで、個々のノードの機能不全とネットワーク自体の機能不全をどうやって区別するんだ、という話になりそうだが。

• 

  沿海域戦闘艦(LCS : Littoral Combat Ship)みたいにミッション・パッケージを交換式にするには、どのパッケージが接続されているかを知る仕組みとともに、データや指令をやりとりするためのインタフェース、そしてアーキテクチャの設計が重要になる 出典 : 米国防総省

サブシステムの管制と、データ記述の標準化

もちろん、艦側の指揮管制装置やネットワークについて、統一的なインタフェース仕様やデータ・フォーマットを策定する必要がある。

例えば、位置情報を記述するためのデータ・フォーマットを定めて、艦側の指揮管制システムも、艦の固有兵装も、必要に応じて搭載するサブシステムも、みんなそれを使う。

対象は、空中の探知目標だったり、水上の探知目標だったり、水中の探知目標だったり、海底に敷設された機雷だったりするだろう。とはいえ、いずれも何らかの位置情報を持つのは同じだ。それなら、緯度・経度・高度・深度といったデータと、対象物を区別する識別子を規定すれば、記述型式を標準化できそうではある。

もちろん、ネットワークに接続するための物理的・電気的なインタフェース仕様を統一する必要があるが、その上位の各レイヤーについても事情は同じ。重複のないアドレッシングを行うだけでなく、対象物の種類や利用可能な機能を把握するためのプロパティ情報が要るはずだ。昨今、軍用ネットワークもTCP/IPの利用が一般化しているので、レイヤー3・レイヤー4については、あまり難しいことにはならないと思われる。

「多用途」であれば、多用途区画に据え付けるモジュールにはいろいろな種類、いろいろな用途があるはずだ。すると、それを制御するためのソフトウェアも、用途に合わせたものが必要になる。そのソフトウェアは、どこに持たせるのが正解だろうか。

艦側の指揮管制装置に持たせておく手も考えられるが、それでは用がないソフトウェアまで抱え込むことになりかねない。接続するモジュールが新型化したときに、それに合わせてソフトウェアを更新する手間もかかる。第一、将来的にどんなモジュールを接続することになるか、最初から予見して、すべて遺漏なく準備しておくのは無理がある。

すると、個々のモジュールを管制するためのソフトウェアや管制機能は、モジュールの側に持たせるべきであろう。それを、API(Application Programming Interface)を叩くようなイメージで指揮管制装置の側から呼び出して制御できれば、統合化したシステムを構築する土台ができそうではある。

データ融合に必要なもの

戦闘システムを統合化するのであれば、状況認識の部分も統合化する必要がある。つまり、センサー融合を行い、あらゆる友軍、あらゆる脅威の情報を単一の状況図にまとめたい。それができてこその「統合化された戦闘システム」である。

例えば、レーダーが何かを探知したとする。レーダーの探知情報は自艦を基準とする「方位」「距離」といった相対的なデータとして得られるが、そのままではセンサー融合ができない。

しかし、戦闘システムのネットワークに測位システムがつながっていれば、そこから艦位の情報を得られる。するとレーダーの管制システムは、艦の位置を基準として方位と距離の情報を加味することで、探知目標の絶対位置を計算できる理屈となる。

他のセンサーについても同じように処理する。すると、各種センサーの探知情報がすべて緯度・経度・高度・深度といった絶対値として得られるから、それを指揮管制装置に集約・融合する。これにより、単一状況図を生成できる。一つの画面に、航空機も水上艦も潜水艦も機雷も、みんな出てくる。

もし、分野別のサブシステムがそれぞれ離れ小島になっていたら、探知情報は別々の画面に出ることになるから、単一状況図にならない。

機能分担とアーキテクチャ設計

その単一状況図に基づいて、指揮管制装置のソフトウェアが脅威評価や意思決定支援を行い、何を使って何と交戦するかを決める、あるいはリコメンドする。そんな話になろうか。

ただし、艦側の指揮管制システムが受け持つのは、「意思決定」「交戦を担当するサブシステムの割り当て」「交戦に必要なデータ(目標の位置・針路・速力など)の引き渡し」まで。そこから先の交戦プロセスは、個々のサブシステムに委ねるのが良いと思える。

そうしないと、異なるさまざまなサブシステムごとに、交戦のための指揮機能を艦側の指揮管制装置が持っておかなければならない。それでは機能の分業化が曖昧になる。それよりも、必要な情報を与えた上で「これをやれ」と命じる方が理に適う。

ここまで書いてきた話から、「どの機能をどこに置いて、どういう形で役割分担させるか」というアーキテクチャ設計が、とても重要なのだと分かる。最初にそこでしくじると、後々まで禍根を残すことになる。