WO2011007553A1 - 運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法 - Google Patents

Abstract

オンデマンドバスの運行スケジューリングシステムは、乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、データベースに格納される運行実績から予め乗客の乗降に関する特性情報を抽出し、抽出した特性情報と抽出した特性情報に対応する運行実績に含まれる予約を示す情報とを対応付けてデータベースに格納する手段と、運行スケジュールを決定する現在の状況が、特性情報が示す状況に整合するとき、整合した特性情報に対応する運行実績に含まれる予約情報に基づいて、オンデマンドバスの運行スケジュールを決定する手段とを設ける。

Description

運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法 参照による取込

  本出願は、平成21年（2009年）7月13日に出願された日本特許出願　特願2009-164678号の優先権を主張し、その内容を参照することにより、本出願に取り込む。

　本発明は、ユーザからの要求に応じて運行するオンデマンドバスシステムに係り、特にその運行スケジューリングシステム及び運行スケジューリング方法に関する。

　交通渋滞の解消や交通機関の省エネルギー化を図るためにオンデマンドバスが検討されている。オンデマンドバスシステムに関して、利用客からの、乗車位置、目的地、希望乗車時刻、乗客の数を特定した乗車の要求を受信すると、その要求を満足する目的地へ適切なルートが決定されるシステムが特許文献1に開示されている。特許文献1に記載されるオンデマンドバスのルートは、すべての乗客が要求している利用の乗車地点、乗客の目的地、複数あるバスのそれぞれの現在の位置、それぞれのバスの現在予定されているルート、交通状況、の関数として決定される。

特開平10－241091

　特許文献１に記載の技術によれば、各乗客の要求（乗車位置、目的地、希望乗車時刻）は、ルートが決定されることにより、満足される。しかしながら、オンデマンドバスシステムの大規模化、たとえば、運行地域の拡大、運行するバスの台数の増加、乗客の増加に伴い、ルートの決定までに時間を要し、希望乗車時刻までに時間的余裕の少ない要求には応えられない場合が発生する。このような要求に応えられない場合を解消するために、たとえば、希望乗車時刻の30分前までや1時間前までのように、ルートの決定に要する時間を確保した運用があるが、このような運用はオンデマンドバスの本質的な利便性を損なう。

　このような状況において、ルートの決定に要する時間を短縮した、オンデマンドバスシステムの運行スケジュールシステムが必要とされる。

　上記課題を解決するために、次のような運行実績を活用したオンデマンドバスの運行スケジューリングシステム及びその方法が開示される。

　運行スケジューリングシステムは、オンデマンドバスの乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、データベースに格納される運行実績から予め乗客の乗降に関する特性情報を抽出し、抽出した特性情報と抽出した特性情報に対応する運行実績に含まれる予約を示す情報とを対応付けてデータベースに格納する手段と、
運行スケジュールを決定する現在の状況が、特性情報が示す状況に整合するとき、整合した特性情報に対応する運行実績に含まれる予約情報に基づいて、オンデマンドバスの運行スケジュールを決定する手段とを設ける。

　さらに望ましい運行スケジューリングシステムは、乗客の乗降に関する予約と実績に係る運行実績が、少なくとも、乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、実績として前記オンデマンドバスを運行した日時の天候に関する情報を含む。

　さらに望ましい運行スケジューリングシステムは、乗客の乗降位置および乗降時刻の少なくとも一方の時刻の規則性に基づいて、運行実績から特性情報を抽出する。

　さらに望ましい運行スケジューリングシステムは、乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、実績としてオンデマンドバスを運行した日時の天候に関する情報の各情報間の相関関係に基づいて、運行実績から特性情報を抽出する。

　本発明によれば、運行実績から予め運行スケジュールを決定しておくので、運行スケジュールの決定に要する時間を短くできたり、乗り合いの多い運行計画を生成できたりする。

本実施形態のオンデマンドバスシステムの構成図である。 予約情報テーブルの構成例である。 実績情報テーブルの構成例である。 特性情報テーブルの構成例である。 運行スケジュールを決定する処理のフローチャートである。 バスの運行の対象地域の例示である。 決定した運行スケジュールの例である。 決定した運行スケジュールの例である。 決定した運行スケジュールの例である。

　以下、本発明の実施形態について図面を用いて説明する。図1に、本実施形態のオンデマンドバスシステムの構成図を示す。オンデマンドシステムは、運行するオンデマンドバス（以下、バス）1への乗車を希望するユーザからの要求を受け付ける予約受付システム２、予約受付システム２からの予約情報およびバス１の運行実績などに基づいて、バス１の運行スケジュールを決定する運行スケジューリングシステム３、バス１の運行情報を収集し、その運行実績として運行データベース５に格納する運行情報システム４を有する。運行スケジューリングシステム３が用いるバス１の運行実績は、運行データベース５に格納されている。なお、詳細を省略するが、オンデマンドバスシステムを運用する地域（運用地域：バスを運行する全域）の現在情報として、各道路（または、交差点間のような道路区間）の渋滞情報（混雑度や道路区間又は所定区間の走行時間）、気象条件などを収集し、運行データベース５に日時情報（年月日、曜日、祝日、時刻など）に対応付けて格納しておく。

　図1では、1台のバスを示しているが、運用地域の広さやオンデマンドバスシステムの利用客数に応じて、台数は決定される。バスの台数は、商店街、病院、公共施設、さらには急坂の存在などの地勢的特徴及び時間帯に基づいて、運用地域の中のある地域、ある地域と他の地域との間などを単位として決定される。地域に割当てていないバスを用意しておき、乗車を希望するユーザが少ない地域に、ユーザからの要求に応じて臨時に割当ててもよい。

　本実施形態の説明では、配車された1台のバスへの乗客の乗車希望を満足するように、そのバスの運行スケジュールを決定する運行スケジューリングシステム３について詳しく示す。

　図1では、理解を容易にするために、予約受付システム２、運行スケジューリングシステム３、運行情報システム４、及び運行データベース５を分けて示しているが、データベースシステムを有する1台のコンピュータで実現してもよいし、各システムの負荷や機能に応じた、複数台のコンピュータによる分散システムによって実現してもよい。

　また、バス１は、運行スケジューリングシステム３、運行情報システム４との通信のための無線通信装置を備えると共に、バス１の位置や現在時刻を把握するためのGPS(Global Positioning System)装置を備えている。バス１の位置や現在時刻は、運行情報として運行情報システム４に送信される。

　予約受付システム２は、乗車を希望するユーザからの要求をメールや電話で受け付ける。オペレータがユーザからの乗車希望を受け付け、受け付けた内容を予約受付システム２に入力してもよいが、ユーザが慣れてくると（乗車希望位置、降車希望位置、乗車希望時刻または降車希望時刻、および、乗車人員などの、乗車希望に必要な要件の伝達に慣れてくると）、自動受付が可能である。メールの場合は、所定のフォーマットを使用するメールを用いるか、予約受付システム２においてメールの文章を構文解析、意味解析することにより、乗車希望の内容を予約情報として抽出する。電話の場合は、メールで受け付ける仕組みの前段で音声認識装置を動作させ、文章を抽出する。この文章から予約情報を抽出するのは、メールの場合と同様である。

　メールの場合であっても、電話の場合であっても、自動受付の場合に、乗車希望に必要な要件の欠落が、予約情報を抽出する段階で判明する。この場合、欠落情報の追加を返信メールや電話のコールバックで要請する。

　運行データベース５に含まれる、予約情報テーブルの構成例を図２に、実績情報テーブルの構成例を図３に示す。予約情報テーブルの内容は、予約受付システム２で受け付けた予約情報を運行スケジューリングシステム３内のプログラムによって格納される。このプログラムは、予約受付システム２からの受信割り込みによって起動し、予約情報を運行スケジューリングシステム３を介して予約情報テーブルへ格納し、受け付けた予約情報に対する応答を運行スケジューリングシステム３から取得し、取得した応答をユーザへ返送して処理を終了する。

　予約情報テーブルは、予約番号50、乗客情報51、予約情報52、予約確定フラグ53の各欄を有する。予約情報52は、さらに月日54、曜日55、乗車(希望)時刻56、降車(希望)時刻57、乗車(希望)位置58、降車(希望)位置、乗車(希望)人数60、などの欄を有する。

　予約番号52は、ユーザに受付を完了した旨を応答する際に用いると共に、運行スケジューリングシステム２で、運行スケジュールに反映する予約情報52を識別するために用いる。後述するが、運行実績を運行データベース５に格納する際に、どの予約情報に対応する運行実績かを識別するためにも用いる。

　乗客情報51は、たとえば乗客（ユーザと同義）を識別する乗客識別子である。乗客識別子をキーにして、乗客の氏名、住所、電話番号などの属性情報を格納した乗客データベースを検索する。予約確定フラグ53は、予約情報52を運行スケジュールに反映し、確定した予約情報をユーザへの応答として返送したことを示すフラグである。換言すると、運行スケジューリングシステム２が、予約確定フラグ53がONの予約情報をバス１の運行スケジュールに反映したことを示している。予約確定フラグ53が空欄はOFFをあらわし、＊はペンディング状態を表す。ペンディング状態については後述する。

　予約情報52の個々の項目は、後述する例示によって明らかにされる。ただし、乗車時刻56の欄の括弧付きの時刻、降車時刻57の欄の－(ハイフン)について説明しておく。予約受付システム２による乗車希望に必要な要件として、乗車希望位置、降車希望位置、乗車希望時刻または降車希望時刻、および、乗車人員などと説明した。乗車希望時刻及び降車希望時刻の両方を要件とすると、乗車希望位置と降車希望位置とにおいて、指定された希望時刻を厳守したバス1の運行ができない状況が発生するので、その一方を要件とする。乗車希望時刻が指定されたとき、降車時刻57の欄に－(ハイフン)を格納する。降車希望時刻が指定されたとき、乗車時刻58の欄に、運行スケジューリングシステム２が決定した乗車(希望)位置58へのバス１の到着予想時刻を括弧付きで格納する。この到着予想時刻は、確定した予約情報としてユーザへ返送する応答の中に含むことにより、ユーザは乗車希望位置でその到着予想時刻より前にバス１を待つことができる。

　本実施形態のオンデマンドバスシステムの実運用においては、交通事故などによる突然の道路障害などを考慮して、乗車希望時刻や降車希望時刻は、たとえば±２分、±５分などの許容幅を持って運用される。

　なお、図２に示す予約情報テーブルは、後に具体例を説明するために、6月21日(日)の10：10の状態を示している。

　実績情報テーブルの内容は、運行情報システム４がバス１から受信した運行情報が、運行情報システム４によって格納される。バス１からの運行情報には、バスの走行（位置、速度など）に係る情報だけではなく、各乗客の乗降情報（位置、時刻など）が含まれる。本実施形態では、実績としての各乗客の乗降情報に基づいて、バス１の運行スケジュールを決定するので、バスの走行に係る情報については省略する。実績情報テーブルは、予約番号50、乗客情報51、実績情報61の各欄を有する。実績情報52は、さらに乗車時刻62、降車時刻63、乗車位置64、降車位置65、乗車人数66、号車67、などの欄を有する。予約番号50および乗客情報51は、予約情報テーブルの予約番号50および乗客情報51と同じであり、実績情報テーブルの各レコードは、予約情報テーブルの各予約情報52に対応して、その運行実績を格納する。したがって、予約情報と実績情報を併せて運行実績と呼ぶ。ここでは、予約情報テーブルと実績情報テーブルとを分けて説明するが、予約番号50および乗客情報51を共通にした1つのテーブルとして構成してもよい。実績情報61の個々の項目は、後述する例示によって明らかにされる。

　なお、図３に示す実績情報テーブルは、後に具体例を説明するために、6月21日(日)の10：10の状態を示している。

　図４に、運行データベース５に含まれる特性情報テーブルの構成例を示す。特性情報テーブルは、予約情報テーブルと実績情報テーブルとに格納される運行実績から得られる乗客の特性を格納する特性欄70とその特性を示す予約番号71の欄を有する。乗客の特性は、運行実績（予約情報テーブルの内容と実績情報デーブルの内容）の各項目間の相関関係や規則性(パターン)を探すデータマイニング技術や数理計画法に基づく他の技術によって得られる。図４のNo.1の特性は、「乗客Ａは、毎週日曜日に位置αから乗車し、位置βで10：25に降車する。」というものであり、運行実績を示す予約情報テーブル及び実績情報テーブルの予約番号25、75、102、126などから得られた、規則性に基づく特性である。No.2の特性は、「乗客Ｂは、日曜日に雨が降ると、二人で位置γから10：15に乗車し、位置βで降車する。」というものであり、運行実績を示す予約情報テーブル及び実績情報テーブルの予約番号26、127などから得られた、規則性および乗車事項62、降車時刻63などと天候68との項目間の相関関係に基づく特性である。

　図５に、運行スケジューリングシステム３が運行スケジュールを決定する処理のフローチャートを示す。この処理は、オンデマンドバスシステムの一日の運用開始前に実行を開始する。まず、特性情報があるか否かを判定する(ステップ100)。この判定の基準は、簡単に説明した運行データベース５に格納されている現在情報に対応付けてある日時情報であり、特に現在時刻である。すなわち、現在時刻から所定時間内に乗車時刻を含む特性情報があるか否かを判定する。所定時間は、たとえば10分であり、長すぎると新たな乗車希望の予約のために決定した運行スケジュールの修正が多くなり、短すぎると、運行スケジュールを決定すべき時刻までに決定できない可能性が出てくる。この判定は、換言すると、運行スケジュールを決定する現在の状況（時刻を含む）が、いずれかの特性情報が示す状況に整合するか否かを判定している。

　特性情報があれば、予約情報があるか否かを判定する(ステップ110)。予約情報には、5時間後に乗車を希望するような予約情報もあるが、予約情報があれば、その予約情報に対応する運行スケジュールを決定する。なぜならば、ユーザは乗車希望に沿ってバス1に乗車できるか否かを示す応答を待っているからである。前述したように、降車希望時刻を指定した予約情報の場合は、乗車位置における仮の乗車希望時刻を、降車希望時刻から降車位置との間の走行時間を減算して求める。走行時間は、実績のある走行時間より長めの時間を用いればよく、厳密な値である必要はない。

　予約情報があれば、特性情報と予約情報を用いて運行スケジュールを決定し(ステップ120)、なければ、特性情報を用いて運行スケジュールを決定する(ステップ140)。

　ステップ100において、特性情報がなければ、予約情報があるか否かを判定し(ステップ150)、予約情報があれば、予約情報を用いて運行スケジュールを決定する(ステップ160)。予約情報がなければ、ステップ100に戻る。すなわち、現在時刻から所定時間内に特性情報がなく、予約情報もなければ、ステップ100とステップ150との実行によるアイドルループを構成する。

　ステップ120、ステップ140及びステップ160のいずれかで決定された（すでに決定されていたものを修正した場合を含む）運行スケジュールをバス1へ通知する(ステップ130)。

　運行スケジュールを決定する処理の例を示す。この例のバス１の運行の対象地域を図６に示す。図６において、実線は、バス1が走行可能な道路を示す。破線は、バス1の運行スケジュールとして決定された走行経路のいくつかの例を示す。ギリシャ文字（α、β、γ、・・・）はユーザの乗車位置又は降車位置を表す。ｘ1、ｘ2、・・・などは、交差点位置を示す。乗車位置、降車位置などの位置情報には、実際は緯度・経度を用いるが、ここでは記号（ギリシャ文字及びxn（ｎ＝1、2、3、・・・））を用いる。

　第１の例を説明する。現在時刻を6月7日(日)の10：00とし、図5のステップ100に設定してある所定時間を10分とする。図４に示す特性テーブルを参照すると、No.1の特性70が特性情報として判定される(ステップ100)。No.1の特性情報に対応する予約番号を得る。予約番号71の欄の現在時刻から見て最新の予約番号は75である。予約番号の値が75の予約内容をコピーし、新たな予約情報として、予約番号50に102を付し、コピーした内容と共に予約情報テーブルに格納する。このとき、予約確定フラグは＊(ペンディング)とする。

　所定時間の10分以内に予約情報はないので(ステップ110：No)、特性情報を用いた運行スケジュールを決定する(ステップ140)。このステップは、特性情報に対応した予約番号欄50の値が102の予約情報が仮に予約されたとして、運行スケジュールを決定する。

　図７Ａに示す運行スケジュールが得られる。図７Ａに示す運行スケジュールは、バス1が位置αを10：10に出発し、交差点ｘ1、ｘ2、ｘ3、ｘ4、ｘ5を経由して、位置βに10：25に到着することを示している。

　運行スケジュールの決定は、出発地から目的地への最短時間経路探索または最短距離経路探索による。これらは、道路区間（たとえば、交差点間）毎に、距離と対応させた上下線方向毎の走行時間のテーブルを備え、それらの距離又は走行時間を候補経路毎に加算し、最小の値を示す候補経路を選択する方法である。走行時間が道路の混雑度によって変化する場合は、その混雑度に応じた走行時間をテーブルに設けて使用する。

　予約番号欄50の値が102の予約情報が予約されたならば、運行スケジューリングシステム３は、予約確定フラグ53を＊からONに変更し、予約できた旨を予約受付システム２を介してユーザＡに通知する。

　決定した運行スケジュールをバス1へ通知することにより(ステップ130)、バス1は10：10に位置αに到着するように運行する。位置αに到着する10：10に、ユーザＡから未だ予約されないとき、他のユーザからの予約情報にも対応する運行スケジュールでないならば、運行スケジューリングシステム３はバス1の運行をキャンセルする。

　第２の例を説明する。第1の例から時間が経過し、現在時刻を6月7日(日)の10：07とする。図４に示す特性テーブルを参照すると、特性情報はなく(ステップ100：No)、予約番号50の欄の値が103の予約情報があるので(ステップ150：Yes)、予約情報を用いた運行スケジュールを決定する(ステップ160)。なお、図２の予約情報テーブルは、6月21日(日)の10：10の状態を示しているので、予約番号50の欄の値が103の行の予約確定フラグ53はONを示しているが、6月7日(日)の10：07の時点では、OFF(空欄)である。10：07の時点では、すでに図７Ａに示す運行スケジュールによって、バス1が位置αに向けて運行されている。予約番号50の欄の値が103の予約情報を反映して、運行スケジュールを改めて決定すると、図７Ｂの運行スケジュールのようになる。すなわち、時刻10：17に位置Δを経由して、位置β、位置ηへの運行経路を得る。同様に、位置Δから位置βへの経路探索、位置βから位置ηへの経路探索を実行する。図７Ｂは、6月7日(日)の10：00に決定したバス1の運行スケジュールを修正して、運行スケジュールを決定したことを示している。

　経路探索した結果、位置Δに10：17、位置βに10：25の到着という制約条件を満足できなければ、予約番号50の欄の値が103の予約情報は、他のバスの運行スケジュールの決定に用いられる。いずれのバスの運行スケジュールにも組み入れることができないときは、予約番号50の欄の値が103の予約情報を送ってきたユーザＣに対して、予約がとれない旨と共に、予約可能な予約情報の案を通知する。

　第３の例を説明する。第２の例から日時が経過し、現在時刻を6月21日(日)の10：10、雨天とする。すでに、図４に示す特性テーブルを参照して、10：00に予約番号50の欄の値が158の予約情報に対応して、特性情報のNo.1を使用して運行スケジュールを決定し、10：05に予約番号50の欄の値が159の予約情報に対応して、特性情報のNo.2を使用して運行スケジュールを決定している。これらを図8の運行スケジュールNo.1及びNo.2に示す。10：10には、新たな特性情報はなく(ステップ100：No)、予約番号50の欄の値が160の予約情報があるので(ステップ150：Yes)、予約情報を用いた運行スケジュールを決定する(ステップ160)。結果として、図８の運行スケジュールNo.3が得られる。予約番号50の欄の値が160の予約情報を反映できない場合を含めて、運行スケジュールの決定については前述の例と同じであるので省略する。

　本実施形態によれば、運行実績から予め運行スケジュールを決定しておくので、運行スケジュールの決定に要する時間を短くできる。運行スケジュールの実行中の要求を、実行中の運行スケジュールに反映するようにするので、運行スケジュールの決定に要する時間をさらに短くでき、乗客の要求に応えられない状況の発生を少なくすることができる。結果として、乗り合いの多い運行スケジュールを決定できる。

　1：オンデマンドバス、２：予約受付システム、３：運行スケジューリングシステム、４：運行情報システム、５：運行データベース。

Claims (8)

1. オンデマンドバスの乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースと、
   前記データベースに格納される前記運行実績から予め前記乗客の乗降に関する特性情報を抽出し、抽出した前記特性情報と抽出した前記特性情報に対応する前記運行実績に含まれる前記予約を示す情報とを対応付けて前記データベースに格納する手段と、
   運行スケジュールを決定する現在の状況が、前記特性情報が示す状況に整合するとき、整合した前記特性情報に対応する前記運行実績に含まれる前記予約情報に基づいて、前記オンデマンドバスの前記運行スケジュールを決定する手段とを設けることを特徴とするオンデマンドバスの運行スケジューリングシステム。
2. 前記乗客の乗降に関する前記予約と前記実績に係る前記運行実績は、少なくとも、前記乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の天候に関する情報を含むことを特徴とする請求項１記載のオンデマンドバスの運行スケジューリングシステム。
3. 前記乗客の前記乗降位置および前記乗降時刻の少なくとも一方の時刻の規則性に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項２記載のオンデマンドバスの運行スケジューリングシステム。
4. 前記乗客の前記乗降位置、前記乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の前記天候に関する情報の各情報間の相関関係に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項２記載のオンデマンドバスの運行スケジューリングシステム。
5. オンデマンドバスの乗客の乗降に関し、その予約と実績に係る運行実績を格納するデータベースを有するコンピュータによる、前記オンデマンドバスの運行スケジュールの決定方法であって、前記コンピュータは、
   前記データベースに格納される前記運行実績から前記乗客の乗降に関する特性情報を抽出し、
   抽出した前記特性情報と抽出した前記特性情報に対応する前記運行実績に含まれる前記予約を示す情報とを対応付けて前記データベースに格納し、
   運行スケジュールを決定する現在の状況が、前記特性情報が示す状況に整合するとき、整合した前記特性情報に対応する前記運行実績に含まれる前記予約情報に基づいて、前記オンデマンドバスの前記運行スケジュールを決定することを特徴とするオンデマンドバスの運行スケジューリング方法。
6. 前記データベースに格納される、前記乗客の乗降に関する前記予約と前記実績に係る前記運行実績は、少なくとも、前記乗客の乗降位置、乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の天候に関する情報を含むことを特徴とする請求項５記載のオンデマンドバスの運行スケジューリング方法。
7. 前記コンピュータは、前記乗客の前記乗降位置および前記乗降時刻の少なくとも一方の時刻の規則性に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項６記載のオンデマンドバスの運行スケジューリング方法。
8. 前記コンピュータは、前記乗客の前記乗降位置、前記乗降時刻の少なくとも一方の時刻、および、前記実績として前記オンデマンドバスを運行した日時の前記天候に関する情報の各情報間の相関関係に基づいて、前記運行実績から前記特性情報を抽出することを特徴とする請求項６記載のオンデマンドバスの運行スケジューリング方法。

Images