(57)【特許請求の範囲】
【請求項１】
車両に搭載された各種装備の異常を検出する車両診断装置において、
１以上の第１の部品の診断情報と相関がある診断情報を示す第２の部品を特定すると共に、前記第１の部品の診断情報と前記第２の部品の診断情報との関係を定める関係情報を策定し、また、複数の車両から取得した正常時の診断情報から診断対象部品毎の故障の判定情報を生成するサーバと、ネットワークを介して接続され、
メンテナンス対象の車両から読み出した診断情報に、前記サーバと同じ前記関係情報を適用して前記第２の部品の被判定情報を取得し、所定の装備のメンテナンス作業の結果を確定するメンテナンス結果確定手段と、
前記診断対象部品に対応づけて前記判定情報を記憶するデータベースにアクセスして、前記メンテナンス結果確定手段によって確定された前記被判定情報と前記判定情報の比較結果に基づきメンテナンス作業の結果の適否を判定する判定手段と、
前記判定手段による判定結果を報知する報知手段と、
を有することを特徴とする車両診断装置。
【請求項２】
前記データベースはメンテナンス作業を施された車両以外の他車両の診断情報により更新された前記判定情報を記憶しており、
前記メンテナンス結果確定手段は、複数の車両から生成した前記判定情報及び前記メンテナンス作業の結果に基づき前記判定情報を更新する、
ことを特徴とする請求項１記載の車両診断装置。
【請求項３】
前記判定情報は、使用中の車両から送信された診断情報を蓄積して生成される、
ことを特徴とする請求項１又は２記載の車両診断装置。
【請求項４】
車両から診断情報を受信するサーバと、車両の異常を検出する車両診断装置と、を有する車両診断システムであって、
前記車両診断装置は、
１以上の第１の部品の診断情報と相関がある診断情報を示す第２の部品を特定すると共に、前記第１の部品の診断情報と前記第２の部品の診断情報との関係を定める関係情報を策定し、また、複数の車両から取得した正常時の診断情報から診断対象部品毎の故障の判定情報を生成するサーバと、ネットワークを介して接続され、
メンテナンス対象の車両から読み出した診断情報に、前記サーバと同じ前記関係情報を適用して前記第２の部品の被判定情報を取得し、所定の装備のメンテナンス作業の結果を確定するメンテナンス結果確定手段と、
前記診断対象部品に対応づけて前記判定情報を記憶するデータベースにアクセスして、前記メンテナンス結果確定手段によって確定された前記被判定情報と前記判定情報の比較結果に基づきメンテナンス作業の結果の適否を判定する判定手段と、
前記判定手段による判定結果を報知する報知手段と、
を有することを特徴とする車両診断システム。
【請求項５】
前記車両診断装置は、
前記判定結果がメンテナンス作業の結果が適切であることを示す場合、メンテナンス作業の後に、前記判定結果を前記サーバに送信する、
ことを特徴とする請求項４記載の車両診断システム。
【請求項６】
１以上の第１の部品の診断情報と相関がある診断情報を示す第２の部品を特定すると共に、前記第１の部品の診断情報と前記第２の部品の診断情報との関係を定める関係情報を策定し、また、複数の車両から取得した正常時の診断情報から診断対象部品毎の故障の判定情報を生成するサーバと、ネットワークを介して接続された、車両診断装置が、車両に搭載された各種装備の異常を検出する車両の診断方法において、
メンテナンス対象の車両から読み出された診断情報に、メンテナンス結果確定手段が、前記サーバと同じ前記関係情報を適用して前記第２の部品の被判定情報を取得し、所定の装備のメンテナンス作業の結果を確定するステップと、
判定手段が、前記診断対象部品に対応づけて前記判定情報を記憶するデータベースにアクセスして、前記メンテナンス結果確定手段によって確定された前記被判定情報と前記判定情報の比較結果に基づきメンテナンス作業の結果の適否を判定するステップと、
報知手段が、前記判定手段による判定結果を報知するステップと、
を有することを特徴とする診断方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両の異常の有無を判定する車両診断装置、車両診断システム及び診断方法に関する。
【背景技術】
【０００２】
各種のセンサやアクチュエータ（以下、診断対象部品という）の異常を検出できるよう診断装置を車載し、診断装置で診断対象部品の状態を監視しながら、異常があれば異常情報としてそれを記憶したり、サーバに送信することができるようになっている車両がある（例えば、特許文献１参照。）。特許文献１には、異常情報をサーバで収集するが、ユーザが自発的にサービス工場等に車両を持ち込み異常が解消された場合、対策済み情報をサーバに送信することで、ユーザに不要な修理要求を送信することを回避する車両診断システムが記載されている。
【０００３】
ところで、車両に異常が検出され修理した場合や部品交換した場合、サービス工場では診断ツール１５を用いた診断対象部品の診断結果に基づき修理が終了したか否か又は部品交換が正常に完了したか否かを判断している（以下、修理完了判定という）。
【０００４】
図６は、従来の修理完了判定の概略を示す図である。サービス工場の修理者は（ｉ）車両から故障部品を取り外し、（ｉｉ）適切な修理用部品を車両に取り付ける。そして、(iii)診断ツール１５を用いて診断対象部品（交換した修理用部品に限らない）を診断し、(iv)修理者は車両の挙動等を経験的に確認したり、又は、作業手順書などに従った状態であることを確認し、（ｖ）正常であると判定した場合に車両をユーザに返却する。
【特許文献１】特許第３７９９７９５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、診断ツール１５による診断結果に基づく修理完了判定は、診断ツール１５自体に所定の判断基準を記憶させておき、その判断基準と診断結果を比較によって行うものであることから、当該判断基準を策定した時点において把握されていない事象まで当該診断ツール１５を用いて判断するのは困難な場合がある。
【０００６】
例えば、診断ツール１５によって修理完了時には正常であると判定されても、その後に修理用部品が実際に車両に取り付けられてからの使用年数によっては、修理交換を行った時点の判断基準では想定していないことが起こりえる可能性は否定できない（例えば、交通法規制が変更になって制限車速の上限が変わる等、車両や当該修理用部品の使用環境が変わる可能性がある。）。
【０００７】
また、診断ツール１５による診断結果は各診断対象部品の診断結果に過ぎないため、各診断対象部品の診断結果は正常でも、修理や部品交換が正常に完了したか否かは、各診断対象部品やそれ以外の車両部品とのあらゆる状況下においての適合性をふまえて総合的に判定する必要がある場合がある。しかしながら、時間的にも空間的にも限定的な修理時において、そのようなあらゆる状況下を再現できるとは限らないし、また、そのような再現を長期間かけて行うということも、修理待ちをしている車両ユーザを考慮すると現実的でない場合がある。
【０００８】
図７は、診断ツール１５により取得される診断対象部品とそれぞれの診断時間を一例として示したものである。図７に示すように、Ａセンサは１．０秒で、Ｂセンサは２．０秒で診断結果が得られるが、Ｃセンサは８０時間連続走行時に初めて正常であるという診断結果が取得されている。しかしながら、８０時間連続走行するという状況下の診断は非現実的である。また、Ｑシステムについては診断結果が取得されていないが、これはＱシステムが、例えば高温環境（例えば４０度）又は低温環境（例えばマイナス３０度）でのみ診断結果を得られるシステムであるためである。このように極めて限定的な環境をサービス工場などで再現するまで修理が完了しないのでは現実的には診断が困難となってしまう。
【０００９】
すなわち、従来のように診断ツール１５を用いた診断結果から直接、修理や部品交換が正常に完了したか否かを判定する修理完了判定では、長期間にわたらないと評価しきれない事象又は環境変化等により当初想定されていない当該修理用部品の使用状況などをふまえての修理完了判定を下すことが困難であるという問題があった。
【００１０】
本発明は、上記課題に鑑み、環境変化への適応を可能とし、又は、時間的又は空間的な制約を低減して、修理や部品交換が完了したことを判定可能な車両診断装置、車両診断システム及び診断方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記課題に鑑み、本発明は、車両に搭載された各種装備の異常を検出する車両診断装置において、１以上の第１の部品の診断情報と相関がある診断情報を示す第２の部品を特定すると共に、前記第１の部品の診断情報と前記第２の部品の診断情報との関係を定める関係情報を策定し、また、複数の車両から取得した正常時の診断情報から診断対象部品毎の故障の判定情報を生成するサーバと、ネットワークを介して接続され、
メンテナンス対象の車両から読み出した診断情報に、前記サーバと同じ前記関係情報を適用して前記第２の部品の被判定情報を取得し、所定の装備のメンテナンス作業の結果を確定するメンテナンス結果確定手段（例えば、修理結果確定部５１）と、前記診断対象部品に対応づけて前記判定情報（例えば、正常値情報５２）を記憶するデータベース（例えば、メモリ４３、サーバ１４）にアクセスして、メンテナンス結果確定手段によって確定された前記被判定情報と前記判定情報の比較結果に基づきメンテナンス作業の結果の適否を判定する判定手段と、判定手段による判定結果を報知する報知手段と、を有することを特徴とする。
【００１２】
本発明によれば、メンテナンス作業の結果を確定し、それをメンテナンス作業の結果の適否を判定するための判定情報と比較するので、時間的又は空間的な制約を低減して修理が完了したか否かを判定することができる。
【００１３】
また、本発明の一形態において、前記データベースはメンテナンス作業を施された車両以外の他車両の診断情報により更新された前記判定情報を記憶しており、前記メンテナンス結果確定手段は、複数の車両から生成した前記判定情報及び前記メンテナンス作業の結果に基づき前記判定情報を更新する、ことを特徴とする。
【００１４】
本発明によれば、他車両の診断情報を集約したデータベースからメンテナンス結果の適否を判定でき、さらに自車両のメンテナンス結果に基づき判定情報を更新することができる。
【発明の効果】
【００１５】
環境変化への適応を可能とし、又は、時間的又は空間的な制約を低減して、修理や部品交換が完了したことを判定可能な車両診断装置、車両診断システム及び診断方法を提供することができる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明を実施するための最良の形態について、図面を参照しながら実施例を挙げて説明する。
【実施例１】
【００１７】
図１は本実施形態の修理完了判定の概略を示す図である。本実施形態の修理完了判定では、診断ツール１５の代わりに修理結果判定装置１６が診断し、修理者の代わりに修理結果判定装置１６が修理が完了したか否かを判定する。修理結果判定装置１６は予め診断対象部品の診断情報を正常と判定してよい正常値情報を記憶しており、この正常値情報と診断情報を比較することで修理が正常に完了した否かを判定する。したがって、従来のように時間的又は空間的な制約の下、診断結果が正常か否かを判断する必要がない。また、正常値情報は、診断情報の取得に時間がかかる診断対象部品や、所定の車両状況でないと診断結果が得られない診断対象部品を含め、診断対象部品の診断情報の正常範囲を確定するものである。このため、かかる診断対象部品について、サービス工場２０（カーディーラーのサービス設備等を含む）において診断結果を取得して修理が正常に完了した否かを判定することができる。
【００１８】
修理者は、診断情報と正常値情報のずれ量が所定値内であれば車両１１をユーザに返却すればよいし、ずれ量が所定値内でなければ診断情報に基づき所定の診断対象部品を再度チェックすることができる。したがって、修理完了を正確に判定することができる。
【００１９】
修理結果判定装置１６が予め正常値情報を記憶できるよう、図１に示すように種々の車両Ａ〜Ｃは車載診断装置３０から各車両の診断情報をサーバ１４に送信している。診断情報は診断対象部品が正常な場合と異常が検出された場合を含む。正常な診断情報を数多く収集することで、診断対象部品が正常な場合に診断情報が取り得る範囲を確定でき、異常な診断情報を収集することで、診断対象部品が異常な場合に診断情報が取り得る範囲を確定できる。正常な診断情報は例えば定期的に送信し、異常な診断情報は異常が検出された時に送信する。
【００２０】
サーバ１４はＣＰＵ等を有するコンピュータであって、正常な診断情報と異常のある診断情報にデータマイニングを施し、正常値情報５２を生成するパラメータ生成部１７を有する。データマイニングとは、データの巨大集合やデータベースから有用な情報を抽出する技術である。サーバ１４は例えば更新の度に正常値情報５２を修理結果判定装置１６に送信し、また、サービス工場２０からの問い合わせに応じて正常値情報を修理結果判定装置１６に送信する。
【００２１】
なお、修理結果判定装置１６にパラメータ生成部１７を配置し、修理結果判定装置１６がデータマイニングしてもよい。この場合、サーバ１４は正常な診断情報と異常な診断情報をそのまま修理結果判定装置１６に送信する。
【００２２】
〔車載診断装置３０〕
図２は、車載診断装置３０と修理結果判定装置１６のブロック図を示す。車載診断装置３０は、多重通信ネットワークにより相互に接続された通信装置３１、診断ＥＣＵ（Electronic  Control  Unit）３３及び診断対象部品３２を有する。多重通信ネットワークの通信プロトコルには、ＣＡＮ（controller  area  network）、ＬＩＮ（Local  Interconnect  Network）が用いられ、例えばパワートレイン系の電子部品（例えば、エンジン、ブレーキ）にはCAN（高速）が用いられ、ボデー系の電子部品（例えば、ドア、シート等）にはCAN（中速）が用いられる。
【００２３】
車載診断装置３０は診断ＥＣＵ３３により制御される。診断ＥＣＵ３３はＣＰＵ、ＲＡＭ、ＲＯＭ等を備えたコンピュータであり、診断対象部品３２の診断情報を収集し、通信装置３１からサーバ１４へ、コネクタ３４から修理結果判定装置１６に送信する。車載診断装置３０は、車載診断装置３０のＣＰＵがプログラムを実行して実現される診断情報収集部３５、第１の診断情報送信部３６、及び、第２の診断情報送信部３７を有する。
【００２４】
診断対象部品３２は、車載装置を制御するためのセンサやアクチュエータであり、多重通信ネットワークに接続された他のＥＣＵにより管理されている。例えば、エンジンＥＣＵに接続された診断対象部品３２は、Ａ／Ｆセンサ（空燃比センサ）、回転数センサ、エアフローメータ、水温センサ及びスロットル開度センサ等であり、ブレーキＥＣＵに接続された診断対象部品３２は、車輪速センサ、Ｇセンサ、ポンプモータ、油圧センサ等である。
【００２５】
診断対象部品３２に接続された各ＥＣＵはセンサやアクチュエータの自己診断機能を有し、異常が検出された場合には異常の箇所及び内容を示す診断情報を生成し、診断対象部品３２を管理するＥＣＵ又は診断ＥＣＵ３３の少なくとも一方が記憶する。診断情報とは、車両１１を診断するのに有用な情報であり、単なる異常の有無のみを知らせる情報、故障の箇所や程度を知らせる情報、更には故障発生前後の動作データ、異常の発生日時等である。
【００２６】
診断対象部品３２に異常が生じていない（正常な）場合、診断情報収集部３５は所定のサイクル時間毎に、診断対象部品３２にセンサやアクチュエータの診断を要求し、診断情報を収集する。この診断情報は、異常が検出された場合と同様に車両１１を診断するのに有用な情報である。
【００２７】
診断情報収集部３５は、所定のサイクル時間毎に収集した診断情報に、例えば統計処理を施すことで診断情報のうち特徴的な情報のみを抽出して送信するデータの容量を低減することができる。統計処理により例えば、センサ等が出力する電圧値や電流値等の検出信号の平均値、最大値、最小値、中央値及び分散等を算出する。例えば、パラメータ生成部１７が車両Ａ〜Ｃの平均値等にデータマイニングを適用すれば、正常時の診断情報から当該センサの正常値情報５２が得られる。なお、このような統計処理はサーバ１４又は修理結果判定装置１６のいずれで行ってもよい。本実施形態では統計処理したものとしないもの区別せず診断情報という。
【００２８】
第１の診断情報送信部３６は、通信装置３１からサーバ１４に診断情報を送信する。診断情報は、車両１１のシステムを識別できる情報に対応づけて送信される。車両１１のシステムとはエンジン系統、ブレーキ系統、安全装備系統などのシステムをいい、車両１１のシステムを識別できる情報とは例えばエンジンの型番、車台番号等をいう。これは、車両１１のシステムが異なると診断情報が異なるので、システム毎にデータマイニングする必要があるためである。なお、車両１１毎に診断情報を送信し、その車両１１に最適化された正常値情報を生成してもよい。
【００２９】
診断情報の送信のタイミングは、診断対象部品３２が正常な場合の診断情報は、１日に１〜数回等の定期、又は、イグニッションオン又はオフの直後等の不定期である。通信装置３１は、携帯電話網の基地局１２、無線ＬＡＮ又はＷｉＭＡＸ（Worldwide  Interoperability  for  Microwave  Access）のアクセスポイントからネットワーク１３に接続しサーバ１４と通信する。なお、診断情報の送信には公知の通信プロトコル、ＰＰＰプロトコル（Point・to・Point・Protocol）やこれの上位層であるＴＣＰ／ＩＰプロトコル（Transmission  Control  Protocol/Internet  Protocol）等を用いる。ネットワーク１３は例えば通信網やインターネットである。
【００３０】
コネクタ３４は、インストルメントパネルやステアリングコラムの脇に設けられ、修理結果判定装置１６との物理的・ソフト的インターフェイスを提供する。コネクタ３４は、例えばＯＢＤ２（On  Board  Diagnosis  system  stage2）を用いる。
【００３１】
〔修理結果判定装置〕
修理結果判定装置１６は、診断ツール１５の機能に加え、修理結果を確定する修理結果確定部５１及び確定された結果と正常値情報５２から修理が完了したか否かを判定する判定部５３を有するが、本実施形態では修理結果判定部５１がプログラムにより実現されることを想定して、コンピュータの態様として説明する。
【００３２】
修理結果判定装置１６は、ＣＰＵ４２、メモリ４３、ＲＡＭ４４、ＲＯＭ４５、表示制御部４６、記憶媒体装着部４７、ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）４８及び入力装置４９がバスにより接続されたコンピュータである。ＣＰＵ４２は、メモリ４３に記憶されたプログラムを読み出しＲＡＭ４４を作業エリアに実行することで、修理結果確定部５１、判定部５３及びパラメータ生成部１７の機能を提供すると共に、修理結果判定装置１６を統括的に制御する。
【００３３】
入力装置４９はキーボードやマウス、音声入力装置などで構成され、修理者からの様々な操作指示を入力するために用いられる。記憶媒体装着部４７は、ＣＤやＤＶＤ、フラッシュメモリなどの記憶媒体４０に記憶された情報を読み出し、また修理結果判定装置１６が有する情報を書き込む。ＮＩＣ４８は、ネットワーク１３に接続する通信装置であり、サーバ１４から送信される情報に所定のプロトコル処理を施して受信する。
【００３４】
修理結果判定装置１６が正常値情報５２を生成する場合、メモリ４３の正常値情報５２は随時更新され、サーバ１４が正常値情報５２を生成する場合、ＮＩＣ４８によりサーバ１４から正常値情報５２を受信して、メモリ４３に記憶されている正常値情報５２を更新する。なお、サーバ１４から記憶媒体４０に記憶して配布された正常値情報５２を読み出してもよい。
【００３５】
また、修理結果判定装置１６はデータ通信部４１を有し、有線又は無線により車両１１内のコネクタ３４に接続し、多重通信ネットワークを介して診断ＥＣＵ３３と通信する。修理者はデータ通信部４１の規格にしたがったケーブルをコネクタ３４に接続し、入力装置４９を操作して診断ＥＣＵ３３に診断情報の送信を要求する。これにより診断情報収集部３５が収集した診断情報を、第２の診断情報送信部３７がデータ通信部４１を介して修理結果判定装置１６に送信する。無線で通信する場合、例えばＤＳＲＣ（Dedicated  Short  Range  Communication）、ブルートゥース、無線ＬＡＮにより通信する。
【００３６】
なお、異常のある診断対象部品３２を知らせるダイアグコードを取得してもよいが、本実施形態では修理用部品を取り付けた後に、修理が完了しているか否かを判定することを目的にするので、診断情報を取得する際はダイアグコードは既に検出されない場合が多い。
【００３７】
〔正常値情報５２〕
正常値情報５２について説明する。サーバ１４のパラメータ生成部１７は車両Ａ〜Ｃから取得した診断情報に、パターン抽出、クラス分類、回帰分析等の手法を適用して、診断対象部品３２毎に正常と見なしてよいパラメータを生成する。例えば、正常な場合、診断対象部品３２が出力する検出信号の正常値をパラメータに変換する。これにより診断対象部品３２の大部分の正常値情報５２が得られる。
【００３８】
また、診断情報の取得に時間がかかる診断対象部品３２については、車両使用中（例えば、走行中だけでなく、車両イグニッションがオンである状態や、アクセサリースイッチのみがオンである状態を含む）に検出される正常な状態の診断情報と、相関の大きい診断情報を示す診断対象部品３２であって診断情報の取得に時間がかからない診断対象部品３２（単数でも複数でもよい）を決定する。そして、パラメータ生成部１７は後者の検出信号から前者の検出信号を求める関係式を策定し、診断情報の取得に時間がかかる診断対象部品３２の正常状態のパラメータを生成する。
【００３９】
同様に、所定の走行状況でなければ異常を示さない診断対象部品３２については、所定の走行状況に検出される正常な状態の診断情報と、相関の大きい診断情報を示す診断対象部品３２であって診断情報の取得に時間がかからない診断対象部品３２（単数でも複数でもよい）を決定する。そして、後者の検出信号から前者の検出信号を求める関係式を策定し、診断情報の取得に時間がかかる診断対象部品３２の正常状態のパラメータを生成する。これらの相関の抽出や、関係式の策定にデータマイニングを利用する。
【００４０】
なお、異常を示す診断情報を用いてパラメータを生成してもよい。異常を示した診断対象部品３２の診断情報と、相関のある診断情報を示す診断対象部品３２を抽出できれば、特に、取得に時間のかかる診断対象部品３２や所定の走行状況でなければ診断情報を取得できない（異常を示さない）診断対象部品３２にとって有効となる。すなわち、取得に時間のかかる診断対象部品３２や所定の走行状況でなければ異常を示さない診断対象部品３２の異常状態の診断情報を、サービス工場２０で取得しやすい、相関のある他の診断対象部品３２の診断情報から判定できることになる。
【００４１】
図３は、正常値情報５２の一例を示す図である。正常値情報５２は、診断対象部品３２毎に「正常状態のパラメータ」を有する。図３には「正常状態のパラメータ」の右列に、修理後に取得した診断情報から生成した「修理後のパラメータ」を示した。
【００４２】
そして、ずれ量を例えば以下のように算出する。
｛（「正常状態のパラメータ」−「修理後のパラメータ」）／「正常状態のパラメータ」｝×１００
ずれ量の許容値は、例えば所定値（例えば数％〜数１０％）内である。予め「正常時のパラメータ」に許容値に該当する幅を持たせていてもよい。また、「正常状態のパラメータ」からのずれ量に応じて、異常がある可能性をパーセンテージで示してもよい。例えば、「正常状態のパラメータ」から±２０％以内のずれ量なら異常がある可能性は０％、±２０〜３０％以内のずれ量なら異常がある可能性は１０％等とする。
【００４３】
図３では、Ａセンサ〜Ｃセンサは、「正常状態のパラメータ」と「修理後のパラメータ」のずれ量が小さいので修理が正常に完了したと判定される。Ｑシステムでは「正常状態のパラメータ」と「修理後のパラメータ」のずれ量が大きいので修理未完の可能性ありと判定される。図３のＱシステムは図６のＱシステムと同じとしてよく、所定の走行状況（例えば車速ゼロより大、高速道路を走行）にならないと診断情報を検出できない診断対象部品３２の診断情報をサービス工場２０において実用的な時間内に取得することができるようになる。
【００４４】
なお、図３のように「正常状態のパラメータ」を数値で示すのでなく、各診断対象部品３２毎に、相関する複数の診断対象部品３２の診断情報の組を、正常と異常にクラスタリングしておき、データ通信部４１で取得した同じ組の診断情報をパターン認識して、正常又は異常のいずれかに分類されるかで修理が完了したか否かを判定してもよい。
【００４５】
〔修理結果の確定〕
修理結果確定部５１は、サーバ１４のパラメータ生成部１７が正常状態のパラメータを生成した場合と同じ方法で、車両３０から読み出した診断情報から「修理後のパラメータ」を生成する。この修理後のパラメータが修理の確定結果となる。
【００４６】
判定部５３は、この「正常状態のパラメータ」と「修理後のパラメータ」を比較して修理が正常に完了したか否かを判定する。なお、サーバ１４が修理結果確定部５１、判定部５３及び正常値情報５２を有する構成にして、データ通信部４１が受信した診断情報をサーバ１４に送信し、修理結果判定装置１６はサーバ１４から判定結果を受信してもよい。この場合、修理結果判定装置１６は従来の診断ツール１５として構成できる。
【００４７】
〔修理結果判定装置１６の動作手順〕
図４は、修理結果判定装置１６が修理が完了したか否を判定する手順を示すフローチャート図である。図４のフローチャート図は、例えばデータ通信部４１とコネクタ３４を接続し、入力装置４９から所定の操作を入力することでスタートする。
【００４８】
修理結果確定部５１は、車両１１の車載診断装置３０から診断情報を取得する（Ｓ１０）。この診断情報は、診断ＥＣＵ３３が診断対象部品３２に、管理するセンサやアクチュエータの診断を要求して取得したものである。
【００４９】
すべての診断対象部品３２の診断情報を取得すると、修理結果確定部５１は診断情報を「修理後のパラメータ」に変換する（Ｓ２０）。そして、判定部５３は正常値情報５２にアクセスして、診断対象部品３２毎に「正常状態のパラメータ」と「修理後のパラメータ」のずれ量が所定値以上か否かを判定する（Ｓ３０）。サーバ１４の正常値情報５２にアクセスして判定してもよい。
【００５０】
ずれ量が所定値以上の診断対象部品３２が検出された場合（Ｓ３０のＹｅｓ）、修理結果確定部５１はその診断対象部品３２をメモリ４３等に記憶しおき（Ｓ４０）、ステップＳ３０の判定を診断対象部品３２がなくなるまで繰り返す。
【００５１】
ずれ量が所定値以上の診断対象部品３２が検出されなくなると場合（Ｓ３０のＮｏ）、判定部５３は判定結果を出力する（Ｓ５０）。判定結果は、例えばディスプレイ５０へ出力され、ずれ量が所定以上の診断対象部品３２がなければ例えば「修理完了」というメッセージにより表示され、ずれ量が所定以上の診断対象部品３２があれば例えば「修理未完の可能性：Ａセンサ」というメッセージにより表示される。メモリ４３や記憶媒体４０に記憶してもよい。修理者はメッセージを視認して、ユーザに車両１１を返却するか、もう一度、図４の処理を繰り返したり該当する診断対象部品３２を修理するかを判断することができる。
【００５２】
また、パラメータ生成部１７は、既に記憶されている正常値情報５２及び修理後のパラメータにデータマイニングを施し正常値情報５２を更新する（Ｓ６０）。これにより、自車両のメンテナンス結果に基づき正常値情報５２を更新することができる。
【００５３】
本実施例によれば、修理結果判定装置１６が予め正常な診断対象部品３２が出力する診断情報を確定する正常値情報５２を記憶しておくことで、診断情報の取得に時間がかかる診断対象部品３２や所定の走行状況でのみ診断情報が得られる診断対象部品３２の修理が完了した否かを判定することができる。すなわち、診断完了の判断に時間的又は空間的な制約がある診断対象部品３２に対し、現実的な時間及び環境下で修理が完了した否かを判定することができるようになる。また、その後の経年使用で環境が変化するとしても、多様な環境に対応した診断情報が記憶されているので、環境変化に即した診断が可能となる。
【００５４】
また、一度、サービス工場２０で判定を行った後、次回にサービス工場２０に持ち込んだ際（例えば、次の定期点検時や車検時等）に過去の修理結果の妥当性が再確認できる効果もある。
【実施例２】
【００５５】
診断対象部品３２を修理した結果を修理結果判定装置１６により判定したら、判定結果をサーバ１４に送信することで、次回からのデータマイニングに活かすことができる。なお、判定結果の送信先はデータマイニングする装置であればよいので、サーバ１４でも修理結果判定装置１６でもよい。
【００５６】
図５は修理結果推定システムの概略構成図を示す。なお、図５において図１と同一構成部には同一の符号を付しその説明は省略する。車載診断装置３０は診断対象部品３２に異常が検出された場合、異常を示す診断情報（以下、異常診断情報という）をサーバ１４に送信する。異常診断情報には、車台番号及び異常のある診断対象部品３２を知らせるダイアグコード等が含まれる。
【００５７】
例えば、インストルメントパネル等に表示された異常の診断情報にユーザが気づき車両１１をサービス工場２０に持ち込むと、修理結果判定装置１６はダイアグコード等により異常のある診断対象部品３２を特定し修理用部品に交換する。そして、実施例１と同様に修理が完了したか否を推定し、修理が完了したと推定された場合、修理結果判定装置１６はNIC４８から異常解消情報をサーバ１４に送信する。異常解消情報は車台番号と共に送信され、また交換した修理用部品の情報を含む。
【００５８】
サーバ１４は、異常診断情報と異常解消情報とを突合することで、当該異常診断情報の異常を解消するために必要な修理用部品の情報を蓄積できる。特に、ダイアグコードが示す診断対象部品３２と異なる診断対象部品３２を修理用部品に交換した場合、サーバ１４は両者の関係からより適切なデータマイニングを行い、同様な異常診断情報に対し交換の部品を確実に特定できるよう正常値情報５２を生成することができる。
【００５９】
本実施例によれば、実施例１の効果に加え、異常解消情報をサーバ１４に送信するのでさらに診断完了の判断にさらに適切な正常値情報５２を生成することができる。
【図面の簡単な説明】
【００６０】
【図１】修理完了判定の概略を示す図である。
【図２】車載診断装置と修理結果判定装置のブロック図の一例である。
【図３】正常値情報の一例を示す図である。
【図４】修理結果判定装置が、修理が完了したか否を推定する手順を示すフローチャート図である。
【図５】修理結果推定システムの概略構成図である。
【図６】従来の修理完了判定の概略を示す図である。
【図７】診断ツールにより取得される診断対象部品とそれぞれの診断時間を示す図である。
【符号の説明】
【００６１】
１１    車両
１４    サーバ
１６    修理結果判定装置
１７    パラメータ生成部
２０    サービス工場
３０    車載診断装置
３２    診断対象部品
５１    修理結果確定部
５２    正常値情報
５３    判定部
【図１】
0004453764.tif 000002
【図２】
0004453764.tif 000003
【図３】
0004453764.tif 000004
【図４】
0004453764.tif 000005
【図５】
0004453764.tif 000006
【図６】
0004453764.tif 000007
【図７】
0004453764.tif 000008