(57)【特許請求の範囲】
【請求項１】
エリア内に設けられた複数のポートで発生した乗車需要に応じて車両を配車する配車システムにおいて、
全ポートの乗車需要統計データに基づいて設定した予測乗車需要データを格納した予測乗車需要データ記憶手段と、
各ポートの現有車両数を検出する車両数検出手段と、
各ポートの現状の乗車需要の数と行先ポートを含む乗車需要情報を検出するデマンド検出手段と、
他のポートから発車した車両の各ポートへの到着を、前記行先ポートに基づいて予測到着車両数として予測する到着車両予測手段と、
各ポートにおける所定時間の検索範囲での前記現状の乗車需要の数および前記予測乗車需要データと前記現有車両数および前記予測到着車両数との比較により車両の過不足を計算する過不足算出手段と、
前記過不足の計算結果に基づき、余剰車両を有するポートから車両が不足しているポートへ車両を再配車する再配車手段とを具備した配車システム。
【請求項２】
前記検索範囲は、ポート相互間で再配車のために車両を移動させるのに要する最小移動時間以上に設定したことを特徴とする請求項１記載の配車システム。
【請求項３】
互いに異なる複数の検索範囲をパラメータとした場合の前記エリア内における総車両数および再配車数のデータをもとに、予め設定した再配車数を超過しないように前記複数の検索範囲から１つを選択するようにしたことを特徴とする請求項１記載の配車システム。
【請求項４】
互いに異なる複数の検索範囲をパラメータとした場合の前記エリア内における総車両数および平均待ち時間のデータをもとに、予め設定した待ち時間の上限を超過しないように前記複数の検索範囲から１つを選択するようにしたことを特徴とする請求項１記載の配車システム。
【請求項５】
前記検索範囲は、１日のうちで可変とすることを特徴する請求項１記載の配車システム。
【請求項６】
前記検索範囲は、１日のうちで前記予測需要が所定以上となった場合に、該予測需要が所定以下の場合より短くすることを特徴とする請求項５記載の配車システム。
【請求項７】
検索範囲をパラメータとしたときの再配車数および平均待ち時間の積をシミュレーションし、このシミュレーション結果に基づいて前記積が極小値となる検索範囲を選択したことを特徴とする請求項１記載の配車システム。
【請求項８】
前記検索範囲は、前記エリア内の総車両数が所定数未満の場合に、前記各ポート間で再配車するときの車両の最大移動時間の近傍に設定することを特徴とする請求項１記載の配車システム。
【請求項９】
前記再配車手段は、各ポートの駐車場の収容台数が前記現有車両数および予測到着車両数の合計台数以下の場合に、該ポートが余剰車両を有するか否かによらず再配車を行うことを特徴とする請求項１記載の配車システム。
【請求項１０】
前記再配車は、前記現有車両数が最も少ないポートに対して行うことを特徴とする請求項９記載の配車システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、配車システムに関し、特に、複数のポートを含む一定のエリア内で各ポートでの乗車需要に応じて安定的に車両を供給（配車）することができる配車システムに関する。
【０００２】
【従来の技術】
エリア内に配備した所定台数の車両を複数のポートで発生した乗車需要に対応して配車するシステムにおいて、エリア内の各ポートで発生した乗車需要に対して車両が不足することがある。この場合、他のポートで余っている車両を他のポートから移動（以下、「再配車」という）して乗車需要に応じるようにする配車システムが考えられる。
【０００３】
しかし、この配車システムは、車両の不足が生じた場合に、事後的に対応するシステムであるので、他のポートから当該ポートに車両が到着するまでに時間がかかる。また、再配車中に新たに発生する乗車需要や、再配車前に他のポートを出発していた車両の到着により、各ポートにおいて新たに車両の過不足が生じることがあり、乗車需要に対して所望の待ち時間を安定的に設定することができない。
【０００４】
上記不具合を解消するため予測乗車需要データに基づいて再配車することが考えられる。例えば、各ポートの現有車両数と、そのポートで現在発生している乗車需要および過去の乗車需要統計データとに基づいて乗車需要を予測した予測乗車需要データに従って車両を配車することが考えられる。乗車需要予測に基づいて車両を配車する例として、特開平９−１５３０９８号公報に記載された車両需要予測システムがある。
【０００５】
【発明が解決しようとする課題】
上記車両需要予測システムでは、計算された車両需要予測をどこまで考慮して配車するかは人の判断に委ねられていた。したがって、その時々の判断によって配車指示にばらつきが生じ、安定的に配車できないという問題点があった。
【０００６】
本発明は、上記問題点に鑑み、人の判断によらず、安定して乗車需要に応じることができる配車システムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記の課題を解決し、目的を達成するための本発明は、エリア内に設けられた複数のポートで発生した乗車需要に応じて車両を配車する配車システムにおいて、前記各ポートにおける所定時間の検索範囲での現状の乗車需要数および予測乗車需要データと現有車両数および予測到着車両数との比較により車両の過不足を計算する過不足算出手段と、前記過不足の計算結果に基づき、余剰車両を有するポートから車両が不足しているポートへ車両を再配車する再配車手段とを具備した点に特徴がある。
【０００８】
上記特徴によれば、各ポートでの乗車需要予測および到着車両数予測が、予め定めた検索範囲（時間）内でのみ行われる。そして、この予測結果と現状の乗車需要および現状の車両数とに基づいて車両の過不足を計算し、車両が余っているポートから不足しているポートへ再配車が行われる。
【０００９】
【発明の実施の形態】
以下に、図面を参照して本発明を詳細に説明する。図１は本発明の一実施形態に係る配車システムの概要を示す系統図であり、ここでは、エリア内に５つのポートが設けられている場合を想定する。ポートＰ１，Ｐ２，Ｐ３，Ｐ４，Ｐ５（以下、特定のポートを示さない場合は、単に「ポートＰ」と総称する）は、ゴルフ場、空港、ホテル等に設けられた所定の駐車スペースであり、エリア内には車両４が複数台配備される。ポートＰには端末２がそれぞれ設けられている。また、各端末２にはポートＰにおける車両の出入りを検出するセンサ３がそれぞれ接続されている。
【００１０】
センサ３は車両４を特定するためその車両番号を識別する機能を有するが、ここでいう車両番号は、車両前後に取り付けられたナンバプレートに表された車両番号であってもよいし、車両の側部や上部等、検出に適したように特別に記載された車両番号であってもよい。また車両番号は数字に限らず、バーコードや文字・記号等の符号を用いた識別情報であってもよい。センサ３としては、車両に記された前記車両番号を光学的に読取るための光学センサを使用できる。
【００１１】
端末２は車両利用者を識別する識別装置（図示せず）を有していて、この識別装置は利用者が入力するＩＤ番号等から利用者が登録された契約者であるか否かを判別する。ＩＤ番号等はＩＣカードに記述されているのが好ましい。前記識別装置は利用開始時に利用者が差し出したＩＣカードの情報を読み取るとともに、車両の利用を終えたときに車両の使用終了を認識するため利用者が差し出したＩＣカードの情報を読み取る。端末２は利用者が行先を入力するための入力装置（図示せず）を有する。この入力装置は、例えばポート名に対応したスイッチで構成することができる。
【００１２】
車両４は、例えば自走可能な電気自動車であり、利用者に対する車両の利用許可がなされた場合にドアロックが解除されて始動が可能になるように構成する。なお、自動的にドアロックが解除されるものに限らず、利用者が前記ＩＣカードを使ってドアロックを解除するようにしてもよい。いずれの場合も、乗車するポートＰの端末２でＩＣカードの利用者を識別する識別情報（ＩＤ番号等）が認識されたことを前提とするのが好ましい。
【００１３】
端末２は通信回線によりホストコンピュータ（以下、「ホスト」という）１と接続されていて、端末２とホスト１間では互いにデータの授受がなされる。利用者が乗車するポートＰの端末２は、該ポートＰの現有車両番号および車両数、ならびに契約者ＩＤ番号、および乗車需要（デマンド）等をホスト１に送信する。デマンドは利用者がＩＤ番号を入力したときに発生する。なお、デマンドには行先情報が含まれる。ホスト１は、前記ＩＤ番号に基づいて契約者の個人情報を参照し、車両の利用を許可すべきか否かを判断した後、端末２に貸出許可および貸出車両を指示する。貸出許可および貸出車両の指示により現実に乗車が可能になる。貸出許可および貸出車両の指示がなされたときに「発生トリップ」が生じる。
【００１４】
一方、利用者が到着したポートＰの端末２は、該ポートＰの現有車両番号および車両数、ならびに契約者ＩＤ番号、到着認識情報（到着トリップ）、および契約者走行データ等をホスト１に送信する。到着トリップは前記発生トリップに対応する車両４がポートＰへ入場したことをセンサ３で検出したときに出力される。
【００１５】
ホスト１は、端末２から入力された情報に基づいて端末２に貸出許可および貸出車両を指示するための演算を行う演算手段（ＣＰＵ）１０と記憶装置（メモリ）１１とを有するとともに、各車両４へ指示を与えるための通信装置１２を有している。記憶装置１１には各ポートＰ毎の予測乗車需要データ（以下、「予測発生トリップという」）、契約者情報、契約者走行データ等が格納されている。予測発生トリップは過去のデマンド実績をもとに設定した１日のデマンド見込みである。契約者情報は前記ＩＤ番号に対応させた契約者の名前等の個人情報である。契約者走行データは走行距離や走行時間であり、契約者への課金のための情報である。
【００１６】
図２は、前記端末２およびホスト１の要部機能を示すブロック図である。端末２は、デマンド、到着トリップ、契約者ＩＤ、および現有車両数をホスト１に通知するためのデマンド通知部２０、到着トリップ通知部２１、契約者ＩＤ通知部２２、および現有車両数通知部２３を有している。デマンド通知部２０は利用者が入力したＩＤ番号を認識したときにデマンド発生を通知し、到着トリップ通知部２１はセンサ３による車両入場の検出結果を通知する。契約者ＩＤ通知部２２はＩＣカード等から読み込まれたＩＤ番号を通知する。現有車両数通知部２３は前記センサ３で検出された車両番号および車両の出入りの検出結果に基づいて計数された現有車両数を通知する。
【００１７】
さらに、端末２は利用者に乗車車両を指示または案内するための表示装置２４を有する。この表示装置２４はホスト１から入力される貸出許可等に基づいて表示を行うものであり、画情報によって案内するものであってもよいし、音声によって案内するものであってもよい。端末２はホスト１とのデータ通信を行うための通信インタフェース２５を有している。なお、表示装置２４は乗車可能な車両４がポートＰに存在していて、ＩＤコードの入力後直ちに乗車車両指示を出すことができる場合には、車両番号等の案内を行い、車両４が不足している場合には予測待ち時間を案内するようにしてもよい。
【００１８】
ホスト１のメモリ１１は予測発生トリップ記憶部１１０と契約者情報記憶部１１１とを有している。予測発生トリップ記憶部１１０は１日のデマンド実績を各ポートＰ毎に時系列のデータとして蓄積し、予測発生トリップとしてＣＰＵ１０に供給する。予測発生トリップは天候、日時、曜日等毎に過去のデマンド実績を蓄積しておき、その日時、天候、曜日等に応じた予測発生トリップをＣＰＵ１０へ供給できるようにしておくとよい。契約者情報記憶部１１１には前記契約者情報や契約者走行データが記憶される。契約者情報は予め登録されたものであり、契約者走行データは端末２から入力されたものである。
【００１９】
ＣＰＵ１０は通信インタフェース１０７によって端末２の通信インタフェース２５と接続されている。ＣＰＵ１０の需要数判別部１０１は、メモリ１１の予測発生トリップに基づいて、１時間あたりに発生が予測されるデマンドを判別する。ＳＤ設定部１０２は前記予測されるデマンドが基準台数を上回っているか否かによって、予測発生トリップのうち、現時点から何時間（又は何分後）までのものを検索するか、つまり検索範囲（以下、「サーチ・デプス時間：ＳＤ時間」ともいう）を決定できる。ＳＤ時間の決定アルゴリズムについては後述する。
【００２０】
予測乗車需要検出部１０３はＳＤ設定部１０２で決定されたＳＤ時間内での予測発生トリップを予測発生トリップ記憶部１１０から読み込み、過不足数算出部１０４に出力する。過不足数算出部１０４は端末２から入力されたポートＰ毎のデマンドおよび現有車両数、ならびに前記予測発生トリップに基づいて車両の過不足数を算出する。車両の過不足数は前記デマンドに含まれる行先情報によって予定される行先ポートでの到着トリップを考慮して算出される。
【００２１】
再配車設定部１０５は各ポートＰの車両４の過不足数に基づいて、余剰の車両４を他のポートＰに移動つまり再配車するための指示を出力する。この再配車指示は通信装置１２を通じて車両４に通知される。再配車に応じることができるように車両４には通信装置と自動走行装置とが設けられている。自動走行装置は地図データおよびＧＰＳを利用した位置検知システム、および信号機や障害物の監視システム等を利用した既知のシステムを採用することができる。
【００２２】
配車設定部１０６は乗車可能な車両があれば、直ちに貸出許可および貸出車両を端末２に通知する。また、車両が不足している場合には、到着トリップや前記再配車設定部１０５で指示された再配車の到着予定時刻等に基づいて待ち時間を算出し、端末２に通知する。それにより利用者は待ち時間を認識する。
【００２３】
続いて、具体的な配車の例を説明する。各ポートＰの現有車両数と現時点でのデマンドのみによって車両の再配車を行うと、デマンドの変動や車両の移動による新たな車両の過不足が生じるため効率的な配車を行えない。そこで、本実施形態では、予め設定したＳＤ時間内でのデマンドや到着トリップを勘案して車両の過不足を算出し、再配車を行う。図３は、各ポートＰにおける発生トリップと到着トリップの発生による車両数の変化を示した図である。この図では、現ＳＤ時間で予想されるトリップの発生を見越しているが、再配車分は考慮していない。
【００２４】
同図において、ポートＰ１ではデマンドが「３」であり現有車両数は「０」であるので、現時点では車両が３台不足している。このポートＰ１では、現時点以前において他のポートで生じた発生トリップによる到着トリップＴａ１と、ポートＰ３において生じた現ＳＤ時間当初の発生トリップＴｄ３による到着トリップＴａ１１とがある。一方、予測発生トリップＴｆ１が発生すると予測されているので合計デマンドは「４」となる。したがって、現ＳＤ時間内で使用可能な車両数は「２」に対してデマンドは「４」であるので、結果的に２台の車両が不足している。
【００２５】
ポートＰ２ではデマンドが「０」であり現有車両数は「５」であるので、現時点では車両が５台余っている。このポートＰ２では、予測発生トリップＴｆ２，Ｔｆ２１が発生すると予測されているので合計デマンドは「２」となる。したがって、現ＳＤ時間内で使用可能な車両数は「５」に対してデマンドは「２」であるので、結果的に３台の車両が余る。
【００２６】
ポートＰ３ではデマンドが「５」であり現有車両数は「２」であるので、現時点では車両が３台不足している。このポートＰ３では、現有車両が２台あるので２つのデマンドに直ちに応答して発生トリップＴｄ３，Ｔｄ３１が発生する。また、それ以前のＳＤ時間において他のポートで生じた発生トリップによる到着トリップＴａ３，Ｔａ３１がある。予測発生トリップはないので合計デマンドは「５」から変わらない。その結果、現ＳＤ時間内で使用可能な車両数は「４」に対してデマンドは「５」であるので、車両が１台不足している。
【００２７】
ポートＰ４ではデマンドが「１」であり現有車両数は「１」であるので、現時点では車両の過不足はない。このポートＰ４では、現有車両が１台あるのでデマンドに直ちに応答して発生トリップＴｄ４が発生する。また、このポートＰ４では、予測発生トリップＴｆ４があると予測されているので合計デマンドは「２」となる。また、ポートＰ３で生じた発生トリップによる到着トリップＴａ４が発生すると予測される。したがって、現ＳＤ時間内で使用可能な車両数は「２」に対してデマンドは「２」であるので、車両の過不足はない。
【００２８】
ポートＰ５ではデマンドが「０」であり現有車両数は「１」であるので、現時点では車両が１台余っている。このポートＰ５では、ポートＰ４での発生トリップＴｄ４による到着トリップＴａ５があり、かつ、それ以前のＳＤ時間において他のポートで生じた発生トリップによる到着トリップＴａ５１がある。また、予測発生トリップＴｆ５があると予測されているので合計デマンドは「１」となる。その結果、現ＳＤ時間内で使用可能な車両数は「３」に対してデマンドは「１」であるので、車両は２台余っている。
【００２９】
上記ＳＤ時間内での車両数やデマンドの変動を前提に再配車を設定する。以下、再配車のアルゴリズムを段階的に説明する。まず第１段階として、ＳＤ時間内に再配車可能なポートと車両数を検出する。上述の場合では、ポートＰ２とポートＰ５とで車両が余っているので再配車が可能である。第２段階として、余っている車両を再配車した後の残り車両数を求める。そして、第３段階としてこの残り車両数によって次に発生するデマンドに応じることができるかを判別する。すなわち、すべての車両を再配車した後、到着トリップ等によって該ポートＰの車両数が回復するより前にデマンドが発生した場合にはそのデマンドに直ちに応答できない。そこで、残り車両数が次に発生するデマンド分の車両として使用できる見込みがあれば実際に再配車実行可とする。
【００３０】
上述の場合では、ポートＰ２において、余剰分の３台を再配車したとしても車両は２台残っているので、次に発生する予測発生トリップＴｆ２に応じてもさらに１台の余剰がある。したがって、ポートＰ２では３台の再配車を行う余裕があり、再配車実行可能である。一方、ポートＰ５では、余剰分の２台を再配車すると残り車両数は１台となり、次に発生する予測発生トリップＴｆ５に応ずると残りはなくなる。このように、ポートＰ５では再配車すると残り車両数に余裕がなくなるので再配車実行不可とする。
【００３１】
さらに好ましくは、車両が不足しているポートＰに最も近いポートＰから再配車するのがよい。例えばポートＰ５に次の発生デマンドがないとした場合、ポートＰ２とポートＰ５の双方から再配車が可能であり、車両が不足しているポートにより近い方から再配車する。ここでは、車両が不足しているポートＰ１とポートＰ３により近いのがポートＰ５よりもポートＰ２であるとの想定の下、ポートＰ２からポートＰ１へ２台、ポートＰ２からポートＰ３へ１台再配車をしている。
【００３２】
上記検討結果に基づいて再配車した場合の、ＳＤ時間内での各ポートＰでの車両数の変化を図４に示す。同図において、ポートＰ１では、現デマンドの利用者の１人は到着トリップＴａ１の車両に乗車でき、２，３番目の利用者はポートＰ２から再配車された２台の車両（Ｄｖ１，Ｄｖ２）に乗車できる。そして、予測発生トリップＴｆ１の利用者は到着コマンドＴａ１１の車両に乗車できる。
【００３３】
ポートＰ２では２台の車両（ｄ１，ｄ２）をポートＰ１に再配車し、１台の車両（ｄ３）をポートＰ３に再配車した。そして、予測発生トリップＴｆ２の利用者は現有車両（Ｖ１）に乗車でき、予測発生トリップＴｆ２１の利用者は現有車両（Ｖ２）に乗車できる。
【００３４】
ポートＰ３では現有車両が２台あるので５個のデマンドのうち２個には直ちに応答でき、２人の利用者は発生トリップＴｄ３，Ｔｄ３１の車両に乗車できる。また、３人目と４人目の利用者は到着トリップＴａ３，Ｔａ３１の車両に乗車でき、５人目の利用者はポートＰ２から再配車された車両（Ｄｖ３）に乗車できる。
【００３５】
ポートＰ４では現有車両が１台あるので１個あるデマンドに直ちに応答でき、利用者は発生トリップＴｄ４の車両に乗車できる。また、予測発生トリップに対応する利用者は到着トリップＴａ４の車両に乗車できる。さらに、ポートＰ４では到着トリップＴａ４１があるが、これは、ポートＰ５での予測発生トリップＴｆ５に基づくものであり予測不能であり、再配車検討時には考慮されていない。
【００３６】
ポートＰ５では現有車両が１台あるがデマンドはないので発生トリップは直ちには生じない。予測発生トリップＴｆ５の利用者は現有車両Ｖ５に乗車できる。その後に発生する到着トリップＴａ５，Ｔａ５１の車両は、再配車されないでそのまま残る。ポートＰ５では、ポートＰ４で生じた予測発生トリップＴｆ４に基づく到着トリップＴａ５２があるが、これは予測不能なものであり、再配車検討時には考慮されていないが、統計データに基づき、この到着トリップＴａ５２を考慮して計算してもよい。
【００３７】
このようにして、結果的に、ポートＰ１〜ポートＰ３ではＳＤ時間内で過不足なく需要に対応でき、さらにポートＰ４では１台、ポートＰ５では３台の車両が残ることになる。
【００３８】
上述の例では、現ＳＤ時間内でデマンドに応じることができた。しかし、このＳＤ時間内でデマンドに応じることができなかった場合は、不足している車両は次のＳＤ時間の再配車の検討時まで持ち越す。また、予め最大待ち時間を設定しておき、この現ＳＤ時間で設定最大待ち時間を越える場合は、先に再配車しないと決定したポートＰをも含めて再配車可能車両を再配車してデマンドに応じる。
【００３９】
次に、上述の再配車の処理をフローチャートを参照してさらに説明する。図５は車両の過不足計算処理のフローチャートである。ステップＳ１では、ポートＰを示すパラメータＰに「０」をセットし、ステップＳ２ではそのパラメータＰをインクリメント（＋１）する。つまり以下の処理はパラメータＰで代表されるポートに関する。ステップＳ３では持越し到着トリップつまり前回計算までに生じた発生トリップに基づく到着トリップ数をパラメータＮTAとしてセットする。ステップＳ４では現有車両数をパラメータＮPVとしてセットする。ステップＳ５では現有デマンド数をパラメータＤP にセットする。ステップＳ６では予測発生トリップ数をパラメータＤT にセットする。
【００４０】
ステップＳ７では到着トリップが現ＳＤ時間に発生するか否かを判別する。これは、他のすべてのポートの発生トリップの有無、およびその発生トリップのもとになったデマンドに含まれる行先情報に自己のポートが含まれていて、該ＳＤ時間内に到着するか否かの計算により判別する。この計算は、ポート間の既知の距離および車両の予定走行速度に基づいて行う。ステップＳ７が肯定ならばステップＳ８に進み、この到着トリップ数（ＮTA´）を前記到着トリップ数ＮTAおよび現有車両数ＮPVに加算して使用可能な車両数ＮＰとする。
【００４１】
ステップＳ９では過不足の演算を行う。つまり車両数ＮＰから現有デマンド数ＤP および予測発生トリップ数ＤT を減算して過不足数ＶＮＰを求める。ステップＳ１０では再配車後の車両数は十分か否かを判別する。これは過不足の計算によって余っていると判断された車両を再配車した場合に残り車両があって、しかも次の発生デマンドに応じることができるか否かによって判断する。この判断が肯定ならばステップＳ１１に進み、再配車実行可を示すためフラグＰＦを立てる。一方、再配車実行不可ならばステップＳ１２に進んでフラグＰＦをクリアする。  ステップＳ１３では、パラメータＰが「５」になったか、つまりすべてのポートについて車両の過不足数を計算したか否かを判別する。この判断が肯定となるまではステップＳ２に進んで計算を続け、ポートＰ１〜Ｐ５の車両過不足数を求める。
【００４２】
次に、前記車両の過不足計算結果に基づく再配車設定処理を説明する。図６のフローチャートにおいて、ステップＳ２０では、ポートＰを示すパラメータＰに「０」をセットし、ステップＳ２１ではそのパラメータＰをインクリメント（＋１）する。ステップＳ２２ではポートＰに配車可能な車両があるか否かを前記フラグＰＦが立っているか否かによって判断する。再配車可能と判断すればステップＳ２３に進み、該ポートＰから予定距離のポートに車両が不足しているものがあるかを判別する。これは、できるだけ近いポートに優先的に再配車するため、予め定めた最小距離内のポートの車両不足の有無を判別するものである。
【００４３】
ステップＳ２３が肯定ならばステップＳ２４に進み、該ポートＰから、車両が不足している他のポートへ再配車する。但し、ＳＤ時間内で車両の余剰があると計算された場合であっても、現有車両がない場合も想定される。したがって、現有車両の範囲内で再配車するようにする。再配車をしたならばステップＳ２５に進み、再配車による変動をもとに各ポートの車両過不足数を変更する。
【００４４】
ステップＳ２６ではパラメータＰを判別してすべてのポートＰに関して処理を行ったか否かを判別する。この判別が肯定ならばステップＳ２７に進み、車両不足のポートが依然として存在するかを判別する。これが否定ならば処理を終えるし、肯定ならばステップＳ２８に進み、このＳＤ時間で再配車をしないと予め設定した最大待ち時間が超過するか否かを判別する。これが否定ならばステップＳ２９に進んで、不足車両を次のＳＤ時間のデマンドとして持ち越す。すなわち、次の車両過不足計算時の現有デマンドとして残る。
【００４５】
また、最大待ち時間を超過する場合は、現ＳＤ時間で不足を解消するため、さらに遠いポートに余剰車両がないかを検索する。そのために、ステップＳ３０では検索するポートを拡大するため距離設定を増大する。
【００４６】
距離を増大した結果、たとえ車両に余剰のあるポートが存在していても、そこから再配車したのでは結局最大待ち時間を超過することがある。そこで、ステップＳ３１では、新たに設定した距離のポートからの再配車により最大待ち時間内で車両の不足が解消されるか否かを判断する。この判断が肯定ならば、遠くからの再配車は断念してステップＳ２９に進み、次のＳＤ時間で不足車両を補うようにする。
【００４７】
ステップＳ３１が否定ならばステップＳ２０に戻る。そして、ステップＳ３０を処理した後のステップＳ２３では、前回よりもさらに遠くのポートに不足車両があるか否かが判別される。
【００４８】
次に、ＳＤ時間設定のためのアルゴリズムについて説明する。図７は、各ポート間の再配車の所要時間を示す図である。同図に示すように、最も遠いポート間の所要時間は３０分であり、最も近いポート間でも所要時間は５分である。この図から明らかなように、５分未満のＳＤ時間で再配車可能な車両数を決定しても、そのＳＤ時間では再配車された車両が予定のポートにまで到達しない。また、５分以上７分未満のＳＤ時間ではポートＰ１およびポートＰ２間でしか再配車できない。さらに、７分以上９分未満のＳＤ時間ではポートＰ１およびポートＰ２間、ならびにポートＰ２およびポートＰ３間でしか再配車できない。以下、同様に検討していくと、３０分以上のＳＤ時間内では全ポート間で再配車が可能である。このように、再配車を可能にするためには各ポートＰ間の最小所要時間以上のＳＤ時間を設定する必要がある。図７の例では５分以上である。
【００４９】
また、最大待ち時間との関係では、最大待ち時間よりも短いＳＤ時間とする必要がある。例えば最大待ち時間を１５分とした場合、ＳＤ時間は１５分未満に設定する必要があり、この場合、ポートＰ１およびポートＰ２間、ポートＰ２およびポートＰ３間、ポートＰ３およびポートＰ４間、ならびにポートＰ４およびポートＰ５間で再配車が可能となる。なお、車両４を自動走行させて再配車する場合は、各ポート間の所要時間は、自動走行時の走行速度に基づいて決定するのはもちろんである。
【００５０】
次に、配備される車両台数との関連でＳＤ時間を決定するためのアルゴリズムについて説明する。ポートＰにおける総デマンド数と同数の車両を配備しておけば、そのポートＰに再配車する必要はないのは明らかであり、ポートＰに配備する車両数を少なくしていくほど再配車数は多くなる。したがって、車両の配備台数が多く、再配車の必要性が低い場合は、ＳＤ時間を短く設定でき、ポートＰでの待ち時間も短くなる傾向がある。
【００５１】
しかし、配備台数を無制限に多くするのは経済的ではないため、ＳＤ時間を長くし、積極的に再配車を活用することによって配備台数を少なくすることが好ましい。一方、配備台数を少なくしてＳＤ時間を極端に長くすると、待ち時間が長くなる傾向がある。また、ＳＤ時間が長くなると待ち時間は増えるが、他のポートからの到着トリップが多く期待できるようになるので再配車数は比較的少なくなってくる。したがって、配備台数、再配車数、および待ち時間を総合的に検討してＳＤ時間を決定するのがよい。
【００５２】
図８は、車両の配備台数と再配車数との関係をＳＤ時間をパラメータとして示した図であり、図９は、車両の配備台数と平均待ち時間との関係をＳＤ時間をパラメータとして示した図である。図８において、配備台数がａ台以下、再配車数Ａ台以下という設定条件において、配備台数を少なくしていくと同じＳＤ時間では再配車数が少なくなる（ＳＤ時間はＳＤ１＞ＳＤ２＞ＳＤ３＞ＳＤ４とする）。一方、図９に見られるように、配備台数を少なくしていくと平均待ち時間が長くなる。すなわち、配備台数を少なくすると再配車数が少なくなるので、結果として待ち時間が長引いてくる。
【００５３】
したがって、配備台数を少なくしたときに、平均待ち時間が、その上限であるＢ分を越えないようにするには再配車数を増加させる必要があり、そのためにはＳＤ時間を短くしていかなければならない。換言すれば、再配車数を少なくしようとすればＳＤ時間を長くする必要があり、平均待ち時間を少なくしようとすればＳＤ時間は短くする必要がある。
【００５４】
例えば、ポイントＬ，Ｍ，Ｈを設定すると、そのいずれにおいても、平均待ち時間の上限Ｂ分および再配車数Ａ台の設定を共に満足している。したがって、配備台数、再配車数、および平均待ち時間のどれを優先させるかを、その時々の必要性（例えば、ビジネス判断）によって決定することができる。
【００５５】
具体的な数値をもとにシミュレーションした例を説明する。図１０は、エリアのサイズを特定するための各ポートＰ１〜Ｐ５相互間の走行時間を示す図である。同図（ａ）は人が車両を運転する場合の走行時間（時速４８ｋｍ／時）、同図（ｂ）は無人自動走行時の走行時間（時速１６ｋｍ／時）である。また、車両は各ポートＰに１５台ずつ計７５台を配備し、平均待ち時間の上限を１分とした。このシミュレーションでは待ち時間を優先させている。
【００５６】
図１１は、上記シミュレーション条件での配備台数と待ち時間および再配車数との関係を示す図であり、ＳＤ時間は２０分である。図１１において、平均待ち時間の上限を１分としたとき、配備台数は７５台必要であり、そのときの再配車数は４７３台である。
【００５７】
ところで、上記ＳＤ時間は１日にわたって固定しておく必要はなく、デマンドに応じて変化させてもよい。図１２は、１日に発生するデマンドの実績の一例つまり全ポートの乗車需要統計データを示す図である。１日の全デマンドの数（ほぼ全発生トリップと同数）は約１８００トリップである。同図のようにデマンドは１日を通して安定しておらず、かなりの変動がある。デマンドが多いときには、待ち時間が長くならないようにＳＤ時間を短くして再配車数を多くするのが好ましい。そこで、例えば１日のうち予測最大乗車需要（予測最大デマンド）の１／２を基準にして、予測デマンドがこの基準以下のときにはＳＤ時間を２０分とし、予測デマンドがこの基準以上のときにはＳＤ時間を１５分に短縮するようにする。図１１において、予測最大デマンドを１８０台としたとき、ＳＤ時間を変更するための基準値は９０台とする。したがって、ＳＤ時間は、時間帯Ｔ１，Ｔ３，Ｔ５では２０分、時間帯Ｔ２，Ｔ４では１５分に設定する。
【００５８】
次に、ＳＤ時間を設定するための他の基準について説明する。図１３は、配備台数をパラメータとした場合の、再配車数および平均待ち時間の積（以下、「配車係数」という）とＳＤ時間との関係を示すシミュレーション結果である。同図に示したデータは再配車のときの車両の走行速度が３５ｋｍ／時のときのものである。なお、ＳＤ時間は複数のポートのうち互いに最も遠い距離にあるポート間の移動時間（２０分）に対するＳＤ時間の割合（ＳＤ比）で示している。前記配車係数が小さいほど、好ましいシステムといえる。平均待ち時間が短い場合、または空で車両を移動させることが少ない場合であるからである。
【００５９】
この図から分かるように、配備台数がある台数未満の場合に、配車係数の極小値が顕著である。すなわち、配備台数が６０台未満の領域ではＳＤ比が「１」〜「１．５」の近傍にあるとき、つまりＳＤ時間をほぼ最大ポート間移動時間と同時間に設定したときに配車台数の極小値が現れている。一方、配備台数が６０台以上の領域では配車係数の極小値が顕著ではない。すなわち、ＳＤ比の変化に対して配車係数はあまり変化していない。換言すれば、配備台数が多い領域では車両数に余裕があるため、ＳＤ時間を厳密な基準に基づいて設定してもそのことによる効果は期待できない。
【００６０】
デマンドに対して不足気味の配備台数を設定した場合に、ＳＤ時間を選択することにより、配車係数が低い経済的なシステムを構成することができるという効果を奏する。図１３の例で言えば、配備台数が６０台未満のときにＳＤ比を「１」〜「１．５」に設定した場合に効率の良いシステムとなる。なお、配備台数が４５台未満の領域では、デマンドに対する車両数が少なすぎるため、平均待ち時間は１０分以上となるが、ＳＤ比が「１」近傍で配車係数の極小値は現れる。
【００６１】
上述の実施形態は、各ポートの駐車可能台数つまり駐車場の大きさを考慮に入れていない場合の再配車の例である。しかし、各ポートでの駐車可能台数（以下、「収容台数」という）が小さくてエリアでの車両の総配備台数が多い場合は、車両の出し入れ時に渋滞が発生して、車両が多い割りには待ち時間が長くなるという現状がある。
【００６２】
図１４は、待ち時間と車両数との関係を収容台数をパラメータとして示した図である。同図から理解されるように、待ち時間が極小値を示す車両数があり、車両数を多くしても、必ずしも待ち時間が短縮されるとは限らない。例えば、総配備台数を７５台と設定した場合、収容台数（ＣＡＰ）が３０台では約４分、同４０台では２分、同５０台では１分となっているが、収容台数が２０台では同図では表せないような長い待ち時間になってしまう。
【００６３】
そこで、以下に示す実施形態では、ポートの収容台数に応じて再配車をするようにした。図１５は再配車設定処理の変形例に係るフローチャートであり、図６と同ステップ番号は同一または同等の処理である。図１５において、ステップＳ２２およびステップＳ２３のいずれかの判断が否定の場合、つまり当該ポートでは再配車可能な車両がない場合、または当該ポートから予定の近接距離に車両が不足するポートがない場合にはステップＳ４１に進む。
【００６４】
ステップＳ４１では、収容台数ＣＡＰが、ＳＤ時間内で使用可能である車両数ＮP 以下か否かを判断する。この判断が肯定、つまりＳＤ時間内に当該ポートで収容可能な台数以上の車両が入場するという予測が立った場合にはステップＳ４２に進む。ステップＳ４２では他に車両が不足するポートがあるか否かを判断する。車両が不足するポートがある場合はステップＳ２４に進んでそのポートへ再配車をする。
【００６５】
車両が不足しているポートがない場合はステップＳ４２からステップＳ４３に進み、現有車両が最も少ないポートを検出する。現有車両が最も少ないポートを特定したならばステップＳ２４に進み、そのポートへ再配車する。再配車が終わったならばステップＳ２５に進み、各ポートの車両の過不足数を最新値で更新する。なお、ステップＳ２６以降の処理は、図６のステップＳ２７〜Ｓ３１と同様に処理されるので図示および説明は省略した。
【００６６】
上記処理により、現有車両数および予測到着車両数を合計した数が自ポートに収容しきれないと判断した場合は、車両不足ポートが近隣でない場合でもその車両不足ポートへ再配車をして自ポートでの渋滞を防止するようにした。また、車両不足ポートが全くない場合には、最も現有車両が少ないポートに再配車して自ポートでの渋滞が発生しないようにした。なお、現有車両が少ないポートが複数あった場合に、最も近距離のポートに再配車する等の変形は可能である。
【００６７】
図１６は、収容台数を考慮した場合の待ち時間とエリア内に配備された車両数との関係を示す図であり、ポートでの収容台数をパラメータにとっている。同図に示すように、いずれの収容台数においても車両台数が増大するに伴って全ポートでの待ち時間は減少している。特に、収容台数が２０台と少ない場合においても車両数を７５台以上にすれば待ち時間は４分以下になっている。
【００６８】
このように、ポートの収容台数を考慮して再配車をすれば、車両配備台数に応じて待ち時間を減少させることができる。車両配備台数は待ち時間のほか再配車数をも考慮して決定されるが、車両配備台数を増大することによって待ち時間がある点から上昇に転ずる図１４の場合とは異なり、ビジネス判断等により広い範囲で車両配備台数を設定することができる。
【００６９】
なお、上述の実施形態では、車両４を自動走行させて再配車するシステムを想定したが、本発明はそれに限定されず、再配車は、人が運転して行うものでもよいし、車両４をトレーラ等、他の車両で牽引して行うものでもよい。また、利用者が運転するものに限らず、タクシーやハイヤーの配車システムにも適用できる。
【００７０】
【発明の効果】
以上の説明から明らかなように、本発明によれば、車両の乗車需要予測と車両数予測とが予め定められた検索範囲内で行われるため、予測乗車需要をどの範囲まで配慮に入れて配車をするかを人の判断に委ねるのと異なり、配車指示のばらつきが無くなり安定的な配車を実施できる。
【図面の簡単な説明】
【図１】  本発明の実施形態に係る配車システムの構成を示す系統図である。
【図２】  ポートに配備される端末とホストコンピュータとにおける要部機能を示すブロック図である。
【図３】  再配車指示前の各ポートの乗車需要および車両数を示す図である。
【図４】  再配車指示後の各ポートの乗車需要および車両数を示す図である。
【図５】  車両過不足計算のフローチャートである。
【図６】  車両過不足計算結果に基づく再配車設定のフローチャートである。
【図７】  各ポート間の車両の移動時間の一例を示す図である。
【図８】  配備台数と再配車数との関係を示す図である。
【図９】  配備台数と平均待ち時間との関係を示す図である。
【図１０】  各ポート間の車両の移動時間のシミュレーション結果を示す図である。
【図１１】  配備台数と平均待ち時間および再配車数との関係についてのシミュレーション結果を示す図である。
【図１２】  １日の乗車重要の推移を示す図である。
【図１３】  配備台数毎の再配車数と平均待ち時間との積を検索範囲をパラメータとして求めたシミュレーション結果を示す図である。
【図１４】  待ち時間と車両数との関係を収容台数をパラメータとして示した図である。
【図１５】  再配車設定処理の変形例に係るフローチャートである。
【図１６】  収容台数を考慮した場合の待ち時間とエリア内に配備された車両数との関係を収容台数をパラメータとして示した図である。
【符号の説明】
１…ホストコンピュータ、  ２…端末、  ３…センサ、  ４…車両、  １０…ＣＰＵ、  １１…メモリ、  １２…通信装置、  ２０…デマント通知部、  ２１…到着トリップ通知部、  ２２…契約者ＩＤ通知部、  ２３…現有車両数通知部、２４…表示装置、  ２５，１０７…通信インタフェース、  １０１…乗車数判別部、  １０２…ＳＤ設定部、  １０３…予測乗車需要検出部、  １０４…過不足算出部、  １０５…再配車設定部、  １０６…配車設定部
【図１】
0003998108.tif 000002
【図２】
0003998108.tif 000003
【図３】
0003998108.tif 000004
【図４】
0003998108.tif 000005
【図５】
0003998108.tif 000006
【図６】
0003998108.tif 000007
【図７】
0003998108.tif 000008
【図８】
0003998108.tif 000009
【図９】
0003998108.tif 000010
【図１０】
0003998108.tif 000011
【図１１】
0003998108.tif 000012
【図１２】
0003998108.tif 000013
【図１３】
0003998108.tif 000014
【図１４】
0003998108.tif 000015
【図１５】
0003998108.tif 000016
【図１６】
0003998108.tif 000017