JP3963181B2 - 車両の故障診断システム - Google Patents

Description

この発明は、車両の故障診断システムに係り、特に、相互に通信可能な車両と情報センタとを含む車両の故障診断システムに関する。

従来、例えば特開２００２−７３１５３号公報に開示されるように、車両上で車両の状態を診断し、故障の発生が予測される場合に、通信機器を使ってその情報を整備機関に送信するシステムが知られている。このようなシステムによれば、車両が路上で走行不能状態に陥る前に、応急対策を講じたり、或いは、整備機関への入庫を促したりすることで、車両故障に伴う不便を有効に回避することが可能である。

特開２００２−７３１５３号公報 特開２００２−２０２００３号公報 特開２００２−２５０２４８号公報

しかしながら、上記従来のシステムは、車両の故障診断を車両上において完結し、その結果を送信する段階においてのみ外部機関との通信を利用するものである。このため、上記従来のシステムでは、実行すべき故障診断の処理に必要な全ての情報を、車両において記憶しておくことが必要であった。

更に、上記従来のシステムでは、車両の走行に影響を与えるような不具合が発生したら、その不具合が軽度であっても車両から外部機関への情報提供が行われる。車両が走行不能に陥るのを防ぐ意味では、走行不能に直結する不具合が検知されても、その不具合が軽微であり、即座に走行不能に陥ることがないような段階では、必ずしもその情報を車両から外部機関に送信する必要はない。この点、上記従来のシステムは、車両における情報処理の負荷を不必要に高めているという側面を有するものであった。

この発明は、上述のような課題を解決するためになされたもので、車両と外部機関との間で通信を行うことで車両故障に対する早期対策を講ずることができ、かつ、車両における情報処理負荷を十分に軽く抑えることのできる車両の故障診断システムを提供することを目的とする。

第１の発明は、上記の目的を達成するため、相互に通信可能な車両と情報センタとを含む車両の故障診断システムであって、
車両データを検出すべく車両に搭載された車両データ検出手段と、
前記車両データに基づいて車両の不具合を検出すべく、車両または情報センタに設けられた不具合検出手段と、
車両の不具合の発生を検知して、その不具合の原因を特定するための故障特定処理の実行を車両に対して指示すべく、情報センタに設けられた特定処理指示手段と、
指示された故障特定処理を実行すべく、車両に搭載された特定処理実行手段と、
前記故障特定処理の結果を情報センタに返信すべく、車両に搭載された特定処理結果返信手段と、
車両から返信されてきた故障特定処理の結果に基づいて故障個所を特定すべく、情報センタに設けられた故障個所特定手段と、
特定された故障に対する対策を講ずるべく情報センタに設けられ、特定された故障の影響を排除するための回復処理の実行を車両に対して指示する回復処理指示手段と、
指示された回復処理を実行すべく、車両に搭載された回復処理実行手段と、
前記回復処理の結果に基づいて回復処理の続行または終了を決定すべく、車両または情報センタに設けられた処理決定手段と、
を含むことを特徴とする。

また、第２の発明は、第１の発明において、
前記回復処理指示手段は、
最も重大な故障を記憶した最重大故障記憶手段と、
検知された故障が、最も重大な故障である場合にのみ前記回復処理の指示を発する回復対象限定手段と、
を含むことを特徴とする。

また、第３の発明は、第１又は第２の発明において、
前記特定処理指示手段は、
重大な不具合を記憶した重大不具合記憶手段と、
検知された不具合が、重大な不具合である場合にのみ前記故障特定処理の指示を発する特定対象限定手段と、
を含むことを特徴とする。

また、第４の発明は、相互に通信可能な車両と情報センタとを含む車両の故障診断システムであって、
車両データを検出すべく車両に搭載された車両データ検出手段と、
前記車両データに基づいて車両の不具合を検出すべく、車両または情報センタに設けられた不具合検出手段と、
車両の不具合の発生を検知して、その不具合の影響を排除するための回復処理の実行を車両に対して指示すべく、情報センタに設けられた回復処理指示手段と、
指示された回復処理を実行すべく、車両に搭載された回復処理実行手段と、
前記回復処理の結果に基づいて回復処理の続行または終了を決定すべく、車両または情報センタに設けられた処理決定手段と、
を含むことを特徴とする。

また、第５の発明は、第４の発明において、
前記回復処理指示手段は、
最も重大な不具合を記憶した最重大事項記憶手段と、
検知された不具合が、最も重大な不具合である場合にのみ前記回復処理の指示を指令する回復対象限定手段と、
を含むことを特徴とする。

また、第６の発明は、相互に通信可能な車両と情報センタとを含む車両の故障診断システムであって、
特定の不具合の発生に起因する不具合特性値を検出すべく車両に搭載された不具合特性値検出手段と、
前記不具合特性値の大きさに基づいて、検知された前記不具合の重大度を判定する不具合重大度判定手段と、
前記重大度が判定値を越える場合に限り、検知された前記不具合の情報を情報センタに提供する提供情報限定手段と、
車両から情報提供を受けた前記不具合の影響を排除するための回復処理の実行を車両に対して指示すべく、情報センタに設けられた回復処理指示手段と、
指示された回復処理を実行すべく、車両に搭載された回復処理実行手段と、
前記回復処理の結果に基づいて回復処理の続行または終了を決定すべく、車両または情報センタに設けられた処理決定手段と、
を含むことを特徴とする。

また、第７の発明は、第６の発明において、
前記提供情報限定手段は、前記不具合の情報として、前記不具合特性値を含む情報を情報センタに提供し、
前記回復処理指示手段は、
不具合の情報が車両から提供された場合に、前記不具合特性値に基づいて、その不具合を緊急を要する不具合として認識すべきか否かを判別する緊急度判別手段と、
車両から情報提供を受けた前記不具合が、緊急を要するものである場合に限り前記回復処理の指示を指令する回復対象限定手段と、
を含むことを特徴とする。

また、第８の発明は、第６又は第７の発明において、車両から情報提供を受けた前記不具合の原因を特定するための故障特定処理の実行を車両に対して指示すべく、情報センタに設けられた特定処理指示手段と、
指示された故障特定処理を実行すべく、車両に搭載された特定処理実行手段と、
前記故障特定処理の結果を情報センタに返信すべく、車両に搭載された特定処理結果返信手段と、
車両から返信されてきた故障特定処理の結果に基づいて故障個所を特定すべく、情報センタに設けられた故障個所特定手段と、
を含むことを特徴とする。

また、第９の発明は、第１乃至第３および第８の発明の何れかにおいて、
前記故障特定処理は、複数の検査モードを含んでおり、
前記故障個所特定手段は、
車両から返信されてきた故障特定処理の結果に基づいて、故障個所が特定できる場合に当該故障特定処理の完了を判定する特定処理完了手段と、
前記結果に基づいて、故障個所が特定できない場合には、その結果に対応する検査モードの開始を、前記特定処理指示手段に指示させる特定処理継続手段と、
を含むことを特徴とする。

また、第１０の発明は、第１乃至第９の発明の何れかにおいて、
前記車両データに基づいて車両に不具合が発生するまでの走行距離を推定すべく、車両または情報センタに設けられた不具合距離推定手段を備え、更に、
不具合発生までの前記走行距離を車両上に表示する不具合距離表示手段、および、前記走行距離を車両のメンテナンス工場に送信する不具合距離送信手段の少なくとも一方を備えることを特徴とする。

第１の発明によれば、車両において不具合が検出された場合に、その原因を特定するにあたり、車両は、故障特定処理の指示を情報センタから受けることができる。このため、本発明によれば、個々の不具合に対して実行すべき故障特定処理を車両において記憶しておく必要がなく、車両上での情報処理の負荷を軽減することができる。また、この発明によれば、不具合の原因たる故障が特定された後に、その故障の影響を排除するための回復処理を車両上で行うことができる。この際、車両は、実行すべき回復処理の指示を情報センタから受けることができる。このため、本発明によれば、個々の故障に対して実行すべき回復処理を車両において記憶しておく必要がなく、車両上での情報処理の負荷を軽減することができる。

第２の発明によれば、検知された故障が最も重大な故障である場合に限って回復処理を実行することができる。このため、本発明によれば、回復処理の実行に伴う処理負荷の発生を最小限に抑えることができる。

第３の発明によれば、検知された不具合が重大なものである場合に限って故障特定処理を実行することができる。このため、本発明によれば、故障特定処理の実行に伴う処理負荷の発生を最小限に抑えることができる。

第４の発明によれば、車両において不具合が検出された場合に、その不具合の影響を排除するための回復処理を車両上で行うことができる。この際、車両は、実行すべき回復処理の指示を情報センタから受けることができる。このため、本発明によれば、個々の不具合に対して実行すべき回復処理を車両において記憶しておく必要がなく、車両上での情報処理の負荷を軽減することができる。

第５の発明によれば、検知された不具合が最も重大なものである場合に限って回復処理を実行することができる。このため、本発明によれば、回復処理の実行に伴う処理負荷の発生を最小限に抑えることができる。

第６の発明によれば、車両において不具合の発生が認められた場合に、不具合特性値に基づいて、その不具合が緊急を要するものであるか否かを判断することができる。そして、緊急度が高ければ即座に対策を講ずることが必要な不具合であっても、緊急度が低く、即座の対策が不要である場合には、その不具合の情報を情報センタに提供する処理を省略することができる。このため、本発明によれば、無駄な通信を省くことができ、車両における処理負荷を有効に軽減することができる。また、この発明によれば、特定の不具合が大きな不具合特性値を伴って車両に発生した場合に、その不具合の影響を排除するための回復処理を車両上で行うことができる。この際、車両は、実行すべき回復処理の指示を情報センタから受けることができる。このため、本発明によれば、個々の故障に対して実行すべき回復処理を車両において記憶しておく必要がなく、車両上での情報処理の負荷を軽減することができる。

第７の発明によれば、車両から情報センタに不具合の情報が提供された場合に、その不具合が、緊急を要するものである場合に限って回復処理を実行することができる。このため、本発明によれば、回復処理の実行に伴う処理負荷の発生を最小限に抑えることができる。

第８の発明によれば、高い不具合特性値を伴う不具合が車両において検出された場合に、その原因を特定することができる。この際、車両は、故障特定処理の指示を情報センタから受けることができる。このため、本発明によれば、個々の不具合に対して実行すべき故障特定処理を車両において記憶しておく必要がなく、車両上での情報処理の負荷を軽減することができる。

第９の発明によれば、複数の検査モードを含む故障特定処理を車両上で実行させることができる。このため、本発明によれば、故障を特定するために複雑な処理を要するような故障内容についても、適切にその内容を特定することができる。

第１０の発明によれば、車両において不具合が発生すると予想されるまでの走行距離を推定し、その推定値を車両上に表示し、または、メンテナンス工場に送信することができる。このため、本発明を用いれば、不具合の発生前に事前に適切な早期対策を講ずることが可能となる。

実施の形態１．
［実施の形態１の構成］
図１は、本発明の実施の形態１の構成を説明するための概念図である。図１に示す通り、本実施形態のシステムは、ユーザが使用する車両１０と、情報センタ１２と、車両のメンテナンス機関を兼ねるディーラ１４とで構成される。これら３者の間では、後述する通り、互いに通信機器を用いて情報通信を行うことができる。

車両１０には、ECU(Electronic Control Unit)１６と、ディスプレイ１８と、通信機器２０が搭載されている。ECU１６は、車両１０の状態を制御するためのユニットであり、種々の車載センサから車両データを読みとることができ、また、種々の車載アクチュエータを駆動することができる。

ECU１６には、車室内に配置されるディスプレイ１８が接続されている。ディスプレイ１８は、車両の搭乗者に対して種々の情報を表示する装置であると共に、搭乗者による情報入力を可能とするインターフェースとしての機能も有している。ECU１６には、更に、通信機器２０が接続されている。ECU１６は、通信機器２０を介することにより、情報センタ１２やディーラ１４に設置されている機器との間で情報通信を行うことができる。

情報センタ１２には、コンピュータシステム２２と通信機器２４が設置されている。同様に、ディーラ１４にも、コンピュータシステム２６と通信機器２８が設置されている。これらのコンピュータシステム２２，２６は、通信機器２４，２８を介することで、相互に、また、車両１０との間で情報通信を行うことができる。

［実施の形態１における故障診断の概念］
本実施形態のシステムは、車両１０に生じた故障或いは不具合を３つのレベルに区分して認識する。以下、重要度および緊急度が最も低いものを「レベル１の故障または不具合」とし、重要度および緊急度が高くなるに連れ、それらを「レベル２の故障または不具合」、或いは「レベル３の故障または不具合」と称することとする。

（レベル１の故障または不具合）
本実施形態では、車両におけるメンテナンス情報がレベル１に分類される。具体的には、オイル劣化、オイル不足、タイヤ空気圧低下、タイヤ交換時期、エアコンガス圧低下、バッテリ機能低下、エンジンクーラント不足、ウォッシャ不足、ランプ点灯不良などの故障または不具合が、レベル１に分類される。レベル１の故障または不具合の発生時には、車両上で警報ランプを点灯するなどの処理が実行される。この場合、車両単体で故障診断の処理は完結する。

（レベル２の故障または不具合）
車両における異常ショックの発生、および燃費不良などは、レベル２に分類される。異常ショックの発生は、例えば、車載の加速度センサにより検知することができる。また、燃費不良は、固定された基準条件下（例えば、アイドル時、或いは４０km/h定常走行時など）での燃料消費量を、基準値と比較することにより検知することができる。

これらの異常は、通常は即座に車両停止に結びつくものではないが、レベル１の故障等とは異なり、何らかの異常が原因となり発生していると思われると共に、車両１０の搭乗者に対して違和感を与え易い。そこで、本実施形態のシステムは、レベル２の故障または不具合が検知された場合には、その原因である故障の特定を試み、その特定の結果情報をディーラ１４に提供することで、故障に対する早期対策を可能ならしめることとしている。そして、故障を特定する際には、ECU１０が担う負荷を軽減すべく、ECU１０と情報センタ１２との間で情報通信を行いつつ、その特定のための処理の一部を情報センタ１２内で行うこととしている。

（レベル３の故障または不具合）
本実施形態では、車両停止に直接結びつく故障または不具合がレベル３に区分される。具体的には、エンジンストールの前兆である機関回転数Neの異常低下、加速不良、異音発生、異常ノックの発生、プレイグニッションの発生などがレベル３に区分される。機関回転数Neの異常低下は、例えばアイドル時における回転数センサの出力に基づいて検知することができる。加速不良は、例えばスロットル開度または吸入空気量の増加に対して、適正な加速が生じているか否かを見ることで検知可能である。

異音の発生は、例えば、エンジンルームに取り付けたマイクの出力に基づいて検知することができる。より具体的には、そのマイクの出力に周波数解析と、パターン認識を施すことで、異音の発生箇所、つまり異音の発生源を特定することができる。そして、本実施形態では、内燃機関の本体など、車両の走行上重要な部位で音圧レベルの高い異音が生じている場合に、その異音がレベル３の故障または不具合として認識される。

異常ノックの発生は、振動センサ、若しくは筒内圧センサにより検出することができる。また、プレイグニッションの発生は、筒内圧センサにより、或いは、燃焼開始のタイミングと点火プラグの放電タイミングとでイオン電流を比較することにより検知することができる。

これらの異常は、車両を走行不能な状態となる前兆として捕らえることができる。このため、車両においてレベル３の故障または不具合が検知された場合には、速やかに原因を特定して、適切なメンテナンスを施すことが望ましい。そして、車両１０をディーラ１４に搬送する過程では、可能な限り車両１０が自走できることが望ましい。そこで、本実施形態のシステムは、レベル３の故障または不具合が検知された場合には、その原因である故障の特定を試み、その特定の結果情報をディーラ１４に提供すると共に、車両１０に対して、その故障または不具合の影響を排除するための回復措置を施すこととした。そして、故障を特定する際、および回復措置を施す際には、ECU１０が担うべき負荷を軽減すべく、ECU１０と情報センタ１２との間で情報通信を行いつつ、必要な処理の一部を情報センタ１２で実行させることとした。

（車両１０、情報センタ１２およびディーラ１４の役割）
図２は、レベル２およびレベル３の故障または不具合の発生時における故障診断の概要を説明するための図である。尚、レベル１の故障または不具合に対する故障診断の処理は、車両１０上で完結する処理であり、特に新規な事項を含んでいないため、ここでは、その詳細な説明を省略する。

車両１０では、レベル２およびレベル３の故障または不具合と密接に関係する種々の車両データが検出されている。例えば、燃料消費量（レベル２の燃費不良の基礎データ）を算出するための燃料噴射時間および燃料噴射率、エンジンストール（レベル３）の判断の基礎となる機関回転数、異常ノックやプレイグニッション（何れもレベル３）判断の基礎となる筒内圧センサ出力などが、所定のサンプリングタイミングにて検出されている。これらの車両データは、図２に示すように、車両１０から情報センタ１２へ送信される。

情報センタ１２では、車両１０から送られてきた車両データが解析され、重大な異常、つまり、レベル２またはレベル３の故障或いは不具合が発生したかが判断される。具体的には、燃料消費量が時系列で大きく悪化（増加）していなか、機関回転数Neに異常な低下は生じていないか、或いは、筒内圧センサにより異常ノックやプレイグニッションに対応する筒内圧変化が検出されていないか、等が判断される。

情報センタ１２において、重大な異常が認められない場合は、車両１０から情報センタ１２への車両データの送信が繰り返し行われる。一方、重大な異常の発生が認められた場合は、情報センタ１２から車両１０へ、異常の原因である故障の特定が指示される。例えば、機関回転数Neの異常低下が認められた場合は、その原因が内燃機関のフリクション増加であるのか、或いは各種補機類のフリクション増加であるのかを特定すべく予め定められた特定処理に則った動作パターンが、車両１０に対して求められる。

車両１０は、指示に応じた特定処理を実行した後、その処理の結果として発生する車両データを診断データとして情報センタ１２に送信する。例えば、内燃機関のフリクション増加を診断するモードでは、吸入空気量Gaと機関回転数Neとの組み合わせデータが情報センタに送信される。また、各種補機類のフリクション増加を診断するモードでは、個々の補機類の作動前後におけるGaとNeの組み合わせが情報センタ１２に送信される。

情報センタ１２では、車両１０から提供されてきた車両データにより、故障個所が特定できたか否かが判断される。その結果、未だ特定が完了していないと判断された場合は、更に特定を進めるための特定指令が発せられる。一方、特定の完了が認められた場合は、特定された故障の情報が、ディーラ１４に提供される。ディーラ１４は、この情報を受けて、故障に対する早期対策を実施する。具体的には、ユーザへの連絡、車両１０の修理に必要な部品の事前調達などの作業を開始する。

情報センタ１２では、故障が特定された段階で、更に、特定された故障が回復措置の必要な故障、つまり、レベル３の故障または不具合であるかが判断される。その結果、レベル３の故障または不具合であるとの判断がなされると、車両１０に対して回復措置の指令が発せられる。具体的には、特定された故障が内燃機関のフリクション増加である場合は、アイドル空気量の増量が指示される。また、各種補機類の何れかのフリクション増加が特定された場合は、その補機類の作動に伴う空気の増量補正量を増やす指示がなされる。更に、プレイグニッションなど、車両１０上での回復が困難な不具合が特定された場合には、回復措置として、ディーラへの緊急入庫がユーザ（車両１０）に対して指示される。

［実施の形態１における具体的処理］
（全体処理）
図３は、上記の概念に沿った処理が進められるべく車両１０、情報センタ１２およびディーラ１４のそれぞれにおいて実行される具体的処理の内容を説明するためのフローチャートである。この図に示す通り、車両１０においては、ECU１６により、車両１０の状態に関わる数多くの車両データが検出される（ステップ１００）。これらの車両データのうち、レベル２およびレベル３に区分された故障または不具合に関するものは情報センタ１２にデータ送信される（ステップ１０２）。

情報センタ１２では、車両１０からのデータが受信されると（ステップ１１０）、先ず、そのデータがコンピュータシステム２２のデータベースに記憶される（ステップ１１２）。ここでは、具体的には、データを送信してきた車両１０のIDと、送信されてきた車両データの内容とが記憶される。次に、受信した最新の車両データと、データベースに記憶されている過去の車両データとを基礎として、車両１０の故障診断が行われる（ステップ１１４）。具体的には、レベル２およびレベル３に区分される上記の故障または不具合につき、その発生が認められるか否かが、ひとつずつ判断される。

上記の診断の後、レベル２またはレベル３に属する重大な故障または不具合が発見されたか否かが判断される（ステップ１１６）。その結果、重大な故障等の発生が認められなかった場合、情報センタ１２のコンピュータシステム２２は、再び車両データを待ち受ける状態に戻る。一方、重大な故障等の発生が認められた場合は、情報センタ１２において故障特定処理が開始される（ステップ１１８）。

故障特定処理が開始されると、先ず、情報センタ１２から車両１０に対して、特定処理の開始が指令される。次に、情報センタ１２では、実行すべき特定処理が選択される。情報センタ１２には、予め、検知された故障または不具合と、それらの故障または不具合の原因たる故障を特定するための特定処理との対応が記憶されている。ここでは、その記憶に従って、実行すべき特定処理が選択される。このようにして特定処理が選択されると、情報センタ１２から車両１０に対して、その特定処理を進めるうえで最初に実行すべき処理の内容と、その実行の後に確認すべき車両データ（以下、「要求診断データ」とする）とが指示される。

車両１０は、情報センタ１２により発せられた特定指令を受信すると（ステップ１２０）、要求診断データを取得するための処理を開始する（ステップ１２２）。ここでは、具体的には、情報センタ１２により指示された処理が実行され、その処理の結果として生じた特定の車両データが要求診断データとして取得される。このようにして取得された要求診断データは、車両１０から情報センタ１２に送信される（ステップ１２４）。その後、車両１０では、特定完了の指令が受信されるまで（ステップ１２６）、上記ステップ１２２以降の処理が繰り返される。

情報センタ１２は、故障特定処理の実行過程において、車両１０から要求診断データが返信されてくると、そのデータにより故障内容が特定されたか否かを判断する。その結果、故障内容の特定には更なる処理が必要であると判断された場合は、車両１０に対して、次に実行すべき処理の内容と、その処理に対応する要求診断データとが指示される。車両１０は、この指示を受けると、上記ステップ１２２および１２４の処理を実行して、情報センタ１２に対して要求診断データを返信する。

情報センタ１２において、受信した要求診断データにより故障の特定が完了したと判断されると、その旨の指令が情報センタ１２から車両１０に送信される。車両１０においては、この指令により上記ステップ１２６の条件成立が判定される。その結果、情報センタ１２および車両１０の双方において、故障特定処理が終了される。尚、故障特定処理については、後に図４乃至図６を参照して、更に具体的な内容を詳細に説明する。

情報センタ１２は、車両１０の故障が特定されると（ステップ１３０）、先ず、その特定された故障の情報をディーラ１４に送信する（ステップ１３２）。次に、情報センタ１２では、特定された故障が、回復措置を必要とするものであるか、つまり、レベル３の故障または不具合に属するものであるかが判別される（ステップ１３４）。その結果、回復措置の必要性が認められた場合は、速やかに回復処理が開始される（ステップ１３６）。

ディーラ１４は、情報センタ１２から特定故障データが送信されてくるのを待ち受けている（ステップ１４０）。そして、特定故障データを受信すると、先ず、車両１０のIDと、その特定故障データの内容とを、コンピュータシステム２６のデータベースに記憶する（ステップ１４２）。

次に、特定された故障が、早期対策を要するものであるか否かが判別される（ステップ１４４）。その結果、早期対策の必要が認められれば、ユーザへの連絡（電子メール等）や、交換部品の事前発注が自動的に行われる（ステップ１４６）。

情報センタ１２において、上記の回復処理（ステップ１３６）が開始されると、先ず、車両１０に対して回復処理の開始が指令される。次に、情報センタ１２では、実行すべき回復処理が選択される。情報センタ１２には、予め、特定された故障と、その故障の影響を排除するための回復処理との対応が記憶されている。ここでは、その記憶に従って、実行すべき回復処理が選択される。このようにして回復処理が選択されると、情報センタ１２から車両１０に対して、その回復処理を進めるうえで実行するべき処理の内容と、その実行の後に確認すべき車両データ（以下、「回復確認データ」とする）とが指示される。

車両１０においては、情報センタ１２から上記の回復指令が発せられると（ステップ１５０）、その指令に応じた回復措置が実施される（ステップ１５２）。そして、その回復措置の講じられた後に生じた特定の車両データが回復確認データとして取得される。このようにして取得された回復確認データは、車両１０から情報センタ１２に送信される（ステップ１５４）。その後、車両１０では、回復確認の指令が受信されるまで（ステップ１５６）、上記ステップ１５２以降の処理が繰り返される。

情報センタ１２は、回復処理の実行過程において、車両１０から回復確認データが返信されてくると、そのデータを解析して、故障の影響が排除されているか否かを判断する。その結果、故障の影響が排除されていないと判断された場合は、車両１０に対して、更なる回復措置の実行が指示される。車両１０は、この指示を受けると、上記ステップ１５２および１５４の処理を実行して、情報センタ１２に対して回復確認データを返信する。

情報センタ１２は、回復確認データにより故障の影響の排除を認めると、回復確認の旨が情報センタ１２から車両１０に指令される。車両１０においては、この指令により上記ステップ１５６の条件成立が判定される。その結果、情報センタ１２および車両１０の双方において、回復処理が終了される。尚、回復処理については、後に図７を参照して、更に具体的な内容を詳細に説明する。

（故障特定処理の一例）
図４は、情報センタ１２において実行される故障特定処理の一例のフローチャートを示す。図４に示す故障特定処理は、機関回転数Neの異常低下に対応するものである。本実施形態では、内燃機関は、通常、機関回転数Neが４００rpmを下回ることがないように設定されている。このため、本実施形態では、４００rpmを下回る機関回転数Neが検知されると、Neの異常低下が判定される。この場合、情報センタ１２では、その原因たる故障を特定するため、図４に示す手順で故障特定処理が進められる。

尚、ここでは、機関回転数Neの異常低下を、エンジンストールに直結する不具合として捕らえることとしているが、エンジンストールに直結する不具合として把握できるものはこれに限定されるものではない。例えば、筒内圧センサにより検出される筒内圧が異常に低圧であった場合、或いは、トルクセンサにより検知された内燃機関の出力トルクが異常に小さかった場合などに、エンジンストールに直結する不具合の発生を認識することとしてもよい。

図４に示す故障特定処理では、先ず、機関負荷が異常であるか否かを確認するための特定処理が開始される（ステップ１６０）。ここでは、具体的には、情報センタ１２から車両１０に対して、基準負荷状態（エアコン、オルタネータ、パワステなど、負荷を生ずる補機その他の機器（以下、「補機類」と称す）を全て作動させた状態）で吸入空気量Ga（エアフロメータ；AFM計測空気量）と機関回転数Neとを計測し、それら（要求診断データ）を返信することが要求される。

図５は、基準負荷状態におけるAFM計測空気量Gaと機関回転数Neとの関係を示す。機関回転数Neは、負荷が一定である場合には、空気量Gaに対してほぼ一義的に決まる値であるから、両者の正常な関係は図５に示すように予め定めておくことができる。情報センタ１２は、要求診断データとして返信されてきたNeが、同時に返信されてきたGaに対して不当に低い場合には、内燃機関の負荷が異常であると判断する。この場合、故障を特定するために、更に、負荷異常検出ルーチンが開始される（ステップ１６２）。

負荷異常検出ルーチンでは、情報センタ１２から車両１０に対して、空気量Gaを一定にしたまま補機類の一つ一つを強制駆動または強制停止させること、およびそれぞれの補機類の始動または停止の前後の機関回転数Neの変化量を要求診断データとして返信することが順次要求される。補機類の一つ一つが作動または停止すると、内燃機関の負荷が変化し、機関回転数Neに変化が生ずる。情報センタ１２は、補機類のそれぞれに対して発生するべきNe変化量を記憶しており、要求診断データとして送信されてくるNe変化量をその記憶値と比較することにより、個々の補機類の負荷が適正なものであるか否かを判断する。

情報センタ１２は、補機類の何れかにおいて不当に大きなNe変化量が確認された場合は、その補機類が故障していると判断する。一方、補機類の何れにも故障が認められなかった場合は、内燃機関本体にフリクションの増加を伴う故障が生じているか、或いは駆動系に故障が生じていると判断する。このようにして故障個所が特定されると、既述した通り情報センタ１２から車両１０へ特定完了の指令が出されて故障特定処理が終了されると共に、情報センタ１２からユーザ（車両１０）およびディーラ１４へ、特定された故障の情報が提供される。

情報センタ１２は、上記ステップ１６０において実行された特定処理により、内燃機関の負荷異常が認められなかった場合には、次に、アイドルスピードコントロール弁（ISC弁）につまりが生じているか否かを確認するための特定処理を開始する（ステップ１６４）。ここでは、具体的には、情報センタ１２から車両１０に対して、ISC制御量（弁開度、或いは駆動デューティ）と、AFM計測空気量Gaとを計測し、それら（要求診断データ）を返信することが要求される。

図６は、ISC制御量とAFM計測空気量Gaとの関係を示す。両者は、本来、ほぼ比例的な関係を満たすものであり、その正常な関係は図６に示すように予め定めておくことができる。情報センタ１２は、要求診断データとして返信されてきたAFM計測空気量Gaが、同時に返信されてきたISC制御量に対して不当に少量である場合には、ISC弁につまりが生じていると判断する（ステップ１６６）。このようにして故障個所が特定されると、情報センタ１２から車両１０へ特定完了の指令が出されて故障特定処理が終了されると共に、情報センタ１２からユーザ（車両１０）およびディーラ１４に、ISC弁の異常と、その清掃または交換の必要性が連絡される。

情報センタ１２は、上記ステップ１６４において実行された特定処理により、ISC弁のつまりが認められなかった場合には、次に、ISC弁に断線またはショートが生じていないかを確認するための特定処理を開始する（ステップ１６８）。ここでは、具体的には、情報センタ１２から車両１０に対して、ISC弁の端子電圧を計測し、その計測値を要求診断データとして返信することが要求される。

ISC弁の駆動回路に断線またはショートが生じていると、ISC弁の端子電圧は異常値となる。情報センタ１２は、要求診断データとして返信されてきた端子電圧が、予め定められている正常値から大きく乖離している場合には、ISC弁に断線またはショートが生じていると判断する（ステップ１７０）。このようにして故障個所が特定されると、情報センタ１２から車両１０へ特定完了の指令が出されて故障特定処理が終了されると共に、情報センタ１２からユーザ（車両１０）およびディーラ１４に、ISC弁の断線またはショートと、配線チェック或いは交換の必要性が連絡される。

尚、上記の例では、ISC弁の断線・ショートを端子電圧に基づいて診断することとしているが、その断線・ショートを診断する手法は、これに限定されるものではない。例えば、ISC弁を強制的に操作して、その結果生ずるISC制御量とAFM計測空気量Gaとの関係が適正であるか否かを見ることで断線の有無を判断してもよい。更に、ISC弁の端子電流が正常であるか否かにより、その判断を行うこととしてもよい。

情報センタ１２は、上記ステップ１６８において実行された特定処理により、ISC弁の断線またはショートが認められなかった場合には、次に、ISC弁に固着が生じているか否かを確認するための特定処理を開始する（ステップ１７２）。ここでは、具体的には、情報センタ１２から車両１０に対して、ISC弁の操作量（開度指令）と現実の開度（開度センサの出力）を要求診断データとして返信することが要求される。

ISC弁に固着が生じていると、操作量に応じた開度は生じない。情報センタ１２は、要求診断データとして返信されてきた操作量と開度が適正な対応を満たしていない場合は、ISC弁に固着が生じていると判断する（ステップ１７４）。このようにして故障個所が特定されると、情報センタ１２から車両１０へ特定完了の指令が出されて故障特定処理が終了されると共に、情報センタ１２からユーザ（車両１０）およびディーラ１４に、ISC弁の固着と、清掃或いは交換の必要性が連絡される。

尚、上記の例では、ISC弁が開度センサを備えることが前提とされているが、開度センサが備わっていない場合には、開度の代わりにAFM計測空気量Gaを、固着発生の判断の基礎としてもよい。また、上記の例では、ISC弁の制御量と開度（またはAFM計測空気量Ga）とが、静的に適正な関係を満たしているか否かに基づいて固着の発生を判断することとしているが、その判断の手法はこれに限定されるものではない。例えば、ISC弁を強制的に駆動し、その際の制御量の変化量と、開度またはAFM計測空気量Gaの変化量とが、適正に対応しているか否かに基づいて固着の発生を判断することとしてもよい。

情報センタ１２は、上記ステップ１７２において実行された特定処理により、ISC弁の固着が認められなかった場合は、ISC弁は正常であると判断する。そして、この場合は、内燃機関の吸気系全体につまりが生じていると判断する（ステップ１７６）。この場合、情報センタ１２は、ユーザ（車両１０）およびディーラ１４に対して、吸気系全体のつまり、および、エアクリーナの清掃または交換の必要性などを連絡する。

以上説明した通り、本実施形態のシステムは、レベル２またはレベル３の故障或いは不具合を検知すると、その後、情報センタ１２と車両１０との間で適宜情報通信を行いつつ、その故障または不具合の原因たる故障を特定することができる。この際、故障を特定するための主要な情報処理が情報センタ１２において実行されるため、車両１０上のECU１６が担う負荷は十分に軽く抑えられている。このため、本実施形態のシステムによれば、車載されるECU１６に対してさほど高い処理能力を要求することなく、重大な故障を特定し、その故障情報をディーラ１４等の外部機関と共有する機能を実現することができる。

（回復処理の一例）
情報センタ１２は、特定された故障がレベル３の故障に該当する場合は、既述した通り、その故障の影響を排除するための回復処理を実行する。図７は、その回復処理を実現するために情報センタ１２において実行されるフローチャートの一例である。図７に示す回復処理は、機関回転数Neの異常低下が検知された場合、より具体的には、その異常低下の原因がエアコン負荷の異常増加であると特定された場合に実行される処理である。

図７に示す回復処理では、先ず、エアコンの作動時における吸入空気量Gaの増量補正量を所定値だけ増量する指令が車両１０に対して発せられる（ステップ１８０）。車両１０においては、エアコンの作動に伴う機関回転数Neの低下を防ぐべく、その作動時には基本の吸入空気量Gaに対してエアコン補正量が加算される。本ステップ１８０の指示を受け、車両１０においては、そのエアコン補正量を増量する処理が行われる。その結果、エアコン負荷の増大に関わらず、その差動時における機関回転数Neの低下が抑制される。

情報センタ１２では、次に、上述したエアコン補正量の増量に伴って、アイドル時における吸入空気量がISCガード値を越える事態が生じたか否かが判別される（ステップ１８２）。車両１０においては、アイドル時に不要な高出力が発生しないように、アイドル吸入空気量に対してISCガードが設定されている。このため、エアコン補正量の増量に伴い、吸入空気量Gaの指令がそのガードを越える場合は、現実の吸入空気量Gaがガードに規制されることから、エアコン補正量の増量要求が完全には満たされない事態が生ずる。

そこで、情報センタ１２は、アイドル時の吸入空気量GaがISCガード値を越えると判断された場合には、そのような事態が生じない値までISCガード値を上方に修正するよう、車両１０に対して指示を発する（ステップ１８４）。このため、車両１０においては、ISCガードの存在に関わらず、エアコン補正量に対して要求された増量分を現実にアイドル時における吸入空気量Gaに確実に反映させることができる。

情報センタ１２は、車両１０に対してエアコン補正量の増量を指示する際に、その増量後に計測されたアイドル回転数Neを適宜返信することを併せて要求している。そして、そのアイドル回転数Neの返信を受けると、その値に基づいて機関回転数Neが正常値、つまり、４００rpm以上に回復しているか否かを判断する（ステップ１８６）。

上記の判別の結果、機関回転数Neが正常値に回復していないと判別された場合は、再び上記ステップ１８０以降の処理が実行され、エアコン補正量の再度の増量が図られる。一方、機関回転数Neの回復が認められた場合は、その回復が一定期間にわたって継続して認められたか否かが判別される（ステップ１８８）。

機関回転数Neの回復期間が、未だ所定の期間に達していないと判断された場合は、再び上記ステップ１８６の処理が実行される。そして、それらの処理が繰り返されることにより、一定期間の経過が認められた場合は、機関回転数Neの回復が確認され、その旨の指令が車両１０に対して送信される（ステップ１９０）。その結果、車両１０においても回復処理の終了が認識される（上記ステップ１５６参照）。

機関回転数Neの異常低下は、エアコンの負荷に異常増加が発生した場合の他、他の補機類に負荷の増加が生じた場合、内燃機関本体にフリクションの増加が生じた場合、更には、ISC弁につまり、断線、ショート、或いは固着が生じた場合にも発生する。エアコン以外の他の補機類に負荷増加が生じた場合は、エアコンに負荷増加が生じた場合と同様に、補正空気量を増量することで機関回転数Neの回復を図ることができる。また、内燃機関本体にフリクション増加が生じた場合は、基本の吸入空気量を増量することでその回復を実現することができる。そして、ISC弁につまり、断線、ショートまたは固着が発生した場合は、電子スロットルやパワステ用空気量制御弁など、ISC弁と併用されている他の空気量制御機器により要求空気量を補償することでその故障の影響を排除することができる。つまり、本実施形態のシステムは、機関回転数Neの異常低下が検知された場合に、特定された故障の内容に応じて、適宜上記の対策が講じられるように適切な回復処理を行うことで、機関回転数Neを適正に回復させることができる。

本実施形態において、回復処理の対象とされているレベル３の故障または不具合には、上記の例示に係る機関回転数Neの異常低下の他、加速不良、異音発生、異常ノックの発生、およびプレイグニッションの発生などが含まれている。これらの故障のうち、例えば加速不良については、その原因が吸入空気量の不足である場合は、可能な限りで空気量の増量を図ることにより故障の影響を排除することができる。また、異常ノックの発生については、点火時期を修正することによりその影響を排除することができる。本実施形態のシステムは、これらの場合のように、車両１０上で制御量を修正することで故障の影響が排除できる場合には、その影響を排除するための処理を回復処理として実行する。そして、車両１０上での措置では故障の影響が排除できない場合（プレイグニッション等の場合）は、速やかな入庫の必要性をユーザに警報する処理を回復処理として実行する。

以上説明した通り、本実施形態のシステムは、車両１０において重大な故障または不具合（レベル２またはレベル３に属するもの）が発生した場合に、その原因たる故障を車両１０上で特定することができる。更に、特定された故障が緊急度の高いもの（レベル３に属するもの）である場合は、その影響を排除するための回復処理を速やかに車両１０に施すことができる。このため、本実施形態のシステムによれば、車両１０が路上で走行不能な状態に陥るような事態の発生を、有効に未然防止することができる。

更に、本実施形態のシステムによれば、故障を特定するための主要な処理（特定処理）、および特定された故障の影響を排除するための主要な処理（回復処理）を、情報センタ１２において実行させることができる。このため、本実施形態のシステムによれば、車載ECU１６にさほど重い負荷が担わせることなく、上述した優れた効果を実現することができる。

ところで、上述した実施の形態１においては、車両データに基づいてレベル２またはレベル３に属する故障または不具合を検知するための故障診断処理（上記ステップ１１４）を、情報センタ１２において実行することとしているが、本発明はこれに限定されるものではない。すなわち、故障診断処理は車両１０において実行し、車両１０から情報センタ１２へは、検出された故障または不具合の情報のみを送信することとしても良い。

また、上述した実施の形態１においては、検知された故障または不具合の原因たる故障を特定するにあたり、情報センタ１２から車両１０に、逐次実行すべき特定処理を指示し、かつ、車両１０から情報センタ１２へ逐次得られた要求診断データを返信することとしているが、本発明はこれに限定されるものではない。すなわち、情報センタ１２は、検知された故障または不具合の原因を特定するために実行されるべき一連の処理の開始点のみを車両１０に対して指示し、以後の処理は、故障の特定が完了するまで車両１０において完結させ、その結果特定された故障の情報のみを車両１０から情報センタ１２に返信させることとしてもよい。

また、上述した実施の形態１においては、特定された故障の影響を排除するための回復処理を進めるに当たり、情報センタ１２から車両１０に、逐次実行すべき処理の内容を指示し、かつ、車両１０から情報センタ１２へ逐次得られた措置後データを返信することとしているが、本発明はこれに限定されるものではない。すなわち、情報センタ１２は、特定された故障に対して実行するべき回復処理の内容のみを一回だけ指示し、以後、回復が完了するまでの処理は、車両１０において完結させることとしてもよい。

尚、上述した実施の形態１においては、車両１０において上記ステップ１００の処理が実行されることにより前記第１の発明における「車両データ検出手段」が、情報センタ１２において上記ステップ１１４の処理が実行されることにより前記第１の発明における「不具合検出手段」が、情報センタ１２において上記ステップ１１８の処理が実行されることにより前記第１の発明における「特定処理指示手段」および「故障個所特定手段」が、車両１０において上記ステップ１２２の処理が実行されることにより前記第１の発明における「特定処理実行手段」が、車両１０において上記ステップ１２４の処理が実行されることにより前記第１の発明における「特定処理結果返信手段」が、情報センタ１２において上記ステップ１３４および１３６の処理が実行されることにより前記第２の発明における「回復処理指示手段」および「処理決定手段」が、車両１０において上記ステップ１５２の処理が実行されることにより前記第２の発明における「回復処理実行手段」が、それぞれ実現されている。

また、上述した実施の形態１においては、情報センタ１２が上記ステップ１３４の処理を実行することにより前記第２の発明における「最重大故障記憶手段」および「回復対象限定手段」が、それぞれ実現されている。

また、上述した実施の形態１においては、情報センタ１２が上記ステップ１１６の処理を実行することにより前記第３の発明における「重大不具合記憶手段」および「特定対象限定手段」が、それぞれ実現されている。

また、上述した実施の形態１においては、車両１０において上記ステップ１００の処理が実行されることにより前記第４の発明における「車両データ検出手段」が、情報センタ１２において上記ステップ１１４の処理が実行されることにより前記第４の発明における「不具合検出手段」が、情報センタ１２が上記ステップ１３４および１３６の処理を実行することにより前記第４の発明における「回復処理指示手段」および「処理決定手段」が、車両１０において上記ステップ１５２の処理が実行されることにより前記第４の発明における「回復処理実行手段」が、それぞれ実現されている。

また、上述した実施の形態１においては、情報センタ１２において、上記ステップ１３４の処理が実行されることにより前記第５の発明における「最重大事項記憶手段」および「回復対象限定手段」が、それぞれ実現されている。

また、上述した実施の形態１においては、情報センタ１２において、図４に示すステップ１６２，１６６，１７０，１７４または１７６の処理が実行されることにより前記第９の発明における「特定処理完了手段」が、上記ステップ１６０，１６４，１６８および１７２において条件の不成立が判定される場合に前記第９の発明における「特定処理継続手段」が、それぞれ実現されている。

実施の形態２．
次に、再び図３を参照して、本発明の実施の形態２について説明する。本発明の実施の形態２は、実施の形態１の場合と同様のハードウェア構成を用いて実現することができる。上述した実施の形態１のシステムは、エンジンストールの前兆である機関回転数Neの異常低下、加速不良、異音、異常ノックおよびプレイグニッションの何れをも、無条件でレベル３の故障または不具合として取り扱うこととしている。

しかしながら、例えば、機関回転数Neの異常低下については、Neが４００rpmを僅かに低下した程度では、その後即座にエンジンがストールする可能性は高くない。つまり、機関回転数Neの異常低下についていえば、Neが４００rpm程度に低下した段階では、必ずしも緊急に対策を講ずる必要がなく、その段階で故障特定処理や回復処理を実行することは、不必要にECU１６やコンピュータシステム２２の負荷を高めることになりかねない。

加速不良や異音や異常ノックについても同様であり、これらの故障または不具合は、必ずしも常にレベル３の故障または不具合として認識する必要はない。むしろ、ECU１６やコンピュータシステム２２の負荷を不当に高めないためには、それらの故障または不具合については、程度の軽重を区別して、程度の重いものだけをレベル２またはレベル３に区分し、更に、最も程度の重いものだけをレベル３に区分して、故障特定制御の対象、および回復制御の対象を限定することが適切である。

そこで、本実施形態のシステムは、機関回転数Neの異常低下を３段階に区別し、Ne＜２００rpmの場合のみをレベル３、２００rpm≦Ne＜３００rpmの場合をレベル１、および３００rpm≦Ne＜４００rpmの場合をレベル１として取り扱うこととした。同様に、本実施形態では、加速不良、異音、および異常ノックについても３段階の区分けを行い、最も程度の重い場合のみをレベル３、これに準ずるものをレベル２、最も程度の軽いものはレベル１として取り扱うこととした。

これらの場合において、加速不良については、検出された加速度または車速変化の大きさに基づいて３段階の区分けが行われる。また、異音については、異音の発生源として特定された部位および音圧レベルに基づいて３段階の区分けが行われる。そして、異常ノックについては、ノックセンサ等で検出されたノック強度に基づいて３段階の区分けが行われる。尚、プレイグニッションについては、その強度に関わらず常に高い緊急度を認識すべきであるから、本実施形態においても、常にレベル３の故障または不具合として認識することとしている。

以上説明した機能を実現するべく、本実施形態のシステムでは、図３に示すステップ１０２において、車両１０のECU１６は、上記の定義に従ってレベル２またはレベル３に区分される車両データのみを情報センタ１４に送信する。一方、情報センタ１２のコンピュータシステム２２は、図３に示すステップ１１６において、上記の定義に従ってレベル２またはレベル３に区分される故障または不具合のみを重大な故障等と判定し、更に、ステップ１３４においては、上記の定義に従ってレベル３に区分される故障等のみを回復措置の必要な故障等と判定する。

このため、本実施形態のシステムでは、機関回転数Neの異常低下や異常ノックの発生が認められても、それらがレベル１に区分される場合には、車両１０と情報センタ１２の間での情報通信が省略される。更に、それらがレベル２に区分される場合には、故障特定処理は実行されると、回復処理の実行が差し控えられる。このため、本実施形態のシステムによれば、実施の形態１のシステムに比して、ECU１６やコンピュータシステム２２の演算負荷をより少なくすることができる。

尚、上述した実施の形態２においては、Neの異常低下に伴う機関回転数Ne、加速不良に伴う加速度や車速変化、異音の発生に伴うマイク出力、異常ノックの発生に伴うノック強度等が前記第６の発明における「不具合特性値」に相当し、ECU１６が上記ステップ１００において、それらの不具合特性値を検出することにより前記第６の発明における「不具合特性値検出手段」が、上記ステップ１０２の処理を実行することにより前記第６の発明における「不具合重大度判定手段」および「提供情報限定手段」が、それぞれ実現されている。

また、上述した実施の形態２においては、情報センタ１２において、上記ステップ１３４および１３６の処理が実行されることにより前記第６の発明における「回復処理指示手段」および「処理決定手段」が、車両１０において上記ステップ１５２の処理が実行されることにより前記第６の発明における「回復処理実行手段」が、それぞれ実現されている。

また、上述した実施の形態２においては、情報センタ１２において、上記ステップ１３４の処理が実行されることにより前記第７の発明における「緊急度判別手段」および「回復対象限定手段」が、それぞれ実現されている。

また、上述した実施の形態２においては、情報センタ１２において上記ステップ１１８の処理が実行されることにより前記第８の発明における「特定処理指示手段」および「故障個所特定手段」が、車両１０において上記ステップ１２２の処理が実行されることにより前記第８の発明における「特定処理実行手段」が、上記ステップ１２４の処理を実行することにより前記第８の発明における「特定処理結果返信手段」が、それぞれ実現されている。

実施の形態３．
次に、図８乃至図１１を参照して、本発明の実施の形態３について説明する。本実施形態のシステムは、実施の形態１のハードウェアにおいて、ECU１６およびコンピュータユニット２２，２６に、上記図３に示す流れに沿った処理に変えて、後に図９を参照して説明する流れに沿った処理を実行させることにより実現することができる。

車両１０において検出される車両データ１０には、内燃機関等の経時変化が反映されるものがある。例えば、一定の負荷条件における機関回転数Neは、内燃機関のフリクションの増減に対して相関を示す。図８は、アイドル時における同一の負荷条件下で計測された機関回転数Neと、車両１０の走行距離との関係を示したものである。

内燃機関のフリクションは、一般に、機関のならしが進むに連れて小さくなる。このため、図８に示す機関回転数Neは、走行距離の小さな領域では、その距離に対して比例的に上昇傾向を示す。そして、その機関回転数Neは、走行距離が十分に増えて各部の摩耗が進行すると、走行抵抗の増加に伴い低下傾向に転ずる。

アイドル時における機関回転数Neについては、内燃機関が安定作動を続けるために必要な下限値が存在している。図８に示すNGレベルは、その下限値を示している。機関回転数Neの下限値が予め定められており、かつ、機関回転数Neの走行距離に対する低下傾向が把握できれば、現実のNeがNGレベルに達するまでの走行距離の猶予を推測することができる。そこで、本実施形態では、その走行距離の猶予を情報センタ１２において推測し、その結果を車両１０のメンテナンス情報として利用することとした。

図９は、上記の機能を実現するために車両１０、情報センタ１２およびディーラ１４のそれぞれにおいて実行される具体的処理の内容を説明するためのフローチャートである。この図に示す通り、車両１０においては、ECU１６により、基準のアイドル状態が実現されているか否かが判別される（ステップ２００）。基準のアイドル状態とは、内燃機関が、ほぼ一定の負荷を受けてアイドル運転している状態を指す。具体的には、オルタネータが一定の負荷を発生し、かつ、他の補機類が停止している状態が望ましい。車両１０は、基準アイドル状態の成立が認められたら、その時点で検出された機関回転数Neを情報センタ１２に送信する（ステップ２０２）。

情報センタ１２では、車両１０から機関回転数Neのデータ送信を受けると（ステップ２１０）、先ず、そのデータがコンピュータシステム２２のデータベースに記憶される（ステップ２１２）。ここでは、具体的には、データを送信してきた車両１０のIDと、送信されてきた機関回転数Neとが記憶される。次に、最新の機関回転数Neと、データベースに記憶されている過去の機関回転数Neとに基づいて、現在のNeの変化傾向が演算される（ステップ２１４）。

次いで、その演算の結果がNeの低下傾向を示しているか否かが判別される（ステップ２１６）。ここで、機関回転数Neが低下傾向を示していないと判断された場合は、NeがNGレベルの低下する可能性が生じていないと判断され、そのまま今回の処理が終了される。一方、Neが低下傾向を示していると判断された場合は、走行距離に対するNeの傾きと、予め設定されているNeのNG値（例えば４００rpm）とに基づき、NeがNG値に達するまでの走行距離が算出される（ステップ２１８）。そして、演算された走行距離が、車両１０およびディーラ１４に向けて送信される（ステップ２２０）。

車両１０においては、情報センタ１２から発せられた上記のNG情報（走行距離）を受信すると（ステップ２３０）、その情報を車両１０の搭乗者、つまり、ユーザに表示する処理が行われる（ステップ２３２）。

一方、ディーラ１４では、そのNG情報を受信すると（ステップ２４０）、先ず、車両１０のIDと、受信したデータ、つまり、NG状態が成立するまでに残された走行距離とがコンピュータシステム２６のデータベースに記憶される（ステップ２４２）。その後、ユーザへの連絡（電子メール等）や、交換部品の事前発注などの早期対策処理が自動的に行われる（ステップ２４４）。

以上説明した通り、本実施形態のシステムによれば、基準アイドル状態における機関回転数Neの変化を監視することにより、車両１０が走行不能な状態に陥るまでに残された走行距離を事前に推定しておくことができる。更に、本実施形態のシステムでは、その予測に必要な処理の主要部分を情報センタ１２において実行させることができる。このため、本実施形態のシステムによれば、ECU１６に多大な負荷を担わせることなく、車両１０の重大故障を事前に予測し、その故障に対する対策を早期に開始するという機能を実現することができる。

ところで、上述した実施の形態３においては、内燃機関のフリクション増加に起因してNG状態が生ずるまでの走行距離を事前予測の対象としているが、事前予測の対象は、そのような走行距離に限定されるものではない。すなわち、事前予測の対象は、ISC弁の故障や、各種補機類のフリクション増加に起因してNG状態が成立するまでの走行距離であってもよい。以下、それらの変形例の代表例として、ISC弁の故障に着目した場合の走行距離の予測手法を説明する。

図１０は、同一のISC開度に対するAFM計測空気量Gaと、車両１０の走行距離との関係を示した図である。図１０に示すように、ISC弁につまりが生ずる場合は、そのつまりが生じ始めた後、同一のISC開度に対するAFM計測空気量に減少傾向が表れる。このため、その減少傾向を監視することとすれば、ISC弁のつまりに起因してエンジンがストールするまでの走行距離を事前に予測することが可能である。

また、図１１は、ISC弁に対して同一の変化指令値を与えた場合に、基準時間内に生ずるISC開度（またはAFM計測空気量Ga）の変化量と、車両１０の走行距離との関係を示したものである。ISC弁が正常な応答性を示している間は、上記の基準時間内に、ISC開度やAFM計測空気量Gaに正常な変化量が生ずる。これに対して、ISC弁につまりが生じ始めると、ISC弁の応答性が悪化して、その基準時間内におけるISC開度等の変化が過小なものとなる。そして、その基準時間内に生ずるISC開度やAFM計測空気量Gaの変化量を監視することによれば、ISC弁のつまりに起因してエンジンがストールするまでの走行距離を事前に予測することが可能である。

ところで、上述した実施の形態３においては、NG状態が成立するまでの走行距離の予測を、情報センタ１２において実行することとしているが、本発明はこれに限定されるものではない。すなわち、その走行距離の予測は車両１０において実行し、車両１０から情報センタ１２へは、予測された走行距離のみを送信することとしてもよい。

尚、上述した実施の形態３においては、情報センタ１２において上記ステップ２１８の処理が実行されることにより前記第１０の発明における「不具合距離推定手段」が、車両１０において上記ステップ２３２の処理が実行されることにより前記第１０の発明における「不具合距離表示手段」が、情報センタ１２において上記ステップ２２０の処理が実行されることにより前記第１０の発明における「不具合距離送信手段」が、それぞれ実現されている。

実施の形態４．
次に、本発明の実施の形態４について説明する。上述した実施の形態１および２では、レベル３の故障の発生が認められた場合に、その影響を小さくするための回復措置を行うこととしている。例えばエアコン負荷の異常が認められた場合には（図７参照）、エアコンの作動時に発生させる吸入空気Gaの増量補正量を増やしたり、また、ISCガード値を大きくしたりといった回復措置が採られる。以下、上記の増量補正量やISCガード値など、回復措置の実行に伴って変更されるパラメータを「回復パラメータ」と称す。

レベル３の故障が発生した後、その故障の箇所が修理されれば、回復措置による対処は不要となる。換言すると、回復措置の実行に伴って変更されていた回復パラメータの値は、車両の修理後は不適切な値となる。そこで、本実施形態では、回復措置の発動原因となっていた故障の修理がディーラ１４にて行われた場合は、ディーラ１４において、回復パラメータを初期値にリセットすることとした。

より具体的には、本実施形態では、バッテリークリアによっては回復パラメータが初期値にリセットされないものとして、ディーラ１４において、特別な外部入力がECU１６に与えられることにより、回復パラメータが初期値にリセットされるものとする。また、この場合、ECU１６には、部品の変更履歴など、故障の修理に関する履歴が記録されるものとする。

以上説明した通り、本実施形態のシステムによれば、回復措置が発動された後、その原因となった故障箇所が修理される際には、ディーラ１４において、回復パラメータを適正に初期値に戻すことができる。このため、本実施形態のシステムによれば、故障の修理後に、回復パラメータが不適切な値を維持して適正な制御の実行を妨げられるといった不都合の発生を確実に防止することができる。

実施の形態５．
次に、図１２を参照して、本発明の実施の形態５について説明する。本実施形態のシステムは、図１に示す構成を用いて、ECU１６およびコンピュータユニット２２，２６に、後述する図１２に示す流れに沿った処理を実行させることにより実現することができる。

車両において用いられる部品は、公差の範囲内で特性にばらつきを有するのが通常である。このため、高い精度での制御が要求される部品については、部品の交換と同時に、交換後の部品特性と適合するように、その部品に関する制御の内容を修正することが望ましい。そこで、本実施形態のシステムでは、車両１０、情報センタ１２、およびディーラ１４の３者間で必要なデータを授受することにより、その要求を満たす機能を実現することとした。

図１２は、上記の機能を実現するために本実施形態において実行される処理の流れを説明するためのフローチャートである。図１２に示すルーチンによれば、ディーラ１４において車両の部品が交換されると（ステップ２５０）、交換部品の番号、その部品の特性データ、並びに部品交換の対象とされた車両の番号が情報センタ１２に向けて送信される。以下、これらのデータを総称して「交換データ」と称す。

ここで、「特性データ」とは、交換部品そのものの入出力特性を正確に表すデータである。例えば、交換部品がISCバルブである場合には、交換部品として使用されたISCバルブそのものを対象として計測された開度−流量特性が、特性データとして情報センタ１２に送信される。

情報センタ１２は、ディーラ１４から発せられた交換データを受信すると（ステップ２６０）、それらのデータを先ずデータベースに登録する（ステップ２６２）。次に、交換部品の制御に関係する車両情報をデータベースから読み出す（ステップ２６４）。尚、ここで読み出される車両情報は、車両１０からの通信により、予め情報センタ１２に提供されているもの、あるいは、情報センタ１２の要求に応じて随時提供されるものとする（ステップ２７０）。

情報センタ１２は、ディーラ１４から提供された交換データと、車両１０から提供された車両情報とに基づいて、交換部品の制御を制度良く実行するための適合値を算出する（ステップ２６６）。そして、適合値が算出されると、情報センタ１２は、車両１０へ向けてその適合値を送信する（ステップ２６８）。

車両１０は、情報センタ１２から発せられた適合値を受信すると、その適合値を制御の内容に反映させるための設定処理を行う（ステップ２８０，２８２）。以上説明した通り、本実施形態のシステムによれば、車両１０の部品が交換された場合に、交換部品そのものの特性に合致する適合値を車両１０において設定することができる。このため、本実施形態のシステムによれば、部品交換の直後から、交換部品に関連する制御を車両１０上で極めて制度良く実行させることができる。

ところで、上述した実施の形態５においては、情報センタ１２が、適合値を算出するにあたって、車両情報をも基礎とすることとしているが、本発明はこれに限定されるものではない。すなわち、交換部品に対応する適合値は、ディーラ１４から送信される交換データのみを基礎として算出することとしてもよい。

実施の形態６．
次に、図１３を参照して、本発明の実施の形態６について説明する。上述した実施の形態３において、情報センタ１２は、車両１０から提供される各種の情報に基づいて、車両１０における不具合の兆候を検知し、車両１０が走行不能となるまでの走行可能距離を予測する。例えば、ISC弁のつまりの兆候と推測される現象が検知された場合は、その現象に基づいて、ISC弁が適正に作動し得なくなるまでの走行可能距離を予測する。そして、走行可能距離が算出されたら、車両１０の故障に備えるべく、その値を車両１０およびディーラ１４に供給することとしている。

図１３は、ISC弁のつまりの兆候（同一ISC開度に対するAFM計測空気量Ga）と、車両１０の走行距離との関係を示した図である。図１３に示すように、ISC弁につまりが生ずると、同一のISC開度に対するAFM計測空気量Gaに減少傾向が表れる。実施の形態３のシステムでは、その減少傾向を監視することにより、ISC弁のつまりに起因してエンジンがストールするまでの走行距離を事前に予測することとしている。

図１３は、ISC弁が、完全なつまり状態に至る以前に新品に交換された場合の例を示している。この図に示すように、車両１０が走行不能となるまでの走行可能距離は、不具合の原因である部品（ここではISC弁）が交換されれば、当然にリセット（最大値にセット）されるべきである。そこで、本実施形態のシステムは、走行可能距離の算出原因であった部品がディーラ１４において交換された場合には、その走行可能距離に関わる各種のデータを全てリセットすることとした。

具体的には、部品交換の際に、車両１０、情報センタ１２、およびディーラ１４においてそれぞれ保有されていた走行可能距離に関する情報をリセットすることとした。特に、車両１０に保有された走行可能距離の情報は、バッテリークリアによってはリセットされないものとし、ディーラ１４において、特別な外部入力がECU１６に与えられることにより、その情報がリセットされるものとする。また、情報センタ１２における情報は、ディーラ１４からの通信によりリセットされるものとする。

以上の処理によれば、本実施形態では、走行可能距離の算出原因となっていた部品が修理される際に、劣化した部品に起因して設定されていた走行可能距離の情報を確実にリセットすることができる。このため、本実施形態のシステムによれば、劣化部品の交換後に、部品交換以前に設定された走行可能距離の情報が不当に保持されるのを確実に防ぐことができる。

本発明の実施の形態１の構成を説明するための概念図である。 レベル２およびレベル３の故障または不具合の発生時における故障診断の概要を説明するための図である。 図２に示す概念に沿った処理が進められるべく車両、情報センタおよびディーラのそれぞれにおいて実行される具体的処理の内容を説明するためのフローチャートである。 情報センタにおいて実行される故障特定処理の一例のフローチャートである。 基準負荷状態におけるAFM計測空気量Gaと機関回転数Neとの関係を示す。 ISC制御量とAFM計測空気量Gaとの関係を示す。 回復処理を実現するために情報センタにおいて実行されるフローチャートの一例である。 アイドル時における同一の負荷条件下で計測された機関回転数Neと車両の走行距離との関係を示した図である。 本発明の実施の形態３の機能を実現するために車両、情報センタおよびディーラのそれぞれにおいて実行される具体的処理の内容を説明するためのフローチャートである。 同一のISC開度に対するAFM計測空気量Gaと、車両の走行距離との関係を示した図である。 ISC弁に対して同一の変化指令値を与えた場合に、基準時間内に生ずるISC開度（またはAFM計測空気量Ga）の変化量と、車両の走行距離との関係を示した図である。 本発明の実施の形態４において実行される処理の流れを説明するためのフローチャートである。 ISC弁のつまりの兆候（同一ISC開度に対するAFM計測空気量Ga）と、車両の走行距離との関係を示した図である。

符号の説明

１０ 車両
１２ 情報センタ
１４ ディーラ
１６ ECU(Electronic Control Unit)

Claims (10)

1. 相互に通信可能な車両と情報センタとを含む車両の故障診断システムであって、
   車両データを検出すべく車両に搭載された車両データ検出手段と、
   前記車両データに基づいて車両の不具合を検出すべく、車両または情報センタに設けられた不具合検出手段と、
   車両の不具合の発生を検知して、その不具合の原因を特定するための故障特定処理の実行を車両に対して指示すべく、情報センタに設けられた特定処理指示手段と、
   指示された故障特定処理を実行すべく、車両に搭載された特定処理実行手段と、
   前記故障特定処理の結果を情報センタに返信すべく、車両に搭載された特定処理結果返信手段と、
   車両から返信されてきた故障特定処理の結果に基づいて故障個所を特定すべく、情報センタに設けられた故障個所特定手段と、
   特定された故障に対する対策を講ずるべく情報センタに設けられ、特定された故障の影響を排除するための回復処理の実行を車両に対して指示する回復処理指示手段と、
   指示された回復処理を実行すべく、車両に搭載された回復処理実行手段と、
   前記回復処理の結果に基づいて回復処理の続行または終了を決定すべく、車両または情報センタに設けられた処理決定手段と、
   を含むことを特徴とする車両の故障診断システム。
2. 前記回復処理指示手段は、
   最も重大な故障を記憶した最重大故障記憶手段と、
   検知された故障が、最も重大な故障である場合にのみ前記回復処理の指示を発する回復対象限定手段と、
   を含むことを特徴とする請求項１記載の車両の故障診断システム。
3. 前記特定処理指示手段は、
   重大な不具合を記憶した重大不具合記憶手段と、
   検知された不具合が、重大な不具合である場合にのみ前記故障特定処理の指示を発する特定対象限定手段と、
   を含むことを特徴とする請求項１又は２記載の車両の故障診断システム。
4. 相互に通信可能な車両と情報センタとを含む車両の故障診断システムであって、
   車両データを検出すべく車両に搭載された車両データ検出手段と、
   前記車両データに基づいて車両の不具合を検出すべく、車両または情報センタに設けられた不具合検出手段と、
   車両の不具合の発生を検知して、その不具合の影響を排除するための回復処理の実行を車両に対して指示すべく、情報センタに設けられた回復処理指示手段と、
   指示された回復処理を実行すべく、車両に搭載された回復処理実行手段と、
   前記回復処理の結果に基づいて回復処理の続行または終了を決定すべく、車両または情報センタに設けられた処理決定手段と、
   を含むことを特徴とする車両の故障診断システム。
5. 前記回復処理指示手段は、
   最も重大な不具合を記憶した最重大事項記憶手段と、
   検知された不具合が、最も重大な不具合である場合にのみ前記回復処理の指示を指令する回復対象限定手段と、
   を含むことを特徴とする請求項４記載の車両の故障診断システム。
6. 相互に通信可能な車両と情報センタとを含む車両の故障診断システムであって、
   特定の不具合の発生に起因する不具合特性値を検出すべく車両に搭載された不具合特性値検出手段と、
   前記不具合特性値の大きさに基づいて、検知された前記不具合の重大度を判定する不具合重大度判定手段と、
   前記重大度が判定値を越える場合に限り、検知された前記不具合の情報を情報センタに提供する提供情報限定手段と、
   車両から情報提供を受けた前記不具合の影響を排除するための回復処理の実行を車両に対して指示すべく、情報センタに設けられた回復処理指示手段と、
   指示された回復処理を実行すべく、車両に搭載された回復処理実行手段と、
   前記回復処理の結果に基づいて回復処理の続行または終了を決定すべく、車両または情報センタに設けられた処理決定手段と、
   を含むことを特徴とする車両の故障診断システム。
7. 前記提供情報限定手段は、前記不具合の情報として、前記不具合特性値を含む情報を情報センタに提供し、
   前記回復処理指示手段は、
   不具合の情報が車両から提供された場合に、前記不具合特性値に基づいて、その不具合を緊急を要する不具合として認識すべきか否かを判別する緊急度判別手段と、
   車両から情報提供を受けた前記不具合が、緊急を要するものである場合に限り前記回復処理の指示を指令する回復対象限定手段と、
   を含むことを特徴とする請求項６記載の車両の故障診断システム。
8. 車両から情報提供を受けた前記不具合の原因を特定するための故障特定処理の実行を車両に対して指示すべく、情報センタに設けられた特定処理指示手段と、
   指示された故障特定処理を実行すべく、車両に搭載された特定処理実行手段と、
   前記故障特定処理の結果を情報センタに返信すべく、車両に搭載された特定処理結果返信手段と、
   車両から返信されてきた故障特定処理の結果に基づいて故障個所を特定すべく、情報センタに設けられた故障個所特定手段と、
   を含むことを特徴とする請求項６又は７記載の車両の故障診断システム。
9. 前記故障特定処理は、複数の検査モードを含んでおり、
   前記故障個所特定手段は、
   車両から返信されてきた故障特定処理の結果に基づいて、故障個所が特定できる場合に当該故障特定処理の完了を判定する特定処理完了手段と、
   前記結果に基づいて、故障個所が特定できない場合には、その結果に対応する検査モードの開始を、前記特定処理指示手段に指示させる特定処理継続手段と、
   を含むことを特徴とする請求項１乃至３および８の何れか１項記載の車両の故障診断システム。
10. 前記車両データに基づいて車両に不具合が発生するまでの走行距離を推定すべく、車両または情報センタに設けられた不具合距離推定手段を備え、更に、
    不具合発生までの前記走行距離を車両上に表示する不具合距離表示手段、および、前記走行距離を車両のメンテナンス工場に送信する不具合距離送信手段の少なくとも一方を備えることを特徴とする請求項１乃至９の何れか１項記載の車両の故障診断システム。

Images