JP2020009060A - 車両管理システム及び車両管理方法 - Google Patents

Abstract

【課題】複数のメンテナンスを同時に実施できるように配車する車両管理システム及び車両管理方法を提供する。【解決手段】車両の利用要求情報に基づいて、複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定し、前記推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断し、前記メンテナンス必要度が閾値以上になると判断された場合に、配車可能な車両のメンテナンス項目のメンテナンス必要度を推定して当該メンテナンス必要度が閾値以上になるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両を、ユーザからの利用要求に応じる車両として決定する。【選択図】図２

Description

本発明は、車両管理システム及び車両管理方法に関するものである。

バッテリによる電力供給をシステマチックに実現するために、自律的に移動可能なバッテリの電池残量が、予め定められた閾値よりも低くなると、充電ステーションへの移動を指示することで、充電というメンテナンスを実施するバッテリの制御システムが知られている。（特許文献１）。

特開２０１７−１９５７２２号公報

しかしながら、上記従来のバッテリの制御システムでは、メンテナンスの指標が電池残量であってメンテナンスの内容が充電だけであるため、充電以外のメンテナンス、たとえば、車両の定期的な清掃、タイヤ、バッテリ、各種オイルなどの部品交換、車載コンピュータのソフトウェアのバージョンアップなどの更新、車外又は車内への広告の貼り付け作業を含む場合には対応できない。しかも、メンテナンスごとに指標を設定したとしても、各指標が予め定められた閾値を超えると、それぞれのメンテナンスに対して独立してメンテナンスが指示されるため、輸送サービスなどの提供機会が損失し、効率的なメンテナンス指示ができないという問題点がある。

本発明が解決しようとする課題は、複数のメンテナンスを同時に実施できるように配車する車両管理システム及び車両管理方法を提供することである。

本発明は、利用要求情報に基づいて、複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定し、前記推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断し、前記メンテナンス必要度が閾値以上になると判断された場合に、配車可能な車両のメンテナンス項目のメンテナンス必要度を推定して当該メンテナンス必要度が閾値以上になるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両を、ユーザからの利用要求に応じる車両として決定することによって上記課題を解決する。

本発明によれば、車両に対して複数のメンテナンスがある場合に、ユーザからの利用要求に対して、複数のメンテナンスを同時に実施できるように配車することができる。

本発明の車両管理システムの一実施の形態を示すブロック図である。 図１のサーバにて実行される車両の配車管理処理の一例を示すフローチャートである。 図２のステップＳ１のシーンを示す図である。 図２のステップＳ２のシーンを示す図である。 図２のステップＳ３のシーンを示す図である。 図２のステップＳ４のシーンを示す図である。 図２のステップＳ５のシーンを示す図である。 図２のステップＳ６のシーンを示す図である。 図２のステップＳ６の他のシーンを示す図である。

以下、本発明の実施形態を図面に基づいて説明する。図１は、本発明の車両管理システムＳの一実施の形態を示すブロック図である。本実施形態の車両管理システムＳは、本発明に係る車両管理方法を使用したシステムでもある。本実施形態の車両管理システムＳは、複数の車両２を一又は複数のユーザ（利用者）で利用する場合に適用して好ましいシステムであり、予約した車両をユーザが取りに行って自ら運転して利用するといったカーシェアリングのような形態のサービス、ドライバーが運転する車両を用いて一又は複数のユーザを目的地まで輸送する形態のサービス、又は、ドライバーが乗車しない無人運転車両を用いて一又は複数のユーザを目的地まで輸送する形態のサービスなどに適用することができる。

また、このような営業用車両のほか、個人が所有する車両（いわゆる自家用車）や会社が所有する車両（いわゆる社用車）に対して、定期的な清掃、走行エネルギの補給（燃料補給又は充電）、部品交換（タイヤ、バッテリ、各種オイルなどの交換）、車載コンピュータのソフトウェアの更新（バージョンアップなど）、車外又は車内への広告の貼り付け作業を提供するサービスにも適用することができる。要するに、各種の車両に対して、これら複数のメンテナンスのタイミングを知らせたり、実際に複数のメンテナンスを実施したりする機能を備えた車両の管理システムである。なお、以下に説明する実施形態は、本発明をドライバーが乗車しない無人運転車両を用いて一又は複数のユーザを目的地まで輸送する形態のサービスに適用した一例を示す。本実施形態の車両管理システムＳは、サーバ１と、車両２と、ユーザ端末装置３とを含む。以下、各構成を説明する。

《サーバ１》
サーバ１は、１台もしくは複数台のコンピュータ（ＣＰＵ，ＲＯＭ，ＲＡＭなどを備えたハードウェアに、後述する機能を実現するソフトウェアをインストールしたもの）で構成され、外部からの信号入力を受け付けた上で、様々な処理を行う、プログラム可能なサーバである。サーバ１の構成方法の詳細は、特に限定されるものではなく、一般的なサーバを用いればよい。サーバ１には、利用要求取得部１１、データベース１２、配車ルート決定部１３、増加メンテナンス推定部１４、判断部１５、メンテナンス必要度推定部１６、配車車両決定部１７、移動指示部１８及び通信部１９が含まれる。これらの各部のうち、データベース１２は記憶装置により構成され、通信部１９は通信デバイスにより構成され、その他の利用要求取得部１１、データベース１２、配車ルート決定部１３、増加メンテナンス推定部１４、判断部１５、メンテナンス必要度推定部１６、配車車両決定部１７及び移動指示部１８の各機能は、サーバ１にインストールされたソフトウェアにより実現される。

利用要求取得部１１は、ユーザ端末装置３から送信される、ユーザからの車両２の利用要求情報を受信し、データベース１２に当該利用要求情報を出力する。この利用要求情報には、ユーザのＩＤ、ユーザの配車希望意思、ユーザの現在位置、ユーザが希望する乗車地点及び降車地点（緯度・経度などの位置情報）、ユーザが希望する配車時間、乗車人数のほか、ユーザの年齢・職業・家族構成・嗜好性などユーザ個人の属性情報、ユーザの当該配車サービスの利用履歴、配車時の天候その他の環境情報、配車ルートの環境情報などを含んでもよい。なお、利用要求取得部１１は、ユーザ端末装置３から送信される利用要求情報を取得する以外にも、当該ユーザの利用要求情報のうちの一部が、データベース１２に予め格納されている場合には、当該ユーザのＩＤに基づいてデータベース１２から利用要求情報のうちの一部を取得してもよい。

データベース１２は、利用要求取得部１１から出力される、ユーザのＩＤに関連付けられたユーザの年齢・職業・家族構成・嗜好性などユーザ個人の属性情報を含むユーザ属性データと、ユーザの当該配車サービスの利用履歴を含むユーザ履歴データと、ユーザの乗降地情報を含む乗降地データと、配車時の天候および配車ルートの環境情報を含む配車時の環境データと、配車時間を含む配車時間データとを一時的又は恒久的に格納する。

データベース１２には、これら利用要求取得部１１から出力される利用要求に関する情報以外にも、車両２から送信される車両情報と、地図データが格納されている。たとえば、予め既知である車種、車両の登録日その他の静的な情報に加え、車両２の車両状態検出部２２から所定時間間隔で送信される動的な車両情報が格納される。本例の配車サービスでは、車両２が複数台存在するので、所定のサービス区域内に存在する全ての車両情報がここに格納される。車両情報は、車両２の位置情報と車両向き、車速、ドアロック及びドアの開閉状態、シートベルトセンサー値、自動運転中か否かなどの各種車両状態、車両２の使用期間、車両２の使用回数、車両２の乗車距離、車両２の走行エネルギ残量（エンジン車の場合は燃料残量、電気自動車の場合は電池残量、ハイブリッド車の場合は燃料残量及び／又は電池残量）、車両２の各種部品の寿命、車両２に搭載されたコンピュータ（ＥＣＵなそ）のソフトウェア更新情報、メンテナンス毎の車両２の乗車人数の累計、車両２の走行地域、車両２の使用時の天候を含む。また、車両リクエスト受信可能か否か、清掃中その他メンテナンス中か否か、乗客の有無及び人数、輸送指示の目的地に到着したか否かなど、無人自動運転の遠隔監視に関する情報も、同じ車両のＩＤに関連付けて格納される。

データベース１２に格納された地図データは、少なくとも車両２が走行可能な道路リンク情報を含んだいわゆるナビゲーション地図に加え、ユーザの乗降可能場所、給油及び／又は充電場所、車両２の待機場所の情報を含む。その他に、ユーザが歩行するルートを計算するための歩行者道路リンク情報を含んでもよい。地図データベースは、後述する配車ルート決定部１３による配車ルートの決定などに利用される。

配車ルート決定部１３は、データベース１２に格納された利用要求情報、特に乗車地点と降車地点に関する情報を用いて、現在位置と乗車地点と降車地点までの配車ルートを決定し、決定された配車ルートに関する情報を増加メンテナンス推定部１４に出力する。たとえば、本例の無人運転車両による配車サービスにおいて、無人運転車両の停車場所が予め定められている場合の配車ルートの決定方法は、利用要求情報に含まれた乗車地点及び降車地点の位置情報と、地図データに含まれる無人運転車両の乗降場所の位置情報とを用いて、最も近い乗降場所を、それぞれ乗車場所、降車場所として決定する。なお、車両２の配車ルートの決定方法は、特に限定されず、これ以外の他の手法を用いてもよい。

増加メンテナンス推定部１４は、配車ルート決定部１３で決定した配車ルートを入力し、利用要求情報を用いて、配車後に増加するメンテナンス項目のメンテナンス必要度の増加値を推定したのち、その結果を判断部１５に出力する。本例の配車サービスでは、車両２のメンテナンス項目として、車両２の車外又は車内の定期的な清掃メンテナンス、走行エネルギの補給（燃料補給又は充電）メンテナンス、部品交換（タイヤ、バッテリ、各種オイルなどの交換）その他の整備メンテナンス、車載コンピュータのソフトウェアの更新（バージョンアップなど）メンテナンス、車外又は車内への広告の貼り付け作業メンテナンスが含まれる。以下、これらのメンテナンスを、それぞれ清掃メンテナンス、給油メンテナンス、整備メンテナンス、ソフト更新メンテナンス、広告貼り付けメンテナンスともいう。

本実施形態の増加メンテナンス推定部１４は、たとえばユーザからの利用要求に応じて決定された配車ルートを走行したと仮定した場合に、各車両２の現在のメンテナンス必要度に拘らず、清掃メンテナンス、給油メンテナンス、整備メンテナンス、ソフト更新メンテナンス、広告貼り付けメンテナンスのそれぞれのメンテナンス必要度がどのくらい増加するか（メンテナンス必要度の増加絶対値）を事前に推定する処理部である。なお、本発明の車両管理システムＳは、ユーザからの利用要求に応じて決定された配車ルートを走行したと仮定した場合以外、たとえば乗降地点以外のユーザの利用履歴やユーザの属性に基づいて、清掃メンテナンス、給油メンテナンス、整備メンテナンス、ソフト更新メンテナンス、広告貼り付けメンテナンスのそれぞれのメンテナンス必要度がどれくらい増加するかを事前に推定することも含まれる。

ここで、清掃メンテナンスのメンテナンス必要度は、ユーザが車両２に乗車した時間、ユーザが車両２に乗車した距離、ユーザが車両２に乗車した回数などを代用特性として定量化することができる。たとえば、単位時間当たりの車両２の汚れ度合の数値をＤ、ユーザの乗車時間をＴとしたときに、メンテナンス必要度の代用特性値Ｍは、Ｄ×Ｔを用いれば定量化することができる。具体的には、たとえば、通常又は標準的な利用の汚れ度合を予めＤ＝１／時間と定めておき、Ｍ＝Ｄ×Ｔが１００に達したときに清掃メンテナンスを実施するものとすればよい。

また、清掃メンテナンスのメンテナンス必要度の代用特性値を算出するにあたり、メンテナンス必要度を加速あるいは減速させる係数Ｘ（以下、加速／減速係数ともいう）を用いてメンテナンス必要度の推定代用特性値を算出（補正）してもよい。たとえば、配車ルートの走行環境（舗装路、悪路、海岸沿い、雨天時など）が取得できる場合には、配車ルートから推定される汚れ度合と、通常の利用における汚れ具合Ｄとの比率を加速／減速係数Ｘとし、メンテナンス必要度の代用特性値Ｍ＝（Ｄ×Ｘ）×Ｔとすればよい。また、ユーザの利用履歴（綺麗に利用するか否か）が取得できる場合には、ユーザの過去の利用における汚れ度合の平均値と、通常の利用における汚れ具合Ｄとの比率を加速／減速係数Ｘとし、メンテナンス必要度の代用特性値Ｍ＝（Ｄ×Ｘ）×Ｔとすればよい。また、ユーザの属性（たとえば年齢）が取得できる場合には、その年代のユーザの利用時の汚れ度合の平均値と、通常の利用における汚れ具合Ｄとの比率を加速／減速係数Ｘとし、メンテナンス必要度の代用特性値Ｍ＝（Ｄ×Ｘ）×Ｔとすればよい。

給油メンテナンスのメンテナンス必要度は、ユーザが車両２に乗車した走行距離、又は燃料消費量などを代用特性として定量化することができる。たとえば、走行距離をメンテナンス代用特性値として用いた場合、配車ルートが取得できる場合には、配車ルートから走行距離を算出すれば、給油メンテナンスのメンテナンス必要度を定量化することができる。また、配車ルートを用いる以外にも、ユーザの利用履歴が取得できる場合には、ユーザの過去の走行距離の平均値を算出すれば、給油メンテナンスのメンテナンス必要度を定量化することができる。また、配車ルート又はユーザの利用履歴を用いる以外にも、ユーザの属性が取得できる場合には、たとえば、年代ごとに配車利用時の平均走行距離を事前に算出しておき、ユーザの年齢から該当する年代の走行距離を抽出すれば、給油メンテナンスのメンテナンス必要度を定量化することができる。

整備メンテナンスのメンテナンス必要度は、ユーザが車両２に乗車した走行距離、走行時間、乗車回数などを代用特性として定量化することができる。たとえば、ユーザが車両２に乗車した走行距離を整備メンテナンスの代用特性値として用いた場合、配車ルートが取得できる場合には、配車ルートから走行距離を算出すれば、整備メンテナンスのメンテナンス必要度を定量化することができる。また、配車ルートを用いる以外にも、ユーザの利用履歴が取得できる場合には、ユーザの過去の走行距離の平均値を算出すれば、整備メンテナンスのメンテナンス必要度を定量化することができる。また、配車ルート又はユーザの利用履歴を用いる以外にも、ユーザの属性が取得できる場合には、例えば、年代ごとに配車利用時の平均走行距離を事前に算出しておき、ユーザの年齢から該当する年代の走行距離を抽出すれば、整備メンテナンスのメンテナンス必要度を定量化することができる。

ソフト更新メンテナンス、広告貼り付けメンテナンスのメンテナンス必要度は、経過時間などを代用特性として定量化することができる。たとえば、経過時間をソフト更新メンテナンス又は広告貼り付けメンテナンスの代用特性値として用いた場合、配車ルートが取得できる場合には、配車ルートから、利用開始時刻から利用終了時刻までの経過時間を算出すれば、ソフト更新メンテナンス又は広告貼り付けメンテナンスのメンテナンス必要度を定量化することができる。また、ユーザの利用履歴が取得できる場合には、ユーザの過去の利用時間の平均値を算出すれば、ソフト更新メンテナンス又は広告貼り付けメンテナンスのメンテナンス必要度を定量化することができる。また、ユーザの属性（たとえば年齢）が取得できる場合には、年代ごとに配車利用時の平均利用時間を事前に算出しておき、ユーザの年齢から該当する年代の平均利用時間を抽出すれば、ソフト更新メンテナンス又は広告貼り付けメンテナンスのメンテナンス必要度を定量化することができる。

判断部１５は、増加メンテナンス推定部１４で推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断したのち、その結果をメンテナンス必要度推定部１６に出力する。ここで、判断部１５において設定される閾値は、サービス余力限界値に対して低い閾値、換言すれば、サービス余力限界値に対して、メンテナンスの実施の指示が出る方向の値であればよく、サービス提供者が任意に設定することができる。なお、サービス余力限界値とは、無人運転車両による輸送サービスなどを提供するに当たり、これ以上利用を継続しては車両２のメンテナンス対象の品質が低下して輸送サービス品質を満足し得ないと考えられる限界値をいう。このサービス余力限界値は、無人運転車両の輸送サービスの提供者などにより任意の値に設定することができる。たとえば、給油メンテナンスのメンテナンス必要度の代用特性値が累積走行距離である場合には、サービス余力限界値をたとえば最大航続距離に設定することができる。判断部１５は、増加メンテナンス推定部１４で推定されたメンテナンス必要度の増加絶対値が、各メンテナンス項目に設定された閾値以上になるか否かを判断するので、閾値以上になるメンテナンス必要度が存在するということは、各車両２の現在のメンテナンス必要度がどのような値であろうと、そのメンテナンス項目（一又は複数）については、配車後に必ずメンテナンスの実施が必要になるということである。増加メンテナンス推定部１４及び判断部１５は、このような意義を有する。

メンテナンス必要度推定部１６は、増加メンテナンス推定部１４で推定されたメンテナンスについて、判断部１５においてそのメンテナンス必要度が閾値以上になると判断された場合に、配車可能な車両のメンテナンス項目のメンテナンス必要度を推定し、その結果を配車車両決定部１７へ出力する。ここで、メンテナンス必要度推定部１６は、まず複数の車両２から配車可能な車両２を抽出するが、配車可能な車両２は、複数の車両２のうち、輸送サービスの提供を待機中の車両（利用中又は利用予約が確定している車両以外の車両）であって、利用要求情報に基づいて推定される全てのメンテナンス項目のメンテナンス必要度が、それぞれに設定されたサービス余力限界値を超えない車両を抽出する。たとえば、上述した利用要求情報に含まれる乗降地点に基づいて配車ルート決定部１３にて決定された配車ルートを走行しても、給油メンテナンスのメンテナンス必要度（累積走行距離）が最大航続距離を超えない車両２などを抽出する。

さらにメンテナンス必要度推定部１６は、こうして抽出された配車可能な車両２の全車について、複数のメンテナンス項目のうちの少なくとも２つのメンテナンス項目、好ましくは判断部１５において閾値以上となると判断されたメンテナンス項目を除く少なくとも１つのメンテナンス項目、より好ましくは全てのメンテナンス項目について、メンテナンス必要度が、各閾値以上になるか否かを判断する。なお、各車両２の清掃メンテナンス、給油メンテナンス、整備メンテナンス、ソフト更新メンテナンス、広告貼り付けメンテナンスのそれぞれのメンテナンス必要度は、上述した増加メンテナンス推定部１４における処理と同じ代用特性値を用い、最終メンテナンス日時から現在に至るまでのメンテナンス必要度に加算した値が、各閾値以上となるか否かを判断する。

すなわち、清掃メンテナンスのメンテナンス必要度は、最終の清掃メンテナンス日時から配車ルートの走行が終了するまでの、ユーザが車両２に乗車した時間、ユーザが車両２に乗車した距離、ユーザが車両２に乗車した回数などを代用特性として定量化することができる。たとえば、単位時間当たりの車両２の汚れ度合の数値をＤ、ユーザの乗車時間をＴとしたときに、メンテナンス必要度の代用特性値Ｍは、Ｄ×Ｔを用いれば定量化することができる。

このとき、増加メンテナンス推定部１４における処理と同様に、清掃メンテナンスのメンテナンス必要度の代用特性値を算出するにあたり、メンテナンス必要度を加速あるいは減速させる係数Ｘを用いてメンテナンス必要度の推定代用特性値を算出（補正）してもよい。たとえば、配車ルートの走行環境（舗装路、悪路、海岸沿い、雨天時など）が取得できる場合には、配車ルートから推定される汚れ度合と、通常の利用における汚れ具合Ｄとの比率を加速／減速係数Ｘとし、メンテナンス必要度の代用特性値Ｍ＝（Ｄ×Ｘ）×Ｔとすればよい。また、ユーザの利用履歴（綺麗に利用するか否か）が取得できる場合には、ユーザの過去の利用における汚れ度合の平均値と、通常の利用における汚れ具合Ｄとの比率を加速／減速係数Ｘとし、メンテナンス必要度の代用特性値Ｍ＝（Ｄ×Ｘ）×Ｔとすればよい。また、ユーザの属性（たとえば年齢）が取得できる場合には、その年代のユーザの利用時の汚れ度合の平均値と、通常の利用における汚れ具合Ｄとの比率を加速／減速係数Ｘとし、メンテナンス必要度の代用特性値Ｍ＝（Ｄ×Ｘ）×Ｔとすればよい。

給油メンテナンスのメンテナンス必要度は、最終の給油メンテナンス日時から配車ルートの走行が終了するまでのユーザが車両２に乗車した累積走行距離、又は燃料消費量などを代用特性として定量化することができる。たとえば、累積走行距離をメンテナンス代用特性値として用いた場合、配車ルートが取得できる場合には、配車ルートから算出される走行距離を、最終給油日時から現在に至るまでの累積走行距離に加算すれば定量化することができる。また、配車ルートを用いる以外にも、ユーザの利用履歴が取得できる場合には、ユーザの過去の走行距離の平均値を、最終給油日時から現在に至るまでの累積走行距離に加算すれば、給油メンテナンスのメンテナンス必要度を定量化することができる。また、配車ルート又はユーザの利用履歴を用いる以外にも、ユーザの属性が取得できる場合には、たとえば、年代ごとに配車利用時の平均走行距離を事前に算出しておき、ユーザの年齢から該当する年代の走行距離を抽出して、最終給油日時から現在に至るまでの累積走行距離に加算すれば、給油メンテナンスのメンテナンス必要度を定量化することができる。

整備メンテナンスのメンテナンス必要度は、最終の整備メンテナンス日時から配車ルートの走行が終了するまでのユーザが車両２に乗車した累積走行距離、累積走行時間、累積乗車回数などを代用特性として定量化することができる。たとえば、ユーザが車両２に乗車した累積走行距離を、整備メンテナンスの代用特性値として用いた場合、配車ルートが取得できる場合には、配車ルートから算出される走行距離を、最終整備日時から現在に至るまでの累積走行距離に加算すれば、整備メンテナンスのメンテナンス必要度を定量化することができる。また、配車ルートを用いる以外にも、ユーザの利用履歴が取得できる場合には、ユーザの過去の走行距離の平均値を、最終整備日時から現在に至るまでの累積走行距離に加算すれば、整備メンテナンスのメンテナンス必要度を定量化することができる。また、配車ルート又はユーザの利用履歴を用いる以外にも、ユーザの属性が取得できる場合には、例えば、年代ごとに配車利用時の平均走行距離を事前に算出しておき、ユーザの年齢から該当する年代の走行距離を抽出して、最終整備日時から現在に至るまでの累積走行距離に加算すれば、整備メンテナンスのメンテナンス必要度を定量化することができる。

ソフト更新メンテナンス、広告貼り付けメンテナンスのメンテナンス必要度は、最終のメンテナンス日時から配車ルートの走行を終了するまでの累積経過時間などを代用特性として定量化することができる。たとえば、累積経過時間をソフト更新メンテナンス又は広告貼り付けメンテナンスの代用特性値として用いた場合、配車ルートが取得できる場合には、配車ルートから算出される利用開始時刻から利用終了時刻までの経過時間を、最終メンテナンス日時から現在に至るまでの累積経過時間に加算すれば、ソフト更新メンテナンス又は広告貼り付けメンテナンスのメンテナンス必要度を定量化することができる。また、ユーザの利用履歴が取得できる場合には、ユーザの過去の利用時間の平均値を、最終メンテナンス日時から現在に至るまでの累積経過時間に加算すれば、ソフト更新メンテナンス又は広告貼り付けメンテナンスのメンテナンス必要度を定量化することができる。また、ユーザの属性（たとえば年齢）が取得できる場合には、年代ごとに配車利用時の平均利用時間を事前に算出しておき、ユーザの年齢から該当する年代の平均利用時間を抽出し、これを、最終メンテナンス日時から現在に至るまでの累積経過時間に加算すれば、ソフト更新メンテナンス又は広告貼り付けメンテナンスのメンテナンス必要度を定量化することができる。

配車車両決定部１７は、メンテナンス必要度推定部１６で推定されたメンテナンス項目のメンテナンス必要度が、各閾値以上になるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両２を、ユーザからの利用要求に応じる車両２として決定する。ここで、配車車両決定部１７において設定される閾値は、サービス余力限界値に対して低い閾値、換言すれば、サービス余力限界値に対して、メンテナンスの実施の指示が出る方向の値であればよく、サービス提供者が任意に設定することができる。そして、配車車両決定部１７で決定された結果、すなわち配車すべき車両２のＩＤを移動指示部１８及び通信部１９へ出力する。なお、配車車両決定部１７において決定される車両２は、メンテナンス必要度推定部１６で推定されたメンテナンス項目のメンテナンス必要度が、各閾値以上になるメンテナンス項目が複数ある車両２であるが、こうした車両が複数台存在する場合には、たとえばユーザからの利用要求に応じるための配車時間が最短の車両を選択することができる。

《車 両》
本実施形態の車両２としては、モータを駆動源とする電気自動車、内燃機関を駆動源とするエンジン自動車、モータ及び内燃機関の両方を駆動源とするハイブリッド自動車を例示できる。モータを駆動源とする電気自動車やハイブリッド自動車には、二次電池をモータの電源とするタイプのほか、燃料電池又は内燃機関をモータの電源とするタイプのものも含まれる。また、車両２は、ドライバー（人間）が運転する車両、ドライバーが乗車した上で自動運転により走行する自動運転車両、又はドライバーが乗車しない無人運転車両のいずれも含まれ、本実施形態の自動運転機能には、本願出願時における自動運転技術を適宜に用いることができる。

車両２は、ユーザからの利用要求（リクエスト）に応じて提供されるサービス車両であり、本実施形態では、当該サービスが展開される地域に複数台配置されているものとする。ただし、上述したとおり、自家用車や社用車など、非サービス車両を除外する趣旨ではない。車両２には、車両位置算出部２１、車両状態検出部２２、車両情報送信部２３、サーバ情報受信部２４及び走行制御部２５が含まれる。

車両位置算出部２１は、車両２の位置を算出し、車両情報送信部２３に出力する。車両位置算出部２１は、たとえばＧＰＳ／ＩＮＳセンサーと接続されたＥＣＵであり、ＧＰＳ／ＩＮＳセンサーから出力される緯度経度の位置情報を、一定時間（たとえば１００ｍｓｅｃ）毎に出力する。位置情報の算出方法は、特に限定されず、たとえば、地図データに基づくマップマッチングなど、位置を特定可能な他の手法を用いてもよい。

車両状態検出部２２は、車速、ドアロック及びドアの開閉状態、シートベルトセンサー値、自動運転中か否か、などの各種車両状態をはじめとして、車両２への利用要求情報の受信が可能か否か、清掃中その他のメンテナンス中か否か、乗客の有無及び人数、移動指示の目的地に到着したか否かなど、無人自動運転の遠隔監視に関する情報も検出して、車両情報送信部２３に出力する。

車両情報送信部２３は、たとえば４Ｇ／ＬＴＥのモバイル通信機能を備えた車載デバイスであり、ＣＡＮやＬＡＮ等で車両位置算出部２１及び車両状態検出部２２から出力される情報を、一定時間（たとえば１００ｍｓｅｃ）毎に、サーバ１のデータベース１２に送信する。

サーバ情報受信部２４は、たとえば４Ｇ／ＬＴＥのモバイル通信機能を備えた車載デバイスであり、サーバ１の通信部１９を介して移動指示部１８から送信された、待機場所へのルート、ユーザを乗せる地点までの走行ルート、清掃場所その他のメンテナンス場所への走行ルート等の各種走行ルートをはじめ、その他無人の自動運転車両を運行する上で必要な情報を受信する。

走行制御部２５は、車両２の走行駆動源（エンジン及び／又はモータ）、操舵機構、制動機構、方向指示器やワイパーを含む各種電装機器を自動制御するコントローラであり、サーバ１の通信部１９を介して移動指示部１８から送信された、待機場所へのルート、ユーザを乗せる地点までの走行ルート、清掃場所その他のメンテナンス場所への走行ルート等の各種走行ルートをはじめ、その他無人の自動運転車両を運行する上で必要な情報に基づいて、車両２の走行駆動源、操舵機構、制動機構及び各種電装機器を自動制御する。

《ユーザ端末装置》
ユーザ端末装置３は、輸送サービスを希望するユーザが利用要求を行うために使用される端末装置であり、入力部３１と、表示部３２と、通信部３３とを備える。ユーザ端末装置３は、たとえばスマートフォンなどの携帯端末装置であり、利用要求するためのアプリケーションソフトウェアを実行して、通信部３３から４Ｇ／ＬＴＥやＷｉＦｉ（登録商標）などの電気通信回線網を介して、サーバ１にアクセスする。なお、ユーザ端末装置３は、特に限定されず、上記手段のほか、たとえばＷＥＢアプリケーションソフトウェアとして実装されたパーソナルコンピュータからインターネットを介して利用要求を行うなど、他の実装方法を用いてもよい。

ユーザによる入力部３１への入力に基づき、上述したとおり車両２の利用要求情報を、通信部３３を介して利用要求取得部１１に送信する。また配車車両決定部１７から、通信部１９，３３を介して、利用要求情報に対する利用要求結果情報を受信し、ディスプレイなどの表示部３２によりユーザに提示する。

利用要求取得部１１に送信する車両２の利用要求情報は、出発地と目的地を含み、目的地はユーザからの入力で取得し、出発地はユーザの位置情報、またはユーザからの入力で取得してもよい。その他に、経由地の指定、乗降地点の指定、乗車人数、予約時間、相乗り可否などの付加的な情報を更に含んでもよい。

配車車両決定部１７から送信される利用要求結果情報については、ユーザの乗車場所と降車場所、予約された車両２の現在位置、及び予約車両を識別するための情報を含み、配車車両決定部１７で算出された情報に基づき、乗車場所に車両が到着する時間、乗車場所から降車場所までの移動時間、ユーザが乗車場所まで移動するための推奨徒歩ルートなどの付加情報を含んでもよい。

次に、図２及び図３〜図９を参照しながら具体的な処理フローを説明する。図２は、サーバ１にて実行される車両の配車管理処理の一例を示すフローチャート、図３〜図９は、図２のステップＳ１〜Ｓ６の各シーンを示す図である。この処理フローは、所定時間間隔、又は１名のユーザの利用が終了する毎など、周期的に実行されることが好ましい。なお、以下の説明では、車両２に対する複数のメンテナンスとして車両２の清掃メンテナンスと給油メンテナンスと、整備メンテナンスとを例示するが、他の複数のメンテナンスも同じ考え方で処理することができる。また、以下の説明では、清掃メンテナンスのメンテナンス必要度の推定代用特性値として、その車両２へのユーザの乗車時間を用いた例を示し、給油メンテナンスのメンテナンス必要度の推定代用特性値として、その車両２の走行可能距離を用いた例を示し、整備メンテナンスのメンテナンス必要度の推定代用特性値として、その車両２の走行距離を用いた例を示すが、清掃メンテナンスについてはユーザの乗車距離やユーザの乗車回数も同じ考え方で処理することができ、給油メンテナンスについては燃料消費量又は電池消費量も同じ考え方で処理することができ、整備メンテナンスについてはユーザの乗車時間も同じ考え方で処理することができる。

図２のステップＳ１では、あるユーザが自分のユーザ端末装置３を用いて、車両２の利用要求情報を、通信部３３を介して利用要求取得部１１に送信すると、サーバ１の利用要求取得部１１は、当該利用要求情報を取得し、データベース１２に出力する。この利用要求情報には、そのユーザのＩＤ、ユーザの配車希望意思、ユーザの現在位置、ユーザが希望する乗車地点及び降車地点（緯度・経度などの位置情報）、ユーザが希望する配車時間、乗車人数のほか、ユーザの年齢・職業・家族構成・嗜好性などユーザ個人の属性情報、ユーザの当該配車サービスの利用履歴、配車時の天候その他の環境情報、配車ルートの環境情報などが含まれる。図３は、ステップＳ１のシーンの一例を示す図であり、たとえば、ユーザＸが、海水浴場の近くの現在地点から、降車地点Ｙまでの配車を要求したものとする。

ステップＳ２では、配車ルート決定部１３は、データベース１２に格納されたユーザＸの利用要求情報に基づいて、配車ルートを決定する。図４は、ステップＳ２のシーンの一例を示す図であり、配車ルート決定部１３は、ユーザ端末装置３から送信されてデータベース１２に格納された乗降地点情報から、ユーザＸが希望する降車地点Ｙまでの配車ルートＲを決定したものとする。図示する配車ルートＲは、ユーザＸの現在地点から降車地点Ｙまでの最短ルートを選択したものであるが、ユーザＸの現在地点が海水浴場の近くであるため、配車ルートＲの一部は海水浴場に沿った道路を走行するものとなる。

ステップＳ３では、増加メンテナンス推定部１４は、データベース１２に格納されたユーザＸの利用要求情報に基づいて、配車により増加するメンテナンス項目のメンテナンス必要度を推定する。図５は、ステップＳ３のシーンの一例を示す図であり、ユーザＸへの配車により増加するメンテナンス必要度を示した図である。本例では、増加メンテナンス推定部１４は、配車ルート決定部１３により決定された配車ルートＲの走行条件に基づいて、清掃メンテナンスのメンテナンス必要度、整備メンテナンスのメンテナンス必要度及び給油メンテナンスのメンテナンス必要度をそれぞれ推定したものである。

ここで、清掃メンテナンスのメンテナンス必要度の代用特性値は、配車ルートＲを走行した場合の乗車時間と、加速／減速係数とを用いて車室内外の汚れ度合を推定し、整備メンテナンスのメンテナンス必要度の代用特性値及び給油メンテナンスのメンテナンス必要度の代用特性値は、配車ルートＲを走行した場合の走行距離を用いて推定するものとすると、図５に示すように整備メンテナンスのメンテナンス必要度と給油メンテナンスのメンテナンス必要度は、配車ルートＲの走行距離に相関した値だけ増加するのに対し、清掃メンテナンスのメンテナンス必要度は、ユーザＸの現在地点が海水浴場の近くという環境下にあるため、通常の汚れ度合に対する加速／減速係数が大きいものとなり、その結果、清掃メンテナンスのメンテナンス必要度が大幅に増加すると推定される。

ユーザＸの現在地点が海水浴場の近くであるため、ユーザＸは海水浴客と予想され、乗車時に車内が砂で汚れることが予想される。また、海水浴客ではなかったとしても配車ルートＲの一部は海水浴場に沿った汚れに対する走行環境が悪い道路であるため、車室外の汚れ具合が相対的に増加すると予想されるからである。たとえば、上述した単位時間当たりの汚れ度合Ｄの通常配車の場合を１としても、加速／減速係数Ｘが通常の１に対してたとえば２０（本例の場合は加速係数になる）であると、清掃メンテナンスのメンテナンス必要度の代用特性値Ｍ＝（Ｄ×Ｘ）×Ｔが２０倍に増加する。

ステップＳ４では、判断部１５は、ステップＳ３で推定した各メンテナンスのメンテナンス必要度の代用特性値が、それぞれに設定された閾値以上であるかどうかを判断する。図６は、ステップＳ４のシーンの一例を示す図であり、ユーザＸへの配車により、整備メンテナンスのメンテナンス必要度及び給油は、それぞれの閾値未満であるものの、清掃メンテナンスのメンテナンス必要度が閾値以上であると判断された場合である。なお、図６において、清掃メンテナンスのメンテナンス必要度、整備メンテナンスのメンテナンス必要度及び給油メンテナンスのメンテナンス必要度のそれぞれの閾値を便宜的に一律の値として図示しているが、実際の閾値は、各メンテナンスのメンテナンス必要度に対してそれぞれ設定されている。

ステップＳ４において、清掃メンテナンスのメンテナンス必要度、整備メンテナンスのメンテナンス必要度及び給油メンテナンスのメンテナンス必要度のそれぞれの代用特性値が、いずれも各閾値未満である場合には、ステップＳ７へ進み、配車車両決定部１７は、配車可能な車両２のうち配車時間（車両２の現在地点からユーザＸの現在地点までの走行時間）が最短である車両を抽出し、その車両２を配車車両に決定し、移動指示部１８にその旨を出力する。ユーザＸからの利用要求情報に基づいて推定されたメンテナンスのメンテナンス必要度が各閾値以上まで増加しない場合には、配車後において各メンテナンスの必要度がさほど高くならないので、無理して複数のメンテナンス項目を同時に実施するよりもむしろ、配車時間を優先したサービスとする趣旨である。

これに対して、ステップＳ４において、清掃メンテナンスのメンテナンス必要度、整備メンテナンスのメンテナンス必要度及び給油メンテナンスのメンテナンス必要度のそれぞれの代用特性値のいずれかが、各閾値以上である場合には、ステップＳ５へ進む。このような場合は、配車後において、少なくとも閾値以上となったメンテナンス項目についてメンテナンスが必要となるので、他のメンテナンス項目を同時に実施することでメンテナンス時間を短縮する方を優先する。すなわち、ステップＳ５では、ステップＳ４で配車により増加するメンテナンス必要度の代用特性値が閾値以上であるメンテナンス項目があると判断された場合に、配車可能な車両の、現在の全メンテナンスのメンテナンス必要度を推定する。

図７は、ステップＳ５のシーン（推定前）の一例を示す図であり、ユーザＸの利用要求に対して配車可能な車両がＡ，Ｂの２台であり、それぞれの車両Ａ，Ｂの現在の清掃メンテナンスのメンテナンス必要度、整備メンテナンスのメンテナンス必要度及び給油メンテナンスのメンテナンス必要度のそれぞれの代用特性値を示した図である。図７に示す例では、清掃のメンテナンスの代用特性は、車両Ａ，Ｂとも同じ値であり、整備メンテナンスおよび給油メンテナンスの代用特性値は、車両Ａがいずれも０であるのに対し、車両Ｂは０よりも大きい値となっている。メンテナンス必要度推定部１６は、この現在の清掃メンテナンスのメンテナンス必要度、整備メンテナンスのメンテナンス必要度及び給油メンテナンスのメンテナンス必要度のそれぞれの代用特性値を基準にして、データベース１２に格納されたユーザＸの利用要求情報に基づいて、配車による各メンテナンス項目のメンテナンス必要度を推定する。

配車可能な車両Ａ，Ｂの現在地点がそれぞれ異なることがあり、また車両Ａ，ＢはユーザＸの現在地点から離れていることも少なくないので、車両Ａ，ＢがユーザＸの現在地点まで走行することも加味したメンテナンス必要度を推定する。図８は、ステップＳ５のシーン（推定後）の一例を示す図であり、メンテナンス必要度推定部１６による推定後においては、図８に示すように、清掃のメンテナンスの代用特性は、車両Ａ，Ｂとも極めて高い値となり、給油メンテナンスの代用特性値の増加量は車両Ａ，Ｂともに同じ程度であるが、整備メンテナンスの代用特性値は、車両Ａの値に比べ車両Ｂの値が大きい値となっている。

ステップＳ６では、配車車両決定部１７は、ステップＳ５で推定した配車可能な車両Ａ，Ｂの現在の全てのメンテナンスの代用特性値が、各閾値以上であるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両Ｂを、ユーザＸからの利用要求に応じる車両として決定し、移動指示部１８にその旨を出力する。図８に示す例では、車両Ａは、清掃メンテナンスのメンテナンス必要度の代用特性値のみが閾値以上となっているのに対し、車両Ｂは、清掃メンテナンスのメンテナンス必要度の代用特性値に加えて、整備メンテナンスのメンテナンス必要度の代用特性値も閾値以上となっている。したがって、車両ＢをユーザＸに対して配車することで、配車サービス終了後においては、清掃メンテナンスと整備メンテナンスの２つのメンテナンスを同時に行うことができ、メンテナンス時間を短縮することができる。

なお、ステップＳ６において、図８に示す車両Ａ，Ｂの両方ともに、閾値以上になるメンテナンス項目が複数ある場合には、ユーザＸに対する配車時間（車両Ａ，Ｂの現在地点からユーザＸの現在地点までの走行時間）が最短である車両を抽出し、その車両Ａを配車車両に決定し、移動指示部１８にその旨を出力する。また、配車可能な車両Ａ，Ｂ，Ｃが３台存在し、図９に示すように、配車車両決定部１７は、ステップＳ５で推定した配車可能な車両Ａ，Ｂ，Ｃの現在の全てのメンテナンスの代用特性値が、各閾値以上であるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両Ｂ，Ｃが複数台ある場合についても、ユーザＸに対する配車時間（車両Ｂ，Ｃの現在地点からユーザＸの現在地点までの走行時間）が最短である車両を抽出し、その車両Ｃを配車車両に決定し、移動指示部１８にその旨を出力する。

ちなみに、配車車両決定部１７は、決定した配車すべき車両２の特定情報を移動指示部１８に出力すると、移動指示部１８は、通信部１９を介して該当車両２のサーバ情報受信部２４に移動指示情報を送信する。この移動指示情報には、ユーザＸの乗車地点と降車地点と配車ルートなどが含まれ、車両２の走行制御部２５は、当該移動指示情報にしたがって車両を走行させて配車サービスを実施する。

また、当該車両２の配車サービスを終了すると、当該車両２は清掃メンテナンスと整備メンテナンスを実施するためにメンテナンス場所に移動する。この場合に、清掃メンテナンス及び整備メンテナンスを通常の清掃メンテナンス及び整備メンテナンスよりも相対的に短時間で行う旨の指示を伴ってもよい。相対的に短時間で行う清掃メンテナンスとしては、人目に付き易い部位に限った清掃や清掃回数を限定した簡易な清掃などが挙げられる。こうしたメンテナンスの短時間化の指示は、清掃メンテナンスに限定されず、走行エネルギの補給、部品交換、車載コンピュータのソフトウェア更新といったメンテナンスについて行ってもよい。

以上のとおり、本実施形態の車両管理システムＳ及び車両管理方法によれば、車両２の利用情報に基づいて複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定し、推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断し、メンテナンス必要度が閾値以上になると判断された場合に、配車可能な車両のメンテナンス項目のメンテナンス必要度を推定し、推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両を、ユーザからの利用要求に応じる車両として決定するので、複数のメンテナンスを同時に実施することができる。その結果、メンテナンス場所への移動時間といった無駄な時間を短縮することができるので、サービスの提供機会が損失するのを抑制することができる。

また、本実施形態の車両管理システムＳ及び車両管理方法によれば、閾値以上になるメンテナンス項目が複数ある車両が複数台ある場合には、ユーザからの利用要求に応じる配車時間が最短の車両を配車するので、サービスの品質を高めつつ、より一層、サービスの提供機会が損失するのを抑制することができる。

また、本実施形態の車両管理システムＳ及び車両管理方法によれば、増加メンテナンス推定部１４により推定されるメンテナンス項目は、車両の清掃メンテナンス、車両の部品整備メンテナンス、車両の走行エネルギ補給メンテナンスのうち少なくとも一のメンテナンスを含むので、メンテナンス項目のうち頻繁に発生する車両の清掃メンテナンス、車両の部品整備メンテナンス、車両の走行エネルギ補給メンテナンスに対して対応することができ、より一層、サービスの提供機会が損失するのを抑制することができる。

また、本実施形態の車両管理システムＳ及び車両管理方法によれば、メンテナンス必要度推定部１６により推定されるメンテナンス項目は、車両の清掃メンテナンス、車両の部品整備メンテナンス、車両の走行エネルギ補給メンテナンスのうち少なくとも二のメンテナンスを含むので、メンテナンス項目のうち頻繁に発生する車両の清掃メンテナンス、車両の部品整備メンテナンス、車両の走行エネルギ補給メンテナンスに対して対応することができ、より一層、サービスの提供機会が損失するのを抑制することができる。

また、本実施形態の車両管理システムＳ及び車両管理方法によれば、利用要求情報は、ユーザの属性を含み、増加メンテナンス推定部１４は、ユーザの属性に基づいて、複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定するので、たとえば、あるユーザの個人情報が格納されたユーザ属性データから、運転の荒いドライバーである場合には、配車後にタイヤの摩耗などで車両の部品整備メンテナンスのメンテナンス必要度が増加すると予測でき、より精度良く増加するメンテナンスを推定できる。その結果、より一層、サービスの提供機会が損失するのを抑制することができる。

また、本実施形態の車両管理システムＳ及び車両管理方法によれば、利用要求情報は、ユーザの利用履歴を含み、増加メンテナンス推定部１４は、ユーザの利用履歴に基づいて、複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定するので、たとえば、あるユーザの配車サービスの利用履歴データから、このユーザは車内を汚しやすい傾向がある場合に清掃メンテナンスのメンテナンス必要度が増加すると予測でき、より精度良く増加するメンテナンスを推定できる。その結果、より一層、サービスの提供機会が損失するのを抑制することができる。

また、本実施形態の車両管理システムＳ及び車両管理方法によれば、利用要求情報は、乗降地情報、配車時の環境情報及び配車時間を含み、増加メンテナンス推定部１４は、乗降地情報、配車時の環境情報及び配車時間に基づいて、複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定するので、たとえば、あるユーザの利用要求に基づいて決定した配車ルートは、配車時の環境データから、悪路を走行することが分かり、配車後に念のため車両の整備をする必要があることから、部品整備のメンテナンスのメンテナンス必要度が増加すると予測でき、より精度良く増加するメンテナンスを推定できる。その結果、より一層、サービスの提供機会が損失するのを抑制することができる。

Ｓ…車両管理システム
１…サーバ
１１…利用要求取得部
１２…データベース
１３…配車ルート決定部
１４…増加メンテナンス推定部
１５…判断部
１６…メンテナンス必要度推定部
１７…配車車両決定部
１８…移動指示部
１９…通信部
２…車両
２１…車両位置算出部
２２…車両状態検出部
２３…車両情報送信部
２４…サーバ情報受信部
２５…走行制御部
３…ユーザ端末装置
３１…入力部
３２…表示部
３３…通信部

Claims (8)

1. 複数の車両を一又は複数のユーザで利用し、前記ユーザからの利用要求に応じて前記車両の配車を管理する車両管理システムであって、前記車両の複数のメンテナンス項目のメンテナンス必要度が各メンテナンス項目に設定された閾値に達した場合に、当該閾値に達したメンテナンスの実施を指示する車両管理システムにおいて、
   前記車両の利用要求情報を取得する利用要求取得部と、
   前記利用要求情報に基づいて、前記複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定する増加メンテナンス推定部と、
   前記増加メンテナンス推定部で推定されたメンテナンス項目のメンテナンス必要度が当該メンテナンス項目に設定された閾値以上になるか否かを判断する判断部と、
   前記判断部で前記メンテナンス必要度が閾値以上になると判断された場合に、配車可能な車両のメンテナンス項目のメンテナンス必要度を推定するメンテナンス必要度推定部と、
   前記メンテナンス必要度推定部で推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両を、前記ユーザからの利用要求に応じる車両として決定する配車車両決定部と、を備える車両管理システム。
2. 前記配車車両決定部は、閾値以上になるメンテナンス項目が複数ある車両が複数台ある場合には、前記ユーザからの利用要求に応じる配車時間が最短の車両を配車する請求項１に記載の車両管理システム。
3. 前記増加メンテナンス推定部により推定されるメンテナンス項目は、車両の清掃メンテナンス、車両の部品整備メンテナンス、車両の走行エネルギ補給メンテナンスのうち少なくとも一のメンテナンスを含む請求項１又は２に記載の車両管理システム。
4. 前記メンテナンス必要度推定部により推定されるメンテナンス項目は、車両の清掃メンテナンス、車両の部品整備メンテナンス、車両の走行エネルギ補給メンテナンスのうち少なくとも二のメンテナンスを含む請求項３に記載の車両管理システム。
5. 前記利用要求情報は、前記ユーザの属性を含み、
   前記増加メンテナンス推定部は、前記ユーザの属性に基づいて、前記複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定する請求項１〜４のいずれか一項に記載の車両管理システム。
6. 前記利用要求情報は、前記ユーザの利用履歴を含み、
   前記増加メンテナンス推定部は、前記ユーザの利用履歴に基づいて、前記複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定する請求項１〜４のいずれか一項に記載の車両管理システム。
7. 前記利用要求情報は、乗降地情報、配車時の環境情報及び配車時間を含み、
   前記増加メンテナンス推定部は、乗降地情報、配車時の環境情報及び配車時間に基づいて、前記複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定する請求項１〜４のいずれか一項に記載の車両管理システム。
8. プログラムにより動作するコンピュータを用いて、複数の車両を一又は複数のユーザで利用し、前記ユーザからの利用要求に応じて前記車両の配車を管理する車両管理方法であって、前記車両の複数のメンテナンス項目のメンテナンス必要度が各メンテナンス項目に設定された閾値に達した場合に、当該閾値に達したメンテナンスの実施を指示する車両管理方法において、
   前記コンピュータは、
   前記車両の利用要求情報を取得し、
   前記利用要求情報に基づいて、前記複数のメンテナンス項目のうちメンテナンス必要度が増加するメンテナンス項目を推定し、
   前記推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断し、
   前記メンテナンス必要度が閾値以上になると判断された場合に、配車可能な車両のメンテナンス項目のメンテナンス必要度を推定し、
   前記推定されたメンテナンス項目のメンテナンス必要度が閾値以上になるか否かを判断し、閾値以上になるメンテナンス項目が複数ある車両を、前記ユーザからの利用要求に応じる車両として決定する車両管理方法。

Images