自然災害時に活躍する偵察機に注目(7)日本も導入・グローバルホーク

アメリカ空軍では、RQ-4グローバルホークという大きな無人偵察機を運用している。日本と韓国も導入を決めているのだが、今回のお題は、そのグローバルホークだ。

ブロック30とブロック40

グローバルホークは、大きく分けると4種類のモデルがある。最初に登場したブロック10、機体を大型化したブロック20。ここまでがRQ-4Aである。続いて登場したブロック30、現時点では最後のモデルとなっているブロック40。ここまでがRQ-4Bである。

そして、日本で導入するのはブロック30である。と聞いて「アメリカから古いモデルを売りつけられたのかー!」と吹き上がる人がいそうだが、ちょっと待ってほしい。

確かに、ブロック30よりもブロック40の方が後から登場したモデルだが、この両者、「同一機能で新旧の違いがある」というものではないのだ。そのことは、搭載しているセンサー機器の陣容を見れば容易に理解できる。

まず、RQ-4B(ブロック30) のセンサー一式はEISS(Enhanced Integrated Sensor Suite, 強化型統合センサー群)といい、以下の陣容である。

• EO/IR(Electro-Optical/Infrared, 電子光学/赤外線)センサー
• 合成開口レーダー (SAR : Synthetic Aperture Radar)
• ASIP(Airborne Signals Intelligence Payload, 航空機搭載型信号情報収集)

ASIPは、SIGINT (Signal Intelligence, 信号情報) 収集用の機材で、後部胴体下面にいくつも生えているL字型のアンテナがそれだ。

• RQ-4Bグローバルホーク(ブロック30)。主翼に邪魔されて見えにくいが、後部胴体下面にL字型のSIGINT用アンテナが林立している

一方、RQ-4B(ブロック40)はE-8C戦場監視機と同様に対地監視に特化した機体で、AN/ZPY-2 MP-RTIP(Multi Platform-Radar Technology Insertion Program, マルチプラットフォーム・レーダー技術更新計画)と呼ばれるSARを搭載する。

• RQ-4Bグローバルホーク(ブロック40)。胴体下面のアンテナ・フェアリングが目立つ。これがAN/ZPY-2

ついでに書くと、ブロック10とブロック20ではSARとEO/IRセンサーだけを備えていた。

得られるデータが違う

要するに、ブロック30は可視光線映像、赤外線映像、SARによるレーダー映像と、3種類の映像情報を得ることができる。SARは過去にも書いてきているように、解像度の面で見劣りする一方で、昼夜・天候を問わずに使える利点がある。

これを書くために確認してみたところ、ブロック30のSARはGMTI(Ground Moving Target Indicator, 地上移動目標識別)の機能も備えていた。だから、単に静的なレーダー映像を得るだけでなく、移動中の車両を追跡することもできそうだ。ただし「餅は餅屋」だから、それをやるなら最初からその目的で作られているブロック40のほうが優れているだろう。

さらに、SIGINT収集の能力があるのはブロック30だけである。春にオーストラリアで撮ってきたブロック40の写真を確認してみたが、ASIP用のアンテナは見当たらない。

つまり、ブロック30とブロック40では搭載するセンサー機器が違い、得られる情報の種類も違う。新旧の違いというわけではないのである。要は、自分がこの機体を使って収集したい、と考えているデータに見合ったセンサーを搭載しているほうを選択すればいいのだ。

有人偵察機にも似たような話はある。RQ-4で置き換えるはずがなかなか置き換えられない、U-2がそれ。センサー機器を必要に応じて着脱･交換できる構造になっているので、同じU-2でも機体によってセンサー機器が違うことがある。

作る立場からすると

グローバルホークに限らずUAVの多くがそうだが、センサー機器は機体と一体のものではなく、ユーザーの求めに応じて変更したり、更新したりするのが通例。機体は単なるセンサーの運び屋であって、主役はセンサー機器のほうなのだから。

すると、機器が物理的に収まるかどうかというスペースの問題、外部に張り出した機器による空力的な影響という問題もさることながら、もっと面倒な問題が出てくる。

つまり、電源供給、冷却、センサー機器からデータを取り出すためのインターフェイスという問題がついて回る。しかもインタフェースについては、物理的、電気的、論理的と3レベルある。センサーを替える度にインタフェース仕様が異なるのでは、搭載に際しての手間がかかりすぎる。

すると、多様なセンサーに対応できるようにするためのインタフェース仕様や、機上コンピュータ・システムのアーキテクチャを、最初にうまいこと設計しておく必要がある。現時点で必要な機能・能力だけでなく、将来の発展や新機能追加まで視野に入れておかなければならない。

これは逆に、センサー機器を開発・製作する側にも言えること。センサー側の都合だけ考えた結果として突飛な形状になってしまったり、独自仕様のインタフェースやプロトコルを使ったりすれば、機体側とのすりあわせで無駄な手間と時間と費用がかかってしまう。

PCの周辺機器では、物理的・電気的・論理的インタフェースの統一が当たり前になっているが、武器、とりわけセンサー・コンピュータ・通信といった分野も、事情は同じ。独りよがりな製品作りをすれば、結果として販路を狭めることになってしまう。