JP7347395B2

JP7347395B2 - 運行管理方法、サーバ、及びシステム

Info

Publication number: JP7347395B2
Application number: JP2020176888A
Authority: JP
Inventors: 宇史東出; 慶一宇野
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2020-10-21
Filing date: 2020-10-21
Publication date: 2023-09-20
Anticipated expiration: 2040-10-21
Also published as: CN114386739A; JP2022067990A; US20220120570A1

Description

本発明は、運行管理方法、サーバ、及びシステムに関する。

従来、複数の車両の運行を管理する技術が知られている。例えば特許文献１には、管理センタから提供される走行経路に従って周回走行する自動運転車両が開示されている。

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

車両に循環ルートを走行させる場合、例えば燃料補給及びメンテナンス等の作業を当該車両に対して実施するために、当該車両を待機中の他の車両と計画的に入れ替えるように運行スケジュールが決定され得る。一方、例えば循環ルートを走行中の車両に故障が発生した場合、当該車両を待機中の他の車両と入れ替えることが考えられる。しかしながら、故障の発生を予見することは困難であるため、故障の発生に応じて車両の入替えを実施すると、予め計画された運行スケジュールに悪影響が及ぶ可能性がある。したがって、複数の車両の運行を管理する技術には改善の余地がある。

かかる事情に鑑みてなされた本開示の目的は、複数の車両の運行を管理する技術を改善することにある。

本開示の一実施形態に係る運行管理方法は、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行管理方法であって、
サーバが、
前記複数の循環バスの運行スケジュールを記憶すること、
前記複数の循環バスの状態を監視すること、及び
前記循環ルートを走行中の第１循環バスが前記規定周を走行し終える前に故障した場合、第２循環バスを前記循環ルートに投入し、且つ前記第２循環バスが前記規定周を走行し終える前に前記拠点に戻って第３循環バスと交代するように、前記運行スケジュールを修正することを含む。

本開示の一実施形態に係るサーバは、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行を管理するサーバであって、
制御部を備え、
前記制御部は、
前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第１循環バスが前記規定周を走行し終える前に故障した場合、第２循環バスを前記循環ルートに投入し、且つ前記第２循環バスが前記規定周を走行し終える前に前記拠点に戻って第３循環バスと交代するように、前記運行スケジュールを修正する。

本開示の一実施形態に係るシステムは、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと、前記複数の循環バスの運行を管理するサーバと、を備えるシステムであって、
前記サーバは、前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスは、前記運行スケジュールに従って運行し、
前記サーバは、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第１循環バスが前記規定周を走行し終える前に故障した場合、第２循環バスを前記循環ルートに投入し、且つ前記第２循環バスが前記規定周を走行し終える前に前記拠点に戻って第３循環バスと交代するように、前記運行スケジュールを修正し、
前記第２循環バス及び前記第３循環バスは、修正後の前記運行スケジュールに従って運行する。

本開示の一実施形態によれば、複数の車両の運行を管理する技術が改善される。

本開示の一実施形態に係るシステムの概略構成を示すブロック図である。本開示の一実施形態に係る輸送サービスの概要を示す図である。修正前の運行スケジュールの例を示す図である。修正後の運行スケジュールの例を示す図である。車両の概略構成を示すブロック図である。サーバの概略構成を示すブロック図である。サーバの動作を示すフローチャートである。

以下、本発明の実施形態について説明する。

（実施形態の概要）
図１を参照して、本開示の実施形態に係るシステム１の概要について説明する。システム１は、複数の車両１０と、サーバ２０と、を備える。複数の車両１０及びサーバ２０は、例えばインターネット及び移動体通信網等を含むネットワーク３０を介して互いに通信可能である。車両１０は、例えばバス等の旅客自動車であるが、これに限られず人間が乗車可能な任意の車両であってもよい。車両１０は、例えばＳＡＥ（Society of Automotive Engineers）において定義されるレベル１乃至５等の自動運転が可能であってもよい。サーバ２０は、例えばコンピュータ等の情報処理装置である。

本実施形態において複数の車両１０は、循環ルートを走行する循環バスとして用いられる。サーバ２０は、複数の車両１０に対して運行スケジュールを通知することによって、複数の車両１０の運行管理を行う。複数の車両１０は、サーバ２０から通知される運行スケジュールに従って運行する。また、循環ルートの走行中の車両１０に故障が発生した場合、サーバ２０は、後述するように運行スケジュールを修正し得る。

図２を参照して、修正前の運行スケジュールに従って運行する各車両１０の動作の概要について説明する。複数の車両１０のそれぞれは、拠点から循環ルートに投入されると、循環ルートを時計回りに走行しながら、循環ルート上の各バス停Ｘ～Ｚで乗客を乗降させ得る。図２においては、３台の車両１０ａ～１０ｃが循環ルートを走行中である。複数の車両１０のそれぞれは、循環ルートに投入されてから規定周ｎ（本実施形態では、ｎ＝４周）を走行すると、拠点に戻って他の待機中の車両１０と交代する。ここで「交代」とは、車両１０が循環ルートから拠点に戻るとともに、待機中の他の車両１０が拠点から循環ルートに投入されることを示す。以下、車両１０が待機中の他の車両１０と交代することを「通常入替」ともいう。図２においては、２台の車両１０ｄ～１０ｅが拠点で待機中である。複数の車両１０のそれぞれは、循環ルートから拠点に戻ると、例えば燃料補給及びメンテナンス等の作業を受けた後に拠点で待機する。

また、修正前の運行スケジュールは、循環ルートを走行中である車両１０の台数が原則として規定数ａ（本実施形態では、ａ＝３）になるように定められる。また、修正前の運行スケジュールは、上述した通常入替が規定周期Ｐで１回ずつ発生するように定められる。

図３を参照して、修正前の運行スケジュールについて具体的に説明する。図３は、７台の車両１０ａ～１０ｇのそれぞれに割り当てられた運行スケジュールを示す。図中の横軸は時刻を示す。時刻＝０は、複数の車両１０を用いた輸送サービスの営業開始時刻である。右向の矢印が図示されている期間は、車両１０が循環ルートを走行中であることを示す。当該矢印の長さは、車両１０が循環ルートを１周するのに要する時間（本実施形態では、３ｔ）を示す。当該矢印の内部の数値は、車両１０が循環ルートに投入されてから何周目を走行中であるかを示す。内部の数値が「１」である矢印の左端に相当する時刻は、車両１０が拠点から循環ルートに投入される時刻を示す。また、当該矢印の右端に相当する時刻は、当該矢印の右側に次の矢印が存在しない場合には、車両１０が循環ルートから拠点に戻る時刻を示す。

図３に示す修正前の運行スケジュールが適用される場合、例えば車両１０ａは、時刻＝０において拠点から循環ルートに投入され、時刻＝１２ｔにおいて規定周ｎ（ここでは、ｎ＝４周）を走行し終えると拠点に戻り、待機中の車両１０ｄと交代する。車両１０ｄは、時刻＝１２ｔにおいて拠点から循環ルートに投入され、時刻＝２４ｔにおいて規定周ｎ（ここでは、ｎ＝４周）を走行し終えると拠点に戻り、待機中の車両１０ａと交代する。このようにして、車両１０ａ及び１０ｇは互いに交代しながら運行する。同様に、車両１０ｂ及び車両１０ｅが互いに交代しながら運行し、車両１０ｃ及び車両１０ｆが互いに交代しながら運行する。ここで、同一周目の車両１０が同時に複数存在しないように、車両１０ｂは時刻＝４ｔにおいて循環ルートに投入され、車両１０ｃは時刻＝８ｔにおいて循環ルートに投入される。結果として、時刻＝８ｔ以降においては循環ルートを走行中の車両１０の台数が規定台数（ここでは、３台）に維持される。また、上述した通常入替が、時刻＝１２ｔ以降において規定周期Ｐ（ここでは、Ｐ＝４ｔ）で１回ずつ発生する。また、同一周目の車両１０が同時に複数存在しないため、規定周期Ｐを車両１０が循環ルートを１周するために要する時間（ここでは、３ｔ）よりも長くすることができる。通常入替の発生する規定周期Ｐを長くすることにより、車両１０が循環ルートから拠点に戻る頻度が低減するので、拠点に戻った車両１０に対して燃料補給及びメンテナンス等の作業を行う時間的余裕が増大する。

なお例外的に、車両１０ｅは、時刻＝ｔにおいて循環ルートに投入され、時刻＝４ｔにおいて車両１０ｂと交代する。また例外的に、車両１０ｆは、時刻＝２ｔにおいて循環ルートに投入され、時刻＝８ｔにおいて車両１０ｃと交代する。結果として、時刻＝２ｔ以降においては循環ルートを走行中の車両１０の台数が規定台数（ここでは、３台）に維持される。また、上述した通常入替が、時刻＝４ｔ以降において規定周期Ｐ（ここでは、Ｐ＝４ｔ）で１回ずつ発生する。なお、輸送サービスの営業開始時刻から一定期間（ここでは、時刻＝０から時刻＝８ｔまでの期間）においては例外的に、同一周目の車両１０が同時に複数存在することになる。しかしながら、通常入替の発生する周期を規定周期Ｐ（ここでは、Ｐ＝４ｔ）に維持すべく、当該一定期間において例外的に投入される車両１０ｅ及び１０ｆは、規定周ｎ（ここでは、ｎ＝４周）を走行し終える前にそれぞれ車両１０ｂ及び車両１０ｃと交代する。

図４を参照して、修正後の運行スケジュールについて具体的に説明する。図４は、循環ルートを走行中の車両１０ｂが規定周ｎ（ここでは、ｎ＝４周）を走行し終える前に故障した場合に、サーバ２０によって修正された運行スケジュールを示す。以下、図３に示す修正前の運行スケジュールとの差分について説明する。図中の「×」のマークは、循環ルートのｍ周目（ここでは、ｍ＝２）を走行中である車両１０ｂが時刻＝９ｔにおいて故障し、時刻＝９ｔ以降の走行が不可能になったことを示す。また、図中の車両１０ｂに対応する右向の破線矢印は、修正前の運行スケジュールにおいて予定されていた車両１０ａの時刻＝１０ｔ以降の走行がキャンセルされたことを示す。

本実施形態において、車両１０ｂがｍ周目（ただし、ｍは１以上ｎ未満の自然数）で故障した場合、車両１０ｂの代理として車両１０ｇが拠点から循環ルートに投入される。このため、循環ルートを走行中の車両１０の台数が規定台数（ここでは、３台）に維持される。詳細には、車両１０ｇは、修正前の運行スケジュールにおいて車両１０ｂによるｍ＋１周目（ここでは、ｍ＋１＝３）の走行の開始が予定されていた第１タイミング（ここでは、時刻＝１０ｔ）で、循環ルートに投入される。したがって、車両１０ｂの故障が発生した時刻＝９ｔから車両１０ｂが循環ルートに投入される時刻＝１０ｔまでの期間を除き、循環ルートを走行中の車両１０の台数が規定台数（ここでは、３台）に維持される。以下、循環ルートを走行中の車両１０が規定周ｎ（ここでは、ｎ＝４周）を走行し終える前に故障した場合に他の車両１０が投入されることを「故障入替」ともいう。

そして車両１０ｇは、規定周ｎ（ここでは、ｎ＝４周）を走行し終える前に拠点に戻り、修正前の運行スケジュールにおいて車両１０ｂと交代する予定であった車両１０ｅと交代する。詳細には、車両１０ｇは、修正前の運行スケジュールにおいて車両１０ｂによる規定周ｎ（ここでは、ｎ＝４周）の走行の完了が予定されていた第２タイミング（ここでは、時刻＝１６ｔ）で、２周目の走行を終えて車両１０ｅと交代する。かかる構成によれば、故障入替が発生した場合であっても、通常入替の発生する周期が規定周期Ｐ（ここでは、Ｐ＝４ｔ）に維持される。また、かかる構成によれば、車両１０ｅについて通常入替が発生するタイミングを修正する必要がないため、以下に説明する比較例との対比において運行スケジュールを修正するサーバ２０の負荷が低減される。

比較例として、故障入替によって投入された車両１０ｇが時刻＝２２ｔにおいて規定周ｎ（ここでは、ｎ＝４周）を走行し終えて車両１０ｅと交代するように運行スケジュールを修正することを考える。かかる場合には、時刻＝２２ｔにおいて車両１０ｇと車両１０ｅの通常入替が発生することになるが、時刻＝２０ｔにおいて車両１０ｃと車両１０ｆの通常入替が発生し、時刻＝２４ｔにおいて車両１０ｄと車両１０ａの通常入替が発生するため、時刻＝２０ｔから時刻＝２４ｔまでの期間において通常入替の発生する周期が２ｔとなってしまう。このため、通常入替の発生する周期を規定周期Ｐ（ここでは、Ｐ＝４ｔ）に維持できない。また、かかる場合には、通常入替によって車両１０ｅが循環ルートに投入されるタイミングを時刻＝１６ｔから時刻＝２２ｔに遅らせる必要がある。このため、車両１０ｅについて通常入替が発生するタイミングを、車両１０ｂに故障が発生した以降の期間に亘って修正する必要がある。したがって、本実施形態に係る上記構成によれば、当該比較例との対比において運行スケジュールを修正するサーバ２０の負荷が低減される。

また、故障が発生した車両１０ｂに割り当てられた運行スケジュールのうち、故障入替によって循環ルートに投入された車両１０ｇが拠点戻るタイミング（ここでは、時刻＝１６ｔであって、第２タイミングに相当する）以降の運行スケジュールが、車両１０ｇに新たに割り当てられる。具体的には、車両１０ｂの修正前の運行スケジュールは、例えば時刻＝１６ｔから時刻＝２８ｔまでの間に車両１０ｂに対して燃料補給及びメンテナンス等の作業が実施され、時刻＝２８ｔにおいて車両１０ｂが車両１０ｅと交代するように予定されている。そして、車両１０ｂの当該運行スケジュールが車両１０ｇに新たに割り当てられた結果、車両１０ｇの修正後の運行スケジュールは、例えば時刻＝１６ｔから時刻＝２８ｔまでの間に車両１０ｇに対して燃料補給及びメンテナンス等の作業が実施され、時刻＝２８ｔにおいて車両１０ｇが車両１０ｅと交代するように予定されている。なお、車両１０ｂの運行スケジュールを新たに割り当てる対象は、車両１０ａ～ｇ以外の他の車両１０であってもよい。

次に、システム１の各構成について詳細に説明する。

（車両の構成）
図５に示すように、車両１０は、通信部１１と、測位部１２と、撮像部１３と、記憶部１４と、制御部１５と、を備える。

通信部１１は、ネットワーク３０に接続する１つ以上の通信インタフェースを含む。当該通信インタフェースは、例えば４Ｇ（4th Generation）若しくは５Ｇ（5th Generation）等の移動体通信規格に対応するが、これらに限られない。本実施形態において、車両１０は、通信部１１及びネットワーク３０を介してサーバ２０と通信する。

測位部１２は、車両１０の位置情報を取得する１つ以上の装置を含む。具体的には、測位部１２は、例えばＧＰＳに対応する受信機を含むが、これに限られず、任意の衛星測位システムに対応する受信機を含んでもよい。

撮像部１３は、１つ以上のカメラを含む。撮像部１３に含まれる各カメラは、例えば車外又は車内の被写体を撮像可能となるように車両１０に設けられてもよい。撮像部１３によって生成される画像は、例えば車両１０の自律運転制御に利用され得る。

記憶部１４は、１つ以上のメモリを含む。メモリは、例えば半導体メモリ、磁気メモリ、又は光メモリ等であるが、これらに限られない。記憶部１４に含まれる各メモリは、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。記憶部１４は、車両１０の動作に用いられる任意の情報を記憶する。例えば、記憶部１４は、システムプログラム、アプリケーションプログラム、及び組み込みソフトウェア等を記憶してもよい。記憶部１４に記憶された情報は、例えば通信部１１を介してネットワーク３０から取得される情報で更新可能であってもよい。

制御部１５は、１つ以上のプロセッサ、１つ以上のプログラマブル回路、１つ以上の専用回路、又はこれらの組合せを含む。プロセッサは、例えばＣＰＵ（Central Processing Unit）若しくはＧＰＵ（Graphics Processing Unit）等の汎用プロセッサ、又は特定の処理に特化した専用プロセッサであるがこれらに限られない。プログラマブル回路は、例えばＦＰＧＡ（Field-Programmable Gate Array）であるがこれに限られない。専用回路は、例えばＡＳＩＣ（Application Specific Integrated Circuit）であるがこれに限られない。制御部１５は、車両１０全体の動作を制御する。例えば、制御部１５は、サーバ２０から通知された運行スケジュールに従って、車両１０の運行を制御する。

（サーバの構成）
図６に示すように、サーバ２０は、通信部２１と、記憶部２２と、制御部２３と、を備える。

通信部２１は、ネットワーク３０に接続する１つ以上の通信インタフェースを含む。当該通信インタフェースは、例えば移動体通信規格、有線ＬＡＮ（Local Area Network）規格、又は無線ＬＡＮ規格に対応するが、これらに限られず、任意の通信規格に対応してもよい。本実施形態において、サーバ２０は、通信部２１を介して車両１０と通信する。

記憶部２２は、１つ以上のメモリを含む。記憶部２２に含まれる各メモリは、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。記憶部２２は、サーバ２０の動作に用いられる任意の情報を記憶する。例えば、記憶部２２は、システムプログラム、アプリケーションプログラム、データベース、地図情報、及び複数の車両１０の運行スケジュール等を記憶してもよい。記憶部２２に記憶された情報は、例えば通信部２１を介してネットワーク３０から取得される情報で更新可能であってもよい。

制御部２３は、１つ以上のプロセッサ、１つ以上のプログラマブル回路、１つ以上の専用回路、又はこれらの組合せを含む。制御部２３は、サーバ２０全体の動作を制御する。制御部２３によって制御されるサーバ２０の動作の詳細については後述する。

（サーバの動作フロー）
図７を参照して、本実施形態に係るサーバ２０の動作について説明する。

ステップＳ１００：サーバ２０の制御部２３は、複数の車両１０の運行スケジュールを記憶部２２に記憶する。運行スケジュールは、例えば制御部２３によって自動的に生成されてもよく、オペレータによって入力されてもよく、或いは通信部２１及びネットワーク３０を介して外部装置から取得されてもよい。

ここでは、図３に示す例に即して具体的に説明する。ステップＳ１００で記憶される運行スケジュールは、複数の車両１０を用いた輸送サービスの営業開始時刻から一定期間（ここでは、時刻＝０から時刻＝８ｔまでの期間）を除き、同一周目の車両１０が同時に複数存在しないように定められている。また、当該運行スケジュールは、規定周ｎ（ここでは、ｎ＝４周）を走行し終えた車両１０と他の車両１０との交代が規定周期Ｐ（ここでは、Ｐ＝４ｔ）で１回ずつ発生するように定められている。

ステップＳ１０１：制御部２３は、複数の車両１０の状態の監視を開始する。具体的には、制御部２３は、通信部２１及びネットワーク３０を介して、複数の車両１０のそれぞれと通信可能に接続する。制御部２３は、ステップＳ１００の運行スケジュールを複数の車両１０に通知する。複数の車両１０のそれぞれは、サーバ２０から通知された運行スケジュールに従って運行する。そして制御部２３は、例えば定期的に又は任意のタイミングで、各車両１０から車両情報を受信することによって、各車両１０の状態を監視する。車両情報は、車両１０に故障が発生したか否かを示す情報を含むがこれに限られず、例えば車両１０の位置情報、車速、及び運行スケジュールとの乖離を示す情報等、車両１０に関する任意の情報を含んでもよい。

ステップＳ１０２：制御部２３は、循環ルートを走行中の車両１０が規定周ｎを走行し終える前に故障したか否かを判定する。車両１０が故障したと判定した場合（ステップＳ１０２－Ｙｅｓ）、プロセスはステップＳ１０３に進む。一方、車両１０が故障していないと判定した場合（ステップＳ１０２－Ｎｏ）、プロセスはステップＳ１０２を繰り返す。

ステップＳ１０３：ステップＳ１０２で車両１０が故障したと判定した場合（ステップＳ１０２－Ｙｅｓ）、制御部２３は、ステップＳ１００で記憶した運行スケジュールを修正する。

ここでは、図４の例に即して具体的に説明する。制御部２３は、循環ルートを走行中の車両１０ｂが規定周ｎ（ここでは、ｎ＝４周）を走行し終える前に故障した場合、車両１０ｇを循環ルートに投入し、且つ車両１０ｇが規定周ｎ（ここでは、ｎ＝４周）を走行し終える前に拠点戻って車両１０ｅと交代するように、運行スケジュールを修正する。ここで、車両１０ｂが規定周ｎ（ここでは、ｎ＝４周）を走行し終える前に故障した場合に車両１０ｇを循環ルートに投入するように運行スケジュールを修正することによって、制御部２３は、循環ルートを走行中の車両１０の台数を規定数ａ（ここでは、ａ＝３）に維持する。

詳細には、車両１０ｂがｍ周目（ｍは１以上ｎ未満の自然数。ここでは、ｍ＝２）で故障した場合、車両１０ｂによるｍ＋１周目の走行の開始が予定されていた第１タイミング（ここでは、時刻＝１０ｔ）で車両１０ｇを循環ルートに投入するように、運行スケジュールが修正される。また、車両１０ｂによる規定周ｎ（ここでは、ｎ＝４周）の走行の完了が予定されていた第２タイミング（ここでは、時刻＝１６ｔ）で車両１０ｇが車両１０ｅと交代するように、運行スケジュールが修正される。

ステップＳ１０４：制御部２３は、故障した車両１０に割り当てられた運行スケジュールの一部を、他の車両１０に新たに割り当てる。制御部２３は、ステップＳ１０３及びＳ１０４で修正された後の運行スケジュールを複数の車両１０に通知する。その後、プロセスはステップ１０２に戻る。

ここでは、図４の例に即して具体的に説明する。制御部２３は、故障した車両１０ｂに割り当てられた運行スケジュールのうち、車両１０ｇが拠点に戻るタイミング（ここでは、時刻＝１６ｔであって、第２タイミングに相当する）以降の運行スケジュールを、車両１０ｇに新たに割り当てる。しかしながら上述したように、運行スケジュールを割り当てる対象は、車両１０ａ～１０ｇ以外の他の車両であってもよい。

本発明を諸図面及び実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形及び改変を行ってもよいことに注意されたい。したがって、これらの変形及び改変は本発明の範囲に含まれることに留意されたい。例えば、各構成部又は各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の構成部又はステップ等を１つに組み合わせたり、或いは分割したりすることが可能である。

例えば、上述した実施形態において、サーバ２０の構成及び動作を、互いに通信可能な複数の情報処理装置に分散させた実施形態も可能である。また例えば、サーバ２０の一部又は全部の構成要素を車両１０に設けた実施形態も可能である。

また、上述した実施形態において、例えば循環ルートを走行中の複数の車両１０が比較的短時間に故障した場合、必ずしも当該複数の車両１０のそれぞれについて代理となる他の車両１０を循環ルートに投入しなくてもよい。例えば、現在時刻から遡って一定期間（例えば、車両１０が循環ルートを１周走行するのに要する時間を３ｔとした場合、現在時刻から３ｔ前までの期間）において、代理の車両１０を循環ルートに投入可能な台数に上限を設けてもよい。仮に、循環ルートを走行中の複数の車両１０が比較的短時間に故障した場合において当該複数の車両１０のそれぞれについて故障入替を実施すると、拠点で待機している車両１０の台数が予定よりも少なくなったり、或いはゼロになったりし得る。かかる場合、予定されていた通常入替が実施できない等の不都合が生じる可能性がある。これに対して、上述したように代理の車両１０を循環ルートに投入可能な台数に上限を設ける構成によれば、当該不都合が生じる蓋然性が低減する。

また、上述した実施形態において、循環ルートを走行中の車両１０は、運行スケジュールからの乖離（例えば、遅延時間）が大きくなると、循環ルートを走行中の他の車両１０との間の時間距離が予定よりも短くなってしまう場合がある。例えば、図３に示す運行スケジュール上では、循環ルートを走行中の車両１０同士の間の時間距離はｔであることが予定されている。しかしながら、車両１０が運行スケジュールに対して遅延すると、当該時間距離が遅延時間の分だけ短くなり得る。ここで制御部２３は、例えば通常入替又は故障入替によって代理の車両１０を循環ルートに投入する際、循環ルートを走行中である車両１０のうち、拠点との間の時間距離が基準値（例えば、ｔ）未満である車両１０が存在するか否かを判定してもよい。そして制御部２３は、拠点との間の時間距離が基準値未満である車両１０が存在しなくなるまで、代理の車両１０の投入を保留してもよい。

また、例えば汎用のコンピュータを、上述した実施形態に係るサーバ２０として機能させる実施形態も可能である。具体的には、上述した実施形態に係るサーバ２０の各機能を実現する処理内容を記述したプログラムを、汎用のコンピュータのメモリに格納し、プロセッサによって当該プログラムを読み出して実行させる。したがって、本実施形態に係る発明は、プロセッサが実行可能なプログラム、又は当該プログラムを記憶する非一時的なコンピュータ可読媒体としても実現可能である。

１システム
１０、１０ａ～１０ｇ車両
１１通信部
１２測位部
１３撮像部
１４記憶部
１５制御部
２０サーバ
２１通信部
２２記憶部
２３制御部
３０ネットワーク

Claims

それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行管理方法であって、
サーバが、
前記複数の循環バスの運行スケジュールを記憶すること、
前記複数の循環バスの状態を監視すること、及び
前記循環ルートを走行中の第１循環バスが前記規定周を走行し終える前に故障した場合、第２循環バスを前記循環ルートに投入し、且つ前記第２循環バスが前記規定周を走行し終える前に、前記第１循環バスによる前記規定周の走行の完了が予定されていた第２タイミングで前記第２循環バスが前記拠点に戻って第３循環バスと交代するように、前記運行スケジュールを修正すること
を含む、運行管理方法。
請求項１に記載の運行管理方法であって、
前記サーバは、前記第１循環バスが前記規定周を走行し終える前に故障した場合、前記第２循環バスを前記循環ルートに投入するように前記運行スケジュールを修正することによって、前記循環ルートを走行中の循環バスの台数を維持する、運行管理方法。
請求項１又は２に記載の運行管理方法であって、
前記規定周をｎ周とし、ｍを１以上ｎ未満の自然数とし、
前記第１循環バスがｍ周目で故障した場合、前記第１循環バスによるｍ＋１周目の走行の開始が予定されていた第１タイミングで前記第２循環バスを前記循環ルートに投入するように、前記運行スケジュールが修正される、運行管理方法。
請求項１から３の何れか一項に記載の運行管理方法であって、
修正前の前記運行スケジュールは、前記複数の循環バスを用いた輸送サービスの営業開始時刻から一定期間を除き、同一周目の循環バスが同時に複数存在しないように定められている、運行管理方法。
請求項１から４の何れか一項に記載の運行管理方法であって、
修正前の前記運行スケジュールは、規定周を走行し終えた循環バスと他の循環バスとの交代が規定周期で１回ずつ発生するように定められている、運行管理方法。
請求項１から５の何れか一項に記載の運行管理方法であって、
前記サーバが、前記第１循環バスに割り当てられた運行スケジュールのうち、前記第２循環バスが前記拠点に戻るタイミング以降の運行スケジュールを、前記第２循環バス又は第４循環バスに新たに割り当てることを更に含む、運行管理方法。
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行を管理するサーバであって、
制御部を備え、
前記制御部は、
前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第１循環バスが前記規定周を走行し終える前に故障した場合、第２循環バスを前記循環ルートに投入し、且つ前記第２循環バスが前記規定周を走行し終える前に、前記第１循環バスによる前記規定周の走行の完了が予定されていた第２タイミングで前記第２循環バスが前記拠点に戻って第３循環バスと交代するように、前記運行スケジュールを修正する、サーバ。
請求項７に記載のサーバであって、
前記制御部は、前記第１循環バスが前記規定周を走行し終える前に故障した場合、前記第２循環バスを前記循環ルートに投入するように前記運行スケジュールを修正することによって、前記循環ルートを走行中の循環バスの台数を維持する、サーバ。
請求項７又は８に記載のサーバであって、
前記規定周をｎ周とし、ｍを１以上ｎ未満の自然数とし、
前記制御部は、前記第１循環バスがｍ周目で故障した場合、前記第１循環バスによるｍ＋１周目の走行の開始が予定されていた第１タイミングで前記第２循環バスを前記循環ルートに投入するように、前記運行スケジュールを修正する、サーバ。
請求項７から９の何れか一項に記載のサーバであって、
修正前の前記運行スケジュールは、前記複数の循環バスを用いた輸送サービスの営業開始時刻から一定期間を除き、同一周目の循環バスが同時に複数存在しないように定められている、サーバ。
請求項７から１０の何れか一項に記載のサーバであって、
修正前の前記運行スケジュールは、規定周を走行し終えた循環バスと他の循環バスとの交代が規定周期で１回ずつ発生するように定められている、サーバ。
請求項７から１１の何れか一項に記載のサーバであって、
前記制御部は、前記第１循環バスに割り当てられた運行スケジュールのうち、前記第２循環バスが前記拠点に戻るタイミング以降の運行スケジュールを、前記第２循環バス又は第４循環バスに新たに割り当てる、サーバ。
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと、前記複数の循環バスの運行を管理するサーバと、を備えるシステムであって、
前記サーバは、前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスは、前記運行スケジュールに従って運行し、
前記サーバは、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第１循環バスが前記規定周を走行し終える前に故障した場合、第２循環バスを前記循環ルートに投入し、且つ前記第２循環バスが前記規定周を走行し終える前に、前記第１循環バスによる前記規定周の走行の完了が予定されていた第２タイミングで前記第２循環バスが前記拠点に戻って第３循環バスと交代するように、前記運行スケジュールを修正し、
前記第２循環バス及び前記第３循環バスは、修正後の前記運行スケジュールに従って運行する、システム。
請求項１３に記載のシステムであって、
前記規定周をｎ周とし、ｍを１以上ｎ未満の自然数とし、
前記サーバは、前記第１循環バスがｍ周目で故障した場合、前記第１循環バスによるｍ＋１周目の走行の開始が予定されていた第１タイミングで前記第２循環バスを前記循環ルートに投入するように、前記運行スケジュールを修正する、システム。
請求項１３又は１４の何れか一項に記載のシステムであって、
修正前の前記運行スケジュールは、前記複数の循環バスを用いた輸送サービスの営業開始時刻から一定期間を除き、同一周目の循環バスが同時に複数存在しないように定められている、システム。
請求項１３から１５の何れか一項に記載のシステムであって、
修正前の前記運行スケジュールは、規定周を走行し終えた循環バスと他の循環バスとの交代が規定周期で１回ずつ発生するように定められている、システム。
請求項１３から１６の何れか一項に記載のシステムであって、
前記サーバは、前記第１循環バスに割り当てられた運行スケジュールのうち、前記第２循環バスが前記拠点に戻るタイミング以降の運行スケジュールを、前記第２循環バス又は第４循環バスに新たに割り当て、
前記第２循環バス又は前記第４循環バスは、前記第２循環バスが前記拠点に戻るタイミング以降は、新たに割り当てられた前記運行スケジュールに従って運行する、システム。