JP2020140486A - 車両運行管理システム - Google Patents

車両運行管理システム Download PDF

Info

Publication number
JP2020140486A
JP2020140486A JP2019036023A JP2019036023A JP2020140486A JP 2020140486 A JP2020140486 A JP 2020140486A JP 2019036023 A JP2019036023 A JP 2019036023A JP 2019036023 A JP2019036023 A JP 2019036023A JP 2020140486 A JP2020140486 A JP 2020140486A
Authority
JP
Japan
Prior art keywords
vehicle
stop
transmitter
bus
signal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019036023A
Other languages
English (en)
Other versions
JP6676800B1 (ja
Inventor
明宏 吉川
Akihiro Yoshikawa
明宏 吉川
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Space 24 Information Co Ltd
Original Assignee
Space 24 Information Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Space 24 Information Co Ltd filed Critical Space 24 Information Co Ltd
Priority to JP2019036023A priority Critical patent/JP6676800B1/ja
Priority to JP2020042528A priority patent/JP7426705B2/ja
Application granted granted Critical
Publication of JP6676800B1 publication Critical patent/JP6676800B1/ja
Publication of JP2020140486A publication Critical patent/JP2020140486A/ja
Priority to JP2023223828A priority patent/JP2024026617A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】発信機とユーザ端末を用いてバスとバス停を含む運行設備のステータスまたはそのバス運行設備に対する相対的なユーザのステータスを時刻に関連付けて推定する。【解決手段】バス運行管理システム10は、ユーザの携帯端末90と、各バス停14に設置されたバス停発信機30と、各バス12内に設置されたバス内発信機32,34と、バス運行管理センタ40の管理サーバ50とを備えている。携帯端末90は、バス停発信機30から受信すると、そのバス停発信機が設置されているバス停14を識別し、バス内発信機32,34から受信すると、そのバス内発信機が設置されているバス12を識別する。携帯端末90は、いずれかのバス停発信機といずれかのバス内発信機の双方から信号を同時に受信すると、現在、バス停14にバス12が停車しており、かつ、それらバス停およびバスの近傍にユーザが位置すると判定し、その判定結果を管理サーバ50に送信する。【選択図】図1

Description

本発明は、乗客運送用の複数台の車両の運行を管理する技術に関し、特に、発信機とユーザ端末とを用いて車両運行設備のステータスまたはその車両運行設備に対する相対的なユーザの挙動またはステータスを時刻に関連付けて推定する技術に関する。
乗客運送用の複数台の車両の運行を管理する技術が既に提案されている。ここに、「車両」は、例えば、乗合バス、貸切りバス、乗合タクシー、貸切りタクシー、列車、電車、軌道系交通機関(例えば、モノレール、ケーブルカー、トロッコ)などを含む。また、「車両」は、例えば、固定されたルートに沿って運行されるか、または、乗客の要望に応じて随時決まるルートに沿って運行される。
特許文献1は、前記車両としての乗合バスの運行を管理する技術であって、ユーザがバスへの乗車を希望する所在地情報をユーザ端末からサーバに送信し、それにより、バスに対して乗車予約をするものを開示している。
特許文献2は、前記車両としての乗合バスの運行を管理する別の技術であって、ユーザ端末のGPS機能を利用してサーバがユーザの現在位置を遠隔的に監視し、それにより、ユーザのバスへの乗降時に乗降位置を測位する技術を開示している。この技術においては、その測位結果に基づき、前記サーバが、ユーザに対する運賃を計算し、ユーザは、ユーザ端末を用いてその運賃を電子決算する。
特許文献3は、前記車両としての乗合バスの運行を管理するさらに別の技術であって、路線図上において各停留所名の表記に隣接して二次元コードを表示し、ユーザが、ユーザ端末でその二次元コードを読み取ってその読み取り結果であるリンク情報をもとにサーバにアクセスし、ユーザ端末がサーバから運行情報をダウンロードする技術を開示している。
特開2002−056498号公報 特開2008−217194号公報 特開2006−268392号公報
本発明者は、従来の車両運行管理システムについて研究を行い、その結果、次のようないくつかの知見を得た。
すなわち、一般に、車両運行管理システムにおいては、運行中、車両(例えば、移動物体)と停車場(例えば、静止物体)との間の相対的位置が時々刻々変化し、その変化に同期するように、乗客(例えば、移動物体)の位置ないしは行動が変化する。
具体的には、例えば、車両および停車場を備えて車両運行設備のステータスおよび乗客の挙動ステータスが、いずれかの停車場において、次に到着する車両を待っている待ちフェーズにあるのか、いずれかの停車場にいずれかの車両が到着したために乗客がその車両に乗車する乗車フェーズ(例えば、乗車開始、乗車途上、乗車完了という3つのフェーズに再分類される)にあるのか、いずれかの停車場にいずれかの車両が到着したため乗客がその車両から降車する降車フェーズ(例えば、降車開始、降車途上、降車完了という3つのフェーズに再分類される)にある。
さらに、近年、情報通信技術が格段に進歩し、潜在的な乗客の大半が、通信機能を有する携帯端末などの通信端末を携行している。この通信端末は、一般に、相手方通信デバイスの通信特性に応じ、近距離通信および遠距離通信を選択的に行うというように、高度な通信機能を搭載している。
このようなユーザ端末を利用して乗客が車両運行管理システムを利用すれば、ハードウエア資源としてもソフトウエア資源としても、車両運行管理システムに課されるべき負担が軽減される。
これに対し、前述のように、ユーザ端末を利用して乗客が車両運行管理システムを利用するという技術は、特許文献1ないし3において既に提案されている。
しかし、それら特許文献1ないし3においては、ユーザ端末を用いて車両運行設備に対する相対的なユーザの挙動を推定する技術が提案されていない。
これに対し、本発明者は、ユーザの挙動を推定するために、新規なハードウエア構成として、車両運行設備としての車両および停車場にそれぞれ、固有な信号を発信する発信機であってユーザ端末との間で近距離通信が可能であり、かつ、当該発信機からユーザ端末が受信した信号の強度に基づいてユーザ端末が当該発信機との距離を測定可能であるものを装着することを提案した。
本発明者は、さらに、ユーザの挙動を推定するために、新規なソフトウエア構成として、それら発信機からユーザ端末が受信した信号(例えば、受信の有無、受信強度など)に基づき、ユーザ端末が、受信対象(例えば、いずれの車両か、いずれの停車場か)を特定し、その特定された受信対象を参照し、それにより、ユーザの挙動を時刻に関連付けて推定することを提案した。
このような事情を背景に、本発明は、乗客運送用の複数台の車両の運行を管理する技術であって、発信機とユーザ端末とを用いて車両運行設備のステータスまたはその車両運行設備に対する相対的なユーザの挙動またはステータスを時刻に関連付けて推定するものを提供することを課題としてなされたものである。
本発明によって下記の各態様が得られる。各態様は、項に区分し、各項には番号を付し、必要に応じて他の項の番号を引用する形式で記載する。これは、本発明が採用し得る技術的特徴の一部およびそれの組合せの理解を容易にするためであり、本発明が採用し得る技術的特徴およびそれの組合せが以下の態様に限定されると解釈すべきではない。すなわち、下記の態様には記載されていないが本明細書には記載されている技術的特徴を本発明の技術的特徴として適宜抽出して採用することは妨げられないと解釈すべきなのである。
さらに、各項を他の項の番号を引用する形式で記載することが必ずしも、各項に記載の技術的特徴を他の項に記載の技術的特徴から分離させて独立させることを妨げることを意味するわけではなく、各項に記載の技術的特徴をその性質に応じて適宜独立させることが可能であると解釈すべきである。
(1) 乗客運送用の複数台の車両の運行を管理するシステムであって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置され、固有の停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機と、
各車両内に設置され、固有の車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機と、
前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
を含み、
前記通信端末は、
いずれかの停車場発信機から停車場信号を受信すると、その停車場信号に基づき、前記いずれかの停車場発信機が設置されているいずれかの停車場を識別し、その識別結果を前記管理サーバに送信する停車場識別部と、
いずれかの車両発信機から車両信号を受信すると、その車両信号に基づき、前記いずれかの車両発信機が設置されているいずれかの車両を識別し、その識別結果を前記管理サーバに送信する車両識別部と、
いずれかの停車場発信機といずれかの車両発信機との双方から信号を同時に受信すると、現在、前記いずれかの停車場発信機が設置されているいずれかの停車場に、前記いずれかの車両発信機が設置されているいずれかの車両が停車しており、かつ、それら停車場および車両の近傍にユーザが位置すると判定し、その判定結果を前記管理サーバに送信する停車判定部と
を含み、
前記管理サーバは、前記通信端末から前記判定結果を受信すると、その受信時刻に関連付けて、前記受信した判定結果をメモリに保存する保存部を含む車両運行管理システム。
(2) 乗客運送用の複数台の車両の運行を管理するシステムであって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置され、固有の停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機と、
各車両内に設置され、固有の車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機と、
前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
を含み、
前記通信端末は、
いずれかの停車場発信機から停車場信号を受信すると、その停車場信号に基づき、前記いずれかの停車場発信機が設置されているいずれかの停車場を識別する停車場識別部と、
いずれかの車両発信機から車両信号を受信すると、その車両信号に基づき、前記いずれかの車両発信機が設置されているいずれかの車両を識別する車両識別部と、
前記いずれかの停車場発信機から停車場信号を受信し、かつ、前記いずれかの車両発信機から車両信号を受信すると、それら信号に基づき、前記識別された停車場と前記識別された車両とが同じ空間および/または同じ時間を共有するか否かを判定し、共有する場合には、前記識別された停車場と前記識別された車両とを互いに紐付けし、その紐付け情報を前記管理サーバに送信する紐付け部と、
前記いずれかの停車場発信機から受信した停車場信号と前記いずれかの車両発信機から受信した車両信号と前記紐付け情報とに基づき、前記識別された停車場と前記識別された車両とを含む車両運行設備および/またはユーザのステータスを推定し、そのステータス情報を前記管理サーバに送信するステータス推定部と
を含み、
前記管理サーバは、前記通信端末から前記紐付け情報および/または前記ステータス情報を受信すると、その受信時刻に関連付けて、受信した情報をメモリに保存する保存部を含む車両運行管理システム。
(3) 前記ステータス推定部は、各時刻ごとの前記通信端末の停車場信号および車両信号のそれぞれの受信の有無と、各時刻ごとの前記通信端末の停車場信号および車両信号のそれぞれの受信強度と、前記通信端末の停車場信号および車両信号のそれぞれの受信強度の時間的変化特性とのうちの少なくとも一つに基づき、前記車両運行設備に対する相対的なユーザの位置とユーザの挙動フェーズとユーザの移動速度とのうちの少なくとも一つを含むユーザのステータスを推定する(2)項に記載の車両運行管理システム。
(4) 前記ユーザのフェーズは、ユーザがいずれかの停車場で待機する待機フェーズと、ユーザがいずれかの車両に乗車する乗車フェーズと、ユーザがいずれかの車両から降車する降車フェーズとのうちの少なくとも二つに分類される(3)項に記載の車両運行管理システム。
(5) 前記通信端末が前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および第2受信圏のサイズが、互いに異なるように設定される(1)ないし(4)項のいずれかに記載の車両運行管理システム。
(6) 前記通信端末は、その通信端末が前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および第2受信圏のサイズを、発信元が停車場発信機であるか車両発信機であるかに応じて変更するために、有効受信の有無を判定するための実際受信強度または実際受信距離の基準値を、発信元が停車場発信機であるか車両発信機であるかに応じて変更する(1)ないし(5)項のいずれかに記載の車両運行管理システム。
(7) 前記通信端末は、前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および前記第2受信圏のサイズを、前記車両が前記停車場に停車する状態で、前記第1受信圏および第2受信圏が少なくとも部分的に互いにオーバーラップするように設定する(1)ないし(6)項のいずれかに記載の車両運行管理システム。
(8) 前記通信端末は、前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および前記第2受信圏のサイズを、前記車両が前記停車場に停車する状態で、前記第1受信圏および第2受信圏が少なくとも部分的に互いにオーバーラップするように設定し、
前記紐付け部は、前記通信端末がいずれかの停車場に設置されている停車場発信機といずれかの車両に設置されている車両発信機との双方から停車場信号および車両信号を同時に有効に受信すると、前記いずれかの停車場発信機から受信した停車場信号によって表される停車場IDであって今回の停車場を表すものと、前記いずれかの車両発信機から受信した車両信号によって表される車両IDであって今回の車両を表すものとを互いに紐付けする(2)項に記載の車両運行管理システム。
(9) 前記ステータス推定部は、ユーザが、いずれかの停車場に設置された停車場発信機に前記通信端末でタッチするかまたは前記通信端末をかざすと、ユーザが、そのいずれかの停車場に到着する予定の車両に乗車するための予約を行い、その乗車予約を前記管理サーバに送信する乗車予約部を含む(2)項に記載の車両運行管理システム。
(10) 前記ステータス推定部は、ユーザが、いずれかの車両に設置されている車両発信機に前記通信端末でタッチするかまたは前記通信端末をかざすと、ユーザが、そのいずれかの車両への乗車を完了したと判定し、その判定結果を前記管理サーバに送信する乗車完了判定部を含む(2)項に記載の車両運行管理システム。
(11) 前記通信端末は、前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および前記第2受信圏のサイズを、前記車両が前記停車場に停車する状態で、前記第1受信圏および第2受信圏が少なくとも部分的に互いにオーバーラップするように設定し、
前記ステータス推定部は、
前記通信端末が、いずれかの停車場に設置されている停車場発信機といずれかの車両に設置されている車両発信機との双方から停車場信号および車両信号を同時に有効に受信する状態を少なくとも一時的に経験することを条件に、前記いずれかの車両発信機から車両信号を前記いずれの停車場発信機より支配的に有効に受信するかまたは前記いずれかの車両発信機から有効に受信した車両信号の強度が漸減する状態から、前記いずれかの停車場発信機から有効に受信した停車場信号を前記いずれかの車両発信機より支配的に有効に受信する状態に遷移すると、ユーザが、前記いずれかの停車場発信機から有効に受信した停車場信号によって表される停車場IDによって認識される今回の停車場において、前記いずれかの車両発信機から有効に受信した車両信号によって表される車両IDによって認識される今回の車両から降車する降車フェーズにあると判定し、その判定結果を前記管理サーバに送信する降車判定部と、
前記今回の停車場をユーザの実際の降車停車場として認識し、その降車停車場を前記管理サーバに送信する降車停車場認識部と
を含む(2)項に記載の車両運行管理システム。
(12) 前記車両は、乗合バス、貸切りバス、乗合タクシー、貸切りタクシー、列車、電車または軌道系交通機関を含む(1)ないし(11)項のいずれかに記載の車両運行管理システム。
(13) 前記車両は、固定されたルートに沿って運行されるか、または、乗客の要望に応じて随時決まるルートに沿って運行される(1)ないし(12)項のいずれかに記載の車両運行管理システム。
(14) (1)ないし(13)項のいずれかに記載の通信端末としてコンピュータを機能させるためのプログラム。
本明細書の全体を通じて、「プログラム」という用語は、例えば、それの機能を果たすためにコンピュータにより実行される指令の組合せを意味するように解釈したり、それら指令の組合せのみならず、各指令に従って処理されるファイルやデータをも含むように解釈することが可能であるが、それらに限定されない。
また、このプログラムは、それ単独でコンピュータにより実行されることにより、所期の目的を達するものとしたり、他のプログラムと共にコンピュータにより実行されることにより、所期の目的を達するものとすることができるが、それらに限定されない。後者の場合、本項に係るプログラムは、データを主体とするものとすることができるが、それに限定されない。
(15) (1)ないし(13)項のいずれかに記載の管理サーバとしてコンピュータを機能させるためのプログラム。
(16) (14)または(15)項に記載のプログラムをコンピュータ読み取り可能に記録した記録媒体。
本明細書の全体を通じて、「記録媒体」という用語は、種々な形式の記録媒体を意味するように解釈することが可能であり、そのような記録媒体は、例えば、フレキシブル・ディスク等の磁気記録媒体、CD、CD−ROM等の光記録媒体、MO等の光磁気記録媒体、ROM等のアンリムーバブル・ストレージ等を含むが、それらに限定されない。
(17) 乗客運送用の複数台の車両の運行を管理するシステムまたは方法であって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置された少なくとも1個の停車場発信機であって固有の停車場信号を近距離無線通信方式で発信するものと、
各車両内に設置された少なくとも1個の車両発信機であって固有の車両信号を近距離無線通信方式で発信するものと、
前記複数台の車両の運行を集中的に管理する車両運行管理センタによって使用される管理サーバと
を含み、
前記通信端末は、
いずれかの停車場発信機から停車場信号を受信すると、発信機IDと停車場IDとの間に予め定められた関係に従い、前記停車場信号によって表される発信機IDから、前記いずれかの停車場発信機が設置されているいずれかの停車場を識別する停車場識別部と、
いずれかの車両発信機から車両信号を受信すると、発信機IDと車両IDとの間に予め定められた関係に従い、前記車両信号によって表される発信機IDから、前記いずれかの車両発信機が設置されているいずれかの車両を識別する車両識別部と
を含み、
前記通信端末および/または前記管理サーバは、前記通信端末がいずれかの停車場発信機から受信した停車場信号といずれかの車両発信機から受信した車両信号とに基づき、前記識別された停車場と前記識別された車両とが同じ空間および/または同じ時間を共有するか否かを判定し、共有する場合には、前記識別された停車場と前記識別された車両とを時刻に関連付けて互いに紐付けし、それにより、前記識別された停車場と前記識別された車両とを含む車両運行設備のステータスを時刻に関連付けて推定するステータス推定部を含む車両運行管理システムまたは方法。
(18) 前記通信端末および/または前記管理サーバは、さらに、各時刻ごとの前記通信端末の停車場信号および車両信号のそれぞれの受信の有無と、各時刻ごとの前記通信端末の停車場信号および車両信号のそれぞれの受信強度と、前記通信端末の停車場信号および車両信号のそれぞれの受信強度の時間的変化特性とのうちの少なくとも一つに基づき、前記車両運行設備に対する相対的なユーザの位置とユーザの挙動フェーズとユーザの移動速度とのうちの少なくとも一つを含むユーザの挙動ステータスを時刻に関連付けて推定するユーザ挙動推定部を含む(17)項に記載の車両運行管理システムまたは方法。
(19) 乗客運送用の複数台の車両の運行を管理するシステムまたは方法であって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置され、固有の停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機と、
各車両内に設置され、固有の車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機と、
前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
を含み、
前記通信端末は、
いずれかの停車場発信機から停車場信号を受信すると、その停車場信号に基づき、前記いずれかの停車場発信機が設置されているいずれかの停車場を時刻に関連付けて識別する停車場識別部と、
いずれかの車両発信機から車両信号を受信すると、その車両信号に基づき、前記いずれかの車両発信機が設置されているいずれかの車両を時刻に関連付けて識別する車両識別部と、
それぞれの識別結果の内容とそれぞれの識別時刻の同時性および時間的先後とに基づき、ユーザと前記識別された停車場と前記識別された車両との間の相対位置関係を推定する推定部と
を含む車両運行管理システムまたは方法。
(19) 乗客運送用の複数台の車両の運行を管理するシステムまたは方法であって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置され、固有の停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機と、
各車両内に設置され、固有の車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機と、
前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
を含み、
前記通信端末は、
いずれかの停車場発信機から停車場信号を受信すると、その停車場信号に基づき、前記いずれかの停車場発信機が設置されているいずれかの停車場を識別し、その識別結果を前記管理サーバに送信する停車場識別部と、
いずれかの車両発信機から車両信号を受信すると、その車両信号に基づき、前記いずれかの車両発信機が設置されているいずれかの車両を識別し、その識別結果を前記管理サーバに送信する車両識別部と
を含み、
前記管理サーバは、前記通信端末から受信したそれぞれの識別結果の内容とそれぞれの受信時刻の同時性および時間的先後とに基づき、ユーザと前記識別された停車場と前記識別された車両との間の相対位置関係を推定する推定部を含む車両運行管理システムまたは方法。
(20) 乗客運送用の複数台の車両の運行を管理するシステムまたは方法であって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置され、固有の停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機と、
各車両内に設置され、固有の車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機と、
前記複数台の車両の運行を管理するために使用される管理サーバと
を含み、
前記通信端末は、
いずれかの停車場発信機から停車場信号を受信すると、その停車場信号に基づき、前記いずれかの停車場発信機が設置されているいずれかの停車場を識別し、その識別結果を前記管理サーバに送信する停車場識別部と、
いずれかの車両発信機から車両信号を受信すると、その車両信号に基づき、前記いずれかの車両発信機が設置されているいずれかの車両を識別し、その識別結果を前記管理サーバに送信する車両識別部と、
各停車場発信機および/または各車両発信機の故障の有無を診断する故障診断部と、
当該通信端末の現在位置をユーザの現在位置として測定する測位部と、
その測位部によって測定されたユーザの現在位置および/または当該通信端末の速度取得部もしくは加速度取得部によって取得されたユーザの速度もしくは加速度を用いて、ユーザの行動を、ユーザがいずれかの停車場発信機において静止または歩行しているのか、ユーザが走行中のいずれかの車両に乗車していてその車両と共に走行しているのかを推定するユーザ行動推定部と、
いずれかの停車場発信機が故障していると診断すると、前記停車場識別部に代わり、測定されたユーザの現在位置と、推定されたユーザの行動とから、ユーザが居る停車場を識別し、その識別結果を前記管理サーバに送信する代行停車場識別部と、
いずれかの車両発信機が故障していると診断すると、前記車両識別部に代わり、測定されたユーザの現在位置と、推定されたユーザの行動とから、ユーザが乗車している車両を識別し、その識別結果を前記管理サーバに送信する代行車両識別部と
を含む車両運行管理システムまたは方法。
(21) 前記故障診断部は、各発信機の設置位置と各発信機の発信機IDとの間に予め定められた関係であって前記通信端末または前記管理サーバのメモリに保存されているものに従い、前記測位部によって測定された現在位置から、その現在位置に設置されているはずであるいずれの発信機を識別し、そのいずれかの発信機から信号を前記通信端末が受信しない場合に、そのいずれかの発信機が故障していると診断する(20)項に記載の車両運行管理システムまたは方法。
(22) 地理的に互いに異なる複数の位置にそれぞれ設置されている複数の発信機の各々の故障の有無をユーザがその設置位置に居るときにそのユーザの通信端末を用いて診断する方法であって、
前記通信端末の測位部により、その現在位置を測定する測位工程と、
各発信機の設置位置と各発信機の発信機IDとの間に予め定められた関係であって前記通信端末のメモリに保存されているものに従い、前記測定された現在位置から、その現在位置に設置されているはずであるいずれの発信機を識別する識別工程と、
その識別されたいずれかの発信機から信号を前記通信端末が受信しない場合に、そのいずれかの発信機が故障していると診断する診断工程と、
その診断結果を管理サーバに送信する送信工程と
を含む発信機故障診断方法。
この方法は、発信機の故障(例えば、機能不全、電池不足など)の有無を診断する技術に関する。
この方法によれば、ユーザが、予定通りまたは偶然に、いずれかの発信機の設置位置に接近したときに、そのユーザの通信端末を用いてそのいずれかの発信機の故障の有無を診断し、その診断結果を、そのユーザの通信端末から、遠隔地にある管理サーバに通知することが可能となる。
その結果、この方法によれば、管理サーバは、地理的に離散的に位置する複数の発信機を集中的に管理する際に、各発信機ごとの故障診断を、作業者をわざわざその発信機の設置位置に派遣させなくても、故障診断に必要な作業をユーザに、場合によっては無意識のうちに、代行させ、さらに、そのユーザの通信端末による診断結果を管理サーバに送信することによってその管理サーバにリアルタイムで通知することが可能となる。
図1は、本発明の例示的な一実施形態に従うバス運行管理システムのハードウエア構成を概念的に表す系統図である。
図2は、図1に示すバス運行管理システムにおける総合的な通信ネットワークであって複数のノードとしてのバス停、バス、ユーザ端末およびバス運行管理センタを相互に接続するものを概念的に表す系統図である。
図3は、図1に示すバス運行管理システムにおいて、ユーザが、待機フェーズにあるために、いずれかのバス停に接近してそのバス停に設置されているバス停発信機に携帯端末でタッチする行動の一例を示す平面図である。
図4は、図1に示すバス運行管理システムにおいて、ユーザが、乗車フェーズにあるために、前記いずれかのバス停において、いずれかのバスにそれの乗車口から乗車してその乗車口に設置されている乗車口発信機に携帯端末でタッチする行動の一例を示す平面図である。
図5は、図1に示すバス運行管理システムにおいて、ユーザが、降車フェーズにあるために、前記いずれかのバス停において、いずれかのバスの降車口から降車する行動の一例を示す平面図である。
図6(a)は、前記待機フェーズにおいて、前記携帯端末が希望乗車バス停のバス停発信機から受信する信号の相対受信強度Irの時刻歴の一例を概念的に表すグラフであり、同図(b)は、前記乗車フェーズにおいて、前記携帯端末が前記乗車口発信機から受信する信号の相対受信強度Irの時刻歴の一例を概念的に表すグラフであり、同図(c)は、前記降車フェーズにおいて、前記携帯端末が前記降車口発信機から受信する信号の相対受信強度Irの時刻歴の一例を概念的に表すグラフであり、同図(d)は、同じく降車フェーズにおいて、前記携帯端末が希望降車バス停のバス停発信機から受信する信号の相対受信強度Irの時刻歴の一例を概念的に表すグラフである。
図7は、図1に示すバス運行管理システムが適用されるバス路線図の一例を部分的に示す平面図である。
図8は、いずれも図2に示すバス停発信機ならびに乗車口発信機および降車口発信機であってそれぞれ互いに共通する構成を有するものを概念的に表す機能ブロック図である。
図9は、図1に示すバス運行管理システムにおいて、複数のバス停に設置される複数のバス停発信機についての複数の発信機IDを管理するテーブルの一例を示す図である。
図10は、図1に示すバス運行管理システムにおいて、複数台のバスに搭載される複数の乗車口発信機および複数の降車口発信機についての複数の発信機IDを管理するテーブルの一例を示す図である。
図11は、図1に示すバス運行管理システムにおいて、複数の発信機についての複数の有効受信半径(有効受信の有無を判定するための基準値)を管理するテーブルの一例を示す図である。
図12は、図1に示すユーザすなわちバスの潜在的な乗客の携帯端末を概念的に表す機能ブロック図である。
図13は、図1に示す各発信機から同図に示す携帯端末が受信する信号の強度である絶対受信強度RSSIがそれら発信機と携帯端末との間の距離Dに応じて減少するという信号特性を概念的に表すグラフである。
図14は、図1に示す管理サーバを概念的に表す機能ブロック図である。
図15は、図1に示すバス運行管理システムの携帯端末および管理サーバによって実行される複数のプログラムであって前記待機フェーズを検知するとともにユーザのために乗車を予約するために実行されるものを概念的に表すフローチャートである。
図16は、図1に示すバス運行管理システムの携帯端末および管理サーバによって実行される複数のプログラムであって前記乗車フェーズを検知するために実行されるものを概念的に表すフローチャートである。
図17は、図1に示すバス運行管理システムの携帯端末および管理サーバによって実行される複数のプログラムであって前記降車フェーズを検知するために実行されるものを概念的に表すフローチャートである。
図18は、図1に示すバス運行管理システムにおいて、図1に示す管理サーバによって作成されるステータス管理テーブルであって各ユーザごとにステータスの時刻歴を表すものの一例を概念的に表す図である。
図19は、図1に示すバス運行管理システムにおいて、前記携帯端末の画面上に表示される複数の仮想的なボタンであって、複数の副次的な機能をユーザが選択して起動させるためにユーザによって選択して操作されるものの一例を概念的に表す正面図である。
以下、本発明のさらに具体的で例示的な複数の実施の形態のうちの一つを図面に基づいて詳細に説明する。
図1には、本発明の一実施形態に従うバス運行管理システム(以下、単に「システム」という。)10のハードウエア構成および通信ネットワーク構成が概念的に系統図で表されている。このシステムは、本発明の一実施形態に従う車両運行管理システムの一例であって、本発明の一実施形態に従う車両運行管理方法の一例を実行する。
<システムのハードウエア構成の概略>
概略的に説明するに、このシステム10は、旅客用の複数台のバス12の運行を管理することを目的として構成される。
その目的を達成するために、このシステム10は、(a)いずれかのバス12の乗客となる可能性があるユーザの携帯端末90と、(b)各バス停14に設置されるバス停発信機30と、(c)各バス12内に、そのバス12の乗車口16に設置される乗車口発信機32およびバス12の降車口18に設置される降車口発信機34と、(d)前記複数台のバス12の運行を集中的に管理する車両運行管理センタ40によって使用される管理サーバ50と、(e)各バス12内に設置されるバス内通信装置20とを備えている。
バス12は、前述の「乗客運送用の車両」の一例であり、例えば、乗合バス、貸切りバスである。また、バス12は、固定されたルート(例えば、路線)に沿って運行されるか、または、乗客の要望に応じて随時決まる可変のルートに沿って運行される。
ユーザの携帯端末90は、前述の「ユーザの通信端末」の一例である。バス停14は、前述の「停車場」の一例であり、また、バス停発信機30は、前述の「停車場発信機」の一例である。前述の「停車場」の別の例は、列車、電車(例えば、路面電車、地下鉄)の駅である。前述の「停車場」のさらに別の例は、タクシーの停車場である。
乗車口発信機32および降車口発信機34は、それぞれ、前述の「少なくとも1個の車両発信機」の一例である。本実施形態においては、乗車口発信機32および降車口発信機34がいずれも、バス12の室内に設置されているが、これに代えて、バス12の外壁内に設置されても、バス12の外壁面に設置されてもよい。
本実施形態においては、バス12が、乗車口16と降車口18とを有するというように、乗客がバス12に乗車するときとバス12から降車するときとで互いに異なるゲートを通過するようになっているが、これに代えて、同じゲートを通過するようにしてもよい。すなわち、バス12は、少なくとも1個の乗降口を有してもよいのである。
バス停発信機30、乗車口発信機32および降車口発信機34は、互いに共通する構成を有する。具体的には、いずれの発信機30,32,34も、(a)固有な信号を発信し、(b)図2に示すように、携帯端末90との間で一方向近距離通信が可能であり、(c)図13を参照して後述するように、各発信機30,32,34から携帯端末90が受信した信号の強度RSSI(Received Signal Strength Indicator、受信信号強度、受信信号強度指標値)に基づいて携帯端末90が各発信機30,32,34との距離D(すなわち、実際の受信半径)を測定可能であるものである。
説明の便宜上、バス停発信機30から携帯端末90が受信する信号をバス停信号と称し、また、乗車口発信機32から携帯端末90が受信する信号を乗車口信号と称し、また、降車口発信機34から携帯端末90が受信する信号を降車口信号と称する。ここに、「バス停信号」は、前述の「停車場信号」の一例であり、また、「乗車口信号」は、前述の「車両信号」の一例であり、また、「降車口信号」は、前述の「車両信号」の別の例である。
図2に示すように、携帯端末90は、管理サーバ50との間で、通信ネットワークを介して遠距離双方向通信が可能である。同様に、バス内通信装置20も、管理サーバ50との間で、通信ネットワークを介して遠距離双方向通信が可能である。
バス内通信装置20は、交通情報やリクエストを管理サーバ50に送信する送信部22と、交通情報やリクエストを管理サーバ50から受信する受信部24と、その受信した情報を運転手または乗客に出力する出力部26とを有する。
その出力部26は、受信部24が管理サーバ50から受信した、バス12の運転手向けの情報であって、例えば、当該バス12の運行関連情報(例えば、当該路線についての渋滞情報または事故情報、当該路線の周辺の天候情報、当該バス12の乗車率(混雑度)の時間的変動予測情報など)をバス12の運転手に出力する。
この出力部26は、さらに、受信部24が管理サーバ50から受信した、バス12内の乗客向けの情報であって、例えば、運行関連情報(例えば、渋滞情報、事故情報、天候情報、当該バス12の乗車率(混雑度)の時間的変動予測情報など)、案内情報(例えば、バス12の路線の周辺にある観光地に関係する情報など)、広告情報(当該バス12の運営会社または他の他の企業に関係する広告情報など)をバス12内の複数人の乗客に出力する。
この出力部26は、画像で運転手または乗客に出力したり、音声で運転手または乗客に出力したり、または、運転手または乗客用の携帯端末90に無線で出力してもよい。よって、出力部26の一例は、ディスプレイであり、別の例は、スピーカまたはイヤホンであり、さらに別の例は、送信機である。
<システムのソフトウエア構成ないしはアルゴリズムの概略>
このシステム10は、いずれかのバス停発信機30からバス停信号を受信すると、そのバス停信号に基づき、そのバス停発信機30が設置されているバス停14を識別し、さらに、いずれかのバス内発信機32,34からバス信号を受信すると、そのバス信号に基づき、そのバス内発信機32,34が設置されているバス12を識別する。
このシステム10は、さらに、バス停発信機30から受信したバス停信号とバス内発信機32,34から受信したバス信号とに基づき、バス停14とバス12とが同じ空間および/または同じ時間を共有するか否かを判定し、共有する場合には、バス停14とバス12とを時刻に関連付けて互いに紐付けして、バス停14とバス12とを備えたバス運行設備のステータスを時刻に関連付けて推定する。
このシステム10は、さらに、各時刻ごとの携帯端末90のバス停信号およびバス信号のそれぞれの受信の有無と、各時刻ごとの携帯端末90のバス停信号およびバス信号のそれぞれの受信強度と、携帯端末90のバス停信号およびバス信号のそれぞれの受信強度の時間的変化特性とのうちの少なくとも一つに基づき、複数台のバス12と複数箇所のバス停14とを備えたバス運行設備に対する相対的なユーザの位置とユーザの挙動フェーズとユーザの移動速度とのうちの少なくとも一つを含むユーザの挙動ステータスを時刻に関連付けて推定する。
ここに、ユーザの挙動フェーズは、ユーザがいずれかの停車場で待機する待機フェーズと、ユーザがいずれかの車両に乗車する乗車フェーズと、ユーザがいずれかの車両から降車する降車フェーズとに分類される。
待機フェーズは、例えば、携帯端末90のユーザが、いずれかのバス停14において、次に到着するバス12を待っているフェーズとして定義される。また、乗車フェーズは、例えば、携帯端末90のユーザが、いずれかのバス停14にいずれかのバス12が到着したためにそのバス12に乗車するフェーズとして定義される。また、降車フェーズは、例えば、いずれかのバス停14にいずれかのバス12が到着したためにそのバス12に乗車している乗客である携帯端末90のユーザがそのバス12から降車するフェーズとして定義される。
<待機フェーズ判別アルゴリズム>
図3に例示するように、ユーザが、携帯端末90と共に、いずれかのバス停14に接近し、バス停発信機30の第1受信圏内に進入すると、図6(a)に例示するように、携帯端末90がバス停発信機30から受信した信号の強度である受信強度Iが時間tと共に増加する。
このとき、携帯端末90は、そのユーザが、今回のバス停14において、次のバス12を待っている待機フェーズにあると判定し、その結果を管理サーバ50に送信する。
ここに、「受信圏」という用語は、後に詳述するが、携帯端末90がバス停発信機30からバス停信号を有効に受信できる範囲を意味する。他の受信圏である後述の第2受信圏および第3受信圏もそれに準ずる意味を有する。
ユーザが、さらに、バス停発信機30に接近すると、やがて、バス停発信機30に最も接近した位置に到達し、その位置において、受信強度Iが最大値Imaxとなる。
この位置において、ユーザが、そのバス停発信機30に携帯端末90でタッチするかまたは携帯端末90をかざす(バス停発信機30に例えば50cm以内の距離で接近する)と、携帯端末90が、ユーザが、そのバス停14においてそのバス停14に次に到着する予定のバス12に乗車することを予約することをリクエストするための乗車予約信号を管理サーバ50に送信する。
<乗車フェーズ判別アルゴリズム>
図4に例示するように、今回のバス停14にバス12が接近し、やがて到着して停車する。この停車状態において、ユーザが、そのバス12に乗車口16から乗車するために、携帯端末90と共に、今回のバス停14から今回のバス12の乗車口16に接近し、乗車口発信機32の第2受信圏内に進入すると、図6(b)に例示するように、携帯端末90が乗車口発信機32から受信した信号の強度である受信強度Iが時間tと共に増加する。
このとき、携帯端末90は、そのユーザが、今回のバス12に乗車する乗車フェーズにある(例えば、乗車が開始された乗車開始モードにある)と判定し、その結果を管理サーバ50に送信する。
図4に例示するように、バス停発信機30の第1受信圏と、バス停14に停車しているバス12の乗車口発信機32の第2受信圏とが部分的に互いにオーバーラップする。
したがって、図6(a)および(b)に例示するように、乗車フェーズの進行中に、同じユーザの同じ携帯端末90が、バス停発信機30と乗車口発信機32との双方からバス停信号および乗車口信号を同時に受信する同時受信区間が存在する。
その同時受信区間を携帯端末90が経験すると、その携帯端末90は、バス停発信機30から受信したバス停信号によって表されるバス停ID(前述の「停車場ID」の一例)と、乗車口発信機32から受信した乗車口信号によって表されるバスID(前述の「車両ID」の一例)とを互いに紐付けし、同じ物理空間上で今回のユーザと今回のバス停14と今回のバス12とが互いに関連付けられたと判定し、その結果を管理サーバ50に送信する。
ここに、「同じ物理空間上で今回のユーザと今回のバス停14と今回のバス12とが互いに関連付けられた」という文言は、幾何学的に解釈すれば、例えば、それら3つの物体が時間という次元に関してではなく場所という次元に関して互いに関連付けられる(例えば、バス12とバス停14との距離が所定距離未満である)ことを意味する。
また、その文言は、現象的に解釈すれば、例えば、今回のバス停14で今回の乗客が待機しており、その乗客が乗車しようとしている今回のバス12が今回のバス停14に停車直前であるか、停車しているかまたは、今回の乗客が今回のバス12に乗車してそのバス12が発車した直後であることを意味する。
ユーザが、さらに同じ向きに歩行し、乗車口16からバス12内に乗車し、そのバス12の乗車口16に位置する乗車口発信機32に接近すると、やがて、ユーザは、乗車口発信機32に最も接近した位置に到達し、その位置において、受信強度Iが最大値Imaxとなる。
この位置において、ユーザが、その乗車口発信機32に携帯端末90でタッチするかまたは携帯端末90をかざす(乗車口発信機32に例えば30cmまたは50cm以内の距離で接近する)と、携帯端末90が、ユーザが、そのバス停14への乗車が完了したと判定し、その結果を管理サーバ50に送信する。
<降車フェーズ判定アルゴリズム>
図5に例示するように、携帯端末90を持った乗客が乗車しているバス12が今回のバス停14に接近し、やがて到着して停車する。この停車状態において、ユーザが、そのバス12において、携帯端末90と共に、降車口18に接近する。
やがて、ユーザが、バス12の車内において、降車口発信機34の第3受信圏内に進入すると、図6(c)に例示するように、携帯端末90が降車口発信機34から受信した信号の強度である受信強度Iが時間tと共に増加する。その後、受信強度Iが最大値Imaxに達する。
その後、ユーザが降車口発信機34から遠ざかると、受信強度Iが低下する。降車口発信機34が降車口18内においてバス12の外板近傍に配置されているため、受信強度Iの低下は、現象的には、ユーザがバス12を、降車口発信機34から降車したという行動を反映する可能性が高い。
よって、このとき、携帯端末90は、今回のユーザが、今回のバス12から降車する降車フェーズにある(例えば、降車が開始された降車開始モードにある)と判定し、その結果を管理サーバ50に送信する。
バス12がバス停14に停車している状態においては、ユーザが降車口発信機34から遠ざかるにつれて、ユーザがバス停発信機30に接近することになる。その結果、図6(d)に例示するように、携帯端末90がバス停発信機30から受信した信号の強度である受信強度Iが時間tと共に増加する。
図5に例示するように、バス停発信機30の第1受信圏と、バス停14に停車しているバス12の降車口発信機34の第3受信圏とが部分的に互いにオーバーラップする。
したがって、図6(c)および(d)に例示するように、降車フェーズの進行中に、同じユーザの同じ携帯端末90が、バス停発信機30と降車口発信機34との双方からバス停信号および降車口信号を同時に受信する同時受信区間が存在する。
その同時受信区間を携帯端末90が経験すると、その携帯端末90は、降車口発信機34から受信した乗車口信号によって表されるバスIDと、バス停発信機30から受信したバス停信号によって表されるバス停IDとを互いに紐付けし、同じ物理空間上で今回のユーザと今回のバス停14と今回のバス12とが互いに関連付けられたと判定し、その結果を管理サーバ50に送信する。
ここに、「同じ物理空間上で今回のユーザと今回のバス停14と今回のバス12とが互いに関連付けられた」という文言は、現象的に解釈すれば、例えば、今回の乗客が降車しようとしている今回のバス12が、今回のバス停14に停車直前であるか、停車しているかまたは発車直後である(例えば、バス12とバス停14との距離が所定距離未満である)ことを意味する。
ユーザが、さらに同じ向きに歩行し、降車口発信機34から遠ざかると、やがて、受信強度I4が0に低下する。この現象に応答し、携帯端末90が、ユーザのバス12からの降車が完了したと判定し、その結果を管理サーバ50に送信する。
ユーザが、さらに同じ向きに歩行し、バス停発信機30に接近すると、やがて、そのバス停発信機30に最も接近した位置に到達し、その位置において、受信強度Iが最大値Imaxとなる。その後、ユーザが、さらに同じ向きに歩行し、バス停発信機30から遠ざかると、受信強度Iが低下する。
<バス路線の例と各要素へのIDの割り付け例>
図7に例示するように、このシステム10が適用されるバス路線においては、1つのバス停14に、複数本のルートAおよびBが相乗りしている。よって、ルートAを運行するバス14と、ルートBを運行するバス14とが、時間を異にして、同じバス停14に停車する。
図7に示すように、バス停14自体、そのバス停14のバス停発信機30、バス12自体、ならびに、そのバス12内の乗車口発信機32および降車口発信機34にそれぞれ、固有の識別子、すなわち、IDが予め割り当てられている。
特に、乗車口発信機32および降車口発信機34については、それら発信機32および34が共通に設置されるバス12に固有のIDの部分(例えば、メインID)と、それら発信機32および34にそれぞれ固有のIDの部分(例えば、サブID)との双方が割り当てられる。図7に示す例においては、ある発信機のサブIDが「1」であるときに、その発信機が乗車口発信機32であることを表す一方、ある発信機のサブIDが「2」であるときに、その発信機が降車口発信機34であることを表す。
<発信機>
図8には、いずれも図1に示すバス停発信機30、乗車口発信機32および降車口発信機34であって共通の構成を有するものが機能ブロック図で表されている。
それらバス停発信機30、乗車口発信機32および降車口発信機34は、共通の構成を有するため、以下、図8を参照することにより、その共通の構成を、バス停発信機30のみについて代表的に説明する。
まず、概念的に説明するに、バス停発信機30は、固有の発信機IDを識別し得る識別信号を局地的に発信する非接触式または接触(近接)式の通信デバイスである。
次に、作動方式を説明するに、バス停発信機30は、固有の識別信号を外部からのトリガ信号を要することなく能動的に、局地的に、かつ、供給電力が不足しない限り永続的に発信する。
バス停発信機30は、一般に、識別信号としてのビーコン信号を発信するビーコン装置、無線標識などの名称でも知られている装置である。このバス停発信機30は、一例においては、原信号を変調することにより、対応する発信機IDを表す識別信号を生成し、その生成された識別信号を、IR信号、Bluetooth(登録商標)信号、NFC(近距離無線通信)信号などとして局地的に発信する。
次に、図8を参照してハードウエア構成を説明するに、バス停発信機30は、プロセッサ100およびそのプロセッサ100によって実行される複数のアプリケーションを記憶するメモリ102を有するコンピュータ104を主体として構成されている。
このバス停発信機30は、さらに、電源としての交換可能な使い捨て電池106を有している。電池106に代えて、充電可能な電池を採用したり、外部電源としての商用電源または太陽電池を採用することが可能である。
外部電源として太陽電池を採用する場合、昼間に太陽電池を用いて発電された電気エネルギーのうち余剰のものをバッテリに蓄積し、夜間には、そのバッテリから電池エネルギーを取り出してバス停発信機30を作動させてもよい。
このバス停発信機30は、さらに、識別信号を生成して発信する発信部108を有している。その発信部108は、電池106によって作動させられるとともに、コントローラ110によって制御される。そのコントローラ110は、コンピュータ100によって制御される。
バス停発信機30のソフトウエア構成を説明するに、プロッサ100は、発信機IDが反映されるように、原信号(例えば、搬送信号)を変調するための信号をコントローラ110に対して出力する。そのコントローラ110は、発信部108を制御し、その結果、発信部108は、今回発信すべき識別信号を生成する。その後、その生成された識別信号が発信部108から発信される。
次に、図9ないし図11を参照することにより、バス停発信機30、乗車口発信機32および降車口発信機34を個々に説明する。
各バス停発信機30は、固有の信号を発信し、その固有の信号は、固有の発信機IDを表す。各バス停発信機30については、いずれのバス停14に設置されているかが既知であり、かつ、そのバス停14の空間座標値(x,y,z)も既知であるため、バス停発信機30から受信した信号が、予め定められた信号(例えば、2値信号列)−ID間の関係に従い、発信機IDに変換されれば、その発信機IDから、バス停発信機30が設置されているバス停14のIDと、のバス停14の地理的位置とがそれぞれ一義的に決まる。
図9には、バス停発信機ID管理テーブルが表形式で表されている。このテーブルは、管理サーバ50のメモリに保存されており、携帯端末90からアクセスがあると、そのテーブルが管理サーバ50から携帯端末90にダウンロードされてそれのメモリ132に保存される。このテーブルにおいては、バス停発信機30の発信機IDと、そのバス停発信機30が設置されているバス停14のバス停IDと、そのバス停14のバス停名称との関係が発信機IDごとに定義されている。
各乗車口発信機32は、固有の信号を発信し、その固有の信号は、固有の発信機IDを表す。各乗車口発信機32については、いずれのバス12に設置されているかが既知であり、かつ、そのバス12の乗車口16と降車口18とのうちのいずれに設置されているかも既知であるため、乗車口発信機32から受信した信号が、予め定められた信号(例えば、2値信号列)−ID間の関係に従い、発信機IDに変換されれば、その発信機IDから、その乗車口発信機32が設置されているバス12のIDと、その乗車口発信機32が降車口発信機ではなく乗車口発信機であることとがそれぞれ一義的に決まる。
各降車口発信機34は、固有の信号を発信し、その固有の信号は、固有の発信機IDを表す。各降車口発信機34については、いずれのバス12に設置されているかが既知であり、かつ、そのバス12の乗車口16と降車口18とのうちのいずれに設置されているかも既知であるため、降車口発信機34から受信した信号が、予め定められた信号(例えば、2値信号列)−ID間の関係に従い、発信機IDに変換されれば、その発信機IDから、その降車口発信機34が設置されているバス12のIDと、その降車口発信機34が乗車口発信機ではなく降車口発信機であることとがそれぞれ一義的に決まる。
図10には、バス内発信機ID管理テーブルが表形式で表されている。このテーブルは、管理サーバ50のメモリに保存されており、携帯端末90からアクセスがあると、そのテーブルが管理サーバ50から携帯端末90にダウンロードされてそれのメモリ132に保存される。このテーブルにおいては、乗車口発信機32および降車口発信機34の発信機IDと、乗車口発信機32または降車口発信機34が設置されているバス12のバスIDと、そのバス12に適用されるルートを表すルートIDとの関係が発信機IDごとに定義されている。
図11には、有効受信半径管理テーブルが表形式で表されている。このテーブルは、管理サーバ50のメモリに保存されており、携帯端末90からアクセスがあると、そのテーブルが管理サーバ50から携帯端末90にダウンロードされてそれのメモリ132に保存される。このテーブルにおいては、バス停発信機30、乗車口発信機32および降車口発信機34の発信機IDと、後述の有効受信半径との関係が発信機IDごとに定義されている。
この有効受信半径管理テーブルに従い、携帯端末90は、それが受信している発信機30,32,34の種別(バス停14用か、乗車口16用か、降車口18用か)に応じて有効受信半径を可変に設定し、その結果、発信機30,32,34ごとに個別に有効受信半径を設定することが可能となる。
有効受信半径の可変設定を具体的に説明すると、図3に示す待機フェーズの例においては、携帯端末90が、バス停発信機30から信号を受信すると、そのバス停発信機30を中心とする円を成す第1受信圏を定義する第1有効受信半径R1を5m(図11参照)に設定する。
図4に示す乗車フェーズの例においては、携帯端末90が、乗車口発信機32から信号を受信すると、その乗車口発信機32を中心とする円を成す第2受信圏を定義する第2有効受信半径R2を1m(図11参照)に設定する。
図5に示す降車フェーズの例においては、携帯端末90が、降車口発信機34から信号を受信すると、その降車口発信機34を中心とする円を成す第3受信圏を定義する第3有効受信半径R3を1m(図11参照)に設定する。
<携帯端末>
携帯端末90は、ユーザによって携帯されるとともに無線通信機能を有するデバイス、例えば、携帯電話機、スマートフォン、ラップトップ型コンピュータ、タブレット型コンピュータ、PDAなどである。また、携帯端末90は、ユーザの通信端末の一例である。
次に、図12を参照して携帯端末90のハードウエア構成を説明するに、携帯端末90は、プロセッサ130およびそのプロセッサ130によって実行される複数のプログラム(「アプリケーション」ともいう)を記憶するメモリ132を有するコンピュータ134を主体として構成されている。
この携帯端末90は、さらに、情報を表示する表示部(例えば、液晶ディスプレイ)136と、バス停発信機30および管理サーバ50からの信号を受信する受信部138と、信号を生成してその信号を管理サーバ50に送信する送信部140とを有する。ここに、受信部138は、バス停発信機30からの識別信号を感知する部分でもある。
この携帯端末90は、さらに、ユーザからデータやコマンドを入力するための入力部150を有する。その入力部150は、例えば、所望の情報(例えば、コマンド、データなど)を携帯端末90に入力するためにユーザによって操作可能な操作部を有する。その操作部としては、ユーザによって操作可能なアイコン(例えば、仮想的なボタン)を表示するタッチスクリーン、ユーザによって操作可能な物理的な操作部(例えば、キーボード、キーパッド、ボタンなど)、音声を感知するマイクなどがあるが、これらに限定されない。
この携帯端末90は、さらに、GPS(衛星測位システム)受信機152を有する。GPS受信機152は、よく知られているように、複数のGPS衛星から複数のGPS信号を受信し、それらGPS信号に基づき、GPS受信機152の地球上における位置(緯度、経度および高度)を三角測量によって測定する。
この携帯端末90は、さらに、自身の加速度を検出する加速度センサ154を内蔵している。その加速度センサ154は、携帯端末90に搭載されているため、携帯端末90と一体的に振動し、その結果、加速度センサ154自体に作用する加速度を、携帯端末90およびそれを携帯しているユーザに作用する加速度と等価なものとして検出する。
この加速度センサ154の型式は、例えば、半導体ピエゾ抵抗型、静電容量型、熱検知型などである。一例においては、この加速度センサ154が、X軸、Y軸およびZ軸という3軸方向の加速度Gx,Gy,Gzを個々に検出し、それら3つの検出値Gx,Gy,Gzの合成値Grとして1つの代表加速度を出力するように設計することが可能である。
この加速度センサ154は、ユーザが携帯端末90を携帯している場合には、そのユーザに作用する加速度に近似するものを検出し、また、そのユーザが車両に乗車している場合には、その車両に作用する加速度(例えば、前後方向加速度、前後方向減速度)に近似するものを検出する。
なお、携帯端末90に作用する加速度は、理論的には、上述のGPS信号に基づいて測定された位置の時間微分を行って速度を計算し、さらに、その速度の時間微分を行うことによって計算することが可能である。しかし、精度の点では、加速度センサ154によって検出された加速度の方が優れている可能性がある。いずれにしても、この加速度センサ154は、車両の軸加速度を検出または推定によって取得する加速度取得部の一例なのである。
ここで、バス停発信機30に関連付けてユーザの携帯端末90の一機能を説明するに、その携帯端末90は、バス停発信機30から識別信号を受信している状態で、その携帯端末90のコンピュータに予めインストールされているあるプログラム、すなわち、ガイド発信機処理のための専用アプリケーション(以下、「発信機用アプリケーション」という。)を起動させる(ログイン)と、前記受信した識別信号を復調し、それにより、前記発信機IDを解読する。
さらに、携帯端末90は、バス停発信機30から識別信号を受信している状態で、前記発信機用アプリケーションを起動させると、前記受信した識別信号(例えば、その識別信号の強度)に基づき、その識別信号を発信したときのバス停発信機30の位置と、その識別信号を受信したときの携帯端末90の位置との間の距離を測定することも行う。
すなわち、携帯端末90は、バス停発信機30から受信した識別信号に基づき、そのバス停発信機30に固有の発信機IDと、そのときのバス停発信機30との距離との双方を獲得するようになっているのである。
<発信機の受信レンジ>
バス停発信機30、乗車口発信機32および降車口発信機34には、それぞれ、みかけ上、2種類の受信エリアが割り当てられる。それらは、受信可能エリアと有効受信エリア(以下、「受信レンジ」または「受信圏」ともいう。)である。
それらエリアは、いずれも、各発信機30,32,34の設置位置を中心とする1つの球で概して画定される。受信圏のいくつかの例が、前述のように、図3ないし図5に示されている。
各発信機30,32,34の受信可能エリアは、最大受信半径(例えば、約50m)を有するのに対し、有効受信エリアは、有効受信半径(例えば、0mから約50mまでの範囲内の任意の値)を有する。最大受信半径は不変値であるのに対し、有効受信半径は、後述のように、携帯端末90によって随時設定可能な可変値である。
受信可能エリアは、各発信機30,32,34の電力供給が正常である場合に、各発信機30,32,34からの識別信号が到達可能なエリア、すなわち、そのエリア内に存在する限り、携帯端末90がその識別信号を受信可能なエリアを意味する。
これに対し、有効受信エリアは、受信可能エリアの最大受信半径より小さい有効受信半径を有している。最大受信半径は、任意に設定することが不可能であるのに対し、有効受信半径は、携帯端末90においてソフト的に任意に設定することが可能である。
すなわち、最大受信半径は、ハードウエアによって決まる受信限度を意味するのに対し、有効受信半径は、ソフトウエアによって決まる受信限度を意味するということが可能なのである。
前述のように、携帯端末90は、それが受信した識別信号の強度に基づき、各発信機30,32,34との距離を測定する。図13には、携帯端末90が各発信機30,32,34から受信する信号の強度である受信強度RSSIが、携帯端末90と各発信機30,32,34との間の距離Dが増加するにつれて低下する様子がグラフで例示されている。このグラフで表される特性を参照すれば、携帯端末90は、受信強度RSSIを距離測定値Dに変換することができる。
その距離測定値Dは、可変設定値としての有効受信半径rを超えることもあれば、超えないこともある。そして、その距離測定値Dが受信有効半径rを超えないときは、携帯端末90が有効受信エリア内に存在するときであるのに対し、その距離測定値Dが受信有効半径rを超えるときは、携帯端末90が受信可能エリア内には存在するが有効受信エリア内には存在しないときである。
図13には、距離測定値Dが受信有効半径rを超えるか否かを問わず、携帯端末90が各発信機30,32,34から受信した信号の強度を表すグラフと、説明の便宜上、距離測定値Dが受信有効半径rを超えない領域についてのみ受信強度が存在するように絶対受信強度Iaのグラフを下方にシフトしてなるグラフとが存在する。前者のグラフは、絶対受信強度Iaを表すグラフと称することとすれば、後者のグラフは、相対受信強度Irを表すグラフと称することとができる。そして、図6(a)ないし(d)の各グラフは、相対受信強度Irを用いて作成されている。
<管理サーバ>
次に、管理サーバ50のハードウエア構成を説明するに、図14には、管理サーバ50が機能ブロック図で表されている。管理サーバ50は、プロセッサ160およびそのプロセッサ160によって実行される複数のアプリケーションを記憶するメモリ162を有するコンピュータ164を主体として構成されている。
この管理サーバ50は、さらに、情報を表示する表示部(例えば、液晶ディスプレイ)166と、携帯端末90からの信号を受信する受信部168と、信号を生成してその信号を携帯端末90に送信する送信部170と、時計172とを有する。この管理サーバ50は、発信機30からの受信を直接的には行わず、事実上、携帯端末90を介して行うことになる。
<バス運行管理システムのソフトウエア構成>
<概論>
このシステム10は、ソフトウエア構成として、バス運行管理プログラムを有する。そのバス運行管理プログラムをフェーズごとに分類して説明すると、図15には、前述の待機フェーズ判別アルゴリズムに基づく待機フェーズ判定プログラムであって携帯端末90によって実行されるモジュールと管理サーバ50によって実行されるモジュールとを含むものが概念的にフローチャートで表されている。さらに、図16には、前述の乗車フェーズ判別アルゴリズムに基づく乗車フェーズ判定プログラムであって携帯端末90によって実行されるモジュールと管理サーバ50によって実行されるモジュールとを含むものが概念的にフローチャートで表されている。さらに、図17には、前述の降車フェーズ判別アルゴリズムに基づく降車フェーズ判定プログラムであって携帯端末90によって実行されるモジュールと管理サーバ50によって実行されるモジュールとを含むものが概念的にフローチャートで表されている。
<待機フェーズ判定プログラム>
前記バス運行管理プログラムが起動されると、図15に示すように、まず、携帯端末90が、ステップS1301において、管理サーバ50へのログインのためのリクエストをユーザIDと共に管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS1351において、そのリクエストをユーザIDと共に受信し、そのユーザIDを、このシステム10の今回のユーザとしてメモリ162に登録する。続いて、管理サーバ50は、ステップS1352において、メモリ162から、図9に示すバス停発信機ID管理テーブルと、図10に示すバス内発信機ID管理テーブルと、図11に示す有効受信半径管理テーブルと、このシステム10によって集中的に管理される複数のバス12、複数のルートおよび複数のバス停14ならびに時刻表(バス別時刻表、ルート別時刻表、バス停別時刻表など)を管理するための運行管理テーブルであって図示しないものとを読み出して携帯端末90に送信する。
これに対し、携帯端末90は、ステップS1302において、それらテーブルを管理サーバ50からダウンロードし、続いて、ステップS1303において、それらテーブルをメモリ132に保存する。その後、携帯端末90は、ステップS1304において、発信元を制限することなく無差別に任意の複数の発信機30,32,34から信号を受信することを試行する。
続いて、携帯端末90は、ステップS1305を実行する。このステップは、第1ステージと、第2ステージと、第3ステージとに分類される。
第1ステージにおいては、携帯端末90が、すべてのバス停14のすべてのバス停発信機30ならびにすべてのバス12のすべてのバス内発信機32および34のうちの少なくとも一つから信号を受信したか否かを判定する。受信した場合には、携帯端末90は、その受信した各信号によって表される発信機IDから、携帯端末90がいずれかのバス停発信機30から信号を受信したか否かを判定する。受信した信号が存在する場合に、その信号が、いずれかのバス停発信機30からの信号であるか否かを判定するのである。
なお、この第1ステージにおいては、その判定結果が暫定的である。なぜなら、その受信が、前述の受信可能エリア内での受信すなわち非有効受信であるか、前述の有効受信エリアすなわち第1受信圏内での受信すなわち有効受信であるかの判別は次のステージにおいて行われるからである。
携帯端末90がいずれかのバス停発信機30から信号を受信したと判定された場合には、第2ステージにおいて、携帯端末90は、その受信した信号の強度RSSI(絶対受信強度Ia)を測定し、その強度測定値を前述のようにして距離測定値Dに変換する。
その後、第3ステージにおいて、携帯端末90は、前記受信した信号によって表される発信機IDに対応する有効受信半径rをメモリ132から読み出し、前記距離測定値Dが有効受信半径r以下である場合に、ユーザがいずれかのバス停14に位置し、よって、携帯端末90がいずれかのバス停発信機30の第1受信圏内に存在し、その結果、携帯端末90がそのいずれかのバス停発信機30から信号を有効に受信したと判定する。この判定は最終的なものである。
携帯端末90がバス停発信機30から信号を有効に受信したと判定された場合には、ステップS1305の判定がYESとなるが、それ以外の場合には、その判定がNOとなり、ステップS1304に戻る。
なお、そのステップS1304においては、発信元を特定の発信機に制限せず、無差別にいずれの発信機からの信号も携帯端末90が受信することを試行する。すなわち、無差別受信試行を行うのである。
しかし、その場合には、携帯端末90は、後述のステップS1306において、いずれかのバス停発信機30からの信号しか使用しないにもかかわらず、いずれかのバス停14に偶然にも通りかかった予定外のバス12のバス内発信機32および34からの信号も、ステップS1305において、処理対象となってしまう。
このことを防止するために、例えば、ステップS1304の実行に先立ち、標的発信機として、複数のバス停発信機30は選択するが、複数のバス内発信機32および34は選択しないようにし、そのうえで、ステップS1304において、携帯端末90が受信した信号が、標的発信機からの信号である場合に限り、その受信した信号を用いた処理をステップS1305以後のステップにおいて行わせるようにしてもよい。
このような態様でのステップS1304の受信試行は、上述の無差別受信試行との対比において、標的受信試行と称される。この標的受信試行によれば、もともと発信元が制限される通信環境においては、無差別受信試行より無駄のない信号処理が可能となる。
ただし、このような態様でのステップS1304の受信試行は、発信元の範囲が制限されるものの、すべてのバス停14のバス停発信機30が受信対象となるか、または、場合によっては、すべてのバス停14のうち、携帯端末90によって測定された現在位置の近傍に位置する複数のバス停14のバス停発信機30が受信対象となり、標的発信機が、1つとか2つとかに限定されていない。
そのため、相対的には、このような態様でのステップS1304の受信試行といえども無差別受信試行に分類されるかもしれない。しかし、すべての発信機30,32,34を受信対象とする場合と対比する限りにおいては、このような態様でのステップS1304の受信試行を標的受信試行と称しても支障はない。
ステップS1305の判定がYESである場合には、携帯端末90が、ステップS1306において、今回のバス停発信機30から受信した信号を、図9のテーブルを参照してバス停IDに変換する。
その後、携帯端末90は、ステップS1307において、ユーザが待機フェーズにあると判定し、続いて、ステップS1308において、ユーザが今回のバス停14において待機している待機フェーズにあること(例えば、バス停IDとユーザIDと待機フェーズ・フラグとの組合せ)を含む待機フェーズ情報をユーザIDに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS1353において、前記待機フェーズ情報を携帯端末90から受信し、続いて、ステップS1354において、そのときの時刻を時計172を用いて計測し、その時刻を、管理サーバ50が携帯端末90から前記待機フェーズ情報を受信した受信時刻tに割り当てる。その後、管理サーバ50は、ステップS1355において、メモリ162に割り当てられた図18に例示するユーザ別ステータス管理テーブルすなわちフェーズ履歴リスト(ユーザ時系列挙動リスト)を、受信時刻tに関連付けて、今回の待機フェーズ情報が反映されるように更新する。
携帯端末90は、ステップS1308の実行後、ステップS1309において、今回のバス停IDを、図9に示すテーブルを参照して、今回のバス停14の名称に変換し、そのバス停名を携帯端末90の画面上に表示し、それにより、ユーザが、現在、そのバス停14にいることが携帯端末90とバス停発信機30との協働作用によって認識されたことを知らされる。
その後、携帯端末90は、ステップS1310において、前記複数のルートのうち、今回のバス停14を通過するもののすべてを画面上に表示する。続いて、携帯端末90は、ステップS1310において、ユーザが目的地を入力することを支援する。その後、携帯端末90は、ステップS1312において、前記全ルートのうち、前記入力された目的地に適合するものを複数の候補ルートとして選択し、それら候補ルートを画面上に表示する。
続いて、携帯端末90は、ステップS1313において、それら候補ルートのうちいずれかをユーザが希望ルートとして選択することを支援し、その後、ステップS1314において、その選択された希望ルートを画面上に表示する。
続いて、携帯端末90は、その希望ルート上にある複数のバス停14のうち、ユーザが降車を希望するものを希望降車バス停として入力することを支援する。
本実施形態によれば、ユーザは、乗車に先立ち、希望する降車バス停を入力することを要請される。一方、希望降車バス停に関する情報は、管理サーバ50からバス内通信装置20に送信される。よって、該当するバス12の運転手は、バス12の停車が必要なバス停14を、停車直前ではなく、それより早い時刻に把握できるから、便利である。また、ユーザは、いちいち、降車に先立ち、乗車しているバス12に設置されている降車ボタンを押さずに済むため、便利である。
その後、携帯端末90は、ステップS1316において、ユーザが身体的な弱者であるなどの事情で、ユーザの乗降時にバス12の運転手による介助を必要とするか否かをユーザが入力することを支援する。
続いて、携帯端末90は、ステップS1317において、ユーザが、前記時刻表に表示されている複数の乗車時刻の中から、今回選択されたバス停14においてバス12に乗車する時刻を選択することを支援する。その後、携帯端末90は、ステップS1318において、ユーザが乗車すべきバス(以下、「希望バス」と称する。)12のバスIDを画面上に表示する。
続いて、携帯端末90は、ステップS1319において、今回のバス停発信機30を標的発信機とし、それと同じ発信機IDを標的発信機IDとして設定し、その後、ステップS1320において、標的発信機であるバス停発信機30から信号を受信することを試行する。
この試行は、前述のステップS1304におけるように信号を無差別に受信することを試行する無差別受信試行ではなく、結果的に特定の信号しか受信しない(例えば、特定の信号以外の信号を受信すると、その信号のその後の処理を停止し、その信号を処理対象から除外する)という意味において、標的受信試行と称される。
その後、携帯端末90は、ステップS1321において、今回のバス停発信機30から信号を受信したか否かを判定し、受信すると、今回のバス停発信機30に携帯端末90がタッチされた(またはかざされた)か否かを判定する。
具体的には、携帯端末90が、前記距離測定値Dが、30cm−50cmより短い基準値以下であるか否かを判定し、その基準値以下であれば、ユーザが携帯端末90で今回のバス停発信機30にタッチしたと判定する。その場合には、ステップS1321の判定がYESとなるが、それ以外の場合には、その判定がNOとなり、ステップS1320に戻る。
ステップS1321の判定がYESである場合には、携帯端末90は、ステップS1322において、今回受信した信号によって表される発信機IDをバス停IDに変換し、続いて、ステップS1323において、そのバス停IDと、前述のステップS1306において取得されたバス停IDとの間に照合が成立することを確認する。
なお、上述のステップS1320が標的受信試行を行うことから、そのステップにおいては、今回のバス停IDが唯一のバス停IDとして特定され、そのうえで、そのバス停IDを有するバス停14に設置されているバス停発信機30しか発信元として注目されないことから、後続するステップS1322およびS1323において、改めて、今回のバス停IDの取得および前述のステップS1306において取得されたバス停IDとの間の照合を行うことは不可欠ではなく、省略可能である。
その後、携帯端末90は、ステップS1324において、ユーザが今回のバス停14から希望バス12に希望乗車時刻に乗車するための乗車予約を行いことを画面上に表示する。続いて、携帯端末90は、ステップS1325において、ユーザが今回のバス停14から希望バス12に希望乗車時刻に乗車するための乗車予約を行ったこと(例えば、バス停IDとバスIDとユーザIDと乗車予約フラグとの組合せ)と、ユーザが携帯端末90でバス停発信機30にタッチしたこととを含む乗車予約情報をユーザIDに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS1356において、前記乗車予約情報を携帯端末90から受信し、続いて、ステップS1357において、そのときの時刻を時計172を用いて計測し、その時刻を、管理サーバ50が携帯端末90から前記乗車予約情報を受信した受信時刻tに割り当てる。その後、管理サーバ50は、ステップS1358において、図18に例示するユーザ別ステータス管理テーブルを、受信時刻tに関連付けて、今回の乗車予約情報が反映されるように更新する。これにより、今回のユーザにつき、希望バス12への乗車の予約が完了する。
続いて、管理サーバ50は、ステップS1359において、今回のバス12についての予約乗客数をインクリメントし、メモリ162に保存する。
その後、携帯端末90は、ステップS1360において、今回のバス停14での乗車時と希望降車バス停での降車時に運転手による介助を必要とするユーザが存在することをバス内通信装置20に送信する。これにより、そのバス12の運転手は、介助の要否を知らされる。
<乗車フェーズ判定プログラム>
上述の待機フェーズ判定プログラムの実行が終了すると、図16に示すように、まず、携帯端末90が、ステップS1401において、今回のバス停14のバス停発信機30の発信機IDと、今回の希望バス12の乗車口発信機32の発信機IDとをそれぞれ、標的発信機IDとして設定する。
次に、携帯端末90は、ステップS1402において、今回のバス停発信機30および今回の乗車口発信機32をそれぞれ標的発信機として、それら2つの発信機30および32からそれぞれ信号を受信することを試行する。標的受信試行を行うのである。
続いて、携帯端末90は、ステップS1403において、今回の標的であるバス停発信機30と、今回の標的である乗車口発信機32との双方から信号を同時に有効に受信したか否かを判定する。
具体的には、携帯端末90は、今回のバス停発信機30から受信した信号の受信強度RSSIに基づいて計算された距離測定値Dが、そのバス停発信機30に対応する有効受信半径以下であれば、今回のバス停発信機30から信号を有効に受信したと判定する。
さらに、携帯端末90は、今回の乗車口発信機32から信号を受信し、かつ、その受信した信号に基づいて計算された距離測定値Dが、その乗車口発信機32に対応する有効受信半径以下であれば、今回の乗車口発信機32から信号を有効に受信したと判定する。
このステップS1403において、携帯端末90が、今回の標的であるバス停発信機30と、今回の標的である乗車口発信機32との双方から信号を同時に有効に受信したと判定すれば、その判定がYESとなり、ステップS1404に移行し、そうではなければ、判定がNOとなり、ステップS1402に戻る。
ステップS1404においては、携帯端末90が、ユーザが乗車フェーズにあると判定し、続いて、ステップS1405において、ユーザが乗車開始段階にあると判定する。その後、携帯端末90は、ステップS1406において、バス停発信機30から有効に受信した信号によって表される発信機IDをバス停IDに変換し、さらに、乗車口発信機32から有効に受信した信号によって表される発信機IDをバスIDに変換する。
その後、携帯端末90は、ステップS1407において、バス停IDとバスIDとを互いに紐付けし、同じ物理空間上で今回のユーザと今回のバス停14と今回のバス12とが互いに関連付けられたと判定する。続いて、携帯端末90は、ステップS1408において、ユーザが特定のバス停14において特定のバス12に乗車する乗車フェーズにあること(例えば、バス停IDとバスIDとユーザIDと乗車フェーズ・フラグとの組合せ)と、それら紐付けされたバス停IDとバスIDとの組合せ(紐付け情報)と、ユーザが携帯端末90で乗車口発信機32にタッチしたこととを含む乗車フェーズ情報をユーザIDに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS1451において、前記乗車フェーズ情報を携帯端末90から受信し、続いて、ステップS1452において、そのときの時刻を時計172を用いて計測し、その時刻を、管理サーバ50が携帯端末90から前記乗車フェーズ情報(前記紐付け情報を含む)を受信した受信時刻tに割り当てる。その後、管理サーバ50は、ステップS1453において、メモリ162に割り当てられた図18に例示するユーザ別ステータス管理テーブルを、受信時刻tに関連付けて、今回の乗車フェーズ情報が反映されるように更新する。
携帯端末90は、ステップS1408の実行後、ステップS1409において、今回のバスIDを、図10に示すテーブルを参照して、今回のバス12の番号(または名称、記号)に変換し、そのバス番号を携帯端末90の画面上に表示し、それにより、ユーザが、現在、そのバス12に乗車していることが携帯端末90と乗車口発信機32との協働作用によって認識されたことを知らされる。
その後、携帯端末90は、ステップS1410において、そのバス番号を有するバス12が、今回のユーザにとっての希望バスであるか否かを判定する。特別な事情がない限り、この判定はYESとなる。続いて、携帯端末90は、ステップS1411において、ユーザに対し、携帯端末90が有効に受信した信号を発信した乗車口発信機32が設置されているバス12、すなわち、今回のバス停14に停車していると推定されるバス12に乗車することを促進するためのメッセージ(例えば、「このバスにご乗車下さい。」)を画面上に表示する。
その後、携帯端末90は、ステップS1412において、今回の乗車口発信機32の発信機IDを標的発信機IDとして設定する。続いて、携帯端末90は、ステップS1413において、今回の乗車口発信機32を標的発信機として、その発信機32から信号を受信することを試行する。標的受信試行を行うのである。
その後、携帯端末90は、ステップS1414において、今回の乗車口発信機32から信号を受信したか否かを判定し、受信すると、今回の乗車口発信機32に携帯端末90がタッチされた(またはかざされた)か否かを判定する。
具体的には、携帯端末90が、前記距離測定値Dが、30cm−50cmより短い基準値以下であるか否かを判定し、その基準値以下であれば、ユーザが携帯端末90で今回の乗車口発信機32にタッチしたと判定する。その場合には、ステップS1414の判定がYESとなるが、それ以外の場合には、その判定がNOとなり、ステップS1413に戻る。
その後、携帯端末90は、ステップS1415において、ユーザの希望バス12への乗車が完了したと判定し、続いて、ステップS1416において、ユーザが希望バス12への乗車が完了したこと(例えば、バスIDとユーザIDと乗車完了フラグとの組合せ)とユーザが携帯端末90で乗車口発信機32にタッチしたこととを含む乗車完了情報をユーザIDに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS1454において、前記乗車完了情報を携帯端末90から受信し、続いて、ステップS1455において、そのときの時刻を時計172を用いて計測し、その時刻を、管理サーバ50が携帯端末90から前記乗車完了情報を受信した受信時刻tに割り当てる。その後、管理サーバ50は、ステップS1456において、メモリ162に割り当てられた図18に例示するユーザ別ステータス管理テーブルを、受信時刻tに関連付けて、今回の乗車完了情報が反映されるように更新する。
続いて、管理サーバ50は、ステップS1457において、受信時刻tをユーザの実際の乗車時刻としてメモリ162に登録し、その後、ステップS1458において、今回のバス12についての実乗客数をインクリメントし、メモリ162に保存する。
<降車フェーズ判定プログラム>
上述の乗車フェーズ判定プログラムの実行が終了すると、図17に示すように、まず、携帯端末90が、ステップS1501において、今回のバス12の降車口発信機34の発信機IDを唯一の標的発信機IDとして設定する。
次に、携帯端末90は、ステップS1502において、今回の降車口発信機34を標的発信機として、その発信機34から信号を受信することを試行する。標的受信試行を行うのである。
続いて、携帯端末90は、ステップS1503において、今回の標的である降車口発信機34から信号を有効に受信したか否かを判定する。
具体的には、携帯端末90は、今回の降車口発信機34から受信した信号の受信強度RSSIに基づいて計算された距離測定値Dが、その降車口発信機34に対応する有効受信半径以下であれば、今回の降車口発信機34から信号を有効に受信したと判定する。
このステップS1503において、携帯端末90が、今回の標的である降車口発信機34から信号を有効に受信したと判定すれば、その判定がYESとなり、ステップS1504に移行し、そうではなければ、判定がNOとなり、ステップS1502に戻る。
ステップS1504においては、携帯端末90が、降車口発信機34から受信した信号の受信強度RSSIを測定し、続いて、ステップS1505において、受信強度RSSIの今回測定値が前回測定値より低いか否かを判定する。ここに、受信強度RSSIが時間と共に低下するという現象は、受信信号の動特性の一例であり、また、前述の「時間的変化特性」の一例である。その現象は、例えば、ユーザが降車口発信機34から遠ざかる向きに移動していることを反映したものであると推定することが可能である。
受信強度RSSIの今回測定値が前回測定値より低くはない場合には、その判定がNOとなり、ステップS1502に戻るが、受信強度RSSIの今回測定値が前回測定値より低い場合には、その判定がYESとなり、ステップS1506に移行する。
そのステップS1506においては、携帯端末90が、今回の希望降車バス停14のバス停発信機30の発信機IDと、今回のバス12の降車口発信機34の発信機IDとを、2つの標的発信機IDとして設定する。
その後、携帯端末90は、ステップS1507において、今回のバス停発信機30および今回の降車口発信機34をそれぞれ標的発信機として、それら2つの発信機30および34からそれぞれ信号を受信することを試行する。標的受信試行を行うのである。
続いて、携帯端末90は、ステップS1508において、今回の標的であるバス停発信機30と、今回の標的である降車口発信機34との双方から信号を同時に有効に受信したか否かを判定する。
具体的には、携帯端末90は、今回のバス停発信機30から受信した信号の受信強度RSSIに基づいて計算された距離測定値Dが、そのバス停発信機30に対応する有効受信半径以下であれば、今回のバス停発信機30から信号を有効に受信したと判定する。
さらに、携帯端末90は、今回の降車口発信機34から受信した信号に基づいて計算された距離測定値Dが、その降車口発信機34に対応する有効受信半径以下であれば、今回の降車口発信機34から信号を有効に受信したと判定する。
このステップS1508において、携帯端末90が、今回の標的であるバス停発信機30と、今回の標的である降車口発信機34との双方から信号を同時に有効に受信したと判定すれば、その判定がYESとなり、ステップS1509に移行し、そうではなければ、判定がNOとなり、ステップS1507に戻る。
ステップS1509においては、携帯端末90が、ユーザが降車フェーズにあると判定し、続いて、ステップS1510において、ユーザが降車開始段階にあると判定する。その後、携帯端末90は、ステップS1511において、バス停発信機30から有効に受信した信号によって表される発信機IDをバス停IDに変換し、さらに、降車口発信機34から有効に受信した信号によって表される発信機IDをバスIDに変換する。
その後、携帯端末90は、ステップS1512において、バス停IDとバスIDとを互いに紐付けし、同じ物理空間上で今回のユーザと今回のバス停14と今回のバス12とが互いに関連付けられたと判定する。続いて、携帯端末90は、ステップS1513において、ユーザが特定のバス停14において特定のバス12から降車する降車フェーズにあること(例えば、バス停IDとバスIDとユーザIDと降車フェーズ・フラグとの組合せ)と、それら紐付けされたバス停IDとバスIDとの組合せ(紐付け情報)とを含む降車フェーズ情報をユーザIDに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS1551において、前記降車フェーズ情報を携帯端末90から受信し、続いて、ステップS1552において、そのときの時刻を時計172を用いて計測し、その時刻を、管理サーバ50が携帯端末90から前記降車フェーズ情報(前記紐付け情報を含む)を受信した受信時刻tに割り当てる。その後、管理サーバ50は、ステップS1553において、メモリ162に割り当てられた図18に例示するユーザ別ステータス管理テーブルを、受信時刻tに関連付けて、今回の降車フェーズ情報が反映されるように更新する。
携帯端末90は、ステップS1513の実行後、ステップS1514において、今回のバス停IDを、図9に示すテーブルを参照して、今回のバス停14の名称に変換し、その名称を携帯端末90の画面上に表示し、それにより、ユーザが、現在、そのバス停14に降りたことが携帯端末90と降車口発信機34との協働作用によって認識されたことを知らされる。
その後、携帯端末90は、ステップS1515において、その名称を有するバス停14が、今回のユーザにとっての希望降車バス停であるか否かを判定する。特別な事情がない限り、この判定はYESとなる。続いて、携帯端末90は、ステップS1516において、ユーザに対し、携帯端末90が有効に受信した信号を発信したバス停発信機30が設置されているバス停14、すなわち、今回のバス12から、そのバス12が停車してていると推定されるバス停14に降りることを促進するためのメッセージ(例えば、「このバス停で降りて下さい。」)を画面上に表示する。
その後、携帯端末90は、ステップS1517において、今回のバス停発信機30の発信機IDを標的発信機IDとして設定する。続いて、携帯端末90は、ステップS1518において、今回のバス停発信機30を標的発信機として、その発信機30から信号を受信することを試行する。標的受信試行を行うのである。
その後、携帯端末90は、ステップS1519において、前述のステップS1503と同様にして、今回のバス停発信機30から信号を有効に受信したか否かを判定する。有効に受信した場合には、その判定がYESとなり、ステップS1518に戻るが、有効に受信なかった場合には、その判定がNOとなり、ステップS1520に移行する。
そのステップS1520においては、携帯端末90が、ユーザの希望バス12からの降車が完了したと判定し、続いて、ステップS1521において、ユーザが希望バス12からの降車が完了したこと(例えば、バスIDとユーザIDと降車完了フラグとの組合せ)を含む降車完了情報をユーザIDに関連付けて管理サーバ50に送信する。
これに対し、管理サーバ50は、ステップS1554において、前記降車完了情報を携帯端末90から受信し、続いて、ステップS1555において、そのときの時刻を時計172を用いて計測し、その時刻を、管理サーバ50が携帯端末90から前記乗車完了情報を受信した受信時刻tに割り当てる。その後、管理サーバ50は、ステップS1556において、メモリ162に割り当てられた図18に例示するユーザ別ステータス管理テーブルを、受信時刻tに関連付けて、今回の降車完了情報が反映されるように更新する。
続いて、管理サーバ50は、ステップS1557において、受信時刻tをユーザの実際の降車時刻としてメモリ162に登録し、その後、ステップS1558において、今回のバス12についての実乗客数をデクリメントし、メモリ162に保存する。
以上の説明から明らかなように、本実施形態においては、図4に示すように、バス12がバス停14に停車すると、乗車口発信機32の第2受信圏がバス停発信機30の第1受信圏に部分的にオーバーラップするようになっており、それを前提に、携帯端末90が、バス停発信機30と乗車口発信機32との双方から信号を受信する状態が検知されると、あるバス停14にあるバス12が停車しており、かつ、それらバス停14およびバス12の近傍にユーザが居ると判定される。
このように、本実施形態においては、ユーザの位置と、バス停14の位置と、バス12の位置とが、同じ空間ないしは場所を同時に共有する(バス停発信機30とバス内発信機32,34とのそれぞれの信号処理がほぼ同時に(例えば、プロセッサ130の処理速度からして、通常、数十ms以内で)行われるという観点から、場所的にないしは幾何学的に互いに関連付けられる。
これに代えて、乗車口発信機32の第2受信圏がバス停発信機30の第1受信圏にオーバーラップしないようになっており、それを前提に、携帯端末90が、バス停発信機30のみから信号を有効に受信する状態から、乗車口発信機32のみから信号を有効に受信する状態に、実質的な時間の隔たりを経ずに(例えば、人間の歩行速度からして、1秒以内とか0.5秒以内で)遷移すると、あるバス停14にあるバス12が停車しており、かつ、それらバス停14およびバス12の近傍にユーザが居ると判定する態様で本発明を実施してもよい。
この態様においては、ユーザの位置と、バス停14の位置と、バス12の位置とが、同じ時間ないしは時刻を共有するという観点から、場所的にないしは幾何学的に互いに関連付けられる。
また、本実施形態においては、図5に示すように、バス12がバス停14に停車すると、降車口発信機34の第3受信圏が部分的にバス停発信機30の第1受信圏にオーバーラップするようになっており、それを前提に、携帯端末90が、バス停発信機30と降車口発信機34との双方から信号を受信する状態から、降車口発信機34からの信号を支配的に受信する状態(または、降車口発信機34をバス停発信機30より高い強度で受信する状態)に遷移すると、ユーザがバス12から降車したと判定される。
これに代えて、降車口発信機34の第3受信圏がバス停発信機30の第1受信圏にオーバーラップしないようになっており、それを前提に、携帯端末90が、降車口発信機34のみから信号を有効に受信する状態から、バス停発信機30のみから信号を有効に受信する状態に遷移すると、ユーザがバス12から降車したと判定する態様で本発明を実施してもよい。
<バス料金の決済方法>
このシステム10においては、バス料金の決済方法として前払いと後払いとがある。前払いの場合には、定額制が採用されるのに対し、後払いの場合には、従量制(例えば、運行経路の距離)が採用される。
前払いの場合には、このシステム10においては、例えば、前記乗車完了が判定されたとき、または、ユーザがバス内発信機32または34に携帯端末90をタッチさせるかもしくはかざしたときに、携帯端末90を介して、図示しない決済サーバにログインして、必要な額のバス料金が電子決済される。
これに対し、後払いの場合には、このシステム10においては、例えば、前記降車完了が判定されたとき、または、ユーザがバス内発信機32または34に携帯端末90をタッチさせるかもしくはかざしたときに、携帯端末90を介して、図示しない決済サーバにログインして、必要な額のバス料金が電子決済される。
<システムの副次的な複数の機能>
図19には、このシステム10において、携帯端末90の画面上に表示される複数の仮想的なボタン300,302,304,306であって、複数の副次的な機能をユーザが選択して起動させためにユーザによって選択して操作されるものの一例が概念的に表されている。
1.バス運行状況案内サービス300
このサービスによれば、ユーザが注目しているバス12の運行状況が携帯端末90を介してユーザにリアルタイムで案内される。例えば、携帯端末90の画面上に表示されている地図上において、複数の運行中のバス12のうちのいずれかがユーザによって選択されると、その選択されたバス12の運行状況(各バス停14への到着予測時刻、そのバス14の予想乗車率または乗車人数)がユーザに案内される。
2.バス現在地追跡サービス302
このサービスによれば、運行中のバス12の現在地が携帯端末90を介してユーザにリアルタイムで案内される。例えば、運行中のバス12であってユーザが乗車予定のものの現在地が携帯端末90の画面上に案内されるとともに、ユーザが待機しているバス停14への到着予想時刻が携帯端末90の画面上に案内される。
3.バス乗車率変動予測サービス304
このサービスをユーザに提供するために、管理サーバ50は、バス12ごとに、かつ、各バス停14ごとに、かつ、時間離散的に、予約乗客数(予想乗車乗客数)Xから、同じ希望降車バス停を希望するユーザの総数(予想降車乗客数)Yを引き算することにより、各バス停14からバス12が発車する時点でのそのバス12の瞬間乗客数の予想値をリアルタイムで計算する。
さらに、管理サーバ50は、携帯端末90から、バス乗車率変動予測リクエストを受信すると、その携帯端末90に、選択したバス12についての複数のバス停14のそれぞれにおける予想瞬間乗客数またはそれを最大バス乗客数で割り算した予想瞬間乗車率を表すバス混雑度データを送信する。
そのバス混雑度データを受信した携帯端末90は、そのバス混雑度データを画面上に表示し、よって、ユーザは、バス12を選択する前、希望降車バス停を選択する前、またはバス12のルートを選択する前に、バス12の混雑度を知り、それを踏まえて、混雑度の低いバス12を選択することが支援される。
4.最適バス選択支援サービス306
このサービスによれば、ユーザの要望に応じて最適なバス・ルートが自動的に選択される。例えば、ユーザが、現在地と、希望到着時刻と、最終目的地とを携帯端末90に入力すると、最適なバス・ルートと、最適なバス12と、最適なバス停14と、現在地から最適バス停14までの所要時間と、最適バス停14から最終目的地までの所要時間とが携帯端末90を介して案内される。最適バス停14を表すアイコンを携帯端末90の画面上でユーザがクリックすると、その最適バス停14に停車する予定のバス12の運行状況が案内される。
<発信機故障時バックアップ機能>
このシステム10においては、発信機故障時バックアップ機能が携帯端末90と管理サーバ50との協働によって実現される。具体的には、各発信機30,32,34の故障の有無を診断し、故障があると診断すると、故障している発信機30,32,34を用いずに、携帯端末90のみを用いて、ユーザが居るバス停14またはユーザが乗車しているバス12を識別する。
さらに具体的には、このシステム10においては、携帯端末90が、(a)自身の現在位置をユーザの現在位置として測定する測位部を有する。その測位部は、例えば、GPS受信機152を用いるGPS測位部か、携帯端末90が中継基地局として用いる複数の地上基地局からの位置信号を用いる測位部である。
携帯端末90は、さらに、(b)各バス停発信機30および/または各バス発信機32,34の故障の有無を診断し、その識別結果を管理サーバ50に送信する故障診断部を有する。
一例においては、その故障診断部が、前記測位部によって測定された現在位置にいずれかの発信機30,32,34が設置されていることが既知であり、各発信機30,32,34の設置位置を表す空間座標値と各発信機30,32,34の発信機IDとの間に予め定められている関係が管理サーバ50のメモリ162および/または携帯端末90のメモリ132に保存されているところ、その関係に従い、測定された現在位置から、その現在位置に設置されているはずであるいずれの発信機30,32,34を識別し、そのいずれの発信機30,32,34から信号を携帯端末90が受信しない場合に、そのいずれかの発信機30,32,34が故障している(例えば、電池106の残量不足、発信機30,32,34自体の故障など)と診断し、その診断結果を管理サーバ50に送信する。
この例において、携帯端末90がいずれの発信機30,32,34から信号を受信するか否かの判定は、例えば、携帯端末90による診断可能エリアを拡大するために、前述の最大受信半径を前記基準値として用いて行ってもよいし、それに代えて、携帯端末90と診断対象発信機30,32,34との間の信号経路が他の物体によって邪魔される可能性を低下させて携帯端末90による診断精度を向上させるために、前述の最大受信半径より短い前述の有効受信半径を前記基準値として用いて行ってもよい。
携帯端末90は、さらに、(c)前記測位部によって測定されたユーザの現在位置および/または携帯端末90の速度取得部(例えば、測定された地理的位置(空間座標値x,y,z)の時間微分を計算する部分)もしくは加速度取得部(例えば、加速度センサ154)によって取得されたユーザの速度もしくは加速度を用いて、ユーザの行動を、ユーザがいずれかのバス停14において静止しているのかまたは歩行している(速度測定値が速度基準値以下および/または加速度測定値が加速度基準値以上である)のか、ユーザが走行中のいずれかのバス12に乗車していてそのバス12と共に走行している(速度測定値が前記速度基準値より大きいおよび/または加速度測定値が前記加速度基準値より小さい)のかを推定するユーザ行動推定部を有する。
携帯端末90は、さらに、(d)いずれかのバス停発信機30が故障していると診断すると、測定されたユーザの現在位置と、前記推定されたユーザの行動とから、ユーザが居るバス停14を識別し、その識別結果を管理サーバ50に送信する故障時バス停識別部を有する。
携帯端末90は、さらに、(e)いずれかのバス発信機32,34が故障していると診断すると、測定されたユーザの現在位置と、前記推定されたユーザの行動とから、ユーザが乗車しているバス12を識別し、その識別結果を管理サーバ50に送信する故障時バス識別部とを含むように構成される。
なお付言するに、本実施形態においては、各バス停14が、地上において特定の位置に固定的に設置された建物として構成され、その建物にバス停発信機30が装着されている。
これに代えて、各バス停14が、地上において特定の位置に固定的に設置されたポールまたはスタンドとして構成され、そのポールまたはスタンドにているバス停発信機30が装着される態様で本発明を実施してもよい。
さらに付言するに、本実施形態においては、ユーザが、いずれかのバス停14において、バス停発信機30に携帯端末90でタッチするかまたは携帯端末90をかざすというように、そのバス停発信機30の近傍に位置することを条件に、乗車予約およびバス12への乗車が許可される。
これに代えて、ユーザが、いずれかのバス停14において、バス停発信機30の前述の受信可能エリア内の任意の位置に到着すれば、バス停発信機30に接近しなくても、乗車予約およびバス12への乗車が許可される態様で本発明を実施してもよい。
この態様においては、バス12が、規定された位置であってバス停発信機30に近接する位置に停車するか、または、今回のユーザが待機している位置に停車する態様で本発明を実施してもよい。
さらに付言するに、本実施形態においては、複数のバス停14が通常の間隔(例えば、バス12が約10−20分走行する場合に経過する距離に等しい間隔)を隔てて道路に沿って並んで存在し、その結果、複数のバス停発信機30が通常の間隔を隔てて道路に沿って並んで存在する。
これに代えて、複数のバス停14が通常の間隔より短い間隔、例えば、バス停発信機30の受信可能半径の約1−2倍に等しい距離を隔てて道路に沿って並んで存在し、その結果、複数のバス停発信機30がバス停発信機30の受信可能半径の約1−2倍に等しい距離を隔てて道路に沿って並んで存在する態様で本発明を実施してもよい。
さらに付言すれば、本実施形態においては、各バス停14が常設の停車場(常時、停車場として機能し、バス12が停車する)として構成されている。
これに代えて、各バス停14が臨時の停車場(あるときには停車場として機能するが、別のときには停車場として機能せず、そのときにはバス12が停車しない)として構成され、具体的には、各バス停14が、いずれかのユーザの潜在的な出発地または目的地(例えば、個人宅、共同住宅、集合住宅などの居宅、病院、学校、空港、公共施設、商業施設など)に設置される態様で本発明を実施してもよい。
この態様においては、例えば、ユーザがは、自宅を出発地として指定すれば、その場所にバス12が到着し、さらに、他人の居宅、特定の病院、学校、空港、公共施設、商業施設などを目的地として指定すれば、その場所にバス12が到着する。
さらに付言すれば、本実施形態においては、各バス停14が専用の建物として構成されている。
これに代えて、各バス停14が、例えば公営または民間の駐車場のように、複数人のユーザが一か所に集合して待機できる場所であってバス停14を兼ねるものとして構成される態様で本発明を実施してもよい。
さらに付言すれば、本実施形態においては、各バス12が、運転手によって操縦される有人車両の一例として構成されている。
これに代えて、各バス12が、自動運転される無人車両の一例として構成される態様で本発明を実施してもよい。
さらに付言するに、図示されている本実施形態は、本発明を、バス12の運行管理という用途に適用したものであるが、他の交通機関の運行管理に適用したり、他の車両の運行管理という用途に適用することが可能である。
さらに付言するに、本実施形態において、携帯端末90において実行されていた処理の全部または一部をその代わりに管理サーバ50において実行してもよいし、逆に、管理サーバ50において実行されていた処理の全部または一部をその代わりに携帯端末90において実行してもよい。実行されるべき処理がいずれのデバイスで実行されるのかは、そのときの事情、例えば、取り扱われるデータの量や種類、各デバイスの処理速度および記憶容量などによって決まるのが通常であるからである。
以上、本発明の例示的な実施の形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、前記[発明の概要]の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
その課題を解決するために、本発明の一側面によれば、乗客運送用の複数台の車両の運行を管理するシステムであって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置され、固有の停車場発信機IDを表す停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機であって、前記通信端末によって設定される第1受信圏であって前記通信端末が当該停車場発信機から前記停車場信号を有効に受信できる範囲であるものを有するものと、
各車両内に設置され、固有の車両発信機IDを表す車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機であって、前記通信端末によって設定される第2受信圏であって前記通信端末が当該車両発信機から前記車両信号を有効に受信できる範囲であるものを有するものと、
前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
を含み、
前記通信端末は、前記第1受信圏および前記第2受信圏のそれぞれのサイズを、前記車両がいずれかの停車場に到着すると、前記車両の前記車両発信機の前記第1受信圏と前記いずれかの停車場の前記停車場発信機の前記第2受信圏とが少なくとも部分的に互いにオーバーラップするように設定し、
前記通信端末は、前記車両発信機および前記停車場発信機の各々から信号を、当該通信端末と各発信機との間の距離が増加するにつれて低下する受信強度で受信し、
前記通信端末は、前記車両発信機と前記停車場発信機とからそれぞれの信号を同時に受信すると、当該通信端末が前記車両発信機から受信した車両信号によって表される車両発信機IDから前記車両を特定する一方、当該通信端末が前記停車場発信機から受信した停車場信号によって表される停車場発信機IDから前記停車場を特定し、さらに、当該通信端末が前記車両発信機および/または前記停車場発信機から受信した信号の受信強度の時間的変化の向きに基づき、前記車両および/または前記停車場に対するユーザの相対的な挙動フェーズを推定し、その挙動フェーズを前記管理サーバに送信する挙動フェーズ推定部を含む車両運行管理システムが提供される。
本発明によって下記の各態様が得られる。各態様は、項に区分し、各項には番号を付し、必要に応じて他の項の番号を引用する形式で記載する。これは、本発明が採用し得る技術的特徴の一部およびそれの組合せの理解を容易にするためであり、本発明が採用し得る技術的特徴およびそれの組合せが以下の態様に限定されると解釈すべきではない。すなわち、下記の態様には記載されていないが本明細書には記載されている技術的特徴を本発明の技術的特徴として適宜抽出して採用することは妨げられないと解釈すべきなのである。
その課題を解決するために、本発明の一側面によれば、乗客運送用の複数台の車両の運行を管理するシステムであって、
いずれかの車両の乗客となる可能性があるユーザの通信端末と、
各車両のための各停車場に設置され、固有の停車場発信機IDを表す停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機であって、前記通信端末によって設定される第1受信圏であって前記通信端末が当該停車場発信機から前記停車場信号を有効に受信できる範囲であるものを有するものと、
各車両内に設置され、固有の車両発信機IDを表す車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機であって、前記通信端末によって設定される第2受信圏であって前記通信端末が当該車両発信機から前記車両信号を有効に受信できる範囲であるものを有するものと、
前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
を含み、
前記通信端末は、前記第1受信圏および前記第2受信圏のそれぞれのサイズを、前記車両がいずれかの停車場に到着すると、前記車両の前記車両発信機の前記第受信圏と前記いずれかの停車場の前記停車場発信機の前記第受信圏とが少なくとも部分的に互いにオーバーラップするように設定し、
前記通信端末は、前記車両発信機および前記停車場発信機の各々から信号を、当該通信端末と各発信機との間の距離が増加するにつれて低下する受信強度で受信し、
前記通信端末は、前記車両発信機と前記停車場発信機とからそれぞれの信号を同時に受信すると、当該通信端末が前記車両発信機から受信した車両信号によって表される車両発信機IDから前記車両を特定する一方、当該通信端末が前記停車場発信機から受信した停車場信号によって表される停車場発信機IDから前記停車場を特定し、さらに、当該通信端末が前記車両発信機および/または前記停車場発信機から受信した信号の受信強度の時間的変化の向きに基づき、前記車両および/または前記停車場に対するユーザの相対的な挙動フェーズを推定し、その挙動フェーズを前記管理サーバに送信する挙動フェーズ推定部を含む車両運行管理システムが提供される。
本発明によって下記の各態様が得られる。各態様は、項に区分し、各項には番号を付し、必要に応じて他の項の番号を引用する形式で記載する。これは、本発明が採用し得る技術的特徴の一部およびそれの組合せの理解を容易にするためであり、本発明が採用し得る技術的特徴およびそれの組合せが以下の態様に限定されると解釈すべきではない。すなわち、下記の態様には記載されていないが本明細書には記載されている技術的特徴を本発明の技術的特徴として適宜抽出して採用することは妨げられないと解釈すべきなのである。

Claims (16)

  1. 乗客運送用の複数台の車両の運行を管理するシステムであって、
    いずれかの車両の乗客となる可能性があるユーザの通信端末と、
    各車両のための各停車場に設置され、固有の停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機と、
    各車両内に設置され、固有の車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機と、
    前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
    を含み、
    前記通信端末は、
    いずれかの停車場発信機から停車場信号を受信すると、その停車場信号に基づき、前記いずれかの停車場発信機が設置されているいずれかの停車場を識別し、その識別結果を前記管理サーバに送信する停車場識別部と、
    いずれかの車両発信機から車両信号を受信すると、その車両信号に基づき、前記いずれかの車両発信機が設置されているいずれかの車両を識別し、その識別結果を前記管理サーバに送信する車両識別部と、
    いずれかの停車場発信機といずれかの車両発信機との双方から信号を同時に受信すると、現在、前記いずれかの停車場発信機が設置されているいずれかの停車場に、前記いずれかの車両発信機が設置されているいずれかの車両が停車しており、かつ、それら停車場および車両の近傍にユーザが位置すると判定し、その判定結果を前記管理サーバに送信する停車判定部と
    を含み、
    前記管理サーバは、前記通信端末から前記判定結果を受信すると、その受信時刻に関連付けて、前記受信した判定結果をメモリに保存する保存部を含む車両運行管理システム。
  2. 乗客運送用の複数台の車両の運行を管理するシステムであって、
    いずれかの車両の乗客となる可能性があるユーザの通信端末と、
    各車両のための各停車場に設置され、固有の停車場信号を近距離無線通信方式で発信する少なくとも1個の停車場発信機と、
    各車両内に設置され、固有の車両信号を近距離無線通信方式で発信する少なくとも1個の車両発信機と、
    前記複数台の車両の運行を集中的に管理するために使用される管理サーバと
    を含み、
    前記通信端末は、
    いずれかの停車場発信機から停車場信号を受信すると、その停車場信号に基づき、前記いずれかの停車場発信機が設置されているいずれかの停車場を識別する停車場識別部と、
    いずれかの車両発信機から車両信号を受信すると、その車両信号に基づき、前記いずれかの車両発信機が設置されているいずれかの車両を識別する車両識別部と、
    前記いずれかの停車場発信機から停車場信号を受信し、かつ、前記いずれかの車両発信機から車両信号を受信すると、それら信号に基づき、前記識別された停車場と前記識別された車両とが同じ空間および/または同じ時間を共有するか否かを判定し、共有する場合には、前記識別された停車場と前記識別された車両とを互いに紐付けし、その紐付け情報を前記管理サーバに送信する紐付け部と、
    前記いずれかの停車場発信機から受信した停車場信号と前記いずれかの車両発信機から受信した車両信号と前記紐付け情報とに基づき、前記識別された停車場と前記識別された車両とを含む車両運行設備および/またはユーザのステータスを推定し、そのステータス情報を前記管理サーバに送信するステータス推定部と
    を含み、
    前記管理サーバは、前記通信端末から前記紐付け情報および/または前記ステータス情報を受信すると、その受信時刻に関連付けて、受信した情報をメモリに保存する保存部を含む車両運行管理システム。
  3. 前記ステータス推定部は、各時刻ごとの前記通信端末の停車場信号および車両信号のそれぞれの受信の有無と、各時刻ごとの前記通信端末の停車場信号および車両信号のそれぞれの受信強度と、前記通信端末の停車場信号および車両信号のそれぞれの受信強度の時間的変化特性とのうちの少なくとも一つに基づき、前記車両運行設備に対する相対的なユーザの位置とユーザの挙動フェーズとユーザの移動速度とのうちの少なくとも一つを含むユーザのステータスを推定する請求項2に記載の車両運行管理システム。
  4. 前記ユーザのフェーズは、ユーザがいずれかの停車場で待機する待機フェーズと、ユーザがいずれかの車両に乗車する乗車フェーズと、ユーザがいずれかの車両から降車する降車フェーズとのうちの少なくとも二つに分類される請求項3に記載の車両運行管理システム。
  5. 前記通信端末が前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および第2受信圏のサイズが、互いに異なるように設定される請求項1ないし4のいずれかに記載の車両運行管理システム。
  6. 前記通信端末は、その通信端末が前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および第2受信圏のサイズを、発信元が停車場発信機であるか車両発信機であるかに応じて変更するために、有効受信の有無を判定するための実際受信強度または実際受信距離の基準値を、発信元が停車場発信機であるか車両発信機であるかに応じて変更する請求項1ないし5のいずれかに記載の車両運行管理システム。
  7. 前記通信端末は、前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および前記第2受信圏のサイズを、前記車両が前記停車場に停車する状態で、前記第1受信圏および第2受信圏が少なくとも部分的に互いにオーバーラップするように設定する請求項1ないし6のいずれかに記載の車両運行管理システム。
  8. 前記通信端末は、前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および前記第2受信圏のサイズを、前記車両が前記停車場に停車する状態で、前記第1受信圏および第2受信圏が少なくとも部分的に互いにオーバーラップするように設定し、
    前記紐付け部は、前記通信端末がいずれかの停車場に設置されている停車場発信機といずれかの車両に設置されている車両発信機との双方から停車場信号および車両信号を同時に有効に受信すると、前記いずれかの停車場発信機から受信した停車場信号によって表される停車場IDであって今回の停車場を表すものと、前記いずれかの車両発信機から受信した車両信号によって表される車両IDであって今回の車両を表すものとを互いに紐付けする請求項2に記載の車両運行管理システム。
  9. 前記ステータス推定部は、ユーザが、いずれかの停車場に設置された停車場発信機に前記通信端末でタッチするかまたは前記通信端末をかざすと、ユーザが、そのいずれかの停車場に到着する予定の車両に乗車するための予約を行い、その乗車予約を前記管理サーバに送信する乗車予約部を含む請求項2に記載の車両運行管理システム。
  10. 前記ステータス推定部は、ユーザが、いずれかの車両に設置されている車両発信機に前記通信端末でタッチするかまたは前記通信端末をかざすと、ユーザが、そのいずれかの車両への乗車を完了したと判定し、その判定結果を前記管理サーバに送信する乗車完了判定部を含む請求項2に記載の車両運行管理システム。
  11. 前記通信端末は、前記停車場発信機および前記車両発信機からそれぞれ停車場信号および車両信号を有効に受信できる範囲である第1受信圏および前記第2受信圏のサイズを、前記車両が前記停車場に停車する状態で、前記第1受信圏および第2受信圏が少なくとも部分的に互いにオーバーラップするように設定し、
    前記ステータス推定部は、
    前記通信端末が、いずれかの停車場に設置されている停車場発信機といずれかの車両に設置されている車両発信機との双方から停車場信号および車両信号を同時に有効に受信する状態を少なくとも一時的に経験することを条件に、前記いずれかの車両発信機から車両信号を前記いずれの停車場発信機より支配的に有効に受信するかまたは前記いずれかの車両発信機から有効に受信した車両信号の強度が漸減する状態から、前記いずれかの停車場発信機から有効に受信した停車場信号を前記いずれかの車両発信機より支配的に有効に受信する状態に遷移すると、ユーザが、前記いずれかの停車場発信機から有効に受信した停車場信号によって表される停車場IDによって認識される今回の停車場において、前記いずれかの車両発信機から有効に受信した車両信号によって表される車両IDによって認識される今回の車両から降車する降車フェーズにあると判定し、その判定結果を前記管理サーバに送信する降車判定部と、
    前記今回の停車場をユーザの実際の降車停車場として認識し、その降車停車場を前記管理サーバに送信する降車停車場認識部と
    を含む請求項2に記載の車両運行管理システム。
  12. 前記車両は、乗合バス、貸切りバス、乗合タクシー、貸切りタクシー、列車、電車または軌道系交通機関を含む請求項1ないし11のいずれかに記載の車両運行管理システム。
  13. 前記車両は、固定されたルートに沿って運行されるか、または、乗客の要望に応じて随時決まるルートに沿って運行される請求項1ないし12のいずれかに記載の車両運行管理システム。
  14. 請求項1ないし13のいずれかに記載の通信端末としてコンピュータを機能させるためのプログラム。
  15. 請求項1ないし13のいずれかに記載の管理サーバとしてコンピュータを機能させるためのプログラム。
  16. 請求項14または15に記載のプログラムをコンピュータ読み取り可能に記録した記録媒体。
JP2019036023A 2019-02-28 2019-02-28 車両運行管理システム Active JP6676800B1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019036023A JP6676800B1 (ja) 2019-02-28 2019-02-28 車両運行管理システム
JP2020042528A JP7426705B2 (ja) 2019-02-28 2020-03-12 車両運行管理システム
JP2023223828A JP2024026617A (ja) 2019-02-28 2023-12-30 車両運行管理システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019036023A JP6676800B1 (ja) 2019-02-28 2019-02-28 車両運行管理システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2020042528A Division JP7426705B2 (ja) 2019-02-28 2020-03-12 車両運行管理システム

Publications (2)

Publication Number Publication Date
JP6676800B1 JP6676800B1 (ja) 2020-04-08
JP2020140486A true JP2020140486A (ja) 2020-09-03

Family

ID=70058000

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019036023A Active JP6676800B1 (ja) 2019-02-28 2019-02-28 車両運行管理システム

Country Status (1)

Country Link
JP (1) JP6676800B1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7186841B1 (ja) 2021-09-29 2022-12-09 Kddi株式会社 乗客管理装置、乗客管理システム、乗客管理方法及びプログラム
JP2023125180A (ja) * 2022-02-28 2023-09-07 三菱電機株式会社 乗車案内装置およびこれを用いた乗車案内システム並びに乗車案内方法

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4131205A1 (en) * 2021-08-05 2023-02-08 Hitachi, Ltd. Vehicle monitoring system

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010176221A (ja) * 2009-01-27 2010-08-12 Chugoku Electric Power Co Inc:The 車両乗降支援システム、基地局及びユーザ端末
JP2011227550A (ja) * 2010-04-15 2011-11-10 Clarion Co Ltd 停留所装置、車載装置、運行管理装置、及び運行管理システム
JP2012014730A (ja) * 2011-09-22 2012-01-19 Chugoku Electric Power Co Inc:The 車両乗降支援システム
JP2016031595A (ja) * 2014-07-28 2016-03-07 日本電信電話株式会社 情報集配システム、情報集配方法、およびプログラム
JP2016143222A (ja) * 2015-02-02 2016-08-08 株式会社リコー 通信装置、及び情報処理システム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010176221A (ja) * 2009-01-27 2010-08-12 Chugoku Electric Power Co Inc:The 車両乗降支援システム、基地局及びユーザ端末
JP2011227550A (ja) * 2010-04-15 2011-11-10 Clarion Co Ltd 停留所装置、車載装置、運行管理装置、及び運行管理システム
JP2012014730A (ja) * 2011-09-22 2012-01-19 Chugoku Electric Power Co Inc:The 車両乗降支援システム
JP2016031595A (ja) * 2014-07-28 2016-03-07 日本電信電話株式会社 情報集配システム、情報集配方法、およびプログラム
JP2016143222A (ja) * 2015-02-02 2016-08-08 株式会社リコー 通信装置、及び情報処理システム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7186841B1 (ja) 2021-09-29 2022-12-09 Kddi株式会社 乗客管理装置、乗客管理システム、乗客管理方法及びプログラム
JP2023049729A (ja) * 2021-09-29 2023-04-10 Kddi株式会社 乗客管理装置、乗客管理システム、乗客管理方法及びプログラム
JP2023125180A (ja) * 2022-02-28 2023-09-07 三菱電機株式会社 乗車案内装置およびこれを用いた乗車案内システム並びに乗車案内方法

Also Published As

Publication number Publication date
JP6676800B1 (ja) 2020-04-08

Similar Documents

Publication Publication Date Title
US11443634B2 (en) Smart signs for autonomous vehicles
US10745050B2 (en) Automated vehicle parking
JP6477601B2 (ja) 情報処理システム
JP6508130B2 (ja) カーシェアリングシステム
CN111052171A (zh) 为自动驾驶车辆安排停靠位置
JP6676800B1 (ja) 車両運行管理システム
US20190228664A1 (en) Vehicle calling system
JP2011227550A (ja) 停留所装置、車載装置、運行管理装置、及び運行管理システム
US20150161533A1 (en) On-demand vehicle operation management device, on-demand vehicle operation management method, and on-demand vehicle operation management system
JP2024026617A (ja) 車両運行管理システム
JP2013170932A (ja) 充電施設情報提供システム
JP2021177413A (ja) 駐車場管理システム
CN111459154A (zh) 移动物体系统
CN111758115A (zh) 车辆共乘辅助系统
KR20070109529A (ko) 주차장 온라인 관리 장치와 주차 관리 장치 및 그 방법과그를 이용한 주차장 온라인 운영 시스템
WO2020145099A1 (ja) 移動管理システムおよび移動管理方法
JP6383892B1 (ja) 駐車場管理方法
JP6445209B1 (ja) 駐車場管理方法
US11300978B1 (en) System, method, and computer program product for transporting an unmanned vehicle
JP7365092B1 (ja) 駐車場管理システムおよびプログラム
JP7318526B2 (ja) 情報処理装置、情報処理方法及びプログラム
JP6670536B2 (ja) 発信機故障診断システム
JP2020092459A (ja) 発信機故障診断方法
JP2021002406A (ja) 対象物管理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190401

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20190401

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20190416

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190723

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190825

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20191203

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20191205

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20200310

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200312

R150 Certificate of patent or registration of utility model

Ref document number: 6676800

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250