武器システムのRDT&EとIT(3)システム・インテグレーション(1)

日本のIT業界には、システム・インテグレーター(またはSIer)という言葉があるが、実は防衛装備品の世界でも「システム・インテグレーション」という言葉は極めてなじみ深い。そのまま日本語訳して「統合化」としている事例も目にするが、どうもピンとこないので、筆者は(忸怩たる思いをしつつも)カタカナ書きのままにしている。

システム同士を連接させる

本連載の第35回で、「システム艦」について取り上げたことがある。字面通りに軍艦の話で、搭載しているセンサー機器(レーダーなど)、兵装(ミサイルや艦載砲など)、それと指揮管制装置を連接して相互にデータや指令をやりとりできるようにした艦のことを、こう呼ぶことがある。

最も近年では「システム艦」が当たり前になってしまったので、ことさらに「システム艦」と呼んで区別する意味はなくなった。それが既定値なのだから。むしろシステム艦ではない艦のことを「システム艦ではない艦」と呼んで区別すべきかもしれない。

さて。センサー機器と兵装を連接していない艦の場合、人間が間を取り持っている。例えば、レーダーが敵機の飛来を探知すると、探知目標を示す輝点(ブリップ)がスコープに現れる。それをオペレーターが読み取って、探知目標の方位と距離、3次元レーダーならさらに高度を知る。

次に、複数ある探知目標の中から脅威度が高いものを選び出して、その探知目標の距離・方位・針路などといったデータを、砲やミサイルの射撃管制システムに入力する。すると、砲をどちらに指向するか、ミサイルが行くべき場所はどこか、といったことがわかるので、それでようやく交戦できる。

間を取り持つのは人間だから、センサー機器と兵装は独立して存在して、独立して稼働していればよろしい。しかし、人力に依存するが故の、処理能力の限界や、読み間違い・入力間違いといったリスクはついて回る。

システム艦は前述したように、センサー機器と兵装は指揮管制装置を介してつながっている。探知目標に関するデータはセンサーから直接、指揮管制装置に入り、そこで脅威度や優先順を評価した上で、武器、あるいは武器管制システムにデータを渡して交戦させる。

• 

  レーダー用コンソールの例。画面に現れた情報を人間が眼で読み取って、そのデータを手作業で入力していたら、時間がかかるのは明白

データや指令がやりとりできなければ始まらない

と書くだけなら簡単だが、実際はそうではない。パソコン同士でネットワークを構築する場合と同じで、連接してデータや指令をやりとりできるようにするには、決めなければならない話が山ほどある。ネットワークの階層モデルになぞらえて考えてみればいい。つまりこういう話である。

• 物理インタフェース ： コネクタの形状、接点やピンの配置と形状
• 電気的インタフェース ： 電圧、電流、周波数、変調方式
• 伝送プロトコル ： ノードの識別方法とアドレッシング、データ記述形式、エラー訂正など
• 上位プロトコル ： データや指令の記述形式など

こういった要件がちゃんとそろっていなければ、データも指令もやりとりできず、連接は画餅と化す。

例として、レーダーが探知目標に関するデータを指揮管制装置に入れる場面を想定する。少なくとも距離と方位、3次元レーダーならさらに高度、敵味方識別装置(IFF : Identification Friend or Foe)があれば識別に関する情報といった具合に、1つの探知目標だけで複数のデータがある。

しかも、その探知目標が単一ではなく、数十、時には数百のオーダーで発生する。そうしたデータについて、どのような形で何ビット使って、どのような順番で記述するかを決めなければならない。また、割り当てたビット数が足りなくてデータを記述できませんでした、なんてことになっても困る。

レーダーと指揮管制装置の間で、前述した各レイヤーのインタフェース仕様がそろっていて、かつ、データのやりとりに使用するプロトコルやデータの記述形式がそろって、それで初めて「レーダーから探知目標に関するデータを指揮管制装置に入れる」ことができる。

とりあえずレーダーの話を書いたが、他のセンサー機器でも事情は同じである。

逆に、指揮管制装置から艦載砲やミサイルにデータを送って交戦の指令を出す場面でも事情は同じである。艦載砲なら砲を指向する向きと発射のタイミングを指示する必要があるし、ミサイルなら行くべき場所の指示や誘導に関する設定が必要になる。

インテグレーションのお仕事

つまり、「システム艦」におけるシステム・インテグレーションとは、こうした諸条件に基づいて「システム艦を構成する個々のサブシステム」同士が「会話」をできる環境を整える作業である。さらに、実際に連接して動かしてテストして、問題なく作動することを確認するプロセスも必要になる。

これは、コンピュータ、各種の周辺機器、ネットワーク機器と通信回線、所要のソフトウェアなどを集めて、1つの情報システムを仕立てるのと似た部分がある。

カスタマーの要望に応じて、さまざまなメーカーの製品を寄せ集めて(というと言葉が悪いが)1つのシステムを構築しなければならないこともある。

例えば、オーストラリア海軍の新型フリゲートはイージス戦闘システムのうち指揮管制装置の部分だけ使い、そこに自国製のレーダーを組み合わせる計画になっている。

既存のイージス戦闘システムをまるごと持ってきてポン付けするなら、後は艤装上の問題を解決すればどうにかなるが、別のレーダーを組み合わせるとなれば話は別だ。実のところ、そのレーダーを開発する時点ですでに、他社の管制システムと連接することを前提にして、仕様を決めて設計しなければならない。

これは、その他のセンサー・システムやウェポン・システムにも共通する話。販路を広げようとすれば、当初からさまざまな他社製品と組み合わせることを前提にして設計しておく必要がある。業界用語でいうところの、オープン・アーキテクチャ化である。

そこで独りよがりの設計をして、独自プロトコル、独自アーキテクチャで固めてしまうと「オープン・アーキテクチャではない」といって、ポテンシャル・カスタマーにソッポを向かれることになる。