以下、本開示の実施形態について図を用いて説明する。図1は、本開示に係る診断システム100の概略的な構成の一例を示す図である。図1に示すように診断システム100は、車両に搭載されている車載システム1と、車両外に配置されているセンタ2とを備えている。なお、ここでは一例として車載システム1は駆動源としてエンジンを備える車両に搭載されているものとするが、これに限らない。車載システム1は、駆動源としてモータを備える車両に搭載されていてもよい。
<全体構成について>
車載システム1は、診断ECU11、車載センサ12、ディスプレイ13、入力装置14、及び外部通信部15を備える。診断ECU11は、車載センサ12、ディスプレイ13、入力装置14、及び外部通信部15のそれぞれと、車載ネットワーク又は専用の信号線を介して通信可能に構成されている。
診断ECU11は、当該ECUが搭載されている車両(換言すれば車載システム1)の診断を行う電子制御装置(Electronic Control Unit:ECU)である。診断ECU11は、後述の通り、車載センサ12から提供される複数種類の状態量についての計測値に基づいて、車載システム1が正常に動作しているか否かを判定(換言すれば診断)する。診断ECU11が診断装置に相当する。
この診断ECU11は、コンピュータとして構成されている。すなわち、CPU111、RAM112、フラッシュメモリ113、I/O、及びこれらの構成を接続するバスラインなどを備える。なお、診断ECU11が備えるCPUの数は1つでも複数でもよい。また、診断ECU11は、CPU111の代わりに、GPUやMPUを用いて実現されていても良い。さらにCPU111やGPU、MPUを組み合わせて実現されていてもよい。フラッシュメモリ113には、通常のコンピュータを診断ECU11として機能させるためのプログラム(以降、診断プログラム)等が格納されている。
車載センサ12は、ドライバによる運転操作に関する情報(以下、操作情報)を出力するセンサや、運転操作の結果として表れる車両の挙動に関する情報(以下、挙動情報)を検出するセンサの集合である。また、車両の走行環境を示す情報(以下、環境情報)を出力するセンサや、ドライバの身体的、精神的状態を示す情報(以下、ドライバ情報)を出力するセンサも車載センサ12に含まれうる。
操作情報としては、アクセルペダルの操作量、ブレーキペダルの操作量、ステアリングホイールの操作量である操舵角、方向指示器の作動状態、トランスミッションのシフト位置などを用いることができる。
操作情報を出力するセンサとは、アクセルペダルの踏み込み量を検出するアクセルセンサ、ブレーキペダルの踏み込み量もしくはマスタシリンダが発生するブレーキ圧を検出するブレーキセンサ、操舵角としてのステアリングホイールの回転角度を検出する操舵角センサなどである。もちろん、操作情報を出力するセンサは、上述したセンサに限らない。例えば、トランスミッションのシフト位置を検出するポジションセンサや、方向指示器(いわゆるウインカー)を作動させるためのウインカースイッチなども操作情報を出力するセンサに該当する。
挙動情報としては、車両の速度や、加速度、エンジン回転速度、スロットル開度、ヨーレートなどを用いることができる。挙動情報を出力するセンサとは、例えば、車両の走行速度を検出する車速センサや、車両に作用する加速度を検出する加速度センサ、エンジンの回転速度を検出するセンサ、スロットルバルブの開度を検出するスロットル開度センサ、車両に作用するヨーレートを検出するヨーレートセンサなどである。
環境情報としては車両周辺に存在する物体の位置情報や、それらの物体の車両に対する相対速度、降雨や降雪といった天候、気温、明るさ、時刻などを用いることができる。また、環境情報には、車両の位置情報(例えば、緯度、経度、高度)や、車両が走行している道路の種別(例えば一般道路や高速道路など)などといった地理的な情報を示す地理的環境情報を含めることができる。
環境情報を出力するセンサとしては、車両周辺に存在する物体を検出する周辺監視センサや、降雨を検出するレインセンサ、外部の明るさを検出する照度センサ、水平面に対する車体の傾斜角度を検出する傾斜センサ、外気温を検出する温度センサ、車両の現在位置を逐次算出(換言すれば特定)するロケータなどが該当する。
なお、周辺監視センサとは、自車の周辺の所定範囲を撮像範囲とする周辺監視カメラや、ソナー,ミリ波レーダ,LIDAR(Light Detection and Ranging/Laser Imaging Detect ion and Ranging)等である。また、他の車両と相互通信を実施する車車間通信装置も、車両の周辺に存在する他車両についての情報を収集する装置に該当するため、周辺監視センサに含まれる。ロケータは、例えばGNSS(Global Navigation Satellite System)を構成する測位衛星が送信する測位信号を受信するGNSS受信機を備え、GNSS受信機が受信した測位信号を用いて位置を算出する装置である。
ドライバ情報としては、例えばドライバの顔の向きや目の開度、脈拍、意識レベル、連続運転時間などを採用することができる。ドライバ情報を出力するセンサとは、例えばドライバの顔の向きや目の開度を検出するDSM(Driver Status Monitor)や、脈拍を検出する脈波センサなどである。なお、DSMは、近赤外光源及び近赤外カメラと、これらを制御する制御ユニット等とによって構成されている。DSMは、近赤外カメラを自車の運転席側に向けた姿勢にて、例えばインスツルメントパネルの上面に配置されている。
ディスプレイ13は、診断ECU11から入力された画像を表示するデバイスである。ディスプレイ13は、車両に搭載されたディスプレイでも良いし、携帯端末のディスプレイでもよい。なお、ディスプレイ13はヘッドアップディスプレイでもよい。
入力装置14は、診断ECU11に対するユーザの指示操作を受け付けるためのデバイスである。入力装置14は、例えばディスプレイ13に積層されたタッチパネルである。なお、他の態様として入力装置14は、音声認識技術を用いて実現される音声入力装置であってもよい。また、センターコンソールに配置されたハプティックデバイスであってもよい。その他、マウス、キーボードなどであっても良い。上述した複数種類のデバイスを入力装置14として備えていても良い。
外部通信部15は、公衆無線通信回線等を利用してセンタ2などの外部装置と無線通信するための通信モジュールである。外部通信部15は、診断ECU11から入力されたデータを変調してセンタ2に送信するとともに、センタ2から送信されたデータを受信して診断ECU11に提供する。
センタ2は、車載システム1と通信することで、車載システム1の状態を管理する構成である。センタ2は、車載システム1と通信するための通信モジュールや、コンピュータを主体として構成されている。センタ2は車載システム1から送信される後述の不具合レポートを受信した場合には、メンテナンスの手配等の処理を実施する。
また、センタ2は、診断ECU11で使用される診断用データを保存している記憶装置である診断モデルデータベースを備える。センタ2は、機械学習又は管理者の操作によって、診断用データを随時更新する。診断用データの更新を実施した場合には、車載システム1に対して診断用データの更新が存在する旨を通知し、診断ECU11からの要求に基づいて診断ECU11に対して診断用データを配信する。
<診断ECU11の構成について>
次に図2を用いて診断ECU11の構成及び機能について説明する。診断ECU11は図2に示すようにデータ収集部F1、ラベル判定部F2、診断部F3、報告処理部F4、提示処理部F5、更新処理部F6、記号化用データ記憶部M1、及び診断用データ記憶部M2を備える。記号化用データ記憶部M1及び診断用データ記憶部M2を除く各部は、CPUが所定の診断プログラムを実行することによって実現されるものである。つまり、CPUによって実現される各種機能を機能ブロック毎に分けて図示したものが図2である。但し、これら各部は必ずしもソフトウェアにて実現されている必要はなく、その全部または一部はハードウェアにて実現されていてもよい。ハードウェアで実現する態様には1つ又は複数のICを用いて実現する態様も含まれる。記号化用データ記憶部M1、及び診断用データ記憶部M2は、不揮発性の記憶媒体を用いて実現されている。例えば記号化用データ記憶部M1及び診断用データ記憶部M2は、フラッシュメモリ113が備える記憶領域を用いて実現することができる。
データ収集部F1は、車載センサ12から種々の状態量についてのデータを逐次取得する。すなわち、操作情報や挙動情報、環境情報、ドライバ情報などを車載センサ12から逐次取得する。また、データ収集部F1は、所定の状態量の検出値を時間軸で微分した微分データを生成する。例えばデータ収集部F1は、操舵角を時間微分することによって、操舵角の単位時間当りの変化量(いわゆる操舵速度)を算出する。すなわち、データ収集部F1は、アクセルペダルの操作量や車速などといった車載センサ12によって検出される状態量の他、車載センサ12の検出値を加工してなる値が示す状態量についての情報も逐次取得(厳密には算出)する。なお、データ収集部F1は、各センサによる検出値の微分値そのものではなく、単なる差分値を微分データとして用いてもよい。また、1回微分して定まる状態量だけでなく、2回微分して定まる状態量や、積分して定まる状態量を取得するように構成されていても良い。検出値及び算出値を区別しない場合にはまとめてセンシング値と記載する。
データ収集部F1は、逐次取得する状態量毎のセンシング値を、状態量毎に区別してRAM112に保存する。状態量毎のセンシング値は、最新の取得値が先頭となるように時系列順に並べて保存されれば良い。なお、データ収集部F1は、車載システム1の診断に必要な種類の状態量についての値を取得するように構成されていればよく、上述した全ての状態量について取得する必要はない。つまり、データ収集部F1が収集する状態量の具体的な種類は適宜設計されればよい。
複数種類の状態量は、予め設定されている規則によって図3に示すように、複数の状態量グループにグループ化されて取り扱われる。換言すれば、データ収集部F1は、予め設定されている複数の状態量グループのそれぞれを構成する状態量についてのセンシング値を取得する。
便宜上本明細書では、状態量グループとして、図3に示すように第1〜第4状態量グループまでの4つの状態量グループが設定されている場合を例にとって、診断ECU11の作動を説明する。第1状態量グループは例えばドライバの加減速操作に係る状態量の集合である。第2状態量グループは、ドライバの加減速操作の結果として表れる車両の挙動に関す状態量の集合である。第3状態量グループは例えばドライバの操舵操作に係る状態量の集合である。第4状態量グループは、ドライバの操舵操作の結果として表れる車両の挙動に関す状態量の集合である。
なお、図3に示す状態量A〜Mは、データ収集部F1が取得する状態量を概念的に表している。例えば状態量A〜Cは順に、アクセルペダルの踏み込み量(換言すればアクセル位置)、ブレーキペダルの踏み込み量(換言すればブレーキ位置)、シフトポジションを表している。状態量D〜Gは順に、車速、車両前後方向に作用する加速度、スロットル開度、エンジン回転速度を表している。状態量H〜Jは、ステアリングホイールの中立位置に対する回転角度(つまり回転角度)、操舵速度、方向指示器の作動状態を表している。状態量K〜Mは順に、ヨーレート、車体に対するタイヤの切れ角(以降、タイヤ切れ角)、車体に対するタイヤの切れ角を制御する転舵モータの駆動電流(以降、転舵モータ電流)を表している。なお、タイヤ切れ角はトー角とも称される状態量である。
もちろん、診断ECU11に設定されている状態量グループの数や、各グループに属する状態量の種類(つまり状態量グループの構成)は適宜設計されればよい。例えば、診断ECU11には、環境情報に属する状態量のグループが設定されていてもよいし、ドライバ情報に属する状態量のグループが設定されていても良い。上述した以外の状態量グループが設定されていても良い。
また、第1状態量グループは、アクセルペダルの操作速度(以降、アクセル速度)や、ブレーキペダルの操作速度(以降、ブレーキ速度)を含んでいても良い。その他、1つの状態量が複数の状態量グループに属していても良い。例えば車速などは、第2状態量グループだけでなく、第4状態量グループに属していても良い。さらに、図3に示す種々の状態量グループは更に細分化されていてもよい。例えば、第1状態量グループは、加速操作に係る状態量のグループと、減速操作に係る状態量のグループとに分割されていても良い。第2状態量グループも同様である。
なお、上記のように設定された第2状態量グループは、第1状態量グループに属する種々の状態量に対応するドライバの加減速操作を受けての車両挙動を示す状態量によって構成されているため、第1状態量グループと相関が強いグループである。また、上記のように設定された第4状態量グループは、第3状態量グループに属する種々の状態量に対応するドライバの操舵操作を受けての車両挙動を示す状態量によって構成されているため、第3状態量グループと相関が強いグループである。なお、右左折や車線変更の前後には加減速等の操作が発生する可能性が高い。故に、第1状態量グループと第3状態量グループは無関係ではなく、互いにある程度の相関がある。第2状態量グループと第4状態量グループも同様である。
複数の状態量グループのそれぞれには、予めそのグループの状態を示す記号としての状態ラベルが複数用意されている。ラベル判定部F2は、複数の状態量のそれぞれの値の時系列データに基づいて、状態量グループ毎の状態を状態量ラベルで表現(つまり記号化)する構成である。また、このラベル判定部F2は、複数の状態量の時系列データに基づいて、複数の状態量グループの現在の状態が、状態量グループ毎に予め用意されている複数の状態ラベルの何れに該当するかを逐次判定する構成に相当する。ラベル判定部F2が記号化部に相当する。状態ラベルが状態量記号の一例に相当する。
ラベル判定部F2は、状態量グループ毎に記号化を行う。状態量グループ毎の記号化には、二重分節構造を利用した教師なし分割法によって分節化を行う二重分節解析器(DAA:Double Articulation Analyzer)を利用することができる。DAAでは、状態量グループを構成する各状態量(以降、構成状態量)を要素とする多次元の空間において、構成状態量のセンシング値から把握される状態量グループの状態を表すクラスタと、各クラスタ間の遷移確率とが設計者や機械学習によって定義されている。クラスタが、状態量グループが取りうる状態の区分単位であって、状態量ラベルに対応する。
本実施形態では記号化の方法として、隠れ状態とその状態間の確率的遷移で表現されるモデルの一つである階層ディリクレ過程隠れマルコフモデル(いわゆるHDP−HMM)を利用する。HDP−HMMは、HMMに無限次元の隠れ状態(クラスタに相当)を仮定することにより、入力される各信号に応じて隠れ状態の数を決定するという柔軟さを有する。そのため、HMMを利用する際に、隠れ状態数を事前に設計する必要がないという利点を有する。特に、HDP−HMMとして、スティッキーHDP−HMMを用いることが好ましい。スティッキーHDP−HMMは、HDP−HMMの自己遷移確率にバイアスを付加したもので、自己遷移確率を大きくすることにより、隠れ状態の過剰遷移を抑えることができ、動作の連続性を仮定するモデリングを効率的に行うことが可能となる。
記号化用データ記憶部M1は、ラベル判定部F2が、各種状態量の時系列データに基づいて状態量グループの状態を記号化(換言すれば離散化)するために必要なデータを記憶している。状態量グループを記号化するために必要なデータとは、各状態量ラベルの発生する確率を定義したデータや、或る状態量ラベルから別の状態量ラベルへと遷移する確率を示す遷移確率モデル等である。遷移確率モデルとは、各クラスタ間の遷移確率を示すデータに相当する。
ラベル判定部F2は、記号化用データ記憶部M1に保存されているデータを用いて、データ収集部F1が取得している構成状態量毎の現在のセンシング値のまとまりが、いずれのクラスタに属するかを統計的に処理することにより、構成状態量の時系列データを状態量ラベルで区分する。
図4は、第1状態量グループに対する状態量ラベルの付与(つまり記号化)を概念的に表したものである。図4のa1〜a4は、状態量ラベルを表している。図4に示すように、状態量グループの状態は時間の経過に伴って順次記号化されていき、記号列で表現されることとなる。
また、DAAは、生成された記号列を、統計情報を利用した離散文字列の教師なしチャンク化手法の1例であるNested Pitman-Yor Language Model(NPYLM)を用いて、1まとまりのシーン(以降、グループシーン)を意味する部分系列に分節化する。この際、辞書サイズ(即ち、部分系列の数)ができるだけ小さく、部分系列の並びからなる記号列全体の生成確率が最大となるようにする。これにより、状態量ラベル列の状態量シーンへの分節化を行うことが可能になる。部分系列間の遷移確率、および部分系列の生成確率は、学習によって予め生成されたものを使用する。
なお、HDP−HMMやNPYLMを適用したDAAについては、非特許文献、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、等を参照することによって取り入れることができる。
なお、本実施形態では一例としてHDP−HMMやNPYLMを適用したDAAを用いて状態量グループ毎の記号化を実施するものとするがこれに限らない。多様な手法を採用することができる。第2状態量グループ、第3状態量グループ、及び第4状態量グループのそれぞれについても、第1状態量グループと同様に、当該グループを構成する状態量のセンシング値の時系列データを、DAAを用いて状態量ラベルの列に変換する。
図5は、状態量グループ毎の記号化を実施した結果を示す概念図である。各状態量グループには前述の通り異なる状態量ラベルが用意されている。図5に示すaj、bj、cj、及びdj(jは5までの整数)は順に、第1〜第4状態量グループの状態量ラベルを表している。例えば状態量ラベルa1〜a5は順に、停車状態、弱い加速操作、強い加速操作、弱い減速操作、強い減速操作(いわゆる急ブレーキ)に対応する状態量ラベルである。各状態量ラベルに対応する実際の車両状態等は、設計者又は人工知能によって適宜設定される。
ここでは一例として各状態量グループに対して5つの状態量ラベルが用意されているがこれに限らない。状態量グループ毎に設定されている状態量ラベルの数(以降、ラベル数)は適宜設計される。例えば、第3状態量グループについてのラベル数は3や4、6などであってもよい。ラベル数は2以上であればよい。
ラベル判定部F2の状態量グループ毎の状態量ラベルの判定結果は逐次RAM112に保存される。状態量グループ毎の状態量ラベルの判定結果は、状態量グループごとに区別して保存される。1つの状態量グループについての判定時刻が異なる複数の判定結果は、最新の判定結果が先頭となるように時系列順にソートされて保存されれば良い。
診断部F3は、ラベル判定部F2の判定結果に基づいて、診断用データ記憶部M2に保存されているデータを参照し、車載システム1が正常に動作しているか否かを判定する構成である。診断用データ記憶部M2は、診断用データとして、車載システム1が正常であるか否かを判定するための正常モデルと、車載システム1に生じている不具合のパターンを特定するための不具合パターンモデルを備える。
診断用データ記憶部M2に記憶されている正常モデルは、例えば車載システム1が正常である場合に観測されうる、所定の2つの状態量グループの状態量ラベルの組み合わせについての発生確率を示すデータとすることができる。図6の(A)は、車載システム1が正常である場合に観測されうる、第1状態量グループと第2状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータを概念的に表している。図6の(B)は、車載システム1が正常である場合に観測されうる、第3状態量グループと第4状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータを概念的に表している。
ここでは一例として診断用データ記憶部M2は、車載システム1が正常である場合に観測される第1状態量グループと第2状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータと、第3状態量グループと第4状態量グループの組み合わせ毎の発生確率を示すデータの両方を、正常モデルとして備えているものとする。もちろん、正常モデルを形成する状態量グループの組み合わせは上述したものに限らない。第1状態量グループと第4状態量グループの状態量ラベルの組み合わせについてのデータを保持していてもよい。
不具合パターンモデルは、図7に示すように不具合のパターン毎に用意されている。すなわち、車載システム1に生じうる不具合としてm種類の不具合パターンが想定されている場合には、第1不具合パターンから、第m不具合パターンまでのそれぞれに対応する不具合パターンモデルが用意されている。或る不具合についての不具合パターンモデルは、当該不具合が発生している場合に観測されうる、所定の2つの状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータである。図7では、各不具合パターンモデルは、第1状態量グループと第2状態量グループの状態量ラベルの組み合わせ毎の発生確率(換言すれば生起確率)を示すデータで構成されている態様を図示しているが、これに限らない。不具合パターンモデルもまた正常モデルと同様に、第3状態量グループと第4状態量グループの状態量ラベルの組み合わせ毎の発生確率を示すデータを備えていても良い。また、不具合パターンモデルを形成する状態量グループの組み合わせは上述したものに限らない。第1状態量グループと第4状態量グループの組み合わせを用いて不具合パターンモデルを構築してもよい。不具合パターンモデルを形成する状態量グループの組み合わせは、不具合の内容に応じて適宜設計されればよい。
なお、正常モデルは、正常であることが確認されている車載システム1を搭載している車両を走行させることによって得られるデータ(以降、正常データ)を元に構築されればよい。正常データは実車試験によって収集しても良いし、実際の道路上を走行する各車両にデータ収集部F1が収集した生データを送信させることで収集してもよい。収集したデータに基づく正常モデル等の構築は機械学習によって実現されれば良い。正常モデル及び不具合パターンモデルは、車載システム1の状態ごとに、状態量ラベルの組み合わせがどの程度の頻度で現れるかを表す統計データである。
診断部F3は、より細かい要素として、逐次診断部F31と複合診断部F32とを備える。逐次診断部F31は、所定の診断周期Ta毎に、その時点での各状態量グループの状態量ラベルの組み合わせに基づいて車載システム1を診断する構成である。便宜上、診断周期Ta毎の時点を診断時点と称する。最初の診断時点は、診断ECU11の起動処理が完了した時点や、診断ECU11が起動してから所定時間経過したタイミング、ラベル判定部F2による状態量グループごとの状態量ラベルの最初の判定が完了した時点など、適宜設計されれば良い。図8の黒丸は、各診断時点を表している。
診断周期Taは適宜設計されればよい。例えば診断周期Taは1秒や、5秒、10秒などに設定されていれば良い。診断周期Taは、1つの状態量ラベルが継続する時間の平均値や、平均値よりも長い時間に設定されていることが好ましい。なお、図8では時刻t1において、各状態量グループの状態量ラベルの組み合わせとして、(a2,b1,c2,d2)が得られている場合を示している。
例えば逐次診断部F31は、図8の時刻t1のように、第1状態量グループと第2状態量グループの状態量ラベルの組み合わせとして(a2,b1)が得られている場合には、正常モデルを参照し、車載システム1が正常な場合に(a2,b1)の組み合わせが観測される確率Pabを取得する。なお、一例として図6に示す正常モデルを用いれば、車載システム1が正常な場合に(a2,b1)の組み合わせが観測される確率Pabは0.3である。
また、逐次診断部F31は第3状態量グループと第4状態量グループの状態量ラベルの組み合わせとして(c2,d2)が得られている場合には、正常モデルを参照し、車載システム1が正常な場合に(c2,d2)の組み合わせが観測される確率Pcdを取得する。なお、一例として図6に示す正常モデルを用いれば、車載システム1が正常な場合に(c2,d2)の組み合わせが観測される確率Pabは0.4である。観測されている状態量ラベルの組み合わせと正常モデルとから定まる確率Pab、Pcdは、観測された状態量ラベルの組み合わせが正常である確率(換言すれば正常性)を示すパラメータである。故に、正常モデルを参照することで定まる観測された状態量ラベルの組み合わせの発生確率のことを以降では正常確率とも称する。
逐次診断部F31は、診断に用いる状態量グループの組み合わせ毎の正常確率に基づいて、時刻t1の時点において車載システム1が正常であるか否かを判定する。診断に用いる状態量グループの組み合わせとは、ここでは第1状態量グループと第2状態量グループの組み合わせと、第3状態量グループと第4状態量グループの組み合わせのことである。便宜上以降では、車載システム1の正常性の診断に用いる状態量グループの組み合わせのことを、診断用グループペアとも記載する。
例えば、診断用グループペア毎の正常確率(ここではPabとPcd)の何れもが、所定の正常判定閾値以上である場合には車載システム1は正常であると判定し、診断用グループペア毎の正常確率(ここではPabとPcd)の少なくとも何れか一つが正常判定閾値未満である場合には、不具合が発生していると判定する。正常判定閾値は、正常判定閾値は全ての状態量グループの組み合わせ毎において共通する値としても良いし、状態量グループの組み合わせ毎に異なる値に設定されても良い。逐次診断部F31は、上記の判定が完了すると、その判定結果を時刻情報と対応付けてRAM112に保存する。
なお、上記の判定態様は一例であって、これに限らない。例えば逐次診断部F31は、診断用グループペア毎の正常確率に基づいて定まる統合正常確率Pnが、所定の正常判定閾値以上である場合には車載システム1は正常であると判定し、統合正常確率Pnが正常判定閾値未満である場合には、不具合が発生していると判定してもよい。
統合正常確率Pnは、例えば、診断用グループペア毎の正常確率(ここではPabとPcd)を掛け合わせた値である。なお、他の態様として、統合正常確率Pnは、診断用グループペア毎の正常確率の最小値としても良い。そのような態様は、具体的には、PabとPcdの小さい方の値を統合正常確率Pnとして用いる態様に相当する。また、診断用グループペア毎の正常確率の平均値を統合正常確率Pnとして用いても良い。そのような態様は、具体的にはPabとPcdの平均値を統合正常確率Pnとして用いる態様に相当する。統合正常確率Pnは診断時点での車載システム1の正常性を示す指標値である。統合正常確率Pnが局所正常確率に相当する。
また、逐次診断部F31は、車載システム1の動作状態が正常ではない(換言すれば不具合が生じている)と判定した場合には、不具合パターンモデルを用いて車載システム1に生じている不具合の特定を試みる。具体的には、逐次診断部F31は図9に示すように、観測されている状態量ラベルの組み合わせを用いて、不具合パターン毎の該当確率を算出する。或る不具合パターンについての該当確率とは、当該不具合が生じている確率のことであって、その不具合パターンが発生していることの尤もらしさを示す指標に相当する。例えば第1不具合パターンの該当確率は、第1不具合パターンモデルを参照することによって、第1不具合パターンが生じている場合に、現在観測されている状態量ラベルの組み合わせが発生する確率を特定する。
そして逐次診断部F31は、種々の不具合パターンのうち、該当確率が最も大きい不具合パターンを、車載システム1に発生している不具合として採用し、判定時刻と対応付けてRAM112に保存する。便宜上、逐次診断部F31が実施する、或る1時点での状態量グループ毎の状態量ラベルの組み合わせに基づいて当該診断時点での車載システム1の状態を診断する処理を逐次診断処理と称する。
本実施形態では一例として逐次診断部F31は、統合正常確率Pnを診断周期Taで逐次算出するとともに、正常であると判定した場合にも、観測されている状態量ラベルの組み合わせを用いて、不具合パターン毎の該当確率を算出する。逐次診断部F31が算出した統合正常確率Pnや、不具合パターン毎の該当確率は、生成時刻を示すタイムスタンプが付与されてRAM112に保存される。なお、診断周期Taごとの統合正常確率Pnや、不具合パターン毎の該当確率の算出は、次に述べる複合診断部F32によって実行されてもよい。
複合診断部F32は、生成時刻が現時点から所定の遡及時間以内に算出された複数の統合正常確率Pnを用いて、車載システム1が正常であるか否かを判定する構成である。遡及時間は、前述の診断周期Taの2倍以上の値に設定されていればよい。ここでは一例として遡及時間は診断周期Taの10倍に設定されているものとする。そのような構成は、複合診断部F32が直近10回分の統合正常確率Pnに基づいて車載システム1の診断を行う構成に相当する。
具体的には、複合診断部F32は、直近10回分の統合正常確率Pnに基づいて、車載システム1が正常であることの尤もらしさを示す指標として、正常尤度Lnを算出する。正常尤度Lnは、下記式によって定まる。
Ln=Pn(t)×Pn(t−1)×Pn(t−2)×…×Pn(t−9)
式中のPn(t)は最新の統合正常確率Pnを表しており、Pn(t−1)は最新よりも1つ前の(つまり前回算出した)統合正常確率Pnを表している。Pn(t−2)は前々回算出した統合正常確率Pnを表している。Pn(t−9)は、最新のものよりも9つ前の統合正常確率Pnを表している。
そして、複合診断部F32は、上記式で求めた正常尤度Lnが所定の尤度閾値以上である場合に車載システム1は正常であると判定する一方、正常尤度Lnが尤度閾値未満である場合には車載システム1は正常ではないと判定する。ここでは複数時点で算出した統合正常確率Pnをかけ合わせた値を正常尤度Lnとして採用するが、正常尤度Lnの算出態様はこれに限らない。正常尤度Lnは直近10回分の統合正常確率Pnを足し合わせた値としても良い。
また、本実施形態では遡及時間を診断周期Taの10倍に設定しているが、これに限らない。遡及時間は、診断周期Taの5倍や20倍であってもよい。そのような態様は、複合診断部F32が、直近5回分や20回分の統合正常確率Pnに基づいて車載システム1の診断を行う構成に相当する。
また、本実施形態では複合診断部F32は遡及時間毎に診断を実施するものとするが、これに限らない。例えば、複合診断部F32は、車両の走行用電源(いわゆるイグニッション電源)がオフに設定された場合に、走行用電源がオンとなってからオフとなるまでに算出された統合正常確率Pnを用いて車載システム1を診断するように構成されていても良い。そのような構成は、車両の走行用電源がオンとなってからオフとなるまでを遡及時間に設定した態様に相当する。
さらには、複合診断部F32は、車両が停車する度に、車両が発進してから停車するまでの間に算出された統合正常確率Pnを用いて車載システム1を診断するように構成されていても良い。そのような構成は、車両が発進してから停車するまでを遡及時間に設定した態様に相当する。
その他、複合診断部F32は、診断ECU11が車載システム1の診断を実施するためのテストモードに設定されている間に算出した統合正常確率Pnを用いて車載システム1を診断するように構成されていても良い。そのような態様は、別の観点によれば、テストモードに設定されてからテストモードが解除されるまで(換言すれば終了するまで)を遡及時間に設定した態様に相当する。
また、複合診断部F32は、正常尤度Lnを用いた診断の結果、車載システム1は正常ではないと判定した場合には、不具合パターンモデルを参照して、車載システム1に生じている不具合パターンの特定を試みる。具体的には、現時点から遡及時間以内に存在する各診断時点での不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度L1〜Lmを算出する。また、本実施形態では遡及時間は診断周期Taの10倍に設定されているため、上記の構成は、直近10回分の診断時点での不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度L1〜Lmを算出する構成に相当する。加えて、本実施形態では、車載システム1が正常であると判定している場合も診断時点毎に、不具合パターン毎の該当確率を算出している。故に、複合診断部F32は、既に算出済みの直近10回分の不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度L(1)〜L(m)を算出する構成に相当することができる。つまり、複合診断部F32は、生成時刻が現時点から遡及時間以内に算出されている不具合パターン毎の該当確率を用いて、不具合パターン毎の該当尤度L1〜Lmを算出する。
図10は複合診断部F32が車載システム1に生じている不具合パターンを特定する際の作動を概念的に表した図である。該当尤度L(1)は車載システム1に生じている不具合パターンが第1不具合パターンであることの尤もらしさを示す指標であり、該当尤度L(2)は車載システム1に生じている不具合パターンが第2不具合パターンであることの尤もらしさを示す指標である。該当尤度L(m)は車載システム1に生じている不具合パターンが第m不具合パターンであることの尤もらしさを示す指標である。或る不具合パターン(以降、第j不具合パターン)の該当尤度Ljは以下の式によって算出可能である。
L(j)=P(j,t)×P(j,t−1)×P(j,t−2)×P(j,t−9)
式中のP(j,t)は最新の診断時点での第j不具合パターンの該当確率を表しており、P(j,t−1)は最新の診断時点よりも1つ前の診断時点での第j不具合パターンの該当確率を表している。P(j,t−2)は最新の診断時点よりも2つ前の診断時点での第j不具合パターンの該当確率を表している。P(j,t−9)は、最新の診断時点よりも9つ前の診断時点での第j不具合パターンの該当確率を表している。
そして複合診断部F32は、種々の不具合パターンのうち、該当尤度が最も大きい不具合パターンを、車載システム1に発生している可能性が高い不具合と判定する。便宜上、複合診断部F32が実施する、車載システム1の状態を診断する処理を長期診断処理と称する。
車載システム1が正常であるか否か、及び正常ではない場合に予想される不具合パターンといった、複合診断部F32の診断結果は、判定時刻と対応付けられてRAM112に保存される。なお、保存先は書き換え可能な不揮発性メモリであってもよい。
報告処理部F4は、複合診断部F32によって車載システム1が正常ではないと判定された場合に、外部通信部15と協働して、センタ2に車載システム1が正常に動作してないことを報告する構成である。具体的には、車載システム1が正常に動作してないことを示す通信パケットである不具合レポートを生成し、送信する。また、報告処理部F4は、逐次診断部F31よって車載システム1が正常ではないと判定された場合にも車載システム1が正常に動作してないことを示す通信パケットである不具合レポートを生成し、送信する。
なお、本実施形態ではより好ましい態様として、不具合レポートには、車載システム1に生じていると想定される不具合パターンについての情報も含まれているものとする。そのような態様によれば、センタ2は不具合レポートを受信することによって、車載システム1にどのような不具合が生じているかを特定することができる。つまり、車載システム1に生じている不具合パターンについての情報を収集することができる。
また、不具合レポートには、より好ましい態様として、不具合レポートが示す診断結果が逐次診断処理の結果であるのか、長期診断処理の結果であるのかを示す診断パターン情報も含まれているものとする。このような態様によれば、センタ2は受信した不具合レポートが逐次診断処理によるものなのか、長期診断処理によるものなのかを判別することができる。
なお、本実施形態では一例として、逐次診断部F31によって車載システム1が正常ではないと判定された場合と、複合診断部F32によって車載システム1が正常ではないと判定された場合の両方において、不具合レポートを送信するものとするが、これに限らない。複合診断部F32によって車載システム1が正常ではないと判定された場合にのみ、不具合レポートを送信するように構成されていても良い。そのような構成によれば車載システム1からセンタ2に送信する通信量及び通信料を低減することができる。逐次診断部F31によって車載システム1が正常ではないと判定された場合にのみ、不具合レポートを送信するように構成されていても良い。
また、報告処理部F4は、他の態様として、逐次診断部F31又は複合診断部F32によって車載システム1は正常に動作していると判定されている場合、車載システム1が正常に動作していることを示す通信パケットである正常レポートを生成し、センタ2に送信するように構成されていても良い。そのような構成は、逐次診断部F31又は複合診断部F32が診断処理を実施する度に、車載システム1の状態の診断結果を示す通信パケットであるステータスレポートをセンタ2に送信する構成に相当する。車載システム1が正常であることを示すステータスレポートが正常レポートに相当し、車載システム1に不具合が生じていることを示すステータスレポートが不具合レポートに相当する。
提示処理部F5は、複合診断部F32よって車載システム1が正常ではないと判定された場合に車載システム1が正常に動作してないことを示す画像(以降、不具合通知画像)を表示する構成である。不具合通知画像はテキスト情報のみを表示する画像であってもよい。本実施形態ではより好ましい態様として、不具合通知画像には、車載システム1に生じていると想定される不具合パターンについての情報も含まれているものとする。
なお、本実施形態では一例として提示処理部F5は、複合診断部F32によって車載システム1が正常ではないと判定された場合にのみ、不具合通知画像を表示するが、これに限らない。他の態様として、逐次診断部F31によって車載システム1が正常ではないと判定された場合にも、不具合通知画像を表示するように構成されていても良い。
更新処理部F6は、センタ2から診断用データが更新されたことを通知された場合に、自動的に又はユーザの承諾を得た上で、センタ2と通信を実施し、診断用データ記憶部M2に保存されている診断用データの更新を実施する。診断ECU11は当該更新処理部F6を備えることによって、診断用データを随時更新することができる。また、最新の診断用データを用いて車載システム1の診断が可能となる。
<実施形態のまとめ>
上記の構成では、ラベル判定部F2が、車載センサ12の出力値等(つまりセンシング値)の連続的な時系列信号の集合を離散的な状態量ラベルの系列に変換する。そして逐次診断部F31は、状態量グループ毎の状態量ラベルの組み合わせに基づいて車載システム1の状態を診断する。
診断に用いられる状態量ラベルは、センシング値の時系列的な流れを考慮して決定されるため、瞬間的なノイズの影響を緩和することができる。特に本実施形態では、或る状態量ラベルから別の状態量ラベルへと遷移する確率のモデルである遷移確率モデルを用いて状態量ラベルを判定する。故に、センサ出力値がノイズによってぶれる場合においても、実際の状態量ラベルの変化による出力値変動であるかを確率的に判定することができ、より一層、瞬間的なノイズによる状態量ラベルの判定結果への影響を小さくすることができる。
加えて、複数種類の状態量を個々に記号化して取り扱う構成に比べて、複数種類の状態量をグループ化して記号化する構成によれば、或る状態量についてのセンシング値にノイズがのっている場合であっても、他の状態量によって当該ノイズ成分が記号化に与える影響を緩和することができる。
このように車載センサ12の状態をいったん状態量グループ毎の状態量ラベルへと記号化してから、当該状態量グループごとの状態量ラベルの組み合わせに基づいて診断を実施する構成によれば、診断結果に対する瞬間的なノイズの影響を緩和することができる。結果として、瞬間的なノイズに起因して車載システム1の状態を誤診断する恐れを低減することができる。
また、本実施形態では複合診断部F32が、複数の診断時点での状態量ラベルの組み合わせの時系列データに基づいて、車載システム1の状態を診断する。逐次診断部F31の診断結果は、相対的に短時間的な処理によるものであるため、時間的なゆらぎに影響を受ける場合がある。対して複合診断部F32は、相対的に長い時間での状態量ラベルの組み合わせの変遷に基づいて最終的な診断結果を出力するため、一時的なノイズに起因して車載システム1の状態を誤診断する恐れをより一層低減することができる。換言すれば、より精度良い診断結果を得ることができる。
なお、逐次診断部F31は前述の通り、或る1時点での状態量グループ毎の状態量ラベルの組み合わせに基づいて診断するため、一時的なノイズの影響を複合診断部F32よりは受けやすい。しかしながら、不具合パターンの中には、不具合の発現期間が遡及時間に比べて十分に短いものも存在しうる。そのような発現期間が短い不具合パターンについては、或る1時点での状態量グループ毎の状態量ラベルの組み合わせに基づいて診断を実施する逐次診断部F31のほうが好適であるといえる。
また、上記の構成は、診断用データを診断対象の状態が過渡期であるか定常時であるか等の状態によっては使い分けない。つまり、診断対象の状態によらずに同一の診断用データを用いて診断を実施する。このような構成によれば、診断対象が取りうる状態の増加に起因して、診断精度が低下したり、診断用データのデータサイズが増大したり、診断用データの学習コストが増大したりする度合いを低減することができる。
以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。例えば下記の種々の変形例は、技術的な矛盾が生じない範囲において適宜組み合わせて実施することができる。
なお、前述の実施形態で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略する。また、構成の一部のみに言及している場合、他の部分については先に説明した実施形態の構成を適用することができる。
[変形例1]
上述した実施形態では、逐次診断部F31は所定の診断周期でラベル判定部F2の判定結果をサンプリングするとともに車載システム1の状態を診断する構成を開示したが、これに限らない。例えば図11に示すように、状態量グループ毎の状態ラベルの組み合わせが変化した時点での、状態量グループ毎の状態ラベルの組み合わせに基づいて車載システム1の状態を診断するように構成されていても良い。そのような構成は、ラベル判定部F2が状態ラベルの変化を検出する度に、その新たな(換言すれば遷移後の)状態量ラベルの組み合わせに基づいて逐次診断処理を実施する構成に相当する。
上述した実施形態のように、所定の診断周期で逐次診断処理を実施する構成では、前回の逐次診断処理実行時から状態量ラベルの組み合わせが変化していないにも関わらず、再び逐次診断処理を実行する場合が存在する。当然、同じ状態量ラベルの組み合わせに対しては同じ診断結果が得られる。そのため、同じ状態量ラベルが継続している場合に逐次診断処理を複数回実施することは効率的ではない。
対してこの変形例1の構成によれば、状態量グループ毎の状態ラベルの組み合わせの変化が発生する度に、変化後の状態量グループ毎の状態ラベルの組み合わせに基づいて車載システム1の診断を実施する。そのような構成によれば、状態量ラベルの組み合わせが変化していないことに起因して同一の診断結果が得られる診断処理の実行を抑制することができる。つまり、逐次診断処理の効率性を高めることができる。それに伴い、CPUでの演算負荷を低減することもできる。
[変形例2]
上述した実施形態では、状態量ラベルを状態量記号として用いる態様を開示したがこれに限らない。診断部F3は、状態量ラベルの系列を分節化してなる状態量シーンを状態量記号として用いて車載システム1の状態を診断してもよい。つまり診断部F3は、状態量グループ毎の状態量シーンの組み合わせに基づいて車載システム1の状態を診断してもよい。
[変形例3]
上述した実施形態では、DAA等を用いて連続的な時系列信号の集合を離散的な状態量ラベルの系列に変換する構成を開示したが、記号化の手法はこれに限定されない。例えば図12に示すように状態量グループ毎に状態量ラベルの判定ルールを予め作成しておき、ラベル判定部F2は当該判定ルールに従ってモードを判定してもよい。
ラベル判定部F2は、状態量グループを構成する所定の状態量が、判定ルールとして定義されている所定の条件を満たした際に、当該条件に対応する状態量ラベルに遷移したと判定し、以降その他の遷移条件を満たすまで同じ状態量ラベルが継続するものとして判定を行う。このような構成によっても、状態量グループ毎の状態の記号化を実施することができる。
[変形例4]
変形例3に関連して、ラベル判定部F2は、予め設計されている判定ルールと、或る状態量ラベルから他の状態量ラベルへの遷移確率モデルとを組み合わせて状態量ラベルを判定するように構成されていてもよい。例えば、ラベル判定部F2は、予め設計されている判定ルールと、実際の状態量毎のセンシング値とを照らし合わせることにより、状態量ラベル毎の該当確率を算出する。そして、算出した状態量ラベル毎の該当確率と、遷移確率モデルで定義されている状態量ラベル間の遷移確率とを掛け合わせた値が最も大きい状態量ラベルを現在の状態量ラベルと判定する。
例えば、第2状態量グループの状態量ラベルの判定処理として、実際の状態量毎のセンシング値と判定ルールとに基づいて状態量ラベルb1〜b5の該当確率をP1〜5と判定しており、現在の状態量ラベルから各状態量ラベルに遷移する確率モデルがQ1〜5に設定されている場合、現在の状態量ラベルbpreは、下記の式によって定まる状態量ラベルとすればよい。なお、式中のi及びjは1〜5までの整数をとる変数である。i及びjが取りうる値の範囲は、対象とする状態量グループに設定されている状態量ラベルの数に応じて定まる。
このような構成によっても、上述した実施形態と同様の効果を奏する。
[変形例5]
上述した実施形態では診断ECU11が、報告処理部F4と提示処理部F5の両方を備えるものとしたが、これに限らない。報告処理部F4と提示処理部F5とは、診断結果の出力先が異なるだけであって、何れか一方のみを備える構成であってもよい。
また、診断ECU11は、報告処理部F4と提示処理部F5を備えていなくとも良い。そのような構成においては、点検者が診断結果を参照可能なように、診断結果をSDカード等の書き換え可能であって不揮発性の記憶媒体に保存するように構成されていることが好ましい。ここでの点検者は、車両のユーザであってもよいし、ディーラーショップ等の作業員であってもよい。
[変形例6]
上述した実施形態では診断ECU11が診断部F3を備える構成を開示したが、これに限らない。診断部F3の機能はセンタ2が備えていてもよい。その場合には、車載システム1はラベル判定部F2の判定結果を逐次(例えば診断周期Ta毎に)センタ2に逐次送信する。ラベル判定部F2の判定結果とは、具体的には状態量グループ毎の状態量ラベルのセットである。状態量グループ毎の状態量ラベルのセットは、換言すれば、状態量グループ毎の状態を示す記号群に相当する。センタ2は、車載システム1から送信されてくる状態量ラベルのセットに基づいて上記の診断部F3と同様に診断を実施する。
上記の構成においてセンタ2は、診断結果を車載システム1に返送しても良いし、返送しなくともよい。センタ2が診断部F3を備える構成によれば、診断ECU11は、外部通信部15と接続されてあって、且つ、少なくともデータ収集部F1とラベル判定部F2とを備えていれば良い。つまり、診断対象には、外部通信部15、データ収集部F1、及びラベル判定部F2が備わっていれば良い。
ラベル判定部F2の判定結果は、連続的な時系列信号の集合を記号化したものであるため、状態量毎のセンシング値をセンタ2に送信する構成に比べて、データサイズを低減することができる。
[変形例7]
上述した実施形態では診断部F3は、正常モデルを用いて車載システム1が正常に動作しているか否かを反転する構成を開示したがこれに限らない。診断用データとして不具合パターンモデルのみが用意されている構成において、診断部F3は、いずれの不具合パターンにも該当しなかった場合に、車載システム1は正常に動作していると判定してもよい。つまり、正常モデルは必ずしも診断用データとして用意されている必要はない。
[変形例8]
以上では診断対象を車載システム1とする態様を開示したがこれに限らない。飛行機や船舶等の他の種別の移動体に適用することができる。また、工場設備や、家庭用のコンピュータなど、種々の装置に適用することができる。つまり、診断対象は、車載システム1に限らず、複数のセンサを備える種々の装置とすることができる。