JP2009301078A - 車両運行システム - Google Patents

Abstract

【課題】
時間帯によって集中需要区間が存在する場合であっても、合理的な運行計画を簡易に作成して、車両運行サービスを提供する。
【解決手段】
運行計画の作成に先立って、記憶部２１０に記憶されている利用実績情報に基づいて、集中需要対応運行計画作成部２２０が、需要の多い時間帯である集中需要時間帯と、車両利用の需要の多い停留所区間である集中需要区間との組み合わせに対する集中需要を抽出し、抽出結果に基づいて集中需要に適切に対応できる集中需要対応運行計画を作成する。そして、運行計画作成手段が、乗降地点、乗車人数及び乗車希望時刻を含む乗合車両の新たな利用要求情報に対応して、集中需要対応運行計画手段により作成された集中需要対応運行計画をそのまま取り込みつつ、現在の運行計画の更新を行ない、最適化された新たな運行計画を作成して、車両運行サービスを行う。
【選択図】 図４

Description

本発明は、利用者からのデマンドに基づいて運行計画を作成し、作成された運行計画に沿って車両の運行を行う車両運行システムに関する。

近年、利用者が希望する乗車位置、乗車時刻及び降車位置を含むデマンドを受けて運行計画を作成し、作成された運行計画に従って、バス等の車両の運行を行うデマンドバスシステム等の車両運行システムが注目されている。こうした車両運行システムでは、従来から、受け付けられたデマンドに基づき、乗車待ち時間、迂回時間又は車両の総走行時間等といった、サービス圏内全体にわたる利用者の条件又は運行車両の走行条件を考慮して運行計画の作成を行っている（特許文献１参照）。

こうした車両運行システムによれば、サービス圏内であれば、利用者は、どこからどこへでも乗り継ぎなしで、自由に行けるサービスを受けることができる。このため、路線バス方式よりもかなりコストパフォーマンスの高いサービスの提供が可能となっている。

特開２００３−１７４３９７号公報

上述した従来の車両運行システムにおいては、需要が少ない場合には路線バス方式よりも効率よくサービスできるが、集中需要があるところでは、受け付けたデマンドの１件ずつを組み合わせて最適化して運行計画を作成するという一般的な方法を採用することにすると、受付業務が膨大となってしまうとともに、迅速な運行計画の算出のためには計算資源を用意することが必要となってしまう。さらに、車両運用が輻輳して、全体の効率が低下する傾向がある。このため、従来では、需要の多いところには路線バスの運用を行ない、運行し、需要の少ないところだけを対象としてデマンド受け付けを行って、運行計画を作成することが一般的とされていた。

しかしながら、路線バス方式を採用した重要集中区間に対しては、走行ルートと時刻表を固定し、公表して運行するために、天候等による需要の変動に対して、きめ細かく可変的に対応できない。このため、一部区間における路線バス方式の採用は、システム全体のコスト増及び車両の効率の低下を余儀なくされていた。

本発明は、上記の事情を鑑みてなされたものであり、時間帯によって集中需要区間が存在する場合であっても、合理的な運行計画を簡易に作成して、車両運行サービスを提供することができる新たな車両運行システムを提供することを目的とする。

本発明者が、長年の研究・開発の経験から得た知見によれば、従来の技術において発生した様々な問題点は、一部の集中需要のために、広い区域において走行箇所とダイヤを固定して車両運用を行うこと、又は、需要の多少に関係なく、デマンドの全てを同じ条件で受け付けようとすることに起因している。本発明は、かかる知見に基づいてなされたものである。

すなわち、本発明の車両運行システムは、運行サービスの提供に供される車両の利用の実績情報を記憶する記憶手段と；前記記憶手段における記憶内容に基づいて、前記車両利用の需要の多い時間帯である集中需要時間帯と、前記車両利用の需要の多い停留所区間である集中需要区間との組み合わせに対する集中需要を抽出し、抽出結果に基づいて、前記集中需要に対応する集中需要対応運行計画を作成する集中需要対応運行計画作成手段と；乗降地点、乗車人数及び乗車希望時刻を含む乗合車両の新たな利用要求情報に対応して、前記集中需要対応運行計画作成手段により作成された集中需要対応運行計画をそのまま取り込みつつ、現在の運行計画の更新を行ない、最適化された新たな運行計画を作成する運行計画作成手段と；前記新たな運行計画に基づいて、前記車両ごとに運行時刻順に乗降地点を抽出し、該当する車両の車載装置へ送信する運行制御手段と；を備えることを特徴とする車両運行システムである。

この車両運行システムでは、記憶手段における記憶されている運行サービスの提供に利用される車両の利用実績情報に基づいて、集中需要対応運行計画作成手段が、需要の多い時間帯である集中需要時間帯と、車両利用の需要の多い停留所区間である集中需要区間との組み合わせに対する集中需要を抽出する。ここで、利用実績情報には、利用時間、乗車停留所といった情報に加えて、曜日情報や天候情報等を含むようにすることができる。

引き続き、集中需要対応運行計画作成手段が、抽出結果に基づいて、定期的に集中需要に適切に対応できる集中需要対応運行計画を作成する。ここで、利用実績情報には、利用時間、乗車停留所といった情報に加えて、曜日情報や天候情報等が含まれている場合には、需要の曜日変動や、天候変動に適切に対応できる集中需要対応運行計画を作成することができる。

なお、集中需要対応運行計画は、変動要素に対応した複数のパターンのそれぞれについて、例えば月に一度等に予め作成しておき、適用日における変動要素の値に応じて選択するようにすることもできるし、変動要素の値が確定した時点で、適用日ごとに新たに作成するようにすることもできる。

以上のようにして、適用日の集中需要対応運行計画が作成されていることを前提として、運行計画作成手段が、乗降地点、乗車人数及び乗車希望時刻を含む乗合車両の新たな利用要求情報に対応して、集中需要対応運行計画作成手段により作成された集中需要対応運行計画をそのまま取り込みつつ、現在の運行計画の更新を行ない、最適化された新たな運行計画を作成する。

こうして、新たな運行計画が作成されると、運行制御手段が、新たな運行計画に基づいて、車両ごとに運行時刻順に乗降地点を抽出し、該当する車両の車載装置へ送信する。こうして送信された運行時刻順に乗降地点の情報に基づいて、各車両の運行が行われる。

したがって、本発明の車両運行システムによれば、時間帯によって集中需要区間が存在する場合であっても、合理的な運行計画を簡易に作成して、車両運行サービスを提供することができる。

本発明の車両運行システムでは、前記車両に搭載され、乗降実績情報を送信する集中需要実績送信手段と；前記集中需要実績送信手段からの乗降実績情報に基づいて、前記記憶手段における利用実績情報を更新する利用実績更新手段と；を更に備えるようにすることができる。

この場合には、実際の運行計画に基づく車両運行において得られた乗降実績情報が、運行中車両における集中需要実績送信手段から報告される。この報告を受けた利用実績更新手段は、記憶装置内の利用実績情報を更新する。このため、集中需要対応運行計画作成手段は、実際の利用実績を学習的に反映させたうえで、合理的な集中需要対応運行計画の作成を行うことができる。

また、本発明の車両運行システムでは、前記集中需要区間における停留所に配置された運行情報提示手段と；前記集中需要対応運行計画に基づいて、前記集中需要区間の停留所ごとにおける前記車両の通過予定時刻情報を生成して、該当する停留所に配置された運行情報提示手段へ送る集中需要対応情報送信手段と；を更に備えるようにすることができる。

この場合には、集中需要対応情報送信手段が、適用日の当日における集中需要区間における停留所ごとにおける車両の通過予定時刻情報を生成して、該当する停留所に配置された運行情報提示手段へ送る。そして、運行情報提示手段が、配置された停留所における車両の通過予定時刻情報を利用者に提示する。このため、利用者の利便性を向上できるとともに、集中需要区間における車両利用を集中需要対応計画による車両運行に効率的に集約することができる。

ここで、前記運行情報提示手段が、現在時刻以降の前記集中需要時間帯における前記車両の通過予定時刻情報を提示するようにすることができる。

以上説明したように、本発明の車両運行システムによれば、時間帯によって集中需要区間が存在する場合であっても、合理的な運行計画を簡易に作成して、車両運行サービスを提供することができるという効果を奏する。

以下、本発明の一実施形態を、図１〜図１２を参照しつつ説明する。なお、図面においては、同一又は同等の要素については同一の符号を付し、重複する説明を省略する。

［構成］
図１には、本発明の一実施形態に係る車両運行サービスシステムであるデマンドバスシステム１００の構成の概略が模式的に示されている。この図１に示されるように、デマンドバスシステム１００は、管理センタ１１０と、バス車両１５０_j（ｊ＝１〜５）と、車両通過時刻情報提示装置１６０_k（ｋ＝１，…）とを備えている。

ここで、管理センタ１１０は、利用者の電話機３１０又は携帯電話機３２０から、公衆電話網や移動通信網を介して、バスの利用予約に関するデマンドＤＭＤ１，ＤＭＤ２を受けるとともに、当該デマンドＤＭＤ１，ＤＭＤ２に対する応答ＲＳＰ１，ＲＳＰ２を送るようになっている。ここで、電話機３１０や携帯電話機３２０は多数存在するが、図１では、１台ずつが代表的に示されている。

また、管理センタ１１０は、バス車両１５０_j（ｊ＝１〜５）へ、運行指示情報ＲＴＤ_jを送るようになっている。また、また、バス車両１５０_jは、管理センタ１１０からの運行指示情報ＲＴＤ_jに従って、サービス領域ＳＶＡ内を走行するようになっている。更に、バス車両１５０_jのそれぞれは、運行指示情報ＲＴＤ_jに従って、サービス領域ＳＶＡ内を走行において得られる、後述する乗車人数情報ＮＲＤ_jを、管理センタ１１０へ送る。

なお、本実施形態では、サービス領域ＳＶＡにおいては、バス停を全体で約250箇所設定してあるが、例えば、図２に示されるように、午前９時台にバス停Ａ→Ｂ，Ｃ→Ｄという集中需要の乗降区間があり、午後２〜４時台にその逆の集中需要の乗降区間があるものとする。

管理センタ１１０は、図３に示されるように、電話装置１１１と、入力装置１１２と、表示装置１１３とを備えている。また、管理センタ１１０は、処理制御部１１５と、バス通信部１１７と、バス停通信部１１８とを備えている。

上記の電話装置１１１は、利用者の電話機３１０や携帯電話機３２０との間で通話通信を行う。この電話装置１１１を利用して、管理センタ１１０に駐在するオペレータが、利用者からのバスの利用予約に関するデマンドＤＭＤ１，ＤＭＤ２を受けたり、当該デマンドＤＭＤ１，ＤＭＤ２に対する応答ＲＳＰ１，ＲＳＰ２を送ったりするようになっている。ここで、デマンドＤＭＤ１，ＤＭＤ２の内容は、乗降するバス停留所名、乗降人数及び乗車希望時刻等を含んでいる。

入力装置１１２は、キーボードやマウス等を備えて構成されている。この入力装置１１２を操作して、オペレータは、デマンドＤＭＤ１，ＤＭＤ２の内容や各種指令を処理制御部１１５へ入力するようになっている。

表示装置１１３は、液晶ディスプレイパネル等を備えて構成されている。この表示装置１１３には、操作ガイダンス、入力装置１１２を利用した入力結果、新たに作成された運行計画候補におけるデマンドＤＭＤ１，ＤＭＤ２に対応する乗車可能時刻等が表示されるようになっている。

なお、オペレータは、表示装置１１３に表示される入力結果を確認しつつ、入力装置１１２を操作して、オペレータは、デマンドＤＭＤ１，ＤＭＤ２の内容を処理制御部１１５へ入力するようになっている。

処理制御部１１５は、管理センタ１１０全体の動作を制御する。この処理制御部１１５は、図４に示されるように、記憶部２１０と、集中需要対応運行計画作成部２２０と、運行計画作成部２３０とを備えている。また、処理制御部１１５は、集中需要対応情報送信部２４０と、利用実績更新部２５０と、運行制御部２６０とを備えている。

記憶部２１０は、ハードディスク装置等を備えて構成されている。この記憶部２１０には、図５（Ａ）に示されるように、利用実績情報２１１、集中需要対応運行計画候補情報２１２、集中需要対応運行計画情報２１３、予約リスト２１４、運行計画情報２１５等の様々な情報データが記憶されている。

なお、記憶部２１０には、日々の年月日、曜日、天候等の情報が記憶されるようになっている。こうした情報は、入力装置１１２から入力することもできるし、管理センタ１１０における計時手段や、気象情報提供サイトから得るようにすることもできる。

利用実績情報２１１としては、図５（Ｂ）に示されるように、需要の変動要素パターンごとに、それまでの実際に運用された運行計画と各バス停の乗降情報とが、時系列で、最近の所定期間分が登録される。ここで、所定期間の長さは、実験、シミュレーション、経験等に基づいて、予め定められる。

なお、本実施形態では、当該変動要素パターンは、曜日と天候との組み合わせで指定されるようになっている。また、本実施形態では、乗降情報は、乗車人数となっている。

集中需要対応運行計画候補情報２１２としては、集中需要対応運行計画作成部２２０により、後述のようにして作成された集中需要対応運行計画候補が登録される。なお、集中需要対応運行計画候補は、需要の変動要素パターンごとに作成されるようになっている。

集中需要対応運行計画情報２１３としては、実際に運用中の集中需要対応運行計画、又は、前回の運行計画によるサービス提供が終了した後における次のサービス提供で適用されるべき運行計画で採用される集中需要対応運行計画が登録される。このため、集中需要対応運行計画情報２１３の内容は、一般に、毎日更新される。

予約リスト２１４には、現時点の運行計画において予約がなされているデマンドが登録されている。また、運行計画情報２１５には、現時点の運行計画が登録されている。

図４に戻り、集中需要対応運行計画作成部２２０は、集中需要対応運行計画候補を、例えば月に１回というように、定期的に作成する。かかる集中需要対応運行計画候補の作成に際して、集中需要対応運行計画作成部２２０は、まず、記憶部２１０から、利用実績情報を読み取り、需要の変動パターンごとに、集中需要が発生する蓋然性が高い区間と時間帯との組み合わせを抽出する。引き続き、集中需要対応運行計画作成部２２０は、当該組み合わせのそれぞれにおける需要量（すなわち、利用人数）の予測値を算出する。

次に、集中需要対応運行計画作成部２２０は、当該組み合わせの抽出結果と、需要量の予測結果とに基づいて、需要の変動パターンごとの集中需要対応運行計画候補を作成する。そして、集中需要対応運行計画作成部２２０は、こうして作成された集中需要対応運行計画候補に、集中需要対応運行計画候補情報２１２の内容を更新する。

また、集中需要対応運行計画作成部２２０は、運行計画作成の作成対象なる日の曜日、天候という需要の変動パターンが定まった段階（遅くとも運行計画作成の作成対象なる日におけるデマンド受付開始時刻まで）で、当該変動パターンに対応する集中需要対応運行計画候補を読み出す。そして、集中需要対応運行計画作成部２２０は、読み出された集中需要対応運行計画候補に、集中需要対応運行計画情報２１３の内容を更新する。

運行計画作成部２３０は、新たなデマンドの内容を受けると、集中需要対応運行計画情報２１３に記憶された集中需要対応運行計画をそのまま取り込みつつ、新たな運行計画候補を作成する。そして、新たな運行計画が決定されると、運行計画作成部２３０は、予約リスト２１４に当該新たなデマンドの内容を追加するとともに、運行計画情報２１５の内容を、決定された新たな運行計画に更新する。

なお、本実施形態では、バス車両１５０_j（ｊ＝１〜５）に対して、ルート、ダイヤ及び担当エリアは予め設定されておらず、バス停を全体で約３００箇所設定してある。そして、運行計画作成部２３０は、デマンドに応じて、自由な乗降の組み合わせ及び配車計算を行い、最適解を選定して運行計画を作成していくようになっている。

集中需要対応情報送信部２４０は、集中需要対応運行計画情報２１３に基づいて、車両通過時刻情報提示装置１６０_k（ｋ＝１，…）それぞれに通知すべき車両通過時刻情報ＤＴＤ_kを作成する。そして、集中需要対応情報送信部２４０は、車両通過時刻情報ＤＴＤ_kを、対応する車両通過時刻情報提示装置１６０_kへ、バス停通信部１１８を介して送る。

なお、集中需要対応情報送信部２４０は、後述するように、一定時間ごとに、作成された車両通過時刻情報ＤＴＤ_kを、対応する車両通過時刻情報提示装置１６０_kへ送るようになっている。

利用実績更新部２５０は、日々のデマンド受付終了時刻となると、運行計画情報２１５を読み出し、読み出された結果を利用実績情報２１１内に追加する。また、利用実績更新部２５０は、バス車両１５０_jからバス通信部１１７を介して受けた乗車人数情報ＮＲＤ_jに基づいて、利用実績情報２１１の内容を更新する。ここで、乗車人数情報ＮＲＤ_jには、バス車両１５０_jの識別子、バス停の識別子、年月日及び時刻情報、乗車人数等が含まれている。

なお、利用実績更新部２５０は、所定期間が経過した情報については、利用実績情報２１１内から削除するようになっている。

運行制御部２６０は、運行計画情報２１５に基づいて、バス車両１５０_j（ｊ＝１〜５）に通知すべき運行指示ＲＴＤ_jを作成する。そして、運行制御部２６０は、運行指示情報ＲＴＤ_jを、対応するバス車両１５０_jへ向けて送る。

なお、運行制御部２６０は、後述するように、一定時間ごとに、運行計画情報２１５をチェックし、新たな運行計画が作成されていた場合に、運行指示ＲＴＤ_jを作成し、バス車両１５０_jのそれぞれに送るようになっている。

バス通信部１１７は、移動体通信網を介したバス車両１５０_jとの間の通信制御を行う。このバス通信部１１７を介することにより、処理制御部１１５は、運行指示ＲＴＤ_jをバス車両１５０_jのそれぞれに通知したり、乗車人数情報ＮＲＤ_j情報を受信したりすることができるようになっている。

バス停通信部１１８は、バス車両１５０_jとの間の通信制御を行う。このバス停通信部１１８を介することにより、処理制御部１１５は、車両通過時刻情報ＤＴＤ_kを車両通過時刻情報提示装置１６０_kのそれぞれに通知することができるようになっている。

バス車両１５０_j（ｊ＝１〜５）のそれぞれには、管理センタ１１０への乗車人数情報ＮＲＤ_jの送信や、管理センタ１１０からの運行指示ＲＴＤ_jに応じた処理を行う車載器が搭載されている。この車載器は、図３に示されるように、通信部１５１と、制御装置１５２と、表示装置１５３、入力装置１５４とを備えている。

通信部１５１は、移動体通信網を介した管理センタ１１０との間の通信制御を行う。この通信部１５１を利用した通信により、管理センタ１１０から運行指示ＲＴＤ_jを受けると、その内容が制御装置１５２に報告される。また、通信部１５１は、制御装置１５２からの指令に従って、管理センタ１１０へ乗車人数情報ＮＲＤ_jを送る。

制御装置１５２は、車載器全体の動作の制御を行う。この制御装置１５２は、通信部１５１から運行指示ＲＴＤ_jの内容を受けると、当該運行指示ＲＴＤ_jの内容の表示画像データを作成する。そして、制御装置１５２は、作成された表示画像データを表示部１５３へ送る。

また、制御装置１５２は、入力装置１５４からの乗車人数入力結果を受けると、乗車人数情報ＮＲＤ_jを作成する。そして、制御装置１５２は、作成された乗車人数情報ＮＲＤ_jを、通信部１５１を介して管理センタ１１０へ送る。

なお、本実施形態では、車載器は、不図示のＧＰＳ計測部を更に備えており、当該ＧＰＳ計測部により計測されたバス車両１５０_jの現在位置は、制御装置１５２に報告されるようになっている。バス車両１５０_jの現在位置を受けた制御装置１５２は、その情報を、通信部１５１を介して、定期的に管理センタ１１０へ送る。こうしてバス車両１５０_jの現在位置情報を受けた管理センタ１１０では、その情報をバス運行管理に役立てるようになっている。

表示装置１５３は、液晶ディスプレイパネル等を備えて構成されている。この表示装置１５３は、制御装置１５２からの表示画像データに従って、画像表示を行う。また、本実施形態では、入力装置１５４は、表示装置１５３の画面上に配置されたタッチバネルとして構成されている。

［動作］
次に、上記のように構成されたデマンドバスシステム１００の動作について、集中需要対応運行計画及び運行計画の作成処理に主に着目して、説明する。

＜利用実績情報の更新処理＞
まず、集中需要対応運行計画の作成の基礎となる利用実績情報の更新について、説明する。

日々の運行計画に沿った運行が行われているバス車両１５０_j（ｊ＝１〜５）が、集中需要区間となる可能性がある区間のバス停において乗車があるたびに、運転手が入力装置１５３から乗車人数を入力する。かかる乗車人数の入力に際して、本実施形態では、制御装置１５２が、集中需要区間となる可能性がある区間のバス停において、図６に示されるような乗車人数入力画面を表示する。そして、当該乗車人数入力画面における表示に従って、入力装置１５４である当該画面上に配置されたタッチパネルの押下操作を行うことにより、乗車人数の入力が行われる。この入力結果は、制御装置１５２に報告される。

乗車人数の入力結果が報告された制御装置１５２は、ＧＰＳ計測結果等に基づいて、当該バス停を特定した後に、上述した乗車人数情報ＮＲＤ_jを作成する。そして、制御装置１５２は、作成された乗車人数情報ＮＲＤ_jを、通信部１５１を介して管理センタ１１０へ送る。

管理センタ１１０では、乗車人数情報ＮＲＤ_jを利用実績更新部２５０が受ける。乗車人数情報ＮＲＤ_jを受けた利用実績更新部２５０は、当日の曜日及び天候によって定まる需要の変動パターンに対応する記憶部２１０内の利用実績情報２１１の内容を更新する。

また、利用実績更新部２５０は、日々のデマンド受付終了時刻となると、運行計画情報２１５を読み出す。そして、利用実績更新部２５０は、読み出された結果を追加することにより、当日の需要の変動パターンに対応する記憶部２１０内の利用実績情報２１１の内容を更新する。

＜集中需要対応運行計画の作成処理＞
次に、集中需要対応運行計画の作成処理について説明する。

この集中需要対応運行計画の作成処理に際しては、図７に示されるように、まず、ステップＳ５１において、集中需要対応運行計画作成部２２０が、集中需要対応運行計画候補の作成時期となったか否かを判定する。なお、本実施形態では、前回の集中需要対応運行計画候補の作成から１月が経過した場合に、集中需要対応運行計画作成部２２０が、集中需要対応運行計画候補の作成時期となったと判定するようになっている。

ステップＳ５１における判定の結果が否定的であった場合（ステップＳ５１：Ｎ）には、ステップＳ５１の処理が繰り返される。そして、前回の集中需要対応運行計画候補の作成から１月が経過し、ステップＳ５１における判定の結果が肯定的となると（ステップＳ５１：Ｙ）、処理はステップＳ５２へ進む。このステップＳ５２においては、集中需要対応運行計画作成部２２０が、記憶部２１０から利用実績情報２１１を読み取る。

次に、ステップＳ５３において、集中需要対応運行計画作成部２２０が、利用実績情報２１１の読み取り結果に基づいて、利用実績の分析を行う。かかる分析に際して、集中需要対応運行計画作成部２２０は、まず、需要の変動パターンごとに、時間帯別にバス停間の利用件数と利用人数の累積及び平均値を算出する。引き続き、この算出結果に基づき、例えば、１時間に４件以上又は１時間に１０人以上等の一定以上の利用のある時間帯及び乗降バス停間の組み合わせを、集中需要のある組み合わせとして抽出する。そして、抽出された乗降バス停間について、需要の時間帯変動を算出し、集中需要の基礎データとして、需要の変動パターンごとに、集中需要乗降バス停間の件数、人数の平均値と、時間帯の変動係数とを求める。

次いで、ステップＳ５４において、集中需要対応運行計画作成部２２０が、集中需要対応運行計画候補を、需要の変動パターンごとに作成する。かかる集中需要対応運行計画候補の作成に際して、集中需要対応運行計画作成部２２０は、ステップＳ５３における分析結果に基づいて、需要の変動パターンごとに、集中需要の乗降バス停間の時間当たりの件数と利用者数を推定する。この推定結果に基づいて、バス車両の配分を行う。この配分に際しては、例えば、推定利用件数の３件に１回の割合で、また、推定利用者数に対して、使用する車両定員の０．７、すなわち９人乗りであれば６人に１回の割合で配車することとし、これらの内で配車数の大きい方を採用する。引き続き、配車が割り当てられたバス車両を等間隔運行として、例えば、３回ならばその時間帯の１０分と３０分と５０分のように、乗車可能時刻を設定することにより、集中需要対応運行計画作成部２２０が、集中需要対応運行計画候補を作成する。

こうして集中需要対応運行計画候補が作成されると、ステップＳ５５において、集中需要対応運行計画作成部２２０は、新たに作成された集中需要対応運行計画候補に、記憶部２１０内の集中需要対応運行計画候補情報２１２の内容を更新する。そして、処理はステップＳ５１に戻る。この後、ステップＳ５１〜Ｓ５５の処理が繰り返されることにより、定期的に新たな集中需要対応運行計画候補が作成され、集中需要対応運行計画候補情報２１２の内容が更新される。

そして、集中需要対応運行計画作成部２２０は、運行計画作成の作成対象なる日の曜日、天候という需要の変動パターンが定まった段階（遅くとも運行計画作成の作成対象なる日におけるデマンド受付開始時刻まで）で、当該変動パターンに対応する集中需要対応運行計画候補を読み出す。そして、集中需要対応運行計画作成部２２０は、読み出された集中需要対応運行計画候補に、集中需要対応運行計画情報２１３の内容を更新する。

＜集中需要区間における集中需要に対応する車両通過時刻表示処理＞
次に、運用当日における集中需要区間における集中需要に対応する車両通過時刻表示処理について、説明する。

この処理では、図８に示されるように、まず、ステップＳ７１において、運用当日におけるサービス開始時刻となると、集中需要対応情報送信部２４０が、記憶部２１０から集中需要対応運行計画情報２１３を読み取る。引き続き、ステップＳ７２において、集中需要対応情報送信部２４０が、読み取られた集中需要対応運行計画情報２１３の内容に基づいて、車両通過時刻情報提示装置１６０_k（ｋ＝１，…）それぞれに通知すべき車両通過時刻情報ＤＴＤ_kを作成する。そして、ステップＳ７３において、集中需要対応情報送信部２４０が、集中需要の時間帯における車両通過時刻を内容とする車両通過時刻情報ＤＴＤ_kを、対応する車両通過時刻情報提示装置１６０_kへ、バス停通信部１１８を介して送る。

この車両通過時刻情報ＤＴＤ_kを受けた車両通過時刻情報提示装置１６０_kでは、受信後における集中需要の時間帯における車両通過時刻を表示する。この表示結果の例が、図９に示されている。

図８に戻り、ステップＳ７３の処理が終了すると、処理は、ステップＳ７４へ進む。このステップＳ７４では、集中需要対応情報送信部２４０が、前回の車両通過時刻情報ＤＴＤ_kの送信から所定時間を経過したか否かを判定する。この判定の結果が否定的であった場合（ステップＳ７４：Ｎ）には、ステップＳ７４の処理が繰り返される。

一方、ステップＳ７４における判定の結果が肯定的であった場合（ステップＳ７４：Ｙ）の場合には、処理はステップＳ７３へ戻る。この後、ステップＳ７３，Ｓ７４の処理が繰り返される。

＜運行計画の作成処理＞
次に、デマンドに対応して行われる運行計画の作成処理について、説明する。

前提として、現在までに受けた少なくとも１つのデマンドに対応した運行計画（以下、「現在運行計画」という）が作成され、管理センタ１１０の記憶部２１０内の運行計画情報２１５として登録されているものとする。また、現在運行計画において予約が完了しているデマンドの内容が、記憶部２１０内の予約リスト２１４に登録されているものとする。

このデマンド処理では、図１０に示されるように、まず、ステップＳ１１において、利用者から新たなデマンドを受けたか否かが判定される。この判定の結果が否定的であった場合（ステップＳ１１：Ｎ）には、ステップＳ１１の処理が繰り返される。

一方、オペレータが電話装置１１１により新たなデマンドを受けると、ステップＳ１１における判定の結果が肯定的となり（ステップＳ１１：Ｙ）、処理はステップＳ１２へ進む。このステップＳ１２では、新たなデマンドの入力処理が行われる。かかる新たなデマンドの入力処理では、オペレータが表示装置１１３の表示を確認しながら、入力装置１１２を操作して、当該新たなデマンドの内容を運行計画作成部２３０に対して入力する。こうした新たなデマンドの内容は、乗降するバス停留所名、乗降人数及び乗車希望時刻等を含んでいる。

次に、ステップＳ１３において、運行計画作成部２３０により、新たなデマンドの内容に対応した新たな運行計画の作成処理が行われる。この処理では、図１１に示されるように、まず、ステップＳ２１において、新たな運行計画候補の作成が行われる。

この新たな運行計画候補の作成に際して、運行計画作成部２３０は、予約リスト２１４に登録されているデマンド内容と、新たなデマンド内容との新たな組み合わせである新たな予約の組み合わせを作成する。引き続き、運行計画作成部２３０は、記憶部２１０から運用日に適用される集中需要対応運行計画に関する情報である集中需要対応運行計画情報２１３の内容を読み出す。そして、運行計画作成部２３０は、新たな予約の組み合わせから、運用日に適用される集中需要対応運行計画をそのまま取り込みつつ、仮運行計画を作成する。

次に、運行計画作成部２３０は、作成された仮運行計画について、サービス指標及び運行指標を算出する。ここで、サービス指標には、待ち時間、迂回時間等が含まれ、運行指標には、総走行時間等が含まれる。

こうして仮運行計画のサービス指標及び運行指標が算出されると、運行計画作成部２３０は、算出された指標の中に、現在運行計画の場合と比べて極端に悪い値のものが含まれているか否かを判定することにより、サービス指標及び運行指標に関する第１次評価に合格か否かを判定する。

以上の仮運行計画の作成及び第１次評価を、予約リスト２１４に登録されているデマンド内容と、新たなデマンド内容との全ての組み合わせについて行ない、運行計画候補を作成する。そして、全ての組み合わせの第１次評価が完了すると、運行計画作成部２３０は、サービス指標及び運行指標に関する第１次評価に合格した新たな運行計画候補のランク付けを行う。このランク付けは、サービス指標及び運行指標を総合的に勘案して行われる。すなわち、サービス指標の値が小さいほど、運行指標の値が小さいほど総合ランクが高くなるように行われる。

こうして、新たな運行計画候補のランク付けが終了すると、処理はステップＳ２２へ進む。このステップＳ２２では、ランク付けされた新たな運行計画候補の内で最もランクの高い第１候補に基づく、新たなデマンドに対応する乗車可能時間等の予約内容が利用者に通知される。かかる通知処理に際しては、まず、運行計画作成部２３０が、第１候補に基づく、新たなデマンドに対応する乗車可能時間等の予約内容を、表示装置１１３に表示させる。この表示内容を見たオペレータが、電話装置１１１を利用して、通話中の利用者に、その内容を通知する。

次に、ステップＳ２３において、まず、運行計画作成部２３０が、利用者の了解がとれたか否かを判定する。ここで、運行計画作成部２３０は、オペレータが、了解が取れた旨の操作入力を入力装置１１２に対して行ったことが、入力装置１１２から報告された場合に肯定的な判定を行う。一方、運行計画作成部２３０は、オペレータが、了解が取れなかった旨の操作入力を入力装置１１２に対して行ったことが、入力装置１１２から報告された場合に否定的な判定を行う。

ステップＳ２３における判定の結果が肯定的であった場合（ステップＳ２３：Ｙ）には、その時点において候補となっている新たな運行計画候補を新たな運行計画に決定し、ステップＳ１３の処理が終了する。そして、処理は図１０のステップＳ１４へ進む。

図１１に戻り、ステップＳ２３における判定の結果が否定的であった場合（ステップＳ２３：Ｎ）には、処理はステップＳ２４へ進む。このステップＳ２４では、運行計画作成部２３０が、新たな運行計画候補として次候補があるか否かを判定する。

ステップＳ２４における判定の結果が肯定的であった場合（ステップＳ２４：Ｙ）には、処理はステップＳ２５へ進む。このステップＳ２５では、次候補に基づく、新たなデマンドに対応する乗車可能時間等の予約内容が利用者に通知される。かかる通知処理に際しては、まず、運行計画作成部２３０が、第１候補に基づく、新たなデマンドに対応する乗車可能時間等の予約内容を、表示装置１１３に表示させる。この表示内容を見たオペレータが、電話装置１１１を利用して、通話中の利用者に、その内容を通知する。

この後、処理はステップＳ２３へ戻る。そして、ステップＳ２３における判定の結果が肯定的となるか、ステップＳ２４における判定の結果が否定的となるまで、上記のステップＳ２３〜Ｓ２５の処理が繰り返される。

上記のステップＳ２４における判定の結果が否定的となった場合（ステップＳ２４：Ｎ）には、処理はステップＳ２６へ進む。このステップＳ２６では、新たなデマンドに関するバス利用に対する予約が不可であることが、利用者に通知される。かかる通知に際しては、まず、運行計画作成部２３０が、新たなデマンドに対応するバス利用予約が不可である旨を、表示装置１１３に表示させる。この表示内容を見たオペレータが、電話装置１１１を利用して、通話中の利用者に、その旨を通知する。

ステップＳ２６の処理が終了すると、ステップＳ１３の処理が終了する。そして、処理は図１０のステップＳ１４へ進む。

ステップＳ１４では、運行計画作成部２３０が、新たな運行計画が決定されたか否かを判定する。この判定の結果が否定的であった場合（ステップＳ１４：Ｎ）には、処理はステップＳ１１へ戻る。

一方、ステップＳ１４における判定の結果が肯定的であった場合（ステップＳ１４：Ｙ）には、処理はステップＳ１５へ進む。このステップＳ１５では、運行計画作成部２３０が、新たなデマンドの内容を予約リスト２１４内に追加するとともに、決定された新たな運行計画に運行計画情報２１５の内容を更新する。この更新に際して、運行計画作成部２３０は、更に運行計画情報２１５内の更新フラグをＯＮにする。この後、処理はステップＳ１１へ戻る。

以後、上記のステップＳ１１〜Ｓ１５の処理が繰り返されることにより、新たなデマンドに対応した新たな運行計画の作成処理が行われる。

＜バス車両への運行指示情報の送信処理＞
以上のような運行計画作成部２３０による新たな運行計画の作成処理と並行して、運行制御部２６０による運行指示ＲＴＤ_j（ｊ＝１〜５）の作成及びバス車両１５０_jへの通知の処理が行われる。この運行指示ＲＴＤ_jの作成及び通知の処理では、図１２に示されるように、まず、ステップＳ４１において、運行計画作成部２３０が、所定時間が経過したか否かを判定する。

ステップＳ４１における判定の結果が否定的であった場合（ステップＳ４１：Ｎ）には、処理はステップＳ４１へ戻る。そして、ステップＳ４１における判定の結果が肯定的となるまで、ステップＳ４１の処理が繰り返される。

所定時間が経過し、ステップＳ４１における判定の結果が肯定的となると（ステップＳ４１：Ｙ）、処理はステップＳ４２へ進む。このステップＳ４２では、運行制御部２６０は、運行計画情報２３０内の更新フラグがＯＮであるか否かを判定することにより、前回の参照時から運行計画情報２３０が更新されたか否かを判定する。この判定の結果が否定的であった場合（ステップＳ４２：Ｎ）には、処理はステップＳ４１へ戻る。そして、ステップＳ４２における判定の結果が肯定的となるまで、上記のステップＳ４１，Ｓ４２の処理が繰り返される。

運行計画作成部２３０により運行計画情報２１５が更新され、ステップＳ４２における判定の結果が肯定的となると（ステップＳ４２：Ｙ）、処理はステップＳ４３へ進む。このステップＳ４３では、運行制御部２６０が、運行計画情報２１５に登録されている運行計画を取得する。そして、運行計画情報２１５内の更新フラグをＯＮに設定する。

次に、ステップＳ４４において、運行制御部２６０が、取得された運行計画に基づいて、バス車両１５０_j（ｊ＝１〜５）のそれぞれに通知すべき運行指示ＲＴＤ_jを作成する。引き続き、ステップＳ４５において、運行制御部２６０が、作成された運行指示ＲＴＤ_jを、バス通信部１１７を介して、バス車両１５０_jへ送る。

この後、処理はステップＳ４１へ戻る。そして、運行制御部２６０は、上記のステップＳ４１〜Ｓ４５の処理を繰り返す。

以上のようにして、管理センタ１１０から発行された運行指示ＲＴＤ_jを受けると、バス車両１５０_jでは、その内容が表示装置１５３に表示される。そして、運行指示ＲＴＤ_jの内容が、バス車両１５０_jでの運転手に提示される。

以上説明したように、本実施形態では、需要の変動パターンごとに、サービス領域ＳＶＡにおける集中需要区間と集中需要時間帯との組み合わせに対応する集中需要対応運行計画を作成する。そして、作成された集中需要対応運行計画をそのまま取り込みつつ、デマンドに対応した運行計画が作成される。したがって、本実施形態によれば、時間帯によって集中需要区間が存在する場合であっても、合理的な運行計画を簡易に作成して、車両運行サービスを提供することができる。

すなわち、本実施形態のデマンドバスシステム１００によれば、鉄道駅、病院、大規模店舗等の集中需要がある地区に適用するデマンドバスにおいて、集中需要バス停に先行的に仮予約の仮運行計画を設定し、その情報を利用者に提供して、需要の集約化を実現することにより、従来のように、集中需要地点を含む固定路線バスを設定して、その他をデマンドバスとするという、固定路線における無駄な運行を軽減し、かつ、すべてを個別予約とすることによる集中需要地点に係る予約と運行の混乱や輻輳を軽減することを可能としている。

これにより、従来のデマンドバスでは１台１日当り数十人といわれてきた対応限界を超えることを可能とするとともに、受付の負担も大幅に軽減することを可能としている。
また、単に固定路線バスを一部に適用するのではなく、利用データに即してサービス地点や運行時刻を可変として随時に更新していく操作を付加することにより、肌理の細かい対応が可能となり、従来デマンドバスでは適用困難と考えられがちであった、都市部や観光地等集中需要のある地区でのコストパフォーマンスの高いバスサービスの方式を提供することを可能としている。

また、本実施形態では、利用実績情報の基礎となる各バス停における乗車人数情報を、日々の実際のバス運行において収集している。合理的な集中需要対応運行計画を精度良く作成することができる。

また、本実施形態では、管理センタ１１０が、集中需要区間におけるバス停に配置された車両通過時刻情報提示装置１６０_kへ、集中需要時間帯における車両通過時刻情報ＮＲＤ_kを送り、車両通過時刻情報提示装置１６０_kでは、受信した車両通過時刻情報ＮＲＤ_kで通知された集中需要時間帯における車両通過時刻情報を表示して、利用者に提示するようにしている。このため、利用者の利便性を向上できるとともに、集中需要区間における車両利用を集中需要対応計画による車両運行に効率的に集約することができる。

［実施形態の変形］
本発明は、上記の実施形態に限定されるものではなく、様々な変形が可能である。

例えば、上記の実施形態では、バス車両の数を５台としたが、バス車両の数は任意の数とすることができる。

また、上記の実施形態では、需要の変動パターンを曜日と天候との組み合わせにより指定するようにしたが、任意の要素の組み合わせとすることができる。例えば、曜日及び天候に加えて、季節を需要の変動パターンの要素とすることができる。

また、上記の実施形態では、集中需要時における運行情報のバス停における利用者への提供を表示装置への表示により行うことにしたが、音声により、又は、音声と表示とを組み合わせて行うようにしてもよい。

また、上記の実施形態では、新たな運行計画候補のランク付けを運行計画作成部２３０が行うようにしたが、オペレータが行うようにしてもよい。

また、上記の実施形態では、新たな運行計画候補のランク付け後における第１候補における予約内容を利用者に提示し、利用者の了解が得られなかった場合に、次候補における予約内容を提示していくようにした。これに対し、当該第１候補における予約内容をのみ利用者に提示し、了解が得られなかった場合には、利用者のデマンド内容の変更を促すようにし、デマンド内容の変更がなされた場合には、当該変更されたデマンド内容を新たなデマンド内容として、新たに運行計画作成処理を行うようにしてもよい。

また、上記の実施形態では、オペレータが入力装置１１２を操作して、デマンドの内容や利用者の承諾等を運行計画作成部２３０へ入力するようにしたが、利用者がパーソナルコンピュータ等の通信機能を有する情報処理装置を使用し、当該情報処理装置と運行計画作成部２３０とが直接通信することにより、デマンドの内容や利用者の承諾等を運行計画作成部２３０へ入力するようにしてもよい。

また、上記の実施形態では、サービス提供に使用される車両をバスとするデマンドバスシステムについて本発明を適用したが、サービス提供に使用される車両をバス以外のタクシー等とするデマンドタクシーシステム等の車両運行システムに本発明を適用できることは、勿論である。

以上説明したように、本発明の車両運行システムは、デマンドに対応して運行計画を作成し、作成された運行計画に沿って車両の運行を行う車両運行システムに適用することができる。

本発明の一実施形態に係るデマンドバスシステムの構成を模式的に示す図である。 サービス領域内の集中需要区間を概念的に示す図である。 図１の管理センタ、バス車両の車載器、及び車両通過時刻提示装置の内部設備の構成を概略的に示すブロック図である。 図３の処理制御部の構成を示すブロック図である。 図４の記憶部における記憶内容を説明するための図である。 バス車両の車載器における乗車人数の入力操作を説明するための図である。 集中需要対応運行計画の作成処理を説明するためのフローチャートである。 集中需要区間における集中需要に対応する車両通過時刻表示処理を説明するためのフローチャートである。 車両通過時刻提示装置における表示例を説明するための図である。 デマンド処理を説明するためのフローチャートである。 図１０の運行計画作成処理を説明するためのフローチャートである。 運行指示発行処理を説明するためのフローチャートである。

符号の説明

１００…デマンドバスシステム（車両運行システム）、１１０…管理センタ、１１１…電話装置、１１２…入力装置、１１３…表示装置、１１５…処理制御部、１１７…バス通信部、１１８…バス停通信部、１５０_j…バス車両、１５１…通信部、１５２…制御装置、１５３…表示装置、１５４…入力装置、１６０_j…車両通過時刻提示装置（運行情報定時手段）、１６１…通信部、１６２…制御装置、１６３…表示装置、２１０…記憶部（記憶手段）、２２０…集中需要対応運行計画作成部（集中需要対応運行計画作成手段）、２３０…運行計画作成部（運行計画作成手段）、２４０…集中需要対応情報送信部（集中需要対応情報送信手段）、２５０…利用実績更新部（利用実績更新手段）、２６０…運行制御部（運行制御手段）、３１０…電話機、３２０…携帯電話機。

Claims (4)

1. 運行サービスの提供に利用される車両の利用実績情報を記憶する記憶手段と；
   前記記憶手段における記憶内容に基づいて、前記車両利用の需要の多い時間帯である集中需要時間帯と、前記車両利用の需要の多い停留所区間である集中需要区間との組み合わせに対する集中需要を抽出し、抽出結果抽出結果に基づいて、前記集中需要に対応する集中需要対応運行計画を作成する集中需要対応運行計画作成手段と；
   乗降地点、乗車人数及び乗車希望時刻を含む乗合車両の新たな利用要求情報に対応して、前記集中需要対応運行計画作成手段により作成された集中需要対応運行計画をそのまま取り込みつつ、現在の運行計画の更新を行ない、最適化された新たな運行計画を作成する運行計画作成手段と；
   前記新たな運行計画に基づいて、前記車両ごとに運行時刻順に乗降地点を抽出し、該当する車両の車載装置へ送信する運行制御手段と；
   を備えることを特徴とする車両運行システム。
2. 前記車両に搭載され、乗降実績情報を送信する需要実績送信手段と；
   前記需要実績送信手段からの乗降実績情報に基づいて、前記記憶手段における利用実績情報を更新する利用実績更新手段と；
   を更に備えることを特徴とする請求項１に記載の車両運行システム。
3. 前記集中需要区間における停留所に配置された運行情報提示手段と；
   前記集中需要対応運行計画に基づいて、前記集中需要区間の停留所ごとにおける前記車両の通過予定時刻情報を生成して、該当する停留所に配置された運行情報提示手段へ送る集中需要対応情報送信手段と；
   を更に備えることを特徴とする請求項１又は２に記載の車両運行システム。
4. 前記運行情報提示手段は、現在時刻以降の前記集中需要時間帯における前記車両の通過予定時刻情報を提示する、ことを特徴とする請求項３に記載の車両運行システム。

Images