特開 2024-15725 支援装置、支援方法、およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024015725

(43)【公開日】2024-02-06

(54)【発明の名称】支援装置、支援方法、およびプログラム

(51)【国際特許分類】

   G08G 1/09 20060101AFI20240130BHJP

   G08G 1/16 20060101ALI20240130BHJP

【ＦＩ】

G08G1/09 H

G08G1/09 F

G08G1/16 E

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2022117992

(22)【出願日】2022-07-25

(71)【出願人】

【識別番号】000006208

【氏名又は名称】三菱重工業株式会社

(74)【代理人】

【識別番号】100149548

【弁理士】

【氏名又は名称】松沼 泰史

(74)【代理人】

【識別番号】100162868

【弁理士】

【氏名又は名称】伊藤 英輔

(74)【代理人】

【識別番号】100161702

【弁理士】

【氏名又は名称】橋本 宏之

(74)【代理人】

【識別番号】100189348

【弁理士】

【氏名又は名称】古都 智

(74)【代理人】

【識別番号】100196689

【弁理士】

【氏名又は名称】鎌田 康一郎

(72)【発明者】

【氏名】大野 秀和

(72)【発明者】

【氏名】小西 高三郎

【テーマコード（参考）】

5H181

【Ｆターム（参考）】

5H181AA01

5H181BB04

5H181BB05

5H181BB13

5H181FF04

5H181FF12

5H181FF13

5H181FF17

5H181FF27

5H181LL04

5H181LL06

5H181LL09

(57)【要約】

【課題】車車間通信の通信範囲や追随走行の非対象車両の存在に影響されることなく、追随走行の対象車両同士をマッチングさせることができる支援装置を提供する。
【解決手段】支援装置は、車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとするバブルを生成し、バブル情報を登録するバブル生成部と、所定のマッチング条件を満たすバブルを追随走行要求の要求元バブルに対するマッチング候補として選択するマッチング処理部と、前記要求元バブルおよび前記マッチング候補それぞれのリーダーにバブル統合を指示する統合指示部と、前記要求元バブルおよび前記マッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、前記統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報を統合して更新する更新処理部と、を備える。
【選択図】図２

【特許請求の範囲】

【請求項1】

車両の追随走行を支援する支援装置であって、
前記車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報と生成した前記バブルの識別情報とを関連付けたバブル情報を登録するバブル生成部と、
前記バブルに含まれる車両から追随走行要求を受け付けた場合に、複数の前記バブルのうち所定のマッチング条件を満たすバブルを、前記追随走行要求の要求元バブルに対するマッチング候補として選択するマッチング処理部と、
前記要求元バブルおよび前記マッチング候補それぞれのリーダーにバブル統合を指示する統合指示部と、
前記要求元バブルおよび前記マッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、前記統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報を統合して更新する更新処理部と、
を備える支援装置。

【請求項2】

前記車両情報は前記車両の目的地を含み、
前記マッチング処理部は、前記要求元バブルの目的地までの走行経路と少なくとも一部が共通する走行経路を有するバブルであって、共通する走行経路の長さが所定距離以上、または、共通する走行経路の走行時間が所定時間以上であるバブルを前記マッチング候補として選択する、
請求項１に記載の支援装置。

【請求項3】

前記車両情報は前記車両の車両属性を含み、
前記マッチング処理部は、前記要求元バブルの車両属性と一致する車両属性を有するバブルを前記マッチング候補として選択する、
請求項１に記載の支援装置。

【請求項4】

前記マッチング処理部は、前記要求元バブルに含まれる車両の台数との合計台数が上限台数以下となるバブルを前記マッチング候補として選択する、
請求項１に記載の支援装置。

【請求項5】

複数の前記バブルそれぞれの走行位置を含む更新情報を取得する更新情報取得部をさらに備え、
前記マッチング処理部は、前記更新情報に基づいて、前記要求元バブルの走行位置から所定の検索距離内に位置するバブルを前記マッチング候補として選択する、
請求項１に記載の支援装置。

【請求項6】

複数の前記バブルそれぞれの走行位置およびバブル速度を含む更新情報を取得する更新情報取得部をさらに備え、
前記マッチング処理部は、前記更新情報に基づいて、前記要求元バブルが指定した設定時間以内に合流可能なバブルを前記マッチング候補として選択する、
請求項１に記載の支援装置。

【請求項7】

前記統合指示部は、前記要求元バブルおよび前記マッチング候補のうち後方を走行する後続バブルが前方を走行する先行バブルに追いつくように、前記先行バブルの減速および前記後続バブルの加速の少なくとも一方を指示する、
請求項１に記載の支援装置。

【請求項8】

前記バブルから離脱車両を離脱させる分離要求を受け付けた場合に、前記バブルのバブル情報から前記離脱車両の車両情報を削除して更新するとともに、前記離脱車両をリーダーとする離脱バブルを生成して、前記離脱車両の車両情報と生成した前記離脱バブルの識別情報とを関連付けたバブル情報を登録する分離処理部をさらに備える、
請求項１から７の何れか一項に記載の支援装置。

【請求項9】

車両の追随走行を支援する支援方法であって、
前記車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報と生成した前記バブルの識別情報とを関連付けたバブル情報を登録するステップと、
前記バブルに含まれる車両から追随走行要求を受け付けた場合に、複数の前記バブルのうち所定のマッチング条件を満たすバブルを、前記追随走行要求の要求元バブルに対するマッチング候補として選択するステップと、
前記要求元バブルおよび前記マッチング候補それぞれのリーダーにバブル統合を指示するステップと、
前記要求元バブルおよび前記マッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、前記統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報を統合して更新するステップと、
を有する支援方法。

【請求項10】

車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報と生成した前記バブルの識別情報とを関連付けたバブル情報を登録するステップと、
前記バブルに含まれる車両から追随走行要求を受け付けた場合に、複数の前記バブルのうち所定のマッチング条件を満たすバブルを、前記追随走行要求の要求元バブルに対するマッチング候補として選択するステップと、
前記要求元バブルおよび前記マッチング候補それぞれのリーダーにバブル統合を指示するステップと、
前記要求元バブルおよび前記マッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、前記統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報を統合して更新するステップと、
を支援装置に実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、支援装置、支援方法、およびプログラムに関する。

【背景技術】

【0002】

同一方面や同一目的地に向けて複数の車両が隊列を組んで走行する隊列走行（以下、「追随走行」とも記載する。）を行うことにより、運転手の運転負担軽減や、空力性能向上による燃費向上といったメリットがある。追随走行を支援するための技術として、特許文献１には、車車間通信の通信範囲内に存在する車両のうち、目的地までのルートや希望車種が一致する車両同士が追随走行の要求および許可を自動的に行うことが記載されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０２２－３２６７３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、従来の技術では、車車間通信の通信範囲内に追随走行の対象車両が存在しない場合や、対象車両間に追随走行の非対象車両が存在する場合に、追随走行のマッチング相手（前走車または追走車）を見つけることが困難となる可能性がある。

【0005】

本開示の目的は、車車間通信の通信範囲や追随走行の非対象車両の存在に影響されることなく、追随走行の対象車両同士をマッチングさせることができる支援装置、支援方法、およびプログラムを提供することにある。

【課題を解決するための手段】

【0006】

本開示の一態様によれば、支援装置は、車両の追随走行を支援する支援装置であって、前記車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報と生成した前記バブルの識別情報とを関連付けたバブル情報を登録するバブル生成部と、前記バブルに含まれる車両から追随走行要求を受け付けた場合に、複数の前記バブルのうち所定のマッチング条件を満たすバブルを、前記追随走行要求の要求元バブルに対するマッチング候補として選択するマッチング処理部と、前記要求元バブルおよび前記マッチング候補それぞれのリーダーにバブル統合を指示する統合指示部と、前記要求元バブルおよび前記マッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、前記統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報を統合して更新する更新処理部と、を備える。

【0007】

本開示の一態様によれば、支援方法は、車両の追随走行を支援する支援方法であって、前記車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報と生成した前記バブルの識別情報とを関連付けたバブル情報を登録するステップと、前記バブルに含まれる車両から追随走行要求を受け付けた場合に、複数の前記バブルのうち所定のマッチング条件を満たすバブルを、前記追随走行要求の要求元バブルに対するマッチング候補として選択するステップと、前記要求元バブルおよび前記マッチング候補それぞれのリーダーにバブル統合を指示するステップと、前記要求元バブルおよび前記マッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、前記統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報を統合して更新するステップと、を有する。

【0008】

本開示の一態様によれば、プログラムは、車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報と生成した前記バブルの識別情報とを関連付けたバブル情報を登録するステップと、前記バブルに含まれる車両から追随走行要求を受け付けた場合に、複数の前記バブルのうち所定のマッチング条件を満たすバブルを、前記追随走行要求の要求元バブルのマッチング候補として選択するステップと、前記要求元バブルおよび前記マッチング候補それぞれのリーダーにバブル統合を指示するステップと、前記要求元バブルおよび前記マッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、前記統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報を統合して更新するステップと、を支援装置に実行させる。

【発明の効果】

【0009】

上記態様によれば、車車間通信の通信範囲や追随走行の非対象車両の存在に影響されることなく、追随走行の対象車両同士をマッチングさせることができる。

【図面の簡単な説明】

【0010】

【図1】第１の実施形態に係る支援システムの全体構成を示す概略図である。

【図2】第１の実施形態に係る支援装置の機能構成を示すブロック図である。

【図3】第１の実施形態に係るバブルを説明するための図である。

【図4】第１の実施形態に係る支援システムにおけるバブル生成処理の一例を示すシーケンス図である。

【図5】第１の実施形態に係る車両情報の一例を示す図である。

【図6】第１の実施形態に係るバブル情報の一例を示す図である。

【図7】第１の実施形態に係る更新情報の一例を示す図である。

【図8】第１の実施形態に係る支援システムにおけるバブル統合処理の一例を示すシーケンス図である。

【図9】第１の実施形態に係る支援装置におけるマッチング処理の一例を示すフローチャートである。

【図10】第１の実施形態に係る支援装置における速度指示処理の一例を示すフローチャートである。

【図11】第１の実施形態に係るバブル情報の更新処理の一例を示す第１の図である。

【図12】第１の実施形態に係る支援システムにおける情報通知処理の一例を示すシーケンス図である。

【図13】第１の実施形態に係る支援システムにおけるバブル分離処理の一例を示すシーケンス図である。

【図14】第１の実施形態に係るバブル情報の更新処理の一例を示す第２の図である。

【図15】第１の実施形態に係る支援システムにおける異なるエリア間でのバブル情報の管理の一例を示すシーケンス図である。

【図16】第１の実施形態に係る対象車両の状態遷移の一例を示す図である。

【図17】第１の実施形態に係る支援装置の状態遷移の一例を示す図である。

【発明を実施するための形態】

【0011】

＜第１の実施形態＞
（支援システムの全体構成）
以下、図面を参照しながら実施形態について詳しく説明する。
図１は、第１の実施形態に係る支援システムの全体構成を示す概略図である。
図１に示すように、支援システム１は、支援装置１０と、対象車両２０と、交通情報ＤＢ４１と、気象情報ＤＢ４２とを備える。

【0012】

支援装置１０は、対象道路Ｒの監視を行う道路管制センターなどに設けられ、対象道路Ｒにおける対象車両２０の追随走行を支援する追随走行支援サービスを提供する。

【0013】

対象道路Ｒは例えば高速道路であり、対象車両２０および非対象車両３０が混在して走行する。

【0014】

対象車両２０は追随走行支援サービスを利用するコネクテッド車であり、支援装置１０とモバイル通信事業者が提供する通信サービスによる無線通信を行って追随走行に関する各種情報、信号などを送受信する。また、対象車両２０は、他の対象車両２０と無線通信（車車間通信）を行って追随走行に関する各種情報、信号などを送受信する。対象車両２０は、ユーザ（運転者などの搭乗者や自動運転車両の場合は車両の利用者や管理者）が希望する場合に、対象道路Ｒを走行する際に他の対象車両２０と車群をなして走行（追随走行）する。対象車両２０は、運転者が運転する車両であってもよいし、自動運転車両であってもよい。また、追随走行時、後続の対象車両２０は、先行する対象車両２０に電子牽引されてもよい。

【0015】

非対象車両３０は、追随走行支援サービスを利用しない非コネクテッド車である。

【0016】

交通情報ＤＢ４１には、対象道路Ｒの交通情報が記録される。交通情報は、例えば、渋滞、事故、通行止めなどの事象、事象の発生位置（地点または区間）、事象の開始時刻および終了時刻（予想時刻）が含まれる。

【0017】

気象情報ＤＢ４２には、対象道路Ｒの気象情報が記録される。気象情報は、例えば、対象道路Ｒのエリア（１つ以上の区間からなる領域）ごとの天気に関する情報や、天気に起因する事象（路面の凍結など）の情報が含まれる。

【0018】

また、支援システム１は、対象道路Ｒの路側に設けられた路側機器５０をさらに備えていてもよい。路側機器５０は、支援装置１０と対象車両２０との間の通信を中継する。路側機器５０は、対象車両２０と無線通信（路車間通信）を行って各種情報、信号などを送受信する。路側機器５０は、支援装置１０とモバイル通信事業者が提供する通信サービスによる無線通信または有線通信を行って各種情報、信号などを送受信する。

【0019】

なお、本実施形態では、路側機器５０を用いずに、支援装置１０と対象車両２０とが直接通信する態様を例として説明する。

【0020】

（支援装置の機能構成）
図２は、第１の実施形態に係る支援装置の機能構成を示すブロック図である。
図２に示すように、支援装置１０は、プロセッサ１１と、メモリ１２と、ストレージ１３と、通信インタフェース１４とを備える。

【0021】

メモリ１２は、プロセッサ１１の動作に必要なメモリ領域を有する。

【0022】

ストレージ１３は、いわゆる補助記憶装置であって、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。

【0023】

通信インタフェース１４は、外部機器（対象車両２０、交通情報ＤＢ４１、気象情報ＤＢ４２、路側機器５０など）との間で各種情報の送受信を行うためのインタフェースである。

【0024】

プロセッサ１１は、所定のプログラムに従って動作することにより、バブル生成部１１０、マッチング処理部１１１、更新情報取得部１１２、統合指示部１１３、更新処理部１１４、分離処理部１１５、通知部１１６としての機能を発揮する。

【0025】

バブル生成部１１０は、対象車両２０からバブル登録要求を受け付けた場合に、対象車両２０をリーダーとする追随走行の車両群であるバブルを生成し、対象車両２０の車両情報と生成したバブルの識別情報とを関連付けたバブル情報を登録する。

【0026】

マッチング処理部１１１は、一のバブルから追随走行要求を受け付けた場合に、複数のバブルのうち所定のマッチング条件を満たすバブルを、追随走行要求の要求元バブルのマッチング候補として選択する。

【0027】

更新情報取得部１１２は、複数のバブルそれぞれの走行位置を含む更新情報を取得する。

【0028】

統合指示部１１３は、要求元バブルおよびマッチング候補それぞれのリーダーにバブル統合を指示する。

【0029】

更新処理部１１４は、要求元バブルおよびマッチング候補の一方を統合バブルとし、他方を統合バブルに統合される被統合バブルとすることを通知する統合完了通知を受け付けた場合に、統合バブルのバブル情報に被統合バブルのバブル情報を統合して更新する。また、更新処理部１１４は、被統合バブルのバブル情報を削除する。

【0030】

分離処理部１１５は、バブルから離脱車両を離脱させる分離要求を受け付けた場合に、バブルのバブル情報から離脱車両の車両情報を削除して更新するとともに、離脱車両をリーダーとする離脱バブルを生成して、離脱車両の車両情報と生成した離脱バブルの識別情報とを関連付けたバブル情報を登録する。

【0031】

通知部１１６は、要求元バブルの更新情報をマッチング候補に通知するとともに、マッチング候補の更新情報を要求元バブルに通知する。また、通知部１１６は、交通情報ＤＢ４１の交通情報または気象情報ＤＢ４２の気象情報から、バブルの進行方向前方に異常事象があることを検出した場合に、この異常事象に関する異常情報をバブルに通知する。異常事象は、例えば、事故や路面の凍結など、追随走行に影響する可能性のある事象である。

【0032】

なお、支援装置１０は、単独のコンピュータによって構成されるものであってもよいし、支援装置１０の構成を複数のコンピュータに分けて配置し、複数のコンピュータが互いに協働することで支援装置１０として機能するものであってもよい。

【0033】

また、支援装置１０のプロセッサ１１が実行する所定のプログラムは、コンピュータ読み取り可能な記録媒体に記憶される。また、コンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしてもよい。さらに、このプログラムは、上述した機能の一部を実現するためのものであってもよい。更に、上述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であってもよい。

【0034】

（バブルについて）
図３は、第１の実施形態に係るバブルを説明するための図である。
本実施形態に係る支援装置１０は、対象道路Ｒにおいて追随走行する車群を「バブル」という単位で管理する。以下、バブルの概念について図３を参照しながら説明する。

【0035】

図３に示すように、バブルは、少なくとも１台の対象車両２０を含む。また、各バブルに含まれる対象車両２０のうち１台がリーダーとなる。リーダーは、支援装置１０とバブルとの間の通信を代表して行う車両である。リーダー車両が、支援装置１０とリーダー以外の対象車両２０への情報の展開や情報の中継をする機能を有するため、リーダー以外の車両は、支援装置１０とは個別に通信を行わなくても良い。リーダーは、同一バブル内の他の対象車両２０と車車間通信を行って、追随走行に関する各種情報、信号や、支援装置１０から通知された情報の伝達などを行う。

【0036】

図３の（ａ）には、１つのバブルに１台の対象車両２０（２０Ａ，２０Ｂ）のみが含まれる単独バブルＢ１，Ｂ２の例が示されている。単独バブルＢ１，Ｂ２のリーダーは、それぞれ対象車両２０Ａ，２０Ｂである。

【0037】

また、バブル同士を統合して、複数の対象車両２０を含む１つのバブルを形成することができる。図３の（ｂ）には、単独バブルＢ１，Ｂ２を統合し、対象車両２０Ａ，２０Ｂの２台を含む統合バブルＢ１の例が示されている。図３の（ｂ）の例では、単独バブルＢ１は、単独バブルＢ２を吸収して統合バブルＢ１となり、単独バブルＢ２は統合バブルＢ１に吸収されて消滅する被統合バブルＢ２となる。統合バブルＢ１のリーダーは、対象車両２０Ａ，２０Ｂ間で調整して決められる。図３の（ｂ）の例では、対象車両２０Ａが統合バブルＢ１のリーダーとなる。

【0038】

１つのバブルに含まれる対象車両２０の上限台数は予めることも可能であり、その場合は、上限台数に達したバブルは、他のバブルと統合することはできない。また、上限台数に満たないバブル同士でも、統合して上限台数を超える場合には統合することができない。また、上限台数に達するまでは、統合バブルはさらに他の単独バブルまたは統合バブルと統合してもよい。

【0039】

なお、統合バブルに含まれる各対象車両２０の走行フォーメーション（走行レーンや走行順など）をは任意である。図３の（ｂ）の例のように、統合バブルＢ１の各対象車両２０Ａ，２０Ｂは、同一レーンを前後に並んで走行してもよい。このとき、後続の対象車両２０Ｂは、先行する対象車両２０Ａに電子牽引されてもよい。また、統合バブルＢ１の対象車両２０Ａ，２０Ｂは、異なるレーンを走行してもよい。また、危険回避などのために、各対象車両２０Ａ，２０Ｂの運転者、または自動運転車両の場合は内蔵された自動運転制御装置の判断で一時的にレーン変更を行ってもよい。リーダー車両が必ずしも、先頭を走行しなくても良い。フォーメーションやレーンの変更などは、対象車両２０Ａ，２０Ｂ間で車車間通信による相互の調整を行いながら行う。

【0040】

さらに、複数の対象車両２０を含む統合バブルＢ１は、２つのバブルに分離することができる。例えば、図３の（ｃ）に示すように、分岐や出口などで対象車両２０Ａ，２０Ｂの一方が追随走行から離脱する場合に、統合バブルＢ１は２つのバブルＢ１，Ｂ３に分離する。図３の（ｃ）の例では、統合バブルＢ１は、対象道路Ｒの走行を継続する継続バブルＢ１と、対象道路Ｒから退出する離脱バブルＢ３とに分離する。継続バブルＢ１および離脱バブルＢ３それぞれにおいて、新たなリーダーが設定される。図３の（ｃ）の例では、継続バブルＢ１のリーダーは対象車両２０Ａであり、離脱バブルＢ３のリーダーは対象車両２０Ｂである。各バブルに複数の対象車両２０が含まれる場合は、バブル内の対象車両２０間での調整によりリーダーを決定する。

【0041】

（支援装置の処理１：バブル生成処理）
図４は、第１の実施形態に係る支援システムにおけるバブル生成処理の一例を示すシーケンス図である。
以下、図４を参照しながら、バブル生成処理の流れについて詳細に説明する。ここでは、図３の（ａ）に示す対象車両２０Ａのバブルを生成する例について説明する。

【0042】

まず、対象車両２０Ａは、追随走行支援サービスを開始すると判断した場合（ステップＳ１０）、支援装置１０にバブル登録要求を送信する（ステップＳ１１）。

【0043】

対象車両２０Ａは、例えば、ユーザがサービス開始の操作を行った場合に、サービスを開始すると判断する。また、対象車両２０Ａは、ＧＮＳＳなどを用いた既知の位置検出技術を使って自身が対象道路Ｒに進入したことを検出した場合に、サービスを開始すると判断してもよい。あるいは、路側に設置する路車間の通信装置との通信をトリガに開始を判断しても良い。

【0044】

図５は、第１の実施形態に係る車両情報の一例を示す図である。
対象車両２０が支援装置１０に送信するバブル登録要求には、車両情報Ｄ１（図５）が含まれる。図５に示すように、車両情報Ｄ１は、対象車両２０の識別情報（車両ＩＤ）、車両属性、目的地、経由地、目的地到着期限、同伴車両情報、走行位置などの情報を含む。車両属性は、大型車、特大車、バスといった、車両の外形的特徴や用途などに応じた区分を表す情報である。目的地および経由地は、例えば対象道路Ｒの出口ＩＣである。同伴車両情報は、対象車両２０に同伴する同伴車両の台数、および同伴車両の識別情報（車両ＩＤ）を含む。同伴車両とは、例えば、対象道路Ｒに進入する以前から対象車両２０と追随走行を行っていた車両や、対象車両２０が電子牽引などで牽引する被牽引車両である。図３および図５の例では、対象車両２０Ｂは単独で走行する車両であり、同伴車両台数は０となる。

【0045】

次に、支援装置１０のバブル生成部１１０は、バブル登録要求に含まれる車両情報Ｄ１に基づいて、新たなバブルを生成する（ステップＳ１２）。また、バブル生成部１１０は、新たに生成したバブルのバブル情報Ｄ２（図６）を生成して、ストレージ１３に記録する。

【0046】

図６は、第１の実施形態に係るバブル情報の一例を示す図である。
図６に示すように、バブル情報Ｄ２は、バブルの識別情報（バブルＩＤ）、リーダー、包含車両台数、進行方向、共通目的地、個車情報などの情報を含む。リーダーは、バブルのリーダーである対象車両２０の車両ＩＤである。包含車両台数は、バブルに含まれる対象車両２０の合計台数である。共通目的地は、バブルに含まれる対象車両２０が共通して向かう目的地（出口ＩＣ）である。個車情報は、バブルに含まれる各対象車両２０の車両情報Ｄ１（図５）である。また、バブル情報Ｄ２は、バブルに含まれる対象車両２０の目的地のうち、最も遠い目的地を示す最終目的地の情報を含んでもよい。

【0047】

図３、図５、および図６の例では、対象車両２０Ａは同伴車両なし（同伴車両情報＝０）である。この場合、バブル生成部１１０は、対象車両２０Ａのみを含む単独バブルＢ１を生成する。この単独バブルＢ１のリーダーは対象車両２０Ａであり、包含車両台数は「１」である。進行方向および共通目的地は、対象車両２０Ａの進行方向（上り、下り、〇〇方面など）、および目的地（出口ＩＣ）である。個車情報には、対象車両２０Ａの車両情報Ｄ１のみが記録される。

【0048】

なお、同伴車両ありの対象車両２０からバブル登録要求を受け付けた場合、バブル生成部１１０は対象車両２０および同伴車両の複数の車両を含むバブルを生成する。このとき、対象車両２０は、同伴車両との間で車車間通信を行って、同伴車両の車両情報Ｄ１を取得する。また、対象車両２０は、ステップＳ１１において、バブル登録要求とともに、自身および同伴車両の車両情報Ｄ１を支援装置１０に送信する。支援装置１０のバブル生成部１１０は、対象車両２０およびその同伴車両それぞれの車両情報Ｄ１を含むバブル情報Ｄ２を生成する。バブル情報Ｄ２の包含車両台数には、対象車両２０および同伴車両の合計台数が入力される。

【0049】

また、支援装置１０のバブル生成部１１０は、バブル登録要求の送信元である対象車両２０Ａに、生成したバブルＢ１のバブル情報Ｄ２を送信することにより、バブルＩＤを通知する（ステップＳ１３）。

【0050】

対象車両２０Ａは、バブル情報Ｄ２（バブルＩＤ）を受信すると、ＡＣＫ通知を送信する（ステップＳ１４）。また、ＡＣＫ通知には、対象車両２０ＡのバブルＢ１の更新情報Ｄ３（図７）が含まれる。

【0051】

図７は、第１の実施形態に係る更新情報の一例を示す図である。
図７に示すように、更新情報Ｄ３は、バブルの識別情報（バブルＩＤ）、更新情報の更新時刻、走行位置、バブル速度などを含む。対象車両２０ＡのバブルＢ１の場合、更新情報Ｄ３の走行位置およびバブル速度は、更新時刻における対象車両２０Ａの位置および走行速度である。

【0052】

次に、対象車両２０Ａは、ユーザが他の対象車両２０との追随走行（他のバブルとのマッチング）を希望する場合、追随走行要求を支援装置１０に送信する（ステップＳ１５）。対象車両２０Ａは、例えばユーザの追随走行のマッチング候補を探す操作を行った場合に、追随走行要求を送信する。また、対象車両２０Ａは、事前にユーザから追随走行を希望する機能設定を受け付けている場合には、自動的に追随走行要求を送信してもよい。また、追随走行要求には、対象車両２０Ａの現在の位置や走行速度を通知するために更新情報Ｄ３が含まれていてもよい。

【0053】

なお、バブルに複数の対象車両２０（または同伴車両）が含まれる場合、リーダーの対象車両２０が代表して追随走行要求を送信する。このとき、バブルの包含車両台数が既に上限台数に達している場合には、対象車両２０は追随走行要求を送信しない。

【0054】

支援装置１０のマッチング処理部１１１は、バブルＢ１から追随走行要求を受け付けると、ストレージ１３に記録されている他のバブルの中から、要求元バブルＢ１と統合可能なマッチング候補を検索する（ステップＳ１６）。マッチング候補の検索処理の詳細については後述する。

【0055】

また、図４の例では、要求元バブルＢ１のマッチング候補が見つからなかったケースについて説明する。マッチング処理部１１１は、要求元バブルＢ１とのマッチング候補が見つからない場合、「マッチング候補待ち」指示を要求元バブルＢ１のリーダーである対象車両２０Ａに送信する（ステップＳ１７）。

【0056】

バブルＢ１のリーダーである対象車両２０Ａは、「マッチング候補待ち」指示を受け付けると、追随走行を保留状態とする。また、対象車両２０Ａは、以降、所定時間ごとに更新情報Ｄ３を支援装置１０に送信する（ステップＳ１８）。支援装置１０の更新情報取得部１１２は、バブルＢ１（対象車両２０Ａ）から更新情報Ｄ３を受信すると、ストレージ１３に記録して蓄積する。これにより、支援装置１０は、要求元バブルＢ１が対象道路Ｒのどの位置をどの速度で走行しているかを把握することができる。

【0057】

（支援装置の処理２：バブル統合処理）
図８は、第１の実施形態に係る支援システムにおけるバブル統合処理の一例を示すシーケンス図である。
以下、図８を参照しながら、２つのバブルを統合する処理の流れについて詳細に説明する。ここでは、図３の（ａ）～（ｂ）に示すバブルＢ１，Ｂ２を統合する例について説明する。また、バブルＢ１は、図４のステップＳ１５において追随走行要求を送信し、マッチング候補待ちの状態であるとする。

【0058】

各バブルＢ１，Ｂ２のリーダー（対象車両２０Ａ，２０Ｂ。以下、リーダー２０Ａ，２０Ｂとも記載する。）は、それぞれ所定時間ごとに更新情報Ｄ３を支援装置１０に送信する（ステップＳ２０）。支援装置１０の更新情報取得部１１２は、バブルＢ１，Ｂ２それぞれから更新情報Ｄ３を受信すると、ストレージ１３に記録して蓄積する。この処理は、図４のステップＳ１８と同じ処理である。

【0059】

支援装置１０のマッチング処理部１１１は、ストレージ１３に記録された各バブルの更新情報Ｄ３に基づいて、バブルＢ１と統合するマッチング候補を検索する（ステップＳ２１）。

【0060】

図９は、第１の実施形態に係る支援装置におけるマッチング処理の一例を示すフローチャートである。
図９を参照しながら、支援装置１０がバブルＢ１のマッチング候補を検索する処理の流れについて説明する。なお、図９に示す各処理（ステップＳ２１１～Ｓ２１６）は、図４のステップＳ１６および図８のステップＳ２１で共通の処理である。

【0061】

まず、マッチング処理部１１１は、各バブルの更新情報Ｄ３に基づいて、追随走行に関するＯＤＤ（Operational Design Domain）の範囲内のバブルを抽出する（ステップＳ２１１）。例えば、マッチング処理部１１１は、ストレージ１３に登録されている複数のバブルのうち、バブル速度が所定の追随走行上限速度（例えば、８０ｋｍ／ｈ）以下であるバブルを抽出する。マッチング処理部１１１は、バブル速度が追随走行上限速度を超えているバブルについては、マッチング対象外として除外する。なお、追随走行上限速度は、対象道路Ｒに規定される最低速度以上、最高速度以下の範囲内となるように設定される。また、車両属性ごとに異なる追随走行上限速度が設定されてもよい。

【0062】

次に、マッチング処理部１１１は、要求元バブルＢ１の走行位置の前後の所定の追随走行制限区間（例えば、１ｋｍ）内に、統合不可のバブル、すなわち、包含車両台数が上限台数に達したバブルが存在するか判断する（ステップＳ２１２）。

【0063】

マッチング処理部１１１は、要求元バブルＢ１の設定区間内に包含車両台数が上限台数に達したバブルが存在する場合（ステップＳ２１２；ＮＯ）、要求元バブルＢ１が統合可能なマッチング候補なしと判断する（ステップＳ２１６）。この場合、マッチング処理部１１１は、マッチング候補の検索処理を一旦終了して、図４のステップＳ１７に進む。これにより、マッチング処理部１１１は、バブル同士の間隔を確保し、バブル同士が接近して追随走行に支障が生じることを抑制する。

【0064】

次に、マッチング処理部１１１は、ステップＳ２１１で抽出したバブルのうち、要求元バブルＢ１の走行位置から進行方向前方の検索距離（例えば、１ｋｍ）内に、所定のマッチング条件を満たすバブルがあるか判断する（ステップＳ２１３）。例えば、マッチング条件は以下の（１）～（４）などの条件である。

【0065】

（１）要求元バブルＢ１と進行方向が一致する。

【0066】

（２）要求元バブルＢ１と車両属性が一致する。なお、車両属性は必ずしも同一でなくてもよい。例えば、統合可能な車両属性の組み合わせ予めテーブルなどで設定しておき、要求元バブルＢ１の車両属性（例えば、大型車）と統合可能な車両属性（例えば、大型車またはバス）であれば、車両属性が一致すると判断してもよい。

【0067】

（３）要求元バブルＢ１の包含車両台数と、抽出したバブルの包含車両台数との合計台数が上限台数以下（つまり、要求元バブルＢ１に含まれる対象車両を追加可能）である。

【0068】

（４）要求元バブルＢ１の共通目的地までの走行経路と、抽出したバブルの共通目的地までの走行経路とで少なくとも一部の走行経路が共通し、この共通する走行経路の長さが所定距離（例えば、４０ｋｍ）以上である。または、バブル速度を追随走行上限速度としたときに、共通する走行経路の走行時間が所定時間（例えば、３０分）以上である。

【0069】

マッチング処理部１１１は、要求元バブルＢ１の進行方向前方に、上記のマッチング条件（１）～（４）を満たすバブルがある場合（ステップＳ２１３；ＹＥＳ）、このバブルをマッチング候補として選択する（ステップＳ２１５）。

【0070】

また、マッチング処理部１１１は、要求元バブルＢ１の進行方向前方にマッチング条件を満たすバブルが存在しない場合（ステップＳ２１３；ＮＯ）、要求元バブルＢ１の進行方向後方でマッチング候補を検索する。具体的には、マッチング処理部１１１は、要求元バブルＢ１の走行位置から進行方向後方の検索距離（例えば、１ｋｍ）内に、上記のマッチング条件（１）～（４）を満たすバブルがあるか判断する（ステップＳ２１４）。

【0071】

マッチング処理部１１１は、要求元バブルＢ１の進行方向後方に、上記のマッチング条件を満たすバブルがある場合（ステップＳ２１４；ＹＥＳ）、このバブルをマッチング候補として選択する（ステップＳ２１５）。図３の例では、マッチング処理部１１１は要求元バブルＢ１の進行方向後方に存在するバブルＢ２をマッチング候補として選択する。

【0072】

一方、マッチング処理部１１１は、要求元バブルＢ１の進行方向後方にマッチング条件を満たすバブルが存在しない場合（ステップＳ２１４；ＮＯ）、要求元バブルＢ１のマッチング候補なしと判断する（ステップＳ２１６）。この場合、マッチング処理部１１１は、マッチング候補の検索処理を一旦終了して、図４のステップＳ１７に進む。

【0073】

マッチング処理部１１１は、上記のようにマッチング候補の検索距離を限定することにより、合流（統合）するまでに時間がかかるバブルをマッチング候補から除外することができる。

【0074】

また、マッチング処理部１１１は、マッチング候補なし（ステップＳ２１６）であった場合も、要求元バブルＢ１から更新情報Ｄ３を受信する度に、または、所定の検索待機時間が経過するごとに、図９のマッチング候補を検索する一連の処理を再度実施する。これにより、検索距離内にマッチング候補が見つからなかった場合でも、例えば後に対象道路Ｒに進入した新たなバブルが生成され、且つこのバブルがマッチング条件を満たすときに、この新たなバブルを要求元バブルＢ１のマッチング候補として選択することができる。

【0075】

なお、マッチング処理部１１１は、上記した各処理において、更新情報Ｄ３の更新時刻と現在時刻とに時間差がある場合には、各バブルの現在時刻における走行位置をこの時間差およびバブル速度に基づいて推定してもよい。

【0076】

次に、図８に戻り、ステップＳ２１において支援装置１０のマッチング処理部１１１が要求元バブルＢ１のマッチング候補としてバブルＢ２を選択した後の処理について説明する。支援装置１０の統合指示部１１３は、要求元バブルＢ１およびマッチング候補バブルＢ２それぞれのリーダー２０Ａ，２０Ｂに統合待機指示を送信する（ステップＳ２２）。統合待機指示には、それぞれのマッチング相手となるバブルのバブルＩＤが含まれる。例えば、要求元バブルＢ１には、統合待機指示とともに、マッチング候補バブルＢ２のバブルＩＤが送信される。また、マッチング候補バブルＢ２には、統合待機指示とともに、要求元バブルＢ１のバブルＩＤが送信される。

【0077】

また、統合予定のバブルＢ１，Ｂ２のリーダー２０Ａ，２０Ｂは、それぞれ、統合待機指示を受信すると、ＡＣＫ通知を送信する（ステップＳ２３）。また、ＡＣＫ通知には、各バブルＢ１，Ｂ２の更新情報Ｄ３が含まれる。

【0078】

支援装置１０の統合指示部１１３は、ＡＣＫ通知に含まれる各バブルＢ１，Ｂ２の更新情報Ｄ３に基づいて、統合予定のバブルＢ１，Ｂ２それぞれの統合指示を生成して送信する（ステップＳ２４）。

【0079】

統合指示は、例えば、バブル速度の変更指示である。統合指示部１１３は、統合予定のバブルＢ１，Ｂ２のうち、進行方向後方を走行する後続バブル（図３の例では、バブルＢ２）が、進行方向前方を走行する先行バブル（図３の例では、バブルＢ１）に追いつくように、または、先行バブルＢ１が後続バブルＢ２に追いつかれるように、各バブルのバブル速度を指示する。

【0080】

図１０は、第１の実施形態に係る支援装置における速度指示処理の一例を示すフローチャートである。
図１０を参照しながら、支援装置１０が後続バブルＢ２および先行バブルＢ１の速度指示を行う処理の詳細について説明する。

【0081】

まず、統合指示部１１３は、後続バブルＢ２の現在のバブル速度が上限速度未満である場合（ステップＳ２４１；ＹＥＳ）、後続バブルＢ２の速度指示を「上限速度に加速」とする（ステップＳ２４２）。

【0082】

上限速度は、追随走行上限速度である。例えば、後続バブルＢ２の現在のバブル速度が７０ｋｍ／ｈ、追随走行上限速度が８０ｋｍ／ｈである場合、統合指示部１１３は、後続バブルＢ２の速度指示を「追随走行上限速度８０ｋｍ／ｈに加速」とする。

【0083】

また、統合指示部１１３は、交通情報ＤＢ４１の交通情報や、気象情報ＤＢ４２の気象情報を参照して、上限速度を変更してもよい。例えば、雨などにより対象道路Ｒに臨時速度規制があり、かつ、臨時速度規制における制限速度が追随走行上限速度よりも低い場合、臨時速度規制における制限速度を上限速度として考える。後続バブルＢ２の現在のバブル速度が７０ｋｍ／ｈ、追随走行上限速度が８０ｋｍ／ｈ、臨時速度規制における制限速度が７５ｋｍ／ｈである場合、統合指示部１１３は、臨時速度規制における制限速度７５ｋｍ／ｈを上限速度とする。また、このとき、統合指示部１１３は、後続バブルＢ２の速度指示を「臨時速度規制における制限速度７５ｋｍ／ｈに加速」とする。

【0084】

一方、後続バブルＢ２の現在のバブル速度が上限速度（追随走行上限速度または臨時速度規制における制限速度）と同じである場合（ステップＳ２４１；ＮＯ）、統合指示部１１３は、後続バブルＢ２の速度指示を「現在のバブル速度を維持」とする（ステップＳ２４３）。

【0085】

次に、統合指示部１１３は、先行バブルＢ１の現在のバブル速度に基づき、先行バブルＢ１の速度指示を設定する。

【0086】

統合指示部１１３は、先行バブルＢ１の現在のバブル速度が所定速度を超える場合（ステップＳ２４４；ＹＥＳ）、先行バブルＢ１の速度指示を「指定速度に減速」とする（ステップＳ２４５）。所定速度は上限速度から所定マージンαを減じた値であり、例えば上限速度＝８０ｋｍ/ｈ、所定マージンα＝５ｋｍ／ｈのとき、７５ｋｍ／ｈである。所定マージンαの値は任意に変更してもよい。また、指定速度は、例えば、上限速度から所定マージンαを減じた値である。例えば、先行バブルＢ１の現在のバブル速度が８０ｋｍ／ｈである場合、統合指示部１１３は、先行バブルＢ１の速度指示を「７５ｋｍ／ｈに減速」とする。そうすると、先行バブルＢ１と後続バブルＢ２との間の距離が１ｋｍであり、指示後の各バブルＢ１，Ｂ２の速度差が５ｋｍ／ｈであるとすると、後続バブルＢ２は先行バブルＢ１に約１２分後（約１６ｋｍ走行後）に追いつく（合流する）ことができる。

【0087】

また、統合指示部１１３は、先行バブルＢ１の現在のバブル速度が所定速度以下である場合（ステップＳ２４４；ＹＥＳ）、先行バブルＢ１の速度指示を「現在のバブル速度を維持」とする（ステップＳ２４５）。例えば、先行バブルＢ１の現在のバブル速度が７５ｋｍ／ｈである場合、この速度を維持するように指示する。

【0088】

また、統合指示部１１３は、各バブルの速度指示を決定すると、後続バブルＢ２および先行バブルＢ１それぞれに速度指示を送信する（ステップＳ２４７）。そうすると、各バブルＢ１，Ｂ２のリーダー２０Ａ，２０Ｂは、受信した速度指示に従って走行する。また、各バブルＢ１，Ｂ２が２台以上の対象車両２０からなる場合、リーダー２０Ａ，２０Ｂは、車車間通信を介して他の対象車両２０（非リーダー）に速度指示を伝達する。他の対象車両２０（非リーダー）は、リーダー２０Ａ，２０Ｂから伝達された速度指示に従って走行する。なお、各対象車両２０が有人車両である場合、対象車両２０は速度指示を運転者に提示し、運転者が対象車両２０に提示された速度指示に従って運転を行う。また、対象車両２０がクルーズコントロール装置を有している場合、または、自動運転車両である場合、クルーズコントロール装置または自動運転制御装置が速度指示に従って加速および減速の制御を自動的に行つても良い。

【0089】

次に、図８に戻り、ステップＳ２４において支援装置１０の統合指示部１１３が統合予定のバブルＢ１，Ｂ２に統合指示（速度指示）を送信した後の処理について説明する。各バブルＢ１，Ｂ２は、統合指示を受信してから統合が完了するまでの間、所定時間ごとに更新情報Ｄ３を支援装置１０に送信する（ステップＳ２５）。

【0090】

支援装置１０の通知部１１６は、バブルＢ１，Ｂ２から更新情報Ｄ３を受信すると、それぞれのマッチング相手に更新情報Ｄ３を通知（転送）する（ステップＳ２６）。つまり、通知部１１６は、バブルＢ１から受信した更新情報Ｄ３をバブルＢ２に通知し、バブルＢ２から受信した更新情報Ｄ３をバブルＢ１に通知する。バブルＢ１，Ｂ２の対象車両２０Ａ，２０Ｂは、マッチング相手の更新情報Ｄ３に基づいて、マッチング相手の走行位置や、マッチング相手までの距離などをユーザに提示してもよいし、自動運転制御用の情報として用いてもよい。

【0091】

次に、バブルＢ１，Ｂ２のリーダー２０Ａ，２０Ｂは、車車間通信が可能な距離に接近すると、バブルＩＤを送受信して相互にマッチング相手であることを確認した後、バブルＢ１，Ｂ２の統合処理を行う（ステップＳ２７）。

【0092】

統合処理では、バブルＢ１，Ｂ２間での調整により、どの対象車両２０を統合バブルのリーダーとするか決定する。図３の例では、対象車両２０Ａが統合バブルＢ１のリーダーとなる。この場合、対象車両２０Ａの先行バブルＢ１が後続バブルＢ２を統合して統合バブルＢ１となり、後続バブルＢ２が先行バブルＢ１に統合される被統合バブルＢ１となる。また、統合バブルＢ１の各対象車両２０は、車車間通信を介して互いの車両情報Ｄ１を取得する。これにより、各対象車両２０は、統合バブルＢ１の最終目的地（対象車両２０の目的地のうち、最も遠い目的地）や共通目的地（対象車両２０の目的地のうち、最も近いの目的地）などの情報を共有することができる。

【0093】

また、統合処理では、バブルＢ１，Ｂ２の各対象車両２０は、車車間通信で直接的に、または他の対象車両２０を介して間接的に通信可能となるように、カメラなどのセンサで互いの位置や周辺に存在する非対象車両３０の有無などを確認して、必要に応じてフォーメーションの変更を行う。具体的にどのようなフォーメーションとするかは、各対象車両２０の運転者または自動運転制御装置の判断に依存する。バブルＢ１，Ｂ２双方の対象車両２０が通信しながらの走行、すなわち、追随走行が可能な状態に移行すると、統合処理完了となる。

【0094】

統合処理が完了すると、被統合バブルＢ１のリーダー２０Ｂおよび統合バブルＢ１のリーダー２０Ａは、それぞれ支援装置１０に統合完了通知を送信する（ステップＳ２８）。被統合バブルＢ１のリーダー２０Ｂは、統合完了通知において、自身（被統合バブルＢ２）のバブルＩＤと、自身の統合先となる統合バブルＢ１のバブルＩＤを合わせて通知する。また、統合バブルＢ１のリーダー２０Ａは、統合完了通知において、自身（統合バブルＢ１）のバブルＩＤと、統合バブルＢ１の各対象車両２０（リーダー２０Ａおよび非リーダー２０Ｂ）の車両情報Ｄ１を通知する。以降は、対象車両２０Ａは統合バブルＢ１のリーダーとして、対象車両２０Ｂは統合バブルＢ１の非リーダーとして、互いに車車間通信を行いながら追随走行を行う。

【0095】

また、支援装置１０の更新処理部１１４は、被統合バブルＢ１および統合バブルＢ１から受信した統合完了通知に基づいて、バブル情報Ｄ２を更新する（ステップＳ２９）。

【0096】

図１１は、第１の実施形態に係るバブル情報の更新処理の一例を示す第１の図である。
図１１に示すように、更新処理部１１４は、統合バブルＢ１および被統合バブルＢ２の統合完了通知に基づいて、統合バブルＢ１のバブル情報Ｄ２に被統合バブルＢ２のバブル情報Ｄ２を追加して更新する。統合バブルＢ１のバブルＩＤは、統合前のバブルＢ２のバブルＩＤを引き継ぐため、変更なしである。統合バブルＢ１のリーダーは、バブルＢ１，Ｂ２間で調整後の新たなリーダーの車両ＩＤとなる。図１１の例では、統合バブルＢ１のリーダーは対象車両２０Ａである。包含車両台数は、バブルＢ１，Ｂ２に含まれる対象車両２０（および同伴車両）の合計台数である。共通目的地は、バブルＢ１，Ｂ２の両方が到達する目的地であり、バブルＢ１，Ｂ２の共通目的地のうち近い方が記録される。個車情報には、統合バブルＢ１に含まれる全ての対象車両２０Ａ，２０Ｂそれぞれの車両情報Ｄ１が記録される。

【0097】

また、更新処理部１１４は、被統合バブルＢ１のバブル情報Ｄ２を削除する。

【0098】

（支援装置の処理３：情報通知処理）
図１２は、第１の実施形態に係る支援システムにおける情報通知処理の一例を示すシーケンス図である。
以下、図１２を参照しながら、支援装置１０が各バブルに各種情報を通知する処理の流れについて説明する。

【0099】

まず、統合バブルＢ１のリーダー２０Ａは、所定時間ごとに統合バブルＢ１の更新情報Ｄ３を支援装置１０に送信する（ステップＳ３０）。

【0100】

支援装置１０の通知部１１６は、交通情報ＤＢ４１および気象情報ＤＢ４２を参照して、統合バブルＢ１の更新情報Ｄ３に含まれる走行位置よりも進行方向前方において、追随走行に影響を与える異常事象や規制情報があるか確認する。追随走行に影響を与える異常事象または規制情報を検出した場合（ステップＳ３１）、通知部１１６は、検出した内容に応じた異常情報または速度指示を統合バブルＢ１のリーダー２０Ａに送信する（ステップＳ３２）。

【0101】

例えば、通知部１１６は、交通情報ＤＢ４１の交通情報や気象情報ＤＢ４２の気象情報から、統合バブルＢ１の進行方向前方のある区間において、異常事象を検出したとする。異常事象は、例えば、路面凍結、事故などである。この場合、通知部１１６は、異常事象の内容（路面凍結）、異常事象が発生した（または発生が予想される）区間を含む異常情報を生成して、統合バブルＢ１のリーダー２０Ａに送信する（ステップＳ３２）。また、交通情報や気象情報に異常事象の終了予測時刻が含まれている場合、または、異常事象から終了予測時刻を推定可能である場合、異常情報に異常事象の終了予測時刻を含めてもよい。

【0102】

また、例えば、通知部１１６は、交通情報ＤＢ４１の交通情報から、統合バブルＢ１の進行方向前方のある区間において、臨時速度規制が設定されたことを検出したとする。この場合、通知部１１６は、統合バブルＢ１のバブル速度を臨時速度規制における制限速度まで減速する速度指示を生成して、統合バブルＢ１のリーダー２０Ａに送信する（ステップＳ３２）。

【0103】

通知部は、異常事象および規制情報の両方が検出された場合には、異常情報および速度指示の両方を統合バブルＢ１のリーダー２０Ａに送信してもよい。

【0104】

次に、統合バブルＢ１のリーダー２０Ａは、支援装置１０から異常情報または速度指示を受信した場合、この異常情報または速度指示を、車車間通信により統合バブルＢ１の他の対象車両２０（非リーダー２０Ｂ）に伝達する（ステップＳ３３）。

【0105】

また、リーダー２０Ａおよび非リーダー２０Ｂは、それぞれ、異常情報または速度指示に応じた処理を行う。異常情報に応じた処理は、リーダー２０Ａおよび非リーダー２０Ｂの運転者または自動運転制御装置の判断に依存する。また、リーダー２０Ａおよび非リーダー２０Ｂは、受信した速度指示に従って走行する。速度のコントロールは、運転者、クルーズコントロール装置、または自動運転制御装置が実施する。

【0106】

このように、支援装置１０は、異常事象や規制情報などを検出した場合に、複数の対象車両２０Ａ，２０Ｂそれぞれと個別に通信を行う必要はなく、統合バブルＢ１のリーダー２０Ａとのみ通信を行えばよいので、支援装置１０と対象車両２０との間の通信量を低減することができる。また、個々の対象車両２０Ａ，２０Ｂの走行位置などを監視することなく、バブル毎に走行位置を監視すればよいので、監視に要する処理負荷やリソースを低減することができる。ここに示した、リーダー車両を介した異常事象や規制情報の通信については、支援装置１０と個々の対象車両との通信処理が処理負荷やリソースで許容できる場合は、個別に送信することも、方法としてあり得る。

【0107】

（支援装置の処理３：バブル分離処理）
図１３は、第１の実施形態に係る支援システムにおけるバブル分離処理の一例を示すシーケンス図である。
以下、図１３を参照しながら、バブルを２つに分離する処理の流れについて詳細に説明する。ここでは、図３の（ｂ）～（ｃ）に示す統合バブルＢ１をバブルＢ２，Ｂ３に分離する例について説明する。また、図３および図１３の例では、非リーダー２０Ｂが統合バブルＢ１から離脱する例について説明するが、リーダー２０Ａが統合バブルＢ１から離脱してもよい。

【0108】

まず、統合バブルＢ１の対象車両２０Ｂは、分岐や出口などで統合バブルＢ１から離脱する必要がある場合、車車間通信を介して他の対象車両２０Ａに離脱通知を送信する（ステップＳ４０）。例えば、対象車両２０Ｂは、自身の目的地（出口ＩＣ）が統合バブルＢ１の最終目的地（他の対象車両２０Ａの目的地）よりも手前であり、且つ、自身の目的地から所定距離前（例えば、５ｋｍ前）の位置に到達したとき、他の対象車両２０Ａに離脱通知を送信する。

【0109】

次に、統合バブルＢ１の各対象車両２０は、車車間通信を行って離脱調停処理を行う（ステップＳ４１）。離脱調停処理では、例えば、リーダー２０Ａは、離脱通知の送信元の対象車両２０Ｂ（以下、離脱車両２０Ｂとも記載する。）から、車両ＩＤおよび離脱位置（出口ＩＣ）を取得する。また、対象道路Ｒの走行を継続する継続バブルＢ１（統合バブルＢ１）に残留する対象車両２０間で調整を行い、継続バブルＢ１の新たなリーダーとなる対象車両を決定する。図３および図１３の例では、継続バブルＢ１に残留するのは対象車両２０Ａのみであるため、対象車両２０Ａが継続してリーダーとなる。なお、継続バブルＢ１に残留する対象車両２０が２台以上ある場合、対象車両２０Ａが継続してリーダーとなってもよいし、他の対象車両２０とリーダーを交代してもよい。また、離脱車両が複数存在する場合は、統合バブルＢ１から分離するバブルのリーダーを離脱車両の中から決定する。図３および図１３の例では、離脱車両は対象車両２０Ｂのみであるため、対象車両２０Ｂが分離するバブルのリーダーとなる。

【0110】

また、離脱調停処理が完了すると、継続バブルＢ１のリーダー２０Ａは、支援装置１０に離脱バブルＩＤ要求を送信する（ステップＳ４２）。離脱バブルＩＤ要求には、継続バブルＢ１（統合バブルＢ１）のバブルＩＤ、継続バブルＢ１から離脱する離脱車両２０Ｂの車両ＩＤなどが含まれる。

【0111】

次に、支援装置１０の分離処理部１１５は、離脱車両２０Ｂ用の新たな離脱バブルＢ３を生成する（ステップＳ４３）。

【0112】

図１４は、第１の実施形態に係るバブル情報の更新処理の一例を示す第２の図である。
図１４に示すように、分離処理部１１５は、新たに生成した離脱バブルＢ３のバブル情報Ｄ２を生成して、ストレージ１３に記録する。離脱バブルＢ３の離脱車両２０Ｂの車両情報Ｄ１は、離脱元となる統合バブルＢ１のバブル情報Ｄ２からコピーしてもよいし、継続バブルＢ１のリーダー２０Ａから取得してもよい。また、分離処理部１１５は、継続バブルＢ１のバブル情報Ｄ２について、離脱車両２０Ｂの車両情報Ｄ１の削除や、包含車両台数から離脱車両の台数を減じるなどの更新処理を行う。

【0113】

支援装置１０の分離処理部１１５は、離脱バブルＢ３を生成すると、離脱バブルＢ３のバブルＩＤと、離脱バブルＢ３に含まれる離脱車両２０Ｂの車両ＩＤとを継続バブルＢ１のリーダー２０Ａに通知する（ステップＳ４４）。

【0114】

継続バブルＢ１のリーダーは、離脱バブルＢ３のバブルＩＤを受信すると、支援装置１０から受信した離脱バブルＢ３のバブルＩＤを離脱車両２０Ｂに通知する（ステップＳ４５）。この通知を受けて、離脱車両２０Ｂは、統合バブルＢ１の非リーダーから、離脱バブルＢ３のリーダーに変化する。

【0115】

また、統合バブルＢ１が継続バブルＢ１と離脱バブルＢ３とに分離した後、継続バブルＢ１のリーダー２０Ａと、離脱バブルＢ３のリーダー２０Ｂは、それぞれ所定時間ごとに更新情報Ｄ３を支援装置１０に送信する（ステップＳ４６）。

【0116】

次に、離脱バブルＢ３のリーダー２０Ｂは、追随走行サービスを終了すると判断した場合（ステップＳ４７）、支援装置１０にサービス離脱通知を送信する（ステップＳ４８）。サービス離脱通知には、離脱バブルＢ３のバブルＩＤが含まれる。

【0117】

離脱バブルＢ３のリーダー２０Ｂは、例えば、ユーザがサービス終了の操作を行った場合に、サービスを終了すると判断する。また、リーダー２０Ｂは、自身が対象道路Ｒから退出したことを検出した場合に、サービスを終了すると判断してもよい。または、路側に設置した路車間の通信装置（路側機器５０）との通信をトリガにして、終了を判断しても良い。

【0118】

また、支援装置１０の更新処理部１１４は、離脱バブルＢ３からサービス離脱通知を受信した場合、ストレージ１３から離脱バブルＢ３のバブル情報Ｄ２を削除する（ステップＳ４９）。これにより、支援装置１０は、追随走行支援サービスを終了したバブルの管理、監視などの処理を終了する。

【0119】

（支援装置の処理４：異なるエリア間でのバブル情報の管理について）
図１５は、第１の実施形態に係る支援システムにおける異なるエリア間でのバブル情報の管理の一例を示すシーケンス図である。
図１には、支援システム１が１台の支援装置１０を備える例が示されているが、これに限られることはない。支援システム１は、対象道路Ｒが複数のエリアに跨っている場合、複数の支援装置１０をエリア毎に設けてもよい。また、エリアごとに異なる道路事業者が対象道路Ｒを運営しており、各エリアの支援装置１０は、各道路事業者が運用してもよい。ここでは、図１５に示すように、対象道路Ｒが２つのエリアＡ，Ｂを有し、エリアＡの支援装置１０Ａと、エリアＢの支援装置１０Ｂの２つが設けられている例について説明する。

【0120】

まず、エリアＡにおいて、支援装置１０Ａが対象車両２０Ａのバブル生成処理（図４のステップＳ１０～Ｓ１７）を実行し、対象車両２０ＡをリーダーとするバブルＢ１が登録されたとする。また、バブルＢ１のリーダー２０Ａは、エリアＡを走行中、所定時間ごとに更新情報をエリアＡの支援装置１０Ａに送信する（ステップＳ５０）。

【0121】

支援装置１０Ａの更新情報取得部１１２は、バブルＢ１から更新情報Ｄ３を受信すると、このバブルＢ１のバブルＩＤ（バブル情報Ｄ２）が登録されているか確認する（ステップＳ５１）。支援装置１０ＡにバブルＢ１のバブル情報Ｄ２が登録済みである場合、支援装置１０Ａの更新情報取得部１１２は、バブルＢ１の走行位置などの管理用の情報として、更新情報Ｄ３をストレージ１３に記録する（ステップＳ５２）。

【0122】

また、バブルＢ１がエリアＡからエリアＢに移動したとする。エリアＢに移動後、バブルＢ１のリーダー２０Ａは、所定時間ごとに更新情報Ｄ３を支援装置１０Ｂに送信する（ステップＳ５０）。

【0123】

支援装置１０Ｂの更新情報取得部１１２は、バブルＢ１から更新情報Ｄ３を受信すると、このバブルＢ１のバブルＩＤ（バブル情報Ｄ２）が登録されているか確認する（ステップＳ５１）。バブルＢ１のバブル情報Ｄ２は、エリアＡで登録されたものであるため、エリアＢの支援装置１０Ｂには未登録である。このため、支援装置１０Ａの更新情報取得部１１２は、バブルＢ１に対し、バブル情報Ｄ２の送信を要求する（ステップＳ５３）。

【0124】

バブルＢ１のリーダー２０Ａは、バブル情報Ｄ２の送信要求を受け付けると、支援装置１０ＡからバブルＩＤとともに受信したバブル情報Ｄ２（図３のステップＳ１３）を、支援装置１０Ｂに送信する（ステップＳ５４）。

【0125】

支援装置１０Ｂの更新情報取得部１１２は、バブルＢ１から受信したバブル情報Ｄ２をストレージ１３に記録する（ステップＳ５５）。

【0126】

また、バブルＢ１のリーダー２０Ａは、エリアＢを走行中、所定時間ごとに更新情報Ｄ３を支援装置１０Ｂに送信する（ステップＳ５０）。

【0127】

支援装置１０Ｂの更新情報取得部１１２は、バブルＢ１から更新情報Ｄ３を受信すると、このバブルＢ１のバブルＩＤが登録されているか確認する（ステップＳ５１）。ステップＳ５３～Ｓ５５の処理により、支援装置１０ＢにはバブルＢ１のバブル情報Ｄ２が登録済みとなったので、支援装置１０Ｂの更新情報取得部１１２は、バブルＢ１の走行位置などの管理用の情報として、更新情報Ｄ３をストレージ１３に記録する（ステップＳ５２）。

【0128】

このように、支援装置１０Ｂは、バブルＢ１を介して支援装置１０Ａが生成したバブルＢ１のバブル情報Ｄ２を取得することにより、バブルＢ１の管理をエリアＡの支援装置１０Ａから引き継ぐことができる。ここでは、支援装置１０Ａと支援装置１０Ｂとが、バブルに関する情報を共有しない場合の処理を示したが、複数の支援装置１０同士で、バブル情報を共有して処理しても良い。

【0129】

（対象車両の状態遷移）
図１６は、第１の実施形態に係る対象車両の状態遷移の一例を示す図である。
図１６を参照しながら、対象車両２０の状態および役割（リーダーまたは非リーダー）がどのように変化するかを、図３の対象車両２０Ａを例として説明する。

【0130】

「Ｖ１１：開始待ち」は、対象車両２０Ａがバブルを用いた追随走行支援サービスを開始していない状態である。

【0131】

「Ｖ１２：バブルＩＤ発行待ち」は、対象車両２０Ａが追随走行支援サービスを開始（Ｃ１０１）した後、支援装置１０からのバブルＩＤ通知を待っている状態である。

【0132】

「Ｖ１３：単独バブル（リーダー）」は、対象車両２０Ａが支援装置１０から単独バブルＢ１のバブルＩＤが発行された（Ｃ１０２）状態である。対象車両２０Ａは、この状態に遷移してから、支援装置１０に更新情報Ｄ３の送信を行う。単独バブルＢ１には他の対象車両が含まれていないため、対象車両２０Ａは単独バブルＢ１のリーダーとなっている。

【0133】

「Ｖ１４：マッチング候補待ち（リーダー）」は、支援装置１０に「追随走行要求を行い（Ｃ１０３）、支援装置１０によるマッチング候補の選定通知を待っている状態である。この状態でマッチングをキャンセル（Ｃ１０５）することもできる。そうすると、遷移元の状態（Ｖ１３）に戻る。

【0134】

「Ｖ１５：ネゴシエーション状態（リーダー）」は、バブルの統合処理中、または、バブルの分離処理中の状態である。
バブルの統合処理中の状態とは、支援装置１０からマッチング候補のバブルＩＤを通知（Ｃ１０６）されてから、バブル間の統合処理が完了するまでの状態（図８のステップＳ２１～Ｓ２８）である。リーダーの選定は、対象車両２０間での調整による。なお、マッチング中止（キャンセル）となった場合には（Ｃ１０７）、遷移元の状態（Ｖ１３）に戻る。
バブルの分離処理中の状態とは、統合バブルのリーダーから離脱要求があり、バブルの分離が完了するまでの状態（図１３のステップＳ４０～Ｓ４５）である。対象車両２０Ａ自身がリーダーであり離脱要求を行うケース（Ｃ１１４）と、対象車両２０Ａが非リーダーであり、離脱するリーダーに代えてリーダーに昇格するケース（Ｃ１１５）がある。

【0135】

「Ｖ１６：統合完了（リーダー）」は、バブル同士の統合処理の結果、対象車両２０Ａが統合バブルＢ１のリーダーの立場を維持できた場合（Ｃ１０９）の状態である。
対象車両２０Ａは、統合バブルＢ１に空席がない（包含車両台数＝上限台数）場合（Ｃ１１２）、この状態を継続しながら走行する。
対象車両２０Ａは、統合バブルＢ１に空席がある（包含車両台数＜上限台数）場合や他車両（非リーダー）の離脱による空席が発生した場合（Ｃ１１３）、「Ｖ１３：単独バブル（リーダー）」に遷移する。
また、リーダーである対象車両２０Ａ自身が統合バブルＢ１からの離脱、またはリーダーから非リーダーへの降格を希望する場合（Ｃ１１４）、「Ｖ１５：ネゴシエーション状態（リーダー）」に遷移する。その際、リーダーである対象車両２０Ａは、統合バブルＢ１内の他の対象車両２０に対して、新たなリーダー選定などの再調整（離脱調停）を行うよう指示する。

【0136】

「Ｖ１７：統合完了（非リーダー）」は、バブル同士の統合処理の結果、対象車両２０Ａが統合バブルのリーダーにならなかった（降格した）場合（Ｃ１１０）の状態である。
非リーダーである対象車両２０Ａが対象道路Ｒからの退出や、ＳＡ／ＰＡへ進むことを希望する場合、統合バブルのリーダーに離脱要求を行うことで（Ｃ１１６）、この統合バブルから離脱することができる。
また、リーダーの離脱要求、または、リーダーが非リーダーへの降格を希望した場合に、リーダーから再調整指示を受け付ける。再調整中にリーダーとの車車間通信が途絶えた場合、リーダー消失（Ｃ１１７）と判断して、「Ｖ１８：離脱待ち」状態に遷移する。これにより、対象車両２０Ａは、一旦状態をリセットして、バブルの生成および統合などの処理をやりなおす。
なお、再調整により自身がリーダーとなった場合は、「Ｖ１５：ネゴシエーション状態（リーダー）」に遷移する。

【0137】

「Ｖ１８：離脱待ち」は、対象車両２０Ａ（非リーダー）が統合バブルのリーダーに離脱要求を送信後（Ｃ１１６）の状態である。離脱要求に対しリーダーから応答（離脱バブルＩＤ通知）が得られた場合、単独バブル（離脱バブル）として走行し、サービス終了の判断後（Ｃ１１８）、「Ｖ１９：終了」状態に遷移する。対象車両２０Ａは、例えばユーザによる終了操作、対象道路Ｒからの退出を検出したとき、または、この状態に遷移してから所定のタイムアウト時間経過後に、サービス終了と判断する。
また、対象車両２０Ａは、リーダーへの離脱要求が未達（応答なし）であった場合も、この状態に遷移してもよい。

【0138】

「Ｖ１９：終了」は、対象車両２０Ａがバブルを用いた追随走行支援サービスを終了した（Ｃ１０４、Ｃ１１８）後の状態である。

【0139】

（支援装置の状態遷移）
図１７は、第１の実施形態に係る支援装置の状態遷移の一例を示す図である。
図１７を参照しながら、支援装置１０が対象車両２０ＡのバブルＢ１を管理する際の管理状態の変化について説明する。

【0140】

「Ｖ２１：バブルＩＤ要求待ち」は、支援装置１０の初期状態であり、対象車両２０Ａからのバブル登録要求（バブルＩＤの発行要求）を待ち受ける状態である。

【0141】

「Ｖ２２：バブルサービス要求待ち」は、対象車両２０Ａからのバブル登録要求に対しバブルＩＤを発行した後（Ｃ２０１）、この対象車両２０ＡのバブルＢ１から追随走行要求（マッチング要求）を待ち受ける状態である。また、支援装置１０は、バブルＢ１の更新情報Ｄ３を受信すると（Ｃ２０２）、この状態を継続して、バブルＢ１の位置および速度の監視などの処理を行う。

【0142】

「Ｖ２３：マッチング候補確定待ち」は、支援装置１０がバブルＢ１からのマッチング要求を受け付けて（Ｃ２０３）、この要求元バブルＢ１のマッチング候補を選定している状態である。支援装置１０は、要求元バブルＢ１から更新情報Ｄ３を受信すると（Ｃ２０４）、この状態を継続してマッチング候補の再選定を行う。
支援装置１０は、要求元バブルＢ１がマッチング要求をキャンセルした場合（Ｃ２０５）、「Ｖ２２：バブルサービス要求待ち」に戻る。
支援装置１０は、要求元バブルＢ１がサービス終了（キャンセル）した場合（Ｃ２０６）、この要求元バブルＢ１について、「Ｖ２６：バブル管理終了」の状態となる。

【0143】

「Ｖ２４：バブル統合完了待ち」は、支援装置１０が要求元バブルＢ１のマッチング候補を選定した後（Ｃ２０７）、要求元バブルＢ１とマッチング候補からの統合完了通知を待ち受ける状態である。支援装置１０は、要求元バブルＢ１から更新情報Ｄ３を受信すると（Ｃ２０８）、この状態を継続して、要求元バブルＢ１の位置および速度の監視や、マッチング候補へ要求元バブルＢ１の更新情報Ｄ３を転送するなどの処理を行う。

【0144】

「Ｖ２５：バブル統合更新待ち」は、要求元バブルＢ１が統合バブルＢ１として存続することを示す統合完了通知を受信した場合（Ｃ２０９）、各対象車両がこの統合バブルＢ１での追随走行を続けていると想定して、統合バブルＢ１からの更新情報Ｄ３を待ち受ける状態である。支援装置１０は、統合バブルＢ１から更新情報Ｄ３を受信すると（Ｃ２１０）、この状態を継続して、統合バブルＢ１の位置および速度の監視などの処理を行う。

【0145】

「Ｖ２６：バブル管理終了」は、バブルＢ１に対する支援サービスが不要となり、このバブルＢ１の管理を終了した状態である。
支援装置１０は、マッチングを希望する要求元バブルＢ１が非統合バブルＢ１として消失することを示す統合完了通知を受信した場合（Ｃ２１１）、または、サービス終了（離脱バブルが対象道路Ｒから退出など）によりバブルが不要となった場合（Ｃ２１２、Ｃ２１３）、この状態に遷移してバブルＢ１の管理を終了する。
また、支援装置１０は、統合バブルＢ１からバブル分離要求（離脱バブルＩＤ要求）を受け付けた場合（Ｃ２１４）、統合バブルＢ１を継続バブルと離脱バブルの２のバブルに分離する。このとき、支援装置１０は、離脱バブルのＩＤ発行のため、「Ｖ２１：バブルＩＤ要求待ち」に遷移し、離脱バブルＩＤ発行後（「Ｖ２２：マッチング要求待ち」遷移後）に離脱バブルからサービス終了の通知を受け付けると（Ｃ２１５）、再び「Ｖ２６：バブル管理終了」に戻って離脱バブルの管理を終了する。

【0146】

（作用、効果）
以上のように、本実施形態に係る支援装置１０は、対象車両２０からバブル登録要求を受け付けた場合に、当該対象車両２０をリーダーとする追随走行の車両群であるバブルを生成し、当該対象車両２０の車両情報Ｄ１と生成したバブルのバブルＩＤ（識別情報）とを関連付けたバブル情報Ｄ２を登録するバブル生成部１１０と、バブルから追随走行要求を受け付けた場合に、所定のマッチング条件を満たすバブルを、追随走行要求の要求元バブルのマッチング候補として選択するマッチング処理部１１１と、要求元バブルおよびマッチング候補それぞれのリーダーにバブル統合を指示する統合指示部１１３と、要求元バブルおよびマッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、統合バブルのバブル情報Ｄ２に被統合バブルのバブル情報Ｄ２を統合して更新する更新処理部１１４と、を備える。

【0147】

このようにすることで、支援装置１０は、追随走行のマッチング候補を探す処理を、対象車両２０同士の車車間通信による相互接続に頼ることなく開始することができるため、車車間通信の通信範囲や他の非対象車両３０の存在などにマッチング候補の検索処理が阻害されることを抑制することができる。また、支援装置１０は、追随走行を行う車両群（複数の対象車両２０）をバブルという単位でまとめて管理し、各バブルのリーダーとバブル統合の指示などの送受信を行うので、対象車両２０それぞれを個別に管理するよりも、管理リソースや通信量を低減することができる。

【0148】

また、マッチング処理部１１１は、要求元バブルの目的地までの走行経路と少なくとも一部が共通する走行経路を有するバブルであって、共通する走行経路の長さが所定距離以上、または、共通する走行経路の走行時間が所定時間以上であるバブルをマッチング候補として選択する。

【0149】

追随走行を行う距離や時間が短いと、追随走行により得られる効果（運転負担軽減、燃費向上などの効果）が小さくなる。しかしながら、本実施形態に係る支援装置１０は、所定距離または所定時間以上、追随走行を継続可能なバブル同士をマッチングさせることにより、追随走行を行う距離または時間が短くなってしまうことを抑制し、追随走行の効果を高めることができる。

【0150】

また、マッチング処理部１１１は、要求元バブルの車両属性と一致する車両属性を有するバブルをマッチング候補として選択する。

【0151】

車両属性（車両のサイズなど）が大きく異なると、例えば空力性能向上による燃費向上のような、追随走行の効果が小さくなる可能性がある。しかしながら、本実施形態に係る支援装置１０は、車両属性が一致するバブル同士をマッチングさせることにより、追随走行により得られる効果が低減することを抑制することができる。

【0152】

また、マッチング処理部１１１は、要求元バブルに含まれる車両の台数との合計台数が上限台数以下となるバブルをマッチング候補として選択する。

【0153】

このようにすることで、支援装置１０は、統合後のバブルが大きくなりすぎて追随走行が困難となったり、周囲の他車（非対象車両３０）の走行に影響を与えることを抑制することができる。

【0154】

また、支援装置１０は、複数のバブルそれぞれの走行位置を含む更新情報Ｄ３を取得する更新情報取得部１１２をさらに備える。マッチング処理部１１１は、更新情報Ｄ３に基づいて、要求元バブルの走行位置から所定の検索距離内に位置するバブルをマッチング候補として選択する。

【0155】

このようにすることで、支援装置１０は、統合するまでに時間がかかるバブルをマッチング候補から除外することができる。これにより、統合後に追随走行を実施する距離または時間が短くなってしまい、追随走行により得られる効果が低減することを抑制することができる。

【0156】

また、統合指示部１１３は、マッチングした２つのバブルについて、後続バブルが先行バブルに追いつくように、先行バブルの減速および後続バブルの加速の少なくとも一方を指示する。

【0157】

このようにすることで、支援装置１０は、マッチングした２つのバブルの速度を調整して、これらバブルをより確実に合流させることができる。また、各バブルの運転者が他のバブルの位置や速度を考慮して加減速を自身で判断する必要がないため、運転に伴う負担を軽減することができる。

【0158】

また、支援装置１０は、バブルから離脱車両を離脱させる分離要求を受け付けた場合に、バブルのバブル情報Ｄ２から離脱車両の車両情報Ｄ１を削除して更新するとともに、離脱車両をリーダーとする離脱バブルを生成し、離脱バブルのバブル情報Ｄ２を登録する分離処理部１１５をさらに備える。

【0159】

このようにすることで、支援装置１０は、バブルの統合と分離を必要に応じて行うことができるので、目的地が異なる対象車両２０同士を組み合わせて１つのバブルとして追随走行させることができる。

【0160】

＜その他の実施形態＞
上述の実施形態において、支援装置１０のマッチング処理部１１１が、追随走行の要求元バブルＢ１の進行方向前方または後方の検索距離（例えば、１ｋｍ）内にマッチング条件を満たすバブルが存在する場合に、このバブルをマッチング候補として選択する態様について説明したこれに限られることはない。他の実施形態では、マッチング処理部１１１は、バブルのマッチングまでの制限時間を設定し、この制限時間内でマッチング可能なバブルをマッチング候補としてもよい。

【0161】

追随走行の要求元バブルＢ１は、リーダー２０Ａのユーザの操作を受け付けて、マッチング候補とのバブル統合をいつまでに完了したいかを示す制限時間を設定する。また、要求元バブルＢ１は、追随走行要求（図４のステップＳ１５）とともに設定した制限時間、および更新情報Ｄ３を支援装置１０に送信する（図４のステップＳ１５）。

【0162】

また、支援装置１０のマッチング処理部１１１は、マッチング候補検索処理（図８のステップＳ２１）において、上述のマッチング条件（１）～（４）を満たし、且つ、制限時間以内に要求元バブルＢ１と合流可能なバブルをマッチング候補として選択する。

【0163】

なお、マッチング処理部１１１は、
ＲＴ：制限時間
ＤＬ：最新の更新情報Ｄ３における要求元バブルＢ１の位置と相手バブルとの距離
ＤＶ：最新の更新情報Ｄ３における要求元バブルＢ１と相手バブルとのバブル速度差
としたとき、「ＤＬ÷ＤＶ＜ＲＴ」を満たすバブルを、要求元バブルＢ１と合流可能であると判断する。

【0164】

例えば、要求元バブルＢ１が設定した制限時間が１０分であり、マッチング条件を満たすバブルＢ２，Ｂ３があるとする。要求元バブルＢ１とバブルＢ２との距離が０．５ｋｍ、速度差が５ｋｍ／ｈの場合、「０．５ｋｍ÷５ｋｍ／ｈ＝６分」である。そうすると、合流するまでにかかる時間が制限時間未満であるため、マッチング処理部１１１は、このバブルＢ２をマッチング候補として選択する。一方、要求元バブルＢ１とバブルＢ３との距離が１ｋｍ、速度差が５ｋｍ／ｈの場合、「１ｋｍ÷５ｋｍ／ｈ＝１２分」である。そうすると、合流するまでにかかる時間が制限時間を超えるため、マッチング処理部１１１は、このバブルＢ３をマッチング候補から除外する。

【0165】

また、マッチング処理部１１１は、マッチング情報を満たし、且つ、制限時間までに合流可能なバブルが複数ある場合、要求元バブルＢ１との距離が最も近いバブルをマッチング候補として選択する。これにより、マッチング処理部１１１は、最短時間で合流可能なバブルをマッチング候補として選択することができる。

【0166】

このようにすることで、支援装置１０は、バブルの統合完了までの時間を短くすることができるので、統合相手のバブルを見つけるまでに対象車両２０が単独で走行する距離や時間を短縮することができる。これにより、統合後に追随走行を実施する距離または時間が短くなってしまい、追随走行により得られる効果が低減することを抑制することができる。

【0167】

以上、図面を参照して一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、様々な設計変更等をすることが可能である。すなわち、他の実施形態においては、上述の処理の順序が適宜変更されてもよい。また、一部の処理が並列に実行されてもよい。

【0168】

＜付記＞
上述の実施形態に記載の支援装置、支援方法、およびプログラムは、例えば以下のように把握される。

【0169】

（１）第１の態様によれば、車両の追随走行を支援する支援装置１０は、車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報Ｄ１と生成したバブルの識別情報とを関連付けたバブル情報Ｄ２を登録するバブル生成部１１０と、バブルに含まれる車両から追随走行要求を受け付けた場合に、複数のバブルのうち所定のマッチング条件を満たすバブルを、追随走行要求の要求元バブルに対するマッチング候補として選択するマッチング処理部１１１と、要求元バブルおよびマッチング候補それぞれのリーダーにバブル統合を指示する統合指示部１１３と、要求元バブルおよびマッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、統合バブルのバブル情報Ｄ２に前記統合バブルに統合される被統合バブルのバブル情報Ｄ２を統合して更新する更新処理部１１４と、を備える。

【0170】

このようにすることで、支援装置１０は、追随走行のマッチング候補を探す処理を、対象車両２０同士の車車間通信による相互接続に頼ることなく開始することができるため、車車間通信の通信範囲や他の非対象車両３０の存在などにマッチング候補の検索処理が阻害されることを抑制することができる。また、支援装置１０は、追随走行を行う車両群（複数の対象車両２０）をバブルという単位でまとめて管理し、各バブルのリーダーとバブル統合の指示などの送受信を行うので、対象車両２０それぞれを個別に管理するよりも、管理リソースや通信量を低減することができる。

【0171】

（２）第２の態様によれば、第１の態様に係る支援装置１０において、車両情報Ｄ１は車両の目的地を含み、マッチング処理部１１１は、要求元バブルの目的地までの走行経路と少なくとも一部が共通する走行経路を有するバブルであって、共通する走行経路の長さが所定距離以上、または、共通する走行経路の走行時間が所定時間以上であるバブルをマッチング候補として選択する。

【0172】

このようにすることで、支援装置１０は、追随走行を行う距離または時間が短くなってしまうことを抑制し、追随走行の効果を高めることができる。

【0173】

（３）第３の態様によれば、第１または第２の態様に係る支援装置１０において、車両情報Ｄ１は車両の車両属性を含み、マッチング処理部１１１は、要求元バブルの車両属性と一致する車両属性を有するバブルをマッチング候補として選択する。

【0174】

このようにすることで、支援装置１０は、車両属性の不一致により追随走行により得られる効果が低減することを抑制することができる。

【0175】

（４）第４の態様によれば、第１から第３の何れか一の態様に係る支援装置１０において、マッチング処理部１１１は、要求元バブルに含まれる車両の台数との合計台数が上限台数以下となるバブルをマッチング候補として選択する。

【0176】

このようにすることで、支援装置１０は、統合後のバブルが大きくなりすぎて追随走行が困難となったり、周囲の他車の走行に影響を与えることを抑制することができる。

【0177】

（５）第５の態様によれば、第１から第４の何れか一の態様に係る支援装置１０は、複数のバブルそれぞれの走行位置を含む更新情報Ｄ３を取得する更新情報取得部１１２をさらに備え、マッチング処理部１１１は、更新情報Ｄ３に基づいて、要求元バブルの走行位置から所定の検索距離内に位置するバブルをマッチング候補として選択する。

【0178】

このようにすることで、支援装置１０は、統合するまでに時間がかかるバブルをマッチング候補から除外することができる。これにより、統合後に追随走行を実施する距離または時間が短くなってしまい、追随走行により得られる効果が低減することを抑制することができる。

【0179】

（６）第６の態様によれば、第１から第４の何れか一の態様に係る支援装置１０は、複数のバブルそれぞれの走行位置およびバブル速度を含む更新情報Ｄ３を取得する更新情報取得部１１２をさらに備え、マッチング処理部１１１は、更新情報Ｄ３に基づいて、要求元バブルが指定した設定時間以内に合流可能なバブルをマッチング候補として選択する。

【0180】

このようにすることで、支援装置１０は、バブルの統合完了までの時間を短くすることができるので、統合相手のバブルを見つけるまでに対象車両２０が単独で走行する距離や時間を短縮することができる。これにより、統合後に追随走行を実施する距離または時間が短くなってしまい、追随走行により得られる効果が低減することを抑制することができる。

【0181】

（７）第７の態様によれば、第１から第６の何れか一の態様に係る支援装置１０において、統合指示部１１３は、要求元バブルおよびマッチング候補のうち後方を走行する後続バブルが前方を走行する先行バブルに追いつくように、先行バブルの減速および後続バブルの加速の少なくとも一方を指示する。

【0182】

このようにすることで、支援装置１０は、マッチングした２つのバブルの速度を調整して、これらバブルをより確実に合流させることができる。また、各バブルの運転者が他のバブルの位置や速度を考慮して加減速を自身で判断する必要がないため、運転に伴う負担を軽減することができる。

【0183】

（８）第８の態様によれば、第１から第７の何れ一の態様に係る支援装置１０は、バブルから離脱車両を離脱させる分離要求を受け付けた場合に、当該バブルのバブル情報Ｄ２から離脱車両の車両情報Ｄ１を削除して更新するとともに、離脱車両をリーダーとする離脱バブルを生成して、離脱車両の車両情報Ｄ１と生成した離脱バブルの識別情報とを関連付けたバブル情報Ｄ２を登録する分離処理部１１５をさらに備える。

【0184】

このようにすることで、支援装置１０は、バブルの統合と分離を必要に応じて行うことができるので、目的地が異なる対象車両２０同士を組み合わせて１つのバブルとして追随走行させることができる。

【0185】

（９）第９の態様によれば、支援方法は、車両の追随走行を支援する支援方法であって、車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報Ｄ１と生成したバブルの識別情報とを関連付けたバブル情報Ｄ２を登録するステップと、バブルに含まれる車両から追随走行要求を受け付けた場合に、複数のバブルのうち所定のマッチング条件を満たすバブルを、追随走行要求の要求元バブルに対するマッチング候補として選択するステップと、要求元バブルおよびマッチング候補それぞれのリーダーにバブル統合を指示するステップと、要求元バブルおよびマッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、統合バブルのバブル情報に前記統合バブルに統合される被統合バブルのバブル情報Ｄ２を統合して更新するステップと、を有する。

【0186】

（１０）第１０の態様によれば、プログラムは、車両からバブル登録要求を受け付けた場合に、当該車両をリーダーとする追随走行の車両群であるバブルを生成し、当該車両の車両情報Ｄ１と生成したバブルの識別情報とを関連付けたバブル情報Ｄ３を登録するステップと、バブルに含まれる車両から追随走行要求を受け付けた場合に、複数のバブルのうち所定のマッチング条件を満たすバブルを、追随走行要求の要求元バブルに対するマッチング候補として選択するステップと、要求元バブルおよびマッチング候補それぞれのリーダーにバブル統合を指示するステップと、要求元バブルおよびマッチング候補の一方を統合バブルとすることを通知する統合完了通知を受け付けた場合に、統合バブルのバブル情報Ｄ２に前記統合バブルに統合される被統合バブルのバブル情報Ｄ２を統合して更新するステップと、を支援装置に実行させる。

【符号の説明】

【0187】

１ 支援システム
１０，１０Ａ，１０Ｂ 支援装置
１１ プロセッサ
１１０ バブル生成部
１１１ マッチング処理部
１１２ 更新情報取得部
１１３ 統合指示部
１１４ 更新処理部
１１５ 分離処理部
１１６ 通知部
１２ メモリ
１３ ストレージ
１４ 通信インタフェース
２０，２０Ａ，２０Ｂ 対象車両
３０ 非対象車両
５０ 路側機器

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】