図面 (/)

技術 乗車予約利用者支援装置及び乗車予約利用者支援方法

出願人 スズキ株式会社SBドライブ株式会社
発明者 秋田晃久保田整須山温人
出願日 2019年4月10日 (1年10ヶ月経過) 出願番号 2019-074687
公開日 2020年10月22日 (4ヶ月経過) 公開番号 2020-173589
状態 未査定
技術分野 交通制御システム
主要キーワード 補正係数表 待機解除信号 所定時間β シートベルト装着センサ 所定時間α 待機解除 待機要求 予約調整
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年10月22日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (16)

課題

利用者の利便性を高め、かつ、車両運行計画への影響を抑制すること。

解決手段

少なくとも、利用者の端末及び利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部(301)と、端末の位置情報を取得する位置情報取得部(302)と、位置情報が示す地点から乗車予定地までに利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部(303)と、位置情報及び経路情報に基づいて端末が予想経路から外れているか否かを判定する経路外れ判定部(304)と、端末が予想経路から外れている場合、端末に利用者への通知を提供させる通知提供部(305)と、を具備する。

概要

背景

利用者乗り合いバスの利用を予約する乗車予約ステムにおいて、乗り合いバスが乗車予定地到着したときに、利用者が時間通りに間に合わない場合であっても、可能な限り待機していることが利用者の利便性の観点から望ましい。

しかし、利用者が乗車予定地に間に合わない場合にまで待機を行うと、乗り合いバスの運行計画遅延が生じるおそれが高くなるため、好ましくない。そこで、一定条件の下で、乗車予約を取り消すことが考えられる。

例えば、一般交通と、乗車予約が可能なオンデマンド交通とを組み合わせて、目的地まで行く場合、一般交通の遅延情報に基づき、予約したオンデマンド交通の経路部分出発地点への到着日時を再計算し、再計算の結果、予約したオンデマンド交通に間に合わない場合、予約システムに対して、当該予約の取り消しを行なわせることが提案されている(特許文献1等参照)。

概要

利用者の利便性を高め、かつ、車両運行計画への影響を抑制すること。少なくとも、利用者の端末及び利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部(301)と、端末の位置情報を取得する位置情報取得部(302)と、位置情報が示す地点から乗車予定地までに利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部(303)と、位置情報及び経路情報に基づいて端末が予想経路から外れているか否かを判定する経路外れ判定部(304)と、端末が予想経路から外れている場合、端末に利用者への通知を提供させる通知提供部(305)と、を具備する。

目的

本発明は係る点に鑑みてなされたものであり、利用者の利便性を高め、かつ、車両運行計画への影響を抑制できる乗車予約利用者支援装置及び乗車予約利用者支援方法を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

少なくとも、利用者端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部と、前記端末の位置情報を取得する位置情報取得部と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する経路外れ判定部と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる通知提供部と、を具備することを特徴とする乗車予約利用者支援装置

請求項2

前記予想経路は、前記地点から前記乗車予定地までの最短経路を含むことを特徴とする請求項1に記載の乗車予約利用者支援装置。

請求項3

前記通知は、前記車両が前記乗車予定地に到着する車両到着予想時刻を含むことを特徴とする請求項1又は請求項2に記載の乗車予約利用者支援装置。

請求項4

前記通知は、前記利用者に前記車両の待機要否の確認を含むことを特徴とする請求項1から請求項3のいずれかに記載の乗車予約利用者支援装置。

請求項5

前記位置情報取得部が取得した、前記位置情報に基づいて前記利用者が前記乗車予定地に到着する利用者到着予想時刻を取得する到着時刻取得部をさらに具備し、前記経路外れ判定部は、前記利用者到着予想時刻が、前記車両が前記乗車予定地に到着する車両到着予想時刻よりも遅い場合、前記端末に前記利用者への前記通知を提供させることを特徴とする請求項1から請求項4のいずれかに記載の乗車予約利用者支援装置。

請求項6

前記車両が待機している状態において、前記車両の前記乗車予定地からの発車予定時刻から所定時間が経過した後に、前記利用者による乗車予約を取り消す予約調整部をさらに具備することを特徴とする請求項1から請求項5のいずれかに記載の乗車予約利用者支援装置。

請求項7

前記予約調整部は、前記利用者の属性情報に基づいて前記所定時間を調整することを特徴とする請求項6に記載の乗車予約利用者支援装置。

請求項8

前記予約調整部は、前記所定時間の累積時間が1回の運行サイクル内で上限時間未満になるように前記所定時間を調整することを特徴とする請求項6又は請求項7に記載の乗車予約利用者支援装置。

請求項9

前記乗車予約の取り消しがあった場合に、前記通知は、前記利用者に前記乗車予約の取り消しを知らせると共に再予約を促す内容を含むことを特徴とする請求項6から請求項8のいずれかに記載の乗車予約利用者支援装置。

請求項10

前記位置情報取得部により前記端末の前記位置情報を取得できない場合、前記車両に待機を指示する待機指示処理部をさらに具備する請求項6から請求項9のいずれかに記載の乗車予約利用者支援装置。

請求項11

前記前記位置情報取得部により前記端末の前記位置情報を取得できない場合、前記通知提供部は、前記車両が前記乗車予約地に到着したこと示す通知を前記端末に提供することを特徴とする請求項6から請求項10のいずれかに記載の乗車予約利用者支援装置。

請求項12

少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する工程と、前記端末の位置情報を取得する工程と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する工程と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する工程と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる工程と、を具備することを特徴とする乗車予約利用者支援方法

技術分野

0001

本発明は、乗車予約利用者支援装置及び乗車予約利用者支援方法に関する。

背景技術

0002

利用者が乗り合いバスの利用を予約する乗車予約システムにおいて、乗り合いバスが乗車予定地到着したときに、利用者が時間通りに間に合わない場合であっても、可能な限り待機していることが利用者の利便性の観点から望ましい。

0003

しかし、利用者が乗車予定地に間に合わない場合にまで待機を行うと、乗り合いバスの運行計画遅延が生じるおそれが高くなるため、好ましくない。そこで、一定条件の下で、乗車予約を取り消すことが考えられる。

0004

例えば、一般交通と、乗車予約が可能なオンデマンド交通とを組み合わせて、目的地まで行く場合、一般交通の遅延情報に基づき、予約したオンデマンド交通の経路部分出発地点への到着日時を再計算し、再計算の結果、予約したオンデマンド交通に間に合わない場合、予約システムに対して、当該予約の取り消しを行なわせることが提案されている(特許文献1等参照)。

先行技術

0005

特開2014−10818号公報

発明が解決しようとする課題

0006

しかしながら、予約した乗り合いバスの乗車予定地まで利用者が徒歩で向かう場合、特許文献1に記載されたような一般交通の遅延情報を利用した技術は適用できない。

0007

本発明は係る点に鑑みてなされたものであり、利用者の利便性を高め、かつ、車両運行計画への影響を抑制できる乗車予約利用者支援装置及び乗車予約利用者支援方法を提供することを目的とする。

課題を解決するための手段

0008

本発明の一態様の乗車予約利用者支援装置は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部と、前記端末の位置情報を取得する位置情報取得部と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する経路外れ判定部と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる通知提供部と、を具備することを特徴とする。

0009

本発明の一態様の乗車予約利用者支援方法は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する工程と、前記端末の位置情報を取得する工程と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する工程と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する工程と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる工程と、を具備する。

発明の効果

0010

本発明によれば、利用者の利便性を高め、かつ、車両運行計画への影響を抑制できる。

図面の簡単な説明

0011

第1の実施の形態に係る乗車予約利用者支援装置を適用した乗り合いバス予約システム全体を示す模式図である。
第1の実施の形態に係る車両管理サーバ予約管理部を示す機能ブロック図である。
第1の実施の形態に係る端末を示す機能ブロック図である。
第1の実施の形態に係るバスを示す機能ブロック図である。
第1の実施の形態に係る乗り合いバス予約システムにおける処理及びデータのやり取りを示すシーケンス図である。
第1の実施の形態に係る乗り合いバス予約システムにおける利用者支援処理の各処理を示すフローチャート図である。
第1の実施の形態に係る乗り合いバス予約システムにおける通知提供処理の各処理を示すフローチャート図である。
第1の実施の形態に係る乗り合いバス予約システムにおいて端末に提供される通知を含む画面例を示す模式図である。
第1の実施の形態に係る乗り合いバス予約システムにおける利用者支援の具体例を示す説明図である。
第1の実施の形態に係る乗り合いバス予約システムにおける利用者支援の具体例を示す説明図である。
第1の実施の形態に係るサーバ及び端末のハードウェア構成の一例を示す図である。
第2の実施の形態に係る車両管理サーバの予約管理部を示す機能ブロック図である。
第2の実施の形態に係る乗り合いバス予約システムにおける利用者支援処理の一部を示すフローチャート図である。
第2の実施の形態に係る乗り合いバス予約システムにおける通知提供処理の一部を示すフローチャート図である。
第3の実施の形態に係る乗り合いバス予約システムにおける利用者支援処理の一部を示すフローチャート図である。

実施例

0012

以下、本発明の実施の形態について添付図面を参照して詳細に説明する。なお、以下においては、本発明に係る乗車予約利用者支援装置及びその方法を、定時運行を行う無人運転乗り合いバスに適用した例について説明するが、適用対象はこれに限定されることなく変更可能である。例えば、本発明に係る乗車予約利用者支援装置を、利用者の依頼に応じて配車され、利用者及びその同伴者に限り乗車することを前提とした、タクシーのような無人運転車両に適用してもよい。また、車両のタイプは特に限定されることなく、四輪車二輪車三輪車等の鞍乗型車両のどちらのタイプの車両であってもよい。また、無人運転車両は、搭乗員が乗っていても構わない。さらに、車両が、運転手により運転される手動運転車両、及び、運転支援装置が搭載された車両であってもよい。

0013

(本発明の概要
定期運行される無人運転バスの乗車予約システムにおいて、利用者が乗車予定地に向っていない場合、一定条件の下で、乗車予約を取り消すことが、定期運行性の確保の観点から、有効であると考えられる。

0014

そこで、利用者の現在位置と乗車予定地との相対関係に基づいて乗車予約を取り消すことが考えられる。例えば、利用者が乗車予定地から離れていること、又は、利用者が乗車予定地と異なる方向に向かっていることなどを条件として、乗車予約を取り消すことが可能である。しかし、これらの場合、利用者が乗車予定地に向う経路建物があったり、道路工事が行われている等の障害があったり、一時的に乗車予定地から離れていく場合、又は、一時的に異なる方向に向かう場合にも、予約が取り消されてしまい、利用者の利便性が著しく損なわれるという不都合が生じる。

0015

このような事態を回避するために、利用者が車両に対して待機を行うことを要求することが考えられる。利用者からの要求があった場合にのみ車両が待機すればよく、利用者の利便性が高くなる。しかし、要求を行うかどうかは利用者の自主性に委ねられるため、実効性が懸念される。特に、利用者が高齢者の場合、このような懸念が高くなる。

0016

そこで、本発明者らは、鋭意検討を重ねた結果、利用者の端末の移動経路が、利用者の乗車予定地までの所定の径路から外れている場合、適切な通知を行い、利用者の意志を確認し、それに沿った対処を行うことが、利用者の利便性及び車両運行計画への影響抑制に寄与することを見出し、本発明を完成した。

0017

すなわち、本実施の形態に係る乗車予約利用者支援装置は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する予約情報取得部と、前記端末の位置情報を取得する位置情報取得部と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する経路情報取得部と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する経路外れ判定部と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる通知提供部と、を具備する。

0018

また、本実施の形態に係る乗車予約利用者支援方法は、少なくとも、利用者の端末及び前記利用者が車両に乗車する乗車予定地を特定する乗車予約情報を取得する工程と、前記端末の位置情報を取得する工程と、前記位置情報が示す地点から乗車予定地までに前記利用者が用いると予想される予想経路を示す経路情報を取得する工程と、前記位置情報及び前記経路情報に基づいて前記端末が前記予想経路から外れているか否かを判定する工程と、前記端末が前記予想経路から外れている場合、前記端末に前記利用者への通知を提供させる工程と、を具備する。

0019

<第1の実施の形態>
以下、本発明の第1の実施の形態に係る乗車予約利用者支援装置を適用した乗り合いバス運行システムについて、図1図11を参照して、詳細に説明する。

0020

(システム全体)
図1は、第1の実施の形態に係る乗車予約利用者支援装置を適用した乗り合いバス予約システム全体を示す模式図である。図1に示す乗り合いバス予約システム1は、クラウド2に配置された車両管理サーバ3を備えている。車両管理サーバ3には、ネットワークの一例である移動体通信網4を介して、端末5及びバス6が通信可能に接続されている。また、車両管理サーバ3には、インターネット(不図示)を介して、管制用端末7が接続されている。管制用端末7は、移動体通信網4を介して、バス6と通信可能に接続されている。端末5及びバス6は、GNSS衛星8からGNSS信号受信可能に構成されている。なお、図1では、端末5及びバス6は、便宜上、1つずつ示しているが、複数存在していてもよい。

0021

(車両管理サーバ)
車両管理サーバ3は、予約管理部31、運行管理部32及び経路探索部33の各機能を備えている。予約管理部31は、本発明に係る乗車予約利用者支援装置の一例である。利用者への支援の詳細について後述する。また、予約管理部31は、利用者からの乗車予約を受け付けて乗車予約情報(後述)を作成し、運行管理部32に提供するように構成されている。

0022

運行管理部32は、バス6を、運行計画に従って、運行経路予定時刻に従って走らせると共に、バス6の運行状況及び車内状況を把握し、管制用端末7にそれらを出力させるように構成されている。また、運行管理部32は、バス6にバス停停車し、利用者を乗せて、発車するまでの一連の動作(以下、「迎車動作」と記載する)を実行させる。

0023

経路探索部33は、予約管理部31からの情報に基づいて、地図データを参照し、端末5の現在位置からバス停までの利用者が利用すると予想される予想経路を探索するよう構成されている。また、経路探索部33は、端末5及びバス6の現在位置からバス停への到着予想時刻を算出するよう構成されている。経路探索部33は、一般的なカーナビゲーション装置及び経路探索サービスのための経路探索サーバが備えている構成と同様であればよい。
(予約管理部)
図2は、第1の実施の形態に係る車両管理サーバ3の予約管理部を示す機能ブロック図である。予約管理部31は、その機能として、予約情報取得部301、位置情報取得部302、経路情報取得部303、経路外れ判定部304、通知提供部305、到着時刻取得部306、待機指示処理部307、予約調整部308及び乗車予約作成部309を備えている。

0024

予約情報取得部301は、記憶部34に記憶された乗車予約データベース(DB)341を参照し、端末5の利用者が行った乗車予約情報を取得するよう構成されている。乗車予約情報は、少なくとも、利用者の端末5及び利用者が車両に乗車するバス停を特定できる識別情報を含んでいる。識別情報の形式等は特に限定されない。バス停は、本発明の乗車予定地の一例である。

0025

位置情報取得部302は、通信部35を制御し、端末5及びバス6から現在位置情報を受信するよう構成されている。

0026

経路情報取得部303は、端末5の現在位置情報及びバス停の位置情報を経路探索部33に入力し、その応答として、現在位置情報が示す地点からバス停まで利用者が利用すると予想される予想経路を示す経路情報を取得するよう構成されている。ここで、バス停の位置情報は、例えば、緯度経度で表されるが特に限定されない。バス停の位置情報は、乗車予約情報に含まれるバス停を特定できる識別情報に基づいて、運行管理部32(図1参照)が管理し、記憶部34に記憶されているバス停データベース342を参照することにより取得できるが、特に限定されない。

0027

経路外れ判定部304は、端末5の位置情報及び経路情報に基づいて端末5が予想経路から外れているか否かを判定する処理(以下、「経路外れ判定処理」と記載する)を行うよう構成されている。経路外れ判定処理の詳細については後述する。

0028

通知提供部305は、端末5に利用者への通知を提供させる処理(以下、「通知提供処理」と記載する)を行うよう構成されている。具体的には、通知提供部305は、通信部35を制御し、端末5へ所望の通知を行うよう指示する信号(以下、「通知指示信号」と記載する)を送信する。通知指示信号には、例えば、通知内容を特定するための識別情報及び利用者及びバス6の到着予想時刻が含まれるが、特に限定されない。通知提供処理の詳細については後述する。

0029

到着時刻取得部306は、端末5又はバス6の現在位置情報及びバス停の位置情報を経路探索部33に入力し、その応答として、端末5又はバス6がバス停に到着すると予想される時刻(以下、「到着予想時刻」と記載する)を取得するように構成されている。

0030

待機指示処理部307は、端末5から通信部35により受信した待機要求信号(後述)に応じて、バス6に対し、バス停での待機を行うことを指示する信号(以下、「待機指示信号」と記載する)を送信するよう構成されている。また、待機指示処理部307は、バス6に対し、バス停での待機を解除することを指示する信号(以下、「待機解除信号」と記載する)を送信するように構成されている。

0031

予約調整部308は、端末5からの待機要求信号に応じて、待機指示処理部307がバス6への待機指示信号の送信を行い、待機解除信号を送信していない状態(以下、「待機継続状態」と記載する)において、バス6がバス停に到着後所定時間経過後に、利用者による乗車予約を取り消す処理(以下、「予約キャンセル処理」と記載する)を行うように構成されている。

0032

乗車予約作成部309は、端末5と通信部35を介して通信し、乗車予約を受け付け、乗車予約情報を作成し、乗車予約データベース341に登録する処理を行うように構成されている。乗車予約を受け付けるための乗車予約作成部309と端末5とのデータのやり取りや各種処理は、一般的な交通機関の予約システムと同様であり、説明を省略する。

0033

上述のような予約管理部31の各機能は、後述するように車両管理サーバ3を実現するためのコンピュータ装置1000(図11参照)のプロセッサ1001がプログラムを実行し、通信部35を制御して信号等を送受信し、又は、記憶部34に対しデータ等を書き込み及び読み出しすることにより実現することができる。

0034

(端末)
図3は、第1の実施の形態に係る端末5を示す機能ブロック図である。図3に示すように、端末5は、演算部51により実現される機能として、乗車予約処理部501、通知出力部502、現在位置出力部503、待機要求処理部504及び操作受付部505を備えている。

0035

乗車予約処理部501は、車両管理サーバ3の乗車予約作成部309(図2参照)と、通信部52により移動体通信網4(図1参照)を介して通信し、乗車予約を行うように構成されている。乗車予約を行うための乗車予約作成部309とのデータのやり取りや各種処理は、一般的な交通機関の予約システムと同様であり、説明を省略する。

0036

通知出力部502は、通知提供部305(図2参照)からの通知指示信号に応じて、出力部53を制御し、利用者への通知を行うように構成されている。通知は、例えば、出力部53の一例である表示部に通知内容を表示することにより行われるが特に限定されない。例えば、通知内容を出力部53の一例であるスピーカーから音声出力してもよい。通知内容は、記憶部54に記憶された通知データ541に基づいてもよいし、通知指示信号に含められ、又は、付随して通知提供部305から受信した情報(例えば、到着予想時刻)に基づいていてもよい。

0037

現在位置出力部503は、GNSS受信部55によりGNSS衛星8(図1参照)からGNSS信号を受信して現在位置情報を取得し、現在位置情報を、通信部52を制御し、車両管理サーバ3の位置情報取得部302へ送信する処理を行うように構成されている。

0038

待機要求処理部504は、利用者による操作に応じ、車両管理サーバ3の待機指示処理部307(図2参照)に対し、通信部52を介して、バス6への待機指示を要求する信号(以下、「待機要求信号」と記載する)を送信するように構成されている。利用者による操作は、入力部56を介して行われ、操作受付部505により受け付けられ、待機要求処理部504に伝えられるように構成されている。

0039

上述のような端末5の各機能は、後述するように端末5を実現するためのコンピュータ装置1000(図11参照)のプロセッサ1001がプログラムを実行し、通信部52を制御して信号等を送受信し、又は、記憶部54に対しデータ等を書き込み及び読み出しすることにより実現することができる。

0040

特に、端末5が、スマートフォン又はタブレットに代表されるように、オペレーションシステム(OS)上で実行されるアプリケーションプログラムにより、様々な機能を実現できる場合、図3を参照して説明した各機能の一部又は全部は、アプリケーションプログラムにより実現されてもよい。

0041

(バス)
図4は、第1の実施の形態に係るバス6を示す機能ブロック図である。なお、バス6が当然に備えている構成(例えば、車輪シートヘッドライト)や任意に備えている構成(空調装置等)については、本実施の形態の説明に必要なものだけを示し、省略している。

0042

図4に示すように、バス6は、演算部61が実現する機能として、自動運転制御部601、ドア開閉制御部602、現在位置出力部603、駆動制御部604、制動制御部605、操舵制御部606、会話制御部607及び運行状況通知部608を備えている。

0043

自動運転制御部601は、車両管理サーバ3の運行管理部32から、通信部62により移動体通信網4(図1参照)を介して通信を行い、運行計画に関する情報を取得し、運行計画に沿った運行経路を無人自動走行し、乗車予約がなされたバス停で迎車動作を実行するように構成されている。

0044

まず、自動運転制御部601は、記憶部63に記憶された地図データ(不図示)を参照し、運行計画で指定された運行経路を走行する。

0045

自動運転制御部601は、無人自動走行に際し、駆動制御部604に、電動モータ等の駆動部64を制御させ、バス6の加減速を行わせる。また、自動運転制御部601は、制動制御部605に、ブレーキ等の制動部65を制御させ、バス6の制動及び停止を行わせる。さらに、自動運転制御部601は、操舵制御部606に、ステアリングモータ等の操舵部66を制御させ、バス6の右左折等を行わせる。

0046

より具体的には、自動運転制御部601は、センサ67の一つである前方カメラからの検知信号に従って、前方車両との距離を把握し、車間を維持するように、駆動部64及び制動部65の制御を実行する。ここで、前方カメラの他、前方センサミリ波レーダ、LIDAR等)を用いてもよい。

0047

また、自動運転制御部601は、センサ67の一つである前方カメラからの検知信号に基づいて、障害物を検知したとき、制動部65を制御し、バス6を停止する制御を実行し、又は、操舵部66を制御し、バス6を方向転換し、障害物を回避する制御を実行する。

0048

このように自動運転制御部601は、例えば、SAEInternationalにより定義された自動運転ベル4又は5に相当する自動運転を行うことができるように構成されるが、特に限定されるものではない。

0049

また、自動運転制御部601は、バス停において利用者を乗車させるときは、操舵部66を制御して、バス停近くの路肩にバス6を寄せ、次いで、制動部65を制御し、バス6を停車させる。その後、自動運転制御部601は、ドア開閉制御部602に、ドア開閉駆動部70を制御させ、ドアを開き、利用者を乗車させる。このようなバス停に停車する一連の動作を、以下、バス停停車動作と記載する。

0050

また、自動運転制御部601は、センサ67の一つであるドアセンサにより、ドアが閉っていること、及び、センサ67の一つであるシートベルト装着センサにより、利用者が着座し、シートベルトを装着したことを確認(以下、「安全確認」と記載する)し、利用者の安全を確保した後、バス6を発車させる。このようなバス6がバス停から発車する一連の動作を、以下、バス停発車動作と記載する。バス停発車動作の中で行われる安全確認の結果は、自動運転制御部601が、通信部62を制御し、運行管理部32(図1参照)に送信される。運行管理部32は、安全確認の結果を、記憶部34(図2参照)に記録し、また、管制用端末7へ出力し、管制担当者に通知する。

0051

現在位置出力部603は、GNSS受信部68によりGNSS衛星8(図1参照)からGNSS信号を受信して現在位置情報を取得し、現在位置情報を、通信部62を制御し、車両管理サーバ3の位置情報取得部302へ送信する処理を行うように構成されている。

0052

会話制御部607は、通信部62を制御し、移動体通信網4(図1)を介して、管制用端末7と通信を行い、管制担当者による利用者との会話を実現するように構成されている。バス6において、入力部69の一つであるマイクにより利用者の音声を受け付けると共に、出力部71の一つであるスピーカーから管制担当者の音声を出力する。音声に代えて、または音声に加えて、ディスプレイでのテキスト表示を行ってもよい。

0053

運行状況通知部608は、自動運転制御部601からの情報、ドアセンサ、シートベルト装着センサなどにより、バス停での停車、利用者の乗車、バス停からの発車などの運行状況通知を作成し、通信部62を制御して、移動体通信網4(図1参照)を介して、予約管理部31及び運行管理部32に運行状況通知を送信するように構成されている。

0054

上述のようなバス6の各機能は、ECU(Electronic Control Unit)及び/又は車載コンピュータにより実現することができる。例えば、車載コンピュータの構成は、基本的には、後述するように端末5を実現するためのコンピュータ装置1000(図11参照)と同等である。したがって、プロセッサ1001がプログラムを実行し、通信部62を制御して信号等を送受信し、又は、記憶部63に対しデータ等を書き込み及び読み出しすることにより、バス6の各機能を実現することができる。また、ECUのように、マイクロコントローラマイコン)により、バス6の各機能が実現されていてもよい。

0055

(オンデマンド交通)
第1の実施の形態では、定期運行を行う乗り合いバスにおいて乗車予約があったバス停にバス6が停車する場合を例に挙げて説明する。本発明が適用される交通機関の他の態様としては、オンデマンド交通(デマンド型交通ともいう)を挙げることができる。オンデマンド交通には、例えば、以下のタイプが含まれるが、特に限定されるものではない。本発明の主題は、乗車予約があったバス停に利用者が現れない場合の対処であり、車両の運行形式に依存しない。

0056

(1)定路線
一般的な路線バスのように一定の経路を巡回し、バス停に停止するが、車両予約があった場合のみ運行する。
(2)自由経路ドアツードア
運行エリアは決まっているものの、一般的なタクシー事業のように運行経路を定めず、需要に応じ、乗降場所の指定も行わない。この場合、乗車予定地は、利用者が指定する任意の地点であってよく、例えば、自宅であってもよい。
(3)迂回経路・エリアデマンド型
定路線型を基本とし、予約があった場合に予め定められた迂回経路やエリアへ運行する。
(4)自由経路ミーティングポイント
運行経路は定めず、予約があったバス停間を結ぶ最短経路を運行する。

0057

しかしながら、本実施の形態は、オンデマンド交通に限定されるものではなく、タクシー等の予約配車にも適用することができる。

0058

(乗車予約からバス発車までの処理)
図5は、第1の実施の形態に係る乗り合いバス予約システム1における処理及びデータのやり取りを示すシーケンス図である。図5に示すように、まず、端末5から車両管理サーバ3の予約管理部31に対し、乗車予約が行われる(S1)。このとき、予約管理部31は、端末5から、例えば、利用者、利用者の端末5、利用日利用経路乗車バス停及び降車バス停に関する情報を受け取る。

0059

予約管理部31は、端末5から受け取った情報に基づいて、乗車予約情報を作成する(S2)。乗車予約情報は、例えば、利用者を識別する利用者ID、利用者の端末5を識別する端末ID、利用日、利用経路を識別する利用経路ID、乗車バス停を識別する乗車バス停ID及び降車バス停を識別する降車バスIDや、利用者の乗車区間に応じて予め定められる運賃を識別する運賃IDを含む。予約管理部31は、作成した乗車予約情報を乗車予約データベース341(図2参照)に登録する。

0060

次に、予約管理部31は、乗車予約情報に従って、乗車バス停での停車を行う旨の要求(以下、「バス停停車要求」と記載する)を、運行管理部32に送信する(S3)。バス停停車要求には、利用日及び利用経路ID及び乗車バス停IDが含まれる。

0061

運行管理部32は、バス停停車要求に応じて、バス停での停車を行う旨の指示(以下、「バス停停車指示」と記載する)を、バス6に送信する。より具体的には、運行管理部32は、バス停停車要求に含まれる利用日及び利用経路IDに基づいて、記憶部34(図2参照)に記憶された運行計画データベース343を検索して乗車するバス6を特定し、特定されたバス6に対してバス停停車指示を送信する。バス停停車指示には、例えば、乗車予定地のバス停を識別するバス停IDが含まれる。

0062

バス6が、運行に出発すると、定期的に、現在位置情報を予約管理部31の位置情報取得部302(図2参照)に送信する(S5)。図5では、便宜上、1回分だけ示している。

0063

予約管理部31の到着時刻取得部306は、位置情報取得部302が取得したバス6の現在位置情報を経路探索部33(図2参照)に入力し、バス6のバス停への到着予想時刻(以下、「バス到着予想時刻」と記載する)を取得する(S6)。バス到着予想時刻は、本発明の車両到着予想時刻の一例である。次いで、通知提供部305が、バス6の到着予想時刻が現在時刻から所定の時間(例えば、10分)以内になったか否かに基づいて、利用者支援処理(S8)を開始するか否かの判定を行う(S7)。なお、現在時刻は、例えば、時計部(リアルタイムクロック回路等)36(図2参照)から取得できる。利用者支援処理(S8)の詳細については、後述する。

0064

その後、バス6がバス停に到着すると、自動運転制御部601(図4参照)は、バス停停車動作を行い、バス停に停車する(S9)。次いで、運行状況通知部608は、バス6がバス停に停車したことを示す通知(以下、「停車確認通知」と記載する)を、予約管理部31へ送信する(S10)。

0065

その後、自動運転制御部601は、バス停発車動作を行い、バス停から発車する(S11)。次いで、運行状況通知部608は、バス6がバス停を発車したことを示す通知(以下、「発車確認通知」と記載する)を、予約管理部31へ送信する(S12)。

0066

(利用者支援処理)
図6は、第1の実施の形態に係る乗り合いバス予約システム1における利用者支援処理の各処理を示すフローチャート図である。図6に示すように、予約管理部31(図2参照)において、まず、位置情報取得部302が、乗車予約データベース341から乗車予約情報を取得する(S101)。

0067

次いで、位置情報取得部302が、乗車予約情報に基づいて、バス6に乗車予約した利用者の端末5に対し、現在位置情報を要求し、取得する(S102)。

0068

次に、位置情報取得部302が、現在位置情報を取得できたか否か判定する(S103)。S103における判定がNoであれば、処理を終了し、Yesであれば、経路情報取得部303が、端末5の現在位置情報に基づいて、端末5の現在位置情報が示す地点からバス停までに利用者が用いると予想される予想経路を示す経路情報を取得する(S104)。予想経路の詳細については、後述する。

0069

(経路外れ判定処理)
その後、経路外れ判定部304が、S104で取得した経路情報と、端末5から取得する最新の現在位置情報に基づいて、端末5が予想経路から外れているか否かを判定する経路判定処理を行う(S105)。

0070

本実施の形態において、経路外れ判定処理には、一般的なカーナビゲーション装置で行われている経路再検索(リルート)の要否の判定と同じ手法を用いることができる。例えば、端末5から取得した現在位置情報が示す地点を地図上にプロットする。プロットされた複数の地点が示す移動経路と、予想経路とを対比し、経路再検索を行うか否か判定することができる。

0071

経路外れ判定処理(S105)が終了後、その結果に基づいて、利用者が予想経路から外れているか否かを判定する(S106)。S106における判定がYesであれば、通知提供処理(S107)に進む。

0072

S106における判定がNoであれば、到着時刻取得部306が、位置情報取得部302が端末5から取得した最新の現在位置情報を、経路探索部33に入力し、その応答として、端末5、すなわち、利用者がバス停に到着すると予想される到着予想時刻(以下、「利用者到着予想時刻」と記載する)を取得する(S108)。そして、通知提供部305は、利用者到着予想時刻(A)がバス到着予想時刻(B)よりも早い(A<B)か否かに基づいて、利用者が間に合うか否かを判定する(S109)。S109における判定がNoであれば、利用者が間に合わないため、通知提供処理(S107)に進む。一方、S109における判定がYesであれば、S109における判定がYesであれば、利用者が間に合うため、通知提供処理(S107)には進まず、S110に進む。

0073

通知提供部305は、利用者がバス停に到着したか否かを判定する(S110)。利用者がバス停に到着したか否かの判定は、図7に示すS207(後述)と同様である。S110における判定がYesであれば、処理を終了し、Noであれば、S105に戻る。

0074

(通知提供処理)
図7は、第1の実施の形態に係る乗り合いバス予約システム1における通知提供処理の各処理を示すフローチャート図である。通知提供処理(図6中、S107)においては、図7に示すように、まず、通知提供部305が、端末5に対し、バス到着予想時刻の通知を指示する通知指示信号を送信する(S201)。次に、通知提供部305は、端末5に対し、車両の待機要否の確認を行う通知(以下、「待機要求確認通知」と記載する)を行うことを指示する通知指示信号を送信する(S202)。バス到着予想通知(S201)と待機要求確認通知(S202)との順番は限定されず、逆であってもよい。

0075

その後、通知提供部305は、待機要求確認通知(S202)を実行後所定の時間t1が経過したか否かを判定する(S203)。S203における判定がNoであれば、判定を繰り返す。S203における判定がYesであれば、通知提供部305は、端末5から待機要求信号を受信したか否かを判定する(S204)。S204における判定がNoであれば、通知提供処理を終了する。その後、図6に示す利用者支援処理が終了する。

0076

S204における判定がYesであれば、待機指示処理部307がバス6へ待機指示信号を送信する(S205)。次いで、通知提供部305は、バス6の運行状況通知部608から停車確認通知(図5中、S10)を受信したか否かに基づき、バス6がバス停に停車したか否か判定する(S206)。S206における判定がNoであれば、S206に戻る。したがって、S206は、バスが停車するまで繰り返えされる。一方、S206における判定がYesであれば、通知提供部305は、バス6がバス停に到着したことを示す通知(以下、「バス到着通知」と記載する)を行うことを指示する通知指示信号を送信する(S212)。

0077

次いで、通知提供部305は、利用者がバス停に到着したか否かを判定する(S207)。利用者がバス停に到着したか否かは、例えば、端末5の最新の現在位置情報が示す地点がバス停から所定の範囲内であるか否かに基づいて判断することができるが、特に限定されない。S207における判定がYesであれば、S211(後述)に進む。

0078

S207における判定がNoであれば、予約調整部308は、バス6から停車確認通知(図5中、S10)を受信後、所定の時間t2が経過したか否かを判定する(S208)。S208における判定がNoであれば、S207に戻る。S208における判定がYesであれば、予約調整部308は、乗車予約を取り消す(S209)。乗車予約が取り消された場合、通知提供部305は、端末5に対し、乗車予約を再び行う再予約を促す通知を指示する通知指示信号を送信する(S210)。その後、待機指示処理部307がバス6へ待機解除信号を送信(S211)し、通知提供処理を終了する。その後、図6に示す利用者支援処理が終了する。

0079

(画面例)
図8は、第1の実施の形態に係る乗り合いバス予約システム1において端末5に提供される通知を含む画面例を示す模式図である。図8Aは、バス到着予想時刻と、待機の要否の確認の両方を含む画面例である。図8Aに示す画面81は、図7に示すS201及びS202での通知指示信号に応じて、端末5の通知出力部502(図3参照)が、出力部53の一例である表示部に表示させる。図8Aに示すように、画面81は、現在時刻82、バス到着予想時刻83、待機指示ボタン84、及び、キャンセルボタン85を含む。待機指示ボタン84は、利用者の、待機が必要であるとの意志に基づき、利用者による操作を受け付けるためのユーザーインターフェイスである。例えば、表示部がタッチパネルディスプレイである場合、待機指示ボタン84に対応するタッチパネルに指などを触れることにより、利用者の操作を受け付けることができる。操作受付部505により待機指示ボタン84に対する操作が受け付けられると、待機要求処理部504が車両管理サーバ3の待機指示処理部307(図1、2参照)へ待機要求信号を送信し、端末5からの待機要求が行われる。

0080

また、操作受付部505によりキャンセルボタン85に対する操作が受け付けられた場合、乗車予約処理部501が予約調整部308に予約キャンセル要求信号を送信する。

0081

図8Aに示す画面81では、バス到着予想時刻83は、時刻で形式されているが、バス到着予想時刻と現在時刻との差、すなわち残り時間で表示してもよい。

0082

図8Bは、利用者による再予約を促す画面例である。図8Bに示す画面86は、図7に示すS210での通知指示信号に応じて、端末5の通知出力部502(図3参照)が表示部に表示させる。図8Bに示すように、画面86は、乗車予約の取り消しを利用者に知らせるキャンセル通知87を含む。

0083

また、画面86は、OKボタン88及び次回予約ボタン89を含む。次回予約ボタン89は、利用者により、再予約を行うとの意志に基づき、利用者による操作を受け付けるためのユーザーインターフェイスである。次回予約ボタン89に対する操作が操作受付部505により受け付けられると、乗車予約処理部501による乗車予約が行われる。OKボタン88に対する操作が操作受付部505により受け付けられると、端末5での今回の乗車予約に対する一連の処理が終了する。

0084

(具体例)
図9、10は、第1の実施の形態に係る乗り合いバス予約システム1における利用者支援の具体例を示す説明図である。

0085

以下の具体例では、車両管理サーバ3の経路探索部33(図1参照)は、端末5の現在位置情報が示す地点とバス停との最短経路を予想経路とする。

0086

図9は、利用者91がバス停92までに利用すると予想される予想経路が一つである場合を示す。予想経路に沿って利用者91が移動していった場合、バス停92から距離的にはいったん遠ざかり、かつ、その移動方向もバス停92とには向っていない。このような場合であっても、第1の実施の形態に係る利用者支援処理では、予想経路から利用者が外れていないので、乗車予約は取り消されることがない。

0087

予想経路が複数あってもよい。図10は、利用者91がバス停92までに利用すると予想される予想経路が、最短経路とその次に短い経路(以下、「次点経路」と記載する)の2つである場合を示す。この例では、最短経路を利用者91が利用した場合、到着予想時刻は現在時刻から5分後であり、次点経路を利用した場合、到着予想時刻は現在時刻から10分後である。また、バス6のバス到着予想時刻は現在時刻から5分後である。したがって、利用者91が最短経路を利用した場合にはバス到着予想時刻までにバス停92に到着できる。一方、利用者91が次点経路を利用した場合にはバス到着予想時刻までにバス停92に間に合わない。この場合、バス6が到着したときに端末5(図1参照)にバス到着通知(図7に示すS111)が行われる。

0088

図10に示す例において、バス6のバス到着予想時刻が10分後以上である場合、最短経路及び次点経路のいずれであっても、利用者はバス到着予想時刻までにバス停92に到着できる。このため、利用者は最短経路及び次点経路のいずれの経路を選択しても、間に合う。しかし、バス到着予想時刻が5分後である場合は、利用者の選択肢は、最短経路しかない。そこで、図10に示す分岐点が経路上に存在するとき、通知提供部305(図2参照)は、バス到着予想時刻と最短経路及び次点経路をそれぞれ利用したときの利用者の到着予想時刻とを比較する。そして、最短経路及び次点経路のいずれを利用しても利用者が間に合うと判定した場合には、通知提供部305は、分岐点において、その旨の通知を端末5で行なわせることが好ましい。

0089

このように、予想経路は一つには限定されない。また、最短経路は予想経路の一例に過ぎず、他の基準に基づいて選択された経路を予想経路として用いることができる。

0090

(ハードウェア構成)
なお、上記実施の形態の説明に用いた機能ブロック図は、機能単位ブロックを示している。これらの機能ブロック(構成部)は、ハードウェア及び/又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的に結合した1つの装置により実現されてもよいし、物理的に分離した2つ以上の装置を有線又は無線で接続し、これら複数の装置により実現されてもよい。

0091

図11は、第1の実施の形態に係るサーバ及び端末のハードウェア構成の一例を示す図である。車両管理サーバ3、端末5及びバス6の車載コンピュータなどを構成するコンピュータ装置1000は、物理的には、プロセッサ1001、メモリ1002、ストレージ1003、通信装置1004、入力装置1005、出力装置1006、センサ1007、内部バス1008などを含むコンピュータ装置1000として構成されてもよい。

0092

なお、以下の説明では、「装置」という文言は、回路デバイスユニットなどに読み替えることができる。ハードウェア構成は、図に示した各装置を1つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

0093

例えば、プロセッサ1001は1つだけ図示されているが、複数のプロセッサがあってもよい。また、処理は、1のプロセッサで実行されてもよいし、処理が同時に、逐次に、又はその他の手法で、1以上のプロセッサで実行されてもよい。

0094

車両管理サーバ3、端末5、バス6などにおける各機能は、プロセッサ1001、メモリ1002などのハードウェア上に所定のソフトウェア(プログラム)を読み込ませることで、プロセッサ1001が演算を行い、通信装置1004による通信や、メモリ1002及びストレージ1003におけるデータの読み出し及び/又は書き込みを制御することで実現される。

0095

プロセッサ1001は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ1001は、周辺装置とのインターフェース制御装置演算装置レジスタなどを含む中央処理装置(CPU:Central Processing Unit)で構成されてもよい。プロセッサ1001は、1以上のチップ実装されてもよい。

0096

また、プロセッサ1001は、プログラム(プログラムコード)、ソフトウェアモジュールやデータを、ストレージ1003及び/又は通信装置1004からメモリ1002に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。

0097

メモリ1002は、記憶部34、54、63(図2、3、4参照)の一例であり、コンピュータ読み取り可能な記録媒体であり、例えば、ROM(Read Only Memory)、EPROM(Erasable Programmable ROM)、EEPROM(Electrically EPROM)、RAM(Random Access Memory)、その他の適切な記憶媒体の少なくとも1つで構成されてもよい。メモリ1002は、レジスタ、キャッシュメインメモリ主記憶装置)などと呼ばれてもよい。メモリ1002は、本発明に係る乗車予約利用者支援装置を実現するために実行可能なプログラム(プログラムコード)、ソフトウェアモジュールなどを保存することができる。

0098

ストレージ1003は、記憶部34、54、63(図2、3、4参照)の一例であり、コンピュータ読み取り可能な記録媒体であり、例えば、フレキシブルディスクフロッピー(登録商標ディスク光磁気ディスク(例えば、コンパクトディスクCD−ROM(Compact Disc ROM)など)、デジタル多用途ディスク、Blu−ray(登録商標)ディスク)、リムーバブルディスクハードディスクドライブスマートカードフラッシュメモリデバイス(例えば、カードスティックキードライブ)、磁気ストライプ、データベース、サーバ、その他の適切な記憶媒体の少なくとも1つで構成されてもよい。ストレージ1003は、補助記憶装置と呼ばれてもよい。

0099

通信装置1004は、通信部35、52、62(図2、3、4参照)の一例であり、有線及び/又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア(送受信デバイス)であり、例えばネットワークデバイスネットワークコントローラネットワークカード通信モジュールなどともいう。

0100

入力装置1005は、入力部56、69(図2、3、4参照)の一例であり、外部からの入力を受け付ける入力デバイス(例えば、キーボードマウスなど)である。出力装置1006は、出力部53、71(図2、3、4参照)の一例であり、外部への出力を実施する出力デバイス(例えば、ディスプレイ、スピーカーなど)である。なお、入力装置1005及び出力装置1006は、一体となった構成(例えば、タッチパネル)であってもよい。

0101

また、プロセッサ1001やメモリ1002などの各装置は、情報を通信するための内部バス1008で接続される。

0102

また、車両管理サーバ3、端末5及びバス6の車載コンピュータなどは、マイクロプロセッサデジタル信号プロセッサ(DSP:Digital Signal Processor)、ASIC(Application Specific IntegratedCircuit)、PLD(Programmable Logic Device)、FPGA(Field Programmable Gate Array)などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ1001は、これらのハードウェアの少なくとも1つで実装されてもよい。

0103

また、第1の実施の形態において、クラウド2(図1参照)と管制用端末7との間の通信に用いられるネットワークは、インターネット、モバイルネットワーク、LAN(Local Area Network)、WAN(Wide Area Network)などの様々なネットワークを含む。なお、ネットワークは、無線、有線又はこれらの組み合わせで構成されてもよい。例えば、無線通信方式としては、Bluetooth(登録商標)、無線LAN(例えば、IEEE802.11規格準拠)、LTE(Long Term Evolution)、又はその他の無線通信方式を利用することができる。

0104

また、移動体通信網4(図1参照)は、例えば、LTE又はその他の無線通信方式を利用することができる。

0105

以上説明したように、第1の実施の形態によれば、利用者がバス停に予想経路を用いて移動していない場合であっても、利用者の意志を確認し、それに沿った対処を行い、利便性を高めると共に、バス6の運行計画への影響を抑制できる。

0106

例えば、利用者がバス停に到着していない場合に、バス到着予定時刻及びバス到着を通知することにより、利用者は、早い段階に次の便への予約の変更や乗り遅れないように移動を早めるなどの対処を行うことでき、かつ、バス6の定時運行性を確保できるようになる。

0107

また、利用者がバス停に到着していない場合に、利用者にバス6の待機の要否を確認することにより、バス6の待機時間を最小化しつつ利用者がバス6に乗り遅れるのを防ぐことができる。

0108

また、予約が自動的に取り消されることを利用者が確認でき、かつ、次回の予約をすぐに行うことができるので、利用者の便宜性を維持しつつ、バス6の定時運行性を確保できるようになる。

0109

<第2の実施の形態>
次に、第2の実施の形態について、第1の実施の形態との相違を中心に説明する。以下の説明において、第1の実施の形態と同様の構成については、同一の符号を用い、説明を省略する。

0110

図12は、第2の実施の形態に係る車両管理サーバ3の予約管理部を示す機能ブロック図である。図12に示す予約管理部31は、記憶部34が利用者データベース344及び補正係数表345を記憶している点で、第1の実施の形態と異なる。

0111

利用者データベース344には、利用者ごとに利用者のバス停までの移動に関する属性情報が登録されている。属性情報は、例えば、年齢妊娠の有無、身体障害者認定の有無、車いすの利用の有無、ベビーカーの利用の有無が含まれるが特に限定されない。

0112

補正係数表345は、属性情報に基づいて所定時間α及びβを補正する補正係数Cを定めたものである。表1にその一例を示す。

0113

0114

第1の実施の形態では、通知提供部305は、図6に示すフローチャートのS109において、利用者到着予想時刻(A)がバス到着予想時刻(B)よりも早い(A<B)か否かに基づいて、利用者が間に合うか否かを判定している。第2の実施形態では、利用者の実情に合わせてバス到着予想時刻を調整する。

0115

図13は、第2の実施の形態に係る乗り合いバス予約システム1における利用者支援処理の一部を示すフローチャート図である。図13に示すように、S109’において、通知提供部305は、A<B+(α×C)を満たすか否かを判定し、満たさない場合(S109’における判定がNo)に通知提供処理(S107)を行わせる。

0116

すなわち、利用者が利用者到着予想時刻の通りに到着できない場合を考慮し、バス到着予想時刻Bに所定時間αを加えている。所定時間αは例えば10分のように任意に定めることができる。さらに、通知提供部305は、利用者の属性情報に基づいて、補正係数表345で定められた補正係数Cを取得し、これを用いて所定時間αを補正している。

0117

これにより、バス到着予想時刻(B)よりも所定時間αの分だけ利用者が予想より遅くなると想定し、通知提供処理(S107)を行わせることができると共に、所定時間αには利用者の属性情報に応じた補正が行われる。この結果、利用者が高齢であったり、車いすを利用していたり、というような実情に合わせ、通知提供処理(S107)を行うか否か判定できるので、利用者の利便性をより向上できる。

0118

また、第1の実施の形態では、図7に示す通知提供処理において、予約調整部308は、バス6から停車確認通知を受信後、所定の時間t2が経過した場合に乗車予約を取り消す(S208、S209)。ここでの判定には、運行計画で定められたバス発車予定時刻は考慮に入っていない。

0119

図14は、第2の実施の形態に係る乗り合いバス予約システム1における通知提供処理の一部を示すフローチャート図である。図14に示すように、S208’において、予約調整部308は、現在時刻Tc、発車予定時刻Td、所定時間β、及び、補正係数Cとしたとき、Tc>Td+(β×C)を満たすか否かを判定する。そして、満たされる場合に乗車予約の取り消し(S209)を行い、その後、待機指示処理部307が、待機解除送信(図7中、S211)を行う。

0120

すなわち、発車予定時刻Tdに所定時間βを加えることにより、発車予定時刻Tdになったらすぐに乗車予約が取り消し(S209)されることがないように調整を行っている。所定時間βは例えば10分のように任意に定めることができる。さらに、予約調整部308は、利用者の属性情報に基づいて、補正係数表345で定められた補正係数Cを取得し、それを用いて所定時間βを補正している。

0121

これにより、発車予定時刻(Td)から少なくとも所定時間β×補正係数Cの分だけ経過した後、乗車予約の取り消し(S209)が行われ、待機指示が解除(S211)されて、バス6がバス停から発車できるようになる。このため、発車予定時刻(Td)からの発車遅延を必要最低限に抑えられると共に、所定時間βには利用者の属性情報に応じた補正が行われる。この結果、利用者が高齢であったり、車いすを利用していたり、というような実情に合わせ、通知提供処理(S107)を行うか否か判定できるので、利用者の利便性をより向上でき、且つ、バス6の定時運行性を高めることができる。

0122

また、第2の実施の形態では、経路外れ(図6中、S106における判定がYes)があった場合、及び、利用者がバス6の到着までに間に合わない場合(S109における判定がNo)には、バス6の待機が発車予定時刻(Td)から所定時間β×補正係数Cの分まで行われる。したがって、利用者の実情に合わせ、バス6の待機時間が調整されるので、利用者の便利性をより向上できる。

0123

ここで、所定時間βは、バス6の、利用者がバス停に到着するまでの待ち時間に相当する。そこで、式(1)に示すように、所定時間βの積算値、すなわち累積時間が、1回の運行サイクル始発バス停から終着バス停まで)で上限時間γ未満になるように調整することが好ましい。

0124

0125

これにより、利用者による待機要求が長く継続した場合であっても、運行サイクルにおける運行管理と車両制御を調節することで遅れを取り戻すことができるため、バス6の定時運行性を確保することができる。

0126

第2の実施の形態では、所定時間α、βを利用者の属性情報に従って補正しているが、他の情報(例えば、バス6の運行経路の交通混雑状況)を加えて補正してもよい。

0127

以上説明したように、第2の実施の形態によれば、第1の実施の形態と同様の効果を奏すると共に、利用者の属性に応じて必要な利用者支援を行うことで、利用者の利便性をより一層高め、かつ、バス6の運行計画への影響を抑制できる。

0128

また、第2の実施の形態によれば、利用者の年齢などに合わせ、バス6の待機時間を延長できると共に、上限時間γ内で調整することにより、バス6の運行計画への影響を最小化できる。

0129

<第3の実施の形態>
次に、第3の実施の形態について、第1、第2の実施の形態との相違を中心に説明する。以下の説明において、第1、第2の実施の形態と同様の構成については、同一の符号を用い、説明を省略する。

0130

第1、第2の実施の形態では、図6のS103で端末5(図1参照)の現在位置情報を取得できなかった場合に、利用者支援処理を終了しているが、第3の実施の形態では、このような場合にも可能な限り、利用者の支援を行う点で相違する。

0131

図15は、第3の実施の形態に係る乗り合いバス予約システム1における利用者支援処理の一部を示すフローチャート図である。S103で端末5の現在位置情報を取得できないと判定した場合、通知提供部305は、バス6の運行状況通知部608から停車確認通知(図5中、S10)を受信したか否かに基づき、バス6がバス停に停車したか否か判定する(S301)。S301における判定がNoであれば、S301に戻る。したがって、S301は、バスが停車するまで繰り返えされる。

0132

次いで、通知提供部305は、バス到着通知を行うことを指示する通知指示信号を送信する(S302)。その後、予約調整部308は、図14に示すS208’と同様に、Tc>Td+(β×C)を満たすか否かを判定する(S303)。そして、満たされる場合に乗車予約の取り消し(S304)を行い、その後、待機指示処理部307が、待機解除送信(S305)を行い、処理を終了する。ここで、乗車予約の取り消し(S304)及び待機解除送信(S305)は、図7中のS209及びS211と同様の処理である。なお、乗車予約の取り消し(S304)が行われた後、通知提供部305は、端末5に対し、乗車予約を再び行う再予約を促す通知を指示する通知指示信号を送信してもよい(図7中のS210参照)。

0133

これにより、端末5から現在位置情報取得できず、利用者の位置が検出できない場合、待機指示がどこから送信されているのか確認できない、又は、バス停に到着している可能性があるため、待機指示は行わずにバス到着通知のみを行うことができる。また、端末5から現在位置情報を取得できない場合であっても、バス6による待機が行われる。また、発車予定時刻(Td)から少なくとも所定時間β×補正係数Cの分だけ経過した後、乗車予約の取り消し(S209)が行われ、待機指示が解除(S211)されて、バス6がバス停から発車できるようになる。

0134

なお、端末5(図1参照)から現在位置情報を取得できない場合には、以下のような状況が含まれる。
(1)端末5と車両管理サーバ3との間のネットワーク回線(移動体通信網4等)が安定していない。
(2)端末5がGPS衛星8からGPS信号を受信できない。
(3)端末5の電源が切られている、又は、端末5が電波の届かないところにある。
(4)端末5の現在位置情報が示す地点の誤差範囲が、所定の範囲(例えば、200m)以上である。
(5)端末5の現在位置情報が示す地点が安定していない(例えば、所定時間内に100m以上の移動を繰り返す)。

0135

例えば、(1)のようにネットワーク回線が安定していない状況であっても、その後、ネットワーク回線が安定し、通信が復帰したときに通知が行われるようにすることが好ましい。例えば、本実施の形態において、図6を参照して説明したように、通知提供部305は、バス6から停車確認通知(図5中、S10)を受信したか否かを判定(S110)し、判定がYesであれば、通知提供部305は、バス到着通知を行うことを指示する通知指示信号を送信する(S111)。これにより、通信が復帰したときに、利用者はバス6がバス停に到着したことを知ることができるので、利用者の利便性がより向上する。

0136

このように、端末5から現在位置情報を取得できない場合であっても、それを理由にただちに乗車予約を取り消し、また、バス6を必要以上に待機させるという不都合な事態が発生するのを回避できる。

0137

以上説明したように、第3の実施の形態によれば、第1、第2の実施の形態と同様の効果を奏すると共に、端末5が通信できない状況であっても利用者の利便性を高め、かつ、バス6の運行計画への影響を最小限に抑制できる。

0138

例えば、位置情報取得部302(図2参照)により端末5の現在位置情報を取得できない場合、待機指示処理部307がバス6に待機指示信号を送信することにより、端末5が通信できない場合でもバス6を待機させることができる。

0139

また、予約調整部308が、利用者の属性情報に基づいて、所定時間βを補正係数Cで補正することにより、利用者の実情に合わせて待機時間を確保しながら、必要以上に待機が延長されることを抑制できる。

0140

また、本実施の形態及び変形例を説明したが、本発明の他の実施の形態として、上記実施の形態及び変形例を全体的又は部分的に組み合わせたものでもよい。

0141

また、本発明の実施の形態は上記の実施の形態に限定されるものではなく、本発明の技術的思想の趣旨を逸脱しない範囲において様々に変更、置換、変形されてもよい。更には、技術の進歩又は派生する別技術によって、本発明の技術的思想を別の仕方で実現することができれば、その方法を用いて実施されてもよい。従って、特許請求の範囲は、本発明の技術的思想の範囲内に含まれ得る全ての実施形態をカバーしている。

0142

例えば、上記実施の形態においては、乗車予約利用者支援装置を、クラウド2(図1参照)に配置された車両管理サーバ3の一部(予約管理部31)により実現しているが、例えば、バス6に搭載されるカーナビゲーション装置等のような車載装置、利用者が利用するスマートフォン等の移動体通信装置オンプレミスに配置されたサーバ、管制担当者が利用するパーソナルコンピュータのような情報処理装置により実現してもよい。

0143

また、上記実施の形態においては、車両管理サーバ3が、予約管理部31、運行管理部32及び経路探索部33の機能をすべて実現しているが、それぞれの機能を別々のサーバで実現し、それらが連動して、車両管理サーバ3と同等の機能を実現することも、本発明の実施の形態の一つである。

0144

以上説明したように、本発明は、利用者の利便性を高め、かつ、車両運行計画の遅延を防止できるという効果を有し、特に、自動運転乗り合いバスに有用である。

0145

1乗り合いバス予約システム
3車両管理サーバ
5端末
6バス
7管制用端末
8GNSS衛星
31予約管理部
32運行管理部
33経路探索部
34、54、63 記憶部
35、52、62通信部
51、61演算部
53、71 出力部
55、68 GNSS受信部
56、69 入力部
64 駆動部
65制動部
66操舵部
67センサ
70ドア開閉駆動部
301予約情報取得部
302位置情報取得部
303経路情報取得部
304経路外れ判定部
305通知提供部
306到着時刻取得部
307待機指示処理部
308予約調整部
309乗車予約作成部
501 乗車予約処理部
502通知出力部
503、603 現在位置出力部
504待機要求処理部
505操作受付部
601自動運転制御部
602ドア開閉制御部
604駆動制御部
605制動制御部
606操舵制御部
607会話制御部
608運行状況通知部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ