JP4622177B2

JP4622177B2 - Failure diagnosis system, vehicle management device, server device, and inspection diagnosis program

Info

Publication number: JP4622177B2
Application number: JP2001206164A
Authority: JP
Inventors: 進秋山
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2001-07-06
Filing date: 2001-07-06
Publication date: 2011-02-02
Anticipated expiration: 2021-07-06
Also published as: JP2003019931A

Description

【０００１】
【発明の属する技術分野】
本発明は、車両の故障診断システムに関する。
【０００２】
【従来の技術】
近年、高性能マイクロプロセッサの出現などエレクトロニクス技術の進歩を背景として、機械技術と電子技術とが結びついたメカトロニクス技術の進歩が著しい。メカトロニクスの進歩の一部として、自動車等の車両にも多くのコンピュータシステムが採用されてきている。このような車載用のコンピュータシステムは、省資源、省エネルギー、走行性能、安全性、快適性等を追求するものであり、車両内のエンジン・駆動系、走行・安全系、エンターテイメント系、及びその他の随所に搭載されている。
【０００３】
このような電子制御装置では、車両各部位の故障検出を的確に行わないと、種々の不具合を引き起こす可能性があり、場合によっては走行不能となることもある。そのため、電子制御装置に車両各部位の故障を検出するための故障検出プログラムを搭載することにより、信頼性の向上が図られている。すなわち、コンピュータ部やセンサ類の動作状態を適当な周期で自動的にチェックし、故障時には、ダイアグコード（ＳＡＥコード等）等を記憶する。
【０００４】
これにより、修理担当者は、電子制御装置に記憶されるダイアグコード等を、専用ツールを接続することによって読み出し、故障箇所を特定することになる。
【０００５】
【発明が解決しようとする課題】
上述した故障検出は、各電子制御装置において個別に故障検出プログラムを実行し、各電子制御装置の単位でなされるのが一般的であった。
しかしながら最近では、車両制御用の電子制御装置は、車両内ネットワークを介して接続され、相互に連携動作を行うようになっている。
【０００６】
そのため電子制御装置間の連携動作に係る不具合が発生する可能性があり、電子制御装置単位で用意される故障検出プログラムによる情報からだけでは故障個所が特定できないといった事態が生じている。
また、不具合を発生させた故障箇所の特定には、連携動作が関連してくることから、電子制御装置内部の専門的な知識を必要とする。したがって、従来のように各電子制御装置に対し専用ツールを接続してダイアグコード等を読み出すという手法では、故障箇所の特定に困難を極める。そのため、修理工場やディーラーへ車両を持ち込んでも、修理までに相当期間を要することがあった。
【０００７】
本発明は、上述した問題点を解決するためになされたものであり、車両内ネットワークを介して接続される複数の電子制御装置の連携動作による不具合を適切に判断し、さらに、迅速な故障箇所の特定を可能にすることを目的とする。
【０００８】
【課題を解決するための手段及び発明の効果】
本発明の故障診断システムは、複数の電子制御装置と、車両管理装置とを備える。
電子制御装置の夫々は、車両内ネットワークを介して接続され、制御対象を制御し、
相互に連携動作する。そして車両管理装置が、車両内ネットワークを介して電子制御装置と通信し、車両の故障管理を行う。この意味で、電子制御装置も車両管理装置も車両内ネットワーク上のコンピュータシステムとして機能する。
【０００９】
本発明では、車両管理装置を車両内ネットワーク上に配置し、ネットワークを介して電子制御装置の間でやり取りされるデータに基づき、不具合判断手段が、連携動作に係る不具合の発生を判断する。例えばここでいう電子制御装置のデータは、車両管理装置を介して電子制御装置間でやり取りされるものとすることができる（請求項２）。この構成は、車両管理装置がいわゆるゲートウェイとして機能し車両内ネットワークに流れるデータを監視する構成を意味する。車両内ネットワークに流れるデータを監視することによって、電子制御装置間の連携動作を監視でき、この連携動作に係る不具合を判断することができる。
【００１０】
プログラム取得手段は、不具合に対応させて予め用意された検査診断プログラムを取得する。そして、故障箇所特定手段が、取得された検査診断プログラムを実行することによって、該当する電子制御装置に対応処理を実行させ、当該対応処理の実行により電子制御装置から送信される情報に基づいて連携動作に係る故障箇所を特定する。つまり、故障個所特定のために、車両管理装置からの指示で、電子制御装置が対応処理を実行するようにし、例えば特定制御における内部変数などを送信させるのである。
【００１１】
そして、情報出力手段は、故障箇所特定手段による処理結果に基づいて、故障に関する故障情報を出力する。これは例えば、警告灯の点灯であってもよいし、ナビゲーション装置を備える構成であれば、いわゆるナビ画面への情報表示であってもよい。故障情報には、故障箇所が特定できた場合の故障箇所を示すものだけでなく、故障箇所が特定できない場合の異常発生を示すものや電子制御装置から送信される内部変数を示す情報なども含まれる。
【００１２】
このように本発明によれば、ネットワークを介して電子制御装置の間でやり取りされるデータに基づき不具合の発生を判断するため、電子制御装置間の連携動作に係る不具合の発生を判断することができる。そして、予め用意された検査診断プログラムを用い、該当する電子制御装置に例えば特定制御における内部変数などを送信させて故障箇所を特定するため、迅速に故障箇所が特定できる可能性が高い。
【００１３】
なお、故障箇所特定手段は、検査診断プログラムによって故障箇所が特定できない場合、プログラム取得手段に別の検査診断プログラムを取得させるようにすることが考えられる（請求項３）。これは、発生する不具合に対して様々な故障要因が考えられるため、複数の検査診断プログラムによって、故障箇所を段階的に特定していくという技術思想である。例えば、検査診断プログラムを階層化して用意しておき、電子制御装置からの内部変数などを考慮して、段階的に用いるという具合である。このようにすれば、電子制御装置間の複雑なデータの受け渡しなどに関連する故障箇所も複数の検査診断プログラムによって特定できる可能性が高くなり、迅速な故障箇所の特定に寄与できる。
【００１４】
ところで、検査診断プログラムは、不具合に応じて予め用意されるものであるが、種々の不具合に対して用意することを考えると、あるいは、階層化して用意することを考えると、車両内に記憶しておくことは現実的でない。
そこで、さらに、車両外部に設置され、車両管理装置との間でデータ通信可能なサーバ装置を備える構成を採用することが望ましい。このとき、サーバ装置は、検査診断プログラムを記憶した記憶手段を有し、車両管理装置のプログラム取得手段は、サーバ装置から検査プログラムを取得する（請求項４）。このようにすれば、個々の車両の記憶容量を削減できることはもちろん、サーバ装置の検査診断プログラムを更新することにより、各車両において、適切な検査診断プログラムが使用できる。
【００１５】
具体的には、車両管理装置のプログラム取得手段が、不具合を示す不具合情報を含む問い合わせ情報をサーバ装置へ送信する構成とし、サーバ装置は、記憶手段に不具合情報に対応させて検査診断プログラムを記憶しており、プログラム取得手段から問い合わせ情報が送信されると、記憶手段に記憶された検査診断プログラムを不具合情報に基づいて検索し、該当する検査診断プログラムを車両管理装置へ送信する構成とすることが考えられる（請求項５）。
【００１６】
このときサーバ装置は、記憶手段に、さらに、ユーザ毎に用意される顧客情報を記憶しておくようにしてもよい。この場合、プログラム取得手段からの問い合わせ情報が送信されると、顧客情報を考慮して、該当する検査診断プログラムを送信する（請求項６）。顧客情報としては、ユーザの使用している車種やグレードを示す車両情報や、その車両の故障履歴情報などが一例として挙げられる。車両情報や故障履歴情報があれば、適切な検査診断プログラムを選択できる可能性が高くなり、結果として、迅速な故障箇所の特定につながる。また、顧客情報にユーザを特定できる特定情報を含めるようにすれば、サービス契約を取り交わしたユーザ以外の不正なアクセスを防止することもできる。
【００１７】
このような不正アクセス防止は、車両側でも重要となる。車両管理装置が不適当なプログラムを受信する事態となれば、安全走行に重大な支障を来すことになるからである。そこで、車両管理装置のプログラム取得手段は、サーバ装置からの検査診断プログラムの受信に先立って、サーバ装置が正当なものであるか否かを判定する認証処理を実行するようにすることが望ましい（請求項７）。
【００１８】
なお、本発明では、上述したように車両側で実行されるプログラムをサーバ装置から取得することによって、車両側のプログラムを容易に追加・変更できることを一つの特徴としている。
このような観点からは、電子制御装置にて実行される対応処理を実現するための対応処理プログラムをも、電子制御装置に予め記憶しておくこと以外に、サーバ装置から取得するように構成してもよい。すなわち、車両管理装置のプログラム取得手段が、電子制御装置における対応処理のための対応処理プログラムを、サーバ装置から取得して電子制御装置へ送信し、電子制御装置が、車両管理装置から送信された対応処理プログラムを記憶する構成としてもよい（請求項８）。この場合、電子制御装置内部に対応処理プログラムを記憶するための記憶領域を確保しておけばよい。これによって、検査診断プログラムに合わせた対応処理を電子制御装置に実行させることができ、故障箇所特定の幅が広がることになる。
【００１９】
ところで、情報出力手段が故障箇所特定手段による処理結果に基づき故障情報を出力することは既に述べたが、このような情報は、検査診断プログラムの変更や新たな検査診断プログラムの作成に利用できる。そこで、車両管理装置の情報出力手段は、故障箇所特定手段による処理結果に基づき、サーバ装置へ故障情報を送信し、サーバ装置は、故障情報を、記憶手段に記憶する構成とすることが考えられる（請求項９）。このようにすれば、各車両で発生した不具合に対する処理結果に基づく故障情報がサーバ装置の記憶手段に保存されることになり、検査診断プログラムの適切な更新や、新たな検査診断プログラムの作成が容易になる。
【００２０】
また、このような故障箇所に関する情報を記憶手段に記憶するだけでなく、サーバ装置は、故障箇所に関する情報に基づき外部への通知を行うようにしてもよい（請求項１０）。外部とは、ユーザ毎に決まってくる連絡先、例えば販売店やサービス工場とすることが考えられる。例えば交換が必要なパーツを予めサービス工場へ連絡するようにしておけば、利用者が修理のためにサービス工場を訪れた際に迅速な対処が可能になる。
【００２１】
さらにまた、故障箇所に関する故障情報がサーバ装置に保存されるようにした場合など、それらの故障情報を統計することによって、必要になる可能性の高い検査診断プログラムが、ある程度特定できる場合が考えられる。そこで、そのような検査診断プログラムを、実際に不具合が発生する前に、車両管理装置に記憶しておいてもよい。
【００２２】
すなわち、プログラム取得手段は、検査診断プログラムを予め取得可能な構成にしてもよい（請求項１１）。例えば、サーバ装置から検査診断プログラム以外の別データが車両へ送信されることを前提として、プログラム取得手段は、当該別データ送信の際に検査診断プログラムを取得することが考えられる（請求項１２）。別データとは、例えばナビゲーション装置を備える場合の地図データや検索データなどが挙げられる。例えば、店舗の検索などをナビゲーション装置にて実行した場合、これに対応する検索データに重畳させて特定の検査診断プログラムを取得するという具合である。
【００２３】
上述の構成によって、例えば他車で発見された最新の不具合等、それまでに収集された故障情報からの総合的な判断結果に基づき、検査診断プログラム群から最適なものを予め取得しておけば、場合によっては不具合の発生時に検査診断プログラムを即座に起動でき、故障箇所をさらに迅速に特定できる可能性が高くなる。
【００２４】
以上は故障管理システムの発明として説明してきたが、このような故障管理システムを構成する車両管理装置の発明として実現することもできる（請求項１３，１４）。この車両管理装置による作用及び効果は、上述した故障診断システムにおける車両管理装置の作用及び効果と同様であるため、説明は省略する。
【００２５】
このような車両管理装置においても、故障箇所特定手段が、検査診断プログラムによって故障箇所が特定できない場合、プログラム取得手段に別の検査診断プログラムを取得させるように構成することが考えられる。
また、サーバ装置を備える構成を前提として、プログラム取得手段は以下のように構成できる。
【００２６】
すなわち、例えば不具合情報を含む問い合わせ情報をサーバ装置へ送信することにより、サーバ装置から検査プログラムを取得するように構成できる。また、サーバ装置からの検査診断プログラムの受信に先立って、サーバ装置が正当なものであるか否かを判定する認証処理を実行するようにしてもよい。さらにまた、検査診断プログラムに限らず、電子制御装置における対応処理のための対応処理プログラムを、サーバ装置から取得して電子制御装置へ送信する構成とすることも考えられる。また、他車で発見された最新の不具合等、それまでに収集された故障情報からの総合的な判断結果に基づき、検査診断プログラム群から最適な検査診断プログラムを、例えば別データの受信の際に、サーバ装置から予め取得するようにしてもよい。
【００２７】
さらに、情報出力手段について言えば、故障箇所特定手段による処理結果に基づき、サーバ装置へ故障情報を送信するように構成してもよい。
ところで、上述した故障管理システムを構成するサーバ装置の発明として実現することもできる（請求項１５）。このサーバ装置による作用及び効果は、上述した故障診断システムにおけるサーバ装置の作用及び効果と同様であるため、説明は省略する。
【００２８】
このサーバ装置においても、記憶手段に、さらに、ユーザ毎に用意される顧客情報を記憶しておき、車両管理装置から問い合わせ情報が送信されると、顧客情報を考慮して、該当する検査診断プログラムを送信するようにしてもよい。また、記憶手段には、電子制御装置にて実行される対応処理を実現するための対応処理プログラムを記憶しておくことも考えられる。
【００２９】
さらに、車両管理装置が故障情報を送信する構成では、当該故障情報を記憶手段に記憶するようにすることが考えられる。また、当該故障情報に基づき外部への通知を行うようにしてもよい。
なお、本発明では、電子制御装置に対応処理を実行させ、当該対応処理によって電子制御装置から送信される情報に基づき故障箇所を特定する検査診断プログラムに特徴がある。この意味で、検査診断プログラムの発明として実現することもできる（請求項１６）。
【００３０】
【発明の実施の形態】
以下、本発明を具体化した一実施例を図面を参照して説明する。
図１は、実施例の故障診断システムの概略構成を示す説明図である。
本実施例の故障診断システムは、車両に搭載されるコンピュータシステムと、車両外に設置される「サーバ装置」としての顧客サーバ４０とを備えている。
【００３１】
車両に搭載されるコンピュータシステムは、「電子制御装置」としてのエンジンＥＣＵ１１、トランスミッションＥＣＵ１２、ブレーキＥＣＵ１３、ナビＥＣＵ１４、オーディオＥＣＵ１５、ＴＥＬ−ＥＣＵ１６、メータＥＣＵ１７、盗難防止ＥＣＵ１８、エアコンＥＣＵ１９、及び「車両管理装置」としての車両マネージャＥＣＵ３０である。
【００３２】
車両マネージャＥＣＵ３０は、「車両内ネットワーク」としての制御系ネットワーク２１、情報系ネットワーク２２、及びボデー系ネットワーク２３に接続されており、制御系ネットワーク２１上にエンジンＥＣＵ１１と、トランスミッションＥＣＵ１２と、ブレーキＥＣＵ１３とが配置され、情報系ネットワーク２２上にナビＥＣＵ１４と、オーディオＥＣＵ１５と、ＴＥＬ−ＥＣＵ１６とが配置され、ボデー系ネットワーク２３上にメータＥＣＵ１７と、盗難防止ＥＣＵ１８と、エアコンＥＣＵ１９とが配置されている。
【００３３】
エンジンＥＣＵ１１は、車両エンジンの制御を主として行うものである。具体的には、アクセルセンサ、空燃比センサ、空気量センサなど、各種センサ信号に基づき、インジェクタやスロットルモータなどを制御する。他のＥＣＵ１２〜１９についても簡単にその機能の一例を説明すると、トランスミッションＥＣＵは、オートマチックトランスミッションのシフトチェンジに関する機能を有し、ブレーキＥＣＵは、ブレーキ油圧の調整機能を有する。また、ナビＥＣＵ１４は、設定されたルートに基づく案内機能、オーディオＥＣＵ１５はＣＤなどの再生機能、ＴＥＬ−ＥＣＵ１６は、ハンドフリーの携帯電話機における発信／着信機能を有する。さらに、メータＥＣＵ１７はメータ表示機能、盗難防止ＥＣＵ１８は例えば車両停車時の振動などに基づく緊急通報機能、エアコンＥＣＵ１９は設定室温となるような送風温や送風量の調節機能を有する。
【００３４】
このように各ＥＣＵ１１〜１９は、それぞれの制御対象を制御するのであるが、必要に応じて連携して動作する。例えばメータＥＣＵ１７による表示情報としての車速などは、エンジンＥＣＵ１１から車両マネージャＥＣＵ３０を介して送信されるという具合である。この意味で車両マネージャＥＣＵ３０は、従来のいわゆるゲートウェイＥＣＵとしての機能を備えている。また、各ＥＣＵ１１〜１９は、それぞれの制御対象の制御において各部位の故障を検出する故障検出プログラムを実行し、故障検出プログラムによる故障検出結果は、車両マネージャＥＣＵ３０へ送信される。そして特に、本実施例では、車両マネージャＥＣＵ３０から例えば特定制御における内部変数などの送信指示がなされると、予め搭載されている対応処理プログラムを実行することにより、指示された情報を車両マネージャＥＣＵ３０へ出力する。この対応処理プログラムの実行判断を行うＥＣＵ処理については後述する。
【００３５】
一方、顧客サーバ４０は、車両外部に設置され、情報通信網に接続されることにより無線の基地局５０を介して、車両マネージャＥＣＵ３０とデータ通信可能に構成されている。顧客サーバ４０も、いわゆるコンピュータシステムとして構成されている。そして、「記憶手段」としてのデータベース４１を備えている。
【００３６】
このデータベース４１には、図２に示すように、本実施例の故障診断システムによるサービスに契約加入している顧客毎に用意される顧客情報４１ａ、車両で発生する不具合を類型化した不具合情報４１ｂ、車両マネージャＥＣＵ３０にて実行される検査診断プログラム４１ｃ、そして、検査診断プログラム４１ｃによる処理結果に基づいて車両マネージャＥＣＵ３０から送信される故障情報４１ｄが記憶される。このとき、検査診断プログラム４１ｃは、不具合情報４１ｂに対応させて用意されている。図２中では、不具合情報４１ｂと検査診断プログラム４１ｃとをセットにして示した。
【００３７】
顧客情報４１ａには、顧客サーバ４０にアクセスしたユーザを特定するための特定情報、過去の故障に関する故障履歴情報、車種やグレードを示す車両情報、及び故障時における連絡先情報が記憶されているものとする。特定情報は、例えばユーザＩＤとパスワードから構成することが考えられる。また、連絡先情報には、電話番号やＦＡＸ番号を用いることが考えられる。
【００３８】
不具合情報４１ｂは、車両の不具合症状を類型化したものであり、車両マネージャＥＣＵ３０から送信される問い合わせ情報中の不具合情報から、対応する検査診断プログラム４１ｃを検索するためのキーとなる。
検査診断プログラム４１ｃは、車両マネージャＥＣＵ３０がダウンロードして実行するものであり、ＥＣＵ１１〜１９の中の該当するものに対応処理を実行させ、対応処理によって送信される情報に基づいて故障箇所を特定するためのプログラムである。
【００３９】
そして、故障情報４１ｄは、車両マネージャＥＣＵ３０にて故障箇所が特定された場合に送信される情報であり、検査診断プログラム４１ｃの作成に有効であるため、顧客サーバ４０のデータベース４１に記憶される。
次に、本実施例の故障診断システムの動作を説明する。
【００４０】
ここでは最初に、車両マネージャＥＣＵ３０の動作を説明し、これに対応する顧客サーバ４０及び各ＥＣＵ１１〜１９の処理を次に説明する。
図３は、車両マネージャＥＣＵ３０にて実行される故障診断処理を示すフローチャートである。この処理は、所定時間間隔で繰り返し実行されるものである。
【００４１】
まず最初のステップ（以下、ステップを単に記号Ｓで示す。）１００において、車両内ネットワーク２１，２２，２３上の各ＥＣＵ１１〜１９のデータを監視する。ここでいうデータは、各ＥＣＵ１１〜１９で実行される故障検出プログラムによる故障検出結果データ、及び、ＥＣＵ１１〜１９間で車両マネージャＥＣＵ３０を介してやり取りされるデータである。すなわち、車両マネージャＥＣＵ３０は、これらのデータを監視することによって、ＥＣＵ１１〜１９における個別の不具合だけでなく、ＥＣＵ１１〜１９の連携動作に係る不具合をも検出する。例えば、ナビＥＣＵ１４からは上り坂であることを示すデータが出力されているにもかかわらず、エンジンＥＣＵ１１のデータからエンジン負荷が全く変化していないような場合を、一つの異常パターンとして監視する。
【００４２】
このデータ監視結果に基づき、続くＳ１１０では、車両の不具合を判断する。ここで不具合が判断された場合（Ｓ１１０：ＹＥＳ）、Ｓ１２０へ移行する。一方、不具合が判断されない場合（Ｓ１１０：ＮＯ）、以降の処理を実行せず、本故障診断処理を終了する。
【００４３】
Ｓ１２０では、顧客サーバ４０との間にデータ通信可能状態を確立し、問い合わせ情報を送信する。データ通信状態の確立は、例えば、車両マネージャＥＣＵ３０が顧客サーバ４０を発呼して例えばユーザＩＤとパスワードとを送信し、顧客サーバ４０が上述した顧客情報４１ａ中の特定情報を用いて契約加入しているユーザであるか否かを判断する、といった所定手続きを経てなされる。このようにしてデータ通信可能状態が確立されると、次に、問い合わせ情報を送信する。問い合わせ情報には、判断した不具合を示す不具合情報が含まれる。
【００４４】
これに対して顧客サーバ４０では、問い合わせ情報に含まれる不具合情報とデータベース４１中の不具合情報４１ｂとを比較し、さらに、顧客情報４１ａ中の故障履歴情報及び車両情報を考慮して、該当する検査診断プログラム４１ｃを選択する。
【００４５】
したがって、続くＳ１３０では、検査診断プログラムが選択されたか否かを判断する。この判断は、顧客サーバ４０からの選択完了の通知に基づいて行われる。ここで検査診断プログラムが選択されたと判断された場合（Ｓ１３０：ＹＥＳ）、Ｓ１４０へ移行する。一方、検査診断プログラム４１ｃが選択されないうちは（Ｓ１３０：ＮＯ）、この判断処理を繰り返す。
【００４６】
Ｓ１４０では、認証手続を行う。この認証手続は、車両側の安全のためのものであり、不当なプログラムの受信を確実に防止する趣旨である。具体的には、ＥＣＵ内のデータをツールで書き換える場合に従来より用いられているような関数を用いた認証を行うことが考えられる。例えば、一方の装置から乱数ｒなどの関数値ｆ（ｒ）を送信し、他方の装置が、この関数値ｆ（ｒ）に基づく関数値Ｆ（ｆ（ｒ））を返信するようにする。そして、一方の装置は、関数値Ｆ（ｆ（ｒ））＝ｒと判断すれば、すなわち関数Ｆ＝ｆ^-1であれば、他方の装置を正当な装置と判断するという具合である。
【００４７】
このような認証手続（Ｓ１４０）により顧客サーバ４０が正当であると判断された場合（Ｓ１５０：ＹＥＳ）、Ｓ１６０へ移行する。一方、正当でないと判断された場合（Ｓ１５０：ＮＯ）、以降の処理を実行せず、本故障診断処理を終了する。
【００４８】
Ｓ１６０では、検査診断プログラム４１ｃのダウンロードを行う。ここでは顧客サーバ４０に対してダウンロードを要求し、顧客サーバ４０から送信される検査診断プログラム４１ｃを受信する。
続くＳ１７０では、ダウンロードした検査診断プログラム４１ｃを実行する。これによって、ＥＣＵ１１〜１９の中の該当するものだけが対応処理を実行し、対応処理によって、例えば特定制御における内部変数などの情報を送信してくる。その結果、検査診断プログラム４１ｃでは、さらに、送信される情報に基づいて故障箇所の特定を行う。
【００４９】
したがって次のＳ１８０では、故障箇所が特定されたか否かを判断する。ここで故障箇所が特定された場合（Ｓ１８０：ＹＥＳ）、Ｓ１９０へ移行する。一方、故障箇所が特定されない場合（Ｓ１８０：ＮＯ）、Ｓ１２０からの処理を繰り返す。つまり、ここで否定判断されると、新たな問い合わせ情報が送信されることになり（Ｓ１２０）、別の検査診断プログラムが選択され（Ｓ１３０：ＹＥＳ）、ダウンロードされて実行される（Ｓ１６０，Ｓ１７０）。
【００５０】
Ｓ１９０では、特定した故障箇所に関する故障情報を顧客サーバ４０へ送信するとともに、故障に関する情報表示を行う。その後、本故障診断処理を終了する。故障に関する情報表示は、例えばメータＥＣＵ１７への情報出力により警告灯の点灯という形で行うことが考えられる。また例えばナビＥＣＵ１４への情報出力により、案内機能の実現に用いられるナビ画面への情報表示という形式で行ってもよい。後者の場合、例えば「○○の交換が必要です」というような故障箇所を指摘する表示であってもよいし、「修理を依頼して下さい」というような抽象的な内容表示であってもよい。これらの表示内容は、顧客の要望に応じて設定変更できるようにすると便利である。
【００５１】
このような車両マネージャＥＣＵ３０における故障診断処理に対応して実行される顧客サーバ４０における処理が、図４のフローチャートに示すサーバ側処理である。この処理は、上述したような所定手順を経て車両マネージャＥＣＵ３０との間にデータ通信可能状態が確立されると、所定時間間隔で繰り返し実行される。
【００５２】
まず最初のＳ２００において、車両マネージャＥＣＵからの問い合わせ情報が送信されたか否かを判断する。この処理は、図３中のＳ１２０に対応するものである。ここで問い合わせ情報が送信された場合（Ｓ２００：ＹＥＳ）、Ｓ２１０へ移行する。一方、問い合わせ情報が送信されない場合（Ｓ２００：ＮＯ）、Ｓ２５０へ移行する。
【００５３】
Ｓ２１０では、データベース４１中の検査診断プログラム４１ｃを、不具合情報４１ｂをキーにして検索する。またこのとき、上述したように、顧客情報４１ａ中の故障履歴情報及び車両情報も考慮する。そして、該当する検査診断プログラム４１ｃを選択する。この検査診断プログラム４１ｃの選択完了通知により、車両マネージャＥＣＵ３０は認証手続を実行する（図３中のＳ１４０）。
【００５４】
したがって、これに対応してＳ２２０では、車両マネージャＥＣＵ３０との間で認証手続を実行する。
認証手続の実行により、車両マネージャＥＣＵ３０は、顧客サーバ４０が正当であるとの判断を行うと（図３中のＳ１５０：ＹＥＳ）、検査診断プログラム４１ｃのダウンロードを要求してくる（Ｓ１６０）。
【００５５】
そこで続くＳ２３０では、検査診断プログラム４１ｃのダウンロード要求があったか否かを判断する。ここでダウンロードの要求があったと判断した場合（Ｓ２３０：ＹＥＳ）、Ｓ２４０にて検査診断プログラム４１ｃを送信し、その後、Ｓ２５０へ移行する。一方、ダウンロード要求がないと判断した場合（Ｓ２３０：ＮＯ）、Ｓ２４０の処理を実行せず、Ｓ２５０へ移行する。
【００５６】
Ｓ２５０では、故障情報が送信されたか否かを判断する。この処理は、図３中のＳ１９０に対応するものであり、車両マネージャＥＣＵ３０は、故障箇所が特定されると（図３中のＳ１８０：ＹＥＳ）、その故障箇所に関する故障情報を送信してくる。ここで故障情報が送信されたと判断した場合（Ｓ２５０：ＹＥＳ）、Ｓ２６０へ移行する。一方、故障情報が送信されない場合（Ｓ２５０：ＮＯ）、以降の処理を実行せず、本サーバ側処理を終了する。
【００５７】
故障情報が送信された場合に移行するＳ２６０では、故障情報をデータベース４１に記憶する。これが、図２中に示す故障情報４１ｄに相当する。そして続くＳ１７０にて故障情報に基づく通知を行い、その後、本サーバ側処理を終了する。故障情報に基づく通知は、顧客情報４１ａ中の連絡先情報で特定される連絡先へなされる。例えばその顧客が普段から修理を依頼する特定の修理工場が連絡先情報で指定されている場合、この修理工場への連絡を行うという具合である。通知内容は、例えば特定された故障箇所の交換パーツを指示するものであるという具合である。
【００５８】
また、車両マネージャＥＣＵ３０における故障診断処理に対応して実行されるＥＣＵ１１〜１９における処理が、図５のフローチャートに示すＥＣＵ処理である。この処理は、各ＥＣＵ１１〜１９において、所定時間間隔で繰り返し実行される。
【００５９】
処理が開始されるとまず、対応処理の指示があったか否かを判断する（Ｓ３００）。この指示は、車両マネージャＥＣＵ３０による検査診断プログラム４１ｃの実行によって出力される（図３中のＳ１７０）。上述したように、特定制御における内部変数の送信を要求する指示が一例として挙げられる。ここで対応処理の指示があった場合（Ｓ３００：ＹＥＳ）、対応処理プログラムを実行し（Ｓ３１０）、その後、本ＥＣＵ処理を終了する。一方、対応処理の指示がない場合（Ｓ３００：ＮＯ）、Ｓ３１０の処理を実行せず、本ＥＣＵ処理を終了する。対応処理プログラムの実行によって、指示された内部変数などの情報が車両マネージャＥＣＵ３０へ送信される。なお、以上の説明では、特定制御における内部変数の送信指示を例に挙げているが、故障箇所特定に有用な情報の送信指示であればよい。
【００６０】
次に本実施例の故障診断システムが発揮する効果を説明する。
本実施例の故障診断システムでは、車両マネージャＥＣＵ３０が、車両内ネットワーク２１，２２，２３上の各ＥＣＵ１１〜１９のデータを監視して（図３中のＳ１００）、不具合を判断する（Ｓ１１０）。つまり、各ＥＣＵ１１〜１９で実行される故障検出プログラムによる故障検出結果データ、及び、ＥＣＵ１１〜１９間で車両マネージャＥＣＵ３０を介してやり取りされるデータから、不具合を判断するのである。したがって、車両マネージャＥＣＵ３０は、ＥＣＵ１１〜１９における個別の不具合だけでなく、ＥＣＵ１１〜１９の連携動作に係る不具合をも検出できる。そして、不具合に対応した検査診断プログラム４１ｃを取得し（Ｓ１６０）、検査診断プログラムを実行することによって、ＥＣＵ１１〜１９の中の該当するものに対応処理を実行させ、例えば特定制御における内部変数などを送信させることによって故障箇所を特定する（Ｓ１７０）。その結果、迅速に故障箇所が特定できる可能性が高い。
【００６１】
また、本実施例の故障診断システムでは、故障箇所が特定できない場合（Ｓ１８０：ＮＯ）、新たな問い合わせ情報を送信し（Ｓ１２０）、別の検査診断プログラム４１ｃを取得して実行する（Ｓ１６０，Ｓ１７０）。これは、発生する不具合に対して様々な故障要因が考えられるため、複数の検査診断プログラム４１ｃによって、段階的に故障箇所を特定していくことを意味する。例えばＦＴＡ（Fault Tree Analysis ）手法を用いて、複数の検査診断プログラム４１を準備しておくことが考えられる。これによって、各ＥＣＵ１１〜１９間の複雑なデータの受け渡しなどに関連する故障箇所であっても特定できる可能性が高くなり、迅速な故障箇所の特定に寄与できる。
【００６２】
さらにまた、本実施例の故障診断システムでは、車両外部に顧客サーバ４０を設置し、この顧客サーバ４０へ不具合情報を含む問い合わせ情報を送信することにより（図３中のＳ１２０）、顧客サーバ４０から検査診断プログラム４１ｃを取得する（Ｓ１６０）。その結果、個々の車両の記憶容量を削減できることはもちろん、顧客サーバ４０のデータベース４１を頻繁にアップデートすることにより、各車両において、適切な検査診断プログラム４１ｃが使用でき、故障箇所の適切な特定が実現される。
【００６３】
また、顧客サーバ４０には、顧客情報４１ａが記憶されており（図２参照）、顧客情報４１ａ中の故障履歴情報及び車両情報を考慮して、車両マネージャＥＣＵ３０へ送信する検査診断プログラム４１ｃを選択する（図４中のＳ２１０）。したがって、適切な検査診断プログラムを選択できる可能性が高くなり、迅速な故障箇所の特定という効果が際だつことになる。
【００６４】
さらに、顧客情報４１ａには契約加入しているユーザを特定するための特定情報が記憶されており、この特定情報を用いて、車両マネージャＥＣＵ３０との間でデータ通信可能状態を確立する。そのため、契約を取り交わしたユーザ以外の不正なアクセスを防止することができる。一方で、車両マネージャＥＣＵ３０は、検査診断プログラム４１ｃのダウンロードに先立って、顧客サーバとの間で認証手続を実行し（図３中のＳ１４０，図４中のＳ２２０）、顧客サーバ４０の正当性を判断する（図３中のＳ１５０）。これによって、車両マネージャＥＣＵ３０が不適当なプログラムを受信することを防止でき、安全走行に重大な支障を来すような事態を確実に回避できる。
【００６５】
また、本実施例の故障診断システムでは、車両マネージャＥＣＵ３０は故障箇所を特定すると（図３中のＳ１８０：ＹＥＳ）、故障箇所に関する故障情報を、顧客サーバ４０へ送信する（Ｓ１９０）。これに対して顧客サーバ４０は、故障情報が送信されると（図４中のＳ２５０：ＹＥＳ）、故障情報をデータベース４１へ記憶し（Ｓ２６０）、故障情報４１ｄとして蓄積していく（図２参照）。したがって、この故障情報４１ｄを用いることにより、検査診断プログラム４１ｃを作成やアップデータが容易になる。すなわち、検査診断プログラム４１ｃの作成効率の向上が図られる。
【００６６】
加えて、顧客サーバ４０は、故障情報の記憶に留まらず、故障情報に基づく通知を行う（図４中のＳ２７０）。例えば交換が必要なパーツを予めサービス工場へ連絡するという具合である。これによって、利用者が修理のためにサービス工場を訪れた際に迅速な対処が可能となる。
【００６７】
以上、本発明はこのような実施例に何等限定されるものではなく、本発明の主旨を逸脱しない範囲において種々なる形態で実施し得る。
（イ）上記実施例では、車両側で実行されるプログラムを顧客サーバ４０から取得することによって、車両側のプログラムを容易にアップデートできることを一つの特徴としている。
【００６８】
このような観点からは、図６に示すように、ＥＣＵ１１〜１９で実行される対応処理プログラムを、顧客サーバ４０のデータベース４１に用意しておき、検査診断プログラム４１ｃと共に、車両マネージャＥＣＵ３０によってダウンロードされるようにしてもよい。そして、対応処理プログラムについては、車両マネージャＥＣＵ３０からＥＣＵ１１〜１９の中の該当するものに送信されるようにする。つまり、ＥＣＵ１１〜１９には、対応処理プログラムのための記憶領域を確保しておけばよいのである。特に図６に示すように、検査診断プログラム４１ｃに対応させて対応処理プログラム４１ｅを用意しておけば、検査診断プログラム４１ｃに合わせた対応処理を実行させることができ、故障箇所特定の幅が広がることになる。
【００６９】
（ロ）また、上記実施例では、不具合を判断した際に、その都度、検査診断プログラム４１ｃをダウンロードしていた。
しかしながら、顧客サーバ４０のデータベース４１に記憶される故障情報４１ｄを統計すれば、発生頻度の高い不具合が特定される可能性もある。したがって、発生頻度が高いと想定される不具合に対応する検査診断プログラム４１ｃを予め顧客サーバ４０から車両マネージャＥＣＵ３０へ送信するような構成を採用してもよい。ダウンロードは、通信コストを抑える意味でも、例えば、ナビＥＣＵ１４の案内機能に用いられる地図データや検索データなどが顧客サーバ４０から送信される構成とし、これらのデータに重畳させてなされるようにすることが考えられる。このように発生頻度が高いと想定される不具合に対応する検査診断プログラム４１ｃを予め取得しておけば、場合によっては不具合の発生時に検査診断プログラム４１ｃを即座に起動でき、故障箇所をさらに迅速に特定できる可能性が高くなる。
【００７０】
（ハ）さらにまた、上記実施例では、故障箇所が特定されないうちは（図３中のＳ１８０：ＮＯ）、繰り返し別の検査診断プログラム４１ｃをダウンロードしている（Ｓ１６０）。ただし、複数の検査診断プログラム４１ｃによっても故障箇所が特定できないことも考えられるため、例えば所定数の検査診断プログラム４１ｃによって故障箇所が特定できない場合、あるいは、段階的に用意された一連の検査診断プログラム４１ｃを用いても故障箇所が特定できない場合には、それまでの情報を顧客サーバ４０へ送信して、技術担当者の判断を仰ぐような構成にしてもよい。
【図面の簡単な説明】
【図１】実施例の故障診断システムの概略構成を示す説明図である。
【図２】顧客サーバのデータベース内の情報を示す説明図である。
【図３】故障診断処理を示すフローチャートである。
【図４】サーバ側処理を示すフローチャートである。
【図５】ＥＣＵ処理を示すフローチャートである。
【図６】別実施例における顧客サーバのデータベース内の情報を示す説明図である。
【符号の説明】
１１…エンジンＥＣＵ
１２…トランスミッションＥＣＵ
１３…ブレーキＥＣＵ
１４…ナビＥＣＵ
１５…オーディオＥＣＵ
１６…ＴＥＬ−ＥＣＵ
１７…メータＥＣＵ
１８…盗難防止ＥＣＵ
１９…エアコンＥＣＵ
２１…制御系ネットワーク
２２…情報系ネットワーク
２３…ボデー系ネットワーク
３０…車両マネージャＥＣＵ
４０…顧客サーバ
４１…データベース
４１ａ…顧客情報
４１ｂ…不具合情報
４１ｃ…検査診断プログラム
４１ｄ…故障情報
４１ｅ…対応処理プログラム
５０…基地局[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a vehicle fault diagnosis system.
[0002]
[Prior art]
In recent years, mechatronics technology, which combines mechanical technology and electronic technology, has made remarkable progress against the backdrop of advances in electronics technology such as the advent of high-performance microprocessors. As part of the progress of mechatronics, many computer systems have been adopted in vehicles such as automobiles. Such in-vehicle computer systems pursue resource saving, energy saving, driving performance, safety, comfort, etc., such as engine / drive system, driving / safety system, entertainment system, etc. in the vehicle. It is installed everywhere.
[0003]
In such an electronic control device, if failure detection of each part of the vehicle is not performed accurately, various problems may be caused, and in some cases, traveling may become impossible. Therefore, reliability is improved by installing a failure detection program for detecting a failure in each part of the vehicle in the electronic control unit. That is, the operating state of the computer unit and sensors is automatically checked at an appropriate cycle, and when a failure occurs, a diagnosis code (SAE code or the like) is stored.
[0004]
As a result, the repair person reads the diagnostic code stored in the electronic control unit by connecting the dedicated tool, and specifies the failure location.
[0005]
[Problems to be solved by the invention]
The above-described failure detection is generally performed for each electronic control unit by executing a failure detection program individually in each electronic control unit.
However, recently, an electronic control device for vehicle control is connected via an in-vehicle network and performs a cooperative operation with each other.
[0006]
For this reason, there is a possibility that a problem relating to the cooperative operation between the electronic control devices may occur, and there is a situation in which the failure location cannot be identified only from the information by the failure detection program prepared for each electronic control device.
In addition, the identification of the failure location that caused the problem requires specialized knowledge inside the electronic control device because the linked operation is related. Therefore, the conventional method of connecting a dedicated tool to each electronic control device and reading out a diag code or the like makes it extremely difficult to identify a fault location. For this reason, even if the vehicle is brought to a repair shop or dealer, it may take a considerable period of time to repair.
[0007]
The present invention has been made to solve the above-described problems, and appropriately determines a failure caused by a cooperative operation of a plurality of electronic control devices connected via an in-vehicle network. It aims to make it possible to specify.
[0008]
[Means for Solving the Problems and Effects of the Invention]
  The failure diagnosis system of the present invention includes a plurality of electronic control devices and a vehicle management device.
  Electronic control unitEachConnected via the in-vehicle network and controlledControl
Work together. Then, the vehicle management device communicates with the electronic control device via the in-vehicle network and performs vehicle failure management. In this sense, both the electronic control device and the vehicle management device function as a computer system on the in-vehicle network.
[0009]
  In the present invention, the vehicle management device is arranged on the in-vehicle network,Exchanged between electronic control unitsBased on the data, the failure judgment meansRelated cooperationDetermine the occurrence of a defect. For example, the data of the electronic control device here isIt can be exchanged between the electronic control devices via the vehicle management device (claim 2)..This configurationThe vehicle management device functions as a so-called gateway and monitors the data flowing in the in-vehicle network.To completemeans. By monitoring the data flowing in the in-vehicle networkAndThe cooperative operation between the electronic control devices can be monitored, and a problem related to the cooperative operation can be determined.
[0010]
  The program acquisition means acquires an inspection diagnosis program prepared in advance corresponding to the defect. Then, the failure location specifying unit executes the acquired inspection diagnosis program to cause the corresponding electronic control device to execute the corresponding process, and based on the information transmitted from the electronic control device by the execution of the corresponding processRelated cooperationIdentify the fault location. That is, in order to identify the fault location, the electronic control device executes a corresponding process in response to an instruction from the vehicle management device, and transmits, for example, an internal variable in the specific control.
[0011]
Then, the information output means outputs failure information related to the failure based on the processing result by the failure location specifying means. This may be, for example, lighting of a warning light, or information display on a so-called navigation screen as long as it has a navigation device. The failure information includes not only information indicating the failure location when the failure location can be identified, but also information indicating the occurrence of an abnormality when the failure location cannot be identified and information indicating internal variables transmitted from the electronic control unit. It is.
[0012]
  Thus, according to the present invention, via a networkExchanged between electronic control unitsOccurrence of defects related to cooperative operation between electronic control units to determine the occurrence of defects based on dataTheI can refuse. And since the failure location is specified by transmitting the internal variable etc. in specific control etc. to the applicable electronic control apparatus using the inspection diagnostic program prepared beforehand, it is highly possible that the failure location can be specified quickly.
[0013]
  In addition, when a failure location cannot be pinpointed by a test diagnostic program, it is possible for a fault location specification means to make a program acquisition means acquire another test diagnostic program (Claim 3). This is a technical idea of identifying a failure location step by step with a plurality of inspection and diagnosis programs because various failure factors can be considered for the failure that occurs. For example, the examination diagnosis program is prepared in a hierarchical manner, and is used step by step in consideration of internal variables from the electronic control unit. In this way, there is a high possibility that a failure location related to the exchange of complex data between the electronic control devices can be specified by a plurality of inspection diagnosis programs, and it is possible to contribute to the rapid specification of the failure location.
[0014]
  By the way, although the inspection diagnosis program is prepared in advance according to the trouble, it is stored in the vehicle in consideration of preparing for various troubles or considering hierarchization. It is not realistic to keep it.
  In view of this, it is desirable to employ a configuration that includes a server device that is installed outside the vehicle and that can perform data communication with the vehicle management device. At this time, the server device has a storage unit that stores the inspection diagnosis program, and the program acquisition unit of the vehicle management device acquires the inspection program from the server device (Claim 4). In this way, not only the storage capacity of each vehicle can be reduced, but also an appropriate inspection diagnosis program can be used in each vehicle by updating the inspection diagnosis program of the server device.
[0015]
  Specifically, the program acquisition unit of the vehicle management apparatus is configured to transmit inquiry information including defect information indicating a defect to the server device, and the server device stores an examination diagnosis program in the storage unit in association with the defect information. When the inquiry information is transmitted from the program acquisition means, the inspection diagnosis program stored in the storage means is searched based on the defect information, and the corresponding inspection diagnosis program is transmitted to the vehicle management device. Can be considered (Claim 5).
[0016]
  At this time, the server device may further store customer information prepared for each user in the storage means. In this case, when the inquiry information from the program acquisition means is transmitted, the corresponding examination diagnosis program is transmitted in consideration of the customer information (Claim 6). Examples of customer information include vehicle information indicating the vehicle type and grade used by the user, failure history information of the vehicle, and the like. If there is vehicle information and failure history information, there is a high possibility that an appropriate inspection / diagnosis program can be selected. As a result, the failure location can be quickly identified. In addition, if specific information that can identify a user is included in the customer information, unauthorized access by users other than those who have signed a service contract can be prevented.
[0017]
  Such unauthorized access prevention is also important on the vehicle side. This is because if the vehicle management device receives an inappropriate program, it will cause a serious obstacle to safe driving. Therefore, it is desirable that the program acquisition means of the vehicle management device execute an authentication process for determining whether or not the server device is valid prior to receiving the inspection diagnosis program from the server device (Claim 7).
[0018]
  As described above, the present invention has one feature that the program on the vehicle side can be easily added / changed by acquiring the program executed on the vehicle side from the server device.
  From such a point of view, the correspondence processing program for realizing the correspondence processing executed by the electronic control device is also obtained from the server device in addition to storing in advance in the electronic control device. May be. That is, the program acquisition unit of the vehicle management device acquires a response processing program for response processing in the electronic control device from the server device and transmits the response processing program to the electronic control device, and the electronic control device is transmitted from the vehicle management device. It is good also as a structure which memorize | stores a corresponding | compatible processing program (Claim 8). In this case, a storage area for storing the corresponding processing program may be secured in the electronic control unit. As a result, it is possible to cause the electronic control device to execute corresponding processing in accordance with the inspection diagnosis program, and the range of failure location identification is expanded.
[0019]
  By the way, although it has already been described that the information output means outputs the failure information based on the processing result by the failure location specifying means, such information can be used for changing the inspection diagnosis program or creating a new inspection diagnosis program. Therefore, it is conceivable that the information output means of the vehicle management device transmits failure information to the server device based on the processing result by the failure location specifying means, and the server device stores the failure information in the storage means. (Claim 9). In this way, the failure information based on the processing result for the failure that has occurred in each vehicle is stored in the storage means of the server device, and appropriate update of the inspection diagnosis program and creation of a new inspection diagnosis program can be performed. It becomes easy.
[0020]
  In addition to storing the information regarding the failure location in the storage unit, the server device may notify the outside based on the information regarding the failure location (Claim 10). The outside may be a contact address determined for each user, for example, a store or a service factory. For example, if a part requiring replacement is notified in advance to the service factory, a quick response can be made when the user visits the service factory for repair.
[0021]
Furthermore, when failure information about the failure location is stored in the server device, it may be possible to identify to some extent inspection diagnostic programs that are likely to be necessary by statistically analyzing the failure information. . Therefore, such an inspection diagnosis program may be stored in the vehicle management apparatus before a problem actually occurs.
[0022]
  That is, the program acquisition unit may be configured to be able to acquire the examination diagnosis program in advance (Claim 11). For example, on the premise that other data other than the inspection diagnosis program is transmitted from the server device to the vehicle, the program acquisition means may acquire the inspection diagnosis program at the time of the separate data transmission (Claim 12). Examples of the different data include map data and search data when a navigation device is provided. For example, when a store search or the like is executed by the navigation device, a specific examination diagnosis program is acquired by superimposing the search data corresponding to the search.
[0023]
With the above configuration, if the most appropriate one is obtained in advance from the inspection diagnosis program group based on the comprehensive judgment result from the failure information collected so far, for example, the latest trouble discovered in other vehicles, etc. In some cases, the inspection / diagnostic program can be started immediately upon occurrence of a malfunction, and the possibility that the failure location can be identified more quickly is increased.
[0024]
  Although the above has been described as an invention of a failure management system, it can also be realized as an invention of a vehicle management device constituting such a failure management system (Claims 13 and 14). thisvehicleThe actions and effects of the management device are the same as those in the above-described failure diagnosis system.vehicleSince it is the same as the operation and effect of the management device, the description is omitted.
[0025]
  like thisvehicleEven in the management apparatus, it is conceivable that the failure location specifying means is configured to cause the program acquisition means to acquire another inspection diagnosis program when the failure location cannot be specified by the inspection diagnosis program.
  Moreover, on the premise of a configuration including a server device, the program acquisition unit can be configured as follows.
[0026]
That is, for example, by transmitting inquiry information including defect information to the server device, the inspection program can be acquired from the server device. Further, prior to receiving the examination diagnosis program from the server device, an authentication process for determining whether or not the server device is valid may be executed. Furthermore, not only the examination diagnosis program but also a configuration in which a response processing program for response processing in the electronic control device is acquired from the server device and transmitted to the electronic control device may be considered. In addition, based on comprehensive judgment results from failure information collected so far, such as the latest defects found in other vehicles, an optimal inspection diagnosis program from the inspection diagnosis program group, for example, when receiving other data Alternatively, it may be acquired in advance from the server device.
[0027]
Further, regarding the information output means, the failure information may be transmitted to the server device based on the processing result by the failure location specifying means.
By the way, it can also be realized as an invention of a server device constituting the above-described failure management system (claim 15). Since the operation and effect of this server device are the same as the operation and effect of the server device in the above-described failure diagnosis system, description thereof is omitted.
[0028]
Also in this server device, the customer information prepared for each user is further stored in the storage means, and when inquiry information is transmitted from the vehicle management device, the corresponding examination diagnosis program in consideration of the customer information May be transmitted. It is also conceivable to store a corresponding processing program for realizing the corresponding processing executed by the electronic control device in the storage means.
[0029]
Furthermore, in the configuration in which the vehicle management device transmits failure information, it is conceivable to store the failure information in a storage unit. Further, notification to the outside may be performed based on the failure information.
Note that the present invention is characterized by an inspection / diagnosis program that causes an electronic control device to execute a corresponding process and identifies a failure location based on information transmitted from the electronic control device through the corresponding process. In this sense, the present invention can also be realized as an invention of an examination diagnosis program (claim 16).
[0030]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is an explanatory diagram illustrating a schematic configuration of a failure diagnosis system according to an embodiment.
The failure diagnosis system of the present embodiment includes a computer system mounted on a vehicle and a customer server 40 as a “server device” installed outside the vehicle.
[0031]
The computer system mounted on the vehicle includes an engine ECU 11, a transmission ECU 12, a brake ECU 13, a navigation ECU 14, an audio ECU 15, a TEL-ECU 16, a meter ECU 17, an anti-theft ECU 18, an air conditioner ECU 19, and a “vehicle management device”. Is a vehicle manager ECU 30.
[0032]
The vehicle manager ECU 30 is connected to a control system network 21 as an “in-vehicle network”, an information system network 22, and a body system network 23. On the control system network 21, an engine ECU 11, a transmission ECU 12, a brake ECU 13, The navigation ECU 14, the audio ECU 15, and the TEL-ECU 16 are disposed on the information system network 22, and the meter ECU 17, the anti-theft ECU 18, and the air conditioner ECU 19 are disposed on the body system network 23.
[0033]
The engine ECU 11 mainly controls the vehicle engine. Specifically, an injector, a throttle motor, and the like are controlled based on various sensor signals such as an accelerator sensor, an air-fuel ratio sensor, and an air amount sensor. An example of the functions of the other ECUs 12 to 19 will be briefly described. The transmission ECU has a function related to a shift change of the automatic transmission, and the brake ECU has a function of adjusting the brake hydraulic pressure. The navigation ECU 14 has a guidance function based on the set route, the audio ECU 15 has a reproduction function such as a CD, and the TEL-ECU 16 has a transmission / reception function in a hands-free mobile phone. Further, the meter ECU 17 has a meter display function, the anti-theft ECU 18 has an emergency notification function based on vibrations when the vehicle is stopped, for example, and the air conditioner ECU 19 has a function of adjusting the air temperature and the air volume so as to reach the set room temperature.
[0034]
Thus, each ECU 11-19 controls each control object, but operates in cooperation as necessary. For example, the vehicle speed as display information by the meter ECU 17 is transmitted from the engine ECU 11 via the vehicle manager ECU 30. In this sense, the vehicle manager ECU 30 has a function as a conventional so-called gateway ECU. Moreover, each ECU11-19 performs the failure detection program which detects the failure of each site | part in control of each control object, and the failure detection result by a failure detection program is transmitted to vehicle manager ECU30. In particular, in this embodiment, when the vehicle manager ECU 30 issues an instruction to transmit, for example, an internal variable in specific control, the instructed information is sent to the vehicle manager ECU 30 by executing a preinstalled processing program. Output. The ECU process for determining the execution of the corresponding process program will be described later.
[0035]
On the other hand, the customer server 40 is installed outside the vehicle and configured to be able to perform data communication with the vehicle manager ECU 30 via the wireless base station 50 by being connected to the information communication network. The customer server 40 is also configured as a so-called computer system. A database 41 is provided as “storage means”.
[0036]
In this database 41, as shown in FIG. 2, customer information 41a prepared for each customer who subscribes to the service by the failure diagnosis system of the present embodiment, defect information 41b that classifies defects occurring in the vehicle. In addition, an inspection diagnosis program 41c executed by the vehicle manager ECU 30 and failure information 41d transmitted from the vehicle manager ECU 30 based on a processing result by the inspection diagnosis program 41c are stored. At this time, the inspection diagnosis program 41c is prepared corresponding to the defect information 41b. In FIG. 2, the defect information 41b and the inspection diagnosis program 41c are shown as a set.
[0037]
The customer information 41a stores identification information for identifying a user who has accessed the customer server 40, failure history information regarding past failures, vehicle information indicating vehicle type and grade, and contact information at the time of failure. And For example, the specific information may be composed of a user ID and a password. Further, it is conceivable to use a telephone number or a FAX number for the contact information.
[0038]
The defect information 41b is a type of vehicle defect symptom and serves as a key for searching the corresponding examination diagnosis program 41c from the defect information in the inquiry information transmitted from the vehicle manager ECU 30.
The inspection diagnosis program 41 c is downloaded and executed by the vehicle manager ECU 30, causes the corresponding one of the ECUs 11 to 19 to execute a corresponding process, and identifies a failure location based on information transmitted by the corresponding process. It is a program for.
[0039]
The failure information 41d is information that is transmitted when a failure location is specified by the vehicle manager ECU 30, and is effective in creating the inspection diagnosis program 41c. Therefore, the failure information 41d is stored in the database 41 of the customer server 40.
Next, the operation of the failure diagnosis system of this embodiment will be described.
[0040]
Here, first, the operation of the vehicle manager ECU 30 will be described, and the processing of the customer server 40 and the ECUs 11 to 19 corresponding thereto will be described next.
FIG. 3 is a flowchart showing a failure diagnosis process executed by the vehicle manager ECU 30. This process is repeatedly executed at predetermined time intervals.
[0041]
First, in the first step (hereinafter, the step is simply indicated by symbol S) 100, data of the ECUs 11 to 19 on the in-vehicle networks 21, 22, and 23 are monitored. The data here is failure detection result data by a failure detection program executed by each of the ECUs 11 to 19 and data exchanged between the ECUs 11 to 19 via the vehicle manager ECU 30. That is, by monitoring these data, the vehicle manager ECU 30 detects not only individual problems in the ECUs 11 to 19 but also problems related to the cooperative operation of the ECUs 11 to 19. For example, a case where the engine load does not change at all from the data of the engine ECU 11 despite the fact that the data indicating the uphill is output from the navigation ECU 14 is monitored as one abnormal pattern.
[0042]
On the basis of the data monitoring result, in the subsequent S110, a malfunction of the vehicle is determined. If a problem is determined here (S110: YES), the process proceeds to S120. On the other hand, when a defect is not determined (S110: NO), the subsequent processing is not executed and the failure diagnosis processing is terminated.
[0043]
In S120, a data communicable state is established with the customer server 40, and inquiry information is transmitted. The data communication state is established, for example, when the vehicle manager ECU 30 calls the customer server 40 and transmits, for example, a user ID and a password, and the customer server 40 subscribes using the specific information in the customer information 41a described above. It is performed through a predetermined procedure such as determining whether or not the user is a user. When the data communicable state is established in this way, next, inquiry information is transmitted. The inquiry information includes defect information indicating the determined defect.
[0044]
On the other hand, the customer server 40 compares the defect information included in the inquiry information with the defect information 41b in the database 41, and further considers the failure history information and the vehicle information in the customer information 41a, and the corresponding inspection. The diagnostic program 41c is selected.
[0045]
Accordingly, in the subsequent S130, it is determined whether or not an examination diagnosis program has been selected. This determination is made based on a notification of selection completion from the customer server 40. If it is determined that the examination diagnosis program has been selected (S130: YES), the process proceeds to S140. On the other hand, as long as the examination diagnosis program 41c is not selected (S130: NO), this determination process is repeated.
[0046]
In S140, an authentication procedure is performed. This authentication procedure is for safety on the vehicle side, and is intended to reliably prevent the reception of an unjust program. Specifically, when data in the ECU is rewritten with a tool, it is conceivable to perform authentication using a function that has been conventionally used. For example, a function value f (r) such as a random number r is transmitted from one device, and the other device returns a function value F (f (r)) based on the function value f (r). If one device determines that the function value F (f (r)) = r, that is, the function F = f^-1If so, the other device is determined to be a valid device.
[0047]
When it is determined that the customer server 40 is valid by such an authentication procedure (S140) (S150: YES), the process proceeds to S160. On the other hand, when it is determined that it is not valid (S150: NO), the subsequent processing is not executed and the failure diagnosis processing is terminated.
[0048]
In S160, the examination diagnosis program 41c is downloaded. Here, the customer server 40 is requested to download, and the examination diagnosis program 41c transmitted from the customer server 40 is received.
In subsequent S170, the downloaded examination diagnosis program 41c is executed. Accordingly, only the corresponding one of the ECUs 11 to 19 executes the corresponding process, and information such as an internal variable in the specific control is transmitted by the corresponding process. As a result, the inspection diagnosis program 41c further specifies a failure location based on the transmitted information.
[0049]
Accordingly, in the next S180, it is determined whether or not a failure location has been identified. If a failure location is specified here (S180: YES), the process proceeds to S190. On the other hand, when a failure location is not specified (S180: NO), the process from S120 is repeated. That is, if a negative determination is made here, new inquiry information is transmitted (S120), another examination diagnosis program is selected (S130: YES), downloaded and executed (S160, S170). .
[0050]
In S190, failure information related to the specified failure location is transmitted to the customer server 40, and information related to the failure is displayed. Thereafter, the failure diagnosis process is terminated. It is conceivable that the information display regarding the failure is performed, for example, by turning on a warning lamp by outputting information to the meter ECU 17. Further, for example, information output to the navigation ECU 14 may be performed in the form of information display on a navigation screen used for realizing the guidance function. In the latter case, for example, the display may indicate a failure location such as “replacement is required” or an abstract content display such as “Request repair”. Good. It is convenient that these display contents can be changed according to the customer's request.
[0051]
The process in the customer server 40 executed in response to the failure diagnosis process in the vehicle manager ECU 30 is a server-side process shown in the flowchart of FIG. This process is repeatedly executed at predetermined time intervals when a data communicable state is established with the vehicle manager ECU 30 through the predetermined procedure as described above.
[0052]
First, in S200, it is determined whether inquiry information from the vehicle manager ECU is transmitted. This process corresponds to S120 in FIG. When inquiry information is transmitted here (S200: YES), it transfers to S210. On the other hand, when inquiry information is not transmitted (S200: NO), it transfers to S250.
[0053]
In S210, the examination diagnosis program 41c in the database 41 is searched using the defect information 41b as a key. At this time, as described above, the failure history information and vehicle information in the customer information 41a are also taken into consideration. Then, the corresponding examination diagnosis program 41c is selected. The vehicle manager ECU 30 executes an authentication procedure based on the selection completion notification of the inspection diagnosis program 41c (S140 in FIG. 3).
[0054]
Accordingly, correspondingly, in S220, an authentication procedure is executed with the vehicle manager ECU 30.
When the vehicle manager ECU 30 determines that the customer server 40 is valid by executing the authentication procedure (S150: YES in FIG. 3), the vehicle manager ECU 30 requests download of the inspection diagnosis program 41c (S160).
[0055]
Accordingly, in S230, it is determined whether or not there is a request for downloading the examination diagnosis program 41c. If it is determined that a download request has been made (S230: YES), the examination diagnosis program 41c is transmitted in S240, and then the process proceeds to S250. On the other hand, if it is determined that there is no download request (S230: NO), the process of S240 is not executed and the process proceeds to S250.
[0056]
In S250, it is determined whether failure information has been transmitted. This process corresponds to S190 in FIG. 3, and when the failure location is specified (S180: YES in FIG. 3), the vehicle manager ECU 30 transmits failure information regarding the failure location. If it is determined that the failure information has been transmitted (S250: YES), the process proceeds to S260. On the other hand, when failure information is not transmitted (S250: NO), the subsequent processing is not executed and the server-side processing is terminated.
[0057]
In S260, which is shifted to when the failure information is transmitted, the failure information is stored in the database 41. This corresponds to the failure information 41d shown in FIG. In subsequent S170, notification based on the failure information is performed, and then the server-side processing is terminated. The notification based on the failure information is made to the contact specified by the contact information in the customer information 41a. For example, when a specific repair shop that the customer usually requests for repair is specified in the contact information, this repair shop is contacted. The notification content indicates, for example, that the replacement part at the specified failure location is indicated.
[0058]
Moreover, the process in ECU11-19 performed corresponding to the failure diagnosis process in vehicle manager ECU30 is ECU process shown to the flowchart of FIG. This process is repeatedly executed at predetermined time intervals in the ECUs 11 to 19.
[0059]
When the process is started, first, it is determined whether or not there is an instruction for the corresponding process (S300). This instruction is output by the execution of the inspection diagnosis program 41c by the vehicle manager ECU 30 (S170 in FIG. 3). As described above, an instruction for requesting transmission of an internal variable in specific control is an example. If there is an instruction for the handling process (S300: YES), the handling process program is executed (S310), and then the ECU process is terminated. On the other hand, when there is no instruction for the corresponding process (S300: NO), the process of S310 is not executed and the ECU process is terminated. By executing the response processing program, information such as the instructed internal variable is transmitted to the vehicle manager ECU 30. In the above description, the transmission instruction for the internal variable in the specific control is taken as an example, but any transmission instruction for information useful for identifying the fault location may be used.
[0060]
Next, the effect which the failure diagnosis system of a present Example exhibits is demonstrated.
In the failure diagnosis system of the present embodiment, the vehicle manager ECU 30 monitors the data of the ECUs 11 to 19 on the in-vehicle networks 21, 22, and 23 (S100 in FIG. 3), and determines a malfunction (S110). That is, the failure is determined from the failure detection result data by the failure detection program executed by each of the ECUs 11 to 19 and the data exchanged between the ECUs 11 to 19 via the vehicle manager ECU 30. Therefore, the vehicle manager ECU 30 can detect not only individual problems in the ECUs 11 to 19 but also problems related to the cooperative operation of the ECUs 11 to 19. Then, the inspection diagnosis program 41c corresponding to the defect is acquired (S160), and the inspection diagnosis program is executed to execute the corresponding processing in the ECUs 11 to 19, for example, internal variables in the specific control. The failure location is specified by transmitting (S170). As a result, there is a high possibility that the failure location can be quickly identified.
[0061]
Further, in the failure diagnosis system of the present embodiment, when the failure location cannot be specified (S180: NO), new inquiry information is transmitted (S120), and another inspection diagnosis program 41c is acquired and executed (S160, S170). ). This means that various failure factors can be considered for the failure that occurs, and therefore the failure location is specified step by step by a plurality of inspection diagnosis programs 41c. For example, it is conceivable to prepare a plurality of examination diagnosis programs 41 using an FTA (Fault Tree Analysis) method. As a result, the possibility of being able to be specified even if it is a failure location related to the exchange of complex data between the ECUs 11 to 19 is increased, and it is possible to contribute to the rapid specification of the failure location.
[0062]
Furthermore, in the failure diagnosis system of the present embodiment, the customer server 40 is installed outside the vehicle, and the inquiry information including the defect information is transmitted to the customer server 40 (S120 in FIG. 3). The inspection diagnosis program 41c is acquired (S160). As a result, not only can the storage capacity of each vehicle be reduced, but the database 41 of the customer server 40 is frequently updated, so that an appropriate inspection and diagnosis program 41c can be used in each vehicle, and the appropriate location of the failure can be specified. Realized.
[0063]
Further, customer information 41a is stored in the customer server 40 (see FIG. 2), and an inspection diagnosis program 41c to be transmitted to the vehicle manager ECU 30 is selected in consideration of failure history information and vehicle information in the customer information 41a. (S210 in FIG. 4). Therefore, there is a high possibility that an appropriate inspection / diagnosis program can be selected, and the effect of promptly identifying a failure location becomes conspicuous.
[0064]
Furthermore, the customer information 41a stores specific information for specifying a user who has subscribed to the contract, and establishes a data communicable state with the vehicle manager ECU 30 using this specific information. Therefore, unauthorized access by users other than those who have signed a contract can be prevented. On the other hand, the vehicle manager ECU 30 executes an authentication procedure with the customer server (S140 in FIG. 3 and S220 in FIG. 4) prior to downloading the inspection diagnosis program 41c, and checks the validity of the customer server 40. Judgment is made (S150 in FIG. 3). Thereby, it is possible to prevent the vehicle manager ECU 30 from receiving an inappropriate program, and it is possible to reliably avoid a situation that causes a serious obstacle to safe driving.
[0065]
Further, in the failure diagnosis system of the present embodiment, when the vehicle manager ECU 30 specifies the failure location (S180: YES in FIG. 3), the failure information regarding the failure location is transmitted to the customer server 40 (S190). On the other hand, when the failure information is transmitted (S250: YES in FIG. 4), the customer server 40 stores the failure information in the database 41 (S260) and accumulates it as failure information 41d (see FIG. 2). ). Therefore, by using the failure information 41d, it is easy to create and update the inspection diagnosis program 41c. That is, the creation efficiency of the examination diagnosis program 41c can be improved.
[0066]
In addition, the customer server 40 does not only store the failure information, but performs notification based on the failure information (S270 in FIG. 4). For example, a part that needs to be replaced is notified in advance to a service factory. This enables a quick response when the user visits a service factory for repair.
[0067]
As described above, the present invention is not limited to such embodiments, and can be implemented in various forms without departing from the spirit of the present invention.
(A) The above embodiment is characterized in that the program on the vehicle side can be easily updated by acquiring the program executed on the vehicle side from the customer server 40.
[0068]
From this point of view, as shown in FIG. 6, correspondence processing programs executed by the ECUs 11 to 19 are prepared in the database 41 of the customer server 40 and downloaded together with the inspection diagnosis program 41 c by the vehicle manager ECU 30. You may make it do. The response processing program is transmitted from the vehicle manager ECU 30 to the corresponding one of the ECUs 11 to 19. That is, the ECUs 11 to 19 need only have a storage area for the corresponding processing program. In particular, as shown in FIG. 6, if a response processing program 41e is prepared in correspondence with the inspection diagnosis program 41c, the corresponding processing according to the inspection diagnosis program 41c can be executed, and the range of failure location identification is expanded. It will be.
[0069]
(B) In the above embodiment, the inspection diagnostic program 41c is downloaded each time a failure is determined.
However, if the failure information 41d stored in the database 41 of the customer server 40 is statistics, there is a possibility that a failure with a high occurrence frequency is specified. Therefore, you may employ | adopt the structure which transmits the test | inspection diagnostic program 41c corresponding to the malfunction assumed that generation | occurrence | production frequency is high from the customer server 40 to vehicle manager ECU30 previously. For the purpose of reducing the communication cost, the download is configured such that, for example, map data or search data used for the guidance function of the navigation ECU 14 is transmitted from the customer server 40 and superimposed on these data. Can be considered. If the examination diagnosis program 41c corresponding to the trouble that is assumed to occur frequently is acquired in advance, the examination diagnosis program 41c can be started immediately when the trouble occurs in some cases, and the failure location can be further quickly detected. The possibility that it can be identified increases.
[0070]
(C) Furthermore, in the above-described embodiment, while the failure location is not specified (S180: NO in FIG. 3), another inspection diagnosis program 41c is repeatedly downloaded (S160). However, since it is possible that the failure location cannot be specified by the plurality of test diagnosis programs 41c, for example, when the failure location cannot be specified by a predetermined number of test diagnosis programs 41c, or a series of test diagnosis programs prepared in stages. If a fault location cannot be identified using 41c, the information up to that point may be transmitted to the customer server 40 to ask for the judgment of a technician.
[Brief description of the drawings]
FIG. 1 is an explanatory diagram showing a schematic configuration of a failure diagnosis system of an embodiment.
FIG. 2 is an explanatory diagram showing information in a database of a customer server.
FIG. 3 is a flowchart showing a failure diagnosis process.
FIG. 4 is a flowchart showing server-side processing.
FIG. 5 is a flowchart showing an ECU process.
FIG. 6 is an explanatory diagram showing information in a database of a customer server in another embodiment.
[Explanation of symbols]
11 ... Engine ECU
12 ... Transmission ECU
13 ... Brake ECU
14 ... Navi ECU
15 ... Audio ECU
16 ... TEL-ECU
17 ... Meter ECU
18 ... Anti-theft ECU
19 ... Air conditioner ECU
21 ... Control network
22 Information network
23 ... Body network
30 ... Vehicle manager ECU
40 ... customer server
41 ... Database
41a ... Customer information
41b ... Bug information
41c ... Examination diagnosis program
41d ... Failure information
41e ... Corresponding processing program
50 ... Base station

Claims

A plurality of electronic control devices that are connected via an in-vehicle network, control a controlled object, and operate in cooperation with each other ;
A failure diagnosis system comprising a vehicle management device that communicates with the electronic control unit via the in-vehicle network and performs vehicle failure management,
The vehicle management device includes:
Failure determination means for determining occurrence of a failure related to the cooperative operation based on data exchanged between the electronic control units via the in-vehicle network;
When the occurrence of the defect is determined by the defect determination unit, a program acquisition unit that acquires an inspection diagnosis program prepared in advance corresponding to the defect;
By executing the test diagnosis program obtained by the program acquisition unit, to execute the corresponding processing to the corresponding electronic control unit, on the basis of the information transmitted by the execution of the corresponding processing from the electronic control device A failure location specifying means for specifying a failure location related to the cooperative operation ;
Fault diagnosis system, characterized in that on the basis of the processing result by the failure location specification means, and an information output means for outputting failure information related to the failure.

The failure diagnosis system according to claim 1 ,
The data exchanged between the electronic control device via the vehicle network is fault diagnosis system, characterized in that it is intended to be exchanged between the electronic control device via the vehicle management device.

In the fault diagnosis system according to claim 1 or 2 ,
Fault diagnosis system the failure position specifying means, when the failure location by said test diagnostic program can not be identified, characterized in that to get another test diagnostic program in the program acquiring means.

In the failure diagnosis system according to any one of claims 1 to 3 ,
And a server device installed outside the vehicle and capable of data communication with the vehicle management device,
The server device has storage means for storing the examination diagnosis program,
The fault diagnosis system according to claim 1, wherein the program acquisition unit of the vehicle management apparatus acquires the inspection program from the server device.

In the fault diagnosis system according to claim 4 ,
The program acquisition means of the vehicle management device transmits inquiry information including defect information indicating the defect to the server device,
The server device
In the storage means, the examination diagnostic program is stored in correspondence with the defect information,
When inquiry information is transmitted from the program acquisition means, the inspection diagnosis program stored in the storage means is searched based on the defect information, and the corresponding inspection diagnosis program is transmitted to the vehicle management device. Fault diagnosis system.

In the fault diagnosis system according to claim 5 ,
The server device
The storage means further stores customer information prepared for each user,
When the inquiry information from the program acquisition means is transmitted, the inspection diagnosis program is transmitted to the vehicle management device in consideration of the customer information.

In the failure diagnosis system according to any one of claims 4 to 6 ,
The program acquisition means of the vehicle management device executes an authentication process for determining whether or not the server device is valid prior to receiving an inspection diagnosis program from the server device. Diagnostic system.

In the failure diagnosis system according to any one of claims 4 to 7 ,
The program acquisition means of the vehicle management device acquires a response processing program for the response processing in the electronic control device from the server device and transmits the response processing program to the electronic control device.
The electronic control device stores the response processing program transmitted from the vehicle management device.

In the failure diagnosis system according to any one of claims 4 to 8 ,
The information output means of the vehicle management device transmits the failure information to the server device based on a processing result by the failure location specifying means,
The server apparatus stores the failure information in the storage unit.

The failure diagnosis system according to claim 9 ,
The server device performs notification to the outside based on the failure information.

In the failure diagnosis system according to any one of claims 4 to 10 ,
The fault diagnosis system characterized in that the program acquisition means can acquire the inspection diagnosis program in advance.

The fault diagnosis system according to claim 11 ,
Assuming that other data other than the examination diagnosis program is transmitted from the server device to the vehicle,
The fault diagnosis system, wherein the program acquisition means acquires the inspection diagnosis program at the time of the separate data transmission.

Connected via the in-vehicle network, used to control a controlled object, and operate together with multiple electronic control units.
A vehicle management device that communicates with the electronic control unit via the in-vehicle network and performs vehicle failure management,
Failure determination means for determining occurrence of a failure related to the cooperative operation based on data exchanged between the electronic control units via the in-vehicle network;
When the occurrence of the defect is determined by the defect determination unit, a program acquisition unit that acquires an inspection diagnosis program corresponding to the defect;
By executing the test diagnosis program obtained by the program acquisition unit, to execute the corresponding processing to the corresponding electronic control unit, on the basis of the information transmitted by the execution of the corresponding processing from the electronic control device vehicle management apparatus characterized by and a failure place specifying means for specifying a failure point of the cooperative operation.

  The vehicle management device according to claim 13, further comprising:
  It has information output means for outputting failure information related to a failure based on a processing result by the failure location specifying means.
  A vehicle management device.

A plurality of electronic control devices that are connected via an in-vehicle network, control a controlled object, and operate in cooperation with each other, and a vehicle management that communicates with the electronic control device via the in-vehicle network to perform vehicle failure management A server device that constitutes a failure diagnosis system together with the device,
The vehicle management device has an inspection diagnosis function for causing a corresponding electronic control device to execute a corresponding process and identifying a failure location based on information transmitted from the electronic control device by executing the corresponding process. As a premise
A storage means for storing an inspection diagnosis program for realizing the inspection diagnosis function in association with defect information related to the defect related to the cooperative operation ;
When inquiry information including the defect information is transmitted from the vehicle management device, the inspection diagnosis program stored in the storage means is searched based on the defect information, and the vehicle inspection device is searched for the corresponding inspection diagnosis program. The server device characterized by transmitting to.

A plurality of electronic control devices that are connected via an in-vehicle network, control a controlled object, operate in cooperation with each other, and communicate with the electronic control device through the in-vehicle network to manage vehicle failures. A program executed by the vehicle management device of a failure diagnosis system comprising a device,
An inspection diagnosis program for causing a corresponding electronic control device to execute a corresponding process and identifying a failure location related to the cooperative operation based on information transmitted from the electronic control device by executing the corresponding process.