(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-09-11
(45)【発行日】2023-09-20
(54)【発明の名称】運行管理方法、サーバ、及びシステム
(51)【国際特許分類】
G08G 1/127 20060101AFI20230912BHJP
G06Q 50/30 20120101ALI20230912BHJP
【FI】
G08G1/127 A
G06Q50/30
(21)【出願番号】P 2020176888
(22)【出願日】2020-10-21
【審査請求日】2022-09-20
(73)【特許権者】
【識別番号】000003207
【氏名又は名称】トヨタ自動車株式会社
(74)【代理人】
【識別番号】100147485
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】230118913
【氏名又は名称】杉村 光嗣
(74)【代理人】
【識別番号】100187078
【氏名又は名称】甲原 秀俊
(72)【発明者】
【氏名】東出 宇史
(72)【発明者】
【氏名】宇野 慶一
【審査官】西畑 智道
(56)【参考文献】
【文献】特開2020-013379(JP,A)
【文献】特開2006-018443(JP,A)
【文献】特開平07-132827(JP,A)
【文献】特開平08-329155(JP,A)
【文献】特開2009-018679(JP,A)
【文献】特開2018-197897(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G08G 1/00-99/00
G01C 21/00-21/36
G01C 23/00-25/00
G06Q 50/30
(57)【特許請求の範囲】
【請求項1】
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行管理方法であって、
サーバが、
前記複数の循環バスの運行スケジュールを記憶すること、
前記複数の循環バスの状態を監視すること、及び
前記循環ルートを走行中の第1循環バスが前記規定周を走行し終える前に故障した場合、第2循環バスを前記循環ルートに投入し、且つ前記第2循環バスが前記規定周を走行し終える前に
、前記第1循環バスによる前記規定周の走行の完了が予定されていた第2タイミングで前記第2循環バスが前記拠点に戻って第3循環バスと交代するように、前記運行スケジュールを修正すること
を含む、運行管理方法。
【請求項2】
請求項1に記載の運行管理方法であって、
前記サーバは、前記第1循環バスが前記規定周を走行し終える前に故障した場合、前記第2循環バスを前記循環ルートに投入するように前記運行スケジュールを修正することによって、前記循環ルートを走行中の循環バスの台数を維持する、運行管理方法。
【請求項3】
請求項1又は2に記載の運行管理方法であって、
前記規定周をn周とし、mを1以上n未満の自然数とし、
前記第1循環バスがm周目で故障した場合、前記第1循環バスによるm+1周目の走行の開始が予定されていた第1タイミングで前記第2循環バスを前記循環ルートに投入するように、前記運行スケジュールが修正される、運行管理方法。
【請求項4】
請求項1から
3の何れか一項に記載の運行管理方法であって、
修正前の前記運行スケジュールは、前記複数の循環バスを用いた輸送サービスの営業開始時刻から一定期間を除き、同一周目の循環バスが同時に複数存在しないように定められている、運行管理方法。
【請求項5】
請求項1から
4の何れか一項に記載の運行管理方法であって、
修正前の前記運行スケジュールは、規定周を走行し終えた循環バスと他の循環バスとの交代が規定周期で1回ずつ発生するように定められている、運行管理方法。
【請求項6】
請求項1から
5の何れか一項に記載の運行管理方法であって、
前記サーバが、前記第1循環バスに割り当てられた運行スケジュールのうち、前記第2循環バスが前記拠点に戻るタイミング以降の運行スケジュールを、前記第2循環バス又は第4循環バスに新たに割り当てることを更に含む、運行管理方法。
【請求項7】
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行を管理するサーバであって、
制御部を備え、
前記制御部は、
前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第1循環バスが前記規定周を走行し終える前に故障した場合、第2循環バスを前記循環ルートに投入し、且つ前記第2循環バスが前記規定周を走行し終える前に
、前記第1循環バスによる前記規定周の走行の完了が予定されていた第2タイミングで前記第2循環バスが前記拠点に戻って第3循環バスと交代するように、前記運行スケジュールを修正する、サーバ。
【請求項8】
請求項
7に記載のサーバであって、
前記制御部は、前記第1循環バスが前記規定周を走行し終える前に故障した場合、前記第2循環バスを前記循環ルートに投入するように前記運行スケジュールを修正することによって、前記循環ルートを走行中の循環バスの台数を維持する、サーバ。
【請求項9】
請求項
7又は
8に記載のサーバであって、
前記規定周をn周とし、mを1以上n未満の自然数とし、
前記制御部は、前記第1循環バスがm周目で故障した場合、前記第1循環バスによるm+1周目の走行の開始が予定されていた第1タイミングで前記第2循環バスを前記循環ルートに投入するように、前記運行スケジュールを修正する、サーバ。
【請求項10】
請求項
7から
9の何れか一項に記載のサーバであって、
修正前の前記運行スケジュールは、前記複数の循環バスを用いた輸送サービスの営業開始時刻から一定期間を除き、同一周目の循環バスが同時に複数存在しないように定められている、サーバ。
【請求項11】
請求項
7から
10の何れか一項に記載のサーバであって、
修正前の前記運行スケジュールは、規定周を走行し終えた循環バスと他の循環バスとの交代が規定周期で1回ずつ発生するように定められている、サーバ。
【請求項12】
請求項
7から
11の何れか一項に記載のサーバであって、
前記制御部は、前記第1循環バスに割り当てられた運行スケジュールのうち、前記第2循環バスが前記拠点に戻るタイミング以降の運行スケジュールを、前記第2循環バス又は第4循環バスに新たに割り当てる、サーバ。
【請求項13】
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと、前記複数の循環バスの運行を管理するサーバと、を備えるシステムであって、
前記サーバは、前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスは、前記運行スケジュールに従って運行し、
前記サーバは、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第1循環バスが前記規定周を走行し終える前に故障した場合、第2循環バスを前記循環ルートに投入し、且つ前記第2循環バスが前記規定周を走行し終える前に
、前記第1循環バスによる前記規定周の走行の完了が予定されていた第2タイミングで前記第2循環バスが前記拠点に戻って第3循環バスと交代するように、前記運行スケジュールを修正し、
前記第2循環バス及び前記第3循環バスは、修正後の前記運行スケジュールに従って運行する、システム。
【請求項14】
請求項
13に記載のシステムであって、
前記規定周をn周とし、mを1以上n未満の自然数とし、
前記サーバは、前記第1循環バスがm周目で故障した場合、前記第1循環バスによるm+1周目の走行の開始が予定されていた第1タイミングで前記第2循環バスを前記循環ルートに投入するように、前記運行スケジュールを修正する、システム。
【請求項15】
請求項
13又は14の何れか一項に記載のシステムであって、
修正前の前記運行スケジュールは、前記複数の循環バスを用いた輸送サービスの営業開始時刻から一定期間を除き、同一周目の循環バスが同時に複数存在しないように定められている、システム。
【請求項16】
請求項
13から
15の何れか一項に記載のシステムであって、
修正前の前記運行スケジュールは、規定周を走行し終えた循環バスと他の循環バスとの交代が規定周期で1回ずつ発生するように定められている、システム。
【請求項17】
請求項
13から
16の何れか一項に記載のシステムであって、
前記サーバは、前記第1循環バスに割り当てられた運行スケジュールのうち、前記第2循環バスが前記拠点に戻るタイミング以降の運行スケジュールを、前記第2循環バス又は第4循環バスに新たに割り当て、
前記第2循環バス又は前記第4循環バスは、前記第2循環バスが前記拠点に戻るタイミング以降は、新たに割り当てられた前記運行スケジュールに従って運行する、システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、運行管理方法、サーバ、及びシステムに関する。
【背景技術】
【0002】
従来、複数の車両の運行を管理する技術が知られている。例えば特許文献1には、管理センタから提供される走行経路に従って周回走行する自動運転車両が開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
車両に循環ルートを走行させる場合、例えば燃料補給及びメンテナンス等の作業を当該車両に対して実施するために、当該車両を待機中の他の車両と計画的に入れ替えるように運行スケジュールが決定され得る。一方、例えば循環ルートを走行中の車両に故障が発生した場合、当該車両を待機中の他の車両と入れ替えることが考えられる。しかしながら、故障の発生を予見することは困難であるため、故障の発生に応じて車両の入替えを実施すると、予め計画された運行スケジュールに悪影響が及ぶ可能性がある。したがって、複数の車両の運行を管理する技術には改善の余地がある。
【0005】
かかる事情に鑑みてなされた本開示の目的は、複数の車両の運行を管理する技術を改善することにある。
【課題を解決するための手段】
【0006】
本開示の一実施形態に係る運行管理方法は、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行管理方法であって、
サーバが、
前記複数の循環バスの運行スケジュールを記憶すること、
前記複数の循環バスの状態を監視すること、及び
前記循環ルートを走行中の第1循環バスが前記規定周を走行し終える前に故障した場合、第2循環バスを前記循環ルートに投入し、且つ前記第2循環バスが前記規定周を走行し終える前に前記拠点に戻って第3循環バスと交代するように、前記運行スケジュールを修正することを含む。
【0007】
本開示の一実施形態に係るサーバは、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行を管理するサーバであって、
制御部を備え、
前記制御部は、
前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第1循環バスが前記規定周を走行し終える前に故障した場合、第2循環バスを前記循環ルートに投入し、且つ前記第2循環バスが前記規定周を走行し終える前に前記拠点に戻って第3循環バスと交代するように、前記運行スケジュールを修正する。
【0008】
本開示の一実施形態に係るシステムは、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと、前記複数の循環バスの運行を管理するサーバと、を備えるシステムであって、
前記サーバは、前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスは、前記運行スケジュールに従って運行し、
前記サーバは、
前記複数の循環バスの状態を監視し、
前記循環ルートを走行中の第1循環バスが前記規定周を走行し終える前に故障した場合、第2循環バスを前記循環ルートに投入し、且つ前記第2循環バスが前記規定周を走行し終える前に前記拠点に戻って第3循環バスと交代するように、前記運行スケジュールを修正し、
前記第2循環バス及び前記第3循環バスは、修正後の前記運行スケジュールに従って運行する。
【発明の効果】
【0009】
本開示の一実施形態によれば、複数の車両の運行を管理する技術が改善される。
【図面の簡単な説明】
【0010】
【
図1】本開示の一実施形態に係るシステムの概略構成を示すブロック図である。
【
図2】本開示の一実施形態に係る輸送サービスの概要を示す図である。
【
図3】修正前の運行スケジュールの例を示す図である。
【
図4】修正後の運行スケジュールの例を示す図である。
【発明を実施するための形態】
【0011】
以下、本発明の実施形態について説明する。
【0012】
(実施形態の概要)
図1を参照して、本開示の実施形態に係るシステム1の概要について説明する。システム1は、複数の車両10と、サーバ20と、を備える。複数の車両10及びサーバ20は、例えばインターネット及び移動体通信網等を含むネットワーク30を介して互いに通信可能である。車両10は、例えばバス等の旅客自動車であるが、これに限られず人間が乗車可能な任意の車両であってもよい。車両10は、例えばSAE(Society of Automotive Engineers)において定義されるレベル1乃至5等の自動運転が可能であってもよい。サーバ20は、例えばコンピュータ等の情報処理装置である。
【0013】
本実施形態において複数の車両10は、循環ルートを走行する循環バスとして用いられる。サーバ20は、複数の車両10に対して運行スケジュールを通知することによって、複数の車両10の運行管理を行う。複数の車両10は、サーバ20から通知される運行スケジュールに従って運行する。また、循環ルートの走行中の車両10に故障が発生した場合、サーバ20は、後述するように運行スケジュールを修正し得る。
【0014】
図2を参照して、修正前の運行スケジュールに従って運行する各車両10の動作の概要について説明する。複数の車両10のそれぞれは、拠点から循環ルートに投入されると、循環ルートを時計回りに走行しながら、循環ルート上の各バス停X~Zで乗客を乗降させ得る。
図2においては、3台の車両10a~10cが循環ルートを走行中である。複数の車両10のそれぞれは、循環ルートに投入されてから規定周n(本実施形態では、n=4周)を走行すると、拠点に戻って他の待機中の車両10と交代する。ここで「交代」とは、車両10が循環ルートから拠点に戻るとともに、待機中の他の車両10が拠点から循環ルートに投入されることを示す。以下、車両10が待機中の他の車両10と交代することを「通常入替」ともいう。
図2においては、2台の車両10d~10eが拠点で待機中である。複数の車両10のそれぞれは、循環ルートから拠点に戻ると、例えば燃料補給及びメンテナンス等の作業を受けた後に拠点で待機する。
【0015】
また、修正前の運行スケジュールは、循環ルートを走行中である車両10の台数が原則として規定数a(本実施形態では、a=3)になるように定められる。また、修正前の運行スケジュールは、上述した通常入替が規定周期Pで1回ずつ発生するように定められる。
【0016】
図3を参照して、修正前の運行スケジュールについて具体的に説明する。
図3は、7台の車両10a~10gのそれぞれに割り当てられた運行スケジュールを示す。図中の横軸は時刻を示す。時刻=0は、複数の車両10を用いた輸送サービスの営業開始時刻である。右向の矢印が図示されている期間は、車両10が循環ルートを走行中であることを示す。当該矢印の長さは、車両10が循環ルートを1周するのに要する時間(本実施形態では、3t)を示す。当該矢印の内部の数値は、車両10が循環ルートに投入されてから何周目を走行中であるかを示す。内部の数値が「1」である矢印の左端に相当する時刻は、車両10が拠点から循環ルートに投入される時刻を示す。また、当該矢印の右端に相当する時刻は、当該矢印の右側に次の矢印が存在しない場合には、車両10が循環ルートから拠点に戻る時刻を示す。
【0017】
図3に示す修正前の運行スケジュールが適用される場合、例えば車両10aは、時刻=0において拠点から循環ルートに投入され、時刻=12tにおいて規定周n(ここでは、n=4周)を走行し終えると拠点に戻り、待機中の車両10dと交代する。車両10dは、時刻=12tにおいて拠点から循環ルートに投入され、時刻=24tにおいて規定周n(ここでは、n=4周)を走行し終えると拠点に戻り、待機中の車両10aと交代する。このようにして、車両10a及び10gは互いに交代しながら運行する。同様に、車両10b及び車両10eが互いに交代しながら運行し、車両10c及び車両10fが互いに交代しながら運行する。ここで、同一周目の車両10が同時に複数存在しないように、車両10bは時刻=4tにおいて循環ルートに投入され、車両10cは時刻=8tにおいて循環ルートに投入される。結果として、時刻=8t以降においては循環ルートを走行中の車両10の台数が規定台数(ここでは、3台)に維持される。また、上述した通常入替が、時刻=12t以降において規定周期P(ここでは、P=4t)で1回ずつ発生する。また、同一周目の車両10が同時に複数存在しないため、規定周期Pを車両10が循環ルートを1周するために要する時間(ここでは、3t)よりも長くすることができる。通常入替の発生する規定周期Pを長くすることにより、車両10が循環ルートから拠点に戻る頻度が低減するので、拠点に戻った車両10に対して燃料補給及びメンテナンス等の作業を行う時間的余裕が増大する。
【0018】
なお例外的に、車両10eは、時刻=tにおいて循環ルートに投入され、時刻=4tにおいて車両10bと交代する。また例外的に、車両10fは、時刻=2tにおいて循環ルートに投入され、時刻=8tにおいて車両10cと交代する。結果として、時刻=2t以降においては循環ルートを走行中の車両10の台数が規定台数(ここでは、3台)に維持される。また、上述した通常入替が、時刻=4t以降において規定周期P(ここでは、P=4t)で1回ずつ発生する。なお、輸送サービスの営業開始時刻から一定期間(ここでは、時刻=0から時刻=8tまでの期間)においては例外的に、同一周目の車両10が同時に複数存在することになる。しかしながら、通常入替の発生する周期を規定周期P(ここでは、P=4t)に維持すべく、当該一定期間において例外的に投入される車両10e及び10fは、規定周n(ここでは、n=4周)を走行し終える前にそれぞれ車両10b及び車両10cと交代する。
【0019】
図4を参照して、修正後の運行スケジュールについて具体的に説明する。
図4は、循環ルートを走行中の車両10bが規定周n(ここでは、n=4周)を走行し終える前に故障した場合に、サーバ20によって修正された運行スケジュールを示す。以下、
図3に示す修正前の運行スケジュールとの差分について説明する。図中の「×」のマークは、循環ルートのm周目(ここでは、m=2)を走行中である車両10bが時刻=9tにおいて故障し、時刻=9t以降の走行が不可能になったことを示す。また、図中の車両10bに対応する右向の破線矢印は、修正前の運行スケジュールにおいて予定されていた車両10aの時刻=10t以降の走行がキャンセルされたことを示す。
【0020】
本実施形態において、車両10bがm周目(ただし、mは1以上n未満の自然数)で故障した場合、車両10bの代理として車両10gが拠点から循環ルートに投入される。このため、循環ルートを走行中の車両10の台数が規定台数(ここでは、3台)に維持される。詳細には、車両10gは、修正前の運行スケジュールにおいて車両10bによるm+1周目(ここでは、m+1=3)の走行の開始が予定されていた第1タイミング(ここでは、時刻=10t)で、循環ルートに投入される。したがって、車両10bの故障が発生した時刻=9tから車両10bが循環ルートに投入される時刻=10tまでの期間を除き、循環ルートを走行中の車両10の台数が規定台数(ここでは、3台)に維持される。以下、循環ルートを走行中の車両10が規定周n(ここでは、n=4周)を走行し終える前に故障した場合に他の車両10が投入されることを「故障入替」ともいう。
【0021】
そして車両10gは、規定周n(ここでは、n=4周)を走行し終える前に拠点に戻り、修正前の運行スケジュールにおいて車両10bと交代する予定であった車両10eと交代する。詳細には、車両10gは、修正前の運行スケジュールにおいて車両10bによる規定周n(ここでは、n=4周)の走行の完了が予定されていた第2タイミング(ここでは、時刻=16t)で、2周目の走行を終えて車両10eと交代する。かかる構成によれば、故障入替が発生した場合であっても、通常入替の発生する周期が規定周期P(ここでは、P=4t)に維持される。また、かかる構成によれば、車両10eについて通常入替が発生するタイミングを修正する必要がないため、以下に説明する比較例との対比において運行スケジュールを修正するサーバ20の負荷が低減される。
【0022】
比較例として、故障入替によって投入された車両10gが時刻=22tにおいて規定周n(ここでは、n=4周)を走行し終えて車両10eと交代するように運行スケジュールを修正することを考える。かかる場合には、時刻=22tにおいて車両10gと車両10eの通常入替が発生することになるが、時刻=20tにおいて車両10cと車両10fの通常入替が発生し、時刻=24tにおいて車両10dと車両10aの通常入替が発生するため、時刻=20tから時刻=24tまでの期間において通常入替の発生する周期が2tとなってしまう。このため、通常入替の発生する周期を規定周期P(ここでは、P=4t)に維持できない。また、かかる場合には、通常入替によって車両10eが循環ルートに投入されるタイミングを時刻=16tから時刻=22tに遅らせる必要がある。このため、車両10eについて通常入替が発生するタイミングを、車両10bに故障が発生した以降の期間に亘って修正する必要がある。したがって、本実施形態に係る上記構成によれば、当該比較例との対比において運行スケジュールを修正するサーバ20の負荷が低減される。
【0023】
また、故障が発生した車両10bに割り当てられた運行スケジュールのうち、故障入替によって循環ルートに投入された車両10gが拠点戻るタイミング(ここでは、時刻=16tであって、第2タイミングに相当する)以降の運行スケジュールが、車両10gに新たに割り当てられる。具体的には、車両10bの修正前の運行スケジュールは、例えば時刻=16tから時刻=28tまでの間に車両10bに対して燃料補給及びメンテナンス等の作業が実施され、時刻=28tにおいて車両10bが車両10eと交代するように予定されている。そして、車両10bの当該運行スケジュールが車両10gに新たに割り当てられた結果、車両10gの修正後の運行スケジュールは、例えば時刻=16tから時刻=28tまでの間に車両10gに対して燃料補給及びメンテナンス等の作業が実施され、時刻=28tにおいて車両10gが車両10eと交代するように予定されている。なお、車両10bの運行スケジュールを新たに割り当てる対象は、車両10a~g以外の他の車両10であってもよい。
【0024】
次に、システム1の各構成について詳細に説明する。
【0025】
(車両の構成)
図5に示すように、車両10は、通信部11と、測位部12と、撮像部13と、記憶部14と、制御部15と、を備える。
【0026】
通信部11は、ネットワーク30に接続する1つ以上の通信インタフェースを含む。当該通信インタフェースは、例えば4G(4th Generation)若しくは5G(5th Generation)等の移動体通信規格に対応するが、これらに限られない。本実施形態において、車両10は、通信部11及びネットワーク30を介してサーバ20と通信する。
【0027】
測位部12は、車両10の位置情報を取得する1つ以上の装置を含む。具体的には、測位部12は、例えばGPSに対応する受信機を含むが、これに限られず、任意の衛星測位システムに対応する受信機を含んでもよい。
【0028】
撮像部13は、1つ以上のカメラを含む。撮像部13に含まれる各カメラは、例えば車外又は車内の被写体を撮像可能となるように車両10に設けられてもよい。撮像部13によって生成される画像は、例えば車両10の自律運転制御に利用され得る。
【0029】
記憶部14は、1つ以上のメモリを含む。メモリは、例えば半導体メモリ、磁気メモリ、又は光メモリ等であるが、これらに限られない。記憶部14に含まれる各メモリは、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。記憶部14は、車両10の動作に用いられる任意の情報を記憶する。例えば、記憶部14は、システムプログラム、アプリケーションプログラム、及び組み込みソフトウェア等を記憶してもよい。記憶部14に記憶された情報は、例えば通信部11を介してネットワーク30から取得される情報で更新可能であってもよい。
【0030】
制御部15は、1つ以上のプロセッサ、1つ以上のプログラマブル回路、1つ以上の専用回路、又はこれらの組合せを含む。プロセッサは、例えばCPU(Central Processing Unit)若しくはGPU(Graphics Processing Unit)等の汎用プロセッサ、又は特定の処理に特化した専用プロセッサであるがこれらに限られない。プログラマブル回路は、例えばFPGA(Field-Programmable Gate Array)であるがこれに限られない。専用回路は、例えばASIC(Application Specific Integrated Circuit)であるがこれに限られない。制御部15は、車両10全体の動作を制御する。例えば、制御部15は、サーバ20から通知された運行スケジュールに従って、車両10の運行を制御する。
【0031】
(サーバの構成)
図6に示すように、サーバ20は、通信部21と、記憶部22と、制御部23と、を備える。
【0032】
通信部21は、ネットワーク30に接続する1つ以上の通信インタフェースを含む。当該通信インタフェースは、例えば移動体通信規格、有線LAN(Local Area Network)規格、又は無線LAN規格に対応するが、これらに限られず、任意の通信規格に対応してもよい。本実施形態において、サーバ20は、通信部21を介して車両10と通信する。
【0033】
記憶部22は、1つ以上のメモリを含む。記憶部22に含まれる各メモリは、例えば主記憶装置、補助記憶装置、又はキャッシュメモリとして機能してもよい。記憶部22は、サーバ20の動作に用いられる任意の情報を記憶する。例えば、記憶部22は、システムプログラム、アプリケーションプログラム、データベース、地図情報、及び複数の車両10の運行スケジュール等を記憶してもよい。記憶部22に記憶された情報は、例えば通信部21を介してネットワーク30から取得される情報で更新可能であってもよい。
【0034】
制御部23は、1つ以上のプロセッサ、1つ以上のプログラマブル回路、1つ以上の専用回路、又はこれらの組合せを含む。制御部23は、サーバ20全体の動作を制御する。制御部23によって制御されるサーバ20の動作の詳細については後述する。
【0035】
(サーバの動作フロー)
図7を参照して、本実施形態に係るサーバ20の動作について説明する。
【0036】
ステップS100:サーバ20の制御部23は、複数の車両10の運行スケジュールを記憶部22に記憶する。運行スケジュールは、例えば制御部23によって自動的に生成されてもよく、オペレータによって入力されてもよく、或いは通信部21及びネットワーク30を介して外部装置から取得されてもよい。
【0037】
ここでは、
図3に示す例に即して具体的に説明する。ステップS100で記憶される運行スケジュールは、複数の車両10を用いた輸送サービスの営業開始時刻から一定期間(ここでは、時刻=0から時刻=8tまでの期間)を除き、同一周目の車両10が同時に複数存在しないように定められている。また、当該運行スケジュールは、規定周n(ここでは、n=4周)を走行し終えた車両10と他の車両10との交代が規定周期P(ここでは、P=4t)で1回ずつ発生するように定められている。
【0038】
ステップS101:制御部23は、複数の車両10の状態の監視を開始する。具体的には、制御部23は、通信部21及びネットワーク30を介して、複数の車両10のそれぞれと通信可能に接続する。制御部23は、ステップS100の運行スケジュールを複数の車両10に通知する。複数の車両10のそれぞれは、サーバ20から通知された運行スケジュールに従って運行する。そして制御部23は、例えば定期的に又は任意のタイミングで、各車両10から車両情報を受信することによって、各車両10の状態を監視する。車両情報は、車両10に故障が発生したか否かを示す情報を含むがこれに限られず、例えば車両10の位置情報、車速、及び運行スケジュールとの乖離を示す情報等、車両10に関する任意の情報を含んでもよい。
【0039】
ステップS102:制御部23は、循環ルートを走行中の車両10が規定周nを走行し終える前に故障したか否かを判定する。車両10が故障したと判定した場合(ステップS102-Yes)、プロセスはステップS103に進む。一方、車両10が故障していないと判定した場合(ステップS102-No)、プロセスはステップS102を繰り返す。
【0040】
ステップS103:ステップS102で車両10が故障したと判定した場合(ステップS102-Yes)、制御部23は、ステップS100で記憶した運行スケジュールを修正する。
【0041】
ここでは、
図4の例に即して具体的に説明する。制御部23は、循環ルートを走行中の車両10bが規定周n(ここでは、n=4周)を走行し終える前に故障した場合、車両10gを循環ルートに投入し、且つ車両10gが規定周n(ここでは、n=4周)を走行し終える前に拠点戻って車両10eと交代するように、運行スケジュールを修正する。ここで、車両10bが規定周n(ここでは、n=4周)を走行し終える前に故障した場合に車両10gを循環ルートに投入するように運行スケジュールを修正することによって、制御部23は、循環ルートを走行中の車両10の台数を規定数a(ここでは、a=3)に維持する。
【0042】
詳細には、車両10bがm周目(mは1以上n未満の自然数。ここでは、m=2)で故障した場合、車両10bによるm+1周目の走行の開始が予定されていた第1タイミング(ここでは、時刻=10t)で車両10gを循環ルートに投入するように、運行スケジュールが修正される。また、車両10bによる規定周n(ここでは、n=4周)の走行の完了が予定されていた第2タイミング(ここでは、時刻=16t)で車両10gが車両10eと交代するように、運行スケジュールが修正される。
【0043】
ステップS104:制御部23は、故障した車両10に割り当てられた運行スケジュールの一部を、他の車両10に新たに割り当てる。制御部23は、ステップS103及びS104で修正された後の運行スケジュールを複数の車両10に通知する。その後、プロセスはステップ102に戻る。
【0044】
ここでは、
図4の例に即して具体的に説明する。制御部23は、故障した車両10bに割り当てられた運行スケジュールのうち、車両10gが拠点に戻るタイミング(ここでは、時刻=16tであって、第2タイミングに相当する)以降の運行スケジュールを、車両10gに新たに割り当てる。しかしながら上述したように、運行スケジュールを割り当てる対象は、車両10a~10g以外の他の車両であってもよい。
【0045】
本発明を諸図面及び実施例に基づき説明してきたが、当業者であれば本開示に基づき種々の変形及び改変を行ってもよいことに注意されたい。したがって、これらの変形及び改変は本発明の範囲に含まれることに留意されたい。例えば、各構成部又は各ステップ等に含まれる機能等は論理的に矛盾しないように再配置可能であり、複数の構成部又はステップ等を1つに組み合わせたり、或いは分割したりすることが可能である。
【0046】
例えば、上述した実施形態において、サーバ20の構成及び動作を、互いに通信可能な複数の情報処理装置に分散させた実施形態も可能である。また例えば、サーバ20の一部又は全部の構成要素を車両10に設けた実施形態も可能である。
【0047】
また、上述した実施形態において、例えば循環ルートを走行中の複数の車両10が比較的短時間に故障した場合、必ずしも当該複数の車両10のそれぞれについて代理となる他の車両10を循環ルートに投入しなくてもよい。例えば、現在時刻から遡って一定期間(例えば、車両10が循環ルートを1周走行するのに要する時間を3tとした場合、現在時刻から3t前までの期間)において、代理の車両10を循環ルートに投入可能な台数に上限を設けてもよい。仮に、循環ルートを走行中の複数の車両10が比較的短時間に故障した場合において当該複数の車両10のそれぞれについて故障入替を実施すると、拠点で待機している車両10の台数が予定よりも少なくなったり、或いはゼロになったりし得る。かかる場合、予定されていた通常入替が実施できない等の不都合が生じる可能性がある。これに対して、上述したように代理の車両10を循環ルートに投入可能な台数に上限を設ける構成によれば、当該不都合が生じる蓋然性が低減する。
【0048】
また、上述した実施形態において、循環ルートを走行中の車両10は、運行スケジュールからの乖離(例えば、遅延時間)が大きくなると、循環ルートを走行中の他の車両10との間の時間距離が予定よりも短くなってしまう場合がある。例えば、
図3に示す運行スケジュール上では、循環ルートを走行中の車両10同士の間の時間距離はtであることが予定されている。しかしながら、車両10が運行スケジュールに対して遅延すると、当該時間距離が遅延時間の分だけ短くなり得る。ここで制御部23は、例えば通常入替又は故障入替によって代理の車両10を循環ルートに投入する際、循環ルートを走行中である車両10のうち、拠点との間の時間距離が基準値(例えば、t)未満である車両10が存在するか否かを判定してもよい。そして制御部23は、拠点との間の時間距離が基準値未満である車両10が存在しなくなるまで、代理の車両10の投入を保留してもよい。
【0049】
また、例えば汎用のコンピュータを、上述した実施形態に係るサーバ20として機能させる実施形態も可能である。具体的には、上述した実施形態に係るサーバ20の各機能を実現する処理内容を記述したプログラムを、汎用のコンピュータのメモリに格納し、プロセッサによって当該プログラムを読み出して実行させる。したがって、本実施形態に係る発明は、プロセッサが実行可能なプログラム、又は当該プログラムを記憶する非一時的なコンピュータ可読媒体としても実現可能である。
【符号の説明】
【0050】
1 システム
10、10a~10g 車両
11 通信部
12 測位部
13 撮像部
14 記憶部
15 制御部
20 サーバ
21 通信部
22 記憶部
23 制御部
30 ネットワーク