(57)【要約】      （修正有）【課題】車両の需給状況を考慮した効率的なタイミングで複数のメンテナンスの実施を指示する車両メンテナンス管理システムＳ及び車両メンテナンス管理方法を提供する。【解決手段】サーバ１は、車両２の利用情報を取得する利用情報取得部１０６と、車両のメンテナンス必要度を推定するメンテナンス必要度推定部１０７と、メンテナンス必要度が、第１閾値に達したか否かを判断する第１判断部１０８と、第１判断部により一のメンテナンスに対するメンテナンス必要度が、第１閾値に達したと判断された場合に、メンテナンス必要度推定部で推定された他のメンテナンスに対するメンテナンス必要度が、第１閾値より低い第２閾値に達したか否かを判断する第２判断部１０９と、第２判断部により他のメンテナンスのメンテナンス必要度が第２閾値に達した場合に、一のメンテナンスの実施及び他のメンテナンスの実施を同時に指示するメンテナンス指示部１１１と、を備える。【選択図】図１
2020013374.tif 000002
【特許請求の範囲】
【請求項１】
車両の利用状態が複数のメンテナンスのそれぞれに設定された所定条件を満足した場合に、前記所定条件を満足したメンテナンスの実施を指示する車両メンテナンス管理システムにおいて、
前記車両の利用情報を取得する利用情報取得部と、
前記車両の利用情報に基づいて、前記車両のそれぞれのメンテナンスのメンテナンス必要度を推定するメンテナンス必要度推定部と、
前記メンテナンス必要度推定部で推定されたそれぞれのメンテナンス必要度が、それぞれのメンテナンスに対して設定された第１閾値に達したか否かを判断する第１判断部と、
前記第１判断部により一のメンテナンスに対するメンテナンス必要度が、前記第１閾値に達したと判断された場合に、前記メンテナンス必要度推定部で推定された他のメンテナンスに対するメンテナンス必要度が、当該他のメンテナンスに対して設定された、前記第１閾値より低い第２閾値に達したか否かを判断する第２判断部と、
前記第２判断部により前記他のメンテナンスのメンテナンス必要度が前記第２閾値に達した場合に、前記一のメンテナンスの実施及び前記他のメンテナンスの実施を同時に指示するメンテナンス指示部と、を備える車両メンテナンス管理システム。
【請求項２】
前記第２判断部は、それぞれのメンテナンスのメンテナンス必要度に対して設定された前記第１閾値に対し、その差分が所定値である第２閾値を用いて、前記他のメンテナンスに対するメンテナンス必要度が、前記第２閾値に達したか否かを判断する請求項１に記載の車両メンテナンス管理システム。
【請求項３】
前記第２判断部は、それぞれのメンテナンスのメンテナンス必要度に対して設定された前記第１閾値に対し、その到達率が所定値である第２閾値を用いて、前記他のメンテナンスに対するメンテナンス必要度が、前記第２閾値に達したか否かを判断する請求項１に記載の車両メンテナンス管理システム。
【請求項４】
前記メンテナンス指示部は、
前記第２判断部により前記他のメンテナンスのメンテナンス必要度が前記第２閾値に達した場合に、前記車両の前記一のメンテナンスの実施及び前記他のメンテナンスの実施を同時に指示するときは、
前記一のメンテナンス及び前記他のメンテナンスの少なくとも一方を相対的に短時間で実施する旨を含めて指示する請求項１〜３のいずれか一項に記載の車両メンテナンス管理システム。
【請求項５】
前記メンテナンス指示部は、
前記他のメンテナンスのメンテナンス必要度が、前記第２閾値に達したと判断された場合であっても、予め定められたメンテナンスの重要度が相対的に低いメンテナンスについては、前記車両のメンテナンスの実施の指示を禁止する請求項１〜４のいずれか一項に記載の車両メンテナンス管理システム。
【請求項６】
前記利用情報取得部は、前記車両の使用期間、前記車両の使用回数、前記車両の乗車距離、前記車両の走行エネルギ残量、前記車両の部品寿命、前記車両に搭載されたコンピュータのソフトウェア更新情報、メンテナンス毎の車両の乗車人数の累計、前記車両の使用者の特性、前記車両の走行地域、前記車両の使用時の天候の少なくとも一の情報を取得する請求項１〜５のいずれか一項に記載の車両メンテナンス管理システム。
【請求項７】
前記利用情報取得部は、前記車両の最終清掃日時と、前記最終清掃日時から現在に至るまでの前記車両の利用情報とを取得し、
前記メンテナンス必要度推定部は、前記最終清掃日時から現在に至るまでの前記車両の利用情報に基づいて、前記車両のメンテナンス必要度を推定する請求項６に記載の車両メンテナンス管理システム。
【請求項８】
前記利用情報取得部は、前記車両の最終走行エネルギ補給日時と、前記最終走行エネルギ補給日時から現在に至るまでの前記車両の利用情報とを取得し、
前記メンテナンス必要度推定部は、前記最終走行エネルギ補給日時から現在に至るまでの前記車両の利用情報に基づいて、前記車両のメンテナンス必要度を推定する請求項６又は７に記載の車両メンテナンス管理システム。
【請求項９】
前記利用情報取得部は、前記車両の最終部品交換日時と、前記最終部品交換日時から現在に至るまでの前記車両の利用情報とを取得し、
前記メンテナンス必要度推定部は、前記最終部品交換日時から現在に至るまでの前記車両の利用情報に基づいて、前記車両のメンテナンス必要度を推定する請求項６〜８のいずれか一項に記載の車両メンテナンス管理システム。
【請求項１０】
前記利用情報取得部は、前記ソフトウェア更新情報を取得し、
前記メンテナンス必要度推定部は、前記ソフトウェア更新情報に基づいて、前記車両のメンテナンス必要度を推定する請求項６〜９のいずれか一項に記載の車両メンテナンス管理システム。
【請求項１１】
前記車両は、少なくとも１台の車両を一又は複数のユーザで利用する営業用車両である請求項１〜１０のいずれか一項に記載の車両メンテナンス管理システム。
【請求項１２】
プログラムにより動作するコンピュータを用いて、車両の利用状態が複数のメンテナンスのそれぞれに設定された所定条件を満足した場合に、当該所定条件を満足したメンテナンスの実施を指示する車両メンテナンス管理方法において、
前記コンピュータは、
前記車両の利用情報を取得し、
前記車両の利用情報に基づいて、前記車両のそれぞれのメンテナンスのメンテナンス必要度を推定し、
前記推定されたそれぞれのメンテナンス必要度が、それぞれのメンテナンスに対して設定された第１閾値に達したか否かを判断し、
一のメンテナンスに対するメンテナンス必要度が、前記第１閾値に達したと判断された場合に、前記推定された他のメンテナンスに対するメンテナンス必要度が、当該他のメンテナンスに対して設定された、前記第１閾値より低い第２閾値に達したか否かを判断し、
前記他のメンテナンスのメンテナンス必要度が前記第２閾値に達した場合に、前記一のメンテナンスの実施及び前記他のメンテナンスの実施を同時に指示する車両メンテナンス管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両メンテナンス管理システム及び車両メンテナンス管理方法に関するものである。
【背景技術】
【０００２】
バッテリによる電力供給をシステマチックに実現するために、自律的に移動可能なバッテリの電池残量が、予め定められた閾値よりも低くなると、充電ステーションへの移動を指示することで、充電というメンテナンスを実施するバッテリの制御システムが知られている（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第６０５０９０９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記従来のバッテリの制御システムでは、メンテナンスの指標が電池残量であってメンテナンスの内容が充電だけであるため、充電以外のメンテナンス、たとえば、車両の定期的な清掃、タイヤ、バッテリ、各種オイルなどの部品交換、車載コンピュータのソフトウェアのバージョンアップなどの更新を含む場合には対応できない。しかも、メンテナンスごとに指標を設定したとしても、各指標が予め定められた閾値を超えると、それぞれのメンテナンスに対して独立してメンテナンスが指示されるため、輸送サービスなどの提供機会が損失し、効率的なメンテナンス指示ができないという問題点がある。
【０００５】
本発明が解決しようとする課題は、車両に対して複数のメンテナンスを指示する場合に、車両の需給状況を考慮した効率的なタイミングでメンテナンスの実施を指示することができる車両メンテナンス管理システム及び車両メンテナンス管理方法を提供することである。
【課題を解決するための手段】
【０００６】
本発明は、車両の利用情報を取得し、車両の利用情報に基づいて車両の複数のメンテナンスのそれぞれのメンテナンス必要度を推定し、一のメンテナンスに対するメンテナンス必要度が、第１閾値に達したと判断された場合に、他のメンテナンスに対するメンテナンス必要度が、当該他のメンテナンスに対して設定された、前記第１閾値より低い第２閾値に達したか否かを判断し、他のメンテナンスのメンテナンス必要度が前記第２閾値に達した場合に、前記一のメンテナンスの実施及び前記他のメンテナンスの実施を同時に指示することによって上記課題を解決する。
【発明の効果】
【０００７】
本発明によれば、車両に対して複数のメンテナンスを指示する場合に、車両の需給状況を考慮した効率的なタイミングでメンテナンスの実施を指示することができる。
【図面の簡単な説明】
【０００８】
【図１】本発明の車両メンテナンス管理システムの一実施の形態を示すブロック図である。
【図２】図１のサーバにて実行される車両のメンテナンス管理処理の一例を示すフローチャートである。
【図３】図２のステップＳ５のサブルーチンを示すフローチャートである。
【図４Ａ】図１の第１判断部及び第２判断部にて用いられるメンテナンス必要度の第１閾値及び第２閾値の一例（車両の清掃メンテナンス及び走行エネルギ補給メンテナンス）を説明する車両のメンテナンス必要度と時間との関係を示すグラフである。
【図４Ｂ】図４Ａの比較例を説明する車両のメンテナンス必要度と時間との関係を示すグラフである。
【図５】図１の第２判断部にて用いられるメンテナンス必要度の第２閾値の設定例（車両の清掃メンテナンス）を説明する車両のメンテナンス必要度と時間との関係を示すグラフである。
【図６】図２のステップＳ２のサブルーチンを示すフローチャートである。
【図７】図１の車両情報データベースに登録される会員情報の一例を示すデータシートである。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態を図面に基づいて説明する。図１は、本発明の車両メンテナンス管理システムＳの一実施の形態を示すブロック図である。本実施形態の車両メンテナンス管理システムＳは、本発明に係る車両メンテナンス管理方法を使用したシステムでもある。本実施形態の車両メンテナンス管理システムＳは、少なくとも１台の車両２を一又は複数のユーザ（利用者）で利用する場合に適用して好ましいシステムであり、予約した車両をユーザが取りに行って自ら運転して利用するといったカーシェアリングのような形態のサービス、ドライバーが運転する車両を用いて一又は複数のユーザを目的地まで輸送する形態のサービス、又は、ドライバーが乗車しない無人運転車両を用いて一又は複数のユーザを目的地まで輸送する形態のサービスなどに適用することができる。
【００１０】
また、このような営業用車両のほか、個人が所有する車両（いわゆる自家用車）や会社が所有する車両（いわゆる社用車）に対して、定期的な清掃、走行エネルギの補給（燃料補給又は充電）、部品交換（タイヤ、バッテリ、各種オイルなどの交換）、車載コンピュータのソフトウェアの更新（バージョンアップなど）を提供するサービスにも適用することができる。要するに、各種の車両に対して、これら複数のメンテナンスのタイミングを知らせたり、実際に複数のメンテナンスを実施したりする機能を備えたシステムである。なお、以下に説明する実施形態は、本発明をドライバーが乗車しない無人運転車両を用いて一又は複数のユーザを目的地まで輸送する形態のサービスに適用した一例を示す。本実施形態の車両メンテナンス管理システムＳは、サーバ１と、車両２と、ユーザ端末機３とを含む。以下、各構成を説明する。
【００１１】
《サーバ１》
サーバ１は、１台もしくは複数台のコンピュータ（ＣＰＵ，ＲＯＭ，ＲＡＭなどを備えたハードウェアに、後述する機能を実現するソフトウェアをインストールしたもの）で構成され、外部からの信号入力を受け付けた上で、様々な処理を行う、プログラム可能なサーバである。サーバ１の構成方法の詳細は、特に限定されるものではなく、一般的なサーバを用いればよい。サーバ１には、車両情報データベース１０１、地図データベース１０２、車両リクエスト管理部１０３、車両計画部１０４、車両予約部１０５、利用情報取得部１０６、メンテナンス必要度推定部１０７、第１判断部１０８、第２判断部１０９、記憶部１１０及びメンテナンス指示部１１１が含まれる。これらの各部のうち、車両情報データベース１０１、地図データベース１０２及び記憶部１１０は、記憶装置により構成され、その他の車両リクエスト管理部１０３、車両計画部１０４、車両予約部１０５、利用情報取得部１０６、メンテナンス必要度推定部１０７、第１判断部１０８、第２判断部１０９及びメンテナンス指示部１１１の各機能は、サーバ１にインストールされたソフトウェアにより実現される。
【００１２】
車両情報データベース１０１は、予め既知である車種、車両の登録日その他の静的な情報に加え、車両２の車両情報送信部２３から所定時間間隔で送信される動的な車両情報を記憶するデータベースである。後述するように、車両２は複数台存在するので、所定のサービス区域内に存在する全ての車両情報がここに格納される。車両情報は、車両２の位置情報と車両向き、車速、ドアロック及びドアの開閉状態、シートベルトセンサー値、自動運転中か否かなどの各種車両状態、車両２の使用期間、車両２の使用回数、車両２の乗車距離、車両２の走行エネルギ残量（エンジン車の場合は燃料残量、電気自動車の場合は電池残量、ハイブリッド車の場合は燃料残量及び／又は電池残量）、車両２の各種部品の寿命、車両２に搭載されたコンピュータ（ＥＣＵなそ）のソフトウェア更新情報、メンテナンス毎の車両２の乗車人数の累計、車両２の使用者の特性（綺麗好きな否かなど）、車両２の走行地域、車両２の使用時の天候を含む。また、車両リクエスト受信可能か否か、清掃中その他メンテナンス中か否か、乗客の有無及び人数、輸送指示の目的地に到着したか否かなど、無人自動運転の遠隔監視に関する情報も、同じ車両のＩＤに関連付けて記憶される。
【００１３】
地図データベース１０２は、少なくとも車両２が走行可能な道路リンク情報を含んだいわゆるナビゲーション地図に加え、ユーザの乗降可能場所、給油及び／又は充電場所、車両２の待機場所の情報を含む。その他に、ユーザが歩行するルートを計算するための歩行者道路リンク情報を含んでもよい。
【００１４】
車両リクエスト管理部１０３は、ユーザ端末機３から、車両２の利用要求情報を受信し、車両計画部１０４に車両２の利用要求情報を出力する。また、車両計画部１０４から利用要求情報に対する利用要求結果情報を入力し、ユーザ端末機３に利用要求結果情報を送信する。
【００１５】
車両計画部１０４は、車両リクエスト管理部１０３から出力された車両２の利用要求情報と、車両情報データベース１０１に格納された車両情報とを用いて、車両２の配車計画情報を算出し、算出した車両２の配車計画情報を車両リクエスト管理部１０３及び車両予約部１０５に出力する。ここで、車両２の配車計画情報の算出方法について説明すると、まず車両２の利用要求情報に含まれる出発地点及び目的地点の位置情報と、地図データベース１０２に含まれる乗降場所の位置情報とを用いて、最も近い乗降場所を、それぞれ乗車場所、降車場所として決定する。次に、車両２の利用要求情報が受信可能な全ての車両２のうち、最も乗車場所に近い車両２を、割り当て車両として決定する。なお、車両２の配車計画情報の算出方法は、特に限定されず、これ以外の他の手法を用いてもよい。
【００１６】
車両予約部１０５は、車両計画部１０４から出力される車両２の配車計画情報と、車両情報データベース１０１に含まれる車両情報とを用いて、ユーザを乗せる地点までの走行ルート、ユーザを降ろす地点までの走行ルートを算出し、これにその他の無人の自動運転車両を運行する上で必要な情報を加味して、車両２のサーバ情報受信部２４に送信する。
【００１７】
利用情報取得部１０６は、ユーザの利用要求情報に対して割り当てられた車両２に関し、車両情報データベース１０１に格納された車両２の車両情報から、当該車両２の車両ＩＤに関連付けられた最後にメンテナンスを行った日時の情報（以下、最終メンテナンス日時ともいう）を取得する。ここで取得する最終メンテナンス日時については、清掃を実施した日時（車室外の洗車のみ、車室内の清掃のみ、又は車室外及び車室内の双方ともに清掃を実施した日時）、走行エネルギの補給を行った日時、部品交換（タイヤ、バッテリ、各種オイルなどの交換）を行った日時、車載コンピュータのソフトウェアの更新（バージョンアップなど）を行った日時など、一又は複数の情報を含んでもよい。最終メンテナンス日時は、車両情報データベース１０１へアクセスできる端末装置があれば、メンテナンス実施担当者が直接入力したり、メンテナンス実施担当者から情報を得た遠隔監視の担当者が入力したりする。その他にも、車両２に搭載された端末装置によってメンテナンスの実施を入力して車両情報送信部２３から車両情報データベース１０１へ記憶させてもよい。なお、本実施形態では、最終メンテナンス日時から起算して現在までの車両２のメンテナンス必要度を推定するが、最終メンテナンス日時とは異なる基準日、たとえば車両２の初期登録日から起算し、メンテナンスを実施する度にメンテナンス必要度を減じることで現在までの車両２のメンテナンス必要度を推定してもよい。
【００１８】
メンテナンス必要度推定部１０７は、車両の利用情報に基づいて車両２のメンテナンス必要度を推定する。より具体的には、利用情報取得部１０６で取得した最終メンテナンス日時から現在に至るまでの車両２の利用情報に基づいて車両２のメンテナンス必要度を推定する。ここで、車両２の利用情報の代用特性として、本実施形態では、ユーザが車両２に乗車した時間、ユーザが車両２に乗車した距離、ユーザが車両２に乗車した回数、走行エネルギ残量（燃料残量又は電池残量）、使用されている部品の寿命情報、ソフトウェア更新情報のうちの１つ又はこれらの２つ以上の組み合わせの積算値を用いる。メンテナンス必要度の推定方法の具体例は後述する。
【００１９】
第１判断部１０８は、メンテナンス必要度推定部１０７にて推定されたメンテナンス必要度について、サービス提供者が任意に設定した第１閾値を超えるか否かを判断する。そして、メンテナンス必要度推定部１０７にて推定されたメンテナンス必要度が第１閾値を超える場合には、その車両２はメンテナンスが必要であると判断し、そのメンテナンス項目を記憶部１１０に一時的に記憶する一方、メンテナンス必要度推定部１０７にて推定されたメンテナンス必要度が第１閾値を超えない場合には、その車両２はメンテナンスが必要でないと判断する。
【００２０】
第２判断部１０９は、第１判断部１０８により複数のメンテナンスのうちの一のメンテナンスに対するメンテナンス必要度が、第１閾値に達したと判断された場合に、メンテナンス必要度推定部１０７で推定された他のメンテナンスに対するメンテナンス必要度が、当該他のメンテナンスに対して設定された、第１閾値より低い第２閾値に達したか否かを判断する。そして、他のメンテナンスについて、メンテナンス必要度推定部１０７にて推定されたメンテナンス必要度が第２閾値を超える場合には、その車両２は、一のメンテナンスと共に当該他のメンテナンスも同時に実施するのが効率的であると判断し、そのメンテナンス項目を記憶部１１０に一時的に記憶する一方、他のメンテナンスについて、メンテナンス必要度推定部１０７にて推定されたメンテナンス必要度が第２閾値を超えない場合には、その車両２は、一のメンテナンスと共に当該他のメンテナンスも同時に実施するのは適当でないと判断する。
【００２１】
ここで、第１判断部１０８にて用いられる第１閾値と、第２判断部１０９で用いられる第２閾値との設定方法の一例を説明する。第２閾値は、第１閾値に対して低い閾値、換言すればメンテナンスの実施の指示が出る方向の値であればよく、サービス提供者が任意に設定することができる。たとえば、図５は、第２判断部１０９にて用いられるメンテナンス必要度の第２閾値の設定例を説明する車両のメンテナンス必要度と時間との関係を示すグラフである。図示する例では、車両２の清掃メンテナンスについて、メンテナンス必要度を車両２の乗車時間で代用しているが、上図に示すように、任意に設定した清掃メンテナンスの第１閾値Ｔ１（乗車時間）に対して、その差分がΔ時間（たとえば２０分）だけ少ない値を清掃メンテナンスの第２閾値Ｔ２（乗車時間）とする。また、下図に示すように、任意に設定した清掃メンテナンスの第１閾値Ｔ１（乗車時間）への到達率を１００％とした場合に、その到達率が９０％に達する値を清掃メンテナンスの第２閾値Ｔ２（乗車時間）としてもよい。なお、上述した具体的数値２０分及び９０％は単なる例示であって、本実施形態に係る車両メンテナンス管理システムＳの管理者等が、経験則やサービスの提供方針等に基づいて任意に設定することができる値である。
【００２２】
一つのメンテナンスに対して２つの閾値、すなわち第１閾値と第２閾値を設けるのは以下の理由による。図４Ａは、第１判断部１０８及び第２判断部１０９にて用いられるメンテナンス必要度の第１閾値及び第２閾値の一例（車両の清掃メンテナンス及び走行エネルギ補給メンテナンス）を説明する車両のメンテナンス必要度と時間との関係を示すグラフ、図４Ｂは、図４Ａの比較例を説明する車両のメンテナンス必要度と時間との関係を示すグラフである。
【００２３】
まず、図４Ｂに示すように、上図の車両２の清掃メンテナンスのメンテナンス必要度を乗車時間で推定しながら、下図の車両２の走行エネルギ補給メンテナンスのメンテナンス必要度を走行可能距離で推定している場合に、時間ｔ１において車両２の清掃メンテナンスのメンテナンス必要度が第１閾値Ｔ１に達したとする。このとき、図４Ｂの下図に示すように走行エネルギ補給メンテナンスのメンテナンス必要度は第１閾値Ｌ１に達していないと、比較例の車両メンテナンス管理システムは、車両２の清掃メンテナンスの実施のみを指示し、走行エネルギ補給メンテナンスの実施の指示は行わない。
【００２４】
しかしながら、車両２の清掃メンテナンスの実施を終了して、再び輸送サービスに供された当該車両２の走行可能距離は、既に補給メンテナンスの第１閾値Ｌ１に接近していることから、少し走行したタイミングｔ２において、走行エネルギ補給メンテナンスのメンテナンス必要度が第１閾値Ｌ１に達し、ここで再び当該車両２に対してメンテナンス、すなわち今度は走行エネルギ補給メンテナンスの実施の指示がされる。一つのメンテナンスを実施する場合には、メンテナンスを実施する場所まで車両２を走行させ、メンテナンスを終了してから配車ステーションまで走行させるが、短時間のうちに複数のメンテナンスを異なるタイミングで実施すると、メンテナンス場所まで走行して配車ステーションまで戻る時間が重複し、そのぶん無駄になるので、需要に応える機会を失ってしまう。
【００２５】
これに対して、本実施形態の車両メンテナンス管理システムＳでは、図４Ａに示すように、上図の車両２の清掃メンテナンスのメンテナンス必要度を乗車時間で推定しながら、下図の車両２の走行エネルギ補給メンテナンスのメンテナンス必要度を走行可能距離で推定している場合に、時間ｔ１において車両２の清掃メンテナンスのメンテナンス必要度が第１閾値Ｔ１に達したとする。このとき、図４Ｂの下図に示すように走行エネルギ補給メンテナンスのメンテナンス必要度は第１閾値Ｌ１に達していなくても、第１閾値Ｌ１より低い第２閾値Ｌ２に達している場合には、その車両２は、車両２の清掃メンテナンスと共に走行エネルギ補給のメンテナンスも同時に実施するのが効率的であると判断する。これにより、図４Ｂに示すように個々にメンテナンスを実施する場合に比べて、メンテナンス場所まで走行して配車ステーションまで戻る時間の重複がなくなり、そのぶん需要に応える機会の損失を抑制することができる。
【００２６】
図１に戻り、記憶部１１０は、第１判断部１０８において、メンテナンス必要度推定部１０７にて推定されたメンテナンス必要度がその第１閾値を超える場合に、そのメンテナンス項目を一時的に記憶する。また、第１判断部１０８により複数のメンテナンスのうちの一のメンテナンスに対するメンテナンス必要度が、その第１閾値に達したと判断された場合に、他のメンテナンスについて、メンテナンス必要度推定部１０７にて推定されたメンテナンス必要度が第２閾値を超えるときに、そのメンテナンス項目を一時的に記憶する。記憶部１１０に記憶されるメンテナンス項目は、車両２ごとに記憶され、２以上のメンテナンス項目が記憶される。
【００２７】
メンテナンス指示部１１１は、記憶部１１０に記憶された一又は複数のメンテナンス項目について、実施する旨をその車両２に指示又は報知する。特に限定されないが、メンテナンス指示部１１１の指示先又は報知先としては、輸送サービスの提供会社又はその担当者、メンテナンスを実施する会社又はその担当者、ロボット等が挙げられる。メンテナンス指示部１１１による指示又は報知方法は、視覚又は聴覚による認識が可能な方法、たとえばディスプレイへの表示、車両２の所定位置に設けられた表示器の点灯、音声を含む音による指示又は報知などが挙げられる。
【００２８】
なお、第１判断部１０８及び第２判断部１０９で車両２の清掃などが必要であると判断された場合に、その車両２のメンテナンスを自動的に実施してもよい。具体的には、メンテナンス指示部１１１は、地図データベース１０２を参照して現在位置からメンテナンス場所までの走行ルートを演算し、無人自動運転機能付き車両２へ当該走行ルートを送信する。車両２は、メンテナンス指示部１１１から送信された走行ルートを、サーバ情報受信部２４を介して走行制御部２５に入力し、自動運転機能を用いてメンテナンス場所まで走行して自動的に車両２のメンテナンスを実施してもよい。
【００２９】
たとえば、車両２の清掃は、車室外の清掃であれば洗車ロボットを含む自動洗車機を用いることができるほか、車室内の清掃であれば清掃ロボットを用いて自動的に清掃することができる。またはこれに代えて、自動運転機能を用いて清掃場所まで車両を走行し、所定の清掃場所に停車させることで、清掃会社の清掃担当者が当該車両２の清掃を行うようにしてもよい。また、これに代えて又はこれに加えて、車両２の清掃は、車両２のウインドウォッシャーを噴射してワイパーを作動し、フロントウィンド、リヤウィンド及び／又はヘッドランプなどを洗浄することも含まれる。
【００３０】
《車  両》
車両２は、ユーザからの利用要求（リクエスト）に応じて提供されるサービス車両であり、本実施形態では、当該サービスが展開される地域に複数台配置されているものとする。ただし、上述したとおり、自家用車や社用車など、非サービス車両を除外する趣旨ではない。車両２には、車両位置算出部２１、車両状態検出部２２、車両情報送信部２３、サーバ情報受信部２４及び走行制御部２５が含まれる。
【００３１】
車両位置算出部２１は、車両２の位置を算出し、車両情報送信部２３に出力する。車両位置算出部２１は、たとえばＧＰＳ／ＩＮＳセンサーと接続されたＥＣＵであり、ＧＰＳ／ＩＮＳセンサーから出力される緯度経度の位置情報を、一定時間（たとえば１００ｍｓｅｃ）毎に出力する。位置情報の算出方法は、特に限定されず、たとえば、地図データに基づくマップマッチングなど、位置を特定可能な他の手法を用いてもよい。
【００３２】
車両状態検出部２２は、車速、ドアロック及びドアの開閉状態、シートベルトセンサー値、自動運転中か否か、などの各種車両状態をはじめとして、車両２への利用要求情報の受信が可能か否か、清掃中か否か、乗客の有無及び人数、移動指示の目的地に到着したか否かなど、無人自動運転の遠隔監視に関する情報も検出して、車両情報送信部２３に出力する。
【００３３】
車両情報送信部２３は、たとえば４Ｇ／ＬＴＥのモバイル通信機能を備えた車載デバイスであり、ＣＡＮやＬＡＮ等で車両位置算出部２１及び車両状態検出部２２から出力される情報を、一定時間（たとえば１００ｍｓｅｃ）毎に、サーバ１の車両情報データベース１０１に送信する。
【００３４】
サーバ情報受信部２４は、たとえば４Ｇ／ＬＴＥのモバイル通信機能を備えた車載デバイスであり、サーバ１の車両予約部１０５及びメンテナンス指示部１１１から送信された、待機場所へのルート、ユーザを乗せる地点までの走行ルート、清掃場所への走行ルート等の各種走行ルートをはじめ、その他無人の自動運転車両を運行する上で必要な情報を受信する。
【００３５】
走行制御部２５は、車両２の走行駆動源（エンジン及び／又はモータ）、操舵機構、制動機構、方向指示器やワイパーを含む各種電装機器を自動制御するコントローラであり、サーバ１の車両予約部１０５及びメンテナンス指示部１１１から送信された、待機場所へのルート、ユーザを乗せる地点までの走行ルート、清掃場所への走行ルート等の各種走行ルートをはじめ、その他無人の自動運転車両を運行する上で必要な情報に基づいて、車両２の走行駆動源、操舵機構、制動機構及び各種電装機器を自動制御する。
【００３６】
《ユーザ端末機》
ユーザ端末機３は、輸送サービスを希望するユーザが利用要求を行うために使用される端末装置であり、たとえばスマートフォンなどの携帯端末装置であり、利用要求するためのアプリケーションソフトウェアを実行して、４Ｇ／ＬＴＥやＷｉＦｉ（登録商標）などの電気通信回線網を介して、サーバ１にアクセスする。なお、ユーザ端末機３は、特に限定されず、上記手段のほか、たとえばＷＥＢアプリケーションソフトウェアとして実装されたパーソナルコンピュータからインターネットを介して利用要求を行うなど、他の実装方法を用いてもよい。
【００３７】
ユーザによる入力に基づき、下記に説明する車両２の利用要求情報を車両リクエスト管理部１０３に送信する。また車両リクエスト管理部１０３から、利用要求情報に対する利用要求結果情報を受信し、ディスプレイなどを介してユーザに提示する。
【００３８】
車両リクエスト管理部１０３に送信する車両２の利用要求情報は、出発地と目的地を含み、目的地はユーザからの入力で取得し、出発地はユーザの位置情報、またはユーザからの入力で取得してもよい。その他に、経由地の指定、乗降地点の指定、乗車人数、予約時間、相乗り可否などの付加的な情報を更に含んでもよい。
【００３９】
車両リクエスト管理部１０３から送信される利用要求結果情報については、ユーザの乗車場所と降車場所、予約された車両２の現在位置、及び予約車両を識別するための情報を含み、車両予約部１０５で算出された情報に基づき、乗車場所に車両が到着する時間、乗車場所から降車場所までの移動時間、ユーザが乗車場所まで移動するための推奨徒歩ルートなどの付加情報を含んでもよい。
【００４０】
次に、図２及び図３を参照しながら具体的な処理フローを説明する。この処理フローは、所定時間間隔、又は１名のユーザの利用が終了する毎など、周期的に実行されることが好ましい。なお、以下の説明では、車両２に対する複数のメンテナンスとして車両２の清掃メンテナンスと走行エネルギ補給メンテナンスを例示するが、他の複数のメンテナンスも同じ考え方で処理することができる。また、以下の説明では、清掃メンテナンスのメンテナンス必要度の推定代用特性値として、その車両２へのユーザの乗車時間を用いた例を示し、走行エネルギ補給メンテナンスのメンテナンス必要度の推定代用特性値として、その車両２の走行可能距離を用いた例を示すが、前者についてはユーザの乗車距離やユーザの乗車回数も同じ考え方で処理することができ、後者については燃料残量又は電池容量残量も同じ考え方で処理することができる。
【００４１】
図２のステップＳ１では、利用情報取得部１０６は、車両計画部１０４で割り当てられた車両２について、車両情報データベース１０１を参照して複数のメンテナンスの最終メンテナンス日時を抽出し、ステップＳ２へ進む。本例では、車両２の定期的な清掃、走行エネルギの補給（燃料補給又は充電）、部品交換（タイヤ、バッテリ、各種オイルなどの交換）、車載コンピュータのソフトウェアの更新（バージョンアップなど）をメンテナンス項目とするため、これら全てのメンテナンスについて、当該車両２の車両ＩＤに関連付けられた最後にメンテナンスを行った日時の情報（以下、最終メンテナンス日時ともいう）を取得する。ここで取得する最終メンテナンス日時については、清掃を実施した日時（車室外の洗車のみ、車室内の清掃のみ、又は車室外及び車室内の双方ともに清掃を実施した日時）、走行エネルギの補給を行った日時、部品交換（タイヤ、バッテリ、各種オイルなどの交換）を行った日時、車載コンピュータのソフトウェアの更新（バージョンアップなど）を行った日時などである。
【００４２】
ステップＳ２では、メンテナンス必要度推定部１０７は、上述した複数のメンテナンスについて、それぞれその最終メンテナンス日時から現在までのユーザの乗車時間の合計時間等々を、メンテナンス必要度の推定代用特性値として算出し、ステップＳ３へ進む。
【００４３】
ステップＳ３では、第１判断部１０８は、上述した複数のメンテナンスのメンテナンス必要度について、サービス提供者が設定したそれぞれの第１閾値と、ステップＳ２で算出したメンテナンス必要度の推定代用特性値とを比較し、少なくとも一のメンテナンスのメンテナンス必要度の推定代用特性値の方が大きい場合は、ステップＳ４へ進み、いずれのメンテナンスのメンテナンス必要度の推定代用特性値も小さい場合は、処理を終了する。ここで、図４Ａの上図に示すように、時間ｔ１において清掃メンテナンスのメンテナンス必要度のみが第１閾値Ｔ１に達していたものとする。ステップＳ４では、第１閾値を超えたメンテナンス項目、本例では清掃メンテナンスを記憶部１１０に一時的に記憶する。なお、この時間ｔ１において、清掃メンテナンスのメンテナンス必要度以外にも、自己の第１閾値に達しているメンテナンスがあれば、記憶部１１０に記憶する。
【００４４】
ステップＳ５では、第１閾値を超えたメンテナンス項目、本例では清掃メンテナンス以外のメンテナンスのメンテナンス必要度について、それぞれの第２閾値に達しているか否かを判断し、第２閾値に達しているものがあれば記憶部１１０に記憶する。図３は、図２のステップＳ５のサブルーチンを示すフローチャートであり、図３においてｎはメンテナンスの種類ごとに付された序数を表す。上述した車両２の定期的な清掃、走行エネルギの補給、部品交換、車載コンピュータのソフトウェアの更新の各メンテナンスを行う場合において、ステップＳ３で第１閾値に達したメンテナンス項目が清掃メンテナンスであれば、当該清掃メンテナンスを除く他のメンテナンスである走行エネルギの補給、部品交換、車載コンピュータのソフトウェアの更新が、ｎ＝１〜３にそれぞれ割り当てられる。
【００４５】
ステップＳ５１及びＳ５２において、清掃メンテナンスを除く他のメンテナンスのうちｎ＝１が走行エネルギ補給メンテナンスであるとすると、ステップＳ５３において、時間ｔ１における走行エネルギ補給メンテナンスのメンテナンス必要度が第２閾値Ｌ２に達しているか否かを判断する。ここで、時間ｔ１における走行エネルギ補給メンテナンスのメンテナンス必要度が第２閾値Ｌ２に達していない場合には、ステップＳ５５を介してステップＳ５２に戻り、ｎをインクリメントすることで次のメンテナンス項目、たとえば部品交換メンテナンスのメンテナンス必要度がその第２閾値に達しているか否かを判断する。同様に、ステップＳ５５を介してステップＳ５２に戻り、ｎをインクリメントすることで次のメンテナンス項目、たとえばソフトウェア更新メンテナンスのメンテナンス必要度がその第２閾値に達しているか否かを判断する。
【００４６】
図３に示すステップＳ５１〜Ｓ５５を実行することで、図４Ａの下図に示すように、時間ｔ１における走行エネルギ補給メンテナンスのメンテナンス必要度のみが第２閾値Ｌ２に達しているとすると、ステップＳ５４にて記憶部１１０に走行エネルギ補給メンテナンスを一時的に記憶する。仮に、図３に示すステップＳ５１〜Ｓ５５を実行することで、走行エネルギ補給メンテナンス以外の、部品交換メンテナンス及び／又はソフトウェア更新メンテナンスのメンテナンス必要度がそれぞれの第２閾値に達している場合には、これらのメンテナンス項目も記憶部１１０に一時的に記憶する。
【００４７】
図２に戻り、ステップＳ６では、メンテナンス指示部１１１は、記憶部１１０に一時的に記憶された全てのメンテナンス項目を読み出し、これらのメンテナンスが必要である旨の指示又は報知が行われるとともに、これに代えて又はこれに加えて、清掃の実施が行われる。図４Ａに示す例では、清掃メンテナンスと共に走行エネルギ補給メンテナンスも同時に実施する旨の指示又は報知が行われる。この場合に、清掃メンテナンス及び走行エネルギ補給メンテナンスを通常の清掃メンテナンス及び走行エネルギ補給メンテナンスよりも相対的に短時間で行う旨の指示を伴ってもよい。相対的に短時間で行う清掃メンテナンスとしては、人目に付き易い部位に限った清掃や清掃回数を限定した簡易な清掃などが挙げられる。こうしたメンテナンスの短時間化の指示は、清掃メンテナンスに限定されず、走行エネルギの補給、部品交換、車載コンピュータのソフトウェア更新といったメンテナンスについて行ってもよい。
【００４８】
また、定期的な清掃、走行エネルギの補給、部品交換、車載コンピュータのソフトウェア更新といったメンテナンスについて、提供するサービスに応じた重要度を予め設定しておき、需要が高く及び／又は供給が低い場合には、重要度の低いメンテナンスの実施の指示を禁止してもよい。
【００４９】
また、定期的な清掃、走行エネルギの補給、部品交換、車載コンピュータのソフトウェア更新といったメンテナンスについて、メンテナンス必要度の推定代用特性値については、ユーザが車両２に乗車した時間、ユーザが車両２に乗車した距離、ユーザが車両２に乗車した回数、車両２の走行エネルギ残量、車両２の部品寿命、車両２に搭載されたコンピュータのソフトウェア更新情報、メンテナンス毎の車両２の乗車人数の累計、車両２の使用者の特性、車両２の走行地域、車両２の使用時の天候のうちの少なくとも１つを用いることができるほか、これらの２つ以上の組み合わせの積算値を用いてもよい。たとえば、ユーザが車両２に乗車した距離と、ユーザが車両２に乗車した回数とを組み合わせる場合は、図２のステップＳ２において、最終清掃日時から現在までにユーザがその車両２に乗車した距離の合計値と、最終清掃日時から現在までにユーザがその車両２に乗車した回数とを乗算した値を、メンテナンス必要度の推定代用特性値として算出する。
【００５０】
また、図２のステップＳ２においてメンテナンス必要度の推定代用特性値を算出するにあたり、メンテナンス必要度を加速あるいは減速させる係数Ｘ（以下、加速／減速係数ともいう）を用いてメンテナンス必要度の推定代用特性値を算出（補正）してもよい。図６は、図２のステップＳ２のサブルーチンを示すフローチャートである。この処理フローは、図１のメンテナンス必要度推定部１０７の他例（拡張機能）である。加速／減速係数Ｘは、最終清掃日時から現在までに、ユーザが車両２を利用した日時、ユーザが車両２を利用した日時の天気、ユーザが車両２を利用した走行地域の特性、車両２を利用したユーザの特性のうちの１つ、又はこれらの２つ以上の組み合わせた値を用いることができる。
【００５１】
ステップＳ２１では、図２のステップＳ２で抽出した、割り当てられた車両２の最終清掃日時から現在までのメンテナンス必要度（乗車時間）を取得し、ステップＳ２２へ進む。ステップＳ２２では、加速／減速係数Ｘの適用の判断が行われる。ここで、加速／減速係数Ｘの数値は、サービス提供者が任意の値に設定できるが、説明を簡便にするために、以下においては仮に設定した値で説明する。
【００５２】
たとえば、加速／減速係数Ｘとして、ユーザが車両２を利用した日時を用いる場合、昼食時間帯をＸ＝１．２としたり、年末の夕食時間をＸ＝１．５としたりする。食事時間帯に車両２を利用すると、他の時間帯の利用に比べて車室内などが汚れる可能性が高くなり、なかでも、昼食時間帯はテイクアウトによる車室内への持ち込みの可能性が高くなり、また年末や年始の夕食時間帯は、外食に車両２を利用する頻度が高くなるからである。
【００５３】
また、加速／減速係数Ｘとして、ユーザが車両２を利用した日時の天気を用いる場合、晴天時をＸ＝１．０（つまり不適用）としたり、雨天時をＸ＝１．５としたりする。取得する天気の情報は、車両２のワイパーの稼働情報等から判断することができる。雨天時に車両２を利用すると、晴天時に車両２を利用する場合に比べて車室外などが汚れる可能性が高くなったり、ユーザの服や靴によって車室内が汚れる可能性が高くなったりするからである。
【００５４】
また、加速／減速係数Ｘとして、ユーザが車両２を利用した走行地域（運送サービスの展開地域など）の特性を用いる場合、市街地をＸ＝１．０（つまり不適用）としたり、観光地をＸ＝１．２としたり、山間部又は未舗装道路をＸ＝１．５としたりする。市街地は舗装道路が多いのに対し、山間部は未舗装道路が多いので、山間部や未舗装道路を走行した場合には、市街地を走行した場合に比べて車室外などが汚れる可能性が高くなるからである。また観光地を走行した場合には、観光地で販売している飲食物を車室内で食する機会が比較的多く、市街地に比べて車室内などが汚れる可能性が高くなるからである。
【００５５】
また、加速／減速係数Ｘとして、車両２を利用したユーザの特性を用いる場合、ユーザ情報を管理している会員データベース（車両情報データベース１０１に記憶してもよい）の情報を参照し、車室内にごみを置いて帰るユーザをＸ＝１．２としたり、車室内のごみを片付けて帰るユーザをＸ＝０．８としたりする。図７は、図１の車両情報データベース１０１などに登録される会員情報の一例を示すデータシートである。会員情報としては、その会員の個人情報をはじめとして、サービス利用に必要な情報に加えて、車内カメラで撮像した映像データから、ごみの置き帰り回数やごみの持ち帰り回数を解析及び演算して記録しておき、サービス提供者の係数Ｘの算出の材料とする。
【００５６】
また、加速／減速係数Ｘとして、車両２を利用したユーザの特性を用いる場合、車両２を利用予約する本人だけではなく、同乗者の特性を考慮してもよい。たとえば、同乗者が大人ばかりの場合にはＸ＝１．０（つまり不適用）としたり、同乗者に小中学生以下などの子供が多い場合にはＸ＝１．５としたりする。小さい子供が同乗者に多いと車室内が汚れる可能性が高いからである。また、同乗者が会員データベースに登録されている場合には、その同乗者の特性を図５に示すデータシートから抽出し、利用予約する本人の特性に加えた係数Ｘとしてもよい。
【００５７】
なお、加速／減速係数Ｘとしては、最終清掃日時から現在までに、ユーザが車両２を利用した日時、ユーザが車両２を利用した日時の天気、ユーザが車両２を利用した走行地域の特性、車両２を利用したユーザの特性のうちの何れか１つを用いることができるほか、これらの２つ以上の組み合わせた値を用いることができる。たとえば、天候が雨天で走行地域が観光地のように、加速／減速係数Ｘの要素が同時に発生している場合には、各要素の加速／減速係数Ｘを乗算した値を最終的な加速／減速係数Ｘとすればよい。
【００５８】
図６に戻り、ステップＳ２２において、加速／減速係数Ｘが不適用（つまりＸ＝１．０）と判断された場合は処理を終了するが、加速／減速係数Ｘを適用すると判断された場合はステップＳ２３へ進み、適用する加速／減速係数Ｘをメンテナンス必要度の推定代用特性値に乗算したのち、図２のステップＳ３へ進む。
【００５９】
以上のとおり、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、車両２の利用情報に基づいて車両２のメンテナンス必要度を推定し、一のメンテナンスに対するメンテナンス必要度が第１閾値に達したと判断された場合に、他のメンテナンスに対するメンテナンス必要度が、当該他のメンテナンスに対して設定された、第１閾値より低い第２閾値に達したときは、一のメンテナンスの実施及び他のメンテナンスの実施を同時に指示するので、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６０】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、それぞれのメンテナンスのメンテナンス必要度に対して設定された第１閾値に対し、その差分が所定値である第２閾値を用いるので、近々にメンテナンス指示が出されるメンテナンスをより確実に特定することができ、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６１】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、それぞれのメンテナンスのメンテナンス必要度に対して設定された第１閾値に対し、その到達率が所定値である第２閾値を用いるので、近々にメンテナンス指示が出されるメンテナンスをより確実に特定することができ、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６２】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、メンテナンス必要度が第２閾値に達したと判断されたときは、車両２のメンテナンスを相対的に短時間で実施する旨を含めて指示するので、メンテナンスに要する時間が短縮され、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６３】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、メンテナンス必要度が第２閾値に達したと判断された場合であっても、予め定められたメンテナンスの重要度が相対的に低いメンテナンスについては、車両２のメンテナンスの実施の指示を禁止するので、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６４】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、利用情報取得部は、車両２の使用期間、車両２の使用回数、車両２の乗車距離、車両２の走行エネルギ残量、車両２の部品寿命、車両２に搭載されたコンピュータのソフトウェア更新情報、メンテナンス毎の車両２の乗車人数の累計、車両２の使用者の特性、車両２の走行地域、車両２の使用時の天候の少なくとも一の情報を取得するので、メンテナンス必要度の推定精度が向上し、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６５】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、最終清掃日時から現在に至るまでの車両２の利用情報に基づいて、車両２のメンテナンス必要度を推定するので、清掃のメンテナンス必要度の推定精度が向上し、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６６】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、最終走行エネルギ補給日時から現在に至るまでの車両２の利用情報に基づいて、車両２の走行エネルギ補給のメンテナンス必要度を推定するので、走行エネルギ補給のメンテナンス必要度の推定精度が向上し、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６７】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、最終部品交換日時から現在に至るまでの車両２の利用情報に基づいて、車両２の部品交換のメンテナンス必要度を推定するので、部品交換のメンテナンス必要度の推定精度が向上し、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６８】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、ソフトウェア更新情報に基づいて、ソフトウェア更新のメンテナンス必要度を推定するので、ソフトウェア更新のメンテナンス必要度の推定精度が向上し、より一層、メンテナンスに要する無駄な時間を短縮することができる。これにより、効率的なタイミングでメンテナンスを指示することができ、サービスの提供機会が損失するのを抑制することができる。
【００６９】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、メンテナンス必要度を加速又は減速させる係数Ｘを用いてメンテナンス必要度を推定するので、外部環境や車両２の使われ方も含めたメンテナンス必要度が推定される。その結果、メンテナンス必要度の推定精度がより一層向上する。
【００７０】
また、本実施形態の車両メンテナンス管理システムＳ及び車両メンテナンス管理方法によれば、メンテナンス必要度を加速又は減速させる係数Ｘは、車両２を利用した日時、車両２を利用した日時の天気、車両２を利用した走行地域の特性、車両２を利用したユーザの特性のうちの１つ又はこれらの２つ以上の組み合わせに基づいて設定するので、より具体的に加速／減速係数Ｘが設定される。その結果、メンテナンス必要度の推定精度がより一層向上する。
【符号の説明】
【００７１】
Ｓ…車両メンテナンス管理システム
１…サーバ
１０１…車両情報データベース
１０２…地図データベース
１０３…車両リクエスト管理部
１０４…車両計画部
１０５…車両予約部
１０６…利用情報取得部
１０７…メンテナンス必要度推定部
１０８…第１判断部
１０９…第２判断部
１１０…記憶部
１１１…メンテナンス指示部
２…車両
２１…車両位置算出部
２２…車両状態検出部
２３…車両情報送信部
２４…サーバ情報受信部
２５…走行制御部
３…ユーザ端末機
【図１】
2020013374.tif 000003
【図２】
2020013374.tif 000004
【図３】
2020013374.tif 000005
【図４Ａ】
2020013374.tif 000006
【図４Ｂ】
2020013374.tif 000007
【図５】
2020013374.tif 000008
【図６】
2020013374.tif 000009
【図７】
2020013374.tif 000010