特許 7396247 運行管理方法、サーバ、及びシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-04

(45)【発行日】2023-12-12

(54)【発明の名称】運行管理方法、サーバ、及びシステム

(51)【国際特許分類】

   G08G 1/127 20060101AFI20231205BHJP

   G06Q 50/30 20120101ALI20231205BHJP

【ＦＩ】

G08G1/127 A

G06Q50/30

【請求項の数】 20

(21)【出願番号】P 2020180005

(22)【出願日】2020-10-27

(65)【公開番号】P2022070762

(43)【公開日】2022-05-13

【審査請求日】2022-09-20

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】100147485

【弁理士】

【氏名又は名称】杉村 憲司

(74)【代理人】

【識別番号】230118913

【弁護士】

【氏名又は名称】杉村 光嗣

(74)【代理人】

【識別番号】100187078

【弁理士】

【氏名又は名称】甲原 秀俊

(72)【発明者】

【氏名】東出 宇史

(72)【発明者】

【氏名】宇野 慶一

【審査官】貞光 大樹

(56)【参考文献】

【文献】特開２０２０－１６０８３６（ＪＰ，Ａ）

【文献】特開２００６－１６３７３８（ＪＰ，Ａ）

【文献】特開２００３－１６８１９３（ＪＰ，Ａ）

【文献】特開２０２０－１４０３５１（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０８Ｇ １／００ － ９９／００

Ｇ０６Ｑ １０／００ － １０／３０

Ｇ０６Ｑ ３０／００ － ３０／０８

Ｇ０６Ｑ ５０／００ － ５０／２０

Ｇ０６Ｑ ５０／２６ － ９９／００

Ｇ１６Ｚ ９９／００

(57)【特許請求の範囲】

【請求項1】

それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行管理方法であって、
サーバが、
前記複数の循環バスの運行スケジュールを記憶すること、
前記運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定すること、及び
前記所定の条件が満たされると判定した場合、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正すること
を含む、運行管理方法。

【請求項2】

請求項１に記載の運行管理方法であって、
前記所定のイベントは、前記循環ルートを走行中の循環バスが故障する第１イベント、前記循環ルートを走行中の循環バスの前記運行スケジュールに対する遅延時間が閾値以上になる第２イベント、又は前記複数の循環バスを用いた輸送サービスの利用客の人数が閾値以上になる第３イベントを含む、運行管理方法。

【請求項3】

請求項１又は２に記載の運行管理方法であって、
前記サーバは、前記拠点で待機中の循環バスの台数に基づいて、前記所定の条件が満たされるか否かを判定する、運行管理方法。

【請求項4】

請求項３に記載の運行管理方法であって、
前記拠点で待機中の前記循環バスは、修正前の前記運行スケジュール上で、循環バスと他の循環バスとの交代が次に発生するタイミングまでに燃料補給又はメンテナンスが完了する予定の循環バスであり、
前記所定の条件は、前記拠点で待機中の循環バスの台数が２台以上であるという第１条件を含む、運行管理方法。

【請求項5】

請求項１から４の何れか一項に記載の運行管理方法であって、
前記所定の条件は、前記所定のイベントの発生時刻の所定時間前から前記発生時刻までの期間に前記循環ルートに投入された追加の循環バスの台数が上限値未満であるという第２条件を含む、運行管理方法。

【請求項6】

請求項１から５の何れか一項に記載の運行管理方法であって、
前記サーバが、前記複数の循環バスの運行履歴を記憶することを更に含み、
前記サーバは、前記運行履歴に基づいて、前記所定の条件が満たされるか否かを判定する、運行管理方法。

【請求項7】

請求項６に記載の運行管理方法であって、
前記サーバは、前記運行履歴に基づいて、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正する場合の修正案を生成し、
前記所定の条件は、生成された前記修正案が所定の要件を満たすという第３条件を含み、
前記サーバは、前記所定の条件が満たされると判定した場合、前記修正案に従って前記運行スケジュールを修正する、運行管理方法。

【請求項8】

それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと通信する通信部と、制御部と、を備えるサーバであって、
前記制御部は、
前記複数の循環バスの運行スケジュールを記憶し、
前記運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定し、
前記所定の条件が満たされると判定した場合、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正する、サーバ。

【請求項9】

請求項８に記載のサーバであって、
前記所定のイベントは、前記循環ルートを走行中の循環バスが故障する第１イベント、前記循環ルートを走行中の循環バスの前記運行スケジュールに対する遅延時間が閾値以上になる第２イベント、又は前記複数の循環バスを用いた輸送サービスの利用客の人数が閾値以上になる第３イベントを含む、サーバ。

【請求項10】

請求項８又は９に記載のサーバであって、
前記制御部は、前記拠点で待機中の循環バスの台数に基づいて、前記所定の条件が満たされるか否かを判定する、サーバ。

【請求項11】

請求項１０に記載のサーバであって、
前記拠点で待機中の前記循環バスは、修正前の前記運行スケジュール上で、循環バスと他の循環バスとの交代が次に発生するタイミングまでに燃料補給又はメンテナンスが完了する予定の循環バスであり、
前記所定の条件は、前記拠点で待機中の循環バスの台数が２台以上であるという第１条件を含む、サーバ。

【請求項12】

請求項８から１１の何れか一項に記載のサーバであって、
前記所定の条件は、前記所定のイベントの発生時刻の所定時間前から前記発生時刻までの期間に前記循環ルートに投入された追加の循環バスの台数が上限値未満であるという第２条件を含む、サーバ。

【請求項13】

請求項８から１２の何れか一項に記載のサーバであって、
前記制御部は、
前記複数の循環バスの運行履歴を記憶し、
前記運行履歴に基づいて、前記所定の条件が満たされるか否かを判定する、サーバ。

【請求項14】

請求項１３に記載のサーバであって、
前記制御部は、前記運行履歴に基づいて、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正する場合の修正案を生成し、
前記所定の条件は、生成された前記修正案が所定の要件を満たすという第３条件を含み、
前記制御部は、前記所定の条件が満たされると判定した場合、前記修正案に従って前記運行スケジュールを修正する、サーバ。

【請求項15】

それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと、前記複数の循環バスと通信するサーバと、を備えるシステムであって、
前記サーバは、前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスは、前記運行スケジュールに従って運行し、
前記サーバは、
前記運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定し、
前記所定の条件が満たされると判定した場合、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正し、
前記複数の循環バスは、修正後の前記運行スケジュールに従って運行する、システム。

【請求項16】

請求項１５に記載のシステムであって、
前記所定のイベントは、前記循環ルートを走行中の循環バスが故障する第１イベント、前記循環ルートを走行中の循環バスの前記運行スケジュールに対する遅延時間が閾値以上になる第２イベント、又は前記複数の循環バスを用いた輸送サービスの利用客の人数が閾値以上になる第３イベントを含む、システム。

【請求項17】

請求項１５又は１６に記載のシステムであって、
前記サーバは、前記拠点で待機中の循環バスの台数に基づいて、前記所定の条件が満たされるか否かを判定する、システム。

【請求項18】

請求項１７に記載のシステムであって、
前記拠点で待機中の前記循環バスは、修正前の前記運行スケジュール上で、循環バスと他の循環バスとの交代が次に発生するタイミングまでに燃料補給又はメンテナンスが完了する予定の循環バスであり、
前記所定の条件は、前記拠点で待機中の循環バスの台数が２台以上であるという第１条件を含む、システム。

【請求項19】

請求項１５から１８の何れか一項に記載のシステムであって、
前記所定の条件は、前記所定のイベントの発生時刻の所定時間前から前記発生時刻までの期間に前記循環ルートに投入された追加の循環バスの台数が上限値未満であるという第２条件を含む、システム。

【請求項20】

請求項１５から１９の何れか一項に記載のシステムであって、
前記サーバは、前記複数の循環バスの運行履歴に基づいて、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正する場合の修正案を生成し、
前記所定の条件は、生成された前記修正案が所定の要件を満たすという第３条件を含み、
前記サーバは、前記所定の条件が満たされると判定した場合、前記修正案に従って前記運行スケジュールを修正する、システム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２０－０１３３７９号公報

【発明の概要】

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

【0004】

複数の車両の運行を管理する技術には改善の余地がある。

【0005】

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

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

【0006】

本開示の一実施形態に係る運行管理方法は、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスの運行管理方法であって、
サーバが、
前記複数の循環バスの運行スケジュールを記憶すること、
前記運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定すること、及び
前記所定の条件が満たされると判定した場合、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正することを含む。

【0007】

本開示の一実施形態に係るサーバは、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと通信する通信部と、制御部と、を備えるサーバであって、
前記制御部は、
前記複数の循環バスの運行スケジュールを記憶し、
前記運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定し、
前記所定の条件が満たされると判定した場合、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正する。

【0008】

本開示の一実施形態に係るシステムは、
それぞれ拠点から循環ルートに投入され規定周を走行すると前記拠点に戻って他の循環バスと交代する複数の循環バスと、前記複数の循環バスと通信するサーバと、を備えるシステムであって、
前記サーバは、前記複数の循環バスの運行スケジュールを記憶し、
前記複数の循環バスは、前記運行スケジュールに従って運行し、
前記サーバは、
前記運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定し、
前記所定の条件が満たされると判定した場合、追加の循環バスを前記拠点から前記循環ルートに投入するように前記運行スケジュールを修正し、
前記複数の循環バスは、修正後の前記運行スケジュールに従って運行する。

【発明の効果】

【0009】

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

【図面の簡単な説明】

【0010】

【図1】本開示の一実施形態に係るシステムの概略構成を示すブロック図である。

【図2】本開示の一実施形態に係る輸送サービスの概要を示す図である。

【図3】運行スケジュールの例を示す図である。

【図4】車両の概略構成を示すブロック図である。

【図5】サーバの概略構成を示すブロック図である。

【図6】サーバの動作を示すフローチャートである。

【発明を実施するための形態】

【0011】

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

【0012】

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

【0013】

本実施形態において複数の車両１０は、循環ルートを走行する循環バスとして用いられる。サーバ２０は、複数の車両１０に対して運行スケジュールを通知することによって、複数の車両１０の運行管理を行う。複数の車両１０は、サーバ２０から通知される運行スケジュールに従って運行する。

【0014】

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

【0015】

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

【0016】

図３に示す運行スケジュールが適用される場合、例えば車両１０ａは、時刻＝０において拠点から循環ルートに投入され、時刻＝１２ｔにおいて規定周ｎ（ここでは、ｎ＝４周）を走行し終えると拠点に戻り、待機中の車両１０ｄと交代する。車両１０ｄは、時刻＝１２ｔにおいて拠点から循環ルートに投入され、時刻＝２４ｔにおいて規定周ｎ（ここでは、ｎ＝４周）を走行し終えると拠点に戻り、待機中の車両１０ａと交代する。このようにして、車両１０ａ及び１０ｇは互いに交代しながら運行する。同様に、車両１０ｂ及び車両１０ｅが互いに交代しながら運行し、車両１０ｃ及び車両１０ｆが互いに交代しながら運行する。ここで、車両１０ｂは時刻＝４ｔにおいて循環ルートに投入され、車両１０ｃは時刻＝８ｔにおいて循環ルートに投入される。

【0017】

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

【0018】

なお例外的に、車両１０ｅは、時刻＝ｔにおいて循環ルートに投入され、時刻＝４ｔにおいて車両１０ｂと交代する。また例外的に、車両１０ｆは、時刻＝２ｔにおいて循環ルートに投入され、時刻＝８ｔにおいて車両１０ｃと交代する。

【0019】

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

【0020】

また、複数の車両１０のそれぞれは、運行スケジュールに追従するように自動走行する。具体的には、複数の車両１０のそれぞれには、予め許容された速度上限値が設定されている。循環ルートを走行中の車両１０は、例えば運行スケジュールに対して遅延している場合、遅延を低減し又は解消するために、車速が速度上限値を超えない範囲において加速し得る。

【0021】

ここで、運行スケジュール上で予定されていない所定のイベントが発生した場合に、追加の車両１０を拠点から循環ルートに投入することを考える。当該イベントは、複数の車両１０を用いた輸送サービスの需要（例えば、利用客の数）に対して供給（例えば、循環ルートを走行中の車両１０の台数）が相対的に少なくなる任意のイベントである。具体的には、輸送サービスの供給が減少するイベントとして、例えば循環ルートを走行中の車両１０が故障するイベント、又は循環ルートを走行中の車両１０の運行スケジュールに対する遅延時間が閾値以上になるイベントが挙げられる。一方、輸送サービスの需要が増加するイベントとして、例えば輸送サービスの利用客の人数（例えば、バス停で車両１０の到着を待っている利用客及び循環ルートを走行中の車両１０に乗車している利用客の合計人数）が閾値以上になるイベントが挙げられる。以下、追加の車両１０を拠点から循環ルートに投入することを「追加投入」ともいう。

【0022】

しかしながら、上述したイベントが発生する度に追加投入を実施してしまうと、例えば拠点で通常入替を控えた車両１０までが追加投入のために利用されてしまい、通常入替が実施できなくなる等、運行スケジュールに悪影響が及ぶ可能性がある。

【0023】

これに対して、本実施形態に係るサーバ２０は、複数の車両１０の運行スケジュールを記憶する。サーバ２０は、運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定する。そしてサーバ２０は、所定の条件が満たされると判定した場合、追加の車両１０を拠点から循環ルートに投入するように運行スケジュールを修正する。

【0024】

かかる構成によれば、運行スケジュール上で予定されていない所定のイベントが発生した場合に、追加投入を実施すべきか否かが判断される。したがって、例えば所定のイベントが発生する度に追加投入を実施する構成と比較して運行スケジュールに悪影響が及ぶ可能性が低減し得る点で、複数の車両１０の運行を管理する技術が改善する。

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

ステップＳ１０１：制御部２３は、複数の車両１０の状態の監視を開始する。

【0040】

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

【0041】

ステップＳ１０２：制御部２３は、運行スケジュール上で予定されていない所定のイベントが発生したか否かを判定する。所定のイベントが発生したと判定した場合（ステップＳ１０２－Ｙｅｓ）、プロセスはステップＳ１０３に進む。一方、所定のイベントが発生していないと判定した場合（ステップＳ１０２－Ｎｏ）、プロセスはステップＳ１０２を繰り返す。

【0042】

本実施形態において所定のイベントは、上述したように循環ルートを走行中の車両１０が故障する第１のイベント、循環ルートを走行中の車両１０の運行スケジュールに対する遅延時間が閾値以上になる第２のイベント、又は輸送サービスの利用客の人数（例えば、バス停で車両１０の到着を待っている利用客及び循環ルートを走行中の車両１０に乗車している利用客の合計人数）が閾値以上になる第３のイベントを含んでもよい。

【0043】

所定のイベントが発生したか否かの判定には、任意の手法が採用可能である。例えば、制御部２３は、監視中に複数の車両１０から取得される車両情報に基づいて、循環ルートを走行中の車両１０が故障したことを検出すると、上記第１のイベントが発生したと判定してもよい。

【0044】

また、制御部２３は、監視中に複数の車両１０から取得される車両情報に基づいて、循環ルートを走行中の車両１０の遅延時間を取得してもよい。そして制御部２３は、取得された遅延時間が閾値以上になった場合、上記第２のイベントが発生したと判定してもよい。

【0045】

また、制御部２３は、監視中に複数の車両１０から取得される車両情報に基づいて、循環ルートを走行中の各車両１０の車内にいる利用客の人数を取得してもよい。制御部２３は、例えば各バス停に設けられた端末装置から通信部２１を介して取得する情報に基づいて、各バス停で車両１０の到着を待っている利用客の人数を取得してもよい。具体的には、制御部２３は、端末装置からバス停の待ち合いスペースの撮像画像を受信し、当該画像から画像認識により利用客の人数を取得してもよく、或いは端末装置から利用客の人数を示す情報を受信してもよい。そして制御部２３は、利用客の合計人数が閾値以上になった場合、上記第３のイベントが発生したと判定してもよい。

【0046】

ステップＳ１０３：ステップＳ１０２でイベントが発生したと判定した場合（ステップＳ１０２－Ｙｅｓ）、制御部２３は、所定の条件が満たされるか否かを判定する。所定の条件が満たされると判定した場合（ステップＳ１０３－Ｙｅｓ）、プロセスはステップＳ１０４に進む。一方、所定の条件が満たされないと判定した場合（ステップＳ１０３－Ｎｏ）、プロセスはステップＳ１０２に戻る。

【0047】

ここで、上記所定の条件、及び当該所定の条件が満たされているか否かの判定手法について具体例を挙げて説明する。第１例において、所定の条件は、拠点で待機中の車両１０の台数がｎ台以上であるという第１の条件を含む。本実施形態においてｎ＝２であるが、ｎは２以上の任意の自然数であってもよい。また「待機中の車両１０」は、運行スケジュール上で通常入替（すなわち、車両１０と他の車両１０との交代）が次に発生するタイミングまでに燃料補給又はメンテナンスが完了する予定の車両１０である。制御部２３は、拠点で待機中の車両１０の台数を運行スケジュールから取得する。そして制御部２３は、拠点で待機中の車両１０の台数に基づいて、上記第１の条件が満たされるか否かを判定する。詳細には、制御部２３は、拠点で待機中の車両１０の台数がｎ台未満である場合、第１の条件が満たされないと判定する。

【0048】

第２例において、所定の条件は、上記所定のイベントの発生時刻の所定時間前から当該発生時刻までの判定期間に拠点から循環ルートに投入された追加の車両１０の台数が上限値未満であるという第２の条件を含む。「所定時間」は、例えば車両１０が循環ルートを１周走行するのに要する時間（図３に示す例では、３ｔ）であるが、任意に定められてもよい。また「上限値」は、例えば２台であるが、任意に定められてもよい。制御部２３は、運行スケジュールを参照して、上記判定期間に拠点から循環ルートに投入された追加の車両１０の台数を取得する。制御部２３は、取得された台数が上限値と等しい場合（或いは、台数が上限値以上である場合）、第２の条件が満たされないと判定する。

【0049】

第３例において、所定の条件は、後述するように制御部２３によって生成された運行スケジュールの修正案が所定の要件を満たすという第３の条件を含む。制御部２３は、複数の車両１０の運行履歴に基づいて、第３の条件が満たされるか否かを判定する。具体的には、制御部２３は、記憶部２２に記憶された運行履歴に基づいて、追加の車両１０を拠点から循環ルートに投入するように運行スケジュールを修正する場合の修正案を生成する。運行スケジュールの修正案の生成には、例えば最適化アルゴリズム、シミュレーション、又はＡＩ（Artificial Intelligence）等、任意の手法が採用可能である。そして制御部２３は、生成した修正案が所定の要件を満たすか否かを判定する。「所定の要件」は、例えば修正案に係る運行スケジュール上の任意の時点において、車両１０に対する燃料補給又はメンテナンス等の作業が完了してから当該車両１０が次に拠点から循環ルートに投入されるまでの時間が閾値以上であるという要件を含む。制御部２３は、修正案が所定の要件を満たさない場合、第３の条件が満たされないと判定する。かかる要件によれば、車両１０に対する燃料補給又はメンテナンス等の作業の実施に時間的余裕を設けることができる。しかしながら、「所定の要件」は当該例に限られず、任意に定められてもよい。

【0050】

なお、所定の条件は、上記の第１の条件、第２の条件、及び第３の条件のうち２つ以上の条件を含んでもよい。例えば、所定の条件が第１の条件及び第２の条件を含むとき、制御部２３は、第１の条件及び第２の条件の両方が満たされる場合に所定の条件が満たされると判定し、第１の条件及び第２の条件の少なくとも一方が満たされない場合に所定の条件が満たされないと判定する。

【0051】

ステップＳ１０４：ステップＳ１０３で所定の条件が満たされると判定した場合（ステップＳ１０３－Ｙｅｓ）、制御部２３は、追加の車両１０を拠点から循環ルートに投入するように運行スケジュールを修正し、修正後の運行スケジュールを複数の車両１０に通知する。なお、上述した所定の条件に第３の条件が含まれる場合、制御部２３は、ステップＳ１０３で生成した修正案に従って運行スケジュールを修正する。複数の車両１０は、通知された修正後の運行スケジュールに従って運行する。

【0052】

以上述べたように、本実施形態に係るサーバ２０は、複数の車両１０の運行スケジュールを記憶する。サーバ２０は、運行スケジュール上で予定されていない所定のイベントが発生すると、所定の条件が満たされるか否かを判定する。そしてサーバ２０は、所定の条件が満たされると判定した場合、追加の車両１０を拠点から循環ルートに投入するように運行スケジュールを修正する。

【0053】

かかる構成によれば、運行スケジュール上で予定されていない所定のイベントが発生した場合に、追加投入を実施すべきか否かが判断される。したがって、例えば所定のイベントが発生する度に追加投入を実施する構成と比較して運行スケジュールに悪影響が及ぶ可能性が低減し得る点で、複数の車両１０の運行を管理する技術が改善する。

【0054】

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

【0055】

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

【0056】

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

【符号の説明】

【0057】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】