前回は、今年5月に壱岐空港を拠点として飛行試験を実施した、ゼネラル・アトミックス・エアロノーティカル・システムズ(GA-ASI)社の無人機(UAV : Unmanned Aerial Vehicle)、ガーディアンが搭載するセンサー機材と、それらを連携させる事例について紹介した。今回はその続きである。

データ量が増えると処理が追いつかない

壱岐空港における取材では、実際にガーディアンが壱岐島の周囲を周回飛行して、レーダーや電子光学センサーを作動させた。そして、洋上を航行している船舶をレーダーで探知した結果や、それに対して電子光学センサーを指向して得られた映像が報道陣に披露された。

そして何にビックリしたかと言えば、洋上を航行している船舶(ひょっとすると軍艦も含まれているかもしれないので、艦船というほうがいいかもしれない)の数の多さだった。小さな漁船から大きな貨物船まで、多種多様な船が洋上を行き来している。

SeaVueレーダーは同時に5000個の探知目標を扱えるというが、それは決して過剰性能ではないのだな、と実感できた。

さて。大量の探知目標を扱えるということは、探知データの量も膨大になるということである。洋上にいる大量の艦船について、何時間も捕捉・追尾していれば、結構なデータ量になる。

さらに、レーダー探知にひもづける形で船舶自動識別システム(AIS : Automated Identification System)のデータや電子光学センサーの映像を加えれば、さらにデータ量が増える。すると、「データの山に埋もれてしまって、分析が追いつかない」という問題が発生するのだ。

SeaVueレーダーで連続的に追跡すれば、個々の探知目標がどこから来てどこに向かっているかを個別に把握できる。一般的な航路から外れた妙な動きをする探知目標は「怪しいぞ」ということになる。

しかし、「普通ではない」ことがわかるのは、何が普通なのかがわかっている場合に限られる。それがなければ、比較対象がないから、怪しいもなにもあったものではない。

なんのことはない、ビッグデータの解析という問題である。

  • ガーディアンUAVからGCSに送られてきたSeaVueレーダーの探知情報を、報道関係者がいる別棟の大画面テレビに表示した様子。背景の映り込みが少々邪魔だが、多数の探知目標がいる様子は見て取れる。表示しているエリアは玄界灘で、中央やや左上が壱岐島。四角で囲まれたブリップがガーディアンの位置

コンピュータを援用する

前回に、センサー同士の連携が役立つ例として「瀬取り」を挙げたが、これは「他の船舶がいない空いている洋上で、2隻のフネが近接する」というパターンによって識別される。さらに、その2隻のフネがどこから来て、どこに向かっているかを調べれば、怪しいかどうかを判断する材料が増える。

しかし、レーダー探知のデータを連続的に人が目で追いながら、パターンを識別したり、怪しいパターンで動く探知目標を拾い上げたりするのは大変な仕事だ。日本近海のように混雑した水域では、人手に頼る処理は非現実的である。

「うっそお」と思ったら、「MarineTraffic」で、どこか日本近隣の海域を見てみればいい。あきれるぐらい多くの船舶がいる様子がわかる。これを個別に人間の眼で追って解析しろといわれたら、やる気になるだろうか?

それではどうするかといえば、コンピュータを援用してデータ分析を受け持たせる、というところに落ち着く。実際、GA-ASI社ではそういう方向の研究開発も進めており、遠からず、世に出せるだろうということだった。

これと似たような話は別のところにもある。「通信傍受によって、真空掃除機のように情報をかき集めている」と評される米国家安全保障局(NSA : National Security Agency)だが、同時に、「大量のデータの山に埋もれている」との評もある。

それをなんとかしようとして、特定のキーワードを含む通信だけ拾い出すとかなんとか、いろいろ工夫をしているわけだが、それでも簡単な仕事ではないらしい。第一、通信を傍受されて困る側は、当然、解析を邪魔しようとして工夫をするのだから。

解析したら活用する

コンピュータを援用(当節の流行の言葉だと、「人工知能を援用」でもよい)してデータを解析することで、特定のパターン、あるいはパターンから外れた動きを拾い出せる可能性は高くなると期待できる。

しかし、まだ続きがある。何かを見つけたら、それを即座に活用できなければ意味がない。

ガーディアンみたいなUAVの場合、機体が搭載するセンサーが吐き出したデータは、管制を担当するオペレーターが詰めている、地上管制ステーション(GCS : Ground Control Station)に入ってくる。

ちなみにガーディアンの場合、操縦を担当するオペレーターとセンサーを担当するオペレーターは別々にいる。GCSには同じ作りのコンソールが2基あって、操縦担当は飛行諸元や機体前方の映像などを見ながら機体を操る。センサー担当は、センサーが送ってきたデータを画面で確認したり、センサーの向きや動作モードを指示したりする。

すると、データが送られてくるGCSに解析機能を付け加える方法が考えられる。しかし、GCSと解析用のコンピュータをデータ通信回線でつないで、解析機能を別立てにする方法も考えられる。複数のUAVを飛ばすのであれば、解析機能はGCSとは別立てにして、意思決定担当者がいる指揮所に集約する方が良いかもしれない。

いずれにしても、解析した結果に基づく報告や指令を、しかるべき組織や艦船や航空機などに、データ通信網で飛ばすことになる。それで初めて、データの収集から活用までのサイクルが完結する。

さまざまなセンサーを搭載した無人機自体が1つのSystem of Systemsだが、その無人機とGCSと解析機能と配信先(インテリジェンスの用語でいうところのカスタマー)の組み合わせも、またSystem of Systemsである。

著者プロフィール

井上孝司


鉄道・航空といった各種交通機関や軍事分野で、技術分野を中心とする著述活動を展開中のテクニカルライター。
マイクロソフト株式会社を経て1999年春に独立。『戦うコンピュータ(V)3』(潮書房光人社)のように情報通信技術を切口にする展開に加えて、さまざまな分野の記事を手掛ける。マイナビニュースに加えて『軍事研究』『丸』『Jwings』『航空ファン』『世界の艦船』『新幹線EX』などにも寄稿している。