障害診断方法及び障害診断システム
【課題】未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる障害診断システム等を提供する。
【解決手段】障害診断装置５は、障害発生条件となり得る候補条件を決定し、候補条件をセンタＤＢ８に記憶するとともに（ステップＳ２）、依頼候補条件情報を複数の端末装置４に送信する（ステップＳ３）。端末装置４は、依頼候補条件情報に係る候補条件を端末ＤＢ７に記憶し（ステップＳ４）、候補条件のいずれかが成立すると、候補条件が成立した時点における自らの診断対象システム２の障害発生有無を判定し、成立候補条件情報及び障害発生有無情報を障害診断装置５に送信する（ステップＳ５）。障害診断装置５は、端末装置４から受信する障害発生有無情報及び成立候補条件情報に基づいて、センタＤＢ８を更新する（ステップＳ６）。
【解決手段】障害診断装置５は、障害発生条件となり得る候補条件を決定し、候補条件をセンタＤＢ８に記憶するとともに（ステップＳ２）、依頼候補条件情報を複数の端末装置４に送信する（ステップＳ３）。端末装置４は、依頼候補条件情報に係る候補条件を端末ＤＢ７に記憶し（ステップＳ４）、候補条件のいずれかが成立すると、候補条件が成立した時点における自らの診断対象システム２の障害発生有無を判定し、成立候補条件情報及び障害発生有無情報を障害診断装置５に送信する（ステップＳ５）。障害診断装置５は、端末装置４から受信する障害発生有無情報及び成立候補条件情報に基づいて、センタＤＢ８を更新する（ステップＳ６）。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の診断対象システムそれぞれに搭載される複数の端末装置、及び端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システム等に関するものである。
【背景技術】
【０００２】
近年、複数のモジュールが協調動作するシステムにおいて、システムの大規模化に伴い、障害診断が難しくなってきている。協調動作システムの一例としては、車両に搭載される車載システムがある。車載システムでは、複数のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）が、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワークを介して互いにデータの送受信を行い、協調して動作を行っている。その為、あるＥＣＵが故障すると他のＥＣＵにも異常が伝搬してしまい、障害の診断をすることが難しい。
特に、車載システムについては、ハイブリッド車や電気自動車などの登場、つながる技術（インフラ協調、隊列走行などの技術）の発展に伴い、電子制御の複雑化、大規模化が顕著になっている。
【０００３】
そこで、障害診断を支援するシステムの開発が盛んになっている。例えば、特許文献１には、診断対象車両に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断システムが開示されている。特許文献１に記載の遠隔故障診断システムでは、どの実施形態も概ね以下の手順に従って遠隔故障診断処理を実行する。
（１）診断対象の車両又はサービス工場は、故障診断要求又は車両データを遠隔地の故障診断サーバに送信する。
（２）故障診断サーバは、受信した故障診断要求又は車両データに基づき、既知の故障（特許文献１では「所定の故障」と記載）について、故障診断の際に必要なデータの走行条件を決定し、走行条件を診断対象の車両に送信する。
（３）診断対象の車両は、受信した走行条件を満たすまで待機し、走行条件が満たされると、そのときの車両データを故障診断サーバに送信する。
（４）故障診断サーバは、受信した車両データに基づき、故障診断を行い、診断結果を診断対象の車両に送信する。
尚、特許文献１における「走行条件」は、故障か否かの判定に必要なデータを取得するための条件であり、故障の発生の有無には関係ない条件である。また、特許文献１における「故障診断サーバに送信する車両データ」は、故障か否かの判定に必要なデータであり、故障ごとに異なる。
【０００４】
しかしながら、特許文献１に記載の遠隔故障診断システムでは、未知の障害については何ら解決策を提示していない。ここで、「未知の障害」とは、異常の現象（正常ではない現象）の中で、発生条件が特定されていない現象を意味する。
【０００５】
未知の障害としては、仕様の不完全性（想定外の使い方や走行環境に対応する仕様の欠如など）や、テスト環境や車両モデルと現実とのずれ（テスト環境や車両モデルに基づくシミュレーションでは発生しない割込みタイミングなど）など、事前に想定していなかった原因によるものなどが挙げられる。このような現象は、特定の稀な条件が揃った場合にのみ発生し、再現することが難しい。
そこで、本発明者らは、未知の障害についての解決策として、事前に想定していなかった原因による未知の障害が発生した場合であっても、障害発生条件を特定できる障害診断装置等を発明している（特許文献２参照）。特許文献２に記載の障害診断装置では、個々の障害原因に関する事前知識や診断対象のモデルに頼らず、正常時の車両動作データを活用し、障害発生条件の候補を絞り込む。すなわち、正常時の車両動作データにはないパターンを抽出することによって、障害発生条件となり得る信号の値の組み合わせを絞り込む。そして、実際の車両において、障害発生条件となり得る信号の値の組み合わせを揃えることによって、現象を再現する。
尚、特許文献２における「障害発生条件」は、特許文献１における「走行条件」と異なり、正常時に発生しない条件である。また、特許文献２における「障害発生条件となり得る信号の値の組み合わせ」は、特許文献１における「故障診断サーバに送信する車両データ」と異なり、障害の種類によらず同一である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−３０２６７５号公報
【特許文献２】特開２０１０−２１８４９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、正常時の車両動作データは、テスト環境などにおいて事前に網羅的に（抜け漏れなく）収集することは困難である。特に、アクセルやブレーキ等の運転者の操作レベルの変数ではなく、ＥＣＵ同士がやり取りする制御レベルの変数については、正常時の全ての値の組み合わせを事前に揃えておくことは難しい。
そして、正常時の車両動作データが網羅的に収集されていない場合、障害発生条件の候補が数多く残ってしまう為、全ての候補を実際の車両において発生させようとすると、多大な時間と費用がかかってしまう。
【０００８】
また、特許文献１に記載の遠隔故障診断システムでは、診断対象の車両が、発生した現象によって動作不能になっている場合には適用できない。また、未知の障害が発生している場合、診断対象の車両をそのまま走行させておくと、更なる故障や障害が発生する可能性があり、望ましくない。
【０００９】
本発明は、前述した問題点に鑑みてなされたもので、その目的とすることは、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる障害診断システム等を提供することである。
【課題を解決するための手段】
【００１０】
前述した目的を達成するために第１の発明は、複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムにおける障害診断方法であって、前記障害診断装置が、特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定し、前記候補条件を第１記憶領域に記憶する第１ステップと、前記障害診断装置が、前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信する第２ステップと、前記端末装置が、前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に記憶し、前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記候補条件が成立した時点における自らの診断対象システムの障害発生有無を判定し、成立した前記候補条件を示す成立候補条件情報、及び前記障害発生有無を示す障害発生有無情報を前記障害診断装置に送信する第３ステップと、前記障害診断装置が、前記端末装置から受信する前記成立候補条件情報及び前記障害発生有無情報に基づいて、前記第１記憶領域を更新する第４ステップと、を含む障害診断方法である。
第１の発明によって、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる。
【００１１】
第１の発明における前記第４ステップでは、例えば、前記障害診断装置が、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する。
これによって、効率的に障害発生条件の候補を絞り込むことができる。
【００１２】
第１の発明における前記第４ステップでは、例えば、前記障害診断装置が、更に、前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信し、前記端末装置が、前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第５ステップ、を更に含む。
これによって、障害発生条件か否か判定済の候補条件については、収集対象から外すことができる。
【００１３】
第１の発明における前記第１ステップにおける前記動作データは、例えば、前記特定の診断対象システムに搭載されている前記端末装置が、前記特定の診断対象システムの環境を示す環境情報とともに、前記障害診断装置に送信するものであり、前記第２ステップでは、前記障害診断装置が、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する。
これによって、情報収集量を減らさずに、車両１台当たりの情報収集の為の処理負荷を軽減することができる。
【００１４】
第２の発明は、複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムであって、前記障害診断装置は、特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定する候補条件決定手段と、前記候補条件決定手段によって決定される前記候補条件を第１記憶領域に登録する第１記憶領域登録手段と、前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信することによって、情報収集を依頼する依頼手段と、成立した前記候補条件を示す成立候補条件情報、及び前記候補条件が成立した時点における診断対象システムの障害発生有無を示す障害発生有無情報を前記端末装置から受信することによって、情報収集の結果を回収する回収手段と、前記端末装置から受信する前記障害発生有無情報及び前記成立候補条件情報に基づいて、前記第１記憶領域を更新する第１記憶領域更新手段と、を具備し、前記端末装置は、前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に登録する第２記憶領域登録手段と、自らの診断対象システムの障害発生有無を検知する検知手段と、前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記成立候補条件情報とともに、前記障害発生有無情報として前記検知手段によって検知される前記障害発生有無を前記障害診断装置に送信することによって、前記障害診断装置からの情報収集の依頼に応答する応答手段と、を具備する障害診断システムである。
第２の発明によって、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる。
【００１５】
第２の発明における前記第１記憶領域更新手段は、例えば、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する。
これによって、効率的に障害発生条件の候補を絞り込むことができる。
【００１６】
第２の発明における前記障害診断装置は、更に、前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信することによって、情報収集の結果の反映を指示する反映指示手段、を具備し、前記端末装置は、更に、前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第２記憶領域更新手段、を具備する。
これによって、障害発生条件か否か判定済の候補条件については、収集対象から外すことができる。
【００１７】
第２の発明における前記端末装置は、更に、自らの診断対象システムの環境を示す環境情報とともに、自らの診断対象システムの動作データを前記障害診断装置に送信することによって、障害診断を要求する障害診断要求手段、を具備し、前記障害診断装置が具備する前記依頼手段は、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する。
これによって、情報収集量を減らさずに、車両１台当たりの情報収集の為の処理負荷を軽減することができる。
【発明の効果】
【００１８】
本発明により、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる障害診断システム等を提供することができる。
【図面の簡単な説明】
【００１９】
【図１】障害診断システムの概要を示す図
【図２】端末装置のハードウエア構成図
【図３】障害診断装置のハードウエア構成図
【図４】端末装置のソフトウエア構成図
【図５】障害診断装置のソフトウエア構成図
【図６】正常時の動作データの一例を示す図
【図７】障害発生時の動作データの一例を示す図
【図８】相違信号集合及び候補条件の一例を示す図
【図９】障害診断処理の流れを示すフローチャート
【図１０】第１例におけるセンタＤＢ及び端末ＤＢの変化を示す図
【図１１】第２例におけるセンタＤＢ及び端末ＤＢの変化を示す図
【発明を実施するための形態】
【００２０】
以下図面に基づいて、本発明の実施形態を詳細に説明する。
図１は、障害診断システムの概要を示す図である。図１に示すように、障害診断システム１は、複数の診断対象システム２ａ〜２ｄにそれぞれ搭載される複数の端末装置４ａ〜４ｄ、及び端末装置４ａ〜４ｄとネットワーク６を介して接続される障害診断装置５によって構成される。障害診断装置５は、例えば、障害診断業務を集中管理する診断センタ３などに設置される。ネットワーク６は、例えば、無線通信ネットワークである。
【００２１】
診断対象システム２ａ〜２ｄは、例えば、車両に搭載される車載システムなどである。また、端末装置４ａ〜４ｄは、例えば、障害診断処理に必要な機能を備えるＥＣＵ（Ｅｌｅｃｔｒｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：電子制御装置）などである。
診断対象システム２ａ〜２ｄには、端末装置４ａ〜４ｄや、他のＥＣＵ、各種センサ等がＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの車載ネットワークを介して接続されている。端末装置４ａ〜４ｄは、車載ネットワークに流れる複数の信号の値を動作データとして取得する。取得した動作データは、ネットワーク６（無線通信ネットワーク）によって遠隔にある障害診断装置５に送信しても良いし、ケーブル等を介して障害診断装置５に送信しても良い。動作データは、車載ネットワークに流れる各ＥＣＵの入出力信号や、各装置の状態値などである。
【００２２】
また、端末装置４ａ〜４ｄは、車両の外に設置されている装置からの情報を収集しても良い。車両の外に設置されている装置としては、ＶＩＣＳ（Ｖｅｈｉｃｌｅ Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ：道路交通情報通信システム）などのビーコンやＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ：全地球測位システム）衛星などが挙げられる。収集される情報は、診断対象システム２ａ〜２ｄの環境を示す環境情報（場所情報、天候情報、道路交通状況情報など）である。取得した環境情報は、ネットワーク６（無線通信ネットワーク）によって遠隔にある障害診断装置５に送信しても良いし、ケーブル等を介して障害診断装置５に送信しても良い。
【００２３】
障害診断装置５は、予め診断対象システム２ａ〜２ｄ（車載システム）における正常時の動作データを記憶しておき、診断対象システム２ａ〜２ｄ（車載システム）における障害発生時の動作データを入力として、診断対象システム２ａ〜２ｄ（車載システム）において発生した障害を診断する。
【００２４】
診断対象システム２ａ〜２ｄ（車載システム）や端末装置４ａ〜４ｄの数は、特に限定されない。障害診断装置５は、例えば、同一のカテゴリ（同一車種）ごとに、診断対象システム２ａ〜２ｄ（車載システム）の情報を管理する。
以下では、診断対象システム２ａ〜２ｄを総称するときは、「診断対象システム２」と表記する。また、端末装置４ａ〜４ｄを総称するときは、「端末装置４」と表記する。
また、以下では、診断対象システム２として、車載システムを例に挙げて説明する。
【００２５】
図２は、端末装置のハードウエア構成図である。尚、図２のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。
図２に示すように、端末装置４は、制御部１１、記憶部１２、インタフェース部１３、通信制御部１４等がバス１５を介して接続されている。
【００２６】
制御部１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等によって構成される。ＣＰＵは、記憶部１２、ＲＯＭ、記録媒体等に格納されるプログラムをＲＡＭ上のワークメモリ領域に呼び出して実行し、バス１５を介して接続された各装置を駆動制御し、障害診断装置５が行う後述する処理を実現する。
ＲＯＭは、不揮発性メモリであり、コンピュータのブートプログラムやＢＩＯＳ等のプログラム、データ等を恒久的に保持している。
ＲＡＭは、揮発性メモリであり、記憶部１２、ＲＯＭ、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部１１が各種処理を行う為に使用するワークエリアを備える。
【００２７】
記憶部１２は、ＨＤＤ（ハードディスクドライブ）であり、制御部１１が実行するプログラム、プログラム実行に必要なデータ、ＯＳ（オペレーティングシステム）等が格納される。プログラムに関しては、ＯＳ（オペレーティングシステム）に相当する制御プログラムや、後述する処理をコンピュータに実行させるためのアプリケーションプログラムが格納されている。これらの各プログラムコードは、制御部１１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。
また、記憶部１２は、端末ＤＢ（データベース）７を有している。端末ＤＢ７には、障害診断処理に必要なデータが記憶される。尚、端末ＤＢ７は、端末装置４の記憶部１２に限らず、診断対象システム２に搭載される他の装置の記憶部が有しても良い。
【００２８】
インタフェース部１３は、診断対象システム２の車載ネットワークとのインタフェースであり、診断対象システム２内に搭載される他の装置とのデータ送受信を行う。
通信制御部１４は、通信制御装置やアンテナ等を有し、端末装置４とネットワーク６との通信を媒介する通信インタフェースであり、ネットワーク６を介して、障害診断装置５との通信制御を行う。
バス１５は、各装置間の制御信号、データ信号等の授受を媒介する経路である。
【００２９】
図３は、障害診断装置のハードウエア構成図である。尚、図３のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。
図３に示すように、障害診断装置５は、制御部２１、記憶部２２、メディア入出力部２３、通信制御部２４、入力部２５、表示部２６、周辺機器Ｉ／Ｆ部２７等が、バス２８を介して接続される。
【００３０】
制御部２１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等によって構成される。
【００３１】
ＣＰＵは、記憶部２２、ＲＯＭ、記録媒体等に格納されるプログラムをＲＡＭ上のワークメモリ領域に呼び出して実行し、バス２８を介して接続された各装置を駆動制御し、障害診断装置５が行う後述する処理を実現する。
ＲＯＭは、不揮発性メモリであり、コンピュータのブートプログラムやＢＩＯＳ等のプログラム、データ等を恒久的に保持している。
ＲＡＭは、揮発性メモリであり、記憶部２２、ＲＯＭ、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部２１が各種処理を行う為に使用するワークエリアを備える。
【００３２】
記憶部２２は、ＨＤＤ（ハードディスクドライブ）であり、制御部２１が実行するプログラム、プログラム実行に必要なデータ、ＯＳ（オペレーティングシステム）等が格納される。プログラムに関しては、ＯＳ（オペレーティングシステム）に相当する制御プログラムや、後述する処理をコンピュータに実行させるためのアプリケーションプログラムが格納されている。
これらの各プログラムコードは、制御部２１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。
また、記憶部２２は、センタＤＢ（データベース）８を有している。センタＤＢ８には、障害診断処理に必要なデータが記憶される。尚、センタＤＢ８は、障害診断装置５の記憶部２２に限らず、他のコンピュータ等の記憶部が有しても良い。
【００３３】
メディア入出力部２３（ドライブ装置）は、データの入出力を行い、例えば、ＣＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）、ＤＶＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）等のメディア入出力装置を有する。
通信制御部２４は、通信制御装置、通信ポート等を有し、コンピュータとネットワーク６間の通信を媒介する通信インタフェースであり、ネットワーク６を介して、他のコンピュータ間との通信制御を行う。ネットワーク６は、有線、無線を問わない。
【００３４】
入力部２５は、データの入力を行い、例えば、キーボード、マウス等のポインティングデバイス、テンキー等の入力装置を有する。
入力部２５を介して、コンピュータに対して、操作指示、動作指示、データ入力等を行うことができる。
表示部２６は、液晶パネル等のディスプレイ装置、ディスプレイ装置と連携してコンピュータのビデオ機能を実現するための論理回路等（ビデオアダプタ等）を有する。
【００３５】
周辺機器Ｉ／Ｆ（インタフェース）部２７は、コンピュータに周辺機器を接続させるためのポートであり、周辺機器Ｉ／Ｆ部２７を介してコンピュータは周辺機器とのデータの送受信を行う。周辺機器Ｉ／Ｆ部２７は、ＵＳＢやＩＥＥＥ１３９４やＲＳ−２３２Ｃ等によって構成されており、通常複数の周辺機器Ｉ／Ｆを有する。周辺機器との接続形態は有線、無線を問わない。
バス２８は、各装置間の制御信号、データ信号等の授受を媒介する経路である。
【００３６】
図４は、端末装置のソフトウエア構成図である。端末装置４が備える各種の手段は、図４に示す機能を備えるソフトウエアと、図２に示すハードウエアとが協働することによって実現されるものである。
図４に示すように、端末装置４を構成する為のソフトウエアは、障害発生有無検知機能３１、障害診断要求機能３２、端末ＤＢ登録機能３３、情報収集応答機能３４、端末ＤＢ更新機能３５等を備える。
【００３７】
障害発生有無検知機能３１は、他のＥＣＵやセンサからＤＴＣ（ダイアグノスティック・トラブル・コード）信号が受信されたか否か、又は、運転者がインパネ（インストルメントパネル：運転席に設けられる計器盤）などに設置される障害検出用ボタンが押下されたか否かに応じて、自らの診断対象システム２の障害発生有無を検知する。
【００３８】
障害診断要求機能３２は、自らの診断対象システム２の動作データを障害診断装置５に送信することによって、障害診断を要求する機能である。また、障害診断要求機能３２は、必要に応じて、自らの診断対象システム２の環境を示す環境情報も障害診断装置５に送信する。
【００３９】
端末ＤＢ登録機能３３は、障害診断装置５から受信するデータを、端末ＤＢ７に登録する機能である。障害診断装置５から受信するデータは、例えば、障害発生条件となり得る候補条件である。
ここで、「障害発生条件」とは、障害が発生した時のＥＣＵの入出力信号や各装置の状態値などの組み合わせである。例えば、発生した正常でない現象に対して、車速を示す信号がＡｋｍ／ｈ、ＡＣＣ（車間距離制御）システムが作動中であることが障害発生条件という具合である。また、「候補条件」とは、障害が発生した時に取り得るＥＣＵの入出力信号や各装置の状態値などの組み合わせである。
端末装置４は、障害診断装置５から障害診断に必要な情報の収集を依頼されるときに、候補条件を端末ＤＢ７に登録する。
【００４０】
情報収集応答機能３４は、自らの診断対象システム２において、端末ＤＢ７に記憶している候補条件のいずれかが成立すると、成立候補条件情報とともに、障害発生有無情報として障害発生有無検知機能３１によって検知される障害発生有無を障害診断装置５に送信することによって、障害診断装置５からの情報収集の依頼に応答する機能である。
ここで、「成立候補条件情報」とは、成立した候補条件を示す情報である。「障害発生有無情報」とは、候補条件が成立した時点に、障害が検知されたか、又は検知されていないかのいずれかを示す情報である。尚、「候補条件が成立した時点」とは、必ずしも時間を特定しているわけではなく、候補条件が成立したことと、障害が検知されたことの因果関係を特定しているに過ぎない。
【００４１】
端末ＤＢ更新機能３５は、障害診断装置５から受信する削除候補条件情報に基づいて、端末ＤＢ７を更新する機能である。
ここで、「削除候補条件情報」とは、センタＤＢ８に記憶されていた候補条件の中で、削除された候補条件を示す情報である。
【００４２】
本発明では、例えば、ＡＣＣ（Ａｕｔｏ Ｃｒｕｉｓｅ Ｃｏｎｔｒｏｌ：車間距離制御）システムが起動中であるにも関わらず、先行車に追従しなかったり、加速が不安定になったりするなど、ＤＴＣ信号としては未検出ではあるが、運転者が障害を検知するような「未知の障害」に関する障害診断を行う。また、本発明では、「未知の障害」が発生した診断対象システム２とは異なる診断対象システム２に対して、障害診断に必要な情報収集を依頼する。
従って、障害診断要求機能３２では、専ら、運転者による障害検出用ボタンが押下されたことが確認されたときに、障害診断を要求する。また、情報収集応答機能３４では、ＤＴＣ信号が受信された場合と、運転者による障害検出用ボタンが押下された場合とを区別せず、両者とも障害があったものとし、障害発生有無情報を「障害発生有り」として障害診断装置５に送信する。
【００４３】
図５は、障害診断装置のソフトウエア構成図である。図４に示すように、障害診断装置５を構成する為のソフトウエアは、候補条件決定機能４１、センタＤＢ登録機能４２、情報収集依頼機能４３、情報収集結果回収機能４４、センタＤＢ更新機能４５、情報週結果反映指示機能４６等を備える。障害診断装置５が備える各種の手段は、図５に示す機能を備えるソフトウエアと、図３に示すハードウエアとが協働することによって実現されるものである。
【００４４】
候補条件決定機能４１は、特定の診断対象システム２の動作データに基づいて障害発生条件となり得る候補条件を決定する機能である。候補条件決定機能４１の具体例としては、特開２０１０−２１８４９２号公報に記載の仕組みなどが挙げられるが、本発明では特に限定されるものではない。
【００４５】
センタＤＢ登録機能４２は、候補条件決定機能４１によって決定される候補条件をセンタＤＢ８に登録する機能である。また、センタＤＢ登録機能４２は、候補条件と紐付けて、端末４から受信する環境情報を登録しても良い。
【００４６】
情報収集依頼機能４３は、センタＤＢ８に記憶している候補条件を複数の端末装置４に送信することによって、情報収集を依頼する機能である。候補条件の送信先は、同一車種の全ての端末装置４としても良いし、同一車種の中で一部の端末装置４に限定しても良い。
【００４７】
結果回収機能４４は、成立候補条件情報及び障害発生有無情報を端末装置４から受信することによって、情報収集の結果を回収する機能である。尚、結果回収機能４４は、車両の点検時などに、車両に接続されるコンピュータから成立候補条件情報及び障害発生有無情報を受信しても良い。
【００４８】
センタＤＢ更新機能４５は、端末装置４から受信する障害発生有無情報及び成立候補条件情報に基づいて、センタＤＢ８を更新する機能である。また、センタＤＢ更新機能４５は、削除した候補条件を削除候補条件情報として特定する。
【００４９】
結果反映指示機能４６は、削除候補条件情報を複数の端末装置４に送信することによって、情報収集の結果の反映を指示する機能である。削除候補条件情報の送信先は、情報収集を依頼する時の候補条件の送信先と同一である。
【００５０】
図６は、正常時の動作データの一例を示す図である。正常時の動作データは、予めセンタＤＢ８に記憶されている。
動作データは、各ＥＣＵの入出力信号について、各ＥＣＵの処理結果が変わらない範囲（例えば、プログラム中の条件分岐やジャンプ部で同じ動きをする範囲）を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものである。また、動作データは、各装置の状態値について、各装置の状態が変わらない範囲（例えば、車両の動作が変化しない範囲）を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものである。
例えば、車速を示す信号の場合、０ｋｍ／ｈであれば０、０ｋｍ／ｈ〜５ｋｍ／ｈであれば１、５ｋｍ／ｈ〜２０ｋｍ／ｈであれば２、・・・といった具合に変換される。
図６に示すように、例えば、Ｎｏ．が「Ｘ１」の正常時の動作データは、信号１が「０」、信号２が「１」、信号３が「０」、信号４が「１」、信号５が「０」である。
【００５１】
図７は、障害発生時の動作データの一例を示す図である。図７に示すデータは、図６に示す正常時の動作データと同じように、同値とみなす範囲にデータの値を分割して変換し、同一時刻ごとに纏めたものである。障害発生時の動作データは、データ容量を圧縮する為、データの組み合わせが変化する時刻のみを抽出するようにしても良い。
【００５２】
図８は、相違信号集合及び候補条件の一例を示す図である。
相違信号集合とは、障害発生時の動作データと正常時の動作データとを比較したときに、値が相違する信号群を示す集合である。図８（ａ）に示す相違信号集合は、図７に示すＮｏ．が「Ｙ２」の障害発生時の動作データと、図６に示す全ての正常時の動作データとを比較した結果を示している。
図７に示すＮｏ．が「Ｙ２」の障害発生時の動作データは、信号１が「０」、信号２が「３」、信号３が「１」、信号４が「０」、信号５が「０」である。一方、図６に示すＮｏ．が「Ｘ１」の正常時の動作データは、信号１が「０」、信号２が「１」、信号３が「０」、信号４が「１」、信号５が「０」である。これらを比較すると、信号２、信号３、及び信号４の３つが相違する。従って、図８（ａ）に示すＮｏ．が「Ｄ１」の相違信号集合は、｛Ｓ２ｆ、Ｓ３ｆ、Ｓ４ｆ｝となる。ここで、「Ｓ２ｆ」とは、障害発生時の動作データに係る信号２の信号値を意味する。つまり、｛Ｓ２ｆ、Ｓ３ｆ、Ｓ４ｆ｝とは、｛信号２＝３、信号３＝１、信号４＝０｝という動作データを意味している。
【００５３】
尚、図７に示すＮｏ．が「Ｙ１」の障害発生時の動作データは、信号１が「１」、信号２が「３」、信号３が「１」、信号４が「０」、信号５が「１」である。これは、図６に示すＮｏ．が「Ｘ６」の正常時の動作データと同一である。つまり、図７に示すＮｏ．が「Ｙ１」の障害発生時の動作データは、正常とみなすことができる。
図７の例では、診断対象システム２が、Ｎｏ．が「Ｙ１」の時刻までは正常な動作をしており、Ｎｏ．が「Ｙ２」の時刻において正常でない動作をした可能性があることを示している。
【００５４】
また、図８（ｂ）に示す候補条件は、図８（ａ）に示す相違信号集合に対して、特開２０１０−２１８４９２号公報に記載の仕組みを利用して算出した結果を示している。
ここで、特開２０１０−２１８４９２号公報に記載の仕組みを適用した障害診断装置５の処理の概要を説明する。障害診断装置５は、全ての相違信号集合を充足することを制約条件とし、各信号の値が障害発生条件の構成要素であることを否定する論理式に同じ重みを設定することで最大充足可能性問題の形に定式化する。次に、障害診断装置５は、最大充足可能性問題のミニマム解を算出し、算出された解を否定する論理式を制約条件として逐次追加して再度解を算出する処理を、解が存在しなくなるまで繰り返すことで、障害発生条件となり得る候補条件を算出する。尚、ミニマム解とは、データを１つでも削るとｓａｔｉｓｆｉａｂｌｅにならない解である。
【００５５】
図８（ａ）に示す相違信号集合に対しては、ミニマム解として、｛Ｓ１ｆ、Ｓ２ｆ｝と｛Ｓ２ｆ、Ｓ５ｆ｝の２つが得られる。従って、障害診断装置５は、図８（ｂ）に示すように、｛Ｓ１ｆ、Ｓ２ｆ｝（データＮｏ．が「Ｃ１」）、｛Ｓ２ｆ、Ｓ５ｆ｝（データＮｏ．が「Ｃ２」）の２つを候補条件とする。また、障害診断装置５は、その他の相違信号集合に基づいて、｛Ｓ１ｆ、Ｓ４ｆ、Ｓ５ｆ｝（データＮｏ．が「Ｃ３」）を３つ目の候補条件とする。
【００５６】
更に、障害診断装置５は、算出された全てのミニマム解の和集合を障害発生条件として決定することもできる。これは、特開２０１０−２１８４９２号公報にも記載されているように、正常時の時系列データが多くなると、ミニマム解の和集合が真の障害発生条件に近づくと考えられるからである。
しかしながら、本発明では、正常時の時系列データが事前に網羅的に（抜け漏れなく）収集することができない場合を想定していることから、ミニマム解の和集合が真の障害発生条件になるとは言い切れない。そこで、障害診断装置５は、それぞれのミニマム解を候補条件とし、「未知の障害」が発生した診断対象システム２とは異なる診断対象システム２に対して、候補条件が成立したときの動作データの収集を依頼する。
【００５７】
図９は、障害診断処理の流れを示すフローチャートである。
図９では、端末装置４ａが搭載されている診断対象システム２ａにおいて障害が検知され、端末装置４ｂ〜４ｄが搭載されている診断対象システム２ｂ〜２ｄに対して、情報収集が依頼されるものとして説明する。
【００５８】
図９に示すように、端末装置４ａは、障害を検知し、自らの診断対象システム２ａの動作データを障害診断装置５に送信する（ステップＳ１）。また、端末装置４ａは、更に、自らの診断対象システム２ａの環境を示す環境情報を障害診断装置５に送信しても良い。
【００５９】
次に、障害診断装置５は、端末装置４ａから受信する動作データに基づき、障害発生条件となり得る候補条件を決定し、候補条件をセンタＤＢ８に記憶する（ステップＳ２）。また、障害診断装置５は、端末装置４ａから受信する環境情報もセンタＤＢ８に記憶するようにしても良い。尚、障害診断装置５は、端末装置４ａから直接受信する場合に限らず、修理工場などのコンピュータから、診断対象システム２ａの動作データを受信しても良い。
【００６０】
次に、障害診断装置５は、センタＤＢ８に記憶している候補条件を「依頼候補条件情報」として複数の端末装置４ｂ〜４ｄに送信する（ステップＳ３）。「依頼候補条件情報」とは、依頼する情報収集の対象データを特定する為の候補条件を示す情報である。
【００６１】
次に、端末装置４ｂ〜４ｄは、障害診断装置５から受信する依頼候補条件情報に係る候補条件を、それぞれ端末ＤＢ７に記憶する（ステップＳ４）。そして、端末装置４ｂ〜４ｄは、端末ＤＢ７に記憶している候補条件のいずれかが成立すると、候補条件が成立した時点における自らの診断対象システム２の障害発生有無を判定し、成立した候補条件を示す成立候補条件情報、及び、障害発生有無を示す障害発生有無情報を障害診断装置５に送信する（ステップＳ５）。
【００６２】
次に、障害診断装置５は、端末装置４ｂ〜４ｄのいずれかから受信する障害発生有無情報及び成立候補条件情報に基づいて、センタＤＢ８を更新する。より詳細には、障害診断装置５は、端末装置４ｂ〜４ｄのいずれかから受信する障害発生有無情報を確認し、「障害発生無し」の場合には端末装置４ｂ〜４ｄのいずれかから受信する成立候補条件情報と一致する候補条件をセンタＤＢ８から削除し、「障害発生有り」の場合には端末装置４ｂ〜４ｄのいずれかから受信する成立候補条件情報と一致しない全ての候補条件をセンタＤＢ８から削除する（ステップＳ６）。
そして、障害診断装置５は、センタＤＢ８から削除した候補条件を示す「削除候補条件情報」を複数の端末装置４ｂ〜４ｄに送信する（ステップＳ７）。「削除候補条件情報」とは、センタＤＢ８から削除した候補条件、すなわち障害発生条件か否か判定済の候補条件を示す情報である。
【００６３】
次に、端末装置４ｂ〜４ｄは、障害診断装置５から受信する削除候補条件情報に基づいて、端末ＤＢ７を更新する（ステップＳ８）。つまり、障害診断装置５は、障害発生条件か否か判定済の候補条件を端末ＤＢ７から削除する。これによって、障害発生条件か否か判定済の候補条件については、収集対象から外すことができる。
【００６４】
尚、ステップＳ６において、障害診断装置５は、候補条件ごとに成立候補条件情報の受信数をカウントしていき、十分信頼できる数の成立候補条件情報及び障害有無情報を受信した候補条件だけをセンタＤＢ８から削除するようにしても良い。
【００６５】
図１０は、第１例におけるセンタＤＢ及び端末ＤＢの変化を示す図である。図１０に示す例では、（ａ）ステップＳ２において、障害診断装置５は、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件をセンタＤＢ８に登録する。この時点では、端末ＤＢ７に登録されている候補条件はない。
（ｂ）ステップＳ３では、障害診断装置５は、依頼候補条件情報として「Ｃ１＝｛Ｓ１ｆ，Ｓ２ｆ｝、Ｃ２＝｛Ｓ２ｆ，Ｓ５ｆ｝、Ｃ３＝｛Ｓ１ｆ，Ｓ４ｆ，Ｓ５ｆ｝」を端末装置４ｂ〜４ｄに送信する。
（ｃ）ステップＳ４において、端末装置４ｂ〜４ｄは、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件を端末ＤＢ７ｂ〜７ｄに登録する。
（ｄ）ステップＳ５において、例えば、端末装置４ｂを搭載する診断対象システム２ｂにおいて、Ｎｏ．が「Ｃ２」の候補条件が成立し、この候補条件が成立した時に診断対象システム２ｂの動作は「障害発生無し」だったとする。この場合、端末装置４ｂは、成立候補条件情報として「Ｃ２」、障害発生有無情報として「障害発生無し」を障害診断装置５に送信する。
（ｅ）ステップＳ６では、障害診断装置５は、Ｎｏ．が「Ｃ２」の候補条件をセンタＤＢ８から削除する。
（ｆ）ステップＳ７では、障害診断装置５は、削除候補条件情報として「Ｃ２」を端末装置４ｂ〜４ｄに送信する。
（ｅ）ステップＳ８では、端末装置４ｂ〜４ｄは、Ｎｏ．が「Ｃ２」の候補条件を端末ＤＢ７ｂ〜７ｄから削除する。
【００６６】
図１０に示す例では、端末装置４ｂを搭載する診断対象システム２ｂにおいて、“Ｎｏ．が「Ｃ２」の候補条件の成立時の動作は正常である。”という情報が収集され、この情報収集の結果に基づいて、障害診断装置５は、候補条件を３つから２つに絞り込むことが示されている。
更に、診断対象システム２ｂ〜２ｄのいずれかにおいて、“Ｎｏ．が「Ｃ１」の候補条件の成立時の動作は正常である。”、“Ｎｏ．が「Ｃ１」の候補条件の成立時の動作は正常でない。”、“Ｎｏ．が「Ｃ３」の候補条件の成立時の動作は正常である。”、又は、“Ｎｏ．が「Ｃ３」の候補条件の成立時の動作は正常でない。”のいずれか１つの情報が収集されれば、障害診断装置５は、障害発生条件を特定できる。
【００６７】
図１１は、第２例におけるセンタＤＢ及び端末ＤＢの変化を示す図である。
図１１に示す例では、（ａ）ステップＳ２において、障害診断装置５は、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件をセンタＤＢ８に登録する。この時点では、端末ＤＢ７に登録されている候補条件はない。
（ｂ）ステップＳ３では、障害診断装置５は、依頼候補条件情報として「Ｃ１＝｛Ｓ１ｆ，Ｓ２ｆ｝、Ｃ２＝｛Ｓ２ｆ，Ｓ５ｆ｝、Ｃ３＝｛Ｓ１ｆ，Ｓ４ｆ，Ｓ５ｆ｝」を端末装置４ｂ〜４ｄに送信する。
（ｃ）ステップＳ４において、端末装置４ｂ〜４ｄは、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件を端末ＤＢ７ｂ〜７ｄに登録する。
（ｄ）ステップＳ５において、例えば、端末装置４ｂを搭載する診断対象システム２ｂにおいて、Ｎｏ．が「Ｃ１」の候補条件が成立し、この候補条件が成立した時に診断対象システム２ｂの動作は「障害発生有り」だったとする。この場合、端末装置４ｂは、成立候補条件情報として「Ｃ１」、障害発生有無情報として「障害発生有り」を障害診断装置５に送信する。
（ｅ）ステップＳ６では、障害診断装置５は、Ｎｏ．が「Ｃ１」の候補条件と一致しない全ての候補条件、すなわちＮｏ．が「Ｃ２」及び「Ｃ３」の候補条件をセンタＤＢ８から削除する。
（ｆ）ステップＳ７では、障害診断装置５は、削除候補条件情報として「全て」を端末装置４ｂ〜４ｄに送信する。
（ｅ）ステップＳ８では、端末装置４ｂ〜４ｄは、全ての候補条件を端末ＤＢ７ｂ〜７ｄから削除する。
【００６８】
図１１に示す例では、端末装置４ｂを搭載する診断対象システム２ｂにおいて、“Ｎｏ．が「Ｃ１」の候補条件の成立時の動作は正常でない。”という情報が収集され、この情報収集の結果に基づいて、障害診断装置５は、候補条件を３つから１つに絞り込むことが示されている。従って、図１１に示す例では、障害診断装置５は、障害発生条件を特定できている。
【００６９】
以上、本発明の実施の形態における障害診断システム１では、前述した通り、未知の障害が発生した診断対象システム２とは異なる診断対象システム２に対して、障害診断に必要な情報収集を依頼し、情報収集の結果を回収する。依頼する情報収集の内容は、障害発生条件となり得る候補条件が成立したこと、及び、成立時の診断対象システム２の動作が「正常」又は「正常でない」のいずれであるかである。従って、本発明の実施の形態では、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる。
【００７０】
＜変形例＞
前述の説明では、ステップＳ３において、障害診断装置５は、候補条件の送信先を、同一車種の全ての端末装置４とした。変形例では、障害診断装置５は、候補条件の送信先を、同一車種の中で一部の端末装置４に限定する。
【００７１】
変形例では、ステップＳ１において、端末装置４ａは、自らの診断対象システム２ａの動作データとともに、自らの診断対象システム２ａの環境を示す環境情報を障害診断装置５に送信する。環境情報としては、前述したように、例えば、場所情報、天候情報、道路交通状況情報などが考えられる。
そして、ステップＳ３において、障害診断装置５は、端末装置４ａから受信する環境情報と合致する環境において動作している診断対象システム２に対してのみ、依頼候補条件情報を送信する。例えば、障害診断装置５は、端末装置４ａから受信する場所情報に基づいて、積雪・寒冷地か否か、起伏が多い山間部か否か、高速道路と一般道路のいずれか、市街地と郊外のいずれか、などを判定し、環境情報と合致する環境において動作している診断対象システム２を特定する。ここで、環境が合致するか否かを判定する為の情報は、予め診断対象システム２ごとにセンタＤＢ８に登録しておいても良いし、障害診断が依頼された時に、それぞれの診断対象システム２に問合せをして収集しても良い。
【００７２】
正常時に取り得る信号値の組み合わせは、診断対象システム２が搭載されている車両の走行場所によって、現れやすさが異なることが考えられる。また、削除したい候補条件は、障害が発生した車両と同じような場所を走っている車両の方が揃いやすいと考えられる。従って、候補条件の送信先を同一車種の中で一部の端末装置４に限定しても、限定しない場合と比較して、成立候補条件情報及び障害発生有無情報の収集量はほとんど変わらない。
そして、候補条件の送信先を同一車種の中で一部の端末装置４に限定することによって、「車両１台当たりの情報収集の為の処理負荷」を軽減することができる。
【００７３】
尚、前述の説明では、障害が発生した診断対象システム２に係る端末装置４は、診断センタ３に設置されている障害診断装置５を介して、他の診断対象システム２に係る端末装置４に情報収集を依頼していたが、例えば、車車間通信や路車間通信などによって、直接的に情報収集を依頼しても良い。更に、各端末装置４が、障害診断装置５の各機能（センタＤＢ８、候補条件決定機能４１、センタＤＢ登録機能４２、情報収集依頼機能４３、結果回収機能４４、センタＤＢ更新機能４５、結果反映指示機能４６）を備える場合、障害診断装置５は不要となる。
【００７４】
また、前述の説明では、端末装置４ｂ〜４ｄは、無条件に情報収集の依頼に応答していたが、当然ながら、診断対象システム２が搭載されている車両の運転者には、事前に情報収集の同意を得ることになる。また、端末装置４ｂ〜４ｄは、車両の起動時に、情報収集をして良いか否か、運転者に問合せを行い、運転者が承諾する旨の指示をしたときのみ、情報収集の依頼に応答するようにしても良い。
本発明による情報収集は、各運転者が所有している車両と同一の車種について更なる安全運用に繋がるものである為、障害診断の依頼者ではない運転者にとっても多大なメリットがある。
【００７５】
以上、添付図面を参照しながら、本発明に係る障害診断システム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【符号の説明】
【００７６】
１………障害診断システム
２………診断対象システム
３………診断センタ
４………端末装置
５………障害診断装置
６………ネットワーク
７………端末ＤＢ
８………センタＤＢ
【技術分野】
【０００１】
本発明は、複数の診断対象システムそれぞれに搭載される複数の端末装置、及び端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システム等に関するものである。
【背景技術】
【０００２】
近年、複数のモジュールが協調動作するシステムにおいて、システムの大規模化に伴い、障害診断が難しくなってきている。協調動作システムの一例としては、車両に搭載される車載システムがある。車載システムでは、複数のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）が、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワークを介して互いにデータの送受信を行い、協調して動作を行っている。その為、あるＥＣＵが故障すると他のＥＣＵにも異常が伝搬してしまい、障害の診断をすることが難しい。
特に、車載システムについては、ハイブリッド車や電気自動車などの登場、つながる技術（インフラ協調、隊列走行などの技術）の発展に伴い、電子制御の複雑化、大規模化が顕著になっている。
【０００３】
そこで、障害診断を支援するシステムの開発が盛んになっている。例えば、特許文献１には、診断対象車両に対して遠隔から故障診断を実行し、故障診断結果を顧客に送信する遠隔故障診断システムが開示されている。特許文献１に記載の遠隔故障診断システムでは、どの実施形態も概ね以下の手順に従って遠隔故障診断処理を実行する。
（１）診断対象の車両又はサービス工場は、故障診断要求又は車両データを遠隔地の故障診断サーバに送信する。
（２）故障診断サーバは、受信した故障診断要求又は車両データに基づき、既知の故障（特許文献１では「所定の故障」と記載）について、故障診断の際に必要なデータの走行条件を決定し、走行条件を診断対象の車両に送信する。
（３）診断対象の車両は、受信した走行条件を満たすまで待機し、走行条件が満たされると、そのときの車両データを故障診断サーバに送信する。
（４）故障診断サーバは、受信した車両データに基づき、故障診断を行い、診断結果を診断対象の車両に送信する。
尚、特許文献１における「走行条件」は、故障か否かの判定に必要なデータを取得するための条件であり、故障の発生の有無には関係ない条件である。また、特許文献１における「故障診断サーバに送信する車両データ」は、故障か否かの判定に必要なデータであり、故障ごとに異なる。
【０００４】
しかしながら、特許文献１に記載の遠隔故障診断システムでは、未知の障害については何ら解決策を提示していない。ここで、「未知の障害」とは、異常の現象（正常ではない現象）の中で、発生条件が特定されていない現象を意味する。
【０００５】
未知の障害としては、仕様の不完全性（想定外の使い方や走行環境に対応する仕様の欠如など）や、テスト環境や車両モデルと現実とのずれ（テスト環境や車両モデルに基づくシミュレーションでは発生しない割込みタイミングなど）など、事前に想定していなかった原因によるものなどが挙げられる。このような現象は、特定の稀な条件が揃った場合にのみ発生し、再現することが難しい。
そこで、本発明者らは、未知の障害についての解決策として、事前に想定していなかった原因による未知の障害が発生した場合であっても、障害発生条件を特定できる障害診断装置等を発明している（特許文献２参照）。特許文献２に記載の障害診断装置では、個々の障害原因に関する事前知識や診断対象のモデルに頼らず、正常時の車両動作データを活用し、障害発生条件の候補を絞り込む。すなわち、正常時の車両動作データにはないパターンを抽出することによって、障害発生条件となり得る信号の値の組み合わせを絞り込む。そして、実際の車両において、障害発生条件となり得る信号の値の組み合わせを揃えることによって、現象を再現する。
尚、特許文献２における「障害発生条件」は、特許文献１における「走行条件」と異なり、正常時に発生しない条件である。また、特許文献２における「障害発生条件となり得る信号の値の組み合わせ」は、特許文献１における「故障診断サーバに送信する車両データ」と異なり、障害の種類によらず同一である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−３０２６７５号公報
【特許文献２】特開２０１０−２１８４９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、正常時の車両動作データは、テスト環境などにおいて事前に網羅的に（抜け漏れなく）収集することは困難である。特に、アクセルやブレーキ等の運転者の操作レベルの変数ではなく、ＥＣＵ同士がやり取りする制御レベルの変数については、正常時の全ての値の組み合わせを事前に揃えておくことは難しい。
そして、正常時の車両動作データが網羅的に収集されていない場合、障害発生条件の候補が数多く残ってしまう為、全ての候補を実際の車両において発生させようとすると、多大な時間と費用がかかってしまう。
【０００８】
また、特許文献１に記載の遠隔故障診断システムでは、診断対象の車両が、発生した現象によって動作不能になっている場合には適用できない。また、未知の障害が発生している場合、診断対象の車両をそのまま走行させておくと、更なる故障や障害が発生する可能性があり、望ましくない。
【０００９】
本発明は、前述した問題点に鑑みてなされたもので、その目的とすることは、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる障害診断システム等を提供することである。
【課題を解決するための手段】
【００１０】
前述した目的を達成するために第１の発明は、複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムにおける障害診断方法であって、前記障害診断装置が、特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定し、前記候補条件を第１記憶領域に記憶する第１ステップと、前記障害診断装置が、前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信する第２ステップと、前記端末装置が、前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に記憶し、前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記候補条件が成立した時点における自らの診断対象システムの障害発生有無を判定し、成立した前記候補条件を示す成立候補条件情報、及び前記障害発生有無を示す障害発生有無情報を前記障害診断装置に送信する第３ステップと、前記障害診断装置が、前記端末装置から受信する前記成立候補条件情報及び前記障害発生有無情報に基づいて、前記第１記憶領域を更新する第４ステップと、を含む障害診断方法である。
第１の発明によって、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる。
【００１１】
第１の発明における前記第４ステップでは、例えば、前記障害診断装置が、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する。
これによって、効率的に障害発生条件の候補を絞り込むことができる。
【００１２】
第１の発明における前記第４ステップでは、例えば、前記障害診断装置が、更に、前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信し、前記端末装置が、前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第５ステップ、を更に含む。
これによって、障害発生条件か否か判定済の候補条件については、収集対象から外すことができる。
【００１３】
第１の発明における前記第１ステップにおける前記動作データは、例えば、前記特定の診断対象システムに搭載されている前記端末装置が、前記特定の診断対象システムの環境を示す環境情報とともに、前記障害診断装置に送信するものであり、前記第２ステップでは、前記障害診断装置が、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する。
これによって、情報収集量を減らさずに、車両１台当たりの情報収集の為の処理負荷を軽減することができる。
【００１４】
第２の発明は、複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムであって、前記障害診断装置は、特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定する候補条件決定手段と、前記候補条件決定手段によって決定される前記候補条件を第１記憶領域に登録する第１記憶領域登録手段と、前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信することによって、情報収集を依頼する依頼手段と、成立した前記候補条件を示す成立候補条件情報、及び前記候補条件が成立した時点における診断対象システムの障害発生有無を示す障害発生有無情報を前記端末装置から受信することによって、情報収集の結果を回収する回収手段と、前記端末装置から受信する前記障害発生有無情報及び前記成立候補条件情報に基づいて、前記第１記憶領域を更新する第１記憶領域更新手段と、を具備し、前記端末装置は、前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に登録する第２記憶領域登録手段と、自らの診断対象システムの障害発生有無を検知する検知手段と、前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記成立候補条件情報とともに、前記障害発生有無情報として前記検知手段によって検知される前記障害発生有無を前記障害診断装置に送信することによって、前記障害診断装置からの情報収集の依頼に応答する応答手段と、を具備する障害診断システムである。
第２の発明によって、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる。
【００１５】
第２の発明における前記第１記憶領域更新手段は、例えば、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する。
これによって、効率的に障害発生条件の候補を絞り込むことができる。
【００１６】
第２の発明における前記障害診断装置は、更に、前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信することによって、情報収集の結果の反映を指示する反映指示手段、を具備し、前記端末装置は、更に、前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第２記憶領域更新手段、を具備する。
これによって、障害発生条件か否か判定済の候補条件については、収集対象から外すことができる。
【００１７】
第２の発明における前記端末装置は、更に、自らの診断対象システムの環境を示す環境情報とともに、自らの診断対象システムの動作データを前記障害診断装置に送信することによって、障害診断を要求する障害診断要求手段、を具備し、前記障害診断装置が具備する前記依頼手段は、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する。
これによって、情報収集量を減らさずに、車両１台当たりの情報収集の為の処理負荷を軽減することができる。
【発明の効果】
【００１８】
本発明により、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる障害診断システム等を提供することができる。
【図面の簡単な説明】
【００１９】
【図１】障害診断システムの概要を示す図
【図２】端末装置のハードウエア構成図
【図３】障害診断装置のハードウエア構成図
【図４】端末装置のソフトウエア構成図
【図５】障害診断装置のソフトウエア構成図
【図６】正常時の動作データの一例を示す図
【図７】障害発生時の動作データの一例を示す図
【図８】相違信号集合及び候補条件の一例を示す図
【図９】障害診断処理の流れを示すフローチャート
【図１０】第１例におけるセンタＤＢ及び端末ＤＢの変化を示す図
【図１１】第２例におけるセンタＤＢ及び端末ＤＢの変化を示す図
【発明を実施するための形態】
【００２０】
以下図面に基づいて、本発明の実施形態を詳細に説明する。
図１は、障害診断システムの概要を示す図である。図１に示すように、障害診断システム１は、複数の診断対象システム２ａ〜２ｄにそれぞれ搭載される複数の端末装置４ａ〜４ｄ、及び端末装置４ａ〜４ｄとネットワーク６を介して接続される障害診断装置５によって構成される。障害診断装置５は、例えば、障害診断業務を集中管理する診断センタ３などに設置される。ネットワーク６は、例えば、無線通信ネットワークである。
【００２１】
診断対象システム２ａ〜２ｄは、例えば、車両に搭載される車載システムなどである。また、端末装置４ａ〜４ｄは、例えば、障害診断処理に必要な機能を備えるＥＣＵ（Ｅｌｅｃｔｒｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：電子制御装置）などである。
診断対象システム２ａ〜２ｄには、端末装置４ａ〜４ｄや、他のＥＣＵ、各種センサ等がＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの車載ネットワークを介して接続されている。端末装置４ａ〜４ｄは、車載ネットワークに流れる複数の信号の値を動作データとして取得する。取得した動作データは、ネットワーク６（無線通信ネットワーク）によって遠隔にある障害診断装置５に送信しても良いし、ケーブル等を介して障害診断装置５に送信しても良い。動作データは、車載ネットワークに流れる各ＥＣＵの入出力信号や、各装置の状態値などである。
【００２２】
また、端末装置４ａ〜４ｄは、車両の外に設置されている装置からの情報を収集しても良い。車両の外に設置されている装置としては、ＶＩＣＳ（Ｖｅｈｉｃｌｅ Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ：道路交通情報通信システム）などのビーコンやＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ：全地球測位システム）衛星などが挙げられる。収集される情報は、診断対象システム２ａ〜２ｄの環境を示す環境情報（場所情報、天候情報、道路交通状況情報など）である。取得した環境情報は、ネットワーク６（無線通信ネットワーク）によって遠隔にある障害診断装置５に送信しても良いし、ケーブル等を介して障害診断装置５に送信しても良い。
【００２３】
障害診断装置５は、予め診断対象システム２ａ〜２ｄ（車載システム）における正常時の動作データを記憶しておき、診断対象システム２ａ〜２ｄ（車載システム）における障害発生時の動作データを入力として、診断対象システム２ａ〜２ｄ（車載システム）において発生した障害を診断する。
【００２４】
診断対象システム２ａ〜２ｄ（車載システム）や端末装置４ａ〜４ｄの数は、特に限定されない。障害診断装置５は、例えば、同一のカテゴリ（同一車種）ごとに、診断対象システム２ａ〜２ｄ（車載システム）の情報を管理する。
以下では、診断対象システム２ａ〜２ｄを総称するときは、「診断対象システム２」と表記する。また、端末装置４ａ〜４ｄを総称するときは、「端末装置４」と表記する。
また、以下では、診断対象システム２として、車載システムを例に挙げて説明する。
【００２５】
図２は、端末装置のハードウエア構成図である。尚、図２のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。
図２に示すように、端末装置４は、制御部１１、記憶部１２、インタフェース部１３、通信制御部１４等がバス１５を介して接続されている。
【００２６】
制御部１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等によって構成される。ＣＰＵは、記憶部１２、ＲＯＭ、記録媒体等に格納されるプログラムをＲＡＭ上のワークメモリ領域に呼び出して実行し、バス１５を介して接続された各装置を駆動制御し、障害診断装置５が行う後述する処理を実現する。
ＲＯＭは、不揮発性メモリであり、コンピュータのブートプログラムやＢＩＯＳ等のプログラム、データ等を恒久的に保持している。
ＲＡＭは、揮発性メモリであり、記憶部１２、ＲＯＭ、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部１１が各種処理を行う為に使用するワークエリアを備える。
【００２７】
記憶部１２は、ＨＤＤ（ハードディスクドライブ）であり、制御部１１が実行するプログラム、プログラム実行に必要なデータ、ＯＳ（オペレーティングシステム）等が格納される。プログラムに関しては、ＯＳ（オペレーティングシステム）に相当する制御プログラムや、後述する処理をコンピュータに実行させるためのアプリケーションプログラムが格納されている。これらの各プログラムコードは、制御部１１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。
また、記憶部１２は、端末ＤＢ（データベース）７を有している。端末ＤＢ７には、障害診断処理に必要なデータが記憶される。尚、端末ＤＢ７は、端末装置４の記憶部１２に限らず、診断対象システム２に搭載される他の装置の記憶部が有しても良い。
【００２８】
インタフェース部１３は、診断対象システム２の車載ネットワークとのインタフェースであり、診断対象システム２内に搭載される他の装置とのデータ送受信を行う。
通信制御部１４は、通信制御装置やアンテナ等を有し、端末装置４とネットワーク６との通信を媒介する通信インタフェースであり、ネットワーク６を介して、障害診断装置５との通信制御を行う。
バス１５は、各装置間の制御信号、データ信号等の授受を媒介する経路である。
【００２９】
図３は、障害診断装置のハードウエア構成図である。尚、図３のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。
図３に示すように、障害診断装置５は、制御部２１、記憶部２２、メディア入出力部２３、通信制御部２４、入力部２５、表示部２６、周辺機器Ｉ／Ｆ部２７等が、バス２８を介して接続される。
【００３０】
制御部２１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等によって構成される。
【００３１】
ＣＰＵは、記憶部２２、ＲＯＭ、記録媒体等に格納されるプログラムをＲＡＭ上のワークメモリ領域に呼び出して実行し、バス２８を介して接続された各装置を駆動制御し、障害診断装置５が行う後述する処理を実現する。
ＲＯＭは、不揮発性メモリであり、コンピュータのブートプログラムやＢＩＯＳ等のプログラム、データ等を恒久的に保持している。
ＲＡＭは、揮発性メモリであり、記憶部２２、ＲＯＭ、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部２１が各種処理を行う為に使用するワークエリアを備える。
【００３２】
記憶部２２は、ＨＤＤ（ハードディスクドライブ）であり、制御部２１が実行するプログラム、プログラム実行に必要なデータ、ＯＳ（オペレーティングシステム）等が格納される。プログラムに関しては、ＯＳ（オペレーティングシステム）に相当する制御プログラムや、後述する処理をコンピュータに実行させるためのアプリケーションプログラムが格納されている。
これらの各プログラムコードは、制御部２１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。
また、記憶部２２は、センタＤＢ（データベース）８を有している。センタＤＢ８には、障害診断処理に必要なデータが記憶される。尚、センタＤＢ８は、障害診断装置５の記憶部２２に限らず、他のコンピュータ等の記憶部が有しても良い。
【００３３】
メディア入出力部２３（ドライブ装置）は、データの入出力を行い、例えば、ＣＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）、ＤＶＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）等のメディア入出力装置を有する。
通信制御部２４は、通信制御装置、通信ポート等を有し、コンピュータとネットワーク６間の通信を媒介する通信インタフェースであり、ネットワーク６を介して、他のコンピュータ間との通信制御を行う。ネットワーク６は、有線、無線を問わない。
【００３４】
入力部２５は、データの入力を行い、例えば、キーボード、マウス等のポインティングデバイス、テンキー等の入力装置を有する。
入力部２５を介して、コンピュータに対して、操作指示、動作指示、データ入力等を行うことができる。
表示部２６は、液晶パネル等のディスプレイ装置、ディスプレイ装置と連携してコンピュータのビデオ機能を実現するための論理回路等（ビデオアダプタ等）を有する。
【００３５】
周辺機器Ｉ／Ｆ（インタフェース）部２７は、コンピュータに周辺機器を接続させるためのポートであり、周辺機器Ｉ／Ｆ部２７を介してコンピュータは周辺機器とのデータの送受信を行う。周辺機器Ｉ／Ｆ部２７は、ＵＳＢやＩＥＥＥ１３９４やＲＳ−２３２Ｃ等によって構成されており、通常複数の周辺機器Ｉ／Ｆを有する。周辺機器との接続形態は有線、無線を問わない。
バス２８は、各装置間の制御信号、データ信号等の授受を媒介する経路である。
【００３６】
図４は、端末装置のソフトウエア構成図である。端末装置４が備える各種の手段は、図４に示す機能を備えるソフトウエアと、図２に示すハードウエアとが協働することによって実現されるものである。
図４に示すように、端末装置４を構成する為のソフトウエアは、障害発生有無検知機能３１、障害診断要求機能３２、端末ＤＢ登録機能３３、情報収集応答機能３４、端末ＤＢ更新機能３５等を備える。
【００３７】
障害発生有無検知機能３１は、他のＥＣＵやセンサからＤＴＣ（ダイアグノスティック・トラブル・コード）信号が受信されたか否か、又は、運転者がインパネ（インストルメントパネル：運転席に設けられる計器盤）などに設置される障害検出用ボタンが押下されたか否かに応じて、自らの診断対象システム２の障害発生有無を検知する。
【００３８】
障害診断要求機能３２は、自らの診断対象システム２の動作データを障害診断装置５に送信することによって、障害診断を要求する機能である。また、障害診断要求機能３２は、必要に応じて、自らの診断対象システム２の環境を示す環境情報も障害診断装置５に送信する。
【００３９】
端末ＤＢ登録機能３３は、障害診断装置５から受信するデータを、端末ＤＢ７に登録する機能である。障害診断装置５から受信するデータは、例えば、障害発生条件となり得る候補条件である。
ここで、「障害発生条件」とは、障害が発生した時のＥＣＵの入出力信号や各装置の状態値などの組み合わせである。例えば、発生した正常でない現象に対して、車速を示す信号がＡｋｍ／ｈ、ＡＣＣ（車間距離制御）システムが作動中であることが障害発生条件という具合である。また、「候補条件」とは、障害が発生した時に取り得るＥＣＵの入出力信号や各装置の状態値などの組み合わせである。
端末装置４は、障害診断装置５から障害診断に必要な情報の収集を依頼されるときに、候補条件を端末ＤＢ７に登録する。
【００４０】
情報収集応答機能３４は、自らの診断対象システム２において、端末ＤＢ７に記憶している候補条件のいずれかが成立すると、成立候補条件情報とともに、障害発生有無情報として障害発生有無検知機能３１によって検知される障害発生有無を障害診断装置５に送信することによって、障害診断装置５からの情報収集の依頼に応答する機能である。
ここで、「成立候補条件情報」とは、成立した候補条件を示す情報である。「障害発生有無情報」とは、候補条件が成立した時点に、障害が検知されたか、又は検知されていないかのいずれかを示す情報である。尚、「候補条件が成立した時点」とは、必ずしも時間を特定しているわけではなく、候補条件が成立したことと、障害が検知されたことの因果関係を特定しているに過ぎない。
【００４１】
端末ＤＢ更新機能３５は、障害診断装置５から受信する削除候補条件情報に基づいて、端末ＤＢ７を更新する機能である。
ここで、「削除候補条件情報」とは、センタＤＢ８に記憶されていた候補条件の中で、削除された候補条件を示す情報である。
【００４２】
本発明では、例えば、ＡＣＣ（Ａｕｔｏ Ｃｒｕｉｓｅ Ｃｏｎｔｒｏｌ：車間距離制御）システムが起動中であるにも関わらず、先行車に追従しなかったり、加速が不安定になったりするなど、ＤＴＣ信号としては未検出ではあるが、運転者が障害を検知するような「未知の障害」に関する障害診断を行う。また、本発明では、「未知の障害」が発生した診断対象システム２とは異なる診断対象システム２に対して、障害診断に必要な情報収集を依頼する。
従って、障害診断要求機能３２では、専ら、運転者による障害検出用ボタンが押下されたことが確認されたときに、障害診断を要求する。また、情報収集応答機能３４では、ＤＴＣ信号が受信された場合と、運転者による障害検出用ボタンが押下された場合とを区別せず、両者とも障害があったものとし、障害発生有無情報を「障害発生有り」として障害診断装置５に送信する。
【００４３】
図５は、障害診断装置のソフトウエア構成図である。図４に示すように、障害診断装置５を構成する為のソフトウエアは、候補条件決定機能４１、センタＤＢ登録機能４２、情報収集依頼機能４３、情報収集結果回収機能４４、センタＤＢ更新機能４５、情報週結果反映指示機能４６等を備える。障害診断装置５が備える各種の手段は、図５に示す機能を備えるソフトウエアと、図３に示すハードウエアとが協働することによって実現されるものである。
【００４４】
候補条件決定機能４１は、特定の診断対象システム２の動作データに基づいて障害発生条件となり得る候補条件を決定する機能である。候補条件決定機能４１の具体例としては、特開２０１０−２１８４９２号公報に記載の仕組みなどが挙げられるが、本発明では特に限定されるものではない。
【００４５】
センタＤＢ登録機能４２は、候補条件決定機能４１によって決定される候補条件をセンタＤＢ８に登録する機能である。また、センタＤＢ登録機能４２は、候補条件と紐付けて、端末４から受信する環境情報を登録しても良い。
【００４６】
情報収集依頼機能４３は、センタＤＢ８に記憶している候補条件を複数の端末装置４に送信することによって、情報収集を依頼する機能である。候補条件の送信先は、同一車種の全ての端末装置４としても良いし、同一車種の中で一部の端末装置４に限定しても良い。
【００４７】
結果回収機能４４は、成立候補条件情報及び障害発生有無情報を端末装置４から受信することによって、情報収集の結果を回収する機能である。尚、結果回収機能４４は、車両の点検時などに、車両に接続されるコンピュータから成立候補条件情報及び障害発生有無情報を受信しても良い。
【００４８】
センタＤＢ更新機能４５は、端末装置４から受信する障害発生有無情報及び成立候補条件情報に基づいて、センタＤＢ８を更新する機能である。また、センタＤＢ更新機能４５は、削除した候補条件を削除候補条件情報として特定する。
【００４９】
結果反映指示機能４６は、削除候補条件情報を複数の端末装置４に送信することによって、情報収集の結果の反映を指示する機能である。削除候補条件情報の送信先は、情報収集を依頼する時の候補条件の送信先と同一である。
【００５０】
図６は、正常時の動作データの一例を示す図である。正常時の動作データは、予めセンタＤＢ８に記憶されている。
動作データは、各ＥＣＵの入出力信号について、各ＥＣＵの処理結果が変わらない範囲（例えば、プログラム中の条件分岐やジャンプ部で同じ動きをする範囲）を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものである。また、動作データは、各装置の状態値について、各装置の状態が変わらない範囲（例えば、車両の動作が変化しない範囲）を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものである。
例えば、車速を示す信号の場合、０ｋｍ／ｈであれば０、０ｋｍ／ｈ〜５ｋｍ／ｈであれば１、５ｋｍ／ｈ〜２０ｋｍ／ｈであれば２、・・・といった具合に変換される。
図６に示すように、例えば、Ｎｏ．が「Ｘ１」の正常時の動作データは、信号１が「０」、信号２が「１」、信号３が「０」、信号４が「１」、信号５が「０」である。
【００５１】
図７は、障害発生時の動作データの一例を示す図である。図７に示すデータは、図６に示す正常時の動作データと同じように、同値とみなす範囲にデータの値を分割して変換し、同一時刻ごとに纏めたものである。障害発生時の動作データは、データ容量を圧縮する為、データの組み合わせが変化する時刻のみを抽出するようにしても良い。
【００５２】
図８は、相違信号集合及び候補条件の一例を示す図である。
相違信号集合とは、障害発生時の動作データと正常時の動作データとを比較したときに、値が相違する信号群を示す集合である。図８（ａ）に示す相違信号集合は、図７に示すＮｏ．が「Ｙ２」の障害発生時の動作データと、図６に示す全ての正常時の動作データとを比較した結果を示している。
図７に示すＮｏ．が「Ｙ２」の障害発生時の動作データは、信号１が「０」、信号２が「３」、信号３が「１」、信号４が「０」、信号５が「０」である。一方、図６に示すＮｏ．が「Ｘ１」の正常時の動作データは、信号１が「０」、信号２が「１」、信号３が「０」、信号４が「１」、信号５が「０」である。これらを比較すると、信号２、信号３、及び信号４の３つが相違する。従って、図８（ａ）に示すＮｏ．が「Ｄ１」の相違信号集合は、｛Ｓ２ｆ、Ｓ３ｆ、Ｓ４ｆ｝となる。ここで、「Ｓ２ｆ」とは、障害発生時の動作データに係る信号２の信号値を意味する。つまり、｛Ｓ２ｆ、Ｓ３ｆ、Ｓ４ｆ｝とは、｛信号２＝３、信号３＝１、信号４＝０｝という動作データを意味している。
【００５３】
尚、図７に示すＮｏ．が「Ｙ１」の障害発生時の動作データは、信号１が「１」、信号２が「３」、信号３が「１」、信号４が「０」、信号５が「１」である。これは、図６に示すＮｏ．が「Ｘ６」の正常時の動作データと同一である。つまり、図７に示すＮｏ．が「Ｙ１」の障害発生時の動作データは、正常とみなすことができる。
図７の例では、診断対象システム２が、Ｎｏ．が「Ｙ１」の時刻までは正常な動作をしており、Ｎｏ．が「Ｙ２」の時刻において正常でない動作をした可能性があることを示している。
【００５４】
また、図８（ｂ）に示す候補条件は、図８（ａ）に示す相違信号集合に対して、特開２０１０−２１８４９２号公報に記載の仕組みを利用して算出した結果を示している。
ここで、特開２０１０−２１８４９２号公報に記載の仕組みを適用した障害診断装置５の処理の概要を説明する。障害診断装置５は、全ての相違信号集合を充足することを制約条件とし、各信号の値が障害発生条件の構成要素であることを否定する論理式に同じ重みを設定することで最大充足可能性問題の形に定式化する。次に、障害診断装置５は、最大充足可能性問題のミニマム解を算出し、算出された解を否定する論理式を制約条件として逐次追加して再度解を算出する処理を、解が存在しなくなるまで繰り返すことで、障害発生条件となり得る候補条件を算出する。尚、ミニマム解とは、データを１つでも削るとｓａｔｉｓｆｉａｂｌｅにならない解である。
【００５５】
図８（ａ）に示す相違信号集合に対しては、ミニマム解として、｛Ｓ１ｆ、Ｓ２ｆ｝と｛Ｓ２ｆ、Ｓ５ｆ｝の２つが得られる。従って、障害診断装置５は、図８（ｂ）に示すように、｛Ｓ１ｆ、Ｓ２ｆ｝（データＮｏ．が「Ｃ１」）、｛Ｓ２ｆ、Ｓ５ｆ｝（データＮｏ．が「Ｃ２」）の２つを候補条件とする。また、障害診断装置５は、その他の相違信号集合に基づいて、｛Ｓ１ｆ、Ｓ４ｆ、Ｓ５ｆ｝（データＮｏ．が「Ｃ３」）を３つ目の候補条件とする。
【００５６】
更に、障害診断装置５は、算出された全てのミニマム解の和集合を障害発生条件として決定することもできる。これは、特開２０１０−２１８４９２号公報にも記載されているように、正常時の時系列データが多くなると、ミニマム解の和集合が真の障害発生条件に近づくと考えられるからである。
しかしながら、本発明では、正常時の時系列データが事前に網羅的に（抜け漏れなく）収集することができない場合を想定していることから、ミニマム解の和集合が真の障害発生条件になるとは言い切れない。そこで、障害診断装置５は、それぞれのミニマム解を候補条件とし、「未知の障害」が発生した診断対象システム２とは異なる診断対象システム２に対して、候補条件が成立したときの動作データの収集を依頼する。
【００５７】
図９は、障害診断処理の流れを示すフローチャートである。
図９では、端末装置４ａが搭載されている診断対象システム２ａにおいて障害が検知され、端末装置４ｂ〜４ｄが搭載されている診断対象システム２ｂ〜２ｄに対して、情報収集が依頼されるものとして説明する。
【００５８】
図９に示すように、端末装置４ａは、障害を検知し、自らの診断対象システム２ａの動作データを障害診断装置５に送信する（ステップＳ１）。また、端末装置４ａは、更に、自らの診断対象システム２ａの環境を示す環境情報を障害診断装置５に送信しても良い。
【００５９】
次に、障害診断装置５は、端末装置４ａから受信する動作データに基づき、障害発生条件となり得る候補条件を決定し、候補条件をセンタＤＢ８に記憶する（ステップＳ２）。また、障害診断装置５は、端末装置４ａから受信する環境情報もセンタＤＢ８に記憶するようにしても良い。尚、障害診断装置５は、端末装置４ａから直接受信する場合に限らず、修理工場などのコンピュータから、診断対象システム２ａの動作データを受信しても良い。
【００６０】
次に、障害診断装置５は、センタＤＢ８に記憶している候補条件を「依頼候補条件情報」として複数の端末装置４ｂ〜４ｄに送信する（ステップＳ３）。「依頼候補条件情報」とは、依頼する情報収集の対象データを特定する為の候補条件を示す情報である。
【００６１】
次に、端末装置４ｂ〜４ｄは、障害診断装置５から受信する依頼候補条件情報に係る候補条件を、それぞれ端末ＤＢ７に記憶する（ステップＳ４）。そして、端末装置４ｂ〜４ｄは、端末ＤＢ７に記憶している候補条件のいずれかが成立すると、候補条件が成立した時点における自らの診断対象システム２の障害発生有無を判定し、成立した候補条件を示す成立候補条件情報、及び、障害発生有無を示す障害発生有無情報を障害診断装置５に送信する（ステップＳ５）。
【００６２】
次に、障害診断装置５は、端末装置４ｂ〜４ｄのいずれかから受信する障害発生有無情報及び成立候補条件情報に基づいて、センタＤＢ８を更新する。より詳細には、障害診断装置５は、端末装置４ｂ〜４ｄのいずれかから受信する障害発生有無情報を確認し、「障害発生無し」の場合には端末装置４ｂ〜４ｄのいずれかから受信する成立候補条件情報と一致する候補条件をセンタＤＢ８から削除し、「障害発生有り」の場合には端末装置４ｂ〜４ｄのいずれかから受信する成立候補条件情報と一致しない全ての候補条件をセンタＤＢ８から削除する（ステップＳ６）。
そして、障害診断装置５は、センタＤＢ８から削除した候補条件を示す「削除候補条件情報」を複数の端末装置４ｂ〜４ｄに送信する（ステップＳ７）。「削除候補条件情報」とは、センタＤＢ８から削除した候補条件、すなわち障害発生条件か否か判定済の候補条件を示す情報である。
【００６３】
次に、端末装置４ｂ〜４ｄは、障害診断装置５から受信する削除候補条件情報に基づいて、端末ＤＢ７を更新する（ステップＳ８）。つまり、障害診断装置５は、障害発生条件か否か判定済の候補条件を端末ＤＢ７から削除する。これによって、障害発生条件か否か判定済の候補条件については、収集対象から外すことができる。
【００６４】
尚、ステップＳ６において、障害診断装置５は、候補条件ごとに成立候補条件情報の受信数をカウントしていき、十分信頼できる数の成立候補条件情報及び障害有無情報を受信した候補条件だけをセンタＤＢ８から削除するようにしても良い。
【００６５】
図１０は、第１例におけるセンタＤＢ及び端末ＤＢの変化を示す図である。図１０に示す例では、（ａ）ステップＳ２において、障害診断装置５は、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件をセンタＤＢ８に登録する。この時点では、端末ＤＢ７に登録されている候補条件はない。
（ｂ）ステップＳ３では、障害診断装置５は、依頼候補条件情報として「Ｃ１＝｛Ｓ１ｆ，Ｓ２ｆ｝、Ｃ２＝｛Ｓ２ｆ，Ｓ５ｆ｝、Ｃ３＝｛Ｓ１ｆ，Ｓ４ｆ，Ｓ５ｆ｝」を端末装置４ｂ〜４ｄに送信する。
（ｃ）ステップＳ４において、端末装置４ｂ〜４ｄは、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件を端末ＤＢ７ｂ〜７ｄに登録する。
（ｄ）ステップＳ５において、例えば、端末装置４ｂを搭載する診断対象システム２ｂにおいて、Ｎｏ．が「Ｃ２」の候補条件が成立し、この候補条件が成立した時に診断対象システム２ｂの動作は「障害発生無し」だったとする。この場合、端末装置４ｂは、成立候補条件情報として「Ｃ２」、障害発生有無情報として「障害発生無し」を障害診断装置５に送信する。
（ｅ）ステップＳ６では、障害診断装置５は、Ｎｏ．が「Ｃ２」の候補条件をセンタＤＢ８から削除する。
（ｆ）ステップＳ７では、障害診断装置５は、削除候補条件情報として「Ｃ２」を端末装置４ｂ〜４ｄに送信する。
（ｅ）ステップＳ８では、端末装置４ｂ〜４ｄは、Ｎｏ．が「Ｃ２」の候補条件を端末ＤＢ７ｂ〜７ｄから削除する。
【００６６】
図１０に示す例では、端末装置４ｂを搭載する診断対象システム２ｂにおいて、“Ｎｏ．が「Ｃ２」の候補条件の成立時の動作は正常である。”という情報が収集され、この情報収集の結果に基づいて、障害診断装置５は、候補条件を３つから２つに絞り込むことが示されている。
更に、診断対象システム２ｂ〜２ｄのいずれかにおいて、“Ｎｏ．が「Ｃ１」の候補条件の成立時の動作は正常である。”、“Ｎｏ．が「Ｃ１」の候補条件の成立時の動作は正常でない。”、“Ｎｏ．が「Ｃ３」の候補条件の成立時の動作は正常である。”、又は、“Ｎｏ．が「Ｃ３」の候補条件の成立時の動作は正常でない。”のいずれか１つの情報が収集されれば、障害診断装置５は、障害発生条件を特定できる。
【００６７】
図１１は、第２例におけるセンタＤＢ及び端末ＤＢの変化を示す図である。
図１１に示す例では、（ａ）ステップＳ２において、障害診断装置５は、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件をセンタＤＢ８に登録する。この時点では、端末ＤＢ７に登録されている候補条件はない。
（ｂ）ステップＳ３では、障害診断装置５は、依頼候補条件情報として「Ｃ１＝｛Ｓ１ｆ，Ｓ２ｆ｝、Ｃ２＝｛Ｓ２ｆ，Ｓ５ｆ｝、Ｃ３＝｛Ｓ１ｆ，Ｓ４ｆ，Ｓ５ｆ｝」を端末装置４ｂ〜４ｄに送信する。
（ｃ）ステップＳ４において、端末装置４ｂ〜４ｄは、Ｎｏ．が「Ｃ１」〜「Ｃ３」の候補条件を端末ＤＢ７ｂ〜７ｄに登録する。
（ｄ）ステップＳ５において、例えば、端末装置４ｂを搭載する診断対象システム２ｂにおいて、Ｎｏ．が「Ｃ１」の候補条件が成立し、この候補条件が成立した時に診断対象システム２ｂの動作は「障害発生有り」だったとする。この場合、端末装置４ｂは、成立候補条件情報として「Ｃ１」、障害発生有無情報として「障害発生有り」を障害診断装置５に送信する。
（ｅ）ステップＳ６では、障害診断装置５は、Ｎｏ．が「Ｃ１」の候補条件と一致しない全ての候補条件、すなわちＮｏ．が「Ｃ２」及び「Ｃ３」の候補条件をセンタＤＢ８から削除する。
（ｆ）ステップＳ７では、障害診断装置５は、削除候補条件情報として「全て」を端末装置４ｂ〜４ｄに送信する。
（ｅ）ステップＳ８では、端末装置４ｂ〜４ｄは、全ての候補条件を端末ＤＢ７ｂ〜７ｄから削除する。
【００６８】
図１１に示す例では、端末装置４ｂを搭載する診断対象システム２ｂにおいて、“Ｎｏ．が「Ｃ１」の候補条件の成立時の動作は正常でない。”という情報が収集され、この情報収集の結果に基づいて、障害診断装置５は、候補条件を３つから１つに絞り込むことが示されている。従って、図１１に示す例では、障害診断装置５は、障害発生条件を特定できている。
【００６９】
以上、本発明の実施の形態における障害診断システム１では、前述した通り、未知の障害が発生した診断対象システム２とは異なる診断対象システム２に対して、障害診断に必要な情報収集を依頼し、情報収集の結果を回収する。依頼する情報収集の内容は、障害発生条件となり得る候補条件が成立したこと、及び、成立時の診断対象システム２の動作が「正常」又は「正常でない」のいずれであるかである。従って、本発明の実施の形態では、未知の障害に対して、障害発生条件の候補を出来る限り絞り込み、障害原因の特定に要する時間と費用を削減することができる。
【００７０】
＜変形例＞
前述の説明では、ステップＳ３において、障害診断装置５は、候補条件の送信先を、同一車種の全ての端末装置４とした。変形例では、障害診断装置５は、候補条件の送信先を、同一車種の中で一部の端末装置４に限定する。
【００７１】
変形例では、ステップＳ１において、端末装置４ａは、自らの診断対象システム２ａの動作データとともに、自らの診断対象システム２ａの環境を示す環境情報を障害診断装置５に送信する。環境情報としては、前述したように、例えば、場所情報、天候情報、道路交通状況情報などが考えられる。
そして、ステップＳ３において、障害診断装置５は、端末装置４ａから受信する環境情報と合致する環境において動作している診断対象システム２に対してのみ、依頼候補条件情報を送信する。例えば、障害診断装置５は、端末装置４ａから受信する場所情報に基づいて、積雪・寒冷地か否か、起伏が多い山間部か否か、高速道路と一般道路のいずれか、市街地と郊外のいずれか、などを判定し、環境情報と合致する環境において動作している診断対象システム２を特定する。ここで、環境が合致するか否かを判定する為の情報は、予め診断対象システム２ごとにセンタＤＢ８に登録しておいても良いし、障害診断が依頼された時に、それぞれの診断対象システム２に問合せをして収集しても良い。
【００７２】
正常時に取り得る信号値の組み合わせは、診断対象システム２が搭載されている車両の走行場所によって、現れやすさが異なることが考えられる。また、削除したい候補条件は、障害が発生した車両と同じような場所を走っている車両の方が揃いやすいと考えられる。従って、候補条件の送信先を同一車種の中で一部の端末装置４に限定しても、限定しない場合と比較して、成立候補条件情報及び障害発生有無情報の収集量はほとんど変わらない。
そして、候補条件の送信先を同一車種の中で一部の端末装置４に限定することによって、「車両１台当たりの情報収集の為の処理負荷」を軽減することができる。
【００７３】
尚、前述の説明では、障害が発生した診断対象システム２に係る端末装置４は、診断センタ３に設置されている障害診断装置５を介して、他の診断対象システム２に係る端末装置４に情報収集を依頼していたが、例えば、車車間通信や路車間通信などによって、直接的に情報収集を依頼しても良い。更に、各端末装置４が、障害診断装置５の各機能（センタＤＢ８、候補条件決定機能４１、センタＤＢ登録機能４２、情報収集依頼機能４３、結果回収機能４４、センタＤＢ更新機能４５、結果反映指示機能４６）を備える場合、障害診断装置５は不要となる。
【００７４】
また、前述の説明では、端末装置４ｂ〜４ｄは、無条件に情報収集の依頼に応答していたが、当然ながら、診断対象システム２が搭載されている車両の運転者には、事前に情報収集の同意を得ることになる。また、端末装置４ｂ〜４ｄは、車両の起動時に、情報収集をして良いか否か、運転者に問合せを行い、運転者が承諾する旨の指示をしたときのみ、情報収集の依頼に応答するようにしても良い。
本発明による情報収集は、各運転者が所有している車両と同一の車種について更なる安全運用に繋がるものである為、障害診断の依頼者ではない運転者にとっても多大なメリットがある。
【００７５】
以上、添付図面を参照しながら、本発明に係る障害診断システム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【符号の説明】
【００７６】
１………障害診断システム
２………診断対象システム
３………診断センタ
４………端末装置
５………障害診断装置
６………ネットワーク
７………端末ＤＢ
８………センタＤＢ
【特許請求の範囲】
【請求項１】
複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムにおける障害診断方法であって、
前記障害診断装置が、特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定し、前記候補条件を第１記憶領域に記憶する第１ステップと、
前記障害診断装置が、前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信する第２ステップと、
前記端末装置が、前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に記憶し、前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記候補条件が成立した時点における自らの診断対象システムの障害発生有無を判定し、成立した前記候補条件を示す成立候補条件情報、及び前記障害発生有無を示す障害発生有無情報を前記障害診断装置に送信する第３ステップと、
前記障害診断装置が、前記端末装置から受信する前記成立候補条件情報及び前記障害発生有無情報に基づいて、前記第１記憶領域を更新する第４ステップと、
を含む障害診断方法。
【請求項２】
前記第４ステップでは、前記障害診断装置が、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する
請求項１に記載の障害診断方法。
【請求項３】
前記第４ステップでは、前記障害診断装置が、更に、前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信し、
前記端末装置が、前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第５ステップ、
を更に含む請求項１又は請求項２に記載の障害診断方法。
【請求項４】
前記第１ステップにおける前記動作データは、前記特定の診断対象システムに搭載されている前記端末装置が、前記特定の診断対象システムの環境を示す環境情報とともに、前記障害診断装置に送信するものであり、
前記第２ステップでは、前記障害診断装置が、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する
請求項１乃至請求項３のいずれかに記載の障害診断方法。
【請求項５】
複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムであって、
前記障害診断装置は、
特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定する候補条件決定手段と、
前記候補条件決定手段によって決定される前記候補条件を第１記憶領域に登録する第１記憶領域登録手段と、
前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信することによって、情報収集を依頼する依頼手段と、
成立した前記候補条件を示す成立候補条件情報、及び前記候補条件が成立した時点における診断対象システムの障害発生有無を示す障害発生有無情報を前記端末装置から受信することによって、情報収集の結果を回収する回収手段と、
前記端末装置から受信する前記障害発生有無情報及び前記成立候補条件情報に基づいて、前記第１記憶領域を更新する第１記憶領域更新手段と、
を具備し、
前記端末装置は、
前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に登録する第２記憶領域登録手段と、
自らの診断対象システムの障害発生有無を検知する検知手段と、
前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記成立候補条件情報とともに、前記障害発生有無情報として前記検知手段によって検知される前記障害発生有無を前記障害診断装置に送信することによって、前記障害診断装置からの情報収集の依頼に応答する応答手段と、
を具備する障害診断システム。
【請求項６】
前記第１記憶領域更新手段は、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する
請求項５に記載の障害診断システム。
【請求項７】
前記障害診断装置は、更に、
前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信することによって、情報収集の結果の反映を指示する反映指示手段、
を具備し、
前記端末装置は、更に、
前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第２記憶領域更新手段、
を具備する請求項５又は請求項６に記載の障害診断システム。
【請求項８】
前記端末装置は、更に、
自らの診断対象システムの環境を示す環境情報とともに、自らの診断対象システムの動作データを前記障害診断装置に送信することによって、障害診断を要求する障害診断要求手段、
を具備し、
前記障害診断装置が具備する前記依頼手段は、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する
請求項５乃至請求項７のいずれかに記載の障害診断システム。
【請求項１】
複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムにおける障害診断方法であって、
前記障害診断装置が、特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定し、前記候補条件を第１記憶領域に記憶する第１ステップと、
前記障害診断装置が、前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信する第２ステップと、
前記端末装置が、前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に記憶し、前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記候補条件が成立した時点における自らの診断対象システムの障害発生有無を判定し、成立した前記候補条件を示す成立候補条件情報、及び前記障害発生有無を示す障害発生有無情報を前記障害診断装置に送信する第３ステップと、
前記障害診断装置が、前記端末装置から受信する前記成立候補条件情報及び前記障害発生有無情報に基づいて、前記第１記憶領域を更新する第４ステップと、
を含む障害診断方法。
【請求項２】
前記第４ステップでは、前記障害診断装置が、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する
請求項１に記載の障害診断方法。
【請求項３】
前記第４ステップでは、前記障害診断装置が、更に、前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信し、
前記端末装置が、前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第５ステップ、
を更に含む請求項１又は請求項２に記載の障害診断方法。
【請求項４】
前記第１ステップにおける前記動作データは、前記特定の診断対象システムに搭載されている前記端末装置が、前記特定の診断対象システムの環境を示す環境情報とともに、前記障害診断装置に送信するものであり、
前記第２ステップでは、前記障害診断装置が、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する
請求項１乃至請求項３のいずれかに記載の障害診断方法。
【請求項５】
複数の診断対象システムそれぞれに搭載される複数の端末装置、及び前記端末装置とネットワークを介して接続される障害診断装置によって構成される障害診断システムであって、
前記障害診断装置は、
特定の診断対象システムの動作データに基づいて障害発生条件となり得る候補条件を決定する候補条件決定手段と、
前記候補条件決定手段によって決定される前記候補条件を第１記憶領域に登録する第１記憶領域登録手段と、
前記第１記憶領域に記憶している前記候補条件を複数の前記端末装置に送信することによって、情報収集を依頼する依頼手段と、
成立した前記候補条件を示す成立候補条件情報、及び前記候補条件が成立した時点における診断対象システムの障害発生有無を示す障害発生有無情報を前記端末装置から受信することによって、情報収集の結果を回収する回収手段と、
前記端末装置から受信する前記障害発生有無情報及び前記成立候補条件情報に基づいて、前記第１記憶領域を更新する第１記憶領域更新手段と、
を具備し、
前記端末装置は、
前記障害診断装置から受信する前記候補条件を、前記第１記憶領域とは異なる第２記憶領域に登録する第２記憶領域登録手段と、
自らの診断対象システムの障害発生有無を検知する検知手段と、
前記第２記憶領域に記憶している前記候補条件のいずれかが成立すると、前記成立候補条件情報とともに、前記障害発生有無情報として前記検知手段によって検知される前記障害発生有無を前記障害診断装置に送信することによって、前記障害診断装置からの情報収集の依頼に応答する応答手段と、
を具備する障害診断システム。
【請求項６】
前記第１記憶領域更新手段は、前記端末装置から受信する前記障害発生有無情報を確認し、「障害発生無し」の場合には前記端末装置から受信する前記成立候補条件情報と一致する前記候補条件を前記第１記憶領域から削除し、「障害発生有り」の場合には前記端末装置から受信する前記成立候補条件情報と一致しない全ての前記候補条件を前記第１記憶領域から削除する
請求項５に記載の障害診断システム。
【請求項７】
前記障害診断装置は、更に、
前記第１記憶領域から削除した前記候補条件を示す削除候補条件情報を複数の前記端末装置に送信することによって、情報収集の結果の反映を指示する反映指示手段、
を具備し、
前記端末装置は、更に、
前記障害診断装置から受信する前記削除候補条件情報に基づいて、前記第２記憶領域を更新する第２記憶領域更新手段、
を具備する請求項５又は請求項６に記載の障害診断システム。
【請求項８】
前記端末装置は、更に、
自らの診断対象システムの環境を示す環境情報とともに、自らの診断対象システムの動作データを前記障害診断装置に送信することによって、障害診断を要求する障害診断要求手段、
を具備し、
前記障害診断装置が具備する前記依頼手段は、前記環境情報に合致する環境において動作している診断対象システムに係る前記端末装置のみに対して、前記第１記憶領域に記憶している前記候補条件を送信する
請求項５乃至請求項７のいずれかに記載の障害診断システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−１９４７２４（Ｐ２０１２−１９４７２４Ａ）
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願番号】特願２０１１−５７４５８（Ｐ２０１１−５７４５８）
【出願日】平成２３年３月１６日（２０１１．３．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＶＩＣＳ
【出願人】（０００００３６０９）株式会社豊田中央研究所 (4,200)
【Ｆターム（参考）】
【公開日】平成２４年１０月１１日（２０１２．１０．１１）
【国際特許分類】
【出願日】平成２３年３月１６日（２０１１．３．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＶＩＣＳ
【出願人】（０００００３６０９）株式会社豊田中央研究所 (4,200)
【Ｆターム（参考）】
[ Back to top ]