JP4940779B2 - 遠隔故障診断システム - Google Patents

Description

本発明は、遠隔から車両に接続して故障を診断する遠隔故障診断システムに関する。

自動車には高密度電子部品を実装した電子機器が数多く搭載されており、近年では、エンジンルームへの搭載が可能となるように、比較的高温な環境においても動作可能な半導体部品の採用も始まっている。

しかし、半導体部品の動作特性、信頼度性能は一般に、量産開始前、代表サンプルを用いて信頼度を予測しているに過ぎない。すなわち、量産開始後は、製品の個々について耐環境性能試験や信頼度試験による出荷前のスクリーニングがなされているわけではなく、また、自動車メーカとしても、受入検査で一品一品寿命試験によるスクリーニングなどが実施されているわけでもない。

したがって、電子機器を搭載した車両を、市場に製品として出荷した後も、ある割合で、性能劣化、故障が発生する可能性は残る。特に、半導体部品としての通常使用条件を超える環境下では、故障の発生する確率も増大する。とりわけ自動車では、ユーザの使用環境、使用条件、使用期間、使用頻度などのバラツキが大きく、市場での車載電子部品の故障の発生確率は他の民生機器に比べて高いと予想できる。

一方、たとえばエンジン制御特性の不具合は、Ｏ₂センサなどのセンサの劣化、故障などによって発生することも多く報告されており、特に、定常的な条件よりも、負荷が大きく変動する過渡状態でのみ不具合現象が出現するケースも多い。したがって、実走行中での不具合発生確率の高まった状況下でのデータを多くの車両からリアルタイムに取得できれば、不具合現象の予測、要因の特定に多大な効果が期待できる。

このような観点から車両の故障診断を行う技術はすでに種々のものが知られている。

たとえば特許文献１には、ネットワークを介して故障した車両と接続し、その故障個所を診断する故障診断システムが提案されている。このシステムによれば、車両を遠隔的に接続することで、顧客がサービス工場に出向かなくとも、車両が故障しているかどうかや故障個所を把握できるため、大変便利である。

また、特許文献２には、空燃比や点火時期などの学習値をデータベースに蓄積し、学習値が正規範囲から外れているときに異常と判断して、実際に車両に故障が生じる前にユーザ等に通知する車両管理システムが提案されている。このシステムによれば、個々の車両の健康状態を管理でき、これにより故障発生を未然に回避することができる。
特開２００２−２２８５５２号公報 特開２００２−２０２００３号公報

自動車に搭載される半導体部品において、故障を誘発するストレス要因としては、熱衝撃、ヒートサイクル、パワーサイクル、湿度、振動などがある。これらのストレスによって、半導体チップ内の接合部の劣化によるリーク電流の増加、端子のはんだ表面の電気的接続性の劣化、機械的な破断による接触抵抗の増大などを経て、最終的なユニットとしての機能不全を引き起こす。

とりわけエンジンルーム内では、熱、振動、湿度などは半導体部品にとっては過酷な環境にあり、遠隔より環境変動を監視して、電子制御ユニット（ＥＣＵ）の特性チェックを行うことは、故障の早期発見、故障発生予測に大きく貢献すると考えられる。

したがって、この種の遠隔故障診断システムには、故障診断の信頼性を高めることが望まれている。本発明はこの観点からの遠隔故障診断システムの改良を目的としている。

本発明の一側面によれば、所定の車載部品のストレス要因に関する車両データを所定のタイミングで送信するように構成された車両と、ネットワークを介してこの車両と接続され、前記車両から受信される前記車両データを蓄積するとともに、蓄積した前記車両データに基づき前記車両の車載部品の故障診断を行う故障診断サーバと、を含む遠隔故障診断システムが提供される。この遠隔故障診断システムにおいて、前記車両は、第１の故障診断プログラムを書き換え可能に保持するメモリと、前記第１の故障診断プログラムを実行することにより、前記車両データの送信を制御するＣＰＵとを有する。一方、前記故障診断サーバは、前記車載部品の故障に対する警戒レベルに応じた複数の故障診断プログラムを記憶する記憶手段と、前記車両より受信した前記車両データに基づいて、前記警戒レベルを判定する判定手段と、前記記憶手段に記憶されている前記複数の故障診断プログラムから、前記判定手段により判定された警戒レベルに対応する第２の故障診断プログラムを選択してこれを前記車両に送信する送信手段とを有する。これにより前記車両は、前記送信手段により送信された前記第２の故障診断プログラムを受信し、前記メモリに保持されている前記第１の故障診断プログラムを、受信した前記第２の故障診断プログラムで更新する更新手段を更に有する。

上記の構成によれば、実走行中などにおける故障を誘発するストレス要因に関する車両データに基づいて、統計的な故障診断が可能になる。これによって、より高精度な故障診断が可能になる。

また、前記複数の故障診断プログラムはそれぞれ、対応する警戒レベルに応じた頻度で前記車両データの送信が行われるようにプログラムされていることが好ましい。これにより、警戒レベルが高まるにつれて車両データの送信頻度を高めることができ、車載部品の故障時期をより正確に判定することができる。

本発明の好適な実施形態によれば、前記車両データは、車種情報を含み、前記故障診断サーバは、蓄積した前記車両データに基づいて、車種別の統計処理を行うことが好ましい。この構成により、個別の車両だけでは予測が難しかった車載部品の経年劣化を予測できるようになる。

また、前記故障診断サーバは、前記統計処理の結果に基づいて、前記判定手段における前記警戒レベルの判定基準を変更することが好ましい。この構成によれば、時々刻々と蓄積されていく車両データに基づいて、警戒レベルの判定基準が最適化され、より正確な警戒レベルの判定を行うことができる。

本発明の好適な実施形態によれば、前記ストレス要因に関する車両データは、前記車載部品の雰囲気温度、雰囲気湿度、振動数を含むことが好ましい。これらのデータによってストレス要因を正確に予測することができる。

本発明の好適な実施形態によれば、前記車両は、前記判定手段による判定結果に応じて、当該車両の入庫案内および／または当該車載部品の手配を行うための手段を更に有することが好ましい。この構成によれば、ユーザは故障診断結果に応じてとるべき対応指針が容易に得られ、この故障診断がより有益なものとなる。

本発明によれば、遠隔故障診断システムにおける故障診断の信頼性を高めることができる。

以下、図面を参照して本発明の好適な実施形態について詳細に説明する。なお、本発明は以下の実施形態に限定されるものではなく、本発明の実施に有利な具体例を示すにすぎない。また、以下の実施形態の中で説明されている特徴の組み合わせの全てが本発明の課題解決手段として必須のものであるとは限らない。

図１は、本実施形態に係る遠隔故障診断システムの構成例を示した図である。情報センタ１００は、顧客の車両１１０、１１１やサービス工場１２０などから送信される各種の情報を蓄積するとともに、故障診断結果を提供するコンピュータ群である。情報センタ１００は、顧客の車両１１０、サービス工場１２０とインターネット１３０やモバイル通信回線などを経由して接続している。

顧客の車両１１０及び１１１は、故障の診断に必要なデータを取得して情報センタ１００に送信する。

サービス工場１２０は、いわゆる修理工場などであり、故障車両１１１から車両データを読み出したり、故障個所や故障の原因に関する情報を情報センタ１００に送信したりする。サービス工場１２０にはサービス工場用のクライアント装置１２１が設定されている。このクライアント装置１２１は、一種のコンピュータであり、ＣＰＵ、メモリ、ハードディスクドライブ及び通信インタフェースなどを備えている。

情報センタ１００は、故障診断処理を実行する故障診断サーバ１０１を有し、この故障診断サーバ１０１は、以下に示す各データベース（ＤＢ）１０２〜１０８に対し読み書き可能に構成されている。

顧客情報データベース（ＤＢ）１０２は、顧客（全ての顧客又は故障診断サービスの契約者）の情報を格納する。

故障情報データベース１０３は、故障車両１１１やサービス工場１２０のクライアント装置１２１から送信された故障データに基づいて、図４に示すような、故障発生履歴テーブルを蓄積する。

車両情報データベース１０４は、顧客の車両１１０、１１１から送信されてきた車両データに基づいて、図５に示すような、車両属性テーブル、個別車両モニタテーブルを蓄積する。

サービス工場データベース１０５は、サービス工場の位置などに関する情報を格納する。地図データベース１０６は、地図データを格納する。

診断プログラムデータベース１０７は、図６に示すような、車種および、診断対象とする電子制御ユニットの故障に対する警戒レベルに応じて内容の異なる故障診断プログラムを記述した診断プログラム設定テーブルを記憶している。警戒レベルについては後述する。

診断データベース１０８は、図７に示すような、車種別の、診断に係る注目データ（診断モニタデータ）に対する、警戒ラインを記述した警戒ライン設定テーブル、車種別に各警戒レベルの内容を規定する警戒レベル設定テーブル、および、車種ごとに各警戒レベルとＭＴＴＦ（平均初期故障時間）との関係を規定する車種別信頼度予測テーブルを蓄積する。

故障診断サーバ１０１は、一種のコンピュータであり、ＣＰＵ、メモリ、ハードディスクドライブ及び通信インタフェースなどを備えている。以下の説明では、フローチャートに対応するプログラムをＣＰＵが実行することにより、各種の処理が実行されることになる。

図２は、本実施形態に係る車両１１０の構成例を示したブロック図である。メインコントローラ２００は、ＣＰＵ、メモリなどからなり、各種制御ユニットやセンサから制御データやセンサ出力を取得し、メモリに蓄積したり、蓄積した情報をモバイル端末（モバイル通信インタフェース）２５０や近距離無線通信インタフェース２５５を介して情報センタ１００に送信したり、情報センタ１００から故障予測結果を受信したりする。近距離無線通信インタフェース２５５は、無線ＬＡＮ、ブルートゥース及びＥＴＣ用の無線規格などを採用できる。

ボディ系システム２１０は、パワーウインドウユニット２１１、ヘッドライトユニット２１２、オーディオユニット２１３、エアコンユニット２１４、ワイパーユニット２１５及びドアロックユニット２１６などを含み、制御結果や電流・電圧などのデータをメインコントローラ２００へと出力する。

制御系システム２２０は、ブレーキがロックしないように制御するＡＢＳ（アンチロック・ブレーキ・システム）２２１、車両の挙動を制御するＤＳＣ（ダイナミック・スタビリティ・コントローラ）２２２、燃料の供給を制御するＥＧＩ（エレクトリック・ガス・インジェクション）２２３、自動変速機を制御するＥＡＴ（エレクトリック・オートマティック・トランスミッション）２２４及び自動走行などドライバの運転を補助するＩＣＣＷ（インテリジェント・クルーズ・コントロール＆ワーニング）２２５を含み、それぞれ、メインコントローラ２００に対して制御結果などを通知する。本実施形態における制御系システム２２０はさらに、エンジンルーム内に搭載されエンジンの制御を司るエンジンＥＣＵ２２６を含む。

また車両には各種のセンサ群が搭載されている。例えば、ＧＰＳ（グローバル・ポジショニング・システム）衛星からの電波を受信して車両の現在位置を算出するＧＰＳセンサ２３１、渋滞情報などを受信するＶＩＣＳ情報受信機２３２、車両の速度を検出する車速センサ２３３、前方の車両など他の車両との距離を計測する車間距離センサ２３４、車両のヨーレートを検出するヨーレートセンサ２３５、車両の加速度を検出する加速度センサ、車両の操舵角を検出する操舵角センサ２３７、スロットルの開度を検出するスロットル開度センサ２３８、ブレーキの踏み込み圧力を検出するブレーキ圧センサ２３９、ウインカスイッチの動作状態を検出するウインカＳＷセンサ２４０、外気温を測定するための外気温センサ２４１、雨が降っているか否かや雨量を測定するレインセンサ２４２、エンジン回転数を検出するエンジン回転数センサ２４６などが車両には搭載されている。本実施形態ではこれらに加え、エンジンＥＣＵ２２６のストレス要因となる雰囲気温度を検出するための温度センサ２４３、同じくエンジンＥＣＵ２２６のストレス要因となる雰囲気湿度を検出するための湿度センサ２４４、および、同じくエンジンＥＣＵ２２６のストレス要因である振動数を検出するための振動センサ２４５が、エンジンルーム内に搭載される。

メインコントローラ２００は、そこに接続された各種センサの出力に基づいて、上記したボディ系システムや制御系システムの制御を統括的に行うものであるが、このメインコントローラ２００はさらに、制御系システム２２０を構成する特定の制御ユニットの故障診断処理も行う。本実施形態では、一例として、故障診断対象を車載部品であるエンジンＥＣＵ２２６とし、上記した温度センサ２４３、湿度センサ２４４、振動センサ２４５などの出力に基づいて、その故障診断を行う。加えて、車両１１０にはエンジンＥＣＵ２２６の電源電流や出力電圧などを監視するためのユニット監視モジュール２８０も設けられ、そのモニタデータはメインコントローラ２００に入力される。

ナビゲーション・コントローラ２６０は、ＧＰＳセンサ２３１からの測位データに基づいて、ハードディスクドライブなどに記憶されている地図情報を検索し、現在位置の地図を表示する装置である。顧客たるドライバへの入出力装置２７０は、液晶ディスプレイなどの表示装置や音声出力装置などを含んでおり、ナビゲーション・コントローラ２６０からの地図データを出力したり、情報センタ１００からの故障診断結果を出力したりする。

図８は、本実施形態における故障診断に係るメインコントローラ２００のハードウェア構成を示すブロック図である。図示の如く、メインコントローラ２００は、このメインコントローラの機能を司るＣＰＵ２０１、固定的なプログラムやデータを記憶しているＲＯＭ２０２、ＣＰＵ２０１のワークエリアを提供するとともに、書き換え可能なプログラムやデータを保持するＲＡＭ２０４、および情報センタ１００と通信を行うための通信インタフェース（Ｉ／Ｆ）２５０（または近距離無線通信Ｉ／Ｆ２５５）を備える。ＲＯＭ２０２には制御プログラム２０３が記憶されており、ＣＰＵ２０１がこの制御プログラム２０３を実行することでメインコントローラとしての役割を果たす。また、ＲＡＭ２０４には故障診断プログラム２０５が保持される。

後述するように、この故障診断プログラム２０５は、制御プログラム２０３の実行中に呼び出されて、車両の故障診断が行われる。この故障診断には、温度センサ２４３、湿度センサ２４４、振動センサ２４５、エンジン回転数センサ２４６からの各出力、並びにユニット監視モジュール２８０から転送されてくる信号が使用される。これらの信号は所定のタイミングで情報センタ１００に転送される。また、診断結果は入出力装置２７０に表示等される。さらに、ＣＰＵ２０１による制御プログラム２０３の実行において、必要に応じて、情報センタ１００より故障診断プログラムが転送されてくるように構成されている。この場合、ＲＡＭ２０４内の故障診断プログラムは、その転送されてきた故障診断プログラムで更新されることになる。

図３は、サービス工場１２０の構成例を示した図である。サービス工場用クライアント１２１は、テスター３０１からの故障診断情報や、故障した車両１１１に搭載されているメインコントローラ２００に蓄積されている故障発生前の車両データを読み出し、発生した故障を表す故障識別コードとともに情報センタ１００に送信するコンピュータである。なお、サービス工場用クライアント１２１は、情報センタ１００と通信するための通信インタフェースも備えている。なお、車両と通信する際には、例えば、近距離無線通信インタフェース３１０を介して車両１１１と接続することができる。テスター３０１は、故障車両に設けられたコネクターに接続することで詳細な故障診断を行う装置である。

図９は、本実施形態に係る車両データの収集に関するフローチャートである。とりわけ、フローチャートでは、正常車両の車両データも含めて収集し、車両情報データベース１０４を更新する。この処理によれば、正常車両の統計的な車両データを収集でき、故障車両の車両データの特徴を発見しやすくなり、正確な故障診断が行えるようになる。なお、同図のフローチャートにおいて、車両側のフローに対応するプログラムは故障診断プログラム２０５に含まれ、ＣＰＵ２０１によって実行される。

まずステップＳ４００において、メインコントローラ２００に搭載されているＣＰＵ２０１は、図８に示された温度センサ２４３、湿度センサ２４４、振動センサ２４５、エンジン回転数センサ２４６、およびユニット監視モジュール２８０からの出力を、それぞれ適切なタイミングでサンプリングし、車両データとしてＲＡＭ２０４に記憶する。なお、図示は省略したが、車両データにはこの他に、走行距離やイグニッション（ＩＧ）がＯＮされた回数（ＩＧ回数）も含まれる。

つぎに、ステップＳ４０２において、メインコントローラ２００に搭載されているＣＰＵ２０１は、所定のタイミングで、ＲＡＭ２０２に記憶されている車両データを読み出し、車両ＩＤおよびタイムスタンプを付加し、モバイル通信インタフェース２５０又は近距離無線通信インタフェース２５５を介して情報センタ１００に送信する。

「所定のタイミング」とは、たとえば、図１０に示されるように、センタ送信イベントが発生したタイミングである。センタ送信イベントとしては、図示のように、イグニッション（ＩＧ）ＯＮ／ＯＦＦ、ユニット監視モジュール２８０よりユニット故障警戒データが発生した、エンジン回転数センサ２４６で検出されたエンジン回転数が設定値以上を示す、温度センサ２４３で検出された温度（ユニット周囲温度）が警戒値を示す、湿度センサ２４４で検出された湿度（ユニット周囲湿度）が警戒値を示す、振動センサ２４５で検出された振動数が警戒値を示す、ユニット監視モジュール２８０よりユニット故障データが発生した、などのイベントが考えられる。また、「所定のタイミング」には、ユニット監視モジュール２８０による、エンジンＥＣＵ２２６の電源電流または出力電圧の定時間モニタリングに対応するタイミングも含まれる。ＣＰＵ２０１は、このようなイベントに応答してそのイベントに対応するデータを、車両ＩＤおよびタイムスタンプとともに情報センタ１００に送信する。

つぎに、ステップＳ４１０において、情報センタ１００の故障診断サーバ１０１は、モバイル通信インタフェースなどを介して車両から送信された車両データを受信する。そして、ステップＳ４１２において、故障診断サーバ１０１は、受信した車両データを、そのデータに含まれている車両ＩＤと関連付けて車両情報データベース１０４（具体的には図５に示される個別車両モニタテーブル）に追記する。

図１１は、故障の診断に使用される故障データの収集に関するフローチャートである。故障データの収集方法は、概ね２通りがある。１つは、故障した車両から故障データを読み出し故障情報データベース１０３へ書き込む方法である（ステップＳ５００、Ｓ５０２）。もう１つは、故障車両１１１が入庫されたサービス工場のクライアント装置１２１によって故障車両１１１から故障データを読み出した後、サービス工場のクライアント装置１２１から故障情報データベース１０３へと書き込む方法である（ステップＳ５１０、Ｓ５１２）。

ステップＳ５００において、故障車両１１１に搭載されたメインコントローラ２００は、故障の発生を認識した顧客により故障データの送信が指定されるか、各種制御装置において異常が検出されると（例えば、警告ランプが点灯したとき）、故障時の走行条件、故障発生時刻、車両番号（車体番号）及び故障識別コードなどをＲＡＭ２０２から読み出し、故障データを作成する。この故障発生時刻と故障識別コードは、顧客が入出力装置２７０を操作して入力してもよいし、警告ランプなどに対応する故障コードを入力してもよい。車両番号などの車両を特定するために役立つ情報は、例えば、ＲＯＭ２０２などに記憶されているものを読み出せばよい。

メインコントローラ２００が故障診断プログラムを搭載している場合には、故障診断プログラムを実行することにより、常時、定期的に又は所定のタイミング（スイッチ操作時など）で、各種センサやユニットからのデータを取得して故障の発生を監視し、故障の発生を検出すると、故障時の走行条件、故障発生時刻と、発生した故障に対応する故障識別コードとを決定し、故障データを作成し、情報センタ１００へとアップロードすることができる。

ステップＳ５０２において、メインコントローラ２００は、ＲＡＭ２０２に記憶されていた車両データと故障データとを情報センタ１００内の故障診断サーバ１０１に送信する。ステップＳ５０４において、故障診断サーバ１０１は、インターネット１３０を経由して車両データと故障データとを受信する。ステップＳ５０６において、故障診断サーバ１０１は、受信した車両データを車両情報データベース１０４に記憶する（図５参照）。ステップＳ５０８において、故障診断サーバ１０１は、受信した故障データを故障情報データベース１０３に記憶する（図４参照）。

以上のようにして、故障診断に使用するための判断要素となる故障データと車両データがデータベースに蓄積されていく。なお、故障データやその車両データは故障モデルといえるものであるが、データマイニング手法においてはこの故障モデルは、時々刻々とデータが追加されることで絶えず変化しており、他のデータとの比較の段階で確定されるものである。その意味では、故障診断サーバ１０１が、受信した故障データを故障情報データベース１０３や車両情報データベース１０４に登録する処理や、これらから所望の車両データを抽出する処理は、故障モデルの作成処理に該当するといえよう。

ところで、故障データや車両データは、サービス工場１２０から収集してもよい。ステップＳ５１０において、テスター３０１が故障車両１１１に接続され、故障診断が実行される。この故障診断においては、テスター３０１及び／又はクライアント装置１２１が、故障車両１１１のメモリに記憶されている車両データを読み出して詳細な調査を実行したり、あるいは特定の検査用信号を各種ユニットに送信し、各種ユニットからの応答データを検査したりするなどして、故障データを作成する。

なお、サービス工場用クライアント１２１は、無線通信インタフェース３１０を介して故障車両１１１と接続し、メモリに格納されている車両データを読み出してもよく、この場合はさらに、サービス工場用のクライアント装置１２１において診断プログラムを実行し、故障個所を詳細に診断して故障データを作成してもよい。ステップＳ５１２において、サービス工場用のクライアント装置１２１は、作成された故障データと、故障車両から読み出し車両データとを情報センタ１００の故障診断サーバ１０１に送信する。その後は、ステップＳ５０４以降の処理を実行する。

このように故障データの収集について２つの方法を例示したが、後者の方法では、車載するには高価すぎるような専門の診断装置を使用できるため、より詳細な診断結果が得られる利点がある。

以下、本実施形態における車両１１０と故障診断サーバ１０１との間で行われる遠隔故障診断について説明する。

半導体部品の故障モードは一般に、製造後、故障の出現する時期により、「初期故障」、「偶発故障」、「摩耗故障」に分類される。初期故障は、出荷前にスクリーニングしきれなかった潜在的な不具合要因が、もともと正常であれば出現しないようなストレスにより加速されて出現するものをいう。偶発故障は、正常品であっても、使用条件や想定外のストレスにより故障に至るものをいう。また、摩耗故障は、ストレスの蓄積により物理的に劣化を生じ、機能不全に至るものいい、設計時の寿命試験によってある程度は予測可能なものである。製品の使用期間により、初期故障期間を過ぎると、半導体部品にとって良好な使用条件下では、故障発生率は最も低くなり、設計寿命に近づくにつれ、再び故障発生率が上昇していくという、いわゆる「バスタブカーブ」をたどる。

車両に搭載される半導体部品は、オフィス向け半導体部品等に比べ、酒家後の環境条件の変動が大きく、また、個々の使用者毎の使用状況もバラツキが大きいため、初期故障、偶発故障ともに他の製品に比べ発生確率は高いと予想できる。

したがって、統計的に大量な情報をリアルタイムに収集できれば、過去の使用状況を考慮して、ある不具合が初期故障なのか偶発故障なのかといって判定も容易になると考えられる。

さらに、電子部品にとって過酷な条件下で自動車を利用し続けている場合は、設計時の寿命が加速され、摩耗故障が早期に出現することも予想される。

この摩耗故障の場合、統計的にみれば、与えたストレスの程度、期間によっては、機能不全には至らないものの正常品とは異なる特性に変化していく、いわゆる「まえぶれ現象」が出現することもある。

よって、統計的に経験値を蓄積しておき、これらを利用して「まえぶれ現象」を早期に発見できれば、機能不全となる致命故障に至る前に、部品交換などの対処が可能になる。

そこで、本実施形態では、この故障診断サーバ１０１による故障診断では、故障判定ラインに至る前の警戒ラインを設定し、この警戒ラインを超えるような場合を「まえぶれ現象」として把握する。そして、後述するように、車両データに基づいて警戒レベルが判定される。また、この警戒レベルの判定結果に応じて、車両１１０のメインコントローラ２００における故障診断プログラム２０５が更新されうる。さらに、この警戒レベルの判定には、図７に示した診断データベース１０８における警戒レベル設定テーブルが利用されるが、その判定精度を高めるべく、この警戒レベル設定テーブルは、故障診断サーバ１０１において収集された車両データの統計処理に基づいて更新されうる。

前述したように、この車両情報データベース１０４には、各車両においてセンタ送信イベントが発生する都度、その車両データが蓄積されていく。その中から、特定車両について、車両データのうちの注目データ（たとえばエンジンＥＣＵ２２６の電源電流）を抽出すれば、その注目データについての経時的な変化を追うことができる。これを同一車種について平均をとれば、車種別の注目データについての統計的な経時変化をとらえることができる。図１３は、そのような注目データについての統計的な経時変化のようすの一例を示す図である。同図に示すように、このようなモニタ値は上下の変動を繰り返しながら故障判定ラインへと向かっていくのが通常である。

そして本実施形態では、同図に示すように、上側故障判定ラインと下側故障判定ラインとの間に、正常範囲と警戒範囲とを分ける上側警戒ラインおよび下側警戒ラインを設定する。具体的には、図７に示した診断データベース１０８における警戒ライン設定テーブルにそれらの値が設定される。注目データの値が、この上側警戒ラインと下側警戒ラインとの間の正常範囲内を外れると、警戒範囲にあると判定される。

図１２は、本実施形態における車両１１０と故障診断サーバ１０１との間で行われる遠隔故障診断処理を示すフローチャートである。この図１２は図９の処理を含んだフローチャートとなっている。図１２のフローチャートにおいて、車両側のフローに対応するプログラムは制御プログラム２０３および故障診断プログラム２０５に含まれ、ＣＰＵ２０１によって実行される。

まず、車両１１０における制御プログラム２０３の実行において、例えばユーザによる操作指示に応じて、あるいは予め定められたタイミングで、故障診断プログラム２０５が起動され、これにより図９に示したステップＳ４００およびＳ４０２の処理が実行される。すなわち、ステップＳ４００では、メインコントローラ２００に搭載されているＣＰＵ２０１は、図８に示された温度センサ２４３、湿度センサ２４４、振動センサ２４５、エンジン回転数センサ２４６、ユニット監視モジュール２８０等からの出力を、それぞれ適切なタイミングでサンプリングし、車両データとしてＲＡＭ２０４に記憶する。

つぎに、ステップＳ４０２において、ＣＰＵ２０１は、所定のタイミングで、ＲＡＭ２０２に記憶されている車両データを情報センタ１００に送信する。具体的には、ステップＳ４０２１で、図１０に例示したようなセンタ送信イベントが発生したかどうかを判定し、センタ送信イベントが発生したときは、当該イベントに対応する車両データにタイムスタンプおよび車両ＩＤを付加し（ステップＳ４０２２）、このタイムスタンプおよび車両ＩＤが付加された車両データを、情報センタ１００に送信する（ステップＳ４０２３）。

ステップＳ４１０で、情報センタ１００における故障診断サーバ１０１は、車両データを受信すると（ステップＳ４１０）、その車両データを車両情報データベース１０４（具体的には図５に示される個別車両モニタテーブル）に追記する（ステップＳ４１２）。

ここまでの処理内容は、図９を参照して前述したとおりである。さて、このステップＳ４１２で車両情報データベース１０４が更新されると、故障診断サーバ１０１はデータベース情報を用いた統計的な故障判定処理を行う（ステップＳ６００）。

図１４は、ステップＳ６００の故障診断サーバ１０１における故障判定処理の詳細を示すフローチャートである。

まず、車両情報データベース１０４から、車両１１０を特定する車両ＩＤの車両データのうちの、監視対象の注目データを抽出する（ステップＳ６０１）。図７に示したような、診断データベース１０８における警戒ライン設定テーブルを参照して、抽出した注目データが、下側警戒値と上側警戒値の間にあるかどうか、すなわち、正常範囲内にあるかどうか（図１３参照）、を判定する（ステップＳ６０２）。ここで当該注目データが正常範囲内にあると判定されたときは、診断対象のエンジンＥＣＵ２２６は正常であると判断される（ステップＳ６０３）。

一方、当該注目データが正常範囲内にない場合には、当該注目データが下側警戒値と下側故障判定値との間、あるいは、上側警戒値と上側故障判定値との間にあるかどうか、すなわち、警戒範囲内にあるかどうか（図１３参照）、を判定する（ステップＳ６０４）。ここで当該注目データが警戒範囲内にないと判定されたときは、診断対象のエンジンＥＣＵ２２６は故障したと判断される（ステップＳ６０５）。一方、当該注目データが警戒範囲内にあると判定されたときは、診断データベース１０８における警戒レベル設定テーブルを参照して、注目データに対応する車両データ（環境データ）に基づき警戒レベルを判定する（ステップＳ６０６）。図７に示される例では、警戒レベル設定テーブルには、警戒レベルＡ，Ｂ，Ｃのそれぞれについて、走行距離、ＩＧ回数、エンジン回転数警戒数、温度警戒数、湿度警戒数、および振動警戒数の各環境データの判定値が記述されている。ここでは、全ての環境データについて判定値未満となる警戒レベルに判定される。たとえば、環境データ「走行距離」について例示すると、車両１１０の走行距離が50,000km未満であれば警告レベルはＡ、50,000km以上100,000km未満のときは警告レベルはＢ、100,000km以上150,000km未満のときは警告レベルＣ、と判定される。

そして、各環境データがメーカ出荷時の初期設定の範囲内であった場合には（ステップＳ６０７，ＹＥＳ）、判定された警戒レベルを設定し（ステップＳ６０８）、そうでなければ、車種別判定値更新処理（ステップＳ６０９）を実行する。

図１５に、ステップＳ６０９における車種別判定値更新処理の詳細フローを示す。
まず、車種グループの環境データと注目データの統計処理を行い、図１３に例示したような時系列変化を抽出する（ステップＳ６１０）。

つぎに、当該車両の環境履歴に応じ、走行距離やＩＧ回数など今後の環境変動に対応した将来の変動予測を行った結果である前回設定値（予測値）との比較を行う（ステップＳ６１１）。

その後、警戒レベル判定精度の向上を目的として、信頼度予測式へのフィードバックを行う（ステップＳ６１２）。
信頼度予測式は、例えば次のように定義される。
注目データの長時間変動＝a＊Ｆ1(走行距離)＋b＊F2（ＩＧ回数）＋c＊F3（エンジン回転数）＋d＊F4(温度)+e＊F5(湿度)+f＊F6(振動)
ただし、a〜fは係数、F1〜F6は各環境変数の注目データ変動への影響を示す関数である。各車両からの注目データ量と環境データ量を統計分析して、各環境変数の影響度合いを示す、係数(ここでは、a〜f)を設計時に設定したものから、現実に応じたフィードバックを行う。

そして、警戒レベル設定テーブルの更新を行う（ステップＳ６１３）。
警戒レベルは、将来の故障可能性の大きさに応じて、「車種別信頼度予測テーブル」にて設定される。ステップＳ６１３でフィードバックされた、環境変数の影響度合いに応じて、「警戒レベル設定テーブル」の各環境変数の警戒レベルごとの警戒値を更新する。

説明を、図１２のフローチャートに戻す。
故障診断サーバ１０１は、上述のステップＳ６００の故障判定処理が終了すると、その故障判定結果（正常／故障／警戒（および警戒レベル））を車両１１０に送信する（ステップＳ６５０）。

車両１０１のメインコントローラ２００に搭載されているＣＰＵ２０１は、故障診断サーバ１０１より故障判定結果を受信すると、入出力装置２７０を構成するディスプレイにその結果を表示する（ステップＳ６６０）。ここで、故障判定結果が「故障」や「警戒」である場合には、併せて、当該車両の入庫案内や、当該車載部品の手配を行うための画面を提供するとよい。

故障診断サーバ１０１は、ステップＳ６００の故障判定処理が終了すると、上記の故障判定結果の送信処理（ステップＳ６５０）に加え、以下の処理も行う。すなわち、ステップＳ６００において設定された警戒レベルを判定し（ステップＳ７０１）、警戒レベルが更新された場合には（ステップＳ７０２，Ｙｅｓ）、図６に示した診断プログラムデータベース１０７における診断プログラム設定テーブルを参照して、更新された警戒レベルに対応する故障診断プログラムを特定し（ステップＳ７０３）、その特定した故障診断プログラムを車両１１０に送信する（ステップＳ７０４）。このとき、車両情報データベース１０４に格納されている車両属性テーブル（図５参照）における、診断対象の車両の「診断プログラムコード」および「診断プログラム設定時刻」も更新する。

診断プログラム設定テーブルに定義される各診断プログラムは、対応する警戒レベルに応じて、たとえば、ステップＳ４０２の車両データの送信タイミングが相異なるものである。たとえば、警戒レベルが高いほど頻繁に車両データの送信が行われるような送信タイミングとされる。

車両１０１のメインコントローラ２００に搭載されているＣＰＵ２０１は、故障診断サーバ１０１より故障診断プログラムを受信すると（ステップＳ７０５）、ＲＡＭ２０２に格納されている故障診断プログラム２０５を、その受信した新たな故障診断プログラムで更新する（ステップＳ７０６）。

以上のように、本実施形態の遠隔故障診断においては、故障診断サーバ１０１に集められた実走行中の車両データを用いた統計的な故障判定によって高精度な故障判定結果が得られると同時に、車両にインストールされている故障診断プログラム２０５は、診断対象ユニットの警戒レベルに応じた最適なものに更新される。これにより、実走行中の故障を誘発するストレス要因に基づいた故障診断が実現され、車載部品の不具合原因の予測や不具合原因の特定を正確に行うことができるようになる。

図１は、実施形態に係る遠隔故障診断システムの構成例を示した図である。 図２は、実施形態に係る車両の構成例を示したブロック図である。 図３は、実施形態に係るサービス工場の構成例を示した図である。 図４は、実施形態における故障情報ＤＢに格納されるデータの一例を示す図である。 図５は、実施形態における車両情報ＤＢに格納されるデータの一例を示す図である。 図６は、実施形態における診断プログラムＤＢに格納されるデータの一例を示す図である。 図７は、実施形態における診断ＤＢに格納されるデータの一例を示す図である。 図８は、実施形態における故障診断に係るメインコントローラのハードウェア構成を示すブロック図である。 図９は、実施形態に係る車両データの収集に関するフローチャートである。 図１０は、実施形態における車両と情報センタとの間で行われるデータ送受信の例を説明する図である。 図１１は、実施形態における故障診断に使用される故障データの収集に関するフローチャートである。 図１２は、実施形態における遠隔故障診断処理を示すフローチャートである。 図１３は、監視対象のデータの経年変化を示すグラフの例および警戒ラインの例を示す図である。 図１４は、実施形態における故障診断サーバによる故障判定処理の詳細を示すフローチャートである。 図１５は、実施形態における車種別判定値更新処理の詳細を示すフローチャートである。

１００…情報センタ
１０１…故障診断サーバ
１１０…故障診断対象車両
１１１…故障車両
１２０…サービス工場
１２１…サービス工場用クライアント

Claims (4)

1. 所定の車載部品のストレス要因に関する車両データを所定のタイミングで送信するように構成された車両と、ネットワークを介してこの車両と接続され、前記車両から受信される前記車両データを蓄積するとともに、蓄積した前記車両データに基づき前記車両の車載部品の故障診断を行う故障診断サーバと、を含む遠隔故障診断システムであって、
   前記車両は、
   第１の故障診断プログラムを書き換え可能に保持するメモリと、
   前記第１の故障診断プログラムを実行することにより、前記車両データの送信を制御するＣＰＵと、を有し、
   前記故障診断サーバは、
   前記車載部品の故障に対する警戒レベルに応じた複数の故障診断プログラムを記憶する記憶手段と、
   前記車両より受信した前記車両データに基づいて、前記警戒レベルを判定する判定手段と、
   前記記憶手段に記憶されている前記複数の故障診断プログラムから、前記判定手段により判定された警戒レベルに対応する第２の故障診断プログラムを選択してこれを前記車両に送信する送信手段と、を有し、
   前記車両は、前記送信手段により送信された前記第２の故障診断プログラムを受信し、前記メモリに保持されている前記第１の故障診断プログラムを、受信した前記第２の故障診断プログラムで更新する更新手段を更に有し、
   前記複数の故障診断プログラムはそれぞれ、対応する警戒レベルに応じた頻度で前記車両データの送信が行われるようにプログラムされていることを特徴とする遠隔故障診断システム。
2. 所定の車載部品のストレス要因に関する車両データを所定のタイミングで送信するように構成された車両と、ネットワークを介してこの車両と接続され、前記車両から受信される前記車両データを蓄積するとともに、蓄積した前記車両データに基づき前記車両の車載部品の故障診断を行う故障診断サーバと、を含む遠隔故障診断システムであって、
   前記車両は、
   第１の故障診断プログラムを書き換え可能に保持するメモリと、
   前記第１の故障診断プログラムを実行することにより、前記車両データの送信を制御するＣＰＵと、を有し、
   前記車両データは、車種情報を含み、
   前記故障診断サーバは、蓄積した前記車両データに基づいて、車種別の統計処理を行い、
   前記故障診断サーバは、
   前記車載部品の故障に対する警戒レベルに応じた複数の故障診断プログラムを記憶する記憶手段と、
   前記車両より受信した前記車両データに基づいて、前記警戒レベルを判定する判定手段と、
   前記記憶手段に記憶されている前記複数の故障診断プログラムから、前記判定手段により判定された警戒レベルに対応する第２の故障診断プログラムを選択してこれを前記車両に送信する送信手段と、
   前記統計処理の結果に基づいて、前記判定手段における前記警戒レベルの判定基準を変更する手段とを有し、
   前記車両は、前記送信手段により送信された前記第２の故障診断プログラムを受信し、前記メモリに保持されている前記第１の故障診断プログラムを、受信した前記第２の故障診断プログラムで更新する更新手段を更に有することを特徴とする遠隔故障診断システム。
3. 前記ストレス要因に関する車両データは、前記車載部品の雰囲気温度、雰囲気湿度、振動数を含むことを特徴とする請求項１又は２に記載の遠隔故障診断システム。
4. 前記車両は、前記判定手段による判定結果に応じて、当該車両の入庫案内および／または当該車載部品の手配を行うための手段を更に有することを特徴とする請求項１から３までのいずれかに記載の遠隔故障診断システム。

Images