(57)【要約】【課題】瞬間的なノイズに起因して、診断対象の状態を誤診断してしまう恐れを低減可能な診断システムを提供する。【解決手段】診断ＥＣＵ１１は、データ収集部Ｆ１、ラベル判定部Ｆ２、及び診断部Ｆ３を備える。データ収集部Ｆ１は、車載センサから車両の挙動やドライバの操作等に係る複数種類の状態量についてのデータを逐次取得し、状態量毎の値の時系列データを生成する。各種状態量は所定の規則によって複数の状態量グループに分類されている。ラベル判定部Ｆ２は、データ収集部Ｆ１によって収集された状態量毎の時系列データに基づいて、複数の状態量グループの現在の状態が、状態量グループ毎に予め用意されている複数の状態量ラベルの何れに該当するかを逐次判定する。診断部Ｆ３は、ラベル判定部Ｆ２が判定した状態量グループ毎の状態量ラベルの組み合わせに基づいて車載システムが正常に動作しているか否かを診断する。【選択図】図２
2019095836.tif 000002
【特許請求の範囲】
【請求項１】
診断対象が正常に動作しているか否かを診断する診断システムであって、
予め設定されている複数の状態量グループを構成する複数種類の状態量のそれぞれについての計測値又は算出値を示すデータを逐次取得するデータ収集部（Ｆ１）と、
前記データ収集部によって収集された複数の前記状態量のそれぞれの値の時系列データに基づいて、複数の前記状態量グループの現在の状態が、前記状態量グループ毎に予め用意されている複数の状態量記号の何れに該当するかを逐次判定する記号化部（Ｆ２）と、
前記診断対象が正常に動作している場合、又は、所定の不具合が生じている場合に取りうる前記状態量グループ毎の前記状態量記号の組み合わせを示す統計データである診断用データを記憶している診断用データ記憶部（Ｍ２）と、
前記記号化部が判定した前記状態量グループ毎の前記状態量記号の組み合わせと、前記診断用データ記憶部に保存されている前記診断用データとに基づいて前記診断対象が正常に動作しているか否かを診断する診断部（Ｆ３）と、を備える診断システム。
【請求項２】
請求項１に記載の診断システムであって、
前記診断用データ記憶部は、前記診断用データとして、前記診断対象が正常に動作している場合に取りうる前記状態量グループ毎の前記状態量記号の組み合わせを示す統計データである正常モデルを記憶しており、
前記診断部は、前記記号化部が判定した前記状態量グループ毎の前記状態量記号の組み合わせと前記正常モデルとを照らし合わせることによって前記診断対象が正常に動作しているか否かを診断する診断システム。
【請求項３】
請求項１又は２に記載の診断システムであって、
前記診断用データ記憶部は、前記診断用データとして、前記診断対象に所定の不具合が生じている場合に取りうる前記状態量グループ毎の前記状態量記号の組み合わせを示す不具合パターンを少なくとも記憶しており、
前記診断部は、前記記号化部が判定した前記状態量グループ毎の前記状態量記号の組み合わせと前記診断用データ記憶部が記憶している前記不具合パターンとを照らし合わせることによって前記診断対象に生じている不具合を特定する診断システム。
【請求項４】
請求項１から３の何れか１項に記載の診断システムであって、
前記診断部として、所定の或る１時点での前記状態量グループ毎の前記状態量記号の組み合わせに基づいて、前記診断対象が正常に動作しているか否かを診断する逐次診断部（Ｆ３１）を備える診断システム。
【請求項５】
請求項４に記載の診断システムであって、
前記逐次診断部は、前記状態量グループ毎の前記状態量記号の組み合わせの変化が発生する度に、その変化後の前記状態量グループ毎の前記状態量記号の組み合わせに基づいて、前記診断対象が正常に動作しているか否かを診断する診断システム。
【請求項６】
請求項１から５の何れか１項に記載の診断システムであって、
前記診断部として、複数時点における前記状態量グループ毎の前記状態量記号の組み合わせに基づいて、前記診断対象が正常に動作しているか否かを診断する複合判定部（Ｆ３２）を備える診断システム。
【請求項７】
請求項６に記載の診断システムであって、
前記複合判定部は、
複数の時点のそれぞれでの前記診断対象が正常である確率である局所正常確率に基づいて、前記診断対象が正常に動作していることの尤もらしさを示す指標である正常尤度を算出し、
前記正常尤度が所定の閾値以上である場合に、前記診断対象は正常に動作していると判定する診断システム。
【請求項８】
請求項１から７の何れか１項に記載の診断システムであって、
前記記号化部は、前記データ収集部によって収集された複数の前記状態量のそれぞれの値の時系列データを、隠れ状態と状態間の確率的遷移で表現されるモデルを利用して、区分単位となる前記状態量グループの状態ごとに区分するとともに前記状態量グループの状態に対応する記号を割り当てることによって、前記状態量グループの状態を記号化する診断システム。
【請求項９】
請求項１から８の何れか１項に記載の診断システムであって、
前記診断システムは、
前記診断対象に設けられている診断装置（１１）と、
前記診断対象の外部に配置されているセンタ（２）と、を備え、
前記診断装置は、前記データ収集部、及び前記記号化部を備えるとともに、前記センタと通信するための外部通信部（１５）と接続されてあって、
前記診断装置は前記外部通信部と連携して前記記号化部が生成した前記状態量グループ毎の状態を示す記号群を逐次送信するように構成されており、
前記センタが、前記外部通信部から送信される前記記号群に基づいて前記診断対象の診断を行う前記診断部としての構成を備える診断システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、診断対象とする所定の設備の状態を診断する診断システムに関する。
【背景技術】
【０００２】
従来、特許文献１に開示されているように、複数センサ間の関係性をモデル化した統計データ（以降、診断モデル）を用いて、センサ値が正常範囲内にあるか否かによって所定の観測対象とする装置／システムの異常状態を検出する診断システムが種々提案されている。また、異常状態時のセンサ出力の関係性をモデル化することによって、異常の原因を特定する仕組みも種々提案されている。なお、特許文献１に開示のシステムにおいては、装置の状態が過渡状態であるか定常状態であるかによって診断モデルを使い分ける構成が採用されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第５４２７１０７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
センサの出力値には瞬間的なノイズが重畳しうる。そのため、センサの出力値が所定の正常範囲に収まっているか否かによって診断対象の状態を診断する手法においては、瞬間的なノイズの影響を受けて診断対象の状態を誤診断する恐れがある。
【０００５】
本開示は、この事情に基づいて成されたものであり、その目的とするところは、瞬間的なノイズに起因して、診断対象の状態を誤診断してしまう恐れを低減可能な診断システムを提供することにある。
【課題を解決するための手段】
【０００６】
その目的を達成するための本開示の診断システムは、診断対象が正常に動作しているか否かを診断する診断システムであって、予め設定されている複数の状態量グループを構成する複数種類の状態量のそれぞれについての計測値又は算出値を示すデータを逐次取得するデータ収集部（Ｆ１）と、データ収集部によって収集された複数の状態量のそれぞれの値の時系列データに基づいて、複数の状態量グループの現在の状態が、状態量グループ毎に予め用意されている複数の状態量記号の何れに該当するかを逐次判定する記号化部（Ｆ２）と、診断対象が正常に動作している場合、又は、所定の不具合が生じている場合に取りうる状態量グループ毎の状態量記号の組み合わせを示す統計データである診断用データを記憶している診断用データ記憶部（Ｍ２）と、記号化部が判定した状態量グループ毎の状態量記号の組み合わせと、診断用データ記憶部に保存されている診断用データとに基づいて診断対象が正常に動作しているか否かを診断する診断部（Ｆ３）と、を備える。
【０００７】
上記の構成では記号化部が、複数種類の状態量のそれぞれについての連続的な時系列信号の集合を離散的な記号列に変換する。そして診断部は、状態量グループ毎の状態量記号の組み合わせに基づいて診断対象が正常に動作しているか否かを診断する。
【０００８】
上記の診断に用いられる状態量記号は、状態量毎の時系列的な流れを考慮して決定されるため、瞬間的なノイズの影響を緩和することができる。加えて、複数種類の状態量を個々に記号化して取り扱うのではなく、複数種類の状態量をグループ化した上で記号化する。このように複数種類の状態量をグループ化して記号化する構成によれば、或る状態量についての計測値又は算出値に瞬間的なノイズが重畳している場合であっても、他の状態量によって当該ノイズ成分が記号化に与える影響を緩和することができる。つまり、瞬間的なノイズに起因して状態量グループの現在の状態を誤判定する恐れを低減できる。
【０００９】
つまり、診断対象の状態を示す種々の情報をいったん状態量グループ毎の状態量記号に記号化してから、当該状態量グループごとの状態量記号の組み合わせに基づいて診断を実施する構成によれば、瞬間的なノイズに起因して診断対象の状態を誤診断する恐れを低減することができる。
【００１０】
なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。
【図面の簡単な説明】
【００１１】
【図１】診断システム１００の概略的な構成の一例を示すブロック図である。
【図２】診断ＥＣＵ１１の概略的な構成を示す機能ブロック図である。
【図３】状態量グループについて説明するための概念図である。
【図４】状態量ラベルの判定方法について説明するための図である。
【図５】ラベル判定部Ｆ２の作動を説明するための図である。
【図６】正常モデルの概念図である。
【図７】不具合パターンモデルの概念図である。
【図８】逐次診断部Ｆ３１の作動を説明するための図である。
【図９】逐次診断部Ｆ３１の作動を説明するための図である。
【図１０】複合診断部Ｆ３２の作動を説明するための図である。
【図１１】変形例１における逐次診断部Ｆ３１の作動を説明するための図である。
【図１２】変形例３におけるラベル判定部Ｆ２の作動を説明するための図である。
【発明を実施するための形態】
【００１２】
以下、本開示の実施形態について図を用いて説明する。図１は、本開示に係る診断システム１００の概略的な構成の一例を示す図である。図１に示すように診断システム１００は、車両に搭載されている車載システム１と、車両外に配置されているセンタ２とを備えている。なお、ここでは一例として車載システム１は駆動源としてエンジンを備える車両に搭載されているものとするが、これに限らない。車載システム１は、駆動源としてモータを備える車両に搭載されていてもよい。
【００１３】
＜全体構成について＞
車載システム１は、診断ＥＣＵ１１、車載センサ１２、ディスプレイ１３、入力装置１４、及び外部通信部１５を備える。診断ＥＣＵ１１は、車載センサ１２、ディスプレイ１３、入力装置１４、及び外部通信部１５のそれぞれと、車載ネットワーク又は専用の信号線を介して通信可能に構成されている。
【００１４】
診断ＥＣＵ１１は、当該ＥＣＵが搭載されている車両（換言すれば車載システム１）の診断を行う電子制御装置（Electronic Control Unit：ＥＣＵ）である。診断ＥＣＵ１１は、後述の通り、車載センサ１２から提供される複数種類の状態量についての計測値に基づいて、車載システム１が正常に動作しているか否かを判定（換言すれば診断）する。診断ＥＣＵ１１が診断装置に相当する。
【００１５】
この診断ＥＣＵ１１は、コンピュータとして構成されている。すなわち、ＣＰＵ１１１、ＲＡＭ１１２、フラッシュメモリ１１３、Ｉ／Ｏ、及びこれらの構成を接続するバスラインなどを備える。なお、診断ＥＣＵ１１が備えるＣＰＵの数は１つでも複数でもよい。また、診断ＥＣＵ１１は、ＣＰＵ１１１の代わりに、ＧＰＵやＭＰＵを用いて実現されていても良い。さらにＣＰＵ１１１やＧＰＵ、ＭＰＵを組み合わせて実現されていてもよい。フラッシュメモリ１１３には、通常のコンピュータを診断ＥＣＵ１１として機能させるためのプログラム（以降、診断プログラム）等が格納されている。
【００１６】
車載センサ１２は、ドライバによる運転操作に関する情報（以下、操作情報）を出力するセンサや、運転操作の結果として表れる車両の挙動に関する情報（以下、挙動情報）を検出するセンサの集合である。また、車両の走行環境を示す情報（以下、環境情報）を出力するセンサや、ドライバの身体的、精神的状態を示す情報（以下、ドライバ情報）を出力するセンサも車載センサ１２に含まれうる。
【００１７】
操作情報としては、アクセルペダルの操作量、ブレーキペダルの操作量、ステアリングホイールの操作量である操舵角、方向指示器の作動状態、トランスミッションのシフト位置などを用いることができる。
【００１８】
操作情報を出力するセンサとは、アクセルペダルの踏み込み量を検出するアクセルセンサ、ブレーキペダルの踏み込み量もしくはマスタシリンダが発生するブレーキ圧を検出するブレーキセンサ、操舵角としてのステアリングホイールの回転角度を検出する操舵角センサなどである。もちろん、操作情報を出力するセンサは、上述したセンサに限らない。例えば、トランスミッションのシフト位置を検出するポジションセンサや、方向指示器（いわゆるウインカー）を作動させるためのウインカースイッチなども操作情報を出力するセンサに該当する。
【００１９】
挙動情報としては、車両の速度や、加速度、エンジン回転速度、スロットル開度、ヨーレートなどを用いることができる。挙動情報を出力するセンサとは、例えば、車両の走行速度を検出する車速センサや、車両に作用する加速度を検出する加速度センサ、エンジンの回転速度を検出するセンサ、スロットルバルブの開度を検出するスロットル開度センサ、車両に作用するヨーレートを検出するヨーレートセンサなどである。
【００２０】
環境情報としては車両周辺に存在する物体の位置情報や、それらの物体の車両に対する相対速度、降雨や降雪といった天候、気温、明るさ、時刻などを用いることができる。また、環境情報には、車両の位置情報（例えば、緯度、経度、高度）や、車両が走行している道路の種別（例えば一般道路や高速道路など）などといった地理的な情報を示す地理的環境情報を含めることができる。
【００２１】
環境情報を出力するセンサとしては、車両周辺に存在する物体を検出する周辺監視センサや、降雨を検出するレインセンサ、外部の明るさを検出する照度センサ、水平面に対する車体の傾斜角度を検出する傾斜センサ、外気温を検出する温度センサ、車両の現在位置を逐次算出（換言すれば特定）するロケータなどが該当する。
【００２２】
なお、周辺監視センサとは、自車の周辺の所定範囲を撮像範囲とする周辺監視カメラや、ソナー，ミリ波レーダ，ＬＩＤＡＲ（Light Detection and Ranging/Laser Imaging Detect ion and Ranging）等である。また、他の車両と相互通信を実施する車車間通信装置も、車両の周辺に存在する他車両についての情報を収集する装置に該当するため、周辺監視センサに含まれる。ロケータは、例えばＧＮＳＳ（Global Navigation Satellite System）を構成する測位衛星が送信する測位信号を受信するＧＮＳＳ受信機を備え、ＧＮＳＳ受信機が受信した測位信号を用いて位置を算出する装置である。
【００２３】
ドライバ情報としては、例えばドライバの顔の向きや目の開度、脈拍、意識レベル、連続運転時間などを採用することができる。ドライバ情報を出力するセンサとは、例えばドライバの顔の向きや目の開度を検出するＤＳＭ（Driver Status Monitor）や、脈拍を検出する脈波センサなどである。なお、ＤＳＭは、近赤外光源及び近赤外カメラと、これらを制御する制御ユニット等とによって構成されている。ＤＳＭは、近赤外カメラを自車の運転席側に向けた姿勢にて、例えばインスツルメントパネルの上面に配置されている。
【００２４】
ディスプレイ１３は、診断ＥＣＵ１１から入力された画像を表示するデバイスである。ディスプレイ１３は、車両に搭載されたディスプレイでも良いし、携帯端末のディスプレイでもよい。なお、ディスプレイ１３はヘッドアップディスプレイでもよい。
【００２５】
入力装置１４は、診断ＥＣＵ１１に対するユーザの指示操作を受け付けるためのデバイスである。入力装置１４は、例えばディスプレイ１３に積層されたタッチパネルである。なお、他の態様として入力装置１４は、音声認識技術を用いて実現される音声入力装置であってもよい。また、センターコンソールに配置されたハプティックデバイスであってもよい。その他、マウス、キーボードなどであっても良い。上述した複数種類のデバイスを入力装置１４として備えていても良い。
【００２６】
外部通信部１５は、公衆無線通信回線等を利用してセンタ２などの外部装置と無線通信するための通信モジュールである。外部通信部１５は、診断ＥＣＵ１１から入力されたデータを変調してセンタ２に送信するとともに、センタ２から送信されたデータを受信して診断ＥＣＵ１１に提供する。
【００２７】
センタ２は、車載システム１と通信することで、車載システム１の状態を管理する構成である。センタ２は、車載システム１と通信するための通信モジュールや、コンピュータを主体として構成されている。センタ２は車載システム１から送信される後述の不具合レポートを受信した場合には、メンテナンスの手配等の処理を実施する。
【００２８】
また、センタ２は、診断ＥＣＵ１１で使用される診断用データを保存している記憶装置である診断モデルデータベースを備える。センタ２は、機械学習又は管理者の操作によって、診断用データを随時更新する。診断用データの更新を実施した場合には、車載システム１に対して診断用データの更新が存在する旨を通知し、診断ＥＣＵ１１からの要求に基づいて診断ＥＣＵ１１に対して診断用データを配信する。
【００２９】
＜診断ＥＣＵ１１の構成について＞
次に図２を用いて診断ＥＣＵ１１の構成及び機能について説明する。診断ＥＣＵ１１は図２に示すようにデータ収集部Ｆ１、ラベル判定部Ｆ２、診断部Ｆ３、報告処理部Ｆ４、提示処理部Ｆ５、更新処理部Ｆ６、記号化用データ記憶部Ｍ１、及び診断用データ記憶部Ｍ２を備える。記号化用データ記憶部Ｍ１及び診断用データ記憶部Ｍ２を除く各部は、ＣＰＵが所定の診断プログラムを実行することによって実現されるものである。つまり、ＣＰＵによって実現される各種機能を機能ブロック毎に分けて図示したものが図２である。但し、これら各部は必ずしもソフトウェアにて実現されている必要はなく、その全部または一部はハードウェアにて実現されていてもよい。ハードウェアで実現する態様には１つ又は複数のＩＣを用いて実現する態様も含まれる。記号化用データ記憶部Ｍ１、及び診断用データ記憶部Ｍ２は、不揮発性の記憶媒体を用いて実現されている。例えば記号化用データ記憶部Ｍ１及び診断用データ記憶部Ｍ２は、フラッシュメモリ１１３が備える記憶領域を用いて実現することができる。
【００３０】
データ収集部Ｆ１は、車載センサ１２から種々の状態量についてのデータを逐次取得する。すなわち、操作情報や挙動情報、環境情報、操作情報などを車載センサ１２から逐次取得する。また、データ収集部Ｆ１は、所定の状態量の検出値を時間軸で微分した微分データを生成する。例えばデータ収集部Ｆ１は、操舵角を時間微分することによって、操舵角の単位時間当りの変化量（いわゆる操舵速度）を算出する。すなわち、データ収集部Ｆ１は、アクセルペダルの操作量や車速などといった車載センサ１２によって検出される状態量の他、車載センサ１２の検出値を加工してなる値が示す状態量についての情報も逐次取得（厳密には算出）する。なお、データ収集部Ｆ１は、各センサによる検出値の微分値そのものではなく、単なる差分値を微分データとして用いてもよい。また、１回微分して定まる状態量だけでなく、２回微分して定まる状態量や、積分して定まる状態量を取得するように構成されていても良い。検出値及び算出値を区別しない場合にはまとめてセンシング値と記載する。
【００３１】
データ収集部Ｆ１は、逐次取得する状態量毎のセンシング値を、状態量毎に区別してＲＡＭ１１２に保存する。状態量毎のセンシング値は、最新の取得値が先頭となるように時系列順に並べて保存されれば良い。なお、データ収集部Ｆ１は、車載システム１の診断に必要な種類の状態量についての値を取得するように構成されていればよく、上述した全ての状態量について取得する必要はない。つまり、データ収集部Ｆ１が収集する状態量の具体的な種類は適宜設計されればよい。
【００３２】
複数種類の状態量は、予め設定されている規則によって図３に示すように、複数の状態量グループにグループ化されて取り扱われる。換言すれば、データ収集部Ｆ１は、予め設定されている複数の状態量グループのそれぞれを構成する状態量についてのセンシング値を取得する。
【００３３】
便宜上本明細書では、状態量グループとして、図３に示すように第１〜第４状態量グループまでの４つの状態量グループが設定されている場合を例にとって、診断ＥＣＵ１１の作動を説明する。第１状態量グループは例えばドライバの加減速操作に係る状態量の集合である。第２状態量グループは、ドライバの加減速操作の結果として表れる車両の挙動に関す状態量の集合である。第３状態量グループは例えばドライバの操舵操作に係る状態量の集合である。第４状態量グループは、ドライバの操舵操作の結果として表れる車両の挙動に関す状態量の集合である。
【００３４】
なお、図３に示す状態量Ａ〜Ｍは、データ収集部Ｆ１が取得する状態量を概念的に表している。例えば状態量Ａ〜Ｃは順に、アクセルペダルの踏み込み量（換言すればアクセル位置）、ブレーキペダルの踏み込み量（換言すればブレーキ位置）、シフトポジションを表している。状態量Ｄ〜Ｇは順に、車速、車両前後方向に作用する加速度、スロットル開度、エンジン回転速度を表している。状態量Ｈ〜Ｊは、ステアリングホイールの中立位置に対する回転角度（つまり回転角度）、操舵速度、方向指示器の作動状態を表している。状態量Ｋ〜Ｍは順に、ヨーレート、車体に対するタイヤの切れ角（以降、タイヤ切れ角）、車体に対するタイヤの切れ角を制御する転舵モータの駆動電流（以降、転舵モータ電流）を表している。なお、タイヤ切れ角はトー角とも称される状態量である。
【００３５】
もちろん、診断ＥＣＵ１１に設定されている状態量グループの数や、各グループに属する状態量の種類（つまり状態量グループの構成）は適宜設計されればよい。例えば、診断ＥＣＵ１１には、環境情報に属する状態量のグループが設定されていてもよいし、ドライバ情報に属する状態量のグループが設定されていても良い。上述した以外の状態量グループが設定されていても良い。
【００３６】
また、第１状態量グループは、アクセルペダルの操作速度（以降、アクセル速度）や、ブレーキペダルの操作速度（以降、ブレーキ速度）を含んでいても良い。その他、１つの状態量が複数の状態量グループに属していても良い。例えば車速などは、第２状態量グループだけでなく、第４状態量グループに属していても良い。さらに、図３に示す種々の状態量グループは更に細分化されていてもよい。例えば、第１状態量グループは、加速操作に係る状態量のグループと、減速操作に係る状態量のグループとに分割されていても良い。第２状態量グループも同様である。
【００３７】
なお、上記のように設定された第２状態量グループは、第１状態量グループに属する種々の状態量に対応するドライバの加減速操作を受けての車両挙動を示す状態量によって構成されているため、第１状態量グループと相関が強いグループである。また、上記のように設定された第４状態量グループは、第３状態量グループに属する種々の状態量に対応するドライバの操舵操作を受けての車両挙動を示す状態量によって構成されているため、第３状態量グループと相関が強いグループである。なお、右左折や車線変更の前後には加減速等の操作が発生する可能性が高い。故に、第１状態量グループと第３状態量グループは無関係ではなく、互いにある程度の相関がある。第２状態量グループと第４状態量グループも同様である。
【００３８】
複数の状態量グループのそれぞれには、予めそのグループの状態を示す記号としての状態ラベルが複数用意されている。ラベル判定部Ｆ２は、複数の状態量のそれぞれの値の時系列データに基づいて、状態量グループ毎の状態を状態量ラベルで表現（つまり記号化）する構成である。また、このラベル判定部Ｆ２は、複数の状態量の時系列データに基づいて、複数の状態量グループの現在の状態が、状態量グループ毎に予め用意されている複数の状態ラベルの何れに該当するかを逐次判定する構成に相当する。ラベル判定部Ｆ２が記号化部に相当する。状態ラベルが状態量記号の一例に相当する。
【００３９】
ラベル判定部Ｆ２は、状態量グループ毎に記号化を行う。状態量グループ毎の記号化には、二重分節構造を利用した教師なし分割法によって分節化を行う二重分節解析器（ＤＡＡ：Double Articulation Analyzer）を利用することができる。ＤＡＡでは、状態量グループを構成する各状態量（以降、構成状態量）を要素とする多次元の空間において、構成状態量のセンシング値から把握される状態量グループの状態を表すクラスタと、各クラスタ間の遷移確率とが設計者や機械学習によって定義されている。クラスタが、状態量グループが取りうる状態の区分単位であって、状態量ラベルに対応する。
【００４０】
本実施形態では記号化の方法として、隠れ状態とその状態間の確率的遷移で表現されるモデルの一つである階層ディリクレ過程隠れマルコフモデル（いわゆるＨＤＰ−ＨＭＭ）を利用する。ＨＤＰ−ＨＭＭは、ＨＭＭに無限次元の隠れ状態（クラスタに相当）を仮定することにより、入力される各信号に応じて隠れ状態の数を決定するという柔軟さを有する。そのため、ＨＭＭを利用する際に、隠れ状態数を事前に設計する必要がないという利点を有する。特に、ＨＤＰ−ＨＭＭとして、スティッキーＨＤＰ−ＨＭＭを用いることが好ましい。スティッキーＨＤＰ−ＨＭＭは、ＨＤＰ−ＨＭＭの自己遷移確率にバイアスを付加したもので、自己遷移確率を大きくすることにより、隠れ状態の過剰遷移を抑えることができ、動作の連続性を仮定するモデリングを効率的に行うことが可能となる。
【００４１】
記号化用データ記憶部Ｍ１は、ラベル判定部Ｆ２が、各種状態量の時系列データに基づいて状態量グループの状態を記号化（換言すれば離散化）するために必要なデータを記憶している。状態量グループを記号化するために必要なデータとは、各状態量ラベルの発生する確率を定義したデータや、或る状態量ラベルから別の状態量ラベルへと遷移する確率を示す遷移確率モデル等である。遷移確率モデルとは、各クラスタ間の遷移確率を示すデータに相当する。
【００４２】
ラベル判定部Ｆ２は、記号化用データ記憶部Ｍ１に保存されているデータを用いて、データ収集部Ｆ１が取得している構成状態量毎の現在のセンシング値のまとまりが、いずれのクラスタに属するかを統計的に処理することにより、構成状態量の時系列データを状態量ラベルで区分する。
【００４３】
図４は、第１状態量グループに対する状態量ラベルの付与（つまり記号化）を概念的に表したものである。図４のａ１〜ａ４は、状態量ラベルを表している。図４に示すように、状態量グループの状態は時間の経過に伴って順次記号化されていき、記号列で表現されることとなる。
【００４４】
また、ＤＡＡは、生成された記号列を、統計情報を利用した離散文字列の教師なしチャンク化手法の１例であるNested Pitman-Yor Language Model（ＮＰＹＬＭ）を用いて、１まとまりのシーン（以降、グループシーン）を意味する部分系列に分節化する。この際、辞書サイズ（即ち、部分系列の数）ができるだけ小さく、部分系列の並びからなる記号列全体の生成確率が最大となるようにする。これにより、状態量ラベル列の状態量シーンへの分節化を行うことが可能になる。部分系列間の遷移確率、および部分系列の生成確率は、学習によって予め生成されたものを使用する。
【００４５】
なお、ＨＤＰ−ＨＭＭやＮＰＹＬＭを適用したＤＡＡについては、非特許文献、T.Taniguchi et al,"Semiotic Prediction of Driving Behavior using Unsupervised Double Articulation Analyzer" IEEE Intelligent Vehicles Symposium,2012、および、K.Takenaka et al," Contextual Scene Segmentation of Driving Behavior based on Double Articulation Analyzer" IEEE/RSJ International Conference onIntelligent Robots and Systems,2012、等を参照することによって取り入れることができる。
【００４６】
なお、本実施形態では一例としてＨＤＰ−ＨＭＭやＮＰＹＬＭを適用したＤＡＡを用いて状態量グループ毎の記号化を実施するものとするがこれに限らない。多様な手法を採用することができる。第２状態量グループ、第３状態量グループ、及び第４状態量グループのそれぞれについても、第１状態量グループと同様に、当該グループを構成する状態量のセンシング値の時系列データを、ＤＡＡを用いて状態量ラベルの列に変換する。
【００４７】
図５は、状態量グループ毎の記号化を実施した結果を示す概念図である。各状態量グループには前述の通り異なる状態量ラベルが用意されている。図５に示すａｊ、ｂｊ、ｃｊ、及びｄｊ（ｊは５までの整数）は順に、第１〜第４状態量グループの状態量ラベルを表している。例えば状態量ラベルａ１〜ａ５は順に、停車状態、弱い加速操作、強い加速操作、弱い減速操作、強い減速操作（いわゆる急ブレーキ）に対応する状態量ラベルである。各状態量ラベルに対応する実際の車両状態等は、設計者又は人工知能によって適宜設定される。
【００４８】
ここでは一例として各状態量グループに対して５つの状態量ラベルが用意されているがこれに限らない。状態量グループ毎に設定されている状態量ラベルの数（以降、ラベル数）は適宜設計される。例えば、第３状態量グループについてのラベル数は３や４、６などであってもよい。ラベル数は２以上であればよい。
【００４９】
ラベル判定部Ｆ２の状態量グループ毎の状態量ラベルの判定結果は逐次ＲＡＭ１１２に保存される。状態量グループ毎の状態量ラベルの判定結果は、状態量グループごとに区別して保存される。１つの状態量グループについての判定時刻が異なる複数の判定結果は、最新の判定結果が先頭となるように時系列順にソートされて保存されれば良い。
【００５０】
診断部Ｆ３は、ラベル判定部Ｆ２の判定結果に基づいて、診断用データ記憶部Ｍ２に保存されているデータを参照し、車載システム１が正常に動作しているか否かを判定する構成である。診断用データ記憶部Ｍ２は、診断用データとして、車載システム１が正常であるか否かを判定するための正常モデルと、車載システム１に生じている不具合のパターンを特定するための不具合パターンモデルを備える。
【００５１】
診断用データ記憶部Ｍ２に記憶されている正常モデルは、例えば車載システム１が正常である場合に観測されうる、所定の２つの状態量グループの状態量ラベルの組み合わせについての発生確率を示すデータとすることができる。図６の（Ａ）は、車載システム１が正常である場合に観測されうる、第１状態量グループと第２状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータを概念的に表している。図６の（Ｂ）は、車載システム１が正常である場合に観測されうる、第３状態量グループと第４状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータを概念的に表している。
【００５２】
ここでは一例として診断用データ記憶部Ｍ２は、車載システム１が正常である場合に観測される第１状態量グループと第２状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータと、第３状態量グループと第４状態量グループの組み合わせ毎の発生確率を示すデータの両方を、正常モデルとして備えているものとする。もちろん、正常モデルを形成する状態量グループの組み合わせは上述したものに限らない。第１状態量グループと第４状態量グループの状態量ラベルの組み合わせについてのデータを保持していてもよい。
【００５３】
不具合パターンモデルは、図７に示すように不具合のパターン毎に用意されている。すなわち、車載システム１に生じうる不具合としてｍ種類の不具合パターンが想定されている場合には、第１不具合パターンから、第ｍ不具合パターンまでのそれぞれに対応する不具合パターンモデルが用意されている。或る不具合についての不具合パターンモデルは、当該不具合が発生している場合に観測されうる、所定の２つの状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータである。図７では、各不具合パターンモデルは、第１状態量グループと第２状態量グループの状態量ラベルの組み合わせ毎の発生確率（換言すれば生起確率）を示すデータで構成されている態様を図示しているが、これに限らない。不具合パターンモデルもまた正常モデルと同様に、第３状態量グループと第４状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータを備えていても良い。また、不具合パターンモデルを形成する状態量グループの組み合わせは上述したものに限らない。第１状態量グループと第４状態量グループの組み合わせを用いて不具合パターンモデルを構築してもよい。不具合パターンモデルを形成する状態量グループの組み合わせは、不具合の内容に応じて適宜設計されればよい。
【００５４】
なお、正常モデルは、正常であることが確認されている車載システム１を搭載している車両を走行させることによって得られるデータ（以降、正常データ）を元に構築されればよい。正常データは実車試験によって収集しても良いし、実際の道路上を走行する各車両にデータ収集部Ｆ１が収集した生データを送信させることで収集してもよい。収集したデータに基づく正常モデル等の構築は機械学習によって実現されれば良い。正常モデル及び不具合パターンモデルは、車載システム１の状態ごとに、状態量ラベルの組み合わせがどの程度の頻度で現れるかを表す統計データである。
【００５５】
診断部Ｆ３は、より細かい要素として、逐次診断部Ｆ３１と複合診断部Ｆ３２とを備える。逐次診断部Ｆ３１は、所定の診断周期Ｔａ毎に、その時点での各状態量グループの状態量ラベルの組み合わせに基づいて車載システム１を診断する構成である。便宜上、診断周期Ｔａ毎の時点を診断時点と称する。最初の診断時点は、診断ＥＣＵ１１の起動処理が完了した時点や、診断ＥＣＵ１１が起動してから所定時間経過したタイミング、ラベル判定部Ｆ２による状態量グループごとの状態量ラベルの最初の判定が完了した時点など、適宜設計されれば良い。図８の黒丸は、各診断時点を表している。
【００５６】
診断周期Ｔａは適宜設計されればよい。例えば診断周期Ｔａは１秒や、５秒、１０秒などに設定されていれば良い。診断周期Ｔａは、１つの状態量ラベルが継続する時間の平均値や、平均値よりも長い時間に設定されていることが好ましい。なお、図８では時刻ｔ１において、各状態量グループの状態量ラベルの組み合わせとして、（ａ２，ｂ１，ｃ２，ｄ２）が得られている場合を示している。
【００５７】
例えば逐次診断部Ｆ３は、図８の時刻ｔ１のように、第１状態量グループと第２状態量グループの状態量ラベルの組み合わせとして（ａ２，ｂ１）が得られている場合には、正常モデルを参照し、車載システム１が正常な場合に（ａ２，ｂ１）の組み合わせが観測される確率Ｐａｂを取得する。なお、一例として図６に示す正常モデルを用いれば、車載システム１が正常な場合に（ａ２，ｂ１）の組み合わせが観測される確率Ｐａｂは０．３である。
【００５８】
また、逐次診断部Ｆ３は第３状態量グループと第４状態量グループの状態量ラベルの組み合わせとして（ｃ２，ｄ２）が得られている場合には、正常モデルを参照し、車載システム１が正常な場合に（ｃ２，ｄ２）の組み合わせが観測される確率Ｐｃｄを取得する。なお、一例として図６に示す正常モデルを用いれば、車載システム１が正常な場合に（ｃ２，ｄ２）の組み合わせが観測される確率Ｐａｂは０．４である。観測されている状態量ラベルの組み合わせと正常モデルとから定まる確率Ｐａｂ、Ｐｃｄは、観測された状態量ラベルの組み合わせが正常である確率（換言すれば正常性）を示すパラメータである。故に、正常モデルを参照することで定まる観測された状態量ラベルの組み合わせの発生確率のことを以降では正常確率とも称する。
【００５９】
逐次診断部Ｆ３１は、診断に用いる状態量グループの組み合わせ毎の正常確率に基づいて、時刻ｔ１の時点において車載システム１が正常であるか否かを判定する。診断に用いる状態量グループの組み合わせとは、ここでは第１状態量グループと第２状態量グループの組み合わせと、第３状態量グループと第４状態量グループの組み合わせのことである。便宜上以降では、車載システム１の正常性の診断に用いる状態量グループの組み合わせのことを、診断用グループペアとも記載する。
【００６０】
例えば、診断用グループペア毎の正常確率（ここではＰａｂとＰｃｄ）の何れもが、所定の正常判定閾値以上である場合には車載システム１は正常であると判定し、診断用グループペア毎の正常確率（ここではＰａｂとＰｃｄ）の少なくとも何れか一つが正常判定閾値未満である場合には、不具合が発生していると判定する。正常判定閾値は、正常判定閾値は全ての状態量グループの組み合わせ毎において共通する値としても良いし、状態量グループの組み合わせ毎に異なる値に設定されても良い。逐次診断部Ｆ３１は、上記の判定が完了すると、その判定結果を時刻情報と対応付けてＲＡＭ１１２に保存する。
【００６１】
なお、上記の判定態様は一例であって、これに限らない。例えば逐次診断部Ｆ３１は、診断用グループペア毎の正常確率に基づいて定まる統合正常確率Ｐｎが、所定の正常判定閾値以上である場合には車載システム１は正常であると判定し、統合正常確率Ｐｎが正常判定閾値未満である場合には、不具合が発生していると判定してもよい。
【００６２】
統合正常確率Ｐｎは、例えば、診断用グループペア毎の正常確率（ここではＰａｂとＰｃｄ）を掛け合わせた値である。なお、他の態様として、統合正常確率Ｐｎは、診断用グループペア毎の正常確率の最小値としても良い。そのような態様は、具体的には、ＰａｂとＰｃｄの小さい方の値を統合正常確率Ｐｎとして用いる態様に相当する。また、診断用グループペア毎の正常確率の平均値を統合正常確率Ｐｎとして用いても良い。そのような態様は、具体的にはＰａｂとＰｃｄの平均値を統合正常確率Ｐｎとして用いる態様に相当する。統合正常確率Ｐｎは診断時点での車載システム１の正常性を示す指標値である。統合正常確率Ｐｎが局所正常確率に相当する。
【００６３】
また、逐次診断部Ｆ３１は、車載システム１の動作状態が正常ではない（換言すれば不具合が生じている）と判定した場合には、不具合パターンモデルを用いて車載システム１に生じている不具合の特定を試みる。具体的には、逐次診断部Ｆ３１は図９に示すように、観測されている状態量ラベルの組み合わせを用いて、不具合パターン毎の該当確率を算出する。或る不具合パターンについての該当確率とは、当該不具合が生じている確率のことであって、その不具合パターンが発生していることの尤もらしさを示す指標に相当する。例えば第１不具合パターンの該当確率は、第１不具合パターンモデルを参照することによって、第１不具合パターンが生じている場合に、現在観測されている状態量ラベルの組み合わせが発生する確率を特定する。
【００６４】
そして逐次診断部Ｆ３１は、種々の不具合パターンのうち、該当確率が最も大きい不具合パターンを、車載システム１に発生している不具合として採用し、判定時刻と対応付けてＲＡＭ１１２に保存する。便宜上、逐次診断部Ｆ３１が実施する、或る１時点での状態量グループ毎の状態量ラベルの組み合わせに基づいて当該診断時点での車載システム１の状態を診断する処理を逐次診断処理と称する。
【００６５】
本実施形態では一例として逐次診断部Ｆ３１は、統合正常確率Ｐｎを診断周期Ｔａで逐次算出するとともに、正常であると判定した場合にも、観測されている状態量ラベルの組み合わせを用いて、不具合パターン毎の該当確率を算出する。逐次診断部Ｆ３１が算出した統合正常確率Ｐｎや、不具合パターン毎の該当確率は、生成時刻を示すタイムスタンプが付与されてＲＡＭ１１２に保存される。なお、診断周期Ｔａごとの統合正常確率Ｐｎや、不具合パターン毎の該当確率の算出は、次に述べる複合診断部Ｆ３２によって実行されてもよい。
【００６６】
複合診断部Ｆ３２は、生成時刻が現時点から所定の遡及時間以内に算出された複数の統合正常確率Ｐｎを用いて、車載システム１が正常であるか否かを判定する構成である。遡及時間は、前述の診断周期Ｔａの２倍以上の値に設定されていればよい。ここでは一例として遡及時間は診断周期Ｔａの１０倍に設定されているものとする。そのような構成は、複合診断部Ｆ３２が直近１０回分の統合正常確率Ｐｎに基づいて車載システム１の診断を行う構成に相当する。
【００６７】
具体的には、複合診断部Ｆ３２は、直近１０回分の統合正常確率Ｐｎに基づいて、車載システム１が正常であることの尤もらしさを示す指標として、正常尤度Ｌｎを算出する。正常尤度Ｌｎは、下記式によって定まる。
【００６８】
Ｌｎ＝Ｐｎ（ｔ）×Ｐｎ（ｔ−１）×Ｐｎ（ｔ−２）×…×Ｐｎ（ｔ−９）
式中のＰｎ（ｔ）は最新の統合正常確率Ｐｎを表しており、Ｐｎ（ｔ−１）は最新よりも１つ前の（つまり前回算出した）統合正常確率Ｐｎを表している。Ｐｎ（ｔ−２）は前々回算出した統合正常確率Ｐｎを表している。Ｐｎ（ｔ−９）は、最新のものよりも９つ前の統合正常確率Ｐｎを表している。
【００６９】
そして、複合診断部Ｆ３２は、上記式で求めた正常尤度Ｌｎが所定の尤度閾値以上である場合に車載システム１は正常であると判定する一方、正常尤度Ｌｎが尤度閾値未満である場合には車載システム１は正常ではないと判定する。ここでは複数時点で算出した統合正常確率Ｐｎをかけ合わせた値を正常尤度Ｌｎとして採用するが、正常尤度Ｌｎの算出態様はこれに限らない。正常尤度Ｌｎは直近１０回分の統合正常確率Ｐｎを足し合わせた値としても良い。
【００７０】
また、本実施形態では遡及時間を診断周期Ｔａの１０倍に設定しているが、これに限らない。遡及時間は、診断周期Ｔａの５倍や２０倍であってもよい。そのような態様は、複合診断部Ｆ３２が、直近５回分や２０回分の統合正常確率Ｐｎに基づいて車載システム１の診断を行う構成に相当する。
【００７１】
また、本実施形態では複合診断部Ｆ３２は遡及時間毎に診断を実施するものとするが、これに限らない。例えば、複合診断部Ｆ３２は、車両の走行用電源（いわゆるイグニッション電源）がオフに設定された場合に、走行用電源がオンとなってからオフとなるまでに算出された統合正常確率Ｐｎを用いて車載システム１を診断するように構成されていても良い。そのような構成は、車両の走行用電源がオンとなってからオフとなるまでを遡及時間に設定した態様に相当する。
【００７２】
さらには、複合診断部Ｆ３２は、車両が停車する度に、車両が発進してから停車するまでの間に算出された統合正常確率Ｐｎを用いて車載システム１を診断するように構成されていても良い。そのような構成は、車両が発進してから停車するまでを遡及時間に設定した態様に相当する。
【００７３】
その他、複合診断部Ｆ３２は、診断ＥＣＵ１１が車載システム１の診断を実施するためのテストモードに設定されている間に算出した統合正常確率Ｐｎを用いて車載システム１を診断するように構成されていても良い。そのような態様は、別の観点によれば、テストモードに設定されてからテストモードが解除されるまで（換言すれば終了するまで）を遡及時間に設定した態様に相当する。
【００７４】
また、複合診断部Ｆ３２は、正常尤度Ｌｎを用いた診断の結果、車載システム１は正常ではないと判定した場合には、不具合パターンモデルを参照して、車載システム１に生じている不具合パターンの特定を試みる。具体的には、現時点から遡及時間以内に存在する各診断時点での不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度Ｌ１〜Ｌｍを算出する。また、本実施形態では遡及時間は診断周期Ｔａの１０倍に設定されているため、上記の構成は、直近１０回分の診断時点での不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度Ｌ１〜Ｌｍを算出する構成に相当する。加えて、本実施形態では、車載システム１が正常であると判定している場合も診断時点毎に、不具合パターン毎の該当確率を算出している。故に、複合診断部Ｆ３２は、既に算出済みの直近１０回分の不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度Ｌ（１）〜Ｌ（ｍ）を算出する構成に相当することができる。つまり、複合診断部Ｆ３２は、生成時刻が現時点から遡及時間以内に算出されている不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度Ｌ１〜Ｌｍを算出する。
【００７５】
図１０は複合診断部Ｆ３２が車載システム１に生じている不具合パターンを特定する際の作動を概念的に表した図である。該当尤度Ｌ（１）は車載システム１に生じている不具合パターンが第１不具合パターンであることの尤もらしさを示す指標であり、該当尤度Ｌ（２）は車載システム１に生じている不具合パターンが第２不具合パターンであることの尤もらしさを示す指標である。該当尤度Ｌ（ｍ）は車載システム１に生じている不具合パターンが第ｍ不具合パターンであることの尤もらしさを示す指標である。或る不具合パターン（以降、第ｊ不具合パターン）の該当尤度Ｌｊは以下の式によって算出可能である。
【００７６】
Ｌ（ｊ）＝Ｐ（ｊ，ｔ）×Ｐ（ｊ，ｔ−１）×Ｐ（ｊ，ｔ−２）×Ｐ（ｊ，ｔ−９）
式中のＰ（ｊ，ｔ）は最新の診断時点での第ｊ不具合パターンの該当確率を表しており、Ｐ（ｊ，ｔ−１）は最新の診断時点よりも１つ前の診断時点での第ｊ不具合パターンの該当確率を表している。Ｐ（ｊ，ｔ−２）は最新の診断時点よりも２つ前の診断時点での第ｊ不具合パターンの該当確率を表している。Ｐ（ｊ，ｔ−９）は、最新の診断時点よりも９つ前の診断時点での第ｊ不具合パターンの該当確率を表している。
【００７７】
そして複合診断部Ｆ３２は、種々の不具合パターンのうち、該当尤度が最も大きい不具合パターンを、車載システム１に発生している可能性が高い不具合と判定する。便宜上、複合診断部Ｆ３２が実施する、車載システム１の状態を診断する処理を長期診断処理と称する。
【００７８】
車載システム１が正常であるか否か、及び正常ではない場合に予想される不具合パターンといった、複合診断部Ｆ３２の診断結果は、判定時刻と対応付けられてＲＡＭ１１２に保存される。なお、保存先は書き換え可能な不揮発性メモリであってもよい。
【００７９】
報告処理部Ｆ４は、複合診断部Ｆ３２によって車載システム１が正常ではないと判定された場合に、外部通信部１５と協働して、センタ２に車載システム１が正常に動作してないことを報告する構成である。具体的には、車載システム１が正常に動作してないことを示す通信パケットである不具合レポートを生成し、送信する。また、報告処理部Ｆ４は、逐次診断部Ｆ３１よって車載システム１が正常ではないと判定された場合にも車載システム１が正常に動作してないことを示す通信パケットである不具合レポートを生成し、送信する。
【００８０】
なお、本実施形態ではより好ましい態様として、不具合レポートには、車載システム１に生じていると想定される不具合パターンについての情報も含まれているものとする。そのような態様によれば、センタ２は不具合レポートを受信することによって、車載システム１にどのような不具合が生じているかを特定することができる。つまり、車載システム１に生じている不具合パターンについての情報を収集することができる。
【００８１】
また、不具合レポートには、より好ましい態様として、不具合レポートが示す診断結果が逐次診断処理の結果であるのか、長期診断処理の結果であるのかを示す診断パターン情報も含まれているものとする。このような態様によれば、センタ２は受信した不具合レポートが逐次診断処理によるものなのか、長期診断処理によるものなのかを判別することができる。
【００８２】
なお、本実施形態では一例として、逐次診断部Ｆ３１によって車載システム１が正常ではないと判定された場合と、複合診断部Ｆ３２によって車載システム１が正常ではないと判定された場合の両方において、不具合レポートを送信するものとするが、これに限らない。複合診断部Ｆ３２によって車載システム１が正常ではないと判定された場合にのみ、不具合レポートを送信するように構成されていても良い。そのような構成によれば車載システム１からセンタ２に送信する通信量及び通信料を低減することができる。逐次診断部Ｆ３１によって車載システム１が正常ではないと判定された場合にのみ、不具合レポートを送信するように構成されていても良い。
【００８３】
また、報告処理部Ｆ４は、他の態様として、逐次診断部Ｆ３１又は複合診断部Ｆ３２によって車載システム１は正常に動作していると判定されている場合、車載システム１が正常に動作していることを示す通信パケットである正常レポートを生成し、センタ２に送信するように構成されていても良い。そのような構成は、逐次診断部Ｆ３１又は複合診断部Ｆ３２が診断処理を実施する度に、車載システム１の状態の診断結果を示す通信パケットであるステータスレポートをセンタ２に送信する構成に相当する。車載システム１が正常であることを示すステータスレポートが正常レポートに相当し、車載システム１に不具合が生じていることを示すステータスレポートが不具合レポートに相当する。
【００８４】
提示処理部Ｆ５は、複合診断部Ｆ３２よって車載システム１が正常ではないと判定された場合に車載システム１が正常に動作してないことを示す画像（以降、不具合通知画像）を表示する構成である。不具合通知画像はテキスト情報のみを表示する画像であってもよい。本実施形態ではより好ましい態様として、不具合通知画像には、車載システム１に生じていると想定される不具合パターンについての情報も含まれているものとする。
【００８５】
なお、本実施形態では一例として提示処理部Ｆ５は、複合診断部Ｆ３２によって車載システム１が正常ではないと判定された場合にのみ、不具合通知画像を表示するが、これに限らない。他の態様として、逐次診断部Ｆ３１によって車載システム１が正常ではないと判定された場合にも、不具合通知画像を表示するように構成されていても良い。
【００８６】
更新処理部Ｆ６は、センタ２から診断用データが更新されたことを通知された場合に、自動的に又はユーザの承諾を得た上で、センタ２と通信を実施し、診断用データ記憶部Ｍ２に保存されている診断用データの更新を実施する。診断ＥＣＵ１１は当該更新処理部Ｆ６を備えることによって、診断用データを随時更新することができる。また、最新の診断用データを用いて車載システム１の診断が可能となる。
【００８７】
＜実施形態のまとめ＞
上記の構成では、ラベル判定部Ｆ２が、車載センサ１２の出力値等（つまりセンシング値）の連続的な時系列信号の集合を離散的な状態量ラベルの系列に変換する。そして逐次診断部Ｆ３１は、状態量グループ毎の状態量ラベルの組み合わせに基づいて車載システム１の状態を診断する。
【００８８】
診断に用いられる状態量ラベルは、センシング値の時系列的な流れを考慮して決定されるため、瞬間的なノイズの影響を緩和することができる。特に本実施形態では、或る状態量ラベルから別の状態量ラベルへと遷移する確率のモデルである遷移確率モデルを用いて状態量ラベルを判定する。故に、センサ出力値がノイズによってぶれる場合においても、実際の状態量ラベルの変化による出力値変動であるかを確率的に判定することができ、より一層、瞬間的なノイズによる状態量ラベルの判定結果への影響を小さくすることができる。
【００８９】
加えて、複数種類の状態量を個々に記号化して取り扱う構成に比べて、複数種類の状態量をグループ化して記号化する構成によれば、或る状態量についてのセンシング値にノイズがのっている場合であっても、他の状態量によって当該ノイズ成分が記号化に与える影響を緩和することができる。
【００９０】
このように車載センサ１２の状態をいったん状態量グループ毎の状態量ラベルへと記号化してから、当該状態量グループごとの状態量ラベルの組み合わせに基づいて診断を実施する構成によれば、診断結果に対する瞬間的なノイズの影響を緩和することができる。結果として、瞬間的なノイズに起因して車載システム１の状態を誤診断する恐れを低減することができる。
【００９１】
また、本実施形態では複合診断部Ｆ３２が、複数の診断時点での状態量ラベルの組み合わせの時系列データに基づいて、車載システム１の状態を診断する。逐次診断部Ｆ３１の診断結果は、相対的に短時間的な処理によるものであるため、時間的なゆらぎに影響を受ける場合がある。対して複合診断部Ｆ３２は、相対的に長い時間での状態量ラベルの組み合わせの変遷に基づいて最終的な診断結果を出力するため、一時的なノイズに起因して車載システム１の状態を誤診断する恐れをより一層低減することができる。換言すれば、より精度良い診断結果を得ることができる。
【００９２】
なお、逐次診断部Ｆ３１は前述の通り、或る１時点での状態量グループ毎の状態量ラベルの組み合わせに基づいて診断するため、一時的なノイズの影響を複合診断部Ｆ３２よりは受けやすい。しかしながら、不具合パターンの中には、不具合の発現期間が遡及時間に比べて十分に短いものも存在しうる。そのような発現期間が短い不具合パターンについては、或る１時点での状態量グループ毎の状態量ラベルの組み合わせに基づいて診断を実施する逐次診断部Ｆ３１のほうが好適であるといえる。
【００９３】
また、上記の構成は、診断用データを診断対象の状態が過渡期であるか定常時であるか等の状態によっては使い分けない。つまり、診断対象の状態によらずに同一の診断用データを用いて診断を実施する。このような構成によれば、診断対象が取りうる状態の増加に起因して、診断精度が低下したり、診断用データのデータサイズが増大したり、診断用データの学習コストが増大したりする度合いを低減することができる。
【００９４】
以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。例えば下記の種々の変形例は、技術的な矛盾が生じない範囲において適宜組み合わせて実施することができる。
【００９５】
なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。
【００９６】
［変形例１］
上述した実施形態では、逐次診断部Ｆ３１は所定の診断周期でラベル判定部Ｆ２の判定結果をサンプリングするとともに車載システム１の状態を診断する構成を開示したが、これに限らない。例えば図１１に示すように、状態量グループ毎の状態ラベルの組み合わせが変化した時点での、状態量グループ毎の状態ラベルの組み合わせに基づいて車載システム１の状態を診断するように構成されていても良い。そのような構成は、ラベル判定部Ｆ２が状態ラベルの変化を検出する度に、その新たな（換言すれば遷移後の）状態量ラベルの組み合わせに基づいて逐次診断処理を実施する構成に相当する。
【００９７】
上述した実施形態のように、所定の診断周期で逐次診断処理を実施する構成では、前回の逐次診断処理実行時から状態量ラベルの組み合わせが変化していないにも関わらず、再び逐次診断処理を実行する場合が存在する。当然、同じ状態量ラベルの組み合わせに対しては同じ診断結果が得られる。そのため、同じ状態量ラベルが継続している場合に逐次診断処理を複数回実施することは効率的ではない。
【００９８】
対してこの変形例１の構成によれば、状態量グループ毎の状態ラベルの組み合わせの変化が発生する度に、変化後の状態量グループ毎の状態ラベルの組み合わせに基づいて車載システム１の診断を実施する。そのような構成によれば、状態量ラベルの組み合わせが変化していないことに起因して同一の診断結果が得られる診断処理の実行を抑制することができる。つまり、逐次診断処理の効率性を高めることができる。それに伴い、ＣＰＵでの演算負荷を低減することもできる。
【００９９】
［変形例２］
上述した実施形態では、状態量ラベルを状態量記号として用いる態様を開示したがこれに限らない。診断部Ｆ３は、状態量ラベルの系列を分節化してなる状態量シーンを状態量記号として用いて車載システム１の状態を診断してもよい。つまり診断部Ｆ３は、状態量グループ毎の状態量シーンの組み合わせに基づいて車載システム１の状態を診断してもよい。
【０１００】
［変形例３］
上述した実施形態では、ＤＡＡ等を用いて連続的な時系列信号の集合を離散的な状態量ラベルの系列に変換する構成を開示したが、記号化の手法はこれに限定されない。例えば図１２に示すように状態量グループ毎に状態量ラベルの判定ルールを予め作成しておき、ラベル判定部Ｆ２は当該判定ルールに従ってモードを判定してもよい。
【０１０１】
ラベル判定部Ｆ２は、状態量グループを構成する所定の状態量が、判定ルールとして定義されている所定の条件を満たした際に、当該条件に対応する状態量ラベルに遷移したと判定し、以降その他の遷移条件を満たすまで同じ状態量ラベルが継続するものとして判定を行う。このような構成によっても、状態量グループ毎の状態の記号化を実施することができる。
【０１０２】
［変形例４］
変形例３に関連して、ラベル判定部Ｆ２は、予め設計されている判定ルールと、或る状態量ラベルから他の状態量ラベルへの遷移確率モデルとを組み合わせて状態量ラベルを判定するように構成されていてもよい。例えば、ラベル判定部Ｆ２は、予め設計されている判定ルールと、実際の状態量毎のセンシング値とを照らし合わせることにより、状態量ラベル毎の該当確率を算出する。そして、算出した状態量ラベル毎の該当確率と、遷移確率モデルで定義されている状態量ラベル間の遷移確率とを掛け合わせた値が最も大きい状態量ラベルを現在の状態量ラベルと判定する。
【０１０３】
例えば、第２状態量グループの状態量ラベルの判定処理として、実際の状態量毎のセンシング値と判定ルールとに基づいて状態量ラベルｂ１〜ｂ５の該当確率をＰ１〜５と判定しており、現在の状態量ラベルから各状態量ラベルに遷移する確率モデルがＱ１〜５に設定されている場合、現在の状態量ラベルｂｐｒｅは、下記の式によって定まる状態量ラベルとすればよい。なお、式中のｉ及びｊは１〜５までの整数をとる変数である。ｉ及びｊが取りうる値の範囲は、対象とする状態量グループに設定されている状態量ラベルの数に応じて定まる。
【数１】
2019095836.tif 000003
【０１０４】
このような構成によっても、上述した実施形態と同様の効果を奏する。
【０１０５】
［変形例５］
上述した実施形態では診断ＥＣＵ１１が、報告処理部Ｆ４と提示処理部Ｆ５の両方を備えるものとしたが、これに限らない。報告処理部Ｆ４と提示処理部Ｆ５とは、診断結果の出力先が異なるだけであって、何れか一方のみを備える構成であってもよい。
【０１０６】
また、診断ＥＣＵ１１は、報告処理部Ｆ４と提示処理部Ｆ５を備えていなくとも良い。そのような構成においては、点検者が診断結果を参照可能なように、診断結果をＳＤカード等の書き換え可能であって不揮発性の記憶媒体に保存するように構成されていることが好ましい。ここでの点検者は、車両のユーザであってもよいし、ディーラーショップ等の作業員であってもよい。
【０１０７】
［変形例６］
上述した実施形態では診断ＥＣＵ１１が診断部Ｆ３を備える構成を開示したが、これに限らない。診断部Ｆ３の機能はセンタ２が備えていてもよい。その場合には、車載システム１はラベル判定部Ｆ２の判定結果を逐次（例えば診断周期Ｔａ毎に）センタ２に逐次送信する。ラベル判定部Ｆ２の判定結果とは、具体的には状態量グループ毎の状態量ラベルのセットである。状態量グループ毎の状態量ラベルのセットは、換言すれば、状態量グループ毎の状態を示す記号群に相当する。センタ２は、車載システム１から送信されてくる状態量ラベルのセットに基づいて上記の診断部Ｆ３と同様に診断を実施する。
【０１０８】
上記の構成においてセンタ２は、診断結果を車載システム１に返送しても良いし、返送しなくともよい。センタ２が診断部Ｆ３を備える構成によれば、診断ＥＣＵ１１は、外部通信部１５と接続されてあって、且つ、少なくともデータ収集部Ｆ１とラベル判定部Ｆ２とを備えていれば良い。つまり、診断対象には、外部通信部１５、データ収集部Ｆ１、及びラベル判定部Ｆ２が備わっていれば良い。
【０１０９】
ラベル判定部Ｆ２の判定結果は、連続的な時系列信号の集合を記号化したものであるため、状態量毎のセンシング値をセンタ２に送信する構成に比べて、データサイズを低減することができる。
【０１１０】
［変形例７］
上述した実施形態では診断部Ｆ３は、正常モデルを用いて車載システム１が正常に動作しているか否かを反転する構成を開示したがこれに限らない。診断用データとして不具合パターンモデルのみが用意されている構成において、診断部Ｆ３は、いずれの不具合パターンにも該当しなかった場合に、車載システム１は正常に動作していると判定してもよい。つまり、正常モデルは必ずしも診断用データとして用意されている必要はない。
【０１１１】
［変形例８］
以上では診断対象を車載システム１とする態様を開示したがこれに限らない。飛行機や船舶等の他の種別の移動体に適用することができる。また、工場設備や、家庭用のコンピュータなど、種々の装置に適用することができる。つまり、診断対象は、車載システム１に限らず、複数のセンサを備える種々の装置とすることができる。
【符号の説明】
【０１１２】
１００  診断システム、１  車載システム（診断対象）、２  センタ、１１  診断ＥＣＵ、Ｆ１  データ収集部、Ｆ２  ラベル判定部、Ｆ３  診断部、Ｆ３１  逐次診断部、Ｆ３２  複合判定部、Ｆ４  報告処理部、Ｆ５  提示処理部、Ｆ６  更新処理部
【図１】
2019095836.tif 000004
【図２】
2019095836.tif 000005
【図３】
2019095836.tif 000006
【図４】
2019095836.tif 000007
【図５】
2019095836.tif 000008
【図６】
2019095836.tif 000009
【図７】
2019095836.tif 000010
【図８】
2019095836.tif 000011
【図９】
2019095836.tif 000012
【図１０】
2019095836.tif 000013
【図１１】
2019095836.tif 000014
【図１２】
2019095836.tif 000015