JP2023049794A - 配車サーバ及び配車方法 - Google Patents

Abstract

【課題】利用者の需要に応えられない事態の発生を抑制できる配車サーバを提供する。【解決手段】配車サーバは、タクシー車両及びデマンド車両の一方の需要が高まるタイミングを予測し、前記タイミングが到来すると、前記タクシー車両及び前記デマンド車両の一方として配車するために確保する車両を、前記タクシー車両及び前記デマンド車両の他方として配車するために確保する車両よりも優先する。【選択図】図５

Description

本発明は、タクシー車両及びデマンド車両の配車を行う配車サーバ及び配車方法に関する。

従来、タクシーが普及している。タクシーとは、利用者（旅客）が運転手に乗車の申し込みを行い、個別契約で旅客輸送を行う交通機関である。

しかしながら、経済的な理由からタクシーを利用し難い利用者もいる。タクシーの代替交通機関として路線バスがある。ところが、路線バスは、例えば過疎地域等では運行本数が少なく不便である。

そこで、地域公共交通の利便性を向上させるため、近年デマンド車両を導入する地方自治体が増加している。デマンド車両とは、タクシーとして用いられる車両（タクシー車両）に該当しない車両であって、利用者の予約に応じて運行時間及び運行ルートが決定される車両である。

特許文献１では、同一の車両をタクシー車両とデマンド車両とに切り替えることを前提として運行スケジュールを決定するシステムが提案されている。特許文献１で提案されているシステムは、車両の空車率が最も低い、つまり運行効率が最も高い運行スケジュールを採用する。

特開２０１９－７８５５４号公報

同一の車両をタクシー車両とデマンド車両とに切り替えることを前提とした運用では、タクシー車両の需要に対してタクシー車両として確保する車両の台数が少なければタクシー車両の需要に応えることができず、デマンド車両の需要に対してデマンド車両として確保する車両の台数が少なければデマンド車両の需要に応えることができないという問題がある。特許文献１で提案されているシステムは、単に車両の空車率が最も低い運行スケジュールを採用するだけであるため、上記の問題を解決できない。

本発明は、上記課題に鑑みて、利用者の需要に応えられない事態の発生を抑制できる配車サーバ及び配車方法を提供することを目的とする。

例示的な本発明の配車サーバは、タクシー車両及びデマンド車両の一方の需要が高まるタイミングを予測し、前記タイミングが到来すると、前記タクシー車両及び前記デマンド車両の一方として配車するために確保する車両を、前記タクシー車両及び前記デマンド車両の他方として配車するために確保する車両よりも優先する。

例示的な本発明によると、利用者の需要に応えられない事態の発生を抑制できる。

本発明の一実施形態に係る車両運用システムの全体構成図 配車サーバの一構成例を示す図 タクシー車両配車サーバの一構成例を示す図 デマンド車両配車サーバの一構成例を示す図 配車サーバの概略動作例を示すフローチャート

以下、本発明の例示的な実施形態について、図面を参照しながら詳細に説明する。

図１は、本発明の一実施形態に係る車両運用システム１（以下、「車両運用システム１」という）の全体構成を示す図である。車両運用システム１は、配車サーバ１０と、タクシー車両配車オペレータ端末２０と、デマンド車両配車オペレータ端末３０と、車載機器４０と、を備える。

車両運用システム１は、同一の車両をタクシー車両とデマンド車両とに切り替えることを前提とするシステムである。

配車サーバ１０は、タクシー車両配車オペレータ端末２０及びデマンド車両配車オペレータ端末３０の夫々と双方向通信が可能である。配車サーバ１０は、単一の場所に設定されるサーバ装置に限定されず、構成要素が複数の場所に分散して設置される分散型のサーバ装置であってもよい。また、配車サーバ１０は、クラウドサーバで構成してもよい。

タクシー車両配車オペレータ端末２０は、タクシー車両の予約を希望する利用者からの電話を受けるオペレータによって操作される電子機器である。配車サーバ１０は、タクシー車両配車オペレータ端末２０からの指令に基づき、タクシー車両の運行計画を作成する。タクシー車両配車オペレータ端末２０は、配車サーバ１０から送信される配車通知を無線通信によって車載機器４０に転送する。

デマンド車両配車オペレータ端末３０は、デマンド車両の予約を希望する利用者からの電話を受けるオペレータによって操作される電子機器である。配車サーバ１０は、デマンド車両配車オペレータ端末３０からの指令に基づき、デマンド車両の運行計画を作成する。デマンド車両配車オペレータ端末３０は、配車サーバ１０から送信される配車通知を無線通信によって車載機器４０に転送する。

車載機器４０は、車両に搭載される電子機器である。車載機器４０は、車両に常時搭載される電子機器であってもよく、車両に一時的に搭載される電子機器であってもよい。車載機器４０は、例えばタブレット型の電子機器である。車載機器４０として、スマートフォン、携帯電話、ノート型パーソナルコンピュータ等の可搬性を有する機器を用いてもよい。

車載機器４０は、配車通知を車両の運転手に報知する。車両の運転手は、配車通知に基づき車両を運転する。なお、車両に搭載される自動運転装置が、車両の運転手に代わって又は車両の運転手を補助して、配車通知に基づき車両を自動運転してもよい。

車両運用システム１は、実際には複数の利用者及び複数の車両に対して運用されるシステムであり、車両運用システム１の管理下にある各車両に車載機器４０が搭載されることになる。但し、以下では、説明の明確化及び具体化のため、特に述べない限りは、車両及び車載機器４０として１台の車両と当該１台の車両に搭載された１台の車載機器４０にのみ注目するものとする。

図２は、配車サーバ１０の一構成例を示す図である。図２に示す構成例では、配車サーバ１０は、タクシー車両配車サーバ１１と、デマンド車両配車サーバ１２と、を備える。タクシー車両配車サーバ１１及びデマンド車両配車サーバ１２は、双方向通信によって連携して動作する。

タクシー車両配車サーバ１１は、タクシー車両配車オペレータ端末２０と双方向通信が可能である。デマンド車両配車サーバ１２は、デマンド車両配車オペレータ端末３０と双方向通信が可能である。タクシー車両配車サーバ１１は、単一の場所に設定されるサーバ装置に限定されず、構成要素が複数の場所に分散して設置される分散型のサーバ装置であってもよい。また、タクシー車両配車サーバ１１は、クラウドサーバで構成してもよい。デマンド車両配車サーバ１２は、単一の場所に設定されるサーバ装置に限定されず、構成要素が複数の場所に分散して設置される分散型のサーバ装置であってもよい。また、デマンド車両配車サーバ１２は、クラウドサーバで構成してもよい。

図３は、タクシー車両配車サーバ１１の一構成例を示す図である。図３に示す構成例では、タクシー車両配車サーバ１１は、第１制御部１１１と、第１記録部１１２と、第１通信部１１３と、を備える。

第１制御部１１１は、少なくとも一つのプロセッサを備えるコンピュータである。具体的には、第１制御部１１１は、図示しないＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、及びＲＯＭ（Read Only Memory）を備えるコンピュータである。第１制御部１１１は、第１記録部１１２に不揮発的に記録されたプログラムに基づいて情報の処理及び送受信を行い、タクシー車両配車サーバ１１の全体を制御する。第１通信部１１３は、タクシー車両配車オペレータ端末２０及びデマンド車両配車サーバ１２の夫々と通信を行う。

第１記録部１１２は、タクシー車両に関する過去の予約情報、タクシー車両に関する現在の予約状況、タクシー車両に関する運行計画、タクシー車両の予約を過去に行った利用者の特性に関する情報（車椅子の使用有無等）、車両運用システム１によって管理されている車両の情報（サイズ、乗車定員、車椅子の対応可否等の情報）、運行中のタクシー車両の位置情報を記録する。なお、運行中のタクシー車両の位置情報は、運行中のタクシー車両に搭載されている車載機器４０からタクシー車両配車サーバ１１に周期的に送信されるようにすればよい。

図４は、デマンド車両配車サーバ１２の一構成例を示す図である。図４に示す構成例では、デマンド車両配車サーバ１２は、第２制御部１２１と、第２記録部１２２と、第２通信部１２３と、を備える。

第２制御部１２１は、少なくとも一つのプロセッサを備えるコンピュータである。具体的には、第２制御部１２１は、図示しないＣＰＵ、ＲＡＭ、及びＲＯＭを備えるコンピュータである。第２制御部１２１は、第２記録部１２２に不揮発的に記録されたプログラムに基づいて情報の処理及び送受信を行い、デマンド車両配車サーバ１２の全体を制御する。第２通信部１２３は、デマンド車両配車オペレータ端末３０及びタクシー車両配車サーバ１１の夫々と通信を行う。

第２記録部１２２は、デマンド車両に関する過去の予約情報、デマンド車両に関する現在の予約状況、デマンド車両に関する運行計画、デマンド車両の予約を過去に行った利用者の特性に関する情報（車椅子の使用有無等）、車両運用システム１によって管理されている車両の情報（サイズ、乗車定員、車椅子の対応可否等の情報）、運行中のデマンド車両の位置情報を記録する。なお、運行中のデマンド車両の位置情報は、運行中のデマンド車両に搭載されている車載機器４０からデマンド車両配車サーバ１２に周期的に送信されるようにすればよい。

次に、配車サーバ１０の動作について説明する。配車サーバ１０は、車両運用システム１の稼働中に図５に示すフローチャートの動作を行う。

まず、第１制御部１１１及び第２制御部１２１は、タクシー車両及びデマンド車両の一方の需要が高まるタイミング（第１タイミング）を予測する（ステップＳ１０）。つまり、第１制御部１１１及び第２制御部１２１は、予測装置の機能を有する。

例えば、第１制御部１１１及び第２制御部１２１は、タクシー車両及びデマンド車両の一方として配車するために確保する車両の台数が規定の数より少なくなったときを第１タイミングとみなしてもよい。この手法によると、第１制御部１１１及び第２制御部１２１は、第１タイミングの予測を容易に実施することができる。タクシー車両として配車するために確保する車両（空きタクシー車両）の台数に関する規定の数と、デマンド車両として配車するために確保する車両（空きデマンド車両）の台数に関する規定の数とは、同じ数であってもよく、互いに異なる数であってもよい。

また例えば、第１制御部１１１及び第２制御部１２１は、過去の予約情報に基づき第１タイミングを予測してもよい。より具体的には、第１制御部１１１及び第２制御部１２１は、過去の同じ曜日同じ時刻の予約情報から第１タイミングを予測してもよく、過去の同じ月日同じ時刻の予約情報から第１タイミングを予測してもよい。この手法によると、利用者が規則的な予約を行う場合に、第１制御部１１１及び第２制御部１２１は、第１タイミングを精度良く予測することができる。

次に、第１制御部１１１及び第２制御部１２１は、第１タイミングが到来したか否かを判定する（ステップＳ２０）。第１制御部１１１及び第２制御部１２１によって第１タイミングが到来したと判定されない場合（ステップＳ２０でＮＯ）、ステップＳ２０から後述するステップＳ４０に直接移行する。

第１制御部１１１及び第２制御部１２１は、第１タイミングが到来したと判定した場合（ステップＳ２０でＹＥＳ）、タクシー車両及びデマンド車両の一方（需要が高まると予測された方）として配車するために確保する車両を、タクシー車両及び前記デマンド車両の他方として配車するために確保する車両よりも優先する（ステップＳ３０）。このステップＳ３０の処理によって、利用者の需要に応えられない事態の発生を抑制できる。ステップＳ３０では車両の確保が行われているため、第１制御部１１１及び第２制御部１２１は、車両確保装置の機能を有する。

例えば、ステップＳ３０において、第１制御部１１１及び第２制御部１２１は、タクシー車両及びデマンド車両の一方として配車するために確保する車両の台数を、タクシー車両及び前記デマンド車両の他方として配車するために確保する車両の台数より多くしてもよい。

例えば、ステップＳ３０において、第１制御部１１１及び第２制御部１２１は、タクシー車両及びデマンド車両の一方として配車するために確保する車両の台数を、タクシー車両及び前記デマンド車両の他方として配車するために確保する車両の台数より多くしてもよい。

また例えば、ステップＳ３０において、第１制御部１１１及び第２制御部１２１は、タクシー車両及びデマンド車両の一方として配車するために確保する車両に関する規定の数に対するタクシー車両及びデマンド車両の一方として配車するために確保する車両の余裕度を、タクシー車両及びデマンド車両の他方として配車するために確保する車両に関する規定の数に対するタクシー車両及びデマンド車両の他方として配車するために確保する車両の余裕度より大きくしてもよい。具体例を挙げて説明すると、ステップＳ３０の処理前に、タクシー車両及びデマンド車両の一方として配車するために確保する車両に関する規定の数を２台とし、タクシー車両及びデマンド車両の他方として配車するために確保する車両に関する規定の数を１台とする。そして、ステップＳ３０の処理前に、タクシー車両及びデマンド車両の一方として配車するために確保する車両が４台あり、タクシー車両及びデマンド車両の他方として配車するために確保する車両が３台あるものとする。この場合、余裕度はいずれも２台である。ステップＳ３０の処理によって、タクシー車両及びデマンド車両の一方として配車するために確保する車両を５台とし、タクシー車両及びデマンド車両の他方として配車するために確保する車両が２台とし、タクシー車両及びデマンド車両の一方に関する余裕度を３台とし、タクシー車両及びデマンド車両の他方に関する余裕度を１台とすればよい。

また例えば、ステップＳ３０において、第１制御部１１１及び第２制御部１２１は、タクシー車両及びデマンド車両の一方として配車するために確保する車両の台数を過去の予約情報に基づき設定してもよい。この手法によると、利用者の需要に応えられない事態の発生をより確実に抑制できる。具体的には、第１制御部１１１及び第２制御部１２１は、過去の同じ曜日同じ時刻の予約情報又は過去の同じ月日同じ時刻の予約情報を用いて、同じ内容の予約が入った場合に必要となるタクシー車両及びデマンド車両の一方の台数を算出し、その台数分の車両をタクシー車両及びデマンド車両の一方として配車するために確保すればよい。

また例えば、ステップＳ３０において、第１制御部１１１及び第２制御部１２１は、タクシー車両及びデマンド車両の一方として配車するために確保する車両の少なくとも一部の車種を、過去の予約情報に含まれる利用者の特性に基づき設定してもよい。この手法によると、利用者の利便性が向上する。具体的には、第１制御部１１１及び第２制御部１２１は、過去の同じ曜日同じ時刻の予約情報又は過去の同じ月日同じ時刻の予約情報に車椅子を使用する利用者がいる場合、タクシー車両及びデマンド車両の一方として配車するために確保する車両の少なくとも一部を、車椅子に対応可能な車両（いわゆる福祉車両）にすればよい。

また例えば、ステップＳ３０において、第１制御部１１１及び第２制御部１２１は、タクシー車両又はデマンド車両として運行中の車両の位置情報に基づき、タクシー車両又はデマンド車両として運行中の車両を、タクシー車両又はデマンド車両として配車するために確保する車両に含めることが可能か否かを判断してもよい。たとえ運行中の車両であっても、運行中の車両の位置と予約の内容次第でタクシー車両又はデマンド車両として配車するために確保する車両に含めることができるからである。この手法によると、タクシー車両又はデマンド車両として配車するために確保する車両を増やすことができるため、利用者の需要に応えられない事態の発生をより確実に抑制できる。

なお、第１タイミングは、タクシー車両及びデマンド車両の一方のみのではなく他方も需要が高まるタイミングとなる場合がある。つまり、第１タイミングは、タクシー車両及びデマンド車両の両方の需要が高まるタイミングとなる場合がある。第１タイミングがタクシー車両及びデマンド車両の両方の需要が高まるタイミングである場合、ステップＳ３０において、第１制御部１１１及び第２制御部１２１は、デマンド車両として配車するために確保する車両を、タクシー車両として配車するために確保する車両よりも優先すればよい。公共性の観点から、基本的にデマンド車両の予約を断ることは許容されていないからであある。この手法によると、利用者のデマンド車両に対する需要に応えられない事態の発生をより確実に抑制できる。

ステップＳ３０続くステップＳ４０において、第１制御部１１１は、タクシー車両配車オペレータ端末２０から予約情報を受け取っていればタクシー車両の運行計画を更新し、第２制御部１２１は、デマンド車両配車オペレータ端末３０から予約情報を受け取っていればデマンド車両の運行計画を更新する。なお、第１制御部１１１及び第２制御部１２１の両方が予約情報を受け取っていない場合、ステップＳ４０の処理はスキップされる。

ステップＳ４０の処理が終了又はスキップされると、ステップＳ１０に戻って図５に示すフロー動作が継続される。

上記実施形態は、全ての点で例示であって、制限的なものではないと考えられるべきであり、本発明の技術的範囲は、上記実施形態の説明ではなく、特許請求の範囲によって示されるものであり、特許請求の範囲と均等の意味及び範囲内に属する全ての変更が含まれると理解されるべきである。

１ 車両運用システム
１０ 配車サーバ
１１ タクシー車両配車サーバ
１１１ 第１制御部
１１２ 第１記録部
１１３ 第１通信部
１２ デマンド車両配車サーバ
１２１ 第２制御部
１２２ 第２記録部
１２３ 第２通信部
２０ タクシー車両配車オペレータ端末
３０ デマンド車両配車オペレータ端末
４０ 車載機器

Claims (8)

1. タクシー車両及びデマンド車両の一方の需要が高まるタイミングを予測し、前記タイミングが到来すると、前記タクシー車両及び前記デマンド車両の一方として配車するために確保する車両を、前記タクシー車両及び前記デマンド車両の他方として配車するために確保する車両よりも優先する、配車サーバ。
2. 前記タクシー車両及び前記デマンド車両の一方として配車するために確保する車両の台数が規定の数より少なくなったときを前記タイミングとみなす、請求項１に記載の配車サーバ。
3. 過去の予約情報に基づき前記タイミングを予測する、請求項１又は請求項２に記載の配車サーバ。
4. 前記過去の予約情報に基づき予測した前記タイミングが到来したときに、前記タクシー車両及び前記デマンド車両の一方として配車するために確保する車両の台数を前記過去の予約情報に基づき設定する、請求項３に記載の配車サーバ。
5. 前記過去の予約情報に基づき予測した前記タイミングが到来したときに、前記タクシー車両及び前記デマンド車両の一方として配車するために確保する車両の少なくとも一部の車種を、前記過去の予約情報に含まれる利用者の特性に基づき設定する、請求項４に記載の配車サーバ。
6. 前記タクシー車両又は前記デマンド車両として運行中の車両の位置情報に基づき、前記タクシー車両又は前記デマンド車両として運行中の車両を、前記タクシー車両又は前記デマンド車両として配車するために確保する車両に含めることが可能か否かを判断する、請求項１～５のいずれか一方に記載の配車サーバ。
7. 前記タイミングが前記タクシー車両及び前記デマンド車両の両方の需要が高まるタイミングである場合、前記タイミングが到来すると、前記デマンド車両として配車するために確保する車両を、前記タクシー車両として配車するために確保する車両よりも優先する、請求項１～６のいずれか一方に記載の配車サーバ。
8. 予測装置が、タクシー車両及びデマンド車両の一方の需要が高まるタイミングを予測する第１の工程と、
   前記タイミングが到来すると、車両確保装置が、前記タクシー車両及び前記デマンド車両の一方として配車するために確保する車両を、前記タクシー車両及び前記デマンド車両の他方として配車するために確保する車両よりも優先する第２の工程と、
   を備える、配車方法。

Images