JP5206126B2 - 車両用故障診断装置、故障診断方法 - Google Patents

Description

本発明は、車両に異常が生じた際に故障の原因を診断する車両用故障診断装置等に関し、特に、車両で故障原因を絞り込む車両用故障診断装置及び故障診断方法に関する。

車両に不具合が検出された場合、不具合の原因を解析するため不具合が検出された時の車載装置の状態を示す車両情報や故障コード等がＥＣＵ（electronic control unit）などに記憶されるようになっている。警告ランプの点灯等に気づいた運転者がサービスセンタに車両を持ち込むと、サービスマンにより診断ツールなどを用いて車両情報が読み出され、サービスマンによる点検により不具合の原因が特定される。

また、診断ツールによる診断時には、車載されたアクチュエータに対し強制駆動信号を送信し、該アクチュエータの動作を確認するといった手法（アクティブテスト）が取られるようになっており、車載装置の状態を確認できるようになっている。この点について、サービスマンによる診断ツールの誤操作により、故障診断の停止や意図しない別の診断機能の作動が指示されることを防止すべく、所定のボタンとの組み合わせで診断ツールが操作された場合にのみアクティブテストを許可する車両用故障診断装置が提案されている（例えば、特許文献１参照。）。
特開２００６−１９４８２５号公報

しかしながら、車両の電子化に伴い、車両部品は複雑かつ高度に進化しており、診断ツールによる故障コードの読み出しやアクティブテストによる強制駆動では、故障診断が完了するまでに時間がかかるようになってきている。故障診断にかかる時間は、サービスマンの熟練度等にも起因するため、長時間化だけでなく、サービスマン毎に故障診断にかかる時間のバラツキをもたらすものともなっている。かかる状況は、サービスセンタのコスト増をもたらし、また、故障診断の間、車両を使用できない車両のオーナも不便であることから、故障診断にかかる時間を短縮することが望まれる。

本発明は、上記課題に鑑み、サービスセンタにおける故障診断の時間を短縮可能な車両用故障診断装置及び故障診断方法を提供することを目的とする。

上記課題に鑑み、本発明は、車両に異常が生じた際に、異常の原因の可能性のある複数の車両部品のリストを生成する部品リスト生成手段と、前記リストを記憶するリスト記憶手段と、前記リストの車両部品のうち、アクティブテストを実行する車両部品を決定するテスト必要部品決定手段と、車両が車両システム起動状態で、車両部品毎にアクティブテストを実行する実行環境条件が満たされたか否かを判定するテスト実行判定手段と、実行環境条件が満たされると判定された場合、当該車両部品のアクティブテストを実行するアクティブテスト実行手段と、アクティブテストの実行の結果、故障していないと判定された車両部品を前記リストから消去するリスト消去手段と、前記リストの車両部品のうち、前記テスト必要部品決定手段がアクティブテストを実行しないと決定した車両部品に対し、車両が車両システム起動状態で、車両部品毎に故障診断のための走行状況条件が満たされたか否かを判定する条件成立判定手段と、前記走行状況条件が満たされると判定された場合、当該車両部品が故障しているか否かを判定する故障判定手段と、を有し、前記リスト消去手段は、前記故障判定手段が故障していないと判定した車両部品を前記リストから消去する、を有することを特徴とする車両用故障診断装置を提供する。

本発明によれば、車両においてアクティブテストを実行することで、故障の可能性のある車両部品を絞り込み、サービスセンタにおける故障診断の時間を短縮できる。

サービスセンタにおける故障診断の時間を短縮可能な車両用故障診断装置及び故障診断方法を提供することができる。

図１は車両用故障診断装置１００の概略を説明する図の一例を示す。車両５０のセンサやアクチュエータ、スイッチ等（以下、車両部品という）に異常が生じると、車両用故障診断装置１００は例えばメータパネルなどに異常に対応する警告ランプを点灯させる。なお、軽微な故障であれば警告ランプを点灯させない場合もある。異常の発生した車両部品を監視するＥＣＵ（electronic control unit）には、ＤＴＣ（Diagnosis Trouble Code）及びフリーズフレームデータ（以下、ＦＦＤという）等が記憶される。

ＤＴＣが記憶されると、本実施形態の車両用故障診断装置１００は、以下の手順で故障箇所を絞り込む。
Ｉ．故障が考えられる車両部品を全てリストアップする。
II．リストアップされた車両部品のうち、アクティブテストが必要な車両部品に対し車両上でアクティブテストを実行し、故障診断する。
III．リストアップされた車両部品のうち、アクティブテストにより故障でないと診断された車両部品をリストから消去する。

したがって、車両５０の乗員（例えば運転者）が警告ランプの点灯に気づき、サービスセンタに車両５０を持ち込んだ時点では、故障の可能性のある車両部品が絞り込まれているので、サービスマンによる故障診断の時間を短縮することができる。

なお、本実施形態では、例えばＤＴＣが記憶されることを異常の検出といい、異常の原因を確定する作業を故障診断という。異常が検出された場合に、実際に車両部品が故障しているか否かは問わない。また、異常の原因とは、破損、劣化等、故障した車両部品、及び／又は、センサ等により検出される検出信号の異常など故障により検出される症状をいう。

また、車両上でアクティブテストを実行するとは、走行可能な状態であることが多い。このため、上記手順は、ガソリンエンジンやディーゼルエンジンのように内燃機関を動力とする車両ではイグニッションがオンの状態で実行され、ハイブリッド車や電気自動車のように駆動力の一部又は全てをモーターとする車両では車両システム起動状態（少なくとも通電されアクセルペダルの操作により走行可能な状態）で実行される。

図２は、車両用故障診断装置１００のブロック図の一例を示す。車両用故障診断装置１００は故障診断ＥＣＵ（Electronic Control Unit）２０により制御され、故障診断ＥＣＵ２０にはＣＡＮ（Controller Area Network）やＬＩＮ（Local Interconnect Network）等の車載ＬＡＮを介して、ＥＣＵ１１Ａ〜１１Ｃ（以下、区別しない場合ＥＣＵ１１という）が接続されている。ＥＣＵ１１Ａ〜１１Ｃには、それぞれアクチュエータ１２ａ〜１２ｃ（以下、区別しない場合、アクチュエータ１２という）、センサ１３ａ〜１３ｂ（以下、区別しない場合、センサ１３という）、及び、スイッチ１４ａ〜１４ｃ（以下、区別しない場合、スイッチ１４という）が接続される。なお、各ＥＣＵ１１に接続されるアクチュエータ１２等は１つでなく複数の場合もある。

各ＥＣＵ１１にはこれらセンサ１３、スイッチ１４から検出信号が入力され、各ＥＣＵ１１は時分割多重通信により検出信号を相互に通信して取得し、アクチュエータ１２に制御信号を供給して駆動することで、所望の制御を実行している（以下、検出信号及び制御情報を区別することなく車両情報という場合がある）。そして、各ＥＣＵ１１が、アクチュエータ１２、センサ１３、又はスイッチ１４の無応答や車両情報の異常値に基づき異常を検出した場合、異常が生じた車両部品に接続されたＥＣＵ１１がＤＴＣ及びＦＦＤを記憶する。

故障診断ＥＣＵ２０は、車両５０で異常が生じた場合に故障診断するＥＣＵであって、ナビ等の処理能力の高いＥＣＵで兼用してもよいし、いずれかのＥＣＵ１１が兼用してもよい。図３は、故障診断ＥＣＵ２０の機能ブロック図の一例を示す。故障診断ＥＣＵ２０は、ＣＰＵ、ＲＡＭ、ＲＯＭ、入出力インターフェイス、ＡＳＩＣ（Application Specific Integrated Circuit）、コンピュータ間通信部及びメモリ等を備え、ＣＰＵがプログラムを実行するか又はＡＳＩＣ等のハードウェアにより、部品リスト生成部２１、ＡＣＶテスト必要部品決定部２２、ＡＣＶテスト実行判定部２３、ＡＣＶテスト実行部２４、故障判定部２６及び部品リスト消去部２７、の各機能を実装する。また、例えば、フラッシュメモリやハードディスクドライブ、ＲＡＭなどのメモリには、車両部品登録ＤＢ３１、ＡＣＶテスト車両部品ＤＢ３２、ＡＣＶテスト実行環境ＤＢ３３、故障診断走行状況ＤＢ３４、及び、部品リスト３５が記憶されている。

故障診断ＥＣＵ２０は、ＥＣＵ１１が異常を検出した場合に、例えばＤＴＣ及びＦＦＤをＥＣＵ１１から取得して記憶したり、そのＤＴＣをサーバ（解析センタ）に送信する。サーバは例えばデータマイニングなどの手法で異常と故障の関係を解析する。なお、故障診断ＥＣＵ２０は、所定のサイクル時間毎に各ＥＣＵ１１から車両情報を受信し、走行中、古い物から順次上書き保存を繰り返す。異常が検出された時の車両情報は上書きを禁止して、サービスセンタで故障解析に利用される。

ところで、サービスセンタでは、アクチュエータ１２、センサ１３、スイッチ１４と通信して、異常を解析するためにＤＴＣを読み出す診断ツールが用いられる。診断ツールは、サービスマンの操作に応じて各種コマンドをＥＣＵ１１に送信して、アクチュエータ１２を強制駆動するアクティブテストを車両５０に対し実行することができるようになっている。アクティブテストは、公道を一般的な車両操作で走行している状況では生じ得ない又は極めて生じにくい（以下、単に「生じにくい」という）状態を車両部品にもたらすテストである。例えば、コマンドによりアクチュエータ（燃料噴射弁、モータ、ソレノイドバルブ等）１２を強制駆動させ、そのときのエンジン回転数、車輪回転速等の変化を診断ツールで受信し、サービスマン又は診断ツールのプログラムが各種アクチュエータ１２の正常・異常を判断する。本実施形態の車両用故障診断装置１００はこのアクティブテストを、車両５０をサービスセンタに持ち込むことなく実行する。

〔ＤＴＣと車両部品〕
ＤＴＣは異常の種類毎に予め定められているため、ＤＴＣにより、エンスト、燃料系異常、失火、エンジン冷却水温異常、Ｏ２センサ不良、アイドリング不良、バッテリー過放電、等の異常の内容が推定されるようになっている。ＤＴＣと異常の内容とは車両５０のメーカによりサービスセンタ等に公開されている。なお、本実施形態ではＤＴＣと車両部品とを対応づけるが、異常の検出をＤＴＣにより管理する必要はなく、車両部品との対応付けが容易な記号や番号をＤＴＣとは独立に設けたり、又は、系統を表す文字列（例えば、ブレーキ）をＤＴＣの代わりに採用してもよい。

これらの異常の内容、例えばエンストであれば、エンストの原因は複数考えられ（例えば、ガス欠、ＮＥ（クランクアングル）センサ異常、エアフロー不足等）、従来は、サービスマンが可能性のある車両部品を点検して、異常の原因を確定していた。本実施例では、このＤＴＣに異常の原因として考えられる車両部品を対応づけて車両部品登録ＤＢ３１に記憶しておく。

図４（ａ）は、車両部品登録ＤＢ３１に記憶されたＤＴＣと車両部品の関係の一例を示す。例えば、ＤＴＣがエンストを表す場合、エンストがガス欠による場合は残燃料センサが異常の原因に考えられ、ＮＥセンサ異常による場合はＮＥセンサが異常の原因に考えられ、エアフロー不足による場合はエアフローセンサが異常の原因に考えられる。また、ＤＴＣが燃料系異常を表す場合、燃料系異常が燃料圧による場合は燃料圧センサやレギュレータポンプが異常の原因に考えられ、インジェクタの噴射量による場合はインジェクタが異常の原因に考えられ、燃調による場合はエアフローセンサやＯ２センサが異常の原因に考えられる。また、ＤＴＣが失火を表す場合、失火が燃料の過大・過小による場合はインジェクタが異常の原因に考えられ、点火系による場合はイグナイタや点火タイミングを計るＮＥセンサが異常の原因に考えられ、燃料の旋回流による場合はスワールコントロールバルブ（以下、ＳＷＣＶという）が異常の原因に考えられる。

部品リスト生成部２１は、ＤＴＣに対応づけられた車両部品を車両部品登録ＤＢ３１から読み出し、車両部品を一覧にした部品リスト３５を生成する。部品リスト３５は故障診断ＥＣＵ２０のメモリに記憶され、サービスセンタにおいて診断ツール等により読み出すことができる。本実施形態では、部品リスト３５にリストアップされた車両部品に対しアクティブテスト等を実行する。

〔アクティブテスト実行の必要性の判定〕
アクティブテストは、車両５０に生じにくい状況を強制的に生じさせるものであるため、部品リスト３５にリストアップされた車両部品のうち、故障診断のためにアクティブテストが必要な（アクティブテストを実行することが好ましい車両部品を含む）車両部品と、必要でない車両部品とがある。車両用故障診断装置１００にとってアクティブテストが必要な車両部品は予め既知である。

ところで、アクティブテストが必要な車両部品であっても、走行中にアクティブテストを実行することが好ましくない車両部品がある。例えば、車両部品がスロットルバルブアクチュエータとするとスロットル開度を全開にするテスト、車両部品が車速センサであるとすると最高車速で走行するテスト、がアクティブテストとなることがある。このような、アクティブテストはアイドル状態であってもイグニッションがオンの状態で実行することは好ましくないので、アクティブテストが必要であってもアクティブテストするべきでない。

これに対し、例えば、ＳＷＣＶであれば、走行中でもアクティブテストが可能な実行環境がある。そこで、車両用故障診断装置１００は、予めアクティブテストが必要であってかつ走行中にアクティブテストが可能な車両部品をＡＣＶテスト車両部品ＤＢ３２に記憶しておく。

図４（ｂ）はＡＣＶテスト車両部品ＤＢ３２に記憶された車両部品の一例を示す。ＡＣＶテスト必要部品決定部２２は、部品リスト３５にリストアップされた車両部品が、ＡＣＶテスト車両部品ＤＢ３２に登録されているか否かに基づき、アクティブテストする車両部品を決定する。

〔アクティブテストの実行〕
アクティブテストする車両部品に対してはアクティブテストすればよいが、車両５０の走行中、常にアクティブテスト可能であることは少なく、車両部品毎にアクティブテストしてよい実行環境が存在する。例えば、ＳＷＣＶであれば、アイドリング状態であればアクティブテストが可能である。このようなアクティブテストが可能な実行環境は車両部品毎に決まっており、車両部品毎にかかる実行環境が得られたことを検出するための条件が、ＡＣＶテスト実行環境ＤＢ３３に記憶されている。

図４（ｃ）は、車両部品毎に実行環境等を登録したＡＣＶテスト実行環境ＤＢ３３の一例を示す。例えば、ＳＷＣＶの場合、アイドリング状態でアクティブテストが可能なので、実行環境条件として、「車速＝ゼロ、シフトポジション ＝ ＰｏｒＮ」と登録されている。

ＡＣＶテスト実行判定部２３は、走行中、ＡＣＶテスト実行環境ＤＢ３３を参照しながら、車両部品毎にアクティブテストが可能な実行環境か否かを判定し、アクティブテストが可能な実行環境となったらその車両部品をＡＣＶテスト実行部２４に通知する。

また、ＡＣＶテスト実行環境ＤＢ３３には、車両部品毎にアクティブテストの内容と故障判断の基準が登録されている。上記のとおり、診断ツールによりアクティブテストが実行されるので、その診断ツールと同様の方法でアクティブテストを実行すればよい。例えば、ＳＷＣＶを例にすると、アクティブテストの内容は「デューティ比１００％で駆動（全開駆動）」である。ＳＷＣＶの開度は所定のセンサ１３により検出される。ＳＷＣＶの制御線が例えば断線している場合、ＳＷＣＶの開度は変化しない。

すなわち、アクティブテストにより、車両５０に生じにくいアクチュエータ１２の駆動信号（制御情報）をアクチュエータ１２に供給し、アクチュエータ１２が駆動信号に従い制御されたか否かをセンサ１３で検出する一連の手順を実行できる。

ＡＣＶテスト実行部２４は、ＡＣＶテスト実行環境ＤＢ３３を参照して、故障判断の基準「デューティ比１００％に対応する開度でスワールコントロールバルブが開いたか」を読み出し、これとアクティブテストの結果を比較して、ＳＷＣＶを故障診断する。

〔アクティブテストしない車両部品の故障判定〕
ＡＣＶテスト必要部品決定部２２がアクティブテストをしないと決定した車両部品については、走行中の走行状況を利用して、故障判定部２６が故障診断する。アクティブテストしなくても故障しているか否かを判定可能な車両部品については、車両部品の必要な制御をもたらす走行状況を利用する。このため、条件成立判定部２５は、車両部品ごとに故障診断が可能な走行状況となったか否かを監視し、かかる走行状況となったことを故障判定部２６に通知する。なお、本実施形態ではアクティブテストの対象とならなかった車両部品は、全て走行中に故障診断の対象とするが、故障診断されなかった車両部品は部品リスト３５から消去されない。

車両部品毎に故障診断が可能な走行状況が得られたことを検出するための条件が、故障診断走行状況検出ＤＢに記憶されている。図５は故障診断走行状況ＤＢ３４に記憶された故障診断が可能な走行状況の一例を示す。例えば、車両部品がイグナイタの場合、イグニッション・オンされた状態であれば点火が繰り返されるので、走行状況条件は「イグニッション・オン」になり、故障判断の基準は、例えば「一次コイル及び二次コイルの抵抗値が基準を満たすか」である。

また、例えば、車両部品がインジェクションの場合、同様に走行状況条件は「イグニッション・オン」であり、故障判断の基準は「噴射時間に応じた作動音が検出されるか」である。作動音は例えば圧電素子などが変換した電圧値から検出される。また、例えば、ヨーレートセンサが車両部品の場合、所定以上の車速でステアリングホイールが操作されればヨーレートセンサの検出信号が増大すると予想されるので、走行状況条件は「操舵角センサが所定値以上に操作され、かつ、車速が所定値以上」であり、故障判断の基準は、例えば「基準値以上のヨーレートが検出されたか」である。

条件成立判定部２５は、走行状況条件をみたす車両部品がある場合、車両部品、走行状況条件、及び、故障判断の基準を故障判定部２６に通知する。故障判定部２６は、その走行状況において車両部品が故障判断の基準を満たすか否かに基づき車両部品を故障診断する。

なお、アクティブテストしない車両部品に対しては、直接的に、故障診断が可能な走行状況とならなくてもデータマイニングにより絞り込むことが可能である。データマイニングでは、教師データを用いて、車両情報から異常の原因を推定する。教師データは、例えば、車両情報及び車両情報の変化量が異常の原因に到達する推定ロジック、及び、推定ロジックに付随するパラメータである。

データマイニングを利用すれば、故障診断が可能な走行状況とならなくても。部品リスト３５の車両部品が故障しているか否かを推定可能なので、データマイニングにより故障している部品リスト３５の車両部品を絞り込むことができる。

〔部品リスト３５の車両部品の消去〕
部品リスト消去部２７は、アクティブテストの結果に基づく車両部品の故障診断、走行中の故障診断による車両部品の故障診断、により故障していないと判定された車両部品を、部品リスト３５から消去する。したがって、走行中に故障していないと判定された車両部品は、走行状況に応じて部品リスト３５から徐々に消去される。このため部品リスト３５には、
・アクティブテストにより又は走行中に故障診断され、故障しているおそれがあると判定された車両部品
・アクティブテストの対象又は走行中の故障診断の対象となった車両部品であるが、いまだ故障診断されなかった車両部品
が残ることになる。したがって、サービスセンタに車両５０が持ち込まれた状況では故障診断すべき車両部品が絞り込まれているので、サービスマンによる故障診断の時間を短縮することができる。

〔車両用故障診断装置１００の動作手順〕
図６は、車両用故障診断装置１００が動作する手順を示すフローチャート図の一例である。図６のフローチャート図は、例えばイグニッションがオンになるとスタートする。

部品リスト生成部２１は、所定のサイクル時間毎に、各ＥＣＵ１１又は故障診断ＥＣＵ２０がＤＴＣを記憶しているか否かを判定する（Ｓ１０）。すなわち、ＤＴＣの発生が図６のフローチャート図の処理を開始するトリガとなる。

ＤＴＣが記憶されている場合（Ｓ１０のＹｅｓ）、部品リスト生成部２１は、記憶されているＤＴＣに対応づけられた車両部品を車両部品登録ＤＢ３１から読み出し、故障診断の対象として複数の車両部品が登録されているか否かを判定する（Ｓ２０）。複数の車両部品が登録されていないＤＴＣの場合（Ｓ２０のＮｏ）、その車両部品が故障している可能性が高いとしてよいので処理を終了する。この場合、サービスセンタではその１つの車両部品だけを点検することになる。なお、故障が考えられる車両部品が１つのみであっても、アクティブテストしてもよい。これにより、その車両部品が本当に故障しているか否かを確認することができる。

複数の車両部品が登録されているＤＴＣの場合（Ｓ２０のＹｅｓ）、部品リスト生成部２１は、ＤＴＣに対応づけられた車両部品を車両部品登録ＤＢ３１から読み出し部品リスト３５を生成する（Ｓ３０）。部品リスト３５は故障診断ＥＣＵ２０のメモリに記憶される。例えば、失火のＤＴＣが検出された場合、インジェクタ、イグナイタ、ＮＥセンサ、ＳＷＣＶが部品リスト３５にリストアップされる。

ついで、ＡＣＶテスト必要部品決定部２２は、部品リスト３５にリストアップされた車両部品のうち、ＡＣＶテスト車両部品ＤＢ３２に登録されている車両部品をアクティブテストが必要かつ可能な車両部品に決定する（Ｓ４０）。失火の場合、例えばＳＷＣＶが、アクティブテストが必要かつ可能な車両部品である。

そして、ＡＣＶテスト実行判定部２３と条件成立判定部２５は、走行中（イグニッションオンの間）、それぞれアクティブテスト、走行中の故障診断を実行する。図６では、まずＡＣＶテスト実行判定部２３が、アクティブテストの実行環境条件を満たすか否かを判定する（Ｓ５０）。実行環境条件を満たす走行状況となると（Ｓ５０のＹｅｓ）、ＡＣＶテスト実行部２４が、ＡＣＶテスト車両部品ＤＢ３２を参照して、アクティブテストの内容を読み出し、その車両部品のアクティブテストを実行する（Ｓ６０）。

そして、ＡＣＶテスト実行部２４は、ＡＣＶテスト車両部品ＤＢ３２を参照して故障判断基準を読み出し、アクティブテストした車両部品を故障診断する（Ｓ７０）。アクティブテストにより、ＳＷＣＶが故障していないと判定されれば、部品リスト消去部２７は部品リスト３５からＳＷＣＶを消去する（Ｓ８０）。

また、ステップＳ５０に戻り、アクティブテストの実行環境条件が満たされない走行状況では（Ｓ５０のＮｏ）、条件成立判定部２５が、部品リスト３５の車両部品毎に走行状況条件を満たす走行状況か否かを判定する（Ｓ９０）。走行状況条件を満たす車両部品がある場合（Ｓ９０のＹｅｓ）、故障判定部２６は、故障診断走行状況検出ＤＢから故障判断の基準を読み出し、当該車両部品を故障診断する（Ｓ７０）。これにより、インジェクタ、イグナイタ及びＮＥセンサについて故障診断されうる。

そして、インジェクタ、イグナイタ及びＮＥセンサが故障していないと判定されれば、部品リスト消去部２７は、部品リスト３５から故障していないと判定された車両部品を消去する（Ｓ８０）。

走行中、車両診断ＥＣＵ２０は図６のフローチャート図を繰り返すので、故障の可能性のある車両部品が絞り込むことできる。したがって、サービスセンタに車両５０が持ち込まれ時点では、部品リスト３５の車両部品の数が少なくなっており、サービスマンによる故障診断の時間を短縮することができる。

〔変形例〕
上記の実施例では車両５０のみで部品リスト３５の車両部品を絞り込んでいったが、サーバ６０を利用することで故障の可能性のある車両部品の絞り込みが容易になる。
図７は、サーバ６０を含む故障診断システム２００を模式的に示す図である。本変形例の車両用故障診断装置１００は、異常が検出されるとＤＴＣをサーバ６０に送信する。そして、サーバ６０は、上記実施例と同様に部品リスト３５を生成する。また、サーバ６０は、部品リスト３５の部品のうちアクティブテストが必要かつ可能な車両部品、その車両部品の実行環境条件、アクティブテストの内容及び故障判断の基準（以下、アクティブテスト情報という）を車両５０に送信する。また、サーバ６０は、部品リスト３５の部品のうちアクティブテストを実行しない車両部品、その車両部品の走行状況条件及び故障判断の基準（以下、走行中テスト情報という）を車両５０に送信する。

したがって、車両５０では、車両部品登録ＤＢ３１、ＡＣＶテスト車両部品ＤＢ３２、ＡＣＶテスト実行環境ＤＢ３３及び故障診断走行状況ＤＢ３４を備えておく必要がない。また、後述するようにデータマイニングをサーバ６０で実行できるので、アクティブテストを実行しない車両部品の絞り込みが容易となる。

なおサーバ６０は、ＣＰＵ、ＲＡＭ、ＲＯＭ、入出力インターフェイス及びメモリ等を備えたコンピュータを実体とし、メモリに車両部品登録ＤＢ３１、ＡＣＶテスト車両部品ＤＢ３２、ＡＣＶテスト実行環境ＤＢ３３及び故障診断走行状況ＤＢ３４を記憶している。したがって、サーバ６０は、部品リスト生成部２１及びＡＣＶテスト必要部品決定部２２、を備える。

図８は、故障診断システム２００が動作する手順を示すシーケンス図の一例である。図８のシーケンス図は、例えば車両５０のイグニッションがオンになるとスタートする。なお、図８において、図６と同一ステップの説明は簡単に行う。

故障診断ＥＣＵ２０は、ＥＣＵ１１等がＤＴＣを記憶しているとそのＤＴＣをサーバ６０に送信する（Ｓ１１０）。また、故障診断ＥＣＵ２０は車両情報を送信する（Ｓ１２０）。この車両情報は例えば、ＤＴＣと共に記憶されたＦＦＤであるが、ＤＴＣが検出された際のＦＦＤに限られず、ＤＴＣが検出された後のＦＦＤに相当する車両情報も含まれる。

サーバ６０の処理に移り、サーバ６０はＤＴＣ及び車両情報を受信する（Ｓ２１０，Ｓ２２０）。ＤＴＣを受信すると、サーバ６０の部品リスト生成部２１は、記憶されているＤＴＣに対応づけられた車両部品を車両部品登録ＤＢ３１から読み出し、故障診断の対象として複数の車両部品が登録されているか否かを判定する（Ｓ２３０）。

複数の車両部品が登録されているＤＴＣの場合（Ｓ２３０のＹｅｓ）、部品リスト生成部２１は、ＤＴＣに対応づけられた車両部品を車両部品登録ＤＢ３１から読み出し部品リスト３５を生成する（Ｓ２４０）。

サーバ６０のＡＣＶテスト必要部品決定部２２は、部品リスト３５にリストアップされた車両部品のうち、ＡＣＶテスト車両部品ＤＢ３２に登録されている車両部品をアクティブテストが必要かつ可能な車両部品に決定する（Ｓ２５０）。

ついで、サーバ６０は、ＡＣＶテスト実行環境ＤＢ３３を参照して、実行環境条件、アクティブテストの内容及び故障判断の基準を読み出しアクティブテスト情報を生成する。また、サーバ６０は、故障診断走行状況ＤＢ３４を参照して、走行状況条件及び故障判断の基準を読み出し走行中テスト情報を生成する。そして、部品リスト３５、アクティブテスト情報及び走行中テスト情報を車両５０に送信する（Ｓ２６０）。

車両５０の処理に移行し、車両５０は部品リスト３５、アクティブテスト情報及び走行中テスト情報を受信する（Ｓ１３０）。車両５０は上記実施例と同様に、アクティブテストを実行して故障の可能性のある車両部品を絞り込み、また、走行状況条件を満たす車両部品がある場合、当該車両部品を故障診断して、故障の可能性のある車両部品を絞り込む（Ｓ１４０〜Ｓ１７０）。

また、サーバ６０は、ステップＳ２２０で受信した車両情報を教師データに適用してデータマイニングを実行する（Ｓ２７０）。処理負荷の大きいデータマイニングをサーバ６０で実行することで、早期に故障した車両部品を絞り込むことができる。そして、データマイニングにより故障していない車両部品が確定したらその車両部品を車両５０に送信する（Ｓ２８０）。

車両用故障診断装置１００の部品リスト消去部２７は、サーバ６０が故障していないと判定した車両部品を部品リスト３５から消去する（Ｓ１６０）。

したがって、本変形例によれば、データマイニングにより車両部品のさらなる絞り込みが期待できるので、サービスマンによる故障診断の時間を短縮することができる。

車両用故障診断装置の概略を説明する図の一例である。 車両用故障診断装置の機能ブロック図の一例である。 故障診断ＥＣＵの機能ブロック図の一例である。 車両部品登録ＤＢ、ＡＣＶテスト車両部品ＤＢ、ＡＣＶテスト実行環境ＤＢの一例を示す図である。 故障診断走行状況ＤＢの一例を示す図である。 車両用故障診断装置が動作する手順を示すフローチャート図の一例である。 サーバを含む故障診断システムを模式的に示す図である。 故障診断システムが動作する手順を示すシーケンス図の一例である。

符号の説明

１１、１１Ａ〜１１Ｃ ＥＣＵ
１２、１２ａ〜１２ｃ アクチュエータ
１３、１３ａ〜１３ｃ センサ
１４、１４ａ〜１４ｃ スイッチ
３１ 車両部品登録ＤＢ
３２ ＡＣＶテスト車両部品ＤＢ
３３ ＡＣＶテスト実行環境ＤＢ
３４ 故障診断走行状況ＤＢ
３５ 部品リスト
５０ 車両
１００ 車両用故障診断装置
２００ 故障診断システム

Claims (3)

1. 車両に異常が生じた際に、異常の原因の可能性のある複数の車両部品のリストを生成する部品リスト生成手段と、
   前記リストを記憶するリスト記憶手段と、
   前記リストの車両部品のうち、アクティブテストを実行する車両部品を決定するテスト必要部品決定手段と、
   車両が車両システム起動状態で、車両部品毎にアクティブテストを実行する実行環境条件が満たされたか否かを判定するテスト実行判定手段と、
   実行環境条件が満たされると判定された場合、当該車両部品のアクティブテストを実行するアクティブテスト実行手段と、
   アクティブテストの実行の結果、故障していないと判定された車両部品を前記リストから消去するリスト消去手段と、
   前記リストの車両部品のうち、前記テスト必要部品決定手段がアクティブテストを実行しないと決定した車両部品に対し、車両が車両システム起動状態で、車両部品毎に故障診断のための走行状況条件が満たされたか否かを判定する条件成立判定手段と、
   前記走行状況条件が満たされると判定された場合、当該車両部品が故障しているか否かを判定する故障判定手段と、を有し、
   前記リスト消去手段は、前記故障判定手段が故障していないと判定した車両部品を前記リストから消去する、ことを特徴とする車両用故障診断装置。
2. 前記リストの車両部品のうち、前記テスト必要部品決定手段がアクティブテストを実行しないと決定した車両部品の故障診断を、
   予め記憶するデータマイニングの教師データに、車両部品から検出された車両情報を適用して行う、ことを特徴とする請求項１記載の車両用故障診断装置。
3. 部品リスト生成手段が、車両に異常が生じた際に、異常の原因の可能性のある複数の車両部品のリストを生成し、リスト記憶手段に記憶するステップと、
   テスト必要部品決定手段が、前記リストの車両部品のうち、アクティブテストを実行する車両部品を決定するステップと、
   テスト実行判定手段が、車両が車両システム起動状態で、車両部品毎にアクティブテストを実行する実行環境条件が満たされたか否かを判定するステップと、
   実行環境条件が満たされると判定された場合、アクティブテスト実行手段が、当該車両部品のアクティブテストを実行するステップと、
   リスト消去手段が、アクティブテストの実行の結果、故障していないと判定された車両部品を前記リストから消去するステップと、
   条件成立判定手段が、前記リストの車両部品のうち、前記テスト必要部品決定手段がアクティブテストを実行しないと決定した車両部品に対し、車両が車両システム起動状態で、車両部品毎に故障診断のための走行状況条件が満たされたか否かを判定するステップと、
   故障判定手段が、前記走行状況条件が満たされると判定された場合、当該車両部品が故障しているか否かを判定するステップと、
   前記リスト消去手段が、前記故障判定手段が故障していないと判定した車両部品を前記リストから消去するステップと、
   を有することを特徴とする車両の故障診断方法。

Images