(57)【要約】      （修正有）【課題】故障対応の緊急性が考慮された上で、ユーザーに対して修理工場の提案を行う車両メンテナンス支援システムを提供する。【解決手段】車両の現在位置情報を取得する位置情報取得手段と、車両の登録位置情報を記憶する登録地記憶手段と、車両の故障の種別を特定する故障種別特定手段と、故障に対応するまでの猶予時間を記憶する猶予時間記憶手段と、修理工場が存在する位置情報を記憶する修理工場情報記憶手段と、前記修理工場情報記憶手段から故障に対して対応可能な修理工場を検索する検索手段と、を有し、前記故障種別特定手段によって故障種別が特定されると、前記猶予時間記憶手段に基づき特定された故障種別に対する猶予時間を求め、当該猶予時間に応じて、前記検索手段が、前記位置情報取得手段によって取得される現在位置情報をキーとして検索を行うか、又は前記登録地記憶手段に登録される登録位置情報をキーとして検索を行うか、を決定する。【選択図】図４
2010127836.tif 000002
【特許請求の範囲】
【請求項１】
車両の故障が発生したときに修理工場に係る情報を提供する車両メンテナンス支援システムであって、
車両の現在位置に係る現在位置情報を取得する位置情報取得手段と、
車両の登録位置に係る登録位置情報を記憶する登録地記憶手段と、
車両の故障の種別を特定する故障種別特定手段と、
車両故障の種別に応じた故障に対応するまでの猶予時間を記憶する猶予時間記憶手段と、修理工場が存在する位置に係る情報を記憶する修理工場情報記憶手段と、
前記修理工場情報記憶手段から故障に対して対応可能な修理工場を検索する検索手段と、を有し、
前記故障種別特定手段によって故障種別が特定されると、前記猶予時間記憶手段に基づき特定された故障種別に対する猶予時間を求め、当該猶予時間に応じて、前記検索手段が、前記位置情報取得手段によって取得される現在位置情報をキーとして検索を行うか、又は前記登録地記憶手段に登録される登録位置情報をキーとして検索を行うか、を決定することを特徴とする車両メンテナンス支援システム。
【請求項２】
前記検索手段は、前記猶予時間があるか否かを判断し、該猶予時間がないと判断した場合には、前記現在位置情報をキーとして検索を行い、前記猶予時間があると判断した場合には前記登録位置情報をキーとして検索を行うことを特徴とする請求項１に記載の車両メンテナンス支援システム。
【請求項３】
前記猶予時間は、前記故障種別特定手段によって故障種別に応じて予め決定された緊急度に応じて設定され、該緊急度が高い場合に設定された前記猶予時間は前記緊急度が低い場合に設定された前記猶予時間に比べて短く設定されていることを特徴とする請求項１又は請求項２に記載の車両のメンテナンス支援システム。
【請求項４】
前記検索手段は、前記現在位置情報をキーとして検索を行う場合、前記現在位置情報に基づいて現在位置周辺に位置する前記修理工場を検索し、前記登録位置情報をキーとして検索を行う場合、登録された登録位置情報または過去の履歴に基づいて登録地周辺に位置する前記修理工場を検索することを特徴とする請求項１乃至請求項３のいずれかに記載の車両のメンテナンス支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両で発生した故障を診断すると共に、当該診断の結果に応じて、修理工場などの情報を提供する車両メンテナンス支援システムに関する。
【背景技術】
【０００２】
従来、内燃機関や各種センサなどに関する情報を取得し、取得した情報に基づき車両の自己診断を行い、異常が発生した際には、運転者に対して異常が発生した旨を警告している。警告を受けた運転者はディーラーなどの整備工場に車両の点検もしくは修理を要望する。要望を受けた整備工場ではダイアグツールを用いて点検を行い、異常箇所に対して修理を行うこととなる。また車両が故障情報をセンターへ送信し、センターがこれを解析するシステムも提案されている。
【０００３】
例えば、特許文献１（特開２００３−２１６７５９号公報）には、通信回線を介して接続された情報端末からの要求に応じて、その情報端末のユーザに対して、情報提供装置から情報を提供する情報提供方法であって、サービス拠点の検索を要求する信号を前記情報端末から受信するのに応じて、その情報端末のユーザの所有商品を構成する複数種類の部品のうち、交換対象部品を特定する特定工程と、前記特定工程にて特定された前記交換対象部品の各サービス拠点における在庫状況と、それらサービス拠点の所在位置情報とを、前記情報提供装置に入手する情報入手工程と、前記情報入手工程にて入手した各種情報を、前記情報提供装置から前記情報端末に提供する情報提供工程と、を有することを特徴とするシステムが開示されている。
【特許文献１】特開２００３−２１６７５９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載のシステムにおいては、車両の故障が発生すると、ユーザーは現在位置に近接したサービス拠点に係る情報を入手することができるが、このようなサービス拠点が当該ユーザーにとって馴染みのあるものとは限らない、ということがある。例えば、自宅近辺に馴染みのサービス拠点が存在するにもかかわらず、自宅などから遠く離れた旅行先などで、車両故障が発生した場合には、従来技術では旅行先近辺のサービス拠点に係る情報が提供され、これを利用することとなってしまう。もちろん、車両故障に対して迅速に対応しなければならない場合には、従来技術による情報提供が役立つが、一方で車両故障の中には、必ずしも早急に対応する必要のないものもある。このように時間に余裕がある場合には、ユーザーは自宅近辺の馴染みのあるサービス拠点を利用したい、というニーズがあるが、従来技術ではその要請に答えることができない、という問題があった。
【０００５】
上記のような問題が何に起因しているのかを勘案すると、そもそも、ある車両故障が発生した場合において、当該故障に早急に対応しなければならないのか、或いは、必ずしも早急に対応する必要があるわけではないのか、をユーザーが判断することができない、ということにある。すなわち、従来技術では、ある車両故障が発生したときの時間的猶予を織り込んでおらず、システム的に問題があった。
【課題を解決するための手段】
【０００６】
上記問題点を解決するために、請求項１に係る発明は、車両の故障が発生したときに修理工場に係る情報を提供する車両メンテナンス支援システムであって、車両の現在位置に係る現在位置情報を取得する位置情報取得手段と、車両の登録位置に係る登録位置情報を
記憶する登録地記憶手段と、車両の故障の種別を特定する故障種別特定手段と、車両故障の種別に応じた故障に対応するまでの猶予時間を記憶する猶予時間記憶手段と、修理工場が存在する位置に係る情報を記憶する修理工場情報記憶手段と、前記修理工場情報記憶手段から故障に対して対応可能な修理工場を検索する検索手段と、を有し、前記故障種別特定手段によって故障種別が特定されると、前記猶予時間記憶手段に基づき特定された故障種別に対する猶予時間を求め、当該猶予時間に応じて、前記検索手段が、前記位置情報取得手段によって取得される現在位置情報をキーとして検索を行うか、又は前記登録地記憶手段に登録される登録位置情報をキーとして検索を行うか、を決定することを特徴とする。
【０００７】
また、請求項２に係る発明は、請求項１に記載の車両メンテナンス支援システムにおいて、前記検索手段は、前記猶予時間があるか否かを判断し、該猶予時間がないと判断した場合には、前記現在位置情報をキーとして検索を行い、前記猶予時間があると判断した場合には前記登録位置情報をキーとして検索を行うことを特徴とする。
【０００８】
また、請求項３に係る発明は、請求項１又は請求項２に記載の車両のメンテナンス支援システムにおいて、前記猶予時間は、前記故障種別特定手段によって故障種別に応じて予め決定された緊急度に応じて設定され、該緊急度が高い場合に設定された前記猶予時間は前記緊急度が低い場合に設定された前記猶予時間に比べて短く設定されていることを特徴とする。
【０００９】
また、請求項４に係る発明は、請求項１乃至請求項３のいずれかに記載の車両のメンテナンス支援システムにおいて、前記検索手段は、前記現在位置情報をキーとして検索を行う場合、前記現在位置情報に基づいて現在位置周辺に位置する前記修理工場を検索し、前記登録位置情報をキーとして検索を行う場合、登録された登録位置情報または過去の履歴に基づいて登録地周辺に位置する前記修理工場を検索することを特徴とする。
【発明の効果】
【００１０】
本発明の車両メンテナンス支援システムによれば、猶予時間に応じて、前記検索手段が、前記位置情報取得手段によって取得される現在位置情報をキーとして検索を行うか、又は前記登録地記憶手段に登録される登録位置情報をキーとして検索を行うか、を決定するので、故障対応の緊急性が考慮された上で、ユーザーに対して修理工場の提案を行うことが可能となる。また、ユーザーは緊急性に応じて修理工場を選択することが可能となるので、遠出をした際に発生した車両故障でも、故障対応の緊急性が低い場合などには、自宅（登録地）近辺の馴染みの修理工場を利用することが可能となる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施の形態を図面を参照しつつ説明する。図１は本発明の実施の形態に係る車両メンテナンス支援システムの概念を説明する図である。図１において１０、１０’、１０’’は車両、２０は車両管理センター、３０は車両修理工場群、２００はセンターサーバー、２１０は故障―猶予時間データベース、２２０は修理工場データベース、３００、３００’、３００’’は修理工場端末をそれぞれ示している。
【００１２】
本実施形態に係る車両メンテナンス支援システムは、故障発生を自己診断する故障診断部を有する車両１０、１０’、１０’’が、中央の車両管理センター２０に設置されているセンターサーバー２００に連絡をし、当該センターサーバー２００が各地に分散する、車両管理センター２０にあらかじめ登録された車両修理工場群３０に修理への対応の可不可の問い合わせを行う。問い合わせを行う際には、故障対応の緊急性が考慮された上で、どの地域に存在する車両修理工場群３０に問い合わせを行うかが決定される。すなわち、故障対応の緊急性に応じて、車両が現在存在する位置周辺の車両修理工場群３０に問い合
わせを行うか、或いは、自宅などの登録された位置周辺の車両修理工場群３０に問い合わせを行うか、を決定する。
【００１３】
車両管理センター２０に設置されるセンターサーバー２００は、車両１０、１０’、１０’’及び修理工場端末３００、３００’、３００’’と情報通信可能に構成されている汎用のサーバーであり、周知のものを用いることが可能である。特に、本実施形態に係る車両メンテナンス支援システムにおいては、センターサーバー２００には故障―猶予時間データベース２１０及び修理工場データベース２２０の２つのデータベースを備えている。
【００１４】
故障―猶予時間データベース２１０は、車両故障の種別に応じた故障に対応するまでの猶予時間を記憶保持するものであり、センターサーバー２００から参照可能に構成されている。車両故障は、その種別に応じて早急に対応する必要があるもの、それほど早急に対応する必要がないものがある。猶予時間とは、故障に対応するまでの余裕時間のことであり、故障対応の緊急性に関する目安となる時間である。例えば、方向指示器のランプなどの故障に対しては早急に対応しなければならないので猶予時間は短く、一方エアコンなどの故障はそれほど急いで対応する必要がないので猶予時間は長くなる。このように故障の種別に応じて、対応までの時間が異なっており、故障種別と猶予時間との関連について記憶するものが故障―猶予時間データベース２１０である。このような故障―猶予時間データベース２１０が記憶保持するデータの一例については図２に示すようなものとなる。具体的には、故障種別によってその緊急度が急いで対応する必要がある状態を表すＡ評価、緊急度がＡ評価に対して、急いで対応する必要がない状態を表すＢ評価および緊急度がＡ評価とＢ評価よりも急いで対応する必要がない状態を表すＣ評価というように故障種別に応じて段階的にその緊急度が予め決定されており、その緊急度に略対応するように猶予時間が決められている。つまり、緊急度と猶予時間の関係は、例えば、Ａ評価の場合には、猶予時間が故障発生時点から３日に以内に対応する故障種別が分類されており、Ｂ評価の場合には、猶予時間が故障発生時点から１週間以内及びＣ評価の場合には、猶予時間が故障発生時点から１ヶ月以内に設定されている。すなわち、猶予時間は、緊急度がＡ評価からＢ評価を経てＣ評価に向かうほど猶予時間が長くなるように設定される。また、これらの故障種別、緊急度および猶予時間は、故障と判断された箇所を表す項目によって予め類別されるとともに決定されている。なお、図２では、緊急度の評価と猶予時間では、それぞれＡ評価に対して故障発生時点から３日、Ｂ評価に対して故障発生時点から１週間以内等の設定がされているが、これらはＡ評価に対して故障発生時点から１日や２日、Ｂ評価に対して故障発生時点から１０日以内の設定が為されているもの(不図示)もあり、緊急度の評価と猶予時間は項目や車両の故障種別によって複数設定されており、緊急度の評価に対して一律に猶予時間が設定されているわけではない。このように予め決定しておくことで後述する猶予時間があるか否かの判断時に、緊急度と猶予時間をそれぞれ評価することによってより適切な猶予時間を運転者に提示することができるようになる。図２は本発明の実施の形態に係る車両メンテナンス支援システムで用いる故障―猶予時間データベースのデータ構造例を示す図である。
【００１５】
修理工場データベース２２０は、車両修理工場群３０に関連する情報を記憶するデータベースである。このようなデータベースとしては、例えば、車両修理工場群３０に属する各々の修理工場に係る情報―例えば、どのような故障に対応することができるか−などの任意の情報を記憶することができるが、少なくとも本実施形態の車両メンテナンス支援システムで用いるためには、各々の修理工場が存在する位置に係る情報を記憶するものである必要がある。
【００１６】
修理工場端末３００、３００’、３００’’は、車両修理工場群３０の各修理工場毎に設置される端末であり、センターサーバー２００からの問い合わせ事項に対する入力を行
ったり、修理予約に対して受付を行ったりする用途に用いられる。このような修理工場端末３００、３００’、３００’’は、通信機能を備える汎用のパーソナルコンピュータを用いることによって実現することができる。
【００１７】
次に、車両メンテナンス支援システムを搭載する車両１０に関してより詳細に説明する。図３は本発明の実施の形態に係る車両メンテナンス支援システムが搭載される車両のブロック構成の概略を示す図である。なお、本実施形態の車両メンテナンス支援システムは、自動車、ハイブリッド車、電気自動車などの車両に搭載されることを想定しているが、その他の移動手段に搭載することも可能である。図３において、１０は車両、１００は故障診断主制御部、１１０はエンジン制御部、１２０はブレーキ制御部、１３０はトランスミッション制御部、１４０はその他制御部、１５０は通信制御部、１６０は位置情報取得部、１７０は表示部・入力部をそれぞれ示している。
【００１８】
本実施形態に係る車両メンテナンス支援システムを搭載する車両１０は故障に関する自己診断機能を有するものであり、このような故障診断の中心的な制御を行うものが故障診断主制御部１００である。この故障診断主制御部１００は、エレクトロニックコントロールユニットなどで構成され、ＣＰＵとＣＰＵ上で動作するプログラムを保持するＲＯＭとＣＰＵのワークエリアであるＲＡＭなどからなる汎用の情報処理機構である。故障診断主制御部１００は、図示されている故障診断主制御部１００と接続される各構成と協働・動作する。
【００１９】
エンジン制御部１１０はこの車両のエンジンを制御するための電子回路装置である。トランスミッション制御部１３０はこの車両の変速機を制御する電子回路装置である。ブレーキ制御部１２０は車両１０の複数のブレーキ・システムを制御する電子回路装置である。このブレーキ制御部１２０は、例えばＡＢＳ（Ａｎｔｉ−ｌｏｃｋＢｒｅａｋｉｎｇ  Ｓｙｓｔｅｍ）およびＶＳＣ（Ｖｅｈｉｃｌｅ  Ｓｔａｂｉｌｉｔｙ  Ｃｏｎｔｒｏｌ）などを含む。その他制御部１４０として表示する装置は、この車両に搭載されているそれぞれの装置のコントローラであって、上記以外の装置を制御する装置である。これは例えば、エア・サスペンション・コントローラ（車高制御装置）、空調装置コントローラ、乗降扉開閉コントローラなどであり、車両１０の種類によって異なる構成となる。
【００２０】
故障診断行うための検出データを取得するために、エンジン制御部１１０、ブレーキ制御部１２０、トランスミッション制御部１３０、その他制御部１４０には、車載センサ群が設けられている。このような車載センサ群としては、エンジン回転センサ、車速センサ、エンジンスロットル開度センサ、トランスミッションギア位置センサ、ペダル操作角度センサ、ペダル操作速度センサ、エンジン水温センサ、エンジン油温センサ、外気温センサ、外気圧センサ（高度センサ）、排ガスセンサ、排気温度センサ、排気圧センサ、吸気温度センサ、吸気圧センサ、空気量センサ、その他、故障診断に必要なセンサが含まれる。
【００２１】
位置情報取得部１６０は、ＧＰＳ衛星からのＧＰＳ信号を受信して自らの位置を計算するＧＰＳ測位部を用いることによって、車両の現在位置情報を取得することができる。なお、本発明の車両メンテナンス支援システムにおいては、位置情報を取得することができれば、このようなＧＰＳ測位法によらずとも、その他の測位法を用いることができるものである。また、本発明に係る車両メンテナンス支援システムの車両１０においては、位置情報取得部１６０に自宅などの登録地をあらかじめ設定している。このような車両１０の登録位置情報を記憶することは、車載のナビゲーションシステムなどで一般的に行われていることである。また、このような登録位置情報は、運転者が等労している修理工場や店舗等の施設情報や、車両の過去の履歴等が記憶されており、登録位置情報をキーとして検索する場合にはこれらの情報から目的の対象施設が検索される。なお、現在位置情報をキ
ーとして検索する場合には、車載にナビゲーションシステム等で行われるように地図データベースから現在位置情報により周辺の施設を検索して目的の対象施設が検索されることになる。
【００２２】
通信制御部１５０は、センターサーバー２００側との通信を行うための制御部であり、適用な無線通信を用いることができる。また、表示部・入力部１７０は液晶などの表示装置とタッチパネルからなるインターフェイスデバイスであり、この表示部・入力部１７０に文字・図形情報等を表示することによって、運転者に対して視覚的に所定の情報を報知したり、表示部・入力部１７０への押下操作などによって運転者からの入力を受け付けたりすることを可能とする。
【００２３】
次に、以上のように構成される車両メンテナンス支援システムにおける処理フローについて説明する。図４は本発明の実施の形態に係る車両メンテナンス支援システムの処理フローの一例を示す図である。図４のフローにおいては、車両１０、センターサーバー２００、登録位置周辺の車両修理工場群、車両の現在位置周辺の車両修理工場群それぞれの処理の流れを示すものとなっている。
【００２４】
車両１０において、ステップＳ１０１で車載センサ群から診断を行うための各種のセンシングを行った情報を取得する。ステップＳ１０１で取得された情報に基づいて、ステップＳ１０２では故障診断を実行する。
【００２５】
次のＳ１０３では、車載センサ群から情報のうち、異常情報が発見された否かが判定される。判定の結果がＮＯであれば再びステップＳ１０１に戻り、ＹＥＳであればステップＳ１０４に進み、ステップＳ１０４で、位置情報取得部１６０から現在位置情報及び登録位置情報を取得する。ステップＳ１０５では、診断情報、現在位置情報、登録位置情報を、センターサーバー２００に向けて送信する。
【００２６】
センターサーバー２００側では、ステップＳ２０１で、診断情報、現在位置情報、登録位置情報の各情報を受信すると、続いて、診断情報に基づいてステップＳ２０２で、故障種別の特定を行う。このような特定用プログラムは、センターサーバー２００にあらかじめインストールされているものが用いられる。
【００２７】
ステップＳ２０３では、故障―猶予時間データベース２１０が参照されて、故障箇所に伴う猶予時間が取得される。ステップＳ２０４では、所定の猶予時間があるか否かが判定される。すなわち、このステップでは、特定された故障種別における緊急性が判定される。ステップＳ２０４での判定結果がＹＥＳであるとき、つまり故障対応の緊急度が低い場合には、ステップＳ２０５に進み、ステップＳ２０４での判定結果がＮＯであるとき、つまり故障対応の緊急度が高い場合には、ステップＳ２０７に進む。
【００２８】
ステップＳ２０５では、登録されている登録位置情報をキーとして修理工場の検索を行い、ステップＳ２０５で抽出された修理工場に対して、ステップＳ２０６で、車両１０の故障情報を送信する。ところで、登録されている登録位置情報をキーとして修理工場の検索を行うとは、具体的にはまずは自宅（登録地）近辺の馴染みの修理工場を抽出し、修理の馴染みの修理工場がない場合には過去の走行履歴や登録位置情報から登録地周辺の修理工場を検索するようにすることを表している。すなわち、登録位置情報をキーとして修理工場の検索を行う概念は、現在位置情報に代わる単なる位置情報ではなく、馴染みの修理工場、既に登録済の登録位置情報、過去の履歴から登録地周辺の修理工場を優先的に検索することであって登録位置情報を含めた車両の履歴に基づく検索を行うことを表している。
【００２９】
一方、ステップＳ２０７では、現在位置情報をキーとして修理工場の検索を行い、ステップＳ２０７で抽出された修理工場に対して、ステップＳ２０８で、車両１０の故障情報を送信する。
【００３０】
ところで、現在位置情報をキーとして修理工場の検索を行うとは、ＧＰＳ衛星からのＧＰＳ信号を受信して自らの位置を計算するＧＰＳ測位部を用いることによって、車両の現在位置情報を取得し、この現在位置情報に基づいてのみ検索を行う。すなわち、現在位置情報をキーとして修理工場の検索を行う概念は、データベースから位置情報のみで検索を行うものであって、登録情報を含めた車両に履歴に依存しない検索を行うことを表している。この点で登録位置情報をキーとして修理工場の検索と相違する。
【００３１】
このように、本実施形態に係る車両メンテナンス支援システムによれば、猶予時間に応じて、現在位置情報をキーとして検索を行うか、登録位置情報をキーとして検索を行うか、が決定されるので、故障対応の緊急性が考慮された上で、ユーザーに対して修理工場の提案を行うことが可能となる。また、ユーザーは緊急性に応じて修理工場を選択することが可能となるので、遠出をした際に発生した車両故障でも、故障対応の緊急性が低い場合などには、自宅（登録地）近辺の馴染みの修理工場を利用することが可能となる。
【００３２】
また、ステップＳ２０９では、車両１０側に特定された故障情報を送信する。ステップＳ１０６で、車両１０側が故障情報を受信すると、ステップＳ１０７において、表示部・入力部１７０で故障情報に係る警告表示を実行する。
【００３３】
各修理工場端末３００、３００’、３００’’では、ステップＳ３０１でセンターサーバー２００から故障情報を受信すると、ステップＳ３０２で、当該故障の修理に対応可能な日程や見積もり金額などを入力する。このステップＳ３０２ではステップＳ２０６およびステップＳ２０８で車両管理センターサーバーから送信された故障情報、すなわち、故障箇所に伴う猶予時間である猶予情報および、故障の箇所を特定するための図２にある項目、車両故障種別から修理工場での部品販売会社からの補修部品の取得日数、修理工場の予定および技術者の対応可能日を勘案して当該故障の修理に対応可能な日程や見積もり金額などを入力される。具体的には、まず当該修理の故障に必要な補修部品の取得日数を部品販売会社に問合せを行い、補修部品の取得日数を取得し、補修部品の取得日数から修理工場の予定および技術者の対応可能日を考慮しない修理可能な日時を特定する。次にその日時から修理工場の予定および技術者の対応可能日を含めた上での修理可能な日時とステップＳ３０１で受信した猶予時間を比較して修理工場として修理対応できる日時を決定するとともに、その修理の項目および車両故障種別から故障箇所に対応する基本工賃、故障修理の技術者の作業時間に要する工賃および補修部品代から最終的な見積もり金額を演算して入力する。そして、ステップＳ３０３では、日程情報や金額情報をセンターサーバー２００側に送信する。
【００３４】
ステップＳ２１０では、各修理工場端末３００、３００’、３００’’から送信された日程情報や金額情報を受信し、車両１０側に転送する。
【００３５】
車両１０側で、ステップＳ１０８において、修理対応可能日程情報・金額情報を受信すると、ステップＳ１０９で、表示部・入力部１７０にこれを表示する。車両１０のユーザーは、表示された修理対応可能日程情報・金額情報のうち、自分にとって都合のよい修理工場による提案を選択して、予約する。ステップＳ１１０では、予約情報をセンターサーバー２００側に送信する。
【００３６】
センターサーバー２００では、ステップＳ２１１で、予約情報を受信すると、当該予約を行うべき修理工場の端末装置に対してこれを転送する。
【００３７】
当該予約情報を受領したいずれかの修理工場は、ステップＳ３０４で予約情報を受信し、ステップＳ３０５でこの予約の受付処理がなされ、さらにステップＳ３０６で、受付処理が完了した旨の情報が送信される。
【００３８】
センターサーバー２００が、受付処理完了情報を、ステップＳ２１２で受信すると、これを車両１０側に転送する。
【００３９】
車両１０側では、ステップＳ１１１で、予約受付完了情報を受信し、ステップＳ１１２で、表示部・入力部１７０に表示して、ユーザーに対して報知する。
【００４０】
次に、本発明の他の実施形態について説明する。図５は本発明の他の実施形態に係る車両メンテナンス支援システムの概念を説明する図であり、図６は本発明の他の実施形態に係る車両メンテナンス支援システムが搭載される車両のブロック構成の概略を示す図である。
【００４１】
他の実施形態に係る車両メンテナンス支援システムが先の実施形態に係る車両メンテナンス支援システムと異なる点は、先の実施形態に係る車両メンテナンス支援システムでは、故障箇所の特定や猶予時間の取得をセンターサーバー２００側で行っていたのに対して、他の実施形態に係る車両メンテナンス支援システムでは、故障箇所の特定や猶予時間の取得を車両１０側で行うように設定される点である。このために、図５及び図６に示すように、他の実施形態においては、故障―猶予時間データベース１８０が車両１０側に設けられる。
【００４２】
以上のように構成される他の実施形態に係る車両メンテナンス支援システムにおける処理フローについて説明する。図７は本発明の他の実施形態に係る車両メンテナンス支援システムの処理フローの一例を示す図である。図７のフローにおいては、車両１０、センターサーバー２００、登録位置周辺の車両修理工場群、車両の現在位置周辺の車両修理工場群それぞれの処理の流れを示すものとなっている。
【００４３】
車両１０において、ステップＳ１０１で車載センサ群から診断を行うための各種のセンシングを行った情報を取得する。ステップＳ１０１で取得された情報に基づいて、ステップＳ１０２では故障診断を実行する。次のＳ１０３では、車載センサ群から情報のうち、異常情報が発見された否かが判定される。判定の結果がＮＯであれば再びステップＳ１０１に戻り、ＹＥＳであればステップＳ１０４に進む。
【００４４】
ステップＳ１０４では、故障種別の特定を行う。このような特定のためのプログラムは、故障診断主制御部１００が備えるものが用いられる。
【００４５】
また、ステップＳ１０５において、表示部・入力部１７０で特定された故障種別に係る警告表示を実行する。ステップＳ１０６では、現在位置情報及び登録位置情報を位置情報取得部１６０から取得する。次のステップＳ１０７では、故障―猶予時間データベース１８０が参照されて、故障箇所に伴う猶予時間が取得される。そして、ステップＳ１０８では、故障情報（猶予情報含む）、現在位置情報、登録位置情報を、センターサーバー２００に向けて送信する。
【００４６】
センターサーバー２００において、ステップＳ２０１で故障情報（猶予情報含む）、現在位置情報、登録位置情報を受信すると、続くステップＳ２０２では、所定の猶予時間があるか否かが判定される。すなわち、このステップでは、特定された故障種別における緊急性が判定される。例えば、本実施例では、図２の緊急度がＡ評価の場合であって設定さ
れた猶予時間が猶予なし〜３日（以内の）の場合には猶予時間がないと判断し、図２の緊急度がＢ評価の場合であって設定された猶予時間が１週間〜１ヶ月（以内の）場合およびＣ評価の場合であって設定された猶予時間が１週間〜１ヶ月の場合には猶予時間があると判断する。つまり、この所定の猶予時間があるか否かの判断は、緊急度の評価と図２に設定された猶予時間によって判断される。そして、緊急度の評価と猶予時間をともに評価することによって、緊急度の評価だけに依存することなくなるので緊急度に対応する猶予時間を運転者に適切に報知することができるようになる。ステップＳ２０２での判定結果がＹＥＳであるとき、つまり故障対応の緊急度が低い場合には、ステップＳ２０３に進み、ステップＳ２０２での判定結果がＮＯであるとき、つまり故障対応の緊急度が高い場合には、ステップＳ２０５に進む。
【００４７】
ステップＳ２０３では、登録されている登録位置情報をキーとして修理工場の検索を行い、ステップＳ２０３で抽出された修理工場に対して、ステップＳ２０４で、車両１０の故障情報を送信する。
【００４８】
一方、ステップＳ２０５では、現在位置情報をキーとして修理工場の検索を行い、ステップＳ２０５で抽出された修理工場に対して、ステップＳ２０６で、車両１０の故障情報を送信する。
【００４９】
このように、本実施形態に係る車両メンテナンス支援システムによれば、猶予時間に応じて、現在位置情報をキーとして検索を行うか、登録位置情報をキーとして検索を行うか、が決定されるので、故障対応の緊急性が考慮された上で、ユーザーに対して修理工場の提案を行うことが可能となる。また、ユーザーは緊急性に応じて修理工場を選択することが可能となるので、遠出をした際に発生した車両故障でも、故障対応の緊急性が低い場合などには、自宅（登録地）近辺の馴染みの修理工場を利用することが可能となる。
【００５０】
各修理工場端末３００、３００’、３００’’では、ステップＳ３０１でセンターサーバー２００から故障情報を受信すると、ステップＳ３０２で、当該故障の修理に対応可能な日程や見積もり金額などを入力する。そして、ステップＳ３０３では、日程情報や金額情報をセンターサーバー２００側に送信する。
【００５１】
ステップＳ２０７では、各修理工場端末３００、３００’、３００’’から送信された日程情報や金額情報を受信し、車両１０側に転送する。
【００５２】
車両１０側で、ステップＳ１０９において、修理対応可能日程情報・金額情報を受信すると、ステップＳ１１０で、表示部・入力部１７０にこれを表示する。車両１０のユーザーは、表示された修理対応可能日程情報・金額情報のうち、自分にとって都合のよい修理工場による提案を選択して、予約する。ステップＳ１１１では、予約情報をセンターサーバー２００側に送信する。
【００５３】
センターサーバー２００では、ステップＳ２０８で、予約情報を受信すると、当該予約を行うべき修理工場の端末装置に対してこれを転送する。
【００５４】
当該予約情報を受領したいずれかの修理工場は、ステップＳ３０４で予約情報を受信し、ステップＳ３０５でこの予約の受付処理がなされ、さらにステップＳ３０６で、受付処理が完了した旨の情報が送信される。
【００５５】
センターサーバー２００が、受付処理完了情報を、ステップＳ２０９で受信すると、これを車両１０側に転送する。
【００５６】
車両１０側では、ステップＳ１１２で、予約受付完了情報を受信し、ステップＳ１１３で、表示部・入力部１７０に表示して、ユーザーに対して報知する。
【００５７】
以上のような、他の実施形態の構成によれば、先の実施形態と同様の効果に加えて、センターサーバー２００側での処理負担を軽減することができる、というメリットがある。
【００５８】
次に、本発明の他の実施形態について説明する。本実施形態における車両メンテナンス支援システムの概念を説明する図としては図１と同様のものを用いることができる。本実施形態に係る車両メンテナンス支援システムが先の実施形態に係る車両メンテナンス支援システムと異なる点は、運転者のスケジュールが考慮されて、修理対応可能日程などが選ばれる点であり、これによって、運転者が予約を行いやすいというメリットを享受することができる。このために、図８に示すように、他の実施形態においては、スケジュールデータベース１９０が車両１０側に設けられる。このスケジュールデータベース１９０は、ブルートゥースなどの車両内通信システム（不図示）によって、例えば運転者が所有する携帯電話、ＰＤＡなどから自動的にスケジュールデータを収集して蓄積するように構成するのが好ましいが、運転者自身が表示部・入力部１７０によって入力するように構成してもよい。
【００５９】
次に、以上のように構成される車両メンテナンス支援システムにおける処理フローについて説明する。図９は本発明の他の実施形態に係る車両メンテナンス支援システムの処理フローの一例を示す図である。図９のフローにおいては、車両１０、センターサーバー２００、登録位置周辺の車両修理工場群、車両の現在位置周辺の車両修理工場群それぞれの処理の流れを示すものとなっている。
【００６０】
車両１０において、ステップＳ１０１で車載センサ群から診断を行うための各種のセンシングを行った情報を取得する。ステップＳ１０１で取得された情報に基づいて、ステップＳ１０２では故障診断を実行する。
【００６１】
次のＳ１０３では、車載センサ群から情報のうち、異常情報が発見された否かが判定される。判定の結果がＮＯであれば再びステップＳ１０１に戻り、ＹＥＳであればステップＳ１０４に進み、ステップＳ１０４で、位置情報取得部１６０から現在位置情報及び登録位置情報を取得する。また、ステップＳ１０４で、スケジュールデータベース１９０から車両１０の運転者（或いは、所有者）のスケジュール情報を取得する。ステップＳ１０６では、診断情報、現在位置情報、登録位置情報、スケジュール情報を、センターサーバー２００に向けて送信する。
【００６２】
センターサーバー２００側では、ステップＳ２０１で、診断情報、現在位置情報、登録位置情報、スケジュール情報の各情報を受信すると、続いて、診断情報に基づいてステップＳ２０２で、故障種別の特定を行う。このような特定用プログラムは、センターサーバー２００にあらかじめインストールされているものが用いられる。
【００６３】
ステップＳ２０３では、故障―猶予時間データベース２１０が参照されて、故障箇所に伴う猶予時間が取得される。ステップＳ２０４では、所定の猶予時間があるか否かが判定される。すなわち、このステップでは、特定された故障種別における緊急性が判定される。ステップＳ２０４での判定結果がＹＥＳであるとき、つまり故障対応の緊急度が低い場合には、ステップＳ２０５に進み、ステップＳ２０４での判定結果がＮＯであるとき、つまり故障対応の緊急度が高い場合には、ステップＳ２０７に進む。
【００６４】
ステップＳ２０５では、登録されている登録位置情報をキーとして修理工場の検索を行い、ステップＳ２０５で抽出された修理工場に対して、ステップＳ２０６で、車両１０の
故障情報、運転者のスケジュール情報を送信する。
【００６５】
一方、ステップＳ２０７では、現在位置情報をキーとして修理工場の検索を行い、ステップＳ２０７で抽出された修理工場に対して、ステップＳ２０８で、車両１０の故障情報、運転者のスケジュール情報を送信する。
【００６６】
このように、本実施形態に係る車両メンテナンス支援システムによれば、猶予時間に応じて、現在位置情報をキーとして検索を行うか、登録位置情報をキーとして検索を行うか、が決定されるので、故障対応の緊急性が考慮された上で、ユーザーに対して修理工場の提案を行うことが可能となる。また、ユーザーは緊急性に応じて修理工場を選択することが可能となるので、遠出をした際に発生した車両故障でも、故障対応の緊急性が低い場合などには、自宅（登録地）近辺の馴染みの修理工場を利用することが可能となる。
【００６７】
また、ステップＳ２０９では、車両１０側に特定された故障情報を送信する。ステップＳ１０７で、車両１０側が故障情報を受信すると、ステップＳ１０８において、表示部・入力部１７０で故障情報に係る警告表示を実行する。
【００６８】
各修理工場端末３００、３００’、３００’’では、ステップＳ３０１でセンターサーバー２００から故障情報、運転者のスケジュール情報を受信すると、ステップＳ３０２で、運転者のスケジュール情報の範囲内で当該故障の修理に対応可能な日程や見積もり金額などを入力する。そして、ステップＳ３０３では、日程情報や金額情報をセンターサーバー２００側に送信する。
【００６９】
ステップＳ２１０では、各修理工場端末３００、３００’、３００’’から送信された日程情報や金額情報を受信し、車両１０側に転送する。
【００７０】
車両１０側で、ステップＳ１０９において、修理対応可能日程情報・金額情報を受信すると、ステップＳ１１０で、表示部・入力部１７０にこれを表示する。車両１０のユーザーは、表示された修理対応可能日程情報・金額情報のうち、自分にとって都合のよい修理工場による提案を選択して、予約する。ステップＳ１１１では、予約情報をセンターサーバー２００側に送信する。
【００７１】
センターサーバー２００では、ステップＳ２１１で、予約情報を受信すると、当該予約を行うべき修理工場の端末装置に対してこれを転送する。
【００７２】
当該予約情報を受領したいずれかの修理工場は、ステップＳ３０４で予約情報を受信し、ステップＳ３０５でこの予約の受付処理がなされ、さらにステップＳ３０６で、受付処理が完了した旨の情報が送信される。
【００７３】
センターサーバー２００が、受付処理完了情報を、ステップＳ２１２で受信すると、これを車両１０側に転送する。
【００７４】
車両１０側では、ステップＳ１１２で、予約受付完了情報を受信し、ステップＳ１１２で、表示部・入力部１７０に表示して、ユーザーに対して報知する。
【００７５】
以上のような、他の実施形態の構成によれば、先の実施形態と同様の効果に加えて、運転者のスケジュールが考慮された修理対応可能日程候補が挙げられるので、運転者が予約を行いやすいというメリットを享受することができる。
【図面の簡単な説明】
【００７６】
【図１】本発明の実施の形態に係る車両メンテナンス支援システムの概念を説明する図である。
【図２】本発明の実施の形態に係る車両メンテナンス支援システムで用いる故障―猶予時間データベースのデータ構造例を示す図である。
【図３】本発明の実施の形態に係る車両メンテナンス支援システムが搭載される車両のブロック構成の概略を示す図である。
【図４】本発明の実施の形態に係る車両メンテナンス支援システムの処理フローの一例を示す図である。
【図５】本発明の他の実施形態に係る車両メンテナンス支援システムの概念を説明する図である。
【図６】本発明の他の実施形態に係る車両メンテナンス支援システムが搭載される車両のブロック構成の概略を示す図である。
【図７】本発明の他の実施形態に係る車両メンテナンス支援システムの処理フローの一例を示す図である。
【図８】本発明の他の実施形態に係る車両メンテナンス支援システムが搭載される車両のブロック構成の概略を示す図である。
【図９】本発明の他の実施形態に係る車両メンテナンス支援システムの処理フローの一例を示す図である。
【符号の説明】
【００７７】
１０、１０’、１０’’・・・車両、２０・・・車両管理センター、３０・・・車両修理工場群、１００・・・故障診断主制御部、１１０・・・エンジン制御部、１２０・・・ブレーキ制御部、１３０・・・トランスミッション制御部、１４０・・・その他制御部、１５０・・・通信制御部、１６０・・・位置情報取得部、１７０・・・表示部・入力部、１８０・・・故障―猶予時間データベース、１９０・・・スケジュールデータベース、２００・・・センターサーバー、２１０・・・故障―猶予時間データベース、２２０・・・修理工場データベース、３００、３００’、３００’’・・・修理工場端末
【図１】
2010127836.tif 000003
【図２】
2010127836.tif 000004
【図３】
2010127836.tif 000005
【図４】
2010127836.tif 000006
【図５】
2010127836.tif 000007
【図６】
2010127836.tif 000008
【図７】
2010127836.tif 000009
【図８】
2010127836.tif 000010
【図９】
2010127836.tif 000011