特開 2024-72925 車両の出張診断提案方法および装置

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

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

(11)【公開番号】P2024072925

(43)【公開日】2024-05-29

(54)【発明の名称】車両の出張診断提案方法および装置

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20240522BHJP

【ＦＩ】

G06Q10/20

【審査請求】未請求

【請求項の数】22

【出願形態】ＯＬ

(21)【出願番号】P 2022183809

(22)【出願日】2022-11-17

(71)【出願人】

【識別番号】000003997

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

(74)【代理人】

【識別番号】100086232

【弁理士】

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

(74)【代理人】

【識別番号】100092613

【弁理士】

【氏名又は名称】富岡 潔

(72)【発明者】

【氏名】田中 康裕

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

5L049

【Ｆターム（参考）】

5L049CC15

(57)【要約】

【課題】車両の故障の予兆を検知したときに、所要時間が所定時間以内であることを条件として、ユーザに出張診断を提案し、ディーラーへの持ち込みを不要とする。
【解決手段】車両側装置において車両データから故障の予兆を検知し（ステップ１０１）、サーバ側で過去の他車の故障予兆検知結果データベースを参照して（ステップ１０３）、異常信号の組み合わせパターンの一致度が高い１つあるいは複数の部品を故障部品候補として抽出する（ステップ１０５）。故障部品候補の全てが出張診断対応部品であるか判定（ステップ１０８）した上で、出張診断で要する所要時間を算出し（ステップ１１９）、所要時間が所定時間以内であれば、ユーザに出張診断を提案する（ステップ１２０，１０９）。
【選択図】図６

【特許請求の範囲】

【請求項1】

車両の部品の故障の予兆を検知し、
この予兆に基づいて１つあるいは複数の故障部品候補を特定し、
故障部品候補について出張診断で要する所要時間を算出し、
所要時間が所定時間以内であれば、ユーザに出張診断を提案する、
車両の出張診断提案方法。

【請求項2】

さらに、
故障部品候補の各々について出張診断での対応の可否を判定し、
出張診断での対応が可能であることを条件としてユーザに出張診断を提案する、
請求項１に記載の車両の出張診断提案方法。

【請求項3】

車両の表示部もしくはユーザの携帯端末を介して出張診断の提案を行う、
請求項１に記載の車両の出張診断提案方法。

【請求項4】

算出した所要時間を、ユーザに出張診断を提案するときに併せて提示する、
請求項１に記載の車両の出張診断提案方法。

【請求項5】

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

【請求項6】

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

【請求項7】

検知した予兆の内容と診断データにおける過去の予兆の内容との一致度に基づき、一致度が比較的に高い複数の故障部品候補を抽出する、
請求項６に記載の車両の出張診断提案方法。

【請求項8】

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

【請求項9】

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

【請求項10】

複数の故障部品候補の全てが出張診断での対応が可能であることを条件としてユーザに出張診断を提案する、
請求項２に記載の車両の出張診断提案方法。

【請求項11】

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

【請求項12】

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

【請求項13】

車両の部品の故障の予兆検知を車両側で行い、
予兆情報としてサーバに送信し、
このサーバ側で、故障部品候補の特定、所要時間の算出および出張診断の提案を処理する、
請求項１に記載の車両の出張診断提案方法。

【請求項14】

算出した所要時間が所定時間を越える場合に、出張診断を受けるために必要な追加の条件を含む選択肢をユーザに提示する、
請求項１に記載の車両の出張診断提案方法。

【請求項15】

算出した所要時間が所定時間を越える場合に、所定時間以内で出張診断が完了する確率を算出し、ユーザに提示する、
請求項１に記載の車両の出張診断提案方法。

【請求項16】

算出した所要時間が所定時間を越える場合に、ディーラーへの持ち込みを提案する、
請求項１に記載の車両の出張診断提案方法。

【請求項17】

さらに、車両が修理工場まで走行可能であるかどうかを判定し、
走行可能でなければ、ディーラーへの搬送を提案する、
請求項１６に記載の車両の出張診断提案方法。

【請求項18】

上記所定時間は、出張診断についてユーザが任意に設定する上限作業時間からなる、
請求項１に記載の車両の出張診断提案方法。

【請求項19】

上記予兆の内容は、複数の異常信号を含み、
自車両について過去に検知した異常信号の履歴を記憶しておき、
この異常信号の履歴を考慮して、検知した予兆の内容と過去の予兆の内容との一致度を求める、
請求項６に記載の車両の出張診断提案方法。

【請求項20】

上記予兆の内容は、複数の異常信号を含み、
これらの複数の異常信号には予め重要度が定められており、
各信号の重要度を考慮して、検知した予兆の内容と過去の予兆の内容との一致度を求める、
請求項６に記載の車両の出張診断提案方法。

【請求項21】

上記予兆の内容は、複数の異常信号を含み、
複数の部品の各々について異常信号の特徴量が異なる場合に当該異常信号を異常分類に対する寄与度が高い異常信号と定め、
この寄与度が高い異常信号を優先して、検知した予兆の内容と過去の予兆の内容との一致度を求める、
請求項６に記載の車両の出張診断提案方法。

【請求項22】

車両の部品の故障の予兆を検知する故障予知部と、
この予兆に基づいて１つあるいは複数の故障部品候補を特定する故障部品特定部と、
故障部品候補について出張診断で要する所要時間を算出する出張診断所要時間算出部と、
所要時間が所定時間以内であれば、ユーザに出張診断を提案する出張診断提案部と、
を備えてなる、車両の出張診断提案装置。

【発明の詳細な説明】

【技術分野】

【0001】

この発明は、車両の故障診断の際にディーラーの修理工場に入庫せずに車両ユーザの自宅等で診断する出張診断をユーザに提案する方法および装置に関する。

【背景技術】

【0002】

車両に何らかの不調があったり故障の予兆を感じた場合、ユーザ（車両の保有者）は、ディーラーつまり当該車両の販売会社に車両を持ち込んで故障診断を受ける必要がある。作業員による故障診断によって修理交換が必要な部品が特定される。簡単な消耗部品の交換など故障診断の際に部品の交換や修理が可能な場合もあるが、多くの場合は、診断で特定した部品の取り寄せやスケジュール調整など修理交換の準備を要するため、診断とは別の日程で改めて車両をディーラーに入庫することになる。つまり、ユーザはディーラーに２回行く必要がある。

【0003】

特許文献１には、メンテナンスのためにユーザがディーラーに車両を入庫させる回数を低減するように、複数の部品について使用時間および走行距離を閾値と比較し、メンテナンスが既に必要な車両部品とともにメンテナンス時期が近い車両部品をユーザに報知するようにしたメンテナンス時期報知装置が開示されている。

【先行技術文献】

【特許文献】

【0004】

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

【発明の概要】

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

【0005】

一般のユーザにとって車両をディーラーに持ち込むことは、時間や手間等の点で面倒である。そのため、何らかの車両の不調を感じていても、ディーラーで診断を受けずに乗り続けてしまいやすい。

【0006】

特許文献１は、あくまでもユーザがディーラーに車両を入庫させることを前提としており、ユーザの自宅等までディーラーの作業員が出張して診断を行う出張診断という診断の形態を開示するものではない。

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

【0007】

この発明に係る車両の出張診断提案方法は、
車両の部品の故障の予兆を検知し、
この予兆に基づいて１つあるいは複数の故障部品候補を特定し、
故障部品候補について出張診断で要する所要時間を算出し、
所要時間が所定時間以内であれば、ユーザに出張診断を提案する。

【0008】

ユーザは、例えば、車両の表示部やユーザが保有する携帯端末を介して、出張診断の提案を受領する。ユーザがこの提案に同意すれば、ディーラーの作業員がユーザの自宅等の車両の保管場所に出張し、故障診断を行うこととなる。修理交換が必要な車両部品は、作業員の故障診断によって最終的に確定される。

【0009】

出張診断はユーザにとって便利であるが、診断に長時間の作業が必要な場合は、出張作業を行う作業員ならびに自宅の車庫等で作業がなされているユーザの双方にとって負担となり、出張診断は必ずしも効率のよいものではない。

【0010】

本発明では、１つあるいは複数の故障部品候補を特定した上で、その出張診断に必要な所要時間を算出し、所要時間が所定時間以内であれば出張診断を提案する。所定時間を越える場合は、基本的に出張診断の提案は行わない。

【発明の効果】

【0011】

この発明によれば、故障の予兆を検知したときに所要時間が所定時間内であることを条件としてユーザが出張診断の提案を受領するので、ユーザは安心して出張診断を受けることができ、診断のために車両をディーラーに入庫させる手間や時間を省くことができる。

【図面の簡単な説明】

【0012】

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

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

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

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

【図5】出張診断所要時間データベースの説明図。

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

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

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

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

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

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

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

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

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

【図15】故障部品候補の特定を行う処理の変形例を示すフローチャート。

【図16】ステップ２０２における故障予兆検知結果データベースの説明図。

【図17】ステップ２０３における故障予兆検知結果履歴データベースの説明図。

【図18】故障部品候補の特定を行う処理の他の変形例を示すフローチャート。

【図19】ステップ２０６における信号重要度データベースの説明図。

【図20】ステップ２０７による処理の結果を示す説明図。

【図21】故障部品候補の特定を行う処理のさらに他の変形例を示すフローチャート。

【図22】ステップ２０８における信号特徴量データベースの説明図。

【図23】ステップ２０９による処理の結果を示す説明図。

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

【0013】

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

【0014】

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

【0015】

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

【0016】

故障予知部００８においては、故障の予兆を検知したときに、図２に示すような形で故障予兆検知結果０５０のデータが生成され、これが通信部００７を介して送信される。図２に例示するように、このデータは、車両の識別番号と、予兆を検知した日時と、予兆の内容つまり異常信号の内容（図示例では、ａ，ｂ，ｃの３つの異常信号を含む）と、を含んでいる。他の付加的な情報を含んでいてもよい。

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

出張診断所要時間算出部０２５は、出張診断可否判定部０１３によって出張診断可能であると判断した場合に、出張診断所要時間データベース０２４を参照して、出張診断で要する所要時間を算出する。出張診断所要時間データベース０２４には、図５に例示するように、車両に含まれる全ての部品（出張診断可能な部品のみであってもよい）について、個々に、出張診断で要する所要時間の情報を付した多量の所要時間データ０５７が格納されている。出張診断所要時間算出部０２５は、故障部品候補として挙げられた複数の部品の所要時間を合算して出張診断で要する所要時間を求める。

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

ステップ１１８では、一致度が高い故障部品候補について出張診断所要時間データベース０２４に格納されたデータ０５７を参照し、ステップ１１９において、複数の故障部品候補全体での出張診断所要時間（合計時間）を算出する。例えば、図５に例示したデータ０５７では、プラグについては「１５分」、インジェクタについては１個当たり「３０分」であることが示されている。なお、一般に、作業に伴って発生する工賃が単位時間（例えば１５分）毎に１単位として計上されることから、出張診断所要時間データベース０２４のデータ０５７も基本的に１５分の倍数となるように定められている。

【0034】

そして、ステップ１２０において、合計の出張診断所要時間が出張診断に関して予め定められている所定時間以内であるか否かを判定する。所定時間以内の場合はステップ１０９に進み、車両の表示部００５やユーザが保有する携帯端末等を介して出張診断を提案する。出張診断の提案に際しては、算出した所要時間を併せて提示することが望ましい。フローチャートには含まれていないが、最終的に、出張診断の提案を受領したユーザが出張診断を要請するか否かを決定することとなる。所定時間は、例えば、１時間あるいは２時間、のように適当に設定される。

【0035】

一方、所定時間を超過している場合は、ステップ１１０に進み、出張診断を提案しない。なお、出張診断を提案しない場合、出張診断に不適当である旨の表示等を行ってもよく、あるいは、何も表示しないようにしてもよい。

【0036】

次に、図９，図１０を参照して、本発明の第２実施例を説明する。なお、以下では、第１実施例と異なる部分について主に説明する。第２実施例は、出張診断の所要時間に関してユーザが希望所要時間を入力できるとともに、ユーザの希望所要時間内で診断が困難な場合に追加料金等のオプションを提示してユーザに問い合わせる点で、第１実施例と異なっている。

【0037】

図９は、この発明に係る出張診断提案システムの第２実施例を示す構成説明図である。出張診断提案システムは、個々の車両が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張診断判定装置００２と、ユーザが保有する携帯端末０４０（例えばスマートフォン等）と、から構成される。

【0038】

車両側装置００１は、第１実施例と同様であり、診断装置００３と、メモリ００４と、表示部００５と、ＥＣＵ（Electronic Control Unit）００６と、通信部００７と、故障予知部００８と、を備えている。

【0039】

出張診断判定装置００２は、第１実施例と特に変わりがなく、通信部００９と、故障部品特定部０１０と、故障予兆一致度診断部０１１と、故障予兆検知結果データベース０１２と、出張診断可否判定部０１３と、出張診断対応部品情報データベース０１４と、出張診断提案部０１５と、出張診断所要時間算出部０２５と、出張診断所要時間データベース０２４と、を含んで構成される。出張診断提案部０１５では、ユーザの希望所要時間を考慮して、出張診断の提案の可否を決定する。

【0040】

携帯端末０４０は、ユーザとの間のインタフェースとなる表示・入力部０４１と、サーバつまり出張診断判定装置００２の通信部００９との間でインターネットや適当な通信網を介して情報の授受が可能な通信部０４２と、を含んで構成される。出張診断の提案を含む出張診断判定装置００２から送られた情報は、ユーザが保有するスマートフォン等からなる携帯端末０４０の表示・入力部０４１に表示される。一方、ユーザは、表示・入力部０４１を介して、出張診断についてユーザの希望所要時間を入力することができ、その時間内で出張診断が完了できる場合に、出張診断判定装置００２から表示・入力部０４１を介してユーザに出張診断が提案される。

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

ステップ１１８では、一致度が高い故障部品候補について出張診断所要時間データベース０２４に格納されたデータ０５７を参照し、ステップ１１９において、複数の故障部品候補全体の出張診断所要時間（合計時間）を算出する。

【0046】

一方、ステップ１２１において、ユーザが出張診断の希望所要時間を入力する。一つの例では、出張診断判定装置００２が携帯端末０４０を介して希望所要時間についての問い合わせをユーザに対し行い、この問い合わせにユーザが応答する形で希望所要時間が入力される。なお、基本的に、診断の所要時間はユーザが負担する料金に相関するので、この希望所要時間は、出張診断に関してユーザが許容し得る費用とも言える。

【0047】

そして、ステップ１２２において、合計の出張診断所要時間がユーザの希望所要時間以内であるか否かを判定する。希望所要時間以内の場合はステップ１０９に進み、ユーザが保有する携帯端末０４０を介して出張診断を提案する。出張診断の提案に際しては、算出した所要時間を併せて提示することが望ましい。

【0048】

これに対し、希望所要時間を超過する場合は、ステップ１２９に進み、ユーザに対し携帯端末０４０を介して追加オプションを提示する。追加オプションとしては、例えば、希望所要時間を越える結果生じる超過分の料金の提示や、逆に長時間を要することによる料金割引の提示、あるいは、希望所要時間内に診断を完了させるために作業員を増やす等による追加料金の提示、等が含まれ得る。ステップ１３０では、このように提示された追加オプションをユーザが受け入れたかどうか判定する。ユーザは、携帯端末０４０の表示・入力部０４１を介して追加オプションの可否を入力することができる。そして、ユーザが追加オプションを許可した場合は、ステップ１０９に進んで出張診断を提案し、ユーザが追加オプションを許可しない場合は、ステップ１１０に進んで出張診断の提案を行わない。

【0049】

次に、図１１，図１２を参照して、本発明の第３実施例を説明する。第３実施例は、算出した所要時間が所定時間を越える場合に、所定時間以内で出張診断が完了する確率を算出し、ユーザに提示するとともに、その上でユーザが出張診断を希望するか否かを問い合わせる点で、第２実施例と異なっている。

【0050】

図１１は、この発明に係る出張診断提案システムの第３実施例を示す構成説明図である。出張診断提案システムは、個々の車両が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張診断判定装置００２と、ユーザが保有する携帯端末０４０と、から構成される。

【0051】

車両側装置００１は、第１実施例と同様であり、診断装置００３と、メモリ００４と、表示部００５と、ＥＣＵ（Electronic Control Unit）００６と、通信部００７と、故障予知部００８と、を備えている。

【0052】

携帯端末０４０は、第２実施例と同様に、ユーザとの間のインタフェースとなる表示・入力部０４１と、サーバつまり出張診断判定装置００２の通信部００９との間で情報の授受が可能な通信部０４２と、を含んで構成される。出張診断の提案や後述の確率を含む出張診断判定装置００２から送られた情報は、ユーザが保有するスマートフォン等からなる携帯端末０４０の表示・入力部０４１に表示される。ユーザは、表示・入力部０４１を介して、出張診断についてユーザの希望所要時間を入力することができる。さらに、希望所要時間を超過する場合に、ユーザは、表示・入力部０４１を介して、後述する確率を考慮した上で出張診断を希望するかどうかを入力することができる。

【0053】

出張診断判定装置００２は、基本的には第２実施例と同様であり、通信部００９と、故障部品特定部０１０と、故障予兆一致度診断部０１１と、故障予兆検知結果データベース０１２と、出張診断可否判定部０１３と、出張診断対応部品情報データベース０１４と、出張診断提案部０１５と、出張診断所要時間算出部０２５と、出張診断所要時間データベース０２４と、を含んで構成される。そして、第３実施例では、さらに、ユーザの希望所要時間内で診断が完了する確率を算出する診断確率算出部０２６を備えている。出張診断提案部０１５では、ユーザの希望所要時間を超過する場合に、この診断確率に対し応答するユーザの出張診断の希望を考慮して、出張診断の提案の可否を決定する。

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

ステップ１１８では、一致度が高い故障部品候補について出張診断所要時間データベース０２４に格納されたデータ０５７を参照し、ステップ１１９において、複数の故障部品候補の出張診断所要時間（合計時間）を算出する。

【0059】

一方、ステップ１２１において、ユーザが出張診断の希望所要時間を入力する。一つの例では、出張診断判定装置００２が携帯端末０４０を介して希望所要時間についての問い合わせをユーザに対し行い、この問い合わせにユーザが応答する形で希望所要時間が入力される。

【0060】

そして、ステップ１２２において、合計の出張診断所要時間がユーザの希望所要時間以内であるか否かを判定する。希望所要時間以内の場合はステップ１０９に進み、ユーザが保有する携帯端末０４０を介して出張診断を提案する。出張診断の提案に際しては、算出した所要時間を併せて提示することが望ましい。

【0061】

これに対し、希望所要時間を超過する場合は、ステップ１２３に進み、ユーザの希望所要時間以内に出張診断が完了する確率を算出し、この確率をユーザの携帯端末０４０に通知する。例えば、複数の故障部品候補の所要時間の総和としてステップ１１８で算出される出張診断所要時間が希望所要時間を超過していても、故障の予兆の内容に対してある一つの故障部品候補の一致度が十分に高く、他の故障部品候補の一致度が比較的低い場合に、実際の診断作業においては、一致度の高い部品の診断のみで修理交換が必要な部品を特定し得ることがある。また、算出した出張診断所要時間が希望所要時間を僅かに越えるような場合は、実際の診断作業が希望所要時間以内に終了することもあり得る。このような種々の条件を考慮して、希望所要時間以内に出張診断が完了する確率を算出する。このような確率の提示を受けることで、ユーザは、出張診断を行うか否かの判断材料を得ることができる。

【0062】

ステップ１２４では、このように提示された確率に対して、ユーザが出張診断を希望したか否か判定する。ユーザは、携帯端末０４０の表示・入力部０４１を介して出張診断の希望を入力することができる。そして、ユーザが出張診断を希望した場合は、ステップ１０９に進んで出張診断を提案し、ユーザが積極的に出張診断を希望しない場合は、ステップ１１０に進んで出張診断の提案を行わない。

【0063】

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

【0064】

図１３は、この発明に係る出張診断提案システムの第４実施例を示す構成説明図である。出張診断提案システムは、個々の車両が有する車両側装置００１と、ディーラー等に設けられたサーバーやクラウドコンピュータからなる出張診断判定装置００２と、から構成される。なお、図示はしていないが、第２，第３実施例と同様に、ユーザが保有する携帯端末０４０を含んでいてもよい。

【0065】

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

【0066】

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

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

ステップ１１８では、一致度が高い故障部品候補について出張診断所要時間データベース０２４に格納されたデータ０５７を参照し、ステップ１１９において、複数の故障部品候補全体の出張診断所要時間（合計時間）を算出する。

【0073】

そして、ステップ１２０において、合計の出張診断所要時間が出張診断に関して予め定められている所定時間以内であるか否かを判定する。所定時間以内の場合はステップ１０９に進み、車両の表示部００５やユーザが保有する携帯端末０４０等を介して出張診断を提案する。出張診断の提案に際しては、算出した所要時間を併せて提示することが望ましい。

【0074】

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

【0075】

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

【0076】

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

【0077】

この第４実施例によれば、車両の状況等を考慮した上で、ユーザに対し、出張診断、ディーラー訪問診断、およびレッカー車での搬送、といった適切な対応が提案されることになる。

【0078】

次に、図１５は、故障部品候補の特定を行う処理の変形例を示すフローチャートである。これは、第１実施例（図６）のステップ１０３～１０５の処理に対応する。ステップ２０１では、車両側装置００１もしくは出張診断判定装置００２に含まれる故障予知部００８において車両データに基づき故障予知を行う。ここでは、図２に例示したような故障予兆検知結果０５０のデータが生成される。ステップ２０３では、図１７に例示する故障予兆検知結果履歴データベース０６１に、ステップ２０１で検知された今回の故障予兆検知結果０５０のデータを加える。つまり、今回の故障予兆検知結果０５０を記憶させる。これにより作成される故障予兆検知結果履歴データベース０６１は、自車両の故障予兆に関するデータベースである。

【0079】

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

【0080】

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

【0081】

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

【0082】

次に図１８は、故障部品候補の特定を行う処理の他の変形例を示すフローチャートである。これは、第１実施例（図６）のステップ１０３～１０５の処理に対応する。ステップ２０１では、車両側装置００１もしくは出張診断判定装置００２に含まれる故障予知部００８において車両データに基づき故障予知を行う。ここでは、図２に例示したような故障予兆検知結果０５０のデータが生成される。ステップ２０２では、故障予兆検知結果データベース０１２（図３）から他車両の故障予兆に関する情報を参照する。ステップ２０４では、自車両の故障予兆検知結果０５０と、故障予兆検知結果データベース０１２から得た他車両の故障予兆の情報と、の一致度を診断する。前述したように、一致度の診断には、複数の異常信号の組み合わせパターンを用いる。

【0083】

ステップ２０６では、異常信号の重要度情報をまとめた信号重要度データベース（信号重要度リストともいう）０６３の情報を参照し、次のステップ２０７において、異常信号の重要度情報を考慮して優先順位の順位付けをし、一致度が高い部品（故障部品候補）の絞り込みを行う。図１９は、信号重要度データベース０６３の一例を示す。また、図２０は、順位付けがなされた結果を表０６４として示した説明図である。

【0084】

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

【0085】

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

【0086】

次に図２１は、故障部品候補の特定を行う処理のさらに他の変形例を示すフローチャートである。これは、第１実施例（図６）のステップ１０３～１０５の処理に対応する。ステップ２０１では、車両側装置００１もしくは出張診断判定装置００２に含まれる故障予知部００８において車両データに基づき故障予知を行う。ここでは、図２に例示したような故障予兆検知結果０５０のデータが生成される。ステップ２０２では、故障予兆検知結果データベース０１２（図３）から他車両の故障予兆に関する情報を参照する。ステップ２０４では、自車両の故障予兆検知結果０５０と、故障予兆検知結果データベース０１２から得た他車両の故障予兆の情報と、の一致度を診断する。前述したように、一致度の診断には、複数の異常信号の組み合わせパターンを用いる。

【0087】

ステップ２０８では、異常信号の特徴量に関する情報をまとめた信号特徴量データベース０６５の情報を参照し、次のステップ２０９において、ステップ２０４において一致度が比較的高かった部品に対して優先順位付けを行う。図２２は、信号特徴量データベース０６５の一例を示す。また、図２３は、順位付けがなされた結果を表０６６として示した説明図である。

【0088】

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

【0089】

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

【0090】

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

【0091】

なお、前述した信号重要度データベース０６３や信号特徴量データベース０６５は、過去の蓄積したデータを利用することで比較的容易に構築することができる。また、部品の故障メカニズムが明らかになっていない場合においても、過去のデータから信号の重要度等を知ることができる。

【符号の説明】

【0092】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】