JP2019168995A - データ構造、端末装置、データ通信方法、プログラム及び記憶媒体 - Google Patents

Abstract

【課題】高速道路などの分岐車線上で発生している渋滞の最後尾の情報を収集する。【解決手段】送信データは、移動体に搭載された端末装置から、情報処理装置へ送信される。そのデータ構造は、移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データと、移動体が渋滞の最後尾に位置していることを示す最後尾データと、を含む。この送信データは、分岐する車線に向かう移動体に渋滞の最後尾を通知するために用いられる。【選択図】図６

Description

本発明は、車両等の移動体の周辺情報を取得する技術に関する。

従来から、車両に設置されたセンサの出力に基づき地図データを更新する技術が知られている。例えば、特許文献１には、車両等の移動体に設置されたセンサの出力に基づいて部分地図の変化点を検出した場合に、当該変化点に関する変化点情報をサーバ装置に送信する運転支援装置が開示されている。また、非特許文献１には、車両側のセンサが検出したデータをクラウドサーバで収集するためのデータフォーマットに関する仕様が開示されている。

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

ｈｅｒｅ社ホームページ、Ｖｅｈｉｃｌｅ Ｓｅｎｓｏｒ Ｄａｔａ Ｃｌｏｕｄ Ｉｎｇｅｓｔｉｏｎ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ｖ２．０．２），［平成２９年１０月２７日検索］、インターネット＜ＵＲＬ：https://lts.cms.here.com/static-cloud-content/Company_Site/2015_06/Vehicle_Sensor_Data_Cloud_Ingestion_Interface_Specification.pdf＞

自動運転車が予め設定された走行経路に従って走行する場合において、高速道路を下りる際、本線道路から分岐する車線（以下、「分岐車線」とも呼ぶ。）上に渋滞が発生していることがある。分岐車線上の渋滞は、長い場合には本線道路上にもつながっていることがあるため、出口で正しく高速道路を降りるためには、自動運転車は本線上につながっている渋滞の最後尾につく必要がある。よって、サーバ装置は、出口渋滞の最後尾の情報を収集し、自動運転車に通知する必要がある。

本発明は、上記のような課題を解決するためになされたものであり、高速道路などの分岐車線上で発生している渋滞の最後尾の情報を収集することを目的とする。

請求項１に記載の発明は、移動体に搭載された端末装置から、情報処理装置へ送信される送信データのデータ構造であって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データと、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データと、を含み、前記分岐する車線に向かう移動体に前記渋滞の最後尾を通知するために用いられる。

請求項５に記載の発明は、移動体に搭載される端末装置であって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成手段と、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成手段と、前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信手段と、を備える。

請求項８に記載の発明は、移動体に搭載される端末装置により実行されるデータ通信方法であって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成工程と、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成工程と、前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信工程と、を備える。

請求項９に記載の発明は、コンピュータを備え、移動体に搭載される端末装置により実行されるプログラムであって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成手段、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成手段、前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信手段、として前記コンピュータを機能させる。

データ収集システムの概略構成を示すブロック図である。 端末装置の構成を示すブロック図である。 端末装置が実行する処理概要を示したブロック図である。 サーバ装置の構成を示すブロック図である。 第１実施例における分岐車線渋滞の例を示す。 第１実施例によるアップロードデータのフォーマットを示す。 第１実施例によるアップロード処理のフローチャートである。 第２実施例における分岐車線渋滞の例を示す。 第２実施例によるアップロードデータのフォーマットを示す。 第２実施例によるアップロード処理のフローチャートである。

本発明の１つの好適な実施形態は、移動体に搭載された端末装置から、情報処理装置へ送信される送信データのデータ構造であって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データと、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データと、を含み、前記分岐する車線に向かう移動体に前記渋滞の最後尾を通知するために用いられる。

上記の送信データは、移動体に搭載された端末装置から、情報処理装置へ送信される。そのデータ構造は、移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データと、移動体が渋滞の最後尾に位置していることを示す最後尾データと、を含む。この送信データは、分岐する車線に向かう移動体に渋滞の最後尾を通知するために用いられる。

上記のデータ構造の一態様は、前記本線道路から分岐する車線の位置を示す位置データを含む。この態様では、情報処理装置は、渋滞が発生している分岐車線の位置を特定することができる。好適な例では、前記本線道路から分岐する車線は、高速道路又は有料道路の出口車線であり、前記位置データは、前記高速道路又は有料道路の出口を示すデータである。

上記のデータ構造の他の一態様は、前記移動体が前記渋滞の最後尾に位置してから前記渋滞データを送信しなくなるまでの経過時間を示す経過時間データを含む。この態様では、情報処理装置は、その渋滞を通過するのに要するおよその時間を推定することができる。

本発明の他の好適な実施形態は、移動体に搭載される端末装置であって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成手段と、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成手段と、前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信手段と、を備える。

上記の端末装置は、移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データと、移動体が渋滞の最後尾に位置していることを示す最後尾データとを生成する。そして、端末装置は、渋滞データ及び最後尾データを含む送信データを情報処理装置へ送信する。これにより、情報処理装置は、本線道路からの分岐車線に発生している渋滞の最後尾位置を知ることができる。

上記の端末装置の一態様では、前記第２生成手段は、前記移動体の後方に向けて配置された検出装置の出力に基づいて、前記移動体が前記渋滞の最後尾に位置しているか否かを決定する。この態様では、検出装置で後方に存在する他の移動体を検出することにより、自車が最後尾に位置しているか否かを決定する。

上記の端末装置の他の一態様では、前記第２生成手段は、前記移動体の前方に位置する他の移動体から受信した車車間通信データに基づいて、前記移動体が前記渋滞の最後尾に位置しているか否かを決定する。この態様では、他の移動体との車車間通信により、自車が最後尾に位置しているか否かを決定する。

本発明の他の好適な実施形態は、移動体に搭載される端末装置により実行されるデータ通信方法であって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成工程と、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成工程と、前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信工程と、を備える。これにより、情報処理装置は、本線道路からの分岐車線に発生している渋滞の最後尾位置を知ることができる。

本発明の他の好適な実施形態は、コンピュータを備え、移動体に搭載される端末装置により実行されるプログラムであって、前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成手段、前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成手段、前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信手段、として前記コンピュータを機能させる。このプログラムをコンピュータで実行することにより、上記の端末装置を実現することができる。このプログラムは、記憶媒体に記憶して取り扱うことができる。

以下、図面を参照して本発明の好適な実施例について説明する。
［データ収集システム］
（全体構成）
図１は、実施例に係るデータ収集システムの概略構成である。データ収集システムは、移動体である車両と共に移動する端末装置１と、各端末装置１とネットワークを介して通信を行うサーバ装置２とを備える。そして、データ収集システムは、各端末装置１から送信された情報に基づき、サーバ装置２が保有する地図やその他の情報を更新する。なお、以後において、「地図」とは、従来の経路案内用の車載機が参照するデータに加えて、ＡＤＡＳ（Ａｄｖａｎｃｅｄ Ｄｒｉｖｅｒ Ａｓｓｉｓｔａｎｃｅ Ｓｙｓｔｅｍ）や自動運転に用いられるデータも含むものとする。

サーバ装置２は、各車両の端末装置１と通信セッションを確立し、車両の周辺環境に関するデータ（以下、「周辺環境データ」と呼ぶ。）をサーバ装置２へ送信することを要求するリクエストＤｒを端末装置１へ送信する。端末装置１は、要求された周辺環境データを含むアップロードデータＤｕをサーバ装置２に送信する。具体的には、端末装置１は、サーバ装置２と通信セッションを確立した場合に、端末装置１が搭載された車両の属性情報等をアップロードデータＤｕに含めてサーバ装置２へ送信する。また、端末装置１は、カメラやライダ（ＬＩＤＡＲ：Ｌａｓｅｒ Ｉｌｌｕｍｉｎａｔｅｄ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ、Ｌａｓｅｒ Ｉｍａｇｉｎｇ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ又はＬｉＤＡＲ：Ｌｉｇｈｔ Ｄｅｔｅｃｔｉｏｎ ａｎｄ Ｒａｎｇｉｎｇ）などから構成されるセンサ部７の出力に基づき周辺環境データを生成し、アップロードデータＤｕに含めてサーバ装置２へ送信する。

サーバ装置２は、各端末装置１からアップロードデータＤｕを受信して記憶する。サーバ装置２は、例えば、収集したアップロードデータＤｕに基づき、地図データの作成基準時点からの変化部分（変化点）を検出し、検出した変化点を反映するための地図データの更新などを行う。

また、端末装置１は、他の端末装置１との間で車車間通信データＤｖを送受信することにより、車車間通信を行う。なお、端末装置１は、車両に取り付けられた車載機又は車載機の一部であってもよく、車両の一部であってもよい。あるいは、センサ部７を接続することができれば、端末装置１はノート型ＰＣ等の可搬性のある端末機器であってもよい。

（端末装置の構成）
図２は、端末装置１の機能的構成を表すブロック図を示す。図２に示すように、端末装置１は、主に通信部１１と、記憶部１２と、入力部１３と、制御部１４と、インターフェース１５と、出力部１６とを有する。端末装置１内の各要素は、バスライン９８を介して相互に接続されている。

通信部１１は、制御部１４の制御に基づき、アップロードデータＤｕをサーバ装置２へ送信したり、地図ＤＢ４を更新するための地図データをサーバ装置２から受信したりする。また、通信部１１は、車両を制御するための信号を車両に送信する処理、車両の状態に関する信号を車両から受信する処理を行ってもよい。

記憶部１２は、制御部１４が実行するプログラムや、制御部１４が所定の処理を実行する為に必要な情報を記憶する。本実施例では、記憶部１２は、複数の地図ＤＢ４と、センサデータキャッシュ６と、車両属性情報ＩＶとを記憶する。

地図ＤＢ４は、例えば、道路データ、施設データ、及び、道路周辺の地物データなどを含むデータベースである。道路データには、経路探索用の車線ネットワークデータ、道路形状データ、交通法規データなどが含まれる。地物データは、道路標識等の看板や停止線等の道路標示、センターライン等の道路区画線や道路沿いの構造物等の情報を含む。また、地物データは、自車位置推定に用いるための地物の高精度な点群情報などを含んでもよい。その他、地図ＤＢ４には、位置推定に必要な種々のデータが記憶されてもよい。なお、記憶部１２は、データの種類（道路データ、施設データ、地物データ）ごとに分けられた複数の地図ＤＢ４を記憶してもよく、用途（案内用、自動運転用、障害検知用）等に分けられた複数の地図ＤＢ４を記憶してもよい。

センサデータキャッシュ６は、センサ部７の出力データ（いわゆる生データ）を一時的に保持するキャッシュメモリである。車両属性情報ＩＶは、車両の種別、車両ＩＤ、車両長さ、車幅、車高などの車両サイズ、車両の燃料タイプなど、端末装置１を搭載した車両の属性に関する情報を示す。

入力部１３は、ユーザが操作するためのボタン、タッチパネル、リモートコントローラ、音声入力装置等であり、例えば、経路探索のための目的地を指定する入力、自動運転のオン及びオフを指定する入力などを受け付け、生成した入力信号を制御部１４へ供給する。出力部１６は、例えば、制御部１４の制御に基づき出力を行うディスプレイやスピーカ等である。

インターフェース１５は、センサ部７の出力データを制御部１４やセンサデータキャッシュ６に供給するためのインターフェース動作を行う。センサ部７は、ライダ３１やカメラ３２などの車両の周辺環境を認識するための複数の外界センサと、ＧＰＳ受信機３３、ジャイロセンサ３４、ポジションセンサ３５、３軸センサ３６などの内界センサを含む。ライダ３１は、外界に存在する物体までの距離を離散的に測定し、当該物体の表面を３次元の点群として認識し、点群データを生成する。カメラ３２は、車両から撮影した画像データを生成する。ポジションセンサ３５は、各外界センサの位置を検出するために設けられ、３軸センサ３６は、各外界センサの姿勢を検出するために設けられている。なお、センサ部７は、図２に示した外界センサ及び内界センサ以外の任意の外界センサ及び内界センサを有してもよい。例えば、センサ部７は、外界センサとして、超音波センサ、赤外線センサ、マイクなどを含んでもよい。

制御部１４は、１または複数のプラットフォーム上で所定のプログラムを実行するＣＰＵなどを含み、端末装置１の全体を制御する。制御部１４は、機能的には、位置推定部１７と、オブジェクト検出部１８と、アップロードデータ生成部１９とを含む。図３は、端末装置１の位置推定部１７、オブジェクト検出部１８、及びアップロードデータ生成部１９の処理概要を示したブロック図である。

位置推定部１７は、センサデータキャッシュ６に保持されているセンサ部７の出力データ及び地図ＤＢ４に基づき、自車位置（車両の姿勢も含む）を推定する。位置推定部１７は、種々の位置推定方法を実行可能となっている。位置推定部１７は、例えば、ＧＰＳ受信機３３及びジャイロセンサ３４等の自立測位センサの出力に基づくデッドレコニング（自律航法）による自車位置推定方法、自律航法に地図ＤＢ４の道路データなどをさらに照合する処理（マップマッチング）を行う自車位置推定方法、周囲に存在する所定のオブジェクト（ランドマーク）を基準としてライダ３１やカメラ３２などの外界センサの出力データと地図ＤＢ４の地物情報が示すランドマークの位置情報とに基づく自車位置推定方法などを実行する。そして、位置推定部１７は、現在実行可能な位置推定方法の中から最も高い推定精度となる位置推定方法を実行し、実行した位置推定方法に基づき得られた自車位置等を示した自車位置情報を、アップロードデータ生成部１９へ供給する。位置推定部１７は、実行した位置推定方法を特定する情報を自車位置情報に含めてアップロードデータ生成部１９へ供給する。

オブジェクト検出部１８は、センサ部７が出力する点群情報、画像データ、音声データ等に基づき、所定のオブジェクトを検出する。この場合、例えば、オブジェクト検出部１８は、位置推定部１７が推定した自車位置に基づき、センサ部７により検出したオブジェクトに対応する地物データを地図ＤＢ４から抽出する。そして、オブジェクト検出部１８は、センサ部７により検出したオブジェクトの位置及び形状等と、地図ＤＢ４から抽出した地物データが示すオブジェクトの位置及び形状等とに違いがある場合、又は、地図ＤＢ４に該当する地物データが存在しない場合などに、センサ部７により検出したオブジェクトに関する情報（「オブジェクトデータ」とも呼ぶ。）を、アップロードデータ生成部１９へ供給する。

なお、オブジェクト検出部１８は、センサ部７により検出したオブジェクトと地図ＤＢ４の地物情報が示すオブジェクトとに形状や位置等に違いがあるか否かに関わらず、特定のオブジェクトを検出した場合に、当該オブジェクトに関するオブジェクトデータをアップロードデータ生成部１９へ供給してもよい。例えば、オブジェクト検出部１８は、センサ部７の出力に基づき、道路標識の内容、形状、位置等を認識した場合、又は、車線境界（即ち区画線等）の位置、形状等を認識した場合に、これらの認識結果をオブジェクトデータとしてアップロードデータ生成部１９へ供給してもよい。

アップロードデータ生成部１９は、位置推定部１７から供給される自車位置情報と、オブジェクト検出部１８から供給されるオブジェクトデータと、センサデータキャッシュ６から供給されるセンサ部６の出力データ（いわゆる生データ）とに基づき、アップロードデータＤｕを生成する。そして、アップロードデータ生成部１９は、生成したアップロードデータＤｕを、通信部１１によりサーバ装置２へ送信する。例えば、アップロードデータ生成部１９は、サーバ装置２との通信セッションを確立した場合に、車両属性情報ＩＶを含むアップロードデータＤｕを生成し、生成したアップロードデータＤｕを通信部１１によりサーバ装置２へ送信する。

（サーバ装置）
図４は、サーバ装置２の機能的構成を示すブロック図を示す。図４に示すように、サーバ装置２は、主に通信部２１と、記憶部２２と、制御部２３とを有する。サーバ装置２内の各要素は、バスライン９９を介して相互に接続されている。

通信部２１は、制御部２３の制御に基づき、各端末装置１からアップロードデータＤｕを受信したり、地図ＤＢ４を更新するための地図データを各端末装置１へ送信したりする。

記憶部２２は、制御部２３が実行するプログラムや、制御部２３が所定の処理を実行する為に必要な情報を記憶する。本実施例では、記憶部２２は、配信地図ＤＢ５を記憶する。

配信地図ＤＢ５は、各端末装置１に配信するための地図データであり、各端末装置１から受信するアップロードデータＤｕに基づき更新が行われる。配信地図ＤＢ５は、地図ＤＢ４と同様に、道路データ、施設データ、道路周辺の地物データなど、自動運転やＡＤＡＳなどで使用される種々のデータを記憶している。

制御部２３は、所定のプログラムを実行するＣＰＵなどを含み、サーバ装置２の全体を制御する。本実施例では、制御部２３は、通信部２１によりアップロードデータＤｕを端末装置１から受信した場合に、アップロードデータＤｕに含まれる周辺環境データに基づいて配信地図ＤＢ内の地図データを更新する。

上記の構成において、車両は本発明の移動体の一例であり、センサ部７は本発明の検出装置の一例であり、サーバ装置２は本発明の情報処理装置の一例である。また、アップロードデータ生成部１９は本発明の第１生成手段、第２生成手段の一例であり、通信部１１は本発明の送信手段の一例である。

［分岐車線の渋滞に関するデータの収集］
以下、データ収集システムにより、分岐車線の渋滞（以下、「分岐車線渋滞」とも呼ぶ。）に関する情報（以下、「分岐車線渋滞情報」と呼ぶ。）を収集する方法について説明する。なお、分岐車線は、高速道路や有料道路の出口、ＰＡ及びＳＡなどの分岐車線、並びに一般道の立体交差点における分岐車線などを含む。

（第１実施例）
第１実施例は、各車両の端末装置１から１つの共通のサーバ装置２へ分岐車線渋滞情報を送信するものである。図５（Ａ）は、分岐車線の渋滞の例を示す。高速道路や有料道路などの本線道路Ｒｍから、出口の料金所やＰＡ、ＳＡなどへ向かう分岐車線Ｒｄが分岐している。分岐車線Ｒｄには、複数の車両Ｖが並び、渋滞となっている。渋滞の最後尾にいる車両Ｖｘの端末装置１ｘは、自分が分岐車線渋滞の最後尾についたことを知らせるために、分岐車線渋滞情報を含むアップロードデータをサーバ装置２へ送信する。

図６は、分岐車線渋滞情報を含むアップロードデータのフォーマットを示す。このアップロードデータは、分岐車線渋滞に属している車両Ｖの端末装置１からサーバ装置２へ送信される。図示のように、アップロードデータは、「基本情報部」と、「特有情報部」とを含む。基本情報部は、端末装置１からサーバ装置２へのアップロードデータにおいて必要な基本的な情報を含む部分であり、「ヘッダ」、「車両メタデータ」、「車両位置」を含む。「ヘッダ」は、サーバ装置２と端末装置１との間で行われる通信で使用されるデータフォーマットのバージョンと、そのアップロードデータが送信された時刻を示すタイムスタンプとを含む。「車両メタデータ」は、その端末装置１が搭載された車両に関する情報であり、車両ＩＤ、車両サイズ、その車両に搭載されたセンサの種別などを含む。「車両位置」は、その端末装置１がアップロードデータをサーバ装置２へ送信するときの車両の位置を示す情報であり、例えば位置座標である。

アップロードデータの特有情報部は、「道路リンクＩＤ」、「分岐地点ＩＤ」、「渋滞フラグ」、「最後尾フラグ」、「経過時間」を含む。

「道路リンクＩＤ］は、車両Ｖが属する道路リンクのＩＤである。車両Ｖが分岐車線にいる場合、その分岐車線の道路リンクＩＤが用いられる。但し、分岐車線自体に道路リンクＩＤが付与されていない場合には、本線道路の道路リンクＩＤを用いてもよい。端末装置１は、車両Ｖの現在位置と地図ＤＢ４内の地図データから道路リンクを特定し、道路リンクＩＤを設定する。

「分岐地点ＩＤ」は、分岐車線が設けられている地点を示すＩＤである。分岐車線が高速道路や有料道路の出口へ向かう車線である場合、分岐地点ＩＤは高速道路や有料道路のインターチェンジ（ＩＣ）を示すＩＤとなる。また、分岐車線が高速道路や有料道路のサービスエリア（ＳＡ）やパーキングエリア（ＰＡ）へ入る車線である場合、分岐地点ＩＤはＳＡやＰＡのＩＤとなる。さらに、分岐車線が一般道路の立体交差点における分岐車線である場合、分岐地点ＩＤはその立体交差点のＩＤとなる。端末装置１は、車両Ｖの現在位置と地図ＤＢ４の地図データから分岐地点を特定し、分岐地点ＩＤを設定する。また、地図データから特定したノードＩＤを用いてもよい。

「渋滞フラグ」は、分岐車線が渋滞しているか否かを示すフラグである。渋滞フラグは、分岐車線が渋滞している場合に「１」に設定され、渋滞していない場合に「０」に設定される。端末装置１は、例えば車両Ｖの速度や、カメラ３２による前方画像などに基づいて、分岐車線が渋滞しているか否かを判定し、渋滞フラグを設定する。

「最後尾フラグ」は、車両Ｖが分岐車線渋滞に属している場合に、車両Ｖの位置がその渋滞の最後尾であるか否かを示す。最後尾フラグは、車両Ｖの位置が分岐車線渋滞の最後尾である場合に「１」に設定され、最後尾でない場合に「０」に設定される。端末装置１は、カメラ３２による撮影画像やライダ３１による計測結果に基づいて、自車の後方に車両がいるか否か、即ち自車が最後尾であるか否かを判定することができる。

「経過時間」は、その車両が分岐車線渋滞の最後尾についてからの経過時間を示す。但し、経過時間は、その車両が分岐車線の渋滞を抜けた後は、分岐車線渋滞の最後尾についてから渋滞を抜けるまでに要した時間、または渋滞が解消されるまでの時間となる。具体的には、端末装置１は、その車両が分岐車線渋滞に属している間は、その車両が分岐車線渋滞の最後尾についてからの経過時間をカウントしていく。そして、その車両が分岐車線渋滞を抜けたとき、または渋滞が解消されたときに、時間のカウントを停止してそのときの経過時間を保存する。よって、車両が分岐車線渋滞を抜けた後は、経過時間は増加しない。

上記のアップロードデータにおいて、渋滞フラグは本発明の渋滞データの一例であり、最後尾フラグは本発明の最後尾データの一例であり、分岐地点ＩＤは本発明の位置データの一例であり、経過時間は本発明の経過時間データの一例である。

なお、端末装置１は、カメラ３２やライダ３１を用いて自身が最後尾車両であるか否かを判定する他に、車車間通信により、他の端末装置１から最後尾であることを示す情報（以下、「最後尾通知データ」と呼ぶ。）を受信することができる。これについて以下に説明する。いま、図５（Ａ）に示すように、ある時点において分岐車線渋滞の最後尾の車両Ｖｘに端末装置１ｘが搭載されているとする。このとき、端末装置１ｘは、最後尾フラグを「１」としたアップロードデータをサーバ装置２へ送信している。これに加えて、車両Ｖｘの端末装置１ｘは、車車間通信により、通信可能な所定距離の範囲内に存在する他の端末装置１に対して最後尾通知データを送信する。ここで、最後尾通知データは、時刻情報と、送信元の端末装置１ｘの自車位置と、その車両Ｖｘが最後尾であることを示す情報とを含む。

その後、図５（Ｂ）に示すように、車両Ｖｘの後方に別の車両Ｖｙが並び、その車両Ｖｙに端末装置１ｙが搭載されているとする。車両Ｖｙの端末装置１ｙは、車両Ｖｘの端末装置１ｘが車車間通信により送信している最後尾通知データを受信すると、自分が分岐車線渋滞の最後尾であると認識し、最後尾フラグを「１」に設定してサーバ装置２へアップロードデータを送信する。こうして、端末装置１は、他の車両の端末装置１が送信する最後尾通知データを車車間通信で受信することにより、自車が分岐車線渋滞の最後尾にいると認識することができる。

なお、こうして自車が分岐車線渋滞の最後尾にいると認識すると、車両Ｖｙの端末装置１ｙは、時刻情報と、自身の自車位置と、自身が最後尾車両であることを示す情報とを含む最後尾通知データを、車車間通信により周囲の車両に送信する。端末装置１ｘは、車両Ｖｙの端末装置１ｙから送信された最後尾通知データを車車間通信により受信し、車両Ｖｙが新たに最後尾車両になったこと、即ち、自身は最後尾車両では無くなったことを認識する。そして、その後は、車両Ｖｘの端末装置１ｘは、最後尾フラグを「０」に設定したアップロードデータをサーバ装置２へ送信する。こうして、車車間通信により、それまで最後尾であった車両から、新たに最後尾になった車両へと最後尾車両であることを示す情報を伝達することができる。

図７は、分岐車線渋滞情報を含むアップロードデータのアップロード処理を示す。この処理は、端末装置１の制御部１４が予め用意されたプログラムを実行することにより行われる。また、この処理は、所定時間毎に繰り返し実行される。

まず、端末装置１は、車両が分岐地点から所定距離内に入ったか否かを判定する（ステップＳ１０）。端末装置１は、車両の現在位置と、地図ＤＢ４内の地図データとに基づいてこの判定を行う。車両が分岐地点から所定距離内に入っていない場合（ステップＳ１０：Ｎｏ）、処理は終了する。

一方、車両が分岐地点から所定距離内に入った場合（ステップＳ１０：Ｙｅｓ）、端末装置１は、分岐車線が渋滞しているか否かを判定する（ステップＳ１１）。なお、端末装置１は、例えば車両の速度や、カメラ３２により撮影した前方画像などに基づいて、分岐車線が渋滞しているか否かを判定する。分岐車線が渋滞していない場合（ステップＳ１１：Ｎｏ）、端末装置１は、渋滞フラグを「０」に設定し（ステップＳ１２）、ステップＳ１４へ進む。一方、分岐車線が渋滞している場合（ステップＳ１１：Ｙｅｓ）、端末装置１は、渋滞フラグを「１」に設定する（ステップＳ１３）。

次に、端末装置１は、自車が渋滞の最後尾にいるか否かを判定する（ステップＳ１４）。なお、端末装置１は、前述のように、カメラ３２やライダ３１による後方車両の検出結果に基づいて自車が最後尾であるか否かを判定しても良く、それまで最後尾であった車両から車車間通信により最後尾通知データを受信したときに自車が最後尾であると判定しても良い。

自車の位置が渋滞の最後尾である場合（ステップＳ１４：Ｙｅｓ）、端末装置１は最後尾フラグを「１」に設定する（ステップＳ１５）。一方、自車の位置が渋滞の最後尾ではない場合（ステップＳ１４：Ｎｏ）、端末装置１は、最後尾フラグを「０」に設定する（ステップＳ１６）。なお、端末装置１は、ステップＳ１２で渋滞フラグが「０」に設定された場合も、最後尾フラグを「０」に設定する。

次に、端末装置１は、上記のように設定された渋滞フラグ及び最後尾フラグを含むアップロードデータを生成し（ステップＳ１７）、そのアップロードデータをサーバ装置２へ送信する（ステップＳ１８）。そして、アップロード処理は終了する。

なお、上記のアップロード処理では、分岐車線が渋滞していない場合（ステップＳ１１：Ｎｏ）、端末装置１は、渋滞フラグを「０」に設定してアップロードデータをサーバ装置２へ送信している。その代わりに、分岐車線が渋滞していない場合には、端末装置１はアップロードデータをサーバ装置２へ送信しないこととしてもよい。

サーバ装置２は、アップロードデータを受信することにより、分岐車線の渋滞状況を知ることができる。具体的には、アップロードデータの道路リンクＩＤ及び分岐地点ＩＤにより、サーバ装置２は、対象となる道路とその分岐地点（出口、ＳＡ、ＰＡなど）を特定することができる。また、渋滞フラグにより、サーバ装置２は、その分岐車線が渋滞しているか否かを知ることができる。さらに、車両から順次送信されるアップロードデータ中の渋滞フラグが「１」から「０」に変化した場合には、サーバ装置２は、その分岐地点における渋滞が解消したと推定することができる。

また、最後尾フラグと車両位置により、サーバ装置２は、その分岐車線に発生している渋滞の最後尾の位置を知ることができる。よって、サーバ装置２は、渋滞の最後尾の位置を、その分岐車線を今後通過することを予定している他の車両に通知することができる。これにより、その後にその分岐車線を通過する予定の車両が誤って渋滞を通り越してしまうことを防止できる。さらには、経過時間により、サーバ装置２はその渋滞を抜けるのに必要な大体の所要時間を知り、その後にその分岐車線を通過する予定の他の車両に通知することもできる。

（第２実施例）
第２実施例は、複数のサーバ装置２があり、各車両の端末装置１はそれぞれ決められたサーバ装置２へ分岐車線渋滞情報を送信するものである。車両は複数の自動車メーカーにより生産されるので、自動車メーカー毎にクラウドシステムが構築され、サーバ装置２が用意される場合がある。この場合、各車両の端末装置１は、それぞれ自車の自動車メーカーが運営するサーバ装置２と通信することになる。第２実施例は、このような場合に、クラウドシステム毎に分岐車線渋滞情報をサーバ装置２へ収集するものである。

いま、第１実施例と同様に、アップロードデータに「最後尾フラグ」を含めてサーバ装置２に送信する場合を考える。Ａ社とＢ社の２つの自動車メーカーがあり、それぞれが独立してクラウドシステムを構築しているものとする。なお、基本的にクラウドシステム間の通信はできないものとする。以下、自動車メーカーＡ社のクラウドシステムを「クラウドＡ」と呼び、そのサーバ装置２を「サーバ装置２ａ」と呼び、自動車メーカーＡ社の車両を「車両Ｖａ」と呼び、その車両Ｖａに搭載されている端末装置を「端末装置１ａ」と呼ぶ。また、自動車メーカーＡ社の複数の車両Ｖａの集合を「グループＡ」と呼ぶ。同様に、自動車メーカーＢ社のクラウドシステムを「クラウドＢ」と呼び、そのサーバ装置２を「サーバ装置２ｂ」と呼び、自動車メーカーＢ社の車両を「車両Ｖｂ」と呼び、その車両Ｖｂに搭載されている端末装置を「端末装置１ｂ」と呼ぶ。また、自動車メーカーＢ社の複数の車両Ｖｂの集合を「グループＢ」と呼ぶ。

図８（Ａ）は、分岐車線Ｒｄが渋滞し、複数の車両が並んでいる状態を示す。各車両は、基本的に第１実施例と同様に分岐車線渋滞情報を含むアップロードデータをサーバ装置２へ送信する。但し、第２実施例では、自動車メーカー毎にクラウドシステムが構築されているため、クラウドシステム毎に最後尾の車両に関するデータをサーバ装置２へ送信する必要がある。

いま、図８（Ａ）に示すように、分岐車線Ｒｄには、渋滞の先頭側から、車両Ｖｂ_１、車両Ｖｂ_２、車両Ｖａ_１、車両Ｖｂ_３、車両Ｖａ_２が並んでいる。この場合、分岐車線渋滞の最後尾にいる車両Ｖａ_２の端末装置１ａ_２は、自分が最後尾であることを示す情報をクラウドＡのサーバ装置２ａに送信している。よって、クラウドＡのサーバ装置２ａは、車両Ｖａ_２が分岐車線渋滞の最後尾にいると認識している。

ここで、図８（Ｂ）に示すように、車両Ｖａ_２の後ろに、別の車両Ｖｂ_４が来たとする。この場合、車両Ｖｂ_４の端末装置１ｂ_４は、自分が最後尾であることを示す情報をクラウドＢのサーバ装置２ｂに送信する。そして、クラウドＢのサーバ装置２ｂは、車両Ｖｂ_４が分岐車線渋滞の最後尾にいると認識する。

この場合、車両Ｖｂ_４が最後尾の車両になったことにより、車両Ｖａ_２は最後尾の車両ではなくなるので、車両Ｖａ_２は、自分が最後尾ではなくなったことを示す情報をクラウドＡのサーバ装置２ａに送信することになるが、そうするとクラウドＡの世界では、分岐車線渋滞の最後尾の車両がいなくなってしまう。なお、クラウドＢの端末装置１ｂ_４はクラウドＡのサーバ装置２ａとは通信できないため、クラウドＡのサーバ装置２ａは、車両Ｖｂ_４が最後尾であることを示す情報を端末装置１ｂ_４から受信することはない。よって、クラウドＡのサーバ装置２ａは、どの車両が分岐車線渋滞の最後尾にいるかがわからなくなる。

そこで、第２実施例では、各端末装置１からサーバ装置２へ送信されるアップロードデータに、自分の属するグループにおける最後尾の車両であることを示すフラグ（以下、「グループ最後尾フラグ」と呼ぶ。）を含める。さらに、アップロードデータに、自車の後方に後続車があるか否かを示すフラグ（以下、「後続車フラグ」と呼ぶ。）を含める。

図９は、第２実施例によるアップロードデータのフォーマットを示す。このアップロードデータは、車両Ｖの端末装置１からサーバ装置２へ送信される。図示のように、アップロードデータは、「基本情報部」と、「特有情報部」とを含む。基本情報部は、端末装置１からサーバ装置２へのアップロードデータにおいて必要な基本的な情報を含む部分であり、「ヘッダ」、「車両メタデータ」、「車両位置」を含む。ここで、「ヘッダ」、「車両メタデータ」、「車両位置」は、第１実施例と同様であるので説明を省略する。

アップロードデータの特有情報部は、「道路リンクＩＤ」、「分岐地点ＩＤ」、「渋滞フラグ」、「グループ最後尾フラグ」、「後続車フラグ」、「経過時間」を含む。ここで、「道路リンクＩＤ］、「分岐地点ＩＤ］、「渋滞フラグ」、「経過時間」は第１実施例と同様であるので説明を省略する。

「グループ最後尾フラグ」は、分岐車線渋滞において、その車両の位置が、同一グループの車両のうちで最後尾の位置であるか否かを示す。グループ最後尾フラグは、車両がグループ内の最後尾である場合に「１」に設定され、グループ内の最後尾ではない場合に「０」に設定される。例えば図８（Ａ）の例では、車両Ｖａ_１はグループＡに属するが、グループＡ内の最後尾の車両ではないので、端末装置１ａ_１はグループ最後尾フラグを「０」に設定する。一方、車両Ｖａ_２はグループＡ内の最後尾の車両であるので、端末装置１ａ_２はグループ最後尾フラグを「１」に設定する。端末装置１は、自車の後方に他の車両がいない場合には、カメラ３２による撮影画像やライダ３１による計測結果に基づいて自車が最後尾であると認識することができる。

「後続車フラグ」は、自車の後方に後続車がいるか否かを示す。後続車フラグは、後続車ありの場合は「１」に設定され、後続車なしの場合は「０」に設定される。例えば図８（Ａ）における車両Ｖａ_２には後続車がないので、端末装置１ａ_２は後続車フラグを「０」に設定する。一方、図８（Ｂ）における車両Ｖａ_２には後続車があるので、端末装置１ａ_２は後続車フラグを「１」に設定する。

次に、グループ内の最後尾車両であること示す情報を、車車間通信で、同一グループの後方の車両に転送する方法について説明する。なお、車車間通信は、同一グループの車両の端末装置間でのみ行えるものとする。例えば、図８（Ａ）の状態では、車両Ｖｂ_３はグループＢの最後尾の車両であるため、端末装置１ｂ_３はグループ最後尾フラグが「１」であるアップロードデータをサーバ装置２ｂへ送信している。これに加えて、車両Ｖｂ_３の端末装置１ｂ_３は、同一グループであるグループＢの周囲の車両に対して、車車間通信により、最後尾ｇを送信する。この最後尾通知データは、時刻情報と、自車位置と、自分がグループ内の最後尾であることを示す情報とを含む。

この状況で、図８（Ｂ）に示すように、車両Ｖｂ_４が分岐車線渋滞の最後尾に来ると、車両Ｖｂ_４の端末装置１ｂ_４は、車両Ｖｂ_３の端末装置１ｂ_３から送信された最後尾通知データを受信する。そして、端末装置１ｂ_４は、受信した最後尾通知データに含まれる車両Ｖｂ_３の自車位置が自分よりも前方である場合には、自分がグループ内の最後尾の車両になったと判定し、アップロードデータに含めるグループ最後尾フラグを「１」に設定する。これに加えて、端末装置１ｂ_４は、車車間通信により、最後尾通知データを周囲の同一グループの車両に送信する。この最後尾通知データは、時刻情報と、自車位置と、自分がグループ内の最後尾であることを示す情報とを含む。車両Ｖｂ_３の端末装置１ｂ_３は、車両Ｖｂ_４の端末装置１ｂ_４が送信した最後尾通知データを受信し、それに含まれる自車位置が自分より後方である場合に、自分より後方に同じグループＢの車両が到着し、自分はグループＢの最後尾車両では無くなったと判定し、その後にサーバ装置２ｂへ送信するアップロードデータのグループ最後尾フラグを「０」に設定するとともに、車車間通信による最後尾通知データの送信を終了する。こうして、グループ内の最後尾の車両であることを示す情報が、後方の同一グループの車両に転送されていく。

図１０は、分岐車線渋滞情報を含むアップロードデータのアップロード処理を示す。この処理は、端末装置１の制御部１４が予め用意されたプログラムを実行することにより行われる。また、この処理は、所定時間毎に繰り返し実行される。

まず、端末装置１は、車両が分岐地点から所定距離内に入ったか否かを判定する（ステップＳ２０）。端末装置１は、車両の現在位置と、地図ＤＢ４内の地図データとに基づいてこの判定を行う。車両が分岐地点から所定距離内に入っていない場合（ステップＳ２０：Ｎｏ）、処理は終了する。

一方、車両が分岐地点から所定距離内に入った場合（ステップＳ２０：Ｙｅｓ）、端末装置１は、分岐車線が渋滞しているか否かを判定する（ステップＳ２１）。なお、端末装置１は、例えば車両の速度や、カメラ３２により撮影した前方画像などに基づいて、分岐車線が渋滞しているか否かを判定する。分岐車線が渋滞していない場合（ステップＳ２１：Ｎｏ）、端末装置１は、渋滞フラグを「０」に設定し（ステップＳ２２）、ステップＳ２４へ進む。一方、分岐車線が渋滞している場合（ステップＳ２１：Ｙｅｓ）、端末装置１は、渋滞フラグを「１」に設定する（ステップＳ２３）。

次に、端末装置１は、分岐車線渋滞において、自車がグループ内の最後尾であるか否かを判定する（ステップＳ２４）。なお、端末装置１は、前述のように、それまでグループ内の最後尾であった車両から車車間通信により最後尾通知データを受信したときに自車がグループ内の最後尾であると判定する。

車両がグループ内の最後尾である場合（ステップＳ２４：Ｙｅｓ）、端末装置１はグループ最後尾フラグを「１」に設定する（ステップＳ２５）。一方、自車がグループ内の最後尾ではない場合（ステップＳ２４：Ｎｏ）、端末装置１は、グループ最後尾フラグを「０」に設定する（ステップＳ２６）。なお、端末装置１は、ステップＳ２２で渋滞フラグを「０」に設定した場合も、グループ最後尾フラグを「０」に設定する。

次に、端末装置１は、自車の後方に後続車があるか否かを判定する（ステップＳ２７）。後続車がある場合（ステップＳ２７：Ｙｅｓ）、端末装置１は後続車フラグを「１」に設定する（ステップＳ２８）。一方、後続車がない場合（ステップＳ２７：Ｎｏ）、端末装置１は後続車フラグを「０」に設定する（ステップＳ２９）。

次に、端末装置１は、上記のように設定された渋滞フラグ、グループ最後尾フラグ及び後続車フラグを含むアップロードデータを生成し（ステップＳ３０）、そのアップロードデータをサーバ装置２へ送信する（ステップＳ３１）。そして、アップロード処理は終了する。

なお、上記のアップロード処理では、分岐車線が渋滞していない場合（ステップＳ１１：Ｎｏ）、端末装置１は、渋滞フラグを「０」に設定してアップロードデータをサーバ装置２へ送信している。その代わりに、分岐車線が渋滞していない場合には、端末装置１はアップロードデータをサーバ装置２へ送信しないこととしてもよい。

こうして、サーバ装置２は、アップロードデータを受信することにより、分岐車線の渋滞状況を知ることができる。具体的には、サーバ装置２は、グループ最後尾フラグにより、自己のグループの車両のうち最後尾にいる車両を特定し、その位置を知ることができる。また、サーバ装置２は、グループ最後尾フラグと後続車フラグとの組み合わせにより、自己のグループの最後尾の車両が、他のグループを含めた全車両の最後尾であるか否かを判定することができる。即ち、サーバ装置２は、自己のグループのある車両から、グループ最後尾フラグ「１」、後続車フラグ「１」を含むアップロードデータを受信した場合、サーバ装置２は、その車両が自己のグループ内では最後尾であるが、他のグループを含めた全車両の最後尾ではないと認識する。これに対し、サーバ装置２は、自己のグループのある車両から、グループ最後尾フラグ「１」、後続車フラグ「０」を含むアップロードデータを受信した場合、その車両が他のグループを含めた全車両の最後尾であると認識する。

なお、図９に示すアップロードデータのフォーマットでは、特有情報部に「後続車フラグ」を含めているが、その代わりに、「全体最後尾フラグ」を含めることとしてもよい。この場合、「全体最後尾フラグ」は、グループを問わず、分岐車線渋滞に属している全車両の最後尾であることを示すものとする。即ち、全体最後尾フラグは、車両が分岐車線渋滞に属する全車両の最後尾である場合に「１」に設定され、全車両の最後尾ではない場合に「０」に設定される。これにより、サーバ装置２は、アップロードデータに含まれる「グループ最後尾フラグ」を見ることにより、自己のグループに属する車両における最後尾車両を知ることができ、「全体最後尾フラグ」を見ることにより全車両における最後尾車両を知ることができる。

同じ出口渋滞に存在する同一グループ車両間の車車間通信が、距離が離れているなどの理由により成立できなかった場合、複数の車両から、同じ出口渋滞についての最後尾フラグがサーバ装置２へ送信される可能性がある。その場合には、サーバ装置２は、ヘッダのタイムスタンプ情報や車両位置情報を参照し、最も後方に位置すると考えられる車両をグループ内での最後尾の車両と認識すればよい。

１ 端末装置
２ サーバ装置
４ 地図ＤＢ
５ 配信地図ＤＢ
６ センサデータキャッシュ
７ センサ部
１４、２３ 制御部

Claims (10)

1. 移動体に搭載された端末装置から、情報処理装置へ送信される送信データのデータ構造であって、
   前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データと、
   前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データと、
   を含み、
   前記分岐する車線に向かう移動体に前記渋滞の最後尾を通知するために用いられるデータ構造。
2. 前記本線道路から分岐する車線の位置を示す位置データを含む請求項１に記載のデータ構造。
3. 前記本線道路から分岐する車線は、高速道路又は有料道路の出口車線であり、
   前記位置データは、前記高速道路又は有料道路の出口を示すデータである請求項２に記載のデータ構造。
4. 前記移動体が前記渋滞の最後尾に位置してから前記渋滞データを送信しなくなるまでの経過時間を示す経過時間データを含む請求項１乃至３のいずれか一項に記載のデータ構造。
5. 移動体に搭載される端末装置であって、
   前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成手段と、
   前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成手段と、
   前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信手段と、
   を備える端末装置。
6. 前記第２生成手段は、前記移動体の後方に向けて配置された検出装置の出力に基づいて、前記移動体が前記渋滞の最後尾に位置しているか否かを決定する請求項５に記載の端末装置。
7. 前記第２生成手段は、前記移動体の前方に位置する他の移動体から受信した車車間通信データに基づいて、前記移動体が前記渋滞の最後尾に位置しているか否かを決定する請求項５に記載の端末装置。
8. 移動体に搭載される端末装置により実行されるデータ通信方法であって、
   前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成工程と、
   前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成工程と、
   前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信工程と、
   を備えるデータ通信方法。
9. コンピュータを備え、移動体に搭載される端末装置により実行されるプログラムであって、
   前記移動体が本線道路から分岐する車線上の渋滞に属していることを示す渋滞データを生成する第１生成手段、
   前記移動体が前記渋滞の最後尾に位置していることを示す最後尾データを生成する第２生成手段、
   前記渋滞データ及び前記最後尾データを含む送信データを情報処理装置へ送信する送信手段、
   として前記コンピュータを機能させるプログラム。
10. 請求項９に記載のプログラムを記憶した記憶媒体。