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

Description

【０００１】
【発明の属する技術分野】
本発明は、遠隔から車両に接続して故障を診断する遠隔故障診断システムに関する。
【０００２】
【従来の技術】
従来、車両の故障診断を行なう種々の技術が知られている（特許文献１）。この特許文献１には、ディーラーのサービス工場等に配置されたセレクトモニタ（故障診断装置）を用いて車両の故障診断を行なうようにした故障診断装置が開示されている。即ち、この公報に記載の発明は、まず、車載のセンサ・スイッチ類やアクチュエータ類のデータ等の車両データを記憶する電子制御装置が車両に搭載され、一方、ディーラーのサービス工場等には、セレクトモニタ（故障診断装置）が配置されている。このセレクトモニタは、この車載の電子制御装置からこれらの各種の車両データである内部データを読み出すと共に、自らも計測機能を有し、この自己計測した車両のデータと車載の電子制御装置から読み出した内部データとを同時に表示させることで、対応するデータの比較検討が容易に行なえるようになっている。このようにして、この公報記載の故障診断装置は、車載の電子制御装置から読み出したデータの妥当性を容易に判断可能とし、診断効率を向上させるようにしている。
特許文献２には、車両の自己診断情報をイグニッション・キーに保存させ、このイグニッション・キーから読み出した診断情報から故障箇所、故障状態等を詳細に解析するようにした故障検出装置が開示されている。具体的には、この公報に記載の発明では、イグニッション・キーをシリンダ錠から取り出すとき、車両の送信機が自己診断情報を出力し、イグニッション・キーの受信機がこの情報を受信し、車両の自己診断情報がイグニッション・キーのメモリに記憶される。この自己診断情報を保存したイグニッション・キーから、キー情報リーダを使ってその診断情報が読み出され、パソコンに入力され、このパソコンにより故障箇所・故障状態等を詳細に検出するようになっている。この公報記載の発明によれば、イグニッション・キーは車両から取り外して携帯する唯一の部品であるから、このキーを預かったディーラーが、キーから自己診断情報を読み出して故障個所、故障状態等を検出することができる。よって、故障修理や交換部品などに必要な費用、車両の納期などについて直ちに明示することができるといった効果がある。
特許文献３には、車両の自己診断による異常に基づく故障診断情報が車両から基地局側に無線にて送信され、その後、その故障診断情報に対応した車両の異常が解消（修復）されたときには、その異常解消情報（修理済コード）が、車両から基地局へ無線にて送信されるようにした車両診断システムが開示されている。この公報記載の発明によれば、基地局にて車両の故障診断情報が受信され、その後に対応する修理済コードが受信されたときには、基地局からユーザに対する車両の点検・修理・整備に関する要請を省略することができ、車両と基地局との相互間の無駄な処理を無くすことができるようになっている。
【０００３】
しかしながら、上述した従来技術は、いずれも、車両自身が故障診断機能を備え、この自己故障診断機能により得られた故障診断情報を、何らかの手段、例えば、故障診断装置（セレクトモニタ）、イグニッション・キー、基地局への無線による送信を介して、ディーラーを含む外部に連絡するようにしたものにすぎない。
【０００４】
それに対して、特許文献４では、ネットワークを介して故障した車両と接続し、その故障個所を診断する故障診断システムが提案されている。この従来技術によれば、故障診断システムと車両とを遠隔的に接続することで、顧客がサービス工場に出向かなくとも、車両が故障しているかどうかや故障個所を把握できるため、大変便利である。
【０００５】
【特許文献１】
特開平１０−１００１３号公報
【特許文献２】
特開平１１−５１８１７号公報
【特許文献３】
特開平１１−２２３５７８号公報
【特許文献４】
特開２００２−２２８５５２号公報。
【０００６】
【発明が解決しようとする課題】
ところで、故障診断を行なうには故障診断の対象となる車両において、時々刻々と変化するセンサ出力や制御データなどの車両データをサンプリングして、故障診断システムに送信する必要がある。
【０００７】
さらに、故障の種類によっては、ある特定の走行条件でしか再現されないものもあろう。例えば、走行中に異常を感じ、ディーラーや整備工場に車両を入庫させたが、そのときは故障が再現されないといったことはよく聞く話である。
【０００８】
そこで、本発明では、車両の故障診断に必要なデータに関するユーザ側の負担と通信トラヒックとを低減することを目的とする。
【０００９】
【課題を解決するための手段】
上記の目的を達成するため、本発明に係る遠隔故障診断システムは、以下の構成を特徴とする。
【００１５】
本願発明は、診断対象車両に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断システムにおいて、故障診断に必要となる故障車両の車両データを、該故障車両に故障が発生したときの走行条件とともに記憶するデータベースと、前記データベースの更新要求が発行されると、更新に必要となる特定の走行条件下における車両データを、複数の故障車両に要求する要求手段と、前記故障車両から受信された車両データに基づいて前記データベースの内容を更新する更新手段とを含むことを特徴とする。
【００１６】
尚、上述の目的は、上記の各構成を備える遠隔故障診断システムに対応する遠隔故障診断方法によっても達成される。
【００１７】
また、同目的は、上記遠隔故障診断システムに含まれる各手段を、コンピュータによって実現するためのプログラム、及びそのプログラムコードが格納されているコンピュータ読み取り可能な記憶媒体によっても達成される。
【００１８】
【発明の効果】
本発明によれば、車両の故障診断に必要なデータに関するユーザ側の負担と通信トラヒックとを、従来技術よりも低減できる遠隔故障診断システム、遠隔故障診断方法及び診断対象車両が実現される。
【００３１】
請求項１、２及び３に記載の発明によれば、故障診断用のデータベースを更新する際に、更新に必要となる車両データだけを車両に対して要求することも可能になるため、データベース更新処理に関連する負荷を低減できる。
【００３２】
【発明の実施の形態】
以下、本発明に係る遠隔故障診断システムについての一実施形態を、図面を参照して詳細に説明する。なお、以下では、一見すると特許請求の範囲には記載されていないと思われる実施形態が存在するかもしれないが、これらは意識的に除外したものではない。例えば特許請求の範囲に記載の発明と均等であるため、あえて特許請求の範囲には記載していないこともある。
【００３３】
［第１の実施形態］
図１は、本実施形態に係るシステムの構成例を示した図である。情報センター１００は、顧客の車両１１０、１１１やサービス工場１２０などから送信される各種の情報を蓄積するとともに、故障診断結果を提供するコンピュータ群である。情報センター１００は、顧客の車両１１０、サービス工場１２０とインターネット１３０やモバイル通信回線などを経由して接続している。
【００３４】
顧客の車両１１０及び１１１は、故障の診断に必要なデータを取得して情報センター１００に送信する。
【００３５】
サービス工場１２０は、いわゆる修理工場などであり、故障車両１１１から車両データを読み出したり、故障個所や故障の原因に関する情報を情報センター１００に送信したりする。サービス工場にはサービス工場用のクライアント装置が設定されている。このクライアント装置は、一種のコンピュータであり、ＣＰＵ、メモリ、ハードディス・クドライブ及び通信インタフェースなどを備えている。以下の説明では、フローチャートに対応するプログラムをＣＰＵが実行することにより、各種の処理が実行されることになる。
【００３６】
情報センター１００には、故障の診断処理を実行する故障診断サーバ１０１と、顧客（全ての顧客又は故障診断サービスの契約者）の情報を格納した顧客情報データベース１０２と、故障車両１１１やサービス工場のクライアント装置１２１から送信された故障データを格納する故障情報データベース１０３と、顧客の車両１１０、１１１から送信されてきた車両データを蓄積する車両情報データベース１０４と、サービス工場の位置などに関する情報を格納するサービス工場データベース１０５と、地図データを格納した地図データベース１０６と、故障を診断するための各種プログラムを格納した診断プログラムデータベース１０７とを含んでいる。
【００３７】
故障診断サーバ１０１は、一種のコンピュータであり、ＣＰＵ、メモリ、ハードディス・クドライブ及び通信インタフェースなどを備えている。以下の説明では、フローチャートに対応するプログラムをＣＰＵが実行することにより、各種の処理が実行されることになる。
【００３８】
この故障診断サーバ１０１により、例えば、所定の故障について故障診断を実行する際に必要となる走行条件を決定する決定手段（例：故障診断サーバ１０１のＣＰＵ）と、前記決定された走行条件を前記診断対象車両１１０に対して送信する送信手段（例：故障診断サーバ１０１の通信インタフェース）と、前記走行条件に則して取得された車両データを前記診断対象車両から受信する受信手段（例：故障診断サーバ１０１の通信インタフェース）と、前記受信された車両データに基づいて前記所定の故障について故障診断を実行する故障診断手段（例：故障診断サーバ１０１のＣＰＵ）と、前記故障診断手段による故障診断結果を前記診断対象車両の顧客に対して通知する通知手段（例：故障診断サーバ１０１の通信インタフェース）とを有する故障診断システムが実現される。
【００３９】
図２は、本実施形態に係る車両の構成例を示したブロック図である。遠隔車両用クライアント装置２００は、ＣＰＵ、メモリなどからなるメインコントローラであり、各種制御ユニットやセンサから制御データやセンサ出力を取得し、メモリに蓄積したり、蓄積した情報をモバイル端末（モバイル通信インタフェース）２５０や近距離無線通信インタフェース２５５を介して情報センター１００に送信したり、情報センター１００から故障予測結果を受信したりする。近距離無線通信インタフェース２２５は、無線ＬＡＮ、ブルートゥース及びＥＴＣ用の無線規格などを採用できる。
【００４０】
ボディー系システム２１０は、パワーウインドウユニット２１１、ヘッドライトユニット２１２、オーディオユニット２１３、エアコンユニット２１４、ワイパーユニット２１５及びドアロックユニット２１６などを含み、制御結果や電流・電圧などのデータを車両用クライアント装置２００へと出力する。
【００４１】
制御系システム２２０には、ブレーキがロックしないように制御するＡＢＳ（アンチロック・ブレーキ・システム）２２１、車両の挙動を制御するＤＳＣ（ダイナミック・スタビリティ・コントローラ）２２２、燃料の供給を制御するＥＧＩ（エレクトリック・ガス・インジェクション）２２３、自動変速機を制御するＥＡＴ（エレクトリック・オートマティック・トランスミッション）２２４及び自動走行などドライバの運転を補助するＩＣＣＷ（インテリジェント・クルーズ・コントロール＆ワーニング）２２５などを含み、車両用クライアント装置２２０に対して制御結果などを通知する。
【００４２】
また車両には各種のセンサ群が搭載されている。例えば、ＧＰＳ（グローバル・ポジショニング・システム）衛星からの電波を受信して車両の現在位置を算出するＧＰＳセンサ２３１、渋滞情報などを受信するＶＩＣＳ情報受信機２３２、車両の速度を検出する車速センサ２３３、前方の車両など他の車両との距離を計測する車間距離センサ２３４、車両のヨーレートを検出するヨーレートセンサ２３５、車両の加速度を検出する加速度センサ、車両の操舵角を検出する操舵角センサ２３７、スロットルの開度を検出するスロットル開度センサ２３８、ブレーキの踏み込み圧力を検出するブレーキ圧センサ２３９、ウインカスイッチの動作状態を検出するウインカＳＷセンサ２４０、外気温を測定するための外気温センサ２４１及び雨が降っているか否かや雨量を測定するレインセンサ２４２などが車両には搭載されている。
【００４３】
ナビゲーション・コントローラ２６０は、ＧＰＳセンサ２３１からの測位データに基づいて、ハードディス・クドライブなどに記憶されている地図情報を検索し、現在位置の地図を表示する装置である。顧客たるドライバへの入出力装置２７０は、液晶ディスプレイなどの表示装置と音声主力装置などを含んでおり、ナビゲーション・コントローラ２６０からの地図データを出力したり、情報センター１００からの故障診断結果を出力したりする。
【００４４】
この図２に示された車両により、遠隔故障診断システム（例：故障診断サーバ１０１）から前記走行条件を受信する手段（例：モバイル通信インタフェース２５０や近距離無線通信インタフェース２５５など）と、前記受信された走行条件に則して車両データを取得する手段（例：車両用クライアント装置２００、ＧＰＳセンサ２３１など）と、前記取得された車両データを前記遠隔故障診断システムに送信する手段（例：モバイル通信インタフェース２５０や近距離無線通信インタフェース２５５など）と、前記遠隔故障診断システムから故障診断結果を受信する手段（例：モバイル通信インタフェース２５０や近距離無線通信インタフェース２５５など）と、前記受信された故障診断結果を出力する手段（例：入出力装置２７０など）とを含む診断対象車両が実現される。
【００４５】
図３は、サービス工場１２０の構成例を示した図である。サービス工場用クライアント１２１は、テスター３０１からの故障診断情報や、故障した車両１１１に搭載されている車両用クライアント装置２００に蓄積されている故障発生前の車両データを読み出し、発生した故障を表す故障識別コードとともに情報センター１００に送信するコンピュータである。なお、サービス工場用クライアント１２１は、情報センター１００と通信するための通信インタフェースも備えている。なお、車両と通信する際には、例えば、近距離無線通信インタフェース３１０を介して車両１１１と接続することができる。テスター３０１は、故障車両に設けられたコネクターに接続することで詳細な故障診断を行なう装置である。
【００４６】
図４は、本実施形態に係る車両データの収集に関するフローチャートである。とりわけ、フローチャートでは、正常車両の車両データも含めて収集し、車両情報データベースを作成する。すなわち、正常車両の車両データがあれば、故障車両の車両データの特徴を発見しやすくなり、故障診断時に使用する故障モデルの作成や、特定の故障についての走行条件の決定にも役立つからである。
【００４７】
ステップＳ４００において、車両用クライアント装置２００に搭載されているＣＰＵは、各種センサやユニットからの出力を、それぞれ適切なタイミングでサンプリングし、メモリに記憶する。
【００４８】
ステップＳ４０２において、車両用クライアント装置２００に搭載されているＣＰＵは所定のタイミング（例えば、定期的、エンジン始動時、エンジン始動が所定時間経過後、及びドライバによる明示的な指示が入力されたときなど）になったと判断すると、メモリに記憶されている車両データを読み出し、車両又はドライバを特定する情報を付加し、モバイル通信インタフェース２５０又は近距離無線通信インタフェース２５５を介して情報センター１００に送信する。
【００４９】
ステップＳ４１０において、情報センター１００の故障診断サーバ１０１は、モバイル通信インタフェースなどを介して車両から送信された車両データを受信する。ステップＳ４１２において、故障診断サーバ１０１は、受信した車両データを、対応する車両又はドライバを特定する情報と関連付けて車両情報データベース１０４に記憶する。
【００５０】
以上の手順により、故障をしていない正常車両についての車両データが車両データベース１０４に格納される。
【００５１】
図５は、故障の診断に使用される故障データの収集に関するフローチャートである。故障データの収集方法は、概ね２通りがある。１つは、故障した車両から故障データを読み出し故障情報データベース１０３へ書き込む方法である（ステップＳ５００、Ｓ５０２）。もう１つは、故障車両１１１が入庫されたサービス工場のクライアント装置１２１によって故障車両１１１から故障データを読み出した後、サービス工場のクライアント装置１２１から故障情報データベース１０３へと書き込む方法である（Ｓ５１０、Ｓ５１２）。
【００５２】
ステップＳ５００において、故障車両１１１に搭載された車両用クライアント装置２００は、故障の発生を認識した顧客により故障データの送信が指定されるか、各種制御装置において異常が検出されると（例えば、警告ランプが点灯したとき）、故障時の走行条件、故障発生時刻、車両番号（車体番号）及び故障識別コードなどをメモリから読み出し、故障データを作成する。この故障発生時刻と故障識別コードは、顧客が入出力装置２７０を操作して入力してもよいし、警告ランプなどに対応する故障コードを入力してもよい。車両番号などの車両を特定するために役立つ情報は、例えば、ＲＯＭなどに記憶されているものを読み出せばよい。
【００５３】
車両用クライアント装置２００が故障診断プログラムを搭載している場合には、故障診断プログラムを実行することにより、常時、定期的に又は所定のタイミング（スイッチ操作時など）で、各種センサやユニットからのデータを取得して故障の発生を監視し、故障の発生を検出すると、故障時の走行条件、故障発生時刻と、発生した故障に対応する故障識別コードとを決定し、故障データを作成し、情報センター１００へとアップロードすることができる。
【００５４】
ステップＳ５０２において、車両用クライアント装置２００は、メモリに記憶されていた車両データと故障データとを情報センター１００内の故障診断サーバ１０１に送信する。ステップＳ５０４において、故障診断サーバ１０１は、インターネット１３０を経由して車両データと故障データとを受信する。ステップＳ５０６において、故障診断サーバ１０１は、受信した車両データを車両情報データベース１０４に記憶する。ステップＳ５０８において、故障診断サーバ１０１は、受信した故障データを車両情報データベースに記憶する。
【００５５】
以上のようにして、故障診断に使用するための判断要素となる故障データと車両データとが各データベースに記憶される。なお、故障データやその車両データは故障モデルといえるものであるが、データマイニング手法においてはこの故障モデルは、時々刻々とデータが追加されることで絶えず変化しており、他のデータとの比較の段階で確定されるものである。その意味では、故障診断サーバ１０１が、受信した故障データを故障情報データベース１０３や車両情報データベース１０４に登録する処理や、これらから所望の車両データを抽出する処理は、故障モデルの作成処理に該当するといえよう。
【００５６】
ところで、故障データや車両データは、サービス工場１２０から収集してもよい。ステップＳ５１０において、テスター３０１が故障車両１１１に接続され、故障診断が実行される。この故障診断においては、テスター３０１及び／又はクライアント装置１２１が、故障車両１１１のメモリに記憶されている車両データを読み出して詳細な調査を実行したり、あるいは特定の検査用信号を各種ユニットに送信し、各種ユニットからの応答データを検査したりするなどして、故障データを作成する。
【００５７】
なお、サービス工場用クライアント１２１は、無線通信インタフェース３１０を介して故障車両１１１と接続し、メモリに格納されている車両データを読み出してもよく、この場合はさらに、サービス工場用のクライアント装置１２１において診断プログラムを実行し、故障個所を詳細に診断して故障データを作成してもよい。ステップＳ５１２において、サービス工場用のクライアント装置１２１は、作成された故障データと、故障車両から読み出し車両データとを情報センター１００の故障診断サーバ１０１に送信する。その後は、ステップＳ５０４以降の処理を実行する。
【００５８】
このように故障データの収集について２つの方法を例示したが、後者の方法では、車載するには高価すぎるような専門の診断装置を使用できるため、より詳細な診断結果が得られる利点があろう。
【００５９】
図６は、本実施形態に係る遠隔故障診断処理についてのフローチャートである。
【００６０】
ステップＳ６００において、車両用クライアント装置２００は、入出力装置２７０から故障診断要求が入力されたことを検知すると、情報センター１００の故障診断サーバ１０１に対して、故障診断要求を送信する。なお、故障診断のトリガーは、ドライバによりトリガーされる場合だけでなく、車両用クライアント装置２００が定期的又はある特定の条件を満たした時にトリガーしてもよいし、故障診断サーバ１０１が定期的又はある特定の条件を満たした時にトリガーしてもよいし、あるいは車両に搭載されている故障検出装置により故障が検出され（警告ランプが点灯した）ときにトリガーしてもよい。なお、車両用クライアント装置２００は、診断の対象となる故障の種類が、入出力装置２７０から指定されたときには、故障診断要求のなかに、指定された故障の種類（故障コードなど）を搭載する。
【００６１】
ステップＳ６０２において、故障診断サーバ１０１は、通信インタフェースを介して故障診断要求を受信する。
【００６２】
ステップＳ６０４において、故障診断サーバ１０１は、診断の対象となる故障の種類を決定する。例えば、故障診断要求に含まれている故障の種類に関する情報に基づいて決定してもよい。故障の種類は１つであってもよいし、複数であってもよい。故障診断要求において故障の種類が含まれていないときは、診断可能な全ての故障（例えば、ｉ＝０番目の故障コードからｉ＝ｎ番目の故障コード）を対象として決定してもよいし、または緊急度の高い故障に絞り込んでもよい。
【００６３】
ステップＳ６０６において、故障診断サーバ１０１は、診断対象として決定された故障に対応する走行条件を決定する。なお、２以上の走行条件が決定されてもよい。
【００６４】
図７は、故障情報データベースと車両情報データベースの内容と故障診断の概念を示した図である。例えば、故障コードＥ０００１として表される故障が診断対象として決定された場合には、故障診断サーバ１０１は、故障情報データベース１０３を参照し、故障コードＥ０００１に対応する走行条件を抽出する。この例では、１３０Ｒのカーブを時速５０ｋｍ／ｈで走行していることが走行条件となる。
【００６５】
ステップＳ６０８において、車両診断サーバ１０１は、決定された走行条件に関する情報を診断対象車両１１０に送信する。なお、車両診断サーバ１０１は、走行条件に識別番号（走行条件ＩＤ）を付しておき、診断対象車両の車両番号と、送信した走行条件ＩＤとを対応付けてデータベースに登録しておいてもよい。診断対象車両が走行条件に合致するまでには長期間を要する場合も想定されるので、どの車両が診断対象車両であり、かつ、どのような走行条件について診断しているかを故障診断サーバ１０１側で管理する必要があるからである。
【００６６】
ステップＳ６１０において、車両用クライアント装置２００は、モバイル通信インタフェース２５０などを介して、走行条件に関する情報を受信し、ＲＡＭなどの記憶装置に記憶する。
【００６７】
ステップＳ６１２において、車両用クライアント装置２００は、走行条件に関連するセンサや制御装置からの出力データが、ＲＡＭに記憶されている走行条件を満たすか否かを判定し、満たすようになるまで待機する。例えば、１３０Ｒのカーブを時速５０ｋｍ／ｈで走行していることが走行条件の場合は、ＧＰＳセンサ２３１からの情報に基づいてナビゲーション・コントローラ２６０により概ね１３０Ｒであるようなカーブを走行しているかどうかを判定し、車速センサ２３３の出力が概ね時速５０ｋｍ／ｈであるかどうかを判定する。これらの条件が満たされると待機ループを抜けて、次のステップへと進む。
【００６８】
ステップＳ６１４において、車両用クライアント装置２００は、各種センサや制御装置からの出力をサンプリングして車両データを作成し、ＲＡＭやハードディスクなどの記憶装置に格納する。
【００６９】
ステップＳ６１６において、車両用クライアント装置２００は、記憶装置から車両データを読み出して、故障診断サーバ１０１に送信する。
【００７０】
ステップＳ６１８において、故障診断サーバ１０１は、通信インタフェースを介して車両データを受信し、車両情報データベースに格納する。図７の例では、車両を特定するための番号と、車両データの一例であるヨーレート、車両データが取得されたときの走行条件などが、車両情報データベース１０４に格納される。
【００７１】
ステップＳ６２０において、車両診断サーバ１０１は、故障車両の車両データと診断対象車両の車両データとに基づいて、診断対象車両１１０に故障が発生しているかどうかを判定する。
【００７２】
ステップＳ６２２において、車両診断サーバ１０１は、故障診断結果に関する情報を、診断対象車両１１０に送信する。
【００７３】
ステップＳ６２４において、車両用クライアント装置２００は、故障診断結果に関する情報を受信する。
【００７４】
ステップＳ６２６において、車両用クライアント装置２００は、受信された故障診断結果を入出力装置２７０から出力する。
【００７５】
以上のようなフローで遠隔故障診断が実行される。なお、診断結果を受信したことにより、遠隔診断処理は終了されることになるが、その際に、車両用クライアント装置２００は、記憶装置に記憶しておいた走行条件を削除する。削除しなければ、常にこの走行条件が有効となり、走行条件を満たしたときに車両データが取得され送信されてしまうからである。
【００７６】
なお、車両用クライアント装置２００は、故障診断サーバ１０１から走行条件の削除命令を受信した時など、所定の削除条件を満たしたときに、特定の走行条件の削除を実行してもよい。また、車両用クライアント装置２００は、故障診断サーバ１０１から車両データの送信終了命令が受信されるまでは、走行条件に合致するたびに車両データを取得して送信しつづけてもよい。
【００７７】
図８は、故障診断処理の詳細なフローチャートである。ステップＳ８００において、故障診断サーバ１０１は、診断対象となっているｉ（ｉの初期値は０）番目の故障について、診断対象車両１１０の車両データを、車両情報データベース１０４から抽出する。図７の例を用いて説明すると、診断対象車両１１０の車両番号と、走行条件とから対応する車両データを特定して読み出す。
【００７８】
ステップＳ８０２において、故障診断サーバ１０１は、診断対象となっているｉ（ｉの初期値は０）番目の故障について、故障車両１１１の車両データを、車両情報データベース１０４から抽出する。図７の例を用いて説明すると、故障車両１１１の車両番号と、走行条件とから対応する車両データを特定して読み出す。
【００７９】
ステップＳ８０４において、故障診断サーバ１０１は、読み出された診断対象車両１１０の車両データと、故障車両１１１の車両データとを比較し、同様の故障が発生していると考えられる程度に両者が同一又は類似しているかを判定する。同一又は類似していればステップＳ８０６に進み、そうでなければステップＳ７０８に進む。なお、故障診断の際には、他の正常車両の車両データと比較してもよい。すなわち、故障診断サーバ１０１０は、他の正常車両の車両データと診断対象車両１１０の車両データとを比較し、統計的に誤差の範囲内になければ異常（故障）が発生していると判断する。あるいは、故障車両と正常車両の双方の車両データと比較し、どちらにより類似しているかを判定してもよい。 具体的なデータ処理としては、ＭＢＲ（Ｍｅｍｏｒｙ Ｂａｓｅｄ Ｒｅａｓｏｎｉｎｇ）などのデータマイニング手法を用いることもできる。ＭＢＲを適用すれば、大量の故障データや車両データを直接使用すして故障モデルや正常モデルを作成するため、他方式のように事前のモデリングは不要となるメリットがある。従って、システムを変更することなく、新規の故障データを随時追加するだけで、過去に存在しなかった新規の故障の診断も実現できる。また、過去の故障事実（故障データ）に基づいて故障診断を実行しているため、故障の根拠も明確であり、従来技術に比べても故障診断の信頼性が高くなろう。さらに、データの部分集合（例えば、以下の時間幅Ｔの車両データ）で推論を実行するため、ノイズにも強い特徴がある。
【００８０】
ステップＳ８０６において、故障診断サーバ１０１は、ｉ番目の故障識別コードを故障リストに追加する。故障リストは、メモリ又はハードディス・クドライブなどの記憶手段に格納される。
【００８１】
ステップＳ８０８において、全ての故障コードについて故障診断を終了したかを判定する。終了していなければ、ステップＳ８３０のいてｉの値をインクリメントし、ステップＳ８００へと戻り、次の故障識別コードについて故障診断を行なう。
【００８２】
ステップＳ８１０において、故障診断サーバ１０１は、記憶手段に記憶されている故障リストを読み出し、何れかの故障識別コードが登録されているかを判定する。いずれかの故障識別コードが登録されていれば、その故障識別コードに対応する故障が発生していることになる。故障コードが登録されていなければステップＳ８２２に進む。１つでも故障が発見された場合にはステップＳ８２０へと進む。
【００８３】
ステップＳ８２０において、故障診断サーバ１０１は、ドライバに報告するための故障診断結果（予測レポート）を作成する。例えば、故障リストに登録されている故障識別コードについて、緊急度別にソートし、故障診断結果を作成してもよい。この故障診断結果には、例えば、発見された全ての故障を含ませてもよいし、あるいは運行の支障をきたすようなものや、安全性に直結するような緊急度の高い故障のみを含ませてもよい。なぜなら、緊急度の低いものを通知すると、過度に不安になるドライバも存在するかもしれないので、緊急度の高いもののみを通知させる利点がある。
【００８４】
また、故障の緊急度が高い場合には、その緊急度を反映させた故障診断結果を作成してもよい。これにより、ドライバは、緊急の度合いを把握しやすくなろう。
【００８５】
ステップＳ８２２において、故障診断サーバ１０１は、故障なしを示す診断結果を作成し記憶手段に記憶する。診断結果としては、例えば、「故障の発生を確認できませんでした。快適なドライビングをお楽しみ下さい。」とか、「現時点では故障の発生は確認できませんでした。この故障診断は、故障していないことを保証するものではありません。」とか、「現時点では故障の発生は確認できませんでした。但し、不意に故障が発生することもありますので、運行前点検や定期点検などは必ず実行しましょう。」などのメッセージとすればよいだろう。
【００８６】
以上のように、本実施形態にかかる発明では、特定の走行条件に合致したときに診断対象車両の車両データを送信すればよいため、車両側とサーバ側への負荷を従来よりも軽減でき、さらに通信トラヒックも低減できる。また、特定の走行条件でしか発生しないような故障も効率よく発見できる利点がある。
【００８７】
［第２の実施形態］
上述した第１の実施形態に係る遠隔故障診断システムを基本とする第２の実施形態を説明する。以下の説明においては、第１の実施形態と同様な構成については重複する説明を省略し、本実施形態における特徴的な部分を中心に説明する。
【００８８】
第２の実施形態では、通常の車両データに基づいて簡易な診断を実行し、その結果詳細な診断が必要と判定されたときには、走行条件等を指定して車両データを取得し、詳細な診断を実行するものである。
【００８９】
図９は、第２の実施形態にかかる故障診断に関するフローチャートである。図４及び図６と共通のステップについては同一の引用符号を付すことで説明を簡潔にする。ステップＳ４００において、診断対象車両１１０は所定のタイミングで車両データを送信し、ステップＳ４１０において、故障診断サーバ１０１が、車両データを受信したものとする。なお、このときの車両データは走行条件等が指定されていないため、サンプリング間隔を長めにするなどしてデータ量を低減できるようにしておいてもよい。
【００９０】
ステップＳ９０４において、故障診断サーバ１０１は、受信された車両データに基づいて故障診断を行なう。なお、ここでの故障診断は図８に示したフローチャートに従った実行される。
【００９１】
ステップＳ９０５において、故障診断サーバ１０１は、故障診断結果に基づいて、より詳細な診断が必要かを判定する。例えば、比較結果が故障と断定できるほどの数値を示してはいないが、それに近い場合には、詳細な診断が必要と判定する。ここでの数値とは、故障車両の車両データと診断対象車両の車両データとの一致度合いを示すような値のことであり、相関演算により得られる相関値などを採用できよう。判定の結果、詳細な診断が必要な場合は、ステップＳ６０６に進み、詳細診断の対象となった故障に対応する走行条件を決定する。一方、詳細な診断が不要な場合は、ステップＳ６２２へと進む。
【００９２】
以上のように本実施形態によれば、診断対象車両１１０に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断システム（例：故障診断サーバ１０１など）であって、前記診断対象車両１１０から受信した車両データに基づき、所定の故障について故障診断を実行する第１の故障診断手段（例：故障診断サーバ１０１のＣＰＵ、ステップＳ９０４）と、前記故障診断の結果に基づいて、より詳細な故障診断が必要かを判定する判定手段（例：故障診断サーバ１０１のＣＰＵ、ステップＳ９０５）と、より詳細な故障診断が必要と判定されると、該より詳細な故障診断を実行する際に必要となる特定の走行条件における車両データを要求する要求手段（例：故障診断サーバ１０１のＣＰＵ、ステップＳ６０８）と、前記走行条件に則して取得された車両データを前記診断対象車両から受信する受信手段（例：ステップＳ６１８）と、前記受信された車両データに基づいて、前記第１の故障診断手段よりも詳細な故障診断を実行する第２の故障診断手段（例：故障診断サーバ１０１のＣＰＵ、ステップＳ６２０）と、前記第２の故障診断手段による故障診断結果を前記診断対象車両の顧客に対して通知する通知手段と（例：故障診断サーバ１０１のＣＰＵ、ステップＳ６２２）を有する遠隔故障診断システムが提供される。
【００９３】
また、本実施形態では、例えば、定期的なタイミングなどで車両データを送信したときに、故障診断を行なうことも可能なため、ドライバが故障診断の実行を失念しているときでも、自動で故障診断結果を報告することができる。
【００９４】
また、通常の故障診断時には、データ量の少ない車両データで簡易に診断しておき、故障の可能性が確認されたときには、走行条件等を指定してさらに詳細な車両データを取得して詳細な故障診断を実行することで、通常時は車両データのデータサイズを抑えることができる。また、走行条件に合致した時に詳細診断用の車両データを送信するため、長い時間で見ればトータルで送信される車両データの量を低減できよう。さらに、特定の走行条件での再現されやすい故障を効率よく発見できる。
【００９５】
［第３の実施形態］
上述の実施形態では、主に診断車両側から故障診断のトリガーをかけるものであった。しかしながら、本発明はこれに限定されることはなく、情報センター１００側からトリガーをかけることもできる。
【００９６】
図１０は、第３の実施形態に係る故障診断のフローチャートである。図６のステップＳ６００とＳ６０２とを、ステップＳ１００２に置き換えている。ステップＳ１００２において、故障診断サーバ１０１は、診断を開始すべき所定のタイミングであるかどうかを判定する。この所定のタイミングとは、１週間に１度のような定期的なタイミングでもよいし、品質部門からの要求があったタイミングでもよいし、連休初日など自動車の利用が増えるときであってもよい。あるいは、前回の診断時刻を記憶装置に記憶しておき、そこから一定期間をすぎても診断の要求が車両側から送信され
以上のように本実施形態では、車両やユーザ側から診断要求がなかった場合であっても、故障診断サーバ１０１が必要な時刻を見計らって診断を開始することで、ドライバが故障診断の実行を失念しているときでも自動で故障診断結果を報告できる。また、診断開始時のユーザ側の操作が不要となるため、ユーザにとっても使い勝手が向上しよう。
【００９７】
なお、故障が発見されなかった場合に、故障診断サーバ１０１は、ドライバに診断結果を通知することなく終了してもよい。これにより、ドライバに無駄な情報が送信されることを抑制できる。また、本実施形態では、ドライバが意識せずとも、故障診断を実行しているため、故障の発生が発見されない場合には、そのままドライバに意識させないようにする方が運転に集中でき、好ましいかもしれない。
【００９８】
［第４の実施形態］
本実施形態では、同一又は類似の車両データが毎回送信されることによる無駄なトラヒックを抑制し、効率よく故障診断を実行しようとするものである。図１１は、本実施形態にかかる故障診断処理のフローチャートである。図６、図９及び図１０に示されたフローチャートのうち、ステップＳ６１０とステップＳ６１２との間に本実施形態に特有の処理を付加している。
【００９９】
ステップＳ１１１１において、車両用クライアント装置２００は、あらかじめ記憶装置に記憶しておいた前回の診断時刻を読み出し、その診断時刻と現在の時刻とを比較し、所定の時間が経過しているかを判定する。所定時間を経過していれば、ステップＳ６１２へと進み、走行条件に合致した車両データを取得する。そうでなければ、現在の車両データも前回の車両データと大きな相異はないと考えられるため、所定の時間だけ待機することにする。所定時間とは、例えば、１日、１週間という単位でもよいし、経験的に有意な変化が現れると思われるような時間などを設定すればよい。
【０１００】
このように本実施形態では、前回の診断時刻から所定時間の経過を待ってから車両データを取得して故障診断を実行するため、車両データの変化が余りないことにより前回と同様の診断結果となってしまうような事態を回避できる。すなわち、意味のある診断結果が得られるときに車両データの取得や送信を実行するため、無駄な車両データの取得や送信を省略できるメリットがある。
【０１０１】
なお、ステップＳ１００２は所定時間が経過するまで待機することで目的を達成していたが、他の方法を用いてもよい。例えば、車両用クライアント装置２００が、前回の車両データをハードディス・クドライブなどの記憶装置に記憶しておき、今回取得された車両データと前回の車両データとを比較し、実質的に相異している場合には今回の車両データを故障診断サーバ１０１に送信するようにしてもよい。
【０１０２】
また、所定時間に代えて、前回の診断時から所定距離を越えて走行していることを条件としてもよい。車両用クライアント装置２００は、前回診断した時の走行距離メータの値を記憶装置に記憶しておき、そこから１００ｋｍや１０００ｋｍなどの所定距離を超えて走行したか否かを判定するようにすればよい。
【０１０３】
また、車両用クライアント装置２００は、所定時間を適宜補正してもよい。例えば、車両用クライアント装置２００は、今回取得された車両データと前回の車両データとを比較し、実質的に相異していない場合には、一応車両データを送信するとともに、所定時間を従来よりも長く設定する。このように、車両データにあまり変化が無い場合には、車両データを頻繁に送信することは無駄であるので、送信のタイミングを徐々に長くしてゆけばよい。なお、送信周期を変化させるのではなく、サンプリング周期を従来よりも長く設定することで、一回に送信される車両データのサイズを小さくすることもできる。なお、故障診断サーバ１０１が、同様の判定を行なって、所定時間の変更を車両用クライアント装置２００に指示してもよい。
【０１０４】
以上のように本実施形態によれば、所定の条件を満たすまで、車両用クライアント装置２００が車両データの送信を禁止するため、無駄な通信が抑制される。
【０１０５】
［第５の実施形態］
本実施形態では、故障情報データベース１０３の更新処理を効率よく行なうことを目的とする。図１２は、本実施形態に係る故障情報データベース１０３の更新処理に係るフローチャートである。
【０１０６】
ステップＳ１２００において、故障診断サーバ１０１は、更新要求が入力されたかどうかを判定する。この更新要求は、故障診断サーバ１０１の管理者が操作部から入力してもよいし、品質部門のコンピュータからの更新要求を故障診断サーバ１０１に入力してもよい。また、どのような故障について故障情報を更新するかを指定してもよい。指定の際は故障コードを指定することができる。
【０１０７】
ステップＳ１２０２において、故障診断サーバ１０１は、更新すべき故障は特定の走行条件において再現性が高いものであるかを判定する。例えば、故障診断サーバ１０１は、指定された故障コードを検索キーとして、故障情報データベース１０３を検索し、特定の走行条件が登録されているかどうかを判定する。特定の走行条件が登録されていれば、ステップＳ６０６へと進み、検索により抽出された特定の走行条件を、車両データを取得するための走行条件として決定する。そうでなければ、ステップＳ６１４へと進み、故障診断サーバ１０１は、走行条件を特別に指定することなく故障車両１１１の車両用クライアント装置２００に車両データを取得させ送信させる。
【０１０８】
ステップＳ１２２０において、故障診断サーバ１０１は、故障車両１１１の車両用クライアント装置２００から受信した車両データに基づいて、故障情報データベース１０３と車両情報データベース１０４を更新する。
【０１０９】
以上のように本実施形態によれば、診断対象車両１１０に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断システム（例：故障診断サーバ１０１）において、故障診断に必要となる故障車両の車両データを記憶するデータベース（例：故障情報データベース１０３、車両情報データベース１０４）と、前記データベースの更新要求が発行されると、更新に必要となる車両データのうち特定の走行条件下における車両データを１以上の故障車両に要求する要求手段（例：ステップＳ６０８）と、前記故障車両から受信された車両データに基づいて前記データベースの内容を更新する更新手段（例：Ｓ１２２０）とを含む遠隔故障診断システムが提供される。
【０１１０】
本実施形態によれば、故障の種類に応じて走行条件を種々指定できるため、特定の走行条件でした再現されないような故障について車両データを効率よく更新することができる。
【０１１１】
［第６の実施形態］
本実施形態では、図９の遠隔故障診断フローチャートをベースとして、詳細診断を実行するにあたり、特定の走行条件下での車両データが必要のときには再度車両データを要求し、不要のときは現在の車両データに基づいて詳細診断を実行するフローチャートである。なお、図９の説明で既に説明した部分は省略する。
【０１１２】
図１３は、第６の実施形態に係る遠隔故障診断のフローチャートである。ステップＳ９０５において、詳細診断が必要と判定されるとステップＳ１３０６に進む。ステップＳ１３０６において、故障診断サーバ１０１は、詳細診断の対象となった故障の種類に応じて、現在入手されている車両データで詳細診断が可能であるか、または特定の走行条件下での車両データが無ければ詳細診断を実行できないかを判定する。例えば、故障情報データベース１０３に、故障コードと対応付けて、詳細診断を実行する際の走行条件が登録されているか否かに基づいて判定すればよい。
【０１１３】
判定の結果、特定の走行条件下での車両データが必要であれば、ステップＳ６０６以降の処理へと進む。不要であれば、ステップＳ６２０へと進み、現在入手されている車両データで詳細診断を実行する。
【０１１４】
以上説明したように、本実施形態によれば、簡易診断、詳細診断及び特定走行条件下での車両データを用いた詳細診断を、故障の種別に応じて使い分けることで、車両側とシステム側の負荷を軽減でき、さらには通信トラヒックの軽減も可能となる。
【０１１５】
［他の実施形態］
上述の実施形態では、故障車両を含め、すべての車両データを車両情報データベース１０４に蓄積していた。しかしながら、故障車両の車両データについては故障情報データベース１０３に蓄積するようにしてもよい。車両の普及台数を考慮すれば、車両データの量は膨大になるおそれがあるため、古い情報については車両情報データベース１０３から随時削除する必要がある。そこで、本当に必要な故障車両の車両データだけを故障情報データベース１０３残すことで、車両情報データベース１０３の記憶量を削減できよう。
【０１１６】
なお、走行条件については、車両データに含まれる時間ごとの緯度経度情報や、速度情報、加速度情報、夜か昼か、気温、雨か晴れかなどによって特定可能である。例えば、故障診断サーバ１１０は、緯度経度情報から車両データが取得されたときの位置を特定し、さらに地図データベースからその位置が高速道路なのか、１３０Ｒのカーブなのか、斜度１５度の坂なのかといった走行条件を特定する。
【０１１７】
故障の診断結果については、故障診断サーバ１１０から車両用クライアント装置２００に対して直接送信してもよいが、電子メールとして顧客に送信してもよい。例えば、故障診断サーバ１１０は、故障診断対象車両１１０の車両番号に基づいて顧客データベース１０２を検索し、顧客の電子メールアドレスを抽出する。そして、故障診断サーバ１１０は、抽出された電子メールアドレスに対して診断結果を送信する。
【０１１８】
なお、ドライバの電子メールアドレスだけでなく、そのドライバが所属する会社の電子メールアドレスなどのように複数の電子メールアドレスを顧客データベースに登録しておけば、故障診断サーバ１１０は、ドライバだけでなく、そのドライバが所属する会社にも診断結果を配信できるため、会社全体として安全管理に役立てられる利点がある。
【０１１９】
上述の走行条件に加え、サンプリング周期やサンプリング時間を故障診断サーバ１０１が指定することで、車両データのサイズを調整することもできる。
【０１２０】
また、故障診断サーバ１０１は、同時に複数の走行条件を車両用クライアント装置２００に送信してもよい。車両用クライアント装置２００は、複数の走行条件のうち合致するものがあるたびに車両データを取得し記憶装置に記憶する。なお、取得された記憶装置は、各走行条件ごとに送信してもよいし、すべての走行条件に合致したときに送信してもよい。
【図面の簡単な説明】
【図１】図１は、本実施形態に係るシステムの構成例を示した図である。
【図２】図２は、本実施形態に係る車両の構成例を示したブロック図である。
【図３】図３は、サービス工場１２０の構成例を示した図である。
【図４】図４は、本実施形態に係る車両データの収集に関するフローチャートである。
【図５】図５は、故障診断に使用される故障データの収集に関するフローチャートである。
【図６】図６は、第１の施形態に係る遠隔故障診断処理についてのフローチャートである。
【図７】図７は、本実施形態に係るデータベースの内容と故障診断処理の概念を示す図である。
【図８】図８は、本実施形態に係る故障診断処理の詳細なフローチャートである。
【図９】図９は、第２の実施形態に係る遠隔故障診断処理のフローチャートである。
【図１０】図１０は、第３の実施形態に係る遠隔故障診断処理のフローチャートである。
【図１１】図１１は、第４の実施形態に係る遠隔故障診断処理のフローチャートである。
【図１２】図１２は、第５の実施形態に係るデータベース更新処理のフローチャートである。
【図１３】図１１は、第６の実施形態に係る遠隔故障診断処理のフローチャートである。
【符号の説明】
１００…情報センター
１０１…故障診断サーバ
１１０…故障診断対象車両
１１１…故障車両
１２０…サービス工場
１２１…サービス工場用クライアント

Claims (3)

1. 診断対象車両に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断システムにおいて、
   故障診断に必要となる故障車両の車両データを、該故障車両に故障が発生したときの走行条件とともに記憶するデータベースと、
   前記データベースの更新要求が発行されると、更新に必要となる車両データのうち特定の走行条件下における車両データを複数の故障車両に要求する要求手段と、
   前記故障車両から受信された車両データに基づいて前記データベースの内容を更新する更新手段と
   を含む遠隔故障診断システム。
2. 診断対象車両に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断方法であって、
   故障診断に必要となる故障車両の車両データを、該故障車両に故障が発生したときの走行条件とともに記憶するデータベースの更新要求を受信するステップと、
   前記データベースの更新に必要となる車両データのうち特定の走行条件下における車両データを送信するよう複数の故障車両に要求するステップと、
   前記故障車両から受信された車両データに基づいて前記データベースの内容を更新するステップと
   を含む遠隔故障診断方法。
3. 診断対象車両に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断をコンピュータに実行させるためのコンピュータプログラムであって、
   故障診断に必要となる故障車両の車両データを、該故障車両に故障が発生したときの走行条件とともに記憶するデータベースの更新要求を受信するステップと、
   前記データベースの更新に必要となる車両データのうち特定の走行条件下における車両データを送信するよう複数の故障車両に要求するステップと、
   前記故障車両から受信された車両データに基づいて前記データベースの内容を更新するステップと
   をコンピュータに実行させるためのコンピュータプログラム。

Images