以下、添付図面を参照して、実施形態に係るデータ収集装置、データ収集システムおよびデータ収集方法について詳細に説明する。なお、本実施形態によりこの発明が限定されるものではない。
まず、図1を用いて実施形態に係るデータ収集方法の概要について説明する。図1は、データ収集方法の概要を示す図である。なお、かかるデータ収集方法は、図1に示すデータ収集装置1および各車両に搭載された車載装置50(図2参照)間でデータ通信を行うことで実現される。
データ収集装置1は、データの利用者からデータの収集要求を受け付けるとともに、受け付けた収集要求に基づき、車載装置50からデータを収集し、収集したデータを各利用者へ提供するサーバ装置である。
図1に示す例では、利用者がサービスプロバイダ、開発者、一般ユーザである場合を示す。すなわち、データ収集装置1は、これら利用者が所望するデータを利用者に代わって収集し、収集したデータを提供する。
具体的には、データ収集装置1は、各車両から走行位置に関する位置データを取得する(ステップS1)。続いて、データ収集装置1は、位置データに基づいて走行データを収集する車両を選択する(ステップS2)。
例えば、データ収集装置1は、車両による渋滞が発生した場合もしくは渋滞の発生が予測された場合、渋滞地点へ向かう各車両について走行データを収集する車両として選択する。続いて、データ収集装置1は、ステップS2にて選択した車両から走行データを収集する(ステップS3)。
ここで、各車両の走行速度を示す速度データなどデータ種別を指定して走行データを収集することが可能である。これにより、データ収集装置1は、指定した走行データのみを収集することができる。すなわち、データ収集装置1は、指定したデータのみを収集することで、通信負荷を抑えることができるとともに、データ収集装置1に一度に多くのデータの集約によるデータ収集装置1のサーバダウンの発生を抑制することができる。
また、データ収集装置1は、収集した走行データを解析することで、渋滞に関係する各車両の挙動を詳細に把握することができる。そして、データ収集装置1は、収集した走行データに基づいて各車両が走行すべき走行車線を決定する(ステップS4)。
例えば、データ収集装置1は、各走行車線において渋滞が緩和もしくは、渋滞の発生自体を抑制するように、各車両の走行すべき走行車線を決定することができる。そして、データ収集装置1は、各車両に対して決定した走行車線に関する車線情報をそれぞれ通知する(ステップS5)。
そして、各車両がデータ収集装置1によって決定された走行車線を走行することで、渋滞を緩和することができる。このような、走行車線の決定は、特に、高速道路などにおいて、本線車線と、本線車線へ合流する合流車線とが交わる合流地点において有効である。
この場合、データ収集装置1は、合流車線を走行する車両と、本線を走行する車両のそれぞれの車速データを収集することで、それぞれの車両が合流地点へ到着する時刻を算出することが可能である。
このとき、データ収集装置1は、それぞれの車両の合流地点への到着時刻が一致する場合、本線を走行する車両に対して、追い越し車線を走行するように予め通知しておくことができる。これにより、それぞれの車両が互いに円滑に走行することが可能となる。
また、高速道路の出口付近の渋滞の場合には、渋滞地点に到達する前(余裕を持って)に出口側の車線から離脱する側の車線に車線変更する指示を行うことにより、渋滞範囲付近での無理な車線変更の多発を抑止でき、無理な車線変更による各車両走行の非円滑化による渋滞の悪化を防止できる。
このように、実施形態に係るデータ収集装置1は、渋滞の緩和または渋滞の発生を抑制するために必要なデータに絞ったうえで、各車載装置50から収集する。これにより、データ収集装置1および各車載装置50間の通信負荷を抑えることが可能となる。
したがって、データ収集装置1は、迅速にデータを収集することが可能となる。そして、データ収集装置1は、収集したデータを用いて走行車線を決定することで、迅速に収集したデータを有効に活用することが可能となる。
次に、図2を用いて実施形態に係るデータ収集システムの構成について説明する。図2は、データ収集システムの構成例を示す図である。図2に示すように、データ収集システムSは、データ収集装置1と、複数の利用者端末10と、複数の車載装置50とを備える。
データ収集装置1、利用者端末10および車載装置50は、ネットワークNを介して接続される。データ収集装置1は、利用者端末10から受け付けた収集要求に基づき、各車載装置50からデータを収集し、利用者端末10へ提供する。
利用者端末10は、利用者が操作する端末であり、スマートフォンなどの携帯電話機や、タブレット端末や、PDAや、デスクトップ型PCや、ノート型PC等である。利用者
は、利用者端末10を操作し、上記の収集要求をデータ収集装置1へ送信することができる。また、利用者端末10は、データ収集装置1から提供されるデータを利用者へ提示することも可能である。なお、車載装置50を利用者端末10として用いることも可能である。
車載装置50は、各車両に搭載された通信装置である。車載装置50は、走行データを車両の走行情報などを内部の記憶媒体に記憶しておき、データ収集装置1から送信される送信要求に基づいてデータ収集装置1へ送信する。
次に、図3を用いて実施形態に係るデータ収集装置1の構成例について説明する。図3は、データ収集装置1のブロック図である。図3に示すように、データ収集装置1は、通信部2と、制御部3と、記憶部4とを備える。
通信部2は、ネットワークNとの間で情報の送受信を行う通信インターフェイスである。制御部3は、通信部2およびネットワークNを介して各々との間で各種の情報を送受信することができる。
制御部3は、収集部31と、選択部32と、決定部33と、送信部34とを備える。制御部3は、例えば、CPU(Central Processing Unit)、ROM(Read Only Memory)、RAM(Random Access Memory)、HDD(Hard Disk Drive)、入出力ポート
などを有するコンピュータや各種の回路を含む。
コンピュータのCPUは、例えば、ROMに記憶されたプログラムを読み出して実行することによって、制御部3の収集部31、選択部32、決定部33および送信部34として機能する。
また、制御部3の収集部31、選択部32、決定部33および送信部34の少なくともいずれか一部または全部をASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等のハードウェアで構成することもできる。
また、記憶部4は、例えば、RAMやHDDに対応する。RAMやHDDは、車両情報データベース41と、収集条件データベース42と、タグ情報データベース43と、実データデータベース44と、スコアデータベース45とを備える。なお、データ収集装置1は、有線や無線のネットワークで接続された他のコンピュータや可搬型記録媒体を介して上記したプログラムや各種情報を取得することとしてもよい。
車両情報データベース41は、各車両に関する車両情報テーブルを有する。図4は、車両情報テーブルの一例を示す図である。図4に示すように、車両情報テーブル41aは、「車載装置ID」、「所有者情報」、「車種情報」および「車載装備」等が互いに関連付けられた情報である。
「車載装置ID」は、各車載装置50を識別する識別子である。「所有者情報」は、車載装置50が搭載される車両の所有者に関する情報である。図4に示す例では、所有者情報として、所有者の氏名を示しているが、所有者情報に、所有者の性別、年齢、住所、職業などを含むようにしてもよい。
「車種情報」は、車両の車種に関する情報であり、車種名や、年式に関する情報である。「車載装備」は、車両の装備に関する情報である。例えば、車両情報には、カメラの有無や、カメラの種別等を示す情報が含まれる。
図3の説明に戻り、収集条件データベース42について説明する。収集条件データベース42は、利用者端末10から受け付けた収集条件に関する収集条件テーブルを有する。図5は、収集条件テーブルの一例を示す図である。
図5に示すように、収集条件テーブル42aは、「利用者ID」、「要求ID」および「収集条件」が互いに関連付けられた情報である。「利用者ID」は、利用者を識別する識別子である。
「要求ID」は、収集要求を識別するための識別子である。また、「収集条件」は、実データの収集条件を示す情報である。例えば、収集条件は、「対象車両条件」、「記録トリガ」、「収集内容」などが含まれる。
「対象車両条件」は、収集対象となる車両の条件を示し、「記録トリガ」は、車載装置50で、実データの記録を開始するトリガを示す。また、「記録内容」は、車載装置50に記録する実データを示す情報である。
図5に示す例では、要求ID「001」の対象車両が「○○社製」の車両であり、記録トリガが加速度(>○○G)であり、収集内容が位置情報および加速度(前後3秒分)である場合を示す。
この場合、車載装置50は、加速度が○○Gを超えたことを検知した場合に、加速度が○○Gを超えた時点を基準として前後3秒分の加速度のデータを位置情報と共に記録することになる。
また、要求ID「002」の対象車両が60代以上のユーザであり、記録トリガがブレーキ圧(>○○psi)であり、加速度が○○psiを超えた時点を基準として(前後5秒分)である場合を示す。
この場合、車載装置50は、ブレーキ圧が○○psiを超えたことを検知した場合に、加速度が○○Gを超えた時点を基準として前後5秒分のブレーキ圧のデータを位置情報と共に記録することになる。
また、要求ID「003」に示すように、対象車両を全車とすることも可能である。また、要求ID「003」に示すように、記録トリガを無くし、常時記録することも可能である。
図3の説明に戻り、タグ情報データベース43について説明する。タグ情報データベース43は、各車載装置50から送信されたタグ情報を格納するデータベースである。例えば、タグ情報データベースには、上記の要求ID毎にタグ情報に時刻に関する情報や、タグ情報IDや車載装置IDなどを付与して格納される。なお、タグ情報データベース43は、タグ情報記憶部の一例である。
実データデータベース44は、タグ情報に基づき、各車載装置50から収集した実データを記憶するデータベースである。タグ情報データベース43および実データデータベース44に格納された情報は、提供部35によって適宜利用者へ提供される。
スコアデータベース45は、車線走行指示に対する車両の尊守状況示す尊守情報を記憶する車両尊守情報記憶部として機能する。スコアデータベース45は、尊守情報として、各車両の尊守状況をスコア化してスコアテーブルを有する。上述のように、本実施形態では、各車両の走行車線を決定する。しかし、全ての車両が決定された走行車線を走行するとは限らない。このため、データ収集装置1が決定した走行車線に対して車両が実際に走行したか否かをスコアで管理する。
図6は、スコアテーブルの一例を示す図である。図6に示すように、スコアテーブル45aは、「車載装置ID」、「課金」、「スコア」、「解消条件」などが互いに関連付けられた情報である。
車載装置IDは、車載装置50を識別するための識別子である。「課金」は、課金しているか否かを示し、「スコア」は、車載装置50のスコアを示す。例えば、データ収集装置1は、課金しているユーザに対して、課金してないユーザよりも優遇して走行車線を決定したり、スコアが高いユーザに対して、スコアが低いユーザよりも優遇して走行車線を決定したりすることができる。
また、スコアが低いユーザについては、ペナルティを課すこともでき、そのペナルティを解消するための条件が図6に示す「解消条件」となる。図6に示す例では、「解消条件」が、連続5回または課金である場合を示す。この連続5回とは、データ収集装置1が決定した走行車線を5回連続で走行することを意味する。
図3の説明に戻り、制御部3の各構成について説明する。制御部3の収集部31は、各車両の走行位置に関する位置データおよび走行データを各車両にそれぞれ搭載された車載装置50から収集する。
例えば、収集部31は、各車両の走行位置に関する位置データを収集することができる。その後、収集部31は、後述する選択部32によって選択された車両の車載装置50から走行データを収集することも可能である。
また、収集部31は、収集した位置データをタグ情報データベース43へ登録すするとともに、収集した走行データを実データデータベース44へ登録する。なお、位置データは、タグ情報の一例に対応する。
また、収集部31は、収集対象となるデータの収集条件を含む収集要求を利用者端末10から受け付けることも可能である。収集部31は、収集条件を受け付けると、収集条件に対して上記の要求IDを付したうえで、収集条件データベース42へ登録する。
また、選択部32は、収集条件を満たす車両を選択する。選択部32は、車両情報データベース41を参照し、収集条件データベース42から収集条件を満たす車両を選択する。このとき、1つの車両が、複数の収集条件を満たす場合、1つの車両に対して複数の収集条件が適用される。
そして、選択部32は、車両毎の収集条件を示す収集条件ファイルを生成する。収集条件データベース42が更新された場合に、各収集条件ファイルを更新することも可能である。このとき、選択部32は、更新後の収集条件ファイルを送信部34へ通知する。
このとき、各車両の走行車線を決定するための収集条件として少なくとも位置データと走行車線データを設定し、タグ情報として少なくとも位置データを設定することで、収集部31は、走行車線を決定するために必要なデータを得ることができる。
選択部32は、収集部31によって収集された位置データに基づいて走行データを収集すべき車両を選択する。例えば、選択部32は、各車両の現在の位置データをマップに重畳することで、渋滞が発生中または、渋滞が発生する見込みの地点を推定する。
続いて、選択部32は、推定した渋滞に関する車両について走行データを収集する車両として選択する。なお、渋滞に関する車両とは、例えば、渋滞の発生地点または渋滞の発生が予測される予測地点に向かう車両を示す。
選択部32は、渋滞に関する車両を選択すると、当該車両の詳細な走行データに関する送信要求を送信部34を介して当該車両の車載装置50へ送信する。かかる送信要求には、データ種別を指定する情報や、データの期間に関する情報などが含まれる。
これにより、収集部31は、渋滞に関係する車両の車載装置50からのみ走行データを収集することが可能である。これにより、全ての車載装置50から常時走行データを収集する場合に比べて、ネットワークNおよびデータ収集装置1の負荷を抑えることが可能となる。
また、この際、選択部32は、位置データに加え、位置データの時刻に関する情報を考慮して車両を選択することができる。すなわち、選択部32は、各車両の最新の位置データから車両の走行経路を推定した上で、走行データを収集する車両を選択する。また、例えば、選択部32は、最新の位置データが現在時刻よりも所定時間以上経過したものである場合は、かかる位置データから現在の位置データを推定することにしてもよい。
決定部33は、選択部32によって選択された車両の車載装置50から収集した走行データに基づいて各車両が走行すべき走行車線を決定する。決定部33は、各車両の走行車線を決定すると、車両毎に走行すべき走行車線を示す車線情報を生成し、送信部74を介して各車載装置50へ送信する。
決定部33は、走行データに基づき、各車両の挙動を把握したうえで、各走行車線において渋滞が緩和もしくは、渋滞の発生を抑制するように、各車両の走行すべき走行車線を決定することができる。決定部33は、例えば、高速道路(特に渋滞が発生している)を走行中の車両等に、走行中の車線に適した走行車線変更等の指示を行うことができる。
このとき、決定部33は、特定の優先車両に対して他の車両とは異なる優先条件で走行車線を決定することもできる。ここで、特定の優先車両とは、課金している車両や、スコアが相対的に高い車両を示す。なお、優先車両に、救急車やパトカーなどの緊急車両などを含めるようにしてもよい。
決定部33は、優先車両について、比較的空いている走行車線や、優先車両専用の走行車線を決定することができる。すなわち、決定部33は、優先車両に対して他の車両よりも優遇して走行車線を決定する。これにより、他の車両に対して、スコアの向上や課金を促進することができる。
また、決定部33は、各車両に対して決定した走行車線に関する情報を各車両の車載装置50へ通知する。その後、決定部33は、各車両の走行データに基づいて、各車両がどの走行車線を走行したかを監視し、車両毎にスコアを算出し、スコアデータベース45を更新する。すなわち、決定部33は、決定した走行車線に対する各車両の尊守状況を監視した上で、スコアデータベース45を更新する。
また、決定部33は、各車両の性能に応じて、走行車線を決定することにしてもよい。すなわち、決定部33は、走行車線毎に類似する性能の車両が走行するように各車両の走行車線を決定することができる。
例えば、かかる性能は、排気量や、車両種別を示す。また、車両種別とは、スポーツカー、セダン、ワゴン、ミニバンなどを示す。決定部33は、これら性能に関する情報を車両情報データベース41から取得することができる。
このように、決定部33は、各車両の性能に基づき、各車両の走行車線を決定することで、各走行車線において、同様の性能を有する車両が走行することとなる。これにより、各走行車線における混雑を解消することができる。なお、決定部33は、各車両のドライバの運転傾向に基づいて各車両の走行車線を決定することにしてもよい。
送信部34は、選別要求送信部および送信要求送信部として機能する。送信部34は、選択部32によって生成された収集条件ファイルを各車載装置50へ送信することで、選別要求送信部としての機能を担う。
また、送信部34は、選択部32によって選択された車両の車載装置50に対して詳細な走行データの送信要求を送信することで、送信要求送信部としての機能を担う。これにより、上記の収集部31は、選択部32によって選択された車両の車載装置50のみから走行データを収集することとなる。
また、送信部34は、選択部32によって車両毎に生成された収集条件ファイルと、かかる収集条件ファイルの同期コマンドとを各車載装置50へ送信する。
また、送信部34は、タグ情報を利用者へ提供後、利用者によって指定されたタグ情報について、実データの送信要求を対象となる車載装置50へ送信する。
次に、図7を用いて車載装置50の構成例について説明する。図7は、車載装置50のブロック図である。なお、図7には、車両の車速を検出する車速センサ91、車両の舵角を検出する舵角センサ92、車両の加速度を検出するGセンサ93、車両の周辺を撮像するカメラ94および車両の位置を検出する位置検出装置95をあわせて示す。尚、位置検出装置95はGPS受信装置や、車輪回転速センサ等から構成される車速センサとジャイロ等の車両方向センサ等からなる自立航行装置により実現できる。
これら、車速センサ91、舵角センサ92、Gセンサ93、カメラ94および位置検出装置95は、CAN通信などの車載ネットワークBを介して車載装置50に接続される。
車載装置50は、通信部6と、制御部7と、記憶部8とを備える。通信部6は、ネットワークNとの間で情報の送受信を行う通信インターフェイスである。制御部7は、通信部2およびネットワークNを介して各々との間で各種の情報を送受信することができる。
制御部7は、取得部71と、検出部72と、選別部73と、送信部74とを備える。制御部7は、例えば、CPU(Central Processing Unit)、ROM(Read Only Memory)、RAM(Random Access Memory)、HDD(Hard Disk Drive)、入出力ポートなどを有するコンピュータや各種の回路を含む。
コンピュータのCPUは、例えば、ROMに記憶されたプログラムを読み出して実行することによって、制御部7の取得部71、検出部72、選別部73および送信部74として機能する。
また、制御部7の取得部71、検出部72、選別部73および送信部74の少なくともいずれか一部または全部をASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等のハードウェアで構成することもできる。
また、記憶部8は、例えば、RAMやHDDに対応する。RAMやHDDは、タグ情報記憶部81と、実データ記憶部82、収集条件記憶部83とを備える。なお、車載装置50は、有線や無線のネットワークで接続された他のコンピュータや可搬型記録媒体を介して上記したプログラムや各種情報を取得することとしてもよい。
タグ情報記憶部81について説明する。タグ情報は対応する実データのインデックスデータとしての役割を持つデータで、例えば利用者等が実データの確認必要性を判断するために用いる情報である。
尚、タグ情報については、利用者がそれを見て認識できるのが好ましいので、単に実データの一部・概要と言うものでは無く、実データを加工して利用者に認識し易くした、所謂メタデータの形式にするのが好ましい。
具体的には、トリガ(収集条件の成立時点)の日時データ、位置データ、実データのデータサイズ、トリガ発生原因の値レベル(例えば加速度値がトリガである場合、加速度値のレベル(閾値未満,~閾値2倍,~閾値3倍・・))と言ったものである。このタグ情報は実データに基づき生成されるもので、日時データ、位置データ等は検出値(有効数字を丸める加工等は必要に応じて行う)、レベル値は検出値の所定計算式での処理や検出値のテーブルデータを用いた処理等でタグ情報を生成できる。このようにして生成したタグ情報がタグ情報記憶部81に記憶される。
なお、タグ情報は実データに比べ容量が小さいので記憶容量の問題はあまり大きくないが、実データが消去に伴いタグ情報の必要性がなくなる(低下する)ので、記憶容量に余裕がなければ実データに同期して消去しても良い。
また、タグ情報は利用者による実データの選別・検索に用いられる事から、リアルタイム性が重要であるため、タグ情報を生成した際には速やかに(通信が可能であればすぐに)データ収集装置1に送信する処理となっている。
さらに、車載装置50に記憶されているタグ情報とデータ収集装置1に記憶されているタグ情報は同じデータである必要があるため、車載装置50側でタグ情報を更新(新規生成、削除)した場合はその情報を速やかにデータ収集装置1に送信し、データ収集装置1側のタグ情報も同期して更新する必要がある。なお、データ収集装置1側でタグ情報を消去した場合、車載装置50側では記憶装置の容量に余裕がなければタグ情報および対応する実データを消去しても良い。
実データ記憶部82は、収集条件を満たした収集対象種別の実データ(対象実データ)を記憶する記憶部である。実データ記憶部82には、実データとタグ情報とが対応付けられて記憶される。例えば、実データ記憶部82は、リングバッファ方式の記憶媒体であり、例えば記憶保持指定等の特別な設定がなされない限り、古い実データから順に新しいデータへ随時上書きされる。
収集条件記憶部83は、車載装置50毎のデータ収集条件が記載された記憶部である。図8は、収集条件記憶部83の一例を示す図である。
図8に示すように、収集条件記憶部83は、複数の領域に分割される。収集条件記憶部83の各領域には、利用目的がそれぞれ異なる収集条件が格納される。
具体的には、収集条件記憶部83は、サービス領域R1と、必須領域R2と、開発領域R3と、自律生成領域R4とに分割される。サービス領域R1は、例えば、一般ユーザ向けのサービスを提供するサービスプロバイダまたはデータ収集装置1の管理者が一般ユーザ向けに提供するサービスが指定した収集条件を記憶する領域である。
必須領域R2は、データの収集が必須である収集条件を記憶する領域である。例えば、必須領域R2には、人命にかかわる収集条件が記憶される。具体的には、必須領域R2には、消防車や、警察車両などの緊急車両による収集条件が記憶される。必須領域R2のデータ収集条件(データ種別)は、例えば、位置情報であり、データ収集装置1は、かかる位置情報に基づき、各車両の位置情報をリアルタイムで把握することができる。
データ収集装置1は、各車両の近隣で火災、交通事故などが発生した場合に、現場近傍に位置する車載装置50に対してカメラ映像を要求する送信要求を送信する。そして、データ収集装置1は、カメラ映像を緊急車両へ提供することで、緊急車両が現場に到着するよりも早く、現場の様子を確認することができる。
また、開発領域R3は、車両の開発者の収集条件を格納する領域である。例えば、車両の開発者は、送信要求に基づき収集した実データを自動運転車両の開発に用いることが可能である。
また、自律生成領域R4は、車載装置50が自身で自律して生成した収集条件を記憶する領域である。例えば、車載装置50は、車両の異常を検出した場合に、異常に類似する現象に関する収集条件を生成し、自律生成領域R4に格納することができる。
これにより、例えば、データ収集装置1は、各車載装置50からタグ情報および実データを収集し、また、異常の原因を特定するためのデータを収集し、これらデータに基づき原因を特定したうえで、対応策を車載装置50へ送信することができる。
図7の説明に戻り、制御部7の取得部71について説明する。取得部71は、収集条件および収集要求をそれぞれデータ収集装置1から取得する。取得部71は、取得した収集条件を用いて記憶部8の収集条件記憶部83を更新する。これにより、記憶部8の収集条件記憶部83を最新のものへ更新する(データ収集装置1で記憶されている収集条件と同期)ことができる。
また、取得部71は、データ収集装置1から車線情報を取得すると、図示しない表示部を介してユーザへ通知することができる。また、車両が自動運転車両である場合、自動運転を制御する制御装置へ車線情報を通知することもできる。
検出部72は、収集条件記憶部83に格納された収集条件を満たすイベントを検出する。検出部72は、収集条件記憶部83に格納された収集条件を満たすイベントを検出した場合、かかる収集条件を満たすイベントに対する実データに基づきタグ情報を生成し、選別部73および送信部74へそれぞれ通知する。
また、検出部72は、例えば、車両の異常を検出した場合に、かかる異常に基づく収集条件を生成し、自律生成領域R4(図8参照)へ格納するとともに、送信部74を介してデータ収集装置1へ異常の解析を依頼することもできる。
選別部73は、検出部72から通知されるタグ情報に対して収集条件を満たす実データを対応付けて実データ記憶部82へ記憶する。すなわち、選別部73は、収集条件を満たす実データを選別して実データ記憶部82へ記憶することができる。
また、選別部73は、データ収集装置1から送信要求が送信された場合に、送信要求に基づき、送信要求によって指定された(データ収集装置1側でタグ情報に基づき利用者等により指定された実データ)を実データ記憶部82から選別し、送信部74へ通知することもできる。
送信部74は、上記の検出部72によって生成されたタグ情報をデータ収集装置1へ送信するとともに、選別部73によって選別された実データをデータ収集装置1へ送信する。
これにより、データ収集装置1は、各利用者が所望する実データおよびその実データに対応するタグデータを各利用者へ提供することが可能となる。
次に、図9を用いて実施形態に係るデータ収集装置1が実行する処理手順について説明する。図9は、実施形態に係るデータ収集装置1が実行する処理手順を示すフローチャートである。なお、この処理はデータ収集装置1が稼働中に繰り返し実行される。
次に、図9を用いて実施形態に係るデータ収集装置1が実行する処理手順について説明する。図9は、実施形態に係るデータ収集装置1が実行する処理手順を示すフローチャートである。
まず、図9に示すように、データ収集装置1は、位置データを収集し(ステップS101)、渋滞が発生するか否かを判定する(ステップS102)。データ収集装置1は、渋滞が発生すると判定した場合(ステップS102,Yes)、渋滞に関係する車両を選択する(ステップS103)。
続いて、データ収集装置1は、ステップS103にて選択した車両の車載装置50に対して走行データの送信要求を送信し(ステップS104)、走行データを収集する(ステップS105)。
続いて、データ収集装置1は、走行データに基づいて各車両の走行車線を決定し(ステップS106)、各車両の車載装置50へ走行車線に関する車線情報を通知する(ステップS107)。
その後、データ収集装置1は、各車両が走行車線を走行したか否かに応じてスコアを更新して(ステップS108)、処理を終了する。また、データ収集装置1は、ステップS102の判定において、渋滞が発生しないと判定した場合(ステップS102,No)、処理を終了する。
なお、ここでは、ステップS102の判定処理に応じて、ステップS103以降の処理を行う場合について説明したが、ステップS102の判定処理を省略して、ステップS103の処理へ移行することにしてもよい。
続いて、図10を用いて車載装置50が実行する処理手順について説明する。図10は、車載装置50が実行する処理手順を示すフローチャートである。なお、以下の処理手順は、車載装置50の稼働中に繰り返し実行される。
図10に示すように、まず、車載装置50は、タグ情報として位置データを送信し(ステップS201)、走行データに対する送信要求を取得したか否かを判定する(ステップS202)。車載装置50は、送信要求を取得した場合(ステップS202,Yes)、送信要求によって指定されたデータ種別を選別する(ステップS203)。
続いて、車載装置50は、選別した走行データを送信し(ステップS204)、車線情報を取得したか否かを判定する(ステップS205)。車載装置50は、車線情報を取得した場合(ステップS205,Yes)、車線情報を通知して処理を終了する。
一方、車載装置50は、ステップS202の処理において、送信要求を取得していない場合(ステップS202,No)、ステップS201の処理へ移行する。また、車載装置50は、ステップS205の処理において、車線情報を取得していない場合(ステップS205,No)、ステップS205の処理を継続して行う。
上述したように、実施形態に係るデータ収集装置1は、収集部31と、選択部32と、決定部33とを備える。収集部31は、各車両の走行位置に関する位置データを含む走行データを各車両に搭載された車載装置50から収集する。選択部32は、収集部31によって収集された位置データに基づいて収集部31が走行データを収集すべき車両を選択する。決定部33は、選択部32によって選択された車両の車載装置50から収集した走行データに基づいて車両が走行すべき走行車線を決定する。したがって、実施形態に係るデータ収集装置1によれば、収集したデータを有効に活用することができる。
ところで、上述した実施形態では、データ収集装置1が、各車両の走行車線を決定する場合について説明したが、これに限定されるものではない。特に、データ収集装置1で、各車両の走行車線を決定すると、データ収集装置1の処理負荷が増大し、サーバダウンを招く恐れもある。
このため、データ収集装置1は、走行車線を車載装置50に決定させることもできる。言い換えれば、走行車線の決定権を車載装置50へ譲渡することも可能である。図11は、決定権の譲渡の一例を示す図である。なお、図11では、車載装置50の記載を省略して示す。
図11に示すように、データ収集装置1の決定部33は、例えば、所定範囲A毎に、リーダ車両RCを決定する。そして、決定したリーダ車両RCの車載装置50へ所定範囲A内を走行する各車両の走行データを通知するととともに、決定権を譲渡する。
リーダ車両RCの車載装置50は、走行データに基づき、各車両の走行車線を決定し、例えば、データ収集装置1を介して所定範囲A内の各車両の車載装置50へ通知することができる。なお、この場合に、車車間通信を用いるなどして、データ収集装置1を介在させることなく、車線情報を通知することにしてもよい。
つまり、決定部33は、複数の車両を1つのグループと見做し、かかるグループにおいてリーダ車両RCを決定し、グループに属する各車両の走行車線についてリーダ車両RCの車載装置50へ委ねる。
これにより、決定部33が、すべての車両の走行車線を決定する場合に比べて、データ収集装置1の処理負荷を軽減することができる。
ところで、上述した実施形態では、データ収集装置1が、車載装置50からデータを収集する場合について説明したが、これに限定されるものではない。すなわち、データ収集装置1は、スマートフォンやタブレット端末などの端末装置からデータを収集することも可能である。
次に、データ収集技術について全般的な基本的動作について、図12A以降の添付図面を用いてより詳細に説明する。まず、図12A~図12Cを用いてデータ収集システムにおいてデータ利用者へデータが提供されるまでの一連の流れについて説明する。
図12A~図12Cは、データ収集システムの動作説明図である。図12Aに示すように、データ収集システムは、自動運転車の開発車等のデータ利用者が使用する端末装置205と、クラウド等で形成されたデータ収集装置(サーバ)200、各車両に搭載された車載装置Y1,Y2,Y3・・(車載装置全般を示す場合車載装置Yと記載する)から構成される。尚、車載装置Yとしては、カメラ、画像記憶部(メモリ)、加速度センサやGPS等の各種センサ、マイクロコンピュータ等を持つドライブレコーダを兼用利用するのが、ハード構成を効率的に兼用・利用できる点で有効である。
先ずデータ利用者はデータ収集装置200と接続された端末装置205によりデータ収集条件を設定する。また、この際に、データ収集装置200は、収集する実データに付加するデータ検索・概要把握に用いるインデックスデータ的な特性を持つタグデータ生成のためのタグデータ生成用データを作成する。
尚、タグデータ生成用データは端末装置205あるいはデータ収集装置200に記憶されたプログラムや生成用データを用いて、データ利用者の操作に基づき生成される。そして、これらデータ収集条件やタグデータ生成用データはデータ収集装置200に記憶され、またデータ収集対象車両(データ利用者が車両条件を指定)に送信されて、各車載装置Yにも記憶される。
次に、各車載装置Yは、各センサ・カメラの出力データを監視し、記憶しているデータ収集条件を満たすイベントが発生した場合にその実データRを記憶装置に記憶し、また実データRと記憶しているタグデータ生成用データに基づき当該実データRに対応するタグデータTを生成し記憶する。そして、各車載装置Yは、タグデータTをデータ収集装置200に送信し、データ収集装置200はそのタグデータTを記憶する。尚、実データRはこの際、データ収集装置200へ送信されない。
そして、データ利用者が端末装置205によりデータ収集状況の確認や実データRの収集のためにデータ収集装置200と接続した場合、データ収集装置200から収集されたタグデータTに基づく情報が端末装置205に表示され、またタグデータTに基づくデータ収集指示操作を行うための操作画面が端末装置205に表示される。
そして、データ利用者が端末装置205により収集する実データRの指定操作を行うと、データ収集装置200を介して対象の各車載装置Yに対象の実データRを指定する指示データが送信される。
その後、図12Cに示されるように、収集指示のあった実データR(画像データ等)が各車載装置Yからデータ収集装置200へ送信され、データ収集装置200に記憶される。そして、データ利用者が端末装置205によりデータ収集装置200に記憶された実データRにアクセスして、閲覧、ダウンロード等を行う。
尚、車載装置Yのデータ容量の観点からは、データ収集装置200に送信された実データRおよび対応するタグデータTは車載装置Yから削除するのが好ましい。また、タグデータTとしては、単に取得データの一部を取り出したようなデータでは無く、データ利用者が見て実データRの概要が把握できる、実データRの要否が判断できるメタデータ化したタグデータが好ましい。
次に、タグデータTの具体例について図13Aおよび図13Bを用いて説明する。図13Aは、タグデータTの一例を示す図である。図13Bは、収集条件IDの一例を示す図である。タグデータTは、例えば、図13Aに示すようなイベントID,車両番号,収集条件ID,イベント発生日時,イベント発生座標(緯度、経度),Tripカウンタで構成される。
イベントIDは、データをユニークに識別するための識別コードであり、収集条件ファイルで指定される収集条件IDとイベント発生時刻から生成する。例えば、収集条件IDが001と発生順が1番目であれば、「0010001」とする。また、車両番号は、各車両の識別番号であり、イベント発生日時は、イベント(データ収集条件を満たす状態)が発生した日時データである。イベント発生座標(緯度、経度)は、イベントが発生した位置データであり、Tripカウンタは、イグニッションスィッチのオンオフ回数(データ収集開始時点等、所定時点からのエンジンオンオフ回数)である。
また、収集条件IDは、図13Bに示すような収集条件データ(ファイル)と関連付けられた車載装置Yに設定されたデータ収集条件(例えば複数のデータ利用者によりデータ収集がなされる場合、あるいは単独のデータ利用者が複数の異なった条件でデータを収集したい場合に、各車載装置Yに複数のデータ収集条件が設定されることになる)を識別するためのデータであり、これら収集条件データ(ファイル)は各車載装置Yとデータ収集装置200で共通のものが記憶されることになる。尚、ある条件で収集対象となっていない車載装置Yについては、当該車載装置Yに記憶された収集条件ファイルには当該収集条件のデータは記憶されていない。
尚、収集条件データ(ファイル)は簡単なデータ構成では、収集条件を識別するための収集条件IDデータと、収集条件内容を示す収集条件データで構成され、またデータ利用者が画面表示で分かりやすくするようにイベント名(表示に利用)が関連付けられているのが好ましい。
また、本例では、収集条件を示すIDやその名称をタグデータTとしたが、実データRのレベル分けしたデータ種別としそのレベルデータをタグデータTとする方法や、データ収集条件の付加データとして収集条件達成レベル的なものでレベル分けした情報、例えば割込車両検出時における割り込み発生前の前方車両との車間距離レベルで危険度(車間距離長:割込危険度小、車間距離中:割込危険度中、車間距離短:割込危険度大)を判定してタグデータTとすると言った方法も好適な方法である。
このような上記システムをクラウドで形成した場合、上述のような車載装置Yは、収集したデータに時刻、位置、速度等の情報をタグ付けし、クラウドにメタ情報としてタグデータTだけをアップロードし、画像等のデータ本体は車載装置Yに記憶しておく。そして、サービス開発者等の利用者が車載機から必要なデータを取得したい時、クラウドに収集されたメタデータを参照することで対象車両を特定し、システムがその車両に記録されている画像を引き出すことで、データを回収する。
これにより、大容量の画像データをクラウドで保管する必要がなくなり、軽量のタグデータTだけを管理、参照し、必要な画像データのみを収集することが可能になる。
例えば、自動運転の開発において、開発者が危険な割り込みシーンのデータが必要となる。刻々と変化する道路環境により、さまざまな種類の割り込みが発生することが想定される。これに対して、本実施形態では、タグ付け機能によりデータが管理されているため、危険な割り込みシーンだけを容易に見つけることが可能となる。
次にシステムの各構成装置(車載装置、データ収集装置、端末装置(データ利用者))の処理・データの流れを図13Cの処理・データ遷移図を用いて説明する。図13Cは、データ収集システムにおけるデータ遷移図である。尚、車載装置Yは1台のみの表記であるが、データ収集対象として指定された車載装置は全て同様の動作を行うこととなる。
データ利用者が端末装置205を用いてデータ収集条件を入力すると(ステップS301)、当該データ収集条件入力データはデータ収集装置200に送信され、データ収集装置200ではそのデータ収集条件入力データに基づきデータ収集条件データファイルと、実データに基づき実データに対応するタグデータを生成するために用いられるタグデータ生成データを作成する(ステップS302)。
作成されたデータ収集条件データファイルとタグデータ生成データは、車載装置Yに送信され、またデータ収集条件データファイルはデータ収集装置200に記憶される(ステップS303)。そして、車載装置Yは、データ収集装置200から送信されたデータ収集条件データファイルとタグデータ生成データを記憶する(ステップS304)。
データ収集条件データファイルに含まれるデータ収集条件に合致するイベントが発生した場合(ステップS305:車両の各センサ出力により判断)、車載装置Yは、車両の各センサより収集対象(データ収集条件データファイルのデータを参照)のデータを取得、記憶し、実データに基づき、タグデータを生成する(ステップS306)。
そして、車載装置50は、生成したタグデータを車載装置50内に記憶する(ステップS307)。また、生成されたタグデータはデータ収集装置200に送信され、データ収集装置200が送信されたタグデータを記憶する(ステップS308)。このイベント発生時の処理(ステップS305~ステップS306の処理)はイベント発生に伴い随時行われる。
データ収集装置200に記憶されたタグデータは、データ利用者の端末装置205に対する操作により端末装置205に提供され、端末装置205にはデータの収集状況や実データ収集のための操作画面が表示される。これにより、データ利用者は、データ収集状態を確認することができる(ステップS309)。
この際、データ利用者が必要な実データRの収集指示操作を行うと(ステップS310)、収集指示操作データがデータ収集装置200に送信され、データ収集装置200では当該収集指示操作データに基づき収集対象の実データ識別データを含む収集指令データを作成する(ステップS311)。かかる収集指令データは、車載装置Yへ送信される。
そして、車載装置Yでは受信した収集指示データに基づき収集対象実データを選択し、当該実データをデータ収集装置200に送信する(ステップS312)。
次に、データ収集装置200は、車載装置Yから送信される実データRを受信し(ステップS313)、実データ取得情報を端末装置205に送信するとともに、受信した実データRを記憶する(ステップS314)。そして、データ利用者は端末装置205を操作してデータ収集装置200に記憶された実データRにアクセスし、実データRの閲覧やダウンロードを行う(ステップS315)。
以上のような流れでデータ利用者は必要な実データを効率良く収集でき、このような流れでデータ処理・蓄積・伝送が行われるので各装置のデータ処理・記憶負荷や、装置間のデータ伝送負荷を抑えることができる。
次に、データ収集例を、具体的データ種別として地図(道路)データを例に説明する。なお、以下では、説明を分かりやすくする観点から、まず、図14を用いて従来のデータ収集システムについて説明し、その後、図15を用いて本願のデータ収集システムについて説明する。
図14は、従来技術を説明する図である。また、図15は、実施形態に係るデータ収集装置のデータの収集例を示す図である。
図14に示すように、従来のデータ収集システムでは、各車載装置X1,X2,・・は車載センサ等が取得した位置データ,時刻データ,画像データ等のデータを、車両識別データ等の必要な付加データを付加してデータ収集装置(サーバ)100に送信(データアップ)する。尚、取得データ種別(どのような種類のデータを取得するか。例えば、位置、時刻、画像、速度、振動、傾斜等のデータ)やデータ取得範囲(道路区間、期間)は利用者等によりデータ収集装置100経由で予め設定されており、各車載装置X1,X2,・・は設定されたデータを該当のセンサから取得する。
このような従来のデータ収集システムでは、車両が走行した指定区間の画像データが全てクラウド等のデータ収集装置100に送られていた。そうすると、例えば交通量の多い道路は、データの重複が多くなり必要以上に大量の実データ(特に画像データ112は容量大)等が収集されデータ収集装置100の記憶部102に大量の収集データ110が蓄積されてしまうことになる。このため、データ容量が膨大になりデータ収集装置100の記憶部102の記憶容量を圧迫すると言った問題が発生する。
この問題に対処した実施形態例が、図15に示した実施形態である。図15に示すように、本実施形態のデータ収集システムでは、各車載装置Y1,Y2,・・は車載センサ等が取得した位置データ,時刻データ,画像データ等のデータについて、データ収集装置200から指定されたデータ収集条件により各センサ等から実データRを収集し、またデータ収集装置200から指定されたタグデータ生成条件に基づきタグデータTを生成する。
そして、生成したタグデータTと対応する実データRは各車載装置Y1,Y2,・・(生成した車載装置)に蓄積される。尚、車載装置Y1,Y2,・・に収集させるデータ種別等のデータ収集条件やタグデータ生成のためのタグデータ生成条件情報は、データ利用者の端末装置205操作に基づき、データ収集装置200で生成されてデータ収集装置200の記憶部202に記憶される。また、タグデータ生成条件情報は、データ収集対象の車載装置Y1,Y2,・・に送信されてその記憶部に記憶される。
また、車載装置Yにて生成されたタグデータTは、データ収集装置200に送信され、データ収集装置200はこれらタグデータTを蓄積する。尚、この際には、実データRは車載装置Yからデータ収集装置200には送信されない。
そして、サービス開発者等のデータ利用者が車載装置Yから必要なデータを取得したい時、データ収集装置200に収集、蓄積されたタグデータTをデータ収集装置200に通信接続された自己の端末装置205から参照することで対象車両を特定してデータ収集指示操作を行う。
この操作に従って、データ収集装置200は、蓄積されたタグデータTに基づき収集したい実データRを持つ車両を特定し、当該車両の車載装置Y1,Y2・・に対して収集対象の実データの送信指令を送信することで、車載装置Y1,Y2・・に蓄積されている対象の実データ(画像データ230等)を引き出すことでデータを収集する。
尚、端末装置205には、データ収集条件の指定やタグデータに基づく実データ収集指定操作等を行うための操作画面がデータ収集装置200のタグデータT等を参照して生成され表示される。
尚、実データRを収集する車両の特定については、上記のように車両自体を特定・指定する方法以外に、車両条件を指定する方法、例えば車種や走行位置(領域)、走行時刻(時間帯)、ある特定のイベントが発生した車両等の条件を指定して、該当する車両の実データRを収集する方法等も考えられる。
こうすることで、大容量の画像データ230等をデータ収集装置200で保管する必要がなくなり、軽量のタグデータTだけを管理、参照し、必要な画像データのみを収集することが可能になる。すなわち、データ収集装置200の記憶部202の記憶容量の圧迫を抑制することができる。例えば自動運転の開発において、開発者が危険な割り込みシーンのデータを必要とした場合、刻々と変化する道路環境により、さまざまな種類の割り込みが発生しますが、タグ付け機能によりデータが管理されているため、タグデータTにより危険な割り込みシーンだけを見つけ、その画像データだけを収集することができる。
また、例えば車両が走行した時刻と位置情報がタグデータとしてデータ収集装置200に送られるので、開発者がある道路の画像データを求めた場合、データ収集装置200のタグデータTを参照し、対象の道路を通過した車両を特定する。そして、開発者はその車両からデータ収集装置200を経由して画像データを取得することが可能となる。
将来的にデータを収集しセンターに提供するコネクテッドカーは増加すると見られており、そこから収集されるデータも膨大なものになると推定見込まれるため、本実施形態のようにタグデータTを活用し、サービス開発者等のデータ利用者のニーズに合致するデータだけを効率的に収集することで、様々なサービスに活用することが可能となる。
また、タグデータTのデータ容量は小さいため、データ収集条件に合致したタグデータTを全てデータ収集装置200に記憶するようにしても良いが、データ収集を指定した道路区間間の交通量に大きな差がある場合は、交通量の多い道路区間のタグデータTの生成・送信・蓄積を間引く処理や適正収集量を超えた場合に古いデータを削除する処理等を行っても良く、また逆に交通量の非常に少ない道路区間についてはデータ収集条件を緩めて類似データを補間的に収集する処理等を行っても良い。
この場合、データ利用者にその旨を報知したり、実データ収集の指示を行う際の操作画面にその旨の情報を表示し対象のデータの取捨を選択できるような操作画面としたりし、データ利用者が適切な対処ができるようにすることが好ましい。
次に上記実施形態における各技術的特徴についてその要点を記載する。
技術的特徴1:道路における路線区間を識別できるデータをタグデータとして含めている(データ収集条件に含める)。このため、路線区間に基づくデータ選別が可能となる。
技術的特徴2:技術的特徴1において、データ収集装置は路線区間別の収集データ量(数)が同等となるように実データ収集指示をする。これにより、路線区間の交通量の差によらず実データを収集でき、各路線区間間のデータ収集量の差による無駄な実データ収集を防止できる。
技術的特徴3:技術的特徴1において、データ収集装置は路線区間別の収集データ量(数)が同等となるようにデータ収集条件を設定する。例えば、データ収集条件にデータ収集条件成立時の○回に1回データ取得を行うと言った間引き条件を入れる。これにより、路線区間の交通量の差によらず車載機の実データの取得量を一定化でき、各路線区間間のデータ収集量の差による無駄な実データ収集を防止でき、また車載機等のデータ処理・記憶負荷、データ伝送負荷を低減できる。
技術的特徴4:生成・記憶するタグデータをメタデータ化する。これにより、データ利用者等によるデータ内容の把握が容易になり、収集実データの選択等が容易になる。
技術的特徴5:技術的特徴4において、収集条件の項目に関係するメタデータ化を行う。収集条件は元々データ利用者が設定するものであるため、その関係のメタデータを用いれば、データ利用者等によるデータ内容の把握がより容易になり、収集実データの選択等が容易になる。
技術的特徴6:技術的特徴4・5において、ある項目(収集条件等)に関係するメタデータ化に際して当該項目のレベル情報もメタデータ化する。ある項目のレベルに基づく詳細選別が可能となり、収集実データのより詳細な選択等が容易になる。
さらなる効果や変形例は、当業者によって容易に導き出すことができる。このため、本発明のより広範な態様は、以上のように表しかつ記述した特定の詳細および代表的な実施形態に限定されるものではない。したがって、添付の特許請求の範囲およびその均等物によって定義される総括的な発明の概念の精神または範囲から逸脱することなく、様々な変更が可能である。