車群管理方法および隊列走行通信システム
【課題】双方向通信を利用して隊列走行を行う隊列走行システムにおいて、送達確認に必要な通信量を減らして、通信の途絶をできるだけ抑制する。
【解決手段】本発明に係る隊列走行方法では、１台のリーダとその他のメンバからなる車群を形成して、リーダが定期的にＨＢパケットを送信し、メンバがＨＢパケットに応答してＭＲパケットを送信する。これを通信の１サイクルとして定義したときに、ＨＢパケットには前サイクルにおけるメンバからの通信に対するＡＣＫを格納し、ＭＲパケットには現サイクルにおけるリーダからの通信と前サイクルにおけるメンバからの通信に対するＡＣＫを格納する。ＡＣＫをサイクルごとにまとめて送れるので通信量を削減できる。また、各車両は自車が認識する周囲の状態情報を送信し、各車両は通信から得られる状態情報および自車のセンサで得られる情報に基づいて自律的に走行制御を行う。
【解決手段】本発明に係る隊列走行方法では、１台のリーダとその他のメンバからなる車群を形成して、リーダが定期的にＨＢパケットを送信し、メンバがＨＢパケットに応答してＭＲパケットを送信する。これを通信の１サイクルとして定義したときに、ＨＢパケットには前サイクルにおけるメンバからの通信に対するＡＣＫを格納し、ＭＲパケットには現サイクルにおけるリーダからの通信と前サイクルにおけるメンバからの通信に対するＡＣＫを格納する。ＡＣＫをサイクルごとにまとめて送れるので通信量を削減できる。また、各車両は自車が認識する周囲の状態情報を送信し、各車両は通信から得られる状態情報および自車のセンサで得られる情報に基づいて自律的に走行制御を行う。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車群管理方法および隊列走行通信システムに関する。
【背景技術】
【０００２】
近年、先行車両に自動的に追従して走行する隊列走行が研究されている。このような隊列走行により、運転者を運転操作から解放するとともに、車間距離の短縮による輸送効率および燃費の向上を図ることができる。また、このような隊列走行では、車車間通信により走行制御に必要な情報をやりとりして、より効果的な制御を実現する提案がなされている。
【０００３】
通信を利用する隊列走行の第１の態様としては、レーダの代わりにあるいはレーダと併用して、前方車両から送信される情報にしたがって自車両を制御する手法がある。このような仕組みの隊列走行を、本明細書では、通信ＡＣＣ（Ａｄａｐｔｉｖｅ Ｃｒｕｉｓｅ
Ｃｏｎｔｒｏｌ）あるいは追従走行と称する。
【０００４】
さらに進んだ態様として、隊列走行を行う車両間で送達確認を行い、双方向の通信を担保しつつ走行制御を行う隊列走行システムがある。双方向通信が担保されると割り込みたい車両に対して車間を広げるなどの柔軟で高度な制御が可能となり、車間距離の短縮化、燃費の改善、滑らかな追従が実現できる。このような仕組みの隊列走行を、本明細書では、協調走行と称する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−４６８２０号公報
【特許文献２】特開２００６−２６１７４２号公報
【特許文献３】特開２００１−６０９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、協調走行を行っている車両が互いの通信全てに対して個別に受信応答（ＡＣＫ）を送信する分散通信方式の場合、必要な通信の量が隊列走行を行う車両の台数の増加に伴って急激に増加する。Ｎ台の車両で隊列走行をしている場合に、ある１台の車両が送信した情報に対して残りのＮ−１台の車両が受信応答を返すことになるので、Ｎ台の車両がそれぞれ情報を送信するたびに合計でＮ２のオーダーの回数送信が必要となる。
【０００７】
このように通信量が増加すると電波干渉が発生し、隊列走行制御に悪影響を与えるおそれがある。したがって、送達確認に要する通信量をできるだけ減らして、通信の途絶がなるべく発生しないようにすることが望まれる。
【０００８】
また、協調走行を行っている際に通信途絶が発生したら、通信ＡＣＣによる追従走行に切り替えることも考えられる。通信ＡＣＣでは、送達確認が不要であり、また、車間距離も長くなるので電波干渉が抑制されるためである。しかしながら、協調走行から通信ＡＣＣによる追従走行に切り替えて車間距離を広げるのは容易ではない。通信の途絶を完全に抑制することは困難であることを考慮すると、通信途絶が発生した際の悪影響をできるだけ少なくすることも望ましい。
【０００９】
以上のように、本発明は、双方向通信を利用して隊列走行を行う隊列走行システムにお
いて、送達確認に必要な通信量を減らして、通信の途絶をできるだけ抑制することを目的とする。また、本発明はさらに、通信の途絶が発生した場合にもその影響を最小限にすることを目的とする。
【課題を解決するための手段】
【００１０】
通信途絶の抑制を達成するために、本発明に係る車群管理方法は、
双方向通信が可能な複数の車両から、１台の車両をリーダ、その他の車両をメンバとして車群を形成し、車群内の車両同士による通信を利用して隊列走行を行う隊列走行通信システムにおける車群管理方法であって、
リーダが、定期的に情報を送信するステップと、
各メンバが、リーダから送信される情報に対して応答を返すステップと、
を含み、
リーダから送信される情報には、前サイクルにおける各メンバからの通信を受信できたか否かを示す受信応答が含まれ、
各メンバから送信される情報には、現サイクルにおけるリーダからの通信、および、前サイクルにおける他のメンバからの通信を受信できたか否かを示す受信応答が含まれ、
各車両は、他の車両から送信される情報に含まれる受信応答に基づいて、通信の双方向性を確認する
ことを特徴とする。
【００１１】
上記のように、車群内でリーダが定期的に情報送信を行い、それに対してメンバが応答を返すことで、車群内の通信に関して時間的な境界であるサイクルを導入できる。そして、各車両が１サイクル分の受信応答をまとめて送信するとパケットヘッダなどの重複情報を減らせるので、通信の双方向性を確認するために要する通信量を削減できる。通信量を削減できるので通信品質の向上すなわち通信途絶を抑制することが可能となる。
【００１２】
本発明においては、各車両が定期的に送信する情報には、当該車両の位置、車群を構成する車両の識別子、車群を構成する各車両に対する受信応答が含まれ、
各車両は、他の車両から送信される情報と、自車両が備えるセンサによって取得される情報とに基づいて、自律的に走行制御を行うことが好ましい。
ここで、各車両が定期的に送信する情報には、車群を構成する車両の車群内の走行順序が含まれることが好ましい。車群内の走行順序は、送信する情報の中に車群を構成する識別子を走行順序にしたがって列挙することで表現することができる。また、車両の識別子と走行順序（番号等）を関連付けて送信する情報に格納するようにしても良い。また、車群外の直前および直後の車両に関する情報も含まれることが好ましい。また、自車両が備えるセンサとしては、自車両の位置を測定するセンサ、自車両の少なくとも前方の物体の位置を測定するセンサが含まれることが好ましい。
【００１３】
上記のように、各車両が定期的に送信する情報に送信車両が送信時点で把握している車群に関する情報を格納して送信するようにし、他の車両に対して特定の制御を行うように指示する命令を発することなく各車両が自律的に走行制御の判断を行うことで、制御命令を送信する必要がなくなる。さらに制御命令の送達確認に要する通信も不要となる。このように通信量を減らすことができるので、通信品質の向上すなわち通信途絶を抑制することが可能となる。また、他車両から送信される情報を一時的に受信できなかった場合であっても、次に送信される情報を受信したときに走行制御が可能となり、しかも常に最も新しい状態情報に基づいて走行制御が可能となるという利点も得られる。
【００１４】
本発明において、車群を構成する車両の台数に上限が設けられていることが好ましい。
【００１５】
車群内の車両台数を制限することで、車群内での通信量を減らすことができ、通信品質
の向上および通信途絶の抑制が可能となる。
【００１６】
本発明においては、車群の先頭に位置する車両は、車群外の前方の車両に対して追従する走行制御を行い、
車群の先頭車両とその前方の車両との間の車間距離は、車群内での車間距離よりも長い
ことが好ましい。
【００１７】
上記のように車群の先頭車両がその前方車両に追従することで、複数の車群が全体として隊列走行が可能となる。この際、車群の先頭車両とその前方の車間距離を、車群内の車間距離よりも長くすることで、車群の前方での速度等の変化をこの部分で吸収することができ、車群内への影響を低減することができる。すなわち、前方車群で通信途絶等が発生した場合であっても、その悪影響を前方車群内だけにとどめることが可能となり、後方車群に通信途絶による悪影響が極力及ばないようにできる。
【発明の効果】
【００１８】
本発明によれば、より少ない通信量で隊列走行を行う車両間での送達確認が行えるので、電波の干渉が減り通信の途絶が抑制される。
【００１９】
さらに、通信の途絶が発生した場合であっても、その影響を限定的にすることができる。
【図面の簡単な説明】
【００２０】
【図１】本実施形態におけるＡＣＫ制御方式を説明する図である。
【図２】本実施形態における車群協調走行と車群間の走行制御を説明する図である。
【図３】車群内で通信途絶が発生した場合に、通信途絶車両の前後で車群を分離する制御を説明する図である。
【図４】本実施形態におけるデータパケットのフォーマットを説明する図である。
【図５】本実施形態におけるＡＣＫ制御方式を詳細に説明する図である。
【図６】本実施形態における状態情報の情報源を説明する図である。
【図７】本実施形態における車両の機能構成を説明する図である。
【図８】本実施形態における車両の状態遷移を説明する図である。
【図９】通信ＡＣＣにより走行していた２台の車両が合流して１つの車群を形成する処理を説明する図である。
【図１０】車群に対して通信ＡＣＣにより追従走行していた車両を車群が合流する処理を説明する図である。
【図１１】２つの車群が合流して１つの車群を形成する処理を説明する図である。
【図１２】車群内で車両ＩＤが競合した場合の競合解決処理を説明する図である。
【図１３】車群内から通信メンバが離脱したときの制御を説明する図である。
【図１４】車群内から通信リーダ（先頭車両）が離脱したときの制御を説明する図である。
【図１５】車群内の車両が車群協調走行を解除した場合の処理を説明する図である。
【図１６】車群内に通信機能を有しない車両が割り込んだ場合の処理を説明する図である。
【図１７】車群内車両の通信機能停止を検出する方法を説明する図である。
【図１８】車群内で車両の通信機能が停止した場合の処理を説明する図である。
【図１９】車群内の車両が通信可能範囲外へ移動した場合の処理を説明する図である。
【図２０】車群内で電波干渉が発生した場合の処理を説明する図である。
【図２１】パケット受信時に行う全車両共通の処理のフローチャートである。
【図２２】追従走行状態にある車両がパケット受信時および送信タイミング到来時に行う処理のフローチャートである。
【図２３】車群準備状態にある車両がパケット受信時および送信タイミング到来時に行う処理のフローチャートである。
【図２４】通信リーダ状態にある車両が車群パケット受信時に行う処理のフローチャートである。
【図２５】通信リーダ状態にある車両が通信ＡＣＣパケット受信時に行う処理のフローチャートである。
【図２６】通信リーダ状態にある車両が送信タイミング到来時に行う処理のフローチャートである。
【図２７】通信メンバ状態にある車両が車群パケット受信時に行う処理のフローチャートである。
【図２８】通信メンバ状態にある車両が送信タイミング到来時に行う処理のフローチャートである。
【発明を実施するための形態】
【００２１】
本実施形態は、車群を形成し車群内での双方向通信によって隊列走行を制御する隊列走行システムである。本実施形態の隊列走行制御は、協調走行の一種であるが従来技術と区別するために車群協調走行と称する。このような双方向通信を利用する車群協調走行では、より柔軟で高度な隊列走行制御が可能となり車間距離を短縮化できる。車間距離を短縮した隊列走行を行っているときに、通信の途絶が発生した場合には、安全のために隊列走行制御を解除または制御を追従走行に変更して車間距離を開ける必要が生じる。このように、双方向通信を利用して隊列走行を行う場合、通信途絶が発生するとその影響が大きい。
【００２２】
１．本実施形態に係る隊列走行システムの概要説明
本実施形態では、通信を管理するリーダを選出し、通信リーダが通信メンバを選んでグループ（車群）を形成する。それ以降、通信リーダと通信メンバ間の定期的な通信によって車群の維持・管理を行う。また、車群内の制御リーダが他の車両に目標制御値を送信し、各車両が送信された目標制御値に従って走行することで隊列走行が行われる。このように、通信リーダが車群内の通信を管理し、制御リーダが車群内の隊列走行制御を行うことで、車群による隊列走行が実現される。
【００２３】
本実施形態においては、車群内および車群間でこれから述べる通信方式や車群維持・管理手法を採用することで、通信途絶の発生抑制および通信途絶時の影響軽減を実現する。
【００２４】
（Ａ）通信途絶の発生抑制
通信途絶の発生抑制のためには、隊列走行に必要な無線通信を効率的に行って、電波干渉を抑制する必要がある。その対策として以下の手法を採用する。
【００２５】
（Ａ−１）ＡＣＫ制御の改善（車群通信方式）
通信の双方向性を確認するためにＡＣＫ（受信応答。ループバックと呼ばれることもあるが本明細書ではＡＣＫと呼ぶ。）を返す必要がある。各車両が他車両からの通信に対して個別にＡＣＫを返す分散通信方式では、車両数の増加にしたがって必要な通信量が急激に（Ｏ（Ｎ２）のオーダーで）増加する。したがって、車群内の各車両が１回メッセージ（ＡＣＫのみの通信を除く）を送信するたびに車群内でＮ２のオーダー回の通信が必要となり、電波の干渉を招く。
【００２６】
本実施形態においては、図１（Ａ）に示すように、車群内で通信リーダ（図中Ａ）がブロードキャスト通信を行い、それに応答して各メンバ（図中Ｂ，Ｃ）が応答を返す通信方式を採用する。本明細書では、通信リーダからの通信をＨＢ（HeartBeat）、通信メンバ
からの通信をＭＲ（Membership Report）と称する。このような通信方式とすることで、
車群内の通信にサイクルを定義することができる。１サイクルは、通信リーダからのＨＢで始まり、次のＨＢの直前で終了する。通信リーダおよび通信メンバは、１サイクルにおいて１回の送信権が得られる。
【００２７】
図１（Ｂ）を参照してＡＣＫ制御の方式を説明する。図１（Ｂ）において、「カウンタ」は各車両が送信するメッセージを識別するものであり、「ＡＣＫ」はそのメッセージ送信においてどのメッセージに対するＡＣＫを返すかを示す。図に示すように、通信リーダは、前サイクルにおける各メンバからの通信に対するＡＣＫを格納してＨＢパケットを送信する。また、通信メンバは、現サイクルにおける通信リーダからの通信に対するＡＣＫと、前サイクルにおける他のメンバからの通信に対するＡＣＫを格納してＭＲパケットを送信する。具体的には、サイクルｉにおいて、通信リーダはサイクルｉ−１における通信メンバからの通信に対するＡＣＫを格納してＨＢパケットを送信する。また、通信メンバは、サイクルｉにおける通信リーダからのＨＢパケットに対するＡＣＫと、サイクルｉ−１における他のメンバからのＭＲパケットに対するＡＣＫを格納してＭＲパケットを送信する。
【００２８】
このようにサイクルごとのＡＣＫをまとめて伝達することで、通信回数を減らしつつ、互いの通信の双方向性が確認できる。なお、本ＡＣＫ制御方式では、各車両がそれぞれ１回メッセージ送信するときに必要となる双方向性確認のための通信回数は車群の台数と同じ（Ｏ（Ｎ））である。このように車群内での双方向性確認のための通信回数を減らせるので、電波干渉を抑制し通信途絶の発生を抑制することができる。メンバ間通信の双方向性確認には１サイクルの遅延が生じるが、ＡＣＫのための通信回数を減らせ１サイクルごとに新しい情報を送れるので問題は生じない。むしろ、従来のＡＣＫ方式ではＡＣＫ確認にＮサイクルを必要としＮサイクルおきにしか新しい情報が送れないのに対して、本ＡＣＫ方式ではＡＣＫ確認しつつ１サイクルごとに新しい情報を送信できるために、通信の遅延が少なくなるという利点がある。
【００２９】
なお、ＡＣＫを返す対象の通信を車群内車両からの通信に限る必要はなく、車群外の車両からの通信に対してもＡＣＫを返すようにしても良い。本実施形態においては、後述するように、自車両が属する車群のすぐ前方に位置する車両（「車群外先行車」と呼ぶ）と、自車両が属する車群のすぐ後方に位置する車両（「車群外後続車」と呼ぶ）からの通信に対するＡＣＫを含める。
【００３０】
（Ａ−２）状態情報共有による協調（情報伝達方式）
本実施形態では、各車両は自車が把握している状態情報をＨＢパケットやＭＲパケットに含めて送信する。各車両は、周囲車両の通信から得られる状態情報および、自車両のセンサ等から得られる情報に基づいて、周囲の状態情報の変化を把握して、状態情報の更新およびそれに応じた制御を行う。状態情報は、車群の維持・管理に必要または有用な情報や、隊列走行制御に必要または有用な情報である。たとえば、状態情報には、双方向通信可能性、車群に属しているか否か、車群内での走行順、各車両の位置、走行方向、走行速度、加速度など種々の情報が含まれうる。
【００３１】
状態情報を共有し各車両が最新の状態情報に応じて自律的に制御を行う間接命令型の制御方式以外に、他車両からの明示的な制御命令にしたがって制御を行う直接命令型の制御方式を採用することも考えられる。直接命令型の命令伝達方式には、リーダが制御命令を送りメンバがＡＣＫを返す方式や、リーダが複数回（パケット到達率に応じて必要な回数が計算される）制御命令を送りメンバはＡＣＫを返さない方式が考えられる。しかしながら、間接命令型の制御方式には以下のような利点があるため、本実施形態では状態情報共有による制御方式を採用する。
【００３２】
まず、状態情報共有方式では、制御命令やそれに対するＡＣＫを送る必要がなくなるため、通信量を減らすことができる。制御命令＋ＡＣＫ方式では１回の制御情報伝達に２回（往復）の通信が必要であり、制御命令複数回伝送方式では複数回の通信を必要としてしまう。また、複数回伝送方式では何回送出するかを設計することも難しい。状態情報共有方式では状態情報を送る必要があるが、状態情報自体は制御目的以外にも必要な情報であり、余分なデータというわけではない。
【００３３】
また、制御命令を送信する方式で送信に失敗した場合は有効時間内であれば制御命令の再送を行うが、その間に状況の変化が生じることもあり、情報が実際に有効である保証はない。その場合、無駄なブロードキャストの発生や陳腐化した情報による混乱が生じる可能性がある。それに対して、状態情報共有方式では、各車両が常に最新の状態情報を送信するため、無駄なブロードキャストの発生や情報の陳腐化といった問題は生じない。
【００３４】
なお、状態情報共有方式では、他車両から送信される状態情報に単純に従うと制御状態が振動する場合がある。たとえば、ある車両が車群に合流したり離脱したりを繰り返すことが起こりうる。そのため制御状態の変更にヒステリシスを設けこの問題を回避することが望ましい。具体的には、制御状態の振動を引き起こす可能性が高い車両からの通知される状態情報を一定期間（除外期間）無視するようにすればよい。
【００３５】
（Ａ−３）車群通信の優先制御
車群内では通信の双方向性を維持することが隊列走行の制御に重要である。したがって、車群通信（車群に属する車両の通信）を車群に属さない車両の通信に優先させることで、車群通信の通信途絶を抑制することが好ましい。このために本実施形態では、車群通信を受信した車両は通信を抑制する。
【００３６】
抑制方法については、車群通信を傍受した車両が一定時間待機する抑制（Suppression
）方式と、車群通信を傍受した車両が車群通信で指定された時間まで待機する予約（Reservation）方式とがある。すなわち、抑制方式では待機時間を受信側車両（車群外車両）
で判断し、予約方式では待機時間を送信側車両（車群内車両）で判断する。抑制方式では車群通信に対して特殊な制御を設ける必要がないので実装が簡易であり、予約方式では車群通信に追加情報が必要であるものの車群通信を行っている間確実に通信を除外できるという利点がそれぞれある。
【００３７】
また、抑制される通信内容に関して、全ての通信を行わない方法と、車両制御用を除いた通信（エンターテインメント用情報、交通情報等）を行わないことが考えられる。全ての通信を待機すれば車群通信の優先度が上がるが、車群に属さない車両の制御用情報のやりとりができなくなる。したがって、車群通信をどれだけ優先させるかによって、抑制する通信内容を決定すればよい。
【００３８】
なお、本実施形態では、抑制方式で、制御用以外の通信を行わない手法を採用する。
【００３９】
（Ｂ）通信途絶の影響軽減
本実施形態では、通信途絶を抑制するために上記（Ａ）のような種々の手法を採用しているが、それでも通信途絶を完全になくすことは困難である。そこで、通信途絶が発生した場合であっても、その影響が軽減する設計が望まれる。通信途絶による影響としては、隊列走行制御モードの切り替え（車群協調走行から追従走行への切り替え）による車間距離等の変化が挙げられる。
【００４０】
本実施形態では、以下の手法によって通信途絶時の悪影響を軽減する。
【００４１】
（Ｂ−１）車群間での追従走行
本実施形態では、図２に示すように、１つの車群を構成する車両台数に上限を設け、車群間の隊列走行制御方式として追従走行を採用する。車群内では、上述の車群通信によって双方向通信を行いながら隊列走行制御を行う。このような車群協調走行では、柔軟な制御が可能であるため車間距離を比較的短くすることができる。
【００４２】
一方、車群間の隊列走行制御では、後方車両が前方車両に追従する追従走行を採用する。ここでは、後続車群２２の先頭車両２２Ｈが通信ＡＣＣにより前方車群２１の最後尾車両２１Ｔに追従する。先頭車両２２Ｈにおける走行制御は、最後尾車両２１Ｈからの通信および自車に搭載されたレーダによって得られる情報に基づいて行われる。追従走行では、車群協調走行ほどには柔軟な制御ができないため、車間距離はより長くなっている。
【００４３】
このように車群間を追従走行とすることで、ある車群内での通信途絶の影響が後続車群に及ばないようにすることができる。たとえば、前方車群２１において通信途絶が発生し、前方車群内の車両が全て通信ＡＣＣによる追従走行に変更になった場合を考える。前方車群内では、追従走行への移行に伴って車間距離を長くする必要があるため、各車両間の相対位置が変化する。しかしながら、後続車群の先頭車両はもともと追従走行を行っているため、前方車両との相対位置（車間距離）を変化させる必要がない。もちろん前方車両の速度変化（減速）に伴って後続車群も速度を変化させる必要があるが、車両間の相対位置に変化がなければ乗員に対して与える不安は少ないと考えられる。
【００４４】
（Ｂ−２）車群内での通信途絶時に車群分割
車群内で通信の途絶が発生する状況には、２通りの状況が考えられる。１つは、特定の車両との間で通信が行えなくなる場合である。図３（Ａ）に示すように、車群を構成する特定の車両３１との間で通信ができなくなった場合には、図３（Ｂ）に示すように車両３１より前方に位置する車両からなる車群３２と、車両３１より後方に位置する車両からなる車群３３との２つの車群に分割する。そして後方車群３３は、車両３１に対して通信ＡＣＣにより追従走行を行う。このようにすれば、車両間の相対位置の変化を最小限とすることができる。
【００４５】
また、通信の輻輳により車群を構成する車両全体で通信ができにくくなる状況も考えられる。この場合には、通信リーダが車群内の通信メンバの一部を車群から除外する。車群を構成する車両台数を少なくすることで、電波干渉を軽減でき通信を回復できる。除外された車両以外は車群協調走行を維持できるので、通信途絶時の悪影響を抑えることができる。
【００４６】
２．本実施形態に係る隊列走行システムにおける制御要求
本実施形態に係る隊列走行システムでは、以下の通信制御を可能とする。なお、ここでは本隊列走行システムが満たすべき要求を提示するだけにし、これらの要求を如何にして実現するかについては後述する。
【００４７】
（Ａ）隊列への合流
車両間の通信によって隊列へ新たな車両が合流できる必要がある。隊列の合流とは、隊列に属する車両台数が増加することを言い、車群が新たに形成されることを含む。隊列への合流の態様は、さらに［１］〜［３］の３つに分けることができる。
【００４８】
［１］車群の形成：
これは、車群に属していない車両同士が合流して新たに車群を形成するシナリオである。このシナリオのイメージは図９に示されている。なお、図中、点線で囲まれている車両
の集まりは車群を意味する。
【００４９】
［２］車群への参加：
これは、既存の車群に、車群に属していない車両が参加して車群が大きくなるシナリオである。このシナリオのイメージは図１０に示されている。
【００５０】
［３］車群同士の合流：
これは、既存の２つの車群が合流して、１つの大きな車群になるシナリオである。このシナリオのイメージは図１１に示されている。
【００５１】
また、隊列の合流時における問題として車両ＩＤの競合がある。
【００５２】
［４］車両ＩＤの競合解決
車両ＩＤには全ての車両に個別のＩＤを割り当てることが理想的であるが無駄が多いため、たとえば、ある限られた範囲で重複しないようなＩＤを採用することが考えられる。このように車両ＩＤは必ずしも一意ではないので、隊列の合流時に車群内の車両で車両ＩＤが重複（競合）する場合がある。したがって、この車両ＩＤの競合を解決する仕組みも必要である。
【００５３】
（Ｂ）隊列からの離脱
［５］車線変更による離脱
車群内の車両が車線変更などにより隊列から離脱した場合には、残りの車両で車群を維持して隊列走行を続けることができるという要求である（図１３、図１４参照）。
【００５４】
（Ｃ）隊列の分離
車群内に車群通信不可能な車両が発生した場合には、その車両よりも前方部分と後方部分との２つに車群を分離するという要求である。車群内に車群通信不可能な車両が現れるシナリオは以下の２つに分けることができる。
【００５５】
［６］ドライバーによる解除
車群協調走行中に、その車群内の１台がドライバーによって隊列走行を解除することによって、車群内に車群通信できない車両が現れる場合である（図１５参照）。
【００５６】
［７］非通信車両の割り込み
車群内に、通信機能を有していない車両が割り込むことによって、車群内に車群通信できない車両が現れる場合である（図１６参照）。
【００５７】
（Ｄ）通信の途絶
車群内で通信の途絶が発生した場合でも、安全に制御を続けられることが要求される。通信の途絶は、さらに以下の４つの態様に分類できる。
【００５８】
［８］特定車両の通信機能停止
車群内の車両の通信機能が停止した場合に、その車両よりも前方部分と後方部分との２つに車群を分離する。なお、通信機能の停止には、送信機能が停止する場合（図１７（Ａ）参照）と受信機能が停止する場合（図１７（Ｂ）参照）がある。いずれの場合であっても、その車両よりも前方部分と後方部分の２つに車群を分離する（図１８）。
【００５９】
［９］通信可能範囲外への移動
車群内の車両が通信可能範囲外へ移動した場合にも、それ以外の車両で車群を維持することが要求される（図１９参照）。
【００６０】
［１０］電波干渉の発生
電波干渉（輻輳）が発生した場合には、車群内の全ての車両が同時多発的に通信を受信できなくなる。電波干渉が発生した場合には全体の通信量を抑制する必要がある。本実施形態では、車群を構成する車両の台数を減らすことで通信量を抑制する（図２０参照）。
【００６１】
３．本実施形態に係る隊列走行システムの詳細説明
（Ａ）通信リーダ・制御リーダの決定方針
本実施形態に係る隊列走行システムでは、通信リーダが通信可能範囲内から通信メンバを選出して車群を形成する。そのため、どの車両を通信リーダとするかは重要な問題である。通信リーダが車群内のどの位置にあっても上記の要求を満たした機能を実装可能であるが、通信リーダは車群の先頭または中央付近に位置することが好適である。
【００６２】
通信リーダが先頭の場合、車群後方の車両を合流する場合は合流する車両台数が何台であっても通信リーダの変更が生じず安定である。一方、車群前方の車両を合流する場合には必ず通信リーダの変更が生じてしまうため不安定である。
【００６３】
一方、通信リーダが車群中央付近の場合、車群前方および後方のいずれからの合流であっても、合流する台数が少ない場合は通信リーダの変更が生じず安定であるが、合流する台数が多くなると通信リーダの変更が生じて不安定となる。
【００６４】
このように、車群への合流を考慮した場合、通信リーダを先頭車両として、後方からの合流のみを許可すれば（前方からの合流は行わない）常に通信リーダが変わらず安定的であることが分かる。
【００６５】
また、通信の途絶時の影響についても考察する。通信リーダの通信機能が停止した場合、通信リーダが先頭であれば、２台目以降の車両で１つの車群を自律的に形成することができる。これに対して、通信リーダが車群中央付近であれば、少なくとも車群は２つに分かれてしまう（あるいは完全に車群を解消する）。また、電波干渉発生時にも、通信リーダが先頭であれば、車群最後尾の車両を車群から除くことで対応できる。通信リーダが中央付近の場合は、通信リーダを変更しないという条件の下では、車群の先頭と最後尾から均等に車両を除くという複雑な制御が必要となる。
【００６６】
このように、通信途絶時の影響を考慮しても通信リーダが先頭であれば制御が容易あるいは安定的である。
【００６７】
なお、通信リーダは、その通信可能範囲内から通信メンバを選出して車群を形成する。ここで、通信可能範囲は、直接通信可能な範囲（ワンホップで通信可能な範囲）だけではなく、マルチホップ通信により通信可能な範囲内であって良い。ただし、以下では説明の簡略化のためにシングルホップ通信を例に説明するが、マルチホップ通信を利用しても構わない。
【００６８】
以上の検討の結果、本実施形態では、通信リーダが常に車群になるように制御を行う。これにより、前方からの合流が行えなくなるがこのデメリットは小さく、制御が安定的になるという大きなメリットが得られる。もっとも、このことは本発明において通信リーダを先頭車両以外にすることを除外するものではなく、通信リーダは先頭以外であっても構わない。
【００６９】
制御リーダは、車群内の隊列走行を行うための目標制御値を車群内の車両に通知する。ここで、目標制御値は、たとえば、目標とする加速度情報、操舵角情報、ブレーキ操作情
報などが含まれる。このような目標制御値を決定するためには、制御リーダは車群の先頭であることが好ましい。したがって、通信リーダが先頭である場合には、通信リーダが制御リーダを兼ねることが好ましい。一方、通信リーダが中央付近の車両である場合には、車群の先頭車両が制御リーダとなることが好ましい。
【００７０】
（Ｂ）パケットフォーマット
図４（Ａ）（Ｂ）に本実施形態で使用するパケットフォーマットの例を示す。本実施形態においては、車群に属している車両も車群に属していない車両も、または、通信リーダであっても通信メンバであっても、同一のパケットフォーマットを有するパケットを送信する。
【００７１】
送信元車両ＩＤ４０１には、このパケットを生成した車両のＩＤが格納される。本実施形態においては、車両ＩＤは１６ビットで表現されるものとする。
【００７２】
宛先車両ＩＤ４０２には、このパケットを届ける車両ＩＤが格納される。なお、ブロードキャスト通信を行う場合には、宛先車両ＩＤ４０２にはブロードキャストである旨を示す識別子（典型的には「０ｘＦＦＦＦ」）を格納する。
【００７３】
車両状態４０３として、送信元車両の状態に関する種々の情報が格納される。車両状態として典型的には位置情報が含まれる。送信元位置４０４には、緯度情報２８ビット、経度情報２８ビット、高さ情報１４ビットの合計７０ビットで表現される位置情報が格納される。その他の車両状態としては、速さ、進行方向、ブレーキ状態等種々のものを採用できるが、ここではその詳細は省略する。
【００７４】
制御状態４０５には、隊列走行制御の状態として、「車群協調走行」、「通信ＡＣＣ走行」、「ＡＣＣ走行」、「マニュアル走行」のいずれであるかを示す情報が格納される。車群ＩＤ４０６には、自車が属する車群のＩＤが格納される。なお、自車両が車群に属さない場合は「０」を格納するものとする。サイクル４０７には、車群通信におけるＨＢパケットとＭＲパケットの交換を１サイクルとして、このパケットが何サイクル目のものであるかを格納する。種類４０８には、このパケットがＨＢパケットであるかＭＲパケットであるかを格納する。なお、自車両が車群に属していない場合は、サイクルおよび種類は空欄とする（「０」を格納する）。
【００７５】
図４（Ｂ）に走行順車両ＩＤ４０９と走行順送達確認４１０の詳細を示した。走行順車両ＩＤ４０９には、車群内の車両と車群外の前後１台の車両を、その走行順にしたがって格納する。また、走行順送達確認４１０には、これらの各車両からの通信を受信したか否かを示すＡＣＫを格納する。
【００７６】
ここでは１つの車群に属すことができる車両台数の上限はＮ台であり、車群内車両用としてＮ車両分のフィールドが用意されている。車群内の車両台数がＮ台に満たない場合には、余った走行順車両ＩＤフィールドは空欄とする（「０」を格納する）。なお、車両ＩＤは１６ビットを採用しているが、車群内の車両の走行順車両ＩＤ４０９にはその車両ＩＤの下位Ｌビット（たとえば７ビット）を格納する。これは車群内の車両との間では、後述するように車両ＩＤのＬビットが競合した場合に競合解決ができるためである。このように車両ＩＤを短縮化することで通信量を削減している。もちろん走行順車両ＩＤに格納する値は車両ＩＤの下位Ｌビットでなくても良く、実際の車両ＩＤがＫビットであるときに、この車両ＩＤから導かれるＬ（＜Ｋ）ビットの値であればよい。
【００７７】
なお、車群に属しない車両は、車群内車両のＩＤを空欄にしたパケットを生成して送信する。
【００７８】
・ＡＣＫ制御
ここで、上述したフォーマットのパケットを利用して行う、車群内での双方向通信可能性の確認（ＡＣＫ制御）について改めて説明する。図５は、５台の車両Ａ〜Ｅで構成される車群において、あるサイクル（ここではサイクル「２３」）において交換されるメッセージの内容を示す。図５左側は通信リーダから送信されるＨＢパケット、図５右側は通信メンバから送信されるＭＲパケットの内容を示している。図５において示される通信の内容は、図４に示すパケットフォーマットを簡略化して示したものである。まず、通信リーダＡが、サイクル番号「２３」を格納したＨＢパケットを車群内の車両に対してブロードキャスト送信する。ここで、走行順車両ＩＤには、車群を構成する車両のＩＤをその走行順にしたがって格納する。また、各車両に対するＡＣＫには、前回サイクル（＃２２）においてそれぞれの車両からの通信を受信できたか否かに応じた値を格納する。自車両についてのＡＣＫは不定であって良く、本実施形態では常に「１」を格納するものとするが、このフィールドを他の用途に利用しても構わない。
【００７９】
通信メンバ（ここでは車両Ｂ）は、通信リーダからのＨＢパケットを受信すると、それに応答したＭＲパケットを送信する。ここでは、通信メンバＢから通信リーダＡへユニキャスト通信を行う。通信メンバＢは、現在サイクル（＃２３）のＭＲパケットを送信する際に、通信リーダＡのＡＣＫに関しては現在サイクル（＃２３）で通信リーダＡからの通信を受信できたか否かを、通信メンバＣ〜Ｅに関しては前回サイクル（＃２２）で各通信メンバからの通信を受信できたか否かを格納する。なお、通信メンバＢは、前回サイクル（＃２２）において他の通信メンバＣ〜Ｅが送信するＭＲパケットを傍受することで、他の通信メンバＣ〜Ｅからの通信を受信できたか否か判断する。
【００８０】
このように通信リーダが通信サイクルの管理を行い、通信メンバが各サイクルに１回通信リーダからのＨＢパケットに応答してＭＲパケットを送信するという通信方式を採用しているので、車群内の全車両についての１サイクル分のＡＣＫをまとめて送信することが可能である。これにより双方向通信の確認に必要な通信量を削減することができる。
【００８１】
（Ｃ）状態情報の定義
次に、各車両が記憶する、現在の周囲および自車両に関する情報（状態情報）について説明する。状態情報には、大きく分けて、所属する車群に関する情報、自車が属していない車群（外部車群）に関する情報、一定期間通知される情報を無視すべき車両のリスト（除外リスト）、初期設定情報が含まれる。
【００８２】
所属車群情報としては、車群ＩＤ、現在のサイクル番号、車群内車両および車群外の先行車・後続車に関する車両ＩＤ、ＡＣＫ有無、通信から得られる車両情報（位置情報等）がある。また、車群内の車両に関しては、車群内での走行順序も記憶する。
【００８３】
これらの情報は、車群内の車両や車群外の先行車・後続車からの通信や自車両のセンサ等から得られる情報が情報源となる。より詳細な情報源を図６に示す。図中、「自」とあるのは自車で定義された情報、または自車のセンサから得られる情報を意味し、「ＨＢ」とあるのは通信リーダからの情報（ＨＢパケット）であることを意味し、「ＭＲ」とあるのは通信メンバからの情報（ＭＲパケット）であることを意味し、「外」とあるのは車群外からの情報であることを意味し、「−」とあるのは情報を取得しなくても良いことを意味する。車群外の車両についての情報は一部の車群メンバは取得しなくても良いが、もちろん車群外の車両からの通信からこれらの情報を取得して記憶しても良い。
【００８４】
図６に示すように、通信リーダは、車群メンバに関する情報は各メンバ（ＭＲパケット）から取得し、車群外の先行車・後続車からの情報はこれらの車両からの通信から取得す
る。最後尾以外の通信メンバは、通信リーダに関する情報と、車群内での通信メンバの走行順序は通信リーダ（ＨＢパケット）から取得する。通信メンバのＡＣＫ（前サイクルでの自車からの通信が届いたか）や位置情報などの車両情報は、各通信メンバ（ＭＲパケット）から取得する。また、最後尾の通信メンバは、車群外の後続車両との間のＡＣＫおよび車両情報を、当該車両から取得する。
【００８５】
外部車群情報としては、車群ＩＤ、通信リーダの車両ＩＤ、サイクル番号を記憶する。これは、外部車群に属する車両からの通信を傍受することによって得られる。この情報は、周囲にどのような車群が存在するかを把握するために車両内に使用される。
【００８６】
外部車群のうち、自車両が属する車群のすぐ後ろに位置する車群については、その車群を構成する車両のＩＤおよび、これらの車両から受信した通信の最新サイクル番号を記憶する。この情報は、車群同士の合流時に後続車群内の全ての車両との間の双方向通信が確認できた段階で合流を行うために使用される。
【００８７】
除外リストは、状態の振動を防止するために一定期間送信される状態情報を無視する車両または車群のリストである。車群については、車群ＩＤ、通信リーダの車両ＩＤ、除外開始時刻を記憶する。また、車両については、車両ＩＤおよび除外開始時刻を記憶する。
【００８８】
初期設定情報としては、車群内車両台数の上限（車群サイズ）、パケットの送信レート（サイクル時間）、ランダム待機時間、通信タイムアウトと判定するまでの時間、通信途絶と判定するまでのタイムアウト回数、車群対象から除外している期間などが含まれる。
【００８９】
（Ｄ）車両の構成
図７は本実施形態に係る隊列走行システムを構成する車両の機能ブロックを示す図である。各車両は、車両走行制御ＥＣＵ（Electronic Control Unit）７０１、車車間通信装
置７０５、ＧＰＳ装置７０７、ミリ波レーダ７０８、エンジンＥＣＵ７０９、ブレーキＥＣＵ７１０、ステアリングＥＣＵ７１１などを備える。車両走行制御ＥＣＵ７０１は、後述する各種の処理を実行する制御部７０２、状態情報などを記憶する記憶部７０３、時刻を計測するタイマ７０４などを有する。車車間通信装置７０５は、車両間で無線通信を行う通信部７０６を有する。無線通信方式は任意のものであって構わないが、７００ＭＨｚ帯を利用した車車間通信システム（たとえばITC-FORUM RC-006）や、５．８ＧＨｚ帯を利用した車車間通信システム（たとえばITC-FORUM RC-005）などを採用することができるが、これらに限定されるものでもない。ＧＰＳ装置７０７は、自車両の位置情報をＧＰＳ衛星等から取得するための装置である。なお、必ずしもＧＰＳ衛星から直接送信される信号を受信するものでなく、中継装置等からの信号を受信するものであっても良い。ミリ波レーダ７０８は前方車両の位置を計測するためのものである。したがって、ミリ波以外の波長の電波や超音波などを用いた測距センサ、あるいはステレオカメラによる測距センサなどを用いても良い。エンジンＥＣＵ７０９、ブレーキＥＣＵ７１０、ステアリングＥＣＵ７１１は自車の状態を取得するためのものであり、この他にも必要に応じて車内の機器から情報を取得すればよい。
【００９０】
（Ｅ）制御フロー
ここでは、通信リーダを車群の先頭車両として設計した場合に制御要求［１］〜［１０］を満たすための処理を説明する。上述したように、通信リーダを先頭としているので車群の成長は後方からのみとする。
【００９１】
・状態遷移
まず、図８を参照して追従走行、車群協調走行、マニュアル走行の間の状態遷移を定義する。マニュアル走行時に、追従走行機能を有効にしレーダや通信などを使って実際に追
従走行が可能になると追従走行状態に遷移する。なお、実際には通信ＡＣＣによる追従走行とＡＣＣによる追従走行の２つの場合があるが、本発明においては本質的な違いではないのでこれら２つの状態をまとめて追従走行状態としている。追従走行状態において、他の車両と連続していることと双方向通信が可能であることが、それぞれレーダと通信によって判断できると、車群準備状態に遷移する。車群準備状態にある車両は、ランダム待機時間待機した後に通信リーダ状態に遷移してＨＢパケットを送信する。この際、後続車両を車群メンバとして選出する。待機時間中にＨＢパケットを受信して、その中に自車両ＩＤが含まれていれば車群メンバに遷移する。ＨＢパケットを送信する際に後続車両のみをメンバとして選出するので、結局連続する２台の車両のうち前方の車両がリーダになる。
【００９２】
また、追従走行状態中に前方車群からのＨＢパケットに自車両のＩＤが含まれている場合には、前方車群に属する通信メンバへと遷移する。
【００９３】
通信リーダは、前方車群からのＨＢパケットに自車両のＩＤが含まれている場合には、前方車群に属する通信メンバへと遷移する。
【００９４】
通信メンバは、先行車との間で通信が途絶したり、ＨＢパケットにおいて自車が先頭であったりする場合には、通信リーダ状態へと移行し、車群内の自車よりも後方の車両を通信メンバとする。また、ＨＢパケットに自車両のＩＤが含まれなくなったり、自ら車群協調走行モードを解除したりする場合には、追従走行状態へと遷移する。
【００９５】
また、いずれの状態においても、ドライバーによる隊列走行の解除によりマニュアル走行状態へ移行することができる。
【００９６】
・フローチャート
次に、車両走行制御ＥＣＵの制御部が行う処理について、図２１〜図２８のフローチャートを参照して説明する。図２１は、車両の状態にかかわらず他の車両からのパケットを受信したときに行う共通処理を示している。図２１の共通処理は、車群外からのパケットを受信したときに、それらの情報を状態情報として格納する処理、および走行制御に関係ない通信を抑制する処理といえる。
【００９７】
待機状態にあるときに他の車両からのパケットが到着すると（Ｓ２１０２）、所定時間の間走行制御を含まない通信を控える（Ｓ２１０４）。本実施形態では、他の車両から隊列走行に関するパケットを受信した車両側が、あらかじめ定められた時間だけ通信を抑制する。もちろん、走行制御を含む通信については通常通り送信を続ける。
【００９８】
そして、受信パケットが、自車両が属する車群内の車両からの車群パケットであるか判断する（Ｓ２１０６）。受信したパケットが、自車両が属さない車群からの車群パケット（自車両が車群に属しない場合は全ての車群パケットが該当する）であるか、または、車群パケット以外のパケット（通信ＡＣＣパケット）である場合は否定判定される（Ｓ２１０６−ＮＯ）。所属車群からのパケットでない場合には、受信パケットの送信元が後続車両であって、かつ、自車の通信を受信可能であるか（ＡＣＫビットが立っているか）を判断する（Ｓ２１０８）。なお、後続車両とは、自車両のすぐ後ろの車両を意味する。送信元が後続車両であるか否かは、受信パケットに含まれる車群外先行車両が、自車両であるか否かによって判断できる。送信元が後続車両であり、かつ、自車両からの通信を受信できる場合には状態情報に、所属車群情報の車群外後続車両としてこの車両を登録する（Ｓ２１１０）。なお、自車が属する車群以外の車両からのパケットを受信した場合のみＳ２１０８の判定を行うので、自車両が車群に属している場合は自車両が車群の最後尾である場合のみ、この登録が行われる。
【００９９】
また同様に、受信したパケットの送信元が先行車両であって、かつ、自車の通信を受信可能であるかを判断する（Ｓ２１１２）。先行車両とは、自車両のすぐ前に位置する車両のことである。受信パケットの送信元が先行車であるか否かは、自車両の状態（車群の先頭または非車群）および、パケットに含まれる送信元の位置情報と自車のレーダで取得できる前方車両の位置情報が一致するか否かによって判断することができる。すなわち、受信したパケットに含まれる送信元の位置情報と自車のレーダで取得できる前方車両の位置情報が一致する場合は、先行車からのパケットであると判断できる（Ｓ２１１２−ＹＥＳ）。この場合、自車の状態情報に、所属車群情報の車群外先行車両としてこの車両を登録する（Ｓ２１１４）。なお、自車が属する車群以外の車両からのパケットを受信した場合のみＳ２１１２の判定を行うので、自車両が車群に属している場合は自車両が車群の先頭である場合のみ、この登録が行われる。
【０１００】
また、受信したパケット（所属車群以外からパケット）が車群パケットであるか判断する（Ｓ２１１６）。受信パケットが車群パケットである場合（Ｓ２１１６−ＮＯ）には、状態情報として、外部車群情報にこの車群に関する情報を登録する（Ｓ２１１８）。
【０１０１】
受信したパケットが所属車群からの車群パケットでない場合（Ｓ２１０６−ＮＯ）には、上記のＳ２１０８〜Ｓ２１１８の処理を行った上で、ステップＳ２１２０へ進む。一方、受信したパケットが所属車群からの車群パケットである場合（Ｓ２１０６−ＮＯ）には、そのままステップＳ２１２０へ進む。ステップＳ２１２０では、送信元の車両が除外リストに存在する車両または除外リストに存在する車群に属する車両である場合か判断し、除外リストに該当する場合（Ｓ２１２０−ＹＥＳ）はそれ以上の処理をせずに待機状態に戻る。除外リストに該当しない場合には、受信パケットが車群パケットであるか否か判断する（Ｓ２１２２）。車群パケットである場合には車群パケット受信処理へ進み、車群パケットではない場合（通信ＡＣＣパケットである場合）は通信ＡＣＣパケット受信処理へと進む。なお、これ以降の処理は、車両の状態に応じて異なるものとなる。したがって、以下では、車両の状態別に処理フローを説明する。以下のフローチャートでは、パケット受信時だけでなく、送信タイミング到来時の処理も含まれることに注意されたい。
【０１０２】
図２２〜図２８は、各状態（追従走行状態、車群準備状態、通信リーダ、通信メンバ）において、車群パケット受信時、通信ＡＣＣパケット受信時、および送信タイミング到来時に行う処理を示すフローチャートである。上述したように、車群パケットおよび通信パケット受信時には、前処理として図２１に示した共通処理が実行されることに注意されたい。以下では、図２１〜図２８のフローチャートに従うことで、「２．本実施形態に係る隊列走行システムにおける制御要求」で示した［１］〜［１０］の機能が実現できることを説明する。
【０１０３】
［１］車群の形成
図９（Ａ）（Ｂ）に示すように、通信ＡＣＣによる追従走行中の２台の車両が通信の双方向性を確認したことにより、車群を形成する制御シナリオである。
【０１０４】
まず車両Ａ，Ｂのそれぞれは、定期的に車両ＩＤと位置情報を含む通信ＡＣＣパケットをブロードキャスト送信しながら走行をしている。車両Ｂが車両Ａの後方から接近して車両Ａの通信ＡＣＣパケット（Ｓ２１０２、Ｓ２１０６−ＮＯ）を受信したときに、車両Ａのパケットに含まれる位置情報と、自車のミリ波レーダによって得られる前方車両の位置情報とが一致して、車両Ａが車両Ｂの先行車両であることが分かる（Ｓ２１１２−ＹＥＳ）。したがって、車両Ｂは、車両Ａを車群外先行車両として登録する（Ｓ２１１４）。車両Ｂに送信タイミングが到来すると（Ｓ２２１０）、図９（Ａ）に示すように、車群外先行車両が車両Ａであり、車両Ａに対するＡＣＫを有りにした通信ＡＣＣパケットを生成してブロードキャスト送信する（Ｓ２２１２）。
【０１０５】
車両Ｂからの通信ＡＣＣパケット（Ｓ２１０２，Ｓ２１０６−ＮＯ）を受信した車両Ａは、受信したパケットの車群外先行が自車両でありＡＣＫも有る（Ｓ２１０８−ＹＥＳ）ことから、車両Ｂを車群外後続車両として登録する（Ｓ２１１０）。そして、車両Ａに送信タイミングが到来すると（Ｓ２２１０）、図９（Ａ）に示すように、車群外後続車両が車両Ｂであり、車両Ｂに対するＡＣＫを有りにした通信ＡＣＣパケット生成してブロードキャスト送信する（Ｓ２２１２）。
【０１０６】
車両Ａは、車両Ｂから受信する通信ＡＣＣパケットに自車両が車群外先行車両でかつＡＣＫも有りとされていることから、受信した通信ＡＣＣパケットは後続車両からのものであり、かつ、ＡＣＫが有る（Ｓ２２０６−ＹＥＳ）と判断できるため、車群準備状態へと状態遷移する。また、車両Ｂも同様に、車両Ａから受信する通信ＡＣＣパケットに自車両が車群外後続車両であり、かつ、ＡＣＫも有りとされていることから、受信した通信ＡＣＣパケットは先行車両からのものであり、かつ、ＡＣＫが有る（Ｓ２２０８−ＹＥＳ）と判断できるため、車群準備状態へと状態遷移する。このように、車両Ａと車両Ｂは、通信ＡＣＣによる追従走行中に、双方向通信ができること、および、両車両が連続していることを確認したことによって、車群準備状態へと状態遷移する。
【０１０７】
なお、図２２のフローチャートでは双方向の通信可能性および連続性が一度でも確認されたら状態遷移を行うもの（Ｓ２２０６かＳ２２０８のいずれかが成り立てばすぐに状態遷移する）として示しているが、何回か連続してこの条件が成立する場合に状態遷移を行うようにすることも、安定性の面で優れるので好ましい。
【０１０８】
車群準備状態へと移行した車両Ａ，Ｂは、それぞれランダム時間待機した後に送信タイミングを得る（Ｓ２３１２）。車両Ａが先に送信タイミングを得たとすると、車両Ａは通信リーダへ状態遷移するとともに、状態情報の編集を行う（Ｓ２３１４）。ここで、状態情報の編集とは車群を構成する車両を選出することを含んでいる。本実施形態では、通信リーダを車群の先頭とするために、通信リーダよりも後方に位置する車両を車群に含める。車両Ｂは車両Ａの後方であるため、作成される所属車群情報には車両Ａを通信リーダ、車両Ｂを通信メンバとする車群が格納される。また、共通処理によって得ている外部車群情報を参照して、自車両が属する車群における車群ＩＤとサイクルを、他の車群と重複しないように決定する（Ｓ２３１８）。そして、車両Ａは、通信リーダとして図９（Ｂ）に示すＨＢパケットをブロードキャスト送信する（Ｓ２３１８）。車群準備状態にある車両Ｂが、このＨＢパケットを受信し（Ｓ２３０２、Ｓ２３０４−ＨＢ）、このＨＢパケットが先行車両のものからでありかつＡＣＫ確認も有る（Ｓ２３０６−ＹＥＳ）ことから、車両Ａを通信リーダとする車群のメンバになったことが分かる。そこで、車両Ｂは通信メンバへと状態遷移し、状態情報を更新する（Ｓ２３０８）。
【０１０９】
なお、後方に位置する車両Ｂが先に送信タイミングを得た場合には、通信メンバを後方に位置する車両からのみ選択するので、車両Ｂは自車両のみから構成される車群の通信リーダとなる。車両Ｂは通信リーダとしてＨＢパケットを送信するが、車両Ａにとっては車両Ｂは先行車両ではない（Ｓ２３０６−ＮＯ）ことから車群準備状態を継続する。やがて、車両Ａが送信タイミングを得て、上記の説明と同様に、車両Ｂをメンバとした車群を形成することになる。通信リーダとなっていた車両Ｂも、他の車群から送信されるＨＢパケット内に自車両のＩＤを発見することから、車両Ａを通信リーダとする車群の通信メンバに遷移する（Ｓ２４０４−Ｓ２４０６−Ｓ２４０８−Ｓ２４１０）。したがって、車群準備状態にある車両Ａと車両Ｂのいずれが先に送信タイミングを得たとしても、最終的に形成される車群は同じとなる。
【０１１０】
このようにして、通信ＡＣＣによって追従走行を行っていた車両Ａと車両Ｂの間で通信
の双方向性および連続性が確認されると、前方の車両Ａを通信リーダとして２台の車両からなる車群が形成されることになる。車群を形成した車両Ａと車両Ｂは、車両Ａ，Ｂを車群リストに含むＨＢパケットとＭＲパケットを定期的に交換して、通信の双方向性を確認しながら車群協調走行を行うことができる。
【０１１１】
［２］車群への参加
図１０（Ａ）（Ｂ）に示すように、車群に対して通信ＡＣＣで追従している車両が、車群に参加して車群が大きくなるシナリオである。
【０１１２】
まず、図１０（Ａ）に示すように、車両Ａ〜Ｃで構成される車群の後方に、通信ＡＣＣにより追従走行を行う車両Ｄが存在する状況を考える。この状況では、車両Ｄが車群外先行車両として車両Ｃを認識して（Ｓ２１１２−Ｓ２１１４）、通信ＡＣＣパケットを送信する（Ｓ２２１２）。つまり車両Ｄが送信する通信ＡＣＣパケットには車群外先行車両として車両Ｃが格納され、かつ、ＡＣＫ有りが格納される。車両Ｃがこの通信ＡＣＣパケットを受信することで、車両Ｃは車両Ｄが車群外後続車両であることを認識する（Ｓ２１０８−Ｓ２１１０）。車両Ｃは、車群外後続車両に車両Ｄを格納してＭＲパケットを送信する（Ｓ２８０８）。通信リーダＡは、このＭＲパケットを受信することで車群外後続車両が車両Ｄであることを認識する（Ｓ２４０４−Ｓ２４３２−Ｓ２４３４−Ｓ２４３６）。
【０１１３】
このように通信リーダ（車両Ａ）が、車群外後続車両が車両Ｄであると認識している状況で、車両Ｄからの通信ＡＣＣパケットを受信したときの処理を説明する。通信ＡＣＣパケットを受信した通信リーダ（Ｓ２５０２）は、車群外後続車両である車両Ｄと車群最後尾車両である車両Ｃとの間で双方向通信が確立している（Ｓ２５０４−ＹＥＳ）ことから、車群内の車両台数が最大に達していなければ（Ｓ２５０６−ＹＥＳ）、車両Ｄを車群の最後尾に登録する（Ｓ２５０８）。そして、次の送信タイミングで通信リーダは、車両Ｄを車群リストに含めてＨＢパケットを送信する。
【０１１４】
追従走行をしている車両Ｄが、車両ＡからのＨＢパケットを受信すると、まず受信パケットは先行車からのものでありかつＡＣＫが有る（Ｓ２２０８−ＹＥＳ）ので、車群準備状態へ遷移する。そして、車群準備状態においてＨＢパケットを受信したときに（Ｓ２３０４−ＨＢ）、このＨＢパケットが先行車両からのものでありかつＡＣＫの確認も有る（Ｓ２３０６−ＹＥＳ）ので、通信メンバ状態へと遷移する（Ｓ２３０８）。またこのとき自車両が車群に所属したことに応じて、状態情報を更新する。
【０１１５】
このようにして、車群に対して通信ＡＣＣで追従していた車両Ｄが、車群と車両Ｄの間で双方向通信可能性と連続性が確認された場合に、車群に合流することができる。
【０１１６】
［３］車群同士の合流
図１１（Ａ）（Ｂ）に示すように、車群間を通信ＡＣＣで追従走行している２つの車群が合流して１つの大きな車群を形成するシナリオである。
【０１１７】
前方車群１１０１の最後尾車両Ｃと後方車群１１０２の先頭車両Ｄとか連続していることは、上記と同様にして分かる。車両Ｃが送信するＭＲパケットを受信することによって、前方車群１１０１内の各車両は車群外後続車両が車両Ｄであることが認識できる。同様に、車両Ｄが送信するＨＢパケットを受信することによって、後方車群内の各車両は車群外先行車両が車両Ｃであることが認識できる。
【０１１８】
通信リーダＡが後方車群内の通信メンバからＭＲパケットを受信した場合は、Ｓ２４０４−Ｓ２４０６−Ｓ２４２２−Ｓ２４２４と処理が進み、ＭＲパケットに含まれる車群リストを後方車群情報に登録する。また、後方車群の通信リーダからＨＢパケットを受信し
た場合は、Ｓ２４０４−Ｓ２４０６−Ｓ２４０８−Ｓ２４１２−Ｓ２４２２−Ｓ２４２４と処理が進み、結局同様の処理が行われることになる。なおＳ２４１２における判断は、通信リーダＡが同一車群に属していると認識している通信メンバからＨＢパケット（別の車群ＩＤを有する）を受信したか否かの判断なので、このケースでは否定判定される。通信リーダは、後方車群情報として、後方車群をどの車両が構成するかと、後方車群を構成するそれぞれの車両からの通信を受信できるか否かを記憶している。そして、後方車群からのＨＢパケットを受信したときに（Ｓ２４２５−ＹＥＳ）、後方車群に属する全車両から通信を受信可能であり（Ｓ２４２６−ＹＥＳ）、後方車群を全て合流しても最大数に達しない場合（Ｓ２４０８−ＹＥＳ）は、所属車群情報の最後尾に、後方車群を構成する各車両を登録する（Ｓ２４３０）。また、後方車群を除外リストに登録して、一定期間後方車群からの情報による状態情報の変更を行わないようにする。通信リーダは、送信タイミングが到来すると、車群リストに車両Ａ〜Ｆまでを含むＨＢパケットを送信する（Ｓ２６１２）。
【０１１９】
後方車群の通信リーダＤは、車両ＡからのＨＢパケットを受信すると、他の車群のＨＢパケットに自車両のＩＤを発見するので通信メンバへと状態遷移する（Ｓ２４０４−Ｓ２４０６−Ｓ２４０８−Ｓ２４１０）。また、車両ＡからのＨＢパケットを受信した、後方車群の通信メンバＥ，Ｆは、他の車群のＨＢパケットに自車両のＩＤを発見するので、所属車群を変更する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、通信メンバＥ，Ｆは、元の車群を除外リストに登録して、所属車群の変更が完了していない同一車群に属していた車両からの情報による状態変動を起こさないようにする。
【０１２０】
このようにして、通信ＡＣＣにより追従走行していた２つの車群１１０１，１１０２の間で、連続性と通信の双方向性が確認された場合に、これら２つの車群１１０１，１１０２を１つの車群１１０３に合流することができる。
【０１２１】
［４］車両ＩＤの競合解決
通信に使用するパケット内では、車群内の車両に関するＩＤは本来のビット数（例えば１６ビット）よりも短いビット数（例えば７ビット）で表現している（図４（Ｂ）参照）。これは、通信パケットのデータ量を減らすための工夫である。そもそも車両ＩＤに重複がないことは保証していないが、仮に１６ビットの車両ＩＤが重複していない場合でも、下位７ビットのみを使用する場合は衝突が発生する確率が高まる。このような車群内で使用するビット数を短縮化した車両ＩＤが衝突した場合に、車両ＩＤの再設定を行って競合を解決する必要がある。
【０１２２】
図１２（Ａ）に示すように８台の車両で車群が構成されている例を考える。図中「ｈ−ｏ」などとあるのは、全１６ビットの車両ＩＤのうち、上位９ビットが「ｈ」であり、下位７ビットが「ｏ」であることを意味している。この例では、通信リーダと６台目の車両の下位７ビットが「ｇ」で衝突しており、４台目と７台目の車両の下位７ビットが「ｅ」で衝突している。
【０１２３】
本実施形態では、通信リーダは車両ＩＤの再設定は行わず、通信メンバが車両ＩＤの下位７ビットの再設定を行って競合を解決する。すなわち、通信リーダは、車群リスト内の車両ＩＤが重複しているか否かの判断は行わない。一方、通信メンバは、通信リーダから受信するＨＢパケットにおいて自車両のＩＤ（下位７ビット）が２つ以上登録されているか判断する（Ｓ２７２６）。ここで車両ＩＤの競合が発生している場合には、自車両の車両ＩＤの下位７ビットに関して再設定を行う（Ｓ２７３０）。なお、新しい車両ＩＤの下位７ビットは、ＨＢパケットに含まれている「ｇ」「ｈ」「ｗ」「ｅ」「ｍ」「ｏ」以外の値をランダムに選択するものとする。ランダムに設定しているので、再度衝突が発生する可能性もあるが、再設定処理を繰り返すことで最終的には競合が解決できる。
【０１２４】
また、車両ＩＤが競合している通信メンバからのＭＲパケットは、どの通信メンバに関する情報であるか判断できないため、受信したＭＲパケットの送信元の車両ＩＤが競合している場合にはそのＭＲパケットは無視する（Ｓ２７１８）。一方、通信リーダの車両ＩＤが他のメンバと競合している場合であっても、通信リーダからのパケットをパケット種別（ＨＢパケット）から判断できるので、ＨＢパケットについてはそのような処理を行う必要はない。
【０１２５】
このように、車群内で車両ＩＤが衝突したときの競合解決が可能となる。競合解決が担保されると、車群内では短縮化した車両ＩＤを使って通信データ量を減らすことが可能となる。
【０１２６】
なお、短縮化した車両ＩＤを使うことにより通信データ量を減らすことができるが、競合解決のためのオーバヘッドが生じるのは避けられない。通信データ量が問題とならないケースやオーバヘッドが許されない環境では、車群内であっても短縮化した車両ＩＤを用いないことが好ましいと言える。
【０１２７】
［５］車線変更による離脱
車群を構成する車両が路線変更などにより隊列から離脱した場合に、残りの車両で車群を維持して隊列走行を行うというシナリオである。
【０１２８】
まず、図１３（Ａ）（Ｂ）を参照して通信メンバが路線変更により離脱する場合を説明する。ここでは５台の車両Ａ〜Ｅで構成される車群から、車両Ｃが路線変更した場合を考える。このとき、通信により通知される車群リストには車群を構成する車両とその走行順序が格納されているので、車群内の各車両は車群の状況が把握できる。各車両は、通信リーダＡから送信されるＨＢパケットによって、車両Ａ，Ｂ，Ｃ，Ｄ，Ｅの順からなる５台の車両から車群が構成されていることが分かる。また、それぞれの車両の位置情報も車群パケットに格納されている。
【０１２９】
一方、各車両はレーダによって前方車両の位置が分かる。車両Ｃが路線変更した場合、車両Ｄは前方の車両が（Ｘｂ，Ｙｂ）に位置することがレーダから検出できる。ここで、車群パケットから得られる位置情報を参照すると、（Ｘｂ，Ｙｂ）に位置する車両は車両Ｂであることが分かる。すなわち、車両Ｄは車両Ｂのすぐ後ろに位置していることが分かり、したがってその間に位置していた車両Ｃが路線変更等により離脱したことが分かる。そこで、車両Ｄは所属車群情報から離脱した車両Ｃを除いて、車両Ａ，Ｂ，Ｄ，Ｅがこの順序で並んで車群を構成していると更新する。この処理は、Ｓ２７２０またはＳ２７２８で行われる処理である。車両Ｄに送信タイミングが到来すると、車両Ｄは自車が保持している状態情報、すなわち、車群は車両Ａ，Ｂ，Ｄ，Ｅから構成されるという車群リストをＭＲパケットに格納して送信する。
【０１３０】
通信リーダＡは、車両ＤからのこのＭＲパケットを受信すると、車群から車両Ｃが離脱したことを認識し、状態情報を更新する（Ｓ２４０４−Ｓ２４３２−Ｓ２４３４−Ｓ２４３６）。通信リーダＡに送信タイミングが到来すると、通信リーダは自車が保持している状態情報、すなわち車群は車両Ａ，Ｂ，Ｄ，Ｅから構成されるという車群リストをＨＢパケットに格納して送信する（Ｓ２６１２）。
【０１３１】
通信リーダＡからのＨＢパケットを受信した車群メンバは、車群から車両Ｃが離脱したことを車群リストから認識できる。
【０１３２】
このように、車群中の車両が路線変更等により離脱した場合であっても、残りの車両に
よって車群を維持することができる（Ｓ２７２８）。
【０１３３】
次に、図１４（Ａ）（Ｂ）を参照して通信リーダが路線変更等により離脱する場合を説明する。このとき、車群において通信リーダの直後を走行していた通信メンバである車両Ｂは、レーダによって車群内の先行車両を特定することができなくなる。車両Ｂに送信タイミングが到来したときに先行車が特定不能であれば、車両Ｂは通信リーダへと状態遷移する（Ｓ２８０２−Ｓ２８０４−Ｓ２８１０）。そして、自車両を通信リーダとして、元の車群に含まれる車両のうち、自車両よりも後方に位置する全ての車両を通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャスト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｂ〜Ｅが格納されている。
【０１３４】
車両Ｂから送信されるＨＢパケットを受信した車両Ｃ〜Ｅでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、所属車群情報を受信したＨＢパケットにしたがって編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１３５】
このように、通信リーダが路線変更等により車群から離脱した場合であっても、２番目を走行していた通信メンバが新しい通信リーダとなって、車群を維持することができる。
【０１３６】
［６］ドライバーによる解除
車群協調走行中に、その車群内の１台がドライバーによって車群隊列走行を解除し、マニュアル走行または通信ＡＣＣ走行に移行したときに、残りの車両で車群を維持して隊列走行を行うというシナリオである。
【０１３７】
図１５に示すように、７台の車両Ａ〜Ｇが車群を形成しているときに車両Ｄがドライバーの操作によって車群協調走行を解除した場合を考える。車両Ｄは、通信機能により車群協調走行を解除したことを周囲の車両に通知する。このとき車両Ｄが送信する通信情報は、制御情報に自車の隊列走行モード（「マニュアル」または「通信ＡＣＣ」）を格納し、走行順リストには、車群外前方車両に車両Ｃを、車群外後方車両に車両Ｅを格納して送信する。
【０１３８】
車群の通信リーダが、ドライバー操作による協調走行解除を通知するパケットを受信した場合（Ｓ２６０９−ＹＥＳ）は、この車両から車群外後続車両までを所属車群情報から削除するとともに、除外リストに登録する（Ｓ２６１１）。これにより、車両Ｄおよびこれより後方に位置する車両が車群から除外され、車両Ａが通信リーダである車群には車両Ａ〜Ｃのみが含まれるようになる。そして通信リーダは、ＨＢパケットの車群リストに車両Ａ，Ｂ，Ｃのみを格納して送信することで、他の車両に対して車群を構成するメンバが変更したことを通知する。
【０１３９】
一方、通信メンバが、ドライバー操作による協調走行解除を通知するパケットを受信した場合は、解除を行った車両が先行車であるか判断する（Ｓ２８０７）。自車両の前方に位置する車両が協調走行を解除した場合には、自車両が通信リーダへ遷移する（Ｓ２８１０）。この場合は、車両Ｅが通信リーダへと遷移する。そして、自車両よりも後方の車両Ｆ，Ｇを通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャス
ト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｅ，Ｆ，Ｇが格納されている。
【０１４０】
車両Ｅから送信されるＨＢパケットを受信した車両Ｆ，Ｇでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、受信したＨＢパケットにしたがって所属車群情報を編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１４１】
このように、車群内のいずれかの車両でドライバーが車群協調走行を解除した場合であっても、その位置で車群を分離して前方車群および後方車群を生成して車群協調走行が行える。
【０１４２】
［７］非通信車両の割り込み
車群内に、通信機能を有していない車両が割り込んだときに、この非通信車両の前後で車群を分離するシナリオである。
【０１４３】
図１６に示すように、６台の車両Ａ〜Ｆで構成される車群が形成されているときに、車両Ｄの前方に通信機能を有していない車両Ｘが割り込んだ場合を考える。このとき、通信により通知される車群リストには、車群を構成する車両とのその走行順序が格納されているので、車群内の状況が把握できる。ここでは、車群が車両Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆの順からなる６台の車両で構成されていることが分かる。また、それぞれの車両の位置情報も車群パケットに格納されている。
【０１４４】
一方、各車両はレーダによって前方車両の位置が分かる。車両Ｄの前方に非通信車両Ｘが割り込んだ場合は、レーダによって得られる前方車両の位置と、車群通信によって得られる前方車両（車両Ｃ）の位置（Ｘｃ，Ｙｃ）とが矛盾することになる。すなわち、車両Ｄは、先行車両を特定することができなくなる。
【０１４５】
通信メンバである車両Ｄに送信タイミングが到来したときに、車両Ｄは先行車両が特定できないので、通信リーダへと状態遷移する（Ｓ２８０４−Ｓ２８１０）。そして、自車両を通信リーダとして、元の車群に含まれる車両のうち、自車両よりも後方に位置する全ての車両を通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャスト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｄ，Ｅ，Ｆが格納されている。
【０１４６】
車両Ｄから送信されるＨＢパケットを受信した車両Ｅ，Ｆでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、所属車群情報を受信したＨＢパケットにしたがって編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１４７】
また、車両Ｄから送信されるＨＢパケットを受信した車両Ａ（元の車群の通信リーダ）は、受信パケットが他の車群からのＨＢパケットであり（Ｓ２４０４−ＮＯ，Ｓ２４０６−ＹＥＳ）、自車の所属車群情報に通信メンバとして登録されている車両が送信元である（Ｓ２４１２ーＹＥＳ）ことが分かる。受信したＨＢパケットの送信元の車両Ｃは、元の
車群の３番目以降なので（Ｓ２４１６−ＮＯ）、車両Ｃおよびそれより後ろの車両Ｅ，Ｆを車群から削除して、車両Ａ，Ｂ，Ｃのみを車群リストに含むように所属車群情報を更新する（Ｓ２４２０）。なお、分離した後続車群の通信リーダの走行位置が２番目であった場合（Ｓ２４１６−ＹＥＳ）は、通信リーダＡは１台だけの車群となるので、車群準備状態へと遷移する（Ｓ２４１８）。なお、いずれの場合も、分離した車群との間で状態の振動を起こさないように、新たな車群を除外リストに追加している（Ｓ２４１４）。
【０１４８】
通信リーダＡから車両Ａ〜Ｃを車群リストに含むＨＢパケットを受信した車両Ｂ，Ｃは、所属車群を構成する車両に変化があったことを認識して、所属車群情報を更新する。
【０１４９】
このように、車群内に通信機能を有しない車両が割り込んだ場合であっても、その位置で車群を分離して前方車群および後方車群を生成して車群協調走行が行える。
【０１５０】
［８］特定車両の通信機能停止
車群内の特定車両の通信機能が停止したときに、この車両の前後で車群を分離するシナリオである。通信機能の停止には、送信機能の停止と、受信機能の停止がある。まず、それぞれの場合について、どのようにして機能停止を他の車両が検知するかについて説明する。
【０１５１】
図１７（Ａ）は、車両Ａ〜Ｇで構成される車群内の車両Ｄの送信機能が停止した場合を説明する図である。車群内の車両は、自車両は車両Ｄからの通信を受信しないことがわかる。そこで、ＨＢパケットまたはＭＲパケットに車両ＤについてＡＣＫ無しを格納して送信する。また、他の車両からのパケットにも車両ＤについてＡＣＫ無しが格納されていることから、車群内の各車両は自車両だけでなく車群内の全車両が車両Ｄからの通信を受信できないことが分かる。このように、車群内の車両のうち所定割合以上の車両（全車両でも良い）が、車両ＤについてＡＣＫ無しの車群パケットを送信した場合は、この車両Ｄの通信機能が停止したと判断できる。なお、この判断は１サイクルだけで判断するのではなく、車両ＤからのＡＣＫ無しが所定サイクル以上続いた場合に、車両Ｃの送信機能が停止したと判断することが好ましい。
【０１５２】
図１７（Ｂ）は、車両Ａ〜Ｇで構成される車群内の車両Ｄの受信機能が停止したが送信機能は有効な場合を説明する図である。車両Ｄは受信機能が停止していることから他の車両からの通信を受信できず、ＭＲパケット（またはＨＢパケット）に他の車両についてＡＣＫ無しを格納して送信する。車両Ｄ以外の車両は、車群内の各車両からの通信を受信できるので、各車両についてＡＣＫ有りを格納してＭＲパケットまたはＨＢパケットを送信する。このように車両Ｄから車群内の車両のうち所定割合以上の車両（全車両でも良い）についてＡＣＫ無しの車群パケットを受信し、他の車両からはＡＣＫ有りの車群パケットを受信している場合には、車両Ｄの受信機能が停止したことが判断できる。なお、この判断も、１サイクルだけで判断するのではなく、車両Ｄが各車両について所定サイクル以上続けてＡＣＫ無しの車群パケットを送信する場合に、車両Ｄの受信機能が停止したと判断することが好ましい。
【０１５３】
図１８は先行車両の通信機能が停止したときの制御を説明する図である。車両Ｄの通信機能（送信機能・受信機能いずれでも）が停止した場合、車両Ｅは送信タイミング到来時に先行車両の通信機能が停止している（Ｓ２８０６−ＹＥＳ）ことから、通信リーダへと遷移し（Ｓ２８１０）、自車両よりも後方の車両Ｆ，Ｇを通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャスト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｅ，Ｆ，Ｇが格納されている。
【０１５４】
車両Ｅから送信されるＨＢパケットを受信した車両Ｆ，Ｇでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、受信したＨＢパケットにしたがって所属車群情報を編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１５５】
また、車両Ｅから送信されるＨＢパケットを受信した車両Ａ（元の車群の通信リーダ）は、受信パケットが他の車群からのＨＢパケットであり（Ｓ２４０４−ＮＯ，Ｓ２４０６−ＹＥＳ）、自車の所属車群情報に通信メンバとして登録されている車両が送信元である（Ｓ２４１２ーＹＥＳ）ことが分かる。受信したＨＢパケットの送信元の車両Ｅは、元の車群の３番目以降なので（Ｓ２４１６−ＮＯ）、車両Ｅ、それより後ろの車両Ｆ，Ｇ、および通信機能の停止した車両Ｄを車群から削除して、車両Ａ，Ｂ，Ｃのみを車群リストに含むように所属車群情報を更新する（Ｓ２４２０）。なお、いずれの場合も、分離した車群との間で状態の振動を起こさないように、新たな車群を除外リストに追加している（Ｓ２４１４）。
【０１５６】
通信リーダＡから車両Ａ〜Ｃを車群リストに含むＨＢパケットを受信した車両Ｂ，Ｃは、所属車群を構成する車両に変化があったことを認識して、所属車群情報を更新する。
【０１５７】
ここで車両Ｅは、受信機能が停止したことにより周囲の車両からの通信が受信できなくなる。したがって、車両Ｅでも自らの受信機能が停止したことを推定できる。そこで、車両Ｅは他の車両からのパケットを受信しなくても、車群メンバ状態から追従走行状態へと遷移することが好ましい。通信メンバは、自らの受信機能が停止した場合（Ｓ２８０８−ＹＥＳ）には、車群準備状態へと遷移し（Ｓ２８２０）、状態情報を編集する。また、元の車群を除外リストに追加する（Ｓ２８２２）。これにより、受信機能が途絶えた車両は、自らメンバを解除できる。
【０１５８】
このように、車群内のいずれかの車両で通信機能が停止した場合であっても、その位置で車群を分離して前方車群および後方車群を生成して車群協調走行が行える。
【０１５９】
［９］通信可能範囲外への移動
車群内の車両が通信可能範囲外へ移動した場合に、通信可能な車両同士で車群を維持するシナリオである。図１９（Ａ）（Ｂ）は、車両Ａ〜Ｅの５台の車両で車群を形成している際に、車両Ａ，Ｂ間の車間距離が開いて車両Ａ，Ｂ間での通信ができなくなった場合を示す図である。車両Ｂは、先行車両からの通信を受信できなくなるので、先行車を特定することができなくなる（Ｓ２８０４−ＹＥＳ）。したがって、図１４（Ｂ）に示すように車両Ｂは通信リーダへ遷移して、車群内で自車よりも後方に位置する車両を通信メンバとした新しい車群を形成する。これ以降の処理は上記［７］で説明した処理と同じであるため、詳細は省略する。
【０１６０】
なお、図１９（Ａ）（Ｂ）では通信リーダ（先頭車両）と２番目の車両との間で車間距離が開いた場合を説明したが、車群内の任意の車両間で車間距離が開いた場合も、先行車両を特定できなくなった車両が通信リーダに遷移することに代わりはない。
【０１６１】
［１０］電波干渉の発生
電波干渉が発生した場合に、車群協調走行を行う車両台数を減らして通信量を抑制することで、通信品質を回復する制御である。
【０１６２】
図２０（Ａ）（Ｂ）は、車両Ａ〜Ｇの７台の車両で構成される車群内で電波の干渉が発生した場合を説明する図である。電波干渉が発生すると車群内の多くの車両で電波を受信できなくなる。したがって、通信リーダは、車群リストにＡＣＫ無しを多く含むＭＲパケットを同時に受信することになる。このように、通信リーダは、車群内の通信メンバが全体的に他車両からの通信をできなくなった場合に、電波干渉による受信障害が発生したと判断する。
【０１６３】
通信リーダが同時多発的な受信途絶を検知したときは、所属車群情報から最後尾車両を削除する（Ｓ２６０６−Ｓ２６１０）。この例では、車群最後尾の車両Ｇを通信メンバから除外して、車群外後続車両として登録する。そして、通信リーダは、新しい車群リストを含むＨＢパケットを生成してブロードキャスト通信する（Ｓ２６１２）。
【０１６４】
このＨＢパケットを受信した車両Ｇは、自車が属していた車群からのＨＢパケットであるにもかかわらず、自車両のＩＤがＨＢパケットに含まれないことから、自車両が車群から除外されたことを検知して車群準備状態へ遷移する（Ｓ２７０４−Ｓ２７１４−Ｓ２７２４−Ｓ２７３２）。
【０１６５】
なお、通信メンバである車両Ｂ〜Ｆは、車両ＡからのＨＢパケットを受信することで、車両Ｇが車群から除外されたことを認識できるので、状態情報を更新する。
【０１６６】
このようにして、車両Ｇと車両Ａ〜Ｆは別の車群となるので、車両Ｆ，Ｇ間は通信ＡＣＣによる追従走行となり車間距離が開くので、電波干渉が軽減されることになる。なお、車両Ｇを車群から除外しても電波干渉が改善されない場合には、さらに次の最後尾車両を除外していくことで、最終的に電波干渉が軽減される。
【０１６７】
以上のように本実施形態によれば、車群内での通信量を削減することで、通信品質の向上すなわち通信途絶の抑制が可能となる。また、通信途絶が発生した場合であっても、重大な影響が及ぶ範囲を車群内に限定可能である。また、通信途絶が発生した場合に車群を分離することで、通信途絶が発生した車群内についても重大な影響がおよび範囲を限定可能である。
【０１６８】
なお、上記では例示的に実施形態を参照して本発明の説明を行ったが、本発明は上記で記した実施形態に限定して解釈するべきではない。たとえば、実施形態では通信リーダが車群の先頭である場合を例に説明しているが、通信リーダを先頭以外としても良い。また、通信リーダが先頭であっても先頭以外であっても、車群の前方に位置する車両を車群に合流するようにしても構わない。前方の車両を合流する場合も後方の車両を合流する場合と同様の処理により対処可能である。また、車群内で通信リーダが変更する場合も、新しい通信リーダがＨＢパケットにより自車両が通信リーダになったことを通知すればよい。
【０１６９】
また、上記の実施形態では、通信リーダと制御リーダが同一の車両である場合を例に説明しているが、必ずしも通信リーダと制御リーダとを同一の車両とする必要はない。たとえば、通信リーダを中央付近の車両（先頭車両以外の車両）とし、制御リーダを先頭車両とする形態が考えられる。通信リーダが上記の説明と同様の方法により車群の維持・管理を行い、制御リーダが車群の隊列走行を制御する。この場合、制御リーダが目標制御値を含む走行制御情報をブロードキャスト送信し、これを受信した通信リーダが車群メンバに走行制御情報を再度ブロードキャスト送信することで、車群内の各車両に走行制御情報を伝達する。このように、通信リーダと制御リーダとを別々の車両とした場合、メンバー離脱などの解散の影響が少なくなりロバスト性が向上する。また、通信リーダによる走行制御情報の転送により車群の範囲が広がるという利点もある。
【符号の説明】
【０１７０】
７０１ 車両走行制御ＥＣＵ
７０２ 制御部
７０３ 記憶部
７０４ タイマ
７０５ 車車間通信装置
７０６ 通信部
７０７ ＧＰＳ装置
７０８ ミリ波レーダ
７０９ エンジンＥＣＵ
７１０ ブレーキＥＣＵ
７１１ ステアリングＥＣＵ
【技術分野】
【０００１】
本発明は、車群管理方法および隊列走行通信システムに関する。
【背景技術】
【０００２】
近年、先行車両に自動的に追従して走行する隊列走行が研究されている。このような隊列走行により、運転者を運転操作から解放するとともに、車間距離の短縮による輸送効率および燃費の向上を図ることができる。また、このような隊列走行では、車車間通信により走行制御に必要な情報をやりとりして、より効果的な制御を実現する提案がなされている。
【０００３】
通信を利用する隊列走行の第１の態様としては、レーダの代わりにあるいはレーダと併用して、前方車両から送信される情報にしたがって自車両を制御する手法がある。このような仕組みの隊列走行を、本明細書では、通信ＡＣＣ（Ａｄａｐｔｉｖｅ Ｃｒｕｉｓｅ
Ｃｏｎｔｒｏｌ）あるいは追従走行と称する。
【０００４】
さらに進んだ態様として、隊列走行を行う車両間で送達確認を行い、双方向の通信を担保しつつ走行制御を行う隊列走行システムがある。双方向通信が担保されると割り込みたい車両に対して車間を広げるなどの柔軟で高度な制御が可能となり、車間距離の短縮化、燃費の改善、滑らかな追従が実現できる。このような仕組みの隊列走行を、本明細書では、協調走行と称する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−４６８２０号公報
【特許文献２】特開２００６−２６１７４２号公報
【特許文献３】特開２００１−６０９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、協調走行を行っている車両が互いの通信全てに対して個別に受信応答（ＡＣＫ）を送信する分散通信方式の場合、必要な通信の量が隊列走行を行う車両の台数の増加に伴って急激に増加する。Ｎ台の車両で隊列走行をしている場合に、ある１台の車両が送信した情報に対して残りのＮ−１台の車両が受信応答を返すことになるので、Ｎ台の車両がそれぞれ情報を送信するたびに合計でＮ２のオーダーの回数送信が必要となる。
【０００７】
このように通信量が増加すると電波干渉が発生し、隊列走行制御に悪影響を与えるおそれがある。したがって、送達確認に要する通信量をできるだけ減らして、通信の途絶がなるべく発生しないようにすることが望まれる。
【０００８】
また、協調走行を行っている際に通信途絶が発生したら、通信ＡＣＣによる追従走行に切り替えることも考えられる。通信ＡＣＣでは、送達確認が不要であり、また、車間距離も長くなるので電波干渉が抑制されるためである。しかしながら、協調走行から通信ＡＣＣによる追従走行に切り替えて車間距離を広げるのは容易ではない。通信の途絶を完全に抑制することは困難であることを考慮すると、通信途絶が発生した際の悪影響をできるだけ少なくすることも望ましい。
【０００９】
以上のように、本発明は、双方向通信を利用して隊列走行を行う隊列走行システムにお
いて、送達確認に必要な通信量を減らして、通信の途絶をできるだけ抑制することを目的とする。また、本発明はさらに、通信の途絶が発生した場合にもその影響を最小限にすることを目的とする。
【課題を解決するための手段】
【００１０】
通信途絶の抑制を達成するために、本発明に係る車群管理方法は、
双方向通信が可能な複数の車両から、１台の車両をリーダ、その他の車両をメンバとして車群を形成し、車群内の車両同士による通信を利用して隊列走行を行う隊列走行通信システムにおける車群管理方法であって、
リーダが、定期的に情報を送信するステップと、
各メンバが、リーダから送信される情報に対して応答を返すステップと、
を含み、
リーダから送信される情報には、前サイクルにおける各メンバからの通信を受信できたか否かを示す受信応答が含まれ、
各メンバから送信される情報には、現サイクルにおけるリーダからの通信、および、前サイクルにおける他のメンバからの通信を受信できたか否かを示す受信応答が含まれ、
各車両は、他の車両から送信される情報に含まれる受信応答に基づいて、通信の双方向性を確認する
ことを特徴とする。
【００１１】
上記のように、車群内でリーダが定期的に情報送信を行い、それに対してメンバが応答を返すことで、車群内の通信に関して時間的な境界であるサイクルを導入できる。そして、各車両が１サイクル分の受信応答をまとめて送信するとパケットヘッダなどの重複情報を減らせるので、通信の双方向性を確認するために要する通信量を削減できる。通信量を削減できるので通信品質の向上すなわち通信途絶を抑制することが可能となる。
【００１２】
本発明においては、各車両が定期的に送信する情報には、当該車両の位置、車群を構成する車両の識別子、車群を構成する各車両に対する受信応答が含まれ、
各車両は、他の車両から送信される情報と、自車両が備えるセンサによって取得される情報とに基づいて、自律的に走行制御を行うことが好ましい。
ここで、各車両が定期的に送信する情報には、車群を構成する車両の車群内の走行順序が含まれることが好ましい。車群内の走行順序は、送信する情報の中に車群を構成する識別子を走行順序にしたがって列挙することで表現することができる。また、車両の識別子と走行順序（番号等）を関連付けて送信する情報に格納するようにしても良い。また、車群外の直前および直後の車両に関する情報も含まれることが好ましい。また、自車両が備えるセンサとしては、自車両の位置を測定するセンサ、自車両の少なくとも前方の物体の位置を測定するセンサが含まれることが好ましい。
【００１３】
上記のように、各車両が定期的に送信する情報に送信車両が送信時点で把握している車群に関する情報を格納して送信するようにし、他の車両に対して特定の制御を行うように指示する命令を発することなく各車両が自律的に走行制御の判断を行うことで、制御命令を送信する必要がなくなる。さらに制御命令の送達確認に要する通信も不要となる。このように通信量を減らすことができるので、通信品質の向上すなわち通信途絶を抑制することが可能となる。また、他車両から送信される情報を一時的に受信できなかった場合であっても、次に送信される情報を受信したときに走行制御が可能となり、しかも常に最も新しい状態情報に基づいて走行制御が可能となるという利点も得られる。
【００１４】
本発明において、車群を構成する車両の台数に上限が設けられていることが好ましい。
【００１５】
車群内の車両台数を制限することで、車群内での通信量を減らすことができ、通信品質
の向上および通信途絶の抑制が可能となる。
【００１６】
本発明においては、車群の先頭に位置する車両は、車群外の前方の車両に対して追従する走行制御を行い、
車群の先頭車両とその前方の車両との間の車間距離は、車群内での車間距離よりも長い
ことが好ましい。
【００１７】
上記のように車群の先頭車両がその前方車両に追従することで、複数の車群が全体として隊列走行が可能となる。この際、車群の先頭車両とその前方の車間距離を、車群内の車間距離よりも長くすることで、車群の前方での速度等の変化をこの部分で吸収することができ、車群内への影響を低減することができる。すなわち、前方車群で通信途絶等が発生した場合であっても、その悪影響を前方車群内だけにとどめることが可能となり、後方車群に通信途絶による悪影響が極力及ばないようにできる。
【発明の効果】
【００１８】
本発明によれば、より少ない通信量で隊列走行を行う車両間での送達確認が行えるので、電波の干渉が減り通信の途絶が抑制される。
【００１９】
さらに、通信の途絶が発生した場合であっても、その影響を限定的にすることができる。
【図面の簡単な説明】
【００２０】
【図１】本実施形態におけるＡＣＫ制御方式を説明する図である。
【図２】本実施形態における車群協調走行と車群間の走行制御を説明する図である。
【図３】車群内で通信途絶が発生した場合に、通信途絶車両の前後で車群を分離する制御を説明する図である。
【図４】本実施形態におけるデータパケットのフォーマットを説明する図である。
【図５】本実施形態におけるＡＣＫ制御方式を詳細に説明する図である。
【図６】本実施形態における状態情報の情報源を説明する図である。
【図７】本実施形態における車両の機能構成を説明する図である。
【図８】本実施形態における車両の状態遷移を説明する図である。
【図９】通信ＡＣＣにより走行していた２台の車両が合流して１つの車群を形成する処理を説明する図である。
【図１０】車群に対して通信ＡＣＣにより追従走行していた車両を車群が合流する処理を説明する図である。
【図１１】２つの車群が合流して１つの車群を形成する処理を説明する図である。
【図１２】車群内で車両ＩＤが競合した場合の競合解決処理を説明する図である。
【図１３】車群内から通信メンバが離脱したときの制御を説明する図である。
【図１４】車群内から通信リーダ（先頭車両）が離脱したときの制御を説明する図である。
【図１５】車群内の車両が車群協調走行を解除した場合の処理を説明する図である。
【図１６】車群内に通信機能を有しない車両が割り込んだ場合の処理を説明する図である。
【図１７】車群内車両の通信機能停止を検出する方法を説明する図である。
【図１８】車群内で車両の通信機能が停止した場合の処理を説明する図である。
【図１９】車群内の車両が通信可能範囲外へ移動した場合の処理を説明する図である。
【図２０】車群内で電波干渉が発生した場合の処理を説明する図である。
【図２１】パケット受信時に行う全車両共通の処理のフローチャートである。
【図２２】追従走行状態にある車両がパケット受信時および送信タイミング到来時に行う処理のフローチャートである。
【図２３】車群準備状態にある車両がパケット受信時および送信タイミング到来時に行う処理のフローチャートである。
【図２４】通信リーダ状態にある車両が車群パケット受信時に行う処理のフローチャートである。
【図２５】通信リーダ状態にある車両が通信ＡＣＣパケット受信時に行う処理のフローチャートである。
【図２６】通信リーダ状態にある車両が送信タイミング到来時に行う処理のフローチャートである。
【図２７】通信メンバ状態にある車両が車群パケット受信時に行う処理のフローチャートである。
【図２８】通信メンバ状態にある車両が送信タイミング到来時に行う処理のフローチャートである。
【発明を実施するための形態】
【００２１】
本実施形態は、車群を形成し車群内での双方向通信によって隊列走行を制御する隊列走行システムである。本実施形態の隊列走行制御は、協調走行の一種であるが従来技術と区別するために車群協調走行と称する。このような双方向通信を利用する車群協調走行では、より柔軟で高度な隊列走行制御が可能となり車間距離を短縮化できる。車間距離を短縮した隊列走行を行っているときに、通信の途絶が発生した場合には、安全のために隊列走行制御を解除または制御を追従走行に変更して車間距離を開ける必要が生じる。このように、双方向通信を利用して隊列走行を行う場合、通信途絶が発生するとその影響が大きい。
【００２２】
１．本実施形態に係る隊列走行システムの概要説明
本実施形態では、通信を管理するリーダを選出し、通信リーダが通信メンバを選んでグループ（車群）を形成する。それ以降、通信リーダと通信メンバ間の定期的な通信によって車群の維持・管理を行う。また、車群内の制御リーダが他の車両に目標制御値を送信し、各車両が送信された目標制御値に従って走行することで隊列走行が行われる。このように、通信リーダが車群内の通信を管理し、制御リーダが車群内の隊列走行制御を行うことで、車群による隊列走行が実現される。
【００２３】
本実施形態においては、車群内および車群間でこれから述べる通信方式や車群維持・管理手法を採用することで、通信途絶の発生抑制および通信途絶時の影響軽減を実現する。
【００２４】
（Ａ）通信途絶の発生抑制
通信途絶の発生抑制のためには、隊列走行に必要な無線通信を効率的に行って、電波干渉を抑制する必要がある。その対策として以下の手法を採用する。
【００２５】
（Ａ−１）ＡＣＫ制御の改善（車群通信方式）
通信の双方向性を確認するためにＡＣＫ（受信応答。ループバックと呼ばれることもあるが本明細書ではＡＣＫと呼ぶ。）を返す必要がある。各車両が他車両からの通信に対して個別にＡＣＫを返す分散通信方式では、車両数の増加にしたがって必要な通信量が急激に（Ｏ（Ｎ２）のオーダーで）増加する。したがって、車群内の各車両が１回メッセージ（ＡＣＫのみの通信を除く）を送信するたびに車群内でＮ２のオーダー回の通信が必要となり、電波の干渉を招く。
【００２６】
本実施形態においては、図１（Ａ）に示すように、車群内で通信リーダ（図中Ａ）がブロードキャスト通信を行い、それに応答して各メンバ（図中Ｂ，Ｃ）が応答を返す通信方式を採用する。本明細書では、通信リーダからの通信をＨＢ（HeartBeat）、通信メンバ
からの通信をＭＲ（Membership Report）と称する。このような通信方式とすることで、
車群内の通信にサイクルを定義することができる。１サイクルは、通信リーダからのＨＢで始まり、次のＨＢの直前で終了する。通信リーダおよび通信メンバは、１サイクルにおいて１回の送信権が得られる。
【００２７】
図１（Ｂ）を参照してＡＣＫ制御の方式を説明する。図１（Ｂ）において、「カウンタ」は各車両が送信するメッセージを識別するものであり、「ＡＣＫ」はそのメッセージ送信においてどのメッセージに対するＡＣＫを返すかを示す。図に示すように、通信リーダは、前サイクルにおける各メンバからの通信に対するＡＣＫを格納してＨＢパケットを送信する。また、通信メンバは、現サイクルにおける通信リーダからの通信に対するＡＣＫと、前サイクルにおける他のメンバからの通信に対するＡＣＫを格納してＭＲパケットを送信する。具体的には、サイクルｉにおいて、通信リーダはサイクルｉ−１における通信メンバからの通信に対するＡＣＫを格納してＨＢパケットを送信する。また、通信メンバは、サイクルｉにおける通信リーダからのＨＢパケットに対するＡＣＫと、サイクルｉ−１における他のメンバからのＭＲパケットに対するＡＣＫを格納してＭＲパケットを送信する。
【００２８】
このようにサイクルごとのＡＣＫをまとめて伝達することで、通信回数を減らしつつ、互いの通信の双方向性が確認できる。なお、本ＡＣＫ制御方式では、各車両がそれぞれ１回メッセージ送信するときに必要となる双方向性確認のための通信回数は車群の台数と同じ（Ｏ（Ｎ））である。このように車群内での双方向性確認のための通信回数を減らせるので、電波干渉を抑制し通信途絶の発生を抑制することができる。メンバ間通信の双方向性確認には１サイクルの遅延が生じるが、ＡＣＫのための通信回数を減らせ１サイクルごとに新しい情報を送れるので問題は生じない。むしろ、従来のＡＣＫ方式ではＡＣＫ確認にＮサイクルを必要としＮサイクルおきにしか新しい情報が送れないのに対して、本ＡＣＫ方式ではＡＣＫ確認しつつ１サイクルごとに新しい情報を送信できるために、通信の遅延が少なくなるという利点がある。
【００２９】
なお、ＡＣＫを返す対象の通信を車群内車両からの通信に限る必要はなく、車群外の車両からの通信に対してもＡＣＫを返すようにしても良い。本実施形態においては、後述するように、自車両が属する車群のすぐ前方に位置する車両（「車群外先行車」と呼ぶ）と、自車両が属する車群のすぐ後方に位置する車両（「車群外後続車」と呼ぶ）からの通信に対するＡＣＫを含める。
【００３０】
（Ａ−２）状態情報共有による協調（情報伝達方式）
本実施形態では、各車両は自車が把握している状態情報をＨＢパケットやＭＲパケットに含めて送信する。各車両は、周囲車両の通信から得られる状態情報および、自車両のセンサ等から得られる情報に基づいて、周囲の状態情報の変化を把握して、状態情報の更新およびそれに応じた制御を行う。状態情報は、車群の維持・管理に必要または有用な情報や、隊列走行制御に必要または有用な情報である。たとえば、状態情報には、双方向通信可能性、車群に属しているか否か、車群内での走行順、各車両の位置、走行方向、走行速度、加速度など種々の情報が含まれうる。
【００３１】
状態情報を共有し各車両が最新の状態情報に応じて自律的に制御を行う間接命令型の制御方式以外に、他車両からの明示的な制御命令にしたがって制御を行う直接命令型の制御方式を採用することも考えられる。直接命令型の命令伝達方式には、リーダが制御命令を送りメンバがＡＣＫを返す方式や、リーダが複数回（パケット到達率に応じて必要な回数が計算される）制御命令を送りメンバはＡＣＫを返さない方式が考えられる。しかしながら、間接命令型の制御方式には以下のような利点があるため、本実施形態では状態情報共有による制御方式を採用する。
【００３２】
まず、状態情報共有方式では、制御命令やそれに対するＡＣＫを送る必要がなくなるため、通信量を減らすことができる。制御命令＋ＡＣＫ方式では１回の制御情報伝達に２回（往復）の通信が必要であり、制御命令複数回伝送方式では複数回の通信を必要としてしまう。また、複数回伝送方式では何回送出するかを設計することも難しい。状態情報共有方式では状態情報を送る必要があるが、状態情報自体は制御目的以外にも必要な情報であり、余分なデータというわけではない。
【００３３】
また、制御命令を送信する方式で送信に失敗した場合は有効時間内であれば制御命令の再送を行うが、その間に状況の変化が生じることもあり、情報が実際に有効である保証はない。その場合、無駄なブロードキャストの発生や陳腐化した情報による混乱が生じる可能性がある。それに対して、状態情報共有方式では、各車両が常に最新の状態情報を送信するため、無駄なブロードキャストの発生や情報の陳腐化といった問題は生じない。
【００３４】
なお、状態情報共有方式では、他車両から送信される状態情報に単純に従うと制御状態が振動する場合がある。たとえば、ある車両が車群に合流したり離脱したりを繰り返すことが起こりうる。そのため制御状態の変更にヒステリシスを設けこの問題を回避することが望ましい。具体的には、制御状態の振動を引き起こす可能性が高い車両からの通知される状態情報を一定期間（除外期間）無視するようにすればよい。
【００３５】
（Ａ−３）車群通信の優先制御
車群内では通信の双方向性を維持することが隊列走行の制御に重要である。したがって、車群通信（車群に属する車両の通信）を車群に属さない車両の通信に優先させることで、車群通信の通信途絶を抑制することが好ましい。このために本実施形態では、車群通信を受信した車両は通信を抑制する。
【００３６】
抑制方法については、車群通信を傍受した車両が一定時間待機する抑制（Suppression
）方式と、車群通信を傍受した車両が車群通信で指定された時間まで待機する予約（Reservation）方式とがある。すなわち、抑制方式では待機時間を受信側車両（車群外車両）
で判断し、予約方式では待機時間を送信側車両（車群内車両）で判断する。抑制方式では車群通信に対して特殊な制御を設ける必要がないので実装が簡易であり、予約方式では車群通信に追加情報が必要であるものの車群通信を行っている間確実に通信を除外できるという利点がそれぞれある。
【００３７】
また、抑制される通信内容に関して、全ての通信を行わない方法と、車両制御用を除いた通信（エンターテインメント用情報、交通情報等）を行わないことが考えられる。全ての通信を待機すれば車群通信の優先度が上がるが、車群に属さない車両の制御用情報のやりとりができなくなる。したがって、車群通信をどれだけ優先させるかによって、抑制する通信内容を決定すればよい。
【００３８】
なお、本実施形態では、抑制方式で、制御用以外の通信を行わない手法を採用する。
【００３９】
（Ｂ）通信途絶の影響軽減
本実施形態では、通信途絶を抑制するために上記（Ａ）のような種々の手法を採用しているが、それでも通信途絶を完全になくすことは困難である。そこで、通信途絶が発生した場合であっても、その影響が軽減する設計が望まれる。通信途絶による影響としては、隊列走行制御モードの切り替え（車群協調走行から追従走行への切り替え）による車間距離等の変化が挙げられる。
【００４０】
本実施形態では、以下の手法によって通信途絶時の悪影響を軽減する。
【００４１】
（Ｂ−１）車群間での追従走行
本実施形態では、図２に示すように、１つの車群を構成する車両台数に上限を設け、車群間の隊列走行制御方式として追従走行を採用する。車群内では、上述の車群通信によって双方向通信を行いながら隊列走行制御を行う。このような車群協調走行では、柔軟な制御が可能であるため車間距離を比較的短くすることができる。
【００４２】
一方、車群間の隊列走行制御では、後方車両が前方車両に追従する追従走行を採用する。ここでは、後続車群２２の先頭車両２２Ｈが通信ＡＣＣにより前方車群２１の最後尾車両２１Ｔに追従する。先頭車両２２Ｈにおける走行制御は、最後尾車両２１Ｈからの通信および自車に搭載されたレーダによって得られる情報に基づいて行われる。追従走行では、車群協調走行ほどには柔軟な制御ができないため、車間距離はより長くなっている。
【００４３】
このように車群間を追従走行とすることで、ある車群内での通信途絶の影響が後続車群に及ばないようにすることができる。たとえば、前方車群２１において通信途絶が発生し、前方車群内の車両が全て通信ＡＣＣによる追従走行に変更になった場合を考える。前方車群内では、追従走行への移行に伴って車間距離を長くする必要があるため、各車両間の相対位置が変化する。しかしながら、後続車群の先頭車両はもともと追従走行を行っているため、前方車両との相対位置（車間距離）を変化させる必要がない。もちろん前方車両の速度変化（減速）に伴って後続車群も速度を変化させる必要があるが、車両間の相対位置に変化がなければ乗員に対して与える不安は少ないと考えられる。
【００４４】
（Ｂ−２）車群内での通信途絶時に車群分割
車群内で通信の途絶が発生する状況には、２通りの状況が考えられる。１つは、特定の車両との間で通信が行えなくなる場合である。図３（Ａ）に示すように、車群を構成する特定の車両３１との間で通信ができなくなった場合には、図３（Ｂ）に示すように車両３１より前方に位置する車両からなる車群３２と、車両３１より後方に位置する車両からなる車群３３との２つの車群に分割する。そして後方車群３３は、車両３１に対して通信ＡＣＣにより追従走行を行う。このようにすれば、車両間の相対位置の変化を最小限とすることができる。
【００４５】
また、通信の輻輳により車群を構成する車両全体で通信ができにくくなる状況も考えられる。この場合には、通信リーダが車群内の通信メンバの一部を車群から除外する。車群を構成する車両台数を少なくすることで、電波干渉を軽減でき通信を回復できる。除外された車両以外は車群協調走行を維持できるので、通信途絶時の悪影響を抑えることができる。
【００４６】
２．本実施形態に係る隊列走行システムにおける制御要求
本実施形態に係る隊列走行システムでは、以下の通信制御を可能とする。なお、ここでは本隊列走行システムが満たすべき要求を提示するだけにし、これらの要求を如何にして実現するかについては後述する。
【００４７】
（Ａ）隊列への合流
車両間の通信によって隊列へ新たな車両が合流できる必要がある。隊列の合流とは、隊列に属する車両台数が増加することを言い、車群が新たに形成されることを含む。隊列への合流の態様は、さらに［１］〜［３］の３つに分けることができる。
【００４８】
［１］車群の形成：
これは、車群に属していない車両同士が合流して新たに車群を形成するシナリオである。このシナリオのイメージは図９に示されている。なお、図中、点線で囲まれている車両
の集まりは車群を意味する。
【００４９】
［２］車群への参加：
これは、既存の車群に、車群に属していない車両が参加して車群が大きくなるシナリオである。このシナリオのイメージは図１０に示されている。
【００５０】
［３］車群同士の合流：
これは、既存の２つの車群が合流して、１つの大きな車群になるシナリオである。このシナリオのイメージは図１１に示されている。
【００５１】
また、隊列の合流時における問題として車両ＩＤの競合がある。
【００５２】
［４］車両ＩＤの競合解決
車両ＩＤには全ての車両に個別のＩＤを割り当てることが理想的であるが無駄が多いため、たとえば、ある限られた範囲で重複しないようなＩＤを採用することが考えられる。このように車両ＩＤは必ずしも一意ではないので、隊列の合流時に車群内の車両で車両ＩＤが重複（競合）する場合がある。したがって、この車両ＩＤの競合を解決する仕組みも必要である。
【００５３】
（Ｂ）隊列からの離脱
［５］車線変更による離脱
車群内の車両が車線変更などにより隊列から離脱した場合には、残りの車両で車群を維持して隊列走行を続けることができるという要求である（図１３、図１４参照）。
【００５４】
（Ｃ）隊列の分離
車群内に車群通信不可能な車両が発生した場合には、その車両よりも前方部分と後方部分との２つに車群を分離するという要求である。車群内に車群通信不可能な車両が現れるシナリオは以下の２つに分けることができる。
【００５５】
［６］ドライバーによる解除
車群協調走行中に、その車群内の１台がドライバーによって隊列走行を解除することによって、車群内に車群通信できない車両が現れる場合である（図１５参照）。
【００５６】
［７］非通信車両の割り込み
車群内に、通信機能を有していない車両が割り込むことによって、車群内に車群通信できない車両が現れる場合である（図１６参照）。
【００５７】
（Ｄ）通信の途絶
車群内で通信の途絶が発生した場合でも、安全に制御を続けられることが要求される。通信の途絶は、さらに以下の４つの態様に分類できる。
【００５８】
［８］特定車両の通信機能停止
車群内の車両の通信機能が停止した場合に、その車両よりも前方部分と後方部分との２つに車群を分離する。なお、通信機能の停止には、送信機能が停止する場合（図１７（Ａ）参照）と受信機能が停止する場合（図１７（Ｂ）参照）がある。いずれの場合であっても、その車両よりも前方部分と後方部分の２つに車群を分離する（図１８）。
【００５９】
［９］通信可能範囲外への移動
車群内の車両が通信可能範囲外へ移動した場合にも、それ以外の車両で車群を維持することが要求される（図１９参照）。
【００６０】
［１０］電波干渉の発生
電波干渉（輻輳）が発生した場合には、車群内の全ての車両が同時多発的に通信を受信できなくなる。電波干渉が発生した場合には全体の通信量を抑制する必要がある。本実施形態では、車群を構成する車両の台数を減らすことで通信量を抑制する（図２０参照）。
【００６１】
３．本実施形態に係る隊列走行システムの詳細説明
（Ａ）通信リーダ・制御リーダの決定方針
本実施形態に係る隊列走行システムでは、通信リーダが通信可能範囲内から通信メンバを選出して車群を形成する。そのため、どの車両を通信リーダとするかは重要な問題である。通信リーダが車群内のどの位置にあっても上記の要求を満たした機能を実装可能であるが、通信リーダは車群の先頭または中央付近に位置することが好適である。
【００６２】
通信リーダが先頭の場合、車群後方の車両を合流する場合は合流する車両台数が何台であっても通信リーダの変更が生じず安定である。一方、車群前方の車両を合流する場合には必ず通信リーダの変更が生じてしまうため不安定である。
【００６３】
一方、通信リーダが車群中央付近の場合、車群前方および後方のいずれからの合流であっても、合流する台数が少ない場合は通信リーダの変更が生じず安定であるが、合流する台数が多くなると通信リーダの変更が生じて不安定となる。
【００６４】
このように、車群への合流を考慮した場合、通信リーダを先頭車両として、後方からの合流のみを許可すれば（前方からの合流は行わない）常に通信リーダが変わらず安定的であることが分かる。
【００６５】
また、通信の途絶時の影響についても考察する。通信リーダの通信機能が停止した場合、通信リーダが先頭であれば、２台目以降の車両で１つの車群を自律的に形成することができる。これに対して、通信リーダが車群中央付近であれば、少なくとも車群は２つに分かれてしまう（あるいは完全に車群を解消する）。また、電波干渉発生時にも、通信リーダが先頭であれば、車群最後尾の車両を車群から除くことで対応できる。通信リーダが中央付近の場合は、通信リーダを変更しないという条件の下では、車群の先頭と最後尾から均等に車両を除くという複雑な制御が必要となる。
【００６６】
このように、通信途絶時の影響を考慮しても通信リーダが先頭であれば制御が容易あるいは安定的である。
【００６７】
なお、通信リーダは、その通信可能範囲内から通信メンバを選出して車群を形成する。ここで、通信可能範囲は、直接通信可能な範囲（ワンホップで通信可能な範囲）だけではなく、マルチホップ通信により通信可能な範囲内であって良い。ただし、以下では説明の簡略化のためにシングルホップ通信を例に説明するが、マルチホップ通信を利用しても構わない。
【００６８】
以上の検討の結果、本実施形態では、通信リーダが常に車群になるように制御を行う。これにより、前方からの合流が行えなくなるがこのデメリットは小さく、制御が安定的になるという大きなメリットが得られる。もっとも、このことは本発明において通信リーダを先頭車両以外にすることを除外するものではなく、通信リーダは先頭以外であっても構わない。
【００６９】
制御リーダは、車群内の隊列走行を行うための目標制御値を車群内の車両に通知する。ここで、目標制御値は、たとえば、目標とする加速度情報、操舵角情報、ブレーキ操作情
報などが含まれる。このような目標制御値を決定するためには、制御リーダは車群の先頭であることが好ましい。したがって、通信リーダが先頭である場合には、通信リーダが制御リーダを兼ねることが好ましい。一方、通信リーダが中央付近の車両である場合には、車群の先頭車両が制御リーダとなることが好ましい。
【００７０】
（Ｂ）パケットフォーマット
図４（Ａ）（Ｂ）に本実施形態で使用するパケットフォーマットの例を示す。本実施形態においては、車群に属している車両も車群に属していない車両も、または、通信リーダであっても通信メンバであっても、同一のパケットフォーマットを有するパケットを送信する。
【００７１】
送信元車両ＩＤ４０１には、このパケットを生成した車両のＩＤが格納される。本実施形態においては、車両ＩＤは１６ビットで表現されるものとする。
【００７２】
宛先車両ＩＤ４０２には、このパケットを届ける車両ＩＤが格納される。なお、ブロードキャスト通信を行う場合には、宛先車両ＩＤ４０２にはブロードキャストである旨を示す識別子（典型的には「０ｘＦＦＦＦ」）を格納する。
【００７３】
車両状態４０３として、送信元車両の状態に関する種々の情報が格納される。車両状態として典型的には位置情報が含まれる。送信元位置４０４には、緯度情報２８ビット、経度情報２８ビット、高さ情報１４ビットの合計７０ビットで表現される位置情報が格納される。その他の車両状態としては、速さ、進行方向、ブレーキ状態等種々のものを採用できるが、ここではその詳細は省略する。
【００７４】
制御状態４０５には、隊列走行制御の状態として、「車群協調走行」、「通信ＡＣＣ走行」、「ＡＣＣ走行」、「マニュアル走行」のいずれであるかを示す情報が格納される。車群ＩＤ４０６には、自車が属する車群のＩＤが格納される。なお、自車両が車群に属さない場合は「０」を格納するものとする。サイクル４０７には、車群通信におけるＨＢパケットとＭＲパケットの交換を１サイクルとして、このパケットが何サイクル目のものであるかを格納する。種類４０８には、このパケットがＨＢパケットであるかＭＲパケットであるかを格納する。なお、自車両が車群に属していない場合は、サイクルおよび種類は空欄とする（「０」を格納する）。
【００７５】
図４（Ｂ）に走行順車両ＩＤ４０９と走行順送達確認４１０の詳細を示した。走行順車両ＩＤ４０９には、車群内の車両と車群外の前後１台の車両を、その走行順にしたがって格納する。また、走行順送達確認４１０には、これらの各車両からの通信を受信したか否かを示すＡＣＫを格納する。
【００７６】
ここでは１つの車群に属すことができる車両台数の上限はＮ台であり、車群内車両用としてＮ車両分のフィールドが用意されている。車群内の車両台数がＮ台に満たない場合には、余った走行順車両ＩＤフィールドは空欄とする（「０」を格納する）。なお、車両ＩＤは１６ビットを採用しているが、車群内の車両の走行順車両ＩＤ４０９にはその車両ＩＤの下位Ｌビット（たとえば７ビット）を格納する。これは車群内の車両との間では、後述するように車両ＩＤのＬビットが競合した場合に競合解決ができるためである。このように車両ＩＤを短縮化することで通信量を削減している。もちろん走行順車両ＩＤに格納する値は車両ＩＤの下位Ｌビットでなくても良く、実際の車両ＩＤがＫビットであるときに、この車両ＩＤから導かれるＬ（＜Ｋ）ビットの値であればよい。
【００７７】
なお、車群に属しない車両は、車群内車両のＩＤを空欄にしたパケットを生成して送信する。
【００７８】
・ＡＣＫ制御
ここで、上述したフォーマットのパケットを利用して行う、車群内での双方向通信可能性の確認（ＡＣＫ制御）について改めて説明する。図５は、５台の車両Ａ〜Ｅで構成される車群において、あるサイクル（ここではサイクル「２３」）において交換されるメッセージの内容を示す。図５左側は通信リーダから送信されるＨＢパケット、図５右側は通信メンバから送信されるＭＲパケットの内容を示している。図５において示される通信の内容は、図４に示すパケットフォーマットを簡略化して示したものである。まず、通信リーダＡが、サイクル番号「２３」を格納したＨＢパケットを車群内の車両に対してブロードキャスト送信する。ここで、走行順車両ＩＤには、車群を構成する車両のＩＤをその走行順にしたがって格納する。また、各車両に対するＡＣＫには、前回サイクル（＃２２）においてそれぞれの車両からの通信を受信できたか否かに応じた値を格納する。自車両についてのＡＣＫは不定であって良く、本実施形態では常に「１」を格納するものとするが、このフィールドを他の用途に利用しても構わない。
【００７９】
通信メンバ（ここでは車両Ｂ）は、通信リーダからのＨＢパケットを受信すると、それに応答したＭＲパケットを送信する。ここでは、通信メンバＢから通信リーダＡへユニキャスト通信を行う。通信メンバＢは、現在サイクル（＃２３）のＭＲパケットを送信する際に、通信リーダＡのＡＣＫに関しては現在サイクル（＃２３）で通信リーダＡからの通信を受信できたか否かを、通信メンバＣ〜Ｅに関しては前回サイクル（＃２２）で各通信メンバからの通信を受信できたか否かを格納する。なお、通信メンバＢは、前回サイクル（＃２２）において他の通信メンバＣ〜Ｅが送信するＭＲパケットを傍受することで、他の通信メンバＣ〜Ｅからの通信を受信できたか否か判断する。
【００８０】
このように通信リーダが通信サイクルの管理を行い、通信メンバが各サイクルに１回通信リーダからのＨＢパケットに応答してＭＲパケットを送信するという通信方式を採用しているので、車群内の全車両についての１サイクル分のＡＣＫをまとめて送信することが可能である。これにより双方向通信の確認に必要な通信量を削減することができる。
【００８１】
（Ｃ）状態情報の定義
次に、各車両が記憶する、現在の周囲および自車両に関する情報（状態情報）について説明する。状態情報には、大きく分けて、所属する車群に関する情報、自車が属していない車群（外部車群）に関する情報、一定期間通知される情報を無視すべき車両のリスト（除外リスト）、初期設定情報が含まれる。
【００８２】
所属車群情報としては、車群ＩＤ、現在のサイクル番号、車群内車両および車群外の先行車・後続車に関する車両ＩＤ、ＡＣＫ有無、通信から得られる車両情報（位置情報等）がある。また、車群内の車両に関しては、車群内での走行順序も記憶する。
【００８３】
これらの情報は、車群内の車両や車群外の先行車・後続車からの通信や自車両のセンサ等から得られる情報が情報源となる。より詳細な情報源を図６に示す。図中、「自」とあるのは自車で定義された情報、または自車のセンサから得られる情報を意味し、「ＨＢ」とあるのは通信リーダからの情報（ＨＢパケット）であることを意味し、「ＭＲ」とあるのは通信メンバからの情報（ＭＲパケット）であることを意味し、「外」とあるのは車群外からの情報であることを意味し、「−」とあるのは情報を取得しなくても良いことを意味する。車群外の車両についての情報は一部の車群メンバは取得しなくても良いが、もちろん車群外の車両からの通信からこれらの情報を取得して記憶しても良い。
【００８４】
図６に示すように、通信リーダは、車群メンバに関する情報は各メンバ（ＭＲパケット）から取得し、車群外の先行車・後続車からの情報はこれらの車両からの通信から取得す
る。最後尾以外の通信メンバは、通信リーダに関する情報と、車群内での通信メンバの走行順序は通信リーダ（ＨＢパケット）から取得する。通信メンバのＡＣＫ（前サイクルでの自車からの通信が届いたか）や位置情報などの車両情報は、各通信メンバ（ＭＲパケット）から取得する。また、最後尾の通信メンバは、車群外の後続車両との間のＡＣＫおよび車両情報を、当該車両から取得する。
【００８５】
外部車群情報としては、車群ＩＤ、通信リーダの車両ＩＤ、サイクル番号を記憶する。これは、外部車群に属する車両からの通信を傍受することによって得られる。この情報は、周囲にどのような車群が存在するかを把握するために車両内に使用される。
【００８６】
外部車群のうち、自車両が属する車群のすぐ後ろに位置する車群については、その車群を構成する車両のＩＤおよび、これらの車両から受信した通信の最新サイクル番号を記憶する。この情報は、車群同士の合流時に後続車群内の全ての車両との間の双方向通信が確認できた段階で合流を行うために使用される。
【００８７】
除外リストは、状態の振動を防止するために一定期間送信される状態情報を無視する車両または車群のリストである。車群については、車群ＩＤ、通信リーダの車両ＩＤ、除外開始時刻を記憶する。また、車両については、車両ＩＤおよび除外開始時刻を記憶する。
【００８８】
初期設定情報としては、車群内車両台数の上限（車群サイズ）、パケットの送信レート（サイクル時間）、ランダム待機時間、通信タイムアウトと判定するまでの時間、通信途絶と判定するまでのタイムアウト回数、車群対象から除外している期間などが含まれる。
【００８９】
（Ｄ）車両の構成
図７は本実施形態に係る隊列走行システムを構成する車両の機能ブロックを示す図である。各車両は、車両走行制御ＥＣＵ（Electronic Control Unit）７０１、車車間通信装
置７０５、ＧＰＳ装置７０７、ミリ波レーダ７０８、エンジンＥＣＵ７０９、ブレーキＥＣＵ７１０、ステアリングＥＣＵ７１１などを備える。車両走行制御ＥＣＵ７０１は、後述する各種の処理を実行する制御部７０２、状態情報などを記憶する記憶部７０３、時刻を計測するタイマ７０４などを有する。車車間通信装置７０５は、車両間で無線通信を行う通信部７０６を有する。無線通信方式は任意のものであって構わないが、７００ＭＨｚ帯を利用した車車間通信システム（たとえばITC-FORUM RC-006）や、５．８ＧＨｚ帯を利用した車車間通信システム（たとえばITC-FORUM RC-005）などを採用することができるが、これらに限定されるものでもない。ＧＰＳ装置７０７は、自車両の位置情報をＧＰＳ衛星等から取得するための装置である。なお、必ずしもＧＰＳ衛星から直接送信される信号を受信するものでなく、中継装置等からの信号を受信するものであっても良い。ミリ波レーダ７０８は前方車両の位置を計測するためのものである。したがって、ミリ波以外の波長の電波や超音波などを用いた測距センサ、あるいはステレオカメラによる測距センサなどを用いても良い。エンジンＥＣＵ７０９、ブレーキＥＣＵ７１０、ステアリングＥＣＵ７１１は自車の状態を取得するためのものであり、この他にも必要に応じて車内の機器から情報を取得すればよい。
【００９０】
（Ｅ）制御フロー
ここでは、通信リーダを車群の先頭車両として設計した場合に制御要求［１］〜［１０］を満たすための処理を説明する。上述したように、通信リーダを先頭としているので車群の成長は後方からのみとする。
【００９１】
・状態遷移
まず、図８を参照して追従走行、車群協調走行、マニュアル走行の間の状態遷移を定義する。マニュアル走行時に、追従走行機能を有効にしレーダや通信などを使って実際に追
従走行が可能になると追従走行状態に遷移する。なお、実際には通信ＡＣＣによる追従走行とＡＣＣによる追従走行の２つの場合があるが、本発明においては本質的な違いではないのでこれら２つの状態をまとめて追従走行状態としている。追従走行状態において、他の車両と連続していることと双方向通信が可能であることが、それぞれレーダと通信によって判断できると、車群準備状態に遷移する。車群準備状態にある車両は、ランダム待機時間待機した後に通信リーダ状態に遷移してＨＢパケットを送信する。この際、後続車両を車群メンバとして選出する。待機時間中にＨＢパケットを受信して、その中に自車両ＩＤが含まれていれば車群メンバに遷移する。ＨＢパケットを送信する際に後続車両のみをメンバとして選出するので、結局連続する２台の車両のうち前方の車両がリーダになる。
【００９２】
また、追従走行状態中に前方車群からのＨＢパケットに自車両のＩＤが含まれている場合には、前方車群に属する通信メンバへと遷移する。
【００９３】
通信リーダは、前方車群からのＨＢパケットに自車両のＩＤが含まれている場合には、前方車群に属する通信メンバへと遷移する。
【００９４】
通信メンバは、先行車との間で通信が途絶したり、ＨＢパケットにおいて自車が先頭であったりする場合には、通信リーダ状態へと移行し、車群内の自車よりも後方の車両を通信メンバとする。また、ＨＢパケットに自車両のＩＤが含まれなくなったり、自ら車群協調走行モードを解除したりする場合には、追従走行状態へと遷移する。
【００９５】
また、いずれの状態においても、ドライバーによる隊列走行の解除によりマニュアル走行状態へ移行することができる。
【００９６】
・フローチャート
次に、車両走行制御ＥＣＵの制御部が行う処理について、図２１〜図２８のフローチャートを参照して説明する。図２１は、車両の状態にかかわらず他の車両からのパケットを受信したときに行う共通処理を示している。図２１の共通処理は、車群外からのパケットを受信したときに、それらの情報を状態情報として格納する処理、および走行制御に関係ない通信を抑制する処理といえる。
【００９７】
待機状態にあるときに他の車両からのパケットが到着すると（Ｓ２１０２）、所定時間の間走行制御を含まない通信を控える（Ｓ２１０４）。本実施形態では、他の車両から隊列走行に関するパケットを受信した車両側が、あらかじめ定められた時間だけ通信を抑制する。もちろん、走行制御を含む通信については通常通り送信を続ける。
【００９８】
そして、受信パケットが、自車両が属する車群内の車両からの車群パケットであるか判断する（Ｓ２１０６）。受信したパケットが、自車両が属さない車群からの車群パケット（自車両が車群に属しない場合は全ての車群パケットが該当する）であるか、または、車群パケット以外のパケット（通信ＡＣＣパケット）である場合は否定判定される（Ｓ２１０６−ＮＯ）。所属車群からのパケットでない場合には、受信パケットの送信元が後続車両であって、かつ、自車の通信を受信可能であるか（ＡＣＫビットが立っているか）を判断する（Ｓ２１０８）。なお、後続車両とは、自車両のすぐ後ろの車両を意味する。送信元が後続車両であるか否かは、受信パケットに含まれる車群外先行車両が、自車両であるか否かによって判断できる。送信元が後続車両であり、かつ、自車両からの通信を受信できる場合には状態情報に、所属車群情報の車群外後続車両としてこの車両を登録する（Ｓ２１１０）。なお、自車が属する車群以外の車両からのパケットを受信した場合のみＳ２１０８の判定を行うので、自車両が車群に属している場合は自車両が車群の最後尾である場合のみ、この登録が行われる。
【００９９】
また同様に、受信したパケットの送信元が先行車両であって、かつ、自車の通信を受信可能であるかを判断する（Ｓ２１１２）。先行車両とは、自車両のすぐ前に位置する車両のことである。受信パケットの送信元が先行車であるか否かは、自車両の状態（車群の先頭または非車群）および、パケットに含まれる送信元の位置情報と自車のレーダで取得できる前方車両の位置情報が一致するか否かによって判断することができる。すなわち、受信したパケットに含まれる送信元の位置情報と自車のレーダで取得できる前方車両の位置情報が一致する場合は、先行車からのパケットであると判断できる（Ｓ２１１２−ＹＥＳ）。この場合、自車の状態情報に、所属車群情報の車群外先行車両としてこの車両を登録する（Ｓ２１１４）。なお、自車が属する車群以外の車両からのパケットを受信した場合のみＳ２１１２の判定を行うので、自車両が車群に属している場合は自車両が車群の先頭である場合のみ、この登録が行われる。
【０１００】
また、受信したパケット（所属車群以外からパケット）が車群パケットであるか判断する（Ｓ２１１６）。受信パケットが車群パケットである場合（Ｓ２１１６−ＮＯ）には、状態情報として、外部車群情報にこの車群に関する情報を登録する（Ｓ２１１８）。
【０１０１】
受信したパケットが所属車群からの車群パケットでない場合（Ｓ２１０６−ＮＯ）には、上記のＳ２１０８〜Ｓ２１１８の処理を行った上で、ステップＳ２１２０へ進む。一方、受信したパケットが所属車群からの車群パケットである場合（Ｓ２１０６−ＮＯ）には、そのままステップＳ２１２０へ進む。ステップＳ２１２０では、送信元の車両が除外リストに存在する車両または除外リストに存在する車群に属する車両である場合か判断し、除外リストに該当する場合（Ｓ２１２０−ＹＥＳ）はそれ以上の処理をせずに待機状態に戻る。除外リストに該当しない場合には、受信パケットが車群パケットであるか否か判断する（Ｓ２１２２）。車群パケットである場合には車群パケット受信処理へ進み、車群パケットではない場合（通信ＡＣＣパケットである場合）は通信ＡＣＣパケット受信処理へと進む。なお、これ以降の処理は、車両の状態に応じて異なるものとなる。したがって、以下では、車両の状態別に処理フローを説明する。以下のフローチャートでは、パケット受信時だけでなく、送信タイミング到来時の処理も含まれることに注意されたい。
【０１０２】
図２２〜図２８は、各状態（追従走行状態、車群準備状態、通信リーダ、通信メンバ）において、車群パケット受信時、通信ＡＣＣパケット受信時、および送信タイミング到来時に行う処理を示すフローチャートである。上述したように、車群パケットおよび通信パケット受信時には、前処理として図２１に示した共通処理が実行されることに注意されたい。以下では、図２１〜図２８のフローチャートに従うことで、「２．本実施形態に係る隊列走行システムにおける制御要求」で示した［１］〜［１０］の機能が実現できることを説明する。
【０１０３】
［１］車群の形成
図９（Ａ）（Ｂ）に示すように、通信ＡＣＣによる追従走行中の２台の車両が通信の双方向性を確認したことにより、車群を形成する制御シナリオである。
【０１０４】
まず車両Ａ，Ｂのそれぞれは、定期的に車両ＩＤと位置情報を含む通信ＡＣＣパケットをブロードキャスト送信しながら走行をしている。車両Ｂが車両Ａの後方から接近して車両Ａの通信ＡＣＣパケット（Ｓ２１０２、Ｓ２１０６−ＮＯ）を受信したときに、車両Ａのパケットに含まれる位置情報と、自車のミリ波レーダによって得られる前方車両の位置情報とが一致して、車両Ａが車両Ｂの先行車両であることが分かる（Ｓ２１１２−ＹＥＳ）。したがって、車両Ｂは、車両Ａを車群外先行車両として登録する（Ｓ２１１４）。車両Ｂに送信タイミングが到来すると（Ｓ２２１０）、図９（Ａ）に示すように、車群外先行車両が車両Ａであり、車両Ａに対するＡＣＫを有りにした通信ＡＣＣパケットを生成してブロードキャスト送信する（Ｓ２２１２）。
【０１０５】
車両Ｂからの通信ＡＣＣパケット（Ｓ２１０２，Ｓ２１０６−ＮＯ）を受信した車両Ａは、受信したパケットの車群外先行が自車両でありＡＣＫも有る（Ｓ２１０８−ＹＥＳ）ことから、車両Ｂを車群外後続車両として登録する（Ｓ２１１０）。そして、車両Ａに送信タイミングが到来すると（Ｓ２２１０）、図９（Ａ）に示すように、車群外後続車両が車両Ｂであり、車両Ｂに対するＡＣＫを有りにした通信ＡＣＣパケット生成してブロードキャスト送信する（Ｓ２２１２）。
【０１０６】
車両Ａは、車両Ｂから受信する通信ＡＣＣパケットに自車両が車群外先行車両でかつＡＣＫも有りとされていることから、受信した通信ＡＣＣパケットは後続車両からのものであり、かつ、ＡＣＫが有る（Ｓ２２０６−ＹＥＳ）と判断できるため、車群準備状態へと状態遷移する。また、車両Ｂも同様に、車両Ａから受信する通信ＡＣＣパケットに自車両が車群外後続車両であり、かつ、ＡＣＫも有りとされていることから、受信した通信ＡＣＣパケットは先行車両からのものであり、かつ、ＡＣＫが有る（Ｓ２２０８−ＹＥＳ）と判断できるため、車群準備状態へと状態遷移する。このように、車両Ａと車両Ｂは、通信ＡＣＣによる追従走行中に、双方向通信ができること、および、両車両が連続していることを確認したことによって、車群準備状態へと状態遷移する。
【０１０７】
なお、図２２のフローチャートでは双方向の通信可能性および連続性が一度でも確認されたら状態遷移を行うもの（Ｓ２２０６かＳ２２０８のいずれかが成り立てばすぐに状態遷移する）として示しているが、何回か連続してこの条件が成立する場合に状態遷移を行うようにすることも、安定性の面で優れるので好ましい。
【０１０８】
車群準備状態へと移行した車両Ａ，Ｂは、それぞれランダム時間待機した後に送信タイミングを得る（Ｓ２３１２）。車両Ａが先に送信タイミングを得たとすると、車両Ａは通信リーダへ状態遷移するとともに、状態情報の編集を行う（Ｓ２３１４）。ここで、状態情報の編集とは車群を構成する車両を選出することを含んでいる。本実施形態では、通信リーダを車群の先頭とするために、通信リーダよりも後方に位置する車両を車群に含める。車両Ｂは車両Ａの後方であるため、作成される所属車群情報には車両Ａを通信リーダ、車両Ｂを通信メンバとする車群が格納される。また、共通処理によって得ている外部車群情報を参照して、自車両が属する車群における車群ＩＤとサイクルを、他の車群と重複しないように決定する（Ｓ２３１８）。そして、車両Ａは、通信リーダとして図９（Ｂ）に示すＨＢパケットをブロードキャスト送信する（Ｓ２３１８）。車群準備状態にある車両Ｂが、このＨＢパケットを受信し（Ｓ２３０２、Ｓ２３０４−ＨＢ）、このＨＢパケットが先行車両のものからでありかつＡＣＫ確認も有る（Ｓ２３０６−ＹＥＳ）ことから、車両Ａを通信リーダとする車群のメンバになったことが分かる。そこで、車両Ｂは通信メンバへと状態遷移し、状態情報を更新する（Ｓ２３０８）。
【０１０９】
なお、後方に位置する車両Ｂが先に送信タイミングを得た場合には、通信メンバを後方に位置する車両からのみ選択するので、車両Ｂは自車両のみから構成される車群の通信リーダとなる。車両Ｂは通信リーダとしてＨＢパケットを送信するが、車両Ａにとっては車両Ｂは先行車両ではない（Ｓ２３０６−ＮＯ）ことから車群準備状態を継続する。やがて、車両Ａが送信タイミングを得て、上記の説明と同様に、車両Ｂをメンバとした車群を形成することになる。通信リーダとなっていた車両Ｂも、他の車群から送信されるＨＢパケット内に自車両のＩＤを発見することから、車両Ａを通信リーダとする車群の通信メンバに遷移する（Ｓ２４０４−Ｓ２４０６−Ｓ２４０８−Ｓ２４１０）。したがって、車群準備状態にある車両Ａと車両Ｂのいずれが先に送信タイミングを得たとしても、最終的に形成される車群は同じとなる。
【０１１０】
このようにして、通信ＡＣＣによって追従走行を行っていた車両Ａと車両Ｂの間で通信
の双方向性および連続性が確認されると、前方の車両Ａを通信リーダとして２台の車両からなる車群が形成されることになる。車群を形成した車両Ａと車両Ｂは、車両Ａ，Ｂを車群リストに含むＨＢパケットとＭＲパケットを定期的に交換して、通信の双方向性を確認しながら車群協調走行を行うことができる。
【０１１１】
［２］車群への参加
図１０（Ａ）（Ｂ）に示すように、車群に対して通信ＡＣＣで追従している車両が、車群に参加して車群が大きくなるシナリオである。
【０１１２】
まず、図１０（Ａ）に示すように、車両Ａ〜Ｃで構成される車群の後方に、通信ＡＣＣにより追従走行を行う車両Ｄが存在する状況を考える。この状況では、車両Ｄが車群外先行車両として車両Ｃを認識して（Ｓ２１１２−Ｓ２１１４）、通信ＡＣＣパケットを送信する（Ｓ２２１２）。つまり車両Ｄが送信する通信ＡＣＣパケットには車群外先行車両として車両Ｃが格納され、かつ、ＡＣＫ有りが格納される。車両Ｃがこの通信ＡＣＣパケットを受信することで、車両Ｃは車両Ｄが車群外後続車両であることを認識する（Ｓ２１０８−Ｓ２１１０）。車両Ｃは、車群外後続車両に車両Ｄを格納してＭＲパケットを送信する（Ｓ２８０８）。通信リーダＡは、このＭＲパケットを受信することで車群外後続車両が車両Ｄであることを認識する（Ｓ２４０４−Ｓ２４３２−Ｓ２４３４−Ｓ２４３６）。
【０１１３】
このように通信リーダ（車両Ａ）が、車群外後続車両が車両Ｄであると認識している状況で、車両Ｄからの通信ＡＣＣパケットを受信したときの処理を説明する。通信ＡＣＣパケットを受信した通信リーダ（Ｓ２５０２）は、車群外後続車両である車両Ｄと車群最後尾車両である車両Ｃとの間で双方向通信が確立している（Ｓ２５０４−ＹＥＳ）ことから、車群内の車両台数が最大に達していなければ（Ｓ２５０６−ＹＥＳ）、車両Ｄを車群の最後尾に登録する（Ｓ２５０８）。そして、次の送信タイミングで通信リーダは、車両Ｄを車群リストに含めてＨＢパケットを送信する。
【０１１４】
追従走行をしている車両Ｄが、車両ＡからのＨＢパケットを受信すると、まず受信パケットは先行車からのものでありかつＡＣＫが有る（Ｓ２２０８−ＹＥＳ）ので、車群準備状態へ遷移する。そして、車群準備状態においてＨＢパケットを受信したときに（Ｓ２３０４−ＨＢ）、このＨＢパケットが先行車両からのものでありかつＡＣＫの確認も有る（Ｓ２３０６−ＹＥＳ）ので、通信メンバ状態へと遷移する（Ｓ２３０８）。またこのとき自車両が車群に所属したことに応じて、状態情報を更新する。
【０１１５】
このようにして、車群に対して通信ＡＣＣで追従していた車両Ｄが、車群と車両Ｄの間で双方向通信可能性と連続性が確認された場合に、車群に合流することができる。
【０１１６】
［３］車群同士の合流
図１１（Ａ）（Ｂ）に示すように、車群間を通信ＡＣＣで追従走行している２つの車群が合流して１つの大きな車群を形成するシナリオである。
【０１１７】
前方車群１１０１の最後尾車両Ｃと後方車群１１０２の先頭車両Ｄとか連続していることは、上記と同様にして分かる。車両Ｃが送信するＭＲパケットを受信することによって、前方車群１１０１内の各車両は車群外後続車両が車両Ｄであることが認識できる。同様に、車両Ｄが送信するＨＢパケットを受信することによって、後方車群内の各車両は車群外先行車両が車両Ｃであることが認識できる。
【０１１８】
通信リーダＡが後方車群内の通信メンバからＭＲパケットを受信した場合は、Ｓ２４０４−Ｓ２４０６−Ｓ２４２２−Ｓ２４２４と処理が進み、ＭＲパケットに含まれる車群リストを後方車群情報に登録する。また、後方車群の通信リーダからＨＢパケットを受信し
た場合は、Ｓ２４０４−Ｓ２４０６−Ｓ２４０８−Ｓ２４１２−Ｓ２４２２−Ｓ２４２４と処理が進み、結局同様の処理が行われることになる。なおＳ２４１２における判断は、通信リーダＡが同一車群に属していると認識している通信メンバからＨＢパケット（別の車群ＩＤを有する）を受信したか否かの判断なので、このケースでは否定判定される。通信リーダは、後方車群情報として、後方車群をどの車両が構成するかと、後方車群を構成するそれぞれの車両からの通信を受信できるか否かを記憶している。そして、後方車群からのＨＢパケットを受信したときに（Ｓ２４２５−ＹＥＳ）、後方車群に属する全車両から通信を受信可能であり（Ｓ２４２６−ＹＥＳ）、後方車群を全て合流しても最大数に達しない場合（Ｓ２４０８−ＹＥＳ）は、所属車群情報の最後尾に、後方車群を構成する各車両を登録する（Ｓ２４３０）。また、後方車群を除外リストに登録して、一定期間後方車群からの情報による状態情報の変更を行わないようにする。通信リーダは、送信タイミングが到来すると、車群リストに車両Ａ〜Ｆまでを含むＨＢパケットを送信する（Ｓ２６１２）。
【０１１９】
後方車群の通信リーダＤは、車両ＡからのＨＢパケットを受信すると、他の車群のＨＢパケットに自車両のＩＤを発見するので通信メンバへと状態遷移する（Ｓ２４０４−Ｓ２４０６−Ｓ２４０８−Ｓ２４１０）。また、車両ＡからのＨＢパケットを受信した、後方車群の通信メンバＥ，Ｆは、他の車群のＨＢパケットに自車両のＩＤを発見するので、所属車群を変更する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、通信メンバＥ，Ｆは、元の車群を除外リストに登録して、所属車群の変更が完了していない同一車群に属していた車両からの情報による状態変動を起こさないようにする。
【０１２０】
このようにして、通信ＡＣＣにより追従走行していた２つの車群１１０１，１１０２の間で、連続性と通信の双方向性が確認された場合に、これら２つの車群１１０１，１１０２を１つの車群１１０３に合流することができる。
【０１２１】
［４］車両ＩＤの競合解決
通信に使用するパケット内では、車群内の車両に関するＩＤは本来のビット数（例えば１６ビット）よりも短いビット数（例えば７ビット）で表現している（図４（Ｂ）参照）。これは、通信パケットのデータ量を減らすための工夫である。そもそも車両ＩＤに重複がないことは保証していないが、仮に１６ビットの車両ＩＤが重複していない場合でも、下位７ビットのみを使用する場合は衝突が発生する確率が高まる。このような車群内で使用するビット数を短縮化した車両ＩＤが衝突した場合に、車両ＩＤの再設定を行って競合を解決する必要がある。
【０１２２】
図１２（Ａ）に示すように８台の車両で車群が構成されている例を考える。図中「ｈ−ｏ」などとあるのは、全１６ビットの車両ＩＤのうち、上位９ビットが「ｈ」であり、下位７ビットが「ｏ」であることを意味している。この例では、通信リーダと６台目の車両の下位７ビットが「ｇ」で衝突しており、４台目と７台目の車両の下位７ビットが「ｅ」で衝突している。
【０１２３】
本実施形態では、通信リーダは車両ＩＤの再設定は行わず、通信メンバが車両ＩＤの下位７ビットの再設定を行って競合を解決する。すなわち、通信リーダは、車群リスト内の車両ＩＤが重複しているか否かの判断は行わない。一方、通信メンバは、通信リーダから受信するＨＢパケットにおいて自車両のＩＤ（下位７ビット）が２つ以上登録されているか判断する（Ｓ２７２６）。ここで車両ＩＤの競合が発生している場合には、自車両の車両ＩＤの下位７ビットに関して再設定を行う（Ｓ２７３０）。なお、新しい車両ＩＤの下位７ビットは、ＨＢパケットに含まれている「ｇ」「ｈ」「ｗ」「ｅ」「ｍ」「ｏ」以外の値をランダムに選択するものとする。ランダムに設定しているので、再度衝突が発生する可能性もあるが、再設定処理を繰り返すことで最終的には競合が解決できる。
【０１２４】
また、車両ＩＤが競合している通信メンバからのＭＲパケットは、どの通信メンバに関する情報であるか判断できないため、受信したＭＲパケットの送信元の車両ＩＤが競合している場合にはそのＭＲパケットは無視する（Ｓ２７１８）。一方、通信リーダの車両ＩＤが他のメンバと競合している場合であっても、通信リーダからのパケットをパケット種別（ＨＢパケット）から判断できるので、ＨＢパケットについてはそのような処理を行う必要はない。
【０１２５】
このように、車群内で車両ＩＤが衝突したときの競合解決が可能となる。競合解決が担保されると、車群内では短縮化した車両ＩＤを使って通信データ量を減らすことが可能となる。
【０１２６】
なお、短縮化した車両ＩＤを使うことにより通信データ量を減らすことができるが、競合解決のためのオーバヘッドが生じるのは避けられない。通信データ量が問題とならないケースやオーバヘッドが許されない環境では、車群内であっても短縮化した車両ＩＤを用いないことが好ましいと言える。
【０１２７】
［５］車線変更による離脱
車群を構成する車両が路線変更などにより隊列から離脱した場合に、残りの車両で車群を維持して隊列走行を行うというシナリオである。
【０１２８】
まず、図１３（Ａ）（Ｂ）を参照して通信メンバが路線変更により離脱する場合を説明する。ここでは５台の車両Ａ〜Ｅで構成される車群から、車両Ｃが路線変更した場合を考える。このとき、通信により通知される車群リストには車群を構成する車両とその走行順序が格納されているので、車群内の各車両は車群の状況が把握できる。各車両は、通信リーダＡから送信されるＨＢパケットによって、車両Ａ，Ｂ，Ｃ，Ｄ，Ｅの順からなる５台の車両から車群が構成されていることが分かる。また、それぞれの車両の位置情報も車群パケットに格納されている。
【０１２９】
一方、各車両はレーダによって前方車両の位置が分かる。車両Ｃが路線変更した場合、車両Ｄは前方の車両が（Ｘｂ，Ｙｂ）に位置することがレーダから検出できる。ここで、車群パケットから得られる位置情報を参照すると、（Ｘｂ，Ｙｂ）に位置する車両は車両Ｂであることが分かる。すなわち、車両Ｄは車両Ｂのすぐ後ろに位置していることが分かり、したがってその間に位置していた車両Ｃが路線変更等により離脱したことが分かる。そこで、車両Ｄは所属車群情報から離脱した車両Ｃを除いて、車両Ａ，Ｂ，Ｄ，Ｅがこの順序で並んで車群を構成していると更新する。この処理は、Ｓ２７２０またはＳ２７２８で行われる処理である。車両Ｄに送信タイミングが到来すると、車両Ｄは自車が保持している状態情報、すなわち、車群は車両Ａ，Ｂ，Ｄ，Ｅから構成されるという車群リストをＭＲパケットに格納して送信する。
【０１３０】
通信リーダＡは、車両ＤからのこのＭＲパケットを受信すると、車群から車両Ｃが離脱したことを認識し、状態情報を更新する（Ｓ２４０４−Ｓ２４３２−Ｓ２４３４−Ｓ２４３６）。通信リーダＡに送信タイミングが到来すると、通信リーダは自車が保持している状態情報、すなわち車群は車両Ａ，Ｂ，Ｄ，Ｅから構成されるという車群リストをＨＢパケットに格納して送信する（Ｓ２６１２）。
【０１３１】
通信リーダＡからのＨＢパケットを受信した車群メンバは、車群から車両Ｃが離脱したことを車群リストから認識できる。
【０１３２】
このように、車群中の車両が路線変更等により離脱した場合であっても、残りの車両に
よって車群を維持することができる（Ｓ２７２８）。
【０１３３】
次に、図１４（Ａ）（Ｂ）を参照して通信リーダが路線変更等により離脱する場合を説明する。このとき、車群において通信リーダの直後を走行していた通信メンバである車両Ｂは、レーダによって車群内の先行車両を特定することができなくなる。車両Ｂに送信タイミングが到来したときに先行車が特定不能であれば、車両Ｂは通信リーダへと状態遷移する（Ｓ２８０２−Ｓ２８０４−Ｓ２８１０）。そして、自車両を通信リーダとして、元の車群に含まれる車両のうち、自車両よりも後方に位置する全ての車両を通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャスト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｂ〜Ｅが格納されている。
【０１３４】
車両Ｂから送信されるＨＢパケットを受信した車両Ｃ〜Ｅでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、所属車群情報を受信したＨＢパケットにしたがって編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１３５】
このように、通信リーダが路線変更等により車群から離脱した場合であっても、２番目を走行していた通信メンバが新しい通信リーダとなって、車群を維持することができる。
【０１３６】
［６］ドライバーによる解除
車群協調走行中に、その車群内の１台がドライバーによって車群隊列走行を解除し、マニュアル走行または通信ＡＣＣ走行に移行したときに、残りの車両で車群を維持して隊列走行を行うというシナリオである。
【０１３７】
図１５に示すように、７台の車両Ａ〜Ｇが車群を形成しているときに車両Ｄがドライバーの操作によって車群協調走行を解除した場合を考える。車両Ｄは、通信機能により車群協調走行を解除したことを周囲の車両に通知する。このとき車両Ｄが送信する通信情報は、制御情報に自車の隊列走行モード（「マニュアル」または「通信ＡＣＣ」）を格納し、走行順リストには、車群外前方車両に車両Ｃを、車群外後方車両に車両Ｅを格納して送信する。
【０１３８】
車群の通信リーダが、ドライバー操作による協調走行解除を通知するパケットを受信した場合（Ｓ２６０９−ＹＥＳ）は、この車両から車群外後続車両までを所属車群情報から削除するとともに、除外リストに登録する（Ｓ２６１１）。これにより、車両Ｄおよびこれより後方に位置する車両が車群から除外され、車両Ａが通信リーダである車群には車両Ａ〜Ｃのみが含まれるようになる。そして通信リーダは、ＨＢパケットの車群リストに車両Ａ，Ｂ，Ｃのみを格納して送信することで、他の車両に対して車群を構成するメンバが変更したことを通知する。
【０１３９】
一方、通信メンバが、ドライバー操作による協調走行解除を通知するパケットを受信した場合は、解除を行った車両が先行車であるか判断する（Ｓ２８０７）。自車両の前方に位置する車両が協調走行を解除した場合には、自車両が通信リーダへ遷移する（Ｓ２８１０）。この場合は、車両Ｅが通信リーダへと遷移する。そして、自車両よりも後方の車両Ｆ，Ｇを通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャス
ト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｅ，Ｆ，Ｇが格納されている。
【０１４０】
車両Ｅから送信されるＨＢパケットを受信した車両Ｆ，Ｇでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、受信したＨＢパケットにしたがって所属車群情報を編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１４１】
このように、車群内のいずれかの車両でドライバーが車群協調走行を解除した場合であっても、その位置で車群を分離して前方車群および後方車群を生成して車群協調走行が行える。
【０１４２】
［７］非通信車両の割り込み
車群内に、通信機能を有していない車両が割り込んだときに、この非通信車両の前後で車群を分離するシナリオである。
【０１４３】
図１６に示すように、６台の車両Ａ〜Ｆで構成される車群が形成されているときに、車両Ｄの前方に通信機能を有していない車両Ｘが割り込んだ場合を考える。このとき、通信により通知される車群リストには、車群を構成する車両とのその走行順序が格納されているので、車群内の状況が把握できる。ここでは、車群が車両Ａ，Ｂ，Ｃ，Ｄ，Ｅ，Ｆの順からなる６台の車両で構成されていることが分かる。また、それぞれの車両の位置情報も車群パケットに格納されている。
【０１４４】
一方、各車両はレーダによって前方車両の位置が分かる。車両Ｄの前方に非通信車両Ｘが割り込んだ場合は、レーダによって得られる前方車両の位置と、車群通信によって得られる前方車両（車両Ｃ）の位置（Ｘｃ，Ｙｃ）とが矛盾することになる。すなわち、車両Ｄは、先行車両を特定することができなくなる。
【０１４５】
通信メンバである車両Ｄに送信タイミングが到来したときに、車両Ｄは先行車両が特定できないので、通信リーダへと状態遷移する（Ｓ２８０４−Ｓ２８１０）。そして、自車両を通信リーダとして、元の車群に含まれる車両のうち、自車両よりも後方に位置する全ての車両を通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャスト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｄ，Ｅ，Ｆが格納されている。
【０１４６】
車両Ｄから送信されるＨＢパケットを受信した車両Ｅ，Ｆでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、所属車群情報を受信したＨＢパケットにしたがって編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１４７】
また、車両Ｄから送信されるＨＢパケットを受信した車両Ａ（元の車群の通信リーダ）は、受信パケットが他の車群からのＨＢパケットであり（Ｓ２４０４−ＮＯ，Ｓ２４０６−ＹＥＳ）、自車の所属車群情報に通信メンバとして登録されている車両が送信元である（Ｓ２４１２ーＹＥＳ）ことが分かる。受信したＨＢパケットの送信元の車両Ｃは、元の
車群の３番目以降なので（Ｓ２４１６−ＮＯ）、車両Ｃおよびそれより後ろの車両Ｅ，Ｆを車群から削除して、車両Ａ，Ｂ，Ｃのみを車群リストに含むように所属車群情報を更新する（Ｓ２４２０）。なお、分離した後続車群の通信リーダの走行位置が２番目であった場合（Ｓ２４１６−ＹＥＳ）は、通信リーダＡは１台だけの車群となるので、車群準備状態へと遷移する（Ｓ２４１８）。なお、いずれの場合も、分離した車群との間で状態の振動を起こさないように、新たな車群を除外リストに追加している（Ｓ２４１４）。
【０１４８】
通信リーダＡから車両Ａ〜Ｃを車群リストに含むＨＢパケットを受信した車両Ｂ，Ｃは、所属車群を構成する車両に変化があったことを認識して、所属車群情報を更新する。
【０１４９】
このように、車群内に通信機能を有しない車両が割り込んだ場合であっても、その位置で車群を分離して前方車群および後方車群を生成して車群協調走行が行える。
【０１５０】
［８］特定車両の通信機能停止
車群内の特定車両の通信機能が停止したときに、この車両の前後で車群を分離するシナリオである。通信機能の停止には、送信機能の停止と、受信機能の停止がある。まず、それぞれの場合について、どのようにして機能停止を他の車両が検知するかについて説明する。
【０１５１】
図１７（Ａ）は、車両Ａ〜Ｇで構成される車群内の車両Ｄの送信機能が停止した場合を説明する図である。車群内の車両は、自車両は車両Ｄからの通信を受信しないことがわかる。そこで、ＨＢパケットまたはＭＲパケットに車両ＤについてＡＣＫ無しを格納して送信する。また、他の車両からのパケットにも車両ＤについてＡＣＫ無しが格納されていることから、車群内の各車両は自車両だけでなく車群内の全車両が車両Ｄからの通信を受信できないことが分かる。このように、車群内の車両のうち所定割合以上の車両（全車両でも良い）が、車両ＤについてＡＣＫ無しの車群パケットを送信した場合は、この車両Ｄの通信機能が停止したと判断できる。なお、この判断は１サイクルだけで判断するのではなく、車両ＤからのＡＣＫ無しが所定サイクル以上続いた場合に、車両Ｃの送信機能が停止したと判断することが好ましい。
【０１５２】
図１７（Ｂ）は、車両Ａ〜Ｇで構成される車群内の車両Ｄの受信機能が停止したが送信機能は有効な場合を説明する図である。車両Ｄは受信機能が停止していることから他の車両からの通信を受信できず、ＭＲパケット（またはＨＢパケット）に他の車両についてＡＣＫ無しを格納して送信する。車両Ｄ以外の車両は、車群内の各車両からの通信を受信できるので、各車両についてＡＣＫ有りを格納してＭＲパケットまたはＨＢパケットを送信する。このように車両Ｄから車群内の車両のうち所定割合以上の車両（全車両でも良い）についてＡＣＫ無しの車群パケットを受信し、他の車両からはＡＣＫ有りの車群パケットを受信している場合には、車両Ｄの受信機能が停止したことが判断できる。なお、この判断も、１サイクルだけで判断するのではなく、車両Ｄが各車両について所定サイクル以上続けてＡＣＫ無しの車群パケットを送信する場合に、車両Ｄの受信機能が停止したと判断することが好ましい。
【０１５３】
図１８は先行車両の通信機能が停止したときの制御を説明する図である。車両Ｄの通信機能（送信機能・受信機能いずれでも）が停止した場合、車両Ｅは送信タイミング到来時に先行車両の通信機能が停止している（Ｓ２８０６−ＹＥＳ）ことから、通信リーダへと遷移し（Ｓ２８１０）、自車両よりも後方の車両Ｆ，Ｇを通信メンバとして新しい車群を生成して所属車群情報として登録する（Ｓ２８１２）。外部の車群と重複しない車群ＩＤおよびサイクルを選択し（Ｓ２８１４）、元の車群を除外リストに登録した上で（Ｓ２８１６）、ＨＢパケットを作成してブロードキャスト送信する（Ｓ２８１８）。このＨＢパケットの車群リストには車両Ｅ，Ｆ，Ｇが格納されている。
【０１５４】
車両Ｅから送信されるＨＢパケットを受信した車両Ｆ，Ｇでは、ＨＢパケットの車群ＩＤは自車が属している車群ＩＤとは異なるものの、そのＨＢパケットの車群リスト中に自車の車両ＩＤが存在することが分かる。したがって、自車は今までとは異なる車群のメンバになったことが認識できるので、受信したＨＢパケットにしたがって所属車群情報を編集する（Ｓ２７０４−Ｓ２７０６−Ｓ２７０８−Ｓ２７１０）。また、元の車群からの情報による状態の振動を避けるために、元の車群を除外リストに追加する（Ｓ２９１２）。
【０１５５】
また、車両Ｅから送信されるＨＢパケットを受信した車両Ａ（元の車群の通信リーダ）は、受信パケットが他の車群からのＨＢパケットであり（Ｓ２４０４−ＮＯ，Ｓ２４０６−ＹＥＳ）、自車の所属車群情報に通信メンバとして登録されている車両が送信元である（Ｓ２４１２ーＹＥＳ）ことが分かる。受信したＨＢパケットの送信元の車両Ｅは、元の車群の３番目以降なので（Ｓ２４１６−ＮＯ）、車両Ｅ、それより後ろの車両Ｆ，Ｇ、および通信機能の停止した車両Ｄを車群から削除して、車両Ａ，Ｂ，Ｃのみを車群リストに含むように所属車群情報を更新する（Ｓ２４２０）。なお、いずれの場合も、分離した車群との間で状態の振動を起こさないように、新たな車群を除外リストに追加している（Ｓ２４１４）。
【０１５６】
通信リーダＡから車両Ａ〜Ｃを車群リストに含むＨＢパケットを受信した車両Ｂ，Ｃは、所属車群を構成する車両に変化があったことを認識して、所属車群情報を更新する。
【０１５７】
ここで車両Ｅは、受信機能が停止したことにより周囲の車両からの通信が受信できなくなる。したがって、車両Ｅでも自らの受信機能が停止したことを推定できる。そこで、車両Ｅは他の車両からのパケットを受信しなくても、車群メンバ状態から追従走行状態へと遷移することが好ましい。通信メンバは、自らの受信機能が停止した場合（Ｓ２８０８−ＹＥＳ）には、車群準備状態へと遷移し（Ｓ２８２０）、状態情報を編集する。また、元の車群を除外リストに追加する（Ｓ２８２２）。これにより、受信機能が途絶えた車両は、自らメンバを解除できる。
【０１５８】
このように、車群内のいずれかの車両で通信機能が停止した場合であっても、その位置で車群を分離して前方車群および後方車群を生成して車群協調走行が行える。
【０１５９】
［９］通信可能範囲外への移動
車群内の車両が通信可能範囲外へ移動した場合に、通信可能な車両同士で車群を維持するシナリオである。図１９（Ａ）（Ｂ）は、車両Ａ〜Ｅの５台の車両で車群を形成している際に、車両Ａ，Ｂ間の車間距離が開いて車両Ａ，Ｂ間での通信ができなくなった場合を示す図である。車両Ｂは、先行車両からの通信を受信できなくなるので、先行車を特定することができなくなる（Ｓ２８０４−ＹＥＳ）。したがって、図１４（Ｂ）に示すように車両Ｂは通信リーダへ遷移して、車群内で自車よりも後方に位置する車両を通信メンバとした新しい車群を形成する。これ以降の処理は上記［７］で説明した処理と同じであるため、詳細は省略する。
【０１６０】
なお、図１９（Ａ）（Ｂ）では通信リーダ（先頭車両）と２番目の車両との間で車間距離が開いた場合を説明したが、車群内の任意の車両間で車間距離が開いた場合も、先行車両を特定できなくなった車両が通信リーダに遷移することに代わりはない。
【０１６１】
［１０］電波干渉の発生
電波干渉が発生した場合に、車群協調走行を行う車両台数を減らして通信量を抑制することで、通信品質を回復する制御である。
【０１６２】
図２０（Ａ）（Ｂ）は、車両Ａ〜Ｇの７台の車両で構成される車群内で電波の干渉が発生した場合を説明する図である。電波干渉が発生すると車群内の多くの車両で電波を受信できなくなる。したがって、通信リーダは、車群リストにＡＣＫ無しを多く含むＭＲパケットを同時に受信することになる。このように、通信リーダは、車群内の通信メンバが全体的に他車両からの通信をできなくなった場合に、電波干渉による受信障害が発生したと判断する。
【０１６３】
通信リーダが同時多発的な受信途絶を検知したときは、所属車群情報から最後尾車両を削除する（Ｓ２６０６−Ｓ２６１０）。この例では、車群最後尾の車両Ｇを通信メンバから除外して、車群外後続車両として登録する。そして、通信リーダは、新しい車群リストを含むＨＢパケットを生成してブロードキャスト通信する（Ｓ２６１２）。
【０１６４】
このＨＢパケットを受信した車両Ｇは、自車が属していた車群からのＨＢパケットであるにもかかわらず、自車両のＩＤがＨＢパケットに含まれないことから、自車両が車群から除外されたことを検知して車群準備状態へ遷移する（Ｓ２７０４−Ｓ２７１４−Ｓ２７２４−Ｓ２７３２）。
【０１６５】
なお、通信メンバである車両Ｂ〜Ｆは、車両ＡからのＨＢパケットを受信することで、車両Ｇが車群から除外されたことを認識できるので、状態情報を更新する。
【０１６６】
このようにして、車両Ｇと車両Ａ〜Ｆは別の車群となるので、車両Ｆ，Ｇ間は通信ＡＣＣによる追従走行となり車間距離が開くので、電波干渉が軽減されることになる。なお、車両Ｇを車群から除外しても電波干渉が改善されない場合には、さらに次の最後尾車両を除外していくことで、最終的に電波干渉が軽減される。
【０１６７】
以上のように本実施形態によれば、車群内での通信量を削減することで、通信品質の向上すなわち通信途絶の抑制が可能となる。また、通信途絶が発生した場合であっても、重大な影響が及ぶ範囲を車群内に限定可能である。また、通信途絶が発生した場合に車群を分離することで、通信途絶が発生した車群内についても重大な影響がおよび範囲を限定可能である。
【０１６８】
なお、上記では例示的に実施形態を参照して本発明の説明を行ったが、本発明は上記で記した実施形態に限定して解釈するべきではない。たとえば、実施形態では通信リーダが車群の先頭である場合を例に説明しているが、通信リーダを先頭以外としても良い。また、通信リーダが先頭であっても先頭以外であっても、車群の前方に位置する車両を車群に合流するようにしても構わない。前方の車両を合流する場合も後方の車両を合流する場合と同様の処理により対処可能である。また、車群内で通信リーダが変更する場合も、新しい通信リーダがＨＢパケットにより自車両が通信リーダになったことを通知すればよい。
【０１６９】
また、上記の実施形態では、通信リーダと制御リーダが同一の車両である場合を例に説明しているが、必ずしも通信リーダと制御リーダとを同一の車両とする必要はない。たとえば、通信リーダを中央付近の車両（先頭車両以外の車両）とし、制御リーダを先頭車両とする形態が考えられる。通信リーダが上記の説明と同様の方法により車群の維持・管理を行い、制御リーダが車群の隊列走行を制御する。この場合、制御リーダが目標制御値を含む走行制御情報をブロードキャスト送信し、これを受信した通信リーダが車群メンバに走行制御情報を再度ブロードキャスト送信することで、車群内の各車両に走行制御情報を伝達する。このように、通信リーダと制御リーダとを別々の車両とした場合、メンバー離脱などの解散の影響が少なくなりロバスト性が向上する。また、通信リーダによる走行制御情報の転送により車群の範囲が広がるという利点もある。
【符号の説明】
【０１７０】
７０１ 車両走行制御ＥＣＵ
７０２ 制御部
７０３ 記憶部
７０４ タイマ
７０５ 車車間通信装置
７０６ 通信部
７０７ ＧＰＳ装置
７０８ ミリ波レーダ
７０９ エンジンＥＣＵ
７１０ ブレーキＥＣＵ
７１１ ステアリングＥＣＵ
【特許請求の範囲】
【請求項１】
双方向通信が可能な複数の車両から、１台の車両をリーダ、その他の車両をメンバとして車群を形成し、車群内の車両同士による通信を利用して隊列走行を行う隊列走行通信システムによる車群管理方法であって、
リーダが、定期的に情報を送信するステップと、
各メンバが、リーダから送信される情報に対して応答を返すステップと、
を含み、
リーダから送信される情報には、前サイクルにおける各メンバからの通信を受信できたか否かを示す受信情報が含まれ、
各メンバから送信される情報には、現サイクルにおけるリーダからの通信、および、前サイクルにおける他のメンバからの通信を受信できたか否かを示す受信情報が含まれ、
各車両は、他の車両から送信される情報に含まれる受信情報に基づいて、送達確認を行い、
前記送達確認によって通信の双方向性が確認された車両で車群を形成および維持する
ことを特徴とする車群管理方法。
【請求項２】
各車両が定期的に送信する情報には、当該車両の位置、車群を構成する車両の識別子、車群を構成する各車両に対する受信応答が含まれ、
各車両は、他の車両から送信される情報と、自車両が備えるセンサによって取得される情報とに基づいて、自律的に走行制御を行う
ことを特徴とする請求項１に記載の車群管理方法。
【請求項３】
車群を構成する車両が定期的に送信する情報には、さらに、車群を構成する車両の車群内の走行順序も含まれる
ことを特徴とする請求項２に記載の車群管理方法。
【請求項４】
車群を構成する車両が定期的に送信する情報には、車群を構成する車両の識別子が、車群内の走行順序にしたがって列挙されている
ことを特徴とする請求項３に記載の車群管理方法。
【請求項５】
車群の先頭に位置する車両は、車群外の前方の車両に対して追従する走行制御を行い、
車群の先頭車両とその前方の車両との間の車間距離は、車群内での車間距離よりも長い
ことを特徴とする請求項１〜４のいずれかに記載の車群管理方法。
【請求項６】
各車両が送信する情報には、少なくとも当該車両の位置が含まれており、
各車両が前方車両の位置を測定可能な測距手段を有しており、
車両から送信される情報に含まれる位置と、測距手段によって測定される前方車両の位置とが一致するかによって、車両が連続しているか否かを判断し、
前記送達確認により通信の双方向性が確認され、かつ、連続している車両で車群を形成および維持する
ことを特徴とする請求項１〜５のいずれかに記載の車群管理方法。
【請求項７】
リーダは、車群内の先頭車両である
ことを特徴とする請求項１〜６のいずれかに記載の車群管理方法。
【請求項８】
車群を構成する車両の台数に上限が設けられている
ことを特徴とする請求項６または７に記載の車群管理方法。
【請求項９】
車群を構成していない２台の車両の間で、通信の双方向性および連続性が確認された場
合は、当該２台の車両で車群を形成する
ことを特徴とする請求項６〜８のいずれかに記載の車群管理方法。
【請求項１０】
リーダは、車群内の先頭車両であり、
前記２台の車両のうち、前方車両がリーダとなり、後方車両がメンバとなる
ことを特徴とする請求項９に記載の車群管理方法。
【請求項１１】
車群を構成している複数の第１の車両と車群を構成していない第２の車両との間で、通信の双方向性が確認され、かつ、
前記第１の車両のいずれかと前記第２の車両とが連続している判断された場合に、
前記第２の車両を前記車群に合流させる
ことを特徴とする請求項６〜１０のいずれかに記載の車群管理方法。
【請求項１２】
リーダは、車群内の先頭車両であり、
前記車群内の最後尾車両と前記第２の車両とが連続していると判断された場合に、前記第２の車両を前記車群に合流させる
ことを特徴とする請求項１１に記載の車群管理方法。
【請求項１３】
第１の車群を構成している複数の第１の車両と第２の車群を構成している複数の第２の車両に関し、全ての車両間で通信の双方向性が確認され、かつ、前記第１の車両のいずれかと前記第２の車両のいずれかとが連続していると判断された場合に、
前記第１の車群と前記第２の車群を合流させる
ことを特徴とする請求項６〜１２のいずれかに記載の車群管理方法。
【請求項１４】
リーダは、車群内の先頭車両であり、
前記第１の車群の最後尾車両と前記第２の車両の先頭車両とが連続していると判断された場合に、前記第２の車群内の全ての車両を前記第１の車群のメンバとして合流させる
ことを特徴とする請求項１３に記載の車群管理方法。
【請求項１５】
車群内のいずれかの車両において、当該車両の前記測距手段によって測定される前方車両の位置が、他の車両から送信される情報に基づいて当該車両の２つ前の車両の位置と等しいと判断できる場合は、当該車両の前方に位置していた車両が車群から離脱したと判断し、この離脱した車両を車群から除く
ことを特徴とする請求項６〜１４のいずれかに記載の車群管理方法。
【請求項１６】
車群内のいずれかの車両が隊列走行を解除した場合には、当該車両より前方の車両からなる車群と、当該車両よりも後方の車両からなる車群との２つの車群に分離する
ことを特徴とする請求項６〜１５のいずれかに記載の車群管理方法。
【請求項１７】
車群内に他の車両と通信不可能な車両が現れた場合には、当該車両より前方の車両からなる車群と、当該車両よりも後方の車両からなる車群との２つの車群に分離する
ことを特徴とする請求項６〜１６のいずれかに記載の車群管理方法。
【請求項１８】
車群内に他の車両と通信不可能な車両が現れる場合とは、車群内に通信機能を有しない車両が割り込んだ場合であり、
車群内のいずれかの車両において、当該車両の測距手段によって測定される前方車両の位置が、他の車両から送信される情報から得られる車群内のいずれの車両の位置とも一致しない場合に、自車両の前方に通信機能を有しない車両が割り込んだと判断する
ことを特徴とする請求項１７に記載の車群管理方法。
【請求項１９】
車群内に他の車両と通信不可能な車両が現れる場合とは、車群内の車両の通信機能が停止した場合であり、
車群内の車両は、他の車両から送信される情報に含まれる受信情報に基づいて、車群内の車両の通信機能の停止を判断する
ことを特徴とする請求項１７に記載の車群管理方法。
【請求項２０】
車群内で同時多発的な通信途絶が発生した場合は、車群内のメンバを少なくとも１台車群から除外する
ことを特徴とする請求項６〜１９のいずれかに記載の車群管理方法。
【請求項２１】
リーダは、車群内の先頭車両であり、
車群内で同時多発的な通信途絶が発生した場合は、車群内の最後尾の車両を車群から除外する
ことを特徴とする請求項２０に記載の車群管理方法。
【請求項２２】
各車両が送信する情報には、車群を構成する車両の識別子が含まれており、
メンバは、リーダから送信される情報の中に自車両の識別子と同一の識別子が複数含まれているときに、自車両の識別子を再設定する
ことを特徴とする請求項６〜２１のいずれかに記載の車群管理方法。
【請求項２３】
各車両が送信する情報には、車群を構成する車両の識別子が、ビット数を短縮化した形式で含まれており、
メンバは、リーダから送信される情報の中に、自車両のビット数を短縮化した形式の識別子と同一の識別子が含まれているときは、自車両の識別子を再設定する
ことを特徴とする請求項２２に記載の車群管理方法。
【請求項２４】
それぞれが車載無線端末を備える複数の車両から構成される隊列走行通信システムであって、
複数の車両のうちの１台の車両をリーダ、その他の車両をメンバとして車群を形成し、
リーダが、定期的に情報を送信し、
各メンバが、リーダから送信される情報に対して応答を返し、
リーダから送信される情報には、前サイクルにおける各メンバからの通信を受信できたか否かを示す受信情報が含まれ、
各メンバから送信される情報には、現サイクルにおけるリーダからの通信、および、前サイクルにおける他のメンバからの通信を受信できたか否かを示す受信情報が含まれ、
各車両は、他の車両から送信される情報に含まれる受信情報に基づいて、送達確認を行い、
前記送達確認によって通信の双方向性が確認された車両で車群を形成および維持する
ことを特徴とする隊列走行通信システム。
【請求項２５】
それぞれが車載無線端末を備える複数の車両から構成される車群の隊列走行通信システムであって、
前記車群中の１台の車両を、隊列走行の制御を行う制御リーダとし、
前記車群中の前記制御リーダを除いた車両のうち１台の車両を、前記制御リーダから送信される制御情報を前記車群中の他車両に転送する通信リーダとする、
ことを特徴とする隊列走行通信システム。
【請求項１】
双方向通信が可能な複数の車両から、１台の車両をリーダ、その他の車両をメンバとして車群を形成し、車群内の車両同士による通信を利用して隊列走行を行う隊列走行通信システムによる車群管理方法であって、
リーダが、定期的に情報を送信するステップと、
各メンバが、リーダから送信される情報に対して応答を返すステップと、
を含み、
リーダから送信される情報には、前サイクルにおける各メンバからの通信を受信できたか否かを示す受信情報が含まれ、
各メンバから送信される情報には、現サイクルにおけるリーダからの通信、および、前サイクルにおける他のメンバからの通信を受信できたか否かを示す受信情報が含まれ、
各車両は、他の車両から送信される情報に含まれる受信情報に基づいて、送達確認を行い、
前記送達確認によって通信の双方向性が確認された車両で車群を形成および維持する
ことを特徴とする車群管理方法。
【請求項２】
各車両が定期的に送信する情報には、当該車両の位置、車群を構成する車両の識別子、車群を構成する各車両に対する受信応答が含まれ、
各車両は、他の車両から送信される情報と、自車両が備えるセンサによって取得される情報とに基づいて、自律的に走行制御を行う
ことを特徴とする請求項１に記載の車群管理方法。
【請求項３】
車群を構成する車両が定期的に送信する情報には、さらに、車群を構成する車両の車群内の走行順序も含まれる
ことを特徴とする請求項２に記載の車群管理方法。
【請求項４】
車群を構成する車両が定期的に送信する情報には、車群を構成する車両の識別子が、車群内の走行順序にしたがって列挙されている
ことを特徴とする請求項３に記載の車群管理方法。
【請求項５】
車群の先頭に位置する車両は、車群外の前方の車両に対して追従する走行制御を行い、
車群の先頭車両とその前方の車両との間の車間距離は、車群内での車間距離よりも長い
ことを特徴とする請求項１〜４のいずれかに記載の車群管理方法。
【請求項６】
各車両が送信する情報には、少なくとも当該車両の位置が含まれており、
各車両が前方車両の位置を測定可能な測距手段を有しており、
車両から送信される情報に含まれる位置と、測距手段によって測定される前方車両の位置とが一致するかによって、車両が連続しているか否かを判断し、
前記送達確認により通信の双方向性が確認され、かつ、連続している車両で車群を形成および維持する
ことを特徴とする請求項１〜５のいずれかに記載の車群管理方法。
【請求項７】
リーダは、車群内の先頭車両である
ことを特徴とする請求項１〜６のいずれかに記載の車群管理方法。
【請求項８】
車群を構成する車両の台数に上限が設けられている
ことを特徴とする請求項６または７に記載の車群管理方法。
【請求項９】
車群を構成していない２台の車両の間で、通信の双方向性および連続性が確認された場
合は、当該２台の車両で車群を形成する
ことを特徴とする請求項６〜８のいずれかに記載の車群管理方法。
【請求項１０】
リーダは、車群内の先頭車両であり、
前記２台の車両のうち、前方車両がリーダとなり、後方車両がメンバとなる
ことを特徴とする請求項９に記載の車群管理方法。
【請求項１１】
車群を構成している複数の第１の車両と車群を構成していない第２の車両との間で、通信の双方向性が確認され、かつ、
前記第１の車両のいずれかと前記第２の車両とが連続している判断された場合に、
前記第２の車両を前記車群に合流させる
ことを特徴とする請求項６〜１０のいずれかに記載の車群管理方法。
【請求項１２】
リーダは、車群内の先頭車両であり、
前記車群内の最後尾車両と前記第２の車両とが連続していると判断された場合に、前記第２の車両を前記車群に合流させる
ことを特徴とする請求項１１に記載の車群管理方法。
【請求項１３】
第１の車群を構成している複数の第１の車両と第２の車群を構成している複数の第２の車両に関し、全ての車両間で通信の双方向性が確認され、かつ、前記第１の車両のいずれかと前記第２の車両のいずれかとが連続していると判断された場合に、
前記第１の車群と前記第２の車群を合流させる
ことを特徴とする請求項６〜１２のいずれかに記載の車群管理方法。
【請求項１４】
リーダは、車群内の先頭車両であり、
前記第１の車群の最後尾車両と前記第２の車両の先頭車両とが連続していると判断された場合に、前記第２の車群内の全ての車両を前記第１の車群のメンバとして合流させる
ことを特徴とする請求項１３に記載の車群管理方法。
【請求項１５】
車群内のいずれかの車両において、当該車両の前記測距手段によって測定される前方車両の位置が、他の車両から送信される情報に基づいて当該車両の２つ前の車両の位置と等しいと判断できる場合は、当該車両の前方に位置していた車両が車群から離脱したと判断し、この離脱した車両を車群から除く
ことを特徴とする請求項６〜１４のいずれかに記載の車群管理方法。
【請求項１６】
車群内のいずれかの車両が隊列走行を解除した場合には、当該車両より前方の車両からなる車群と、当該車両よりも後方の車両からなる車群との２つの車群に分離する
ことを特徴とする請求項６〜１５のいずれかに記載の車群管理方法。
【請求項１７】
車群内に他の車両と通信不可能な車両が現れた場合には、当該車両より前方の車両からなる車群と、当該車両よりも後方の車両からなる車群との２つの車群に分離する
ことを特徴とする請求項６〜１６のいずれかに記載の車群管理方法。
【請求項１８】
車群内に他の車両と通信不可能な車両が現れる場合とは、車群内に通信機能を有しない車両が割り込んだ場合であり、
車群内のいずれかの車両において、当該車両の測距手段によって測定される前方車両の位置が、他の車両から送信される情報から得られる車群内のいずれの車両の位置とも一致しない場合に、自車両の前方に通信機能を有しない車両が割り込んだと判断する
ことを特徴とする請求項１７に記載の車群管理方法。
【請求項１９】
車群内に他の車両と通信不可能な車両が現れる場合とは、車群内の車両の通信機能が停止した場合であり、
車群内の車両は、他の車両から送信される情報に含まれる受信情報に基づいて、車群内の車両の通信機能の停止を判断する
ことを特徴とする請求項１７に記載の車群管理方法。
【請求項２０】
車群内で同時多発的な通信途絶が発生した場合は、車群内のメンバを少なくとも１台車群から除外する
ことを特徴とする請求項６〜１９のいずれかに記載の車群管理方法。
【請求項２１】
リーダは、車群内の先頭車両であり、
車群内で同時多発的な通信途絶が発生した場合は、車群内の最後尾の車両を車群から除外する
ことを特徴とする請求項２０に記載の車群管理方法。
【請求項２２】
各車両が送信する情報には、車群を構成する車両の識別子が含まれており、
メンバは、リーダから送信される情報の中に自車両の識別子と同一の識別子が複数含まれているときに、自車両の識別子を再設定する
ことを特徴とする請求項６〜２１のいずれかに記載の車群管理方法。
【請求項２３】
各車両が送信する情報には、車群を構成する車両の識別子が、ビット数を短縮化した形式で含まれており、
メンバは、リーダから送信される情報の中に、自車両のビット数を短縮化した形式の識別子と同一の識別子が含まれているときは、自車両の識別子を再設定する
ことを特徴とする請求項２２に記載の車群管理方法。
【請求項２４】
それぞれが車載無線端末を備える複数の車両から構成される隊列走行通信システムであって、
複数の車両のうちの１台の車両をリーダ、その他の車両をメンバとして車群を形成し、
リーダが、定期的に情報を送信し、
各メンバが、リーダから送信される情報に対して応答を返し、
リーダから送信される情報には、前サイクルにおける各メンバからの通信を受信できたか否かを示す受信情報が含まれ、
各メンバから送信される情報には、現サイクルにおけるリーダからの通信、および、前サイクルにおける他のメンバからの通信を受信できたか否かを示す受信情報が含まれ、
各車両は、他の車両から送信される情報に含まれる受信情報に基づいて、送達確認を行い、
前記送達確認によって通信の双方向性が確認された車両で車群を形成および維持する
ことを特徴とする隊列走行通信システム。
【請求項２５】
それぞれが車載無線端末を備える複数の車両から構成される車群の隊列走行通信システムであって、
前記車群中の１台の車両を、隊列走行の制御を行う制御リーダとし、
前記車群中の前記制御リーダを除いた車両のうち１台の車両を、前記制御リーダから送信される制御情報を前記車群中の他車両に転送する通信リーダとする、
ことを特徴とする隊列走行通信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【公開番号】特開２０１１−２５００２１（Ｐ２０１１−２５００２１Ａ）
【公開日】平成２３年１２月８日（２０１１．１２．８）
【国際特許分類】
【出願番号】特願２０１０−１１９５８５（Ｐ２０１０−１１９５８５）
【出願日】平成２２年５月２５日（２０１０．５．２５）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２３年１２月８日（２０１１．１２．８）
【国際特許分類】
【出願日】平成２２年５月２５日（２０１０．５．２５）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]