ソフトウェアの観点から見た将来戦闘機(2)センサー/データ融合

今回から何回かに分けて、「戦闘機に求められる能力(capability)を実現するために、ソフトウェアがどんな仕事をしなければならないか」という話を取り上げてみる。

なにも戦闘機に限らず、情報システムのアーキテクチャやソフトウェアの設計では、やはり「求められる能力をいかにして実現するか」を具現化しているのではないだろうか。

センサー融合とソフトウェア(点の場合)

筆者は「センサー融合」(sensor fusion)を、「同じプラットフォームが装備する複数のセンサーから得た探知情報を、別々の場面でバラバラに表示するのではなく、1つの画面に統合して提示する機能」と定義している。

戦闘機の場合、自ら能動的に捜索する手段としてのレーダーと、受動的に捜索する手段としてのレーダー警報受信機(RWR : Radar Warning Receiver)またはESM(Electronic Support Measures)がある。

レーダーの探知情報は、画面上にブリップ(輝点)の形で現れる。数値データとしては、「方位、距離、俯仰角」である。一方、RWRやESMはパッシブ式のセンサーで、距離はわからないから、得られるのは方位線だけである。センサーの配置によって、平面的な方位(俯仰角が分からない)になる場合と、立体的な方位(俯仰角も分かる)になる場合がある。

• 

  レーダーの探知情報は、自身を中心とする相対的な情報(方位と距離)として得られる。自己位置の情報を加味しないと、探知目標の絶対的な位置情報は得られない

いずれにせよも、自機からの相対的な向きに基づくところは共通だから、レーダーの探知情報と、RWR/ESMの探知情報を融合する処理は、まだしも易しい部類と思われる。「レーダーが55度の方向・100ノーティカルマイル(185.2km)の距離で探知した目標」と、「ESMが55度の方向で探知したレーダー電波発信源」は、同一目標とみなせそう……ではない。同じ方位に複数の「誰かさん」がいるかもしれないからだ。

だから、RWRやESMは単に「電波が来ています」だけでなく、その電波の発信源を識別する仕掛けを持たなければならない。例えばの話、戦闘機搭載レーダーの電波だと識別できれば、それを地対空ミサイル・システムの捜索レーダーとゴッチャにする危険性は避けられる。センサー融合を行うソフトウェアは、そういう判断まで求められる。単に数字だけ見て、重ねてしまえば一丁上がり、ではすまない。

センサー融合とソフトウェア(映像の場合)

その他のセンサーとして、映像を得る手段となる電子光学センサーと赤外線センサーがある。F-35が装備する全周視界装置・EO-DAS(Electro-Optical Distributed Aperture System)も、この仲間となる。

「映像なら、融合の対象にはならないのでは?」と思いそうになるが、さにあらず。映像情報にレーダーやESMの情報を融合する使い方は考えられる。例えば、EO-DASの映像にレーダーやESMの情報を重畳すれば、「パイロットが見ている方向に存在する探知目標のシンボルを、映像に重ねて出す」なんてことが可能になる。

映像だと「なにかの飛行機」あるいは「点」にしか見えなくても、それが出しているレーダー電波の情報を手がかりにして機種まで把握できればありがたい。敵機の機種がわかれば、対処方法を考える際の役に立つ。

EO-DASの場合、パイロットの頭の向きに合わせて、適切な映像を生成してリアルタイム表示しなければならない。ということは、頭の向きをセンシングするところも、映像を生成して表示するところも、迅速かつ精確な処理が求められる。処理が遅ければ仕事にならない。

900km/hで飛んでいる飛行機は、1秒間に250m移動する。ということは、処理が1秒遅れれば、位置情報が250mずれたセコハンの情報になってしまう。実際にどこまでの誤差が許容されるかは、現場の人間ではないから判断いたしかねるけれども、ズレが少ない方がいいに決まっている、というぐらいのことは分かる。

データ融合とソフトウェア

次は「データ融合」(data fusion)だ。筆者はこちらを、「自前だけでなく、他のプラットフォームが装備するセンサーから得た探知情報も含めて、別々の場面でバラバラに表示するのではなく、ひとつの画面に統合して提示する機能」と定義している。

• 

  多種多様なセンサーから得た情報を、単一の画面にまとめて分かりやすく表示するのは不可欠の能力。これはボーイングが10年ほど前に日本でデモした、F/A-18用先進コックピットのデモンストレータ

当然、こちらのほうが難易度が高い。先に書いたように、レーダーにしろRWRにしろESMにしろ、得られる情報は相対的なものだ。つまり、自身を基準点とする方位や距離である。その情報を単純に列挙しても、融合はできない。

データ融合を行うには、探知を行うプラットフォームの絶対的な位置を割り出す必要がある。すると、そこを起点として方位線を所定の距離まで引くことで、探知目標の位置も幾何学的に計算できる理屈。その辺の考え方はRWRやESMも同じだが、先に書いたように、これらは方位しかわからない点が異なる。

では、融合処理を行うために、プラットフォーム相互間で交換するデータはどうするか。以下の2種類の方法が考えられる。

• 個々のプラットフォームの位置と、それぞれのプラットフォームが探知した目標の方位と距離をやりとりする
• 個々のプラットフォームで探知目標の位置まで計算してから、それをやりとりする

前者では、データを送り出すプロセスは迅速になるが、やりとりするデータ量が増えるし、受け取った側で融合処理を行う前に計算する仕事が増える。後者では、データを送り出すプロセスには余分な時間がかかるが、受け取った側は位置情報を重畳すれば済むから、融合処理は速くなる。

たぶん、やりとりするデータ量が少ないほうがありがたいので、個⼈的には後者(割り出した位置情報をやりとりする)を推す。ネットワークにかかる負担が減るメリットもあるからだ。実際のデータ融合の現場でどう処理しているかは不明だが、おそらく、同じ考え方ではないだろうか。

戦闘機に限らず、他の航空機でも艦艇でも、航法のために高精度の測位システムを備えているものだから、自身の緯度・経度・高度は常にわかる。それなら、その情報を使って探知目標の絶対位置まで割り出してしまうほうが話が楽だ。

と、こういった思考プロセスは、ネットワークを介してデータをやりとりする情報システムの開発では、たいてい直面している話ではないだろうか。