JP2020190893A - 情報収集システム、情報収集方法及び情報収集プログラム - Google Patents

Abstract

【課題】通信の可否が混在する機器群からのデータの収集時間を短縮することができる。【解決手段】情報収集システムは、複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置と、前記複数の機器とを含む情報収集システムであって、前記情報収集装置は、前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定する推定部と、前記推定部が推定した前記可能性が相対的に高い前記機器を選択する選択部と、前記選択部が選択した前記機器に前記第２のデータを要求する要求部と、を有する。【選択図】図４

Description

本発明は、情報収集システム、情報収集方法及び情報収集プログラムに関する。

近年、自動車のコネクテッド化に関する取り組みの進行に伴い、車両データをセンタに収集して分析を行い、車両機能の改善やドライバへの高度な情報通知に活用する、新たなビジネスへの期待が高まっている。

一方で、主に、以下の２つの理由から収集データが膨大になることが想定されており、対処が求められている。１つ目は、コネクテッド化する車両の増大が見込まれること、もう２つ目は、車両内で扱うセンサやカメラ映像のデータ量の増大が見込まれることにある。

膨大なデータの収集の負担を軽減するための考え方に、オンデマンド型分散データ収集がある。オンデマンド型分散データ収集では、車両から全てのデータをアップロードするプローブカーとは異なり、センタが必要になるまで車載器は車両データを残しておく。車載器は、センタからの要求をトリガーとして、センタに車両データをアップロードする。これにより、不要なデータのアップロードが抑制され、車載カメラ映像をはじめとする、高密度なデータを活用するサービスを、より少ない通信量で実現可能とすることができる。

特開２００７−３１０７９０号公報 特開２０１６−１００８０３号公報 特開２０１７−０４５１２９号公報 特開２００７−０８９０２１号公報

オンデマンド型分散データ収集を実現するためには、車載器とセンタとが常時通信できるとは限らない点を考慮する必要がある。例えば、車両の駐車時は、消費電力の観点から車載器はスリープ状態に入るため、車載器は大容量データの通信を行うことはできない。

なお、上記のような問題は、車載器以外の移動体や、ＩｏＴ（Internet of Things）機器のように、複数のタイミングでデータ（センサ値等）を送信する機器についても発生しうると考えられる。

そこで、一側面では、本発明は、通信の可否が混在する機器群からのデータの収集時間を短縮することを目的とする。

一つの態様では、情報収集システムは、複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置と、前記複数の機器とを含む情報収集システムであって、前記情報収集装置は、前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定する推定部と、前記推定部が推定した前記可能性が相対的に高い前記機器を選択する選択部と、前記選択部が選択した前記機器に前記第２のデータを要求する要求部と、を有する。

一側面として、通信の可否が混在する機器群からのデータの収集時間を短縮することができる。

本発明の実施の形態における車両データ収集システムの構成例を示す図である。 本発明の実施の形態におけるデータ収集の概要を説明するための図である。 通信可能性の推定処理の概要を説明するための第１の図である。 通信可能性の推定処理の概要を説明するための第２の図である。 通信可能性の推定に用いられる第１の性質を説明するための図である。 通信可能性の推定に用いられる第２の性質を説明するための図である。 本発明の実施の形態におけるセンタサーバ１０のハードウェア構成例を示す図である。 本発明の実施の形態における車載器２０のハードウェア構成例を示す図である。 本発明の実施の形態における車両データ収集システムの機能構成例を示す図である。 メタデータの受信処理の処理手順の一例を説明するためのフローチャートである。 通信結果のステートと時間間隔の関係の一例を示す図である。 通信可能性モデルのパラメータを生成するために必要な情報の格納形式の一例を示す図である。 ＯＫモデル及びＮＧモデルの生成及び更新を説明するための図である。 簡易モデルの一例を示す図である。 データ活用サーバ３０からのデータ要求の受信に応じてセンタサーバ１０が実行する処理手順の一例を説明するためのフローチャートである。 通信可能性の推定処理の具体例を説明するための図である。 観測データ数が十分でない車両に関する通信可能性モデルの選択方法の一例を説明するための図である。 車両の分類に関する木構造の一例を示す図である。 本実施の形態の効果を説明するための図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における車両データ収集システムの構成例を示す図である。図１において、複数の車両のそれぞれに搭載された車載器２０とセンタサーバ１０とは、複数の基地局を末端とする移動体通信網等の無線通信網や、インターネット網等の有線通信網を介して通信可能である。また、センタサーバ１０とデータ活用サーバ３０とは、インターネット等を介して通信可能である。

車載器２０は、車両の状態や環境等に関するデータを記録すると共に、記録されたデータをセンタサーバ１０へ送信する機能（通信機能）を有する情報処理装置である。

センタサーバ１０は、車載器２０から送信されるデータを蓄積する１以上のコンピュータ（情報処理装置）である。

データ活用サーバ３０は、センタサーバ１０に蓄積されたデータを活用し、所定のサービスを提供する１以上のコンピュータである。例えば、特定の車両の走行データを活用した運転行動型自動車保険や、或る条件に合致する多数の車両の運転に関する情報の統計に基づく、交通情報、走行車両の異常検知などのサービスがデータ活用サーバ３０によって提供されてもよい。

図２は、本発明の実施の形態におけるデータ収集の概要を説明するための図である。本実施の形態において、各車両の車載器２０から送信されるデータは、メタデータと実データの２種類に分類される。

メタデータは、複数のタイミング（一定間隔等の周期的なタイミング、又は不定期のイベント発生時のタイミング）において、車両（車載器２０）から能動的又は自発的にアップロードされるデータである。メタデータは、当該メタデータに対応する期間（前のメタデータが送信されてから今回のメタデータの送信時までの期間）の車両内の実データに関連し、かつ実データと比較して少データ量の、車両の状況に関連する情報（例えば、位置情報、統計値、イベントフラグ）等を含むデータである。アップロードされたメタデータは、センタサーバ１０のメタデータ収集部１１によって受信され、センタサーバ１０内に蓄積される。なお、「能動的又は自発的」とは、センタサーバ１０からの要求に応じてではなく（センタサーバ１０からの要求とは無関係に）、という意味である。

データ活用サーバ３０のデータ要求部３１は、特定の車両の実データを得るために、当該特定の車両を示す条件が指定されたデータ要求をセンタサーバ１０へ送信する。センタサーバ１０の実データ収集部１２は、データ要求を受信すると、当該データ要求に指定された条件に合致する車両を、それまでに受信されたメタデータ群に基づいて特定し、当該車両から実データを収集する。実データ収集部１２は、収集された実データをデータ活用サーバ３０に送信する。図２の例では３つの車両のうち、１つの車両を実データの収集対象としているが、実際は複数の車両が実データの収集対象となり得る。実データを得たデータ活用サーバ３０は、サービスを提供するための処理を行う。

図２に示した方法によれば、全ての車両の全ての実データがセンタサーバ１０に蓄積されないため、データ活用サーバ３０でのデータ活用に至るまでのセンタサーバ１０におけるデータ容量を削減することができる。しかし、過去に蓄積したメタデータに基づいて車両を検索するため、車両の車載器２０に対する実データのリクエスト時には、当該車載器２０が、例えば、既に車両が走行を終了しているなどの要因で、通信ができない状態になり得る。

そこで、本実施の形態では、通信可能性が低い車両（車載器２０）へのリクエスト（実データの要求）を減らすことで、実データの収集に関する通信待ち時間の削減を実現する。これは、通信可能性の推定をセンタサーバ１０側で行うことで実現される。なお、通信可能性とは、通信が成功する可能性（確率）をいう。

通信可能性の推定処理は、図３に示すように、推定のための情報として車両との通信履歴（通信間隔の履歴）や通信内容を蓄積する処理と、図４に示すようにリクエスト時に通信可能性の推定値を計算し、推定値に基づいてリクエストの発行先（送信先）の車両（車載器２０）を選別する処理の大きく２つに分けられる。ここで、本実施の形態において通信可能性の推定に用いられる２つの性質について、図５及び図６を用いて説明する。

図５は、通信可能性の推定に用いられる第１の性質を説明するための図である。第１の性質は、最近の通信成功と時刻差が小さいタイミングの方が、通信可能性が高いという性質である。或る車両の車載器２０とセンタサーバ１０との間の通信が、時刻Ｔに成功した場合を考える。その後、当該車載器２０から実データを収集する場合、時間的局所性の観点からは、時刻Ｔ_１と時刻Ｔ_２では、最後（最近）の通信に成功した時刻Ｔにより近いタイミングである時刻Ｔ_１の方が、通信可能性が高いと考え得る。

図６は、通信可能性の推定に用いられる第２の性質を説明するための図である。第２の性質は、最後（最近）の通信成功からの経過時間が同じでも、観測される通信間隔の履歴により、通信可能性の意味合いが異なるという性質である。

例として、或る２台の車両があり、それぞれの車両と最後に通信が成功したタイミングが同一時刻Ｔであるとする。この場合、両車両ともリクエスト時刻と最終通信成功時刻との差は同じであり、図５に示した第１の性質に基づく考えでは通信可能性は同一であると推定される。しかし、各車両は、それぞれが受けるサービスや車載器２０の仕様により、メタデータの通信間隔が異なり得る場合があるため、過去の通信の観測を含めて考えると、別のことが言える。

具体的には、図６のリクエスト時刻において、車両Ａは過去の通信間隔の範囲内であるため、これまで通り通信可能性が高い状態であることも見込める。一方で、車両Ｂにとって、図６のリクエスト時刻は、過去の通信間隔の範囲外であり、車両Ａと同様の通信可能性の高さを持っているとは定性的に言い難い。すなわち、図６の例では、車両Ａの方が通信可能性が高いと考えるのが妥当であるといえる。

本実施の形態では、上記２つ性質に基づいて通信可能性を推定するが、これらの性質に限らず、車載器２０から送信されるメタデータに含まれる情報を解釈し、他の性質に基づいて通信可能性が推定されてもよい。例えば、ナビゲーションシステムへ入力される目的地情報に基づいて、車載器２０が目的地までの走行時間（所要時間）の推定値を算出し、センタサーバ１０は当該推定値に基づいて通信可能性の高さを推定するようにしてもよい。

続いて、センタサーバ１０等の構成について具体的に説明する。図７は、本発明の実施の形態におけるセンタサーバ１０のハードウェア構成例を示す図である。図７のセンタサーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

センタサーバ１０での処理を実現するプログラムは、記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってセンタサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、記録媒体１０１の一例としては、ＣＤ−ＲＯＭ、ＤＶＤディスク、又はＵＳＢメモリ等の可搬型の記録媒体が挙げられる。また、補助記憶装置１０２の一例としては、ＨＤＤ（Hard Disk Drive）又はフラッシュメモリ等が挙げられる。記録媒体１０１及び補助記憶装置１０２のいずれについても、コンピュータ読み取り可能な記録媒体に相当する。

図８は、本発明の実施の形態における車載器２０のハードウェア構成例を示す図である。図８の車載器２０は、ＣＰＵ２０１、補助記憶装置２０２、メモリ装置２０３、通信装置２０４、カメラ２０５、ＧＰＳ受信機２０６及び各種センサ２０７等を有する。

車載器２０での処理を実現するプログラムは、補助記憶装置２０２にインストールされる。メモリ装置２０３は、プログラムの起動指示があった場合に、補助記憶装置２０２からプログラムを読み出して格納する。ＣＰＵ２０１は、メモリ装置２０３に格納されたプログラムに従って車載器２０に係る機能を実現する。通信装置２０４は、無線通信によってネットワークに接続するための制御を行う装置である。カメラ２０５は、例えば、デジタルカメラであり、車両の周辺又は所定の方向の画像を撮像する。ＧＰＳ受信機２０６は、ＧＰＳ（Global Positioning System）衛星から送信されるＧＰＳ信号を受信して、当該ＧＰＳ信号に基づき車両の現在位置を測定する。各種センサ２０７は、例えば、ＩＭＵ（Inertial Measurement Unit）センサ等、車両の状態又は車両の環境の状況等を検出する１以上のセンサである。

図９は、本発明の実施の形態における車両データ収集システムの機能構成例を示す図である。図９において、車載器２０は、メタデータ送信部２１、リクエスト受信部２２及び実データ送信部２３等を有する。これら各部は、車載器２０にインストールされた１以上のプログラムが、ＣＰＵ２０１に実行させる処理により実現される。

メタデータ送信部２１は、定期的、又は所定のイベント（事象）の発生時等の複数のタイミングを契機として、車両のメタデータをセンタサーバ１０へ能動的又は自発的に送信する。リクエスト受信部２２は、実データの送信要求をセンタサーバ１０から受信する。実データ送信部２３は、実データの送信要求に応じ、実データをセンタサーバ１０へ送信する。

センタサーバ１０は、メタデータ収集部１１及び実データ収集部１２を有する。これら各部は、センタサーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。センタサーバ１０は、また、車両検索ＤＢ１３及び通信可能性モデルＤＢ１４を利用する。これら各データベース（記憶部）は、例えば、補助記憶装置１０２、又はセンタサーバ１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

メタデータ収集部１１は、メタデータ受信部１１１及び通信可能性モデル更新部１１２を含む。メタデータ受信部１１１は、車載器２０から送信されるメタデータを受信し、当該メタデータを車両検索ＤＢ１３へ登録（記憶）する。なお、車両検索ＤＢ１３には、メタデータの履歴が記憶される。通信可能性モデル更新部１１２は、メタデータの受信時や、実データの送信要求の送信時等、車載器２０との通信の試行時において、メタデータの送信元の車両又は実データの送信要求の送信先の車両の通信可能性モデルを生成（又は更新）する。生成された通信可能性モデルは、車両ＩＤに関連付けられて通信可能性モデルＤＢ１４に記憶される。すなわち、通信可能性モデルは、車両ごとに生成される。

実データ収集部１２は、データ要求受信部１２１、通信可能性推定部１２２、リクエスト生成部１２３、リクエスト送信部１２４、実データ受信部１２５、収集終了判定部１２６及び要求データ送信部１２７等を含む。

データ要求受信部１２１は、データ活用サーバ３０から送信されるデータ要求を受信し、当該データ要求に指定された条件に合致する車両を車両検索ＤＢ１３に記憶されているメタデータ群に基づいて特定する。通信可能性推定部１２２は、データ要求受信部１２１によって特定された各車両の車載器２０の現時点での通信可能性を、それぞれの車両に関して通信可能性モデルＤＢ１４に記憶されている通信可能性モデルに基づいて推定（計算）する。リクエスト生成部１２３は、通信可能性推定部１２２によって推定された通信可能性に基づいて、実データの送信要求の送信先とする車両を選択（選別）し、当該車両の車載器２０に対するリクエスト（実データの送信要求）を生成する。リクエスト送信部１２４は、リクエスト生成部１２３によって生成されたリクエストを送信する。実データ受信部１２５は、当該リクエストの送信先の車載器２０から返信される実データを受信する。収集終了判定部１２６は、実データの受信状況（収集状況）が収集の終了条件を満たしたか否かを判定する。要求データ送信部１２７は、終了条件が満たされるまでに実データ受信部１２５によって受信された実データをデータ活用サーバ３０へ送信する。

データ活用サーバ３０は、データ要求部３１及び要求データ受信部３２を有する。これら各部は、データ活用サーバ３０にインストールされた１以上のプログラムが、データ活用サーバ３０のＣＰＵに実行させる処理により実現される。

データ要求部３１は、データ要求をセンタサーバ１０へ送信する。要求データ受信部３２は、データ要求に応じて収集された実データをセンタサーバ１０から受信する。

以下、センタサーバ１０が実行する処理手順について説明する。図１０は、メタデータの受信処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ１０１において、メタデータ受信部１１１は、いずれかの車両の車載器２０のメタデータ送信部２１から送信されたメタデータを受信すると、当該メタデータを車両検索ＤＢ１３に追加する。車両検索ＤＢ１３は、車両ＩＤや、メタデータに含まれるセンサ値やイベント情報を検索できる形式でメタデータを保存すればよい。

続いて、通信可能性モデル更新部１１２は、受信されたメタデータの送信元の車両に関する通信可能性モデルの更新処理を実行する（Ｓ１０２）。続いて、通信可能性モデル更新部１１２は、更新後の通信可能性モデルを、当該車両の車両ＩＤに関連付けて通信可能性モデルＤＢ１４に書き込む（Ｓ１０３）。

続いて、ステップＳ１０２における通信可能性モデルの更新処理の詳細について説明する。図５及び図６において説明した通り、本実施の形態では通信間隔の計測を基本として通信可能性モデルを生成又は更新するが、実際には車載器２０との通信成功だけではなく、車載器２０との通信確立の失敗に関する情報を得ることもできる。なお、センタサーバ１０が観測（検知）できる通信の失敗は、センタサーバ１０から接続試行した場合（すなわち、実データの送信要求の際）の通信失敗となる。車載器２０が通信圏外からセンタサーバ１０に通信試行した際の失敗については、センタサーバ１０は観測（検知）できない。

車載器２０とセンタサーバ１０の間で発生する通信の結果を示すステートは、成功（ＯＫ）と失敗（ＮＧ）の２種となる。このＯＫ及びＮＧは、時間的局所性の観点から、ＯＫ又はＮＧの直近直後時間におけるセンタサーバ１０と車載器２０との通信可能性を表していると考えられる。ＯＫであった時刻の直近直後は高い確率でＯＫであり、また、ＮＧであった時刻の直近直後は高い確率でＮＧであると考えられる。

通信結果のステートが直近直後の通信可能性を示すものであると考えると、通信結果そのものだけでなく、メタデータを構成する情報（データ要素）のうち、当該メタデータの受信以後の通信の成否を推定できるデータ要素も、以後の通信可能性の推定のための情報とすることができる。

例えば、通信に成功した車載器２０から受信したメタデータの中に、駐車のためにスリープする旨のイグニッションオフ（ＩＧＮＯＦＦ）情報等、車載器２０が通信を終了することを示唆する情報が含まれている場合、車両が走行を始めるために再びイグニッションオンにならない限り、センタサーバ１０は当該車両の車載器２０との通信の成功は見込めない。このイグニッションオフ情報をＩＧＮＯＦＦのｔｒｕｅ又はｆａｌｓｅで表し、メタデータの受信時の通信結果のステート（ＯＫ／ＮＧ）の区別に判断に含めることとする。なお、ｔｒｕｅは、ＩＧＮＯＦＦ情報を含むメタデータが受信されたことを示す。ｆａｌｓｅは、ＩＧＮＯＦＦ情報を含まないメタデータが受信されたことを示す。

すなわち、メタデータの受信時の通信結果のステートは、当該メタデータの受信の成功自体だけを示すものではなく、当該メタデータの受信以後の通信の成功の可能性を示すものである。具体的には、ＩＧＮＯＦＦがｔｒｕｅであるメタデータ（ＩＧＮＯＦＦ情報を含むメタデータ）が受信された場合、通信結果のステートはＮＧとなり、ＩＧＮＯＦＦがｆａｌｓｅであるメタデータ（ＩＧＮＯＦＦ情報を含まないメタデータ）が受信された場合、通信結果のステートはＯＫとなる。

なお、オンデマンド通信（センタサーバ１０から車載器２０への実データの送信要求に応じて実行される通信）については、通信の成否がそのまま通信結果のステート（ＯＫ又はＮＧ）となる。すなわち、当該データ要求の送信に成功した場合、通信結果のステートＯＫであり、当該データ要求の送信に失敗した場合、通信結果のステートはＮＧである。上記より、ＯＫの観測例は、ＩＧＮＯＦＦがｆａｌｓｅであるメタデータが受信されたこと、又はオンデマンド通信の成功がある。ＮＧの観測例は、オンデマンド通信失敗と、ＩＧＮＯＦＦがｔｒｕｅであるメタデータが受信されたことである。

通信が試行された２つの時刻の差分で表される時間間隔は、図１１に示すように、当該時間間隔の開始時の通信結果のステート（ＯＫ又はＮＧ）と、当該時間間隔の終了時の通信結果のステート（ＯＫ又はＮＧ）との組み合わせ（２×２＝４）で４種となる。

本実施の形態では、図１１に示した通信結果のステートや各ステートの時間間隔が車両ごとに観測され、通信可能性モデルを表現するパラメータが車両ごとに更新される。パラメータを生成するために必要な情報は、図１２に示すように、通信可能性モデルＤＢ１４にキー・バリューの形式で格納する。キーは車両（車載器２０）を一意に示す車両ＩＤである。バリュー（値）は、当該車両に関する観測情報と、当該観測情報に基づく通信可能性モデルパラメータである。図１２の例では、最終通信時刻、最終通信結果、時間間隔バッファが、観測情報に含まれる例が示されている。

最終通信時刻は、センタサーバ１０が車両（車載器２０）との通信を試行した最後の時刻である。最終通信結果は、最終通信時刻における通信結果のステート（ＯＫ又はＮＧ）である。時間間隔バッファは、４種（ＯＫ→ＯＫ、ＯＫ→ＮＧ、ＮＧ→ＮＧ、ＮＧ→ＯＫ）の時間間隔ごとに当該時間間隔の長さ（時間長）の履歴を複数のＦＩＦＯ形式で記憶するバッファである。なお、各時間間隔バッファのバッファサイズは、原理的には１でも実施可能であるが、時間間隔の観測ノイズの抑制のために、２以上であるのが望ましい。また、各種の時間間隔バッファのサイズは相互に異なっていても良いが、車両間では統一されるのが望ましい。当該バッファサイズは、車両データ収集システムで扱われる全車両の全体的な時間間隔のバラつきや各ステートの出現比率を考慮し、事前に定めておけばよい。

図１０のステップＳ１０１において、メタデータ受信部１１１は、受信されたメタデータに係る車両ＩＤに対応するバリューに含まれる、最終通信時刻と現在時刻との差分（以下、「対象通信間隔」という。）を計算した後に、最終通信時刻を現在時刻によって上書きする。また、メタデータ受信部１１１は、受信したメタデータの通信結果のステートと、最終通信結果と対応する時間間隔バッファに対して対象時間間隔を追加した後に、最終通信結果を受信したメタデータの通信結果のステートによって上書きする。更に、メタデータ受信部１１１は、更新後の時間間隔バッファに基づいて、通信可能性モデルパラメータを生成（又は更新）する。

ここで、通信可能性モデルパラメータの生成又は更新について説明する。まず、観測できた内容（４種の時間間隔バッファ）と、更新される通信可能性モデルの内容の関係を説明する。前述したように、本実施の形態では時間的局所性の観点から通信可能性が推定される。このため、最終通信結果（最終通信時刻の通信結果のステート）がＯＫである場合の以後の時間経過に対するモデルと、ＮＧである場合の以後の時間経過に関する２つのモデルが生成される。以下、前者を「ＯＫモデル」といい、後者を「ＮＧモデル」という。

図１３は、ＯＫモデル及びＮＧモデルの生成及び更新を説明するための図である。まず、ＯＫモデルの生成及び更新について説明する。ＯＫモデルは、ＯＫ→ＯＫとＯＫ→ＮＧの２種類の時間間隔を使い、時間の経過に応じて通信可能性が減衰するモデルとして生成される。ＯＫモデルは２つの線形減衰に分類される。最初の線形減衰（時刻Ｔ_１までの線形減衰）は、ＯＫ→ＯＫの観測区間における減衰である。当該観測区間は、図６の通信間隔範囲内を示すものであり、すなわち通信可能性の低下が強く推定できない時間区間を表す。

通信可能性モデル更新部１１２は、ＯＫ→ＯＫの時間間隔バッファの各値（時間長）を、以下の式（１）に代入して時刻Ｔ_１を算出する。

但し、Ｎ_ｏｏは算出に用いたＯＫ→ＯＫ時間間隔のサンプル数、Ｄ_ｏｏは各時間間隔（ＯＫ→ＯＫの時間間隔バッファの各値）である。式（１）は、ＯＫ→ＯＫ時間間隔バッファの値の平均がＴ_１とされることを示す。但し、一般的な観測ノイズを除外する方法としての外れ値を除いた平均や、より直近の時間間隔に重みを付けた平均値などを用いてＴ_１が算出されてもよい。通信可能性モデル更新部１１２は、０からＴ_１までの通信可能性推定値Ｓ_Ｏｋを、以下の式（２）を用いて算出する。

但し、ａ_１は事前に定めておく緩やかな減衰を示す負の傾きであり、ＯＫ→ＯＫの観測であっても、時間経過に伴い多少生じ得る減衰を示す。また、Ｓ_０は、通信可能性推定値の尺度（最大値）として予め設定される値である。

次に、通信可能性モデル更新部１１２は、Ｔ_１以後の経過時間領域としての減衰を、ＯＫ→ＮＧの時間間隔のバッファの各値を用いて表す。０からＴ_１までの範囲と同様に、通信可能性モデル更新部１１２は、ＯＫ→ＮＧの時間間隔のバッファの各値を、以下の式（３）に代入して時刻Ｔ_２を算出する。

但し、Ｎ_ｏｎは算出に用いたＯＫ→ＮＧ時間間隔のサンプル数、Ｄ_ｏｎは各時間間隔である。通信可能性モデル更新部１１２は、時刻Ｔ_２以降の通信可能性推定値Ｓ_Ｏｋを、以下の式（４）を用いて算出する。

すなわち、Ｔ_１からＴ_２までの時刻はＳ_１からＳ_２までの線形な減衰を表し、Ｔ_２以後はＳ_２で一定とする。Ｓ_２は０に十分近い正の値又は０として事前に定める。このようにして、通信可能性モデルは、変数である最終通信時刻からの経過時間ｔから、通信可能性のスコア（通信可能性推定値）を得るための関数となる。

一方、ＮＧモデルは、ＮＧ→ＮＧとＮＧ→ＯＫの２種類の時間間隔を使い、時間の経過に応じて通信可能性が増加するモデルとして生成される。ＮＧモデルは、時刻Ｔ_１までの線形増加と、時刻Ｔ_１以降の線形増加に分類される。

通信可能性モデル更新部１１２は、ＮＧ→ＮＧの時間間隔バッファの各値を、以下の式（４）に代入して時刻Ｔ_１を算出する。

但し、Ｎ_ｎｎは算出に用いたＯＫ→ＯＫ時間間隔のサンプル数、Ｄ_ｎｎは各時間間隔である。式（５）は、時間間隔バッファの平均がＴ_１とされる。その他、一般的な観測ノイズを除外する方法としての外れ値を除いた平均や、より直近の時間間隔に重みを付けた平均値などを用いてＴ_１が算出されてもよい。通信可能性モデル更新部１１２は、０からＴ_１までの通信可能性推定値Ｓ_ｎｇを、以下の式（６）を用いて算出する。

但し、Ｓ_０は経過時間０の際に最低の通信可能性であり、ａ_１は時間経過と共に徐々に通信可能性が増加するような正の係数であり、それぞれ事前に定められる。これは通信不可能である状態が、時間経過に伴い不確定性が増すことを表している。

次に、通信可能性モデル更新部１１２は、Ｔ_１以後の経過時間領域としての増加を、ＮＧ→ＯＫの時間間隔のバッファの各値を用いて表す。０からＴ_１までの範囲と同様に、通信可能性モデル更新部１１２は、ＮＧ→ＯＫ時間間隔のバッファの各値を、以下の式（７）に代入して時刻Ｔ_２を算出する。

但し、Ｎ_ｎｏは算出に用いたＮＧ→ＯＫ時間間隔のサンプル数、Ｄ_ｎｏは各時間間隔である。通信可能性モデル更新部１１２は、時刻Ｔ_２以降の通信可能性推定値Ｓ_ｎｇを、以下の式（８）を用いて算出する。

すなわち、時刻０からＴ_１までがＮＧ→ＮＧの履歴から算出した通信不可能である可能性が高い時間帯、すなわち通信可能性推定値が低い時間帯であり、ＮＧ→ＯＫは通信不可能である状態が、スコアＳ_２まで増すことを表す。なお、Ｓ_２はＯＫモデルのＳ_０と異なり、高いスコアを設定しないのが好適である。これは、あくまでも通信不可能と確定できない不確定性を表すものであり、通信可能性が高いことを示すものではないためである。

通信可能性モデル更新部１１２は、算出した各パラメータを通信可能性モデルＤＢ１４（図１２）に書き込む。なお、事前に値が設定されるパラメータの値は、システムで扱う車両の全体的な傾向から決定しておけばよい。また、本実施の形態は線形に基づくモデルが用いられているが、非線形関数を用いたモデルが用いられてもよい。

また、本実施の形態では、ＯＫモデル及びＮＧモデルの２つのモデルを生成する例を示したが、より簡易化されたモデル（以下、「簡易モデル」という。）が通信可能性モデルとして用いられてもよい。

図１４は、簡易モデルの一例を示す図である。この場合、通信可能性モデル更新部１１２は、ＯＫ→ＯＫの時間バッファを利用し、式（１）と同様にＯＫ→ＯＫの時間間隔の平均値を算出し、当該平均値に事前に定めた係数ｎを乗じて、時間Ｔ_１を算出する。通信可能性モデル更新部１１２は、時刻Ｔ_１までを通信可能性が高い推定値Ｓ_１であるとし、以後を通信可能性の見込みが低い推定値Ｓ_２として、通信可能性推定値を２値とする。この簡易モデルは簡易に計算ができるため、扱う車両数が多い場合、また、センタサーバ１０がＯＫモデル及びＮＧモデルに対して多くのリソースを割り当てることが出来ない場合に好適である。

次に、データ活用サーバ３０からのデータ要求の受信に応じてセンタサーバ１０が実行する処理手順について説明する。図１５は、データ活用サーバ３０からのデータ要求の受信に応じてセンタサーバ１０が実行する処理手順の一例を説明するためのフローチャートである。

データ要求受信部１２１は、データ活用サーバ３０のデータ要求部３１から送信されたデータ要求を受信すると（Ｓ２０１）、当該データ要求に指定された条件に合致するメタデータを検索し、検索された各メタデータから車両ＩＤ（当該メタデータの送信元の車両の車両ＩＤ）を取得する（Ｓ２０２）。この際、複数のメタデータから取得された同一の車両ＩＤの重複は排除される。

続いて、通信可能性推定部１２２は、取得された各車両ＩＤをキーとするバリューを通信可能性モデルＤＢ１４（図１２）から取得し、当該各車両ＩＤに係る各車両について通信可能性を推定する（Ｓ２０３）。ここで、ステップＳ２０３の通信可能性の推定処理について具体的に説明する。

図１６は、通信可能性の推定処理の具体例を説明するための図である。図１６には、データ要求の受信に応じて実行されるステップＳ２０２において、車両Ａ、車両Ｂ、車両Ｃの３台の車両ＩＤが得られた例が示されている。実際にはより多数の車両が候補となる可能性が有るが、ここでは説明を簡潔にするため３台とする。この場合、通信可能性推定部１２２は、車両Ａ、車両Ｂ及び車両Ｃのそれぞれごとに、当該車両との最後の通信の試行に応じて更新された通信可能性モデルを使用して当該車両の通信可能性の推定値（以下、「通信可能性推定値」という。）を算出する。最後の通信の試行とは、図１０のステップＳ１０２、又は後述されるステップＳ２０６のうち、より遅いタイミングをいう。

図１３に示した通り、通信可能性モデルは、最終通信時刻を起点とした通信可能性推定値の時間変化を表している。このため、或る時点での或る車両に関する通信可能性推定値を得るには、当該車両の最終通信時刻を起点とした当該時点までの経過時間ｔを通信可能性モデルに当てはめることで得られる。また、経過時間の当てはめ先の通信可能性モデルは、当該車両の最終通信結果がＯＫであればＯＫモデル、ＮＧであればＮＧモデルである。

図１６の例の場合、車両Ａの最終通信時刻Ｔ_ａにおける最終通信結果はＯＫである。したがって、車両Ａについては車両Ａに対するＯＫモデルＭ_ａのｔに対して（リクエスト時刻（現在時刻）Ｔ−Ｔ_ａ）が当てはめられる。その結果、リクエスト時刻Ｔにおける通信可能性推定値としてＶ_ａが得られる。同様に、車両Ｂの最終通信時刻Ｔ_ｂにおける最終通信結果はＯＫである。したがって、車両Ｂについては車両Ｂに対するＯＫモデルＭ_ｂのｔに対して（リクエスト時刻（現在時刻）Ｔ−Ｔ_ｂ）が当てはめられる。その結果、リクエスト時刻Ｔにおける通信可能性推定値としてＶ_ｂが得られる。一方、車両Ｃの最終通信時刻Ｔ_ｃにおける最終通信結果はＮＧである。したがって、車両Ｃについては車両Ｃに対するＮＧモデルＭ_ｃのｔに対して（リクエスト時刻（現在時刻）Ｔ−Ｔ_ｃ）が当てはめられる。その結果、リクエスト時刻Ｔにおける通信可能性推定値としてＶ_ｃが得られる。その結果、図１６において、リクエスト時刻Ｔにおける通信可能性推定値は車両Ａ＞車両Ｂ＞車両Ｃの順であることが分かる。

続いて、リクエスト生成部１２３は、各車両の通信可能性推定値に基づいてリクエスト先とする車両を選択（選別）するための処理を実行する（Ｓ２０４）。当該処理では、通信可能性値が相対的に高い車両がリクエスト先として選択される。例えば、リクエスト生成部１２３は、各車両の通信可能性推定値を降順にソートし、ソート順にリクエスト先をして選択する（以下、ソート順での選択を「ソート法」という。）。又は、リクエスト生成部１２３は、予め設定された閾値と各通信可能性推定値とを比較し、当該閾値未満である通信可能性推定値に係る車両をリクエスト先から除外してもよい（以下、閾値に基づいてリクエスト先を除外する方法を「除外法」という。）。ソート法の場合、ソート順で上位からＮ（Ｎ≧１）番目までが、１回のリクエスト送信処理（後述のステップＳ２０５及びＳ２０６）におけるリクエスト先とされる。除外法の場合、除外されない全ての車両が１回のリクエスト送信処理におけるリクエスト先とされてもよいし、除外されない車両のうちの一部の車両が１回のリクエスト送信処理におけるリクエスト先とされてもよい。いずれの場合であっても、以下、１回のリクエスト送信処理におけるリクエスト先の車両を「対象車両」という。

続いて、リクエスト生成部１２３は、各対象車両の車載器２０を宛先として、実データの送信要求を示すリクエストを生成する（Ｓ２０５）。続いて、リクエスト送信部１２４は、リクエスト生成部１２３によって生成された各リクエストを送信する（Ｓ２０６）。したがって、各対象車両の車載器２０に対してそれぞれのリクエストが送信される。送信に成功したリクエストは、送信先の車載器２０のリクエスト受信部２２によって受信される。送信に失敗したリクエストは、送信先の車載器２０によって受信されない。送信の成否は、公知の通信プロトコルに基づいて、リクエスト送信部１２４が検知可能である。

続いて、通信可能性モデル更新部１１２は、リクエスト送信部１２４によるリクエストの送信の成否に基づいて、リクエスト先の各車両の通信可能性モデルを更新する（Ｓ２０７）。通信可能性モデルの更新方法は、図１０のステップＳ１０２と同じでよい。但し、ここでは、リクエスト送信が成功した場合、通信結果のステートがＯＫとされ、リクエスト送信が失敗した場合、通信結果のステートがＮＧとされる。リクエスト先の車両の車両ＩＤに関連付けられて通信可能性モデルＤＢ１４に記憶されているバリュー（図１２）の更新前の最終通信結果と、今回の通信結果とのステートの組み合わせに対応する種類の時間間隔バッファに対して、更新前の最終更新時刻から現在時刻までの経過時間が追加された上で、通信可能性モデルが更新される。なお、最終通信時刻は、現在時刻に更新され、最終通信結果は、今回の通信結果のステートに更新される。

一方、ステップＳ２０６において送信されたリクエストを受信した車載器２０の実データ送信部２３は、当該車載器２０に記憶されている実データをセンタサーバ１０へ送信する。なお、実データのうちの送信対象として要求する情報（データ要素）に関する条件がリクエストに含まれてもよい。この場合、実データ送信部２３は、実データのうち、当該条件に合致する情報を送信すればよい。

続いて、実データ受信部１２５は、リクエスト先の各車載器２０から送信された実データを受信する（Ｓ２０８）。続いて、実データ送信部２３は、受信された実データをデータ活用サーバ３０へ送信する（Ｓ２０９）。当該実データは、データ活用サーバ３０の要求データ受信部３２によって受信される。

続いて、収集終了判定部１２６は、実データに関する終了条件が充足したか否かを判定する（Ｓ２１０）。当該終了条件は、例えば、実データの収集対象とされる車両数によって規定されてもよいし、収集時間によって規定されてもよいし、その他の条件によって規定されてもよい。これら終了条件は、データ活用サーバ３０からのデータ要求に指定されてもよいし、センタサーバ１０に設定されていてもよい。また、閾値法の場合には、除外されない全ての車両に対してリクエストが送信されることが終了条件とされてもよい。

終了条件が満たされない場合（Ｓ２１０でＮｏ）、ステップＳ２０４以降が繰り返される。終了条件が満たされると（Ｓ２１０でＹｅｓ）、実データ送信部２３は、収集完了の通知をデータ活用サーバ３０へ送信する（Ｓ２１１）。なお、収集完了の通知は、最後に送信される実データに当該通知を示すフラグを付加することで実現されてもよい。

なお、ソート法と除外法とは併用されてもよい。

ところで、各車両について、観測データ数（時間間隔バッファのサンプル数）が十分であれば、個々の車両の通信可能性モデルを用いて個々の車両の通信可能性の推定を行うことができるが、市場投入直後の車両など、観測データ数が十分でない車両の存在も考えられる。そこで、このような車両についての通信可能性モデルの選択方法について説明する。

図１７は、観測データ数が十分でない車両に関する通信可能性モデルの選択方法の一例を説明するための図である。図１７において説明する処理は、図１０のステップＳ１０２及び図１５のステップＳ２０７における通信可能性モデルの更新処理において、当該通信可能性モデルに対応する車両（図１７では「車両Ａ」）の車両ＩＤに関連付けられて通信可能性モデルＤＢ１４（図１２）のバリューに含まれている最終通信時刻、最終通信結果及び各時間間隔バッファが更新された後であって、通信可能性モデルパラメータの更新前に実行される。

ステップＳ３０１において、通信可能性モデル更新部１１２は、観測数が十分であるか否かを判定する。例えば、各時間間隔バッファの要素数が所定数以上であるか否かが判定されてもよい。観測数が十分である場合（Ｓ３０１でＹｅｓ）、通信可能性モデル更新部１１２は、車両Ａの通信可能性モデルパラメータを更新する（Ｓ３０２）。観測数が不十分である場合（Ｓ３０１でＮｏ）、通信可能性モデル更新部１１２は、上位の通信可能性モデルを生成し、当該通信可能性モデルの通信可能性モデルパラメータを車両Ａの通信可能性モデルパラメータとして記憶する（Ｓ３０３）。

ここで、上位とは、予め登録されている（例えば、補助記憶装置１０２に記憶されている）、各車両をツリー状に分類することで得られる木構造（階層構造）における上位をいう。

図１８は、車両の分類に関する木構造の一例を示す図である。図１８の木構造において葉ノードは各車両である。各内部ノードは、当該内部ノードの下位のノード群の属性の共通性に基づいて、当該ノード群の上位概念に相当するノードである。

図１８では、車両Ａ、車両Ｂ及び車両Ｃが分類１（商用車）に属し、車両Ｄ、車両Ｅ及び車両Ｆが分類２（一般車）に属する例が示されている。この例において、車両Ａの上位とは分類１に相当する。

例えば、車両ＡについてステップＳ３０３が実行される場合、通信可能性モデル更新部１１２は、車両Ａの通信間隔バッファのみならず、車両Ａと同様に分類１に属する他の各車両（車両Ｂ及び車両Ｃ）のそれぞれの時間間隔バッファを用いて通信可能性モデルを生成し、生成された通信可能性モデルのパラメータを、車両Ａの通信可能性モデルパラメータとして通信可能性モデルＤＢ１４に記憶する。すなわち、４つの種類ごとに、時間間隔バッファを統合することで、各種の時間間隔バッファのサンプル数を増加させることができる。また、時間間隔バッファが統合される車両は、属性の一部が共通する車両であるため、通信可能性モデルが同一傾向になる可能性の高い車両である。したがって、観測数が十分でない場合でも、或る程度の精度が確保された通信可能性モデルを生成することができる。なお、分類１に統合しても観測数が十分でない場合には、分類１より上位の分類について同様の処理が実行されることで、車両Ａの通信可能性モデルが推定されればよい。

なお、本実施の形態では、通信の時間間隔から通信可能性の推定を行う例を説明したが、別の情報に基づいて通信可能性の推定が行われてもよい。例えば、車両のナビゲーションシステムに入力された目的地設定の情報をセンタサーバ１０が受信することで当該車両の走行時間を見積もり、その時間帯においては高い通信可能性推定値が算出されるモデルや、車両のグループ（タクシー等）の通信時間帯傾向から、グループとしての通信可能性が高い時間帯を特定し、推定値を算出するモデル等が生成されてもよい。

上述したように、本実施の形態によれば、オンデマンド通信時（実データの収集時）には、各車両の通信可能性モデルに基づいて車両ごとに通信可能性が推定され、通信可能性が相対的に高い車両が通信対象として選択される。その結果、通信の可否が混在する車載器２０群（車両群）からのデータ（実データ）の収集時間を短縮することができる。

図１９は、本実施の形態の効果を説明するための図である。図１９には、仮に、リクエスト送信部１２４が同時に送信できるリクエスト数が４である場合に、８台の車両から実データの収集を完了するまでの所要時間について、（１）と（２）との２通りの例が示されている。

図中左側の（１）は、本実施の形態が適用されない例を示す。例えば、ランダムにリクエスト先の車両が選択され、実データの送信要求が送信される場合が（１）である。この場合、図中（１）に示されるように、実データの送信に失敗した場合にリトライ時間又はタイムアウト時間が発生する。その結果、図中（１）に示されるように、８台分の実データの収集の所要時間は時間Ａとなる。

一方、図中右側の（２）は、本実施の形態が適用される例を示す。（２）では、通信可能性が推定された上で通信可能性が相対的に高い車両に対してリクエストが送信される。したがって、通信が失敗する可能性が低く、リトライ時間やタイムアウト時間が発生する可能性が低い。したがって、８台分の実データの収集時間の所要時間である時間Ｂは、時間Ａより短くなる可能性が高い。

また、本実施の形態では、最後の通信結果のステートに応じて、通信可能性の推定に利用されるモデルが区別される。上述したように、最後の通信結果のステートに応じて通信可能性の傾向は異なると考えられる。したがって、通信可能性の推定の精度の向上を期待することができる。

なお、本実施の形態では、車載器２０（車両）が機器である例を示したが、例えば、スマートフォン等の車載器２０（車両）以外の移動体に対して本実施の形態が適用されてもよい。また、移動体に限らず、各所の固定的に配置されているＩｏＴ（Internet of Things）機器等に対して本実施の形態が適用されてもよい。

なお、本実施の形態において、車載器２０及びセンタサーバ１０は、情報収集システムの一例である。センタサーバ１０は、情報収集装置の一例である。メタデータは、第１のデータの一例である。実データは、第２のデータの一例である。通信可能性推定部１２２は、推定部の一例である。リクエスト生成部１２３は、選択部の一例である。リクエスト送信部１２４は、要求部の一例である。通信可能性モデル更新部１１２は、生成部の一例である。ＯＫモデルは、第１のモデルの一例である。ＮＧモデルは、第２のモデルの一例である。

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

以上の説明に関し、更に以下の項を開示する。
（付記１）
複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置と、前記複数の機器とを含む情報収集システムであって、
前記情報収集装置は、
前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定する推定部と、
前記推定部が推定した前記可能性が相対的に高い前記機器を選択する選択部と、
前記選択部が選択した前記機器に前記第２のデータを要求する要求部と、
を有することを特徴とする情報収集システム。
（付記２）
前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を推定するためのモデルを前記機器ごとに生成する生成部を有し、
前記推定部は、前記機器ごとに、当該機器との最後の通信からの経過時間を前記モデルに当てはめて前記可能性を推定する、
ことを特徴とする付記１記載の情報収集システム。
（付記３）
前記生成部は、前記通信間隔の履歴における最後の通信の成否、又は前記最後の通信において前記第１のデータに含まれている情報に応じて、時間の経過に応じて前記可能性が減衰する第１のモデル、又は時間の経過に応じて前記可能性が増加する第２のモデルを生成する、
ことを特徴とする付記２記載の情報収集システム。
（付記４）
前記生成部は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれていない場合、又は前記最後の通信における前記第２のデータの要求の送信に成功した場合に、前記第１のモデルを生成する、
ことを特徴とする付記３記載の情報収集システム。
（付記５）
前記生成部は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれている場合、又は前記最後の通信における前記第２のデータの要求の送信に失敗した場合に、前記第２のモデルを生成する、
ことを特徴とする付記３記載の情報収集システム。
（付記６）
前記生成部は、前記通信間隔の履歴の数が所定数に満たない前記機器については、他の前記機器の通信間隔の履歴に基づいて前記モデルを生成する、
ことを特徴とする付記２乃至５いずれか一項記載の情報収集システム。
（付記７）
複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置が、
前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定し、
推定した前記可能性が相対的に高い前記機器を選択し、
選択した前記機器に前記第２のデータを要求する、
処理を実行することを特徴とする情報収集方法。
（付記８）
前記情報収集装置が、前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を推定するためのモデルを前記機器ごとに生成する処理を実行し、
前記推定する処理は、前記機器ごとに、当該機器との最後の通信からの経過時間を前記モデルに当てはめて前記可能性を推定する、
ことを特徴とする付記７記載の情報収集方法。
（付記９）
前記生成する処理は、前記通信間隔の履歴における最後の通信の成否、又は前記最後の通信において前記第１のデータに含まれている情報に応じて、時間の経過に応じて前記可能性が減衰する第１のモデル、又は時間の経過に応じて前記可能性が増加する第２のモデルを生成する、
ことを特徴とする付記８記載の情報収集方法。
（付記１０）
前記生成する処理は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれていない場合、又は前記最後の通信における前記第２のデータの要求の送信に成功した場合に、前記第１のモデルを生成する、
ことを特徴とする付記９記載の情報収集方法。
（付記１１）
前記生成する処理は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれている場合、又は前記最後の通信における前記第２のデータの要求の送信に失敗した場合に、前記第２のモデルを生成する、
ことを特徴とする付記９記載の情報収集方法。
（付記１２）
前記生成する処理は、前記通信間隔の履歴の数が所定数に満たない前記機器については、他の前記機器の通信間隔の履歴に基づいて前記モデルを生成する、
ことを特徴とする付記８乃至１１いずれか一項記載の情報収集方法。
（付記１３）
複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置に、
前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定し、
推定した前記可能性が相対的に高い前記機器を選択し、
選択した前記機器に前記第２のデータを要求する、
処理を実行させることを特徴とするプログラム。
（付記１４）
前記情報収集装置に、前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を推定するためのモデルを前記機器ごとに生成する処理を実行させ、
前記推定する処理は、前記機器ごとに、当該機器との最後の通信からの経過時間を前記モデルに当てはめて前記可能性を推定する、
ことを特徴とする付記１３記載のプログラム。
（付記１５）
前記生成する処理は、前記通信間隔の履歴における最後の通信の成否、又は前記最後の通信において前記第１のデータに含まれている情報に応じて、時間の経過に応じて前記可能性が減衰する第１のモデル、又は時間の経過に応じて前記可能性が増加する第２のモデルを生成する、
ことを特徴とする付記１４記載のプログラム。
（付記１６）
前記生成する処理は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれていない場合、又は前記最後の通信における前記第２のデータの要求の送信に成功した場合に、前記第１のモデルを生成する、
ことを特徴とする付記１５記載のプログラム。
（付記１７）
前記生成する処理は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれている場合、又は前記最後の通信における前記第２のデータの要求の送信に失敗した場合に、前記第２のモデルを生成する、
ことを特徴とする付記１５記載のプログラム。
（付記１８）
前記生成する処理は、前記通信間隔の履歴の数が所定数に満たない前記機器については、他の前記機器の通信間隔の履歴に基づいて前記モデルを生成する、
ことを特徴とする付記１４乃至１７いずれか一項記載のプログラム。

１０ センタサーバ
１１ メタデータ収集部
１２ 実データ収集部
１３ 車両検索ＤＢ
１４ 通信可能性モデルＤＢ
２０ 車載器
２１ メタデータ送信部
２２ リクエスト受信部
２３ 実データ送信部
３０ データ活用サーバ
３１ データ要求部
３２ 要求データ受信部
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１１１ メタデータ受信部
１１２ 通信可能性モデル更新部
１２１ データ要求受信部
１２２ 通信可能性推定部
１２３ リクエスト生成部
１２４ リクエスト送信部
１２５ 実データ受信部
１２６ 収集終了判定部
１２７ 要求データ送信部
２０１ ＣＰＵ
２０２ 補助記憶装置
２０３ メモリ装置
２０４ 通信装置
２０５ カメラ
２０６ ＧＰＳ受信機
２０７ 各種センサ
Ｂ バス

Claims (8)

1. 複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置と、前記複数の機器とを含む情報収集システムであって、
   前記情報収集装置は、
   前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定する推定部と、
   前記推定部が推定した前記可能性が相対的に高い前記機器を選択する選択部と、
   前記選択部が選択した前記機器に前記第２のデータを要求する要求部と、
   を有することを特徴とする情報収集システム。
2. 前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を推定するためのモデルを前記機器ごとに生成する生成部を有し、
   前記推定部は、前記機器ごとに、当該機器との最後の通信からの経過時間を前記モデルに当てはめて前記可能性を推定する、
   ことを特徴とする請求項１記載の情報収集システム。
3. 前記生成部は、前記通信間隔の履歴における最後の通信の成否、又は前記最後の通信において前記第１のデータに含まれている情報に応じて、時間の経過に応じて前記可能性が減衰する第１のモデル、又は時間の経過に応じて前記可能性が増加する第２のモデルを生成する、
   ことを特徴とする請求項２記載の情報収集システム。
4. 前記生成部は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれていない場合、又は前記最後の通信における前記第２のデータの要求の送信に成功した場合に、前記第１のモデルを生成する、
   ことを特徴とする請求項３記載の情報収集システム。
5. 前記生成部は、前記最後の通信における前記第１のデータに前記機器が通信を終了することを示唆する情報が含まれている場合、又は前記最後の通信における前記第２のデータの要求の送信に失敗した場合に、前記第２のモデルを生成する、
   ことを特徴とする請求項３記載の情報収集システム。
6. 前記生成部は、前記通信間隔の履歴の数が所定数に満たない前記機器については、他の前記機器の通信間隔の履歴に基づいて前記モデルを生成する、
   ことを特徴とする請求項２乃至５いずれか一項記載の情報収集システム。
7. 複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置が、
   前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定し、
   推定した前記可能性が相対的に高い前記機器を選択し、
   選択した前記機器に前記第２のデータを要求する、
   処理を実行することを特徴とする情報収集方法。
8. 複数の機器のそれぞれから複数のタイミングで送信される第１のデータに基づき前記第１のデータとは異なる第２のデータを前記機器から収集する情報収集装置に、
   前記機器ごとの通信間隔の履歴に基づいて、前記第２のデータを要求するための通信が成功する可能性を前記機器ごとに推定し、
   推定した前記可能性が相対的に高い前記機器を選択し、
   選択した前記機器に前記第２のデータを要求する、
   処理を実行させることを特徴とするプログラム。

Images