WO2019172289A1

WO2019172289A1 - 隊列走行運用システムおよび隊列走行運用方法

Info

Publication number: WO2019172289A1
Application number: PCT/JP2019/008723
Authority: WO
Inventors: 恵小林; 康人畑福; 英樹久保; 元一岩崎; 葉子池田; 新輔井内; 潔竹本; かおり北見; 東　啓史; 達紀白石; 実千代佐藤; 賢綿引
Original assignee: 東芝デジタルソリューションズ株式会社
Priority date: 2018-03-08
Filing date: 2019-03-05
Publication date: 2019-09-12
Also published as: CN111819123A; CN111819123B; US20200402408A1; US11941991B2; EP3764333A1; EP3764333A4; JP2019159492A; JP7134649B2

Abstract

たとえば運転手に関する情報や車両に関する情報に基づき、隊列を適切に編成することができる隊列走行運用システムを提供する。　実施形態によれば、隊列走行運用システムは、複数の車両を連携させて隊列を編成する。隊列走行運用システムは、申請受付処理部と、隊列編成処理部とを具備する。申請受付処理部は、車両の隊列への編入の申請を受け付ける。隊列編成処理部は、前記車両を運転する運転手に関する情報または前記車両に関する情報の少なくとも一方に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する。

Description

隊列走行運用システムおよび隊列走行運用方法

　本発明の実施形態は、隊列走行運用システムおよび隊列走行運用方法に関する。

　近年、運転支援技術や自動運転技術などの進歩に伴い、複数の車両で隊列を組んで走行する隊列走行が注目を集めている。

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

　たとえば、先行する車両を追尾して自動走行する機能を有する車両であれば、ある車両によって誘導される隊列に加わることによって、当該隊列に加わった車両の運転手は、運転が不要となるため、たとえば車内で休憩を取ることなどが可能となる。

　しかしながら、他の車両と連携して走行する機能を有する車両同士であっても、無条件に連携させることは安全面などから現実的ではなく、適切な基準の下、隊列を適切に編成するための仕組みが求められる。

　本発明が解決しようとする課題は、たとえば運転手に関する情報や車両に関する情報に基づき、隊列を適切に編成することができる隊列走行運用システムおよび隊列走行運用方法を提供することである。

　実施形態によれば、隊列走行運用システムは、複数の車両を連携させて隊列を編成する。隊列走行運用システムは、申請受付処理部と、隊列編成処理部とを具備する。申請受付処理部は、車両の隊列への編入の申請を受け付ける。隊列編成処理部は、前記車両を運転する運転手に関する情報または前記車両に関する情報の少なくとも一方に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する。

第１実施形態の隊列走行運用システムの一形態例を示す図。第１実施形態の隊列走行運用システムによる隊列の編成の概要を説明するための図。第１実施形態のサービスセンタ（サーバ）の機能ブロック図。第１実施形態のサービスセンタ（サーバ）のハードウェア構成の一例を示す図。第１実施形態の隊列走行運用システムにおける申請情報の一例を示す図。第１実施形態の隊列走行運用システムにおける登録車両情報の一例を示す図。第１実施形態の隊列走行運用システムにおける登録運転手情報の一例を示す図。第１実施形態の隊列走行運用システムにおける隊列情報の一例を示す図。第１実施形態の隊列走行運用システムにおいて行われ得る隊列の再編成の一例を示す図。第１実施形態の隊列走行運用システム（サービスセンタ）において実行される隊列編成処理の流れを示すフローチャート。第１実施形態の隊列走行運用システム（サービスセンタ）において実行される運行監視（課金）処理の流れを示すフローチャート。第２実施形態の隊列走行運用システムの一形態例を示す図。第２実施形態の隊列走行運用システムによって実施される車両の隊列走行の概要を説明するための図。第２実施形態の隊列走行運用システムによって実施される車両の隊列走行の主たるユースケースを説明するための図。第２実施形態の隊列走行運用システムにおいて隊列を編成するために用いる各種情報（フラグ）を説明するための図。第２実施形態のサービスセンタ（サーバ）の機能ブロック図。第２実施形態のサービスセンタ（サーバ）のハードウェア構成の一例を示す図。第２実施形態の隊列走行運用システムにおける運行ダイヤ情報の一例を示す図。第２実施形態の隊列走行運用システムにおける申請情報の一例を示す図。第２実施形態の隊列走行運用システムにおける登録車両情報の一例を示す図。第２実施形態の隊列走行運用システムにおける登録運転手情報の一例を示す図。第２実施形態の隊列走行運用システムにおける隊列の編成規則を説明するための第１図。第２実施形態の隊列走行運用システムにおける隊列の編成規則を説明するための第２図。第２実施形態の隊列走行運用システムにおけるスケジュール情報の一例を示す図。第２実施形態の隊列走行運用システム（サービスセンタ）において実行される運行スケジュール作成処理の流れを示すフローチャート。第２実施形態の隊列走行運用システム（サービスセンタ）において実行される運行監視（課金）処理の流れを示すフローチャート。

　以下、実施形態について図面を参照して説明する。

　（第１実施形態）
　まず、第１実施形態について説明する。

　図１は、本実施形態の隊列走行運用システムの一形態例を示す図である。

　この隊列走行運用システムは、サービスセンタ１、より詳しくは、サービスセンタ１に設置されるたとえばサーバなどと称されるコンピュータによって一元的に管理されるシステムである。サーバは、プロセッサ（ＣＰＵ：Central Processing Unit）と、通信デバイスと、ストレージデバイスとを少なくとも備えるコンピュータであり、その構成については問わない。サーバとしてサービスセンタ１に設置されるコンピュータは、１台のコンピュータであってもよいし、たとえば負荷分散などのために協働する複数台のコンピュータであってもよい。サーバの概略的なハードウェア構成例については、図４を参照して後述する。

　サービスセンタ１は、たとえば高速道路などの隊列走行が可能な道路（以下、隊列走行可能道路Ｒと称する）であって、車両３を認識するための車両認識装置２がたとえば一定間隔で設けられる道路を走行する複数の車両３を連携させて隊列４を編成するサービスを提供する。サービスセンタ１は、車両３（より詳しくは、車両３に搭載され、または、車両３の運転手３Ａによって携行される通信機器）から、インターネットなどのネットワークＮ経由で、隊列４への編入を要求する申請を受け付ける。また、サービスセンタ１は、隊列走行可能道路Ｒに設けられる車両認識装置２から、隊列走行可能道路Ｒを走行する車両３に関する情報を受信する。この情報には、たとえば、車両３の識別情報、位置、進行方向などが含まれる。さらに、サービスセンタ１は、隊列４を誘導する車両３との間で、ネットワークＮ経由で、たとえば新たな車両３を連携させることを指示するなどのための通信を実行することができる。

　サービスセンタ１は、ある車両３から、隊列４への編入を要求する申請を受け付けた場合、その車両３を連携させる隊列４の有無を判定し、また、その車両３を連携させる隊列４の選定を行う。たとえば、図２に示されるように、隊列走行可能道路Ｒを走行する、隊列４への編入を申請した車両３の近傍を、複数の隊列４（隊列Ａ、隊列Ｂ）が走行する場合、サービスセンタ１は、その車両の各隊列４への連携可否を判定し、また、いずれの隊列４に連携させるべきかを判定する。サービスセンタ１は、いずれかの隊列４へ車両３を編入させることが可能であると判定した場合、隊列４への編入を申請する車両３と、この車両３が編入される隊列４を誘導する車両３との双方に、両者を連携させるための指示を送信する。このサービスセンタ１の制御下で、隊列４への編入を申請した車両３は、たとえば、隊列Ａへ編入し（図２：ａ１）、または、隊列Ｂへ編入する（図２：ａ２）。

　本実施形態の隊列走行運用システムは、サービスセンタ１が、隊列４への編入を申請する車両３を、その車両３に適した隊列４へ編入させるように、隊列４の編成に関する制御を行うものであり、また、この制御を、車両３に関する情報と、運転手３Ａに関する情報との少なくとも一方に基づいて行うものであり、以下、この点について詳述する。

　なお、ここでは、複数の車両３が連携して隊列４として走行するための手法については問わない。たとえば、隊列４を誘導する車両３と、この車両３に従属する車両３とが通信することで隊列走行が実現されてもよいし、従属する車両３が各種センサを用いて自律的に先行する車両３を追尾することで隊列走行が実現されてもよい。また、隊列４を誘導する車両３は、必ずしも、先頭を走行することに限られない。

　図３は、本実施形態のサービスセンタ（サーバ）１の機能ブロック図である。

　図３に示されるように、サービスセンタ１は、申請受付処理部１０１、隊列編成処理部１０２、車両位置検出処理部１０３および運行監視処理部１０４の各処理部と、申請情報ＤＢ（DataBase）１５１、基本情報ＤＢ１５２、隊列情報ＤＢ１５３および車両位置情報ＤＢの各データ部とを有する。また、運行監視処理部１０４は、課金管理部としても機能する。

　サービスセンタ１の処理には、大きく分けて、（１）車両３の隊列４への編入の申請を受け付け、隊列４を編成するフェーズと、（２）隊列４の走行状況を監視し、隊列４として走行した車両３に対する報奨金または課金の額を算出するフェーズと、の２つのフェーズが存在する。申請受付処理部１０１、隊列編成処理部１０２および車両位置検出処理部１０３は（１）に対応し、課金管理部としても機能する運行監視処理部１０４は（２）に対応する。

　前述したように、サーバは、プロセッサと、通信デバイスと、ストレージデバイスとを少なくとも備えるコンピュータである。各処理部は、ストレージデバイスに記憶されているプログラムがプロセッサによって実行されることによって構築される。また、各データ部は、ストレージデバイス上に構築される。図４に、サービスセンタ（サーバ）１のハードウェア構成の一例を示す。

　図４に示されるように、サービスセンタ（サーバ）１は、プロセッサ５１、主メモリ５２、外部記憶装置５３、通信装置５４、入力装置５５、表示装置５６などを備える。これらは、バス５７を介して相互に接続される。前述したように、隊列走行運用システムは、複数のコンピュータによって構築されてもよく、図４は、そのハードウェア構成例を概略的に示しているに過ぎない。

　ここでは、隊列走行運用システムは、外部記憶装置５３に格納される隊列走行運用プログラム１００が、当該外部記憶装置５３から主メモリ５２にロードされてプロセッサ５１によって実行されることによって、図３に示される各処理部が実現されるものとする。また、図３に示される各データ部は、外部記憶装置５３内に構築されるものとする。

　通信装置５４は、たとえば図１に示される車両認識装置２や車両３との間の通信を実行する装置である。入力装置５５は、隊列走行運用システムを管理するオペレータなどが指令を含む情報入力を行うための装置である。表示装置５６は、当該オペレータなどへ情報出力を行うための装置である。

　図３に戻って説明を続ける。

　申請受付処理部１０１は、車両３からの隊列４への編入の申請を受け付ける処理を実行する。図３に示されるように、申請項目には、「誘導／従属」（ｂ１）、「目的地」（ｂ２）、「車両情報（ＩＤ：Identification Data）」（ｂ３）、「運転手情報（ＩＤ＋体調データ）」（ｂ４）などが存在する。これらの申請項目は、車両３の運転手３Ａが音声によって入力できることが好ましい。換言すれば、車両３（より詳しくは、車両３に搭載され、または、車両３を運転する運転手３Ａによって携行される通信機器）は、これらの申請項目を音声によって入力して、サービスセンタ１へ送信する機能を備えることが好ましい。

　「誘導／従属」（ｂ１）は、他の車両３を誘導する車両３として隊列４への編入を申請するのか（「誘導」）、他の車両３に従属する車両３として隊列４への編入を申請するのか（「従属」）を指定するための項目である。「誘導」を指定した場合、その車両３の運転手３Ａは、隊列４を誘導するための要員として位置づけられる。たとえば隊列４の誘導時間や誘導距離などに応じて、その車両３（運転手３Ａ）は報奨金を得ることができる。これにより、この隊列走行運用システムは、隊列４を誘導するための要員としての運転手を確保し易くする。一方、「従属」を指定した場合、その車両３（運転手３Ａ）は、たとえば隊列４へ編入されていた時間や隊列４へ編入された状態で走行していた時間などに応じて課金されるものとする。

　「目的地」（ｂ２）は、隊列４として走行する隊列走行可能道路Ｒ上の目的地を指定するための項目である。ここで指定する目的地は、各々が目指す目的地と必ずしも一致させなくともよい。たとえば、各々が目指す目的地よりも手前の地点を指定してもよい。

　「車両情報（ＩＤ）」（ｂ３）は、たとえばサービスセンタ１へ車両３を登録した際に割り当てられた車両３の識別情報などを指定するための項目である。また、「運転手情報（ＩＤ＋体調データ）」（ｂ４）は、たとえばサービスセンタ１へ運転手３Ａを登録した際に割り当てられた運転手３Ａの識別情報などを指定するための項目である。つまり、この隊列走行運用システムにおいては、隊列４へ編入され得る車両３および当該車両３を運転し得る運転手３Ａについて、事前にサービスセンタ１に登録されていることを前提としている。

　また、「運転手情報（ＩＤ＋体調データ）」（ｂ４）は、たとえばアルコールの検出有無を示す情報などを含むことが好ましい。たとえば、車両３（より詳しくは、車両３に搭載され、または、車両３を運転する運転手３Ａによって携行される通信機器）は、図３に示される各申請項目を音声によって入力するにあたり、運転手３Ａの息からアルコールの検出を行い、その結果をサービスセンタ１へ送信する機能を有することが好ましい。そのほか、「運転手情報（ＩＤ＋体調データ）」（ｂ４）は、その車両３が走行を開始してからどの位の時間が経過しているのか、つまり、運転手３Ａの運転時間を示す情報などを含んでいてもよい。

　また、「車両情報（ＩＤ）」と「運転手情報（ＩＤ）」との一方または両方は、車両３（より詳しくは、車両３に搭載され、または、車両３を運転する運転手３Ａによって携行される通信機器）ごとに固定の値がサービスセンタ１に送信されてもよい。

　申請受付処理部１０１は、基本情報ＤＢ１５２を用いて、車両３から送信される上記申請項目の妥当性を判定し、妥当と判定した場合、当該申請項目を申請情報として纏めて申請情報ＤＢ１５１に格納する。図５に、申請情報ＤＢ１５１に格納される申請情報の一例を示す。申請受付処理部１０１は、申請ごとに受付番号（受付No.）を採番し、図５に示されるように、この受付番号順に、車両３から送信される上記申請項目を申請情報として纏めて申請情報ＤＢ１５１に格納する。なお、申請情報ＤＢ１５１に格納される申請情報には、「隊列編入状況」が含まれる。この「隊列編入状況」については後述する。

　基本情報ＤＢ１５２には、ステーション情報１５２Ａ、登録情報１５２Ｂ、登録運転手情報１５２Ｃが格納されている。ステーション情報１５２Ａは、目的地として指定することのできる地点に関する情報などを含み、申請受付処理部１０１は、たとえば、後述する車両位置検出処理部１０３によって検出される隊列４への編入を申請する車両３の位置とその進行方向とから目的地の指定が妥当か否かなどを判定する。申請項目が妥当ではないと判定した場合、申請受付処理部１０１は、エラーを車両３へ返信する。また、たとえば「誘導」が指定されている場合において、アルコールが検出されたことを示す「運転手情報（体調データ）」や、基準値を超える運転時間を示す「運転手情報（体調データ）」が送られてきた場合も、申請受付処理部１０１は、エラーを車両３へ返信する。

　図６に、登録車両情報１５２Ｂの一例を示し、図７に、登録運転手情報１５２Ｃの一例を示す。なお、登録車両情報１５２Ｂや登録運転手情報１５２Ｃを作成し、基本情報ＤＢ１５２へ格納する手法については、種々の手法が適用可能であり、特定の手法に限定されない。

　登録車両情報１５２Ｂは、たとえば図６に示されるように、車両３の識別情報［車両ＩＤ］と、複数の属性情報とを含む。複数の属性情報は、たとえば、重量、追越加速度、減速／ブレーキ制動力、タイヤの摩擦力など、様々な情報を含み得る。追越加速度は、停止状態からたとえば車両３の通常走行時の速度として想定される第１速度まで達する際の加速度ではなく、第１速度から当該第１速度で走行する他の車両３を追い越すために必要な第２速度まで達する際の加速度である。また、これらの属性情報を基に車両３の性能を評価した性能評価値も、複数の属性情報の中の１つとして含まれる。なお、車両３の性能を評価する手法については、種々の手法が適用可能であり、特定の手法に限定されない。

　また、複数の属性情報には、その車両３を運転するために必要な運転免許を示す情報が含まれ得る。さらに、複数の属性情報には、保険への加入有無を示す情報や、加入する保険の種類を示す情報などが含まれ得る。

　登録運転手情報１５２Ｃは、たとえば図７に示されように、運転手３Ａの識別情報［運転手ＩＤ］と、複数の属性情報とを含む。複数の属性情報には、少なくとも資格（（普通・中型・大型）自動車免許、牽引免許、フォークリフト運転者、玉掛作業者、移動式クレーン運転士や、各種危険物取扱者、各種高圧ガス製造保安責任者・充てん作業者など）に関する情報が含まれる。また、複数の属性情報は、たとえば、経験年数、隊列走行可能道路Ｒの区間ごとの隊列走行（誘導）回数、コミュニケーション能力に関する評価値など、様々な情報を含み得る。

　隊列編成処理部１０２は、申請情報ＤＢ１５１と、基本情報ＤＢ１５２とを用いて、隊列４を編成し、当該編成した隊列４に関する情報（隊列情報）を隊列情報ＤＢ１５３に格納する。

　隊列編成処理部１０２は、第１に、申請受付処理部１０１によって申請を受け付けられるごとに、隊列４を編成するための処理を実行する。換言すると、申請受付処理部１０１は、車両３からの申請を受け付けて、その申請が妥当であると判定し、申請情報を申請情報ＤＢ１５１に格納した場合、隊列編成処理部１０２への通知を実行する。隊列編成処理部１０２は、この通知を受けるごとに、隊列４を編成するための処理を実行する。

　ここで、申請受付処理部１０１によって「従属」が指定された申請が受け付けられた場合を想定する。この場合、隊列編成処理部１０２は、その車両３をいずれかの隊列４へ編入させるための処理を実行する。

　隊列編成処理部１０２は、隊列４への編入を申請する車両３の位置を車両位置検出処理部１０３から取得する。車両位置検出処理部１０３は、基本情報ＤＢ１５２に格納される登録車両情報１５２Ｂ中のたとえば識別情報などを隊列走行可能道路Ｒ上に点在して設けられるすべての車両認識装置２に通知し、事前に登録され、かつ、隊列走行可能道路Ｒを走行している車両３に関する情報を収集する。車両位置検出処理部１０３は、当該収集した情報を車両位置情報ＤＢ１５４へ格納する。車両位置検出処理部１０３は、隊列編成処理部１０２から指定された車両３の位置を車両位置情報ＤＢ１５４から読み出して、隊列編成処理部１０２へ送信する。

　隊列編成処理部１０２は、車両位置検出処理部１０３から取得した位置に基づき、隊列４への編入を申請する車両３を編入させる候補となり得る隊列４を隊列情報ＤＢ１５３から検索する。図８に、隊列情報ＤＢ１５３に格納される隊列４に関する情報（隊列情報）の一例を示す。

　図８に示されるように、隊列情報は、「隊列ＩＤ」、「目的地」、「現在地」、「編成車両数」、「誘導車両」、「従属車両」を各々示す情報を含む。また、「誘導車両」を示す情報は、「車両ＩＤ」、「運転手ＩＤ」、「誘導時間」を各々示す情報を含み、「従属車両」を示す情報は、「車両ＩＤ」、「運転手ＩＤ」、「従属時間」を各々示す情報を含む。

　隊列情報は、申請受付処理部１０１によって「誘導」が指定された申請が受け付けられたとき、隊列編成処理部１０２によって作成されて隊列情報ＤＢ１５３に格納される。隊列編成処理部１０２は、その申請ごとに隊列ＩＤを採番し、当該申請を行った車両３に関する情報のみを含む隊列情報を作成して隊列情報ＤＢ１５３に格納する。この時、この隊列情報の「編成車両数」は１を示し、また、「誘導車両」中の「車両ＩＤ」と「運転手ＩＤ」とは、その車両３の識別情報と当該車両３を運転する運転手３Ａの識別情報とを示している。

　隊列情報の「現在地」は、運行監視処理部１０４によって定期的に更新される。より詳しくは、運転監視処理部１０４は、隊列情報の「誘導車両」中の「車両ＩＤ」で示される車両３の位置を車両位置検出処理部１０３から定期的に取得し、当該取得した位置を示すように隊列情報の更新を定期的に実行する。隊列編成処理部１０２は、このように更新が行われる隊列情報ＤＢ１５３から、隊列４への編入を申請する車両３を編入させる候補となり得る隊列４を検索する。

　たとえば、隊列編成処理部１０２は、隊列４への編入を申請する車両３の近傍を走行する隊列であって、編成車両数が最大連携可能数に達していない隊列を検索する。少なくとも１つの隊列４が検索された場合、隊列編成処理部１０２は、隊列４への編入を申請する車両３および当該車両３を運転する運転手３Ａの情報と、隊列４を誘導する車両３および当該車両３を運転する運転手３Ａとの情報とに基づき、隊列４への編入を申請する車両３を、検索された隊列４へ編入させることが可能か否かを判定する。

　たとえば、隊列編成処理部１０２は、隊列４を誘導する車両３を運転するために必要な免許を、隊列４への編入を申請する車両３の運転手３Ａが保有しているか否かを調べることによって、当該隊列４への編入を申請する車両３を、隊列４へ編入することが可能か否かを判定してもよい。この判定により、たとえば、何らかの事情により、隊列４を誘導する車両３を交代させなければならない場合、ある運転免許が必要な車両３を、その運転免許を保有しない運転手３Ａが運転する車両３で誘導するといった状況を回避することができる。

　また、隊列編成処理部１０２は、たとえば、隊列４を誘導する車両３の保険への加入有無と、隊列４への編入を申請する車両３の保険への加入有無とが一致しているか否かを調べることによって、当該隊列４への編入を申請する車両３を、隊列４へ編入することが可能か否かを判定してもよい。この判定により、たとえば、隊列４が事故にあってしまった場合の対応の効率化を図ることができる。さらには、加入する保険の種類の一致不一致まで調べて、隊列４へ編入することが可能か否かを判定してもよい。

　また、隊列編成処理部１０２は、たとえば、隊列４を誘導する車両３の性能と、隊列４への編入を申請する車両３とが同一ランクか否かを調べることによって、当該隊列４への編入を申請する車両３を、隊列４へ編入することが可能か否かを判定してもよい。この判定により、たとえば、性能の高い方の車両３が、性能の低い方の車両３に合わせて走行しなければならないといった状況を回避することができる。

　そのほか、隊列編成処理部１０２は、車両３の情報と、運転手３Ａの情報との少なくとも一方を用いて、様々な基準で、隊列４への編入を申請する車両３を、隊列４へ編入することが可能か否かを判定することができる。

　隊列編成処理部１０２は、隊列４への編入を申請する車両３を、ある隊列４へ編入させることを決定した場合、隊列４への編入を申請する車両３と、当該車両３を編入させる隊列４を誘導する車両３とに対して、双方を連携させるための指示を送信する。そして、隊列編成処理部１０２は、その隊列情報ＤＢ１５３に格納される当該隊列４に関する隊列情報を更新する。より詳しくは、「編成車両数」を１つ増加させ、「従属車両」に新たに加わった車両３の情報を記録する（図８参照）。

　また、このとき、隊列編成処理部１０２は、申請情報ＤＢ１５１に格納される当該車両３に関する申請情報の更新も行う。より詳しくは、「隊列編入状況」を記録する（図５参照）。隊列編成処理部１０２は、目的地まで走行する隊列４であって、車両３を編入させることのできる隊列４が検索されたならば、その隊列４に編入することを決めて、その旨を「隊列編入状況」として記録する（１：目的地まで）。一方、目的地まで走行する隊列４であって、車両３を編入させることのできる隊列４は検索されなかったが、途中まで走行する隊列４が検索されたならば、隊列編成処理部１０２は、その隊列４に編入することを決めて、その旨を「隊列編入状況」として記録する（２：途中まで）。いずれの隊列４も検索されなかった場合、更新は行われず、「隊列編入状況」は、初期値（０：未編入）のままとなる。

　申請受付処理部１０１によって「誘導」が指定された申請が受け付けられた場合、隊列編成処理部１０２は、「隊列編入状況」が「０」または「２」の車両３を対象として、申請を行った車両３の近傍を走行し、かつ、この車両３に連携させることのできる車両３を検索することにより、隊列４の編成を試みる。「隊列編入状況」が「０」または「２」の車両３が走行している位置を、隊列編成処理部１０２は、車両位置検出処理部１０３から取得する。これにより、隊列編成処理部１０２は、たとえば、図９に示されるように、ある隊列４に「２：途中まで」の状態で編入する車両３を、その隊列４から離脱させ、新たに申請を行った目的地まで走行する別の車両３と連携させる（図９：ｃ１）といったことも行うことができる。

　また、隊列編成処理部１０２は、ある車両３に対して他の車両３を連携させた場合、その旨を運行監視処理部１０４へ通知する。この通知を受けた運行監視処理部１０４は、隊列情報ＤＢ１５３に格納されるその隊列４に関する「誘導車両」中の「誘導時間」と「従属車両」中の「従属時間」との計数を開始する。課金管理部１０４としても機能する運行監視処理部１０４は、これらの時間に基づき、隊列４を誘導する車両３を運転したことに対する報奨金や、隊列４に編入したことに対する課金の額を計算する。

　図１０は、この隊列走行運用システム（サービスセンタ１）において実行される隊列編成処理の流れを示すフローチャートである。

　サービスセンタ１は、まず、隊列４への編入を申請する車両３からの申請情報ＤＢ１５１に格納する（ステップＡ１）。サービスセンタ１は、その申請内容が「従属」の申請である場合（ステップＡ２：ＹＥＳ）、基本情報ＤＢ１５２に格納される登録車両情報１５２Ｂおよび登録運転手情報１５２Ｃと、隊列情報ＤＢ１５３に格納される隊列情報とに基づき、その車両３を連携させることのできる隊列４を検索する（ステップＡ３）。

　隊列４が検索された場合（ステップＡ４：ＹＥＳ）、サービスセンタ１は、その車両３を当該検索された隊列４に編入し（ステップＡ５）、当該隊列４に関して隊列情報ＤＢ１５３を更新するとともに（ステップＡ６）、当該車両３に関して申請情報ＤＢ１５１を更新する（ステップＡ７）。一方、隊列４が検索されない場合（ステップＡ４：ＮＯ）、サービスセンタ１は、この申請に起因する隊列編成処理を終了する。

　また、その申請内容が「誘導」の申請である場合（ステップＡ２：ＮＯ）、サービスセンタ１は、その車両３を誘導車両とする隊列４に関する隊列情報を隊列情報ＤＢ１５３に追加する（ステップＡ８）。そして、サービスセンタ１は、申請情報ＤＢ１５１に格納される申請情報と、基本情報ＤＢ１５２に格納される登録車両情報１５２Ｂおよび登録運転手情報１５２Ｃとに基づき、追加された隊列４に編入可能な車両３を検索する（ステップＡ９）。

　車両３が検索された場合（ステップＡ１０：ＹＥＳ）、サービスセンタ１は、その車両３を隊列４へ編入し（ステップＡ１１）、当該隊列４に関して隊列情報ＤＢ１５３を更新するとともに（ステップＡ１２）、当該車両３に関して申請情報ＤＢ１５１を更新する（ステップＡ１３）。一方、隊列４が検索されない場合（ステップＡ１０：ＮＯ）、サービスセンタ１は、この申請に起因する隊列編成処理を終了する。

　また、図１１は、この隊列走行運用システム（サービスセンタ１）において実行される運行監視（課金）処理の流れを示すフローチャートである。

　サービスセンタ１は、隊列４を誘導する車両３の誘導時間を計数するとともに（ステップＢ１）、隊列４に編入される車両３の従属時間を計数する（ステップＢ２）。そして、サービスセンタ１は、計数した誘導時間または従属時間に基づき、各車両３の報酬金または課金の額を算出する（ステップＢ３）。

　このように、本実施形態の隊列走行運用システムは、サービスセンタ１が、車両３に関する情報と、運転手３Ａに関する情報との少なくとも一方に基づいて、隊列４への編入を申請する車両３を、その車両３に適した隊列４へ編入させるように、隊列４の編成に関する制御を行う。

　つまり、本実施形態の隊列走行運用システムは、たとえば運転手に関する情報や車両に関する情報に基づき、隊列を適切に編成することができる。

　なお、以上の説明では、隊列４内の車両３には、運転手３Ａが乗車することを前提としているが、隊列４内の一部または全部の車両３が無人で自動運転される場合、車両３に関する情報のみに基づき、隊列４の編成に関する制御を行ってもよい。

　（第２実施形態）
　次に、第２実施形態について説明する。

　近年、ネット通販市場の拡大などに伴い、物流量は増加の一途を辿っている。一方、物流を担うトラックの運転手不足が深刻化している。そして、このような状況への対策案の１つとして、たとえば１台の有人トラックが複数台の無人トラックを誘導して走行する隊列走行が注目を集めている。

　仮に、複数の物流会社のトラックを混在させて隊列を編成するとした場合、たとえば隊列を誘導する車両の運転手の割り振りなどが考慮された隊列を適応的に編成するための基盤となるシステムが求められる。

　本実施形態は、たとえば隊列を誘導する車両の運転手の割り振りなどが考慮された隊列の適応的な編成が可能な隊列走行運用システムに関するものである。

　図１２は、本実施形態の隊列走行運用システムの一形態例を示す図である。

　この隊列走行運用システムは、サービスセンタ１－２、より詳しくは、サービスセンタ１－２に設置されるたとえばサーバなどと称されるコンピュータによって一元的に管理されるシステムである。サーバは、プロセッサ（ＣＰＵ）と、通信デバイスと、ストレージデバイスとを少なくとも備えるコンピュータであり、その構成については問わない。サーバとしてサービスセンタ１－２に設置されるコンピュータは、１台のコンピュータであってもよいし、たとえば負荷分散などのために協働する複数台のコンピュータであってもよい。サーバの概略的なハードウェア構成例については、図１７を参照して後述する。

　サービスセンタ１－２は、たとえば複数の物流会社の営業拠点２、より詳しくは、営業拠点２に設置されるたとえばＰＣ（Personal Computer）からインターネットなどのネットワークＮ経由で申請（申請情報）を受け付ける。申請情報は、目的のトラック（車両３）を、希望日時、希望区間などを指定して隊列４に編入させるための情報である。営業拠点２の社員などである申請者は、たとえばサービスセンタ１－２がネットワークＮ上で公開するＷｅｂページにアクセスして申請画面をＰＣ上に表示させ、この申請画面上で必要事項を入力することによって申請情報を作成し、サービスセンタ１－２へ送信する。申請情報を作成するための機器は、ＰＣに限らず、ネットワークＮ上で公開されるＷｅｂページにアクセスする機能を有する機器であればよく、たとえばスマートフォンなどであってもよい。また、図１２においては、サービスセンタ１－２が、物流会社の営業拠点２との間で通信を行う様子を示しているが、申請者は、営業拠点６の社員などに限らず、個人であってもよい。さらには、隊列４に編入させる車両３は、物流会社のトラックに限らず、たとえば個人の自家用車であってもよい。

　また、サービスセンタ１－２は、たとえば、隊列４に編入前の車両３または隊列４に編入後の当該隊列４を誘導する車両３、より詳しくは、これらの車両３の運転手３Ａが携行する通信機器と、ネットワークＮを介して通信することができる。この通信によって、サービスセンタ１は、たとえば隊列４がどの車両３（運転手３Ａ）によって誘導されているのかといった情報を取得することができる。

　この隊列走行運用システムは、運転手３Ａに関する運転手情報（後述する運転手フラグ）と、車両３に関する車両情報（後述する車両フラグ）と、隊列４に関する隊列情報（隊列フラグ）とを用いて、たとえば隊列４を誘導する車両３の運転手３Ａの割り振りなどが考慮された隊列４の適応的な編成を可能としたものであり、以下、これらの情報の一適用例について詳述する。

　図１３は、この隊列走行運用システムによって実施される車両の隊列走行の概要を説明するための図である。

　ここでは、たとえば高速道路などを隊列走行が行える道路であるものと想定し、隊列走行可能道路１０と称する。また、たとえば一般道路などを隊列走行が行えない道路であるものと想定し、非隊列走行可能道路２０と称する。

　さらに、隊列走行可能道路１０上には、隊列４を組んだり解いたりするための複数のステーション１１が設けられているものと想定する。ステーション１１は、たとえば隊列走行可能道路１０の出入口であるインターチェンジ近傍に設けられる。

　この隊列走行運用システムは、共通する２つのステーション１１間を走行する車両３を連携させて隊列４を編成する。隊列４への編入が予定される車両３は、出発拠点のステーション１１まで非隊列走行可能道路２０を走行する。つまり、隊列４へ編入するまでの車両３には、各々運転手３Ａが乗車している。以下、出発拠点のステーション１１を出発ステーション１１と称し、到着拠点のステーション１１を到着ステーション１１と称することがある。

　また、この隊列走行運用システムにおいては、隊列４へ編入する車両３および運転手３Ａは、あらかじめサービスセンタ１へ登録されているものと想定する。車両を登録する際の情報には、性能を判定するための情報が含まれている。図１３中、「Ａ」、「Ｂ」、「Ｃ」は、車両３の性能を表している。この隊列走行運用システムでは、隊列４へ編入する車両３を性能別にたとえば「Ａ：高性能」、「Ｂ：中性能」、「Ｃ：低性能」の３段階でグループ化し、グループごとに隊列を編成する。これにより、隊列４内での車両３間の性能のばらつきを抑えて、たとえば高性能の車両３の走行を低性能の車両３に合わせるといった無駄をなくし、効率的かつ安定した隊列走行を実現する。車両の性能を評価する手法については、種々の手法が適用可能であり、特定の手法に限定されない。

　隊列４は、隊列４を誘導する１台の車両３と、この車両３に従属する１台以上の車両３とで編成される。ここで、隊列４を誘導する車両３は、運転手が運転する有人の車両であり、一方、従属する車両３は、先行する車両に追従するように自動運転される無人の車両である。従属する車両３の自動運転については、誘導する車両３や先行する車両３と通信しながら行われるものであってもよいし、各種センサによって自律的に行われるものであってもよい。複数の車両３を連携させて隊列走行させる手法については、種々の手法が適用可能であり、特定の手法に限定されない。また、ここでは、隊列４への編入が可能な車両３は、他の車両３と連携する機能を搭載し、隊列４を誘導する車両３になり得るし、従属する車両にもなり得ることを前提としている。

　隊列４を誘導する車両３は、基本的には、非隊列走行可能道路２０上を、隊列４へ編入させる車両３をステーション１１まで運転する運転手３Ａの中の一部の運転手３Ａによって運転される。より詳しくは、隊列４に編入後も車両３に乗車する運転手３Ａによって運転される（当該運転手３Ａの運転する車両３が隊列４を誘導する車両３となる）。隊列４に編入後の車両３には乗車しない運転手３Ａは、たとえば、そのステーション１１を到着拠点として隊列４から解かれた自社の車両３を運転して目的地へ向かってもよいし、自社のバスなどによって会社へ戻ってもよい。ステーション１１で車両３を離れる運転手３Ａについては、ここでは、特に拘らない。隊列４を誘導する車両３は、例外的に、サービスセンタ１によって手配された運転手３Ｂ（車両３の運転手３Ａと区別するために、運転手３Ｂと称する）によって運転される。運転手３Ｂが手配される場合とは、隊列４に編入後も車両３に乗車する運転手３Ａの数が、隊列４を誘導するための要員の必要数に満たない場合である。

　また、この隊列走行運用システムでは、隊列４に編入後も車両３に乗車する、隊列４を誘導するための要員としての役割を担う運転手３Ａに対し、到着拠点のステーション１１で隊列４が解かれた後、出発拠点のステーション１１へ戻る手段を手当てする。もちろん、到着拠点のステーション１１で隊列４が解かれた後、そのまま目的地へ向かって非隊列走行可能道路２０を走行してもよい。出発拠点のステーション１１へ戻るケースとしては、たとえば到着拠点のステーション１１周辺を担当エリアとする自社内の他の運転手へ車両３を引き継ぐケースなどが考えられる。自社内の他の運転手とは、たとえば、前述した、出発拠点のステーション１１（引き継ぐ側の運転手３Ａから見ると、到着拠点のステーション１１）まで車両３を運転し、隊列４に編入後は車両３には乗車せず、そのステーション１１を到着拠点として隊列４から解かれた自社の車両３を運転して目的地へ向かう運転手などである。視点を変えると、隊列走行可能道路１０上の出発拠点のステーション１１から到着拠点のステーション１１まで車両３に乗車する運転手は、たとえば出発拠点のステーション１１周辺を担当エリアとする運転手であり、出発拠点のステーション１１周辺の非隊列走行可能道路２０と隊列走行可能道路１０とのみを運転すればよく、担当エリア外の到着拠点のステーション１１周辺の非隊列走行可能道路２０を運転する必要がない。

　この隊列走行運用システムにおいては、出発拠点のステーション１１から到着拠点のステーション１１まで戻ることを希望する運転手が存在する場合、その運転手を運ぶための人員輸送専用車両（たとえばバスなど）５を用意する。換言すれば、サービスセンタ１－２は、人員輸送専用車両５の手配を行う。出発拠点のステーション１１から到着拠点のステーション１１まで戻ることを希望する運転手３Ａとは、隊列４が出発拠点のステーション１１を出発する前までに、同区間を逆方向から走行してきて出発拠点のステーション１１へ到着した隊列４に編入されていた車両３に乗車していた運転手３Ａである。

　隊列４が到着拠点のステーション１１へ到着すると、隊列４が解かれ、車両３は、各々非隊列走行可能道路２０経由で目的地へ向かうことになる。隊列４が解かれた後の車両３の運転手については、ここでは、特に拘らない。たとえば隊列４に編入後も運転手が乗車する車両３については、その運転手が引き続き運転してもよいし、隊列４に編入後は運転手が乗車しない車両３や、隊列４に編入後も運転手が乗車したが隊列４が解かれた後に出発拠点のステーション１１へ運転手が戻る車両３については、そのステーション１１周辺を担当エリアとする自社内の他の運転手などが引き継いでもよい。

　次に、図１４を参照して、この隊列走行運用システムによって実施される車両の隊列走行の主たるユースケースについて説明する。

　図１４に示されるように、この隊列走行運用システムによって実施される車両の隊列走行は、大きく分けて、３つのユースケースが考えられる。

　（Ａ）は、第１ユースケースを示している。

　第１ユースケースは、出発拠点のステーション１１まで車両３を運転する運転手３Ａが隊列４への編入後も車両３に乗車し、到着拠点のステーション１１で隊列４が解かれた後も引き続き車両３を運転して目的地へ向かうケースである。なお、前述したように、隊列４への編入後も車両３に乗車する運転手は、隊列４を誘導するための要員としての役割を担う。

　また、（Ｂ）は、第２ユースケースを示している。

　第２ユースケースは、出発拠点のステーション１１まで車両３を運転する運転手３Ａが隊列４への編入後は車両３に乗車しないケースである。つまり、無人の車両３を到着拠点のステーション１１まで他の車両３に誘導してもらうケースである。到着拠点のステーション１１に到着して隊列４から解かれた車両３は、たとえば、前述したように、そのステーション１１周辺を担当エリアとする自社内の他の運転手などによって目的地まで運転される。なお、第２ユースケースにおける無人の車両３は、他者が運転手となって隊列４を誘導する車両３として利用され得るものとする。

　そして、（Ｃ）は、第３ユースケースを示している。

　第３ユースケースは、出発拠点のステーション１１まで車両３を運転する運転手３Ａが隊列４への編入後も車両３に乗車し、到着拠点のステーション１１で隊列４が解かれた後は、同区間を逆方向へ走行する隊列４へ編入される人員輸送専用車両５に乗車して、出発拠点のステーション１１へ戻るケースである。この第３ユースケースの場合も、第２ユースケースと同様、そのステーション１１周辺を担当エリアとする自社内の他の運転手などによって目的地まで運転される。

　ここで、たとえば出発拠点のステーション１１周辺が担当エリアの運転手３Ａが、担当エリア外の到着拠点のステーション１１周辺の非隊列走行可能道路２０を運転する必要がないユースケースとして、第２ユースケースに加えて、隊列４に編入後の車両３に運転手３Ａが乗車する第３ユースケースを設ける理由について説明する。また、運転手３Ａが、出発拠点のステーション１１から到着拠点のステーション１１まで単独で車両３を運転するのではなく、隊列４を誘導し得ることとなる第１ユースケースを設ける理由についても併せて説明する。

　第１は、複数の物流会社間で、運転手不足の問題に対応するために協力し合うという観点から第１および第３ユースケースが設けられる。また、第２に、運転手を確保し易くするという観点から第１および第３ユースケースが設けられる。より詳しくは、出発拠点のステーション１１から到着拠点のステーション１１まで車両３を預けるだけの第２ユースケースの場合は料金が徴収されるのに対して、第１および第３ユースケースの場合、その車両の運転手３Ａが隊列４を誘導するための要員として位置づけられることへの対価を得られるものとする。第１ユースケースまたは第３ユースケースにおける対価は、隊列走行時の運転有無や運転時間に応じて算出されることが好ましい。

　次に、図１５を参照して、上記第１乃至第３ユースケースが混在する本実施形態の隊列走行運用システムにおいて隊列４を編成するために用いる各種情報（フラグ）について説明する。

　この隊列走行運用システムは、（Ａ）運転手３Ａに関する運転手情報である運転手フラグと、（Ｂ）車両３に関する車両情報である車両フラグと、（Ｃ）隊列４に関する隊列情報である隊列フラグとを用いる。

　運転手フラグには、運転手フラグ（１）と運転手フラグ（２）との２種類が存在し、運転手フラグ（１）は、車両３の隊列４への編入時、車両３に乗車するか否かを示す。運転手フラグ（２）は、隊列走行時、隊列４を誘導する車両３の運転手として運転中か否かを示す。運転手フラグ（１）の値（オン［乗車］、オフ［非乗車］）は申請時に定まり、運転手フラグ（２）の値（オン［運転中］、オフ［非運転中］）は隊列４の走行状況に応じて定まる。運転手フラグ（１）は、後述する申請情報ＤＢ１５１に格納される申請情報に含まれる。運転手フラグ（２）は、後述するスケジュールＤＢ１５３に格納される隊列編成情報１５３Ａに含まれる。

　車両フラグは、車両３の性能を示す。車両フラグの値（Ａ、Ｂ、Ｃ）は、車両３の登録時に定まる。車両フラグは、後述する基本情報ＤＢ１５２に格納される登録車両情報１５２Ｂに含まれる。

　隊列フラグには、隊列フラグ（１）と隊列フラグ（２）との２種類が存在し、隊列フラグ（１）は、人員輸送専用車両５が連携されるか否かを示す。隊列フラグ（２）は、隊列４を誘導するための要員としての運転手の手配が必要か否かを示す。隊列フラグ（１）の値（オン［人員輸送専用車両５連携］、オフ［人員輸送専用車両５非連携］）は、隊列４の編成時に定まり、また、隊列フラグ（２）の値（オン［運転手手配要］、オフ［運転手手配不要］）も、隊列４の編成時に定まる。隊列フラグ（１）と隊列フラグ（２）とは、後述するスケジュールＤＢ１５３に格納される隊列編成情報１５３Ａに含まれる。

　図１６は、本実施形態のサービスセンタ（サーバ）１－２の機能ブロック図である。

　図５に示されるように、サービスセンタ１－２は、申請受付処理部１２１、隊列編成処理部１２２、運転手手配処理部１２３、人員輸送専用車両手配処理部１２４および運行監視処理部１２５の各処理部と、申請情報ＤＢ１７１、基本情報ＤＢ１７２およびスケジュールＤＢ１７３の各データ部とを有する。隊列編成処理部１２２、運転手手配処理部１２３および人員輸送専用車両手配処理部１２４は、運行スケジュール作成処理部１３０を構成する。また、運行監視処理部１２５は、課金管理部としても機能する。

　サービスセンタ１－２の処理には、大きく分けて、（１）車両３の隊列４への編入の申請を受け付けるフェーズ、（２）隊列４を編成するフェーズ、（３）隊列４の走行状況を監視するフェーズ、（４）隊列４として走行した車両３に対して課金するフェーズ、の４つのフェーズが存在する。申請受付処理部１２１は（１）に対応し、運行スケジュール作成処理部１３０を構成する隊列編成処理部１２２、運転手手配処理部１２３および人員輸送専用車両手配処理部１２４は（２）に対応する。また、課金管理部としても機能する運行監視処理部１２５は（３）および（４）に対応する。

　前述したように、サーバは、プロセッサと、通信デバイスと、ストレージデバイスとを少なくとも備えるコンピュータである。各処理部は、ストレージデバイスに記憶されているプログラムがプロセッサによって実行されることによって構築される。また、各データ部は、ストレージデバイス上に構築される。図１７に、サービスセンタ（サーバ）１－２のハードウェア構成の一例を示す。

　図１７に示されるように、サービスセンタ（サーバ）１－２は、プロセッサ７１、主メモリ７２、外部記憶装置７３、通信装置７４、入力装置７５、表示装置７６などを備える。これらは、バス７７を介して相互に接続される。前述したように、隊列走行運用システムは、複数のコンピュータによって構築されてもよく、図１７は、そのハードウェア構成例を概略的に示しているに過ぎない。

　ここでは、隊列走行運用システムは、外部記憶装置５３に格納される隊列走行運用プログラム１００－２が、当該外部記憶装置７３から主メモリ７２にロードされてプロセッサ７１によって実行されることによって、図１６に示される各処理部が実現されるものとする。また、図１６に示される各データ部は、外部記憶装置７３内に構築されるものとする。

　通信装置７４は、たとえば図１２に示される営業拠点２や車両３との間の通信を実行する装置である。入力装置７５は、隊列走行運用システムを管理するオペレータなどが指令を含む情報入力を行うための装置である。表示装置７６は、当該オペレータなどへ情報出力を行うための装置である。

　図１６に戻って説明を続ける。

　申請受付処理部１２１は、たとえば物流会社の営業拠点２などから申請情報を受け付ける処理を実行する。申請受付処理部１２１は、サービスセンタ１へアクセスしてきた営業拠点２のＰＣなどに申請画面２１を表示させるための情報、たとえばＨＴＭＬ（HyperText Markup Language）ファイルを送信する。図１６に示されるように、申請画面２１上の入力項目には、日付（ｄ１）、出発ステーション［発Ｓ］（ｄ２）、到着ステーション［着Ｓ］（ｄ３）、出発または到着の時刻（ｄ４）、隊列走行時の乗車有無（ｄ５）、隊列走行時に乗車する場合における出発ステーションへの帰還希望有無（ｄ６）、隊列４へ編入させる車両３の識別子［車両ＩＤ］（ｄ７）、車両３の運転手３Ａの識別子［運転手ＩＤ］（ｄ８）などが存在する。符号ｄ４で示される、出発または到着の時刻の入力項目は、入力対象が出発時刻であるのか到着時刻であるのかを申請者が切り換え可能であることが好ましい。

　なお、符号ｄ５で示される、隊列走行時の乗車有無の入力項目は、隊列４に編入後の車両３に運転手３Ａが乗車する場合においても乗車無と入力することが可能である。この場合、前述の第２ユースケース（図１４（Ｂ）参照）として扱われ、運転手３Ａは、隊列４を誘導するための要員としては位置づけられなくなる。つまり、たとえば隊列走行時に車両３内で休憩したいといったニーズに応えることができる。

　出発ステーションと到着ステーションとが一致し、かつ、出発または到着の希望時刻が一定の範囲内にある車両３同士を連携させて隊列４を編成することも実現し得るが、この隊列走行運用システムでは、隊列走行可能道路１０を走行させる隊列４のタイムスケジュールがあらかじめ定められているものと想定する。より詳しくは、ステーション１１ごとに、隊列４の出発時刻と、他のステーション１１への到着時刻とが、隊列走行可能道路１０の両方向（上り方面、下り方面）についてあらかじめ定められているものと想定する。このステーション１１ごとの情報は、運行ダイヤ情報１７２Ａとして基本情報ＤＢ１７２に格納されている。図１８に、運行ダイヤ情報１７２Ａの一例を示す。

　運行ダイヤ情報１７２Ａは、ステーション１１ごとに設けられる情報であって、図１８に示されるように、隊列走行可能道路１０の両方向（上り方面、下り方面）について、出発時刻と、他のステーション１１への到着時刻とが示される。

　この運行ダイヤ情報１７２Ａによって、申請受付処理部１２１は、出発ステーションと到着ステーションとが指定されれば、出発時刻または到着時刻の一方の指定のみで、出発時刻または到着時刻の他方を得ることができる。申請画面２１上で入力され、営業拠点６のＰＣなどからサービスセンタ１－２へ送信されてくる情報を、申請受付処理部１２１は、申請情報として申請情報ＤＢ１７１に格納する。図１９に、申請情報ＤＢ１７１に格納される申請情報の一例を示す。

　申請受付処理部１２１は、申請ごとに受付番号（受付No.）を採番し、図１９に示されるように、たとえば、日付ごとに、この受付番号順に、申請画面２１上で入力された情報を申請情報として申請情報ＤＢ１７１に格納する。申請情報に含まれる情報のうち、隊列走行時の乗車有無に関する情報が、運転手フラグ（１）の値となる。つまり、申請受付処理部１２１は、隊列走行時の乗車有として申請が行われた場合、申請情報内の運転手フラグ（１）をオンにし、隊列走行時の乗車無として申請が行われた場合には、申請情報内の運転手フラグ（１）をオフにする。

　基本情報ＤＢ１７２には、運行ダイヤ情報１７２Ａのほか、登録車両情報１７２Ｂと登録運転手情報１７２Ｃとが格納される。なお、登録車両情報１７２Ｂや登録運転手情報１７２Ｃを作成し、基本情報ＤＢ１７２へ格納する手法については、種々の手法が適用可能であり、特定の手法に限定されない。図２０に、登録車両情報１７２Ｂの一例を示し、図２１に、登録運転手情報１７２Ｃの一例を示す。

　登録車両情報１７２Ｂは、たとえば図２０に示すように、車両３の識別子［車両ＩＤ］と複数の属性情報とを含む。複数の属性情報は、たとえば、重量、追越加速度、減速／ブレーキ制動力、タイヤの摩擦力など、様々な情報を含み得る。追越加速度は、停止状態からたとえば車両３の通常走行時の速度として想定される第１速度まで達する際の加速度ではなく、この第１速度から当該第１速度で走行する他の車両３を追い越すために必要な第２速度まで達する際の加速度である。また、登録車両情報１７２Ｂは、これらの属性情報を基に車両３の性能を評価した性能評価値を含む。登録車両情報１７２Ｂに含まれる情報のうち、この性能評価値が、車両フラグの値となる。

　登録運転手情報１７２Ｃは、たとえば図２１に示すように、運転手３Ａの識別子［運転手ＩＤ］と複数の属性情報とを含む。複数の属性情報は、たとえば、経験年数、隊列走行可能道路１０の区間ごとの隊列走行（誘導）回数、コミュニケーション能力に関する評価値など、様々な情報を含み得る。登録運転手情報１５２Ｃは、たとえば、隊列４への編入後も車両３に乗車する運転手３Ａが必要数を超えて存在する場合に、その中から隊列４を誘導するための要員としての運転手３Ａを選出するための情報などとして用いられる。

　隊列編成処理部１２２は、申請情報ＤＢ１７１に格納されている申請情報と、基本情報ＤＢ１７２に格納されている運行ダイヤ情報１７２Ａ、登録車両情報１７２Ｂおよび登録運転手情報１７２Ｃとを用いて隊列４を編成し、隊列４の編成に関する情報である隊列編成情報１７３Ａを作成してスケジュールＤＢ１７３に格納する。なお、隊列編成情報１７３Ａは、隊列４へ編入した車両３に対する課金額を算出する際に、たとえば運転手３Ａによる隊列４の誘導有無（運転有無）や誘導時間（運転時間）などを示す実績情報として用いられる。

　たとえば、サービスセンタ１－２は、申請を２４時間受け付けるが、各日分の申請を当日の所定の時刻で締め切るものと想定する。この場合、隊列編成処理部１０２は、当該所定の時刻の経過後、申請情報ＤＢ１７１に格納される当日分の申請情報を用いた当日分の隊列編成情報１７３Ａを作成する処理を日次処理として実行する。

　隊列編成処理部１２２は、まず、隊列走行可能道路１０上の２つのステーション１１の全通りの組み合わせ（方向も考慮）について、出発時刻、性能ごとに、隊列４への編入を申請する車両３をグループ化する。そして、隊列編成処理部１２２は、作成したグループごとに、車両３の数を集計する。つまり、隊列編成処理部１２２は、区間、出発時刻、性能ごとに、車両３の数を集計する。この時、登録車両情報１７２Ｂに含まれる車両フラグが用いられる。なお、作成したグループに関する情報は、サービスセンタ（サーバ）１－２のストレージデバイス上に中間成果物として一時的に記憶される。この情報には、グループに属する車両３の識別子が含まれている。

　また、隊列編成処理部１２２は、区間、到着時刻ごとに、出発ステーション１１への帰還希望者数を集計する。より詳しくは、帰還希望者の有無を判定する。帰還希望者が存在する場合、隊列編成処理部１２２は、当該区間と逆の区間かつ当該到着時刻から一定期間経過後の直近の出発時刻に、人員輸送専用車両５を割り当てる。この人員輸送専用車両５の割り当てのための処理と、車両３の数の集計のための処理とは、並列的に行ってもよいし、逐次的に行ってもよい。また、逐次駅に行う場合には、どちらを先に行ってもよい。

　続いて、隊列編成処理部１２２は、車両３の数の集計結果と、人員輸送専用車両５の要否の判定結果とに基づき、区間、出発時刻、性能ごとに、隊列４を編成する。図２２および図２３を参照して、隊列編成処理部１２２による隊列４の編成規則について説明する。

　いま、隊列４として連携して走行することのできる車両３の最大数が５台であるものと想定する。また、ある区間をある時間に出発するある性能の車両３が、図２２（Ａ）に示されるように、１８台存在するものと想定する。つまり、あるグループに属する車両３の数が１８台である場合を想定する。

　図２２中、符号３－１は、申請情報に含まれる隊列走行時の乗車有無に関する情報が乗車有である車両３、つまり運転手フラグ（１）がオンである車両３を示す。一方、符号３－２は、申請情報に含まれる隊列走行時の乗車有無に関する情報が乗車無である車両３、つまり運転手フラグ（１）がオフである車両３を示す。ここでは、３台の車両３の運転手３Ａが、隊列４への編入後も車両３に乗車するものと想定する。

　隊列編成処理部１２２は、グループに属する車両３の数を、隊列４として連携して走行することのできる車両３の最大数で除することで、そのグループ内で編成すべき隊列４の数を求める。ここでは、１８÷５＝３．６から、４つの隊列４（４－１～４）を編成すべきことが求まる。

　編成すべき隊列４の数を求めると、隊列編成処理部１２２は、図２２（Ｂ）に示されるように、運転手フラグ（１）がオンである車両３を均等に隊列４へ割り振り、次に、運転手フラグ（１）がオフである車両３を割り振っていく。また、この時、隊列編成処理部１０２は、隊列４ごとに識別子（隊列ＩＤ）を採番する。ここで、隊列４の数である４に対して、運転手フラグ（１）がオンである車両３の数が３と満たないため、運転手３Ａが不在の隊列４が１つ生じる。この場合、隊列編成処理部１２２は、運転手３Ａが不在の隊列４（４－４）について、運転手の手配が必要であることを示すように、隊列フラグ（２）をオンにする。隊列フラグ（２）をオンにするとは、スケジュールＤＢ１７３に格納する隊列編成情報１７３Ａ内の当該隊列４に関する情報を、運転手３Ａの手配が必要であることを示すように設定することである。

　なお、説明を簡単にするために、隊列４を誘導する要員としての運転手３Ａの必要数については触れなかったが、隊列４によっては、１人の運転手３Ａが連続して運転可能な時間を当該隊列４の走行予定時間が上回る場合も考えられ得る。つまり、隊列４の走行予定時間を、１人の運転手３Ａによる連続運転可能時間で除することで、隊列４を誘導する要員としての運転手３Ａの必要数を求めることができる。運転手フラグ（１）がオンである車両３を均等に隊列４へ割り振った結果、運転手３Ａの必要数に満たない隊列４が生じたならば、隊列編成処理部１２２は、その隊列４について、運転手３Ｂの手配が必要であることを示すように、隊列フラグ（２）をオンにする。隊列フラグ（２）は、さらに、運転手３Ｂの必要数を示してもよい。

　逆に、運転手フラグ（１）がオンである車両３の数が、運転手３Ａの必要数を上回る場合も考えられ得る。このような場合、隊列編成処理部１２２は、登録運転手情報１７２Ｃに含まれる運転手３Ａの属性情報に基づき、隊列４の走行区間における各運転手３Ａの適性度を算出して順位づけし、その順位づけにしたがって、適性度の高い運転手３Ａを均等に隊列４に割り振ることが好ましい。より詳しくは、適性度の高い運転手３Ａを、隊列４を誘導する要員として選出することが好ましい。

　一方、図２３は、人員輸送専用車両５の連携有無を示す隊列フラグ（１）をオン［人員輸送専用車両５連携］とするケースを説明するための図である。ある区間のある出発時刻について、人員輸送専用車両５が必要と判定した場合、隊列編成処理部１２２は、その区間および出発時刻に対応して作成されたグループの中で連携数が最大数に達しない隊列４が生じるグループに人員輸送専用車両５を加える。つまり、ここでは、人員輸送専用車両５の性能は、「Ａ：高性能」であり、性能別にグループ化されたいずれのグループにも連携し得ることを想定している。

　いま、図２３（Ａ）に示されるように、人員輸送専用車両５が加えられたあるグループが存在するものとする。また、ここでは、運転手フラグ（１）がオンである車両３の数が隊列４の数を上回っているものとする。より詳しくは、運転手３Ａが不在の隊列４は生じないものとする。

　隊列編成処理部１２２は、前述したように、まず、運転手フラグ（１）がオンである車両３を均等に隊列４へ割り振る。次に、隊列編成処理部１２２は、図２３（Ｂ）に示されるように、運転手フラグ（１）がオフである車両３と人員輸送専用車両５とを割り振っていく。なお、図２３（Ｂ）には、運転手フラグ（１）がオフである車両３を割り振り、その後に、人員輸送専用車両５を割り振る例を示しているが、人員輸送専用車両５を先に割り振るようにしてもよい。さらに言えば、運転手フラグ（１）がオフである車両３と人員輸送専用車両５とを何ら区別する必要がない。

　ここでは、運転手３Ａが不在の隊列４は生じないので、いずれの隊列４についても、隊列フラグ（２）がオンになることはない。その一方で、人員輸送専用車両５が割り振られた隊列４（４－３）については、隊列編成処理部１０２は、人員輸送専用車両５を連携させることを示すように、隊列フラグ（１）をオンにする。隊列フラグ（１）をオンにするとは、スケジュールＤＢ１７３に格納する隊列編成情報１７３Ａ内の当該隊列４に関する情報を、人員輸送専用車両５を連携させることを示すように設定することである。

　なお、説明を簡単にするために、人員輸送専用車両５の必要数については触れなかったが、出発ステーション１１への帰還希望者数が人員輸送専用車両５の定員数を上回っている場合、複数の人員輸送専用車両５が必要となる。人員輸送専用車両５の必要数は、出発ステーション１１への帰還希望者数を、人員輸送専用車両５の定員数で除することで求まる。複数の人員輸送専用車両５が必要である場合、これらを同一グループの隊列４に割り振ってもよいし、異なるグループの隊列４に割り振ってもよい。換言すれば、人員輸送専用車両５は、グループを問わず、連携数が最大数に達しない隊列４に割り振ればよい。

　隊列編成処理部１２２は、以上のように編成した隊列４に関する情報を、隊列編成情報１７３ＡとしてスケジュールＤＢ１７３に格納する。図２４に、隊列編成情報１７３Ａの一例を示す。

　隊列編成情報１７３Ａは、たとえば図２４に示すように、隊列４の識別子［隊列ＩＤ］、出発ステーション［発Ｓ］、到着ステーション［着Ｓ］、出発時刻［発時刻］、複数の申請者、人員輸送専用車両連携要否、運転手手配要否を含み、申請者は、車両３の識別子［車両ＩＤ］、運転手の識別子［運転手ＩＤ］、運転手の状態［ステータス］の組み合わせによって構成される。

　申請者は、たとえば図２２を参照して説明したように、隊列４への車両３の割り振り順に並べられる。したがって、基本的には、まず、隊列４に編入後も運転手３Ａが車両３に乗車する申請者が記録され、次いで、隊列４に編入後は運転手３Ａが車両３に乗車しない申請者が記録されることになる。運転手３Ａが乗車しない申請者については、隊列編成処理部１２２は、運転手の識別子として、たとえば乗車無を意味する特定の値を格納する。運転手の状態としては、後述する運行監視処理部１２５によって、たとえば、隊列４を誘導する車両３を運転中か否かを示す情報や、運転時間、運転開始時刻および運転終了時刻などが記録される。また、この運転手の状態は、運転手フラグ（２）となる情報である。

　また、人員輸送専用車両連携要否は、隊列フラグ（１）となる情報であり、運転手手配要否は、隊列フラグ（２）となる情報である。人員輸送専用車両５を連携させる場合、隊列フラグ（１）がオンとなり、運転手３Ｂの手配が必要な場合、隊列フラグ（２）がオンとなる。

　次に、隊列編成処理部１２２によって作成されてスケジュールＤＢ１７３に格納される隊列編成情報１７３Ａを用いて、リソース手配スケジュール情報１７３Ｂを作成してスケジュールＤＢ１７３に格納する処理を実行する運転手手配処理部１２３および人員輸送専用車両手配処理部１２４について説明する。

　リソース手配スケジュール情報１７３Ｂは、運転手３Ｂおよび人員輸送専用車両５の手配に関するスケジュール情報であり、運転手手配処理部１２３は、運転手３Ｂの手配に関するスケジュール情報を作成し、人員輸送専用車両処理部１２４は、人員輸送専用車両５の手配に関するスケジュール情報を作成する。この２種類のスケジュール情報は、各々、当日分と前日分との少なくとも２つのスケジュール情報を含む。前日分のスケジュール情報は、当日分のスケジュール情報を作成するにあたって、前日の運行終了時における運転手３Ｂや人員輸送専用車両５の配置状況を示す初期情報として利用される。運転手３Ｂや人員輸送専用車両５の配置状況が運行開始時において常に所定の状況である場合には、前日分のスケジュール情報は不要であり、たとえば当該所定の状況を示す情報を基本情報ＤＢ１７２に格納しておき、リソース手配スケジュール情報１７３Ｂの作成時に参照すればよい。

　運転手手配処理部１２３は、まず、スケジュールＤＢ１７３に格納される隊列編成情報１７３Ａ内の隊列フラグ（２）を参照して、隊列編成処理部１２２が編成したすべての隊列４の中から運転手３Ｂの手配が必要な隊列４のみを抽出する。運転手３Ｂの手配が必要な隊列４のみを抽出したら、運転手手配処理部１２３は、リソース手配スケジュール情報１７３Ｂの中の運転手３Ｂの手配に関する前日分のスケジュール情報を参照し、前日の運行終了時、つまり、当日の運行開始時における運転手３Ｂの配置状況を取得する。運転手３Ｂの手配が必要な隊列４のみを抽出し、かつ、運転手３Ｂの配置状況を取得したら、運転手手配処理部１２３は、運転手３Ｂの運用計画を作成し、その運用計画を運転手３Ｂの手配に関する当日分のスケジュール情報としてスケジュールＤＢ１７３に格納する。運転手３Ｂの運用計画を作成する手法については、たとえば鉄道のスケジューリングにおける乗務員運用計画の手法などを適用することができる。

　人員輸送専用車両手配処理部１２４は、まず、スケジュールＤＢ１５３に格納される隊列編成情報１７３Ａ内の隊列フラグ（１）を参照して、隊列編成処理部１２２が編成したすべての隊列４の中から人員輸送専用車両５を連携させる隊列４のみを抽出する。人員輸送専用車両５を連携させる隊列４のみを抽出したら、人員輸送専用車両手配処理部１２４は、リソース手配スケジュール情報１７３Ｂの中の人員輸送専用車両５の手配に関する前日分のスケジュール情報を参照し、前日の運行終了時、つまり、当日の運行開始時における人員輸送専用車両５の配置状況を取得する。人員輸送専用車両５を連携させる隊列４のみを抽出し、かつ、人員輸送専用車両５の配置状況を取得したら、人員輸送専用車両手配処理部１２４は、人員輸送専用車両５の運用計画を作成し、その運用計画を人員輸送専用車両５の手配に関する当日分のスケジュール情報としてスケジュールＤＢ１７３に格納する。人員輸送専用車両５の運用計画を作成する手法については、たとえば鉄道のスケジューリングにおける車両運用計画の手法などを適用することができる。

　このように、この隊列走行運用システムは、運転手３Ａに関する運転手情報（運転手フラグ）と、車両３に関する車両情報（車両フラグ）と、隊列４に関する隊列情報（隊列フラグ）とを用いて、たとえば隊列４を誘導する車両３の運転手３Ａの割り振りなどが考慮された隊列４の適応的な編成を可能とする。

　また、運行監視処理部１２５は、たとえば隊列４のステーション１１からの出発時やステーション１１への到着時に当該隊列４を誘導する車両３の運転手３Ａが携行する携帯機器から送られる情報によって、隊列４がどの車両３（運転手３Ａ）によって誘導されているのかや、その運転時間といった情報を取得する。運行監視処理部１２５は、これら取得した情報を、スケジュールＤＢ１７３に格納される隊列編成情報１７３Ａ内の申請者に関する情報、より詳しくは、運転手の状態［ステータス］として記録する。この情報は、前述したように、運転手フラグ（２）となる情報である。

　前述したように、運行監視処理部１２５は、課金管理部としても機能する。運行監視処理部１２５は、各日の運用終了後、スケジュールＤＢ１７３に格納される隊列編成情報１７３Ａを参照して、当該隊列編成情報１７３Ａから得られる隊列走行時の運転有無や運転時間に基づき、各隊列４について、編入した車両３に対する課金額を算出する。

　たとえば、同一の区間であるならば、隊列走行時に運転手３Ａが乗車していた車両３の料金を、隊列走行時に運転手３Ａが乗車していない車両３の料金よりも安く、隊列走行時に運転手３Ａが乗車していた車両３のうち、隊列４を誘導するための運転を行った運転手３Ａの車両３の料金を、隊列４を誘導するための運転を行わなかった運転手３Ａの車両３の料金よりも安く算出する。さらには、隊列４を誘導するための運転を行った運転手３Ａの車両３が複数存在する場合、運転時間が長い運転手３Ａの車両３の料金を、運転時間が短い運転手３Ａの車両３の料金よりも安く算出する。

　図２５は、この隊列走行運用システム（サービスセンタ１－２）において実行される運行スケジュール作成処理の流れを示すフローチャートである。

　サービスセンタ１－２は、まず、隊列走行可能道路１０上の区間（方向別）、発時刻、性能ごとに、隊列４へ編入する車両３の車両数を集計する（ステップＣ１）。サービスセンタ１は、各車両３の性能を、車両フラグによって取得する。

　また、サービスセンタ１－２は、区間、着時刻ごとに、出発ステーション１１から到着ステーション１１まで車両３に乗車する運転手３Ａであって、出発ステーション１１への帰還を希望する運転手３Ａの数を集計する（ステップＣ２）。より詳しくは、帰還希望者の有無を判定する。そして、サービスセンタ１－２は、この集計結果に基づき、人員輸送専用車両５の割り当てを行う（ステップＣ３）。人員輸送専用車両５の割り当ては、帰還希望者が存在する区間と逆の区間かつ到着ステーション１１の到着時刻から一定期間経過後の直近の出発時刻に対して行う。

　次に、サービスセンタ１－２は、区間、発時刻、性能ごとに、隊列４を編成する（ステップＣ４）。より詳しくは、サービスセンタ１－２は、まず、隊列４の数を算出する。隊列４の数は、総車両数を連携可能数で除することで算出される。次に、サービスセンタ１－２は、算出した数の隊列４に対して、運転手３Ａが乗車する車両３を均等に割り当て、また、人員輸送専用車両５が割り当てられている場合、いずれかの隊列４に人員輸送専用車両５を連携させる。サービスセンタ１－２は、運転手３Ａが乗車する車両３を、運転手フラグ（１）によって取得し、また、人員輸送専用車両５を連携させた隊列４について、隊列フラグ（１）をオンにする。さらに、サービスセンタ１－２は、各隊列４について、運転手３Ｂの手配が必要か否かを判定する。この判定は、運転手３Ａが乗車する車両３の数が、その区間の走行予定時間を１人の運転手３Ａによる連続運転可能時間で除した数を上回っているか否かで行うことができる。サービスセンタ１－２は、運転手３Ｂの手配が必要な隊列４について、隊列フラグ（２）をオンにする。

　次に、サービスセンタ１－２は、運転手３Ｂの手配のための処理を行う（ステップＣ５）。より詳しくは、サービスセンタ１－２は、まず、すべての隊列４の中から運転手３Ｂの手配が必要な隊列４のみを抽出する。サービスセンタ１－２は、該当する隊列４の抽出を、隊列フラグ（２）を用いて行う。運転手３Ｂの手配が必要な隊列４のみを抽出したら、サービスセンタ１－２は、運転手３Ｂの運用計画を作成する。

　また、サービスセンタ１－２は、人員輸送専用車両５の手配のための処理を行う（ステップＣ６）。より詳しくは、サービスセンタ１－２は、まず、すべての隊列４の中から人員輸送専用車両５の手配が必要な隊列４のみを抽出する。サービスセンタ１－２は、該当する隊列４の抽出を、隊列フラグ（１）を用いて行う。人員輸送専用車両５の手配が必要な隊列４のみを抽出したら、サービスセンタ１－２は、人員輸送専用車両５の運用計画を作成する。

　なお、ステップＣ５の運転手３Ｂの手配のための処理と、ステップＣ６の人員輸送専用車両５の手配のための処理とは、順番を入れ替えて実行してもよいし、また、並行して実行してもよい。

　また、図２６は、この隊列走行運用システム（サービスセンタ１－２）において実行される運行監視（課金）処理の流れを示すフローチャートである。

　サービスセンタ１－２は、隊列４を誘導する車両３を運転する運転手３Ａを検知する（ステップＤ１）。サービスセンタ１は、検知した運転手３Ａについて、運転手フラグ（２）をオンにする。また、サービスセンタ１は、各車両３について、運転手フラグ（２）がオンである時間、つまり、運転手３Ａの運転時間を累計する（ステップＤ２）。

　そして、サービスセンタ１は、隊列４へ編入された車両３への運転手３Ａの乗車有無、運転手３Ａの運転時間に基づき、各車両３の課金額を算出する（ステップＤ３）。運転手３Ａの乗車有無は、運転手フラグ（１）を用いて判定することができる。

　以上のように、本実施形態の隊列走行運用システムは、運転手３Ａに関する運転手情報と、車両３に関する車両情報と、隊列４に関する隊列情報とを用いて、たとえば隊列４を誘導する車両３の運転手３Ａの割り振りなどが考慮された隊列４の適応的な編成を可能とする。

　以下に、本実施形態に含まれる特徴について付記する。　
［１］
　複数の車両が隊列として連携して走行可能な道路上の共通する２つの拠点間を走行する車両を連携させて隊列を編成する隊列走行運用システムであって、
　車両を隊列へ編入させる申請のための情報であって、出発拠点および到着拠点と、出発時刻または到着時刻の少なくとも一方と、車両の識別子と、車両の運転手の識別子および隊列走行時の乗車有無とを含む申請情報を受け付ける申請受付部と、
　前記申請受付部によって受け付けられた申請情報に基づき、前記道路上を連携して走行させる隊列を編成する隊列編成部と、
　前記隊列編成部によって編成されたすべての隊列の中から隊列を誘導する車両の運転手の手配が必要な隊列を抽出して運転手の運用計画を作成する運転手手配部と、
　を具備し、
　前記隊列編成部は、前記車両の運転手の隊列走行時の乗車有無を含む前記車両の運転手に関する運転手情報と、前記車両の識別子に対応づけられて管理される前記車両の性能を含む前記車両に関する車両情報とを用いて、前記隊列を編成し、かつ、前記運転手の手配要否を含む前記隊列に関する隊列情報を生成し、
　前記運転手手配部は、前記運転手の手配要否を含む前記隊列情報を用いて、前記運転手の運用計画を作成する、
　隊列走行運用システム。　
［２］
　前記申請情報は、隊列走行時に車両に乗車する運転手の出発拠点への帰還希望有無をさらに含み、
　前記隊列編成部は、出発拠点への帰還を希望する運転手を輸送するための人員輸送専用車両を含めて前記隊列の編成を実行し、かつ、前記人員輸送専用車両の連携有無を含む前記隊列情報を生成し、
　前記人員輸送専用車両の連携有無を含む前記隊列情報を用いて、前記隊列編成部によって編成されたすべての隊列の中から前記人員輸送専用車両が連携する隊列を抽出して前記人員輸送専用車両の運用計画を作成する人員輸送専用車両手配部をさらに具備する、
　［１］に記載の隊列走行運用システム。　
［３］
　前記隊列編成部は、前記道路上の共通する２つの拠点間を走行する車両を前記車両情報で示される性能に基づいてグループ化し、グループごとに隊列を編成する［１］または［２］に記載の隊列走行運用システム。　
［４］
　前記隊列編成部は、隊列走行時に運転手が乗車する車両の数が均等になるように隊列を編成する［１］乃至［３］のいずれか１つに記載の隊列走行運用システム。　
［５］
　前記隊列編成部は、隊列走行時に車両に乗車する運転手の数が、その隊列走行の予定時間を１人の運転手による連続運転可能時間で除した数に満たない場合、運転手の手配が必要である旨を示すように、その隊列に関する前記隊列情報を生成する請求項［１］乃至［４］のいずれか１つに記載の隊列走行運用システム。　
［６］
　前記隊列編成部は、隊列走行による第１拠点から第２拠点への移動後に前記第１拠点への帰還を希望する運転手が存在する場合、その隊列が前記第２拠点へ到着する時刻以降に前記第２拠点を出発して前記第１拠点まで走行する隊列に前記人員輸送専用車両を連携させて、前記人員輸送専用車両が連携する旨を示すように、その隊列に関する前記隊列情報を生成する［２］に記載の隊列走行運用システム。　
［７］
　隊列へ編入された車両に対する課金を管理する課金管理部をさらに具備し、
　隊列走行時に車両に乗車する運転手は、隊列を誘導する車両を運転し得る要員として位置づけられ、
　前記課金管理部は、隊列走行時に運転手が乗車する車両に対する課金額を隊列走行時に運転手が乗車しない車両に対する課金額よりも低く算出する、
　［１］乃至［６］のいずれか１つに記載の隊列走行運用システム。　
［８］
　前記運転手情報は、隊列の走行時、前記隊列を誘導する車両を運転中か否かをさらに含み、
　前記課金管理部は、前記運転手情報が隊列を誘導する車両を運転中であることを示している時間に基づき、その運転手の車両に対する課金額を算出する、
　［７］に記載の隊列走行運用システム。

［９］
　前記運転手情報は、前記車両の運転手の識別子に対応づけられて管理される前記運転手の属性をさらに含み、
　前記隊列編成部は、前記運転手情報で示される運転手の属性に基づき、隊列走行時に車両に乗車する運転手の中から隊列を誘導する車両を運転する運転手を選出する、
　［８］に記載の隊列走行運用システム。

［１０］
　複数の車両が隊列として連携して走行可能な道路上の共通する２つの拠点間を走行する車両を連携させて隊列を編成する隊列走行運用方法であって、
　車両を隊列へ編入させる申請のための情報であって、出発拠点および到着拠点と、出発時刻または到着時刻の少なくとも一方と、車両の識別子と、車両の運転手の識別子および隊列走行時の乗車有無とを含む申請情報を受け付けることと、
　前記受け付けた申請情報に基づき、前記道路上を連携して走行させる隊列を編成することと、
　前記編成したすべての隊列の中から隊列を誘導する車両の運転手の手配が必要な隊列を抽出して運転手の運用計画を作成することと、
　を具備し、
　前記隊列を編成することは、前記車両の運転手の隊列走行時の乗車有無を含む前記車両の運転手に関する運転手情報と、前記車両の識別子に対応づけられて管理される前記車両の性能を含む前記車両に関する車両情報とを用いて、前記隊列を編成し、かつ、前記前記運転手の手配要否を含む前記隊列に関する隊列情報を生成することを含み、
　前記運転手の運用計画を作成することは、前記運転手の手配要否を含む前記隊列情報を用いて、前記運転手の運用計画を作成することを含む、
　隊列走行運用方法。

　本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

　１…サービスセンタ、２…車両認識装置、３…車両、３Ａ，３Ｂ…運転手、４…隊列、５…人員輸送専用車両、６…営業拠点、１０，Ｒ…隊列走行可能道路、１１…ステーション、２０…非隊列走行可能道路、２１…申請画面、１０１，１２１…申請受付処理部、１０２，１２２…隊列編成処理部、１０３…車両位置検出処理部、１０４…運行監視処理部（課金管理部）、１２３…運転手手配処理部、１２４…人員輸送専用車両手配処理部、１３０…運行スケジュール作成処理部、１５１，１７１…申請情報ＤＢ、１５２，１５２Ａ…ステーション情報、１５２Ｂ，１７２Ｂ…登録車両情報、１５２Ｃ，１７２Ｃ…登録運転手情報、１７２…基本情報ＤＢ、１５３…隊列情報ＤＢ、１５４…車両位置情報ＤＢ、１７２Ａ…運行ダイヤ情報、１７３…スケジュールＤＢ、１７３Ａ…隊列編成情報、１７３Ｂ…リソース手配スケジュール情報。

Claims

　複数の車両を連携させて隊列を編成する隊列走行運用システムであって、
　車両の隊列への編入の申請を受け付ける申請受付処理部と、
　前記車両を運転する運転手に関する情報または前記車両に関する情報の少なくとも一方に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する隊列編成処理部と、
　を具備する隊列走行運用システム。
　前記運転手に関する情報は、運転免許に関する情報を含み、
　前記隊列編成処理部は、前記運転免許に関する情報に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する、
　請求項１に記載の隊列走行運用システム。
　前記運転手に関する情報は、体調に関する情報を含み、
　前記隊列編成処理部は、前記体調に関する情報に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する、
　請求項１または２に記載の隊列走行運用システム。
　前記体調に関する情報は、アルコール検知器の出力情報を含む請求項３に記載の隊列走行運用システム。
　前記車両に関する情報は、保険の加入有無に関する情報を含み、
　前記隊列編成処理部は、前記保険の加入有無に関する情報に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する、
　請求項１乃至４のいずれか１項に記載の隊列走行運用システム。
　前記車両に関する情報は、加入する保険の種類に関する情報をさらに含み、
　前記隊列編成処理部は、前記保険の種類に関する情報に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する、
　請求項５に記載の隊列走行運用システム。
　前記車両に関する情報は、性能に関する情報を含み、
　前記隊列編成処理部は、前記性能に関する情報に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定する、
　請求項１乃至６のいずれか１項に記載の隊列走行運用システム。
　複数の車両を連携させて隊列を編成する隊列走行運用方法であって、
　車両の隊列への編入の申請を受け付けることと、
　前記車両を運転する運転手に関する情報または前記車両に関する情報の少なくとも一方に基づき、前記車両を編入させる隊列を選定し、または、前記車両の隊列への編入可否を判定することと、
　を具備する隊列走行運用方法。