JP2013120143A - 異常診断システム及び異常診断方法 - Google Patents

Abstract

【課題】車両の異常を精度良く、効率的に、かつリアルタイムに診断する異常診断システム等を提供する。
【解決手段】診断車両装置１２ａは、診断対象データを検知すると（Ｓ１）、診断対象データをセンタ装置１３に送信する（Ｓ２）。センタ装置１３は、診断対象データを受信し、診断依頼を受け付け（Ｓ３）、診断対象データが希有事象か否かを判定し（Ｓ４）、判定結果に基づいて診断車両２ａが異常か否かを決定し（Ｓ５）、診断結果を診断車両装置１２ａに送信する（Ｓ６）。診断車両装置１２ａは、受信する診断結果が「異常」であるか否かを確認し（Ｓ７）、診断結果が「異常」である場合、出力装置２４によって警告を出力し（Ｓ８）、診断結果が「正常」である場合、診断対象データを正常データとして正常データＤＢ４３に登録する（Ｓ９）。
【選択図】図９

Description

本発明は、車両の異常を診断する異常診断システム等に関するものである。

近年、車両には様々なＥＣＵ（Electronic Control Unit）が搭載されている。ＥＣＵ同士は、ＣＡＮ（Controller Area Network）等のネットワークを介して互いにデータの送受信を行い、協調して動作を行っている。その為、あるＥＣＵが故障すると、他のＥＣＵにも異常な状態が伝搬してしまう可能性があり、異常を診断することが難しい。そこで、車両の異常を精度良く診断するシステムが望まれている。

例えば、非特許文献１には、水車・発電機軸受が正常振動している際の各センサ情報の値の組み合わせを正常状態のデータとみなし、この正常状態データから外れた状態データの蓄積が異常予兆となると考えることによって、水力発電所の水車・発電機軸受異常振動の予兆を検出する技術が開示されている。

また、例えば、特許文献１には、障害を検知し、障害発生条件の候補を導出後、正常に動作している他の同一システム（同一車種）を活用して障害発生条件の候補を削除する仕組みが開示されている。

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

小野田 崇著 「Ｏｎｅ−Ｃｌａｓｓ ＳＶＭに基づく水力発電所におけるリスクマネジメント」オペレーションズ・リサーチ : 経営の科学 51(11), 683-688、社団法人日本オペレーションズ・リサーチ学会、２００６年１１月

しかしながら、非特許文献１に記載の技術を車両に適用しようとすると、以下の問題点がある。
（１）学習用の正常データを予め網羅的に集めることが難しい。
（２）データ不足の状況では、異常診断の精度改善に限界がある。
（３）データ不足の状況では誤診断が多くなる為、リアルタイムに異常を診断してドライバに知らせるという運用ができない。

また、特許文献１に記載の技術では、以下のような懸念点がある。
（１）端末装置において障害を検出する際の条件を更新しなければ、同じ障害を検出し続けて、センタへの問い合わせが繰り返し発生してしまう可能性がある。
（２）障害診断に協力する車両において条件候補の発生をモニタする際、稀にしか発生しない現象は長時間待ち続ける必要があり、効率的ではない。

本発明は、前述した問題点に鑑みてなされたもので、その目的とすることは、車両の異常を精度良く、効率的に、かつリアルタイムに診断する異常診断システム等を提供することである。

前述した目的を達成するために第１の発明は、車両の異常を診断する異常診断システムであって、車両の走行データを記憶する記憶部と、診断対象の走行データである診断対象データを入力する入力部と、前記記憶部に記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域を生成し、前記高密度領域と前記診断対象データとを比較し、前記診断対象データが希有事象又は頻出事象のいずれであるかを判定する判定部と、前記判定部による判定結果に基づいて、車両が異常か否かを決定する診断部と、前記診断部による診断結果を出力する出力部と、を備える異常診断システムである。第１の発明によって、車両の異常を精度良く、効率的に、かつリアルタイムに診断することができる。第１の発明では、市場を走行する多くの車両に関する市場走行データを利用して異常診断処理を実行するので、従来技術の課題であったデータ不足を補うことができ、精度良く診断することができる。

第１の発明における車両に搭載されている車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成され、前記センタ装置は、前記入力部として、前記診断対象データを受信することによって、診断の依頼を受け付ける受付手段と、診断の協力依頼先の車両である協力車両を選定する選定手段と、前記協力車両に係る前記車両装置に前記診断対象データを送信することによって、診断の協力を依頼する協力依頼手段と、を備え、前記車両装置は、前記記憶部として、自車の走行データを記憶する記憶手段と、前記判定部として、前記記憶手段に記憶されている走行データ群について、前記高密度領域を生成し、前記高密度領域と前記診断対象データとを比較し、前記診断対象データが希有事象又は頻出事象のいずれであるかを判定し、判定結果を前記センタ装置に送信することによって、診断に協力する協力手段と、を備え、前記センタ装置は、更に、前記診断部として、前記車両装置から受信する前記判定結果を統合し、車両が異常か否かを決定する診断手段と、前記出力部として、前記診断手段による診断結果を、前記診断対象データに係る車両に搭載されている前記車両装置に送信することによって、診断結果を出力する診断結果出力手段と、を備えることが望ましい。これによって、それぞれの車両装置が自車の走行データを管理し、希有事象判定処理を行うので、通信コストや通信負荷を必要最低限に抑えることができ、効率的になる。

第１の発明における前記車両装置が備える前記記憶手段は、更に、正常時の走行データである正常データを記憶し、前記センタ装置から受信する診断結果が「正常」である場合、前記診断対象データを前記正常データとして記憶することが望ましい。これによって、正常と判断された診断対象データは、車両装置に正常データとして反映されるので、誤検出の数を減らし、センタ装置への診断依頼を減らすことができ、効率的になる。

第１の発明における前記診断部によって車両が異常と決定される場合には、異常の要因特定処理を行う要因特定部、を更に備えることが望ましい。これによって、異常診断処理のみならず、異常の要因特定処理も実行するので、異常が発生したときに、その異常の要因をリアルタイムに特定することができる。

第１の発明における前記車両装置が備える前記記憶手段は、更に、正常時の走行データである正常データを記憶し、前記車両装置は、前記要因特定部の一部として、前記記憶手段に記憶されている前記正常データ、及び前記診断対象データに基づいて、異常の発生条件となり得る要因候補を抽出し、抽出した結果を要因候補リストとする要因候補抽出手段と、前記要因特定部の一部として、前記要因候補リストについて、自車の車両における発生有無を検索し、検索結果を前記センタ装置に送信することによって、前記要因候補の絞込に協力する要因候補絞込協力手段と、を更に備え、前記センタ装置は、前記要因特定部の一部として、前記協力車両に係る前記車両装置から受信する前記検索結果から、前記協力車両において発生している前記要因候補を前記要因候補リストから削除することによって、前記要因候補を絞り込む要因候補絞込手段、を更に備えることが望ましい。これによって、それぞれの車両装置が正常データや自車の走行データを管理し、希有事象判定処理及び要因候補抽出処理を行うので、通信コストや通信負荷を必要最低限に抑えることができ、効率的になる。

第１の発明における前記センタ装置が備える前記診断手段は、希有事象判定の前記協力車両の割合、又は頻出事象判定の前記協力車両の割合のいずれかと、閾値とを比較することによって、車両が異常か否かを決定することが望ましい。これによって、“市場走行の車両において、少数でも同様の事象が発生していれば、全体としては希有事象ではなく、異常でもない”と考える場合の統合条件によって、判定結果の統合が可能となる。

第１の発明における前記センタ装置が備える前記診断手段は、希有事象判定の前記協力車両の割合、又は頻出事象判定の前記協力車両の割合のいずれかと、第１の閾値とを比較することによって、車両が異常か、又はそれ以外かを決定し、更に、車両が異常と決定されない場合には、所定の期間内に、頻出事象判定の前記協力車両の割合が、前記第１の閾値とは異なる第２の閾値を超える場合、車両が正常と決定することが望ましい。これによって、“より安全側に考えて、「確実に異常」、「確実に正常」、「異常可能性あり」の３種類に分類する”と考える場合の統合条件によって、判定結果の統合が可能となる。

第１の発明における前記センタ装置が備える前記診断手段は、希有事象判定の前記協力車両の割合、又は頻出事象判定の前記協力車両の割合のいずれかと、第１の閾値とを比較することによって、車両が異常か、又はそれ以外かを決定し、更に、車両が異常と決定されない場合には、頻出事象判定の前記協力車両に前記診断対象データが前記正常データとして記憶されている場合、車両が正常と決定することが望ましい。これによって、“「異常可能性あり」と判定した場合でも、頻出事象判定車両の少なくとも１台において、診断対象データと同様のデータ（＝全ての変数が同じ値を持つデータ）が正常データＤＢに含まれている場合、過去に正常判定されているとみなす”と考える場合の統合条件によって、判定結果の統合が可能となる。

第１の発明における前記センタ装置が備える前記診断結果出力手段は、更に、前記診断手段による診断結果を、前記協力車両に搭載されている前記車両装置に送信することが望ましい。これによって、協力車両装置が、診断対象データの検出に用いる正常データＤＢの更新を行うようにすれば、協力車両における誤検出の数を減らし、センタ装置への診断依頼を減らすことができ、効率的になる。

第２の発明は、車両に搭載されている車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成され、車両の異常を診断する異常診断システムにおける異常診断方法であって、前記センタ装置又は前記車両装置が、診断対象の走行データである診断対象データを入力する入力ステップと、前記センタ装置又は前記車両装置が、予め記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域を生成し、前記高密度領域と前記診断対象データとを比較し、前記診断対象データが希有事象又は頻出事象のいずれであるかを判定する判定ステップと、前記センタ装置が、前記判定ステップにおける判定結果に基づいて、車両が異常か否かを決定する診断ステップと、前記センタ装置が、前記診断ステップにおける診断結果を出力する出力ステップと、を含む異常診断方法である。第２の発明によって、車両の異常を精度良く、効率的に、かつリアルタイムに診断することができる。第２の発明では、市場を走行する多くの車両に関する市場走行データを利用して異常診断処理を実行するので、従来技術の課題であったデータ不足を補うことができ、精度良く診断することができる。

本発明により、車両の異常を精度良く、効率的に、かつリアルタイムに診断する異常診断システム等を提供することができる。

異常診断システムの全体構成を示す図 車両装置のハードウエア構成図 コンピュータのハードウエア構成図 第１実施形態における異常診断ＥＣＵのソフトウエア構成図 第１実施形態におけるセンタ装置のソフトウエア構成図 データ変換処理を説明する図 観測領域の一例を示す図 高密度領域の一例を示す図 第１実施形態における異常診断処理を示すフローチャート 第２実施形態における異常診断ＥＣＵのソフトウエア構成図 第２実施形態におけるセンタ装置のソフトウエア構成図 第２実施形態における異常診断処理を示すフローチャート 第２実施形態における統合条件を説明する図 第２実施形態における異常診断処理の変形例を示すフローチャート 第３実施形態における異常診断ＥＣＵのソフトウエア構成図 第３実施形態におけるセンタ装置のソフトウエア構成図 正常データの一例を示す図 診断対象データの一例を示す図 相違信号集合及び要因候補の一例を示す図 第３実施形態における異常診断処理を示すフローチャート

以下図面に基づいて、本発明の実施形態を詳細に説明する。最初に図１〜図３を参照しながら、本発明の全ての実施形態に共通する異常診断システムのハードウエア構成について説明する。

図１は、異常診断システムの全体構成を示す図である。図１に示すように、異常診断システム１は、複数の車両２にそれぞれ搭載される複数の車両装置１２、及び車両装置１２とネットワーク９を介して接続されるセンタ装置１３によって構成され、車両２の異常を診断するシステムである。センタ装置１３は、異常診断業務を統括する診断センタ３等に設置される。

車両装置１２とセンタ装置１３との間のデータ通信の経路は、様々な経路が存在する。第１の経路は、車両２が路上等を走行中又は停車中の場合に用いられる。第１の経路では、車両装置１２は、無線通信によって、ネットワーク９を介してセンタ装置１３とのデータ通信を行う。

第２の経路は、車両２がディーラ店４に停車中の場合に用いられる。第２の経路では、車両装置１２は、有線通信又は無線通信によって、ディーラ店４に設置されているディーラＰＣ（Personal Computer）１４と接続され、ディーラＰＣ１４及びネットワーク９を介してセンタ装置１３とのデータ通信を行う。

第３の経路は、車両２が家庭５に停車中の場合に用いられる。第３の経路では、車両装置１２は、有線通信又は無線通信によって、家庭５に設置されている家庭ＰＣ１５と接続され、家庭ＰＣ１５及びネットワーク９を介してセンタ装置１３とのデータ通信を行う。

第４の経路は、車両２が路上等を走行中又は停車中の場合に用いられる。第４の経路では、車両装置１２は、無線通信によって、路上等に設置されている路側器７と接続される。路側器７は、サブセンタ６（異常診断業務の一部を担う。）に設置されているサブセンタＰＣ１６と接続される。サブセンタＰＣ１６は、ネットワーク９を介してセンタ装置１３とのデータ通信を行う。

データ通信の経路は、車両２の周辺環境や状態に応じて適切なものが選択される。以下では、車両装置１２とセンタ装置１３とのデータ通信は、第１の経路から第４の経路のいずれか最適なものによって実現されるものとして説明する。

図２は、車両装置のハードウエア構成図である。車両装置１２は、少なくとも、送受信装置２１、異常診断ＥＣＵ（Electronic Control Unit）２２、及びその他のＥＣＵ群２５を備える。また、車両装置１２は、入力装置２３及び出力装置２４を備えても良い。異常診断ＥＣＵ２２、入力装置２３、出力装置２４、及びＥＣＵ群２５は、ＣＡＮ（Controller Area Network）２６等を介して互いにデータの送受信を行い、協調して動作を行っている。

送受信装置２１は、他のコンピュータ等からデータを受信するとともに、他のコンピュータ等にデータを送信する。異常診断ＥＣＵ２２は、異常診断処理を実行するＥＣＵである。異常診断ＥＣＵ２２の動作の詳細は、実施形態ごとに後述する。

入力装置２３は、ボタン、スイッチ、タッチパネル等であり、運転者からのデータ入力を受け付ける。出力装置２４は、液晶ディスプレイ、有機ＥＬディスプレイ、ヘッドマウントディスプレイ等の表示装置２４ａや、音を出力するスピーカ２４ｂ等である。

ＥＣＵ群２５は、例えば、ドアの開閉やウィンドウの開閉を制御するドア制御ＥＣＵ２５ａ、車内や車外の温度、設定温度等に基づき空調制御を行うエアコンＥＣＵ２５ｂ、駐車中の車両への振動や車内への侵入を検知するセキュリティＥＣＵ２５ｃ、エンジンの運転状態を検知し、燃料噴射制御や点火時期制御、アイドル回転数制御を行うエンジンＥＣＵ２６、車両２に登録されているキーを管理し、キーの認証を行い、エンジン始動を許可する照合ＥＣＵ２５ｅ、道路地図を表示し、経路案内を行うカーナビＥＣＵ２５ｆ等が含まれる。尚、図２に示すＥＣＵは一例である。本発明は、異常診断ＥＣＵ２２を除き、車両２に搭載されているＥＣＵ群２５を何ら限定するものではない。

図３は、コンピュータのハードウエア構成図である。図１に示すセンタ装置１３、ディーラＰＣ１４、家庭ＰＣ１５、サブセンタＰＣ１６は、図３に示すコンピュータ１１によって実現される。尚、図３のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。

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

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

記憶部３２は、ＨＤＤ（Hard Disk Drive）等であり、制御部３１が実行するプログラム、プログラム実行に必要なデータ、ＯＳ（Operating System）等が格納される。プログラムに関しては、ＯＳに相当する制御プログラムや、後述する処理をコンピュータ１１に実行させるためのアプリケーションプログラムが格納されている。これらの各プログラムコードは、制御部３１により必要に応じて読み出されてＲＡＭに移され、ＣＰＵに読み出されて各種の手段として実行される。

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

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

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

＜第１実施形態＞
次に、図４〜図９を参照しながら、第１実施形態について説明する。第１実施形態では、センタ装置１３が、市場における車両２の走行データ（以下、「市場走行データ」という。）を集中管理し、車両２の異常を診断する。つまり、第１実施形態の異常診断システム１は、センタ装置１３による集中管理型のシステムと言える。尚、走行データとは、各ＥＣＵの内部データやＣＡＮ２６上を流れている各種の信号等である。

まず、図４及び図５を参照しながら、ソフトウエア構成について説明する。図４は、第１実施形態における異常診断ＥＣＵのソフトウエア構成図である。図４に示すように、異常診断ＥＣＵ２２は、診断対象データ検出機能４１、診断依頼機能４２、正常データＤＢ（DataBase）４３、自車走行データＤＢ４４等を備える。

診断対象データ検出機能４１は、自車の車両２の診断対象データを検出する機能である。診断対象データとは、異常診断システム１において診断の対象となる走行データであり、異常の可能性があるデータである。診断対象データ検出機能４１は、例えば、定期的に走行データを取得し、取得される走行データが正常データＤＢ４３に記憶されているか否かを確認し、正常データＤＢ４３に記憶されていない場合、異常の可能性があると判定し、診断対象データとして検出する。また、定期的に走行データを取得することに代えて、診断対象データ検出機能４１は、例えば、いずれかのＥＣＵからダイアグノスティックトラブルコードが出力されたり、運転者が何らかの異常を感じ、入力装置２３を介して異常である旨が入力されたりすると、走行データを取得し、正常データＤＢ４３に記憶されているか否かを確認するようにしても良い。

診断依頼機能４２は、センタ装置１３に診断を依頼する機能である。診断依頼機能４２は、診断対象データ検出機能４１によって検出される診断対象データをセンタ装置１３に送信することによって、診断を依頼する。

正常データＤＢ４３は、自車および自車と同車種の車両２における正常時の走行データ（以下、「正常データ」という。）を記憶する。正常データＤＢ４３には、市場に投入される前の試験時の走行データ（以下、「試験走行データ」という。）の中で正常データとして判断されるデータが予め記憶される。また、正常データＤＢ４３には、市場走行データの中で正常データとして判断されるデータも記憶されていく。

自車走行データＤＢ４４は、自車の車両２における走行データ（以下、「自車走行データ」という。）を記憶する。自車走行データＤＢ４４には、正常データか否かに依らず、自車走行データが記憶されていく。

図５は、第１実施形態におけるセンタ装置のソフトウエア構成図である。図５に示すように、センタ装置１３は、診断依頼受付機能５１、希有事象判定機能５２、診断機能５３、診断結果出力機能５４、市場走行データ収集機能５５、市場走行データＤＢ５６等を備える。

診断依頼受付機能５１は、診断対象データが検出され、診断対象となる車両２（以下、「診断車両２ａ」という。）の車両装置１２（以下、「診断車両装置１２ａ」という。）から、診断依頼を受け付ける機能である。診断依頼受付機能５１は、診断車両装置１２ａから診断対象データを受信することによって、診断の依頼を受け付ける。

希有事象判定機能５２は、診断依頼受付機能５１によって受信される診断対象データが希有事象又は頻出事象のいずれであるかを判定する機能である。希有事象判定機能５２は、市場走行データＤＢ５６に記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域を生成し、高密度領域と診断対象データとを比較し、診断対象データが希有事象又は頻出事象のいずれであるかを判定する。希有事象判定機能５２の詳細は、図６〜図８を参照しながら後述する。

診断機能５３は、診断車両２ａが異常か否かを決定する機能である。診断機能５３は、希有事象判定機能５２による判定結果に基づいて、診断車両２ａが異常か否かを決定する。

診断結果出力機能５４は、診断機能５３による診断結果を出力する機能である。診断結果出力機能５４は、例えば、センタ装置１３の表示部３６等に診断結果を出力したり、診断車両装置１２ａに診断結果を送信し、診断依頼に応答したりする。

市場走行データ収集機能５５は、市場を走行している車両２群から、市場走行データを収集する機能である。市場走行データ収集機能５５は、図１に示す各データ通信経路を介して、車両装置１２から市場走行データを収集する。

市場走行データＤＢ５６は、車種ごとに、市場走行データを記憶する。市場走行データＤＢ５６が、様々な走行環境において走行している車両２の市場走行データを記憶していくことによって、希有事象判定機能５２及び診断機能５３の精度が向上する。尚、市場走行データＤＢ５６には、正常データだけでなく、異常の可能性があるデータも含まれる。

次に、図６〜図８を参照しながら、希有事象判定機能５２による希有事象判定処理の一例について説明する。図６は、希有事象判定処理の前処理であるデータ変換処理を説明する図である。図７は、観測領域の一例を示す図である。図８は、高密度領域の一例を示す図である。

本発明では、高密度領域を生成するために、例えば、特開２０１１−９５８７８号公報に記載の技術を用いる。以下、特開２０１１−９５８７８号公報に記載の技術を本発明における異常診断システム１に適用する場合の処理内容について説明する。

センタ装置１３の制御部３１は、希有事象判定処理を行う前処理として、観測データ７１を変換する。ここで、観測データ７１は、試験走行データや市場走行データ等の総称である。具体的には、観測データ７１は、複数の要素を含み、各車両２において同時に観測されるデータパターンである。例えば、観測データ７１は、ある時刻に観測される車速、回転数、ＡＣＣ(Auto Cruse Control)のＯＮ／ＯＦＦなどの複数要素のデータパターンである。観測データ７１に含まれる要素は、車速、回転数のような数値データ、ＡＣＣのＯＮ／ＯＦＦのようなカテゴリデータのいずれかに区分される。

センタ装置１３の制御部３１は、観測データ７１に含まれる要素に対して様々な加工処理を施して所定の範囲の整数値とする。観測データ７１に含まれる要素が数値データの場合、センタ装置１３の制御部３１は、細かく区切って離散化し、デジタル化する。センタ装置１３の制御部３１は、必要に応じて、正規化や対数変換などを行う。加工処理の詳細は、特開２０１１−９５８７８号公報に記載されているため、説明を省略する。

次に、センタ装置１３の制御部３１は、各整数値をビットデータに変換し、カテゴリカルデータが上位、数値データが下位となるように並び替えを行う。並び替えの意義は、特開２０１１−９５８７８号公報に記載されているため、説明を省略する。

図６に示す観測データ７１は、センタ装置１３の制御部３１が加工処理を行うことによって、０〜７の整数値に変換されている。図６に示す観測データ７１では、ｘ１とｘ２の２つの要素を含み、ｘ１とｘ２の両方とも数値データである。

ビットデータ７２のｄ１〜ｄ３は、観測データ７１のｘ１を２進数に変換した各ビットの値である。また、ビットデータ７２のｅ１〜ｅ３は、観測データ７１のｘ２を２進数に変換した各ビットの値である。例えば、観測データ７１ａの場合、ｘ１が「６」、ｘ２が「２」なので、ｄ１が「１」、ｄ２が「１」、ｄ３が「０」、ｅ１が「０」、ｅ２が「１」、ｅ３が「０」のビットデータ７２ａとなる。以下では、ビット列に対して順位の概念を導入する。そして、ｄ１とｅ１のように最も左端のビットを「最上位ビット」（ＭＳＢ:Most Significant Bit）、ｄ３とｅ３のように最も右端のビットを「最下位ビット」（ＬＳＢ：Least Significant Bit）と呼ぶこととする。

図６に示すように、ビットデータ７２は、ｘ１に対応するビット列がｄ１、ｄ２、ｄ３、ｘ２に対応するビット列がｅ１、ｅ２、ｅ３の順に並んでいる。これに対して、センタ装置１３の制御部３１は、各ビットデータ７２の最上位ビットから最下位ビットまで、順位ごとに纏めて、ｄ１->ｅ１->ｄ２->ｅ２->ｄ３->ｅ３と並び替えたビット列である変換データ７３を生成する。例えば、ビットデータ７２ａの場合、センタ装置１３の制御部３１は、１->０->１->１->０->０と並び替えた変換データ７３ａを生成する。

次に、センタ装置１３の制御部３１は、生成された変換データ７３に基づいて、図７に示す観測領域６４を構築する。図７に示す観測領域６４は、二分決定グラフとして構築されている。二分決定グラフの詳細は、特開２０１１−９５８７８号公報に記載されているため、説明を省略する。

図７では、実線で示すＴｈｅｎ枝（変換データ７３のビットの値が「１」に対応する枝）、間隔が広い点線で示すＥｌｓｅ枝（変換データ７３のビットの値が「０」に対応する枝）、「＊」（アスタリスク）を付した間隔が狭い点線で示す否定Ｅｌｓｅ枝の３つを用いて、二分決定グラフを構築している。例えば、図６に示す変換データ７３のｄ１は、ブーリアン変数とみなすことができ、ノード６５に対応している。また、６６は最も上位のノード（ルートノード）、６７は定数ノードである。

次に、センタ装置１３の制御部３１は、図７に示す観測領域６４から、図８に示す高密度領域６８を生成する。ここで、高密度領域６８の生成処理の一例を説明する。まず、センタ装置１３の制御部３１は、二分決定グラフとして構築されている観測領域６４の各ノードにおける最小項の数を算出する。次に、センタ装置１３の制御部３１は、変換データ７３におけるビット数をｎとするときに、最小項の数を２のｎ乗によって除する値を各ノードにおける密度として算出する。次に、センタ装置１３の制御部３１は、観測領域６４の各枝に対して、接続先のノードにおける密度が予め定める閾値よりも高く、かつ接続元のノードよりも接続先のノードのレベルが高い場合には、接続先を定数ノードに変更する。より詳細な内容は、特開２０１１−９５８７８号公報に記載されている。

「ノードのレベル」について説明を加える。センタ装置１３の制御部３１は、観測データ７１に含まれる数値データの最上位ビットに対応するノードをレベル１とし、各数値データのビット列の順位ごとにレベルを分けて前述の処理を実行する。ルートノードやカテゴリカルデータのビットに対応するノードについては、レベル０とする。図６に示すビットデータ７２では、ビット数が３なので、最上位ビットに対応するノードがレベル１、次のビットに対応するノードがレベル２、最下位ビットに対応するノードがレベル３となる。

図８では、高密度領域６８に対応する二分決定グラフと、高密度領域６８を表す平面図が示されている。平面図において、黒色のマスは、観測領域６４に含まれているデータ領域を示している。また、×印が付されているマスは、高密度領域６８の生成処理の結果、高密度に発生していると判定されたデータ領域を示している。高密度領域６８は、黒色のマス、及び×印が付されているマスの両方を含むデータ領域を意味する。

このように生成される高密度領域６８に対して、センタ装置１３の制御部３１は、高密度領域６８と診断対象データとを比較する。そして、センタ装置１３の制御部３１は、診断対象データが高密度領域６８に属する場合、頻出事象と判定し、診断対象データが高密度領域６８に属さない場合、希有事象と判定する。

特開２０１１−９５８７８号公報に記載されている通り、二分決定グラフを用いて高密度領域６８を生成する手法は、計算速度及び精度の面において優れており、車両の異常を精度良く、リアルタイムに診断することを可能とする。特に、観測領域６４は、市場走行データＤＢ５６のデータ蓄積に応じて広がっていく為、第１実施形態によれば、センタ装置１３による希有事象判定処理の精度が向上し、ひいては、車両の異常を精度良く診断することが可能となる。

尚、本発明では、ある走行データの集合から、高密度に発生しているデータ領域を高密度領域６８として推定すれば良く、特開２０１１−９５８７８号公報に記載の手法以外を適用しても良い。例えば、十分に走行データが収集されている場合であれば、最も単純な手法として、センタ装置１３の制御部３１は、観測領域６４をそのまま高密度領域６８としても良い。また、その他の手法としては、センタ装置１３の制御部３１は、公知の１クラス問題に対する手法、例えば、１クラスＳＶＭ（Support Vector Machine）等を用いても良い。

次に、図９を参照しながら、第１実施形態における異常診断処理について説明する。図９は、第１実施形態における異常診断処理を示すフローチャートである。

図９に示すように、診断車両装置１２ａの異常診断ＥＣＵ２２は、診断対象データを検知すると（Ｓ１）、診断対象データをセンタ装置１３に送信する（Ｓ２）。

センタ装置１３の制御部３１は、診断対象データを受信し、診断依頼を受け付ける（Ｓ３）。次に、センタ装置１３の制御部３１は、診断対象データが希有事象か否かを判定し（Ｓ４）、判定結果に基づいて診断車両２ａが異常か否かを決定する（Ｓ５）。

ここで、センタ装置１３の診断機能５３について説明を加える。センタ装置１３の制御部３１は、市場走行データＤＢ５６から全ての走行データを抽出し、観測領域６４を構築し、更に高密度領域６８を生成する。このように生成される高密度領域６８は、単純に、走行データ（正常か異常か不明なデータ）が高密度に発生している領域である。ほとんどの場合、頻出事象であれば「正常」、希有事象であれば「異常（又は異常の可能性あり）」と判定できると考えられる。

しかし、全ての希有事象を「異常」と決定できない場合もあるので、希有事象と判定された診断対象データについては継続的に監視を続けたり、実車の検査を行ったりして、詳細な調査を行うことが望ましい。そして、「正常」か「異常」のいずれであるかを示す調査結果は、センタ装置１３の記憶部３２に記憶させ、診断機能５３による異常診断に反映することが望ましい。

また、全ての頻出事象を「正常」と決定できない場合もあるので、頻出事象と判定された診断対象データと同様のデータ（＝全ての変数が同じ値を持つデータ）について、他の車両２からも同様の依頼が来るか否かを監視することが望ましい。仮に、統計的に有意な数の車両２から同様の依頼が来る場合、頻出事象の「異常」の可能性があるので、詳細な調査を行うことが望ましい。そして、「正常」か「異常」のいずれであるかを示す調査結果は、センタ装置１３の記憶部３２に記憶させ、診断機能５３による異常診断に反映することが望ましい。

以上から、センタ装置１３の制御部３１は、記憶部３２に記憶されている調査結果を参照し、例えば、（１）確実に異常、（２）確実に正常、（３）それ以外、等に分けて、診断結果を生成する。

図９の説明に戻る。センタ装置１３の制御部３１は、診断結果を診断車両装置１２ａに送信する（Ｓ６）。診断車両装置１２ａの異常診断ＥＣＵ２２は、受信する診断結果が「異常」であるか否かを確認する（Ｓ７）。診断結果が「異常」である場合、診断車両装置１２ａの異常診断ＥＣＵ２２は、出力装置２４によって警告を出力する（Ｓ８）。一方、診断結果が「正常」である場合、診断車両装置１２ａの異常診断ＥＣＵ２２は、診断対象データを正常データとして正常データＤＢ４３に登録する（Ｓ９）。尚、診断結果が「正常」及び「異常」のいずれでもない場合、センタ装置１３の制御部３１は、安全側に判断し、Ｓ８の処理を行う（但し、警告内容は変えても良い。）。

以上の通り、第１実施形態では、センタ装置１３による集中管理型の異常診断システム１によって、車両２の異常を精度良く、効率的に、かつリアルタイムに診断することができる。具体的には、市場を走行する多くの車両２から市場走行データを収集し、異常診断処理を実行するので、従来技術の課題であったデータ不足を補うことができ、精度良く診断することができる。また、正常と判断された診断対象データは、診断車両装置１２ａの正常データＤＢ４３に正常データとして反映されるので、誤検出の数を減らし、センタ装置１３への診断依頼を減らすことができ、効率的になる。ひいては、異常診断システム１全体の負荷が低減されるので、車両２に重大異常が発生した際にも、リアルタイムに運転者に通知することが可能となる。

＜第２実施形態＞
次に、図１０〜図１４を参照しながら、第２実施形態について説明する。第２実施形態では、それぞれの車両装置１２が、自車の市場走行データを分散管理し、車両２の異常を診断する。つまり、第２実施形態の異常診断システム１は、複数の車両装置１２による分散管理型のシステムと言える。以下、第１実施形態と同様の構成要素については同じ符号を付し、重複説明を省略する。

まず、図１０及び図１１を参照しながら、ソフトウエア構成について説明する。図１０は、第２実施形態における異常診断ＥＣＵのソフトウエア構成図である。図１０に示すように、異常診断ＥＣＵ２２は、診断対象データ検出機能４１、診断依頼機能４２、協力依頼受付機能４５、希有事象判定機能４６、正常データＤＢ４３、自車走行データＤＢ４４等を備える。診断対象データ検出機能４１、診断依頼機能４２、正常データＤＢ４３、及び自車走行データＤＢ４４は、第１実施形態における図４と同様である。

協力依頼受付機能４５は、センタ装置１３からの協力依頼を受け付ける機能である。協力依頼受付機能４５は、センタ装置１３から診断対象データを受信することによって、協力依頼を受け付ける。

希有事象判定機能４６は、協力依頼受付機能４５によって受信される診断対象データが希有事象又は頻出事象のいずれであるかを判定する機能である。希有事象判定機能５２は、自車走行データＤＢ４４に記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域６８を生成し、高密度領域６８と診断対象データとを比較し、診断対象データが希有事象又は頻出事象のいずれであるかを判定し、判定結果をセンタ装置に送信することによって、診断に協力する。希有事象判定機能４６の詳細は、図６〜図８を参照しながら説明した通りである。

図１１は、第２実施形態におけるセンタ装置のソフトウエア構成図である。図１１に示すように、センタ装置１３は、診断依頼受付機能５１、協力車両選定機能５７、協力依頼機能５８、診断機能５３ａ、診断結果出力機能５４等を備える。診断依頼受付機能５１及び診断結果出力機能５４は、第１実施形態における図５と同様である。

協力車両選定機能５７は、診断の協力依頼先の車両２（以下、「協力車両２ｂ」という。）を選定する機能である。協力車両選定機能５７は、例えば、診断車両２ａと同車種の車両２を協力車両２ｂとして選定する。尚、協力車両選定機能５７は、診断車両２ａも協力車両２ｂとして選定しても良い。

協力依頼機能５８は、協力車両２ｂの車両装置１２（以下、「協力車両装置１２ｂ」という。）に診断の協力を依頼する機能である。協力依頼機能５８は、協力車両装置１２ｂに診断対象データを送信することによって、診断の協力を依頼する。

診断機能５３ａは、診断車両２ａが異常か否かを決定する機能である。診断機能５３ａは、協力車両装置１２ｂから受信する判定結果を統合し、診断車両２ａが異常か否かを決定する。

次に、図１２を参照しながら、第２実施形態における異常診断処理について説明する。図１２は、第２実施形態における異常診断処理を示すフローチャートである。

図１２に示すように、診断車両装置１２ａの異常診断ＥＣＵ２２は、診断対象データを検知すると（Ｓ１１）、診断対象データをセンタ装置１３に送信する（Ｓ１２）。

センタ装置１３の制御部３１は、診断対象データを受信し、診断依頼を受け付ける（Ｓ１３）。次に、センタ装置１３の制御部３１は、複数の協力車両２ｂを選定し（Ｓ１４）、診断対象データを複数の協力車両装置１２ｂに送信する（Ｓ１５）。

それぞれの協力車両装置１２ｂの異常診断ＥＣＵ２２は、診断対象データが希有事象か否か判定し（Ｓ１６）、判定結果をセンタ装置１３に送信する（Ｓ１７）。これに対して、センタ装置１３の制御部３１は、判定結果を統合し、診断車両２ａが異常か否か決定する（Ｓ１８）。

ここで、センタ装置１３の診断機能５３ａについて説明を加える。センタ装置１３の制御部３１は、複数の判定結果を受信するので、互いに矛盾する結果を受信する場合がある。つまり、一部の協力車両装置１２ｂは希有事象と判定し、他の協力車両装置１２ｂは頻出事象と判定する場合がある。そこで、判定結果の統合条件を３つ例示する。センタ装置１３の制御部３１は、統合条件に従って判定結果を統合し、診断車両２ａが異常か否か決定する。

図１３は、第２実施形態における統合条件を説明する図である。図１３（ａ）は、第１の統合条件を説明する図である。“市場走行の車両２において、少数でも同様の事象が発生していれば、全体としては希有事象ではなく、異常でもない”と考える場合、１種類の閾値を用いて判定結果を統合する。例えば、希有事象と判定した協力車両２ｂ（以下、「希有事象判定車両」という。）の割合が閾値（９９％）を下回る場合、センタ装置１３の制御部３１は、診断対象データは頻出事象であり、診断車両２ａは正常と判定する。また、閾値（９９％）以上の場合、センタ装置１３の制御部３１は、診断対象データが希有事象であり、診断車両２ａが異常と判定する。裏を返せば、頻出事象と判定した協力車両２ｂ（以下、「頻出事象判定車両」という。）の割合が閾値（１％）を超える場合、センタ装置１３の制御部３１は、診断対象データが頻出事象であり、診断車両２ａが正常と判定する。また、閾値（１％）以下の場合、センタ装置１３の制御部３１は、診断対象データが希有事象であり、診断車両２ａが異常と判定する。尚、第１の統合条件によって異常と判定された診断車両２ａについては、人手による確認をするため、専門家に連絡し、解析を依頼することが望ましい。

図１３（ｂ）は、第２の統合条件を説明する図である。“より安全側に考えて、「確実に異常」、「確実に正常」、「異常可能性あり」の３種類に分類する”と考える場合、２種類の閾値を用いて判定結果を統合する。まず、センタ装置１３の制御部３１は、第１閾値（９９％）に基づき、「確実に異常」、又は「それ以外」（＝「異常可能性あり」及び「正常」）の判定を行う。第１閾値（９９％）によって「それ以外」と判定した場合、センタ装置１３の制御部３１は、「異常（仮）」と仮判定して、経過観察を行う。所定の期間内に、頻出事象判定車両の割合が第２閾値（５０％）を超える場合、センタ装置１３の制御部３１は、判定結果を「確実に正常」（頻出）に確定する。一方、所定の期間内に、頻出事象判定車両の割合が第２閾値（５０％）を超えない場合、センタ装置１３の制御部３１は、判定結果を「異常可能性あり」に確定する。尚、第２の統合条件によって「異常可能性あり」と判定された診断車両２ａについては、人手による確認をするため、専門家に連絡し、解析を依頼することが望ましい。

図１３（ｃ）は、第３の統合条件を説明する図である。“「異常可能性あり」と判定した場合でも、頻出事象判定車両の少なくとも１台において、診断対象データと同様のデータ（＝全ての変数が同じ値を持つデータ）が正常データＤＢ４３に含まれている場合、過去に正常判定されているとみなす”と考える場合、第２の統合条件の第１閾値（＝第１の統合条件の閾値）による判定後、診断対象データの検索処理を行う。つまり、第１閾値（９９％）によって「それ以外」と判定した場合、センタ装置１３の制御部３１は、頻出事象判定車両の車両装置１２に対して診断対象データの検索処理を依頼する。頻出事象判定車両の車両装置１２は、自らの正常データＤＢ４３を検索し、診断対象データが記憶されているか否かを判定する。診断対象データが記憶されている場合、頻出事象判定車両の車両装置１２は、その旨をセンタ装置１３に送信する。センタ装置１３の制御部３１は、少なくとも１台の車両装置１２から、診断対象データが記憶されている旨を受信した場合、診断対象データが誤って検出されたものであり、診断車両２ａが正常と判定する。尚、全ての頻出事象判定車両の正常データＤＢ４３に診断対象データが記憶されていない場合、第２の統合条件と同様、センタ装置１３の制御部３１は、第２閾値による判定を行う。

図１２の説明に戻る。センタ装置１３の制御部３１は、診断結果を診断車両装置１２ａに送信する（Ｓ１９）。診断車両装置１２ａの異常診断ＥＣＵ２２は、受信する診断結果が「異常」であるか否かを確認する（Ｓ２０）。診断結果が「異常」である場合、診断車両装置１２ａの異常診断ＥＣＵ２２は、出力装置２４によって警告を出力する（Ｓ２１）。一方、診断結果が「正常」である場合、診断車両装置１２ａの異常診断ＥＣＵ２２は、診断対象データを正常データとして正常データＤＢ４３に登録する（Ｓ２２）。尚、診断結果が「正常」及び「異常」のいずれでもない場合、センタ装置１３の制御部３１は、安全側に判断し、Ｓ２１の処理を行う（但し、警告内容は変えても良い。）。

次に、第２実施形態の変形例について説明する。図１２に示すフローチャートでは、センタ装置１３の制御部３１は、判定結果を診断車両装置１２ａのみに送信している。このような構成に加え、センタ装置１３の制御部３１は、更に、判定結果を協力車両装置１２ｂにも送信し、正常データＤＢ４３の更新を指示してもよい。以下では、図１４を参照しながら、この変形例について説明する。図１４は、第２実施形態における異常診断処理の変形例を示すフローチャートである。

図１４に示すように、センタ装置１３の制御部３１は、診断結果を協力車両装置１２ｂに送信する（Ｓ２３）。協力車両装置１２ｂの異常診断ＥＣＵ２２は、診断結果が異常か否かを確認する（Ｓ２４）。

診断結果が異常の場合（Ｓ２４のＹｅｓ）、協力車両装置１２ｂの異常診断ＥＣＵ２２は、正常データＤＢ４３を検索し、診断対象データが存在すれば削除する（Ｓ２５）。これは、自車走行データＤＢ４４内に存在しなくても、正常データＤＢ４３内に存在する可能性があるからである。

診断結果が正常の場合（Ｓ２４のＮｏ）、協力車両装置１２ｂの異常診断ＥＣＵ２２は、正常データＤＢ４３を検索し、診断対象データが存在しなければ登録する（Ｓ２６）。これは、自車走行データＤＢ４４内に存在しても、正常データＤＢ４３内に存在しない可能性があるからである。

以上の通り、第２実施形態では、複数の車両装置１２による分散管理型の異常診断システム１によって、車両２の異常を精度良く、効率的に、かつリアルタイムに診断することができる。具体的には、市場を走行する多くの車両２の市場走行データに基づいて異常診断処理を実行するので、従来技術の課題であったデータ不足を補うことができ、精度良く診断することができる。また、正常と判断された診断対象データは、診断車両装置１２ａの正常データＤＢ４３に正常データとして反映されるので、誤検出の数を減らし、センタ装置１３への診断依頼を減らすことができ、効率的になる。ひいては、異常診断システム１全体の負荷が低減されるので、車両２に重大異常が発生した際にも、リアルタイムに運転者に通知することが可能となる。

更に、第２実施形態では、それぞれの車両装置１２が自車の走行データを管理し、希有事象判定処理を行うので、通信コストや通信負荷を必要最低限に抑えることができ、効率的になる。

また、第２実施形態における変形例では、判定結果を協力車両装置１２ｂにも送信し、正常データＤＢ４３の更新を行うので、協力車両装置１２ｂにおける誤検出の数も減らし、センタ装置１３への診断依頼を減らすことができ、効率的になる。

＜第３実施形態＞
次に、図１５〜図２０を参照しながら、第３実施形態について説明する。第３実施形態では、異常診断処理のみならず、異常の要因特定処理も行う。以下、第２実施形態における分散管理型の異常診断システム１において、異常の要因特定処理を行う場合を説明する。以下、第１実施形態及び第２実施形態と同様の構成要素については同じ符号を付し、重複説明を省略する。

まず、図１５及び図１６を参照しながら、ソフトウエア構成について説明する。図１５は、第３実施形態における異常診断ＥＣＵのソフトウエア構成図である。図１５に示すように、異常診断ＥＣＵ２２は、診断対象データ検出機能４１、要因候補抽出機能４７、要因候補絞込依頼機能４８、要因候補絞込協力機能４９、正常データＤＢ４３、自車走行データＤＢ４４等を備える。診断対象データ検出機能４１、正常データＤＢ４３、及び自車走行データＤＢ４４は、第２実施形態における図１０と同様である。

要因候補抽出機能４７は、正常データＤＢ４３に記憶されている正常データ、及び診断対象データ検出機能４１によって検出されている診断対象データに基づいて、異常の発生条件となり得る要因候補を抽出し、抽出した結果を要因候補リストとする。要因候補抽出機能４７の詳細は、図１７〜図１９を参照しながら後述する。

要因候補絞込依頼機能４８は、センタ装置１３に要因候補の絞込を依頼する機能である。要因候補絞込依頼機能４８は、センタ装置１３に要因候補リストを送信することによって、要因候補の絞込を依頼する。

要因候補絞込協力機能４９は、センタ装置１３からの要因候補の絞込に協力する機能である。要因候補絞込協力機能４９は、センタ装置１３から受信する要因候補リストについて、自車の車両２における発生有無を検索し、検索結果をセンタ装置１３に送信することによって、要因候補の絞込に協力する。

図１６は、第３実施形態におけるセンタ装置のソフトウエア構成図である。図１６に示すように、センタ装置１３は、要因候補絞込依頼受付機能５９、協力車両選定機能５７、協力依頼機能５８、要因候補絞込機能６０、要因候補絞込結果出力機能６１等を備える。協力車両選定機能５７及び協力依頼機能５８は、第２実施形態における図１１と同様である。

要因候補絞込依頼受付機能５９は、診断車両装置１２ａから、要因候補の絞込依頼を受け付ける機能である。要因候補絞込依頼受付機能５９は、診断車両装置１２ａから要因候補リストを受信することによって、要因候補の絞込依頼を受け付ける。

要因候補絞込機能６０は、協力車両装置１２ｂから受信する検索結果から、要因候補を絞り込む機能である。要因候補絞込機能６０は、協力車両２ｂにおいて発生している要因候補を要因候補リストから削除することによって、要因候補を絞り込む。

要因候補絞込結果出力機能６１は、要因候補絞込機能６０による要因候補の絞込結果を出力する機能である。要因候補絞込結果出力機能６１は、例えば、センタ装置１３の表示部３６等に絞込結果を出力したり、診断車両装置１２ａに絞込結果を送信し、絞込依頼に応答したりする。

次に、図１７〜図１９を参照しながら、要因候補抽出機能４７による要因候補抽出処理の一例について説明する。図１７は、正常データの一例を示す図である。図１８は、診断対象データの一例を示す図である。図１９は、相違信号集合及び要因候補の一例を示す図である。

本発明では、要因候補を抽出するために、例えば、特開２０１０−２１８４９２号公報に記載の技術を用いる。以下、特開２０１０−２１８４９２号公報に記載の技術を本発明における異常診断システム１に適用する場合の処理内容について説明する。

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

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

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

相違信号集合とは、診断対象データと正常データとを比較したときに、値が相違する信号群を示す集合である。図１９（ａ）に示す相違信号集合は、図１８に示すＮｏ．が「Ｙ２」の診断対象データと、図１７に示す全ての正常データとを比較した結果を示している。

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

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

図１８の例では、診断車両２ａが、Ｎｏ．が「Ｙ１」の時刻までは正常な動作をしており、Ｎｏ．が「Ｙ２」の時刻において正常でない動作をした可能性があることを示している。

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

図１９（ａ）に示す相違信号集合に対しては、ミニマム解として、｛Ｓ（１）、Ｓ（２）｝と｛Ｓ（２）、Ｓ（５）｝と｛Ｓ（１）、Ｓ（４）、Ｓ（５）｝の３つが得られる。従って、診断車両装置１２ａの異常診断ＥＣＵ２２は、図１９（ｂ）に示すように、｛Ｓ（１）、Ｓ（２）｝（データＮｏ．が「Ｃ１」）、｛Ｓ（２）、Ｓ（５）｝（データＮｏ．が「Ｃ２」）、｛Ｓ（１）、Ｓ（４）、Ｓ（５）｝（データＮｏ．が「Ｃ３」）の３つを要因候補とする。

そして、診断車両装置１２ａの異常診断ＥＣＵ２２は、図１９（ｂ）に示す３つの要因候補を要因候補リストとし、要因候補リストをセンタ装置１３に送信することによって、要因候補の絞込を依頼する。

次に、図２０を参照しながら、第３実施形態における異常診断処理について説明する。図２０は、第３実施形態における異常診断処理を示すフローチャートである。

図２０に示すように、診断車両装置１２ａの異常診断ＥＣＵ２２は、診断対象データを検知する（Ｓ３１）。

診断車両装置１２ａの異常診断ＥＣＵ２２は、要因候補を抽出し（Ｓ３２）、要因候補リストをセンタ装置１３に送信する（Ｓ３３）。

センタ装置１３の制御部３１は、要因候補リストを受信し、絞込依頼を受け付ける（Ｓ３４）。次に、センタ装置１３の制御部３１は、複数の協力車両２ｂを選定し（Ｓ３５）、要因候補リストを複数の協力車両装置１２ｂに送信する（Ｓ３６）。

それぞれの協力車両装置１２ｂの異常診断ＥＣＵ２２は、要因候補リストに含まれる要因候補が自車の車両２において発生しているか否かを検索する（Ｓ３７）。具体的には、協力車両装置１２ｂの異常診断ＥＣＵ２２は、自車走行データＤＢ４４に記憶されている走行データ群を検索し、要因候補リストに含まれる要因候補と一致する走行データ（全ての変数の値が同一のデータ）を検索結果として取得する。そして、協力車両装置１２ｂの異常診断ＥＣＵ２２は、検索結果をセンタ装置１３に送信する（Ｓ３８）。また、協力車両装置１２ｂの異常診断ＥＣＵ２２は、検索結果とともに、その走行データについて異常が発生していたか否かを示す情報（以下、「異常有無情報」という。）もセンタ装置１３に送信する。

前述の説明では、協力車両装置１２ｂの異常診断ＥＣＵ２２は、自車走行データＤＢ４４に記憶されている走行データ群（＝過去データ）を検索するとしたが、未来データを検索するようにしても良い。つまり、協力車両装置１２ｂの異常診断ＥＣＵ２２は、今後走行中に得られる走行データ（＝未来データ）を監視し、要因候補リストに含まれる要因候補と同一の変数値の組が発生するか否かを検出するようにしても良い。同一の変数値の組が発生した場合、Ｓ３８と同様、協力車両装置１２ｂの異常診断ＥＣＵ２２は、検出結果を異常有無情報とともにセンタ装置１３に送信する。未来データの監視は、予め決められた監視期間が経過するまで継続し、監視期間が経過したら終了する。

図２０の説明に戻る。センタ装置１３の制御部３１は、検索結果から要因候補を絞り込み（Ｓ３９）、絞込結果を診断車両装置１２ａに送信する（Ｓ４０）。尚、センタ装置１３の制御部３１は、更に、絞込結果を協力車両装置１２ｂに送信するようにしても良い。

診断車両装置１２ａの異常診断ＥＣＵ２２は、絞込結果に基づき、異常と確認されたデータがあれば、警告を出力する（Ｓ４１）。

また、診断車両装置１２ａの異常診断ＥＣＵ２２は、絞込結果に基づき、異常でないと確認されたデータを正常データとして正常データＤＢ４３に登録する（Ｓ４２）。

次に、第３実施形態における変形例について説明する。前述の説明では、第２実施形態における分散管理型の異常診断システム１を前提としたが、第１実施形態における集中管理型の異常診断システム１においても、同様に異常の要因特定処理を行うことが可能である。

変形例の場合、診断車両装置１２ａの異常診断ＥＣＵ２２は、Ｓ３２において要因候補を抽出するのではなく、診断対象データおよび診断対象データの前後データをセンタ装置１３に送信する。そして、センタ装置１３の制御部３１が、Ｓ３２と同等の処理を実行することによって、要因候補を抽出し、要因候補リストを作成する。そして、センタ装置１３の制御部３１は、自らが作成した要因候補リストを協力車両装置１２ｂに送信する。

以上の通り、第３実施形態では、異常診断処理のみならず、異常の要因特定処理も実行するので、異常が発生したときに、その異常の要因をリアルタイムに特定することができる。異常の要因が特定されることによって、異常が発生している車両２の車両装置１２は、よりきめ細かい対応を取ることができる。例えば、異常の要因に応じて、車両２を完全に停止する必要があるのか、それとも一部の機能（例えば、自動追従制御機能等）のみを使用禁止とし、車両２の走行を継続しても良いのか、といった判定を行い、最適な対応を取ることができる。

更に、第３実施形態では、それぞれの車両装置１２が正常データや自車の走行データを管理し、要因候補抽出処理を行うので、通信コストや通信負荷を必要最低限に抑えることができ、効率的になる。

また、第３実施形態における変形例では、センタ装置１３が要因候補抽出処理を行うので、リアルタイムな対応を可能とする。これは、要因候補抽出処理は、負荷が高くなることが想定されるところ、処理能力が高いセンタ装置１３が行うことによって、リアルタイムな対応が可能となるからである。

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

１………異常診断システム
２………車両
２ａ………診断車両
２ｂ………協力車両
３………診断センタ
１２………車両装置
１２ａ………診断車両装置
１２ｂ………協力車両装置
１３………センタ装置
２２………異常診断ＥＣＵ

Claims (10)

1. 車両の異常を診断する異常診断システムであって、
   車両の走行データを記憶する記憶部と、
   診断対象の走行データである診断対象データを入力する入力部と、
   前記記憶部に記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域を生成し、前記高密度領域と前記診断対象データとを比較し、前記診断対象データが希有事象又は頻出事象のいずれであるかを判定する判定部と、
   前記判定部による判定結果に基づいて、車両が異常か否かを決定する診断部と、
   前記診断部による診断結果を出力する出力部と、
   を備える異常診断システム。
2. 車両に搭載されている車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成され、
   前記センタ装置は、
   前記入力部として、前記診断対象データを受信することによって、診断の依頼を受け付ける受付手段と、
   診断の協力依頼先の車両である協力車両を選定する選定手段と、
   前記協力車両に係る前記車両装置に前記診断対象データを送信することによって、診断の協力を依頼する協力依頼手段と、
   を備え、
   前記車両装置は、
   前記記憶部として、自車の走行データを記憶する記憶手段と、
   前記判定部として、前記記憶手段に記憶されている走行データ群について、前記高密度領域を生成し、前記高密度領域と前記診断対象データとを比較し、前記診断対象データが希有事象又は頻出事象のいずれであるかを判定し、判定結果を前記センタ装置に送信することによって、診断に協力する協力手段と、
   を備え、
   前記センタ装置は、更に、
   前記診断部として、前記車両装置から受信する前記判定結果を統合し、車両が異常か否かを決定する診断手段と、
   前記出力部として、前記診断手段による診断結果を、前記診断対象データに係る車両に搭載されている前記車両装置に送信することによって、診断結果を出力する診断結果出力手段と、
   を備える請求項１に記載の異常診断システム。
3. 前記車両装置が備える前記記憶手段は、更に、正常時の走行データである正常データを記憶し、前記センタ装置から受信する診断結果が「正常」である場合、前記診断対象データを前記正常データとして記憶する
   請求項２に記載の異常診断システム。
4. 前記診断部によって車両が異常と決定される場合には、異常の要因特定処理を行う要因特定部、
   を更に備える請求項１乃至請求項３のいずれかに記載の異常診断システム。
5. 前記車両装置は、
   前記要因特定部の一部として、前記記憶手段に記憶されている前記正常データ、及び前記診断対象データに基づいて、異常の発生条件となり得る要因候補を抽出し、抽出した結果を要因候補リストとする要因候補抽出手段と、
   前記要因特定部の一部として、前記要因候補リストについて、自車の車両における発生有無を検索し、検索結果を前記センタ装置に送信することによって、前記要因候補の絞込に協力する要因候補絞込協力手段と、
   を更に備え、
   前記センタ装置は、
   前記要因特定部の一部として、前記協力車両に係る前記車両装置から受信する前記検索結果から、前記協力車両において発生している前記要因候補を前記要因候補リストから削除することによって、前記要因候補を絞り込む要因候補絞込手段、
   を更に備える請求項４に記載の異常診断システム。
6. 前記センタ装置が備える前記診断手段は、
   希有事象判定の前記協力車両の割合、又は頻出事象判定の前記協力車両の割合のいずれかと、閾値とを比較することによって、車両が異常か否かを決定する
   請求項２又は請求項３に記載の異常診断システム。
7. 前記センタ装置が備える前記診断手段は、
   希有事象判定の前記協力車両の割合、又は頻出事象判定の前記協力車両の割合のいずれかと、第１の閾値とを比較することによって、車両が異常か、又はそれ以外かを決定し、
   更に、車両が異常と決定されない場合には、所定の期間内に、頻出事象判定の前記協力車両の割合が、前記第１の閾値とは異なる第２の閾値を超える場合、車両が正常と決定する
   請求項２又は請求項３に記載の異常診断システム。
8. 前記センタ装置が備える前記診断手段は、
   希有事象判定の前記協力車両の割合、又は頻出事象判定の前記協力車両の割合のいずれかと、第１の閾値とを比較することによって、車両が異常か、又はそれ以外かを決定し、
   更に、車両が異常と決定されない場合には、頻出事象判定の前記協力車両に前記診断対象データが前記正常データとして記憶されている場合、車両が正常と決定する
   請求項３に記載の異常診断システム。
9. 前記センタ装置が備える前記診断結果出力手段は、更に、前記診断手段による診断結果を、前記協力車両に搭載されている前記車両装置に送信する
   請求項２又は請求項３に記載の異常診断システム。
10. 車両に搭載されている車両装置と、前記車両装置とネットワークを介して接続されるセンタ装置と、によって構成され、車両の異常を診断する異常診断システムにおける異常診断方法であって、
    前記センタ装置又は前記車両装置が、診断対象の走行データである診断対象データを入力する入力ステップと、
    前記センタ装置又は前記車両装置が、予め記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域を生成し、前記高密度領域と前記診断対象データとを比較し、前記診断対象データが希有事象又は頻出事象のいずれであるかを判定する判定ステップと、
    前記センタ装置が、前記判定ステップにおける判定結果に基づいて、車両が異常か否かを決定する診断ステップと、
    前記センタ装置が、前記診断ステップにおける診断結果を出力する出力ステップと、
    を含む異常診断方法。

Images