JP5967205B2 - オンデマンド車両運行管理装置、オンデマンド車両運行管理方法及びオンデマンド車両運行管理システム - Google Patents

Description

本発明は、複数の利用者からの要望に基づいてオンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理するオンデマンド車両運行管理装置、オンデマンド車両運行管理方法及びオンデマンド車両運行管理システムに関する。

従来から、例えば、下記特許文献１に示された運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法は知られている。この従来のオンデマンドバスの運行スケジューリングシステム等は、乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、データベースに格納される運行実績から予め乗客の乗降に関する特性情報を抽出し、抽出した特性情報と抽出した特性情報に対応する運行実績に含まれる予約を表す予約情報とを対応付けてデータベースに格納する手段と、運行スケジュールを決定する現在の状況が、特性情報が示す状況に整合するとき、整合した特性情報に対応する運行実績に含まれる予約情報に基づいて、オンデマンドバスの運行スケジュールを決定する手段とを設けるようになっている。

又、従来から、例えば、下記特許文献２に示された車両運行システムも知られている。この従来の車両運行システムは、新たな運行計画候補の作成に際して、予約リストに現在登録されているデマンド内容と、新たなデマンド内容との新たな組み合わせである新たな予約の組み合わせを作成するようになっている。そして、新たな予約の組み合わせについて、ゾーン配車レベル指標の算出及び予め定められているゾーン（市街地、旧市街地、山間地域）ごとのゾーン配車レベル基準指標に基づく第１次評価を行うとともに、サービス指標及び運行指標の算出と第１次評価を行うようになっている。これにより、双方の第１次評価で合格した新たな予約の組み合わせについて、総合ランク付けを行った後に新たな運行計画を決定するようになっている。

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

ところで、上記特許文献１，２に示された従来のシステム等においては、運行スケジュール（運行計画）が確定された後に、オンデマンドバス（オンデマンド車両）の利用を希望する利用者（ユーザ）が新たに現れた場合には、この新たに現れたユーザの要望を取り入れるに際して、既に確定された運行スケジュール（運行計画）を大幅に変更しなければならない状況が生じ得る。すなわち、上記特許文献１，２に示された従来のシステム等によって決定される運行スケジュール（運行計画）は変更や調整に対する自由度が小さいため、要望の追加が運行スケジュール（運行計画）全体に与える影響が大きくなる。従って、この場合には、確定された運行スケジュール（運行計画）の変更や調整に時間を要する可能性があり、新たに現れたユーザの要望を満足する運行スケジュール（運行計画）をオンデマンドバスの運行開始までに確定することが不能となる可能性もある。

本発明は、上記課題を解決するためになされたものであり、その目的は、良好な自由度を確保してオンデマンド車両の運行計画を決定するオンデマンド車両運行管理装置、オンデマンド車両運行管理方法及びオンデマンド車両運行管理システムを提供することにある。

上記目的を達成するために、本発明は、複数の利用者からの要望に基づいてオンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理する運行管理手段を備えたオンデマンド車両運行管理装置を改良しようとするものであり、更には、コンピュータ装置を備えて、複数の利用者からの要望に基づいてオンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理するオンデマンド車両運行管理方法及び複数の利用者が乗車するオンデマンド車両と、前記複数の利用者からの要望に基づいてオンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理する運行管理センタと、前記利用者によって操作されて前記要望を前記運行管理センタに供給する情報端末装置とからなるオンデマンド車両運行管理システムを改良しようとするものである。

本発明の特徴は、前記運行管理手段、前記運行管理センタ、及び、前記コンピュータ装置が、前記オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割し、前記分割した前記サブエリアごとに、前記オンデマンド車両が走行する経路を探索し、前記探索した経路のうちの一つを基本経路に決定し、前記基本経路を走行する前記オンデマンド車両が前記基本経路から離間した地点を経由するために必要な時間である調整時間を考慮して前記運行計画を決定する、ことにある。尚、この場合、前記運行管理手段及び前記運行管理センタが、前記オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割する分割手段を備えることができる。

そして、これらの場合、前記運行管理手段、前記運行管理センタ、及び、前記コンピュータ装置は、前記運行計画の決定後、新たな利用者によって要望が追加された場合、前記調整時間を用いて前記新たな利用者の前記要望に基づいて前記運行計画を変更することができる。

又、本発明の他の特徴は、前記運行管理手段が、前記オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割し、前記運行計画の確定前に利用者から予約を受け付けた場合、同利用者が要望する希望乗降地点を通りかつ同利用者が要望する希望時刻に前記オンデマンド車両を運行させることが可能な候補経路の有無を判断し、前記候補経路が存在する場合、前記利用者を前記オンデマンド車両に乗車させることが可能であると判断し、前記利用者を前記オンデマンド車両に乗車させることが可能であると判断した前記候補経路全てについて所定の評価式を計算して最適解を有する候補経路を基本経路として選択し、前記基本経路を走行する前記オンデマンド車両が前記基本経路から離間した地点を経由するために必要な時間である調整時間を考慮して前記運行計画を確定し、前記運行計画の確定後に利用者から追加予約を受け付けた場合、前記追加予約をした前記利用者が要望する希望乗降地点を通りかつ同利用者が要望する希望時刻での運行が可能となるように前記調整時間を用いて前記運行計画を変更することにもある。

そして、この場合には、前記運行管理手段が、前記運行計画の確定前に利用者から受け付けた予約に含まれる要望と、過去に受け付けた予約に含まれていて前記要望と同一時間帯及び同一サブエリアにおける過去の要望とを比較し、前記過去の要望により頻度の高い時間帯及びサブエリアに応じて前記調整時間を前記運行計画の確定に考慮することができる。

これらによれば、運行管理手段（コンピュータ装置、運行管理センタ）は、オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割し、この分割されたサブエリアごとに探索された経路をオンデマンド車両が走行するときに要する時間を調整するための調整時間をサブエリアごとに設定することができる。そして、運行管理手段（コンピュータ装置、運行管理センタ）は、サブエリアごとに設定した調整時間を用いて、運行計画を決定した後に現れた新たな利用者によって追加された要望を加えた運行計画を決定することができる。

これにより、例えば、出発地から目的地まで運行に支障をきたす可能性のある不確定要素の発生に備えて一義的に時間を付加してオンデマンド車両を運行管理する場合に比して、サブエリアごとに必要十分な調整時間を設定することにより、運行上、無駄な時間を生じさせることを抑制することができる。又、サブエリアごとに必要十分な調整時間を設定することにより、調整時間を利用して自由度の高い運行計画を決定することができる。

すなわち、設定される調整時間はサブエリアごとにサブエリアに対して設定されるものであり、例えば、サブエリア内の個々の特定地点を経由する場合の時間等、地点を特定した上で設定される調整時間ではない。従って、この調整時間を加味して運行計画が決定されることにより、例えば、新たな利用者が要望を追加した場合であっても、この利用者が希望する乗降地点に向かう経路をオンデマンド車両が走行する際に要する時間が、前記乗降地点が存在するサブエリアごとに設定された調整時間内であれば、他の利用者によるオンデマンド車両の利用に対する影響を極めて小さくすることができる。言い換えれば、サブエリアごとに調整時間を設定することができることにより、決定される運行計画における自由度を高めることができて、一旦決定された運行計画に対して追加の要望を加える場合であっても、全体の運行計画に対する影響を小さくして要望を追加することができる。従って、速やかに新たな運行計画を決定することができる。

又、これらの場合、前記運行管理手段（前記コンピュータ装置、前記運行管理センタ）は、例えば、前記オンデマンド車両の運転手の休憩時間が確保されるように、前記運行計画を決定することができる。これにより、オンデマンド車両の運転手は適切に休息を取ることができ、オンデマンド車両の運行を適切に実施することができる。

図１は、本発明の実施形態に係るオンデマンド車両運行管理装置の適用可能なオンデマンド車両運行管理システムの概略図である。 図２は、図１の車両に搭載された運行情報端末装置の構成を概略的に示すブロック図である。 図３は、図１の運行管理センタの構成を概略的に示すブロック図である。 図４は、図１の情報端末装置の構成を概略的に示すブロック図である。 図５は、図３のサーバ（コンピュータ）によって実行されるコンピュータプログラム処理を機能的に表す機能ブロック図である。 図６は、図５の経路データ作成部による候補経路、所要時間及び調整時間の決定を説明するための概略図である。 図７は、図５の経路データ作成部によって決定されて記憶される候補経路、所要時間及び調整時間の情報テーブルを説明するための概略図である。 図８は、図５の予約受付処理部の運行計画候補作成部（ＣＰＵ）が実行する運行計画候補作成プログラムのフローチャートである。 図９は、図５の運行計画確定処理部の調整時間設定・計画確定部（ＣＰＵ）が実行する運行計画確定処理プログラムのフローチャートである。 図１０は、図５の予約追加受付処理部の需要追加処理部（ＣＰＵ）が実行する予約追加対応処理プログラムのフローチャートである。

以下、本発明の一実施形態に係るオンデマンド車両運行管理装置（以下、本装置と称呼する。）について図面を参照しながら説明する。

図１は、本装置の適用可能なオンデマンド車両の運行を管理するオンデマンド車両運行管理システムの概略構成を示している。本実施形態におけるオンデマンド車両運行管理システムは、複数のユーザ（利用者）からの要望（デマンド）に応じて運行される複数台のオンデマンド車両であるオンデマンドバス１０と、本装置を備えて各オンデマンドバス１０の運行計画を決定して運行を管理する運行管理センタ２０と、それぞれのユーザが所持している情報端末装置３０とを備えている。そして、このオンデマンド車両運行管理システムにおいては、各オンデマンドバス１０（より詳しくは、後述する運行情報端末装置１１）、運行管理センタ２０及び情報端末装置３０が、例えば、インターネット回線網や携帯電話回線網等のネットワーク４０によって互いに通信可能に接続されている。

オンデマンドバス１０は、周知の通り、運行経路や運行時刻等（以下、これらをまとめて「運行計画」とも称呼する。）が固定されておらず、後述する運行管理センタ２０によってユーザの要望（要求）に応じて適宜決定された運行計画に従って特定地域を走行する乗合車両である。このため、オンデマンドバス１０には、運行管理センタ２０との通信により運行計画を表す運行計画情報を含む各種情報を送受信する運行情報端末装置１１が搭載されている。運行情報端末装置１１は、図２に示すように、電子制御ユニット１１ａ、通信ユニット１１ｂ、記憶ユニット１１ｃ、報知ユニット１１ｄ及びＧＰＳユニット１１ｅを備えている。

電子制御ユニット１１ａは、ＣＰＵ、ＲＯＭ、ＲＡＭ等を主要構成部品とするマイクロコンピュータであり、オンデマンドバス１０に搭載される運行情報端末装置１１の動作を統括的に制御する。通信ユニット１１ｂは、ネットワーク４０を介した無線通信により、運行管理センタ２０との間の通信を実現するものである。記憶ユニット１１ｃは、ハードディスクや半導体メモリ等の記憶媒体及び同記憶媒体のドライブ装置を含むものである。そして、記憶ユニット１１ｃは、電子制御ユニット１１ａが運行情報端末装置１１の作動を統括的に制御するにあたって必要なプログラム及び後述するように運行管理センタ２０から提供される運行計画情報を含む各種データを予め又は更新可能に記憶している。報知ユニット１１ｄは、表示ディスプレイやスピーカ等から構成されている。そして、報知ユニット１１ｄは、電子制御ユニット１１ａによる制御に従って、表示ディスプレイの画面上に文字、図形等を表示したり、音声をスピーカから出力して、運行計画情報を報知するものである。ＧＰＳユニット１１ｅは、ＧＰＳ(Global Positioning System)衛星からの電波を受信して、運行情報端末装置１１が搭載されるオンデマンドバス１０の位置を検出するものである。

運行管理センタ２０は、ユーザの要望（要求）に応じたオンデマンドバス１０の運行計画を決定し、オンデマンドバス１０に運行計画情報を提供して運行を管理するものである。又、運行管理センタ２０は、ユーザに対して運行計画情報を提供するとともにオンデマンドバス１０の運行に関する各種情報を提供するものである。このため、運行管理センタ２０は、図３に示すように、サーバ２１と通信装置２２とを備えている。

サーバ２１は、制御装置２１ａ、記憶装置２１ｂ及び通信インターフェース２１ｃを備えている。制御装置２１ａは、ＣＰＵ、ＲＯＭ、ＲＡＭ等からなるマイクロコンピュータを主要構成部品とするものであり、オンデマンドバス１０（或いは、運行する便）ごとの運行計画の決定（確定）及び運行の管理に関するサーバ２１の動作を統括的に制御する。記憶装置２１ｂは、ハードディスクや半導体メモリ等の記憶媒体及び同記憶媒体のドライブ装置を含むものであり、各種プログラム及び各種データを記憶している。通信インターフェース２１ｃは、運行管理センタ２０内に構築された通信回線（例えば、ＬＡＮ回線等）に接続するためのインターフェースである。又、記憶装置２１ｂには、それぞれのオンデマンドバス１０の需要（すなわち要望）に関する需要情報（以下、ユーザによる「予約情報」とも称呼する場合がある。）を検索可能に蓄積して記憶する需要データベース２１ｄと、それぞれのオンデマンドバス１０の運行計画情報を含む運行情報を検索可能に蓄積して記憶する運行データベース２１ｅとが構築されている。

需要データベース２１ｄは、ユーザによるオンデマンドバス１０の利用に関する需要情報、具体的に、希望乗降地点を表す希望乗降地点情報、希望する出発又は到着時刻を表す希望時刻情報、希望する出発時刻又は到着時刻に対してユーザが許容することができる付加時間を表す乗降ステータス情報と、ユーザを識別するためのユーザ識別情報とを互いに関連付けて検索可能に蓄積して記憶している。運行データベース２１ｅは、ユーザの要望（要求）に応じたオンデマンドバス１０の運行に関する運行情報、具体的に、運行経路や運行時刻を表す運行計画情報に加えて、オンデマンドバス１０に乗車を希望する、言い換えれば、運行計画に従ってオンデマンドバス１０が運行される便の利用を希望する乗客の人数を表す乗客者数情報と、オンデマンドバス１０を識別するためのバス識別情報とを互いに関連付けて検索可能に蓄積して記憶している。

通信装置２２は、運行管理センタ２０内に構築された通信回線を介してサーバ２１と接続されている。そして、通信装置２２は、ネットワーク４０に接続して、運行情報端末装置１１及び情報端末装置３０との通信を実現するものである。これにより、通信装置２２は、運行情報端末装置１１との間でバス識別情報及び運行情報（特に、運行計画情報）を送受信する。又、通信装置２２は、情報端末装置３０との間でユーザ識別情報及び予約情報（需要情報）を送受信したり、決定した運行計画情報やオンデマンドバス１０の利用に際してユーザの要望（要求）に応えられないことを表すお断り情報を送信したりする。

情報端末装置３０は、ユーザによって操作されて、例えば、電子メールによる文字データや音声による通話によって需要情報（予約情報）を運行管理センタ２０に送信したり、運行管理センタ２０から運行計画情報やお断り情報を受信するものである。このため、情報端末装置３０は、図４に示すように、互いに通信可能に接続された入力ユニット３１、表示ユニット３２、電子制御ユニット３３、記憶ユニット３４及び通信ユニット３５を備えている。入力ユニット３１は、例えば、キーボードや表示ユニット３２内に組み込まれて表示パネルのタッチ操作を検出するタッチパネル式キーボード、或いは、外部（具体的には、運行管理センタ２０に常駐するオペレータ等）との間の通話を可能とする音声入力デバイス等から構成されるものである。表示ユニット３２は、例えば、液晶表示器等からなり、文字、図形等を表示パネル上に表示するものである。

電子制御ユニット３３は、ＣＰＵ、ＲＯＭ、ＲＡＭ等からなるマイクロコンピュータを主要構成部品とするものであり、各種アプリケーションプログラムの実行により入力ユニット３１、表示ユニット３２、記憶ユニット３４及び通信ユニット３５の作動を統括的に制御する。記憶ユニット３４は、電子制御ユニット３３が情報端末装置３０の作動を統括的に制御するための各種アプリケーションプログラム及び各種データを記憶するとともに、予約情報（需要情報）の送信に際して運行管理センタ２０にアクセスするために必要なユーザ識別情報（具体的には、ユーザＩＤ及びパスワード等）を記憶する。通信ユニット３５は、ネットワーク４０に接続して、ユーザ識別情報及び予約情報（需要情報）や、運行計画情報、お断り情報、音声データ等を運行管理センタ２０に送受信する機能を実現する。

ここで、情報端末装置３０としては、具体的に、スマートフォン等の携帯電話やタブレット型の情報端末、ラップトップ型のパーソナルコンピュータ等を採用することができる。尚、この場合、携帯性に劣るものの、例えば、自宅等に設置されたデスクトップ型のパーソナルコンピュータや、自宅等に設置された固定電話等を利用可能であることは言うまでもない。

次に、上記のように構成した本実施形態の動作を機能ブロック図を参照しながら説明する。本実施形態における運行管理センタ２０のサーバ２１（より詳しくは、制御装置２１ａ）は、図５に示すように、経路データ作成部５０、予約受付処理部６０、運行計画確定処理部７０及び予約追加受付処理部８０からなる。尚、詳細を省略するが、運行管理センタ２０のサーバ２１は、オンデマンドバス１０を運行させる運行エリアである運行地域（運行地区）の現在情報として、道路や地形等を表す地図情報、各道路上における交差点等のノード間で表される道路区間の渋滞情報（混雑度や道路区間又は所定区間の走行時間等）、気象情報、オンデマンドバス１０の現在位置等を収集して運行データベース２１ｅの所定記憶位置に記憶するようになっている。又、オンデマンドバス１０の運行台数については、運行エリアである運行地域（運行地区）の広さやユーザの数に応じて適宜決定されるものであり、更には、商店街や、病院、公共施設、地形的特徴（坂道の有無等）、時間帯等に基づいても決定される。尚、この場合、運行地域（運行地区）を割り当てないオンデマンドバス１０を用意しておき、乗車を希望するユーザが少ない運行地域（運行地区）に対して、このオンデマンドバス１０をユーザからの要望（要求）に応じて臨時に割り当てるように実施することも可能である。

経路データ作成部５０は、データ入力部５１を備えている。データ入力部５１は、運行データベース２１ｅから、同データベース２１ｅの所定記憶位置に更新可能に記憶されている地図情報（地図データ）や、渋滞情報、気象情報等を取得して入力する。そして、データ入力部５１は、入力した各情報を候補経路・時間作成部５２に供給する。

候補経路・時間作成部５２は、運行を管理するオンデマンドバス１０を走行させる運行エリアである運行地域（運行地区）を所定のサブエリアに分割（区画）し、このサブエリアごとに、オンデマンドバス１０が走行可能な経路を探索して候補経路として決定する。又、候補経路・時間作成部５２は、探索した候補経路における地点間（ノード間）をオンデマンドバス１０が走行する際に必要となる時間（以下、「所要時間」と称呼する。）を決定する。

更に、候補経路・時間作成部５２は、探索した候補経路のうちの一つをオンデマンドバス１０を運行させる際の基本となる経路（以下、この経路を「基本経路」と称呼する。）として決定する。そして、候補経路・時間作成部５２は、基本経路上から離間した地点（ノード）に向けて枝分かれした経路を加味した経路（以下、この経路を「基本経路外」と称呼する。）を探索した場合には、オンデマンドバス１０が前記地点（ノード）に立ち寄る（経由する）際に必要となる時間（以下、「調整時間」と称呼する。）を決定する機能を発揮する。以下、この候補経路・時間作成部５２による候補経路、所要時間及び調整時間の決定を図６を用いて詳細に説明する。

候補経路・時間作成部５２は、データ入力部５１を介して運行データベース２１ｅから取得した地図情報（地図データ）を用いて、オンデマンドバス１０が走行可能な経路を探索する。このとき、候補経路・時間作成部５２は、オンデマンドバス１０を運行させる運行エリアを、例えば、ユーザによるオンデマンドバス１０の需要や土地利用（住宅地や密集地、標高等）に基づいて所定の大きさのサブエリアごとに分割（区画）し、このサブエリアごとに基本経路及び基本経路外の経路を探索する。この探索を、例示的に図６を用いて説明すると、候補経路・時間作成部５２は、オンデマンドバス１０を運行させる運行エリアをサブエリアＡ、サブエリアＢ、サブエリアＣ・・・に分割する。ここで、図６においては、理解を容易とするために、サブエリアＡ、サブエリアＢ、サブエリアＣ・・・を同一の矩形状に分割するが、サブエリアの分割に関しては矩形状に限定されるものではなくいかなる形状や大きさで分割（区画）可能であることは言うまでもない。

そして、候補経路・時間作成部５２は、地図情報（地図データ）に基づき、サブエリアＡ内に存在するノード１、ノード２及びノード３を特定するとともに、サブエリアＢとの境界に存在するノード１００１を特定し、これらノード１〜３及びノード１００１を通る経路を探索する。具体的に、候補経路・時間作成部５２は、サブエリアＡにおける出発地点であるノード１とノード３とを直接的に結ぶとともにノード３とノード１００１とを直接的に結ぶ経路を基本経路Ａ１００として決定する。又、候補経路・時間作成部５２は、サブエリアＡにおいて、基本経路Ａ１００上から離間したノード２が存在するため、このノード２を経由する経路を基本経路外Ａ１１０として探索する。すなわち、候補経路・時間作成部５２は、ノード１からノード２を経由してノード３に至り、更にノード１００１までを結ぶ経路を基本経路外Ａ１１０として探索する。

同様に、候補経路・時間作成部５２は、地図情報（地図データ）に基づき、サブエリアＢに存在するノード４及びノード５を特定するとともに、サブエリアＡとの境界に存在するノード１００１及びサブエリアＣとの境界に存在するノード１００２を特定し、これらノード１００１、ノード４，５及びノード１００２を通る経路を探索する。具体的に、候補経路・時間作成部５２は、サブエリアＢにおける出発地点であるノード１００１からノード４及びノード５を介してノード１００２までを結ぶ経路を基本経路Ｂ１００として探索する。

尚、上記説明においては、理解を容易とするために、単に各ノードに番号を付すようにした。この場合、より具体的に、各ノードを、例えば、周知にように経度及び緯度を用いた座標によって表すことが可能であり、これによって各ノード間を経度及び緯度を用いて表すことが可能であることは言うまでもない。

このように、候補経路・時間作成部５２は、オンデマンドバス１０を運行させる運行エリアを複数のサブエリアに分割し、各サブエリア内に存在する複数のノードを通る経路を探索する。そして、探索した経路のうちから基本経路を決定するとともに基本経路外を決定する。候補経路・時間作成部５２は、サブエリアごとに決定した基本経路及び基本経路外を経路データＲｉ（ｉ＝０,…,Ｎ）としてデータ出力部５３に出力する。

又、候補経路・時間作成部５２は、決定した各基本経路上をオンデマンドバス１０が走行する際の所要時間を決定するとともに、決定した各基本経路外をオンデマンドバス１０が走行する際の調整時間を決定する。この場合、候補経路・時間作成部５２は、分割（区画）したサブエリアごとに所要時間及び（又は）調整時間を決定する。以下、具体的に図６を用いて説明する。

まず、所定時間の決定から説明する。候補経路・時間作成部５２は、データ入力部５１を介して運行データベース２１ｅから取得した地図情報（地図データ）や、渋滞情報、気象情報を用いて、サブエリアごとについて決定した基本経路上をオンデマンドバス１０が走行するときの所要時間を決定する。すなわち、候補経路・時間作成部５２は、サブエリアごとに異なる需要の大きさや土地利用状況（言い換えれば、サブエリアごとの特徴）に基づき、又、曜日や時間帯、気象によって変動し得る所要時間を決定する。

具体的に、図６の場合を例示的に説明すると、まずサブエリアＡにおいて、候補経路・時間作成部５２は、地図情報（すなわち、土地利用状況）、渋滞情報及び気象情報に基づいて、基本経路Ａ１００の出発地点であるノード１からノード３までの所要時間を１０分に決定し、ノード３からノード１００１までの所要時間を７分に決定する。同様に、サブエリアＢにおいて、候補経路・時間作成部５２は、基本経路Ｂ１００の出発点であるノード１００１からノード４までの所要時間を８分に決定し、ノード４からノード５までの所要時間を７分に決定し、ノード５からノード１００２までの所要時間を２分に決定する。

一方、候補経路・時間作成部５２は、基本経路外を探索した場合には、サブエリアごとについて調整時間を決定する。すなわち、候補経路・時間作成部５２は、オンデマンドバス１０が基本経路上を走行する際の所要時間に対し、基本経路外に従ってオンデマンドバス１０が経由地点を通過するために必要な調整時間をサブエリアごとに決定する。

具体的に、図６の場合を例示的に説明すると、上述したように、サブエリアＡにおいては、基本経路Ａ１００に対して、基本経路Ａ１００から枝分かれしたノード２を経由する基本経路外Ａ１１０が探索されている。この場合、候補経路・時間作成部５２は、地図情報（すなわち、土地利用状況）、渋滞情報及び気象情報に基づいて、基本経路Ａ１００（基本経路外Ａ１１０）の出発地点であるノード１からノード２までの所要時間を１０分に決定するとともに、オンデマンドバス１０が基本経路Ａ１００からノード２を経由してノード３に向かうとした場合にノード２までの往復にかかる５分をサブエリアＡの調整時間として決定する。すなわち、候補経路・時間作成部５２は、基本経路Ａ１００から枝分かれした地点であるノード２を特定することなく、枝分かれした地点を経由するとした場合に所要時間に比して必要な（加算される）時間（図６の例ではノード２までの往復に必要な５分）をサブエリアＡの調整時間として決定する。

一方、図６においては、上述したように、サブエリアＢに基本経路外は決定されていない。従って、候補経路・時間作成部５２は、サブエリアＢについては、調整時間を決定しない。このように、サブエリアごとに所要時間及び（又は）調整時間を決定すると、候補経路・時間作成部５２は、各サブエリアにおける出発地点のノードから各ノードまでの所要時間Ｔｊ（ｊ＝０，…,Ｍ）と、各サブエリアに対応付けられた調整時間とをデータ出力部５３に出力する。

データ出力部５３においては、候補経路・時間作成部５２から出力された、各サブエリアごとに決定された経路データＲｉ（ｉ＝０,…,Ｎ）、所要時間Ｔｊ（ｊ＝０，…,Ｍ）及び各サブエリアの調整時間を取得する。そして、データ出力部５３は、取得した経路データＲｉ（ｉ＝０,…,Ｎ）、所要時間Ｔｊ（ｊ＝０，…,Ｍ）及び各サブエリアの調整時間を運行データベース２１ｅに出力する。これにより、運行データベース２１ｅの所定記憶位置には、各サブエリアの基本経路と基本経路外とについて所要時間及び調整時間が検索可能な情報テーブルとして記憶される。具体的に例示して説明すると、運行データベース２１ｅは、図７に示すように、サブエリアＡの基本経路Ａ１００及びサブエリアＢの基本経路Ｂ１００については各ノードＮｏ．と所要時間とを対応させて記憶する。又、サブエリアＡの基本経路外Ａ１００については、各ノードＮｏ．と所要時間とを対応させて記憶するとともに、太字により示すようにサブエリアＡの調整時間（５分）を記憶する。

尚、サブエリアＡには、調整時間として５分が決定されている。このため、ユーザの要望（要求）により、又は、過去の実績に基づき、例えば、オンデマンドバス１０がノード２を経由することになった場合には、ノード３までの所要時間は５分が加算されて１５分となり、ノード１００１までの所要時間は５分が加算されて２２分となることは言うまでもない。

次に、予約受付処理部６０を説明する。予約受付処理部６０は、図５に示すように、データ入力部６１を備えている。データ入力部６１は、需要データベース２１ｄから、同データベース２１ｄの所定記憶位置に更新可能に記憶されている予約情報（需要情報）を取得して入力する。そして、データ入力部６１は、入力した予約情報（需要情報）を運行計画候補作成部６２に供給する。又、データ入力部６１は、運行データベース２１ｅから、同データベース２１ｅの所定記憶位置に記憶されている経路データＲｉ、所要時間Ｔｊ及び調整時間を取得して入力する。そして、データ入力部６１は、入力した経路データＲｉ、所要時間Ｔｊ及び調整時間を運行計画候補作成部６２に供給する。

ここで、ユーザによる予約情報（需要情報）の送信について説明しておく。オンデマンドバス１０の利用を希望するユーザにおいては、自身が所持する情報端末装置３０を用いて予約情報（需要情報）を運行管理センタ２０に送信することができるとともに、例えば、自宅に設置された固定電話を利用して運行管理センタ２０に常駐しているオペレータに対して音声による通話によって予約情報（需要情報）を伝達することもできる。以下、主に、情報端末装置３０を用いて予約情報（需要情報）を送信（伝達）する場合を説明する。

ユーザが情報端末装置３０を利用して運行管理センタ２０に予約情報（需要情報）を送信する場合、ユーザは、情報端末装置３０にて予約情報（需要情報）を送信するために、例えば、運行管理センタ２０から提供された所定のアプリケーションプログラムを起動させる。そして、ユーザは、情報端末装置３０の入力ユニット３１を利用し、この所定のアプリケーションプログラムに従い、希望乗降地点情報、希望時刻情報及び乗降ステータス情報を予約情報（需要情報）すなわち要望として入力する。ここで、乗降ステータス情報としては、希望時刻Ｔに対し、例えば、「希望時刻Ｔまでに到着」を希望するときには「Ｔ−１５（分）」を入力し、「希望時刻Ｔから出発」を希望するときには「Ｔ＋１５（分）」を入力し、「希望時刻Ｔ頃までに到着（出発）」を希望するときには「Ｔ−１５（分）」及び「Ｔ＋１５（分）」を入力し、特段の希望がないときには「Ｔ−３０（分）」及び「Ｔ＋３０（分）」を入力する。このように、予約情報（需要情報）が入力されると、情報端末装置３０の電子制御ユニット３３は、入力された予約情報（需要情報）と記憶ユニット３４に記憶しているユーザ識別情報とを、通信ユニット３５を介して運行管理センタ２０に送信する。

運行管理センタ２０においては、サーバ２１の制御装置２１ａが通信装置２２を利用してユーザの情報端末装置３０から送信された予約情報（需要情報）及びユーザ識別情報を取得して受け付ける。そして、制御装置２１ａは、予め設けられていて、少なくとも、希望乗降地点情報によって表される希望乗降地点、希望時刻情報によって表される希望乗車（及び／又は降車）時刻及び乗降ステータス情報によって表される付加時間を入力項目とする予約情報テーブルに対して、受け付けた予約情報（需要情報）の対応する各項目を入力する。そして、受け付けた予約情報（需要情報）に基づいて予約情報テーブルの各項目を入力すると、制御装置２１ａは、この予約情報テーブルと受け付けたユーザ識別情報とを関連付けて、需要データベース２１ｄの所定記憶位置に検索可能に記憶する。ここで、希望乗降地点について、例えば、ユーザの自宅が指定されている場合には、制御装置２１ａは予め需要データベース２１ｄに登録されているユーザの自宅の住所等を予約情報テーブルに関連付けて記憶する。

尚、ユーザが、例えば、通話によって予約情報（需要情報）を運行管理センタ２０のオペレータに伝達する場合においては、まず、オペレータが通話によってユーザから氏名と予約情報（需要情報）、すなわち、希望乗降地点情報、希望時刻情報及び乗降ステータス情報を取得して受け付ける。そして、オペレータは、図示を省略するが、運行管理センタ２０に設けられた入力ユニット（例えば、キーボード等）を利用して、制御装置２１ａに対し、前期受け付けた予約情報（需要情報）の各項目を入力する。又、オペレータは、取得したユーザの氏名を用いて予め登録されているユーザ識別情報を取得し、このユーザ識別情報を制御装置２１ａに入力する。これにより、制御装置２１ａは、オペレータによって入力された各項目を反映した予約情報テーブルと入力されたユーザ識別情報とを関連付けて、需要データベース２１ｄの所定記憶位置に検索可能に記憶する。

ここで、ユーザがオンデマンドバス１０を利用するにあたっては、運行管理センタ２０（より詳しくは、サーバ２１）が、後述するように運行計画を確定（決定）するため、ある程度の時間が必要となる。このため、サーバ２１（制御装置２１ａ）は、予約情報（需要情報）を取得すると、現在の時刻から、少なくとも、希望時刻情報によって表される希望乗車時刻又は希望降車時刻（すなわち希望時刻）までの時間が所定の時間以下となるように指定されているときには、ユーザに対してお断り情報を送信するようになっている。言い換えれば、サーバ２１（制御装置２１ａ）は、少なくとも、所定の時間が確保できる時点までは予約情報（需要情報）を受け付け、所定の時間が確保できない時点以降は予約情報（需要情報）の受け付けを締め切るようになっている。

運行計画候補作成部６２は、データ入力部６１を介して取得した予約情報（需要情報）、経路データＲｉ（ｉ＝０，…，Ｎ）、所要時間Ｔｊ（ｊ＝０，…，Ｍ）及び調整時間を用いて、予約情報（需要情報）を送信したユーザに対応する運行計画候補を作成する。すなわち、運行計画候補作成部６２は、探索された経路データＲｉ（ｉ＝０，…，Ｎ）を順に取得し、取得した経路データＲｉ（ｉ＝０，…，Ｎ）においてユーザが要望（要求）している希望乗降地点を通過可能であるか否かを判定する。加えて、運行計画候補作成部６２は、取得した経路データＲｉ（ｉ＝０，…，Ｎ）において決定された所要時間Ｔｊ（ｊ＝０，…，Ｍ）に従い、オンデマンドバス１０が希望乗降地点間を希望乗降時刻及び付加時間によって運行可能であるか否かを判定する。そして、運行計画候補作成部６２は、希望乗降地点を通過し、付加時間を加味した希望乗降時刻（希望時刻）によって運行可能な経路データ及び所要時間、すなわち、候補経路及び運行時刻を運行計画候補として作成する。

このため、運行計画候補作成部６２（より詳しくは、制御装置２１ａのＣＰＵ）は、図８に示すフローチャートに従う運行計画候補作成プログラムを実行する。以下、この運行計画候補作成プログラムに従う各処理を具体的に説明する。

運行計画候補作成部６２（より詳しくは、制御装置２１ａのＣＰＵであるため、以下、単に「ＣＰＵ」と称呼する。）は、ステップＳ１０にて運行計画候補作成プログラムの実行を開始し、続くステップＳ１１にてユーザから予約情報（需要情報）が送信されているか否かを判定する。すなわち、ＣＰＵは、需要データベース２１ｄの所定記憶位置に記憶されている予約情報テーブルが更新されていれば、ユーザから予約情報（需要情報）が送信されているため、「Ｙｅｓ」と判定してステップＳ１２に進む。一方、予約情報テーブルが更新されていなければ、ユーザから予約情報（需要情報）が送信されていないため、ＣＰＵは「Ｎｏ」と判定してステップＳ２３に進み、本プログラムの実行を一旦終了する。そして、所定の短い時間の経過後、ＣＰＵは、再びステップＳ１０にて運行計画候補作成プログラムの実行を開始する。

ステップＳ１２からステップＳ１９までの各ステップ処理は、経路データ作成部５０の候補経路・時間作成部５２によって作成された複数の経路データＲｉ（ｉ＝０，…，Ｎ）及びこれらの経路データＲｉ（ｉ＝０，…，Ｎ）における所要時間Ｔｊ（ｊ＝０，…，Ｍ）のそれぞれについて、ユーザから送信された予約情報（需要情報）すなわち要望を満たすか否かを判定する。言い換えれば、ユーザが希望する予約情報（需要情報）を満たしてオンデマンドバス１０を運行させる候補経路及び運行時刻、すなわち、運行計画候補が存在するか否かを判定する。

具体的に、ステップＳ１２においては、ＣＰＵは、経路データＲｉを識別する番号ｉ及び所要時間Ｔｊを識別する番号ｊをそれぞれ「０」にリセットする。そして、ＣＰＵは、ステップＳ１３に進む。ステップＳ１３においては、ＣＰＵは、データ入力部６１によって運行データベース２１ｅから入力された経路データＲｉを番号ｉ＝「０」から順次取得する。そして、ＣＰＵは、ステップＳ１４に進む。

ステップＳ１４においては、ＣＰＵは、まず、前記ステップＳ１３にて取得した経路データＲｉについて、取得した経路データＲｉによって表される経路上をオンデマンドバス１０が走行するとき、ユーザが希望している希望乗降地点を通過するか否かを判断する。続いて、ＣＰＵは、希望乗降地点を通過する経路データＲｉについて、同経路データＲｉに対応して決定された所要時間Ｔｊを番号ｊ＝「０」から順次取得する。そして、ＣＰＵは、経路データＲｉによって表される経路上を所要時間Ｔｊに従ってオンデマンドバス１０が走行するとき、ユーザが希望している希望乗降地点に希望時刻である希望乗降時刻又は希望乗降時刻に付加時間を加えた時刻により出発又は到着するように運行可能であるか否かを判断する。

このように所要時間Ｔｊを用いたオンデマンドバス１０の運行可否を判断すると、ＣＰＵはステップＳ１５に進んで所要時間Ｔｊの番号ｊを「１」だけインクリメントする。そして、ＣＰＵは、続くステップＳ１６にて所要時間Ｔｊの番号ｊが最終番号である「Ｍ」よりも大きくなるまで繰り返し「Ｎｏ」と判定することにより、前記ステップＳ１４において、前記ステップＳ１３にて取得した経路データＲｉに対応して決定された所要時間Ｔｊ（ｊ＝０，…，Ｍ）に従ってオンデマンドバス１０の運行可否を判断することができる。

一方、ＣＰＵは、ステップＳ１６にて所要時間Ｔｊの番号ｊが最終番号である「Ｍ」よりも大きくなると、「Ｙｅｓ」と判定してステップＳ１７に進み、経路データＲｉの番号ｉを「１」だけインクリメントする。そして、ＣＰＵは、続くステップＳ１８にて経路データＲｉの番号ｉが最終番号である「Ｎ」よりも大きくなるまで繰り返し「Ｎｏ」と判定することにより、前記ステップＳ１３において順次経路データＲｉを取得し、前記ステップＳ１４にて前記取得した経路データＲｉに対応して決定された所要時間Ｔｊ（ｊ＝０，…，Ｍ）に従ってオンデマンドバス１０の運行可否を判断することができる。

そして、ＣＰＵは、ステップＳ１８にて経路データＲｉの番号ｉが最終番号である「Ｎ」よりも大きくなると、「Ｙｅｓ」と判定してステップＳ１９に進む。すなわち、前記ステップＳ１８にて「Ｙｅｓ」と判定する場合には、現在、探索されている全経路データＲｉ（ｉ＝０，…，Ｎ）及び各経路データＲｉ（ｉ＝０，…，Ｎ）に対応する全所要時間Ｔｊ（ｊ＝０，…，Ｍ）について、ユーザによって送信された予約情報（需要情報）を満たすオンデマンドバス１０の運行可否を判断した場合である。従って、ＣＰＵは、ステップＳ１９にて、前記ステップＳ１３〜Ｓ１８までの各ステップ処理を実行することにより、ユーザによって送信された予約情報（需要情報）に含まれる要望（要求）を満たしてオンデマンドバス１０を運行させることができる経路データＲｉすなわち候補経路が存在するか否かを判定する。

具体的に、ＣＰＵは、候補経路が存在するときは、「Ｙｅｓ」と判定してステップＳ２０に進む。一方、候補経路が存在しないときは、「Ｎｏ」と判定してステップＳ２２に進む。ステップＳ２２においては、ＣＰＵは、ユーザの要望（要求）を満たす候補経路が存在しないため、ユーザをオンデマンドバス１０に乗車させることができないと決定する。そして、ＣＰＵは、ステップＳ２３に進み、運行計画候補作成プログラムの実行を一旦終了し、所定の短い時間の経過後、再び、ステップＳ１０にて同プログラムの実行を開始する。

ステップＳ２０においては、今回、予約情報（需要情報）を送信したユーザを乗車させるに際して、ＣＰＵは、候補経路上を走行させるオンデマンドバス１０の定員枠に余裕があるか（定員枠内であるか）否かを判定する。すなわち、候補経路上を走行させるオンデマンドバス１０の定員枠に余裕があってユーザを乗車させることが可能であれば、ＣＰＵは「Ｙｅｓ」と判定してステップＳ２１に進む。一方、候補経路上を走行させるオンデマンドバス１０の定員枠に余裕がなくユーザを乗車させることが不能であれば、ＣＰＵは「Ｎｏ」と判定してステップＳ２２に進む。そして、ＣＰＵは、ステップＳ２２にてユーザをオンデマンドバス１０に乗車させることができないと決定する。その後、ＣＰＵはステップＳ２３に進み、運行計画候補作成プログラムの実行を一旦終了し、所定の短い時間の経過後、再び、ステップＳ１０にて同プログラムの実行を開始する。

ステップＳ２１においては、ＣＰＵは、今回、予約情報（需要情報）を送信したユーザをオンデマンドバス１０に乗車させることが可能であると判断して決定し、このオンデマンドバス１０を運行させる候補経路（経路データＲｉ）及び運行時刻（所要時間Ｔｊ）を運行計画候補として決定する。このように、運行計画候補を決定すると、ＣＰＵはステップＳ２３に進んで運行計画候補作成プログラムの実行を一旦終了し、所定の短い時間の経過後、再び、ステップＳ１０にて同プログラムの実行を開始する。

このように、運行計画候補作成プログラムを実行することにより、運行計画候補を決定するとともに、ユーザのオンデマンドバス１０への乗車可否を決定すると、運行計画候補作成部６２は、今回、予約情報（需要情報）を送信したユーザに対応して決定した運行計画候補を表す運行計画候補情報をデータ出力部６３に出力する。尚、運行計画候補作成部６２は、オンデマンドバス１０への乗車可否を表す乗車可否情報もデータ出力部６３に出力する。

データ出力部６３においては、運行計画候補作成部６２から出力された運行計画候補情報及び乗車可否情報を取得する。そして、データ出力部６３は、取得した運行計画候補情報を運行データベース２１ｅに出力する。これにより、運行データベース２１ｅの所定記憶位置には、今回、予約情報（需要情報）を送信したユーザに対応する運行計画候補情報が検索可能に蓄積されて記憶される。又、データ出力部６３は、取得した乗車可否情報を需要データベース２１ｄに出力する。これにより、需要データベース２１ｄの所定記憶位置には、今回、予約情報（需要情報）を送信したユーザに関連付けられて乗車可否情報が記憶される。従って、サーバ２１（制御装置２１ａ）は、記憶された乗車可否情報に基づき、ユーザがオンデマンドバス１０に乗車できない場合には、通信装置２２を利用して、該当するユーザにお断り情報を送信することができる。

次に、運行計画確定処理部７０を説明する。運行計画確定処理部７０は、図５に示すように、データ入力部７１を備えている。データ入力部７１は、需要データベース２１ｄから、同データベース２１ｄの所定記憶位置に、運行当日までに蓄積されて記憶された複数ユーザの予約情報（需要情報）を取得して入力する。そして、データ入力部７１は、入力した複数ユーザの予約情報（需要情報）を調整時間設定・計画確定部７２に供給する。又、データ入力部７１は、運行データベース２１ｅから、同データベース２１ｅの所定記憶位置に蓄積されて記憶された運行計画候補情報及び運行可能なオンデマンドバス１０のバス識別情報や、台数、乗員数を表すバス情報を取得して入力する。そして、データ入力部７１は、入力した運行計画候補情報及びバス情報を調整時間設定・計画確定部７２に供給する。

調整時間設定・計画確定部７２は、データ入力部７１を介して取得した複数ユーザの予約情報（需要情報）、運行計画候補情報及びバス情報を用いて、オンデマンドバス１０に乗車する複数のユーザの要望（要求）に合った運行計画を確定する。このため、調整時間設定・計画確定部７２（より詳しくは、制御装置２１ａのＣＰＵ）は、図９に示すフローチャートに従う運行計画確定処理プログラムを実行する。以下、この運行計画確定処理プログラムに従う各処理を具体的に説明する。

調整時間設定・計画確定部７２（より詳しくは、制御装置２１ａのＣＰＵであるため、以下、単に「ＣＰＵ」と称呼する。）は、ステップＳ５０にて運行計画確定プログラムの実行を開始する。そして、ＣＰＵは、続くステップＳ５１にて運行させるオンデマンドバス１０とユーザの要望（要求）に応じて送迎する便との各組み合わせに対応する全運行計画情報（具体的に、候補経路及び運行時刻）について、所定の評価式である評価関数の評価値を計算する。

すなわち、ＣＰＵは、評価項目が、各ユーザの希望乗降時刻（希望時刻）との差、オンデマンドバス１０の移動距離及び各サブエリアごとに決定されている調整時間であり、制約条件が便ごとの時間枠（最長時間）である評価関数を所定の評価式として採用する。ここで、評価項目である各ユーザの希望乗降時刻（希望時刻）との差については、予約情報（需要情報）によって表される希望乗降時刻と運行計画候補情報によって表される運行時刻とに基づいて決定される。又、評価項目であるオンデマンドバス１０の移動距離については、予約情報（需要情報）によって表される希望乗降地点や、運行計画候補情報によって表される候補経路、バス情報によって表されるオンデマンドバス１０の乗員数（一度に多くのユーザを送迎できるか否か）に基づいて決定される。更に、評価項目である各サブエリアごとに決定されている調整時間については、運行計画候補情報によって表される候補経路及び運行時刻に対応付けられている調整時間に基づく。

そして、ＣＰＵは、例えば、周知の計算方法に従って評価項目に対する重みを適宜設定し、全運行計画候補情報によって表される全候補経路について、各ユーザの希望乗降時刻（希望時刻）との差、移動距離及び調整時間を評価項目とする評価関数の評価値を計算する。このように、評価関数の評価値を計算すると、ＣＰＵはステップＳ５２に進む。ステップＳ５２においては、ＣＰＵは、前記ステップＳ５１にて計算した評価値に基づき、例えば、評価値が最大又は最小となる、具体的には、各ユーザの希望乗降時刻（希望時刻）との差が最小であり、移動距離が最小であり、更には、調整時間が最大となる評価関数の最適解を選択する。そして、ＣＰＵは、評価関数の最適解、言い換えれば、複数ユーザの要望（要求）を適切に満足する候補経路すなわち運行経路及びこの運行経路に対応する運行時刻からなる運行計画候補を選択すると、ステップＳ５３に進む。

ステップＳ５３においては、ＣＰＵは、前記ステップＳ５２にて選択した運行計画候補に基づき、１日を通して、運転手の休憩時間が確保されているか否かを判断する。すなわち、ＣＰＵは、運行計画候補、言い換えれば、運転手がオンデマンドバス１０を運行させる便と便との間の時間が、予め休憩時間として設定された時間以上空いているか否かを判断する。具体的に、例えば、午前中に運行される便Ａ（運行計画候補）と午後に運行される便Ｂ（運行計画候補）とが選択された状況を想定する。この状況において、便Ａが運行を終えて１２時に戻り、便Ｂが１３時に運行を開始する場合には、便Ａと便Ｂとの間に１時間の空き時間が存在する。この場合、例えば、昼休憩として１時間が設定されていれば、ＣＰＵは、空き時間の１時間が昼休憩時間として確保されていると判断する。一方、便Ａが運行を終えて１２時に戻り、便Ｂが１２時３０分に運行を開始する場合には、便Ａと便Ｂとの間に３０分の空き時間が存在する。この場合においては、ＣＰＵは、空き時間の３０分が昼休憩時間として確保されていないと判断する。

このように、休憩時間が確保されているか否かを判断すると、ＣＰＵは、ステップＳ５４に進んで、前記ステップＳ５３の判断により、運転手の休憩時間が確保されていれば、「Ｙｅｓ」と判定してステップＳ５５に進む。一方、前記ステップＳ５３の判断により、運転手の休憩時間が確保されていなければ、「Ｎｏ」と判定してステップＳ５１に戻る。そして、再び、前記ステップＳ５１〜Ｓ５３の各ステップＳ処理を実行し、運転手の休憩時間が確保されるまで、繰り返しステップＳ５４にて「Ｎｏ」と判定し続ける。

ステップＳ５５においては、ＣＰＵは、前記ステップＳ５２にて選択した運行計画候補、より詳しくは、候補経路（運行経路）に対応付けられていてサブエリアごとに決定されている調整時間を割り振る。すなわち、ＣＰＵは、例えば、需要データベース２１ｄの所定記憶位置に蓄積されて記憶された過去の予約情報（需要情報）すなわち過去の実績のうち、今回の予約情報（需要情報）によって表される要望と同一時間帯及び同一サブエリアの過去の予約情報（需要情報）を参照し、今回、選択した運行計画候補では経由しないものの、過去の実績において経由する頻度の高いノード（地点）が存在しているときには、このノード（地点）を経由することを想定して、決定された調整時間を運行計画候補の運行時刻に加味する（割り振る）。言い換えれば、ＣＰＵは、サブエリアごとに決定されている調整時間を全て運行計画候補の運行時刻に加味するのではなく、経由する必要がある（或いは、経由した方が良い）ノード（地点）を選択した場合には、この選択したノード（地点）を経由することを想定して、決定された調整時間を適宜増減して運行計画候補の運行時刻に加味する（割り振る）。このように、サブエリアごとに決定されている調整時間を割り振ると、ＣＰＵはステップＳ５６に進む。

ステップＳ５６においては、ＣＰＵは、前記ステップＳ５２にて選択した運行計画候補に対して前記ステップＳ５５にて調整時間を加味した（割り振った）運行計画候補を、最終的にオンデマンドバス１０ごとの１日分の運行計画（便）として確定する。そして、ＣＰＵ、１日分の運行計画（便）を確定すると、ステップＳ５７に進み、運行計画確定処理プログラムの実行を終了する。

このように、運行計画確定処理プログラムを実行することにより、運行計画（便）を決定すると、調整時間設定・計画確定部７２は、運行計画を表す運行計画情報とこの運行計画に従って運行されるオンデマンドバス１０のバス識別情報とを対応付けてデータ出力部７３に出力する。データ出力部７３においては、調整時間設定・計画確定部７２から出力された運行計画情報及びバス識別情報を取得する。そして、データ出力部７３は、取得した運行計画情報及びバス識別情報を運行データベース２１ｅに出力する。これにより、運行データベース２１ｅの所定記憶位置には、オンデマンドバス１０ごとの１日分の運行計画情報が検索可能に記憶される。

ここで、運行データベース２１ｅの所定記憶位置に運行計画情報が記憶されると、サーバ２１（制御装置２１ａ）は、予約情報（需要情報）を送信したユーザに対して、希望乗降地点及び希望時刻によってオンデマンドバス１０に乗車（又は降車）するために該当する運行計画情報すなわち便情報を、通信装置２２を利用して送信する。これにより、ユーザは、例えば、情報端末装置３０を介して受信した便情報を確認することにより、オンデマンドバス１０の運行計画を把握することができ、希望乗降地点及び希望時刻によりオンデマンドバス１０を利用することができる。

次に、予約追加受付処理部８０を説明する。予約追加受付処理部８０は、図５に示すように、データ入力部８１を備えている。データ入力部８１は、需要データベース２１ｄから、同データベース２１ｄの所定記憶位置に、運行当日であって運行計画確定処理部７０によって運行計画が確定された後に記憶された追加予約情報（追加需要情報）を取得して入力する。そして、データ入力部８１は、入力した追加予約情報（追加需要情報）を需要追加処理部８２に供給する。又、データ入力部８１は、運行データベース２１ｅから、同データベース２１ｅの所定記憶位置に記憶された運行計画情報及びバス識別情報を取得して入力する。そして、データ入力部８１は、入力した運行計画情報及びバス識別情報を需要追加処理部８２に供給する。

需要追加処理部８２は、既に運行計画確定処理部７０によって運行計画が確定された後において、追加予約が可能であるか否かを判断する。このため、需要追加処理部８２（より詳しくは、制御装置２１ａのＣＰＵ）は、図１０に示すフローチャートに従う予約追加対応処理プログラムを実行する。以下、この予約追加対応処理プログラムに従う各処理を具体的に説明する。

需要追加処理部８２（より詳しくは、制御装置２１ａのＣＰＵであるため、以下、単に「ＣＰＵ」と称呼する。）は、ステップＳ１００にて予約追加対応処理プログラムの実行を開始し、続くステップＳ１０１にてユーザから予約情報（需要情報）が追加されたか否かを判定する。すなわち、ＣＰＵは、需要データベース２１ｄの所定記憶位置に記憶されている予約情報テーブルが追加予約情報（追加需要情報）に従って更新されていれば、ユーザから予約情報（需要情報）が追加されているため、「Ｙｅｓ」と判定してステップＳ１０２に進む。一方、予約情報テーブルが更新されていなければ、ユーザから予約情報（需要情報）が追加されていないため、ＣＰＵは「Ｎｏ」と判定してステップＳ１１２に進み、本プログラムの実行を一旦終了する。そして、所定の短い時間の経過後、ＣＰＵは、再びステップＳ１００にて予約追加対応処理プログラムの実行を開始する。

ステップＳ１０２においては、ＣＰＵは、運行計画確定処理部７０によって確定された運行計画情報によって表される１日分の運行計画、すなわち、オンデマンドバス１０を１日運行する各便を表す便情報Ｂｒ（ｒ＝０，…，Ｌ）を識別する番号ｒを「０」にリセットする。続いて、ＣＰＵは、ステップＳ１０３にて、データ入力部８１によって運行データベース２１ｅから入力された運行計画情報、言い換えれば、便情報Ｂｒを番号ｒ＝「０」から順次取得する。そして、ＣＰＵは、ステップＳ１０４に進む。

ステップＳ１０４においては、ＣＰＵは、前記ステップＳ１０３にて取得した便情報Ｂｒの番号ｒが最終便を表す「Ｌ」以下であるか否かを判定する。すなわち、ＣＰＵは、番号ｒが「Ｌ」以下であれば、言い換えれば、取得した便情報Ｂｒが最終便までの便情報であれば「Ｙｅｓ」と判定してステップＳ１０５に進む。一方、番号ｒが「Ｌ」よりも大きければ、言い換えれば、取得した便情報Ｂｒが本日の最終便よりも後の便情報であれば「Ｎｏ」と判定して、後述するステップＳ１１１に進む。

ステップＳ１０５においては、ＣＰＵは、データ入力部８１によって入力された追加予約情報（追加需要情報）のうちの希望時刻情報に基づいて、前記ステップＳ１０３にて取得した便情報Ｂｒが希望乗降時刻（希望時刻）に合致する便であるか否かを判定する。すなわち、ＣＰＵは、取得した便情報Ｂｒがユーザの希望乗降時刻（希望時刻）に合致する便であれば、「Ｙｅｓ」と判定してステップＳ１０６に進む。一方、前記ステップＳ１０３にて取得した便情報Ｂｒが希望乗降時刻（希望時刻）に合致する便でなければ、ＣＰＵは「Ｎｏ」と判定して後述するステップＳ１１０に進む。

ステップＳ１０６においては、ＣＰＵは、データ入力部８１によって入力された追加予約情報（追加需要情報）のうちの希望乗降地点情報に基づいて、前記ステップＳ１０５にてユーザの希望乗降時刻（希望時刻）に合致すると判定された便情報Ｂｒ（以下、「希望便情報Ｂｒ」と称呼する。）により運行されるオンデマンドバス１０に、ユーザの希望乗降地点にて乗車（又は降車）する他の乗客（ユーザ）がいるか否かを判定する。すなわち、ＣＰＵは、ユーザの希望乗降地点にて乗車（又は降車）する他の乗客（ユーザ）がいれば「Ｙｅｓ」と判定してステップＳ１０８に進む。一方、ユーザの希望乗降地点にて乗車（又は降車）する他の乗客（ユーザ）がいなければ、ＣＰＵは「Ｎｏ」と判定してステップＳ１０７に進む。

ステップＳ１０７においては、ＣＰＵは、希望便情報Ｂｒによって表される運行経路及び運行時刻に対し、ユーザの希望乗降地点を経由するために必要な調整時間が確保されている（割り振られている）か否かを判定する。すなわち、ＣＰＵは、運行経路及び運行時刻に対してユーザの希望乗降地点を経由するために必要な調整時間が確保（加味）されていれば、「Ｙｅｓ」と判定してステップＳ１０８に進む。ここで、ＣＰＵは、追加予約情報（追加需要情報）を送信したユーザの希望乗降地点を経由するために、確保（加味）されている調整時間を用いて運行経路を変更する。

ステップＳ１０８においては、ＣＰＵは、希望便情報Ｂｒに従って運行されるオンデマンドバス１０の定員枠に余裕があるか（定員枠内であるか）否かを判定する。すなわち、希望便情報Ｂｒに従って運行されるオンデマンドバス１０の定員枠に余裕があって、追加予約情報（追加需要情報）を送信したユーザを乗車させることが可能であれば、ＣＰＵは「Ｙｅｓ」と判定してステップＳ１０９に進む。そして、ＣＰＵは、ステップＳ１０９にてユーザのオンデマンドバス１０への乗車が可能と決定し、続くステップＳ１１２にて本プログラムの実行を一旦終了する。一方、希望便情報Ｂｒに従って運行されるオンデマンドバス１０の定員枠に余裕がなく追加予約情報（追加需要情報）を送信したユーザを乗車させることが不能であれば、ＣＰＵは「Ｎｏ」と判定してステップＳ１１０に進む。そして、ＣＰＵは、ステップＳ１１０にて便情報Ｂｒの番号ｒを「１」だけインクリメントし、前記ステップＳ１０３にて次の便情報Ｂｒを取得する。

又、前記ステップＳ１０７にて、ＣＰＵは、運行経路及び運行時刻に対してユーザの希望乗降地点を経由するために必要な調整時間が確保（加味）されていなければ、「Ｎｏ」と判定してステップＳ１１１に進む。ステップＳ１１１においては、ＣＰＵは、前記ステップＳ１０４の判定処理に基づいて既にユーザが乗車可能なオンデマンドバス１０の便が存在しない、或いは、前記ステップＳ１０７の判定処理に基づいて希望便情報Ｂｒに従って運行されるオンデマンドバス１０が希望乗降地点を通過しないため、ユーザをオンデマンドバス１０に乗車させることができないと決定する。その後、ＣＰＵはステップＳ１１２に進み、予約追加対応処理プログラムの実行を一旦終了する。そして、ＣＰＵは、所定の短い時間の経過後、再び、ステップＳ１００にて同プログラムの実行を開始する。

このように、予約追加対応処理プログラムを実行することにより、希望便情報Ｂｒを判定するとともにこの希望便情報Ｂｒによって運行されるオンデマンドバス１０への乗車を許可する、又は、オンデマンドバス１０への乗車を許可しないことを決定すると、需要追加処理部８２は、希望便情報Ｂｒとオンデマンドバス１０への乗車可否を表す乗車可否情報とをデータ出力部８３に出力する。データ出力部８３においては、需要追加処理部８２から出力された希望便情報Ｂｒ及び乗車可否情報を取得する。そして、データ出力部８３は、取得した希望便情報Ｂｒ及び乗車可否情報を運行データベース２１ｅに出力する。これにより、運行データベース２１ｅの所定記憶位置には、今回、送信された追加予約情報（追加需要情報）を判定した希望便情報Ｂｒすなわち調整された（変更された）運行計画情報及び乗車可否情報が検索可能に記憶される。

これにより、サーバ２１（制御装置２１ａ）は、追加予約情報（追加需要情報）を送信したユーザに対して、希望便情報Ｂｒを通信装置２２を利用して送信する。これにより、ユーザは、例えば、情報端末装置３０を介して受信した希望便情報Ｂｒを確認することにより、オンデマンドバス１０の運行計画を把握することができ、希望乗降地点及び希望時刻によりオンデマンドバス１０を利用することができる。又、サーバ２１（制御装置２１ａ）は、既に運行計画情報すなわち便情報が送信されているユーザに対して、例えば、予約情報（需要情報）を追加したユーザが希望する乗降地点を経由するために運行経路が若干変更される場合において、変更が生じることを報知することもできる。更に、サーバ２１（制御装置２１ａ）は、記憶された乗車可否情報に基づき、追加予約情報（追加需要情報）を送信したユーザがオンデマンドバス１０に乗車できない場合には、通信装置２２を利用して、該当するユーザにお断り情報を送信することもできる。

以上の説明からも理解できるように、上記実施形態によれば、オンデマンドバス１０の運行エリアを複数のサブエリアに分割（区画）し、サブエリアごとに必要十分な調整時間を設定することができる。これにより、運行上、無駄な時間（冗長時間）を生じさせることを抑制することができるとともに、調整時間を利用して自由度の高い運行計画を決定することができる。

すなわち、調整時間は、上述したように、サブエリアに対して設定されるものであり、例えば、サブエリア内の個々の特定地点を経由する場合の時間等、地点を特定した上で設定される調整時間ではない。従って、制御装置２１ａが、この調整時間を適宜増減して加味し運行計画を決定することにより、例えば、新たなユーザが追加予約情報（追加需要情報）を送信（伝達）した場合であっても、このユーザの希望乗降地点にオンデマンドバス１０が向かう際の所要時間が希望乗降地点の存在するサブエリアごとに設定された調整時間内であれば、運行計画が決定された時点で予約情報（需要情報）を送信（伝達）していた他のユーザによるオンデマンドバス１０の利用に対する影響を極めて小さくすることができる。言い換えれば、サブエリアごとに調整時間を設定することができることにより、決定される運行計画における自由度を高めることができて、一旦決定された運行計画に対して追加の要望を加える場合であっても、全体の運行計画に対する影響を小さくして要望を追加することができる。従って、速やかに新たな運行計画を決定することができる。

本発明の実施にあたっては、上記実施形態に限定されるものではなく、本発明の目的を逸脱しない限りにおいて種々の変更が可能である。

例えば、上記実施形態においては、運行計画が決定（確定）された後、新たなユーザが追加予約情報（追加需要情報）を送信し、既に決定（確定）された運行計画に新たな要望（要求）を加味する場合を想定して実施した。この場合、既に予約情報（需要情報）を送信しているユーザが、例えば、希望乗降地点を変更したり、希望乗降時刻を変更した利することを要求する場合、言い換えれば、改めて新たな要望（要求）を追加した場合であっても、上記実施形態と同様に、これらの変更を加味して運行計画を調整（変更）可能であることは言うまでもない。

又、上記実施形態においては、運行計画確定処理部７０の調整時間設定・計画確定部７２は、原則として、ユーザによって送信（伝達）された予約情報（需要情報）を変更することなく、オンデマンドバス１０の運行計画を確定するように実施した。又、予約追加受付処理部８０の需要追加処理部８２は、原則として、運行計画が確定された後にユーザによって送信（伝達）された追加予約情報（追加需要情報）を変更することなく、確保されている調整時間を利用してオンデマンドバス１０の運行計画を確定するように実施した。

この場合、例えば、あるユーザが希望している希望乗降地点や希望時刻、乗降ステータス情報による付加時間を変更してもらうことにより、運行計画の調整（変更）に対する影響がより小さくなったり、或いは、運行計画（便）を減少させることができるときには、調整時間設定・計画確定部７２及び需要追加処理部８２、すなわち、サーバ２１の制御装置２１ａは、該当するユーザに対して予約情報（需要情報）や追加予約情報（追加需要情報）の変更を依頼することができる。尚、この場合、該当するユーザが予約情報等の変更依頼を受諾した場合には、例えば、オンデマンドバス１０の利用に際して発生する運賃を割り引く等の特典を付与することができる。このように、予約情報等の変更を依頼し、変更された予約情報等に基づいて運行計画を確定することによって、より多くのユーザの要望を満足する運行計画に従ってオンデマンドバス１０を効率良く運行させることができる。

更に、上記実施形態においては、本発明に係るオンデマンド車両運行管理装置を運行管理センタ２０に設けて実施した。この場合、例えば、オンデマンドバス１０に搭載された運行情報端末装置１１（より詳しくは、電子制御ユニット１１ａ）やユーザが所持する情報端末装置３０（より詳しくは、電子制御ユニット３３）が、単独により、或いは、協働して、上述した経路データ作成部５０、予約受付処理部６０、運行計画確定処理部７０及び予約追加受付処理部８０と同等の機能を実現するように実施することも可能である。この場合においても、上記実施形態と同様の効果が得られる。

Claims (12)

1. 複数の利用者からの要望に基づいてオンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理する運行管理手段を備えたオンデマンド車両運行管理装置であって、
   前記運行管理手段が、
   前記オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割し、
   前記分割した前記サブエリアごとに、前記オンデマンド車両が走行する経路を探索し、
   前記探索した経路のうちの一つを基本経路に決定し、
   前記基本経路を走行する前記オンデマンド車両が前記基本経路から離間した地点を経由するために必要な時間である調整時間を考慮して前記運行計画を決定する、
   ことを特徴とするオンデマンド車両運行管理装置。
2. 請求項１に記載したオンデマンド車両運行管理装置において、
   前記運行管理手段は、前記運行計画の決定後、新たな利用者によって要望が追加された場合、前記調整時間を用いて前記新たな利用者の前記要望に基づいて前記運行計画を変更する、
   ことを特徴とするオンデマンド車両運行管理装置。
3. 請求項１又は請求項２に記載したオンデマンド車両運行管理装置において、
   前記運行管理手段は、前記オンデマンド車両の運転手の休憩時間が確保されるように前記運行計画を決定する、
   ことを特徴とするオンデマンド車両運行管理装置。
4. 複数の利用者からの要望に基づいてオンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理するオンデマンド車両運行管理方法であって、
   コンピュータ装置を用いて、
   前記オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割し、
   前記分割した前記サブエリアごとに、前記オンデマンド車両が走行する経路を探索し、
   前記探索した経路のうちの一つを基本経路に決定し、
   前記基本経路を走行する前記オンデマンド車両が前記基本経路から離間した地点を経由するために必要な時間である調整時間を考慮して前記運行計画を決定する、
   ことを特徴とするオンデマンド車両運行管理方法。
5. 請求項４に記載したオンデマンド車両運行管理方法において、
   前記運行計画の決定後、新たな利用者によって要望が追加された場合、前記調整時間を用いて前記新たな利用者の前記要望に基づいて前記運行計画を前記コンピュータ装置を用いて変更する、
   ことを特徴とするオンデマンド車両運行管理方法。
6. 請求項４又は請求項５に記載したオンデマンド車両運行管理方法において、
   前記オンデマンド車両の運転手の休憩時間が確保されるように前記運行計画を前記コンピュータ装置を用いて決定する、
   ことを特徴とするオンデマンド車両運行管理方法。
7. 複数の利用者が乗車するオンデマンド車両と、前記複数の利用者からの要望に基づいて前記オンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理する運行管理センタと、前記利用者によって操作される情報端末装置であって前記要望を前記運行管理センタに供給する情報端末装置と、からなるオンデマンド車両運行管理システムであって、
   前記運行管理センタが、
   前記オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割し、
   前記サブエリアごとに前記オンデマンド車両が走行する経路を探索し、
   前記探索した経路のうちの一つを基本経路に決定し、
   前記基本経路を走行する前記オンデマンド車両が前記基本経路から離間した地点を経由するために必要な時間である調整時間を考慮して前記運行計画を決定する、
   ことを特徴とするオンデマンド車両運行管理システム。
8. 請求項７に記載したオンデマンド車両運行管理システムにおいて、
   前記運行管理センタは、前記運行計画の決定後、新たな利用者による要望が前記情報端末装置を介して追加されたとき、前記調整時間を用いて前記新たな利用者の前記要望に基づいて前記運行計画を変更する、
   ことを特徴とするオンデマンド車両運行管理システム。
9. 請求項７又は請求項８に記載したオンデマンド車両運行管理システムにおいて、
   前記運行管理センタは、前記オンデマンド車両の運転手の休憩時間が確保されるように前記運行計画を決定する、
   ことを特徴とするオンデマンド車両運行管理システム。
10. 複数の利用者からの要望に基づいてオンデマンド車両の運行計画を決定し、決定した運行計画に従って前記オンデマンド車両の運行を管理する運行管理手段を備えたオンデマンド車両運行管理装置であって、
    前記運行管理手段が、
    前記オンデマンド車両を運行させる運行エリアを所定の複数のサブエリアに分割し、
    前記運行計画の確定前に利用者から予約を受け付けた場合、同利用者が要望する希望乗降地点を通りかつ同利用者が要望する希望時刻に前記オンデマンド車両を運行させることが可能な候補経路の有無を判断し、
    前記候補経路が存在する場合、前記利用者を前記オンデマンド車両に乗車させることが可能であると判断し、
    前記利用者を前記オンデマンド車両に乗車させることが可能であると判断した前記候補経路全てについて所定の評価式を計算して最適解を有する候補経路を基本経路として選択し、
    前記基本経路を走行する前記オンデマンド車両が前記基本経路から離間した地点を経由するために必要な時間である調整時間を考慮して前記運行計画を確定し、
    前記運行計画の確定後に利用者から追加予約を受け付けた場合、前記追加予約をした前記利用者が要望する希望乗降地点を通りかつ同利用者が要望する希望時刻での運行が可能となるように前記調整時間を用いて前記運行計画を変更する、
    ことを特徴とするオンデマンド車両運行管理装置。
11. 請求項１０に記載したオンデマンド車両運行管理装置において、
    前記運行管理手段が、
    前記運行計画の確定前に利用者から受け付けた予約に含まれる要望と、過去に受け付けた予約に含まれていて前記要望と同一時間帯及び同一サブエリアにおける過去の要望とを比較し、
    前記過去の要望により頻度の高い時間帯及びサブエリアに応じて前記調整時間を前記運行計画の確定に考慮する、
    ことを特徴とするオンデマンド車両運行管理装置。
12. 請求項１０又は請求項１１に記載したオンデマンド車両運行管理装置において、
    前記運行管理手段は、前記オンデマンド車両の運転手の休憩時間が確保されるように前記運行計画を確定する、
    ことを特徴とするオンデマンド車両運行管理装置。
    

Images