JP7120131B2 - 情報処理装置 - Google Patents

Description

本発明は、複数の車両が属する車両群を管理する情報処理装置に関する。

特許文献１には、移動店舗として移動体を巡回させるためのスケジューリングおよび配車を行う移動店舗巡回スケジュール作成装置に関する技術が開示されている。

特開２０１５－０６９５９４号公報

本発明は、車両群に属する複数の車両の用途を管理することによって、車両群に属する車両の利用者の需要に応えることが可能となるような技術を提供することを目的とする。

複数の車両が属する車両群を管理する情報処理装置であって、前記車両群に属する各車両は共通する所定の複数用途に使用可能であり、前記情報処理装置は、前記車両群に属する各車両に対して前記所定の複数用途のうちの一つを割当てることと、前記車両群に属している各車両を利用者が利用した際の利用履歴であって、各車両についての、利用期間と利用用途とを含む利用履歴を取得することと、前記利用履歴に基づいて、将来の所定の期間における前記所定の複数用途におけるそれぞれの用途の需要予測をすることと、を実行する制御部を備え、前記制御部は、前記車両群に属する各車両に対して前記所定の複数用途のうちの一つを割当てる際に、前記所定の期間における各車両の用途を、前記需要予測に基づいて決定する。

本発明によれば、車両群に属する複数の車両の用途を管理することによって、車両群に属する車両の利用者の需要に応えることができる。

実施形態に係る車両群管理システムの概略構成を示す図である。 実施形態に係る車両群管理システムを構成する車両、車両群管理サーバ、サービス管理サーバそれぞれの機能構成の一例を概略的に示すブロック図である。 利用履歴データベースに格納されている利用履歴のテーブル構成の一例を示す図である。 実施形態に係る用途割当処理のフローを示すフローチャートである。 実施形態に係る（ａ）利用実績のテーブル構成と（ｂ）需要予測結果のテーブル構成との一例を示す図である。 実施形態に係る用途割当のテーブル構成の一例を示す図である。 車両群管理システムにおける情報および処理のフローを示すシーケンス図である。

本発明に係る情報処理装置は、複数の車両が属する車両群を管理する。ここで、車両群に属する各車両は、共通する所定の複数用途に使用可能な車両である。所定の複数用途と
しては、乗り合いバスとスクールバスと、を例示することができる。この場合の車両群に属する各車両は、乗り合いバスとしても、スクールバスとしても使用可能である。また、所定の複数用途としては、利用者に対して商品を販売する移動型店舗車両と、物品を配送する配送車両と、を例示することもできる。この場合の車両群に属する各車両は、移動型店舗車両としても、配送車両としても使用可能である。なお、所定の複数用途は２種類の用途に限られるものではなく、３種類以上の用途であってもよい。そして、車両群に属する各車両が、所定の複数用途におけるそれぞれの用途で使用可能に構成されていればよい。

情報処理装置において、制御部は、車両群に属する各車両に対して、所定の複数用途のうちの一つを割当てる。換言すれば、車両群に属する各車両の用途は、制御部によって、所定の複数用途のうちの一つが割当てられることにより決定されている。そして、各車両は、制御部によって割当てられた所定の複数用途のうちの一つの用途で使用される。ただし、上記のように、車両群に属する各車両は、いずれも、共通する所定の複数用途で使用可能である。そのため、各車両に対して割当てる用途は、所定の複数用途の範囲内で変更することが可能である。

また、制御部は、車両群に属している各車両を利用者が利用した際の利用履歴を取得する。ここで、利用履歴には利用者が利用した各車両の、利用期間と利用用途とが含まれている。なお、利用用途とは、利用者が車両群に属する、ある車両をある利用期間利用した際における、該利用期間において該車両に割当てられている用途である。つまり、利用用途は所定の複数用途のうちの一つである。

さらに、制御部は、取得した利用履歴に基づいて、将来の所定の期間における所定の複数用途におけるそれぞれの用途の需要予測をする。上述したように、利用履歴には、各車両についての、利用期間毎の用途が含まれている。そのため、利用履歴から、過去のある期間での、所定の複数用途におけるそれぞれの用途の需要実績を把握することができる。そして、所定の複数用途におけるそれぞれの用途の需要実績から、各用途の需要予測をすることができる。また、各用途の需要予測をする際に、例えば、一日を複数の時間帯に分割して、各時間帯における各用途の需要予測をしてもよい。また、各用途の需要予測をする際に、例えば、一週間における曜日毎の各用途の需要予測をしてもよい。

そして、制御部は、車両群に属する各車両に対して所定の複数用途のうちの一つを割当てる際に、所定の期間における各車両の用途を、需要予測に基づいて決定する。ここで、所定の期間は、上述した需要予測によって各用途の需要が予測された期間のことである。

複数の車両を複数の用途に使用する場合に、各用途に使用可能な車両の台数が予め定められていると、複数の車両が使用可能な複数用途のうち、ある一つの用途の需要が増加しても、他の用途に使用されている車両の台数を減らして、需要の増加している用途に使用可能な車両の台数を増加させることができない。つまり、用途毎に予め定められた車両の台数分以上の需要に応えることができない。この場合、車両の利用者の需要の変化に十分に応えることが困難である。

これに対し、本発明では、情報処理装置が、車両群に属する各車両に対して共通する所定の複数用途のうちの一つを割当てることで、車両群に属する各車両の用途を管理している。これにより、車両群に属する各車両が、共通する所定の複数用途に使用可能となる。つまり、一台の車両を所定の複数用途におけるそれぞれの用途として使用することができる。そして、本発明に係る情報処理装置における制御部は、各用途の需要予測に基づいて、車両群に属する各車両に将来の所定の期間における用途を割当てる。つまり、将来の所定の期間において、他の期間に比べて、各車両の用途のうち、一つの用途の需要が比較的
多く且つ他の用途の需要が比較的少ないと予測されたときには、該所定の期間において、他の期間に比べて、需要の比較的多い用途に使用される車両の台数を増加させ、他の車両の用途に使用される車両の台数を減少させる。これにより、車両群に属する複数の車両の用途を、将来における利用者の需要の変化に応じて変更することができる。このように、本発明に係る情報処理装置は、車両群に属する複数の車両の用途を管理することによって、車両群に属する車両の利用者の需要に応えることができる。

以下、本発明の具体的な実施形態について図面に基づいて説明する。本実施形態に記載されている構成部品の寸法、材質、形状、その相対配置等は、特に記載がない限りは発明の技術的範囲をそれらのみに限定する趣旨のものではない。

＜実施形態＞
（システムの概略）
図１は実施形態に係る車両群管理システムの概略構成を示す図である。車両群管理システム１は、自律走行可能な複数の車両１００と、車両群管理サーバ２００と、複数のサービス管理サーバ３００と、を含んで構成される。各車両１００は、複数の用途に使用可能に構成されている。また、複数の車両１００は、車両群Ｇを形成している。そして、車両群Ｇに属する各車両１００には、使用可能な複数の用途が予め定められている。つまり、車両群Ｇに属する各車両１００は共通する所定の複数用途に使用可能である。本実施形態においては、車両群Ｇにおける所定の複数用途を用途Ａ、Ｂとする。換言すれば、車両群Ｇに属する車両１００は用途Ａ、Ｂのどちらの用途としても使用することが可能である。

また、車両群Ｇに属する複数の車両１００の用途は車両群管理サーバ２００によって管理されている。具体的には、車両群管理サーバ２００は、車両群Ｇに属する各車両１００に対して用途Ａ、Ｂのどちらか一方を割当てる。なお、車両群管理システム１においては、各車両１００と、車両群管理サーバ２００と、各サービス管理サーバ３００Ａ、３００Ｂとが、ネットワークＮ１によって相互に接続される。ネットワークＮ１には、例えば、インターネット等の世界規模の公衆通信網であるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）や、携帯電話等の電話通信網が採用されてもよい。

サービス管理サーバ３００は、用途毎に設けられているサーバである。つまり、車両群管理システム１は、用途Ａと用途Ｂとで、２つの異なるサービス管理サーバ３００Ａ、３００Ｂを含んでいる。サービス管理サーバ３００Ａは、ネットワークＮ１を介して、用途Ａで使用される車両１００を管理している。また、サービス管理サーバ３００Ｂは、ネットワークＮ１を介して、用途Ｂで使用される車両１００を管理している。

各サービス管理サーバ３００Ａ、３００Ｂは、車両１００が用途Ａに使用されるために必要な情報である該用途Ａに関する管理情報、または、車両１００が用途Ｂに使用されるために必要な情報である該用途Ｂに関する管理情報を各車両１００に送信することで、それぞれの用途Ａ、Ｂに使用される各車両１００の管理を実現している。さらに、用途Ａ、Ｂに関する管理情報には各車両１００の走行計画が含まれている。例えば、車両群Ｇにおいて、用途Ａが乗り合いバスであり、用途Ｂがスクールバスである場合には、サービス管理サーバ３００Ａは、乗り合いバスの運行経路、運行時刻、運賃情報などを含む、乗り合いバスに関する管理情報を、乗り合いバス（用途Ａ）に使用される各車両１００に送信することで、これらの車両１００を管理している。ここで、「運行経路、運行時刻」が、乗り合いバスに関する管理情報に含まれる「走行計画」に相当する。同様に、サービス管理サーバ３００Ｂは、スクールバスに関する、走行計画を含む管理情報を、スクールバス（用途Ｂ）に使用される各車両１００に送信する。また、車両群Ｇにおいて、用途Ａが移動型店舗であり、用途Ｂが配送車両である場合には、サービス管理サーバ３００Ａは、販売ルート、商品情報などを含む、移動型店舗に関する管理情報を、移動型店舗（用途Ａ）に
使用される各車両１００に送信することで、これらの車両１００を管理している。ここで、「販売ルート」が、移動型店舗に関する管理情報に含まれる「走行計画」に相当する。同様に、サービス管理サーバ３００Ｂは、配送車両に関する、走行計画を含む管理情報を配送車両（用途Ｂ）に使用される各車両１００に送信する。

また、各サービス管理サーバ３００Ａ、３００Ｂは、それぞれの用途Ａ、Ｂに使用されている各車両１００から、利用期間と利用用途とを含む利用履歴を示す情報を周期的に受信し、ＰＲＯＭ、ハードディスクドライブ（ＨＤＤ）、リムーバブルメディア等の補助記憶部にデータを格納している。なお、利用履歴を示す情報の受信は、周期的でなく、利用者が用途Ａまたは用途Ｂに使用されている車両１００の利用を終了した際に、該車両１００からサービス管理サーバ３００Ａまたはサービス管理サーバ３００Ｂに送信されてもよい。

なお、用途Ａに使用される車両１００を管理するサービス管理サーバ３００Ａと、用途Ｂに使用される車両１００を管理するサービス管理サーバ３００Ｂと、が単一のサーバ装置であってもよい。

また、車両群管理サーバ２００は、各サービス管理サーバ３００Ａ、３００Ｂに、それぞれの用途Ａ、Ｂを割当てられた各車両１００についての車両情報を送信する。ここで、車両情報は、車両１００に用途Ａ、Ｂが割当てられる期間を示す情報と、車両１００の識別情報とを含む情報である。そして、各サービス管理サーバ３００Ａ、３００Ｂは、受信した車両情報に基づいて、それぞれの用途Ａ、Ｂが割り当てられた各車両１００の管理を行う。なお、車両群管理サーバ２００とサービス管理サーバ３００Ａ、３００Ｂとが単一のサーバ装置であってもよい。

車両群管理サーバ２００は、一般的なコンピュータを含んで構成される。車両群管理サーバ２００を構成するコンピュータは、ＣＰＵやＤＳＰ等のプロセッサ２１０と、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）等の主記憶部２２０と、ＥＰＲＯＭ、ハードディスクドライブ（ＨＤＤ）、リムーバブルメディア等の補助記憶部２３０と、を備えている。ここで、リムーバブルメディアは、例えば、ＵＳＢメモリやＳＤカード等のフラッシュメモリ、あるいは、ＣＤ－ＲＯＭやＤＶＤディスク、ブルーレイディスクのようなディスク記録媒体である。

車両群管理サーバ２００において、補助記憶部２３０には、オペレーティングシステム（ＯＳ）、各種プログラム、各種情報テーブル等が格納されている。また、車両群管理サーバ２００において、プロセッサ２１０が、補助記憶部２３０に記憶されたプログラムを主記憶部２２０にロードして実行することによって、後述するような各種の機能を実現することができる。ただし、車両群管理サーバ２００における一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。なお、車両群管理サーバ２００は、必ずしも単一の物理的構成によって実現される必要はなく、互いに連携する複数台のコンピュータによって構成されてもよい。

車両群管理サーバ２００は、ネットワークＮ１経由で、過去に利用者が車両群Ｇに属する各車両１００を利用した際の利用履歴を示す情報をサービス管理サーバ３００から受信する。次に、車両群管理サーバ２００は、サービス管理サーバ３００から受信した利用履歴を示す情報に基づいて、将来の所定の期間における用途Ａ、Ｂの需要予測をする。そして、車両群管理サーバ２００は車両群Ｇに属する各車両１００に対して、用途Ａ、Ｂの需要予測に基づいて、該用途Ａ、Ｂのいずれかを割当てる。そして、車両群管理サーバ２００から、ネットワークＮ１経由で、用途Ａ、Ｂそれぞれを管理する各サービス管理サーバ３００Ａ、３００Ｂに、用途Ａまたは用途Ｂを割当てられた各車両１００の車両情報が送
信される。また、車両群管理サーバ２００から、車両群Ｇに属する各車両１００に対して、それぞれの用途Ａ、Ｂが割当てられる期間を示す情報と、割当てた用途を示す情報と、を含んだ用途情報が送信される。

（システム構成）
次に、本実施形態に係る車両群管理システム１を構成する、車両群Ｇに属する車両１００、車両群管理サーバ２００、サービス管理サーバ３００（３００Ａ、３００Ｂ）それぞれの機能構成について図２に基づいて説明する。図２は、実施形態に係る車両群管理システムを構成する車両、車両群管理サーバ、サービス管理サーバそれぞれの機能構成の一例を概略的に示すブロック図である。

（車両）
車両１００は、サービス管理サーバ３００から送信される用途に関する管理情報に基づいて、自律走行を行う自律走行車両である。車両１００は、通信部１０１、記憶部１０２、センサ１０３、位置情報取得部１０４、駆動部１０５、および制御部１０６を含んで構成される。なお、車両１００は、モータを原動機とする電気自動車である。ただし、車両１００の原動機は、電動モータに限定されるものではなく、内燃機関であってもよい。また、車両１００は、原動機としてモータおよび内燃機関の両方を有するハイブリッド車両であってもよい。

通信部１０１は、車両１００をネットワークＮ１に接続するための通信装置である。通信部１０１は、例えば３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ）やＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）等の移動体通信サービスを利用して、ネットワークＮ１経由で、車両群管理サーバ２００やサービス管理サーバ３００を含む他の装置と通信を行うことができる。通信部１０１は、車両１００を利用者が利用した際の利用履歴を示す情報をサービス管理サーバ３００に送信する。その際に、通信部１０１は、車両１００の用途に応じてサービス管理サーバ３００に利用履歴を示す情報を送信する。また、制御部１０６は、通信部１０１を介して、車両群管理サーバ２００から、車両群管理サーバ２００が車両１００に対して割当てた用途を示す情報を含んだ用途情報を受信する処理を行う。また、制御部１０６は、通信部１０１を介して、サービス管理サーバ３００から、用途に関する管理情報を受信する処理を行う。なお、通信部１０１は、他の車両と車々間通信を行うための通信装置をさらに有していてもよい。

記憶部１０２は、情報を記憶する装置であり、磁気ディスクやフラッシュメモリ等の記憶媒体により構成される。記憶部１０２には、例えば地図情報が記憶されている。また、記憶部１０２には、サービス管理サーバ３００から受信した用途に関する管理情報が記憶される。さらに、記憶部１０２には、サービス管理サーバ３００との連携のためのプログラムも記憶されている。

センサ１０３は、車両１００の周囲の状況をセンシングするための装置である。具体的には、センサ１０３は、ステレオカメラ、レーザスキャナ、ＬＩＤＡＲ、レーダ等を含んで構成される。センサ１０３が取得した、車両１００の周囲の状況に関する情報は、制御部１０６に送信される。位置情報取得部１０４は、車両１００の現在位置を取得する装置であり、具体的にはＧＰＳ受信器などを含んで構成される。位置情報取得部１０４が取得した車両１００の現在位置に関する情報は、制御部１０６に送信される。

制御部１０６は、車両１００の制御するための演算処理を行う機能を有する。制御部１０６は、例えば、マイクロコンピュータによって構成される。制御部１０６は、機能モジュールとして、環境検出部１０６１、走行制御部１０６２および用途制御部１０６３を有している。各機能モジュールは、制御部１０６が有するＲＯＭ等の記憶部に記憶されたプ
ログラムを、ＣＰＵ等のプロセッサによって実行することで実現してもよい。また、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

環境検出部１０６１は、センサ１０３が取得した情報に基づいて、車両１００の周囲の環境を検出する。例えば、環境検出部１０６１は、自車両の周囲に存在する他車両等の物体（人や動物を含む）を検出する。また、環境検出部１０６１は、道路における車線の数や位置、道路の構造、道路標識等の、車両１００の自律走行に必要となる種々の対象を検出する。また、環境検出部１０６１は、検出した物体をトラッキングしてもよい。この場合、例えば、１ステップ前に検出した物体の座標と、現在の該物体の座標との差分から、該物体の相対速度を求めてもよい。

また、走行制御部１０６２は、記憶部１０２に記憶された用途に関する管理情報、位置情報取得部１０４が取得した車両１００の位置情報、および、環境検出部１０６１が検出した周囲環境のデータに基づいて、車両１００の走行を制御する。例えば、走行制御部１０６２は、用途に関する管理情報に沿って車両１００を走行させる。また、環境検出部１０６１によって、車両１００が衝突する可能性がある物体が検出された場合、走行制御部１０６２が、該物体との衝突を回避するよう車両１００を走行させる衝突回避制御を実行する。なお、上記のように車両１００を自律走行させる方法については、公知の方法を採用することができる。

用途制御部１０６３は、通信部１０１を介して、車両群管理サーバ２００から、車両群管理サーバ２００が車両１００に対して割当てた車両１００の用途を示す情報を含んだ用途情報を受信する。用途制御部１０６３は、車両１００の用途が変更される場合に、該用途の変更に伴って該車両１００において変更すべきシステムや形態の変更を制御する用途制御を実行する。例えば、車両群管理サーバ２００が、用途Ａが割当てられている車両１００に対して、用途Ｂを新たに割当てたとする。このとき、用途制御部１０６３は、サービス管理サーバ３００Ａとの連携を行うプログラムを、サービス管理サーバ３００Ｂとの連携を行うプログラムに切り替えるなどの制御を実行する。さらに、車両１００の用途に応じて、車両１００の内外装の変更などの制御を実行してもよい。

上述のように、車両群管理サーバ２００が割当てた車両１００の用途Ａ、Ｂそれぞれに応じて、用途制御部１０６３がシステムや形態を制御することにより、用途Ａ、Ｂそれぞれに車両１００を使用可能とすることができる。

駆動部１０５は、原動機であるモータ、および、車両１００を走行させるための機構（例えば、インバータ、ブレーキ、およびステアリング機構）を含んで構成される。駆動部１０５は、走行制御部１０６２が車両１００の走行を制御するために生成した指令に基づいて車両１００を走行させる。これによって、車両１００の自律走行が実現される。

なお、車両１００は、必ずしも常時自律走行を行う車両でなくてもよい。例えば、車両１００は、自動運転モードと手動運転モードとを切り替え可能な車両であってもよい。

（車両群管理サーバ）
車両群管理サーバ２００は、通信部２０１、制御部２０２、および利用履歴データベース（利用履歴ＤＢ）２０３を含んで構成される。通信部２０１は、車両群管理サーバ２００をネットワークＮ１に接続するための通信装置である。通信部２０１は、例えばＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）インターフェースボードや、無線通信のための無線通信回路を含んで構成される。制御部２０２は、通信部２０１を介して、サービス管理サーバ３００Ａ、３００Ｂから利用期間と利用用途を含む利用履歴を示す情報を受信
する。そして、取得した利用履歴を示す情報を利用履歴ＤＢ２０３に格納する処理を行う。利用履歴ＤＢ２０３は、車両群管理サーバ２００のプロセッサ２１０によってデータベース管理システム（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）のプログラムが実行されることで、車両群管理サーバ２００の補助記憶部２３０に構築される。

図３は利用履歴ＤＢ２０３に格納されている利用履歴のテーブル構成の一例を示す図である。図３に示すように、利用履歴のテーブルは、車両ＩＤフィールド、利用開始時刻フィールド、利用終了時刻フィールド、および利用用途フィールドを有する。車両ＩＤフィールドには、車両群Ｇに属する各車両１００の識別情報である車両ＩＤが入力される。利用開始時刻フィールドには、利用者が車両群Ｇに属する各車両１００の利用を開始した際の時刻が入力される。また、利用終了時刻フィールドには、利用者が車両群Ｇに属する各車両１００を利用した際の利用終了の時刻が入力される。利用用途フィールドには、利用者が車両群Ｇに属する各車両１００を利用した際の、車両１００の利用用途が入力される。なお、ここで入力される利用用途は、用途Ａ、Ｂのどちらか一方である。

車両群管理サーバ２００は、車両群Ｇに属する複数の車両１００の利用履歴をサービス管理サーバ３００Ａ、３００Ｂから繰り返し取得する。これにより、車両群管理サーバ２００は利用履歴ＤＢ２０３に格納される利用履歴の数を増やすことができる。つまり、後述の用途Ａ、Ｂの需要予測に使用することができる利用履歴の数を増やすことができる。従って、需要予測部２０２２は、より精度の高い用途Ａ、Ｂの需要予測をすることができる。

制御部２０２は、車両群管理サーバ２００を制御するための演算処理を行う機能を有する。制御部２０２は、プロセッサ２１０によって実現することができる。制御部２０２は、機能モジュールとして、利用履歴取得部２０２１、需要予測部２０２２および用途割当部２０２３を有している。利用履歴取得部２０２１、需要予測部２０２２および用途割当部２０２３は、車両群Ｇに属する各車両１００に対して用途Ａ、Ｂのどちらか一方を割当てるための処理を実行する。

＜用途割当処理のフロー＞
以下、車両群管理サーバ２００の制御部２０２によって実行される、車両群Ｇに属する各車両１００に対して車両群Ｇの用途Ａ、Ｂのどちらか一方を割当てるための用途割当処理について、図４に基づいて説明する。図４は、実施形態に係る用途割当処理のフローを示すフローチャートである。本フローでは、まずＳ１０１において、利用履歴取得部２０２１が利用履歴ＤＢ２０３に格納されている車両群Ｇに属する各車両１００についての利用履歴を取得する。

次に、Ｓ１０２において、需要予測部２０２２は、利用履歴取得部２０２１によって取得された利用履歴に基づいて、将来の所定の期間における、用途Ａ、Ｂの需要予測をする。図５は実施形態に係る（ａ）利用実績のテーブル構成と（ｂ）需要予測結果のテーブル構成との一例を示す図である。なお、本実施形態においては、１日を５つの時間帯に分割し、用途Ａ、Ｂの需要予測をする５つの時間帯が、本発明に係る「所定の期間」に相当する。

まず、利用履歴取得部２０２１が取得した利用履歴に基づいて、需要予測部２０２２は用途Ａ、Ｂの利用実績（図５（ａ））を生成する。なお、用途Ａ、Ｂの利用実績は、将来の所定の期間に対応する複数の利用履歴を使用して生成される。本実施形態においては、需要予測部２０２２は、複数日における利用履歴を使用して用途Ａ、Ｂの利用実績を生成している。

利用実績テーブルには、時間帯フィールド、各用途Ａ、Ｂの利用実績フィールド、および、各用途Ａ、Ｂの配車数フィールドが含まれている。時間帯フィールドには、用途Ａ、Ｂの需要予測をする５つの時間帯が入力されている。各用途Ａ、Ｂの利用実績フィールドには、各時間帯において、利用者によって用途Ａ、Ｂそれぞれに使用された車両１００の台数の、複数日における平均値が入力されている。

また、車両群管理サーバ２００が車両群Ｇに属する各車両１００に対して用途Ａ、Ｂのどちらか一方を割当てることで、用途Ａが割当てられている車両１００の台数（用途Ａの配車数）と、用途Ｂが割当てられている車両の台数（用途Ｂの配車数）と、が定められる。そして、本実施形態では、車両群管理サーバ２００が、各時間帯における、各車両１００に用途Ａ、Ｂのどちらか一方を割当てる。これにより、用途Ａ、Ｂ毎の車両１００の台数である配車数が時間帯毎に決定されることになる。また、図５（ａ）では、車両群Ｇに属する車両１００が２０台であるときの時間帯毎の各用途Ａ、Ｂの配車数の実績が例示されている。利用実績テーブルにおける各用途Ａ、Ｂの配車数フィールドには、時間帯フィールドに入力されている時間帯における、各用途Ａ、Ｂの配車数の、複数日における平均値が入力されている。

なお、利用実績のテーブルの構成は必ずしも上述の形式でなくてもよい。例えば、利用実績フィールドに各用途の利用率などの統計値が入力されていてもよい。利用実績テーブルには、Ｓ１０２において、用途Ａ、Ｂの需要予測をするために必要な情報が含まれていればよい。

利用実績の生成のために使用する利用履歴として、用途Ａ、Ｂの需要予測をする将来の所定の期間に対応する期間の利用履歴を使用することもできる。例えば、平日における用途Ａ、Ｂの需要予測をする場合には、平日の利用履歴を使用し、休日における用途Ａ、Ｂの需要予測をする場合には、休日の利用履歴を使用することもできる。他にも、ある季節や行楽シーズンにおける用途Ａ、Ｂの需要予測をする場合には、対応する季節や行楽シーズンの利用履歴を使用することもできる。このように、用途Ａ、Ｂの需要予測をする将来の所定の期間に対応する期間の利用履歴を使用すれば、より精度の高い用途Ａ、Ｂの需要予測をすることができる。

需要予測部２０２２は、利用履歴から生成された利用実績に基づいて、将来の所定の期間における用途Ａ、Ｂの需要予測をする。利用実績が上述の構成となっていることによって、過去のある期間での各用途Ａ、Ｂの需要実績を把握することができる。従って、過去における各用途Ａ、Ｂの需要実績から、将来における用途Ａ、Ｂの需要予測をすることができる。なお、用途Ａ、Ｂの需要予測の方法については、公知の方法を採用することができる。

需要予測結果テーブル（図５（ｂ））には、時間帯フィールドと各用途Ａ、Ｂの需要フィールドが含まれている。ここで、時間帯フィールドには、需要予測部２０２２が用途Ａ、Ｂの需要予測をした５つの時間帯が入力されている。本実施形態における５つの時間帯が、本発明における「将来の所定の期間」に相当する。また、各用途Ａ、Ｂの需要フィールドには、各時間帯における各用途Ａ、Ｂの需要台数が入力されている。ここで、需要台数とは、車両群Ｇに属する複数の車両１００の利用者が求める各用途Ａ、Ｂの需要に、配車可能な台数の範囲で、最適に応じることのできる、各用途Ａ、Ｂに使用される車両１００の台数である。なお、ここでは、図５（ｂ）に示すように、需要予測部２０２２は、車両群Ｇに属する複数の車両１００の台数である２０台を超えないように各時間帯における用途Ａ、Ｂの需要台数の予測を実行する。

ここで、利用実績を用いて、需要予測をする方法の具体例について、図５を用いて説明
する。図５（ａ）の利用実績では、７：００－１０：００における用途Ａの利用実績と配車数とはそれぞれ１０台、１０台である。また、７：００－１０：００における用途Ｂの利用実績と配車数はそれぞれ５台、１０台である。この場合、用途Ａの需要台数は１０台以上で、用途Ｂの需要台数は５台程度であると予測できる。そこで、需要予測部２０２２は、図５（ｂ）のように、７：００－１０：００における用途Ａの需要台数を１５台、用途Ｂの需要台数を５台として、需要予測をする。

また、図５（ａ）の１４：００－２０：００における用途Ａの利用実績と配車数とはそれぞれ１０台、１０台である。また、１４：００－２０：００における用途Ｂの利用実績と配車数とはそれぞれ１０台、１０台である。この場合、用途Ａ、Ｂの需要台数は共に１０台以上であると予測される。しかし、車両群Ｇに属する車両１００は２０台であるため、需要予測部２０２２は、図５（ｂ）のように、１４：００－２０：００における用途Ａの需要台数を１０台、用途Ｂの需要台数を１０台として、需要予測をする。

また、図５（ａ）の２３：００－７：００における用途Ａの利用実績と配車数とはそれぞれ０台、５台である。また、図５（ａ）の２３：００－７：００における用途Ｂの利用実績と配車数とはそれぞれ１０台、１５台である。この場合、用途Ａの需要台数は０台程度、用途Ｂの需要台数は１０台程度であると予測することができる。そこで、需要予測部２０２２は、図５（ｂ）のように、２３：００－７：００における用途Ａの需要台数を０台、用途Ｂの需要台数を１０台として、需要予測をする。このように、需要予測部２０２２は、用途Ａ、Ｂの需要台数の合計が車両群Ｇに属する車両１００の台数である２０台より少ない場合には、用途Ａ、Ｂの需要台数の合計を２０台より少ない台数として需要予測をすることもできる。

Ｓ１０３においては、用途割当部２０２３は、Ｓ１０２で生成された用途Ａ、Ｂの需要予測に基づいて、車両群Ｇに属する各車両１００に対して、用途Ａ、Ｂのどちらか一方を割当てるために、用途割当テーブルを生成する。用途Ａ、Ｂに関する用途割当テーブルについて、図６に基づいて説明する。図６は、実施形態に係る用途割当のテーブル構成の一例を示す図である。用途割当テーブルには、時間帯フィールドと車両ＩＤフィールド、用途フィールドが含まれている。時間帯フィールドには、将来における時間帯が入力されている。車両ＩＤフィールドには、車両群Ｇに属する各車両１００を特定するための識別情報である車両ＩＤが入力される。用途フィールドには、時間帯フィールドに入力されている時間帯における、各車両１００の用途Ａ、Ｂのどちらか一方が入力されている。用途フィールドに入力される用途は、用途割当部２０２３によって決定される。用途割当部２０２３は、需要予測結果テーブル（図５（ｂ））に入力されている需要台数と一致するように車両群Ｇに属する各車両１００に対して用途Ａ、Ｂのうちのどちらか一方を割当てる。その際に、用途割当部２０２３は、用途を割当てる際に、既に割当てられている用途を考慮して、用途が変更される車両１００の台数を最低にするように用途Ａ、Ｂを割当てることもできる。また、車両１００の使用状況や、車両１００の位置などを考慮して、用途Ａ、Ｂを割当てることもできる。さらに、用途Ａ、Ｂの需要台数の合計が２０台未満である場合には、車両１００に対してメンテナンスやサービス休止などを割当てることもできる。

以上のフローにより、用途割当部２０２３は、用途Ａ、Ｂの需要予測に基づいて、車両群Ｇに属する各車両１００に対して用途Ａ、Ｂのどちらか一方を割当てる。このことにより、車両群Ｇに属する各車両１００の用途Ａ、Ｂを、将来の需要に応じた用途に変更することができるようになる。つまり、用途Ａに使用される車両１００の台数と、用途Ｂに使用される車両１００の台数とを、各用途Ａ、Ｂの需要に応じて変更することができる。

（情報・処理のフロー）
ここで、車両群管理システム１における、車両１００と車両群管理サーバ２００とサービス管理サーバ３００との間の情報、および、各処理のフローについて図７に基づいて説明する。図７は、車両群管理システム１における情報および処理のフローを示すシーケンス図である。

車両群管理システム１においては、サービス管理サーバ３００が用途を割当てられている車両１００に、走行計画を含む、用途に関する管理情報を送信する（Ｓ１０）。また、車両１００からサービス管理サーバ３００に利用履歴を示す情報が送信される（Ｓ１１）。サービス管理サーバ３００は、Ｓ１１において受信した利用履歴を示す情報を格納している。車両群管理サーバ２００はサービス管理サーバ３００から、サービス管理サーバ３００が格納している利用履歴を示す情報を受信する（Ｓ１２）。車両群管理サーバ２００においては、サービス管理サーバ３００から受信した利用履歴を示す情報に含まれる各車両１００についての利用履歴を示す情報が、利用履歴ＤＢ２０３に格納される（Ｓ１３）。次に、車両群管理サーバ２００は、上述した用途割当処理を実行する（Ｓ１４）。Ｓ１４の処理は、需要予測をする時間帯に対応する時間帯における利用履歴を示す情報が利用履歴ＤＢに十分に格納されてから開始されてもよい。また、車両群管理サーバ２００の管理者によってＳ１４の処理が開始されてもよい。

そして、車両群管理サーバ２００は、用途割当部２０２３が生成した用途割当テーブル（図６参照）の車両ＩＤに対応する車両１００に対して、用途情報を送信する（Ｓ１５）。用途情報とは、用途割当テーブルに入力されている時間帯と、該時間帯における用途と、を示す情報を含んだ情報である。ここで、用途割当テーブルに複数の時間帯が含まれている場合には、複数の時間帯と、該複数の時間帯における車両１００の用途と、を示す情報をＳ１５の処理において送信してもよい。

さらに、車両群管理サーバ２００は、用途割当部２０２３が生成した用途割当テーブル（図６参照）の用途フィールドに入力されている用途を管理するサービス管理サーバ３００に対して、該用途が割当てられている車両１００の車両情報を送信する（Ｓ１６）。ここで、車両情報とは、用途割当テーブルに入力されている時間帯と、該時間帯における車両ＩＤと、を示す情報を含んだ情報である。ここで、用途割当テーブルに複数の時間帯が含まれている場合には、複数の時間帯と、該複数の時間帯における車両ＩＤと、を示す情報をＳ１６の処理において送信してもよい。

車両群管理サーバ２００から用途情報を受信した車両１００においては、用途の変更の必要がある場合に、用途制御が実行される（Ｓ１７）。車両１００の用途制御は該車両１００における用途制御部１０６３によって実行される。

本実施形態では、車両群管理サーバ２００が、車両群Ｇに属する各車両１００に対して用途Ａ、Ｂのどちらか一方を割当てることで、車両群Ｇに属する各車両１００の用途を管理している。これにより、車両群Ｇに属する各車両１００が、用途Ａ、Ｂに使用可能となる。そして、本実施形態に係る車両群管理サーバ２００における制御部２０２は、用途Ａ、Ｂの需要予測に基づいて、車両群Ｇに属する各車両１００に対して将来の各時間帯の用途を割当てる。つまり、将来の時間帯において、他の時間帯に比べて、各車両１００の用途のうち、例えば、用途Ａの需要が比較的多く且つ用途Ｂの需要が比較的少ないと予測されたときには、該時間帯において、他の時間帯に比べて、需要の比較的多い用途Ａに使用される車両１００の台数を増加させ、用途Ｂに使用される車両１００の台数を減少させる。これにより、車両群Ｇに属する複数の車両１００の用途を、将来における、利用者の需要の変化に応じて変更することができるようになる。このように、本実施形態に係る車両群管理サーバ２００は、車両群Ｇに属する複数の車両１００の用途を管理することによって、車両群Ｇに属する車両１００の利用者の需要に応えることができる。

なお、本実施形態では、車両群管理サーバ２００は車両群Ｇに属する各車両１００の用途を管理したが、車両群管理サーバ２００は複数の車両群に属する各車両の用途を管理してもよい。例えば、車両群管理システム１に、第１車両群Ｇ１と第２車両群Ｇ２とが含まれているとする。第１車両群Ｇ１に属する複数の車両の共通する所定の複数用途を用途Ａ、Ｂとする。また、第２車両群Ｇ２に属する複数の車両の共通する所定の複数用途を用途Ｃ、Ｄとする。このとき、車両群管理システム１には用途Ａ、Ｂ、Ｃ、Ｄそれぞれを管理するサービス管理サーバ３００Ａ、３００Ｂ、３００Ｃ、３００Ｄが含まれている。そして、車両群管理サーバ２００は第１車両群Ｇ１に属する各車両１００に対して用途Ａ、Ｂのどちらか一方を割当てることができる。また、これと独立して、第２車両群Ｇ２に属する各車両１００に対して用途Ｃ、Ｄのどちらか一方を割当てることができる。このように、車両群管理サーバ２００は、複数の車両群に属する各車両の用途を管理することもできる。

＜その他の実施形態＞
上記の実施形態はあくまでも一例であって、本発明はその要旨を逸脱しない範囲内で適宜変更して実施し得る。また、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

本発明は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク、ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

１００・・・車両
１０６３・・用途制御部
２００・・・車両群管理サーバ
２０２・・・制御部
２０２１・・利用履歴取得部
２０２２・・需要予測部
２０２３・・用途割当部
３００・・・サービス管理サーバ

Claims (1)

1. 複数の車両が属する車両群を管理する情報処理装置であって、
   前記車両群に属する各車両は共通する所定の複数用途に使用可能であり、
   前記情報処理装置は、
   前記車両群に属する各車両に対して前記所定の複数用途のうちの一つを割当てることと、
   前記車両群に属している各車両を利用者が利用した際の利用履歴であって、各車両についての、利用期間と利用用途とを含む利用履歴を取得することと、
   前記利用履歴に基づいて、将来の所定の期間における前記所定の複数用途におけるそれぞれの用途の需要予測をすることと、を実行する制御部を備え、
   前記制御部は、前記車両群に属する各車両に対して前記所定の複数用途のうちの一つを割当てる際に、前記所定の期間における各車両の用途を、前記需要予測に基づいて決定する、情報処理装置。

Images