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

Description

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

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

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

１台の有人車両が複数台の無人車両を誘導する隊列を編成する場合、隊列の連携可能車両数を管理し、隊列から離脱する車両に対する隊列へ合流する車両の運転手の割り当てを管理する仕組みなどを提供する基盤となるシステムが求められる。

本発明が解決しようとする課題は、隊列の連携可能車両数を管理し、隊列から離脱する車両に対する隊列へ合流する車両の運転手の割り当てを管理することができる隊列走行運用システムおよび隊列走行運用方法を提供することである。

実施形態によれば、隊列走行運用システムは、あらかじめ定められた路線上において複数の車両を連携させて隊列を編成する。隊列走行運用システムは、申請受付処理部と、申請管理処理部と、運転手調整処理部と、を具備する。申請受付処理部は、前記路線上に点在する各拠点での出発時刻または到着時刻があらかじめ定められる複数の隊列の中のいずれかの隊列の指定と、前記路線上の出発拠点および到着拠点の指定とを少なくとも含む車両の隊列への編入の申請を受け付ける。申請管理処理部は、前記複数の隊列それぞれの連携車両数が所定数を超えないように、前記申請の受け付け可否の判定を含む申請の管理を行う。運転手調整処理部は、前記路線上の第１拠点を出発拠点として指定する車両の運転手を、前記第１拠点を到着拠点として指定する車両へ割り当てる。

実施形態の隊列走行運用システムの一形態例を示す図。 実施形態の隊列走行運用システムによって実施される車両の隊列走行の概要を説明するための図。 実施形態の隊列走行運用システムにおいて実施され得る隊列単位の合流または分離の一例を示す図。 実施形態のサービスセンタ（サーバ）の機能ブロック図。 実施形態のサービスセンタ（サーバ）のハードウェア構成の一例を示す図。 実施形態の隊列走行運用システムにおいて用いられる運用ダイヤデータの一例を示す図。 実施形態の隊列走行運用システムにおいて用いられる申請データの一例を示す図。 実施形態の隊列走行運用システムにおいて用いられる申請状況管理データの一例を示す図。 実施形態の隊列走行運用システムにおいて用いられる運転手調整管理データの一例を示す図。 実施形態の隊列走行運用システムにおいて実行される運転手調整処理の概要を説明するための第１の図。 実施形態の隊列走行運用システムにおいて実行される運転手調整処理の概要を説明するための第２の図。 実施形態の隊列走行運用システム（サービスセンタ）において実行される申請管理処理の流れを示すフローチャート。 実施形態の隊列走行運用システム（サービスセンタ）において実行される運転手調整処理の流れを示すフローチャート。 実施形態の隊列走行運用システムによって実施される車両の隊列走行の一変形例の概要を説明するための図。 実施形態の隊列走行運用システムによって実施される車両の隊列走行の一変形例における一申請画面例を示す図。

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

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

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

サービスセンタ１００は、たとえばＰＣ（Personal Computer）やスマートフォンなどのユーザ機器２００からインターネットなどのネットワークＮ経由で隊列への車両の編入を要求する申請を受け付ける。ユーザ機器２００は、物流会社の営業拠点などに設けられるものであってもよいし、個人が保有するものであってもよい。換言すれば、隊列へ編入させる車両は、物流会社のトラックに限らず、自家用車であってもよい。

まず、図２を参照して、この隊列走行運用システムによって実施される車両の隊列走行の概要を説明する。

ここでは、たとえば高速道路などを隊列走行が行える道路であるものと想定し、隊列走行可能道路２Ａと称する。また、たとえば一般道路などを隊列走行が行えない道路であるものと想定し、非隊列走行可能道路２Ｂと称する。この隊列走行運用システムは、複数の隊列走行可能道路２Ａを対象として隊列を編成することができる。以下、隊列走行可能道路２Ａを路線と称することがある。

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

この隊列走行運用システムにおいては、隊列走行可能道路２Ａ上を、あらかじめ定められた時刻に各ステーション１を出発または到着するように、有人の車両３Ａ（運転手５Ａが運転する車両）が走行する。また、この隊列走行運用システムにおいては、たとえば一定間隔で１日に数台の車両３Ａが隊列走行可能道路２Ａ上を走行する。車両３Ａには、所定数までの無人の車両３Ｂを連携させることができる。つまり、車両３Ａは、隊列４を誘導するための車両である。なお、車両３Ａは、必ずしも隊列４内において先頭に位置しなくともよい。また、１台の車両３Ａと１台以上の車両３Ｂとを隊列４として連携させて走行させる手法については、ここでは問わない。以下、隊列走行可能道路２Ａ上を走行する車両３Ａ、つまり隊列４を便と称することがある。

サービスセンタ１００に対するユーザ機器２００からの申請には、路線（隊列走行可能道路２Ａ）および便（隊列４）の指定と、隊列４への合流点とするステーション１および隊列４からの離脱点とするステーション１の指定とが少なくとも含まれる。よって、各ステーション１においては、隊列４へ合流する車両３Ｂが存在し得るし、隊列４を離脱する車両３Ｂが存在し得る。この隊列走行運用システムは、第１に、隊列４の車両数が所定数を超えないように、ユーザ機器２００からの申請の受け付け可否の判定を含む申請の管理を行う。

車両３Ｂは、隊列４への合流点である隊列走行可能道路２Ａ上のステーション１まで非隊列走行可能道路２Ｂを運転手５Ｂの運転によって走行する。ここでは、隊列４へ編入される前の運転手５Ｂによって運転される有人の車両を、無人の車両３Ｂと区別するために車両３Ａと称し、また、単独の車両３Ａの運転手を、隊列４を誘導する車両３Ａの運転手５Ａと区別するために運転手５Ｂと称する。車両３Ａは、ステーション１で隊列４へ編入されることにより、無人の車両３Ｂへと移行する。車両３Ｂをステーション１まで運転してきた運転手５Ｂは、そのステーション１を隊列４からの離脱点とする車両３Ａに割り当てられる。隊列４から離脱した車両３Ｂは、運転手５Ｂが割り当てられることにより、有人の車両３Ａへと移行し、非隊列走行可能道路２Ｂを走行する。ここでは、隊列４から離脱後の車両３Ｂの行先については問わない。

なお、図２には、ステーション［Ｍ］１からステーション［Ｍ＋１］１へと走行する隊列４内の車両［１］３Ｂと車両［２］３Ｂとが、ステーション［Ｍ＋１］１において隊列４から離脱し、当該ステーション［Ｍ＋１］１において、車両［５］３Ｂと車両［６］３Ｂとが隊列４へ合流している様子が示されている。図２に示されるように、ステーション［Ｍ＋１］１において隊列４から離脱した車両［１］３Ｂと車両［２］３Ｂとは、当該ステーション［Ｍ＋１］１において隊列４へ合流した車両［５］３Ｂの運転手［Ａ］５Ｂと車両［６］３Ｂの運転手［Ｂ］５Ｂとが割り当てられて、車両［１］３Ａと車両［２］３Ａとに移行し、非隊列走行可能道路２Ｂを走行する。また、ステーション［Ｍ＋１］１において隊列４へ合流した車両［５］３Ａと車両［６］３Ａとは、運転手５Ｂが不在となって、車両［５］３Ｂと車両［６］３Ｂとに移行する。

また、図２には、ステーション［Ｍ＋１］１を出発した隊列４について、当該隊列４内の車両［３］３Ｂと車両［４］３Ｂとが、ステーション［Ｍ＋２］１において隊列４から離脱し、当該ステーション［Ｍ＋２］１において、車両［７］３Ｂと車両［８］３Ｂとが隊列４へ合流している様子が示されている。図２に示されるように、ステーション［Ｍ＋２］１において隊列４から離脱した車両［３］３Ｂと車両［４］３Ｂとは、当該ステーション［Ｍ＋２］１において隊列４へ合流した車両［７］３Ｂの運転手［Ｃ］５Ｂと車両［８］３Ｂの運転手［Ｄ］５Ｂとが割り当てられて、車両［３］３Ａと車両［４］３Ａとに移行し、非隊列走行可能道路２Ｂを走行する。ステーション［Ｍ＋２］１において隊列４へ合流した車両［７］３Ａと車両［８］３Ａとは、運転手５Ｂが不在となって、車両［７］３Ｂと車両［８］３Ｂとに移行する。

なお、図２には、わかり易くするために、各ステーション［Ｍ＋１、Ｍ＋２］１において隊列４から離脱する車両３Ｂの数と隊列４へ合流する車両３Ｂの数とが一致している例を示しているが、これらの数は必ずしも一致しない。この隊列走行運用システムは、第２に、各ステーション１における、隊列４から離脱する車両３Ｂに対する隊列４へ合流する車両３Ａの運転手５Ｂの割り当てを調整する。

また、図２には、隊列４へ車両３Ｂが合流し、または、隊列４から車両３Ｂが離脱する様子を示しているが、本実施形態の隊列走行運用システムにおいては、隊列４同士を合流させ、または、隊列４自体を分離させることも可能である。図３に、隊列４同士の合流または隊列４自体の分離の一例を示す。

図３中、（Ａ）は、隊列４同士を合流させる一例を示し、（Ｂ）は、隊列４自体を分離させる一例を示している。

（Ａ）に示すように、たとえば、ある合流点において隊列走行可能道路２Ａ−１と隊列走行可能道路２Ａ−２とが合流する隊列走行可能道路２Ａを想定する。このような隊列走行可能道路２Ａの場合、隊列４として連携可能な車両数の範囲内において、隊列走行可能道路２Ａ−１を走行する隊列［１］４と隊列走行可能道路２Ａ−２を走行する隊列［２］とを、各々が合流点を通過後、たとえば走行中に合流させることが可能である。この合流を前提として、隊列走行可能道路２Ａ−１を走行する隊列［１］４および隊列走行可能道路２Ａ−２を走行する隊列［２］４の連携可能車両数を設定すればよい。もちろん、３以上の隊列４を１つの隊列４へと合流させることも可能である。

また、（Ｂ）に示すように、たとえば、ある分岐点において隊列走行可能道路２Ａ−１と隊列走行可能道路２Ａ−２とに分岐する隊列走行可能道路２Ａを想定する。このような隊列走行可能道路２Ａの場合、隊列走行可能道路２Ａ−１を走行する隊列［３］４を、分岐点の手前で、隊列走行可能道路２Ａ−１を走行する隊列［３−１］４と隊列走行可能道路２Ａ−２を走行する隊列［３−２］とに、たとえば走行中に分離させることが可能である。この分離後、隊列走行可能道路２Ａ−１を走行する隊列［３−１］４および隊列走行可能道路２Ａ−２を走行する隊列［３−２］４については、各々、連携可能車両数を設定することができる。もちろん、１つの隊列４から３以上の隊列４へ分離させることも可能である。

このような隊列４同士の合流および隊列４自体の分離を行うことで、たとえば、合流後または分離前において一部の運転手５Ａの休憩時間を確保することなどが可能となる。なお、このような合流や分離が行われる隊列４についても、合流前または分離後の最小構成の隊列４を１つの便として扱うことで、このような合流や分離が行われない隊列４と同様に、申請の管理を行うことができる。 図４は、本実施形態のサービスセンタ（サーバ）１の機能ブロック図である。

図４に示されるように、サービスセンタ１００は、申請受付処理部１０１、申請管理処理部１０２および運転手調整処理部１０３と、ＤＢ（DataBase）１５１とを有する。ＤＢ１５１には、後述する、運行ダイヤデータ１５１Ａ、申請データ１５１Ｂ、申請状況管理データ１５１Ｃおよび運転手調整管理データ１５１Ｄが格納される。

前述したように、サーバは、プロセッサと、通信デバイスと、ストレージデバイスとを少なくとも備えるコンピュータである。申請受付処理部１０１、申請管理処理部１０２および運転手調整処理部１０３は、ストレージデバイスに記憶されているプログラムがプロセッサによって実行されることによって構築される。また、ＤＢ１５１は、ストレージデバイス上に構築される。図５に、サービスセンタ（サーバ）１のハードウェア構成の一例を示す。

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

ここでは、隊列走行運用システムは、外部記憶装置５３に格納される隊列走行運用プログラム１００Ａが、当該外部記憶装置５３から主メモリ５２にロードされてプロセッサ５１によって実行されることによって、図４に示される申請受付処理部１０１、申請管理処理部１０２および運転手調整処理部１０３が実現されるものとする。また、図４に示されるＤＢ１５１は、外部記憶装置５３内に構築されるものとする。

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

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

申請受付処理部１０１は、ユーザ機器２００からの隊列４への編入の申請を受け付ける処理を実行する。申請受付処理部１０１は、サービスセンタ１００へアクセスしてきたユーザ機器２００に申請画面２１を表示させるための情報、たとえばＨＴＭＬ（HyperText Markup Language）ファイルを送信する。図４に示されるように、申請画面２１上の入力項目には、日付（ａ１）、路線（ａ２）、便（ａ３）、出発ステーション［発Ｓ］（ａ４）、到着ステーション［着Ｓ］（ａ５）、隊列４へ編入させる車両３Ａの識別子［車両ＩＤ：Identification Data］（ａ６）、車両３Ａの属性［車両属性］（ａ７）、車両３Ａの運転手５Ｂの識別子［運転手ＩＤ］（ａ８）、運転手５Ｂの属性［運転手属性］（ａ９）などが存在する。車両属性には、たとえば、危険物を搭載する車両や大型の車両等、少なくとも所定の資格を必要とする車両であることを認識可能な情報が含まれる。運転手属性には、少なくともその運転手が保有する資格を認識可能な情報が含まれる。資格としては、たとえば、（普通・中型・大型）自動車免許、牽引免許、フォークリフト運転者、玉掛作業者、移動式クレーン運転士、各種危険物取扱者、各種高圧ガス製造保安責任者、充てん作業者などが挙げられる。つまり、車両属性は、これらの資格を必要とする車両であることを認識可能な情報を含む。車両属性および運転手属性は、隊列４から離脱する車両３Ｂに対する隊列４へ合流する車両３Ａの運転手５Ｂの割り当てに利用される。より詳しくは、たとえば、隊列４から離脱する車両３Ｂがタンクローリーである場合、タンクローリーを運転することのできる運転手５Ｂを割り当てるといったことに利用される。

また、申請画面２１上の入力項目には、車両３Ａに搭載される荷物の識別情報（伝票番号等）や、納品条件（引き渡し方法、運送会社の指定等）などが含まれてもよい。これらの情報は、車両３Ａの隊列４への合流時または車両３Ｂの隊列４からの離脱時における荷物の引き渡しのための検品に利用することができる。検品は、荷物単位、車両単位またはステーション単位で、目視またはＲＦＩＤ（Radio Frequency IDentifier）タグを用いた一括スキャン等で行われる。つまり、これらの情報により、荷物の紛失をなくし、または、荷物の紛失時点を特定することが可能となる。

図６に、ＤＢ１５１に格納される運行ダイヤデータ１５１Ａの一例を示す。

運行ダイヤデータ１５１Ａは、たとえば路線（隊列走行可能道路２Ａ）ごとに設けられるデータであって、図６に示されるように、両方向（上り、下り）について、各隊列４の各ステーション１における出発時刻または到着時刻が示される。図６においては、わかり易くするために、各便の始発ステーションと終着ステーションとが一致している例を示しているが、路線（隊列走行可能道路２Ａ）には合流点や分岐点が存在し得るので、各便の始発ステーションと終着ステーションとは、必ずしも一致していなくてもよい。合流点や分岐点が存在しない路線（隊列走行可能道路２Ａ）においても、たとえば申請が集中し易い路線（隊列走行可能道路２Ａ）上の一部区間のみを走行する便を設けてもよい。

さらに、図６においては、わかり易くするために、各便が同一の所要時間で走行する例を示しているが、所要時間は必ずしも同一としなくともよい。たとえば、走行速度を速くしたり、通過するステーションを設けたりすることで、通常便よりも所要時間の短い特別便を設けてもよい。この場合、通常便よりも特別便の方の利用料金を高くするといったことが考えられる。利用料金については、必ずしも固定料金としなくともよく、たとえば連携可能車両数から申請数を引いた残車両数に応じて変動させてもよい。たとえば、残車両数が一定数以上の状況下では低料金で申請を受け付け、残車両数が一定数を下回ったら料金を上げるようにしてもよい。あるいは、申請時に希望額を入力させ、その額に応じて料金を決定するようにしてもよい。

また、たとえば危険物を搭載する車両３Ａや大型の車両等の所定の資格を必要とする車両３Ａを合流させることができる便と、そのような車両３Ａを合流させることができない便とを設けてもよい。換言すれば、所定の資格を有する運転手５Ａが手配される便を設けてもよい。もちろん、たとえば資格ごとに複数種の便をあらかじめ設けるのではなく、所定の資格を必要とする車両３Ａの合流を伴う申請が受け付けられた便について、当該所定の資格を有する運転手５Ａを適応的に手配するようにしてもよい。

なお、運行ダイヤデータ１５１Ａは、一定時間内の便数が所定数以内に制限されるように作成されることが好ましい。

たとえば、図６に示される「××路線」の「第２便」にて「ステーション［１］」から「ステーション［３］」まで車両３Ａを（車両３Ｂとして）誘導してもらうことを申請するユーザは、申請画面２１上の入力項目中の路線（ａ２）に「××路線」、便（ａ３）に「第２便」、発Ｓ（ａ４）に「ステーション［１］」、着Ｓ（Ｓ５）に「ステーション［３］」を入力する。なお、車両ＩＤ（ａ６）、車両属性（ａ７）、運転手ＩＤ（ａ８）、運転手属性（ａ９）には、便や発着ステーションに関わらず、一定の情報が入力される。

申請受付処理部１０１は、ユーザ機器２００から申請を受けると、その申請内容を申請管理処理部１０２に通知する。申請管理処理部１０２は、その申請の受け付け可否を判定し、判定結果を申請受付処理部１０１に通知する。申請管理処理部１０２による受け付け可否の判定については後述する。申請受付処理部１０１は、受け付け不可を申請管理処理部１０２から通知された場合、ユーザ機器２００に対してエラーを通知する。エラーを通知する場合、申請受付処理部１０１は、たとえば申請の受け付けが可能な他の便を斡旋する情報を同時に通知するようにしてもよい。

一方、受け付け可能を申請管理処理部１０２から通知された場合、申請受付処理部１０１は、ユーザ機器２００に対して申請受領を通知する。ユーザ機器２００に対する通知は、申請受付処理部１０１が申請受付時に即応的に行ってもよいし、たとえば申請管理処理部１０２が申請受付処理部１０１による申請受付時とは別のタイミングで行ってもよい。

申請が受け付け可能であった場合、申請受付処理部１０１は、申請ごとに受付番号（受付No.）を採番し、たとえば日付ごとに、この受付番号順に、申請画面２１上で入力された内容を申請データ１５１ＢとしてＤＢ１５１に格納する。図７に、ＤＢ１５１に格納される申請データ１５１Ｂの一例を示す。図７に示されるように、申請データ１５１Ｂは、申請受付処理部１０１が採番した受付番号と、申請画面２１上の入力項目（路線、便、出発ステーション、到着ステーション、車両ＩＤ、車両属性、運転手ＩＤ、運転手属性）とを含む。

また、図８は、ＤＢ１５１に格納される申請状況管理データ１５１Ｃの一例を示す。

申請状況管理データ１５１Ｃは、各便（隊列４）の各ステーション１間における車両３Ｂの連携数を管理するためのものであり、図８に示すように、申請数（上段）と、定員数（下段）とを保持する。申請管理処理部１０２は、申請受付処理部１０１から通知された申請内容で示される便の指定区間において申請数が定員数に達している区間が存在する場合、その申請の受け付け不可を申請受付処理部１０１へ通知する。一方、申請数が定員数に達している区間が存在しない場合、申請管理処理部１０２は、その申請の受け付け可能を申請受付処理部１０１へ通知するとともに、指定区間の申請数を１ずつ増加させるための申請状況管理データ１５１Ｃの更新を実行する。

たとえば、「第２便」による「ステーション［１］」から「ステーション［３］」までの申請に対して、申請管理処理部１０２は、「第２便」の「ステーション［１］→ステーション［２］」および「ステーション［２］→ステーション［３］」の申請数をそれぞれ１つずつ増加させる。この申請状況管理データ１５１Ｃに基づき、申請管理処理部１０２は、隊列４の車両数が所定数を超えないように、ユーザ機器２００からの申請の受け付け可否の判定を含む申請の管理を行う。

この申請管理処理部１０２による申請の管理によって、たとえば、ある便（隊列４）への申請数がある区間において定員数に達していたとしても、あるステーション１で隊列４を離脱する車両３Ｂが存在するならば、そのステーション１以降を出発点とする車両３Ｂの申請を新たに受け付けることが可能となる。たとえば、申請管理処理部１０２は、あるステーション１への到着時における車両３Ｂの数が定員数に達している便（隊列４）について、そのステーション１を到着拠点として指定する車両が１以上連携している場合、当該１以上の車両数を上限として、そのステーション１を出発拠点として指定する車両の申請を受け付け可能と判定する。 なお、前述したように、ある便について、定員数に達しているとしてユーザ機器２００からの申請を受け付け不可と判定し、ユーザに対してエラーを通知する場合、申請の受け付けが可能な他の便を斡旋する情報を同時に通知してもよいが、キャンセル待ちという状態を管理するようにしてもよい。また、キャンセル待ちの数が一定数を超える便が存在する場合、臨時便を増設するようにしてもよい。

逆に、ある便が、全区間に渡って申請数が０である場合、その便を運休させるようにしてもよい。

なお、図４には示されないが、申請管理処理部１０２は、各便（隊列４）の編成を示すデータを作成してＤＢ１５１に格納することが好ましい。より詳しくは、各ステーション１間において各便（隊列４）がどの車両３Ｂを誘導しているのかを示すデータを作成して格納することが好ましい。このデータは、たとえば、車両３Ｂの車両ＩＤを、図８に示される申請状況管理データ１５１Ｃと同様のフォーマットで保持するテーブル形式として作成することができる。

また、申請管理処理部１０２は、申請受付処理部１０１から通知された申請を受け付け可能と判定した場合、さらに、ＤＢ１５１に格納される運転手調整管理データ１５１Ｄの更新を実行する。図９に、ＤＢ１５１に格納される運転手調整管理データ１５１Ｄの一例を示す。

図９に示すように、運転手調整管理データ１５１Ｄは、各便（隊列４）の各ステーション１における隊列４への車両３Ｂの合流数（上段）および隊列４からの車両３Ｂの離脱数（下段）を保持する。たとえば、「第１便」による「ステーション［１］」から「ステーション［３］」までの申請に対して、申請管理処理部１０２は、「第１便」の「ステーション［１］」の合流数を１つ増加させ、また、「第１便」の「ステーション［３］」の離脱数を１つ増加させる。なお、ここでは、わかり易くするために、隊列４から離脱する車両３Ｂが必要とする資格について考慮していないが、実際は、隊列４から離脱する車両３Ｂが必要とする資格に基づき、合流数および離脱数が管理される。

この運転手調整管理データ１５１Ｄは、運転手調整処理部１０３によって利用されるデータである。仮に、すべての便のすべてのステーション１において、合流数と離脱数とが一致するならば、隊列４に合流する車両３Ａをステーション１まで運転してきた運転手５Ｂを、隊列４から離脱する車両３Ｂに割り当てればよい。しかしながら、各ステーション１における合流数と離脱数とは、多くの場合、不一致が生じる。

合流数が離脱数より大きい場合、運転手５Ｂが余ることになる。換言すれば、運転手５Ｂを割り当てるべき車両３Ｂが不足することになる。一方、合流数が離脱数よりも小さい場合、運転手５Ｂが不足することになる。換言すれば、運転手５Ｂを割り当てるべき車両３Ｂが余ることになる。

運転手調整処理部１０３は、この合流数と離脱数との不一致を、一定期間内に到着・出発する複数の隊列４によって解消する。図１０および図１１を参照して、運転手調整処理部１０３が実行する運転手調整処理の概要について説明する。

たとえば、図１０に示されるように、あるステーション１に時刻ｔに到着（または出発）するある便（隊列４）の合流数が離脱数より２大きいとする。この場合、運転手５Ｂが２人余ることになる。また、このステーション１に時刻ｔ＋１に到着（または出発）する後続の便（隊列４）の合流数が離脱数より２小さいとする。この場合、車両３Ｂが２台余ることになる。運転手調整処理部１０３は、時刻ｔにおいて余った２人の運転手を、時刻ｔ＋１において余った車両３Ｂに割り当てる。図１０には、わかり易くするために、時刻ｔにおける合流数と離脱数との差分と、時刻ｔ＋１における離脱数と合流数との差分とが一致している例を示しているが、多くの場合、不一致が生じる。

たとえば、時刻ｔ＋１における合流数が離脱数より１だけ小さいとすると、運転手５Ｂは依然として１人が余ることになる。このような場合、運転手調整処理部１０３は、時刻ｔにおいて余った２人の運転手５Ａを優先的に時刻ｔ＋１において離脱する車両３Ｂに割り当て、時刻ｔ＋１において余った状態となる運転手５Ａについて、時刻ｔ＋１の便（隊列４）に後続する便（隊列４）を対象としてさらに調整を行う。

また、運転手調整処理部１０３は、同一方向の便（隊列４）に限らず、逆方向から同一ステーション１に到着（または出発）する便（隊列４）を対象として、運転手５Ａの調整を行ってもよい。図１１には、あるステーション１に時刻ｔに到着（または出発）するある便（隊列４）と、このステーション１に時刻ｔ´に逆方向から到着（または出発）するある便（隊列４）との間で、運転手５Ａの調整を行う例が示されている。また、図１１には、図１０に示される例とは逆に、時刻ｔにおいて車両３Ｂが余り、この余った車両３Ｂに対して、時刻ｔ´において余る運転手５Ｂを割り当てる例が示されている。

ところで、たとえば、あるステーション１は、どの便（隊列４）においても合流数の方が離脱数よりも多く、また、あるステーション１は、どの便（隊列４）においても離脱数の方が合流数よりも多いといった片寄りが発生すると、合流数と離脱数との不一致を一定期間に解消できない場合が生じ得る。より詳しくは、ある時刻において余った状態となった運転手５Ｂを割り当て可能な車両３Ｂが一定期間を超えて存在しない場合や、ある時刻において余った状態となった車両３Ｂに対して割り当て可能な運転手５Ｂが一定期間を超えて存在しない場合が生じ得る。

運転手調整処理部１０３は、割り当て可能な車両３Ｂが一定期間を超えて存在しない運転手５Ｂに対して、その運転手５Ｂをたとえばステーション１近傍の駅などに輸送するための人員輸送専用車両（バス）を手配する。また、割り当て可能な運転手５Ｂが一定時間を超えて存在しない車両３Ｂに対して、その車両３Ｂを運転して非隊列走行可能道路２Ｂを走行する運転手を手配する。より詳しくは、運転手調整処理部１０３は、人員輸送専用車両（バス）および運転手の運用計画を作成する。これらの運用計画を作成する手法については、たとえば鉄道のスケジューリングにおける乗務員運用計画の手法などを適用することができる。これらの運用計画は、図４には示されないたとえばリソース運用計画データなどとしてＤＢ１５１に格納される。なお、ここでは、このリソース運用計画データに基づく人員輸送専用車両（バス）および運転手の運用については触れない。運転手調整処理部１０３は、運転手５Ｂがどの車両３Ｂに割り当てられたかや、運転手５Ｂがどの車両３Ｂにも割り当てられず、人員輸送専用車両（バス）に乗車することを、ユーザ機器２００に通知する。

また、隊列４を誘導する車両３Ａを運転する運転手５Ａの手配も、たとえば鉄道のスケジューリングにおける乗務員運用計画の手法などを適用することができる。さらに、運転手５Ａが運転する車両３Ａは、人員輸送専用車両（バス）であってもよい。この人員輸送専用車両（バス）を、運転手５Ａの移動手段とすることで、人員の偏りを低減したり、運転手５Ａの休憩時間を確保したりすることが可能となる。

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

サービスセンタ１００は、ユーザ機器２００から申請を受け付けると、ＤＢ１５１に格納される申請状況管理データ１５１Ｃを参照して、指定された便（隊列４）の指定された区間に空きがあるか否かを調べる（ステップＡ１）。より詳しくは、申請数が定員数に達している区間が指定された区間内に存在するか否かを調べる。空きがある場合（ステップＡ１：ＹＥＳ）、つまり、申請数が定員数に達している区間が指定された区間内に存在しない場合、サービスセンタ１００は、申請者に申請受領を返信し（ステップＡ２）、その申請内容を申請データ１５１ＢとしてＤＢ１５１に格納する（ステップＡ３）。サービスセンタ１００は、ＤＢ１５１に格納した申請データ１５１Ｂに基づき、ＤＢ１５１の申請状況管理データ１５１Ｃを更新し（ステップＡ４）、また、ＤＢ１５１の運転手調整管理データを更新する（ステップＡ５）。

また、指定された便（隊列４）の指定された区間に空きがない場合（ステップＡ１：ＮＯ）、より詳しくは、申請数が定員数に達している区間が指定された区間内に存在する場合には、サービスセンタ１００は、申請者にエラーを返信する（ステップＡ６）。前述したように、エラーを返信する場合、たとえば申請の受け付けが可能な他の便を斡旋する情報を同時に通知するようにしてもよいし、キャンセル待ちという状態を管理するようにしてもよい。また、キャンセル待ちの数が一定数を超える便が存在する場合、臨時便を増設するようにしてもよい。

図１３は、この隊列走行運用システム（サービスセンタ１００）において実行される運転手調整処理の流れを示すフローチャートである。サービスセンタ１００は、すべての路線（隊列走行可能道路２Ａ）のすべてのステーション１について、そのステーション１を経由するすべての便（隊列４）を対象として、そのステーション１への到着時刻または出発時刻の早い順に、図１３に示される処理を行っていく。なお、この運転手調整処理は、たとえば各日の始発便の出発時刻よりも前の所定時刻に実行される。つまり、この運転手調整処理が実行される時点においては、処理対象日の便に対する申請は締め切られている。

サービスセンタ１００は、まず、合流車両数が離脱車両数よりも大きいかを調べる（ステップＢ１）。ここでの合流車両数や離脱車両数には、先行する便（隊列４）から引き継がれた余剰車両数が含まれ得る。合流車両数が離脱車両数よりも大きい場合（ステップＢ１：ＹＥＳ）、サービスセンタ１００は、まずは、その便（隊列４）からの離脱車両に合流車両の運転手を割り当てる（ステップＢ２）。このとき、サービスセンタ１００は、先行する便（隊列４）から引き継がれた余剰分の合流車両が存在する場合、その合流車両の運転手を優先的に割り当てる。

サービスセンタ１００は、一定期間内に離脱車両を含む便（隊列４）が存在するか否かを調べ（ステップＢ３）、存在する場合（ステップＢ３：ＹＥＳ）、続いて、当該一定期間内の便（隊列４）からの離脱車両に合流車両の運転手を割り当てる（ステップＢ４）。このときも、サービスセンタ１００は、引き継がれた余剰分の合流車両が存在する場合、その合流車両の運転手を優先的に割り当てる。

サービスセンタ１００は、余剰分の合流車両の運転手すべてをいずれかの車両に割り当てられたか否かを調べ（ステップＢ５）、いずれかの車両にも割り当てられていない運転手が存在する場合（ステップＢ５：ＮＯ）、その運転手に対して人員輸送専用車両（バス）を手配する（ステップＢ６）。

離脱車両数が合流車両数よりも大きい場合（ステップＢ１：ＮＯ、ステップＢ７：ＹＥＳ）、サービスセンタ１００は、まずは、その便（隊列４）への合流車両の運転手を離脱車両に割り当てる（ステップＢ８）。このとき、サービスセンタ１００は、引き継がれた余剰分の離脱車両が存在する場合、その離脱車両に優先的に割り当てる。

サービスセンタ１００は、一定期間内に離脱車両を含む便（隊列４）が存在するか否かを調べ（ステップＢ９）、存在する場合（ステップＢ９：ＹＥＳ）、続いて、当該一定期間内の便（隊列４）への合流車両の運転手を離脱車両に割り当てる（ステップＢ１０）。このときも、サービスセンタ１００は、引き継がれた余剰分の離脱車両が存在する場合、その離脱車両に優先的に割り当てる。

サービスセンタ１００は、余剰分の離脱車両すべてに運転手を割り当てられたか否かを調べ（ステップＢ１１）、運転手が割り当てられていない車両が存在する場合（ステップＢ１１：ＮＯ）、その車両に対して運転手を手配する（ステップＢ１２）。

離脱車両数と合流車両数とが一致する場合（ステップＢ７：ＮＯ）、サービスセンタ１００は、離脱車両に合流車両の運転手を割り当てる（ステップＢ１３）。

このように、この隊列走行運用システムは、隊列の連携可能車両数を管理し、隊列から離脱する車両に対する隊列へ合流する車両の運転手の割り当てを管理することができる。

ところで、以上の説明では、車両３Ａが隊列４へ編入した際、運転手５Ｂが離れて（無人の）車両３Ｂへ移行することを前提としているが、隊列４へ編入後も、運転手５Ａが車両３Ｂへ乗車し続け、隊列４から離脱したら、その車両３Ｂの運転を再開したいというニーズがユーザから寄せられることも考えられ得る。たとえば図１４に示されるように、車両３Ｂが隊列４に編入されている期間を、運転手５Ａの休憩時間として確保するといったことが考えられ得る。

このようなニーズに応えるために、この隊列走行運用システムは、たとえば図１５に示されるように、申請画面２１上の入力項目として、乗車有無（ａ１０）をさらに設けてもよい。この乗車有無（ａ１０）は、隊列４に編入された車両３Ｂへ運転手５Ｂが乗車するか否かを指定するための項目である。

もし、乗車するという指定がなされた場合、申請管理処理部１０２は、その車両３Ｂに関しては、ＤＢ１５１に格納される運転手調整管理データ１５１Ｄの更新を行わない。より詳しくは、その車両３Ｂを合流数や離脱数に加算しない。また、運転手調整処理部１０３は、この車両３Ｂおよび運転手５Ｂを、離脱車両３Ｂに対する合流車両３Ｂへの運転手５Ｂの割り当て処理から除外する。たとえば、ＤＢ１５１に格納される申請データ１５１Ｂを車両ＩＤから参照できるようにしておくことで、運転手調整処理部１０３は、運転手５Ｂの乗車有無を得ることができる。

このように、この隊列走行運用システムは、図１４に示されるような用途に対するニーズにも対応することが可能である。

また、乗車有無（ａ１０）という入力項目を申請画面２１上に設けることにより、乗車するという指定がなされた場合、その運転手５Ｂを、隊列４を誘導する車両３Ａの運転手５Ａとして活用するという運用も可能となる。たとえば、運転手属性（ａ９）として、非隊列走行可能道路２Ｂのみ運転、または、隊列走行可能道路２Ａの運転も可、のいずれかを示す情報が含まれるようにして、前者の場合、その運転手５Ｂについては図１４を参照して説明したような扱いとし、後者の場合、その運転手５Ｂを、隊列４を誘導する車両３Ａの運転手５Ａとして活用し得る要員として扱うものとする。隊列走行可能道路２Ａの運転も可とする申請に対しては、料金面で優遇してもよい。運転手５Ｂを、隊列４を誘導する車両３Ａの運転手５Ａとして活用し得るようにすることは、隊列４を誘導する車両３Ａの運転手５Ａの休憩時間を確保したり、運転手５Ａの連続運転時間を法定時間内に収めたりすることに貢献し得る。

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

１…ステーション、２Ａ…隊列走行可能道路、２Ｂ…非隊列走行可能道路、３…車両、３Ａ…有人車両、３Ｂ…無人車両、４…隊列、５Ａ…（隊列誘導車両の）運転手、５Ｂ…（単独車両の）運転手、２１…申請画面、１００…サービスセンタ、１０１…申請受付処理部、１０２…申請管理処理部、１０３…運転手調整処理部、１５１…ＤＢ、１５１Ａ…運行ダイヤデータ、１５１Ｂ…申請データ、１５１Ｃ…申請状況管理データ、１５１Ｄ…運転手調整管理データ、２００…ユーザ機器。

Claims (10)

1. あらかじめ定められた路線上において複数の車両を連携させて隊列を編成する隊列走行運用システムであって、
   前記路線上に点在する各拠点での出発時刻または到着時刻があらかじめ定められる複数の隊列の中のいずれかの隊列の指定と、前記路線上の出発拠点および到着拠点の指定とを少なくとも含む車両の隊列への編入の申請を受け付ける申請受付処理部と、
   前記複数の隊列それぞれの連携車両数が所定数を超えないように、前記申請の受け付け可否の判定を含む申請の管理を行う申請管理処理部と、
   前記路線上の第１拠点を出発拠点として指定する車両の運転手を、前記第１拠点を到着拠点として指定する車両へ割り当てる運転手調整処理部と、
   を具備する隊列走行運用システム。
2. 前記申請管理処理部は、前記第１拠点への到着時における連携車両数が前記所定数に達している隊列について、前記第１拠点を到着拠点として指定する車両が１以上存在する場合、当該１以上の車両数を上限として、前記第１拠点を出発拠点として指定する車両の申請を受け付け可能と判定する請求項１に記載の隊列走行運用システム。
3. 前記運転手調整処理部は、前記第１拠点を出発拠点として指定する車両の運転手が前記第１拠点を到着拠点として指定する車両を待機する時間が一定期間に収まるように、前記運転手の割り当てを行う請求項１または２に記載の隊列走行運用システム。
4. 前記運転手調整処理部は、前記第１拠点を出発拠点として指定する車両の運転手を割り当て可能な前記第１拠点を到着拠点として指定する車両が一定期間を超えて存在しない場合、前記運転手に対して人員輸送専用車両を手配する請求項１〜３のいずれか１項に記載の隊列走行運用システム。
5. 前記運転手調整処理部は、前記第１拠点を到着拠点として指定する車両へ割り当て可能な前記第１拠点を出発拠点として指定する車両の運転手が一定期間を超えて存在しない場合、前記前記第１拠点を到着拠点として指定する車両に対して運転手を手配する請求項１〜４のいずれか１項に記載の隊列走行運用システム。
6. あらかじめ定められた路線上において複数の車両を連携させて隊列を編成する隊列走行運用方法であって、
   前記路線上に点在する各拠点での出発時刻または到着時刻があらかじめ定められる複数の隊列の中のいずれかの隊列の指定と、前記路線上の出発拠点および到着拠点の指定とを少なくとも含む車両の隊列への編入の申請を受け付けることと、
   前記複数の隊列それぞれの連携車両数が所定数を超えないように、前記申請の受け付け可否の判定を含む申請の管理を行うことと、
   前記路線上の第１拠点を出発拠点として指定する車両の運転手を、前記第１拠点を到着拠点として指定する車両へ割り当てることと、
   を具備する隊列走行運用方法。
7. 前記申請の管理を行うことは、前記第１拠点への到着時における連携車両数が前記所定数に達している隊列について、前記第１拠点を到着拠点として指定する車両が１以上連携している場合、当該１以上の車両数を上限として、前記第１拠点を出発拠点として指定する車両の申請を受け付け可能と判定することを含む請求項６に記載の隊列走行運用方法。
8. 前記運転手を車両へ割り当てることは、前記第１拠点を出発拠点として指定する車両の運転手が前記第１拠点を到着拠点として指定する車両を待機する時間が一定期間に収まるように、前記運転手の割り当てを行うことを含む請求項６または７に記載の隊列走行運用方法。
9. 前記第１拠点を出発拠点として指定する車両の運転手を割り当て可能な前記第１拠点を到着拠点として指定する車両が一定期間を超えて存在しない場合、前記運転手に対して人員輸送専用車両を手配することをさらに具備する請求項６〜８のいずれか１項に記載の隊列走行運用方法。
10. 前記第１拠点を到着拠点として指定する車両へ割り当て可能な前記第１拠点を出発拠点として指定する車両の運転手が一定期間を超えて存在しない場合、前記前記第１拠点を到着拠点として指定する車両に対して運転手を手配することをさらに具備する請求項６〜９のいずれか１項に記載の隊列走行運用方法。

Images