以下図面に基づいて、本発明の実施形態を詳細に説明する。最初に図1〜図3を参照しながら、本発明の全ての実施形態に共通する異常診断システムのハードウエア構成について説明する。
図1は、異常診断システムの全体構成を示す図である。図1に示すように、異常診断システム1は、複数の車両2にそれぞれ搭載される複数の車両装置12、及び車両装置12とネットワーク9を介して接続されるセンタ装置13によって構成され、車両2の異常を診断するシステムである。センタ装置13は、異常診断業務を統括する診断センタ3等に設置される。
車両装置12とセンタ装置13との間のデータ通信の経路は、様々な経路が存在する。第1の経路は、車両2が路上等を走行中又は停車中の場合に用いられる。第1の経路では、車両装置12は、無線通信によって、ネットワーク9を介してセンタ装置13とのデータ通信を行う。
第2の経路は、車両2がディーラ店4に停車中の場合に用いられる。第2の経路では、車両装置12は、有線通信又は無線通信によって、ディーラ店4に設置されているディーラPC(Personal Computer)14と接続され、ディーラPC14及びネットワーク9を介してセンタ装置13とのデータ通信を行う。
第3の経路は、車両2が家庭5に停車中の場合に用いられる。第3の経路では、車両装置12は、有線通信又は無線通信によって、家庭5に設置されている家庭PC15と接続され、家庭PC15及びネットワーク9を介してセンタ装置13とのデータ通信を行う。
第4の経路は、車両2が路上等を走行中又は停車中の場合に用いられる。第4の経路では、車両装置12は、無線通信によって、路上等に設置されている路側器7と接続される。路側器7は、サブセンタ6(異常診断業務の一部を担う。)に設置されているサブセンタPC16と接続される。サブセンタPC16は、ネットワーク9を介してセンタ装置13とのデータ通信を行う。
データ通信の経路は、車両2の周辺環境や状態に応じて適切なものが選択される。以下では、車両装置12とセンタ装置13とのデータ通信は、第1の経路から第4の経路のいずれか最適なものによって実現されるものとして説明する。
図2は、車両装置のハードウエア構成図である。車両装置12は、少なくとも、送受信装置21、異常診断ECU(Electronic Control Unit)22、及びその他のECU群25を備える。また、車両装置12は、入力装置23及び出力装置24を備えても良い。異常診断ECU22、入力装置23、出力装置24、及びECU群25は、CAN(Controller Area Network)26等を介して互いにデータの送受信を行い、協調して動作を行っている。
送受信装置21は、他のコンピュータ等からデータを受信するとともに、他のコンピュータ等にデータを送信する。異常診断ECU22は、異常診断処理を実行するECUである。異常診断ECU22の動作の詳細は、実施形態ごとに後述する。
入力装置23は、ボタン、スイッチ、タッチパネル等であり、運転者からのデータ入力を受け付ける。出力装置24は、液晶ディスプレイ、有機ELディスプレイ、ヘッドマウントディスプレイ等の表示装置24aや、音を出力するスピーカ24b等である。
ECU群25は、例えば、ドアの開閉やウィンドウの開閉を制御するドア制御ECU25a、車内や車外の温度、設定温度等に基づき空調制御を行うエアコンECU25b、駐車中の車両への振動や車内への侵入を検知するセキュリティECU25c、エンジンの運転状態を検知し、燃料噴射制御や点火時期制御、アイドル回転数制御を行うエンジンECU26、車両2に登録されているキーを管理し、キーの認証を行い、エンジン始動を許可する照合ECU25e、道路地図を表示し、経路案内を行うカーナビECU25f等が含まれる。尚、図2に示すECUは一例である。本発明は、異常診断ECU22を除き、車両2に搭載されているECU群25を何ら限定するものではない。
図3は、コンピュータのハードウエア構成図である。図1に示すセンタ装置13、ディーラPC14、家庭PC15、サブセンタPC16は、図3に示すコンピュータ11によって実現される。尚、図3のハードウエア構成は一例であり、用途、目的に応じて様々な構成を採ることが可能である。
コンピュータ11は、制御部31、記憶部32、メディア入出力部33、通信制御部34、入力部35、表示部36、周辺機器I/F部37等が、バス38を介して接続される。
制御部31は、CPU(Central Processing Unit)、ROM(Read Only Memory)、RAM(Random Access Memory)等によって構成される。CPUは、記憶部32、ROM、記録媒体等に格納されるプログラムをRAM上のワークメモリ領域に呼び出して実行し、バス38を介して接続された各装置を駆動制御し、コンピュータ11が行う処理を実現する。ROMは、不揮発性メモリであり、コンピュータ11のブートプログラムやBIOS等のプログラム、データ等を恒久的に保持している。RAMは、揮発性メモリであり、記憶部32、ROM、記録媒体等からロードしたプログラム、データ等を一時的に保持するとともに、制御部31が各種処理を行う為に使用するワークエリアを備える。
記憶部32は、HDD(Hard Disk Drive)等であり、制御部31が実行するプログラム、プログラム実行に必要なデータ、OS(Operating System)等が格納される。プログラムに関しては、OSに相当する制御プログラムや、後述する処理をコンピュータ11に実行させるためのアプリケーションプログラムが格納されている。これらの各プログラムコードは、制御部31により必要に応じて読み出されてRAMに移され、CPUに読み出されて各種の手段として実行される。
メディア入出力部33は、データの入出力を行い、例えば、CDドライブ(−ROM、−R、−RW等)、DVDドライブ(−ROM、−R、−RW等)等のメディア入出力装置を有する。通信制御部34は、通信制御装置、通信ポート等を有し、コンピュータ11とネットワーク9間の通信を媒介する通信インタフェースであり、ネットワーク9を介して、他のコンピュータ11間との通信制御を行う。ネットワーク9は、有線、無線を問わない。
入力部35は、データの入力を行い、例えば、キーボード、マウス等のポインティングデバイス、テンキー等の入力装置を有する。入力部35を介して、コンピュータ11に対して、操作指示、動作指示、データ入力等を行うことができる。表示部36は、液晶パネル等のディスプレイ装置、ディスプレイ装置と連携してコンピュータ11のビデオ機能を実現するための論理回路等(ビデオアダプタ等)を有する。尚、入力部35及び表示部36は、タッチパネルディスプレイのように、一体でも良い。
周辺機器I/F(インタフェース)部37は、コンピュータ11に周辺機器を接続させるためのポートであり、周辺機器I/F部37を介してコンピュータ11は周辺機器とのデータの送受信を行う。周辺機器I/F部37は、USBやIEEE1394やRS−232C等で構成されており、通常複数の周辺機器I/Fを有する。周辺機器との接続形態は有線、無線を問わない。バス38は、各装置間の制御信号、データ信号等の授受を媒介する経路である。
<第1実施形態>
次に、図4〜図9を参照しながら、第1実施形態について説明する。第1実施形態では、センタ装置13が、市場における車両2の走行データ(以下、「市場走行データ」という。)を集中管理し、車両2の異常を診断する。つまり、第1実施形態の異常診断システム1は、センタ装置13による集中管理型のシステムと言える。尚、走行データとは、各ECUの内部データやCAN26上を流れている各種の信号等である。
まず、図4及び図5を参照しながら、ソフトウエア構成について説明する。図4は、第1実施形態における異常診断ECUのソフトウエア構成図である。図4に示すように、異常診断ECU22は、診断対象データ検出機能41、診断依頼機能42、正常データDB(DataBase)43、自車走行データDB44等を備える。
診断対象データ検出機能41は、自車の車両2の診断対象データを検出する機能である。診断対象データとは、異常診断システム1において診断の対象となる走行データであり、異常の可能性があるデータである。診断対象データ検出機能41は、例えば、定期的に走行データを取得し、取得される走行データが正常データDB43に記憶されているか否かを確認し、正常データDB43に記憶されていない場合、異常の可能性があると判定し、診断対象データとして検出する。また、定期的に走行データを取得することに代えて、診断対象データ検出機能41は、例えば、いずれかのECUからダイアグノスティックトラブルコードが出力されたり、運転者が何らかの異常を感じ、入力装置23を介して異常である旨が入力されたりすると、走行データを取得し、正常データDB43に記憶されているか否かを確認するようにしても良い。
診断依頼機能42は、センタ装置13に診断を依頼する機能である。診断依頼機能42は、診断対象データ検出機能41によって検出される診断対象データをセンタ装置13に送信することによって、診断を依頼する。
正常データDB43は、自車および自車と同車種の車両2における正常時の走行データ(以下、「正常データ」という。)を記憶する。正常データDB43には、市場に投入される前の試験時の走行データ(以下、「試験走行データ」という。)の中で正常データとして判断されるデータが予め記憶される。また、正常データDB43には、市場走行データの中で正常データとして判断されるデータも記憶されていく。
自車走行データDB44は、自車の車両2における走行データ(以下、「自車走行データ」という。)を記憶する。自車走行データDB44には、正常データか否かに依らず、自車走行データが記憶されていく。
図5は、第1実施形態におけるセンタ装置のソフトウエア構成図である。図5に示すように、センタ装置13は、診断依頼受付機能51、希有事象判定機能52、診断機能53、診断結果出力機能54、市場走行データ収集機能55、市場走行データDB56等を備える。
診断依頼受付機能51は、診断対象データが検出され、診断対象となる車両2(以下、「診断車両2a」という。)の車両装置12(以下、「診断車両装置12a」という。)から、診断依頼を受け付ける機能である。診断依頼受付機能51は、診断車両装置12aから診断対象データを受信することによって、診断の依頼を受け付ける。
希有事象判定機能52は、診断依頼受付機能51によって受信される診断対象データが希有事象又は頻出事象のいずれであるかを判定する機能である。希有事象判定機能52は、市場走行データDB56に記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域を生成し、高密度領域と診断対象データとを比較し、診断対象データが希有事象又は頻出事象のいずれであるかを判定する。希有事象判定機能52の詳細は、図6〜図8を参照しながら後述する。
診断機能53は、診断車両2aが異常か否かを決定する機能である。診断機能53は、希有事象判定機能52による判定結果に基づいて、診断車両2aが異常か否かを決定する。
診断結果出力機能54は、診断機能53による診断結果を出力する機能である。診断結果出力機能54は、例えば、センタ装置13の表示部36等に診断結果を出力したり、診断車両装置12aに診断結果を送信し、診断依頼に応答したりする。
市場走行データ収集機能55は、市場を走行している車両2群から、市場走行データを収集する機能である。市場走行データ収集機能55は、図1に示す各データ通信経路を介して、車両装置12から市場走行データを収集する。
市場走行データDB56は、車種ごとに、市場走行データを記憶する。市場走行データDB56が、様々な走行環境において走行している車両2の市場走行データを記憶していくことによって、希有事象判定機能52及び診断機能53の精度が向上する。尚、市場走行データDB56には、正常データだけでなく、異常の可能性があるデータも含まれる。
次に、図6〜図8を参照しながら、希有事象判定機能52による希有事象判定処理の一例について説明する。図6は、希有事象判定処理の前処理であるデータ変換処理を説明する図である。図7は、観測領域の一例を示す図である。図8は、高密度領域の一例を示す図である。
本発明では、高密度領域を生成するために、例えば、特開2011−95878号公報に記載の技術を用いる。以下、特開2011−95878号公報に記載の技術を本発明における異常診断システム1に適用する場合の処理内容について説明する。
センタ装置13の制御部31は、希有事象判定処理を行う前処理として、観測データ71を変換する。ここで、観測データ71は、試験走行データや市場走行データ等の総称である。具体的には、観測データ71は、複数の要素を含み、各車両2において同時に観測されるデータパターンである。例えば、観測データ71は、ある時刻に観測される車速、回転数、ACC(Auto Cruse Control)のON/OFFなどの複数要素のデータパターンである。観測データ71に含まれる要素は、車速、回転数のような数値データ、ACCのON/OFFのようなカテゴリデータのいずれかに区分される。
センタ装置13の制御部31は、観測データ71に含まれる要素に対して様々な加工処理を施して所定の範囲の整数値とする。観測データ71に含まれる要素が数値データの場合、センタ装置13の制御部31は、細かく区切って離散化し、デジタル化する。センタ装置13の制御部31は、必要に応じて、正規化や対数変換などを行う。加工処理の詳細は、特開2011−95878号公報に記載されているため、説明を省略する。
次に、センタ装置13の制御部31は、各整数値をビットデータに変換し、カテゴリカルデータが上位、数値データが下位となるように並び替えを行う。並び替えの意義は、特開2011−95878号公報に記載されているため、説明を省略する。
図6に示す観測データ71は、センタ装置13の制御部31が加工処理を行うことによって、0〜7の整数値に変換されている。図6に示す観測データ71では、x1とx2の2つの要素を含み、x1とx2の両方とも数値データである。
ビットデータ72のd1〜d3は、観測データ71のx1を2進数に変換した各ビットの値である。また、ビットデータ72のe1〜e3は、観測データ71のx2を2進数に変換した各ビットの値である。例えば、観測データ71aの場合、x1が「6」、x2が「2」なので、d1が「1」、d2が「1」、d3が「0」、e1が「0」、e2が「1」、e3が「0」のビットデータ72aとなる。以下では、ビット列に対して順位の概念を導入する。そして、d1とe1のように最も左端のビットを「最上位ビット」(MSB:Most Significant Bit)、d3とe3のように最も右端のビットを「最下位ビット」(LSB:Least Significant Bit)と呼ぶこととする。
図6に示すように、ビットデータ72は、x1に対応するビット列がd1、d2、d3、x2に対応するビット列がe1、e2、e3の順に並んでいる。これに対して、センタ装置13の制御部31は、各ビットデータ72の最上位ビットから最下位ビットまで、順位ごとに纏めて、d1->e1->d2->e2->d3->e3と並び替えたビット列である変換データ73を生成する。例えば、ビットデータ72aの場合、センタ装置13の制御部31は、1->0->1->1->0->0と並び替えた変換データ73aを生成する。
次に、センタ装置13の制御部31は、生成された変換データ73に基づいて、図7に示す観測領域64を構築する。図7に示す観測領域64は、二分決定グラフとして構築されている。二分決定グラフの詳細は、特開2011−95878号公報に記載されているため、説明を省略する。
図7では、実線で示すThen枝(変換データ73のビットの値が「1」に対応する枝)、間隔が広い点線で示すElse枝(変換データ73のビットの値が「0」に対応する枝)、「*」(アスタリスク)を付した間隔が狭い点線で示す否定Else枝の3つを用いて、二分決定グラフを構築している。例えば、図6に示す変換データ73のd1は、ブーリアン変数とみなすことができ、ノード65に対応している。また、66は最も上位のノード(ルートノード)、67は定数ノードである。
次に、センタ装置13の制御部31は、図7に示す観測領域64から、図8に示す高密度領域68を生成する。ここで、高密度領域68の生成処理の一例を説明する。まず、センタ装置13の制御部31は、二分決定グラフとして構築されている観測領域64の各ノードにおける最小項の数を算出する。次に、センタ装置13の制御部31は、変換データ73におけるビット数をnとするときに、最小項の数を2のn乗によって除する値を各ノードにおける密度として算出する。次に、センタ装置13の制御部31は、観測領域64の各枝に対して、接続先のノードにおける密度が予め定める閾値よりも高く、かつ接続元のノードよりも接続先のノードのレベルが高い場合には、接続先を定数ノードに変更する。より詳細な内容は、特開2011−95878号公報に記載されている。
「ノードのレベル」について説明を加える。センタ装置13の制御部31は、観測データ71に含まれる数値データの最上位ビットに対応するノードをレベル1とし、各数値データのビット列の順位ごとにレベルを分けて前述の処理を実行する。ルートノードやカテゴリカルデータのビットに対応するノードについては、レベル0とする。図6に示すビットデータ72では、ビット数が3なので、最上位ビットに対応するノードがレベル1、次のビットに対応するノードがレベル2、最下位ビットに対応するノードがレベル3となる。
図8では、高密度領域68に対応する二分決定グラフと、高密度領域68を表す平面図が示されている。平面図において、黒色のマスは、観測領域64に含まれているデータ領域を示している。また、×印が付されているマスは、高密度領域68の生成処理の結果、高密度に発生していると判定されたデータ領域を示している。高密度領域68は、黒色のマス、及び×印が付されているマスの両方を含むデータ領域を意味する。
このように生成される高密度領域68に対して、センタ装置13の制御部31は、高密度領域68と診断対象データとを比較する。そして、センタ装置13の制御部31は、診断対象データが高密度領域68に属する場合、頻出事象と判定し、診断対象データが高密度領域68に属さない場合、希有事象と判定する。
特開2011−95878号公報に記載されている通り、二分決定グラフを用いて高密度領域68を生成する手法は、計算速度及び精度の面において優れており、車両の異常を精度良く、リアルタイムに診断することを可能とする。特に、観測領域64は、市場走行データDB56のデータ蓄積に応じて広がっていく為、第1実施形態によれば、センタ装置13による希有事象判定処理の精度が向上し、ひいては、車両の異常を精度良く診断することが可能となる。
尚、本発明では、ある走行データの集合から、高密度に発生しているデータ領域を高密度領域68として推定すれば良く、特開2011−95878号公報に記載の手法以外を適用しても良い。例えば、十分に走行データが収集されている場合であれば、最も単純な手法として、センタ装置13の制御部31は、観測領域64をそのまま高密度領域68としても良い。また、その他の手法としては、センタ装置13の制御部31は、公知の1クラス問題に対する手法、例えば、1クラスSVM(Support Vector Machine)等を用いても良い。
次に、図9を参照しながら、第1実施形態における異常診断処理について説明する。図9は、第1実施形態における異常診断処理を示すフローチャートである。
図9に示すように、診断車両装置12aの異常診断ECU22は、診断対象データを検知すると(S1)、診断対象データをセンタ装置13に送信する(S2)。
センタ装置13の制御部31は、診断対象データを受信し、診断依頼を受け付ける(S3)。次に、センタ装置13の制御部31は、診断対象データが希有事象か否かを判定し(S4)、判定結果に基づいて診断車両2aが異常か否かを決定する(S5)。
ここで、センタ装置13の診断機能53について説明を加える。センタ装置13の制御部31は、市場走行データDB56から全ての走行データを抽出し、観測領域64を構築し、更に高密度領域68を生成する。このように生成される高密度領域68は、単純に、走行データ(正常か異常か不明なデータ)が高密度に発生している領域である。ほとんどの場合、頻出事象であれば「正常」、希有事象であれば「異常(又は異常の可能性あり)」と判定できると考えられる。
しかし、全ての希有事象を「異常」と決定できない場合もあるので、希有事象と判定された診断対象データについては継続的に監視を続けたり、実車の検査を行ったりして、詳細な調査を行うことが望ましい。そして、「正常」か「異常」のいずれであるかを示す調査結果は、センタ装置13の記憶部32に記憶させ、診断機能53による異常診断に反映することが望ましい。
また、全ての頻出事象を「正常」と決定できない場合もあるので、頻出事象と判定された診断対象データと同様のデータ(=全ての変数が同じ値を持つデータ)について、他の車両2からも同様の依頼が来るか否かを監視することが望ましい。仮に、統計的に有意な数の車両2から同様の依頼が来る場合、頻出事象の「異常」の可能性があるので、詳細な調査を行うことが望ましい。そして、「正常」か「異常」のいずれであるかを示す調査結果は、センタ装置13の記憶部32に記憶させ、診断機能53による異常診断に反映することが望ましい。
以上から、センタ装置13の制御部31は、記憶部32に記憶されている調査結果を参照し、例えば、(1)確実に異常、(2)確実に正常、(3)それ以外、等に分けて、診断結果を生成する。
図9の説明に戻る。センタ装置13の制御部31は、診断結果を診断車両装置12aに送信する(S6)。診断車両装置12aの異常診断ECU22は、受信する診断結果が「異常」であるか否かを確認する(S7)。診断結果が「異常」である場合、診断車両装置12aの異常診断ECU22は、出力装置24によって警告を出力する(S8)。一方、診断結果が「正常」である場合、診断車両装置12aの異常診断ECU22は、診断対象データを正常データとして正常データDB43に登録する(S9)。尚、診断結果が「正常」及び「異常」のいずれでもない場合、センタ装置13の制御部31は、安全側に判断し、S8の処理を行う(但し、警告内容は変えても良い。)。
以上の通り、第1実施形態では、センタ装置13による集中管理型の異常診断システム1によって、車両2の異常を精度良く、効率的に、かつリアルタイムに診断することができる。具体的には、市場を走行する多くの車両2から市場走行データを収集し、異常診断処理を実行するので、従来技術の課題であったデータ不足を補うことができ、精度良く診断することができる。また、正常と判断された診断対象データは、診断車両装置12aの正常データDB43に正常データとして反映されるので、誤検出の数を減らし、センタ装置13への診断依頼を減らすことができ、効率的になる。ひいては、異常診断システム1全体の負荷が低減されるので、車両2に重大異常が発生した際にも、リアルタイムに運転者に通知することが可能となる。
<第2実施形態>
次に、図10〜図14を参照しながら、第2実施形態について説明する。第2実施形態では、それぞれの車両装置12が、自車の市場走行データを分散管理し、車両2の異常を診断する。つまり、第2実施形態の異常診断システム1は、複数の車両装置12による分散管理型のシステムと言える。以下、第1実施形態と同様の構成要素については同じ符号を付し、重複説明を省略する。
まず、図10及び図11を参照しながら、ソフトウエア構成について説明する。図10は、第2実施形態における異常診断ECUのソフトウエア構成図である。図10に示すように、異常診断ECU22は、診断対象データ検出機能41、診断依頼機能42、協力依頼受付機能45、希有事象判定機能46、正常データDB43、自車走行データDB44等を備える。診断対象データ検出機能41、診断依頼機能42、正常データDB43、及び自車走行データDB44は、第1実施形態における図4と同様である。
協力依頼受付機能45は、センタ装置13からの協力依頼を受け付ける機能である。協力依頼受付機能45は、センタ装置13から診断対象データを受信することによって、協力依頼を受け付ける。
希有事象判定機能46は、協力依頼受付機能45によって受信される診断対象データが希有事象又は頻出事象のいずれであるかを判定する機能である。希有事象判定機能52は、自車走行データDB44に記憶されている走行データ群について、高密度に発生しているデータ領域である高密度領域68を生成し、高密度領域68と診断対象データとを比較し、診断対象データが希有事象又は頻出事象のいずれであるかを判定し、判定結果をセンタ装置に送信することによって、診断に協力する。希有事象判定機能46の詳細は、図6〜図8を参照しながら説明した通りである。
図11は、第2実施形態におけるセンタ装置のソフトウエア構成図である。図11に示すように、センタ装置13は、診断依頼受付機能51、協力車両選定機能57、協力依頼機能58、診断機能53a、診断結果出力機能54等を備える。診断依頼受付機能51及び診断結果出力機能54は、第1実施形態における図5と同様である。
協力車両選定機能57は、診断の協力依頼先の車両2(以下、「協力車両2b」という。)を選定する機能である。協力車両選定機能57は、例えば、診断車両2aと同車種の車両2を協力車両2bとして選定する。尚、協力車両選定機能57は、診断車両2aも協力車両2bとして選定しても良い。
協力依頼機能58は、協力車両2bの車両装置12(以下、「協力車両装置12b」という。)に診断の協力を依頼する機能である。協力依頼機能58は、協力車両装置12bに診断対象データを送信することによって、診断の協力を依頼する。
診断機能53aは、診断車両2aが異常か否かを決定する機能である。診断機能53aは、協力車両装置12bから受信する判定結果を統合し、診断車両2aが異常か否かを決定する。
次に、図12を参照しながら、第2実施形態における異常診断処理について説明する。図12は、第2実施形態における異常診断処理を示すフローチャートである。
図12に示すように、診断車両装置12aの異常診断ECU22は、診断対象データを検知すると(S11)、診断対象データをセンタ装置13に送信する(S12)。
センタ装置13の制御部31は、診断対象データを受信し、診断依頼を受け付ける(S13)。次に、センタ装置13の制御部31は、複数の協力車両2bを選定し(S14)、診断対象データを複数の協力車両装置12bに送信する(S15)。
それぞれの協力車両装置12bの異常診断ECU22は、診断対象データが希有事象か否か判定し(S16)、判定結果をセンタ装置13に送信する(S17)。これに対して、センタ装置13の制御部31は、判定結果を統合し、診断車両2aが異常か否か決定する(S18)。
ここで、センタ装置13の診断機能53aについて説明を加える。センタ装置13の制御部31は、複数の判定結果を受信するので、互いに矛盾する結果を受信する場合がある。つまり、一部の協力車両装置12bは希有事象と判定し、他の協力車両装置12bは頻出事象と判定する場合がある。そこで、判定結果の統合条件を3つ例示する。センタ装置13の制御部31は、統合条件に従って判定結果を統合し、診断車両2aが異常か否か決定する。
図13は、第2実施形態における統合条件を説明する図である。図13(a)は、第1の統合条件を説明する図である。“市場走行の車両2において、少数でも同様の事象が発生していれば、全体としては希有事象ではなく、異常でもない”と考える場合、1種類の閾値を用いて判定結果を統合する。例えば、希有事象と判定した協力車両2b(以下、「希有事象判定車両」という。)の割合が閾値(99%)を下回る場合、センタ装置13の制御部31は、診断対象データは頻出事象であり、診断車両2aは正常と判定する。また、閾値(99%)以上の場合、センタ装置13の制御部31は、診断対象データが希有事象であり、診断車両2aが異常と判定する。裏を返せば、頻出事象と判定した協力車両2b(以下、「頻出事象判定車両」という。)の割合が閾値(1%)を超える場合、センタ装置13の制御部31は、診断対象データが頻出事象であり、診断車両2aが正常と判定する。また、閾値(1%)以下の場合、センタ装置13の制御部31は、診断対象データが希有事象であり、診断車両2aが異常と判定する。尚、第1の統合条件によって異常と判定された診断車両2aについては、人手による確認をするため、専門家に連絡し、解析を依頼することが望ましい。
図13(b)は、第2の統合条件を説明する図である。“より安全側に考えて、「確実に異常」、「確実に正常」、「異常可能性あり」の3種類に分類する”と考える場合、2種類の閾値を用いて判定結果を統合する。まず、センタ装置13の制御部31は、第1閾値(99%)に基づき、「確実に異常」、又は「それ以外」(=「異常可能性あり」及び「正常」)の判定を行う。第1閾値(99%)によって「それ以外」と判定した場合、センタ装置13の制御部31は、「異常(仮)」と仮判定して、経過観察を行う。所定の期間内に、頻出事象判定車両の割合が第2閾値(50%)を超える場合、センタ装置13の制御部31は、判定結果を「確実に正常」(頻出)に確定する。一方、所定の期間内に、頻出事象判定車両の割合が第2閾値(50%)を超えない場合、センタ装置13の制御部31は、判定結果を「異常可能性あり」に確定する。尚、第2の統合条件によって「異常可能性あり」と判定された診断車両2aについては、人手による確認をするため、専門家に連絡し、解析を依頼することが望ましい。
図13(c)は、第3の統合条件を説明する図である。“「異常可能性あり」と判定した場合でも、頻出事象判定車両の少なくとも1台において、診断対象データと同様のデータ(=全ての変数が同じ値を持つデータ)が正常データDB43に含まれている場合、過去に正常判定されているとみなす”と考える場合、第2の統合条件の第1閾値(=第1の統合条件の閾値)による判定後、診断対象データの検索処理を行う。つまり、第1閾値(99%)によって「それ以外」と判定した場合、センタ装置13の制御部31は、頻出事象判定車両の車両装置12に対して診断対象データの検索処理を依頼する。頻出事象判定車両の車両装置12は、自らの正常データDB43を検索し、診断対象データが記憶されているか否かを判定する。診断対象データが記憶されている場合、頻出事象判定車両の車両装置12は、その旨をセンタ装置13に送信する。センタ装置13の制御部31は、少なくとも1台の車両装置12から、診断対象データが記憶されている旨を受信した場合、診断対象データが誤って検出されたものであり、診断車両2aが正常と判定する。尚、全ての頻出事象判定車両の正常データDB43に診断対象データが記憶されていない場合、第2の統合条件と同様、センタ装置13の制御部31は、第2閾値による判定を行う。
図12の説明に戻る。センタ装置13の制御部31は、診断結果を診断車両装置12aに送信する(S19)。診断車両装置12aの異常診断ECU22は、受信する診断結果が「異常」であるか否かを確認する(S20)。診断結果が「異常」である場合、診断車両装置12aの異常診断ECU22は、出力装置24によって警告を出力する(S21)。一方、診断結果が「正常」である場合、診断車両装置12aの異常診断ECU22は、診断対象データを正常データとして正常データDB43に登録する(S22)。尚、診断結果が「正常」及び「異常」のいずれでもない場合、センタ装置13の制御部31は、安全側に判断し、S21の処理を行う(但し、警告内容は変えても良い。)。
次に、第2実施形態の変形例について説明する。図12に示すフローチャートでは、センタ装置13の制御部31は、判定結果を診断車両装置12aのみに送信している。このような構成に加え、センタ装置13の制御部31は、更に、判定結果を協力車両装置12bにも送信し、正常データDB43の更新を指示してもよい。以下では、図14を参照しながら、この変形例について説明する。図14は、第2実施形態における異常診断処理の変形例を示すフローチャートである。
図14に示すように、センタ装置13の制御部31は、診断結果を協力車両装置12bに送信する(S23)。協力車両装置12bの異常診断ECU22は、診断結果が異常か否かを確認する(S24)。
診断結果が異常の場合(S24のYes)、協力車両装置12bの異常診断ECU22は、正常データDB43を検索し、診断対象データが存在すれば削除する(S25)。これは、自車走行データDB44内に存在しなくても、正常データDB43内に存在する可能性があるからである。
診断結果が正常の場合(S24のNo)、協力車両装置12bの異常診断ECU22は、正常データDB43を検索し、診断対象データが存在しなければ登録する(S26)。これは、自車走行データDB44内に存在しても、正常データDB43内に存在しない可能性があるからである。
以上の通り、第2実施形態では、複数の車両装置12による分散管理型の異常診断システム1によって、車両2の異常を精度良く、効率的に、かつリアルタイムに診断することができる。具体的には、市場を走行する多くの車両2の市場走行データに基づいて異常診断処理を実行するので、従来技術の課題であったデータ不足を補うことができ、精度良く診断することができる。また、正常と判断された診断対象データは、診断車両装置12aの正常データDB43に正常データとして反映されるので、誤検出の数を減らし、センタ装置13への診断依頼を減らすことができ、効率的になる。ひいては、異常診断システム1全体の負荷が低減されるので、車両2に重大異常が発生した際にも、リアルタイムに運転者に通知することが可能となる。
更に、第2実施形態では、それぞれの車両装置12が自車の走行データを管理し、希有事象判定処理を行うので、通信コストや通信負荷を必要最低限に抑えることができ、効率的になる。
また、第2実施形態における変形例では、判定結果を協力車両装置12bにも送信し、正常データDB43の更新を行うので、協力車両装置12bにおける誤検出の数も減らし、センタ装置13への診断依頼を減らすことができ、効率的になる。
<第3実施形態>
次に、図15〜図20を参照しながら、第3実施形態について説明する。第3実施形態では、異常診断処理のみならず、異常の要因特定処理も行う。以下、第2実施形態における分散管理型の異常診断システム1において、異常の要因特定処理を行う場合を説明する。以下、第1実施形態及び第2実施形態と同様の構成要素については同じ符号を付し、重複説明を省略する。
まず、図15及び図16を参照しながら、ソフトウエア構成について説明する。図15は、第3実施形態における異常診断ECUのソフトウエア構成図である。図15に示すように、異常診断ECU22は、診断対象データ検出機能41、要因候補抽出機能47、要因候補絞込依頼機能48、要因候補絞込協力機能49、正常データDB43、自車走行データDB44等を備える。診断対象データ検出機能41、正常データDB43、及び自車走行データDB44は、第2実施形態における図10と同様である。
要因候補抽出機能47は、正常データDB43に記憶されている正常データ、及び診断対象データ検出機能41によって検出されている診断対象データに基づいて、異常の発生条件となり得る要因候補を抽出し、抽出した結果を要因候補リストとする。要因候補抽出機能47の詳細は、図17〜図19を参照しながら後述する。
要因候補絞込依頼機能48は、センタ装置13に要因候補の絞込を依頼する機能である。要因候補絞込依頼機能48は、センタ装置13に要因候補リストを送信することによって、要因候補の絞込を依頼する。
要因候補絞込協力機能49は、センタ装置13からの要因候補の絞込に協力する機能である。要因候補絞込協力機能49は、センタ装置13から受信する要因候補リストについて、自車の車両2における発生有無を検索し、検索結果をセンタ装置13に送信することによって、要因候補の絞込に協力する。
図16は、第3実施形態におけるセンタ装置のソフトウエア構成図である。図16に示すように、センタ装置13は、要因候補絞込依頼受付機能59、協力車両選定機能57、協力依頼機能58、要因候補絞込機能60、要因候補絞込結果出力機能61等を備える。協力車両選定機能57及び協力依頼機能58は、第2実施形態における図11と同様である。
要因候補絞込依頼受付機能59は、診断車両装置12aから、要因候補の絞込依頼を受け付ける機能である。要因候補絞込依頼受付機能59は、診断車両装置12aから要因候補リストを受信することによって、要因候補の絞込依頼を受け付ける。
要因候補絞込機能60は、協力車両装置12bから受信する検索結果から、要因候補を絞り込む機能である。要因候補絞込機能60は、協力車両2bにおいて発生している要因候補を要因候補リストから削除することによって、要因候補を絞り込む。
要因候補絞込結果出力機能61は、要因候補絞込機能60による要因候補の絞込結果を出力する機能である。要因候補絞込結果出力機能61は、例えば、センタ装置13の表示部36等に絞込結果を出力したり、診断車両装置12aに絞込結果を送信し、絞込依頼に応答したりする。
次に、図17〜図19を参照しながら、要因候補抽出機能47による要因候補抽出処理の一例について説明する。図17は、正常データの一例を示す図である。図18は、診断対象データの一例を示す図である。図19は、相違信号集合及び要因候補の一例を示す図である。
本発明では、要因候補を抽出するために、例えば、特開2010−218492号公報に記載の技術を用いる。以下、特開2010−218492号公報に記載の技術を本発明における異常診断システム1に適用する場合の処理内容について説明する。
以下、正常データは、各ECUの入出力信号について、各ECUの処理結果が変わらない範囲(例えば、プログラム中の条件分岐やジャンプ部で同じ動きをする範囲)を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものとする。また、正常データは、各装置の状態値について、各装置の状態が変わらない範囲(例えば、車両の動作が変化しない範囲)を同値とみなし、同値とみなす範囲ごとにデータを分割して離散的なコード値に変換し、同一時刻ごとに纏めたものとする。
例えば、車速を示す信号の場合、0km/hであれば0、0km/h〜5km/hであれば1、5km/h〜20km/hであれば2、・・・といった具合に変換される。図17に示すように、例えば、No.が「X1」の正常データは、信号1が「0」、信号2が「1」、信号3が「0」、信号4が「1」、信号5が「0」である。
図18に示す診断対象データも、図17に示す正常データと同じように、同値とみなす範囲にデータの値を分割して変換し、同一時刻ごとに纏めたものとする。診断対象データは、データ容量を圧縮する為、データの組み合わせが変化する時刻のみを抽出するようにしても良い。
相違信号集合とは、診断対象データと正常データとを比較したときに、値が相違する信号群を示す集合である。図19(a)に示す相違信号集合は、図18に示すNo.が「Y2」の診断対象データと、図17に示す全ての正常データとを比較した結果を示している。
図18に示すNo.が「Y2」の診断対象データは、信号1が「0」、信号2が「3」、信号3が「1」、信号4が「0」、信号5が「0」である。一方、図17に示すNo.が「X1」の正常データは、信号1が「0」、信号2が「1」、信号3が「0」、信号4が「1」、信号5が「0」である。これらを比較すると、信号2、信号3、及び信号4の3つが相違する。従って、図19(a)に示すNo.が「D1」の相違信号集合は、{S(2)、S(3)、S(4)}となる。ここで、「S(2)」とは、診断対象データに係る信号2の信号値を意味する。つまり、{S(2)、S(3)、S(4)}とは、{信号2=3、信号3=1、信号4=0}という走行データを意味している。
また、図18に示すNo.が「Y1」の診断対象データは、信号1が「1」、信号2が「3」、信号3が「1」、信号4が「0」、信号5が「1」である。これは、図17に示すNo.が「X6」の正常データと同一である。つまり、図18に示すNo.が「Y1」の診断対象データは、正常とみなすことができる。
図18の例では、診断車両2aが、No.が「Y1」の時刻までは正常な動作をしており、No.が「Y2」の時刻において正常でない動作をした可能性があることを示している。
また、図19(b)に示す要因候補は、図19(a)に示す相違信号集合に対して、特開2010−218492号公報に記載の仕組みを利用して、診断車両装置12aの異常診断ECU22が算出した結果を示している。診断車両装置12aの異常診断ECU22は、全ての相違信号集合を充足することを制約条件とし、各信号の値が異常の発生条件の構成要素であることを否定する論理式に同じ重みを設定することで最大充足可能性問題の形に定式化する。次に、診断車両装置12aの異常診断ECU22は、最大充足可能性問題のミニマム解を算出し、算出された解を否定する論理式を制約条件として逐次追加して再度解を算出する処理を、解が存在しなくなるまで繰り返すことで、異常の発生条件となり得る要因候補を算出する。尚、ミニマム解とは、データを1つでも削るとsatisfiableにならない解である。
図19(a)に示す相違信号集合に対しては、ミニマム解として、{S(1)、S(2)}と{S(2)、S(5)}と{S(1)、S(4)、S(5)}の3つが得られる。従って、診断車両装置12aの異常診断ECU22は、図19(b)に示すように、{S(1)、S(2)}(データNo.が「C1」)、{S(2)、S(5)}(データNo.が「C2」)、{S(1)、S(4)、S(5)}(データNo.が「C3」)の3つを要因候補とする。
そして、診断車両装置12aの異常診断ECU22は、図19(b)に示す3つの要因候補を要因候補リストとし、要因候補リストをセンタ装置13に送信することによって、要因候補の絞込を依頼する。
次に、図20を参照しながら、第3実施形態における異常診断処理について説明する。図20は、第3実施形態における異常診断処理を示すフローチャートである。
図20に示すように、診断車両装置12aの異常診断ECU22は、診断対象データを検知する(S31)。
診断車両装置12aの異常診断ECU22は、要因候補を抽出し(S32)、要因候補リストをセンタ装置13に送信する(S33)。
センタ装置13の制御部31は、要因候補リストを受信し、絞込依頼を受け付ける(S34)。次に、センタ装置13の制御部31は、複数の協力車両2bを選定し(S35)、要因候補リストを複数の協力車両装置12bに送信する(S36)。
それぞれの協力車両装置12bの異常診断ECU22は、要因候補リストに含まれる要因候補が自車の車両2において発生しているか否かを検索する(S37)。具体的には、協力車両装置12bの異常診断ECU22は、自車走行データDB44に記憶されている走行データ群を検索し、要因候補リストに含まれる要因候補と一致する走行データ(全ての変数の値が同一のデータ)を検索結果として取得する。そして、協力車両装置12bの異常診断ECU22は、検索結果をセンタ装置13に送信する(S38)。また、協力車両装置12bの異常診断ECU22は、検索結果とともに、その走行データについて異常が発生していたか否かを示す情報(以下、「異常有無情報」という。)もセンタ装置13に送信する。
前述の説明では、協力車両装置12bの異常診断ECU22は、自車走行データDB44に記憶されている走行データ群(=過去データ)を検索するとしたが、未来データを検索するようにしても良い。つまり、協力車両装置12bの異常診断ECU22は、今後走行中に得られる走行データ(=未来データ)を監視し、要因候補リストに含まれる要因候補と同一の変数値の組が発生するか否かを検出するようにしても良い。同一の変数値の組が発生した場合、S38と同様、協力車両装置12bの異常診断ECU22は、検出結果を異常有無情報とともにセンタ装置13に送信する。未来データの監視は、予め決められた監視期間が経過するまで継続し、監視期間が経過したら終了する。
図20の説明に戻る。センタ装置13の制御部31は、検索結果から要因候補を絞り込み(S39)、絞込結果を診断車両装置12aに送信する(S40)。尚、センタ装置13の制御部31は、更に、絞込結果を協力車両装置12bに送信するようにしても良い。
診断車両装置12aの異常診断ECU22は、絞込結果に基づき、異常と確認されたデータがあれば、警告を出力する(S41)。
また、診断車両装置12aの異常診断ECU22は、絞込結果に基づき、異常でないと確認されたデータを正常データとして正常データDB43に登録する(S42)。
次に、第3実施形態における変形例について説明する。前述の説明では、第2実施形態における分散管理型の異常診断システム1を前提としたが、第1実施形態における集中管理型の異常診断システム1においても、同様に異常の要因特定処理を行うことが可能である。
変形例の場合、診断車両装置12aの異常診断ECU22は、S32において要因候補を抽出するのではなく、診断対象データおよび診断対象データの前後データをセンタ装置13に送信する。そして、センタ装置13の制御部31が、S32と同等の処理を実行することによって、要因候補を抽出し、要因候補リストを作成する。そして、センタ装置13の制御部31は、自らが作成した要因候補リストを協力車両装置12bに送信する。
以上の通り、第3実施形態では、異常診断処理のみならず、異常の要因特定処理も実行するので、異常が発生したときに、その異常の要因をリアルタイムに特定することができる。異常の要因が特定されることによって、異常が発生している車両2の車両装置12は、よりきめ細かい対応を取ることができる。例えば、異常の要因に応じて、車両2を完全に停止する必要があるのか、それとも一部の機能(例えば、自動追従制御機能等)のみを使用禁止とし、車両2の走行を継続しても良いのか、といった判定を行い、最適な対応を取ることができる。
更に、第3実施形態では、それぞれの車両装置12が正常データや自車の走行データを管理し、要因候補抽出処理を行うので、通信コストや通信負荷を必要最低限に抑えることができ、効率的になる。
また、第3実施形態における変形例では、センタ装置13が要因候補抽出処理を行うので、リアルタイムな対応を可能とする。これは、要因候補抽出処理は、負荷が高くなることが想定されるところ、処理能力が高いセンタ装置13が行うことによって、リアルタイムな対応が可能となるからである。
以上、添付図面を参照しながら、本発明に係る異常診断システム等の好適な実施形態について説明したが、本発明はかかる例に限定されない。当業者であれば、本願で開示した技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。