JP4622177B2 - 故障診断システム、車両管理装置、サーバ装置、及び検査診断プログラム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、車両の故障診断システムに関する。
【０００２】
【従来の技術】
近年、高性能マイクロプロセッサの出現などエレクトロニクス技術の進歩を背景として、機械技術と電子技術とが結びついたメカトロニクス技術の進歩が著しい。メカトロニクスの進歩の一部として、自動車等の車両にも多くのコンピュータシステムが採用されてきている。このような車載用のコンピュータシステムは、省資源、省エネルギー、走行性能、安全性、快適性等を追求するものであり、車両内のエンジン・駆動系、走行・安全系、エンターテイメント系、及びその他の随所に搭載されている。
【０００３】
このような電子制御装置では、車両各部位の故障検出を的確に行わないと、種々の不具合を引き起こす可能性があり、場合によっては走行不能となることもある。そのため、電子制御装置に車両各部位の故障を検出するための故障検出プログラムを搭載することにより、信頼性の向上が図られている。すなわち、コンピュータ部やセンサ類の動作状態を適当な周期で自動的にチェックし、故障時には、ダイアグコード（ＳＡＥコード等）等を記憶する。
【０００４】
これにより、修理担当者は、電子制御装置に記憶されるダイアグコード等を、専用ツールを接続することによって読み出し、故障箇所を特定することになる。
【０００５】
【発明が解決しようとする課題】
上述した故障検出は、各電子制御装置において個別に故障検出プログラムを実行し、各電子制御装置の単位でなされるのが一般的であった。
しかしながら最近では、車両制御用の電子制御装置は、車両内ネットワークを介して接続され、相互に連携動作を行うようになっている。
【０００６】
そのため電子制御装置間の連携動作に係る不具合が発生する可能性があり、電子制御装置単位で用意される故障検出プログラムによる情報からだけでは故障個所が特定できないといった事態が生じている。
また、不具合を発生させた故障箇所の特定には、連携動作が関連してくることから、電子制御装置内部の専門的な知識を必要とする。したがって、従来のように各電子制御装置に対し専用ツールを接続してダイアグコード等を読み出すという手法では、故障箇所の特定に困難を極める。そのため、修理工場やディーラーへ車両を持ち込んでも、修理までに相当期間を要することがあった。
【０００７】
本発明は、上述した問題点を解決するためになされたものであり、車両内ネットワークを介して接続される複数の電子制御装置の連携動作による不具合を適切に判断し、さらに、迅速な故障箇所の特定を可能にすることを目的とする。
【０００８】
【課題を解決するための手段及び発明の効果】
本発明の故障診断システムは、複数の電子制御装置と、車両管理装置とを備える。
電子制御装置の夫々は、車両内ネットワークを介して接続され、制御対象を制御し、
相互に連携動作する。そして車両管理装置が、車両内ネットワークを介して電子制御装置と通信し、車両の故障管理を行う。この意味で、電子制御装置も車両管理装置も車両内ネットワーク上のコンピュータシステムとして機能する。
【０００９】
本発明では、車両管理装置を車両内ネットワーク上に配置し、ネットワークを介して電子制御装置の間でやり取りされるデータに基づき、不具合判断手段が、連携動作に係る不具合の発生を判断する。例えばここでいう電子制御装置のデータは、車両管理装置を介して電子制御装置間でやり取りされるものとすることができる（請求項２）。この構成は、車両管理装置がいわゆるゲートウェイとして機能し車両内ネットワークに流れるデータを監視する構成を意味する。車両内ネットワークに流れるデータを監視することによって、電子制御装置間の連携動作を監視でき、この連携動作に係る不具合を判断することができる。
【００１０】
プログラム取得手段は、不具合に対応させて予め用意された検査診断プログラムを取得する。そして、故障箇所特定手段が、取得された検査診断プログラムを実行することによって、該当する電子制御装置に対応処理を実行させ、当該対応処理の実行により電子制御装置から送信される情報に基づいて連携動作に係る故障箇所を特定する。つまり、故障個所特定のために、車両管理装置からの指示で、電子制御装置が対応処理を実行するようにし、例えば特定制御における内部変数などを送信させるのである。
【００１１】
そして、情報出力手段は、故障箇所特定手段による処理結果に基づいて、故障に関する故障情報を出力する。これは例えば、警告灯の点灯であってもよいし、ナビゲーション装置を備える構成であれば、いわゆるナビ画面への情報表示であってもよい。故障情報には、故障箇所が特定できた場合の故障箇所を示すものだけでなく、故障箇所が特定できない場合の異常発生を示すものや電子制御装置から送信される内部変数を示す情報なども含まれる。
【００１２】
このように本発明によれば、ネットワークを介して電子制御装置の間でやり取りされるデータに基づき不具合の発生を判断するため、電子制御装置間の連携動作に係る不具合の発生を判断することができる。そして、予め用意された検査診断プログラムを用い、該当する電子制御装置に例えば特定制御における内部変数などを送信させて故障箇所を特定するため、迅速に故障箇所が特定できる可能性が高い。
【００１３】
なお、故障箇所特定手段は、検査診断プログラムによって故障箇所が特定できない場合、プログラム取得手段に別の検査診断プログラムを取得させるようにすることが考えられる（請求項３）。これは、発生する不具合に対して様々な故障要因が考えられるため、複数の検査診断プログラムによって、故障箇所を段階的に特定していくという技術思想である。例えば、検査診断プログラムを階層化して用意しておき、電子制御装置からの内部変数などを考慮して、段階的に用いるという具合である。このようにすれば、電子制御装置間の複雑なデータの受け渡しなどに関連する故障箇所も複数の検査診断プログラムによって特定できる可能性が高くなり、迅速な故障箇所の特定に寄与できる。
【００１４】
ところで、検査診断プログラムは、不具合に応じて予め用意されるものであるが、種々の不具合に対して用意することを考えると、あるいは、階層化して用意することを考えると、車両内に記憶しておくことは現実的でない。
そこで、さらに、車両外部に設置され、車両管理装置との間でデータ通信可能なサーバ装置を備える構成を採用することが望ましい。このとき、サーバ装置は、検査診断プログラムを記憶した記憶手段を有し、車両管理装置のプログラム取得手段は、サーバ装置から検査プログラムを取得する（請求項４）。このようにすれば、個々の車両の記憶容量を削減できることはもちろん、サーバ装置の検査診断プログラムを更新することにより、各車両において、適切な検査診断プログラムが使用できる。
【００１５】
具体的には、車両管理装置のプログラム取得手段が、不具合を示す不具合情報を含む問い合わせ情報をサーバ装置へ送信する構成とし、サーバ装置は、記憶手段に不具合情報に対応させて検査診断プログラムを記憶しており、プログラム取得手段から問い合わせ情報が送信されると、記憶手段に記憶された検査診断プログラムを不具合情報に基づいて検索し、該当する検査診断プログラムを車両管理装置へ送信する構成とすることが考えられる（請求項５）。
【００１６】
このときサーバ装置は、記憶手段に、さらに、ユーザ毎に用意される顧客情報を記憶しておくようにしてもよい。この場合、プログラム取得手段からの問い合わせ情報が送信されると、顧客情報を考慮して、該当する検査診断プログラムを送信する（請求項６）。顧客情報としては、ユーザの使用している車種やグレードを示す車両情報や、その車両の故障履歴情報などが一例として挙げられる。車両情報や故障履歴情報があれば、適切な検査診断プログラムを選択できる可能性が高くなり、結果として、迅速な故障箇所の特定につながる。また、顧客情報にユーザを特定できる特定情報を含めるようにすれば、サービス契約を取り交わしたユーザ以外の不正なアクセスを防止することもできる。
【００１７】
このような不正アクセス防止は、車両側でも重要となる。車両管理装置が不適当なプログラムを受信する事態となれば、安全走行に重大な支障を来すことになるからである。そこで、車両管理装置のプログラム取得手段は、サーバ装置からの検査診断プログラムの受信に先立って、サーバ装置が正当なものであるか否かを判定する認証処理を実行するようにすることが望ましい（請求項７）。
【００１８】
なお、本発明では、上述したように車両側で実行されるプログラムをサーバ装置から取得することによって、車両側のプログラムを容易に追加・変更できることを一つの特徴としている。
このような観点からは、電子制御装置にて実行される対応処理を実現するための対応処理プログラムをも、電子制御装置に予め記憶しておくこと以外に、サーバ装置から取得するように構成してもよい。すなわち、車両管理装置のプログラム取得手段が、電子制御装置における対応処理のための対応処理プログラムを、サーバ装置から取得して電子制御装置へ送信し、電子制御装置が、車両管理装置から送信された対応処理プログラムを記憶する構成としてもよい（請求項８）。この場合、電子制御装置内部に対応処理プログラムを記憶するための記憶領域を確保しておけばよい。これによって、検査診断プログラムに合わせた対応処理を電子制御装置に実行させることができ、故障箇所特定の幅が広がることになる。
【００１９】
ところで、情報出力手段が故障箇所特定手段による処理結果に基づき故障情報を出力することは既に述べたが、このような情報は、検査診断プログラムの変更や新たな検査診断プログラムの作成に利用できる。そこで、車両管理装置の情報出力手段は、故障箇所特定手段による処理結果に基づき、サーバ装置へ故障情報を送信し、サーバ装置は、故障情報を、記憶手段に記憶する構成とすることが考えられる（請求項９）。このようにすれば、各車両で発生した不具合に対する処理結果に基づく故障情報がサーバ装置の記憶手段に保存されることになり、検査診断プログラムの適切な更新や、新たな検査診断プログラムの作成が容易になる。
【００２０】
また、このような故障箇所に関する情報を記憶手段に記憶するだけでなく、サーバ装置は、故障箇所に関する情報に基づき外部への通知を行うようにしてもよい（請求項１０）。外部とは、ユーザ毎に決まってくる連絡先、例えば販売店やサービス工場とすることが考えられる。例えば交換が必要なパーツを予めサービス工場へ連絡するようにしておけば、利用者が修理のためにサービス工場を訪れた際に迅速な対処が可能になる。
【００２１】
さらにまた、故障箇所に関する故障情報がサーバ装置に保存されるようにした場合など、それらの故障情報を統計することによって、必要になる可能性の高い検査診断プログラムが、ある程度特定できる場合が考えられる。そこで、そのような検査診断プログラムを、実際に不具合が発生する前に、車両管理装置に記憶しておいてもよい。
【００２２】
すなわち、プログラム取得手段は、検査診断プログラムを予め取得可能な構成にしてもよい（請求項１１）。例えば、サーバ装置から検査診断プログラム以外の別データが車両へ送信されることを前提として、プログラム取得手段は、当該別データ送信の際に検査診断プログラムを取得することが考えられる（請求項１２）。別データとは、例えばナビゲーション装置を備える場合の地図データや検索データなどが挙げられる。例えば、店舗の検索などをナビゲーション装置にて実行した場合、これに対応する検索データに重畳させて特定の検査診断プログラムを取得するという具合である。
【００２３】
上述の構成によって、例えば他車で発見された最新の不具合等、それまでに収集された故障情報からの総合的な判断結果に基づき、検査診断プログラム群から最適なものを予め取得しておけば、場合によっては不具合の発生時に検査診断プログラムを即座に起動でき、故障箇所をさらに迅速に特定できる可能性が高くなる。
【００２４】
以上は故障管理システムの発明として説明してきたが、このような故障管理システムを構成する車両管理装置の発明として実現することもできる（請求項１３，１４）。この車両管理装置による作用及び効果は、上述した故障診断システムにおける車両管理装置の作用及び効果と同様であるため、説明は省略する。
【００２５】
このような車両管理装置においても、故障箇所特定手段が、検査診断プログラムによって故障箇所が特定できない場合、プログラム取得手段に別の検査診断プログラムを取得させるように構成することが考えられる。
また、サーバ装置を備える構成を前提として、プログラム取得手段は以下のように構成できる。
【００２６】
すなわち、例えば不具合情報を含む問い合わせ情報をサーバ装置へ送信することにより、サーバ装置から検査プログラムを取得するように構成できる。また、サーバ装置からの検査診断プログラムの受信に先立って、サーバ装置が正当なものであるか否かを判定する認証処理を実行するようにしてもよい。さらにまた、検査診断プログラムに限らず、電子制御装置における対応処理のための対応処理プログラムを、サーバ装置から取得して電子制御装置へ送信する構成とすることも考えられる。また、他車で発見された最新の不具合等、それまでに収集された故障情報からの総合的な判断結果に基づき、検査診断プログラム群から最適な検査診断プログラムを、例えば別データの受信の際に、サーバ装置から予め取得するようにしてもよい。
【００２７】
さらに、情報出力手段について言えば、故障箇所特定手段による処理結果に基づき、サーバ装置へ故障情報を送信するように構成してもよい。
ところで、上述した故障管理システムを構成するサーバ装置の発明として実現することもできる（請求項１５）。このサーバ装置による作用及び効果は、上述した故障診断システムにおけるサーバ装置の作用及び効果と同様であるため、説明は省略する。
【００２８】
このサーバ装置においても、記憶手段に、さらに、ユーザ毎に用意される顧客情報を記憶しておき、車両管理装置から問い合わせ情報が送信されると、顧客情報を考慮して、該当する検査診断プログラムを送信するようにしてもよい。また、記憶手段には、電子制御装置にて実行される対応処理を実現するための対応処理プログラムを記憶しておくことも考えられる。
【００２９】
さらに、車両管理装置が故障情報を送信する構成では、当該故障情報を記憶手段に記憶するようにすることが考えられる。また、当該故障情報に基づき外部への通知を行うようにしてもよい。
なお、本発明では、電子制御装置に対応処理を実行させ、当該対応処理によって電子制御装置から送信される情報に基づき故障箇所を特定する検査診断プログラムに特徴がある。この意味で、検査診断プログラムの発明として実現することもできる（請求項１６）。
【００３０】
【発明の実施の形態】
以下、本発明を具体化した一実施例を図面を参照して説明する。
図１は、実施例の故障診断システムの概略構成を示す説明図である。
本実施例の故障診断システムは、車両に搭載されるコンピュータシステムと、車両外に設置される「サーバ装置」としての顧客サーバ４０とを備えている。
【００３１】
車両に搭載されるコンピュータシステムは、「電子制御装置」としてのエンジンＥＣＵ１１、トランスミッションＥＣＵ１２、ブレーキＥＣＵ１３、ナビＥＣＵ１４、オーディオＥＣＵ１５、ＴＥＬ−ＥＣＵ１６、メータＥＣＵ１７、盗難防止ＥＣＵ１８、エアコンＥＣＵ１９、及び「車両管理装置」としての車両マネージャＥＣＵ３０である。
【００３２】
車両マネージャＥＣＵ３０は、「車両内ネットワーク」としての制御系ネットワーク２１、情報系ネットワーク２２、及びボデー系ネットワーク２３に接続されており、制御系ネットワーク２１上にエンジンＥＣＵ１１と、トランスミッションＥＣＵ１２と、ブレーキＥＣＵ１３とが配置され、情報系ネットワーク２２上にナビＥＣＵ１４と、オーディオＥＣＵ１５と、ＴＥＬ−ＥＣＵ１６とが配置され、ボデー系ネットワーク２３上にメータＥＣＵ１７と、盗難防止ＥＣＵ１８と、エアコンＥＣＵ１９とが配置されている。
【００３３】
エンジンＥＣＵ１１は、車両エンジンの制御を主として行うものである。具体的には、アクセルセンサ、空燃比センサ、空気量センサなど、各種センサ信号に基づき、インジェクタやスロットルモータなどを制御する。他のＥＣＵ１２〜１９についても簡単にその機能の一例を説明すると、トランスミッションＥＣＵは、オートマチックトランスミッションのシフトチェンジに関する機能を有し、ブレーキＥＣＵは、ブレーキ油圧の調整機能を有する。また、ナビＥＣＵ１４は、設定されたルートに基づく案内機能、オーディオＥＣＵ１５はＣＤなどの再生機能、ＴＥＬ−ＥＣＵ１６は、ハンドフリーの携帯電話機における発信／着信機能を有する。さらに、メータＥＣＵ１７はメータ表示機能、盗難防止ＥＣＵ１８は例えば車両停車時の振動などに基づく緊急通報機能、エアコンＥＣＵ１９は設定室温となるような送風温や送風量の調節機能を有する。
【００３４】
このように各ＥＣＵ１１〜１９は、それぞれの制御対象を制御するのであるが、必要に応じて連携して動作する。例えばメータＥＣＵ１７による表示情報としての車速などは、エンジンＥＣＵ１１から車両マネージャＥＣＵ３０を介して送信されるという具合である。この意味で車両マネージャＥＣＵ３０は、従来のいわゆるゲートウェイＥＣＵとしての機能を備えている。また、各ＥＣＵ１１〜１９は、それぞれの制御対象の制御において各部位の故障を検出する故障検出プログラムを実行し、故障検出プログラムによる故障検出結果は、車両マネージャＥＣＵ３０へ送信される。そして特に、本実施例では、車両マネージャＥＣＵ３０から例えば特定制御における内部変数などの送信指示がなされると、予め搭載されている対応処理プログラムを実行することにより、指示された情報を車両マネージャＥＣＵ３０へ出力する。この対応処理プログラムの実行判断を行うＥＣＵ処理については後述する。
【００３５】
一方、顧客サーバ４０は、車両外部に設置され、情報通信網に接続されることにより無線の基地局５０を介して、車両マネージャＥＣＵ３０とデータ通信可能に構成されている。顧客サーバ４０も、いわゆるコンピュータシステムとして構成されている。そして、「記憶手段」としてのデータベース４１を備えている。
【００３６】
このデータベース４１には、図２に示すように、本実施例の故障診断システムによるサービスに契約加入している顧客毎に用意される顧客情報４１ａ、車両で発生する不具合を類型化した不具合情報４１ｂ、車両マネージャＥＣＵ３０にて実行される検査診断プログラム４１ｃ、そして、検査診断プログラム４１ｃによる処理結果に基づいて車両マネージャＥＣＵ３０から送信される故障情報４１ｄが記憶される。このとき、検査診断プログラム４１ｃは、不具合情報４１ｂに対応させて用意されている。図２中では、不具合情報４１ｂと検査診断プログラム４１ｃとをセットにして示した。
【００３７】
顧客情報４１ａには、顧客サーバ４０にアクセスしたユーザを特定するための特定情報、過去の故障に関する故障履歴情報、車種やグレードを示す車両情報、及び故障時における連絡先情報が記憶されているものとする。特定情報は、例えばユーザＩＤとパスワードから構成することが考えられる。また、連絡先情報には、電話番号やＦＡＸ番号を用いることが考えられる。
【００３８】
不具合情報４１ｂは、車両の不具合症状を類型化したものであり、車両マネージャＥＣＵ３０から送信される問い合わせ情報中の不具合情報から、対応する検査診断プログラム４１ｃを検索するためのキーとなる。
検査診断プログラム４１ｃは、車両マネージャＥＣＵ３０がダウンロードして実行するものであり、ＥＣＵ１１〜１９の中の該当するものに対応処理を実行させ、対応処理によって送信される情報に基づいて故障箇所を特定するためのプログラムである。
【００３９】
そして、故障情報４１ｄは、車両マネージャＥＣＵ３０にて故障箇所が特定された場合に送信される情報であり、検査診断プログラム４１ｃの作成に有効であるため、顧客サーバ４０のデータベース４１に記憶される。
次に、本実施例の故障診断システムの動作を説明する。
【００４０】
ここでは最初に、車両マネージャＥＣＵ３０の動作を説明し、これに対応する顧客サーバ４０及び各ＥＣＵ１１〜１９の処理を次に説明する。
図３は、車両マネージャＥＣＵ３０にて実行される故障診断処理を示すフローチャートである。この処理は、所定時間間隔で繰り返し実行されるものである。
【００４１】
まず最初のステップ（以下、ステップを単に記号Ｓで示す。）１００において、車両内ネットワーク２１，２２，２３上の各ＥＣＵ１１〜１９のデータを監視する。ここでいうデータは、各ＥＣＵ１１〜１９で実行される故障検出プログラムによる故障検出結果データ、及び、ＥＣＵ１１〜１９間で車両マネージャＥＣＵ３０を介してやり取りされるデータである。すなわち、車両マネージャＥＣＵ３０は、これらのデータを監視することによって、ＥＣＵ１１〜１９における個別の不具合だけでなく、ＥＣＵ１１〜１９の連携動作に係る不具合をも検出する。例えば、ナビＥＣＵ１４からは上り坂であることを示すデータが出力されているにもかかわらず、エンジンＥＣＵ１１のデータからエンジン負荷が全く変化していないような場合を、一つの異常パターンとして監視する。
【００４２】
このデータ監視結果に基づき、続くＳ１１０では、車両の不具合を判断する。ここで不具合が判断された場合（Ｓ１１０：ＹＥＳ）、Ｓ１２０へ移行する。一方、不具合が判断されない場合（Ｓ１１０：ＮＯ）、以降の処理を実行せず、本故障診断処理を終了する。
【００４３】
Ｓ１２０では、顧客サーバ４０との間にデータ通信可能状態を確立し、問い合わせ情報を送信する。データ通信状態の確立は、例えば、車両マネージャＥＣＵ３０が顧客サーバ４０を発呼して例えばユーザＩＤとパスワードとを送信し、顧客サーバ４０が上述した顧客情報４１ａ中の特定情報を用いて契約加入しているユーザであるか否かを判断する、といった所定手続きを経てなされる。このようにしてデータ通信可能状態が確立されると、次に、問い合わせ情報を送信する。問い合わせ情報には、判断した不具合を示す不具合情報が含まれる。
【００４４】
これに対して顧客サーバ４０では、問い合わせ情報に含まれる不具合情報とデータベース４１中の不具合情報４１ｂとを比較し、さらに、顧客情報４１ａ中の故障履歴情報及び車両情報を考慮して、該当する検査診断プログラム４１ｃを選択する。
【００４５】
したがって、続くＳ１３０では、検査診断プログラムが選択されたか否かを判断する。この判断は、顧客サーバ４０からの選択完了の通知に基づいて行われる。ここで検査診断プログラムが選択されたと判断された場合（Ｓ１３０：ＹＥＳ）、Ｓ１４０へ移行する。一方、検査診断プログラム４１ｃが選択されないうちは（Ｓ１３０：ＮＯ）、この判断処理を繰り返す。
【００４６】
Ｓ１４０では、認証手続を行う。この認証手続は、車両側の安全のためのものであり、不当なプログラムの受信を確実に防止する趣旨である。具体的には、ＥＣＵ内のデータをツールで書き換える場合に従来より用いられているような関数を用いた認証を行うことが考えられる。例えば、一方の装置から乱数ｒなどの関数値ｆ（ｒ）を送信し、他方の装置が、この関数値ｆ（ｒ）に基づく関数値Ｆ（ｆ（ｒ））を返信するようにする。そして、一方の装置は、関数値Ｆ（ｆ（ｒ））＝ｒと判断すれば、すなわち関数Ｆ＝ｆ^-1であれば、他方の装置を正当な装置と判断するという具合である。
【００４７】
このような認証手続（Ｓ１４０）により顧客サーバ４０が正当であると判断された場合（Ｓ１５０：ＹＥＳ）、Ｓ１６０へ移行する。一方、正当でないと判断された場合（Ｓ１５０：ＮＯ）、以降の処理を実行せず、本故障診断処理を終了する。
【００４８】
Ｓ１６０では、検査診断プログラム４１ｃのダウンロードを行う。ここでは顧客サーバ４０に対してダウンロードを要求し、顧客サーバ４０から送信される検査診断プログラム４１ｃを受信する。
続くＳ１７０では、ダウンロードした検査診断プログラム４１ｃを実行する。これによって、ＥＣＵ１１〜１９の中の該当するものだけが対応処理を実行し、対応処理によって、例えば特定制御における内部変数などの情報を送信してくる。その結果、検査診断プログラム４１ｃでは、さらに、送信される情報に基づいて故障箇所の特定を行う。
【００４９】
したがって次のＳ１８０では、故障箇所が特定されたか否かを判断する。ここで故障箇所が特定された場合（Ｓ１８０：ＹＥＳ）、Ｓ１９０へ移行する。一方、故障箇所が特定されない場合（Ｓ１８０：ＮＯ）、Ｓ１２０からの処理を繰り返す。つまり、ここで否定判断されると、新たな問い合わせ情報が送信されることになり（Ｓ１２０）、別の検査診断プログラムが選択され（Ｓ１３０：ＹＥＳ）、ダウンロードされて実行される（Ｓ１６０，Ｓ１７０）。
【００５０】
Ｓ１９０では、特定した故障箇所に関する故障情報を顧客サーバ４０へ送信するとともに、故障に関する情報表示を行う。その後、本故障診断処理を終了する。故障に関する情報表示は、例えばメータＥＣＵ１７への情報出力により警告灯の点灯という形で行うことが考えられる。また例えばナビＥＣＵ１４への情報出力により、案内機能の実現に用いられるナビ画面への情報表示という形式で行ってもよい。後者の場合、例えば「○○の交換が必要です」というような故障箇所を指摘する表示であってもよいし、「修理を依頼して下さい」というような抽象的な内容表示であってもよい。これらの表示内容は、顧客の要望に応じて設定変更できるようにすると便利である。
【００５１】
このような車両マネージャＥＣＵ３０における故障診断処理に対応して実行される顧客サーバ４０における処理が、図４のフローチャートに示すサーバ側処理である。この処理は、上述したような所定手順を経て車両マネージャＥＣＵ３０との間にデータ通信可能状態が確立されると、所定時間間隔で繰り返し実行される。
【００５２】
まず最初のＳ２００において、車両マネージャＥＣＵからの問い合わせ情報が送信されたか否かを判断する。この処理は、図３中のＳ１２０に対応するものである。ここで問い合わせ情報が送信された場合（Ｓ２００：ＹＥＳ）、Ｓ２１０へ移行する。一方、問い合わせ情報が送信されない場合（Ｓ２００：ＮＯ）、Ｓ２５０へ移行する。
【００５３】
Ｓ２１０では、データベース４１中の検査診断プログラム４１ｃを、不具合情報４１ｂをキーにして検索する。またこのとき、上述したように、顧客情報４１ａ中の故障履歴情報及び車両情報も考慮する。そして、該当する検査診断プログラム４１ｃを選択する。この検査診断プログラム４１ｃの選択完了通知により、車両マネージャＥＣＵ３０は認証手続を実行する（図３中のＳ１４０）。
【００５４】
したがって、これに対応してＳ２２０では、車両マネージャＥＣＵ３０との間で認証手続を実行する。
認証手続の実行により、車両マネージャＥＣＵ３０は、顧客サーバ４０が正当であるとの判断を行うと（図３中のＳ１５０：ＹＥＳ）、検査診断プログラム４１ｃのダウンロードを要求してくる（Ｓ１６０）。
【００５５】
そこで続くＳ２３０では、検査診断プログラム４１ｃのダウンロード要求があったか否かを判断する。ここでダウンロードの要求があったと判断した場合（Ｓ２３０：ＹＥＳ）、Ｓ２４０にて検査診断プログラム４１ｃを送信し、その後、Ｓ２５０へ移行する。一方、ダウンロード要求がないと判断した場合（Ｓ２３０：ＮＯ）、Ｓ２４０の処理を実行せず、Ｓ２５０へ移行する。
【００５６】
Ｓ２５０では、故障情報が送信されたか否かを判断する。この処理は、図３中のＳ１９０に対応するものであり、車両マネージャＥＣＵ３０は、故障箇所が特定されると（図３中のＳ１８０：ＹＥＳ）、その故障箇所に関する故障情報を送信してくる。ここで故障情報が送信されたと判断した場合（Ｓ２５０：ＹＥＳ）、Ｓ２６０へ移行する。一方、故障情報が送信されない場合（Ｓ２５０：ＮＯ）、以降の処理を実行せず、本サーバ側処理を終了する。
【００５７】
故障情報が送信された場合に移行するＳ２６０では、故障情報をデータベース４１に記憶する。これが、図２中に示す故障情報４１ｄに相当する。そして続くＳ１７０にて故障情報に基づく通知を行い、その後、本サーバ側処理を終了する。故障情報に基づく通知は、顧客情報４１ａ中の連絡先情報で特定される連絡先へなされる。例えばその顧客が普段から修理を依頼する特定の修理工場が連絡先情報で指定されている場合、この修理工場への連絡を行うという具合である。通知内容は、例えば特定された故障箇所の交換パーツを指示するものであるという具合である。
【００５８】
また、車両マネージャＥＣＵ３０における故障診断処理に対応して実行されるＥＣＵ１１〜１９における処理が、図５のフローチャートに示すＥＣＵ処理である。この処理は、各ＥＣＵ１１〜１９において、所定時間間隔で繰り返し実行される。
【００５９】
処理が開始されるとまず、対応処理の指示があったか否かを判断する（Ｓ３００）。この指示は、車両マネージャＥＣＵ３０による検査診断プログラム４１ｃの実行によって出力される（図３中のＳ１７０）。上述したように、特定制御における内部変数の送信を要求する指示が一例として挙げられる。ここで対応処理の指示があった場合（Ｓ３００：ＹＥＳ）、対応処理プログラムを実行し（Ｓ３１０）、その後、本ＥＣＵ処理を終了する。一方、対応処理の指示がない場合（Ｓ３００：ＮＯ）、Ｓ３１０の処理を実行せず、本ＥＣＵ処理を終了する。対応処理プログラムの実行によって、指示された内部変数などの情報が車両マネージャＥＣＵ３０へ送信される。なお、以上の説明では、特定制御における内部変数の送信指示を例に挙げているが、故障箇所特定に有用な情報の送信指示であればよい。
【００６０】
次に本実施例の故障診断システムが発揮する効果を説明する。
本実施例の故障診断システムでは、車両マネージャＥＣＵ３０が、車両内ネットワーク２１，２２，２３上の各ＥＣＵ１１〜１９のデータを監視して（図３中のＳ１００）、不具合を判断する（Ｓ１１０）。つまり、各ＥＣＵ１１〜１９で実行される故障検出プログラムによる故障検出結果データ、及び、ＥＣＵ１１〜１９間で車両マネージャＥＣＵ３０を介してやり取りされるデータから、不具合を判断するのである。したがって、車両マネージャＥＣＵ３０は、ＥＣＵ１１〜１９における個別の不具合だけでなく、ＥＣＵ１１〜１９の連携動作に係る不具合をも検出できる。そして、不具合に対応した検査診断プログラム４１ｃを取得し（Ｓ１６０）、検査診断プログラムを実行することによって、ＥＣＵ１１〜１９の中の該当するものに対応処理を実行させ、例えば特定制御における内部変数などを送信させることによって故障箇所を特定する（Ｓ１７０）。その結果、迅速に故障箇所が特定できる可能性が高い。
【００６１】
また、本実施例の故障診断システムでは、故障箇所が特定できない場合（Ｓ１８０：ＮＯ）、新たな問い合わせ情報を送信し（Ｓ１２０）、別の検査診断プログラム４１ｃを取得して実行する（Ｓ１６０，Ｓ１７０）。これは、発生する不具合に対して様々な故障要因が考えられるため、複数の検査診断プログラム４１ｃによって、段階的に故障箇所を特定していくことを意味する。例えばＦＴＡ（Fault Tree Analysis ）手法を用いて、複数の検査診断プログラム４１を準備しておくことが考えられる。これによって、各ＥＣＵ１１〜１９間の複雑なデータの受け渡しなどに関連する故障箇所であっても特定できる可能性が高くなり、迅速な故障箇所の特定に寄与できる。
【００６２】
さらにまた、本実施例の故障診断システムでは、車両外部に顧客サーバ４０を設置し、この顧客サーバ４０へ不具合情報を含む問い合わせ情報を送信することにより（図３中のＳ１２０）、顧客サーバ４０から検査診断プログラム４１ｃを取得する（Ｓ１６０）。その結果、個々の車両の記憶容量を削減できることはもちろん、顧客サーバ４０のデータベース４１を頻繁にアップデートすることにより、各車両において、適切な検査診断プログラム４１ｃが使用でき、故障箇所の適切な特定が実現される。
【００６３】
また、顧客サーバ４０には、顧客情報４１ａが記憶されており（図２参照）、顧客情報４１ａ中の故障履歴情報及び車両情報を考慮して、車両マネージャＥＣＵ３０へ送信する検査診断プログラム４１ｃを選択する（図４中のＳ２１０）。したがって、適切な検査診断プログラムを選択できる可能性が高くなり、迅速な故障箇所の特定という効果が際だつことになる。
【００６４】
さらに、顧客情報４１ａには契約加入しているユーザを特定するための特定情報が記憶されており、この特定情報を用いて、車両マネージャＥＣＵ３０との間でデータ通信可能状態を確立する。そのため、契約を取り交わしたユーザ以外の不正なアクセスを防止することができる。一方で、車両マネージャＥＣＵ３０は、検査診断プログラム４１ｃのダウンロードに先立って、顧客サーバとの間で認証手続を実行し（図３中のＳ１４０，図４中のＳ２２０）、顧客サーバ４０の正当性を判断する（図３中のＳ１５０）。これによって、車両マネージャＥＣＵ３０が不適当なプログラムを受信することを防止でき、安全走行に重大な支障を来すような事態を確実に回避できる。
【００６５】
また、本実施例の故障診断システムでは、車両マネージャＥＣＵ３０は故障箇所を特定すると（図３中のＳ１８０：ＹＥＳ）、故障箇所に関する故障情報を、顧客サーバ４０へ送信する（Ｓ１９０）。これに対して顧客サーバ４０は、故障情報が送信されると（図４中のＳ２５０：ＹＥＳ）、故障情報をデータベース４１へ記憶し（Ｓ２６０）、故障情報４１ｄとして蓄積していく（図２参照）。したがって、この故障情報４１ｄを用いることにより、検査診断プログラム４１ｃを作成やアップデータが容易になる。すなわち、検査診断プログラム４１ｃの作成効率の向上が図られる。
【００６６】
加えて、顧客サーバ４０は、故障情報の記憶に留まらず、故障情報に基づく通知を行う（図４中のＳ２７０）。例えば交換が必要なパーツを予めサービス工場へ連絡するという具合である。これによって、利用者が修理のためにサービス工場を訪れた際に迅速な対処が可能となる。
【００６７】
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
（イ）上記実施例では、車両側で実行されるプログラムを顧客サーバ４０から取得することによって、車両側のプログラムを容易にアップデートできることを一つの特徴としている。
【００６８】
このような観点からは、図６に示すように、ＥＣＵ１１〜１９で実行される対応処理プログラムを、顧客サーバ４０のデータベース４１に用意しておき、検査診断プログラム４１ｃと共に、車両マネージャＥＣＵ３０によってダウンロードされるようにしてもよい。そして、対応処理プログラムについては、車両マネージャＥＣＵ３０からＥＣＵ１１〜１９の中の該当するものに送信されるようにする。つまり、ＥＣＵ１１〜１９には、対応処理プログラムのための記憶領域を確保しておけばよいのである。特に図６に示すように、検査診断プログラム４１ｃに対応させて対応処理プログラム４１ｅを用意しておけば、検査診断プログラム４１ｃに合わせた対応処理を実行させることができ、故障箇所特定の幅が広がることになる。
【００６９】
（ロ）また、上記実施例では、不具合を判断した際に、その都度、検査診断プログラム４１ｃをダウンロードしていた。
しかしながら、顧客サーバ４０のデータベース４１に記憶される故障情報４１ｄを統計すれば、発生頻度の高い不具合が特定される可能性もある。したがって、発生頻度が高いと想定される不具合に対応する検査診断プログラム４１ｃを予め顧客サーバ４０から車両マネージャＥＣＵ３０へ送信するような構成を採用してもよい。ダウンロードは、通信コストを抑える意味でも、例えば、ナビＥＣＵ１４の案内機能に用いられる地図データや検索データなどが顧客サーバ４０から送信される構成とし、これらのデータに重畳させてなされるようにすることが考えられる。このように発生頻度が高いと想定される不具合に対応する検査診断プログラム４１ｃを予め取得しておけば、場合によっては不具合の発生時に検査診断プログラム４１ｃを即座に起動でき、故障箇所をさらに迅速に特定できる可能性が高くなる。
【００７０】
（ハ）さらにまた、上記実施例では、故障箇所が特定されないうちは（図３中のＳ１８０：ＮＯ）、繰り返し別の検査診断プログラム４１ｃをダウンロードしている（Ｓ１６０）。ただし、複数の検査診断プログラム４１ｃによっても故障箇所が特定できないことも考えられるため、例えば所定数の検査診断プログラム４１ｃによって故障箇所が特定できない場合、あるいは、段階的に用意された一連の検査診断プログラム４１ｃを用いても故障箇所が特定できない場合には、それまでの情報を顧客サーバ４０へ送信して、技術担当者の判断を仰ぐような構成にしてもよい。
【図面の簡単な説明】
【図１】実施例の故障診断システムの概略構成を示す説明図である。
【図２】顧客サーバのデータベース内の情報を示す説明図である。
【図３】故障診断処理を示すフローチャートである。
【図４】サーバ側処理を示すフローチャートである。
【図５】ＥＣＵ処理を示すフローチャートである。
【図６】別実施例における顧客サーバのデータベース内の情報を示す説明図である。
【符号の説明】
１１…エンジンＥＣＵ
１２…トランスミッションＥＣＵ
１３…ブレーキＥＣＵ
１４…ナビＥＣＵ
１５…オーディオＥＣＵ
１６…ＴＥＬ−ＥＣＵ
１７…メータＥＣＵ
１８…盗難防止ＥＣＵ
１９…エアコンＥＣＵ
２１…制御系ネットワーク
２２…情報系ネットワーク
２３…ボデー系ネットワーク
３０…車両マネージャＥＣＵ
４０…顧客サーバ
４１…データベース
４１ａ…顧客情報
４１ｂ…不具合情報
４１ｃ…検査診断プログラム
４１ｄ…故障情報
４１ｅ…対応処理プログラム
５０…基地局

Claims (16)

1. 車両内ネットワークを介して接続され、制御対象を制御し、相互に連携動作する複数の電子制御装置と、
   前記電子制御装置と前記車両内ネットワークを介して通信し、車両の故障管理を行う車両管理装置とを備えた故障診断システムであって、
   前記車両管理装置は、
   前記車両内ネットワークを介して前記電子制御装置の間でやり取りされるデータに基づき前記連携動作に係る不具合の発生を判断する不具合判断手段と、
   前記不具合判断手段にて前記不具合の発生が判断されると、当該不具合に対応させて予め用意された検査診断プログラムを取得するプログラム取得手段と、
   前記プログラム取得手段にて取得された前記検査診断プログラムを実行することによって、該当する電子制御装置へ対応処理を実行させ、当該対応処理の実行により前記電子制御装置から送信される情報に基づいて前記連携動作に係る故障箇所を特定する故障箇所特定手段と、
   前記故障箇所特定手段による処理結果に基づいて、故障に関する故障情報を出力する情報出力手段とを有していること
   を特徴とする故障診断システム。
2. 請求項１に記載の故障診断システムにおいて、
   前記車両内ネットワークを介して前記電子制御装置の間でやり取りされるデータは、前記車両管理装置を介し前記電子制御装置間でやり取りされるものであること
   を特徴とする故障診断システム。
3. 請求項１又は２に記載の故障診断システムにおいて、
   前記故障箇所特定手段は、前記検査診断プログラムによって前記故障箇所が特定できない場合、前記プログラム取得手段に別の検査診断プログラムを取得させること
   を特徴とする故障診断システム。
4. 請求項１〜３のいずれかに記載の故障診断システムにおいて、
   さらに、車両外部に設置され、前記車両管理装置との間でデータ通信可能なサーバ装置を備え、
   前記サーバ装置は、前記検査診断プログラムを記憶した記憶手段を有し、
   前記車両管理装置の前記プログラム取得手段は、前記サーバ装置から前記検査プログラムを取得すること
   を特徴とする故障診断システム。
5. 請求項４に記載の故障診断システムにおいて、
   前記車両管理装置のプログラム取得手段は、前記不具合を示す不具合情報を含む問い合わせ情報を前記サーバ装置へ送信し、
   前記サーバ装置は、
   前記記憶手段に、前記不具合情報に対応させて前記検査診断プログラムを記憶しており、
   前記プログラム取得手段から問い合わせ情報が送信されると、前記記憶手段に記憶された前記検査診断プログラムを前記不具合情報に基づいて検索し、該当する検査診断プログラムを前記車両管理装置へ送信すること
   を特徴とする故障診断システム。
6. 請求項５に記載の故障診断システムにおいて、
   前記サーバ装置は、
   前記記憶手段に、さらに、ユーザ毎に用意される顧客情報を記憶しており、
   前記プログラム取得手段からの問い合わせ情報が送信されると、前記顧客情報を考慮して、該当する検査診断プログラムを前記車両管理装置へ送信すること
   を特徴とする故障診断システム。
7. 請求項４〜６のいずれかに記載の故障診断システムにおいて、
   前記車両管理装置のプログラム取得手段は、前記サーバ装置からの検査診断プログラムの受信に先立って、前記サーバ装置が正当なものであるか否かを判定する認証処理を実行すること
   を特徴とする故障診断システム。
8. 請求項４〜７のいずれかに記載の故障診断システムにおいて、
   前記車両管理装置のプログラム取得手段は、前記電子制御装置における前記対応処理のための対応処理プログラムを、前記サーバ装置から取得して前記電子制御装置へ送信し、
   前記電子制御装置は、前記車両管理装置から送信された前記対応処理プログラムを記憶すること
   を特徴とする故障診断システム。
9. 請求項４〜８のいずれかに記載の故障診断システムにおいて、
   前記車両管理装置の前記情報出力手段は、前記故障箇所特定手段による処理結果に基づき、前記サーバ装置へ前記故障情報を送信し、
   前記サーバ装置は、前記故障情報を、前記記憶手段に記憶すること
   を特徴とする故障診断システム。
10. 請求項９に記載の故障診断システムにおいて、
    前記サーバ装置は、前記故障情報に基づいて外部への通知を行うこと
    を特徴とする故障診断システム。
11. 請求項４〜１０のいずれかに記載の故障診断システムにおいて、
    前記プログラム取得手段は、前記検査診断プログラムを予め取得可能であること
    を特徴とする故障診断システム。
12. 請求項１１に記載の故障診断システムにおいて、
    前記サーバ装置から前記検査診断プログラム以外の別データが車両へ送信されることを前提として、
    前記プログラム取得手段は、前記別データ送信の際に前記検査診断プログラムを取得すること
    を特徴とする故障診断システム。
13. 車両内ネットワークを介して接続され、制御対象を制御し、相互に連携動作する複数の電子制御装置とともに用いられ、
    前記電子制御装置と前記車両内ネットワークを介して通信し、車両の故障管理を行う車両管理装置であって、
    前記車両内ネットワークを介して前記電子制御装置の間でやり取りされるデータに基づき前記連携動作に係る不具合の発生を判断する不具合判断手段と、
    前記不具合判断手段にて前記不具合の発生が判断されると、当該不具合に対応する検査診断プログラムを取得するプログラム取得手段と、
    前記プログラム取得手段にて取得された前記検査診断プログラムを実行することによって、該当する電子制御装置へ対応処理を実行させ、当該対応処理の実行により前記電子制御装置から送信される情報に基づいて前記連携動作に係る故障箇所を特定する故障箇所特定手段とを備えていること
    を特徴とする車両管理装置。
14. 請求項１３に記載の車両管理装置において、さらに、
    前記故障箇所特定手段による処理結果に基づいて、故障に関する故障情報を出力する情報出力手段を備えていること
    を特徴とする車両管理装置。
15. 車両内ネットワークを介して接続され、制御対象を制御し、相互に連携動作する複数の電子制御装置と、前記電子制御装置と前記車両内ネットワークを介して通信し、車両の故障管理を行う車両管理装置とともに故障診断システムを構成するサーバ装置であって、
    前記車両管理装置が、該当する電子制御装置へ対応処理を実行させ、当該対応処理の実行により前記電子制御装置から送信される情報に基づいて故障箇所を特定するための検査診断機能を有することを前提として、
    前記検査診断機能を実現するための検査診断プログラムを、前記連携動作に係る不具合に関する不具合情報に対応させて記憶した記憶手段を備え、
    前記車両管理装置からの前記不具合情報を含む問い合わせ情報が送信されると、前記記憶手段に記憶された前記検査診断プログラムを前記不具合情報に基づいて検索し、該当する検査診断プログラムを前記車両管理装置へ送信すること
    を特徴とするサーバ装置。
16. 車両内ネットワークを介して接続され、制御対象を制御し、相互に連携動作する複数の電子制御装置と、前記電子制御装置と前記車両内ネットワークを介して通信し、車両の故障管理を行う車両管理装置とを備える故障診断システムの前記車両管理装置にて実行されるプログラムであって、
    該当する電子制御装置へ対応処理を実行させ、当該対応処理の実行により前記電子制御装置から送信される情報に基づいて前記連携動作に係る故障箇所を特定するための検査診断プログラム。

Images