JP2011162079A - 故障診断装置、故障診断付き電子制御ユニット、故障診断システム、故障診断方法 - Google Patents

Abstract

【課題】整備に伴う車載システムの異常が検出されても、それを判別可能な故障診断装置、故障診断付き電子制御ユニット、故障診断システム及び故障診断方法を提供すること。
【解決手段】車両１１の部品２１を診断して診断情報３５を生成する診断手段３１と、診断情報３５を記憶する記憶手段２８と、診断情報をサーバ５０に送信する送信手段３６，２４と、を有する故障診断装置１００において、車両１１の車輪に加わる車重が減少したことを検出する車輪浮き検出手段３４と、車輪浮き検出手段が車輪に加わる車重が減少したことを検出した場合、診断情報３５の生成又は送信を禁止する診断停止手段３３と、を有することを特徴とする。
【選択図】図２

Description

本発明は、車両から情報センタに診断情報を送信する故障診断装置、故障診断付き電子制御ユニット、故障診断方法及び故障診断システムに関する。

ＥＣＵ（Electrical Control Unit）は、センサが検出する信号を利用して車両の状況を検出したり、信号に演算処理を施しアクチュエータを制御するなど、各種の車載システムを制御している。ＥＣＵが故障すると所望の制御結果が得られないので、ＥＣＵは、車載システムが正常に作動しているか否かを診断する自己診断機能を備える場合が多い。

自己診断の結果、異常が検出された場合、ＥＣＵは、警告ランプを点灯して運転者に異常を通知すると共に、不揮発メモリに診断結果を記録する。運転者が車両を修理工場等に持ち込むと、サービスマンはＥＣＵに記憶された診断結果を専用のツール（以下、診断ツールという）により読み出して異常の原因を解析することができる。

一方、ＥＣＵが異常を検出すると、携帯電話網等を通じて診断結果を情報センタ（サーバ）に送信する技術が開示されている（例えば、特許文献１参照。）。特許文献１によれば、情報センタは、より早期に診断結果を取得でき、車両メーカやディーラーに提供することができる。したがって、車両メーカやディーラーは、異常の原因を解析して修理方法の特定や製品開発等に利用することができる。

また、上記の診断ツールは故障原因を調査するため疑似的な故障信号を車両の各ＥＣＵに供給することができ、サービスマンは疑似信号に対するＥＣＵの応答を利用して異常の原因を解析する作業を行うことができる。ここで、ＥＣＵは、擬似的な故障信号に対する診断結果も情報センタに送信してしまうが、車載システムは実際には故障していないので、擬似的な故障信号に対する診断結果は、異常の原因の解析には不要である。そこで、診断ツールが車両に接続された場合は、情報センタに診断結果を送信することを禁止する技術が提案されている（例えば、特許文献２参照。）。

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

しかしながら、特許文献１に開示されているように、異常を検出するとＥＣＵが診断結果を情報センタに送信すると、車載システムが故障していなくても、診断結果が情報センタに送信されてしまうという問題がある。具体的には、修理工場では、点検等のためにサービスマンが車載システムから部品を外したり、異常の原因と思われる部品を交換する等の修理作業を行う。

図１は、従来の車両の診断を模式的に示す図の一例である。車両には種々の車載システムが搭載されているが、図では車載システムが部品とＥＣＵとを有するように構成されている。サービスマンは多様な整備を行うことができるため、車両から部品を取り外すと、その部品を管理するＥＣＵがその部品に異常が生じたものと誤検出して（検出自体は正しいが部品に故障は生じていない）、診断結果を情報センタに送信してしまう。修理工場において情報センタに送信された診断結果は、情報センタにとって、異常の原因の解析に有用でなく、却って異常の原因の解析を遅らせるおそれがある。

また、特許文献２によれば、診断ツールをリフトアップする前に車両に接続しておくことで、ＥＣＵが情報センタへ診断情報を送信することを禁止できる。しかし、そのためには診断ツールの接続が必要であるという別の不都合を生じさせる。

また、サービスマンは、修理工場等における整備時には診断情報を情報センタに送信しないよう手動で車両に設定することもできるが、サービスマンが設定を忘れることがないとは限らない。また、この設定は、サービスマンが解除できるが、サービスマンが解除を忘れた場合、ＥＣＵが異常を検出できないか又は異常を検出しても異常情報を情報センタに送信できないという別の不都合を生じさせる。サービスマンが設定の解除を忘れないように、タイマを利用してＥＣＵが設定を元に戻すこと（診断情報を送信するように戻すこと）も可能だが、この場合、所定時間が経過すると整備中でも診断情報が送信されてしまうことになる。

本発明は、上記課題に鑑み、整備に伴う車載システムの異常が検出されても、それを判別可能な故障診断装置、故障診断付き電子制御ユニット、故障診断システム及び故障診断方法を提供することを目的とする。

本発明は、車両の部品を診断して診断情報を生成する診断手段と、診断情報を記憶する記憶手段と、診断情報をサーバに送信する送信手段と、を有する故障診断装置において、車両の車輪に加わる車重が減少したことを検出する車輪浮き検出手段と、車輪浮き検出手段が車輪に加わる車重が減少したことを検出した場合、診断情報の生成又は送信を禁止する診断停止手段と、を有することを特徴とする。

整備に伴う車載システムの異常が検出されても、それを判別可能な故障診断装置、故障診断付き電子制御ユニット、故障診断システム及び故障診断方法を提供することができる。

従来の車両の診断を模式的に示す図の一例である。 実施例に共通する、車両が整備状態であること及び整備の完了を検出する手順を示すフローチャート図の一例である。 故障診断システムの概略構成図の一例である。 情報センタのハードウェア構成図の一例である。 故障診断装置の概略構成図の一例である。 診断情報を模式的に説明する図の一例である。 リフトアップ判定部が、タイヤ浮きが発生していることを検出する手順を示すフローチャート図の一例である。 整備完了判定部が、整備が完了したか否かを判定する手順を示すフローチャート図の一例である。 リモートダイアグ停止部がリモートダイアグを停止又は再開する手順を示すフローチャート図の一例である。 リフトアップ判定部が、タイヤ浮きが発生していることを検出する手順を示すフローチャート図の一例である。 解析センタの機能ブロック図の一例である。 診断情報を模式的に説明する図の一例である。 リモートダイアグ停止部がリモートダイアグを停止又は再開する手順を示すフローチャート図の一例である。 診断部が診断情報を生成する手順を示すフローチャート図の一例、及び、情報センタが診断情報を受信する手順を示すフローチャート図の一例である。

以下、本発明を実施するための形態について図面を参照しながら実施例を挙げて説明する。

図２は、以下の実施例に共通する、車両が整備状態であること及び整備の完了を検出する手順を示すフローチャート図の一例である。まず、ステップＳ１において、車載された故障診断装置は、タイヤの浮きを検出する。タイヤが浮くことは車両がリフトアップ又はジャッキアップ（以下、両者を区別せずに単に「リフトアップ」という）された場合が多いと考えられる。そこで、故障診断装置はタイヤが浮くことから車両が整備中であると判定する。なお、タイヤが浮くのは、車輪に加わる車重が減少したことによるものなので、車輪に加わる車重が減少したことを検出してもよい。

故障診断装置がタイヤの浮きを検出すると、次に、ステップＳ２において、故障診断装置はリモートダイアグを停止する。リモートダイアグとは、故障診断装置が車載システムの異常を検出して、診断情報を情報センタに送信することをいう。なお、リモートダイアグの停止には、後述するように、(a)異常の検出を禁止すること、(b)異常を検出しても診断情報を情報センタに送信しないこと、又は、(c)診断情報が整備中の車両から送信されたものであることを診断情報に含めること、の３つの態様を含む。

リモートダイアグが停止された車両は、その後、サービスマン、車両のユーザ又は乗員（以下、単に「サービスマン」という）により整備され、種々の部品が取り外され得る。しかし、リモートダイアグは既に停止されているので、(a)(b)診断結果が情報センタに送信されることを防止でき、また、(c)情報センタが診断情報を受信しても整備中の診断情報であることを峻別できる。

次に、ステップＳ３において故障診断装置が整備の完了を検出すると、ステップＳ４において、故障診断装置はリモートダイアグを再開する。したがって、サービスマンが手動でリモートダイアグを再開しなくても、リモートダイアグが再開するので、故障診断装置が異常を検出できない状況や、異常を検出しても診断情報を情報センタに送信できない状況となることを確実に防止できる。

図３は、故障診断システム２００の概略構成図を示す。車両１１と情報センタ５０とは、ネットワーク１４を介して通信可能である。ネットワーク１４は、ＧＳＭやＣＤＭＡ（携帯電話網）、IEEE 802.11a／g／n（無線ＬＡＮ）、又は、ＩＥＥＥ802.16e（ＷｉＭＡＸ）で規格化された通信を行う通信事業者の無線通信ネットワーク、及び、インターネットやＬＡＮ等の主に有線式のＩＰネットワークが組み合わされたものである。基地局１３は、通信事業者が運営する無線通信ネットワーク１４の末端の無線局である。

故障診断装置１００は、車載された通信装置により基地局１３を介して情報センタ５０と通信する。上記のとおり、故障診断装置１００は診断情報を情報センタ５０に送信し、情報センタ５０は診断情報を統計処理したり、異常の原因を解析することで、修理方法の特定や製品開発等に利用することができる。また、情報センタ５０は異常に対する対応方法等を故障診断装置１００に送信してもよい。

図４は情報センタ５０のハードウェア構成図の一例を示す。情報センタ５０は、サーバと称されるコンピュータを実体とする。情報センタ５０は、それぞれバスで相互に接続されているＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、記憶媒体装着部２０４、表示制御部２０５、通信装置２０６、入力装置２０７、及び、ＨＤＤ（Hard Disk Drive）２０８を有する。ＣＰＵ２０１は、ＯＳ（Operating System）やプログラムをＨＤＤ２０８から読み出して実行することで種々の機能を提供すると共に、情報センタ５０が行う処理を統括的に制御する。プログラムとしては、車両１１の故障診断装置１００と通信するためのサーバソフトウェア、及び、診断情報を処理するソフトウェアがある。

ＲＡＭ２０２はＣＰＵ２０１がプログラムを実行する際に必要なデータを一時保管する作業メモリ（主記憶メモリ）になり、ＲＯＭ２０３にはＯＳを起動するためのブートローダや各種のパラメータが記憶されている。

記憶媒体装着部２０４には外部メディア３００が着脱可能であり、外部メディア３００に記録されたプログラムを読み込み、ＨＤＤ２０８に記憶させる。通信装置２０６は、ネットワーク１４に接続するためのインターフェイス（例えば、イーサネット（登録商標）カード）であり、主に物理層とデータリンク層に対応する処理を提供する。サーバソフトウェアは、送信時には、ソケットインターフェイスでＴＣＰ／ＩＰプロトコルスタックを呼び出す処理やＴＣＰ／ＩＰプロトコルスタックが通信装置２０６のデバイスドライバを呼び出す処理を実行する。受信時には、デバイスドライバが、通信装置２０６から割り込みを受け付け、通信装置２０６がバッファに記憶した受信データを読み込みＲＡＭ２０２に記憶する。デバイスドライバは、受信データをＴＣＰ／ＩＰプロトコルスタックに渡すので、サーバソフトウェアはＴＣＰ／ＩＰプロトコルスタックがプロトコル処理した受信データを取得する。

入力装置２０７は、キーボードやマウスなどであり、情報センタ５０の管理者の様々な操作指示を受け付ける。表示制御部２０５は、プログラムが指示する画面情報に基づき所定の解像度や色数等で液晶などのディスプレイ２０９に、ウィンドウ、ドキュメント、フレーム、文字列、画像、フォーム、リンク等を表示する。なお、サーバには入力装置２０７、表示制御部２０５及びディスプレイ２０９が接続されていなくてもよい。

ＨＤＤ２０８は、プログラムやＨＴＭＬファイル等が記憶されている。プログラムやＨＴＭＬファイルは、外部メディア３００に記憶して配布されたり、ネットワーク１４を介して不図示のコンピュータからダウンロードされる。

図３に戻り、車両１１は故障診断装置１００を有する。図の車両１１は、修理工場にある昇降機１２によりリフトアップされている。リフトアップされた車両１１は、足回りや底面の部品２１や配線、更にはエンジンさえ取り外すことが可能な状態となる。このため、車両１１がリフトアップされた場合、サービスマンは多様な整備を行う可能性が高い。上記のように、この整備によりＥＣＵ２３が部品２１に異常が生じたものと誤検出し（検出自体は正しいが部品２１に故障は生じていない）、診断情報を情報センタ５０に送信することを防止するため、故障診断装置１００は、整備中であることを検出した場合、異常を検出すること又は診断情報を送信することを防止する。

図５は、故障診断装置１００の概略構成図の一例を示す。故障診断装置１００は、車載ＬＡＮ２５を介して相互に接続されたＥＣＵ（Electrical Control Unit）２３、通信装置２４、及び、タイヤ浮きセンサ２６を有する。車載ＬＡＮ２５には複数のＥＣＵ２３が接続されているが、故障診断の機能について各ＥＣＵ２３の構成は共通としてよいので、図ではＥＣＵ２３を１つだけとした。

ＥＣＵ２３には、各種の部品２１が接続されている。この部品２１は、部品２１そのものがＥＣＵ２３と電気的（有線又は無線のいずれでもよい）に接続されていてもよいし、部品２１と一体に車両１１から取り外されるセンサ２２がＥＣＵ２３と電気的に接続されていてもよい。また、部品２１がセンサ２２そのものであってもよい。したがって、部品２１が車両１１から取り外されると、ＥＣＵ２３はセンサ２２が取り外されたことを検出できる。なお、ＥＣＵ２３、１つ以上の部品２１及びセンサ２２で１つの車載システとなる。

部品２１又はセンサ２２が具体的にどのようなものかはＥＣＵ毎に異なる。例えば、ＥＣＵ２３がエンジンＥＣＵである場合、部品２１はエンジンそのもの、オルタネータ、バッテリ、イグニッションスイッチ（スタートボタン）等であり、センサ２２はO2センサ、ノックセンサ、水温センサ、クランクシャフトポジションセンサ、エアフローメータ、吸気量センサ、排気温センサ等である。

また、例えば、ＥＣＵ２３がボディＥＣＵである場合、部品２１はドア、パワーシート、パワーウィンドウ、パーキングブレーキスイッチ、ライティングシステム、ワイパー等であり、センサ２２は、カーテシスイッチ、パワーウィンドウのタッチセンサ（挟み込み検知）、シート位置センサ、ストップランプスイッチ、シートベルトスイッチ等である。

また、例えば、ＥＣＵ２３がハイブリッドＥＣＵの場合、部品２１は、モータ、モータに電力を供給する高圧ケーブル、バッテリ等であり、センサ２２はモータの電流センサや回転数センサ、高圧ケーブルの電圧センサ、バッテリ残量を検出するための電圧・電流センサ等である。

また、例えば、ＥＣＵ２３がブレーキＥＣＵの場合、部品２１はブレーキアクチュエータ、ブレーキアクチュエータの増圧弁や減圧弁、液圧生成用のポンプ、マスタシリンダ、作動流体の配管、ホイルシリンダ等であり、センサ２２は、ブレーキアクチュエータ内の液圧センサ、マスタシリンダ圧センサ、ホイルシリンダ圧センサ等である。

また、例えば、ＥＣＵ２３が障害物検出ＥＣＵの場合、部品２１は車両前部及び後部のバンパであり、センサ２２はバンパカバーに設けられた孔部に超音波の送受信部が配置されるようにバンパの内側に固定された超音波センサである。

この他、ＥＣＵ２３に対する部品２１及びセンサ２２の関係は多種多様である。また、あるＥＣＵ２３が他のＥＣＵ２３と通信することで１つの車載システムが構築されることも多い。例えば、ボディＥＣＵはパワーウィンドウＥＣＵ、パワーシートＥＣＵ、照合ＥＣＵ、メータＥＣＵ等と車載ＬＡＮ２５を介して通信する。したがって、ＥＣＵ２３が、例えばボディＥＣＵの場合、パワーウィンドウＥＣＵ、パワーシートＥＣＵ、照合ＥＣＵ又はメータＥＣＵ（以下、従動的ＥＣＵという）が部品２１となることもある。この場合、部品（従動的ＥＣＵ）２１を取り外すことで、従動的ＥＣＵがボディＥＣＵに送信すべき情報が送信されないことになるので、従動的ＥＣＵが部品２１に対応する。なお、この場合、部品２１とセンサ２２は一体とみなすことができる。

通信装置２４は、データ通信モジュールと呼ばれる通信端末又はユーザが携帯している携帯電話などである。データ通信モジュールの実体は携帯電話、無線ＬＡＮの端末又はＷｉＭａｘの端末等である。通信装置２４が通信する際、予め通信装置２４に登録されている情報センタ５０のＩＰアドレス又はＵＲＬを指定して、最寄りの基地局１３に接続し、通信事業者の交換局やゲートウェイを介してバックボーンとなるＩＰネットワークに接続する。その後、通信装置２４は、ＴＣＰ／ＩＰなどのプロトコルで情報センタ５０と通信する。

なお、通信装置２４をユーザが携帯している携帯電話とした場合、この携帯電話が情報センタ５０と通信する。携帯電話は例えばナビゲーションシステム（以下、ナビシステムという）２７と有線又は無線（Bluetooth（登録商標）、ZigBee（登録商標）等）で通信するので、携帯電話は、ＥＣＵ２３からナビシステム２７を経由して診断情報３５を受信して情報センタ５０に送信し、また、情報センタ５０から受信したデータがあればナビシステム２７に送信する。

ナビシステム２７は、衛星を利用したＧＮＳＳ（ＧＰＳ、Ｇａｌｉｌｅｏ、Ｇｌｏｎａｓｓ等）により車両１１の現在位置を測位する。また、ナビシステム２７は、現在位置を起点に、ジャイロセンサが検出する走行方向に、車速センサが検出する走行距離を累積して、衛星からの電波が受信できない状況でも車両１１の位置を高精度に推定する。また、ナビシステム２７は、予め記憶した道路地図又は不図示のサーバからダウンロードした道路地図に、車両１１の位置をアイコンなどで表示する。この際、ナビシステム２７は、車両１１が走行している道路として最も可能性の高い道路（リンク）の車線に、自車の位置をマッピングする。

タイヤ浮きセンサ２６は、タイヤが浮いたこと、すなわち車両１１がリフトアップされたことを検出するセンサであり、主に、ハイトセンサ３８又は空気圧センサ３９を実体とする。なお、車両１１がリフトアップされるのは、修理工場に限られず、ユーザの車庫、道路、路肩等、どのような場所でもよい。また、車両１１をリフトアップするのはサービスマンに限られず、乗員やユーザ等、どのような人でもよい。

ハイトセンサ３８は、各輪のショックアブソーバに内蔵された磁気スケールと磁気センサを有する。磁気スケールは、ショックアブソーバのピストンに固定され一定長さ毎にＮ極とＳ極が交番するように配置され、磁気センサは、磁気スケールに対向してシリンダの上端に固定されている。ショックアブソーバに対しピストンが相対移動すると、磁気センサも磁気スケールに対し相対移動する。ハイトセンサ３８は、中立位置を基準に、磁極が変化した回数からショックアブソーバの伸縮量を検出し、それを路面から車体底面までの距離に換算して車高を計測する。車高は４つの車輪毎に独立に計測される。

また、空気圧センサ３９は、各車輪の例えばバルブシステムと一体に配置されるセンサ部と、センサ部が所定時間毎に車体に向けて無線送信したタイヤの空気圧情報を受信する通信部とを有する。センサ部は内蔵するバッテリにより駆動され、通信部は車載ＬＡＮ２５に接続されている。空気圧は、車両１１の重量を４輪で均等に支えた状態と、一輪、二輪又は三輪で支えた状態（一部の車輪がリフトアップされた状態）、又は、０輪で支えた状態（車体の全体がリフトアップされた状態）とで異なる。車両１１の重量を４輪で均等に支えた状態を基準に、いずれかのタイヤの空気圧がそれよりも小さくなれば、車両１１がリフトアップされた可能性があることになる。

ＥＣＵ２３は、ＣＰＵ、主記憶装置、補助記憶装置及び入出力装置がバスを介して接続されたマイコンを実体とする。補助記憶装置２８はフラッシュメモリなどの不揮発メモリである。補助記憶装置２８にはプログラムが記憶されており、ＣＰＵがこのプログラムを実行することで、ＥＣＵ２３に特有の制御を実現している。図では制御部２３が特有の制御を行う。制御部３１は、センサ２２や他のＥＣＵ２３から信号を取得して部品２１を制御する、ＥＣＵ２３にとって本来の制御を実行する機能ブロックである。例えばＥＣＵ２３がエンジンＥＣＵの場合、制御部３１はアクセル開度センサが検出するアクセル開度によりエンジン回転数の維持・増加・減少を判断し、回転速度センサが検出する回転速度に基づき、燃料噴射量、燃料噴射タイミング、吸排気弁の開放タイミング、スロットル開度、イグナイタの点火タイミング等を演算する。また、例えば、ＥＣＵ２３がハイブリッドＥＣＵ２３の場合、アクセルペダル開度、車両速度等を検出して、要求トルクを演算し、エンジンとモータそれぞれが出力するトルクを決定する。

制御部３１に加え、ＥＣＵ２３は、故障診断に関係する機能として、診断部３２、リモートダイアグ停止部３３、リフトアップ判定部３４、送信要求部３６及び整備完了判定部３７を有する。また、補助記憶装置２８には診断情報３５が記憶される。

診断部３２は、制御部３１が機能しているか否かを検出する例えばＷＤＴ（ウォッチドッグタイマ）や、制御部３１が制御する上で必要な信号線の電圧を監視することで断線等を検出する。診断部３２は、例えばＷＤＴがタイムオーバするとリセット回路を作動させＥＣＵ２３をリセットさせる。その後、再度、ＷＤＴがタイムオーバすると、診断部３２はＥＣＵ２３に異常があることを検出する。また、診断部３２は、例えば信号線の電圧が基準値以下（又は以上）になっている時間が所定値以上になると、異常があることを検出する。

診断部３２は、異常があることを検出すると診断情報３５を生成し、また、補助記憶装置２８に記憶させる。
図６は、診断情報３５を模式的に説明する図の一例である。診断情報３５は、例えば、ダイアグコード、ＦＦＤ（フリーズフレームデータ）、及び、日時情報を有する。この他、車速や位置情報を含めてもよい。なお、統計処理のため、診断情報３５には、車両１１の車種を特定できる型式又はエンジンの型式が含まれるか、少なくとも対応付けられている。

なお、通信装置２４がデータ通信モジュールの場合、車両１１の型式は、ＴＣＰ／ＩＰのフレームに必須の送信元情報により代替できる。データ通信モジュールには、予め車種やエンジンの型式に応じて電話番号（ＳＩＭ）が割り当てられているからである。すなわち、情報センタ５０は、送信元情報から診断情報３５の統計処理に必要な程度に車両１１の識別が可能となっている。

ダイアグコードは、その番号によりおよその異常を示した部品２１やＥＣＵ２３を特定するための点検項目（例えば、＋Ｂ系統、回転信号系統、点火信号系統、Ｏ２センサ系統、ノック信号系統等）を示す。サービスマンはダイアグコードと点検項目を対応づけた既存の本や冊子（紙媒体でも電子媒体でもよい）を参照して、車両１１を整備することができる。また、ＦＦＤは、診断部３２が異常を検出した時又はその前後にＥＣＵ２３が車載ＬＡＮ２５等を介して取得した各種のデータであり、図ではＦＦＤの一例として車速、エンジン回転数及び水温が挙げられている。この他、点火時期、スロットル開度、バッテリー電圧、噴射時間等を含めてもよい。日時情報は、診断部３２が異常を検出した時の日時を表す。なお、診断情報３５は固定されている必要はなく、異常を検出したＥＣＵ２３に応じて可変とすることができる。

また、診断部３２は、異常が検出された場合、メータＥＣＵにメータパネルの警告ランプを点灯するよう要求する。乗員は警告ランプが点灯していることを認識することで、修理工場に車両１１を持ち込むなど、適切な行動を取ることができる。

診断部３２は、診断情報３５を生成すると送信要求部３６に診断情報３５の送信を要求する。送信要求部３６は、診断部３２から送信を要求された直後、又は、予め定められたタイミング（例えば、１分〜１０分間隔などの定期的なタイミング）になると、通信装置２４から情報センタ５０に診断情報３５を送信する。

リモートダイアグ停止部３３は、リモートダイアグを停止する。また、停止の後、リモートダイアグを再開する。本実施例のリモートダイアグの停止には、異常の検出を停止すること、又は、異常を検出しても診断情報３５を送信しないことの２つの態様がある。前者の場合、診断部３２が異常を検出しないので、診断情報３５が生成されず（記憶もされず）警告ランプも点灯しないので、サービスマンが診断情報３５を初期化（消去）する必要がない（サービスマンが初期化を忘れることもない）。後者の場合、診断情報３５が生成され（記憶もされ）警告ランプも点灯するが、これにより診断部３２が正常に作動していることを確認できる。

リフトアップ判定部３４は、タイヤ浮きセンサ２６が検出するタイヤ浮き情報に基づき、タイヤ浮きが発生しているか否かを判定する。上記のとおり、タイヤ浮きが発生していること（車輪に加わる車重が減少したこと）は、車両１１が整備中であることを意味する。タイヤ浮き情報は車高情報又は空気圧情報である。

タイヤ浮き情報が異なってもタイヤが浮いたか否かを判定する考え方は同じである。まず、タイヤ浮きセンサ２６がハイトセンサ３８の場合、リフトアップ判定部３４は４輪の車高情報のうち前輪の二輪又は後輪の二輪の車高情報が閾値Ａ以上の場合、タイヤ浮きが発生していると判定する。同様に、リフトアップ判定部３４は４輪の空気圧情報のうち、前輪の二輪又は後輪の二輪の空気圧情報が閾値Ｂ以下の場合、タイヤ浮きが発生していると判定する。いずれの場合も、タイヤ浮き情報が閾値Ａ以上又は閾値Ｂ以下となっている時間が所定時間以上の場合に、タイヤ浮きが発生していると判定することが好ましい。これにより、瞬間的なタイヤ浮きを整備中であると誤判定することを防止できる。なお、閾値Ａ又は閾値Ｂは、二輪が路面から離れた時の車高又は空気圧を実験的に定めておき、その値と同程度か若干小さい値として定められている。

４輪の車高情報のうち前輪の二輪又は後輪の二輪のタイヤ浮き情報が閾値Ａ以上又は閾値Ｂ以下であればタイヤ浮きが発生していると判定するのは、二輪だけリフトアップされることが多いからである。また、右前輪と右後輪の二輪又は左前輪と左後輪の二輪のタイヤ浮き情報が閾値Ａ以上又は閾値Ｂ以下であればタイヤ浮きが発生していると判定しないのは、車両１１が路肩に乗り上げて駐車した場合に、タイヤ浮きが発生していると誤判定することを防止するためである。また、ある一輪のタイヤ浮き情報が閾値Ａ以上又は閾値Ｂ以下であればタイヤ浮きが発生していると判定しないのは、車両１１が悪路を走行中に一輪だけタイヤが浮いても、タイヤ浮きが発生していると誤判定することを防止するためである。

また、整備完了判定部３７は、整備が完了したか否かを判定する。整備が完了したことは、タイヤ浮きが発生していないことと同義とすることもできる。しかし、サービスマンが一度、車両１１を昇降機１２から下ろしても、さらに別の整備を行ったり車両１１を移動だけすることもある。そこで、整備完了判定部３７は、四輪のタイヤ浮き情報が全て閾値Ａ未満又は閾値Ｂより大である場合、かつ、車両１１が所定距離Ｙ〔ｍ〕を走行した場合、整備が完了したと判定する。所定距離Ｙ〔ｍ〕は、修理工場から出る程度の距離でよく、例えば５００〔ｍ〕である。

リフトアップ判定部３４は、タイヤ浮きが発生していると判定すると、整備中フラグをオンに設定する。また、整備完了判定部３７は、整備が完了したと判定すると整備中フラグをオフに設定する。リモートダイアグ停止部３３は、整備中フラグがオンの場合、リモートダイアグを停止し、整備中フラグがオフの場合、リモートダイアグを再開する。

図７は、リフトアップ判定部３４が、タイヤ浮きが発生していることを検出する手順を示すフローチャート図の一例である。以下では、タイヤ浮き情報を車高情報として説明する。図７のフローチャート図は、例えばＩＧオン又はメインシステム（ハイブリッド車や電気自動車の場合）の間、サイクル時間毎に繰り返し実行される。このサイクル時間を車高情報の取得サイクル又は取得サイクルのＮ倍（Ｎ：２以上）としてもよい。

まず、リフトアップ判定部３４は、４輪の車高情報を取得する（Ｓ１０）。４輪の車高情報を全て一度に取得しても、別々に取得してもよい。

次に、リフトアップ判定部３４はタイマをオンにする（Ｓ２０）。このタイマは、タイヤ浮きが発生し始めてからの時間を計測するタイマである。

リフトアップ判定部３４は、前輪又は後輪の二輪の車高情報が閾値Ａ以上か否かを判定する（Ｓ３０）。前輪又は後輪の二輪の車高情報が閾値Ａ以上でない場合（Ｓ３０のＮｏ）、車両１１がリフトアップされている可能性はないので、リフトアップ判定部３４はタイマをオフにして図７の手順を終了する（Ｓ７０）。

前輪又は後輪の二輪の車高情報が閾値Ａ以上の場合（Ｓ３０のＹｅｓ）、車両１１がリフトアップされている可能性があるので、リフトアップ判定部３４はタイマを監視して所定時間が経過したか否かを判定する（Ｓ４０）。

所定時間が経過していない場合（Ｓ４０のＮｏ）、車高情報を閾値Ａと比較する必要があるので、リフトアップ判定部３４は、繰り返し、四輪の車高情報を取得する（Ｓ５０）。こうすることで、リフトアップ判定部３４は車高情報が変化したことを検出できる。

所定時間が経過した場合（Ｓ４０のＹｅｓ）、タイヤ浮きが発生していることになるので、リフトアップ判定部３４は、タイヤ浮きが発生したと判定する（Ｓ６０）。すなわち、リフトアップ判定部３４は、整備中フラグをオンに設定する。

なお、前輪又は後輪の二輪の車高情報が閾値Ａ以上でなくても、ある一輪の車高情報が閾値Ａ以上であればタイヤ浮きが発生していると判定してもよい。この場合、ステップＳ４０の所定時間を、前輪又は後輪の二輪の車高情報が閾値Ａ以上である場合よりも長くする。一輪だけの車高情報でも、閾値Ａ以上である状態が長時間継続すれば、タイヤ浮きが発生している（整備中）と判定することができるからである。すなわち、リフトアップ判定部３４は、車両１１が悪路を走行中に一輪だけタイヤが浮いた状態と、一輪だけのリフトアップを区別することができる。同様の考え方に沿って、ステップＳ４０の所定時間を、車高情報が閾値Ａ以上となった車輪の数に応じて可変にしてもよい。

図８は、整備完了判定部３７が、整備が完了したか否かを判定する手順を示すフローチャート図の一例である。図８のフローチャート図は、例えば整備中フラグがオンになるとサイクル時間毎に実行される。

まず、整備完了判定部３７は、４輪の車高情報を取得する（Ｓ１１０）。４輪の車高情報を全て一度に取得しても、別々に取得してもよい。

整備完了判定部３７は、四輪全ての車高情報が閾値Ａ未満か否かを判定する（Ｓ１２０）。四輪全ての車高情報が閾値Ａ未満でない場合（Ｓ１２０Ｎｏ）、車両１１はリフトアップされた状態と考えられるので、図８の手順を終了する。

四輪全ての車高情報が閾値Ａ未満の場合（Ｓ１２０Ｙｅｓ）、車両１１はリフトアップされた状態から開放されたと考えられるので、整備完了判定部３７は走行距離をカウントする走行距離Ｌを初期化（＝０）する（Ｓ１３０）。

そして、整備完了判定部３７は、走行距離Ｌが閾値Ｙ以上か否かを判定する（Ｓ１４０）。走行距離Ｌが閾値Ｙ以上でない場合（Ｓ１４０のＮｏ）、車両１１が修理工場内で再度整備される可能性があるので、整備完了判定部３７はステップＳ１４０の判定を繰り返す。

走行距離Ｌが閾値Ｙ以上の場合（Ｓ１４０のＹｅｓ）、車両１１が修理工場を出て整備が完了したと考えられるので、整備完了判定部３７は整備が完了したと判定する（Ｓ１５０）。すなわち、整備完了判定部３７は、整備中フラグをオフに設定する。

図９は、リモートダイアグ停止部３３がリモートダイアグを停止又は再開する手順を示すフローチャート図の一例である。図９の手順は、リモートダイアグ停止部３３が、例えば整備中フラグが変化したことによる割り込みを検出してスタートする。

リモートダイアグ停止部３３は、整備中フラグを監視し、整備中フラグの状態が変化したことを検出する（Ｓ２１０）。

リモートダイアグ停止部３３は、整備中フラグがオンからオフに変化した場合には（Ｓ２２０のＹｅｓ）、リモートダイアグを再開し（Ｓ２３０）、整備中フラグがオフからオンに変化した場合には（Ｓ２２０のＮｏ）、リモートダイアグを停止する（Ｓ２４０）。

具体的には、リモートダイアグ停止部３３は、リモートダイアグを停止する場合、診断部３２が異常を検出することを停止する態様か、診断部３２が異常を検出しても診断情報３５を情報センタ５０に送信しないようにする態様のいずれかを実行する。前者の場合、リモートダイアグ停止部３３は、例えば、プログラム上の診断部３２の処理が実行されないように処理を分岐させ、後者の場合、リモートダイアグ停止部３３はプログラム上の送信要求部３６の処理が実行されないように処理を分岐させる。

リモートダイアグ停止部３３がいずれかの態様を実行することで、リモートダイアグを停止させることができる。換言するとリモートダイアグが停止されていない場合は、診断部３２が異常を検出して診断情報３５を生成すると、送信要求部３６が診断情報３５を情報センタ５０に送信することができる。

以上説明したように、本実施例の故障診断装置１００は、車両１１がリフトアップされ種々の部品２１が取り外され得る状況になったことを検出して、リモートダイアグを停止することができる。整備が完了するとリモートダイアグが再開されるので、故障診断装置１００が異常を検出できない状況や、異常を検出しても診断情報３５を情報センタ５０に送信できない状況となることを確実に防止できる。

実施例１では、各輪のタイヤ浮き情報に基づき、タイヤ浮きが発生している状況を整備中とみなしてタイヤ浮きが発生しているか否かを判定した。しかし、タイヤ浮きが発生していても整備中とは限らない状況もある。本実施例では、タイヤ浮きが発生していても整備中とはならない状況を検出してリモートダイアグを停止しない故障診断装置１００について説明する。なお、故障診断システム２００の概略構成図は図５と同様なので説明を省略する。

タイヤ浮きが発生していても整備中とは限らない状況とは、車両１１が極度に傾いている状態が挙げられる。例えば、傾斜のきつい坂路に停車中の状態や、このような坂路で前輪若しくは後輪の二輪又は一輪が段差を超えて停止した状態も該当する可能性がある。

本実施例のリフトアップ判定部３４は、タイヤ浮きが発生していても整備中とは限らない状況を検出して、その場合には整備中フラグをオンに設定しないことで、リモートダイアグを可能にする。特に、車両１１が横転するような状況では、異常が生じる可能性が高く、確実にリモートダイアグすることができる。

リフトアップ判定部３４は、タイヤ浮きが発生していても整備中とは限らない状況であることを、ナビシステム２７を利用して検出する。サービスマンが車両１１をリフトアップするのは、修理工場、駐車場、路肩等であり、少なくとも道路上で行うことはないか又は極めて少ないとしてよい。そこで、リフトアップ判定部３４は、ナビシステム２７が検出した現在位置が道路上か否かを判定して、道路上でない場合にのみタイヤ浮きが発生している状況（整備中）であると判定する。

また、タイヤ浮きが発生している状況であることを判定するため、リフトアップ判定部３４は、３Dジャイロセンサが検出する車体の傾斜情報を利用してもよい。３Dジャイロセンサは例えばナビシステム２７が有している。傾斜情報により、車体がピッチング方向及びローリング方向にそれぞれどのくらい傾いているかを検出することができる。

リフトアップ判定部３４は、傾斜情報に基づき、車体が所定値以上に傾いていない場合に限り、タイヤ浮きが発生している状況（整備中）であると判定する。

また、リフトアップ判定部３４は、現在位置と傾斜情報の両方に基づき、タイヤ浮きが発生している状況（整備中）であると判定してもよい。こうすることで、タイヤ浮きが発生していても整備中とはならない状況をより確実に排除して、リモートダイアグを確実に実行することができる。

図１０は、リフトアップ判定部３４が、タイヤ浮きが発生していることを検出する手順を示すフローチャート図の一例である。図１０において図７と同じステップには同じステップ番号を付した。

まず、リフトアップ判定部３４は、４輪の車高情報を取得する（Ｓ１０）。４輪の車高情報を全て一度に取得しても、別々に取得してもよい。

次に、リフトアップ判定部３４は、現在位置が道路でなく、かつ、車体が傾いていないか否かを判定する（Ｓ１５）。すなわち、リフトアップ判定部３４は、整備中となりうる状況であるか否かを判定する。現在位置が道路でないか否かだけ、又は、車体が傾いていないか否かだけを判定してもよい。

現在位置が道路でなく、かつ、車体が傾いていない場合（Ｓ１５のＹｅｓ）、整備中となりうる状況なので、リフトアップ判定部３４はタイマをオンにする（Ｓ２０）。一方、現在位置が道路であるか、又は、車体が傾いてる場合（Ｓ１５のＮｏ）、整備中となりうる状況ではないので、リフトアップ判定部３４は図１０の手順を終了する。これにより、タイヤ浮きが発生していても整備中とはならない状況では、整備中フラグがオンに設定されることを防止できる。したがって、診断部３２が異常を検出した場合は、リモートダイアグすることができる。

以降の処理は、実施例１の図７と同様である。すなわち、リフトアップ判定部３４は、タイマをオンにした後（Ｓ２０）、前輪又は後輪の二輪の車高情報が閾値Ａ以上か否かを判定する（Ｓ３０）。前輪又は後輪の二輪の車高情報が閾値Ａ以上の場合（Ｓ３０のＹｅｓ）、車両１１がリフトアップされている可能性があるので、リフトアップ判定部３４はタイマを監視して所定時間が経過したか否かを判定する（Ｓ４０）。また、リフトアップ判定部３４は、ある一輪の車高情報が閾値Ａ以上であればタイヤ浮きが発生していると判定してもよい。

前輪又は後輪の二輪の車高情報が閾値Ａ以上か否かを判定する（Ｓ３０）。前輪又は後輪の二輪の車高情報が閾値Ａ以上の場合（Ｓ３０のＹｅｓ）、車両１１がリフトアップされている可能性があるので、リフトアップ判定部３４はタイマを監視して所定時間が経過したか否かを
所定時間が経過していない場合（Ｓ４０のＮｏ）、車高情報を閾値Ａと比較する必要があるので、リフトアップ判定部３４は、繰り返し、車高情報を取得する（Ｓ５０）。所定時間が経過した場合（Ｓ４０のＹｅｓ）、タイヤ浮きが発生していることになるので、リフトアップ判定部３４は、タイヤ浮きが発生したと判定する（Ｓ６０）。すなわち、リフトアップ判定部３４は、整備中フラグをオンに設定する。

整備完了判定部３７が、整備が完了したか否かを判定する手順（図８）、リモートダイアグ停止部３３がリモートダイアグを停止又は再開する手順（図９）は、実施例１と同様である。

以上説明したように、本実施例の故障診断装置１００は、タイヤ浮きが発生していても整備中とはならない状況を検出することで、リモートダイアグを停止しないので、異常が生じた場合には、リモートダイアグすることができる。

実施例１又は２のリモートダイアグの停止態様では、診断情報３５が情報センタ５０に送信されることがなかった。しかし、診断情報３５が情報センタ５０に送信されても、情報センタ５０が、それが整備中に生じたものであることを判別できれば、診断情報３５の統計処理やメーカや修理工場へのフィードバックに支障をきたすことはない。むしろ、情報センタ５０では、ダイアグコードとＦＦＤが得られるので、両者の関係を統計処理して診断情報３５を有効に活用することも可能になる。

そこで、本実施例では、リモートダイアグ停止部３３がリモートダイアグを停止した場合に、診断情報３５に整備中であることを示す情報を含めて情報センタ５０に送信する故障診断装置１００について説明する。

図１１は、解析センタの機能ブロック図の一例を示す。車両１１の故障診断装置１００の機能ブロック図は図５と同様であるが、リモートダイアグ停止部３３の機能が異なる。本実施例のリモートダイアグ停止部３３は、整備中フラグがオンに設定された場合、診断情報３５に整備中であるか否かを示す情報（以下、整備判定情報という）を含めるように診断部３２に要求する。

図１２は、本実施例の診断情報３５を模式的に説明する図の一例である。整備判定情報は、整備中フラグがオンに設定された状態の診断情報３５では「１」に、整備中フラグがオフに設定された状態の診断情報３５では「０」になる。したがって、情報センタ５０は整備判定情報に基づき、その診断情報３５が整備中に生じたものかそうでないのかを判別することができる。なお、整備中フラグがオフに設定された状態の診断情報３５に整備判定情報を一切含めないことで、整備判定情報が診断情報３５に含まれている場合には、整備中フラグがオンに設定された状態の診断情報３５であることを示してもよい。

図１１に戻り、情報センタ５０は、診断情報取得部４１、診断情報取捨部４２及び診断情報ＤＢ４３を有する。診断情報取得部４１及び診断情報取捨部４２は、ＣＰＵがプログラムを実行することにより実現され、診断情報ＤＢ４３はＨＤＤに記憶されている。

診断情報取得部４１は、通信装置２０６により受信した診断情報３５を診断情報ＤＢ４３に記憶する。診断情報取得部４１は、例えば車両１１の型式毎に区分して時系列に診断情報３５を診断情報ＤＢ４３に登録する。こうすることで、車種毎に診断情報３５を利用でき、また、ある車種で同系統のダイアグコードが検出されたことや検出され始めた時期が検出されるようになる。

診断情報取捨部４２は、診断情報ＤＢ４３に記憶された診断情報３５の整備判定情報を参照して、診断情報毎に、整備中のものか否かを判別する。診断情報取捨部４２は、整備中でない診断情報３５と整備中の診断情報３５を区分して統計処理に提供する。また、診断情報取捨部４２は、整備中の診断情報３５を診断情報ＤＢ４３から消去してもよい。

図１３は、リモートダイアグ停止部３３がリモートダイアグを停止又は再開する手順を示すフローチャート図の一例である。なお、リフトアップ判定部３４が、タイヤ浮きが発生していることを検出する手順（図７又は図１０）、整備完了判定部３７が、整備が完了したか否かを判定する手順（図８）、リモートダイアグ停止部３３がリモートダイアグを停止又は再開する手順（図９）は、実施例１又は２と同様である。

リモートダイアグ停止部３３は、整備中フラグを監視し、整備中フラグの状態が変化したことを検出する（Ｓ２１０）。

リモートダイアグ停止部３３は、整備中フラグがオンからオフに変化した場合には（Ｓ２２０のＹｅｓ）、リモートダイアグを再開する（Ｓ２３０）。具体的には、本実施例のリモートダイアグ停止部３３は、診断情報３５に「０」の値を有する整備判定情報を含めるように診断部３２に要求する。

なお、整備中フラグがオフからオンに変化した場合には（Ｓ２２０のＮｏ）、リモートダイアグを停止する（Ｓ２４０）。具体的には、リモートダイアグ停止部３３は、診断情報３５に「１」の値を有する整備判定情報を含めるように診断部３２に要求する。

図１４（ａ）は、診断部３２が診断情報３５を生成する手順を示すフローチャート図の一例を、図１４（ｂ）は情報センタ５０が診断情報３５を受信する手順を示すフローチャート図の一例を、それぞれ示す。

まず、診断部３２はＷＤＴ等によりＥＣＵ２３を監視して異常が検出されるか否を判定する（Ｓ３１０）。異常が検出されない場合（Ｓ３１０のＮｏ）、診断情報３５を生成しないので図１４（ａ）（ｂ）の手順は終了する。
異常が検出された場合（Ｓ３１０のＹｅｓ）、診断部３２は、診断情報３５を生成するが、この際、診断情報３５に整備判定情報を追加する（Ｓ３２０）。診断部３２は、リモートダイアグ停止部３３からの要求に従って、整備判定情報に「１」又は「０」を含める。これにより、この診断情報３５が整備中に検出された異常かそうでないかが明確になる。

ついで、送信要求部３６は、所定のタイミングで診断情報３５を情報センタ５０に送信する（Ｓ３３０）。なお、送信要求部３６は、補助記憶装置２８に記憶されている整備判定情報が「１」の診断情報３５を消去し、整備判定情報が「０」の診断情報３５を消去しない。こうすることで、整備中の診断情報３５がＥＣＵ２３に残ることによりサービスマンが混乱することを防止でき、また、整備中でない状態で生成された診断情報３５のみがＥＣＵ２３に残ることにより、サービスマンが診断情報３５に基づいて適切に整備することが可能になる。

次に、情報センタ５０の通信装置２０６は診断情報３５を受診し、診断情報取得部４１が診断情報３５を取得する（Ｓ４１０）。診断情報取得部４１は、取得した診断情報３５を診断情報ＤＢ４３に記憶させる（Ｓ４２０）。

そして、診断情報取捨部４２は、例えば、1日に1回など決まったタイミングで、診断情報ＤＢ４３の各診断情報の整備判定情報に基づき、診断情報３５を区分する（Ｓ４３０）。これにより、診断情報３５を２つのグループに区分できる。

そして、情報センタ５０はそれぞれのグループの診断情報３５に例えば統計処理を施す（Ｓ４４４０）。情報センタ５０は、整備判定情報が「１」の診断情報３５からも、例えば車種毎に、整備時に取り外される部品２１（整備の邪魔になる部品２１）等を解析することができる。この場合、整備対象の部品（本当に故障している部品）と関連付けることがより好ましい。なお、整備判定情報が「１」の診断情報３５を消去してもよい。

本実施例の故障診断装置１００は、診断情報３５が情報センタ５０にリモートダイアグされても、情報センタ５０は整備による診断情報３５を判別できるので、整備によるものでない診断情報３５の解析を確実に行うことができる。

１１ 車両
１２ 昇降機
１３ 基地局
１４ ネットワーク
２１ 部品
２２ センサ
２３ ＥＣＵ
２４ 通信装置
２５ 車載ＬＡＮ
２６ タイヤ浮きセンサ
２７ ナビゲーションシステム
３３ リモートダイアグ停止部
３４ リフトアップ判定部
３５ 診断情報
３６ 送信要求部
３７ 整備完了判定部
３８ ハイトセンサ
３９ 空気圧センサ
１００ 故障診断装置
２００ 故障診断システム

Claims (14)

1. 車両の部品を診断して診断情報を生成する診断手段と、
   前記診断情報を記憶する記憶手段と、
   前記診断情報をサーバに送信する送信手段と、を有する故障診断装置において、
   前記車両の車輪に加わる車重が減少したことを検出する車輪浮き検出手段と、
   前記車輪浮き検出手段が前記車輪に加わる車重が減少したことを検出した場合、前記診断情報の生成又は送信を禁止する診断停止手段と、
   を有することを特徴とする故障診断装置。
2. 車両の部品を診断して診断情報を生成する診断手段と、
   前記診断情報を記憶する記憶手段と、
   前記診断情報をサーバに送信する送信手段と、を有する故障診断装置において、
   前記車両の車輪に加わる車重が減少したことを検出する車輪浮き検出手段と、
   前記車輪浮き検出手段が前記車輪に加わる車重が減少したことを検出した場合、前記診断情報に、前記車輪に加わる車重が減少した状態の診断情報であることを示す識別情報を含ませる診断停止手段と、
   を有することを特徴とする故障診断装置。
3. 前記車両の位置情報を検出する位置検出手段を有し、
   前記車輪浮き検出手段は、前記位置情報が道路に相当する場合、車輪に加わる車重が減少したことを検出しない、
   ことを特徴とする請求項１又は２記載の故障診断装置。
4. 前記車両の傾斜を検出する傾斜検出手段を有し、
   前記車輪浮き検出手段は、前記傾斜が所定値以上の場合、車輪に加わる車重が減少したことを検出しない、
   ことを特徴とする請求項１〜３いずれか１項記載の故障診断装置。
5. 前記車輪浮き検出手段は、４つの前記車輪のうち、前輪又は後輪の二輪に加わる車重が減少したことを検出する、
   ことを特徴とする請求項１〜４いずれか1項記載の故障診断装置。
6. 前記車輪浮き検出手段は、４つの前記車輪のうち、一輪に加わる車重が減少したことを検出する、
   ことを特徴とする請求項１〜４いずれか1項記載の故障診断装置。
7. 前記車輪浮き検出手段は、4つの前記車輪毎に車高を検出する車高センサである、
   ことを特徴とする請求項１〜６いずれか1項記載の故障診断装置。
8. 前記車輪浮き検出手段は、4つの前記車輪のタイヤ毎に空気圧を検出する空気圧センサである、
   ことを特徴とする請求項１〜６いずれか1項記載の故障診断装置。
9. 前記車輪浮き検出手段が、前記車両の車輪に加わる車重が減少したことから該車両が整備中であると判定した後、
   該車両の整備が完了したことを検出する整備完了検出手段を有する、
   ことを特徴とする請求項１〜８いずれか1項記載の故障診断装置。
10. 前記整備完了検出手段は、前記車輪に加わる車重が増加し、かつ、前記車両が所定距離以上走行した場合、該車両の整備が完了したことを検出する
    ことを特徴とする請求項９項記載の故障診断装置。
11. 前記診断手段は、
    前記識別情報が追加された前記診断情報を、前記送信手段が送信した後、前記記憶手段から消去する、
    ことを特徴とする請求項２項記載の故障診断装置。
12. 車両の部品を診断して診断情報を生成する診断手段と、
    前記診断情報を記憶する記憶手段と、
    前記診断情報をサーバに送信するよう送信手段に要求する送信要求手段と、を有する故障診断付き電子制御ユニットにおいて、
    車載された車輪浮き検出手段が、前記車輪に加わる車重が減少したことを検出した場合、前記診断情報の生成又は送信を禁止する診断停止手段と、
    を有することを特徴とする故障診断付き電子制御ユニット。
13. 車両に搭載された車載システムの診断情報を送信する故障診断装置と、診断情報を受信するサーバとを有する故障診断システムにおいて、
    前記故障診断装置は、
    車両の部品を診断して診断情報を生成する診断手段と、
    前記診断情報を記憶する記憶手段と、
    前記診断情報をサーバに送信する送信手段、
    前記車両の車輪に加わる車重が減少したことを検出する車輪浮き検出手段と、
    前記車輪浮き検出手段が前記車輪に加わる車重が減少したことを検出した場合、前記診断情報に、前記車輪に加わる車重が減少した状態の診断情報であることを示す識別情報を含ませる診断停止手段と、を有し、
    前記サーバは、
    前記診断情報を受信する受信手段と、
    前記識別情報に基づき、前記診断情報を取捨する診断情報取捨手段と、を有する、
    ことを特徴とする故障診断システム。
14. 車両の部品を診断して診断情報を生成する診断手段と、
    前記診断情報を記憶する記憶手段と、
    前記診断情報をサーバに送信する送信手段と、を有する故障診断装置の故障診断方法において、
    車輪浮き検出手段が、前記車両の車輪に加わる車重が減少したことを検出するステップと、
    前記車輪浮き検出手段が前記車輪に加わる車重が減少したことを検出した場合、診断停止手段が、前記診断情報の生成又は送信を禁止するステップと、
    を有することを特徴とする故障診断方法。

Images