JP2023096084A - 運行管理装置 - Google Patents

Abstract

【課題】路線バスの乗客の利便性の低下を抑制する。
【解決手段】予め定められた運行経路を走行する車両ＳＶの運行管理装置１００ａは、車両に乗車する予定の利用者ｕｓ１の現在位置を含む位置情報を取得する位置情報取得部１８と、取得された位置情報を用いて、利用者の乗車場所である仮想の停留所を設定可能な領域である停留所設定可能領域における利用者に最も近い場所に仮想の停留所を設定する仮想停留所設定部１９と、通信装置４０を介して、利用者に仮想の停留所の位置を通知する通知部１３ａと、を備える。
【選択図】図７

Description

本開示は、運行管理装置に関する。

特許文献１には、路線バスの停留所でバスを待っているユーザの人数を取得し、取得された人数が所定の人数以上である場合、配車センタに臨時バスの配車を要求する技術が開示されている。

特開２０１７－１７４２０３号公報

しかしながら、特許文献１に記載の技術では、マイクロバスや、大型バスなどの中古のバスを路線バスとして再利用する場合の配車に関しては十分に考慮されていないので、路線バスの乗客の利便性を損なうおそれがある。

本開示は、以下の形態として実現することが可能である。

本開示の第１の形態によれば、通信装置（５２）を有する複数のバス（ＵＢ、ＵＢ１、ＵＢ２、ＵＢ３）の配車管理装置（１００）が提供される。この配車管理装置は、前記複数のバスのそれぞれに乗車中の乗客の人数である乗車人数を示す乗車人数情報を、前記複数のバスから取得する乗車人数取得部（１１）と、取得された各前記乗車人数と、前記複数のバスの乗車定員数とを用いて、前記複数のバスのうち混雑が予想されるバスである混雑バスを特定する混雑バス特定部（１２）と、前記混雑バスの停留所に配車すべき追加バスの大きさと台数とを、前記混雑バスの前記乗車人数に応じて決定する配車管理部（１３）と、を備える。

この形態の配車管理装置によれば、混雑バスの停留所に配車すべき追加バスの大きさと台数とを、混雑バスの乗車人数に応じて決定するので、混雑バスの乗客の利便性の低下を抑制できる。

本開示の第２の形態によれば、予め定められた運行経路を走行する車両（ＳＶ）の運行管理装置（１００ａ）が提供される。この運行管理装置は、前記車両に乗車する予定の利用者（ｕｓ１）の現在位置を含む位置情報を取得する位置情報取得部（１８）と、取得された前記位置情報を用いて、前記利用者の乗車場所である仮想の停留所を設定可能な領域である停留所設定可能領域における前記利用者に最も近い場所に前記仮想の停留所を設定する仮想停留所設定部（１９）と、通信装置（４０）を介して、前記利用者に前記仮想の停留所の位置を通知する通知部（１３ａ）と、を備える。

この形態の運行管理装置によれば、車両に乗車する予定の利用者の現在位置を含む位置情報を用いて、利用者の乗車場所である仮想の停留所を設定可能な領域である停留所設定可能領域における利用者に最も近い場所に仮想の停留所を設定し、利用者に仮想の停留所の場所を通知するので、利用者の現在位置から乗車場所までの移動距離を短縮できる。このため、利用者の利便性の低下を抑制できる。

本開示の第３の形態によれば、予め定められた複数の場所（Ａｒ１、Ａｒ２、Ａｒ３、Ａｒ４）に配置されている複数の車両（９１、９２、９３、９４）の配車管理装置（１００ｂ）が提供される。この配車管理装置は、イベントの開催日時と開催場所とを含むイベント情報を取得するイベント情報取得部（２０）と、取得された前記イベント情報を用いて、前記イベントのうち或るイベントの開催日時において必要となる車両の台数を算出する台数算出部（２１）と、各前記場所から前記或るイベントの開催場所までの移動経路をそれぞれ取得する移動経路取得部（２２）と、取得された各前記移動経路における移動時間をそれぞれ取得する移動時間取得部（２３）と、各前記場所から前記或るイベントの開催場所に配車する車両を、前記移動時間が少ない順に決定する配車管理部（１３ｂ）と、を備える。

この形態の配車管理装置によれば、イベントの開催日時と開催場所とを含むイベント情報を取得し、イベント情報を用いて或るイベントの開催日時において必要となる車両の台数を算出し、予め定められた複数の場所から或るイベントの開催場所までの移動経路をそれぞれ取得し、各移動経路における移動時間をそれぞれ取得し、各場所から或るイベントの開催場所に配車する車両を移動時間が少ない順に決定するので、車両をイベントの開催場所に移動させる時間および燃費を低減できる。また、各場所における車両の所有台数が異なる場合であっても、イベントの開催日に必要となる台数の車両を確保できる。

本開示は、種々の形態で実現することも可能である。例えば、配車方法、運行管理方法、配車システム、運行管理システム、これらの方法やシステムを実現するためのコンピュータプログラム、かかるコンピュータプログラムを記憶した記憶媒体等の形態で実現することができる。

配車管理システムのイメージを示す説明図。 配車管理装置の概略構成を示すブロック図。 運行中バスの概略構成を示すブロック図。 運行中バス側の配車処理の処理手順を示すフローチャート。 配車管理装置側の配車処理の処理手順を示すフローチャート。 第２実施形態の運行管理システムのイメージを示す説明図。 第２実施形態の運行管理装置の概略構成を示すブロック図。 仮想停留所設定処理の処理手順を示すフローチャート。 第３実施形態の配車管理システムのイメージを示す説明図。 第３実施形態の配車管理装置の概略構成を示すブロック図。 第３実施形態の配車管理装置側の配車処理の処理手順を示すフローチャート。

Ａ．第１実施形態：
Ａ１．装置構成：
図１から図３に示すように、配車管理システム５００は、運行中の複数の路線バス（以下、「運行中バス」と呼ぶ）ＵＢ１、ＵＢ２およびＵＢ３と、配車管理装置１００とを備える。配車管理システム５００では、運行中バスＵＢ１、ＵＢ２、ＵＢ３および配車管理装置１００において後述の配車処理が実行されることにより、配車管理装置１００が運行中バスＵＢ１、ＵＢ２およびＵＢ３の車室内の混雑状況に応じて、運行中バスＵＢ１、ＵＢ２およびＵＢ３の運行経路上に続行便を配車する。配車管理装置１００は、続行便のバスの大きさおよび台数を、運行中バスＵＢ１、ＵＢ２およびＵＢ３の車室内の混雑状況に基づいて決定する。

３台の運行中バスＵＢ１、ＵＢ２およびＵＢ３は、走行に関する制御の全てが運転手の判断によらずに自動的に実行可能なバスである。自動運転としては、例えば、ＳＡＥにおいて規定されているレベル０～５までの運転レベルのうち、レベル４～５の運転が該当する。図１に示すように、運行中バスＵＢ１、ＵＢ２およびＵＢ３は、それぞれ、送受信アンテナと無線基地局と交換局とを含む通信キャリア１０１を介して、インターネットＩＮＴに接続された配車管理装置１００と通信してデータのやりとりを行いつつ、予め定められた運行経路Ｒ１、Ｒ２およびＲ３を走行している。

運行中バスＵＢ１、ＵＢ２およびＵＢ３は、それぞれ、大きさの異なる中古のバスである。「バスの大きさ」とは、バスの座席数等に応じて予め定められている乗員定員数により定まるバスの種類を意味する。図１に示す例では、運行中バスＵＢ１は、乗員定員数が１０人程度のミニバスであり、運行中バスＵＢ２は、乗員定員数が３０人程度の中型バスであり、運行中バスＵＢ３は、乗員定員数が２０人程度のマイクロバスである。各運行中バスＵＢ１、ＵＢ２およびＵＢ３には、図１に示す乗車人数の乗客が乗車している。以降の説明では、各運行中バスを区別する場合、運行中バスＵＢ１、ＵＢ２およびＵＢ３と呼び、各運行中バスを区別しない場合には、総称して運行中バスＵＢと呼ぶ。運行中バスＵＢは、配車管理装置１００からの要求に応じて、運行中バスＵＢの車室内を撮影した撮像画像等を配車管理装置１００に送信する。なお、運行中バスＵＢは、中古のバスでなくてもよく、新車のバスと中古のバスとが混在していてもよい。

運行経路Ｒ１、Ｒ２およびＲ３には、複数の停留所Ｔ１、Ｔ２、Ｔ３およびＴ４が設置されている。以降の説明では、各停留所を区別する場合、停留所Ｔ１、Ｔ２、Ｔ３およびＴ４と呼び、各停留所を区別しない場合には、総称して停留所Ｔと呼ぶ。図１において停留所Ｔ４に例示するように、停留所Ｔには、撮像装置２１３が設置されている。撮像装置２１３の撮像画像は、配車管理装置１００に送信され、停留所Ｔにおいて運行中バスＵＢを待つ乗客の数（以下、「待ち人数」と呼ぶ）を算出する際に用いられる。

配車管理装置１００は、管理センタ９０に設置されている。配車管理装置１００は、運行中バスＵＢおよび停留所Ｔから受信した撮像画像等を解析することによって、運行中バスＵＢの車室内の混雑状況を特定し、混雑状況に適した大きさのバスを配車する。管理センタ９０では、運行中バスＵＢ１と同種の３台のバスＷＢ１と、運行中バスＵＢ２と同種の２台のバスＷＢ２とが、待機している。待機中のバスＷＢ１およびＷＢ２は、運行中バスＵＢの続行便として配車される予定のバスである。以降の説明では、待機中のバスＷＢ１およびバスＷＢ２を、総称して待機中バスＷＢと呼ぶ。

図２に示すように、管理センタ９０は、通信装置４０と、配車管理装置１００と、待機中バスＷＢとを備える。

通信装置４０は、配車管理装置１００と運行中バスＵＢとの間で無線による通信を行う。また、通信装置４０は、配車管理装置１００と待機中バスＷＢとの間で無線による通信を行う。また、通信装置４０は、配車管理装置１００と停留所Ｔとの間で無線による通信を行う。

配車管理装置１００は、ＣＰＵ１０と、メモリ３５と、入出力インターフェース３０とを備えるマイクロコンピュータにより構成されている。ＣＰＵ１０、メモリ３５、および入出力インターフェース３０は、バス３１を介して双方向に通信可能に接続されている。ＣＰＵ１０は、メモリ３５に記憶されたプログラムを展開して実行することにより、乗車人数取得部１１、混雑バス特定部１２、配車管理部１３、待ち人数取得部１４、および降車人数推定部１５として機能する。

乗車人数取得部１１は、運行中バスＵＢにそれぞれ乗車中の乗客の人数を示す情報（以下、「乗車人数情報」と呼ぶ）を運行中バスＵＢから取得し、取得した乗車人数情報を利用して乗客の人数を算出する。乗車人数情報は、例えば、運行中バスＵＢの車室内の撮像画像である。乗車人数取得部１１は、撮像画像を解析し、撮像画像に含まれる人物の数を検出することにより、乗客の数を算出する。

混雑バス特定部１２は、運行中バスＵＢの乗車人数と、運行中バスＵＢの乗車定員数とを用いて、混雑が予想される運行中バスＵＢを混雑バスとして特定する。本実施形態において、「混雑が予想される」とは、運行中バスＵＢの乗車率が、例えば９０％～１５０％であることを意味する。混雑バス特定部１２は、乗車人数が乗車定員数を超えている場合や、乗車人数が乗車定員数未満である場合であっても所定の人数（例えば、乗車定員数の９０％の人数）を超えている場合に、運行中バスＵＢを混雑バスとして特定する。

配車管理部１３は、混雑バスの路線に増発運行させるバス（続行便、以下「追加バス」と呼ぶ）の大きさおよび台数を決定し、混雑バスが停車する予定の停留所Ｔに配車する。配車管理部１３は、追加バスの大きさおよび台数を、混雑バスの乗車人数と、混雑バスが停車する予定の停留所Ｔにおける待ち人数と、混雑バスの降車予定人数とを用いて決定する。例えば、配車管理部１３は、予め定められた混雑率を用いて、混雑バスの混雑率が例えば７０％程度となるように追加バスの大きさおよび台数を決定する。混雑率は、運行中バスＵＢの座席およびつり革の使用状況や、運行中バスＵＢの乗車率等により定められる。混雑率１００％とは、概ね全ての座席に乗客が着席し、また、概ね全てのつり革が使用されている状態や、乗車率が例えば９０％～１５０％程度であることを示している。混雑率７０％とは、座席の全数に対して空席の数が３０％である状態や、乗車率が例えば６０％～７０％程度である状態を示している。混雑率５０％とは、座席の全数に対して空席の数が半分である状態や、乗車率が例えば４０％～５０％程度である状態を示している。

配車管理部１３は、待ち人数の乗客が混雑バスに乗車した場合における乗車率、すなわち、混雑バスの乗員定員数に対する、混雑バスの乗車人数と待ち人数との和の割合を算出し、かかる乗車率が７０％程度になるように追加バスの大きさと台数とを決定する。このとき、配車管理部１３は、追加バスの配車台数がより少なくなるように追加バスの大きさを決定してもよい。

配車管理部１３は、追加バスを配車する際、通信装置４０を介して混雑バスに対して、いわゆるプッシュ通知方式により、混雑バスから追加バスへの乗り換えを促す旨の通知（以下、「乗り換え通知」と呼ぶ）を送信する。

待ち人数取得部１４は、混雑バスの路線上に配置された停留所Ｔのうち、混雑バスが停車する予定の停留所Ｔにおける待ち人数を取得する。待ち人数取得部１４は、停留所Ｔから受信する撮像画像中のバスの待機列の人物の数を検出することにより、待ち人数を算出する。

降車人数推定部１５は、混雑バスの乗客の定期券区間情報を利用して、乗客が降車する予定の停留所Ｔ（以下、「降車予定停留所」と呼ぶ）と、降車予定停留所で降車する人数（以下、「降車予定人数」と呼ぶ）とを推定する。「定期券区間情報」とは、乗車区間が指定された定期券の乗車区間を示す情報を意味する。降車人数推定部１５は、混雑バスとして特定された運行中バスＵＢの乗客の定期券区間情報を取得し、乗車区間の終点の停留所を降車予定停留所と推定し、降車予定停留所の数をカウントすることにより降車予定停留所における降車予定人数を推定する。

メモリ３５は、ＲＯＭ、ＲＡＭ、およびＥＥＰＲＯＭを含み、運行経路情報ＫＩ、運賃情報ＵＩが予め記憶されている。運行経路情報ＫＩには、管理センタ９０で運行を管理するバスの路線地図、運行中バスＵＢの運行経路、時刻表等の情報が格納されている。運賃情報ＵＩには、運行中バスＵＢの運賃の情報が格納されている。

待機中バスＷＢは、上述の追加バスとして配車される予定のバスである。待機中バスＷＢは、混雑バスの運行経路に配車される際、配車管理装置１００から運賃情報ＵＩを受信する。待機中バスＷＢの構成は、後述の運行中バスＵＢの構成と同じである。

図３に示すように、運行中バスＵＢは、車両側通信装置５２と、センサ部７０と、報知装置６４と、運転装置５５と、車両制御装置８０とを備える。これらの各装置は、車載ネットワークを介して接続される。

車両側通信装置５２は、運行中バスＵＢと管理センタ９０との間で無線通信を行って、上述の乗車人数情報および定期券区間情報等のデータのやりとりを行う。

センサ部７０は、運行中バスＵＢの内部および外部の状況を取得する。センサ部７０は、内部カメラ７１と、外部カメラ７２と、周辺物体センサ７３と、位置センサ７４とを備える。

内部カメラ７１は、運行中バスＵＢの車室内に向けられており、車室内の様子を撮影する。内部カメラ７１は、乗車口、降車口、降車ボタンが設けられている場所の周囲等の少なくとも乗客の頭部を撮像可能な場所に配置されている。内部カメラ７１は、例えば、ステレオカメラである。

外部カメラ７２は、運行中バスＵＢの周囲に向けられており、運行中バスＵＢの少なくとも進行方向を撮影する。外部カメラ７２は、例えば、単眼カメラ、ステレオカメラおよびマルチカメラである。

周辺物体センサ７３は、先行車両、隣接車線を走行する車両、対向車両、進入車両、後続車両等の運行中バスＵＢの周囲を走行する他車両のほか、停止車両、落下物、停止物および歩行者といった様々な周辺物の存在、位置、大きさ、距離等を検出する。周辺物体センサ７３として、例えば、レーザーレーダ、ミリ波レーダ、超音波センサ等の反射波を利用した物体センサが挙げられる。

位置センサ７４は、運行中バスＵＢの自己位置を検出する。自己位置は、運行中バスＵＢの緯度及び経度で表される。位置センサ７４として、例えば、全地球航法衛星システム（ＧＮＳＳ）やジャイロセンサ等が挙げられる。自己位置は、運行中バスＵＢの高度を含んでもよい。

センサ部７０は、内部カメラ７１、外部カメラ７２、周辺物体センサ７３、および位置センサ７４に加えて、車速センサ、加速度センサ、ヨーレートセンサ、操舵角センサ、超音波センサ、温度センサ等を備えてもよい。

報知装置６４は、運行中バスＵＢの乗客に向けて、運行中バスＵＢの行き先、停留所Ｔの案内および上述の乗り換え通知等の情報を報知する。報知装置６４は、運行中バスＵＢの車室内に向けられた表示装置６６およびスピーカ６８を備える。表示装置６６は、画像を表示する。表示装置６６において表示される画像は、狭義の画像の他、文字、記号等を含む。スピーカ６８は、音声を出力する。

運転装置５５は、いずれも図示しない駆動装置と、操舵装置と、ブレーキ装置とを備える。駆動装置は、内燃機関及びモータの少なくともいずれか１つを含み、走行用の駆動力を発生する。操舵装置は、電動ステアリング機構等を含み、運行中バスＵＢの操舵を実現する。ブレーキ装置は、ディスクブレーキ等を含み、運行中バスＵＢの制動を実現する。

車両制御装置８０は、ＣＰＵ８１と、メモリ８２と、図示しないインターフェースとを搭載した１つ又は複数のＥＣＵとして構成されている。ＣＰＵ８１は、メモリ８２に記憶されたプログラムを展開して実行することにより、制御部８５として機能する。制御部８５は、車両制御装置８０の全体の動作を制御する。

メモリ８２は、ＲＯＭ、ＲＡＭ、およびＥＥＰＲＯＭを含む。メモリ８２には、運賃情報ＵＩが記憶されている。運賃情報ＵＩは、配車管理装置１００のメモリ３５に格納されている運賃情報ＵＩと同じである。

Ａ２．配車処理：
図４に示す運行中バスＵＢ側における配車処理は、運行中バスＵＢの走行中に繰り返し実行される。配車処理は、運行中バスＵＢのイグニッションスイッチがオンにされたことを示す信号が送信され、かかる信号が車両制御装置８０において受信されると、開始される。制御部８５は、車両側通信装置５２を介して配車管理装置１００と通信する（ステップＳ１０５）。制御部８５は、配車管理装置１００から乗車人数情報の送信要求を受信したか否かを判定する（ステップＳ１１０）。乗車人数情報の送信要求を受信したと判定した場合（ステップＳ１１０：ＹＥＳ）、制御部８５は、配車管理装置１００に乗車人数情報を送信する（ステップ Ｓ１１５）。具体的には、制御部８５は、内部カメラ７１に運行中バスＵＢの車室内を撮像させ、得られた撮像画像を、車両側通信装置５２を介して配車管理装置１００に送信する。

ステップＳ１１５の実行後、または、上述のステップＳ１１０において乗車人数情報の送信要求を受信していないと判定した場合（ステップＳ１１０：ＮＯ）、制御部８５は、配車管理装置１００から定期券区間情報の送信要求を受信したか否かを判定する（ステップＳ１２０）。定期券区間情報の送信要求を受信したと判定した場合（ステップＳ１２０：ＹＥＳ）、制御部８５は、定期券区間情報を配車管理装置１００に送信する（ステップＳ１２５）。具体的には、制御部８５は、運行中バスＵＢの乗車口に設けられたＩＣカード読み取り装置から乗客の定期券の読み取り結果を取得し、乗客の乗車区間の情報を、車両側通信装置５２を介して配車管理装置１００に送信する。

ステップＳ１２５の実行後、または、上述のステップＳ１２０において定期券区間情報の送信要求を受信していないと判定した場合（ステップＳ１２０：ＮＯ）、制御部８５は、配車管理装置１００から乗り換え通知を受信したか否かを判定する（ステップＳ１３０）。乗り換え通知を受信したと判定した場合（ステップＳ１３０：ＹＥＳ）、制御部８５は、追加バスへの乗り換えを乗客に促す（ステップＳ１３５）。具体的には、制御部８５は、表示装置６６に、追加バスへの乗り換えを促す報知画面を表示する。また、制御部８５は、スピーカ６８に、追加バスへの乗り換えを促す案内の音声を出力させる。

ステップＳ１３５の実行後、または、上述のステップＳ１３０において乗り換え通知を受信していないと判定した場合、制御部８５は、上述のステップＳ１０５に戻り、運行中バスＵＢのイグニッションスイッチがオフとされるまでの間、ステップＳ１０５～ステップＳ１３０を繰り返し実行する。例えば、制御部８５は、運行中バスＵＢが停留所Ｔに停車するたびに配車処理を実行してもよいし、停留所Ｔにおいて乗客が乗降する場合にのみ配車処理を実行してもよい。

図５に示す配車管理装置１００側における処理は、例えば、管理センタ９０においてバスの運行を管理するシステムが起動すると開始される。乗車人数取得部１１は、通信装置４０を介して運行中バスＵＢから乗車人数情報を取得する（ステップＳ２０５）。乗車人数取得部１１は、運行中バスＵＢの乗車人数を算出する。具体的には、乗車人数取得部１１は、取得した乗車人数情報（撮像画像）に含まれる人物の数を検出することにより、運行中バスＵＢの乗客の数を算出する。

混雑バス特定部１２は、混雑バスを特定する（ステップＳ２１５）。具体的には、混雑バス特定部１２は、運行中バスＵＢの乗車率が例えば９０％以上である場合に運行中バスＵＢを混雑バスであると特定する。図１に示す例では、混雑バス特定部１２は、運行中バスＵＢ１、ＵＢ２およびＵＢ３のうち、運行中バスＵＢ２を混雑バスであると特定する。なお、混雑バスの特定に用いる乗車率の閾値は、９０％に限らず、実験等により他の任意の乗車率を設定してもよい。

降車人数推定部１５は、通信装置４０を介して混雑バスから定期券区間情報を取得する（ステップＳ２２０）。降車人数推定部１５は、混雑バスの降車予定人数を推定する（ステップＳ２２５）。具体的には、降車人数推定部１５は、取得された定期券区間情報から乗車区間の終点の停留所の数をカウントすることにより、混雑バスの乗客の降車予定停留所および降車予定人数を推定する。

待ち人数取得部１４は、通信装置４０を介して混雑バスが停車予定の停留所Ｔから撮像画像を取得する（ステップＳ２３０）。待ち人数取得部１４は、停留所Ｔにおける待ち人数を算出する（ステップＳ２３５）。具体的には、待ち人数取得部１４は、取得した撮像画像を解析し、停留所に乗客が存在するか否かを判定する。停留所に乗客が存在する場合には、待ち人数取得部１４は、撮像画像中の乗客の数を検出することにより、待ち人数の数を算出する。

配車管理部１３は、追加バスの大きさと台数を決定する（ステップＳ２４０）。具体的には、配車管理部１３は、上述した混雑率が例えば７０％程度となるように、追加バスの大きさと台数とを決定する。なお、混雑率と、追加バスの大きさおよび台数との対応関係を、実験等により予め定めておいてもよい。配車管理部１３は、追加バスの運賃情報に混雑バスの運賃情報ＵＩを適用する（ステップＳ２４５）。具体的には、配車管理部１３は、通信装置４０を介して追加バス（待機中バスＷＢ）の車両側通信装置５２と通信し、追加バスの車両制御装置８０のメモリ８２内に格納されている運賃情報を、混雑バスの運賃情報ＵＩに更新する。配車管理部１３は、追加バスを配車する（ステップＳ２５０）。具体的には、配車管理部１３は、混雑バスの運行経路上に追加バスを配車し、混雑バスが停車する予定の停留所に向けて走行させる。配車管理部１３は、通信装置４０を介して混雑バスに乗り換え通知を送信する（ステップＳ２５５）。

ステップＳ２５５の終了後、上述のステップＳ２０５に戻り、ステップＳ２０５～ステップＳ２５５が繰り返し実行される。

以上の構成を有する第１実施形態の配車管理装置１００によれば、混雑バスの停留所に配車すべき追加バスの大きさおよび台数を混雑バスの乗車人数に応じて決定するので、混雑バスの混雑状況に対応する大きさおよび台数の追加バスを配車できる。このため、混雑バスの乗客の利便性の低下を抑制できる。

混雑バスが停車する予定の停留所における待ち人数を取得し、混雑バスの乗車人数に加えて、待ち人数を用いて追加バスの大きさおよび台数を決定するので、追加バスの大きさおよび台数をより精度よく決定できる。このため、混雑バスの乗客の利便性の低下をさらに抑制できる。

混雑バスの乗客の定期券区間情報を用いて乗客の降車予定停留所および降車予定人数を推定し、混雑バスの乗車人数および待ち人数に加えて、降車予定人数を用いて追加バスの大きさおよび台数を決定するので、追加バスの大きさおよび台数をより精度よく決定できる。このため、混雑バスの乗客の利便性の低下をさらに抑制できる。

乗車人数情報は混雑バスの車室内の撮像画像であるので、撮像画像を解析することにより、混雑バスの乗客の数を精度よく検出できる。

混雑バスに搭載された報知装置を用いて、混雑バスの乗客に追加バスへの乗り換えを促すので、混雑バスの乗客に追加バスの存在を知らしめることができる。この結果、混雑バスの乗客を混雑バスと追加バスとに分散して乗車させることができるので、混雑バスの混雑状況を緩和することができ、混雑バスの乗客の利便性の低下を抑制できる。

Ａ３．第１実施形態の他の実施形態：
（１）配車管理部１３は、乗車人数と、待ち人数と、降車予定人数とを用いて、追加バスの大きさおよび台数を決定していたが、待ち人数および降車予定人数を省略し、乗車人数のみを用いて追加バスの大きさおよび台数を決定してもよい。例えば、乗車人数が乗員定員数の３０％程度の人数となるような大きさのバスを１台追加バスとして決定してもよいし、乗車人数が乗員定員数の１０％程度の人数となるような大きさのバスを２台追加バスとして決定してもよい。

（２）乗車人数、待ち人数、および降車予定人数を配車管理装置１００側で算出していたが、乗車人数および降車予定人数を運行中バスＵＢ側に算出させ、待ち人数を停留所Ｔ側に算出させて、算出結果を配車管理装置１００が取得する構成としてもよい。

（３）乗車人数情報は、運行中バスＵＢの車室内を撮影した撮像画像であったが、撮像画像に代えて、または、加えて、例えば、運行中バスＵＢの積載量であってもよい。この場合、運行中バスＵＢの積載量と乗客の人数とを予め実験等により対応づけておくことにより、積載量から乗車人数を取得できる。また、例えば、運行中バスＵＢの座席に取り付けられた着座センサの検出結果であってもよい。この場合、運行中バスＵＢの乗客のうち、座席に着席している乗客の人数を取得できる。また、例えば、運行中バスＵＢのつり革に取り付けられたセンサの検出結果であってもよい。この場合、運行中バスＵＢの乗客のうち、つり革につかまって乗車している乗客の人数を取得できる。また、例えば、運行中バスＵＢの乗車口および降車口を通過した乗客の数であってもよい。この場合、運行中バスＵＢに乗車してきた乗客の人数と、運行中バスＵＢから降車する乗客の人数とを取得することにより、運行中バスＵＢに現在乗車中の乗客の人数を取得できる。また、例えば、運行中バスＵＢにおける運賃の支払い回数であってもよい。運賃の支払い回数としては、例えば、運行中バスＵＢの乗車口に設けられている図示しない読み取り装置にＩＣカードがタッチされた回数や、所定のアプリケーション上で運賃の決済が行われた回数等が該当する。なお、ＩＣカードに代えて、ＱＲコード（登録商標）や、ＩＤタグ等を利用した運賃の決済であってもよい。また、例えば、これらの情報を組み合わせて乗車人数情報としてもよい。

（４）混雑バス特定部１２は、運行中バスＵＢの過去の運行状況を利用して、混雑バスを特定してもよい。例えば、過去に追加バスを複数回配車した路線や、周辺に学校がある路線などを運行するバスを混雑バスとして特定してもよいし、通勤・通学時間帯など時間帯によって混雑が予想される路線を運行するバスを混雑バスとして特定してもよい。また、混雑バス特定部１２は、運行経路の周辺で開催されるイベントの情報を利用して混雑バスを特定してもよく、イベントの開催日におけるイベントの開催場所の周辺を運行するバスを混雑バスとして特定してもよい。

（５）降車人数推定部１５は、定期券区間情報を用いて降車予定停留所および降車予定人数を推定していたが、混雑バスの車室内の撮像画像を解析して乗客の服装や持ち物を特定することにより、降車予定停留所および降車予定人数を推定してもよい。例えば、乗客の服装が制服であり、持ち物が学校鞄である場合、乗客は学生であると推定できる。このため、混雑バスの停留所の周辺施設を検索して、学校がある停留所を降車予定停留所と推定でき、かかる停留所において下車することが推定できる。なお、降車人数推定部１５は、定期券区間情報と車室内の撮像画像との両方を用いて、降車予定停留所および降車予定人数を推定してもよい。

Ｂ．第２実施形態：
以下では、上述の実施形態と同様の構成には同じ符号を用い、説明を省略する。図６に示す車両ＳＶは、予め定められた区間において人を運送するサービス（以下、「移動サービス」とも呼ぶ）の目的に利用される。図６に示す例では、車両ＳＶは、予め定められた運行経路ＳＲ上を予め定められた停留所ＳＴに向かって走行している。車両ＳＶに乗車する予定の利用者（以下、「利用予定者」とも呼ぶ）ｕｓ１は、情報端末装置２００を用いて車両ＳＶの乗車予約を行うことにより、所定の乗車場所から降車場所まで車両ＳＶに乗車する。乗車場所や、降車場所としては、公共交通機関の停留所や、利用者が所望する場所が用いられる。

しかし、乗車場所および降車場所として利用者の所望する場所を用いると、車両ＳＶの利用者数が多い場合には、車両ＳＶの運行に遅延が生じるおそれがある。また、公共交通機関の停留所（例えば、図６に示す停留所ＳＴ）を用いると、利用予定者ｕｓ１が高齢である場合や、傷病がある場合には、停留所ＳＴまで自力で移動することは容易ではない。このため、利用者の利便性が低下するおそれがある。そこで、本実施形態では、後述の仮想停留所設定処理において、利用予定者ｕｓ１の乗車場所である仮想の停留所（以下、「仮想停留所」と呼ぶ）を、仮想停留所を設定可能な領域（以下、「停留所設定可能領域」と呼ぶ）において利用予定者ｕｓ１の現在位置Ｐ１に最も近い場所に設定する。本実施形態では、停留所設定可能領域として、車両を停車可能な退避場所（以下、「車両退避場所」と呼ぶ）を用いる。図６では、運行経路ＳＲ周辺の停留所設定可能領域において利用予定者ｕｓ１の現在位置Ｐ１に最も近い場所Ｐ２に仮想停留所ＫＴ１が設定された例を示している。そして、車両ＳＶを破線に示す運行経路ＮＲ上を走行させることにより、利用予定者ｕｓ１を仮想停留所ＫＴ１から車両ＳＶに乗車させる。この結果、利用予定者ｕｓ１の車両ＳＶへの乗車場所までの移動距離を短縮できるので、利用予定者ｕｓ１の利便性の低下を抑制できる。以下、本実施形態の仮想停留所設定処理について詳細に説明する。

Ｂ１．装置構成
図７に示すように、第２実施形態における運行管理システムが、第１実施形態の配車管理システム５００と異なる点は、配車管理装置１００に代えて、運行管理装置１００ａを備える点である。運行管理装置１００ａは、ＣＰＵ１０に代えて、ＣＰＵ１０ａを備える点と、メモリ３５に代えて、メモリ３５ｂを備える点において、第１実施形態の配車管理装置１００と異なる。第１実施形態の配車管理装置１００と同一の構成要素には同一の符号を付し、その詳細な説明を省略する。

ＣＰＵ１０ａは、メモリ３５ａに記憶されたプログラムを展開して実行することにより、運行管理部１３ａ、入力受付部１７、位置情報取得部１８、および仮想停留所設定部１９として機能する。

運行管理部１３ａは、運行管理装置１００ａ全体の動作を制御する。運行管理部１３ａは、車両ＳＶの運行経路、停留所および停留所における発着時間等を管理し、通信装置４０を介して、車両ＳＶに運行指示として送信する。図６および図７では図示を省略しているが、運行管理部１３ａは、車両ＳＶのほかにも運行経路が互いに異なる複数台の車両の運行を管理している。したがって、運行管理部１３ａは、利用予定者ｕｓ１の所望する乗車場所や目的地に応じて、利用予定者ｕｓ１をいずれの車両に乗車させるかを選定する。また、本実施形態では、運行管理部１３ａは、仮想停留所設定部１９により設定される仮想停留所の位置を通信装置４０および情報端末装置２００を介して利用予定者ｕｓ１に通知する。すなわち、運行管理部１３ａは、本開示における通知部としても機能する。

入力受付部１７は、情報端末装置２００を介して、利用予定者ｕｓ１の利用者情報の入力を受け付ける。情報端末装置２００としては、スマートフォン、タブレット端末、専用の入力装置等が該当する。利用者情報には、利用予定者ｕｓ１が所望する乗車場所、目的地、属性情報等が含まれる。属性情報には、例えば、年齢、傷病の有無の情報等が含まれる。入力受付部１７は、利用予定者ｕｓ１から利用者情報の入力を受け付けると、メモリ３５ａに利用者ごとに利用者情報ＵｓＩを格納する。

位置情報取得部１８は、利用予定者ｕｓ１の現在位置を示す位置情報を取得する。本実施形態において、「現在位置」には、利用予定者ｕｓ１の現在の位置と、将来の所定時刻において利用予定者ｕｓ１が存在するであろうと想定される位置とを含む。位置情報取得部１８は、位置情報として、情報端末装置２００の現在位置や、利用予定者ｕｓ１から入力される施設名称、住所等を取得する。情報端末装置２００の現在位置としては、例えば、情報端末装置２００に搭載された図示しない位置センサ（例えば、ＧＮＳＳセンサ）の検出結果を取得する。

仮想停留所設定部１９は、位置情報を用いて利用予定者ｕｓ１の乗車場所である仮想停留所を設定する。具体的には、仮想停留所設定部１９は、メモリ３５ａに予め格納されている地図情報Ｍｐを参照し、停留所設定可能領域において利用予定者ｕｓ１の現在位置に最も近い場所に仮想停留所を設定する。車両ＳＶの利用予定者が複数人存在する場合には、利用者情報ＵｓＩの属性情報を参照し、利用予定者の特性に応じて、仮想停留所を設定する。仮想停留所の設定方法は、後述する。

Ｂ２．停留所設定処理：
図８に示す仮想停留所設定処理は、例えば、管理センタ９０において車両ＳＶの運行を管理するシステムが起動すると開始される。入力受付部１７は、乗車希望があるか否かを判定する（ステップＳ３０５）。乗車希望があると判定した場合（ステップＳ３０５：ＹＥＳ）、入力受付部１７は、利用者情報の入力を受付ける（ステップＳ３１０）。具体的には、入力受付部１７は、乗車希望者に対して、情報端末装置２００を介して乗車場所、目的地および利用者属性の入力を促し、入力結果を利用者情報ＵｓＩとしてメモリ３５ａに格納する。

位置情報取得部１８は、乗車希望者の位置情報を取得する（ステップＳ３１５）。具体的には、位置情報取得部１８は、通信装置４０を介して情報端末装置２００の現在位置を取得する。

運行管理部１３ａは、車両ＳＶを選定する（ステップＳ３２０）。具体的には、運行管理部１３ａは、運行管理部１３ａが管理する複数の車両のうち、乗車希望者の乗車場所および目的地を含む経路や、これらの場所の近傍を走行する経路を運行経路とする車両を選定する。運行管理部１３ａは、選定されたバスの乗客の利用者情報ＵｓＩを取得する（ステップＳ３２５）。具体的には、運行管理部１３ａは、メモリ３５ａの利用者情報ＵｓＩを参照して、選定されたバスに乗車中の乗客に対応する利用者情報を取得する。

仮想停留所設定部１９は、仮想停留所を設定する（ステップＳ３３０）。具体的には、仮想停留所設定部１９は、まず、選定されたバスの運行経路の周辺における停留所設定可能領域を探索する。仮想停留所設定部１９は、地図情報Ｍｐを参照して、運行経路の周辺に存在する車両退避場所を探索する。次に、仮想停留所設定部１９は、探索された停留所設定可能領域のうち、上述のステップＳ３１５において取得した乗車希望者の現在位置から最も近い場所を探索し、かかる場所を仮想停留所として設定する。このとき、仮想停留所設定部１９は、乗車希望者が複数人存在する場合には、各乗車希望者の移動距離が最小となる場所を探索する。また、仮想停留所設定部１９は、乗車希望者の属性情報、例えば、年齢がより高い乗車希望者や、傷病が有る乗車希望者の移動距離が最小となる場所を優先して探索してもよい。

仮想停留所設定部１９は、仮想停留所への到着予定時間を算出する（ステップＳ３３５）。具体的には、仮想停留所設定部１９は、通信装置４０を介して、例えば、高度道路交通システム（Intelligent Transport System）等の交通管理システムとの通信によって、仮想停留所までの運行経路における渋滞状況等を取得して、仮想停留所への到着予定時間を算出する。

運行管理部１３ａは、上述のステップＳ３０５において乗車希望を入力した利用予定者ｕｓ１に対して、通信装置４０を介して、仮想停留所の位置と到着予定時間とを送信する（ステップＳ３４０）。入力受付部１７は、乗車希望があるか否かを判定する（ステップＳ３４５）。乗車希望があると判定した場合（ステップＳ３４５：ＹＥＳ）、運行管理部１３ａは、上述のステップＳ３２０において選定された車両に運行指示を送信する（ステップＳ３５０）。具体的には、運行管理部１３ａは、運行指示として、仮想停留所の位置、目的地および運行経路を送信する。

ステップＳ３５０の実行後、または、上述のステップＳ３０５およびステップＳ３４５において乗車希望がないと判定した場合（ステップＳ３０５：ＮＯ、ステップＳ３４５：ＮＯ）、仮想停留所設定処理は終了する。

以上の構成を有する第２実施形態の運行管理装置１００ａによれば、車両ＳＶに乗車する予定の利用予定者ｕｓ１の現在位置Ｐ１を含む位置情報を用いて、停留所設定可能領域である車両退避場所において利用予定者ｕｓ１に最も近い場所Ｐ２に利用者の乗車場所である仮想停留所ＫＴ１を設定し、利用予定者ｕｓ１に仮想停留所ＫＴ１の位置を通知するので、利用予定者ｕｓ１の現在位置Ｐ１から乗車場所までの移動距離を短縮できる。このため、利用予定者ｕｓ１の利便性の低下を抑制できる。また、利用予定者ｕｓ１の属性情報に応じて仮想停留所ＫＴ１を設定するので、仮想停留所ＫＴ１を適切に設定できる。このため、利用予定者ｕｓ１の利便性の低下を抑制できる。

Ｂ３．第２実施形態の他の実施形態：
（１）仮想停留所設定部１９は、選定された車両の乗客が乗員定員数を超える場合など、選定された車両において混雑が予想される場合には、既に乗車している乗客を先に降車させて、その後、乗車希望者を乗車させるように仮想停留所を設定してもよい。

（２）停留所設定可能領域は、車両退避場所に代えて、既に設定された仮想停留所との距離が予め定められた距離以上である場所を用いてもよい。具体的には、利用予定者ｕｓ１とは異なる利用者からの乗車希望を受け付けて仮想停留所を設定した場合、かかる仮想停留所から、例えば、１５０メートル以上離れている場所に利用予定者ｕｓ１の仮想停留所を設定してもよい。なお、予め定められた距離は、１５０メートルに代えて、実験等により他の任意の距離を設定してもよい。また、例えば、停留所設定可能領域として、運行経路ＳＲ上の場所を用いてもよい。この場合、運行経路ＳＲにおける利用予定者ｕｓ１に最も近い場所に仮想停留所が設定されるので、車両ＳＶの運行の遅延の発生を抑制できる。また、車両ＳＶの運行経路ＳＲを変更する必要がないため、仮想停留所設定処理が複雑になることを抑制できる。また、例えば、停留所設定可能領域として、公共交通機関の停留所を用いてもよい。また、例えば、これらの場所を任意に組み合わせて停留所設定可能領域としてもよい。

Ｃ．第３実施形態：
花火大会や、フェスなどのイベントの開催地では、例えば、イベント会場の最寄り駅からイベント会場までの移動手段として、イベント主催者によって手配されたバスやタクシーが利用されることがある。イベント主催者は、イベントの来場者数を予想し、予想される来場者数に合わせてバス等の車両を配車する。しかし、イベントの開催場所によっては、イベントの開催日に必要な台数の車両を配車できないおそれがある。

図９に示すように、イベント主催者は、東京Ａｒ１、静岡Ａｒ２、大阪Ａｒ３、および福岡Ａｒ４において、それぞれ、所有台数に示す複数の車両９１、９２、９３および９４を所有しているとする。例えば、大阪Ａｒ３において或るイベントが開催される予定であり、８台の車両が必要であるとする。この場合、大阪Ａｒ３で所有している車両９３が６台であるので、２台の車両が不足する。大阪Ａｒ３でのイベントの開催日において、静岡Ａｒ２では、所有している車両９２を全て使用する予定であり、東京Ａｒ１および福岡Ａｒ４では、それぞれ、所有している車両９１および９４のうち、２台の車両を使用する予定がない。そこで、本実施形態では、後述の配車処理を実行することにより、東京Ａｒ１または福岡Ａｒ４での余剰分の車両を大阪Ａｒ３に配車して、イベントの開催日にイベントの開催場所（大阪Ａｒ３）で必要となる台数の車両を確保できる。また、イベントの開催日に予想される道路状況等に応じて、東京Ａｒ１と福岡Ａｒ４とのうちいずれの場所から車両を配車させるかを決定することにより、車両の移動時間や燃費等のコストを低減できる。以下、本実施形態の配車処理について詳細に説明する。

Ｃ１．装置構成
図１０に示すように、第３実施形態における配車管理システムが、第１実施形態の配車管理システム５００と異なる点は、配車管理装置１００に代えて、配車管理装置１００ｂを備える点である。配車管理装置１００ｂは、ＣＰＵ１０に代えて、ＣＰＵ１０ｂを備える点と、メモリ３５に代えて、メモリ３５ｂを備える点において、第１実施形態の配車管理装置１００と異なる。第１実施形態の配車管理装置１００と同一の構成要素には同一の符号を付し、その詳細な説明を省略する。

配車管理装置１００ｂは、予め定められた複数の場所Ａｒ１、Ａｒ２、Ａｒ３およびＡｒ４に配置されている複数の車両９１、９２、９３および９４の配車を管理する。なお、場所Ａｒ１、Ａｒ２、Ａｒ３およびＡｒ４や、車両９１、９２、９３および９４の台数は、図９に示す例に限定されない。

ＣＰＵ１０ｂは、メモリ３５ｂに記憶されたプログラムを展開して実行することにより、配車管理部１３ｂ、イベント情報取得部２０、台数算出部２１、移動経路取得部２２、移動時間取得部２３として機能する。

配車管理部１３ｂは、配車管理装置１００ｂ全体の動作を制御する。また、配車管理部１３ｂは、或る特定のイベント（以下、「対象イベント」と呼ぶ）の開催日に対象イベントの開催場所に必要な台数の車両を配車する。本実施形態では、各場所Ａｒ１、Ａｒ２、Ａｒ３およびＡｒ４から対象イベントの開催場所までの移動時間が少ない順に配車する車両を決定する。配車管理部１３ｂは、配車を決定すると、配車の対象となる車両に対して、通信装置４０を介して、移動指示を送信する。移動指示には、対象イベントの開催日、対象イベントの開催場所、かかる開催場所までの移動経路等の情報が含まれる。なお、配車管理部１３ｂは、配車される対象の車両に直接移動指示を送信してもよいし、各車両９１、９２、９３および９４をそれぞれ管理する図示しない管理センタを介して、移動指示を送信してもよい。

イベント情報取得部２０は、通信装置４０を介して、イベント情報を取得する。本実施形態において、「イベント情報」とは、花火大会やフェスといったイベントの開催日時、開催場所、予想される参加人数、ホテルや飛行機の予約状況、公共交通機関の運行情報等の情報を意味する。イベント情報取得部２０は、通信装置４０を介して、インターネットからイベント情報を取得する。また、イベント情報取得部２０は、取得されたイベント情報から対象イベントに関する情報を抽出する。対象イベントは、例えば、イベント主催者から指定される。

台数算出部２１は、取得されたイベント情報を用いて、対象イベントの開催日時において必要となる車両の台数を算出する。台数算出部２１は、対象イベントへの参加人数が予想人数を超える場合に備えて、実際に必要となる車両の台数に余裕を持たせた台数を算出してもよい。

移動経路取得部２２は、各場所Ａｒ１、Ａｒ２、Ａｒ３およびＡｒ４から対象イベントの開催場所（図９に示す例では、大阪Ａｒ３）までの移動経路をそれぞれ取得する。移動経路取得部２２は、メモリ３５ｂに予め格納されている地図情報Ｍｐを参照し、対象イベントの開催場所までの経路を探索し、移動経路を取得する。移動経路取得部２２は、対象イベントの開催場所までの経路として複数の経路が探索される場合には、渋滞がより少ない経路を移動経路として決定する。例えば、移動経路取得部２２は、通信装置４０を介して交通管理システムとの通信によって、対象イベントの開催日の前日や、対象イベントの開催日における渋滞状況を取得し、渋滞を回避可能な経路を移動経路に決定する。

移動時間取得部２３は、移動経路取得部２２によって取得された移動経路における移動時間を取得する。取得された移動時間は、移動経路と対応づけられて、移動コスト情報ＣＩとしてメモリ３５ｂに格納される。なお、移動コスト情報ＣIは、後述の配車処理が実行されることにより生成されるため、図１０では、破線で示している。移動コスト情報ＣＩは、他の対象イベントの開催に際して実行される配車処理において、移動経路および移動時間の算出に利用される。

Ｃ２．配車処理：
図１１に示す配車処理は、例えば、管理センタ９０において車両の配車を管理するシステムが起動すると開始される。イベント情報取得部２０は、通信装置４０を介してイベント情報を取得する（ステップＳ４０５）。台数算出部２１は、対象イベントの開催日に必要な車両の台数を算出する（ステップＳ４１０）。具体的には、台数算出部２１は、イベント情報に含まれる対象イベントの予想参加人数の情報と、車両９１、９２、９３および９４の予め定められている乗員定員数とを用いて、必要な車両の台数を算出する。

台数算出部２１は、対象イベントの開催日の空き車両の台数を算出する（ステップＳ４１５）。具体的には、台数算出部２１は、対象イベントの開催日における各車両９１、９２、９３および９４の使用状況を取得し、使用予定のない車両の台数を算出する。

移動経路取得部２２は、空き車両が配置されている場所から対象イベントの開催場所までの移動経路を取得する（ステップＳ４２０）。具体的には、移動経路取得部２２は、出発地を空き車両が配置されている場所とし、目的地をイベントの開催場所として、目的地までの経路を探索する。このとき、移動経路取得部２２は、高度道路交通システムにより取得される渋滞情報を利用して、渋滞がより少ない経路を移動経路として取得する。移動時間取得部２３は、取得された移動経路における移動時間を算出する（ステップＳ４２５）。

配車管理部１３ｂは、移動時間が少ない順に対象イベントの開催日に使用する車両を決定する（ステップＳ４３０）。このとき、各移動経路の移動時間に差異がほとんどない場合には、配車管理部１３ｂは、移動経路における天候情報を利用して、対象イベントの開催日に使用する車両を決定してもよい。例えば、雨や雪などの悪天候となることが想定される場合には、より天候のよい移動経路を走行する場所に配置されている空き車両を、対象イベントの開催日に使用する車両に決定してもよい。なお、天候情報は、通信装置４０を介してインターネットから取得できる。配車管理部１３ｂは、決定された車両に、通信装置４０を介して移動指示を送信する（ステップＳ４３５）。ステップＳ４３５の実行後、配車処理は終了する。

以上の構成を有する第３実施形態の配車管理装置１００ｂによれば、イベント情報を用いて或るイベントの開催日時において必要となる車両の台数を算出し、複数の場所Ａｒ１、Ａｒ２、Ａｒ３およびＡｒ４から或るイベントの開催場所Ａｒ３までの移動経路をそれぞれ取得し、各移動経路における移動時間をそれぞれ取得し、各場所Ａｒ１、Ａｒ２、Ａｒ３およびＡｒ４から或るイベントの開催場所Ａｒ３に配車する車両を移動時間が少ない順に決定するので、車両をイベントの開催場所に移動させる時間および燃費を低減できる。また、各場所における車両の所有台数が異なる場合であっても、イベントの開催日に必要となる台数の車両を確保できる。

移動経路として渋滞がより少ない経路を取得するので、イベントの開催日に予想される道路状況等に応じて適切な移動経路を取得できる。このため、イベントの開催場所に車両を移動させる際の移動時間や、燃費等のコストを低減できる。

Ｃ３．第３実施形態の他の実施形態：
（１）移動経路として、渋滞がより少ない経路を取得していたが、本開示はこれに限定されない。例えば、幹線道路がより多く含まれる経路や、勾配がより少ない経路を移動経路としてもよい。また、例えば、急カーブがより少ない道路や、道路上に走路区画線が描かれている道路をより多く含む経路等、車両が自動走行する場合に走行への影響がより少ない経路を移動経路としてもよい。

（２）配車管理部１３ｂは、空き車両を対象イベントの開催場所に移動させる際、渋滞がより少ない時間帯、例えば、深夜から早朝といった夜遅くから明け方にかけての時間帯に移動させてもよい。また、このとき、空き車両に乗客を乗せて移動させてもよく、通常の利用料金に比べて安い利用料金を設定してもよい。

Ｄ．その他の実施形態
上記各実施形態において、運行中バスＵＢ、待機中バスＷＢ、車両ＳＶ、車両９１、９２、９３および９４は、いずれも、運転手の判断によらずに自動的に走行する車両であったが、管理センタ９０に配置されるオペレータによる遠隔操縦により走行させてもよいし、運転者による手動運転により走行させてもよい。

本開示に記載の制御部等の各部及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の制御部等の各部及びその手法は、一つ以上の専用ハードウエア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の制御部及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウエア論理回路によって構成されたプロセッサとの組合せにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されていてもよい。

本開示は、上述の実施形態に限られるものではなく、その趣旨を逸脱しない範囲において種々の構成で実現することができる。例えば、発明の概要の欄に記載した各形態中の技術的特徴に対応する実施形態中の技術的特徴は、上述の課題の一部又は全部を解決するために、あるいは、上述の効果の一部又は全部を達成するために、適宜、差し替えや、組み合わせを行うことが可能である。また、その技術的特徴が本明細書中に必須なものとして説明されていなければ、適宜、削除することが可能である。

１１…乗車人数取得部、１２…混雑バス特定部、１３…配車管理部、５２…車両側通信装置、１００…配車管理装置、ＵＢ,ＵＢ１,ＵＢ２,ＵＢ３…運行中バス

Claims (3)

1. 予め定められた運行経路を走行する車両（ＳＶ）の運行管理装置（１００ａ）であって、
   前記車両に乗車する予定の利用者（ｕｓ１）の現在位置を含む位置情報を取得する位置情報取得部（１８）と、
   取得された前記位置情報を用いて、前記利用者の乗車場所である仮想の停留所を設定可能な領域である停留所設定可能領域における前記利用者に最も近い場所に前記仮想の停留所を設定する仮想停留所設定部（１９）と、
   通信装置（４０）を介して、前記利用者に前記仮想の停留所の位置を通知する通知部（１３ａ）と、
   を備える、運行管理装置。
2. 請求項１に記載の運行管理装置であって、
   前記停留所設定可能領域は、前記車両を停車可能な退避場所と、前記利用者とは異なる利用者の前記乗車場所として設定された仮想の停留所との距離が予め定められた距離以上である場所と、前記運行経路上の場所と、を含む、
   運行管理装置。
3. 請求項１または請求項２に記載の運行管理装置であって、
   前記仮想停留所設定部は、前記利用者の特性に応じて、前記仮想の停留所を設定する、
   運行管理装置。

Images