前記課題を解決するためになされた第1の発明は、車載端末装置との間で、少なくとも位置情報を含むメッセージを歩車間通信により送受信して、衝突判定を行う歩行者端末装置であって、前記車載端末装置と歩車間通信を行う通信部と、乗客を乗せる車両に搭載された前記車載端末装置から、当該車両の存在を通知するメッセージを前記通信部で受信すると、乗車要望を通知するメッセージを前記通信部から前記車載端末装置に送信する制御部と、を備え、前記制御部は、自装置を所持する利用者が乗車位置に到着する時刻に関する利用者到着時刻情報と、前記車両が前記乗車位置に到着する時刻に関する車両到着時刻情報とに基づいて、所定の乗車要望通知条件を満足するか否かを判定して、前記乗車要望通知条件を満足する場合には、前記乗車要望を通知するメッセージを送信する構成とする。
これによると、乗車要望通知条件を満足した場合にだけ、歩行者端末装置から、乗車要望を通知するメッセージを送信するため、歩行者端末でのメッセージの送信頻度を削減することができる。これにより、歩行者端末装置の電力消費量を低減するとともに、歩車間通信のトラフィックを削減して歩車間通信の輻輳を抑制することができる。
また、第2の発明は、前記制御部は、前記車載端末装置から受信した前記車両の存在を通知するメッセージに含まれる当該車両の位置情報と、自装置に記憶された乗車位置の位置情報とに基づいて、前記車両到着時刻情報を取得して、その車両到着時刻情報に基づいて、前記乗車要望通知条件を満足するか否かを判定する構成とする。
これによると、歩行者端末装置において、車両到着時刻情報を取得して、乗車要望通知条件を満足するか否かの判定を適切に行うことができる。
また、第3の発明は、前記制御部は、前記車載端末装置から受信した前記車両の存在を通知するメッセージに含まれる前記車両到着時刻情報と、自装置に記憶された乗車位置の位置情報とに基づいて、前記乗車要望通知条件を満足するか否かを判定する構成とする。
これによると、歩行者端末装置において、車載端末装置から車両到着時刻情報を取得するため、歩行者端末の負荷を軽減することができる。
また、第4の発明は、前記制御部は、前記乗車要望通知条件として、前記車両の到着時刻と前記利用者の到着時刻との差分が所定値以下であるか否かを判定し、前記差分が所定値以下の場合には、前記乗車要望を通知するメッセージを送信する構成とする。
これによると、車両(バスやタクシーなど)の到着時刻と利用者の到着時刻との差分が所定値以下でない、すなわち、利用者が明らかに乗車に間に合わないか、または、利用者が余裕を持って乗車に間に合う場合には、乗車要望を通知するメッセージを送信しない。これにより、乗車要望を通知するメッセージを送信する機会を適切に削減することができる。
また、第5の発明は、前記制御部は、前記差分が所定値以下であり、かつ、前記利用者の到着時刻が前記車両の到着時刻より早い場合には、前記乗車要望を通知するメッセージを送信しない構成とする。
これによると、利用者が十分に乗車に間に合う場合にはメッセージを送信しないので、歩行者端末でのメッセージの送信頻度を更に削減することができる。
また、第6の発明は、前記制御部は、前記車載端末装置から受信した前記車両の存在を通知するメッセージに含まれる空席情報に基づいて、前記車両に空席がないと判定した場合には、前記乗車要望を通知するメッセージを送信しない構成とする。
これによると、利用者がバスや乗合タクシーに座れない場合や、タクシーが空車でない場合にはメッセージを送信しないので、歩行者端末でのメッセージの送信頻度を更に削減することができる。
また、第7の発明は、前記制御部は、前記車載端末装置から受信した前記車両の存在を通知するメッセージに含まれる空席情報に基づいて、空席が所定数より少ないと判定した場合には、前記乗車要望通知条件を満足しない場合でも、前記乗車要望を通知するメッセージを車載端末装置に送信する構成とする。
これによると、利用者が乗車することを早いタイミングで車両の運転手に通知することができる。これにより、空席が少ない場合に、利用者の座席を確保することができる。
また、第8の発明は、前記制御部は、前記車載端末装置から受信した前記車両の存在を通知するメッセージに含まれる行き先情報に基づいて、予め登録された車両と行き先が一致するか否かを判定し、行き先が一致しない場合には、前記乗車要望を通知するメッセージを送信しない構成とする。
これによると、利用者が乗車予定の車両が近くにいない場合にはメッセージを送信しないので、歩行者端末でのメッセージの送信頻度を更に削減することができる。
また、第9の発明は、前記制御部は、予め登録された複数の前記車両の中から、現在の時間帯および曜日に応じて、乗車予定の車両を選択して、その車両と行き先が一致するか否かを判定する構成とする。
これによると、利用者が乗車予定の車両を複数登録することができるため、利用者の利便性を高めることができる。また、現在の時間帯および曜日に応じて、利用者が乗車するであろう車両を選択するため、車両の行き先と利用者の行き先が一致するか否かの判定を誤りなく行うことができる。
また、第10の発明は、前記制御部は、自装置に記憶された時刻表情報から前記車両到着時刻情報を取得して、その車両到着時刻情報に基づいて、前記乗車要望通知条件を満足するか否かを判定する構成とする。
これによると、車両が定刻に乗車位置(バス停やタクシー乗り場)に到着する場合には、車両到着時刻情報を含むメッセージを車載端末装置から送信しなくても、乗車要望通知条件を満足するか否かの判定を歩行者端末装置で行うことができる。
また、第11の発明は、前記制御部は、前記車載端末装置から、前記車両の存在を通知するメッセージを受信しない場合に、前記利用者到着時刻情報と、自装置に記憶された前記車両の時刻表情報とに基づいて、前記乗車要望通知条件を満足するか否かを判定する構成とする。
これによると、車両が定刻に乗車位置(バス停やタクシー乗り場)に到着する場合には、車両到着時刻情報を含むメッセージを車載端末装置から送信しなくても、乗車要望通知条件を満足するか否かの判定を歩行者端末装置で行うことができる。
また、第12の発明は、前記制御部は、前記乗車要望を通知するメッセージを送信した後に、利用者の乗車中止状態を検知すると、乗車要望の撤回を通知するメッセージを前記通信部から前記車載端末装置に送信する構成とする。
これによると、利用者が車両に乗車することを中止したことを運転手に通知することができる。このため、利用者が乗車を中止したにも拘わらず、利用者の到着を待つために運転手が車両の発車を遅らせることで、無駄に発車が遅くなることを避けることができる。
また、第13の発明は、乗客を乗せる車両に搭載され、歩行者端末装置との間で、少なくとも位置情報を含むメッセージを歩車間通信により送受信して、衝突判定を行う車載端末装置であって、前記歩行者端末装置と歩車間通信を行う通信部と、自車両の存在を通知するメッセージを前記通信部から送信するのに応じて、利用者が所持する前記歩行者端末装置から、乗車要望を通知するメッセージを前記通信部で受信すると、利用者が自車両に乗車できるか否かを判定して、その判定結果である乗車の可否を通知するメッセージを前記通信部から前記歩行者端末装置に送信する制御部と、を備え、前記制御部は、自車両に空席がない場合には、前記自車両の存在を通知するメッセージを送信しない構成とする。
これによると、車両に空席がない場合やタクシーが空車でない場合に、車両の存在を通知するメッセージを送信しないため、車載端末装置でのメッセージの送信頻度を削減することができる。
また、第14の発明は、乗客を乗せる車両に搭載され、歩行者端末装置との間で、少なくとも位置情報を含むメッセージを歩車間通信により送受信して、衝突判定を行う車載端末装置であって、前記歩行者端末装置と歩車間通信を行う通信部と、自車両の存在を通知するメッセージを前記通信部から送信するのに応じて、利用者が所持する前記歩行者端末装置から、乗車要望を通知するメッセージを前記通信部で受信すると、利用者が自車両に乗車できるか否かを判定して、その判定結果である乗車の可否を通知するメッセージを前記通信部から前記歩行者端末装置に送信する制御部と、を備え、前記制御部は、自装置の位置情報に基づいて、自車両が乗車位置に到着する時刻を推定して、自車両が定刻に乗車位置に到着する場合には、前記自車両の存在を通知するメッセージを送信しない構成とする。
これによると、車両(バス)が定刻に乗車位置(バス停)に到着する場合には、車両の存在を通知するメッセージを送信しないため、車載端末装置でのメッセージの送信頻度を削減することができる。
また、第15の発明は、歩行者端末装置と車載端末装置との間で、衝突判定のために、少なくとも位置情報を含むメッセージを歩車間通信により送受信する歩車間通信システムであって、前記歩行者端末装置は、前記車載端末装置と歩車間通信を行う通信部と、乗客を乗せる車両に搭載された前記車載端末装置から、前記車両の存在を通知するメッセージを前記通信部で受信すると、乗車要望を通知するメッセージを前記通信部から前記車載端末装置に送信する制御部と、を備え、前記車両に搭載された前記車載端末装置は、前記歩行者端末装置と歩車間通信を行う通信部と、前記車両の存在を通知するメッセージを前記通信部から送信するのに応じて、前記歩行者端末装置から、前記乗車要望を通知するメッセージを前記通信部で受信すると、利用者が前記車両に乗車できるか否かを判定して、その判定結果である乗車の可否を通知するメッセージを前記通信部から前記歩行者端末装置に送信する制御部と、を備え、前記歩行者端末装置の前記制御部は、利用者が乗車位置に到着する時刻に関する利用者到着時刻情報と、前記車両が前記乗車位置に到着する時刻に関する車両到着時刻情報とに基づいて、所定の乗車要望通知条件を満足するか否かを判定して、前記乗車要望通知条件を満足する場合には、前記乗車要望を通知するメッセージを送信する構成とする。
これによると、第1の発明と同様に、乗車支援に係るメッセージの送信頻度を低減して、歩行者端末の電力消費量を削減するとともに、歩車間通信のトラフィックを削減して歩車間通信の輻輳を抑制することができる。
また、第16の発明は、歩行者端末装置と車載端末装置との間で、衝突判定のために、少なくとも位置情報を含むメッセージを歩車間通信により送受信する歩車間通信システムにおいて、車両に乗車する利用者を支援する乗車支援方法であって、乗客を乗せる車両に搭載された前記車載端末装置が、自車両の存在を通知するメッセージを送信し、利用者が所持する前記歩行者端末装置が、前記車載端末装置から、前記車両の存在を通知するメッセージを受信すると、乗車要望を通知する前記メッセージを前記車載端末装置に送信し、前記車載端末装置が、前記歩行者端末装置から、前記乗車要望を通知するメッセージを受信すると、利用者が前記自車両に乗車できるか否かを判定して、その判定結果である乗車の可否を通知するメッセージを前記歩行者端末装置に送信するものとし、前記歩行者端末装置は、前記車両の存在を通知するメッセージを受信した際に、利用者が乗車位置に到着する時刻に関する利用者到着時刻情報と、前記車両が前記乗車位置に到着する時刻に関する車両到着時刻情報とに基づいて、所定の乗車要望通知条件を満足するか否かを判定して、前記乗車要望通知条件を満足する場合には、前記乗車要望を通知するメッセージを送信する構成とする。
これによると、第1の発明と同様に、乗車支援に係るメッセージの送信頻度を低減して、歩行者端末の電力消費量を削減するとともに、歩車間通信のトラフィックを削減して歩車間通信の輻輳を抑制することができる。
以下、本発明の実施の形態を、図面を参照しながら説明する。
(第1実施形態)
図1は、第1実施形態に係る乗車支援システムの全体構成図である。
この乗車支援システム(歩車間通信システム)は、利用者が円滑にバス(路線バス)に乗車できるように支援するものであり、利用者が所持する歩行者端末1および携帯情報端末2と、バスに搭載された車載端末3およびカーナビゲーション装置4と、を備えており、歩行者端末1と車載端末3との間で歩車間通信が行われる。
なお、主にバスへの乗車支援を例に説明するが、乗客を乗せる車両であれば何でもよく、タクシーや複数人で乗り合わせる乗合タクシーへの乗車支援でもよい。タクシーの場合であれば、タクシーに搭載の車載端末3から所定の乗車位置への到着時刻を受信し、利用者の到着時刻に基づいて乗車要望をタクシーの車載端末に送信することで、タクシー乗り場で並ぶことなく予約車としてすぐに乗車することができる。
歩車間通信では、位置情報などの所要の情報を含むメッセージを、歩行者端末1と車載端末3との間で送受信する。この歩車間通信では、ITS無線通信、すなわち、ITS(Intelligent Transport System:高度道路交通システム)を利用した安全運転支援無線システムで採用されている周波数帯(例えば700MHz帯や5.8GHz帯)を利用した無線通信によりメッセージを送受信する。
歩行者端末1は、携帯情報端末2と接続されている。この携帯情報端末2は、スマートフォン、携帯電話、タブレット端末、ウェアラブル端末などである。歩行者端末1では、車載端末3との間でメッセージを送受信することで、注意喚起が必要と判定すると、携帯情報端末2に注意喚起の指示を出力し、携帯情報端末2では、歩行者端末1からの指示に応じて、乗員に対する注意喚起の出力動作(例えば音声出力や振動など)を行う。
車載端末3は、カーナビゲーション装置4と接続されている。このカーナビゲーション装置4は、運転者に対して経路案内を行うものである。車載端末3では、歩行者端末1との間でメッセージを送受信することで、注意喚起が必要と判定すると、カーナビゲーション装置4に注意喚起の指示を出力し、カーナビゲーション装置4では、車載端末3からの指示に応じて、運転者注意喚起の出力動作(例えば音声出力や画面表示など)を行う。
また、本実施形態では、歩行者端末1と車載端末3との間で送受信される歩車間通信のメッセージに、乗車支援に係る情報を付加して送信する。
なお、歩行者端末1は、携帯情報端末2に内蔵されたものとしてもよく、車載端末3は、カーナビゲーション装置4に内蔵されたものとしてもよい。
また、歩行者端末1自身が注意喚起の出力動作を行うものとしてもよい。また、車載端末3自身が注意喚起の出力動作を行うものとしてもよい。また、車載端末3が、運転者が所持する携帯情報端末2と通信を行い、運転者に対する注意喚起の出力動作を携帯情報端末2に行わせるようにしてもよい。
また、本実施形態では、歩行者端末1と車載端末3との間の歩車間通信で、乗車支援に係る情報を直接送受信するようにしたが、バス停の近傍などに設置された路側機で中継するようにしてもよい。歩行者端末1は、消費電力を抑制するために通信距離が制限されるため、利用者から遠距離の位置にバスがいる場合、歩車間通信ができなくなるが、路側機で中継すると、利用者から遠距離の位置にバスがいる場合でも、メッセージを送受信することができる。
次に、第1実施形態に係る乗車支援システムの概要について説明する。図2は、乗車支援システムの概要を示す説明図である。図3は、乗車要望通知条件を示す説明図である。
バスの利用者がバス停の近くまで来ているのに、バスの運転手が気づかずにバスを発車させてしまい、利用者がバスに乗り遅れることがある。特に、利用者が高齢者や身体の不自由な人物である場合、バスが間近に来ていることに気付いても、急いでバス停に向かうことができないため、利用者がバスに乗り遅れることが多い。
そこで、本実施形態では、バスの車載端末3において、常時、バスの存在を通知するメッセージを送信し、利用者の歩行者端末1において、バスの存在を通知するメッセージを受信すると、乗車要望を通知するメッセージをバスの車載端末3に送信する。
また、利用者が明らかにバスの乗車に間に合わない場合には、乗車要望を通知しても無駄である。また、余裕を持ってバスの乗車に間に合う場合には、利用者がバス停でバスの到着を待てばよく、特に乗車要望を通知する必要がない。
そこで、本実施形態では、乗車要望通知条件として、利用者がバスに間に合うか否かが不明である場合にのみ、乗車要望を通知するメッセージを送信する。具体的には、利用者がバス停に到着する時刻(利用者の到着時刻)、およびバスがバス停に到着する時刻(バスの到着時刻)を算出して、次式のように、バスの到着時刻と利用者の到着時刻との差分(絶対値)が所定値以下となる場合に、乗車要望を通知するメッセージを送信する。
|バスの到着時刻−利用者の到着時刻|≦所定値
この場合、図2(A)に示すように、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信すると、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
一方、乗車要望通知条件を満足しない場合、すなわち、利用者がバスに十分に間に合う場合、および利用者が明らかにバスに間に合わない場合には、乗車要望を通知するメッセージを送信しない。具体的には、次式のように、バスの到着時刻と利用者の到着時刻との差分(絶対値)が所定値より大きくなる場合には、乗車要望を通知するメッセージを送信しない。
|バスの到着時刻−利用者の到着時刻|>所定値
ここで、この所定値は、様々な条件に応じて適時設定変更してもよいし、適応的に変更してもよい。例えば、地方のようにバスの本数が少ない場合や、都心においても本数が少ない時間帯等においては、比較的大きい値に設定してもよい。
この場合、図2(B)に示すように、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信しても、歩行者端末1から、乗車要望を通知するメッセージを送信しない。
このように本実施形態では、乗車要望通知条件を満足しない場合に、歩行者端末1から、乗車要望を通知するメッセージを送信しないため、歩行者端末1でのメッセージの送信頻度を低減することができる。これにより、歩行者端末1の電力消費量を低減するとともに、歩車間通信のトラフィックを削減して歩車間通信の輻輳を抑制することができる。
次に、第1実施形態に係る歩行者端末1および車載端末3の概略構成について説明する。図4は、歩行者端末1および車載端末3の概略構成を示すブロック図である。
歩行者端末1は、測位部11と、ITS通信部12と、制御部13と、記憶部14と、入出力部15と、を備えている。
測位部11は、GPS(Global Positioning System)、QZSS(Quasi-Zenith Satellite System)などの衛星測位システムにより自装置の位置を測定して、自装置の位置情報を取得する。なお、携帯情報端末2が有する測位機能を利用して、自装置の位置情報を取得するようにしてもよい。
ITS通信部12は、車載端末3との間でITS通信(歩車間通信)によりメッセージを送受信する。また、ITS通信部12は、路側機との間でITS通信(歩路間通信)によりメッセージを送受信することもできる。
入出力部15は、携帯情報端末2との間で情報の入出力を行う。この入出力部15から出力される情報に基づいて、携帯情報端末2において、歩行者に対する注意喚起の動作が行われる。
記憶部14は、地図情報(デジタル地図データ)や、制御部13を構成するプロセッサで実行されるプログラムなどを記憶する。また、記憶部14は、歩行者の速度情報およびバスの速度情報を記憶する。なお、地図情報は携帯情報端末2から取得するようにしてもよい。また、地図情報には、バス停やタクシー乗り場など乗車位置の位置情報が含まれる。
制御部13は、メッセージ制御部21と、衝突判定部22と、注意喚起制御部23と、乗車車両登録部24と、利用者到着時刻推定部25と、車両到着時刻推定部26と、乗車要望通知判定部27と、画面生成部28と、を備えている。この制御部13は、プロセッサで構成され、制御部13の各部は、記憶部14に記憶されたプログラムをプロセッサで実行することで実現される。
メッセージ制御部21は、端末IDや位置情報などの歩行者情報を含むメッセージの送信を制御する。
衝突判定部22は、測位部11で取得した自歩行者の位置情報と、車載端末3から受信したメッセージに含まれる車両の位置情報とに基づいて、自歩行者に車両が衝突する危険性があるか否かを判定する。
注意喚起制御部23は、衝突判定部22の判定結果に応じて、自歩行者に対する注意喚起を実施する。本実施形態では、入出力部15を介して、注意喚起の指示を携帯情報端末2に出力して、この指示に応じて携帯情報端末2において、歩行者に対する注意喚起の出力動作(例えば音声出力や振動など)が行われる。
乗車車両登録部24は、乗車車両登録部24において、利用者が乗車予定のバス(行き先、バス停発車時刻など)を指定する利用者の操作に応じて、利用者が乗車予定のバスを登録する。
利用者到着時刻推定部25は、測位部11で取得した利用者の位置情報と、記憶部14に記憶されたバス停(乗車位置)の位置情報および利用者の速度情報とに基づいて、利用者がバス停に到着する時刻(利用者の到着時刻)を推定する。
なお、歩行者の位置情報を履歴情報として記憶部14に蓄積して、その履歴情報に基づいて歩行者の速度情報(平均歩行速度)を取得すればよい。また、歩行者の属性(年齢など)に基づいて歩行者の速度情報を取得するようにしてもよい。
車両到着時刻推定部26は、車載端末3から受信したメッセージに含まれるバスの位置情報と、記憶部14に記憶されたバス停の位置情報およびバスの速度情報とに基づいて、バスがバス停に到着する時刻(バスの到着時刻)を推定する。
乗車要望通知判定部27は、乗車要望をバスの車載端末3に通知するか否かを判定する。本実施形態では、乗車要望通知条件として、利用者がバスに間に合うか否かが不明である場合、具体的には、バスの到着時刻と利用者の到着時刻との差が所定値以下である場合には、乗車要望を通知するものと判定する。この乗車要望通知判定部27で、乗車要望を通知するものと判定されると、メッセージ制御部21において、乗車要望を通知するメッセージをITS通信部12から送信する。一方、乗車要望通知条件を満足しない場合、すなわち、利用者がバスに十分に間に合う場合、および明らかにバスに間に合わない場合には、乗車要望を通知しないものと判定し、乗車要望を通知するメッセージは送信されない。
画面生成部28は、バスの車載端末3から受信したメッセージに含まれる情報に基づいて、バスの情報を利用者に提示する案内画面(図6(A)参照)を生成して、その案内画面を利用者の携帯情報端末2に表示する。
なお、本実施形態では、バスの情報を利用者に提示する案内画面を表示するようにしたが、この他に、音声の出力でバスの情報を利用者に提示するようにしてもよい。
車載端末3は、測位部31と、ITS通信部32と、制御部33と、記憶部34と、入出力部35と、を備えている。
測位部31は、GPS、QZSSなどの衛星測位システムにより自装置の位置を測定して、自装置の位置情報(緯度、経度)を取得する。なお、カーナビゲーション装置4が有する測位機能を利用して、自装置の位置情報を取得するようにしてもよい。
ITS通信部32は、歩行者端末1との間でITS通信(歩車間通信)によりメッセージを送受信する。また、ITS通信部32は、路側機との間でITS通信(路車間通信)によりメッセージを送受信することもできる。
入出力部35は、カーナビゲーション装置4との間で情報の入出力を行う。この入出力部35から出力される情報に基づいて、カーナビゲーション装置4において、運転者に対する注意喚起の動作が行われる。
記憶部34は、地図情報や、制御部33を構成するプロセッサで実行されるプログラムなどを記憶する。なお、地図情報はカーナビゲーション装置4から取得するようにしてもよい。
制御部33は、メッセージ制御部41と、衝突判定部42と、注意喚起制御部43と、乗車可否判定部44と、画面生成部45と、を備えている。この制御部33は、プロセッサで構成され、制御部33の各部は、記憶部34に記憶されたプログラムをプロセッサで実行することで実現される。
メッセージ制御部41は、端末IDや位置情報などの車両情報を含むメッセージの送信を制御する。
衝突判定部42は、測位部31で取得した自車両の位置情報と、歩行者端末1から受信したメッセージに含まれる歩行者の位置情報とに基づいて、歩行者に自車両が衝突する危険性があるか否かを判定する。
注意喚起制御部43は、衝突判定部42の判定結果に応じて、自車両の運転者に対する注意喚起を行う。本実施形態では、入出力部35を介して、注意喚起の指示をカーナビゲーション装置4に出力して、この指示に応じてカーナビゲーション装置4において、運転者に対する注意喚起の出力動作(例えば音声出力や画面表示など)が行われる。
乗車可否判定部44は、利用者の歩行者端末1から乗車要望を通知するメッセージをITS通信部32で受信すると、そのメッセージに含まれる利用者の位置情報などに基づいて、利用者がバスに乗車できるか否かを判定する。この乗車可否判定部44で判定が行われると、メッセージ制御部41において、乗車可否判定部44の判定結果である乗車の可否を通知するメッセージをITS通信部32から歩行者端末1に送信する。
画面生成部45は、利用者の歩行者端末1から受信したメッセージに含まれる情報に基づいて、バスに乗車する利用者の情報を運転手に提示する案内画面(図6(B)参照)を生成して、その案内画面をバスのカーナビゲーション装置4に表示する。
次に、第1実施形態に係る歩行者端末1および車載端末3から送信されるメッセージについて説明する。図5は、歩行者端末1および車載端末3から送信されるメッセージの内容を示す説明図である。
利用者の歩行者端末1では、メッセージ制御部21において、歩車間通信のメッセージを生成して、そのメッセージをITS通信部12から送信する。また、バスの車載端末3では、メッセージ制御部41において、歩車間通信のメッセージを生成して、そのメッセージをITS通信部32から送信する。これらの歩車間通信のメッセージは、ITS通信のメッセージのフォーマットにしたがって生成され、メッセージには、所定の情報を格納する共通領域と、ユーザが任意の情報を格納することができる自由領域(拡張領域)とがある。
バスの車載端末3では、常時、バスの存在を通知するメッセージを送信する。このメッセージでは、図5(A−1)に示すように、共通領域に、車両ID(車載端末3の端末ID)、自装置の位置情報(経度および緯度)などの所定の情報が格納される。
また、バスの車載端末3では、歩行者端末1から乗車要望を通知するメッセージを受信すると、乗車可否判定を行い、その判定結果、すなわち、乗車の可否を通知するメッセージを送信する。このメッセージでは、図5(A−2)に示すように、共通領域に、車両ID、自装置の位置情報などの所定の情報が格納され、自由領域に、乗車可否情報が格納される。この乗車可否情報は、乗車できる場合に「1」となり、乗車できない場合に「0」となる。
利用者の歩行者端末1では、常時、歩行者の存在を通知するメッセージを送信する。このメッセージ(図示せず)では、共通領域に、歩行者ID(歩行者端末1の端末ID)、自装置の位置情報(経度および緯度)などの所定の情報が格納される。さらに、利用者の歩行者端末1では、乗車要望通知条件を満足する場合に、乗車要望情報を自由領域に付加してメッセージを送信する。このメッセージでは、図5(B)に示すように、共通領域に、歩行者ID(歩行者端末1の端末ID)、自装置の位置情報(経度および緯度)などの所定の情報が格納され、自由領域に、乗車要望情報が格納される。この乗車要望情報は、乗車要望がある場合には「1」となり、乗車要望がない場合には「0」となる。
次に、第1実施形態に係る利用者の携帯情報端末2よびバスのカーナビゲーション装置4に表示される案内画面について説明する。図6は、携帯情報端末2よびカーナビゲーション装置4に表示される案内画面を示す説明図である。
本実施形態では、利用者の歩行者端末1において、乗車要望通知条件を満足する場合に、乗車要望を通知するメッセージをバスの車載端末3に送信し、これに応じて車載端末3から送信される乗車の可否を通知するメッセージを受信すると、バスの情報を利用者に提示する案内画面を利用者の携帯情報端末2に表示する。この案内画面には、図6(A)に示すように、受信したメッセージに含まれる車両到着時刻情報および乗車可否情報が表示される。さらに、バスの系統や行き先を示す情報も表示するようにしてもよい。
なお、乗車要望通知条件を満足しない場合、すなわち、乗車要望を通知するメッセージを送信しない場合には、利用者の携帯情報端末2に案内画面は表示されない。なお、乗車要望通知条件を満足していないこと、あるいは乗車要望通知条件を満足しない理由などを表示するようにしてもよい。
また、本実施形態では、バスの車載端末3において、歩行者端末1から送信される乗車要望を通知するメッセージを受信すると、バスに乗車する利用者の情報を運転手に提示する案内画面をバスのカーナビゲーション装置4に表示する。この案内画面には、図6(B)に示すように、受信したメッセージに含まれる利用者の歩行者IDおよび位置情報(経度および緯度)が表示される。また、利用者の属性情報(車椅子、高齢者、妊婦)なども表示されるようにしてもよい。
なお、案内画面には、乗車要望を通知するメッセージを受信して乗車要望を受け付けた利用者の情報のみが表示される。また、乗車要望を受け付けた利用者が複数いる場合には、各利用者の情報が並べて表示される。
また、本実施形態では、利用者に関する情報としてユーザIDおよび位置情報を案内画面に表示するようにしたが、乗車要望を行った利用者が乗車済みか否かを表す情報を案内画面に表示するようにしてもよい。これにより、未乗車の利用者がいることをバスの運転手が把握することができ、余裕があれば未乗車の利用者を待つことができるようになる。
この場合、利用者の歩行者端末1から受信したメッセージに含まれる利用者の位置情報に基づいて、乗車要望を行った利用者が実際にバスに乗車したことを検知するようにするとよい。また、Bluetooth(登録商標)などの近距離通信や、バスの車内をカメラで撮影した映像を利用して、利用者の乗車を検知するようにしてもよい。
また、利用者が到着するまでの待ち時間を案内画面に表示するようにしてもよい。これにより、待ち時間に基づいて、利用者の到着を待つか発車するかを運転手が判断することができる。この場合、利用者の歩行者端末1から受信したメッセージに含まれる利用者の位置情報に基づいて、利用者が到着するまでの待ち時間を算出すればよい。
次に、第1実施形態に係る歩行者端末1および車載端末3の動作手順について説明する。図7は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、まず、乗車車両登録部24において、利用者が乗車予定のバス(行き先、バス停発車時刻など)を指定する利用者の操作に応じて、利用者が乗車予定のバスを登録する(ST101)。
次に、測位部11において、利用者の位置情報を取得する(ST102)。そして、利用者到着時刻推定部25において、利用者の位置情報と、記憶部14に記憶された歩行者の速度情報およびバス停の位置情報とに基づいて、利用者がバス停に到着する時刻(利用者到着時刻)を推定する(ST103)。
次に、ITS通信部12において、バスの車載端末3からバスの存在を通知するメッセージを受信すると(ST104でYes)、車両到着時刻推定部26において、受信したメッセージに含まれるバスの位置情報と、記憶部14に記憶されたバス停の位置情報およびバスの速度情報とに基づいて、バスがバス停に到着する時刻(車両到着時刻)を推定する(ST105)。
次に、乗車要望通知判定部27において、利用者到着時刻推定部25で取得した利用者到着時刻情報と、車両到着時刻推定部26で取得した車両到着時刻情報とに基づいて、乗車要望通知条件を満足する、すなわち、バスの到着時刻と利用者の到着時刻との差が所定値より小さいか否かを判定する(ST106)。
ここで、乗車要望通知条件を満足する場合には(ST106でYes)、メッセージ制御部21において、乗車要望を通知するメッセージを生成してITS通信部12からバスの車載端末3に送信する(ST107)。
次に、ITS通信部12において、バスの車載端末3から乗車の可否を通知するメッセージを受信すると(ST108でYes)、画面生成部28において、そのメッセージに含まれる乗車可否情報に基づいて、バスの情報を利用者に提示する案内画面(図6(A)参照)を生成して利用者の携帯情報端末2に表示する(ST109)。
一方、乗車要望通知条件を満足しない場合には(ST106でNo)、特に処理を行わずに終了する。
車載端末3では、まず、測位部31において、バスの位置情報を取得する(ST201)。そして、メッセージ制御部41において、バスの存在を通知するメッセージ(バスの位置情報を含む)を生成してITS通信部32から送信する(ST202)。
次に、ITS通信部32において、歩行者端末1から乗車要望を通知するメッセージを受信すると(ST203でYes)、乗車可否判定部44において、受信したメッセージに含まれる利用者の位置情報に基づいて、利用者がバスに乗車できるか否かを判定する(ST204)。そして、メッセージ制御部41において、乗車可否判定部44の判定結果である乗車の可否を通知するメッセージを生成してITS通信部32から送信する(ST205)。なお、歩行者端末1から受信したメッセージに、乗車要望が付加されていない場合には(ST203でNo)、通常の歩車間メッセージとして衝突判定を行うようにしてよい。
次に、乗車可否判定部44で乗車できるものと判定された場合には(ST206でYes)、画面生成部45において、歩行者端末1から受信したメッセージに含まれる情報に基づいて、バスに乗車する利用者の情報を運転手に提示する案内画面(図6(B)参照)を生成してカーナビゲーション装置4に表示する(ST207)。
ところで、利用者の移動速度が通常より遅くなるなどの理由で、利用者の到着時刻が遅くなり、乗車可とされたバスに間に合わなくなる場合がある。この場合、利用者の携帯情報端末2に表示される案内画面で、利用者に次のバスに変更するように案内するようにするとよい。また、この場合においては、当初乗車予定だったバスの車載端末3から次のバスの車載端末3に対して、車車間通信等によって、高齢者が乗車することやその人物が乗車するバス停に関する情報などを通知してもよい。
(第1実施形態の変形例)
次に、第1実施形態の変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図8は、第1実施形態の変形例に係る乗車支援システムの概要を示す説明図である。
第1実施形態では、歩行者端末1において、バスの車載端末3からバスの位置情報を取得して、そのバスの位置情報に基づいてバスの到着時刻を推定するようにしたが、本変形例では、バスの車載端末3において、自装置の位置情報に基づいてバスの到着時刻を推定して、バスの存在を通知するメッセージに到着時刻情報を付加して歩行者端末1に送信する。
歩行者端末1では、バスの存在を通知するメッセージを車載端末3から受信すると、そのメッセージに含まれる到着時刻情報に基づいて、乗車要望通知条件を満足するか否かの判定を行う。
これにより、第1実施形態と比較すると、車載端末3から送信されるメッセージの情報量は増加するが、バスの到着時刻を推定する処理を歩行者端末1で行わずに済むため、歩行者端末1の負荷を軽減することができる。
なお、第1実施形態と同様に、乗車要望通知条件を満足する場合には、図8(A)に示すように、歩行者端末1から、乗車要望を通知するメッセージを送信し、乗車要望通知条件を満足しない場合には、図8(B)に示すように、歩行者端末1から、乗車要望を通知するメッセージを送信しない。
次に、第1実施形態の変形例に係る歩行者端末1および車載端末3の概略構成について説明する。図9は、歩行者端末1および車載端末3の概略構成を示すブロック図である。
歩行者端末1および車載端末3の構成は、第1実施形態(図4参照)と略同様であるが、第1実施形態において歩行者端末1の制御部13に設けられていた車両到着時刻推定部26が省略され、代わりに、車載端末3の制御部33に車両到着時刻推定部46が設けられている。
この車両到着時刻推定部46は、測位部31で取得したバスの位置情報と、記憶部34に記憶されたバス停の位置情報およびバスの速度情報とに基づいて、バスがバス停に到着する時刻(バスの到着時刻)を推定する。なお、カーナビゲーション装置4が備えている経路探索の機能を利用して、バスの到着時刻を取得するようにしてもよい。
次に、第1実施形態の変形例に係る歩行者端末1および車載端末3から送信されるメッセージについて説明する。図10は、歩行者端末1および車載端末3から送信されるメッセージの内容を示す説明図である。
本実施形態では、第1実施形態(図5(A−1)参照)と同様に、バスの車載端末3において、常時、バスの存在を通知するメッセージを送信するが、本実施形態では、メッセージの自由領域に、到着時刻情報が格納される。
次に、第1実施形態の変形例に係る歩行者端末1および車載端末3の動作手順について説明する。図11は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、第1実施形態(図7参照)と同様に、ST101からST103の処理を行う。
次に、ITS通信部12において、バスの車載端末3からバスの存在を通知するメッセージ(車両到着時刻情報を含む)を受信すると(ST111でYes)、乗車要望通知判定部27において、利用者到着時刻推定部25で取得した利用者到着時刻情報と、受信したメッセージに含まれる車両到着時刻情報とに基づいて、乗車要望通知条件を満足するか否かを判定する(ST112)。
ここで、乗車要望通知条件を満足する場合には(ST112でYes)、メッセージ制御部21において、乗車要望を通知するメッセージを生成してITS通信部12からバスの車載端末3に送信する(ST107)。一方、乗車要望通知条件を満足しない場合には(ST112でNo)、特に処理を行わずに終了する。
以降は、第1実施形態(図7参照)と同様に、ST107からST109の処理を行う。
車載端末3では、まず、測位部31において、バスの位置情報を取得する(ST201)。次に、車両到着時刻推定部46において、バスの位置情報と、記憶部34に記憶されたバス停の位置情報およびバスの速度情報とに基づいて、車両到着時刻を推定する(ST211)。そして、メッセージ制御部41において、バスの存在を通知するメッセージ(到着時刻情報を含む)を生成してITS通信部32から送信する(ST212)。
以降は、第1実施形態(図7参照)と同様に、ST203からST207の処理を行う。
(第1実施形態の別の変形例)
次に、第1実施形態の別の変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図12は、第1実施形態の別の変形例に係る乗車要望通知条件を示す説明図である。
バスがバス停に到着する前に歩行者がバス停に到着する場合には、歩行者がバス停でバスの到着を待っていればよく、利用者がバスに乗り遅れることはないため、必ずしも乗車要望を通知するメッセージをバスの車載端末3に送信する必要がない。
そこで、本変形例では、利用者がバスに間に合うか否かが不明である場合、すなわち、バスの到着時刻と利用者の到着時刻との差(絶対値)が所定値以下の場合でも、歩行者がバスより先にバス停に到着する場合、すなわち、利用者の到着時刻がバスの到着時刻より早い場合には、乗車要望を通知するメッセージを送信しない。
なお、利用者がバスに十分に間に合う場合、および明らかにバスに間に合わない場合、すなわち、バスの到着時刻と利用者の到着時刻との差(絶対値)が所定値より大きい場合には、第1実施形態と同様に、乗車要望を通知するメッセージを送信しない。
このように本変形例では、乗車要望を通知するメッセージを送信する機会が少なくなるため、歩行者端末1でのメッセージの送信頻度を更に削減することができる。
(第2実施形態)
次に、第2実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図13は、第2実施形態に係る乗車支援システムの概要を示す説明図である。
利用者が高齢者や身体の不自由な人物である場合、利用者が立ったまま乗車することが難しいため、バスに空席がないと、そのバスに乗車できず、利用者が不快な思いをする。また、バスに空席がない場合、そのバスに乗車しないため、バスの存在を通知するメッセージを車載端末3から受信して、歩行者端末1から車載端末3に乗車要望を送信するようにしても、無駄になる。
そこで、本実施形態では、バスの車載端末3において、バスの空席を検出して、バスに空席があるか否かに関する空席情報を、バスの存在を通知するメッセージに付加して送信し、歩行者端末1において、受信したメッセージに含まれる空席情報に基づいて、バスに空席がない場合には、乗車要望通知条件を満足する場合でも、乗車要望を通知するメッセージを送信しない。
すなわち、図13(A)に示すように、乗車要望通知条件を満足し、かつ、バスに空席がある場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信すると、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
一方、図13(B)に示すように、乗車要望通知条件を満足しない場合、または、乗車要望通知条件を満足するが、バスに空席がない場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信しても、歩行者端末1から、乗車要望を通知するメッセージを送信しない。
このように本実施形態では、バスに空席がない場合には、乗車要望通知条件を満足する場合でも、歩行者端末1から、乗車要望を通知するメッセージを送信しないため、歩行者端末1でのメッセージの送信頻度を更に低減することができる。また、利用者が乗車できると思っていたバスに空席がないために、利用者が不快な思いをすることを回避することができる。
なお、本実施形態では、バスに空席がない場合には、そのバスに利用者が乗車しないものとして、乗車要望を通知するメッセージを送信しないようにしたが、利用者によっては立ったままでもよい場合もある。そこで、事前のユーザ設定で、バスに空席がない場合に乗車要望を通知するメッセージをバスに送信するか否か(バスに乗車するか否か)を利用者が選択できるようにしてもよい。この場合、立ったままでもよいか否かを示す情報を事前に歩行者端末1に設定しておく。そして、歩行者端末1が「立ったままでもよい」という設定になっていれば、バスに空席がない場合でも、歩行者端末1は乗車要望を通知するメッセージをバスの車載端末3に送信する。一方、歩行者端末1が「立ったままはNG」という設定になっていれば、歩行者端末1はバスに空席がない場合には乗車要望を通知するメッセージをバスの車載端末3に送信しない。ここで、立ったままでもよいか否かを示す情報を、歩行者端末1から車載端末に送信してもよい。高齢者の中には、該当するバスには乗車したいが、「立ったままでもよい」と考えている利用者もいる。例えば、例え座席が空いていても、健康維持等の理由により立っている高齢者もいる。このような場合、バスは不要に座席確保を行う必要がなくなるという利点がある。
次に、第2実施形態に係る歩行者端末1および車載端末3の概略構成について説明する。図14は、歩行者端末1および車載端末3の概略構成を示すブロック図である。
歩行者端末1の構成は、第1実施形態の変形例(図9参照)と同様である。
車載端末3の構成は、第1実施形態の変形例(図9参照)と略同様であるが、制御部33が、空席検出部47を備えている。この空席検出部47は、バスの車内に設置されたカメラ7で車内を撮影したカメラ画像を取得して、そのカメラ画像を解析することにより、車内の空席を検出する。メッセージ制御部41は、空席検出部47の検出結果である、空席があるか否かに関する空席情報を、バスの存在を通知するメッセージに付加してITS通信部32から送信する。
なお、本実施形態では、カメラ画像の解析により空席判定を行うようにしたが、座席の荷重を検出する重量センサや、車体全体の荷重を検出する重量センサの検出結果に基づいて空席判定を行うようにしてもよい。
次に、第2実施形態に係る車載端末3から送信されるメッセージについて説明する。図15は、車載端末3から送信されるメッセージの内容を示す説明図である。
本実施形態では、第1実施形態の変形例(図10参照)と同様に、バスの車載端末3から、常時、バスの存在を通知するメッセージを送信するが、本実施形態では、メッセージの自由領域に、到着時刻情報の他に、空席情報が格納される。この空席情報は、空席がある場合には「1」となり、空席がない場合には「0」となる。
次に、第2実施形態に係る歩行者端末1および車載端末3の動作手順について説明する。図16は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、第1実施形態の変形例(図11参照)と同様に、ST101からST103の処理を行う。
次に、ITS通信部12において、バスの車載端末3からバスの存在を通知するメッセージ(到着時刻情報、空席情報を含む)を受信すると(ST121でYes)、乗車要望通知判定部27において、利用者到着時刻推定部25で取得した利用者到着時刻情報と、受信したメッセージに含まれる車両到着時刻情報とに基づいて、乗車要望通知条件を満足するか否かを判定する(ST112)。
ここで、乗車要望通知条件を満足する場合には(ST112でYes)、次に、受信したメッセージに含まれる空席情報に基づいて、バスに空席があるか否かを判定する(ST122)。
ここで、空席がある場合には(ST122でYes)、メッセージ制御部21において、乗車要望を通知するメッセージを生成してITS通信部12からバスの車載端末3に送信する(ST107)。
一方、空席がない場合には(ST122でNo)、特に処理を行わずに終了する。
以降は、第1実施形態の変形例(図11参照)と同様に、ST107からST109の処理を行う。
車載端末3では、まず、測位部31において、バスの位置情報を取得する(ST201)。次に、車両到着時刻推定部46において、バスの位置情報と、記憶部34に記憶されたバス停の位置情報およびバスの速度情報とに基づいて、車両到着時刻を推定する(ST211)。また、空席検出部47において、バスの車内の空席を検出する(ST221)。そして、メッセージ制御部41において、バスの存在を通知するメッセージ(到着時刻情報および空席情報を含む)を生成してITS通信部32から送信する(ST222)。
以降は、第1実施形態の変形例(図11参照)と同様に、ST203からST207の処理を行う。
ところで、複数のバスが短い間隔でバス停に到着する場合に、先行のバスに空席がなく、かつ、後続のバスに空席がある場合には、後続のバスを利用者に案内するとよい。そこで、先行のバスと後続のバスの間隔が所定値以下である場合に、先行のバスに空席がなく、かつ、後続のバスに空席がある場合には、後続のバスの車載端末3では、バスの存在を通知するメッセージを送信し、先行のバスの車載端末3では、バスの存在を通知するメッセージを送信しないようにしてもよい。
(第2実施形態の変形例)
次に、第2実施形態の変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図17は、第2実施形態の変形例に係る乗車支援システムの概要を示す説明図である。
利用者が高齢者や身体の不自由な人物である場合、バスに空席がないと、そのバスに乗車せず、次のバスを待つことが多い。この場合、バスの車載端末3からバスの存在を通知するメッセージを送信して、これに応じて、乗車要望を通知するメッセージを歩行者端末1から車載端末3に送信するようにしても、無駄になる。
そこで、本実施形態では、バスの車載端末3において、バスに空席がない場合には、図17(A)に示すように、バスの存在を通知するメッセージを送信しない。
一方、バスに空席がある場合には、図17(B)に示すように、バスの車載端末3から、バスの存在を通知するメッセージを送信するが、乗車要望通知条件を満足しない場合には、歩行者端末1から、乗車要望を通知するメッセージを送信しない。
また、バスに空席があり、かつ、乗車要望通知条件を満足する場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信すると、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
このように本実施形態では、バスに空席がない場合には、バスの車載端末3からバスの存在を通知するメッセージを送信しないため、車載端末3でのメッセージの送信頻度を更に削減することができ、歩車間通信のトラフィックを削減して歩車間通信の輻輳を抑制する効果が大きくなる。
次に、第2実施形態の変形例に係る歩行者端末1および車載端末3の動作手順について説明する。図18は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1の動作手順は、第1実施形態の変形例(図11参照)と同様である。
車載端末3では、第2実施形態(図16参照)と同様に、ST201、ST211、ST221の処理を行う。
次に、メッセージ制御部41において、空席検出部47の検出に基づいて、バスに空席があるか否かを判定する(ST231)。ここで、空席がある場合には(ST231でYes)、メッセージ制御部41において、バスの存在を通知するメッセージ(到着時刻情報を含む)を生成してITS通信部32から送信する(ST212)。
一方、空席がない場合には(ST231でNo)、特に処理を行わずに終了する。
以降は、第2実施形態(図16参照)と同様に、ST203からST207の処理を行う。
(第3実施形態)
次に、第3実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図19は、第3実施形態に係る乗車支援システムの概要を示す説明図である。
バスの利用者が高齢者や身体の不自由な人物である場合、立ったまま乗車することが難しいため、乗車前に利用者の座席を確保することが望ましく、これには、高齢者が乗車することをバスの運転手に事前に通知する必要がある。
そこで、本実施形態では、バスの空席が残り少ない場合には、利用者がバスに十分に間に合う場合、すなわち、乗車要望通知条件を満足しない場合でも、歩行者端末1から、乗車要望を通知するメッセージを車載端末3に送信するようにする。なお、この場合、乗車要望通知条件を満足しない範囲において、利用者の到着時刻がバスの到着時刻よりも早い場合に、乗車要望を通知するものとする。
具体的には、図19(A)に示すように、乗車要望通知条件を満足する場合、または、乗車要望通知条件を満足せず、かつ、バスの空席が所定値より少ない場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信すると、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
一方、図19(B)に示すように、乗車要望通知条件を満足せず、かつ、バスの空席が所定値以上ある場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信しても、歩行者端末1から、乗車要望を通知するメッセージを送信しない。
このように本実施形態では、バスの空席が残り少ない場合には、利用者がバスに十分に間に合う場合でも、歩行者端末1から、乗車要望を通知するメッセージを車載端末3に送信することで、利用者が乗車することを早いタイミングでバスの運転手に通知することができる。これにより、運転手が、次のバス停で高齢者が乗車する旨の車内アナウンスを行うなどして、高齢者の座席を確保することができる。
また、本実施形態では、歩行者端末1から、利用者が杖を使用している情報や、利用者の年齢や高齢者であることを表す情報などを、利用者の属性情報として、乗車要望を通知するメッセージに付加して送信する。これにより、バスの運転手が、属性情報に基づいて、優先的に座席を確保することができる。
なお、本実施形態では、利用者が乗車することを早いタイミングでバスの運転手に通知することで、利用者の座席を確保するようにしたが、利用者によっては立ったままでもよい場合もある。そこで、事前のユーザ設定で、座席の確保が必要か否かを利用者が選択できるようにしてもよい。
なお、歩行者端末1および車載端末3の構成は、第2実施形態(図14参照)と同様である。
次に、第3実施形態に係る歩行者端末1および車載端末3から送信されるメッセージについて説明する。図20は、歩行者端末1および車載端末3から送信されるメッセージの内容を示す説明図である。
本実施形態では、第1実施形態の変形例(図10参照)と同様に、バスの車載端末3において、常時、バスの存在を通知するメッセージを送信するが、本実施形態では、図20(A)に示すように、メッセージの自由領域に、到着時刻情報の他に、空席情報が格納される。この空席情報は、空席の座席数である。
また、本実施形態では、第1実施形態(図5(B)参照)と同様に、利用者の歩行者端末1において、乗車要望通知条件を満足する場合に、乗車要望を通知するメッセージを送信するが、本実施形態では、図20(B)に示すように、メッセージの自由領域に、乗車要望情報の他に、利用者の属性情報(杖持参)が格納される。
次に、第3実施形態に係る利用者の携帯情報端末2およびバスのカーナビゲーション装置4に表示される案内画面について説明する。図21は、携帯情報端末2およびカーナビゲーション装置4に表示される案内画面を示す説明図である。
本実施形態では、利用者の歩行者端末1において、バスの車載端末3から送信される乗車の可否を通知するメッセージを受信すると、第1実施形態(図6(A)参照)と同様に、案内画面を利用者の携帯情報端末2に表示するが、本実施形態では、図21(A)に示すように、案内画面に、車両到着時刻情報および乗車可否情報の他に、受信したメッセージに含まれる空席情報が表示される。
また、本実施形態では、バスの車載端末3において、歩行者端末1から送信される乗車要望を通知するメッセージを受信すると、第1実施形態(図6(B)参照)と同様に、案内画面をバスのカーナビゲーション装置4に表示するが、本実施形態では、図20(B)に示すように、案内画面に、利用者の歩行者IDおよび位置情報の他に、受信したメッセージに含まれる利用者の属性情報(杖持参)が表示される。
次に、第3実施形態に係る歩行者端末1および車載端末3の動作手順について説明する。図22は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、第2実施形態(図16参照)と同様に、ST101からST103、ST121、ST112の処理を行う。
そして、乗車要望通知条件を満足する場合には(ST112でYes)、メッセージ制御部21において、乗車要望を通知するメッセージ(属性情報を含む)を生成してITS通信部12からバスの車載端末3に送信する(ST132)。
一方、乗車要望通知条件を満足しない場合には(ST112でNo)、次に、乗車要望通知判定部27において、受信したメッセージに含まれる空席情報に基づいて、バスの空席が所定値より少ないか否かを判定する(ST131)。
ここで、空席が所定値より少ない場合には(ST131でYes)、メッセージ制御部21において、乗車要望を通知するメッセージ(属性情報を含む)を生成してITS通信部12からバスの車載端末3に送信する(ST132)。なお、利用者がバスに十分に間に合う場合にメッセージを送信し、明らかにバスに間に合わない場合にはメッセージを送信しない。
一方、空席が所定値より少なくない場合には(ST131でNo)、乗車要望を通知するメッセージを送信することなく、処理を終了する。
以降は、第1実施形態の変形例(図11参照)と同様に、ST108、ST109の処理を行う。
車載端末3では、第2実施形態(図16参照)と同様に、ST201、ST211、ST221、ST222の処理を行う。
次に、ITS通信部32において、歩行者端末1から乗車要望を通知するメッセージ(属性情報を含む)を受信すると(ST241でYes)、第1実施形態(図15参照)と同様に、ST204からST207の処理を行う。
(第4実施形態)
次に、第4実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図23は、第4実施形態に係る乗車支援システムの概要を示す説明図である。
利用者がバスに乗車するバス停に、行き先が異なるバスが停車することがある。この場合、バスに乗車できると思っていたのに行き先が異なるバスであったため、利用者が不快な思いをすることがある。また、行き先が異なるバスに利用者が乗車する乗り間違いが発生する。
そこで、本実施形態では、バスの車載端末3から、バスの存在を通知するメッセージに行き先情報を付加して送信し、利用者の歩行者端末1において、受信したメッセージに含まれる行き先情報に基づいて、利用者が乗車予定のバスと行き先が一致しない場合には、乗車要望通知条件を満足する場合でも、乗車要望を通知するメッセージを送信しない。
すなわち、図23(A)に示すように、乗車要望通知条件を満足し、かつ、利用者が乗車予定のバスと行き先が一致する場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信すると、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
一方、図23(B)に示すように、乗車要望通知条件を満足しない場合、または、乗車要望通知条件を満足するが、利用者が乗車予定のバスと行き先が一致しない場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信しても、歩行者端末1から、乗車要望を通知するメッセージを送信しない。
このように本実施形態では、利用者が乗車予定のバスと行き先が一致しない場合には、乗車要望通知条件を満足する場合でも、歩行者端末1から、乗車要望を通知するメッセージを送信しないため、歩行者端末1でのメッセージの送信頻度を更に低減することができる。また、利用者が乗車できると思っていたバスの行き先が自分の行き先と異なるために利用者が不快な思いをすることを回避することができる。
なお、歩行者端末1および車載端末3の構成は、第1実施形態の変形例(図9参照)と同様である。
次に、第4実施形態に係る車載端末3から送信されるメッセージについて説明する。図24は、車載端末3から送信されるメッセージの内容を示す説明図である。
本実施形態では、第1実施形態の変形例(図10参照)と同様に、バスの車載端末3において、常時、バスの存在を通知するメッセージを送信するが、本実施形態では、メッセージの自由領域に、到着時刻情報の他に、行き先情報が格納される。
次に、第4実施形態に係る歩行者端末1および車載端末3の動作手順について説明する。図25は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、まず、第1実施形態の変形例(図11参照)と同様に、ST101〜ST103の処理を行う。
次に、バスの車載端末3からバスの存在を通知するメッセージ(車両到着時刻情報および行き先情報を含む)をITS通信部12で受信すると(ST141でYes)、乗車要望通知判定部27において、利用者到着時刻推定部25で取得した利用者到着時刻情報と、受信したメッセージに含まれる車両到着時刻情報とに基づいて、乗車要望通知条件を満足するか否かを判定する(ST112)。
ここで、乗車要望通知条件を満足する場合には(ST112でYes)、次に、利用者が乗車予定のバスと行き先が一致するか否かを判定する(ST142)。
ここで、利用者が乗車予定のバスと行き先が一致する場合には(ST142でYes)、メッセージ制御部21において、乗車要望を通知するメッセージを生成してITS通信部12からバスの車載端末3に送信する(ST107)。
一方、利用者が乗車予定のバスと行き先が一致しない場合には(ST142でNo)、特に処理を行わずに終了する。
以降は、第1実施形態の変形例(図11参照)と同様に、ST108からST109の処理を行う。
車載端末3では、第1実施形態の変形例(図11参照)と同様に、ST201、ST211の処理を行う。
次に、メッセージ制御部41において、バスの存在を通知するメッセージ(車両到着時刻情報および行き先情報を含む)を生成してITS通信部32から送信する(ST251)。
以降は、第1実施形態の変形例(図11参照)と同様に、ST203からST207の処理を行う。
(第4実施形態の変形例)
次に、第4実施形態の変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。
利用者が乗車予定のバス(行き先およびバス停発車時刻)が複数ある場合がある。この場合、事前に、利用者が乗車予定のバスを複数登録すればよいが、利用者が乗車したいバスが、時間帯や曜日に応じて異なる場合がある。
そこで、本変形例では、歩行者端末1において、利用者が乗車したい複数のバス(行き先およびバス停発車時刻)を時間帯や曜日に対応付けて登録する。そして、第4実施形態と同様に、利用者が乗車予定のバスと行き先が一致するか否かを判定する際に、登録されたバス(行き先)の中から、現在の時間帯や曜日に基づいて、バス(行き先)を選択する。
このように本変形例では、利用者が乗車予定のバスを複数登録することができるため、利用者の利便性を高めることができる。また、時間帯や曜日に応じてバスの行き先を選択するため、利用者が乗車予定のバスと行き先が一致するか否かの判定を誤りなく行うことができる。
次に、第4実施形態の変形例に係る歩行者端末1および車載端末3の動作手順について説明する。図26は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、まず、乗車車両登録部24において、バス(行き先、バス停発車時刻など)を指定する利用者の操作に応じて、利用者が乗車したいバスを複数登録する(ST151)。
次に、第4実施形態(図25参照)と同様に、ST102、T103、ST141、ST112の処理を行う。
そして、乗車要望通知条件を満足する場合には(ST112でYes)、次に、現在の曜日および時刻に基づいて、利用者が乗車予定のバス(行き先)を選択する(ST152)。そして、利用者が乗車予定のバスと行き先が一致するか否かを判定する(ST142)。
以降は、第4実施形態(図25参照)と同様に、ST107からST109の処理を行う。
車載端末3の動作手順は、第4実施形態(図25参照)と同様である。
(第5実施形態)
次に、第5実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図27は、第5実施形態に係る乗車支援システムの概要を示す説明図である。
バスが定刻通りにバス停に到着する場合には、歩行者端末1は、利用者の到着時刻と時刻表に記載されたバスの到着時刻とに基づいて、乗車要望通知条件を満足するか否かを判定することができ、歩行者端末1でバスの到着時刻を算出したり、バスの車載端末3から歩行者端末1にバスの到着時刻情報を通知したりする必要がない。
そこで、本実施形態では、車載端末3において、バスが定刻にバス停に到着する場合には、バスの存在を通知するメッセージを送信しない。歩行者端末1では、バスの存在を通知するメッセージを受信しない場合には、バスが定刻通りにバス停に到着するものと想定して、時刻表情報からバスの到着時刻情報を取得して、乗車要望通知条件を満足するか否かの判定を行う。
一方、バスが定刻より遅れてバス停に到着する場合には、バスの存在を通知するメッセージにバスの到着時刻情報を付加して送信する。歩行者端末1では、バスの存在を通知するメッセージを車載端末3から受信すると、そのメッセージに含まれる到着時刻情報に基づいて、乗車要望通知条件を満足するか否かの判定を行う。
すなわち、図27(A)に示すように、バスが定刻より遅れてバス停に到着する場合で、かつ、乗車要望通知条件を満足する場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信すると、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
一方、図27(B)に示すように、バスが定刻にバス停に到着する場合で、かつ、乗車要望通知条件を満足する場合には、バスの車載端末3から、バスの存在を通知するメッセージが送信されないまま、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
このように本実施形態では、バスが定刻にバス停に到着する場合には、バスの存在を通知するメッセージ(車両到着時刻情報を含む)を送信しないため、車載端末3からのメッセージの送信頻度を更に削減することができ、歩車間通信のトラフィックを削減して歩車間通信の輻輳を抑制する効果が大きくなる。
なお、歩行者端末1では、バス停に設置された路側機などから事前に時刻表情報を取得するようにすればよい。
なお、歩行者端末1および車載端末3の構成は、第1実施形態の変形例(図9参照)と同様である。
次に、第5実施形態に係る歩行者端末1および車載端末3の動作手順について説明する。図28は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、まず、乗車車両登録部24において、利用者の操作に応じて、利用者が乗車予定のバスを登録する(ST101)。また、路側機などの時刻表情報を提供する装置から、時刻表情報を取得する(ST161)。
次に、第1実施形態の変形例(図11参照)と同様に、ST102、ST103の処理を行う。
次に、ITS通信部12において、バスの車載端末3からバスの存在を通知するメッセージ(車両到着時刻情報を含む)を受信すると(ST111でYes)、乗車要望通知判定部27において、利用者到着時刻推定部25で取得した利用者到着時刻情報と、受信したメッセージに含まれる車両到着時刻情報とに基づいて、乗車要望通知条件を満足するか否かを判定する(ST112)。
一方、バスの車載端末3からバスの存在を通知するメッセージ(車両到着時刻情報を含む)を受信しない場合には(ST111でNo)、時刻表情報に基づいて、バスの到着時刻を取得する(ST162)。すなわち、定刻をバスの到着時刻に設定する。
以降は、第1実施形態の変形例(図11参照)と同様に、ST106からST109の処理を行う。
車載端末3では、第1実施形態の変形例(図11参照)と同様に、ST201、ST211の処理を行う。
次に、メッセージ制御部41において、バスの到着が定刻より遅れるか否かを判定する(ST261)。ここで、バスの到着が定刻より遅れる場合には(ST261でYes)、バスの存在を通知するメッセージ(車両到着時刻情報を含む)をITS通信部12から送信する(ST212)。一方、バスの到着が定刻より遅れない場合には(ST261でNo)、バスの存在を通知するメッセージを送信しない。
以降は、第1実施形態の変形例(図11参照)と同様に、ST203からST207の処理を行う。
(第6実施形態)
次に、第6実施形態について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図29は、第6実施形態に係る乗車支援システムの概要を示す説明図である。
乗車要望を通知するメッセージを利用者の歩行者端末1からバスの車載端末3に送信した後に、利用者が諸事情によりバスの乗車を中止する場合がある。この場合、バスの車載端末3で乗車要望を受け付けた状態が放置されると、利用者の到着を待つために運転手がバスの発車を遅らせることで、無駄にバスの発車が遅れる。
そこで、本実施形態では、歩行者端末1において、乗車要望を通知するメッセージを送信した後に、利用者がバスの乗車を中止したものと想定される乗車中止状態を検知すると、乗車要望の撤回を通知するメッセージをバスの車載端末3に送信する。
すなわち、図29(A)に示すように、乗車要望通知条件を満足する場合には、バスの車載端末3から送信されるバスの存在を通知するメッセージを歩行者端末1で受信すると、歩行者端末1から、乗車要望を通知するメッセージが送信され、これに応じてバスの車載端末3から、乗車の可否を通知するメッセージが送信される。
その後、歩行者端末1において、乗車中止状態を検知すると、図29(B)に示すように、乗車要望の撤回を通知するメッセージがバスの車載端末3に送信される。
このように本実施形態では、利用者がバスの乗車を中止した場合に、乗車要望の撤回を通知するメッセージが歩行者端末1から車載端末3に送信されるため、利用者がバスの乗車を中止したことをバスの運転手が把握することができる。これにより、利用者がバスの乗車を中止したにも拘わらず、利用者の到着を待つために運転手がバスの発車を遅らせることで、無駄にバスの発車が遅れることを避けることができる。
なお、第3実施形態と同様に、利用者が余裕でバスに間に合う場合でも、乗車要望を通知するメッセージを車載端末3に送信する構成として、事前に利用者の座席を確保するための車内アナウンスを運転手に行わせる場合、乗車要望の撤回を運転手に通知することで、無駄な座席の確保をやめることができる。
次に、第6実施形態に係る歩行者端末1および車載端末3の概略構成について説明する。図30は、歩行者端末1および車載端末3の概略構成を示すブロック図である。
歩行者端末1の構成は、第1実施形態の変形例(図9参照)と略同様であるが、制御部13が、乗車中止状態検知部29を備えている。この乗車中止状態検知部29は、利用者がバスに乗車することをやめた乗車中止状態を検知する。この乗車中止状態検知部29で利用者の乗車中止状態を検知すると、メッセージ制御部21において、乗車要望の撤回を通知するメッセージを生成してITS通信部32から送信する。
また、本実施形態では、利用者の位置情報に基づいて、利用者の乗車中止状態として、同一の場所に所定時間以上滞留している状態と、バス停から遠ざかる方向に移動している状態とを検知する。同一の場所に所定時間以上滞留している状態は、利用者に急な体調不良や怪我などの異常が発生した場合である。バス停から遠ざかる方向に移動している状態は、急な予定の変更で別の場所に向かう場合や、忘れ物などのために引き返した場合である。なお、乗車中止を指示する利用者の端末の操作によって、乗車中止状態を検知するようにしてもよい。
車載端末3の構成は、第1実施形態の変形例(図9参照)と同様であるが、制御部33の画面生成部45は、歩行者端末1から乗車要望の撤回を通知するメッセージをITS通信部32で受信すると、乗車要望を撤回した利用者に関する情報を案内画面から削除する処理を行う。合わせて乗車要望の撤回があったことを個別に表示するようにしてもよい。
次に、第6実施形態に係る歩行者端末1から送信されるメッセージについて説明する。図31は、歩行者端末1から送信されるメッセージの内容を示す説明図である。
本実施形態では、第1実施形態(図5(A)参照)と同様に、利用者の歩行者端末1において、乗車要望通知条件を満足する場合に、乗車要望を通知するメッセージを送信するが、本実施形態では、さらに、利用者の乗車中止状態を検知すると、乗車要望の撤回を通知するメッセージを送信する。このメッセージでは、図31(A)に示すように、メッセージの自由領域に、乗車要望撤回情報が格納される。この乗車要望撤回情報は、乗車要望を撤回する場合には「1」となり、乗車撤回を撤回しない場合には「0」となる。
図31(B),(C)は、歩行者端末1から送信されるメッセージの別例である。
図31(B)に示す例では、自由領域に、通知有無情報および通知識別情報が格納される。通知有無情報は、通知があるか否かを表す情報であり、乗車要望および乗車要望の撤回のいずれかを通知する場合には「1」となり、乗車要望および乗車要望撤回のいずれも通知しない場合には「0」となる。通知識別情報は、通知が乗車要望と乗車要望撤回とのいずれであるかを識別する情報であり、乗車要望である場合には「0」となり、乗車要望撤回である場合には「1」となる。
図31(C)に示す例では、図31(B)に示す例と同様に、自由領域に、通知有無情報および通知識別情報が格納され、さらに、利用者状態情報が格納される。この利用者状態情報は、利用者が同一の場所に所定時間以上滞留している場合に「1」となり、バス停から遠ざかる方向に移動している場合に「0」となる。
次に、第6実施形態に係る歩行者端末1および車載端末3の動作手順について説明する。図32は、歩行者端末1および車載端末3の動作手順を示すフロー図である。
歩行者端末1では、第1実施形態の変形例(図11参照)と同様に、ST101からST103、ST111、ST112、ST107からST109の処理を行う。
次に、乗車中止状態検知部29において乗車中止状態を検知したか否かを判定する(ST171)。ここで、乗車中止状態を検知した場合に(ST171でYes)、乗車要望の撤回を通知するメッセージをITS通信部12から送信する(ST172)。
車載端末3では、第1実施形態の変形例(図11参照)と同様に、ST201、ST211、ST212、ST203からST207の処理を行う。
次に、歩行者端末1から乗車要望の撤回を通知するメッセージをITS通信部32で受信すると(ST271でYes)、受信したメッセージに含まれる乗車要望撤回情報に基づいて、案内画面を更新し、バスの乗車を中止した利用者に関する情報を案内画面から削除する(ST272)。
(第6実施形態の変形例)
次に、第6実施形態の変形例について説明する。なお、ここで特に言及しない点は前記の実施形態と同様である。図33は、第6実施形態の変形例に係る乗車支援システムの全体構成図である。
第6実施形態では、利用者の乗車中止状態を検知して、乗車要望の撤回を通知するメッセージを、利用者の歩行者端末1からバスの車載端末3に送信するようにしたが、利用者の乗車中止状態、特に、利用者が同一の場所に所定時間以上滞留していることを検知した場合、利用者に急な体調不良などの異常が発生したものと想定されることから、高齢者の見守りに活用することができる。
そこで、本変形例では、バス停の近傍などの道路上に設置された路側機5が、バスの車載端末3と路車間通信を行い、利用者の家族などの保護者が使用する保護者端末6が、インターネットやセルラー通信網などのネットワークを介して、路側機5と通信を行うように構成し、利用者の歩行者端末1から乗車要望の撤回を通知するメッセージがバスの車載端末3に送信されると、異常通知を、バスの車載端末3から路側機5およびネットワークを経由して保護者端末6に送信する。
この場合、図31(C)に示したように、利用者状態情報を含むメッセージを利用者の歩行者端末1からバスの車載端末3に送信し、利用者状態情報が「1」となる場合、すなわち、乗車中止状態として、利用者が同一の場所に所定時間以上滞留していることを検知した場合、バスの車載端末3から異常通知を保護者端末6に送信する。
このように本変形例では、異常通知を保護者端末6に送信するため、高齢者に異常が発生したことを、家族などの保護者に通知することができる。
なお、事前に、保護者端末6の宛先情報を歩行者端末1のユーザIDに対応付けて路側機5に登録しておけばよい。また、異常通知に、利用者に異常が発生したことを表す情報とともに、利用者の位置情報を付加して送信すると、利用者の位置を保護者が把握することができる。
また、本実施形態では、異常通知をバスの車載端末3から路側機5を介して保護者端末6に送信するようにしたが、異常通知を利用者の歩行者端末1から路側機5を介して保護者端末6に送信するようにしてもよい。
また、本実施形態では、歩行者端末1から車載端末3に乗車要望を通知する場合について説明したが、路側機5を介して車載端末3に乗車要望を通知するようにしてもよい。これによって、特に、バスが利用者から遠い位置にいる場合に、歩行者端末1の消費電力をさらに削減することができる。また、乗車要望を複数の利用者が通知した場合などにおいて、路側機5が複数の乗車要望を1つにまとめて車載端末3に通知することで、歩車間通信のトラフィックを抑えることもできる。
また、路側機5では、歩行者端末1との間でメッセージを送受信する路歩間通信や、車載端末3との間でメッセージを送受信する路車間通信が行われるが、この路歩間通信や路車間通信は、歩車間通信と同様のITS無線通信であり、路歩間通信および路車間通信で送受信されるメッセージは、共通の仕様(データ構成)に基づくものである。
以上のように、本出願において開示する技術の例示として、実施形態を説明した。しかしながら、本開示における技術は、これに限定されず、変更、置き換え、付加、省略などを行った実施形態にも適用できる。また、上記の実施形態で説明した各構成要素を組み合わせて、新たな実施形態とすることも可能である。