JP7215464B2 - データ収集システム、収集センタ、及びデータ収集方法 - Google Patents

Description

本開示は、データ収集システム、収集センタ、及びデータ収集方法に関するものである。

走行中の車両によって得られるデータを無線通信によって車載端末からセンタに送信することで、センタで複数の車両のデータを収集して２次活用を可能にすることが知られている。例えば、センタが複数の車両から収集するデータを用いて地図を自動で生成する技術が知られている。センタが車両から収集するデータの活用の幅が広がる中、車載端末と基地局とのデータ通信量は年々増加している。車載端末と基地局とのデータ通信量が増加すると、通信速度の低下及び通信品質の低下といった問題が発生しやすくなる。

これに対して、特許文献１には、車両の通信端末（つまり、車載端末）が公衆通信網を介してセンタとの間で行う通信のデータ通信量が増加し過ぎないようにする技術が開示されている。特許文献１に開示の技術では、データサンプルを取得する地点での利用可能な通信資源に応じた通信量で自車が送信できる分のデータサンプルはその時点で送信するものと計画する。一方、その時点で送信できない分のデータサンプルは自車の候補経路上で後に続く地点での利用可能な通信資源の余剰を利用して送信するものと計画する。また、特許文献１には、遅延時間が許容範囲内のデータサンプルのうちのデータ価値が高いデータサンプルから順に送信候補とすることが開示されている。

特開２０１９－５６５５９号公報

特許文献１に開示の技術では、ある地点で送信できない分のデータサンプルは、後に続く地点で送信する候補となるため、一時的に車載端末のメモリに記憶しておく必要が生じる。しかしながら、車載端末のメモリの容量は有限であり、記憶しておくことのできるデータサンプルの量は限られる。よって、データ価値が比較的高いデータサンプルであっても、自車の走行経路において利用可能な通信資源によっては、時間の経過に伴って遅延時間が許容範囲外となれば、送信候補から外れて廃棄されると考えられる。特許文献１に開示の技術では、データサンプルをセンタに送信するか否かは、各車両に依存している。よって、他の車両がセンタにアップロードする可能性が高いデータサンプルであっても、そのデータサンプルを送信できるタイミングになるまで車載端末のメモリに保存しておくことで、車載端末のメモリの残容量が圧迫される状況が生じる。その結果、データ価値が比較的高いデータサンプルであっても、車載端末のメモリの残容量が乏しくなることで破棄されてしまい、価値の高いデータサンプルをセンタで収集できない状況が生じてしまう。

この開示のひとつの目的は、複数の車両の車載端末からデータを収集する場合に、価値の高いデータを収集できない状況を生じにくくさせることを可能にするデータ収集システム、収集センタ、及びデータ収集方法を提供することにある。

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は、開示の更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、ひとつの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

上記目的を達成するために、本開示のデータ収集システムは、車両に搭載され、車両の走行によって得られるデータを取得するデータ取得部（３１７）と、データ取得部で取得したデータを送信する車両側送信部（３４）とを備える車載端末（３５）と、複数の車両の車載端末から送信されるデータを受信するセンタ側受信部（２２１）を備える収集センタ（２）とを含み、車載端末は、データ取得部で取得したデータを、車両側送信部で送信可能となるまで一時的に記憶しておく一時記憶部（３２２）と、一時記憶部の記憶容量不足を予測する容量不足予測部（３２０）を備え、車両側送信部は、データ取得部でデータを取得した場合であって、容量不足予測部で一時記憶部の記憶容量不足が予測される場合に、そのデータの要否の問い合わせを収集センタに送信し、収集センタのセンタ側受信部は、車載端末から送信されるデータの要否の問い合わせも受信するものであり、収集センタは、車載端末から送信されるデータの要否の問い合わせをセンタ側受信部で受信した場合に、そのデータの代替の可否を判定する代替可否判定部（２０４）と、代替可否判定部でそのデータの代替が可能と判定したことをもとに、そのデータの要否の問い合わせを送信してきた車載端末にそのデータの破棄を行わせる破棄通知を返信する一方、代替可否判定部でそのデータの代替が不可能と判定した場合に、そのデータの要否の問い合わせを送信してきた車載端末にそのデータの保持を行わせる保持通知を返信するセンタ側送信部（２２２）と、代替可否判定部で代替が可能と判定したデータについて、そのデータを再取得できる可能性である再取得可能性を判定する可能性判定部（２０５）とを備え、センタ側送信部は、代替可否判定部でデータの代替が可能と判定した場合には、可能性判定部で判定したそのデータについての再取得可能性が閾値以上であることをもとに、そのデータの要否の問い合わせを送信してきた車載端末に破棄通知を返信する一方、可能性判定部で判定したそのデータについての再取得可能性が閾値未満の場合には、そのデータの要否の問い合わせを送信してきた車載端末に保持通知を返信し、車載端末は、破棄通知を受信した場合には、要否の問い合わせを行ったデータを破棄して一時記憶部にそのデータを記憶しない一方、保持通知を受信した場合には、要否の問い合わせを行ったデータを一時記憶部に記憶する記憶処理部（３２１）を備える。

また、上記目的を達成するために、本開示の収集センタは、複数の車両のそれぞれに搭載される車載端末で取得して送信される、それぞれの車両の走行によって得られるデータを受信するセンタ側受信部（２２１）と、取得したデータを送信可能となるまで一時的に記憶しておく一時記憶部の記憶容量不足が予測された車載端末から送信される、その車載端末で取得したデータの要否の問い合わせをセンタ側受信部で受信した場合に、そのデータの代替の可否を判定する代替可否判定部（２０４）と、代替可否判定部でそのデータの代替が可能と判定したことをもとに、そのデータの要否の問い合わせを送信してきた車載端末にそのデータの破棄を行わせる破棄通知を返信する一方、代替可否判定部でそのデータの代替が不可能と判定した場合に、そのデータの要否の問い合わせを送信してきた車載端末にそのデータの保持を行わせる保持通知を返信するセンタ側送信部（２２２）と、代替可否判定部で代替が可能と判定したデータについて、そのデータを再取得できる可能性である再取得可能性を判定する可能性判定部（２０５）とを備え、センタ側送信部は、代替可否判定部でデータの代替が可能と判定した場合には、可能性判定部で判定したそのデータについての再取得可能性が閾値以上であることをもとに、そのデータの要否の問い合わせを送信してきた車載端末に破棄通知を返信する一方、可能性判定部で判定したそのデータについての再取得可能性が閾値未満の場合には、そのデータの要否の問い合わせを送信してきた車載端末に保持通知を返信する。

また、上記目的を達成するために、本開示のデータ収集方法は、少なくとも１つのプロセッサにより実行される、複数の車両のそれぞれに搭載される車載端末で取得して送信される、それぞれの車両の走行によって得られるデータを受信するセンタ側受信工程と、取得したデータを送信可能となるまで一時的に記憶しておく一時記憶部の記憶容量不足が予測された車載端末から送信される、その車載端末で取得したデータの要否の問い合わせを受信した場合に、そのデータの代替の可否を判定する代替可否判定工程と、代替可否判定工程でそのデータの代替が可能と判定したことをもとに、そのデータの要否の問い合わせを送信してきた車載端末にそのデータの破棄を行わせる破棄通知を返信する一方、代替可否判定工程でそのデータの代替が不可能と判定した場合に、そのデータの要否の問い合わせを送信してきた車載端末にそのデータの保持を行わせる保持通知を返信するセンタ側送信工程と、代替可否判定工程で代替が可能と判定したデータについて、そのデータを再取得できる可能性である再取得可能性を判定する可能性判定工程とを含み、センタ側送信工程では、代替可否判定工程でデータの代替が可能と判定した場合には、可能性判定工程で判定したそのデータについての再取得可能性が閾値以上であることをもとに、そのデータの要否の問い合わせを送信してきた車載端末に破棄通知を返信する一方、可能性判定工程で判定したそのデータについての再取得可能性が閾値未満の場合には、そのデータの要否の問い合わせを送信してきた車載端末に保持通知を返信する。

以上の構成によれば、データの要否の問い合わせは、取得したデータを送信可能となるまで一時的に記憶しておく一時記憶部の記憶容量不足が予測された車載端末から送信される。一時記憶部の記憶容量不足が予測された車載端末で、取得したそのデータを送信可能となるまで保持すると、その後に取得するデータを収集センタに送信できなくなる状況が生じやすくなる。これに対して、以上の構成では、データの要否の問い合わせを送信してきた車載端末にそのデータの破棄を行わせる破棄通知を返信する一方、代替可否判定部でそのデータの代替が不可能と判定した場合に、そのデータの要否の問い合わせを送信してきた車載端末にそのデータの保持を行わせる保持通知を返信することなる。代替が可能と判定されるデータであれば、破棄通知によってデータが破棄されたとしても、収集センタはそのデータを代替できる可能性が高い。また、破棄通知によってデータが破棄されることで、一時記憶部の記憶容量に余裕を持たせ、その後に取得するデータを収集センタに送信できなくなる状況を生じにくくすることが可能になる。一方、代替が不可能と判定されるデータは、代替できない可能性が高いが、保持通知によってデータを保持させるため、車載端末でそのデータを送信可能となった際に収集センタで収集できる可能性が高まる。その結果、複数の車両の車載端末からデータを収集する場合に、価値の高いデータを収集できない状況を生じにくくさせることが可能になる。

データ収集システム１の概略的な構成の一例を示す図である。 車両側ユニット３及び通信制御装置３０の概略的な構成の一例を示す図である。 通信制御装置３０での対象データ送信関連処理の流れの一例を示すフローチャートである。 対象データ送信関連処理のうちのエリア内処理の流れの一例を示すフローチャートである。 対象データ送信関連処理のうちのエリア外処理の流れの一例を示すフローチャートである。 収集センタ２及び通信統括制御装置２０の概略的な構成の一例を示す図である。 通信統括制御装置２０での要否応答関連処理の流れの一例を示すフローチャートである。 要否応答関連処理のうちの検索処理の流れの一例を示すフローチャートである。 本実施形態の一例の概略について説明を行うための図である。 本実施形態の一例の概略について説明を行うための図である。 本実施形態の一例の概略について説明を行うための図である。

図面を参照しながら、開示のための複数の実施形態を説明する。なお、説明の便宜上、複数の実施形態の間において、それまでの説明に用いた図に示した部分と同一の機能を有する部分については、同一の符号を付し、その説明を省略する場合がある。同一の符号を付した部分については、他の実施形態における説明を参照することができる。

（実施形態１）
＜データ収集システム１の概略構成＞
以下、本実施形態について図面を用いて説明する。まず、図１を用いて、データ収集システム１の説明を行う。図１に示すように、データ収集システム１は、収集センタ２と、車両で用いられる車両側ユニット３とを含んでいる。データ収集システム１には、複数台の車両の車両側ユニット３を含むものとする。

収集センタ２は、例えばサーバとすればよい。収集センタ２は、１つのサーバからなるものであってもよいし、複数のサーバからなるものであってもよい。収集センタ２は、例えばクラウド上のサーバであってもよいし、ブロックチェーン等の分散型ネットワークであってもよい。収集センタ２は、車両側ユニット３から送信されるデータを受信する。収集センタ２は、車両側ユニット３から受信したデータを記憶装置に蓄積したり、データを利用する他のセンタに受け渡したりする。収集センタ２の詳細については後述する。

車両側ユニット３から受信したデータを利用する例としては、撮像画像のデータを地図生成，機械学習に利用する例等が挙げられる。撮像画像のデータを地図生成に利用する例としては、ストリートビューへの利用，ＳＬＡＭ（Simultaneous Localization and Mapping）への利用が挙げられる。撮像画像のデータを機械学習に利用する例としては、歩行等の検出アルゴリズムの訓練への利用が挙げられる。

収集センタ２は、車両から収集したいデータについての情報（以下、収集ニーズ）を車両側ユニット３に送信してもよい。例えば、収集ニーズは、必要とするデータの種別，取得位置等とすればよい。

車両側ユニット３は、収集センタ２との間でデータの通信を行う。車両側ユニット３は、自ユニットを搭載する車両の走行によって得られるデータを収集センタ２に送信する。ここで言うところの車両は、例えば自動車とすればよい。車両側ユニット３の詳細については以下で述べる。

＜車両側ユニット３の概略構成＞
続いて、図２を用いて車両側ユニット３の概略的な構成について説明する。図２に示すように、車両側ユニット３は、通信制御装置３０、ロケータ３１、ナビゲーション装置３２、及び無線通信装置３４を含む。以下では、車両側ユニット３を搭載する車両を自車と呼ぶ。

ロケータ３１は、ＧＮＳＳ（Global Navigation Satellite System）受信機、及び慣性センサを備えている。ＧＮＳＳ受信機は、複数の測位衛星からの測位信号を受信する。慣性センサは、例えばジャイロセンサ及び加速度センサを備える。ロケータ３１は、ＧＮＳＳ受信機で受信する測位信号と、慣性センサの計測結果とを組み合わせることにより、自車の車両位置を逐次測位する。なお、車両位置の測位には、自車に搭載された車速センサから逐次出力される検出結果から求めた走行距離等を用いる構成としてもよい。

ナビゲーション装置３２は、設定された目的地まで自車のユーザを誘導する経路案内を行う。自車の目的地としては、例えば操作入力部を介してユーザから受け付けた操作入力に従った目的地を設定する構成とすればよい。出発地については、例えば自車の現在位置を出発地として設定する構成とすればよい。

データ収集装置３３は、自車から収集センタ２に送信する対象であるデータ（以下、対象データ）を取得することで収集する。自車から収集センタ２に送信する対象であるデータとは、送信の候補であることを示し、送信されない場合もあり得るものとする。データ収集装置３３で取得する対象データは、自車の走行によって得られるデータである。データ収集装置３３で取得する対象データとしては、障害物検出のデータ，撮像画像のデータ等が挙げられる。なお、ここで述べたのはあくまで一例であって、データ収集装置３３が他のデータを取得する構成としてもよい。

障害物検出データは、自車に搭載された周辺監視センサで自車周辺の障害物を検出した場合に生成するその障害物の検出結果のデータとすればよい。障害物の検出は、歩行者，周辺車両，路上障害物等の障害物の種類を区別して検出されることが好ましい。これらの区別は、周辺監視センサがカメラの場合には、画像認識によって行う構成とすればよい。また、これらの区別は、周辺監視センサがミリ波レーダ等の測距センサの場合には、測距点が示す障害物の形状，大きさ等によって行う構成とすればよい。

撮像画像データは、自車に搭載された周辺監視センサのうちのカメラで自車周辺を撮像した場合に生成する撮像画像のデータとすればよい。カメラでの撮像方向は、自車の前方に限らない。例えばデータ収集装置３３で取得する撮像画像データは、収集センタ２から受信する収集ニーズに合致する撮像画像データとしてもよい。

データ収集装置３３は、対象データの他に、対象データに付与されるデータの生成時情報も取得するものとする。生成時情報は、例えばデータ種別，データ生成時刻，データ生成位置等である。データ種別は、データの種類を示す情報である。データ生成時刻は、データが生成された時刻を示す情報である。データ生成位置は、データが生成された地図上の位置を示す情報である。データ生成位置は、自車のロケータ３１によって逐次測位される自車位置をもとに特定される構成とすればよい。

無線通信装置３４は、通信制御装置３０の制御に従って、無線通信を介して情報の送受信を行う。この無線通信装置３４が車両側送信部に相当する。無線通信装置３４は、公衆通信網及び基地局等を介して、収集センタ２と通信を行う。無線通信装置３４は、例えば通信コストの異なる複数種類の通信回線を利用可能な構成としてもよい。無線通信装置３４が利用可能な複数種類の通信回線は、３種類以上であってもよい。一例として、通信コストのより高い通信回線として、ＬＴＥ（Long Term Evolution）等のセルラー回線が挙げられる。一方、通信コストのより低い通信回線として、Ｗｉ－Ｆｉ（登録商標）が挙げられる。

通信制御装置３０は、例えばプロセッサ、メモリ、Ｉ／Ｏ、これらを接続するバスを備え、メモリに記憶された制御プログラムを実行することで、自車で得られるデータの送信に関する処理（以下、データ送信関連処理）を実行する。ここで言うところのメモリは、コンピュータによって読み取り可能なプログラム及びデータを非一時的に格納する非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。また、非遷移的実体的記憶媒体は、半導体メモリ等によって実現される。通信制御装置３０は、データ収集装置３３で収集したデータを一旦受信し、送信タイミング，送信順序を制御してデータを無線通信装置３４から送信させる。通信制御装置３０の詳細については、以下で述べる。

＜通信制御装置３０の概略構成＞
続いて、図２を用いて通信制御装置３０の概略的な構成について説明する。図２に示すように、通信制御装置３０は、地図データベース（以下、地図ＤＢ）３１１、現在位置特定部３１２、目的地取得部３１３、経路検索部３１４、通信資源マップ格納部３１５、データ送信予測部３１６、データ取得部３１７、データ価値マップ格納部３１８、データ価値判定部３１９、データ送信制御部３２０、キャッシュメモリ管理部３２１、及びキャッシュメモリ３２２を機能ブロックとして備えている。なお、通信制御装置３０が実行する機能の一部又は全部を、１つ或いは複数のＩＣ等によりハードウェア的に構成してもよい。また、通信制御装置３０が備える機能ブロックの一部又は全部は、プロセッサによるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。この通信制御装置３０と無線通信装置３４とを含む構成が車載端末３５にあたる。

地図ＤＢ３１１は、リンクデータ，ノードデータ，道路形状等の地図データを格納する。地図ＤＢ３１１は、不揮発性メモリであってもよいし、揮発性メモリであってもよい。地図ＤＢ３１１を揮発性メモリとする場合には、通信制御装置３０の外部から地図データを一時的に格納する構成とすればよい。地図ＤＢ３１１は、不揮発性メモリであって、通信制御装置３０の外部に備えられる構成としてもよい。地図ＤＢ３１１に格納される地図データは、無線通信装置３４を介して自車の外部から取得する構成としてもよい。

現在位置特定部３１２は、ロケータ３１で測位した車両位置と、地図ＤＢ３１１に格納されている地図データとから、地図上での自車の現在位置を特定する。一例として、マップマッチングの技術を用いて、地図上での自車の現在位置を特定すればよい。

目的地取得部３１３は、ナビゲーション装置３２で設定された自車の目的地を取得する。経路検索部３１４は、現在位置特定部３１２で検出した自車の現在位置と、目的地取得部３１３で取得した目的地とを用いて、自車の現在位置から目的地までの推奨経路を探索する。経路検索部３１４は、例えばダイクストラ法を用いて、時間優先，距離優先等の予め設定された探索条件に従って推奨される予測経路を探索すればよい。

なお、目的地取得部３１３は、ナビゲーション装置３２で設定された自車の目的地を取得する構成に限らない。目的地取得部３１３は、ナビゲーション装置３２以外で設定された自車の目的地を取得する構成としてもよい。例えば、目的地取得部３１３が、加減速及び操舵を自動で行う自動運転での目的地を取得する構成としてもよい。また、目的地取得部３１３と経路検索部３１４は、通信制御装置３０の外部に備えられる構成としてもよい。

通信資源マップ格納部３１５は、地点とその地点での通信に利用可能となると推定される通信資源量との対応関係を示す通信資源マップを格納する。通信資源マップ格納部３１５としては、通信制御装置３０の不揮発性メモリを用いればよい。地点は、例えば位置情報とすればよい。通信資源量は、通信速度，通信遅延等で表せばよい。なお、通信資源量は、使用可能容量，使用可能な通信帯域の広さ等であってもよい。通信速度としては、例えばアップロード及びダウンロードでの１秒あたりに転送できるデータ量を用いればよい。遅延時間としては、例えばアップロード及びダウンロードでの通信遅延の時間を用いればよい。なお、通信速度が速く，通信遅延が少ないほど通信資源量が多く、通信速度が遅く，通信遅延が多いほど通信資源量が少ないものとする。通信資源マップは、時間帯別に通信資源マップ格納部３１５に格納されるものとする。ここで言うところの時間帯の区分は、３時間ごと等の等分に分けられる区分であっても、特定の時間帯は短くなったり長くなったりといった不等分に分けられる区分であってもよい。また、通信資源マップは、配信時の通信負荷を軽減するため、複数の地域別に通信資源マップ格納部３１５に格納されることが好ましい。一例として、通信資源マップは、地図上の格子状に規定された矩形状の領域別に、通信速度及び通信遅延の組み合わせで表される通信資源量が設定されている構成とすればよい。

データ送信予測部３１６は、経路検索部３１４で検索した予測経路と通信資源マップ格納部３１５に格納されている通信資源マップとから、いつ、どの地点で、どの程度のデータ送信が可能かを予測する。

データ取得部３１７は、データ収集装置３３で収集される対象データ及びその対象データの生成時情報を取得する。データ取得部３１７での対象データを取得する工程がデータ取得工程に相当する。データ価値マップ格納部３１８は、対象データの価値指標であるデータ価値の判定に必要なデータ価値マップを格納する。データ価値マップ格納部３１８としては、通信制御装置３０の不揮発性メモリを用いればよい。データ価値マップは、例えばデータ価値とデータ種別とデータ位置とが対応付けられる等すればよい。データ価値マップは、収集センタ２から受信する収集ニーズに応じて更新される構成としてもよい。詳しくは、収集ニーズの高いデータ位置のデータ種別ほどデータ価値が高くなるように更新される構成とすればよい。

データ価値判定部３１９は、データ取得部３１７で取得する対象データ及びその対象データの生成時情報をもとに、データ価値マップ格納部３１８に格納されるデータ価値マップを参照し、その対象データのデータ価値を判定する。このデータ価値判定部３１９が価値判定部に相当する。データ価値判定部３１９は、対象データのデータ生成時刻からの経過時間が長くなるのに応じて、データ価値を低く補正して判定してもい。データ生成時刻からの経過時間に応じたデータ価値の補正量は、データ種別によって異なっている構成としてもよい。

データ送信制御部３２０は、データ取得部３１７で取得した対象データの送信タイミングを制御する。データ送信制御部３２０での処理の詳細については、後述する。キャッシュメモリ管理部３２１は、キャッシュメモリ３２２の読み書き，データ削除，データ更新，データの優先度（つまり、優先順位）を管理する。キャッシュメモリ管理部３２１での処理の詳細については、後述する。キャッシュメモリ３２２は、データを一時的に保存する。キャッシュメモリ３２２は、例えば揮発性メモリとすればよい。キャッシュメモリ３２２が一時記憶部に相当する。

＜データ取得関連処理＞
ここで、図３～図５のフローチャートを用いて、通信制御装置３０での対象データの送信に関連する処理（以下、対象データ送信関連処理）の流れの一例について説明を行う。図３のフローチャートは、データ取得部３１７でデータを取得するごとに開始する構成とすればよい。

まず、ステップＳ１では、データ送信制御部３２０が、データ取得部３１７で取得した対象データを収集センタ２へ送信する無線リソースの空きがあるエリア（以下、無線リソース空きエリア）内か否かを判定する。例えば、無線リソース空きエリア内か否かは、通信資源マップ格納部３１５に格納されている通信資源マップをもとに判定すればよい。一例として、対象データが自車の現在位置に対応する地点の通信可能容量内におさまるか否かで判定すればよい。

そして、データ送信制御部３２０が、無線リソース空きエリア内と判定した場合（Ｓ１でＹＥＳ）には、ステップＳ２に移る。一方、無線リソース空きエリア外と判定した場合（Ｓ１でＮＯ）には、ステップＳ３に移る。

ステップＳ２では、エリア内処理を行って、対象データ送信関連処理を終了する。ここで、図４のフローチャートを用いて、エリア内処理の流れの一例について説明を行う。

ステップＳ２１では、キャッシュメモリ管理部３２１が、キャッシュメモリ３２２に未送信の対象データ（以下、未送信データ）が存在するかキャッシュチェックを行う。そして、ステップＳ２２では、未送信データが存在する、送信待ちありの場合（Ｓ２２でＹＥＳ）に、ステップＳ２４に移る。一方、未送信データが存在しない、送信待ちなしの場合（Ｓ２２でＮＯ）には、ステップＳ２３に移る。

ステップＳ２３では、送信待ちの対象データがないので、データ送信制御部３２０が、データ取得部３１７で取得した対象データを、無線通信装置３４から収集センタ２へ即時送信させ、エリア内処理を終了する。一方、ステップＳ２４では、キャッシュメモリ管理部３２１が、データ取得部３１７で取得した対象データを、キャッシュメモリ３２２に書き込む。そして、キャッシュメモリ管理部３２１は、キャッシュメモリ３２２内の、今回取得した対象データと未送信の対象データとを、優先度順にソーティングする。優先度については、データ価値判定部３１９で判定されるデータ価値が高い対象データほど優先度を高くすればよい。

ステップＳ２５では、キャッシュメモリ管理部３２１は、キャッシュメモリ３２２に格納されている対象データのうち、優先度が最も高い対象データを読み出す。ステップＳ２６では、データ送信制御部３２０が、Ｓ２５で読み出した対象データを、無線通信装置３４から収集センタ２へ送信させる。Ｓ２５で読み出した対象データを、無線通信装置３４が収集センタ２へ送信する工程がデータ送信工程に相当する。ステップＳ２７では、キャッシュメモリ管理部３２１が、Ｓ２６で送信させた対象データを、キャッシュメモリ３２２から削除するキャッシュ削除を行う。

ステップＳ２８では、無線リソースの空きのある範囲内で未送信の対象データがある場合（Ｓ２８でＹＥＳ）には、Ｓ２５に戻って処理を繰り返す。一方、無線リソースの空きのある範囲内で未送信の対象データがない場合（Ｓ２８でＮＯ）には、ステップＳ２９に移る。

ステップＳ２９では、キャッシュメモリ管理部３２１がキャッシュメモリ３２２の容量の残量をチェックする。そして、対象データ送信関連処理の開始前から残量が変化していた場合（Ｓ２９でＹＥＳ）には、ステップＳ３０に移る。一方、残量が変化していなかった場合（Ｓ２９でＮＯ）には、エリア内処理を終了する。ステップＳ３０では、データ送信制御部３２０が、自車についてのキャッシュメモリ３２２の残量の情報（以下、残量情報）を、無線通信装置３４から収集センタ２へ送信させ、エリア内処理を終了する。残量情報は、キャッシュメモリ３２２の残量を特定できる情報であればよく、キャッシュメモリ３２２の全容量に対する残量の割合であってもよいし、残量自体であってもよい。

なお、収集センタ２への残量情報の送信は、細かな残量の変化ごとに行うと通信負荷が大きくなってしまう。よって、Ｓ２９では、一定以上の残量の変化を残量の変化があったものとして扱うことが好ましい。例えば、キャッシュメモリ３２２の全容量をレベル分けし、残量のレベルが変わった場合に残量の変化ありとする構成としてもよい。例を挙げると、１ＧＢが全容量の場合に、１００ＭＢを１レベルとし、残量のレベルを１０段階で示す等すればよい。

また、データ送信制御部３２０は、Ｓ２３での対象データの収集センタ２への送信時に、経路検索部３１４で探索した自車の予測経路も収集センタ２へ送信させてもよい。他にも、データ送信制御部３２０は、Ｓ３０での自車の残量情報の収集センタ２への送信時に、経路検索部３１４で探索した自車の予測経路も収集センタ２へ送信させてもよい。さらに、データ送信制御部３２０は、自車の予測経路に加え、現在位置特定部３１２で特定した自車の現在位置も収集センタ２へ送信させる構成としてもよい。

図３に戻って、ステップＳ３では、エリア外処理を行って、対象データ送信関連処理を終了する。ここで、図５のフローチャートを用いて、エリア外処理の流れの一例について説明を行う。

ステップＳ３１では、データ送信制御部３２０が、データ取得部３１７で取得した対象データをキャッシュメモリ３２２に格納する記憶容量の不足を予測する。このデータ送信制御部３２０が容量不足予測部に相当する。このＳ３１の処理工程が容量不足予測工程に相当する。この予測は、例えば現時点のキャッシュメモリ３２２の残容量と、データ送信予測部３１６で予測した今後のデータ送信可能な量と、今後のデータ収集予測量とから予測すればよい。ここで言うところの今後とは、例えば次の基地局エリア到達時等とすればよい。データ収集予測量は、例えばデータ収集装置３３でのデータの収集予定から予測すればよい。他にも、走行距離あたりのデータ収集装置３３でのデータの平均収集量から予測してもよい。なお、残容量を全容量に対する割合で示す場合には、キャッシュメモリ３２２の全容量の情報も用いればよい。また、記憶容量の不足とは、必ずしも記憶容量残量（以下、残容量）０を指すものではない。例えば、残容量が全容量の３０％といった規定量未満となることであってもよい。この規定量が、稼働中の車両のキャッシュメモリ３２２の平均使用率を決めるパラメータとなる。

そして、ステップＳ３１では、記憶容量の不足が予測される場合（Ｓ３１でＹＥＳ）には、ステップＳ３２に移る。一方、ステップＳ３１では、記憶容量が不足しないと予測される場合（Ｓ３１でＮＯ）には、ステップＳ３６に移る。

ステップＳ３２では、データ送信制御部３２０が、データ取得部３１７で取得した対象データの要否の問い合わせを、無線通信装置３４から収集センタ２へ送信させる。この要否の問い合わせを無線通信装置３４から収集センタ２へ送信する工程が要否問い合わせ工程に相当する。対象データの要否の問い合わせには、対象データのデータ量，生成時情報，経路検索部３１４で探索した自車の予測経路，現在位置特定部３１２で特定した自車の現在位置，キャッシュメモリ３２２の残量情報，キャッシュメモリ３２２の残量予測値等も含ませる構成とすればよい。残量予測値は、データ送信制御部３２０が、例えば現時点のキャッシュメモリ３２２の残容量と、データ送信予測部３１６で予測した今後のデータ送信可能な量と、今後のデータ収集予測量とから予測すればよい。対象データの要否の問い合わせを受信した収集センタ２からは、後述する破棄通知若しくは保持通知が返信されてくる。そして、無線通信装置３４がこの破棄通知若しくは保持通知を受信し、データ送信制御部３２０に通知する。

ステップＳ３３では、収集センタ２から保持通知が返信されてきた場合（Ｓ３３でＹＥＳ）には、ステップＳ３４に移る。一方、収集センタ２から破棄通知が返信されてきた場合（Ｓ３３でＮＯ）には、ステップＳ３５に移る。

ステップＳ３４では、キャッシュメモリ管理部３２１が、キャッシュメモリ３２２に格納されている対象データのうち、優先度が最も低い対象データを削除するキャッシュ削除を行い、ステップＳ３６に移る。一方、ステップＳ３５では、キャッシュメモリ管理部３２１が、データ取得部３１７で取得した対象データをキャッシュメモリ３２２に書き込まずに破棄し、エリア外処理を終了する。

ステップＳ３６では、キャッシュメモリ管理部３２１が、データ取得部３１７で取得した対象データを、キャッシュメモリ３２２に書き込む。つまり、Ｓ３２で要否の問い合わせを行った対象データを、キャッシュメモリ３２２に記憶する。よって、このキャッシュメモリ管理部３２１が記憶処理部に相当する。また、Ｓ３５，Ｓ３６の処理工程が記憶処理工程に相当する。そして、ステップＳ３６では、Ｓ２４と同様にして、キャッシュメモリ管理部３２１が、キャッシュメモリ３２２内の、今回取得した対象データと未送信の対象データとを、優先度順にソーティングする。

ステップＳ３７では、Ｓ２９と同様にして、キャッシュメモリ管理部３２１がキャッシュメモリ３２２の容量の残量をチェックする。そして、対象データ送信関連処理の開始前から残量が変化していた場合（Ｓ３７でＹＥＳ）には、ステップＳ３８に移る。一方、残量が変化していなかった場合（Ｓ３７でＮＯ）には、エリア外処理を終了する。ステップＳ３８では、Ｓ３０と同様の処理を行って、エリア外処理を終了する。

＜収集センタ２の概略構成＞
続いて、図６を用いて収集センタ２の概略的な構成について説明する。図６に示すように、収集センタ２は、通信統括制御装置２０及び送受信サーバ２１を含む。送受信サーバ２１は、車載端末３５との間で公衆通信網及び基地局を介して通信を行う。また、図６に示すように、送受信サーバ２１は、受信部２２１及び送信部２２２を機能ブロックとして備えている。受信部２２１は、車載端末３５から送信されてくるデータを受信し、通信統括制御装置２０に送る。この受信部２２１がセンタ側受信部に相当する。また、受信部２２１で車載端末３５から送信されてくるデータを受信する工程がセンタ側受信工程に相当する。送信部２２２は、通信統括制御装置２０の制御に従って、公衆通信網及び基地局を介して車載端末３５へ通知を送信する。この送信部２２２がセンタ側送信部に相当する。

通信統括制御装置２０は、例えばプロセッサ、メモリ、Ｉ／Ｏ、これらを接続するバスを備え、メモリに記憶された制御プログラムを実行することで、データの収集に関する処理（以下、データ収集関連処理）を実行する。ここで言うところのメモリは、コンピュータによって読み取り可能なプログラム及びデータを非一時的に格納する非遷移的実体的記憶媒体（non-transitory tangible storage medium）である。また、非遷移的実体的記憶媒体は、半導体メモリ等によって実現される。通信統括制御装置２０は、車載端末３５からのデータアップロードを統括する。通信統括制御装置２０の詳細については、以下で述べる。

＜通信統括制御装置２０の概略構成＞
続いて、図６を用いて通信統括制御装置２０の概略的な構成について説明する。図６に示すように、通信統括制御装置２０は、データ価値判定データベース（以下、データ価値判定ＤＢ）２０１、交通情報データベース（以下、交通情報ＤＢ）２０２、収集データベース（以下、収集ＤＢ）２０３、代替可否判定部２０４、可能性判定部２０５、経路特定部２０６、車両検索部２０７、及び応答生成部２０８を機能ブロックとして備えている。なお、通信統括制御装置２０が実行する機能の一部又は全部を、１つ或いは複数のＩＣ等によりハードウェア的に構成してもよい。また、通信統括制御装置２０が備える機能ブロックの一部又は全部は、プロセッサによるソフトウェアの実行とハードウェア部材の組み合わせによって実現されてもよい。

データ価値判定ＤＢ２０１は、車載端末３５から要否の問い合わせを受けた対象データの代替の可否の判定に用いられる情報を格納している。一例としては、代替が可能な対象データのデータ種別の情報を格納している構成とすればよい。例えば、代替が可能な対象データのデータ種別として、再現性の高いデータのデータ種別の情報を格納している構成とすればよい。ここで言うところの再現性の高いデータとは、道路構造のデータ等の時間的な変化が少なく、且つ、偶発的な要素の乏しいデータを指す。一例としては、路面標示，地物等のデータが挙げられる。他にも、データ種別及びデータ生成位置別の対象データの収集状況の情報が格納されている構成としてもよい。これは、十分に収集できているデータを、代替が可能な対象データとして判定するのに用いるためである。

交通情報ＤＢ２０２は、地図上の道路区間別の平均交通流量の情報を格納している。平均交通流量は、単位時間あたりの通過車両の台数で表してもよいし、複数段階のレベル分けによって表してもよい。平均交通流量は、複数の車両の車載端末３５から収集した対象データのデータ生成情報の蓄積によって統計的に算出されたものを用いればよい。他にも、道路区間の種類に応じて推定されたものを用いてもよい。例えば、市街地は郊外よりも平均交通流量が多いと推定される。

収集ＤＢ２０３は、複数の車両の車載端末３５から収集した対象データ及びその対象データのデータ生成情報を格納する。収集ＤＢ２０３は、収集した対象データを、その対象データの生成情報と紐付けて格納しておく構成とすればよい。また、収集ＤＢ２０３は、対象データの他にも、各車両の車載端末３５から送信されてくる、それらの車両の残量情報，残量予測値，予測経路，現在位置等も車両別に格納しておく構成とすればよい。各車両のデータの区別は、各車両から各車両のデータを識別可能な情報を付与してデータを送信させることで可能とすればよい。各車両のデータを識別可能な情報としては、車両ＩＤ，無線通信装置３４の機器ＩＤ等が挙げられる。

なお、データ種別及びデータ生成位置別の対象データの収集状況の情報といった、データ価値判定ＤＢ２０１の一部の情報は、収集ＤＢ２０３に格納される情報を利用してもよい。

また、収集ＤＢ２０３は、キャッシュ残量ＤＢ２３１及び予測経路ＤＢ２３２を含む。キャッシュ残量ＤＢ２３１は、各車両の車載端末３５から送信されてきた残量情報，残量予測値を格納する。つまり、キャッシュ残量ＤＢ２３１は、車両別の残量情報，残量予測値を格納する。キャッシュ残量ＤＢ２３１は、残量情報及び残量予測値のうちの少なくとも残量情報を格納する構成とすればよい。予測経路ＤＢ２３２は、各車両の車載端末３５から送信されてきた予測経路を格納する。つまり、予測経路ＤＢ２３２は、車両別の予測経路を格納する。予測経路ＤＢ２３２は、車両の予測経路に、その車両の車載端末３５から送信されてきた現在位置も紐付けて格納する構成としてもよい。

代替可否判定部２０４は、車載端末３５からの対象データの要否の問い合わせを受信部２２１で受信した場合に、その対象データの代替の可否を判定する。例えば、代替可否判定部２０４は、その問い合わせに含まられるデータ生成時情報のうちのデータ種別をもとに、データ価値判定ＤＢ２０１に格納される情報を参照して、対象データが代替可能か否かを判定すればよい。この代替可否判定部２０４での対象データの代替の可否を判定する工程が代替可否判定工程に相当する。

可能性判定部２０５は、代替可否判定部２０４で代替が可能と判定した対象データについて、その対象データを再取得できる可能性（以下、再取得可能性）を判定する。再取得可能性は、その対象データの要否の問い合わせを送信してきた車両に限らず、その車両以外でその対象データを再取得できる可能性とすればよい。なお、再取得可能性は、その対象データの要否の問い合わせを送信してきた車両以外でその対象データを再取得できる可能性としてもよい。

一例として、可能性判定部２０５は、受信部２２１で受信した要否の問い合わせに含まれるデータ生成時情報のうちのデータ生成位置と、交通情報ＤＢ２０２に格納されている平均交通流量の情報とから、その対象データの再取得可能性を判定すればよい。詳しくは、可能性判定部２０５は、その対象データのデータ生成位置の平均交通流量が多くなるのに応じて再取得可能性を高く判定する。一方、可能性判定部２０５は、その対象データのデータ生成位置の平均交通流量が少なくなるのに応じて再取得可能性を低く判定する。

再取得可能性は平均交通流量に応じた連続値であってもよいし、複数段階にレベル分けした値であってもよい。再取得可能性は、再取得可能性ありと再取得可能性なしとの２値であってもよいが、以降では３値以上の複数の値で表現されるものとする。なお、再取得可能性の判定には、同じ対象データの再取得のしやすさに応じて変動する情報であれば、平均交通流量以外の情報を用いる構成としてもよい。この可能性判定部２０５での再取得可能性を判定する工程が代替可否判定工程に相当する。

経路特定部２０６は、予測経路ＤＢ２３２に格納されている車両別の予測経路から、車両の予定走行経路を特定する。一例として、予測経路を予定走行経路として特定すればよい。この予測経路が経路特定情報に相当する。経路特定部２０６は、処理負荷を軽減するために、対象データの要否の問い合わせを送信してきた車両の現在位置から一定の距離内の車両に絞って予定走行経路を特定してもよい。なお、経路特定部２０６は、予測経路ＤＢ２３２に格納されている車両別の予測経路から予定走行経路を特定する構成に限らない。例えば、車両別の現在位置と目的地とから車両別の予測経路を算出し、これらの予測経路を予定走行経路と特定してもよい。この現在位置及び目的地も経路特定情報に相当する。

車両検索部２０７は、対象データの要否の問い合わせを送信してきた車両よりも、その対象データを収集するのに適した車両が存在するか判定する検索処理を行う。検索処理の詳細については後述する。

応答生成部２０８は、対象データの要否の問い合わせに対する通知を生成して、その通知を送受信サーバ２１からその問い合わせを送信してきた車載端末３５へ返信する。応答生成部２０８での処理の詳細については後述する。

＜要否応答関連処理＞
ここで、図７～図８のフローチャートを用いて、通信統括制御装置２０での対象データの要否の問い合わせへの応答に関連する処理（以下、要否応答関連処理）の流れの一例について説明を行う。図７のフローチャートは、受信部２２１で対象データの要否の問い合わせを受信した場合に開始する構成とすればよい。プロセッサによって要否応答関連処理に含まれるステップが実行されることが、データ収集方法が実行されることに相当する。また、通信制御装置３０のプロセッサと通信統括制御装置２０のプロセッサによってそれぞれデータ取得関連処理に含まれるステップと要否応答関連処理に含まれるステップとが実行されることも、データ収集方法が実行されることに相当する。

まず、ステップＳ１０１では、代替可否判定部２０４が、受信部２２１で要否の問い合わせを受信した対象データの代替の可否を判定する。ステップＳ１０２では、Ｓ１０１で代替が可能と判定した場合（Ｓ１０２でＹＥＳ）には、ステップＳ１０３に移る。一方、Ｓ１０１で不可能と判定した場合（Ｓ１０２でＮＯ）には、ステップＳ１０８に移る。

ステップＳ１０３では、可能性判定部２０５が、その対象データについての再取得可能性を判定する。ステップＳ１０４では、Ｓ１０３で判定した再取得可能性が閾値以上であった場合（Ｓ１０４でＹＥＳ）には、ステップＳ１０５に移る。一方、Ｓ１０３で判定した再取得可能性が閾値未満であった場合（Ｓ１０４でＮＯ）には、ステップＳ１０８に移る。ここで言うところの閾値は、再取得が見込まれるか否かを区別するための値であって、任意に設定可能な値である。

ステップＳ１０５では、車両検索部２０７が検索処理を行って、対象データの取得に最適な車両を判断し、ステップＳ１０６に移る。ここで、図８を用いて、検索処理の流れの一例について説明を行う。

ステップＳ１５１では、車両検索部２０７が、受信部２２１で要否の問い合わせを受信した対象データの取得位置が、経路特定部２０６で特定する予定走行経路に含まれる車両を検索する。対象データの取得位置としては、要否の問い合わせに含まれるその対象データのデータ生成位置を用いればよい。検索の対象とする車両は、要否の問い合わせを送信してきた車載端末３５を搭載する車両（以下、問い合わせ元車両）以外の車両とすればよい。

ステップＳ１５２では、Ｓ１５１での検索の結果、対象となる車両（つまり、対象車両）があった場合（Ｓ１５２でＹＥＳ）には、ステップＳ１５３に移る。一方、Ｓ１５１での検索の結果、対象車両がなかった場合（Ｓ１５２でＮＯ）には、ステップＳ１５６に移る。

ステップＳ１５３では、車両検索部２０７が、Ｓ１５１での検索で得られた対象車両から、受信部２２１で要否の問い合わせを受信した対象データをキャッシュメモリ３２２に保持可能な車両を検索する。一例としては、以下のようにすればよい。車両検索部２０７は、キャッシュ残量ＤＢ２３１に格納されている残量予測値を用いて、その残量予測値を送信してきた車載端末３５のキャッシュメモリ３２２に、要否の問い合わせが行われた対象データを保持できるか否かを判定する。よって、車両検索部２０７が保持可否判定部に相当する。判定を行う対象は、Ｓ１５１での検索で得られた対象車両とすればよい。また、残量予測値の代わりに、キャッシュ残量ＤＢ２３１に格納されている残量情報を用いてもよい。残量予測値及び残量情報が残量特定情報に相当する。要否の問い合わせが行われた対象データを保持できると判定されるキャッシュメモリ３２２を搭載する車両が、Ｓ１５３の検索条件に合った車両とする。

ステップＳ１５４では、Ｓ１５３での検索の結果、対象となる車両（つまり、対象車両）があった場合（Ｓ１５４でＹＥＳ）には、ステップＳ１５５に移る。一方、Ｓ１５３での検索の結果、対象車両がなかった場合（Ｓ１５４でＮＯ）には、ステップＳ１５６に移る。一例として、Ｓ１５３の処理で、要否の問い合わせが行われた対象データを保持できると判定されるキャッシュメモリ３２２を搭載する車両が存在した場合に、その車両が対象車両となる。

ステップＳ１５５では、車両検索部２０７が、問い合わせ元車両以外の、Ｓ１５３での検索の結果として得られた対象車両が対象データの取得に最適な車両であるものと判断し、ステップＳ１０６に移る。一方、ステップＳ１５６では、車両検索部２０７が、問い合わせ元車両が対象データの取得に最適な車両であるものと判断し、ステップＳ１０６に移る。

なお、Ｓ１５５では、車両検索部２０７が、Ｓ１５３での検索の結果として得られた対象車両のうち、要否の問い合わせが行われた対象データの代わりとなる対象データを送信可能となるまでキャッシュメモリ３２２に保持している時間が最も短い車両を検索する構成としてもよい。要否の問い合わせが行われた対象データの代わりとなる対象データとは、要否の問い合わせが行われた対象データと同じデータ生成位置で取得される対象データである。この検索は、例えばＳ１５３での検索の結果として得られた対象車両の予定走行経路及び現在位置と、通信資源マップとを用いて行えばよい。通信資源マップについては、前述しとの同様のものを通信統括制御装置２０が取得することで利用可能な構成とすればよい。詳しくは、通信資源マップ上の無線リソースの空きのあるエリアに最も早く到達すると推定される車両を検索すればよい。以上の構成によれば、利用可能な通信資源の最も多い経路を走行するとともに、キャッシュメモリ３２２の対象データの入れ替えが最も早い車両が抽出されることになる。通信統括制御装置２０は、検索したこの車両の車載端末３５に向けて、要否の問い合わせが行われた対象データと同じ対象データの保持を行わせる通知を送信させる構成としてもよい。

図７に戻って、ステップＳ１０６では、Ｓ１０５で検索した車両が問い合わせ元車両に該当しない非該当の場合（Ｓ１０６でＹＥＳ）には、ステップＳ１０７に移る。一方、Ｓ１０５で検索した車両が問い合わせ元車両に該当する場合（Ｓ１０６でＮＯ）には、ステップＳ１０８に移る。

ステップＳ１０７では、応答生成部２０８が、要否の問い合わせが行われた対象データの破棄を行わせる破棄通知を生成する。一方、ステップＳ１０８では、応答生成部２０８が、要否の問い合わせが行われた対象データの保持を行わせる破棄通知を生成する。ステップＳ１０９では、Ｓ１０７で破棄通知を生成した場合には、応答生成部２０８が、送受信サーバ２１から対象データの要否の問い合わせを送信してきた車載端末３５へこの破棄通知を返信させる。一方、Ｓ１０８で保持通知を生成した場合には、応答生成部２０８が、送受信サーバ２１から対象データの要否の問い合わせを送信してきた車載端末３５へこの保持通知を返信させる。このＳ１０９の処理工程がセンタ側送信工程に相当する。

ここで、図９～図１１を用いて、本実施形態の一例の概略について説明を行う。図中のＧＰは、対象データの取得位置をしめす。Ａは、取得位置ＧＰでの対象データの取得に際してキャッシュメモリ３３２の記憶容量不足が予測される車両を示す。Ｂは、キャッシュメモリ３３２の記憶容量に余裕のある、取得位置ＧＰを予定走行経路に含む車両を示す。Ｃは、キャッシュメモリ３３２の記憶容量に余裕のある、取得位置ＧＰを予定走行経路に含まない車両を示す。ＡＲ１～８は、それぞれ異なる基地局エリアを示す。ＡＲ１～８のうちの実線で示す円は無線リソースに空きがあることを示す。ＡＲ１～８のうちの破線で示す円は無線リソースに空きがないことを示す。

図９の場面では、車両Ａが基地局エリアＡＲ３の取得位置ＧＰで対象データを取得する。しかしながら、車両Ａは、無線リソースに空きがなく、キャッシュメモリ３３２の記憶容量不足が予測されるので、収集センタ２にこの対象データの要否の問い合わせを行う。この要否の問い合わせに対して、収集センタ２の通信統括制御装置２０は、車両Ａよりもこの対象データを収集するのに適した車両（以下、最適車両）があるか検索する。基地局エリアＡＲ８に位置する車両Ｃについては、取得位置ＧＰが予定走行経路に含まれないので、最適車両として検索されない。一方、基地局エリアＡＲ２に位置する車両Ｂについては、キャッシュメモリ３３２の記憶容量に余裕があり、取得位置ＧＰを予定走行経路に含むことから、最適車両として検索される。最適車両として車両Ａ以外の車両Ｂが検索されたので、通信統括制御装置２０は、車両Ａの車載端末３５に破棄通知を返信する。これによって、車両Ａでは取得した対象データがキャッシュメモリ３３２に保持されずに破棄され、キャッシュメモリ３３２の記憶容量不足に至らずに済む。

続いて、図１０の場面では、車両Ｂが予定経路に沿って基地局エリアＡＲ２から基地局エリアＡＲ３まで走行し、予定通りに取得位置ＧＰに到達する。車両Ｂは、取得位置ＧＰにおいて、車両Ａが破棄した取得データを取得する。基地局エリアＡＲ３では、無線リソースに空きがないため、車両Ｂの車載端末３５は取得したこの対象データを送信せずにキャッシュメモリ３３２に保持する。車両Ａは、基地局エリアＡＲ３から基地局エリアＡＲ４まで走行する。基地局エリアＡＲ４は、無線リソースに空きがないので、車両Ａの車載端末３５は、キャッシュメモリ３３２に保持しているデータをまだ送信はしない。

続いて、図１１の場面では、車両Ａが、基地局エリアＡＲ４から基地局エリアＡＲ５まで走行する。基地局エリアＡＲ４は、無線リソースに空きがあるので、車両Ａの車載端末３５は、キャッシュ溢れが生じる前に、キャッシュメモリ３３２に保持しているデータを収集センタ２へ送信する。これにより、車両Ａが価値の高いデータをキャッシュメモリ３３２に保持していたとしても、この価値の高いデータを破棄せずに収集センタ２へ送信することが可能になる。また、車両Ｂは、基地局エリアＡＲ３から基地局エリアＡＲ６まで走行する。基地局エリアＡＲ６は、無線リソースに空きがあるので、車両Ｂの車載端末３５は、キャッシュ溢れが生じる前に、キャッシュメモリ３３２に保持しているデータを収集センタ２へ送信する。これにより、車両Ａが破棄した対象データが価値の高いデータだったとしても、車両Ｂがこの対象データを収集センタ２へ送信することが可能になる。

＜実施形態１のまとめ＞
実施形態１の構成によれば、対象データの要否の問い合わせは、対象データを送信可能となるまで一時的に記憶しておくキャッシュメモリ３２２の記憶容量不足が予測された車載端末３５から送信される。キャッシュメモリ３２２の記憶容量不足が予測された車載端末３５で、取得したその対象データを送信可能となるまで保持すると、その後に取得する対象データを収集センタ２に送信できなくなる状況が生じやすくなる。これに対して、実施形態１の構成では、対象データの要否の問い合わせを送信してきた車載端末３５にその対象データの破棄を行わせる破棄通知を返信する一方、代替可否判定部２０４でその対象データの代替が不可能と判定した場合に、その対象データの要否の問い合わせを送信してきた車載端末３５にその対象データの保持を行わせる保持通知を返信することなる。代替が可能と判定される対象データであれば、破棄通知によって破棄されたとしても、収集センタ２はその対象データを代替できる可能性が高い。また、破棄通知によって対象データが破棄されることで、キャッシュメモリ３２２の記憶容量に余裕を持たせ、その後に取得する対象データを収集センタ２に送信できなくなる状況を生じにくくすることが可能になる。一方、代替が不可能と判定される対象データは、代替できない可能性が高いが、保持通知によって対象データを保持させるため、車載端末３５でその対象データを送信可能となった際に収集センタ２で収集できる可能性が高まる。その結果、複数の車両の車載端末３５からデータを収集する場合に、価値の高いデータを収集できない状況を生じにくくさせることが可能になる。

このように、実施形態１の構成によれば、各車両の車載端末３５と収集センタ２とが連携し、各車両のキャッシュメモリ３２２の使用量を平準化することが可能になる。よって、偏った車両でのキャッシュメモリ３２２のキャッシュ溢れを抑止して、価値の高いデータが破棄される状況を生じにくくし、価値の高いデータを収集センタ２で収集できない状況を生じにくくすることが可能になる。

実施形態１の構成によれば、代替可否判定部２０４で対象データの代替が可能と判定した場合であっても、可能性判定部２０５で判定したその対象データについての再取得可能性が閾値未満の場合には、その対象データの要否の問い合わせを送信してきた車載端末３５に保持通知を返信する。これによれば、代替が可能であっても再取得可能性が低い、収集センタ２で再度取得できない可能性が高い対象データを、要否の問い合わせを送信してきた車載端末３５で破棄させずに済む。よって、価値の高いデータを収集センタ２で収集できない状況をより生じにくくすることが可能になる。

実施形態１の構成によれば、代替可否判定部２０４で対象データの代替が可能と判定した場合であって、且つ、可能性判定部２０５で判定したその対象データについての再取得可能性が閾値以上の場合であっても、経路特定部２０６で特定する予定走行経路にその対象データの取得位置が含まれる車両が存在しない場合は、その対象データの送信の問い合わせを送信してきた車載端末３５に保持通知を返信する。これによれば、再取得可能性が高くても、実際に対象データを取得する予定の車両が存在せず、他の車両で再取得できないと推測される場合に、収集センタ２で再度取得できない可能性が高い対象データを、要否の問い合わせを送信してきた車載端末３５で破棄させずに済む。よって、価値の高いデータを収集センタ２で収集できない状況をより生じにくくすることが可能になる。

実施形態１の構成によれば、代替可否判定部２０４で対象データの代替が可能と判定した場合であって、可能性判定部２０５で判定したその対象データについての再取得可能性が閾値以上である場合であって、且つ、経路特定部２０６で特定する予定走行経路にその対象データの取得位置が含まれる車両が存在する場合であっても、その車両のうちに車両検索部２０７で対象データを保持できると判定したキャッシュメモリ３２２を搭載する車両が含まれない場合は、その対象データの送信の問い合わせを送信してきた車載端末３５に保持通知を返信する。これによれば、実際に対象データを取得する予定の車両が存在したとしても、キャッシュメモリ３２２の記憶容量不足を生じさせずに済む車両がなく、他の車両で保持できない可能性が高い対象データを、要否の問い合わせを送信してきた車載端末３５で破棄させずに済む。よって、価値の高いデータを収集センタ２で収集できない状況をより生じにくくすることが可能になる。

（実施形態２）
実施形態１では、通信制御装置３０と無線通信装置３４とが別体の構成を示したが、必ずしもこれに限らない。例えば、通信制御装置３０と無線通信装置３４とが一体の構成であってもよい。

なお、本開示は、上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本開示の技術的範囲に含まれる。また、本開示に記載の制御部及びその手法は、コンピュータプログラムにより具体化された１つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の装置及びその手法は、専用ハードウェア論理回路により、実現されてもよい。もしくは、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと１つ以上のハードウェア論理回路との組み合わせにより構成された１つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

１ データ収集システム、２ 収集センタ、３ 車両側ユニット、２０ 通信統括制御装置、２１ 送受信サーバ、３０ 通信制御装置、３４ 無線通信装置（車両側送信部）、３５ 車載端末、２０４ 代替可否判定部、２０５ 可能性判定部、２０６ 経路特定部、２０７ 車両検索部（保持可否判定部）、２２１ 受信部（センタ側受信部）、２２２ 送信部（センタ側送信部）、３１７ データ取得部、３１９ データ価値判定部（価値判定部）、３２０ データ送信制御部（容量不足予測部）、３２１ キャッシュメモリ管理部（記憶処理部）、３２２ キャッシュメモリ（一時記憶部）

Claims (8)

1. 車両に搭載され、前記車両の走行によって得られるデータを取得するデータ取得部（３１７）と、前記データ取得部で取得した前記データを送信する車両側送信部（３４）とを備える車載端末（３５）と、
   複数の前記車両の前記車載端末から送信される前記データを受信するセンタ側受信部（２２１）を備える収集センタ（２）とを含み、
   前記車載端末は、
   前記データ取得部で取得した前記データを、前記車両側送信部で送信可能となるまで一時的に記憶しておく一時記憶部（３２２）と、
   前記一時記憶部の記憶容量不足を予測する容量不足予測部（３２０）を備え、
   前記車両側送信部は、前記データ取得部で前記データを取得した場合であって、前記容量不足予測部で前記一時記憶部の記憶容量不足が予測される場合に、そのデータの要否の問い合わせを前記収集センタに送信し、
   前記収集センタの前記センタ側受信部は、前記車載端末から送信される前記データの要否の問い合わせも受信するものであり、
   前記収集センタは、
   前記車載端末から送信される前記データの要否の問い合わせを前記センタ側受信部で受信した場合に、そのデータの代替の可否を判定する代替可否判定部（２０４）と、
   前記代替可否判定部でそのデータの代替が可能と判定したことをもとに、そのデータの要否の問い合わせを送信してきた前記車載端末にそのデータの破棄を行わせる破棄通知を返信する一方、前記代替可否判定部でそのデータの代替が不可能と判定した場合に、そのデータの要否の問い合わせを送信してきた前記車載端末にそのデータの保持を行わせる保持通知を返信するセンタ側送信部（２２２）と、
   前記代替可否判定部で代替が可能と判定した前記データについて、そのデータを再取得できる可能性である再取得可能性を判定する可能性判定部（２０５）とを備え、
   前記センタ側送信部は、前記代替可否判定部で前記データの代替が可能と判定した場合には、前記可能性判定部で判定したそのデータについての前記再取得可能性が閾値以上であることをもとに、そのデータの要否の問い合わせを送信してきた前記車載端末に前記破棄通知を返信する一方、前記可能性判定部で判定したそのデータについての前記再取得可能性が前記閾値未満の場合には、そのデータの要否の問い合わせを送信してきた前記車載端末に前記保持通知を返信し、
   前記車載端末は、
   前記破棄通知を受信した場合には、要否の問い合わせを行ったデータを破棄して前記一時記憶部にそのデータを記憶しない一方、前記保持通知を受信した場合には、要否の問い合わせを行ったデータを前記一時記憶部に記憶する記憶処理部（３２１）を備えるデータ収集システム。
2. 請求項１において、
   前記車両側送信部は、前記データの要否の問い合わせに加えて、そのデータの取得位置も前記収集センタに送信するものであり、
   前記センタ側受信部は、前記車載端末から送信される前記データの要否の問い合わせに加え、その車載端末から送信されるそのデータの取得位置も受信するものであり、
   前記可能性判定部は、前記代替可否判定部で代替が可能と判定した前記データについて、前記センタ側受信部で受信したそのデータの取得位置をもとに、その取得位置の平均交通流量が多くなるのに応じて前記再取得可能性を高く判定する一方、その取得位置の平均交通流量が少なくなるのに応じて前記再取得可能性を低く判定するデータ収集システム。
3. 請求項１又は２において、
   前記車両側送信部は、前記データの要否の問い合わせに加えて、そのデータの取得位置も前記収集センタに送信する他、自端末としての前記車載端末を搭載する前記車両の予定走行経路を特定できる経路特定情報も前記収集センタに送信するものであり、
   前記センタ側受信部は、前記車載端末から送信される前記データの要否の問い合わせに加え、その車載端末から送信されるそのデータの取得位置も受信する他、複数の前記車両の前記車載端末から送信される前記経路特定情報も受信するものであり、
   前記収集センタは、
   前記センタ側受信部で取得した前記経路特定情報を用いて、その経路特定情報を送信してきた前記車載端末を搭載する前記車両の予定走行経路を特定する経路特定部（２０６）を備え、
   前記センタ側送信部は、前記代替可否判定部で前記データの代替が可能と判定した場合であって、且つ、前記可能性判定部で判定したそのデータについての前記再取得可能性が閾値以上である場合に、前記経路特定部で特定する前記予定走行経路にそのデータの取得位置が含まれる前記車両が存在することをもとに、そのデータの要否の問い合わせを送信してきた前記車載端末に前記破棄通知を返信する一方、前記経路特定部で特定する前記予定走行経路にそのデータの取得位置が含まれる前記車両が存在しない場合は、そのデータの送信の問い合わせを送信してきた前記車載端末に前記保持通知を返信するデータ収集システム。
4. 請求項３において、
   前記車両側送信部は、前記一時記憶部の記憶容量残量を特定できる残量特定情報も前記収集センタに送信するものであり、
   前記収集センタは、
   前記センタ側受信部で取得した前記残量特定情報を用いて、その残量特定情報を送信してきた前記車載端末の前記一時記憶部に、前記要否の問い合わせが行われた前記データを保持できるか否かを判定する保持可否判定部（２０７）を備え、
   前記センタ側送信部は、前記代替可否判定部で前記データの代替が可能と判定した場合であって、前記可能性判定部で判定したそのデータについての前記再取得可能性が閾値以上である場合であって、且つ、前記経路特定部で特定する前記予定走行経路にそのデータの取得位置が含まれる前記車両が存在する場合に、その車両のうちに前記保持可否判定部で前記データを保持できると判定した前記一時記憶部を搭載する車両が含まれる場合には、そのデータの要否の問い合わせを送信してきた前記車載端末に前記破棄通知を返信する一方、その車両のうちに前記保持可否判定部で前記データを保持できると判定した前記一時記憶部を搭載する車両が含まれない場合は、そのデータの送信の問い合わせを送信してきた前記車載端末に前記保持通知を返信するデータ収集システム。
5. 請求項１～４のいずれか１項において、
   前記車載端末は、
   前記データ取得部で取得した前記データの価値を判定する価値判定部（３１９）を備え、
   前記車両側送信部は、前記データ取得部で取得した前記データのうち、前記価値判定部で判定した前記データの価値の高さが高くなるのに応じて高く決定される優先順位が高い前記データから順番に、送信可能なタイミングで前記データを送信するデータ収集システム。
6. 複数の車両のそれぞれに搭載される車載端末で取得して送信される、それぞれの車両の走行によって得られるデータを受信するセンタ側受信部（２２１）と、
   取得した前記データを送信可能となるまで一時的に記憶しておく一時記憶部の記憶容量不足が予測された前記車載端末から送信される、その車載端末で取得した前記データの要否の問い合わせを前記センタ側受信部で受信した場合に、そのデータの代替の可否を判定する代替可否判定部（２０４）と、
   前記代替可否判定部でそのデータの代替が可能と判定したことをもとに、そのデータの要否の問い合わせを送信してきた前記車載端末にそのデータの破棄を行わせる破棄通知を返信する一方、前記代替可否判定部でそのデータの代替が不可能と判定した場合に、そのデータの要否の問い合わせを送信してきた前記車載端末にそのデータの保持を行わせる保持通知を返信するセンタ側送信部（２２２）と、
   前記代替可否判定部で代替が可能と判定した前記データについて、そのデータを再取得できる可能性である再取得可能性を判定する可能性判定部（２０５）とを備え、
   前記センタ側送信部は、前記代替可否判定部で前記データの代替が可能と判定した場合には、前記可能性判定部で判定したそのデータについての前記再取得可能性が閾値以上であることをもとに、そのデータの要否の問い合わせを送信してきた前記車載端末に前記破棄通知を返信する一方、前記可能性判定部で判定したそのデータについての前記再取得可能性が前記閾値未満の場合には、そのデータの要否の問い合わせを送信してきた前記車載端末に前記保持通知を返信する収集センタ。
7. 少なくとも１つのプロセッサにより実行される、
   複数の車両のそれぞれに搭載される車載端末で取得して送信される、それぞれの車両の走行によって得られるデータを受信するセンタ側受信工程と、
   取得した前記データを送信可能となるまで一時的に記憶しておく一時記憶部の記憶容量不足が予測された前記車載端末から送信される、その車載端末で取得した前記データの要否の問い合わせを受信した場合に、そのデータの代替の可否を判定する代替可否判定工程と、
   前記代替可否判定工程でそのデータの代替が可能と判定したことをもとに、そのデータの要否の問い合わせを送信してきた前記車載端末にそのデータの破棄を行わせる破棄通知を返信する一方、前記代替可否判定工程でそのデータの代替が不可能と判定した場合に、そのデータの要否の問い合わせを送信してきた前記車載端末にそのデータの保持を行わせる保持通知を返信するセンタ側送信工程と、
   前記代替可否判定工程で代替が可能と判定した前記データについて、そのデータを再取得できる可能性である再取得可能性を判定する可能性判定工程とを含み、
   前記センタ側送信工程では、前記代替可否判定工程で前記データの代替が可能と判定した場合には、前記可能性判定工程で判定したそのデータについての前記再取得可能性が閾値以上であることをもとに、そのデータの要否の問い合わせを送信してきた前記車載端末に前記破棄通知を返信する一方、前記可能性判定工程で判定したそのデータについての前記再取得可能性が前記閾値未満の場合には、そのデータの要否の問い合わせを送信してきた前記車載端末に前記保持通知を返信するデータ収集方法。
8. 請求項７において、
   少なくとも１つのプロセッサにより実行される、
   前記車載端末で前記車両の走行によって得られるデータを取得するデータ取得工程と、
   前記データ取得工程で取得した前記データを前記車載端末から収集センタに送信するデータ送信工程と、
   前記データ取得工程で取得した前記データを、前記データ送信工程で送信可能となるまで一時的に記憶しておく前記車載端末の一時記憶部（３２２）の記憶容量不足を予測する容量不足予測工程と、
   前記データ取得工程で前記データを取得した場合であって、前記容量不足予測工程で前記一時記憶部の記憶容量不足が予測される場合に、そのデータの要否の問い合わせを前記車載端末から前記収集センタに送信する要否問い合わせ工程と、
   前記車載端末で前記破棄通知を受信した場合には、前記要否問い合わせ工程で要否の問い合わせを行ったデータを破棄して前記一時記憶部にそのデータを記憶しない一方、前記保持通知を受信した場合には、前記要否問い合わせ工程で要否の問い合わせを行ったデータを前記一時記憶部に記憶する記憶処理工程とを含むデータ収集方法。

Images