特開 2024-169812 車両の修理提案方法および装置

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024169812

(43)【公開日】2024-12-06

(54)【発明の名称】車両の修理提案方法および装置

(51)【国際特許分類】

   B60S 5/00 20060101AFI20241129BHJP

   G06Q 10/20 20230101ALI20241129BHJP

【ＦＩ】

B60S5/00

G06Q10/20

【審査請求】未請求

【請求項の数】19

【出願形態】ＯＬ

(21)【出願番号】P 2023086572

(22)【出願日】2023-05-26

(71)【出願人】

【識別番号】000003997

【氏名又は名称】日産自動車株式会社

(74)【代理人】

【識別番号】100086232

【弁理士】

【氏名又は名称】小林 博通

(74)【代理人】

【識別番号】100092613

【弁理士】

【氏名又は名称】富岡 潔

(72)【発明者】

【氏名】田中 康裕

【テーマコード（参考）】

3D026

5L049

【Ｆターム（参考）】

3D026BA02

3D026BA28

5L049CC15

(57)【要約】

【課題】車両の故障の予兆を検知したときに、出張修理を含む適当な修理方針の提案を行う。
【解決手段】故障予知部において車両データから故障の予兆を検知（ステップ１０１）したときに、サーバー側で過去の他車の故障予兆検知結果データベースを参照して（ステップ１０３）、異常信号の組み合わせパターンの一致度が高い１つあるいは複数の部品を故障部品候補として抽出する（ステップ１０５）。出張修理対応部品情報データベースを参照して（ステップ１０６）、故障部品候補の全てが出張修理対応部品であるか判定（ステップ１０８）し、全てが出張修理対応部品であれば、ユーザに出張修理を提案する（ステップ１０９）。
【選択図】図５

【特許請求の範囲】

【請求項1】

車両の部品の故障の予兆を検知し、
この予兆に基づいて１つあるいは複数の故障部品候補を特定し、
故障部品候補の各々について出張修理での対応の可否を判定し、
この判定に基づき、ユーザに出張修理を含む修理方針の提案を行う、
車両の修理提案方法。

【請求項2】

さらに、
車両データに基づいて車両が走行可能な状態であるか否かを診断し、
走行の可否を考慮して修理方針の提案を行う、
請求項１に記載の車両の修理提案方法。

【請求項3】

故障部品候補が出張修理での対応が可能な場合は、出張修理を提案する、
請求項１に記載の車両の修理提案方法。

【請求項4】

複数の故障部品候補の全てが出張修理での対応が可能な場合は、出張修理を提案する、
請求項１に記載の車両の修理提案方法。

【請求項5】

複数の故障部品候補の中に出張修理での対応が不可の部品が含まれており、かつ車両が走行可能な場合は、ディーラー訪問を提案する、
請求項２に記載の車両の修理提案方法。

【請求項6】

複数の故障部品候補の中に出張修理での対応が不可の部品が含まれており、かつ車両が走行不可の場合は、ディーラーへの搬送を提案する、
請求項２に記載の車両の修理提案方法。

【請求項7】

予め設定した出張修理対応部品情報に基づいて、故障部品候補の各々について出張修理での対応の可否を判定する、
請求項１に記載の車両の修理提案方法。

【請求項8】

上記出張修理対応部品情報を、実際に行った出張修理のデータを用いて更新する、
請求項７に記載の車両の修理提案方法。

【請求項9】

複数の故障部品候補の各々について当該部品が修理交換の必要な部品であることの確率を求め、
出張修理での対応可能な故障部品候補の確率が所定の閾値以上であれば、出張修理での対応不可の故障部品候補を含んでいても出張修理を提案する、
請求項４に記載の車両の修理提案方法。

【請求項10】

複数の故障部品候補を優先度順に並べ、その上位所定範囲の故障部品候補が出張修理での対応が可能なものであれば、下位に出張修理での対応不可の故障部品候補を含んでいても出張修理を提案する、
請求項４に記載の車両の修理提案方法。

【請求項11】

他の車両における過去の予兆情報と診断結果とをまとめた診断データを参照して故障部品候補の特定を行う、
請求項１に記載の車両の修理提案方法。

【請求項12】

上記診断データは、過去の予兆情報とこれに対応して修理交換した後の結果が良好であった修理交換部品との対応を含み、
検知した予兆情報と診断データにおける過去の予兆情報との一致度が高い修理交換部品を、故障部品候補として抽出する、
請求項１１に記載の車両の修理提案方法。

【請求項13】

予兆を検知したときの複数の異常信号の種類と、上記診断データにおける他車両の過去の予兆情報に含まれる異常信号の種類と、の一致度から故障部品候補を特定する、
請求項１２に記載の車両の修理提案方法。

【請求項14】

部品に対応して複数の異常信号に重要度が定められており、
各信号の重要度を考慮して、検知した予兆情報と過去の予兆情報との一致度を求める、
請求項１２に記載の車両の修理提案方法。

【請求項15】

上記重要度は、蓄積された診断データに基づいて設定される、
請求項１４に記載の車両の修理提案方法。

【請求項16】

複数の部品の各々について異常信号の特徴量が異なる場合に当該異常信号を異常分類に対する寄与度が高い異常信号と定め、
この寄与度が高い異常信号を優先して、検知した予兆情報と過去の予兆情報との一致度を求める、
請求項１２に記載の車両の修理提案方法。

【請求項17】

上記特徴量は、蓄積された診断データに基づいて設定される、
請求項１６に記載の車両の修理提案方法。

【請求項18】

車両の部品の故障の予兆検知を車両側で行い、
車両側で取得した予兆情報をサーバーに送信し、
このサーバー側で、故障部品候補の特定および修理方針の提案を行う、
請求項１に記載の車両の車両の修理提案方法。

【請求項19】

車両の部品の故障の予兆を検知する故障予知部と、
この予兆に基づいて１つあるいは複数の故障部品候補を特定する故障部品特定部と、
故障部品候補の各々について出張修理での対応の可否を判定する出張修理可否判定部と、
この判定に基づき、ユーザに出張修理を含む修理方針の提案を行う修理方針提案部と、
を備えてなる、車両の修理提案装置。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、車両の部品の故障の予兆を検知したときに、出張修理を含む適当な修理方針をユーザに提案する方法および装置に関する。

【背景技術】

【0002】

車両に何らかの不調があったり故障の予兆を感じた場合、ユーザ（車両の保有者）は、ディーラーつまり当該車両の販売会社に車両を持ち込んで点検修理を受ける必要がある。

【0003】

特許文献１には、事故により車両が損傷した際の修理の見積もりを、スマートフォンを介した損傷箇所の画像の送信およびこれに応答したサーバーからの見積もり額の受信により遠隔で行えるようにした技術が開示されている。そして、見積もり額に、車両引き取りのための出張費用を含めることが記載されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２００８－３０８０７５号公報

【発明の概要】

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

【0005】

一般のユーザにとって車両をディーラーに持ち込むことは、時間や手間等の点で面倒である。そのため、何らかの車両の不調を感じていても、ディーラーで点検を受けずに乗り続けてしまいやすい。一方、やみくもにユーザが自宅等での修理を求めたとすると、作業員の無駄な出張が増加する。

【0006】

なお、特許文献１における出張費用は、あくまでも事故車両を修理工場まで搬送するための引き取りに要する費用であり、ユーザの自宅等までディーラーの作業員が出張して修理を行う出張修理という形態を開示するものではない。

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

【0007】

この発明に係る車両の修理提案方法は、
車両の部品の故障の予兆を検知し、
この予兆に基づいて１つあるいは複数の故障部品候補を特定し、
故障部品候補の各々について出張修理での対応の可否を判定し、
この判定に基づき、ユーザに出張修理を含む修理方針の提案を行う。

【0008】

本発明では、１つあるいは複数の故障部品候補を特定した上で、出張修理での対応の可否を判定し、最終的な修理方針の提案を行う。

【発明の効果】

【0009】

この発明によれば、故障の予兆を検知したときに故障部品候補を特定しかつその出張修理での対応の可否を考慮した上でユーザが出張修理等の提案を受領するので、ユーザにとって便利であるとともに、作業員の無駄な出張を防止することができる。

【図面の簡単な説明】

【0010】

【図1】この発明に係る出張修理提案システムの第１実施例を示す構成説明図。

【図2】車両側での故障予兆検知結果のデータを表形式で示す説明図。

【図3】出張修理判定装置側の故障予兆検知結果データベースの説明図。

【図4】出張修理対応部品情報データベースの説明図。

【図5】第１実施例の処理の流れを示すフローチャート。

【図6】故障予兆情報の一致度の説明図。

【図7】一致度が高い部品のリストの例を示す説明図。

【図8】出張修理提案システムの第２実施例を示す構成説明図。

【図9】第２実施例の処理の流れを示すフローチャート。

【図10】出張修理提案システムの第３実施例を示す構成説明図。

【図11】異常信号の履歴を含む故障予兆検知結果データベースの説明図。

【図12】故障予兆履歴データベースの説明図。

【図13】第３実施例の処理の流れを示すフローチャート。

【図14】一致度が高い部品のリストの例を示す説明図。

【図15】出張修理提案システムの第４実施例を示す構成説明図。

【図16】信号重要度データベースの説明図。

【図17】第４実施例の処理の流れを示すフローチャート。

【図18】順位付けした部品のリストの例を示す説明図。

【図19】出張修理提案システムの第５実施例を示す構成説明図。

【図20】信号特徴量データベースの説明図。

【図21】第５実施例の処理の流れを示すフローチャート。

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

【0011】

以下、この発明の一実施例を図面に基づいて詳細に説明する。図１は、この発明に係る出張修理提案システムの第１実施例を示す構成説明図である。出張修理提案システムは、個々の車両（例えば車両Ａ）が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張修理判定装置００２と、から構成される。

【0012】

車両側装置００１は、車両が有するいわゆるコンピュータシステムの一部からなり、診断装置００３と、メモリ００４と、表示部００５と、ＥＣＵ（Electronic Control Unit）００６と、通信部００７と、故障予知部００８と、を備えている。診断装置００３は、車両の各部から得られる種々の信号（車両データともいう）を監視し、異常な信号を検出する。故障予知部００８は、１つあるいは複数の異常信号に基づいて何らかの部品が故障に至る予兆であることを検知し、メモリ００４に保存するとともに、通信部００７を介して出張修理判定装置００２へ送信する。車両は、いわゆるコネクテッドカーとして構成されており、通信部００７を介して例えばインターネットに常時接続されている。この通信機能を利用して車両側装置００１と出張修理判定装置００２との間で種々の情報の送受信が行われる。表示部００５は、例えば運転席の前方に設けられたディスプレイからなり、種々の情報が表示される。表示部００５は、車両を保有するユーザの携帯端末（例えばスマートフォン）であってもよい。

【0013】

なお、故障予知部００８が故障の予兆を検知したときに、出張修理判定装置００２への送信と併せて、故障の予兆があったことを表示部００５に表示するようにしてもよい。あるいは故障の予兆単独では表示せずに、後述する出張修理の提案と併せて表示するようにしてもよい。

【0014】

故障予知部００８においては、故障の予兆を検知したときに、図２に示すような形で故障予兆検知結果０５０のデータが生成され、これが通信部００７を介して送信される。図２に例示するように、このデータは、車両の識別番号と、予兆を検知した日時と、予兆の内容つまり異常信号の内容（図示例では、ａ，ｂ，ｃの３つの種類の異常信号を含む）と、を含んでいる。他の付加的な情報を含んでいてもよい。すなわち、故障予知部００８は、何らかの信号ないし情報から故障の予兆があると検知したときに、この予兆に関連した複数の異常信号を含む予兆情報を取得し、日時等と併せて図２のようなデータを生成する。なお、予兆の検知は、予兆情報に含まれる例えばａ，ｂ，ｃの異常信号そのものに基づいて予兆検知を行ってもよく、別の信号や情報が故障の予兆をしたときに予兆があるものと判断して、その時点の異常信号を取得するようにしてもよい。

【0015】

出張修理判定装置００２は、通信部００９と、故障部品特定部０１０と、故障予兆一致度診断部０１１と、故障予兆検知結果データベース０１２と、出張修理可否判定部０１３と、出張修理対応部品情報データベース０１４と、出張修理提案部０１５と、を含んで構成される。なお、これらの各部が必ずしも１つのコンピュータによって構成される必要はなく、複数台のサーバーやクラウドコンピュータによって構成することが可能である。

【0016】

通信部００９は、車両側の通信部００７との間で適当な通信網を介して通信を行うものであり、車両側で故障の予兆を検知したときは、図２に示す故障予兆検知結果０５０のデータを車両側から受領する。最終的に後述する出張修理の提案を行うときには、その旨の情報を車両側へ送信する。

【0017】

故障予兆検知結果データベース０１２には、他の車両（自車両の過去分を含んでいてもよい）における過去の予兆情報と診断結果とをまとめた多量の診断データ、例えば図３に一部を例示したような故障予兆検知結果データ０５１、が格納されている。この故障予兆検知結果データベース０１２のデータ０５１は、図３に例示するように、車両の識別番号と、予兆がどのような箇所の異常であるかという予兆検知内容と、予兆を検知した日時と、異常信号の内容（換言すれば予兆情報）と、実際に修理交換した部品名と、修理交換後の結果（つまり不具合が解消したかどうか）と、の情報を含んでいる。修理交換後の結果が良好であるということは、予兆に基づいて修理交換した部品が妥当であったことを意味している。故障予兆検知結果データベース０１２のデータ０５１には、他の付加的な情報を含んでいてもよい。例えば、予兆を検知した時点から実際に修理交換するまでの経過期間（時間ないし走行距離）、あるいは、放置したまま故障に至った場合は、故障するまでの経過期間（時間ないし走行距離）、等の情報を加えてもよい。故障予兆検知結果データベース０１２には、実際に部品の修理交換を行うたびに新たなデータが追加される。

【0018】

故障予兆一致度診断部０１１は、車両側で検知した予兆の内容と、故障予兆検知結果データベース０１２における過去のデータ０５１に含まれる予兆の内容と、の一致度を求める。例えば、故障予知部００８で得た予兆の内容が異常信号「ａ，ｂ，ｃ」の組み合わせであった場合、故障予兆検知結果データベース０１２の過去のデータ０５１の中で、異常信号「ａ，ｂ，ｃ」の組み合わせを含む組み合わせパターンを一致度の高い組み合わせパターンと判断する。図３の例では、「ａ，ｂ，ｃ」および「ａ，ｂ，ｃ，ｆ」の異常信号の組み合わせが一致度が高い一致パターンであると判断される。なお、「ａ，ｂ，ｃ」の組み合わせの方が「ａ，ｂ，ｃ，ｆ」の組み合わせよりも一致度が高いものとなる。そして、「ａ，ｂ，ｃ」を含まない（一部が不足している）組み合わせパターンや、「ａ，ｂ，ｃ」以外に複数の異常信号を含む組み合わせパターンは、一致度が低い不一致パターンとする。なお、本発明においては、必要な一致度をどの程度に設定するかは任意である。

【0019】

具体的な例を挙げると、異常信号ａ，ｂ，ｃは、例えば、それぞれ、エンジン回転速度、点火時期タイミング、空燃比、であり、常時監視しているこれらの信号（検出信号ないし内部信号）を適当なアルゴリズムの異常検出処理（例えば時系列データに対する統計学的異常検知）によって処理することで、異常であると判定されたものである。異常信号ｆは、例えば、空燃比補正係数であり得る。

【0020】

故障部品特定部０１０は、故障予兆一致度診断部０１１による車両側で検知した予兆の内容と過去のデータ０５１における予兆の内容との一致度に基づき、予兆の内容に対して一致度の高い部品の特定を行う。ここで特定された部品が、予兆に対応した故障部品候補となる。この故障部品候補には、一致度の高い複数の部品が含まれ得る。なお、過去のデータ０５１において予兆に基づいて修理交換したものの良好な結果が得られなかった部品は、予兆内容の一致度が高くでも故障部品候補から除くことが望ましい。

【0021】

出張修理可否判定部０１３は、出張修理対応部品情報データベース０１４を参照して、出張修理の可否を判断するものである。出張修理対応部品情報データベース０１４には、図４に例示するように、車両に含まれる全ての部品（主要な一部の部品であってもよい）について、個々に、出張修理での対応が可能か否かの情報を付した多量の部品情報データ０５２が格納されている。例えば、修理工場にある大掛かりな装置や特殊な機器がないと修理が困難な部品等については、出張修理が否である。出張修理可否判定部０１３は、故障部品特定部０１０が特定した故障部品候補の各々について、出張修理対応部品情報データベース０１４を参照して出張修理での対応が可能かどうかを判定し、例えば、全ての故障部品候補が出張修理での対応が可能な場合に、出張修理可能と判定する。

【0022】

なお、出張修理対応部品情報データベース０１４は、例えば、各部品についての知見（設計情報等）に基づいて予め構築することができるが、実際に出張修理を行ったとき（出張修理を試みたが完了できなかった場合を含む）に逐次更新することが望ましい。特に、仕様が新しい部品については、実際に出張修理を行ったときに、出張修理対応部品情報データベース０１４を更新して新たな情報を蓄えていくことが望ましい。これにより、出張修理で対応できる部品品種を効率良く増やしていくことができる。また、実際の出張修理に基づいてデータを更新していくことで、出張修理によって修理を完了できる確率が高くなる。

【0023】

他の例として、出張修理可否判定部０１３は、一部の故障部品候補が出張修理での対応が否であっても、出張修理可能と判断するようにしてもよい。例えば、複数の故障部品候補の各々について当該部品が修理交換の必要な部品であることの確率を求め、出張修理での対応可能な故障部品候補の確率が所定の閾値以上であれば、出張修理での対応不可の故障部品候補を含んでいても出張修理が可能とする。なお、上記の確率は、例えば、前述した予兆の内容の一致度や過去の故障予兆検知結果データ０５１に基づいて求められる。

【0024】

あるいは、複数の故障部品候補を優先度順に並べ、その上位所定範囲の故障部品候補が出張修理での対応が可能なものであれば、下位に出張修理での対応不可の故障部品候補を含んでいても出張修理が可能であるとしてもよい。例えば、優先度順に並べた中で上位３位までの故障部品候補が出張修理での対応が可能であれば、４位以下に対応不可の故障部品候補を含んでいても出張修理が可能であるとする。

【0025】

出張修理可否判定部０１３が出張修理可能であると判断した場合は、出張修理提案部０１５が車両のユーザに対し出張修理を提案する。具体的には、通信部００９，００７を介して車両側装置００１へ出張修理の提案に関する情報が送られ、車両の表示部００５やユーザが保有する携帯端末（いわゆるスマートフォン等）において、その表示（音声を含んでいてもよい）がなされる。例えば、故障の予兆があること、自宅等での出張修理を受けることができること、等の情報がユーザに伝えられる。

【0026】

図５は、第１実施例の出張修理提案システムの処理の流れを示すフローチャートである。なお、この図５のフローチャートは、車両側装置００１が行う処理と出張修理判定装置００２が行う処理とを区別せずに、全体的な処理の流れの順に各ステップを示している。

【0027】

ステップ１０１では、車両側装置００１の診断装置００３および故障予知部００８によって、車両データに基づき故障予知（予兆の検知）を行う。ここで検知した故障予知情報（故障予兆検知結果０５０）は、ステップ１０２において、車両側装置００１から出張修理判定装置００２に送信される。

【0028】

ステップ１０３では、故障予兆検知結果データベース０１２に蓄積されたデータ０５１つまり他車両の故障予兆の情報を参照する。ステップ１０４では、車両側装置００１から送られた故障予兆検知結果０５０と、故障予兆検知結果データベース０１２から得た他車両の故障予兆の情報の一致度を診断する。前述したように、一致度の診断には、複数種類の異常信号の組み合わせパターンを用いる。例えば、図６に示すように、検知した予兆の内容が異常信号「ａ，ｂ，ｃ」の組み合わせであった場合、「ａ，ｂ，ｃ」や「ａ，ｂ，ｃ，ｆ」の異常信号の組み合わせは一致度が高い一致パターンであり、「ｇ，ｆ」や「ｓ，ｔ」のように信号が異なる場合あるいは「ａ，ｂ，ｃ，ｆ，ｇ，ｈ」のように他の複数の異常信号を含む組み合わせパターンは、一致度が低い不一致パターンである。

【0029】

そして、ステップ１０５において、一致度が高い部品を絞り込み、故障部品候補とする。ここでは、複数の候補があってもよい。例えば、図７の例では、異常信号「ａ，ｂ，ｃ」の組み合わせに対し一致度が高い故障部品候補として、プラグおよびインジェクタの２つの部品が抽出されている。

【0030】

次にステップ１０６において、出張修理対応部品情報データベース０１４に格納されたデータ０５２を参照し、ステップ１０７において、故障部品候補である１つあるいは複数の部品（ステップ１０５で一致度が高いとした部品）について出張修理対応部品情報データベース０１４のデータ０５２と照合する。例えば図４に例示したデータ０５２では、プラグおよびインジェクタは出張修理対応部品となっている。ステップ１０８では、一致度が高い故障部品候補が全て出張修理対応部品であるかどうかの判定を行う。全ての故障部品候補が出張修理対応部品である場合は、ステップ１０９に進み、車両の表示部００５やユーザが保有する携帯端末等を介して出張修理を提案する。ユーザがこの提案に同意すれば、ディーラーの作業員がユーザの自宅等の車両の保管場所に出張し、修理交換を行うこととなる。

【0031】

故障部品候補の１つでも出張修理対応部品ではない場合は、ステップ１１０に進み、出張修理は提案しない。出張修理を提案しない場合、出張修理に不適当である旨の表示等を行ってもよく、あるいは、何も表示しないようにしてもよい。

【0032】

なお、出張修理可否判定部０１３について前述したように、ステップ１０８において、一部の故障部品候補が出張修理での対応が否であっても、例えば優先度等に応じて、出張修理可能と判断し、ステップ１０９で出張修理を提案するようにしてもよい。

【0033】

このように、上記実施例では、部品の故障の予兆を検知したときに、１つあるいは複数の故障部品候補を特定し、これらの故障部品候補が出張修理対応部品であることを条件として出張修理を提案する。従って、ディーラーの作業員がユーザの自宅等で行う出張修理によって修理が完了する確率が高くなり、ユーザにとって便利であるとともに、出張する作業員にとっても無駄な出張を回避することができる。

【0034】

次に、図８，図９を参照して、本発明の第２実施例を説明する。なお、以下では、第１実施例と異なる部分について主に説明する。第２実施例は、故障予知を車両側装置００１ではなくディーラー等が管理する出張修理判定装置００２において行う点、および、車両が修理工場まで走行可能な状態であるかどうかを診断して適切な提案を行うようにした点で、第１実施例と異なっている。

【0035】

第２実施例の出張修理提案システムは、図８に示すように、個々の車両が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張修理判定装置００２と、から構成される。

【0036】

車両側装置００１は、第１実施例と同様に、診断装置００３と、メモリ００４と、表示部００５と、ＥＣＵ００６と、通信部００７と、を備えている。但し、車両側装置００１は、故障予知部００８は含んでいない。

【0037】

出張修理判定装置００２は、基本的には第１実施例と同様に、通信部００９と、故障部品特定部０１０と、故障予兆一致度診断部０１１と、故障予兆検知結果データベース０１２と、出張修理可否判定部０１３と、出張修理対応部品情報データベース０１４と、出張修理提案部０１５と、を含んで構成される。そして、第２実施例では、故障予知部００８が出張修理判定装置００２の一部として構成されている。故障予知部００８は、車両側装置００１の診断装置００３から通信部００７，００９を介して送られてくる１つあるいは複数の異常信号に基づいて何らかの部品が故障に至る予兆であることを検知する。そして、この故障予知部００８において、故障の予兆を検知したときに、複数の異常信号を含む予兆情報を取得する。これにより、図２に示したような故障予兆検知結果０５０のデータが生成される。これは、基本的には第１実施例と同様のデータであり、図２に例示するように、例えば、車両の識別番号と、予兆を検知した日時と、異常信号の内容（図示例では、ａ，ｂ，ｃの３つの異常信号を含む）と、を含んでいる。他の付加的な情報を含んでいてもよい。

【0038】

第２実施例の出張修理判定装置００２は、さらに、車両側装置００１から送られてくる車両データ（異常信号を含む）に基づいて車両の状態を診断する車両状態診断部０２７を含んでいる。この実施例では、車両状態診断部０２７は、主に、車両がディーラーまで走行可能な状態であるか否かを診断する。

【0039】

図９は、第２実施例の出張修理提案システムの処理の流れを示すフローチャートである。基本的な処理の流れは第１実施例と同様であるが、最初にステップ１１２として示すように車両側装置００１から出張修理判定装置００２へ車両データを送信する。ステップ１０１では、車両側装置００１から送られてくる車両データに基づき出張修理判定装置００２側で故障予知（予兆の検知）を行う。

【0040】

ステップ１０３では、故障予兆検知結果データベース０１２に蓄積されたデータ０５１つまり他車両の故障予兆の情報を参照する。ステップ１０４では、故障予知部００８が出力した故障予兆検知結果０５０と、故障予兆検知結果データベース０１２から得た他車両の故障予兆の情報と、の一致度を診断する。前述したように、一致度の診断には、複数の異常信号の組み合わせパターンを用いる。

【0041】

そして、ステップ１０５において、一致度が高い部品を絞り込み、故障部品候補とする。ここでは、複数の候補があってもよい。

【0042】

次にステップ１０６において、出張修理対応部品情報データベース０１４に格納されたデータ０５２を参照し、ステップ１０７において、故障部品候補である複数の部品（ステップ１０５で一致度が高い部品）について出張修理対応部品情報データベース０１４のデータ０５２と照合する。ステップ１０８では、一致度が高い故障部品候補が全て出張修理対応部品であるかどうかの判定を行う。全ての故障部品候補が出張修理対応部品である場合は、ステップ１０９に進み、車両の表示部００５やユーザが保有する携帯端末等を介して出張修理を提案する。

【0043】

一方、故障部品候補の１つでも出張修理対応部品ではない場合は、ステップ１１７に進み、車両が走行可能な状態であるか否かを診断する。走行可能な状態であれば、ステップ１１０に進み、出張修理は提案しない。さらにステップ１１１に進み、車両の表示部００５やユーザが保有する携帯端末０４０等を介して、ディーラーにユーザが車両を持ち込んで修理を行う（ディーラー訪問修理）ことを提案する。

【0044】

ステップ１１７において車両が走行可能な状態ではないと判定した場合は、ステップ１１８へ進み、レッカー車でディーラーまで車両を搬送して修理を受けることを、車両の表示部００５やユーザが保有する携帯端末０４０等を介して提案する。この場合、ユーザが提案を受け入れれば、ディーラーがレッカー車の手配等を行うこととなる。

【0045】

なお、ステップ１１７における走行可否の判断には、車両の状態のほかに、ユーザの都合や意向をユーザに問い合わせて、これを考慮するようにしてもよい。

【0046】

この第２実施例によれば、車両の状況等を考慮した上で、ユーザに対し、出張修理、ディーラー訪問修理、およびレッカー車での搬送、といった適切な対応が提案されることになる。また、第２実施例によれば、車両側に故障予知部００８が不要であるので、既存の車両を含むより多くの車両に対して本発明の適用が可能となる。

【0047】

次に、図１０～図１４を参照して、本発明の第３実施例を説明する。第３実施例は、自車両の過去の故障の予兆の履歴を考慮して故障部品候補の特定を行う点において第１、第２実施例と異なっている。

【0048】

第３実施例の出張修理提案システムは、図１０に示すように、個々の車両が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張修理判定装置００２と、から構成される。

【0049】

車両側装置００１は、第２実施例と同様に、診断装置００３と、メモリ００４と、表示部００５と、ＥＣＵ００６と、通信部００７と、を備えている。

【0050】

出張修理判定装置００２は、基本的には第２実施例と同様に、故障予知部００８と、通信部００９と、故障部品特定部０１０と、故障予兆一致度診断部０１１と、故障予兆検知結果データベース０１２と、出張修理可否判定部０１３と、出張修理対応部品情報データベース０１４と、出張修理提案部０１５と、を含んで構成される。そして、第３実施例では、さらに、故障予知部００８が検出した故障予兆の情報（異常信号の情報）を取得する検出情報取得部０１６と、この自車両の故障予兆の情報を蓄積する故障予兆履歴データベース０１７と、を備えている。

【0051】

図１２は、故障予兆履歴データベース０１７に蓄えられている故障予兆履歴の一例を示しており、自車両についての故障予知の日時とそのときに検出された異常信号とを含むデータ０６１が格納されている。

【0052】

同様に、第３実施例における故障予兆検知結果データベース０１２には、図１１に例示するように、各車両について過去の何回かの異常信号の履歴をも含む故障予兆検知結果データ０６２が蓄積されている。

【0053】

図１３は、第３実施例の出張修理提案システムの処理の流れを示すフローチャートである。基本的な処理の流れは第２実施例と同様であり、最初にステップ１１２において車両側装置００１から出張修理判定装置００２へ車両データを送信する。ステップ１０１では、車両側装置００１から送られてきた車両データに基づき出張修理判定装置００２側で故障予知（予兆の検知）を行う。ここでは、図２に例示したような故障予兆検知結果０５０のデータが生成される。ステップ１１３では、図１２に例示した故障予兆履歴データベース０１７ののデータ０６１に、ステップ１０１で検知された今回の故障予兆検知結果０５０のデータを加える。つまり、今回の故障予兆検知結果０５０を記憶させる。これにより作成される故障予兆履歴データベース０１７は、自車両の故障予兆に関するデータベースである。

【0054】

ステップ１０３では、図１１に例示した過去の履歴を含む故障予兆検知結果データ０６２から他車両の故障予兆に関する情報を参照する。この実施例の故障予兆検知結果データ０６２は、前述したように、基本的には第１実施例の故障予兆検知結果データベース０１２のデータ０５１（図３）に相当するものであるが、各車両について過去の何回かの異常信号の履歴も含まれている。

【0055】

次のステップ１１４では、故障予兆検知結果データ０６２の故障予兆情報と、自車両に関する故障予兆履歴データベース０１７のデータ０６１における故障予兆履歴と、の一致度を診断する。この一致度診断では、過去の履歴を含めた異常信号の組み合わせパターンを用いる。例えば、自車両の故障予兆履歴データ０６１における異常信号の組み合わせパターンが、１回目が「ａ，ｂ，ｃ」、２回目が「ａ，ｂ」、３回目が「ａ，ｂ，ｃ」（図１２参照）であった場合、他車の故障予兆検知結果データ０６２における異常信号の履歴を含む組み合わせパターンの中で、「ａ，ｂ，ｃ」の組み合わせパターンと「ａ，ｂ」の組み合わせパターンを、一致パターンとして判断する。一方、「ａ，ｂ，ｃ，ｆ」のようにａ、ｂ、ｃ以外の信号が含まれている組み合わせパターンや、ａ、ｂが含まれていない組み合わせパターンは不一致パターンとする。図１１の例では、太実線で囲んだ部分が一致パターンとなる。

【0056】

そして、ステップ１０５において、一致度が高い部品を絞り込み、故障部品候補とする。ここでは、複数の候補があってもよい。例えば、図１４に例示したリスト０５３の例では、過去の履歴を考慮した結果、一致度が高い故障部品候補として、プラグが抽出されている。

【0057】

次にステップ１０６において、出張修理対応部品情報データベース０１４に格納されたデータ０５２を参照し、ステップ１０７において、故障部品候補である１つあるいは複数の部品（ステップ１０５で一致度が高いとした部品）について出張修理対応部品情報データベース０１４のデータ０５２と照合する。例えば図４に例示したデータ０５２では、候補となったプラグは出張修理対応部品となっている。ステップ１０８では、一致度が高い故障部品候補が全て出張修理対応部品であるかどうかの判定を行う。全ての故障部品候補が出張修理対応部品である場合は、ステップ１０９に進み、出張修理を提案する。故障部品候補の１つでも出張修理対応部品ではない場合は、ステップ１１０に進み、出張修理は提案しない。

【0058】

このように第３実施例では故障予兆の履歴を考慮して故障部品候補の特定を行うので、より高い精度で故障部品候補を抽出でき、出張修理が完了する確率が高くなる。

【0059】

次に、図１５～図１８を参照して、本発明の第４実施例を説明する。第４実施例は、部品毎に異常信号の重要度を定めておき、この重要度を考慮して予兆情報の一致度を求める点で第１、第２実施例と異なっている。

【0060】

第４実施例の出張修理提案システムは、図１５に示すように、個々の車両が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張修理判定装置００２と、から構成される。

【0061】

車両側装置００１は、第２実施例と同様に、診断装置００３と、メモリ００４と、表示部００５と、ＥＣＵ００６と、通信部００７と、を備えている。

【0062】

出張修理判定装置００２は、基本的には第２実施例と同様に、故障予知部００８と、通信部００９と、故障部品特定部０１０と、故障予兆一致度診断部０１１と、故障予兆検知結果データベース０１２と、出張修理可否判定部０１３と、出張修理対応部品情報データベース０１４と、出張修理提案部０１５と、を含んで構成される。そして、第４実施例では、さらに、各部品について異常信号の重要度の序列を定める信号重要度序列部０１８と、この信号重要度の情報を蓄積した信号重要度データベース０１９と、を備えている。信号重要度データベース０１９には、例えば、図１６に例示したように、各部品の異常信号パターンと各異常信号の重要度とをまとめた信号重要度リスト０６３のデータが格納されている。信号重要度は、例えば、各部品についての知見（設計情報や試験結果等）に基づいて予め設定することができる。あるいは、故障予兆検知結果データベース０１２に順次蓄えられていく多量の故障予兆検知結果データ０５１（図３参照）から異常信号の優先度つまり重要度を求めるようにしてもよい。部品の故障メカニズムが明らかになっていない場合においても、過去のデータから信号の重要度を知ることができる。

【0063】

図１７は、第４実施例の出張修理提案システムの処理の流れを示すフローチャートである。基本的な処理の流れは第２実施例と同様であり、最初にステップ１１２において車両側装置００１から出張修理判定装置００２へ車両データを送信する。ステップ１０１では、車両側装置００１から送られてきた車両データに基づき出張修理判定装置００２側で故障予知（予兆の検知）を行う。ここでは、図２に例示したような故障予兆検知結果０５０のデータが生成される。

【0064】

ステップ１０３では、故障予兆検知結果データベース０１２のデータ０５１（図３）から他車両の故障予兆に関する情報を参照する。ステップ１０４では、自車両の故障予兆検知結果０５０と、故障予兆検知結果データベース０１２から得た他車両の故障予兆の情報と、の一致度を診断する。前述したように、一致度の診断には、複数の異常信号の組み合わせパターンを用いる。

【0065】

次にステップ１１１において、異常信号の重要度情報をまとめた信号重要度データベース０１９の情報（信号重要度リスト０６３）を参照し、次のステップ１１５において、異常信号の重要度情報を考慮して優先順位の順位付けをし、一致度が高い部品（故障部品候補）の絞り込みを行う。

【0066】

図１６の例では、信号重要度リスト０６３に、例えば、予兆検知内容がプラグの場合、異常信号の組み合わせパターンとして「ａ，ｂ，ｃ」と「ａ，ｂ」とがあり、異常信号の重要度は「ａ，ｂ＞ｃ」と記録されている。つまり、信号ｃの重要度は低い。一方、予兆検知内容がインジェクタの場合、異常信号の組み合わせパターンとして「ａ，ｂ，ｃ，ｆ」と「ａ，ｂ，ｆ」とがあり、異度信号の重要度は「ａ，ｆ＞ｂ＞ｃ」と記録されている。

【0067】

従って、この例では、検知された故障予兆の異常信号の組み合わせが「ａ，ｂ，ｃ」である場合、インジェクタに関して重要度が高い信号である信号ｆが含まれていないことから、故障部品候補の絞り込みに際して、プラグに比較してインジェクタとの一致度は低い、ものとする。

【0068】

これにより、図１８のリスト０５３に例示するように、例えば、プラグが第１位、インジェクタが第２位と、順位付けを伴って故障部品候補が抽出される。

【0069】

次にステップ１０６において、出張修理対応部品情報データベース０１４に格納されたデータ０５２を参照し、ステップ１０７において、故障部品候補である１つあるいは複数の部品（ステップ１１５で一致度が高いとした部品）について出張修理対応部品情報データベース０１４のデータ０５２と照合する。例えば図４に例示したデータ０５２では、候補となったプラグおよびインジェクタは出張修理対応部品となっている。ステップ１０８では、一致度が高い故障部品候補が全て出張修理対応部品であるかどうかの判定を行う。全ての故障部品候補が出張修理対応部品である場合は、ステップ１０９に進み、出張修理を提案する。故障部品候補の１つでも出張修理対応部品ではない場合は、ステップ１１０に進み、出張修理は提案しない。

【0070】

このように第４実施例では異常信号の重要度を考慮して故障部品候補の特定を行うので、より高い精度で特定を行うことができるとともに、複数の故障部品候補の順位付けが容易である。

【0071】

次に、図１９～図２１を参照して、本発明の第５実施例を説明する。第５実施例は、各部品の異常信号についてその特徴量に関する情報を考慮して予兆情報の一致度を求める点で第１、第２実施例と異なっている。

【0072】

第５実施例の出張修理提案システムは、図１９に示すように、個々の車両が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張修理判定装置００２と、から構成される。

【0073】

車両側装置００１は、第２実施例と同様に、診断装置００３と、メモリ００４と、表示部００５と、ＥＣＵ００６と、通信部００７と、を備えている。

【0074】

出張修理判定装置００２は、基本的には第２実施例と同様に、故障予知部００８と、通信部００９と、故障部品特定部０１０と、故障予兆一致度診断部０１１と、故障予兆検知結果データベース０１２と、出張修理可否判定部０１３と、出張修理対応部品情報データベース０１４と、出張修理提案部０１５と、を含んで構成される。そして、第５実施例では、さらに、各部品について異常信号の特徴量が何であるか診断する信号特徴量診断部０２０と、この信号特徴量の情報を蓄積した信号特徴量データベース０２１と、を備えている。信号特徴量データベース０２０には、例えば、図２０に例示したように、各部品の異常信号とこの異常信号の特徴量とをまとめた信号特徴量リスト０６５のデータが格納されている。信号特徴量リスト０６５は、例えば、各部品についての知見（設計情報や試験結果等）に基づいて予め作成することができる。あるいは、故障予兆検知結果データベース０１２に順次蓄えられていく多量の故障予兆検知結果データ０５１（図３参照）から異常信号とその特徴量を求めるようにしてもよい。

【0075】

図２１は、第５実施例の出張修理提案システムの処理の流れを示すフローチャートである。基本的な処理の流れは第２実施例と同様であり、最初にステップ１１２において車両側装置００１から出張修理判定装置００２へ車両データを送信する。ステップ１０１では、車両側装置００１から送られてきた車両データに基づき出張修理判定装置００２側で故障予知（予兆の検知）を行う。ここでは、図２に例示したような故障予兆検知結果０５０のデータが生成される。

【0076】

ステップ１０３では、故障予兆検知結果データベース０１２のデータ０５１（図３）から他車両の故障予兆に関する情報を参照する。ステップ１０４では、自車両の故障予兆検知結果０５０と、故障予兆検知結果データベース０１２から得た他車両の故障予兆の情報と、の一致度を診断する。前述したように、一致度の診断には、複数の異常信号の組み合わせパターンを用いる。

【0077】

次にステップ１２０において、異常信号の特徴量に関する情報をまとめた信号特徴量データベース０２０の情報（信号特徴量リスト０６５）を参照し、次のステップ１１６において、ステップ１０４において一致度が比較的高かった部品に対して優先順位付けを行う。

【0078】

図２０の例では、信号特徴量リスト０６５に、例えば、予兆検知内容がプラグの場合、異常信号として、ａ、ｂ、ｃがあり、信号ａの特徴量は１０分間のデータの尖度、信号ｂの特徴量は１０分間のデータの分散値、信号ｃの特徴量は１分間のデータの差分値、である旨が記録されている。

【0079】

一方、予兆検知内容がインジェクタの場合、異常信号として、ａ、ｂ、ｃ、ｆがあり、信号ａの特徴量は１０分間のデータの尖度、信号ｂの特徴量は１０分間のデータの分散値、信号ｃの特徴量は１分間のデータの平均値、信号ｆの特徴量は１０分間のデータの分散値、である旨が記録されている。

【0080】

従って、例えば、検知された故障予兆の異常信号ｃの特徴量が、プラグに関しては１分間のデータの差分値、インジェクターに関しては１分間のデータの平均値、であって互いに異なるため、異常信号ｃに着目することで、より高精度に一致度を判定することができる。つまり、異常を検出した信号の中で異常分類への寄与度が高い信号の種類を用いて一致度を診断することで、故障部品候補の特定の精度が高くなる。

【0081】

次にステップ１０６において、出張修理対応部品情報データベース０１４に格納されたデータ０５２を参照し、ステップ１０７において、故障部品候補である１つあるいは複数の部品（ステップ１１６で一致度が高いとした部品）について出張修理対応部品情報データベース０１４のデータ０５２と照合する。ステップ１０８では、一致度が高い故障部品候補が全て出張修理対応部品であるかどうかの判定を行う。全ての故障部品候補が出張修理対応部品である場合は、ステップ１０９に進み、出張修理を提案する。故障部品候補の１つでも出張修理対応部品ではない場合は、ステップ１１０に進み、出張修理は提案しない。

【符号の説明】

【0082】

００１…車両側装置
００２…出張修理判定装置
００３…診断装置
００５…表示部
００７…通信部
００８…故障予知部
００９…通信部
０１０…故障部品特定部
０１１…故障予兆一致度診断部
０１２…故障予兆検知結果データベース
０１３…出張修理可否判定部
０１４…出張修理対応部品情報データベース
０１５…出張修理提案部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】