JP5899882B2 - 障害診断システム及び障害診断方法 - Google Patents

Description

本発明は、診断対象システムに搭載される端末装置、及び端末装置とネットワークを介して接続されるセンタ装置によって構成され、診断対象システムの障害を診断する障害診断システム等に関するものである。

近年、複数のモジュールが協調動作するシステムにおいて、システムの大規模化に伴い、障害診断が難しくなってきている。協調動作システムの一例としては、車両に搭載される車載システムがある。車載システムでは、複数のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）が、ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワークを介して互いにデータの送受信を行い、協調して動作を行っている。その為、あるＥＣＵが故障すると他のＥＣＵにも異常が伝搬してしまい、障害の診断をすることが難しい。特に、車載システムについては、ハイブリッド車や電気自動車などの登場、つながる技術（インフラ協調、隊列走行などの技術）の発展に伴い、電子制御の複雑化、大規模化が顕著になっている。

そこで、障害診断を支援するシステムの開発が望まれている。特に、特定の稀な条件が揃って初めて発生する障害の診断を支援するシステムが望まれている。特定の稀な条件が揃って発生する障害は、一般に、発生した障害現象を再現することが難しいからである。

特許文献１では、特定の稀な条件が揃って初めて発生する障害についての解決策として、障害発生条件を特定できる障害診断装置等が開示されている。特許文献１に記載の障害診断装置では、個々の障害原因に関する事前知識や診断対象のモデルに頼らず、正常時の車両動作データを活用し、障害発生条件の候補を絞り込む。すなわち、正常時の車両動作データにはないパターンを抽出することによって、障害発生条件となり得る信号の値の組み合わせを絞り込む。そして、実際の車両において、障害発生条件となり得る信号の値の組み合わせを揃えることによって、現象を再現する。

特開２０１０−２１８４９２号公報

ところで、特許文献１に記載の技術では、市場投入前のテスト走行時に正常時データを収集することを想定している。しかしながら、テスト走行時に正常時データを網羅的に収集することは難しい。特に、障害発生条件の候補を絞り込む処理の推定精度は、正常時データの網羅性に依存するため、正常時データを網羅的に収集できなければ、推定精度が悪くなる。

本発明は、前述した問題点に鑑みてなされたもので、その目的とすることは、多様な正常時データを利用可能とし、精度良く障害発生条件の候補を絞り込むことが可能な障害診断システム等を提供することである。

前述した目的を達成するために第１の発明は、診断対象システムに搭載される端末装置、及び前記端末装置とネットワークを介して接続されるセンタ装置によって構成され、前記診断対象システムの障害を診断する障害診断システムであって、前記端末装置は、正常時の前記診断対象システムの動作データである正常時データを記憶する記憶手段と、障害の検知時点の前後における前記診断対象システムの動作データを、障害時データとして前記センタ装置に送信することによって、診断依頼を行う診断依頼手段と、前記記憶手段に記憶されている前記正常時データ、及び前記センタ装置から受信する前記障害時データに基づいて、前記障害の発生条件となり得る候補条件を導出し、導出した結果を候補条件リストとし、前記候補条件リストを前記センタ装置に送信することによって、前記障害の診断依頼に対する協力を行う診断協力手段と、を具備し、前記センタ装置は、前記端末装置から受信する前記障害時データを複数の前記端末装置に送信することによって、前記診断依頼に対する協力を依頼する協力依頼手段と、複数の前記端末装置から複数の前記候補条件リストを受信すると、複数の前記候補条件リストを単一の統合リストに統合する統合手段と、を具備する障害診断システムである。第１の発明によって、多様な正常時データを利用可能とし、精度良く障害発生条件の候補を絞り込むことが可能となる。特に、第１の発明によれば、診断対象システムが、車載システム等のように個人毎に利用される場合であっても、個人のプライバシーを保護することができる。また、第１の発明によれば、システム全体の設備費用を抑えることができる。

第１の発明における前記統合手段は、複数の前記端末装置から受信する前記候補条件リストから処理対象リストを１つ特定し、更に、前記処理対象リストに含まれる前記候補条件から処理対象条件を１つ特定し、前記処理対象リストを除く他の全ての前記候補条件リストの中に前記処理対象条件の部分集合が存在する場合には、前記処理対象条件を前記統合リストに追加する、という一連の処理を、全ての前記候補条件リストに含まれる全ての前記候補条件に対して行うことが望ましい。これによって、最終的に得られる統合リストは、全ての診断対象システムの正常時データを一纏まりにしたときに導出される候補条件リストと近いものとなる。つまり、センタ装置による集中処理と比較して、推定精度の面で差がない。ひいては、推定精度を維持しながら、個人のプライバシーを保護するとともに、システム全体の設備費用を抑えることができる。

また、第１の発明における 前記端末装置は、自らが搭載されている前記診断対象システムにおける前記障害を検知する検知手段、を更に具備することが望ましい。これによって、リアルタイムに障害を検知して診断依頼を行うことができる。

第２の発明は、診断対象システムに搭載される端末装置、及び前記端末装置とネットワークを介して接続されるセンタ装置によって構成され、前記診断対象システムの障害を診断する障害診断システムにおける障害診断方法であって、前記端末装置が、正常時の前記診断対象システムの動作データである正常時データを記憶する記憶ステップと、前記端末装置が、障害の検知時点の前後における前記診断対象システムの動作データを、障害時データとして前記センタ装置に送信することによって、診断依頼を行う診断依頼ステップと、前記センタ装置が、前記端末装置から受信する前記障害時データを複数の前記端末装置に送信することによって、前記診断依頼に対する協力を依頼する協力依頼ステップと、複数の前記端末装置が、前記記憶ステップにおいて記憶されている前記正常時データ、及び前記センタ装置から受信する前記障害時データに基づいて、前記障害の発生条件となり得る候補条件を導出し、導出した結果を候補条件リストとし、前記候補条件リストを前記センタ装置に送信することによって、前記障害の診断依頼に対する協力を行う診断協力ステップと、前記センタ装置が、複数の前記端末装置から複数の前記候補条件リストを受信すると、複数の前記候補条件リストを単一の統合リストに統合する統合ステップと、を含む障害診断方法である。第２の発明によって、多様な正常時データを利用可能とし、精度良く障害発生条件の候補を絞り込むことが可能となる。特に、第２の発明によれば、診断対象システムが、車載システム等のように個人毎に利用される場合であっても、個人のプライバシーを保護することができる。また、第２の発明によれば、システム全体の設備費用を抑えることができる。

第２の発明における前記統合ステップは、複数の前記端末装置から受信する前記候補条件リストから処理対象リストを１つ特定し、更に、前記処理対象リストに含まれる前記候補条件から処理対象条件を１つ特定し、前記処理対象リストを除く他の全ての前記候補条件リストの中に前記処理対象条件の部分集合が存在する場合には、前記処理対象条件を前記統合リストに追加する、という一連の処理を、全ての前記候補条件リストに含まれる全ての前記候補条件に対して行う。これによって、最終的に得られる統合リストは、全ての診断対象システムの正常時データを一纏まりにしたときに導出される候補条件リストと近いものとなる。つまり、センタ装置による集中処理と比較して、推定精度の面で差がない。ひいては、推定精度を維持しながら、個人のプライバシーを保護するとともに、システム全体の設備費用を抑えることができる。

また、第２の発明は、前記端末装置が、自らが搭載されている前記診断対象システムにおける前記障害を検知する検知ステップ、を更に含むことが望ましい。これによって、リアルタイムに障害を検知して診断依頼を行うことができる。

本発明により、多様な正常時データを利用可能とし、精度良く障害発生条件の候補を絞り込むことが可能な障害診断システム等を提供することができる。

障害診断システムの概要を示す図 端末装置のハードウエア構成図 センタ装置のハードウエア構成図 端末装置のソフトウエア構成図 センタ装置のソフトウエア構成図 正常時データの一例を示す図 障害時データの一例を示す図 相違信号集合及び候補条件の一例を示す図 障害診断処理の流れを示すフローチャート 統合処理を説明する図 統合処理の適用例を示す図

以下図面に基づいて、本発明の実施形態を詳細に説明する。最初に図１〜図５を参照しながら、本発明の実施形態における障害診断システムの構成について説明する。

図１は、障害診断システムの概要を示す図である。図１に示すように、障害診断システム１は、複数の診断対象システム２ａ〜２ｃにそれぞれ搭載される複数の端末装置４ａ〜４ｃ、及び端末装置４ａ〜４ｃとネットワーク６を介して接続されるセンタ装置５によって構成され、診断対象システム２ａ〜２ｃの障害を診断するシステムである。センタ装置５は、例えば、障害診断業務を集中管理する診断センタ３などに設置される。ネットワーク６は、例えば、無線通信ネットワークである。

診断対象システム２ａ〜２ｃは、例えば、車両に搭載される車載システムなどである。また、端末装置４ａ〜４ｃは、例えば、障害診断処理に必要な機能を備えるＥＣＵ（Ｅｌｅｃｔｒｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：電子制御装置）などである。

診断対象システム２ａ〜２ｃには、端末装置４ａ〜４ｃや、他のＥＣＵ、各種センサ等がＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）などの車載ネットワークを介して接続されている。端末装置４ａ〜４ｃは、車載ネットワークに流れる複数の信号の値を動作データとして取得する。正常時の診断対象システム２ａ〜２ｃの動作データ（以下、「正常時データ」という。）は、搭載されている端末装置４ａ〜４ｃが記憶する。障害時の診断対象システム２ａ〜２ｃの動作データ（以下、「障害時データ」という。）は、ネットワーク６（無線通信ネットワーク）を介して遠隔にあるセンタ装置５に送信しても良いし、車両が診断センタ３或いは修理施設（不図示）に持ち込まれる場合には、有線ケーブル等を介してセンタ装置５に送信しても良い。動作データは、車載ネットワークに流れる各ＥＣＵの入出力信号や、各装置の状態値などである。

端末装置４ａ〜４ｃは、自らの診断対象システム２ａ〜２ｃの障害を検知すると、障害時データをセンタ装置５に送信することによって、障害の診断依頼を行う。これに対して、センタ装置５は、障害時データを複数の端末装置４ａ〜４ｃに送信することによって、診断依頼に対する協力を依頼する。

端末装置４ａ〜４ｃは、センタ装置５から障害時データを受信すると、予め記憶している自らの診断対象システム２ａ〜２ｃにおける正常時データに基づいて、障害の発生条件となり得る候補条件を導出し、導出した結果を候補条件リストとし、候補条件リストをセンタ装置５に送信することによって、自ら又は他の診断対象システム２ａ〜２ｃにおいて発生する障害の診断依頼に対する協力を行う。センタ装置５は、複数の端末装置４ａ〜４ｃから複数の候補条件リストを受信すると、複数の候補条件リストを単一の統合リストに統合する。

本発明の実施の形態における障害診断システム１では、市場投入後、個人が利用している診断対象システムの正常時データを収集し、それらの正常時データを利用して、障害診断を行う。従って、多様な正常時データを利用し、精度良く障害の発生条件となり得る候補条件を絞り込むことができる。

尚、診断対象システム２ａ〜２ｃ（車載システム）や端末装置４ａ〜４ｃの数は、特に限定されない。センタ装置５は、例えば、同一のカテゴリ（同一車種）ごとに、診断対象システム２ａ〜２ｃ（車載システム）の情報を管理する。以下では、診断対象システム２ａ〜２ｃを総称するときは、「診断対象システム２」と表記する。また、端末装置４ａ〜４ｃを総称するときは、「端末装置４」と表記する。また、以下では、診断対象システム２として、車載システムを例に挙げて説明する。

図２は、端末装置のハードウエア構成図である。尚、図２のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。

図２に示すように、端末装置４は、制御部１１、記憶部１２、インタフェース部１３、通信制御部１４等がバス１５を介して接続されている。

制御部１１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等によって構成される。ＣＰＵは、記憶部１２、ＲＯＭ、記録媒体等に格納されるプログラムをＲＡＭ上のワークメモリ領域に呼び出して実行し、バス１５を介して接続された各装置を駆動制御し、センタ装置５が行う後述する処理を実現する。ＲＯＭは、不揮発性メモリであり、コンピュータのブートプログラムやＢＩＯＳ等のプログラム、データ等を恒久的に保持している。ＲＡＭは、揮発性メモリであり、記憶部１２、ＲＯＭ、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部１１が各種処理を行う為に使用するワークエリアを備える。

記憶部１２は、ＨＤＤ（ハードディスクドライブ）であり、制御部１１が実行するプログラム、プログラム実行に必要なデータ、ＯＳ（オペレーティングシステム）等が格納される。プログラムに関しては、ＯＳ（オペレーティングシステム）に相当する制御プログラムや、後述する処理をコンピュータに実行させるためのアプリケーションプログラムが格納されている。これらの各プログラムコードは、制御部１１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。また、記憶部１２は、端末ＤＢ（データベース）７を有している。端末ＤＢ７には、障害診断処理に必要なデータが記憶される。

インタフェース部１３は、診断対象システム２の車載ネットワークとのインタフェースであり、診断対象システム２内に搭載される他の装置とのデータ送受信を行う。通信制御部１４は、通信制御装置やアンテナ等を有し、端末装置４とネットワーク６との通信を媒介する通信インタフェースであり、ネットワーク６を介して、センタ装置５との通信制御を行う。バス１５は、各装置間の制御信号、データ信号等の授受を媒介する経路である。

図３は、センタ装置のハードウエア構成図である。尚、図３のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。

図３に示すように、センタ装置５は、制御部２１、記憶部２２、メディア入出力部２３、通信制御部２４、入力部２５、表示部２６、周辺機器Ｉ／Ｆ部２７等が、バス２８を介して接続される。

制御部２１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等によって構成される。

ＣＰＵは、記憶部２２、ＲＯＭ、記録媒体等に格納されるプログラムをＲＡＭ上のワークメモリ領域に呼び出して実行し、バス２８を介して接続された各装置を駆動制御し、センタ装置５が行う後述する処理を実現する。ＲＯＭは、不揮発性メモリであり、コンピュータのブートプログラムやＢＩＯＳ等のプログラム、データ等を恒久的に保持している。ＲＡＭは、揮発性メモリであり、記憶部２２、ＲＯＭ、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部２１が各種処理を行う為に使用するワークエリアを備える。

記憶部２２は、ＨＤＤ（ハードディスクドライブ）であり、制御部２１が実行するプログラム、プログラム実行に必要なデータ、ＯＳ（オペレーティングシステム）等が格納される。プログラムに関しては、ＯＳ（オペレーティングシステム）に相当する制御プログラムや、後述する処理をコンピュータに実行させるためのアプリケーションプログラムが格納されている。これらの各プログラムコードは、制御部２１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。また、記憶部２２は、センタＤＢ（データベース）８を有している。センタＤＢ８には、障害診断処理に必要なデータが記憶される。尚、センタＤＢ８は、センタ装置５の記憶部２２に限らず、他のコンピュータ等の記憶部が有しても良い。

メディア入出力部２３（ドライブ装置）は、データの入出力を行い、例えば、ＣＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）、ＤＶＤドライブ（−ＲＯＭ、−Ｒ、−ＲＷ等）等のメディア入出力装置を有する。通信制御部２４は、通信制御装置、通信ポート等を有し、コンピュータとネットワーク６間の通信を媒介する通信インタフェースであり、ネットワーク６を介して、他のコンピュータ間との通信制御を行う。ネットワーク６は、有線、無線を問わない。

入力部２５は、データの入力を行い、例えば、キーボード、マウス等のポインティングデバイス、テンキー等の入力装置を有する。入力部２５を介して、コンピュータに対して、操作指示、動作指示、データ入力等を行うことができる。表示部２６は、液晶パネル等のディスプレイ装置、ディスプレイ装置と連携してコンピュータのビデオ機能を実現するための論理回路等（ビデオアダプタ等）を有する。

周辺機器Ｉ／Ｆ（インタフェース）部２７は、コンピュータに周辺機器を接続させるためのポートであり、周辺機器Ｉ／Ｆ部２７を介してコンピュータは周辺機器とのデータの送受信を行う。周辺機器Ｉ／Ｆ部２７は、ＵＳＢやＩＥＥＥ１３９４やＲＳ−２３２Ｃ等によって構成されており、通常複数の周辺機器Ｉ／Ｆを有する。周辺機器との接続形態は有線、無線を問わない。バス２８は、各装置間の制御信号、データ信号等の授受を媒介する経路である。

図４は、端末装置のソフトウエア構成図である。端末装置４が備える各種の手段は、図４に示す機能を備えるソフトウエアと、図２に示すハードウエアとが協働することによって実現されるものである。

図４に示すように、端末装置４を構成する為のソフトウエアは、正常時データ記憶機能３１、障害検知機能３２、診断依頼機能３３、診断協力機能３４等を備える。

正常時データ記憶機能３１は、端末装置４が搭載されている診断対象システム２の正常時データを記憶する。正常時データ記憶機能３１は、市場投入前のテスト走行時の正常時データ、及び市場投入後の個人利用時の正常時データの両方を記憶する。正常時データ記憶機能３１は、個人利用時、障害検知機能３２が障害を検知していない間の動作データを、正常時データとして記憶していく。

障害検知機能３２は、他のＥＣＵやセンサからＤＴＣ（ダイアグノスティック・トラブル・コード）信号が受信されたこと、又は、運転者によってインパネ（インストルメントパネル：運転席に設けられる計器盤）などに設置される障害検知用ボタンが押下されたことを検知し、自らの診断対象システム２における障害を検知する。

診断依頼機能３３は、障害検知機能３２による障害の検知時点の前後における診断対象システム２の動作データを、障害時データとしてセンタ装置５に送信することによって、診断依頼を行う。尚、データの送信方法は、無線ネットワーク等のネットワーク６を介しても良いし、有線ケーブル等を介しても良い。

診断協力機能３４は、端末ＤＢ７に記憶されている正常時データ、及びセンタ装置５から受信する障害時の診断対象システム２の動作データである障害時データに基づいて、障害の発生条件となり得る候補条件を導出し、導出した結果を候補条件リストとし、候補条件リストをセンタ装置５に送信することによって、障害の診断依頼に対する協力を行う。

ここで、「障害の発生条件」とは、障害が発生した時のＥＣＵの入出力信号や各装置の状態値などの組み合わせである。例えば、発生した正常でない現象に対して、車速を示す信号がＡｋｍ／ｈ、ＡＣＣ（車間距離制御）システムが作動中であることが障害の発生条件という具合である。また、「候補条件」とは、障害が発生した時に取り得るＥＣＵの入出力信号や各装置の状態値などの組み合わせの候補である。

本発明では、例えば、ＡＣＣ（Ａｕｔｏ Ｃｒｕｉｓｅ Ｃｏｎｔｒｏｌ：車間距離制御）システムが起動中であるにも関わらず、先行車に追従しなかったり、加速が不安定になったりするなど、ＤＴＣ信号としては未検出ではあるが、運転者が障害を検知するような「未知の障害」に関する障害診断を行う。また、本発明では、「未知の障害」が発生した診断対象システム２を含む数多くの診断対象システム２に搭載されている端末装置４が、障害の診断依頼に対する協力を行う。

図５は、センタ装置のソフトウエア構成図である。図５に示すように、センタ装置５を構成する為のソフトウエアは、協力依頼機能４１、統合機能４２、統合結果出力機能４３等を備える。センタ装置５が備える各種の手段は、図５に示す機能を備えるソフトウエアと、図３に示すハードウエアとが協働することによって実現されるものである。

協力依頼機能４１は、障害時データを複数の端末装置４に送信することによって、診断依頼に対する協力を依頼する。協力依頼先の端末装置４を特定する方法としては、例えば、協力依頼機能４１は、カテゴリ（車種）などの情報や、利用地域等の利用環境に関する情報が同一又は近い診断対象システム２を抽出し、抽出された診断対象システム２に搭載されている端末装置４を協力依頼先として特定する。

統合機能４２は、複数の端末装置４から複数の候補条件リストを受信すると、複数の候補条件リストを単一の統合リストに統合する。統合リストに含まれる候補条件が、障害診断システム１によって絞り込まれた「障害の発生条件」の候補である。統合機能４２によって、多様な正常時データを利用可能とし、精度良く障害発生条件の候補を絞り込むことが可能となる。

統合機能４２は、各診断対象システム２の正常時データを受信しないので、システム利用者（運転者）のプライバシーを保護することができる。また、各診断対象システム２の正常時データを受信しないということは、センタＤＢ８に正常時データを蓄積しないことを意味するので、大規模なデータベースシステムの導入が不要であり、システム全体の設備費用を抑えることができる。

統合結果出力機能４３は、統合機能４２によって統合された統合リストを出力する。統合結果出力機能４３は、例えば、メディア入出力部２３を介して記憶媒体に統合リストを出力しても良い。また、統合結果出力機能４３は、例えば、通信制御部２４を介して他の装置に統合リストを出力しても良い。また、統合結果出力機能４３は、例えば、表示部２６に統合リストを出力しても良い。また、統合結果出力機能４３は、例えば、周辺機器Ｉ／Ｆ部２７を介して、プリンタ等に統合リストを出力しても良い。

障害が発生した診断対象システム２に搭載されている端末装置４が正常に動作している場合、統合結果出力機能４３は、通信制御部２４を介して、この端末装置４に統合リストを送信するようにしても良い。統合リストを受信した端末装置４は、診断対象システム２の動作中、統合リストに含まれる候補条件が発生するか否かを監視し、発生した場合には、システム利用者（運転者）にその旨を通知するようにしても良い。これによって、システム利用者（運転者）は、診断対象システム２を安全に停止する等の対策を取ることができる。

次に、図６〜図８を参照しながら、診断協力機能３４によって候補条件を導出する方法の具体例について説明する。以下では、具体例として、特開２０１０−２１８４９２号公報に記載の仕組みを説明するが、本発明では特に限定されるものではない。

図６は、正常時データの一例を示す図である。車載システムの動作データは、各ＥＣＵの入出力信号について、各ＥＣＵの処理結果が変わらない範囲（例えば、プログラム中の条件分岐やジャンプ部で同じ動きをする範囲）を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものである。また、車載システムの動作データは、各装置の状態値について、各装置の状態が変わらない範囲（例えば、車両の動作が変化しない範囲）を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものである。

例えば、車速を示す信号の場合、０ｋｍ／ｈであれば０、０ｋｍ／ｈ〜５ｋｍ／ｈであれば１、５ｋｍ／ｈ〜２０ｋｍ／ｈであれば２、・・・といった具合に変換される。図６に示すように、例えば、Ｎｏ．が「Ｘ１」の正常時データは、信号１が「０」、信号２が「１」、信号３が「０」、信号４が「１」、信号５が「０」である。

図７は、障害時データの一例を示す図である。図７に示すデータは、図６に示す正常時データと同じように、同値とみなす範囲にデータの値を分割して変換し、同一時刻ごとに纏めたものである。障害時データは、データ容量を圧縮する為、データの組み合わせが変化する時刻のみを抽出するようにしても良い。

図８は、相違信号集合及び候補条件の一例を示す図である。相違信号集合とは、障害時データと正常時データとを比較したときに、値が相違する信号群を示す集合である。図８（ａ）に示す相違信号集合は、図７に示すＮｏ．が「Ｙ２」の障害時データと、図６に示す全ての正常時データとを比較した結果を示している。

図７に示すＮｏ．が「Ｙ２」の障害時データは、信号１が「０」、信号２が「３」、信号３が「１」、信号４が「０」、信号５が「０」である。一方、図６に示すＮｏ．が「Ｘ１」の正常時データは、信号１が「０」、信号２が「１」、信号３が「０」、信号４が「１」、信号５が「０」である。これらを比較すると、信号２、信号３、及び信号４の３つが相違する。従って、図８（ａ）に示すＮｏ．が「Ｄ１」の相違信号集合は、｛Ｓ（２）、Ｓ（３）、Ｓ（４）｝となる。ここで、「Ｓ（２）」とは、障害時データに係る信号２の信号値を意味する。つまり、｛Ｓ（２）、Ｓ（３）、Ｓ（４）｝とは、｛信号２＝３、信号３＝１、信号４＝０｝という動作データを意味している。

また、図７に示すＮｏ．が「Ｙ１」の障害時データは、信号１が「１」、信号２が「３」、信号３が「１」、信号４が「０」、信号５が「１」である。これは、図６に示すＮｏ．が「Ｘ６」の正常時データと同一である。つまり、図７に示すＮｏ．が「Ｙ１」の障害時データは、正常とみなすことができる。

図７の例では、診断対象システム２が、Ｎｏ．が「Ｙ１」の時刻までは正常な動作をしており、Ｎｏ．が「Ｙ２」の時刻において正常でない動作をした可能性があることを示している。

また、図８（ｂ）に示す候補条件は、図８（ａ）に示す相違信号集合に対して、特開２０１０−２１８４９２号公報に記載の仕組みを利用して、端末装置４が算出した結果を示している。端末装置４は、全ての相違信号集合を充足することを制約条件とし、各信号の値が障害発生条件の構成要素であることを否定する論理式に同じ重みを設定することで最大充足可能性問題の形に定式化する。次に、端末装置４は、最大充足可能性問題のミニマム解を算出し、算出された解を否定する論理式を制約条件として逐次追加して再度解を算出する処理を、解が存在しなくなるまで繰り返すことで、障害発生条件となり得る候補条件を算出する。尚、ミニマム解とは、データを１つでも削るとｓａｔｉｓｆｉａｂｌｅにならない解である。

図８（ａ）に示す相違信号集合に対しては、ミニマム解として、｛Ｓ（１）、Ｓ（２）｝と｛Ｓ（２）、Ｓ（５）｝と｛Ｓ（１）、Ｓ（４）、Ｓ（５）｝の３つが得られる。従って、端末装置４は、図８（ｂ）に示すように、｛Ｓ（１）、Ｓ（２）｝（データＮｏ．が「Ｃ１」）、｛Ｓ（２）、Ｓ（５）｝（データＮｏ．が「Ｃ２」）、｛Ｓ（１）、Ｓ（４）、Ｓ（５）｝（データＮｏ．が「Ｃ３」）の３つを候補条件とする。

そして、端末装置４は、図８（ｂ）に示す３つの候補条件を候補条件リストとし、候補条件リストをセンタ装置５に送信する。

次に、図９〜図１１を参照しながら、本発明の実施の形態における障害診断システムの処理について説明する。

図９は、障害診断処理の流れを示すフローチャートである。図９では、端末装置４ａが搭載されている診断対象システム２ａにおいて障害が検知され、端末装置４ｂ〜４ｃが搭載されている診断対象システム２ｂ〜２ｃに対して、障害診断の診断依頼がなされるものとして説明する。

図９に示すように、端末装置４ａは、障害を検知すると（ステップＳ１）、障害の検知時点の前後における診断対象システム２ａの動作データを、障害時データとしてセンタ装置５に送信する（ステップＳ２）。

次に、センタ装置５は、協力依頼先の端末装置４を特定し（ステップＳ３）、障害時データを協力依頼先の端末装置４に送信する（ステップＳ４）。図９に示す例では、センタ装置５は、障害時データを端末装置４ａ、４ｂ、４ｃにそれぞれ送信する。

次に、端末装置４（４ａ、４ｂ、４ｃ）は、障害の発生条件となり得る候補条件を導出し（ステップＳ５）、候補条件リストをセンタ装置５に送信する（ステップＳ６）。

次に、センタ装置５は、複数の候補条件リストを、単一の統合リストに統合し（ステップＳ７）、統合リストを出力する（ステップＳ８）。図９に示す例では、センタ装置５は、端末装置４ａ、４ｂ、４ｃから、それぞれ候補条件リストを受信する。

図１０は、統合処理を説明する図である。図１０に示す処理は、センタ装置５の制御部２１（統合機能４２）によって実行される。

センタ装置５の制御部２１は、複数の候補条件リストの集合から、処理対象リストを１つ特定する（ステップＳ１１）。また、制御部２１は、処理対象リストに含まれる複数の候補条件の集合から、処理対象条件を１つ特定する（ステップＳ１２）。

次に、制御部２１は、処理対象リストを除く他の全ての候補条件リストの中に、処理対象条件の部分集合（但し、φ集合は除く。）が存在するか否かを判定する（ステップＳ１３）。ステップＳ１３の判定結果がＹｅｓの場合、制御部２１は、ステップＳ１４に進む。ステップＳ１３の判定結果がＮｏの場合、制御部２１は、ステップＳ１６に進む。

ステップＳ１４では、制御部２１は、処理対象条件が統合リストに登録済か否かを判定する。ステップＳ１４の判定結果がＹｅｓの場合、制御部２１は、ステップＳ１６に進む。ステップＳ１４の判定結果がＮｏの場合、制御部２１は、処理対象条件を統合リストに追加し（ステップＳ１５）、ステップＳ１６に進む。

ステップＳ１６では、制御部２１は、全ての候補条件について処理が終了したか否かを判定する。ステップＳ１６の判定結果がＹｅｓの場合、制御部２１は、ステップＳ１７に進む。ステップＳ１６の判定結果がＮｏの場合、制御部２１は、ステップＳ１２から処理を繰り返す。尚、２回目以降のステップＳ１２では、制御部２１は、処理対象条件として特定済の候補条件を除いた候補条件の集合から、処理対象条件を１つ特定する。

ステップＳ１７では、制御部２１は、全ての候補条件リストについて処理が終了したか否かを判定する。ステップＳ１７の判定結果がＹｅｓの場合、制御部２１は、処理を終了する。ステップＳ１７の判定結果がＮｏの場合、制御部２１は、ステップＳ１１から処理を繰り返す。尚、２回目以降のステップＳ１１では、制御部２１は、処理対象リストとして特定済の候補条件リストを除いた候補条件リストの集合から、処理対象条件を１つ特定する。

ここで、ステップＳ１３の判定条件の意義について説明する。以下では、候補条件を導出する方法は、特開２０１０−２１８４９２号公報に記載の仕組みを適用したものとする。

説明の前提として、最終的に得られる統合リストは、全ての診断対象システム２の正常時データを一纏まりにしたときに導出される候補条件リストと近いものとなることが望ましいものとする。このような統合リストであれば、センタ装置５による集中処理によって導出された候補条件リスト（以下、「集中処理による候補条件リスト」と記載する。）と比較して、推定精度の面で差がないからである。そして、ひいては、推定精度を維持しながら、個人のプライバシーを保護するとともに、システム全体の設備費用を抑えることができるからである。

ある端末装置４が記憶している正常時データの集合をＵとし、その端末装置４によって導出された候補条件リストをＬとする。

まず、「候補条件リストＬの中に、処理対象条件の部分集合が存在しない」（命題１）が成り立つならば、「障害時データと同じ値の組合せを持つデータが、正常時データの集合Ｕに存在する」（命題２）が成り立つ。このことが成り立つ理由は、候補条件を導出する方法が、特開２０１０−２１８４９２号公報に記載の仕組みだからである。

次に、命題２が成り立つならば、明らかに、「障害時データと同じ値の組合せを持つデータが、全ての端末装置４が記憶している正常時データを纏めた集合に存在する」（命題３）が成り立つ。

そして、命題３が成り立つならば、「全ての端末装置４が記憶している正常時データを纏めた集合を用いて導出された候補条件リストには、処理対象条件が含まれない」（命題４）が成り立つ。

ここで、統合リストを集中処理による候補条件リストに近いものにするためには、命題４が成り立つような処理対象条件を統合リストに含めない方が望ましい。つまり、遡って考えれば、命題１がいずれかの候補条件リストＬにおいて成り立つ場合、処理対象条件を統合リストに含めない方が望ましい。

以上から、ステップ１３の判定条件「処理対象リストを除く他の全ての候補条件リストの中に、処理対象条件の部分集合が存在する」が成り立つ場合のみ、処理対象条件を統合リストに追加することが望ましい。

図１１は、統合処理の適用例を示す図である。図１１に示す例では、診断対象システム２ａに障害が発生したものとする。また、端末装置４ａ、４ｂ及び４ｃが障害診断に協力し、候補条件リストをセンタ装置５に送信したものとする。そして、センタ装置５が、３つの候補条件リストを１つの統合リストに統合したものとする。

まず、端末装置４ａの候補条件リストにおける１件目の候補条件｛Ｓ（２１）｝に着目し、ステップＳ１３の処理を説明する。センタ装置５は、ステップＳ１３において、端末装置４ｂの候補条件リスト、及び端末装置４ｃの候補条件リストの中に、｛Ｓ（２１）｝の部分集合が存在するか否か判定する。端末装置４ｃの候補条件リストの１件目には、｛Ｓ（２１）｝が存在する。一方、端末装置４ｂの候補条件リストには、｛Ｓ（２１）｝の部分集合が存在しない。従って、センタ装置５は、ステップＳ１３の判定結果をＮｏとし、｛Ｓ（２１）｝を統合リストに追加しない。

次に、端末装置４ａの候補条件リストにおける５件目の候補条件｛Ｓ（３３），Ｓ（４１）｝に着目し、ステップＳ１３の処理を説明する。センタ装置５は、ステップＳ１３において、端末装置４ｂの候補条件リスト、及び端末装置４ｃの候補条件リストの中に、｛Ｓ（３３），Ｓ（４１）｝の部分集合が存在するか否か判定する。端末装置４ｃの候補条件リストの３件目には、｛Ｓ（３３），Ｓ（４１）｝の部分集合である｛Ｓ（３３）｝が存在する。一方、端末装置４ｂの候補条件リストには、｛Ｓ（３３），Ｓ（４１）｝の部分集合が存在しない。従って、センタ装置５は、ステップＳ１３の判定結果をＮｏとし、｛Ｓ（３３），Ｓ（４１）｝を統合リストに追加しない。

次に、端末装置４ｂの候補条件リストにおける２件目の候補条件｛Ｓ（２），Ｓ（２１）｝に着目し、ステップＳ１３の処理を説明する。センタ装置５は、ステップＳ１３において、端末装置４ａの候補条件リスト、及び端末装置４ｃの候補条件リストの中に、｛Ｓ（２），Ｓ（２１）｝の部分集合が存在するか否か判定する。端末装置４ａの候補条件リストの１件目には、｛Ｓ（２），Ｓ（２１）｝の部分集合である｛Ｓ（２１）｝が存在する。また、端末装置４ｃの候補条件リストの１件目にも、｛Ｓ（２），Ｓ（２１）｝の部分集合である｛Ｓ（２１）｝が存在する。従って、センタ装置５は、ステップＳ１３の判定結果をＹｅｓとし、｛Ｓ（２），Ｓ（２１）｝を統合リストに追加する。

次に、端末装置４ｃの候補条件リストにおける４件目の候補条件｛Ｓ（２３），Ｓ（３５），Ｓ（４１）｝に着目し、ステップＳ１３の処理を説明する。センタ装置５は、ステップＳ１３において、端末装置４ａの候補条件リスト、及び端末装置４ｂの候補条件リストの中に、｛Ｓ（２３），Ｓ（３５），Ｓ（４１）｝の部分集合が存在するか否か判定する。端末装置４ａの候補条件リストの３件目には、｛Ｓ（２３），Ｓ（３５），Ｓ（４１）｝の部分集合である｛Ｓ（３５）｝及び｛Ｓ（２３）｝が存在する。また、端末装置４ｃの候補条件リストの６件目にも、｛Ｓ（２３），Ｓ（３５），Ｓ（４１）｝の部分集合である｛Ｓ（３５），Ｓ（４１）｝が存在する。従って、センタ装置５は、ステップＳ１３の判定結果をＹｅｓとし、｛Ｓ（２３），Ｓ（３５），Ｓ（４１）｝を統合リストに追加する。

このように、センタ装置５は、複数の端末装置４から受信する候補条件リストから処理対象リストを１つ特定し、更に、処理対象リストに含まれる候補条件から処理対象条件を１つ特定し、処理対象リストを除く他の全ての候補条件リストの中に処理対象条件の部分集合が存在する場合には、処理対象条件を統合リストに追加する、という一連の処理を、全ての候補条件リストに含まれる全ての候補条件に対して行う。

図１１に示す例では、統合リストには、｛Ｓ（２），Ｓ（２１）｝、及び｛Ｓ（２３），Ｓ（３５），Ｓ（４１）｝の２件のみが含まれている。仮に、正常時データが、自らの車載システムのみ、すなわち端末装置４ａの１台分のみの収集結果である場合、図１１に示す端末装置４ａの候補条件リスト、すなわち６件までしか絞り込みができないことになる。また、従来技術のように、正常時データが、市場投入前のテスト走行時の収集結果である場合も、図１１に示す統合リストよりも絞り込み結果が多くなってしまうことは容易に推測できる。このように、図１０に示す統合処理によれば、１台のみの正常時データを用いる場合や、市場投入前のテスト走行時の正常時データを用いる場合よりも、障害発生条件の絞り込みを精度良く行うことができる。

以上説明したように、本発明の実施の形態における障害診断システムは、正常時データを１箇所に集めて障害発生条件の候補を求めるのではなく、各診断対象システムの端末装置が、自らが記憶している正常時データを使って候補条件を導出し、導出結果を統合リストとして統合する。従って、本発明の実施の形態によれば、多様な正常時データを利用でき、従来よりも精度良く、効率的な障害診断システムの実現が可能となる。

また、本発明の実施の形態における障害診断システムは、各診断対象システムの正常時データを受信しないので、システム利用者のプライバシーを保護することができる。また、各診断対象システムの正常時データを受信しないということは、診断センタに正常時データを蓄積しないことを意味するので、大規模なデータベースシステムの導入が不要であり、システム全体の設備費用を抑えることができる。

以上、添付図面を参照しながら、本発明に係る障害診断システム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

１………障害診断システム
２（２ａ、２ｂ、２ｃ）………診断対象システム
３………診断センタ
４（４ａ、４ｂ、４ｃ）………端末装置
５………センタ装置
６………ネットワーク
７………端末ＤＢ（データベース）
８………センタＤＢ（データベース）

Claims (6)

1. 診断対象システムに搭載される端末装置、及び前記端末装置とネットワークを介して接続されるセンタ装置によって構成され、前記診断対象システムの障害を診断する障害診断システムであって、
   前記端末装置は、
   正常時の前記診断対象システムの動作データである正常時データを記憶する記憶手段と、
   障害の検知時点の前後における前記診断対象システムの動作データを、障害時データとして前記センタ装置に送信することによって、診断依頼を行う診断依頼手段と、
   前記記憶手段に記憶されている前記正常時データ、及び前記センタ装置から受信する前記障害時データに基づいて、前記障害の発生条件となり得る候補条件を導出し、導出した結果を候補条件リストとし、前記候補条件リストを前記センタ装置に送信することによって、前記障害の診断依頼に対する協力を行う診断協力手段と、
   を具備し、
   前記センタ装置は、
   前記端末装置から受信する前記障害時データを複数の前記端末装置に送信することによって、前記診断依頼に対する協力を依頼する協力依頼手段と、
   複数の前記端末装置から複数の前記候補条件リストを受信すると、複数の前記候補条件リストを単一の統合リストに統合する統合手段と、
   を具備する障害診断システム。
2. 前記統合手段は、複数の前記端末装置から受信する前記候補条件リストから処理対象リストを１つ特定し、更に、前記処理対象リストに含まれる前記候補条件から処理対象条件を１つ特定し、前記処理対象リストを除く他の全ての前記候補条件リストの中に前記処理対象条件の部分集合が存在する場合には、前記処理対象条件を前記統合リストに追加する、という一連の処理を、全ての前記候補条件リストに含まれる全ての前記候補条件に対して行う請求項１に記載の障害診断システム。
3. 前記端末装置は、
   自らが搭載されている前記診断対象システムにおける前記障害を検知する検知手段、
   を更に具備する請求項１又は請求項２に記載の障害診断システム。
4. 診断対象システムに搭載される端末装置、及び前記端末装置とネットワークを介して接続されるセンタ装置によって構成され、前記診断対象システムの障害を診断する障害診断システムにおける障害診断方法であって、
   前記端末装置が、正常時の前記診断対象システムの動作データである正常時データを記憶する記憶ステップと、
   前記端末装置が、障害の検知時点の前後における前記診断対象システムの動作データを、障害時データとして前記センタ装置に送信することによって、診断依頼を行う診断依頼ステップと、
   前記センタ装置が、前記端末装置から受信する前記障害時データを複数の前記端末装置に送信することによって、前記診断依頼に対する協力を依頼する協力依頼ステップと、
   複数の前記端末装置が、前記記憶ステップにおいて記憶されている前記正常時データ、及び前記センタ装置から受信する前記障害時データに基づいて、前記障害の発生条件となり得る候補条件を導出し、導出した結果を候補条件リストとし、前記候補条件リストを前記センタ装置に送信することによって、前記障害の診断依頼に対する協力を行う診断協力ステップと、
   前記センタ装置が、複数の前記端末装置から複数の前記候補条件リストを受信すると、複数の前記候補条件リストを単一の統合リストに統合する統合ステップと、
   を含む障害診断方法。
5. 前記統合ステップは、複数の前記端末装置から受信する前記候補条件リストから処理対象リストを１つ特定し、更に、前記処理対象リストに含まれる前記候補条件から処理対象条件を１つ特定し、前記処理対象リストを除く他の全ての前記候補条件リストの中に前記処理対象条件の部分集合が存在する場合には、前記処理対象条件を前記統合リストに追加する、という一連の処理を、全ての前記候補条件リストに含まれる全ての前記候補条件に対して行う請求項４に記載の障害診断方法。
6. 前記端末装置が、自らが搭載されている前記診断対象システムにおける前記障害を検知する検知ステップ、
   を更に含む請求項４又は請求項５に記載の障害診断方法。

Images