ソフトウェアの観点から見た将来戦闘機(3)CNIと搭載兵装の話

前回は、戦闘機に求められる能力(capability)のうち、状況認識(SA : Situation Awareness)に関わる、センサー融合とデータ融合機能について、ソフトウェアの観点から書いた。今回は、その他の状況認識関連機能、それと搭載兵装に関わる部分を取り上げてみる。

CNIとソフトウェア

まず、最初のお題は通信・航法・識別(CNI : Communications, Navigation and Identification)である。具体的なデバイスでいうと、口頭でのやりとりを行う無線機、データリンク機器、GPS(Global Positioning System)や慣性航法装置(INS : Inertial Navigation System)のような航法関連機器、そしてIFF(Identification Friend-or-Foe)のような敵味方識別機器である。

こうして並べてみると、なんだか関連性が薄いものを一緒くたにしているように見えるが、電波やコンピュータが関わるところは共通性がある。F-35のように、これらのサブシステムをひとまとめにして「CNIシステム」として扱っている機体もある。

• 状況認識の機能が働くためには、通信・航法・識別の機能を充実させる必要がある

まずは、無線機とデータリンク機器について。いずれも無線を用いる通信機であり、対象が音声かデータかという違いがある。しかし当節ではどちらにしても、まずデジタル化した上で変調を行い、電波にデータを載せている。デジタル化してしまえば、音声だろうが動画だろうが敵味方の位置情報だろうが、どれもビット列である。

ただ、通信には相手がいる。通信を行う双方の当事者が同じ周波数、同じ変調方式、同じ符号化方式を用いていなければ、通信が成立しない。いきなりすべてを最新鋭の戦闘機に総取り替えするわけにはいかないし、同盟国との連合作戦もあり得るから、最新鋭のプラットフォームだけでなく、古いプラットフォームと通信を行う場面も出てくる。つまり、多様な相互接続性・相互運用性が求められるということ。

また、動画のやりとりみたいに負荷が高い通信がある一方で、音声交話みたいに負荷が低い通信もある。前者に合わせた通信仕様で、あらゆる通信に対応するのではオーバースペックになるし、逆なら能力不足になる。やはり「適材適所」である。

結果として、新旧取り混ぜた複数の通信方式に対応する必要が生じる。それだけでなく、新しい技術が出てきた時に、それに対応する必要もある。そこで最近は、ソフトウェア無線機(SDR : Software Defined Radio)を使用する事例が増えている。

SDRとは、汎用性を持たせたハードウェアをソフトウェアで制御することで、さまざまな種類の通信に対応できるようにしたもの。これなら、新たな通信技術が開発された時でも、ソフトウェアの変更だけで対応できる(と、期待できる)。その代わり、ソフトウェアの開発・試験能力がモノをいう。

通信だけでなく、GPSのようなGNSS(Global Navigation Satellite System)、そしてIFFにも言えることだが、秘匿性を持たせたり、業界関係者だけが使えたりするようにする目的で、暗号化を施す場面が多いのが軍用品だ。暗号化も当節ではデジタル・データを対象とするものであり、なにがしかの暗号化アルゴリズムに、ユーザー固有の鍵情報を組み合わせて実現する。

したがって、民間だけでなく軍事分野でも、公開鍵基盤(PKI : Public Key Infrastructure)の構築が必要になる。これもまた、ソフトウェアが関わってくる領域である。PKI自体は民間とも共通するものだから、資料は豊富であり、ここで細かく述べるまでもないだろう。

なお、IFFについては本連載の第30回で解説している。

搭載兵装とソフトウェア

戦闘機が搭載兵装を使用する場合、ただ単にトリガーを引くとか、投下ボタンを押すとかいう簡単な話では済まない。誘導武器は発射や投下の前に、まず誘導のための仕掛けを正しく機能させる必要がある。

昔は誘導制御をメカニカルに、あるいはアナログ電気回路でやっていたが、今は当然ながらデジタル化してコンピュータ制御としている。すると、コンピュータが正しい誘導を行うためには、正しく機能するソフトウェアと、そこに与える正しいデータが必要になる。

例えば、GPS誘導爆弾をどこかの地上目標に投下するのであれば、目標の緯度・経度を知り、それを誘導爆弾に送り込んでやらなければならない。空対空ミサイルや空対艦ミサイルでも同様に、位置情報を送り込んでから発射するケースがある。

誘導そのものに関わる情報を発射時(または兵装搭載時)にプログラムしなければならない場合もある。例えば、セミアクティブ・レーザー誘導の空対地兵装がそれで、複数の兵装が飛び交っていても誘導が混信しないように、固有のパルス・コードを指定してやらなければならない。

• レーザー誘導兵装では混信を防ぐために、パルス・コードの指定が必要になる。これはペーブウェイ誘導爆弾の設定ダイヤル

そんなこんなの事情により、機体側のセンサーやミッション・コンピュータと、搭載兵装が「会話」できなければ、仕事にならない。「会話」するためには、兵装ステーションのところまでデータ通信用の配線を引っ張っていって、兵装につながなければならない。

もちろん、そこでは7階層モデルに基づき、下はコネクタの形状や電気的な仕様から、上はプロトコルやデータ・フォーマットまで、規格化・標準化しておかなければ、「会話」が成立しない。そうした規格の一例として、GPS誘導兵装ではおなじみのMIL-STD-1760バスがある。

口でいうほど簡単じゃないクラウド・シューティング

防衛省の「将来戦闘機ビジョン」に「クラウド・シューティング」という項目があって、「とにかく撃てば誰かが誘導してくれて当たる」といっている。

実現すれば面白いが、発射する機体と誘導する機体が別になる場面も出てくるわけだ。するとソフトウェア的な課題として、誘導を担当する機体とミサイルを、どうやってひもづけるかという問題が考えられる。

最近では、双方向データリンクを備えたミサイルが出てきているが、それらは普通、発射母機と1対1でひもづけるもの。それなら、識別情報を1つセットすれば済む。しかし、「他の誰かが誘導してくれる」となると、それでは済まない。撃った後で「誰かが」誘導を引き継いでくれるとなると、誰が引き継ぐのかがわからないから、事前に固定的なコードをセットするわけには行かないだろう。まさか正規表現で指定するわけにも行くまいし。

また、同時に複数の味方機が同じミサイルの誘導制御を取ろうとしてコンフリクトすることがないように、調停する機能もいりそうだ。しかも、戦場でのことだから、敵が妨害や乗っ取りを企ててくる可能性も考えなければならない。ニセの「誰かさん」に制御を乗っ取られないようにするにはどうすればいいか。

この一事をもってしても、実現に際してのハードルはかなり高いように思える。しかも、モノを作ったらテストしなければならない。どういう条件を設定して、どこまでテストすれば完成だといえるのか。テストケースを作るのも大変そうだ。

それに、敵機と味方機だけでなく、味方機が撃った空対空ミサイルが何発あって、それぞれがどこを飛んでいて、どこに向かっているか、という情報がなければ、適切な誘導が成り立たない。しかも動きが速い空中戦でのことだから、データ更新の頻度が低いと使い物にならない。さてどうする?